# stën
> Thoughts, stories and ideas.
Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts.
Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`).
## Pages
_No public content available._
## Posts
### Rise, Tarnished: Automating Elden Ring in Switch 2
URL: https://sten.pw/rise-tarnished-automating-elden-ring-in-switch-2/
Last updated: 2026-09-29T05:49:24.000Z
Nine years ago, Bertrand Fan wrote [Automating Zelda](https://medium.com/@bertrandom/automating-zelda-3b37127e24c8?ref=sten.pw), a story about a Teensy microcontroller pretending to be a game controller so that Breath of the Wild could play itself. The article stuck with me. It stuck with me enough that I ended up [contributing to his snowball-thrower project](https://github.com/bertrandom/snowball-thrower/pull/1?ref=sten.pw), and enough that nine years later, I built the same kind of machine for a different game and a console that didn't exist back then.

This is the story of teaching a $25 dev board to farm runes in Elden Ring on the Nintendo Switch 2, and of finding out how far modern AI tooling actually gets you when you leave your comfort zone.

![](https://sten.pw/content/images/2026/08/IMG_3016.JPEG)

**The whole farm: one $25 board and a USB-C cable. Build yours from* [**here*](https://github.com/exsilium/switch-eldenring-boulder-farm?ref=sten.pw)**.*

## Why farm at all

I love From Software's games. The Dark Souls series, Demon's Souls: the remake was a genuine reason I bought a PS5 at launch. It all culminated in Elden Ring and Shadow of the Erdtree, a world so dense that Future Press needed three massive volumes ([I](https://www.future-press.com/shop/elden-ring-books-of-knowledge-volume-i/?ref=sten.pw), [II](https://www.future-press.com/shop/elden-ring-books-of-knowledge-volume-ii/?ref=sten.pw), [III](https://www.future-press.com/shop/elden-ring-books-of-knowledge-volume-iii/?ref=sten.pw)) to document it. The game was a hit on every platform it touched after its 2022 release, spawned the Nightreign spin-off, and now, in 2026, the complete "Tarnished Edition" is landing on the Nintendo Switch 2.

Here's the catch: From Software games notoriously lack cross-progression. Every new platform means starting over at level one. I've done the honest climb. It can be stressful. What I want on a new platform is to explore the Lands Between in a semi-god-like state, and that means one thing: level farming.

Located northeast of Greyoll’s Dragonbarrow, at a place known as Lenne’s Rise - a suitably elevated terrain - the game introduces a challenge similar to Indiana Jones and the Raiders of the Lost Ark. As players descend from this location, a huge boulder mysteriously spawns and rolls down after the hero. Defying typical physics as one might expect in a fantasy setting, the boulder specifically targets the player in a heart-pounding pursuit. If the player is able to quickly dodge this lethal trap, the boulder crashes down a cliff and shatters, rewarding the player with +1952 runes for their quick reflexes. 🪨🧺

Runes are the game's main currency and experience points that allows the protagonist to level up and become stronger! 💪If you are just starting your adventure in Elden Ring, this is one of the easiest ways to quickly acquire Runes to level up! Altough being a quick reward, doing this manually over and over again can (and will) become tedious.

In 2024 I solved this with a Cronus Zen, a man-in-the-middle adapter that sits between controller and console and runs scripted macros. It's infamous for enabling unfair advantages in multiplayer, but my use was strictly single-player: automating the rolling boulder at Lenne's Rise, a farming spot that yields around 240,000 runes per hour. Since level 100 costs roughly 2,000,000 runes total, a script left running does most of the tedious part for you. Most, not all. As with the Zelda automation, where the in-game weather could throw off the results, this farm has failure modes of its own: a pesky deer wandering onto the path to block or misguide you, or a system stutter (weather related?) causing an input to be slightly ignored or overplayed. Any of these can get the character killed, and the script keeps pressing buttons regardless. It wants an occasional check-in, not a full night unsupervised. My GPC script for it is [here](https://gist.github.com/exsilium/cd2ef4cbe61024c16e3fb56e33a4854c?ref=sten.pw).

***☝️\~240,000 runes per hour, zero human input.**

So when the Tarnished Edition was announced for Switch 2, my first thought was simple: plug in the Cronus Zen and reuse the script. The support page [said no](https://guide.cronus.support/nintendo-switch-2?URykk9WrdxwyZm=54J8Q5I5W&ref=sten.pw). No Switch 2 support.

Time to build something myself.

## Finding a way in

The original Automating Zelda rig used a Teensy++ 2.0 emulating a HORI Pokken Tournament Pro Pad, a Wii U controller that happened to work on the Switch 1\. That trick would most likely still work on the Switch 2\. But nine years have passed, and I wanted to know if something better was possible now: emulating a real Switch Pro Controller.

The most promising prior art I found was [esp-usb-ble-hid](https://github.com/finger563/esp-usb-ble-hid?ref=sten.pw), a project that emulates a full Pro Controller on the console side and bridges generic HID input into it: any controller, on a Switch 1\. A quick test confirmed that a real Switch Pro Controller works over USB on the Switch 2\. That settled the feasibility question: full Pro Controller emulation on the new console should be possible.

![](https://sten.pw/content/images/2026/07/pro-controller-usb-switch2.jpeg)

**If the real one works over USB, a fake one can too.*

I had an Adafruit [ESP32-S3 TFT Feather](https://learn.adafruit.com/adafruit-esp32-s3-tft-feather/overview?ref=sten.pw) sitting in a drawer, perfect for the job. And I had a second motive: I work with AI daily, and I wanted to see what current tooling does for embedded development, a domain I don't live in. If I express what I want, point at reference implementations and my previous work, do I get a working solution in minutes?

Spoiler: no. But the full answer is more interesting than that.

## The build

My toolchain for the experiment:

- [Odysseus](https://github.com/odysseus-dev/odysseus?ref=sten.pw) \- deep research and plan writing.
- [Visual Studio Code Insiders](https://code.visualstudio.com/insiders?ref=sten.pw) \+ Copilot plugin - base implementation.
- [GitHub Copilot App](https://github.com/features/ai/github-app?ref=sten.pw) \- feature build-out.

I started by writing a plan, with AI help, naturally, after running deep research on the existing solutions. The result lives in the repo: [plan-switchProControllerEmulation.prompt.md](https://github.com/exsilium/switch-eldenring-boulder-farm/blob/master/docs/plan-switchProControllerEmulation.prompt.md?ref=sten.pw). Then I set up PlatformIO in VS Code, bootstrapped a git repo, and handed the plan to Copilot running on Claude Opus 4.8\. Off it went, full of confidence, and within minutes scaffolded a project that compiled cleanly and uploaded to the board.

Awesome! ❇️

Except it didn't work. The Switch 2 ignored it. My PC reported an unknown or damaged USB device. And I didn't even know whether a PC *should* recognize a Pro Controller out of the box. (It should, without any extra drivers, one of many things I learned on the way.)

![](https://sten.pw/content/images/2026/07/usb-not-recognized.png)

**Compiled cleanly. Uploaded fine. Did nothing.*

This is where the experiment got real. My first rounds of feedback were as lazy as feedback gets: "It didn't work, what now?" The AI responded the way AI does: it reasoned, it reacted, it generated. My project sprouted USB protocol debug parameters. It also sprouted red herrings, at one point concluding that USB-C vendor authentication was the root cause. It wasn't.

The more rounds I did, the more I had to validate the AI's reasoning myself, which meant educating myself about what was actually happening on the wire and what was even possible. The devil was in the details, and pointing at a similar project was nowhere near enough. Afterwards I collected the full drift between plan and reality in [plan-remarks.md](https://github.com/exsilium/switch-eldenring-boulder-farm/blob/master/docs/plan-remarks.md?ref=sten.pw), but the highlights:

- **The Arduino framework was a dead end.** It couldn't initialize the USB handshake correctly.
- **ESP-IDF defaults to a 100 Hz tick rate.** Even correct code fails the handshake because the board responds too slowly.
- **The AI-generated HID descriptor was faulty.** A custom gamepad descriptor that didn't match the component, a true definition of slop.
- **Flash vs RAM descriptors.** DMA needs the descriptors in RAM; putting them in flash breaks things quietly.

Each of these was a side-quest of its own, and each needed me to steer the AI firmly toward the right resolution. But once they were solved, I had an emulated Pro Controller that a PC recognized instantly: inputs easily verified in Steam's controller configuration panel.

![](https://sten.pw/content/images/2026/07/steam-controller-test.gif)

**The moment it worked: Steam sees a Pro Controller. It's a $25 dev board.*

## From foundation to farm

With the foundation solid, the rest was a breeze:

- A Docker-based build system that doubles as a GitHub Action, so CI runs on every push.
- A rework of the one-off implementation into an engine plus declarative, GPC-style scripting.
- A controller overlay on the Feather's built-in display.
- Rumble read-back for experimental death detection, because deaths still happen and the script deserves to know. (⚠️This didn't work the way I had planned, but I left it in regardless).
- And finally, the port of the real Lenne's Rise boulder-farm routine from my earlier [GPC script (v1.1.0)](https://gist.github.com/exsilium/cd2ef4cbe61024c16e3fb56e33a4854c?ref=sten.pw).

**The board narrates its own inputs.*

The feature phase was where AI tooling genuinely shined. With the GitHub Copilot App I settled into a two-stage rhythm:

1. **Interactive mode** to draft a plan as a GitHub Issue, something I could assess, review, and edit outside the session. This would work just as well in a team setting.
2. **Autopilot mode**, which amounted to typing "Implement #12". Out came a PR on a branch that I could flash onto real hardware and validate before merging.

![](https://sten.pw/content/images/2026/07/issue-to-pr-copilot.png)

**Issue in, pull request out.*

I had a working solution ready before launch day. All that was missing was a copy of the game to test it against.

## Tarnished Edition Launch

![](https://sten.pw/content/images/2026/07/ER_TARNISHED-EDITION_NS2_UK.webp)

**This is it: the complete edition, four years after the original release, now on Nintendo Switch 2\. Details* [**here*](https://en.bandainamcoent.eu/elden-ring/elden-ring-tarnished-edition?ref=sten.pw)**.*

The game was announced on April 2, 2025, about two months before the Nintendo Switch 2 released on June 5, 2025\. Details were scarce at the time, but I knew right then that this alone justified getting the Switch 2 at launch. I'm a fan of physical media, so I was frustrated to later find out that one of the most high-profile third-party games for the system would ship as the dreaded Game-Key Card release: essentially a DRM key in the form of a game cartridge. It made little sense to me, especially after the successful Cyberpunk 2077 release on the Switch 2\. Reportedly, the game is simply too big to fit (This came out to be a lie! 😠). Oh well...

I'm not into buying physical Game-Key Cards, but I make exceptions: Resident Evil Requiem was one, and the Tarnished Edition had to be another. Of course I pre-ordered the physical copy! Shoutout to [Gameroom.ee](https://gameroom.ee/?ref=sten.pw) for the quick turnaround and having the game ready for pick-up on the launch day. 🎉🎈

### Time is of the essence

Each platform behaves a bit differently, so although I had tested the setup against Elden Ring on PC, the timings needed verifying and adjusting for the Switch 2 build.

Here are the changes I had to make:

- It's evident that Elden Ring feels "heavier" on Switch 2 - Input requires more time. Map reloads more slowly;
- For some reason, I couldn't summon Torrent the same way as on PS5/PC - I needed to add an extra input to trigger it smoothly;
- Added a separate menu item to trigger "A" when changing Controller / Grip Order.

☝️Overall, all of these adjustments were minor to get the loop running, except the farming performance was not what I had become used to. It matters not...

## What I actually learned

AI tools are powerful - well, I knew that already! But I couldn't express a wish and receive a working solution like magic: not in embedded development, not where the failure modes live in USB timing and descriptor bytes. The scaffold came in minutes; the working handshake took real debugging, real reading, and repeated correction of confidently wrong reasoning.

The pattern that emerged: Expressing a desire is not the same as receiving a result. AI accelerates you brilliantly on ground someone has mapped, and it will confidently walk you into a swamp on ground nobody has. The skill isn't prompting. The skill is knowing enough to tell the map from the swamp.

There's a bigger shift hiding in this story. Code is no longer the valuable asset it once was. Most of my repository was written by a machine in minutes, and anyone with the same tools could regenerate something like it tomorrow. What can't be regenerated is what it took to make it work: knowing that the handshake dies at a 100 Hz tick rate, knowing which confident claim is a red herring, knowing what a finished solution even looks like. The value has moved from the code itself to the knowledge and skills that turn it into a product, a service, or a solution. Or, in this particular case, a boulder farm.

Meanwhile, somewhere in the Lands Between, a boulder rolls down Lenne's Rise. Again. And again. My Tarnished stands at the bottom, collecting runes while I do other things. Sometimes a deer gets in the way. Sometimes the weather turns. That's fine: dying is part of the game.

Rise, Tarnished. Or at least, level up.
### Programmable XBee in Linux/MacOS/*BSD
URL: https://sten.pw/programmable-xbee-zigbee-radio-development-in-linux-macos/
Last updated: 2021-03-24T12:16:56.000Z
## Intro

[Digi](https://www.digi.com/?ref=sten.pw) is quite famous for its [confusing portfolio](https://www.sparkfun.com/pages/xbee%5Fguide?ref=sten.pw) of XBee radios that over the years have been featured in numerous DIY projects and are available from many hobby shops. There are literally [tons](https://learn.sparkfun.com/tutorials/exploring-xbees-and-xctu?ref=sten.pw) [of](https://spin.atomicobject.com/2016/07/18/xbee-tutorial/?ref=sten.pw) [guides](https://www.cooking-hacks.com/documentation/tutorials/xbee-arduino-raspberry-pi-tutorial/?ref=sten.pw) out there to get you started. They usually start by configuring the radios so that the channel works for communication. Continuing from there, the tutorials cover how to hook up an Arduino/Raspberry/\[Name-your-board\] so that they can "talk" to each other for whatever practical application you may have in mind. There is also an excellent book about [Building Wireless Sensor Networks](https://www.amazon.com/Building-Wireless-Sensor-Networks-Processing/dp/0596807732?ref=sten.pw) which covers XBee radios in detail as well as [Building Wireless Sensor Networks Using Arduino](https://www.amazon.com/gp/product/1784395587?ref=sten.pw) for more specialized usage and scenarios.

This is all **great**! But what if I told you, **you can add logic** to certain XBee modules without having any additional boards attached to it. This may or may not be news, but Digi also has a programmable variant of its radio modules, in which they have included an 8-bit HCS08 microcontroller ([MC9S08QE32](http://www.nxp.com/docs/en/data-sheet/MC9S08QE32.pdf?ref=sten.pw)) directly on the XBee module.

From pricing point of view, there's very little difference between the two. For an example:

| **Model**                                                | **SKU**         | **Programmable** | **Price**  |
| -------------------------------------------------------- | --------------- | ---------------- | ---------- |
| XBee-PRO ZigBee Through-Hole (Wire Antenna)              | XBP24CZ7WIT-004 | No!              | 25.83€+VAT |
| Programmable XBee-PRO ZigBee Through-Hole (Wire Antenna) | XBP24CZ7WITB003 | Yes!             | 27.99€+VAT |

This looks really really good and competitive, and one might start to wonder why aren't they covered in more detail, until you start looking into what you'd need to develop on it:

- You'd need a DEV-Kit ([XK2-Z7SBE0](http://eu.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyXK2-Z7SBE0&ref=sten.pw))! Digi sells one with some SMT version of the modules, interface board and a debugger for **400+€!** What if I just need one for blinking some LEDs?
- Although the excellent configuration tooling called [XCTU](https://www.digi.com/products/xbee-rf-solutions/xctu-software/xctu?ref=sten.pw) is a multiplatform offering, the development tools are strictly Windows bound!
- SDK Documentation and tutorials are all burried into the same Windows based SDK tooling, making accessibility difficult.

Based on this, it's easy to see why the Hobbyist crowd aren't much using these.

But what if I told you, **you don't need the DEV-Kit** and that **you can develop/flash the module at the comfort of your Linux/MacOS/BSD machine!**

## Development flow and tooling

**Time for some warning!** Do keep in mind that this solution makes it more challenging to debug your application. Also, it relies on the bootloader to work properly. The bootloader code is designed to protect its memory space not to overwrite itself but I guess it's still possible to end up with a non-functional XBee module. Consider yourself warned!

If you have familiarized yourself with the basic XBee modules, here's what you need with the Programmable variant:

- An [USB XBee Explorer](https://www.sparkfun.com/products/11812?ref=sten.pw) or [equivalent](https://www.sparkfun.com/products/11697?ref=sten.pw) with a working Reset button. The Reset button is used frequently to access the module's bootloader for Bypassing the onboard MCU or for flashing application firmware.
- [pxbee-fwup.js](https://github.com/exsilium/pxbee-fwup.js?ref=sten.pw) \- for flashing the built binary.
- Unless you are on Linux, [Docker](https://www.docker.com/?ref=sten.pw) is required for building the project as the compiler and burner are 32-bit Linux binaries.
- A Programmable XBee module (duh!)

### Building hello world

Start with a boilerplate hello-world project for blinking a LED on your new shiny Programmable S2B or S2C Xbee module. For that check-out the [pxbee-blink-led](https://github.com/exsilium/pxbee-blink-led?ref=sten.pw) project.

```
git clone https://github.com/exsilium/pxbee-blink-led.git
cd pxbee-blink-led

```

If you are using a S2C version of Programmable module, edit the `include/xbee_config.h` file and change `#define CONFIG_XBEE_S2B` to `#define CONFIG_XBEE_S2CTH`. Then build the project:

```
make all

```

For nuances about compiling on non 32-bit Linux, please see the above linked Github page but if you have [Docker](https://www.docker.com/?ref=sten.pw) installed the following should work:

```
make builddocker
make dall

```

This will produce an HCS08 binary (`./obj/blink_led.abs.bin`) that you can upload to the XBee module. The application offers very little in functionality - it just turns on/off pin 7 in 125ms intervals. The same pin is by default used for RX signal strength indicator so if your XBee shield has a LED connected to it, you will see a rapidly blinking LED when the application will boot up.

### Flashing

The factory shipped modules are all flashed with a bootloader and they do support firmware update over the serial interface. As long as the bootloader works, it's quite safe to upload a new application binary to the module.

For that, we need the help of [pxbee-fwup.js](https://github.com/exsilium/pxbee-fwup.js?ref=sten.pw) project:

```
git clone https://github.com/exsilium/pxbee-fwup.js.git
cd pxbee-fwup.js
npm install
./fwup.js --help

```

To flash the binary:

```
./fwup.js -d /dev/your-serial-port -b 9600 -F ./obj/blink_led.abs.bin

```

[![asciicast](https://asciinema.org/a/2BP9maFqVWEz2MdN37sb73KE4.png)](https://asciinema.org/a/2BP9maFqVWEz2MdN37sb73KE4?ref=sten.pw)

## Conclusions

For the DIY crowd on a Linux machine, there is now tooling in place that gives a good opportunity to explore Programmable XBee radios without big investments. Futher more, this will enable you to save power and reduce the footprint of your projects as there is no need for a separate microcontroller board.

**Have fun!** 🍻😎

## Some links

- [XBee-SDK Documentation](https://xbee-sdk-doc.readthedocs.io/?ref=sten.pw)
- [XBee-SDK API Documentation](http://exsilium.github.io/xbee-sdk-doc/?ref=sten.pw)
- [XBee Frame Generator](https://exsilium.github.io/xbee-frame-generator/?ref=sten.pw)
- [XBee Relay Trigger](https://github.com/exsilium/pxbee-trigger?ref=sten.pw) \- Practical application for automating garage doors and swing gates
### My 10+ years with a Mac
URL: https://sten.pw/my-10-years-with-a-mac/
Last updated: 2017-01-09T08:10:19.000Z
The recent Macbook Pro launch started an avalanche of discussions about what Apple has done wrong, how the MBP is not a real *pro* device and how the machine's only purpose is to get money from rich *iSheep*. Looking at Mac related discussions forums, there seems to be a vocal group of people who have had **enough** and they are moving away from Apple to Windows/Linux/*you-name-it* OS.

Some of the loudest arguments that got repeated to death:

- No ports! Pros need and use USB/SD/x ports! Welcome to Dongleland.
- It's slow! Skylake *lulz*!
- 16GB in 2016? What a joke!
- Expensive!

Well, as it stands, I ordered one of the 15" beauties with almost maxed out configuration (only constraining myself to 1TB instead of 2TB - *Ouch*, screamed the wallet). Why? Let me try to explain.

## TL;DR;

I like UNIX, I like macOS. Upgrades are different. My previous laptop was from year 2009 making the 2016 tMBP an excellent upgrade!

### Switching to a Mac in the first place

Looking back at my computer history I started with a PC - DOS, Windows 3.1, 95, NT, 98, 2000, ME, XP. In 1996 I was exposed to FreeBSD and Linux (Slackware) which i grew to love enormously, but purely as a server side OS. A big part of why I loved and used Windows at the time on my Desktop, was the games. I didn't care much for the OS itself, but it was the standard at the time for productivity/document authoring (Office) as well as entertainment/gaming - remember, this was all before Web 2.0 explosion.

I don't count the times when I had a multiboot setup or experimented with different Linux desktops, because it doesn't really count if you don't use it as a daily driver. I remember that there were severe limitations accessing NTFS partitions from Linux side and vice versa creating data silos. During the experimentation phase I quickly realised that I needed a single OS, switching between different two worlds wasn't for me.

I don't recall when I made the switch, but I do remember the game that finally pushed me over to the Linux side - it was **Neverwinter Nights** Linux client release. After that, in 2003, I found that, hey, I can live in Linux! 🙌 Wine was able to run MS Office programs, so I made the decision to see it through and the disk/partition that hosted my Windows installation was slowly forgotten.

Still, I can't say my Linux desktop experience was smooth. Actually, it was quite the opposite. Driver issues and compatibility as well as the whole upgrade experience became an hurdle. This was partly due to Linux dependency-circle-of-hell that eventually always surfaced. Some of my mandatory commercial driver packages contributed to this issue a lot. Every upgrade started to become a challenge to get everything working. This kind of constant (re)configuring started to distract me.

Late 2004 I started to look around for a laptop due to increased traveling and my experiences with Linux on the Desktop as well as multiple sources stating that Linux in laptop is a bumpy ride (drivers, power management) made me look elsewhere. A coworker of mine at the time had made the jump to experiment Apple's Mac OS X and demonstrated proudly his new [iBook G4](http://www.everymac.com/systems/apple/ibook/specs/ibook%5Fg4%5F1.0%5F12.html?ref=sten.pw). Already then, the white plastic shell looked like something straight out from a sci-fi movie. The owner of it was also a Linux fan, so it was a good reference to begin with.

The winning arguments at the time was that OS X was really a UNIX OS at heart. There where two package managers [Fink](https://en.wikipedia.org/wiki/Fink?ref=sten.pw) and [DarwinPorts](https://en.wikipedia.org/wiki/MacPorts?ref=sten.pw) bridging the world to GNU and OSS so this made my soon-to-be-system familiar even before I had one. Another winning argument was that the software and hardware came from a single company - no driver issues guaranteed! If something didn't work, you knew whom to blame. As an added bonus, the gaming situation, although not comparable to Windows, was much better than in Linux, so it felt like I was gaining something. 👌

I did get a word of advice from another Apple "pro" user to stay away from iBook and look towards more capable PowerBook. I was oblivious to the PowerPC CPU situation, nor did I have any insight to the rumors about Apple switching to Intel. I was just happy when in early 2005 I found a good offer on a barely used [PowerBook G4 17"](http://www.everymac.com/systems/apple/powerbook%5Fg4/specs/powerbook%5Fg4%5F1.5%5F17.html?ref=sten.pw) which was a BTO/CTO configured machine. The top of the line model available at the time.

This machine was marvellous piece of engineering. The software worked so well on the laptop that first time ever I started to rely on laptop sleep function. The UI was refreshing, everything was running smooth and with the help of [Quicksilver](https://qsapp.com/?ref=sten.pw), launching applications was superfast and intuitive. It was remarkable experience that showed how hardware and software can work together. It quickly made my Desktop PC obsolete. This happened 12 years ago.

### Switching to Intel Mac

In retrospective, I was bummed when Apple announced that it will be switching to Intel based CPUs already during the same year when I had bought my first Mac. However, the effects of how and what it would mean to me as a user were unknown. Apple kept improving its OS and as long as my machine was supported, everything worked really really well making me a happy user. Because of the significant number of PowerPCs out there, the support for the architecture remained strong.

I ended up using the trusty Powerbook until 2009 when Apple launched the new Unibody design. I switched to a [Macbook Pro 17"](http://www.everymac.com/systems/apple/macbook%5Fpro/specs/macbook-pro-core-2-duo-2.66-aluminum-17-early-2009-unibody-specs.html?ref=sten.pw). Comparing to the competition, it was strongly ahead. It was a beautiful piece of engineering that also cost arm and a leg but I already knew what to expect and I knew it was worth it. I ended up getting the "*cheapest*" 17" MBP one could buy (brand new this time), but I did end up upgrading the memory and switching to SSD at a later time. I knew the journey I was on and I was comfortable knowing that the investment in the machine will be for many years to come. The launch of the Unibody received some screams as well, Apple had chosen to go with a glossy screen as default, although offering matte BTO/CTO option. I remember a lot of the comments about this being not a *pro* move.

In 2011 I started to use a 2009 15" Unibody MBP that I received from work. As my wife had used the Powerbook G4 to write her Master's thesis (showing some challenging performance issues) and planned to start her PhD dissertation, I proudly handed the 17" Unibody to her, she's been happy with it to this day.

### macOS on Desktop

In 2012, mainly out of curiousity, I built myself a Desktop machine with passive liquid-cooling and I squeezed OS X on it with an ulterior motive to occasionally play something on Windows 🤡. The i7-3770K machine hasn't given me any headache. I've upgraded from one macOS version to another and the only components that have changed are either SSDs (I currently run 2x1TB SSD in RAID-0 configuration) or memory (now @ 16GB). Some trickery and magic were needed at some point to get iCloud and some other services to work. I don't really fancy that. It's clear that although Apple doesn't actively block the Hackintosh crowd, they don't necessarily make their life easy - protecting their cloud infrastructure and customers, it all makes sense. However, there has been no urge for me to boot into Windows 10, other than the occasional AAA game title that gets launched. I dream more about gaming than I have actually time to enjoy them - such is life.

### Time to move forward

Oddly enough, I was still quite happy with the 2009 models. Although I know that there has been plenty of improvements over the years, none seemed significant enough for me to go out and buy a new machine.

Latest version of macOS changed that. Apple doesn't support installing the newest MacOS 10.12 "*Sierra*" on our 15"&17" 2009 Unibody models, nor will I start to force it. There's no real point to it. My wife is happy with that machine and I figure *El Capitan* will receive security fixes for the next year or two. Kudos to Apple making planned obsolescence work that well. Suddenly, I was on a lookout for a new machine.

For me, when I saw the announcement of the 2016 model I knew it was time for me to move on, not away.

### The Macbook Pro 2016

#### Why? Why not?

The choices we make in the past and the experiences we gain, shape our decisions for the future.

Looking back more than 10 years with Apple, I've had only 2 different Mac generations, the PowerBook and the 2009 Unibody. Both did receive some minor upgrades (battery for the G4, SSD and/or memory for the Unibodies) but they have proved themselves to be battle worthy. I didn't have any issues with them nor did I have any complaints - why should I change? Just because the rage on the Internets? Nope.

Speaking of complaints, let's circle back to the original list of screams about the 2016 MBP to see how I feel about things:

- USB-C is a great standard, I like how Apple seems to have fully invested into it. I personally have very little appliances that I hook up so I don't feel the pain. I did buy the following to ease the transition though:  
  - [Sony USB-A/C flash drive](https://www.amazon.com/dp/B01AZC3NWY?ref=sten.pw)
  - [nonda USB-C to USB 3.0 Mini Adapter](https://www.amazon.com/dp/B015Z7XE0A?ref=sten.pw)
- [It's not slow](https://www.cpubenchmark.net/compare.php?cmp%5B%5D=2863&cmp%5B%5D=2699&ref=sten.pw). Moore's Law **is** slowing down @ Intel. The only Kaby Lake mobile CPU that is aimed at performance and was available at the time of launch was the dual core i7-7500U. An i7-6920HQ which is a four core model almost doubles the performance. A new generation of Intel chips no longer brings the added performance bonuses that people have come to expect. Upgrading from Penryn T9550 however, does. The new chip is more than **5 times** faster. Apple has skipped generations before, they might do it again.
- Memory - If you really need beyond 16GB then, yes.. you have a problem. Even when running VMs, it's hard for me to exhaust all that memory. Heavy lifting for me happens in the cloud. I just can't relate to the problem.
- It is expensive, this is not news, it has always been so. Then again, I don't switch machines every year.

Some reasons I'm not switching away:

- I really like macOS. To the point that I even use it on non-Apple hardware (*sssh!*)
- Linux position and experience on laptops hasn't changed over the years. The alternatives that are offered are limited, often sub-par and buying just "any" computer for cheap doesn't justify the potential driver/power management hell. It's never fun to hit some serious UEFI issue to boot Linux.
- You pay for the full experience. You simply can't get similar UNIX experience anywhere else.
- XPS Developer Edition is often cited as recommended alternative to MBP. Sorry, but when it comes to build quality and sturdiness, you simply can't compare these two.
- Although it costs more, I *feel* like I get more out of it.

#### First impressions

- Received it 2017-01-05
- Youtube videos and pictures don't do it justice, the thing is an absolute marvel of engineering to look at, feel and use.
- My unit came with macOS 10.12.2 installed, the release date of that was 2016-12-13
- Keyboard is nice, quickly adapted, but I'm not sure I can get used to the silent/feedbackless tbESC, I might need to remap.
- Some of the TouchBar functionality is nice. It's not a must have revolution, but it is a convenience function if the software supports it. I was delighted to see that the just recently launched [Spark](https://sparkmailapp.com/?ref=sten.pw) already has built in support. I do get it why they call it the emoji bar. It's actually useful for that function 😏
- I do miss MagSafe for charging.
### Goodbye Confluence
URL: https://sten.pw/goodbye-confluence/
Last updated: 2021-03-23T15:38:46.000Z
It all started simple enough, a simple wiki to host different projects and experiments. Among all the other great functionality for the time, It also had a "*News*" feature that at a later date evolved into a blog.

But *The Times They Are A Changin'*, so it's been a fun experiment with some takeaways:

1. Blogs are fun, even if no one reads them but yourself - the magical number of 7 limits our working [memory capacity](https://en.wikipedia.org/wiki/The%5FMagical%5FNumber%5FSeven,%5FPlus%5For%5FMinus%5FTwo?ref=sten.pw). It's fun to look back even a year or two to see what felt *important* at the time, triggering different emotions as you look back - both good and bad.
2. Stick to one language. I scribbled stuff in Estonian but even when writing just for myself, it felt out of place. As English isn't my native tongue, I don't have to feel embarrassed when looking back at all the awful spelling mistakes i did ;)
3. Archive and move on. I think that was the hardest part. A collection of *something* that hold marginal value only to yourself. Software entropy at work is good motivation to make the switch, but it's emotionally hard to break away from something old to something new. Still, it's a beneficial and needed exercise to do just that!

Confluence Blog statistics:

- Total entries: **38**
- Time in service: (4th of May) **2008-2016** (24th of April)
- Shutdown: 2016-11-17
### Welcome to Ghost
URL: https://sten.pw/welcome-to-ghost/
Last updated: 2026-06-19T18:09:10.000Z
Ghost is not new to me. I've patiently waited while the software matures to the point that I can migrate away from my current [Atlassian Confluence](https://www.atlassian.com/software/confluence?ref=sten.pw) setup that I have been running since [2008](https://en.wikipedia.org/wiki/2008?ref=sten.pw).

Confluence is (was) great, but for personal use it's simply a piece of complexity that requires huge amount of resources to properly run (Java! I'm looking at you!). Instead, I've taken on the quest to find ways to make things thinner and lighter. I'll export my old legacy stuff for archiving purposes and will just try to **let it go...**

Before that happens though, this article will remain my testing grounds.

#### Node Bulletin Board

NodeBB and Ghost seems like were made to complement each other. A lot of the philosophies are shared. Namely **Markdown** has been made centerpiece for formatting.

When a Ghost entry is greated, NodeBB topic can be created to handle the comments. This is great! However, one thing to keep in mind is that the stub that gets created in NodeBB is not updated and only reflects the content of the article at the time of creation.

#### Confluence vs Ghost+NodeBB

###### Projects and pages

Confluence was about creating a "space" for a project and then arbitrary number of pages and sub-pages with content under that space. However, for smaller personal projects NodeBB allows similar content management. Categories and sub-categories represent the "space" and a thread a particular content page.

###### Blog

In Confluence, Blog was just a special content within a space and a lot of effort was put into making the Blog section look something more interesting than the vanilla Confluence site. Ghost as a publishing platform is much more elegant for those purposes and the theming options are endless. However, the basic "casper" theme is so modern and clean that I don't see any immediate reason to switch to something more custom. However, I've tweaked some of the css to make the site more "me" in terms of switching to a monospace font. There are plenty of free and commercial Ghost themes available. One possible caveat seems to be that many of them are out-of-date when it comes to supporting all the newest features of Ghost...

###### Sharing access

Confluence was connected to Atlassian Crowd, an identity management solution that made it easy to propagate single identity over multiple Atlassian products. Still the requirement was that the use account was registered within the Crowd itself and for personal projects, again... too much overhead!

Sharing access to particular category within NodeBB has been made easy. The access management is really fine grained and the user can utilize different authorities to log in to NodeBB.

Access to Blog isn't restricted, as well.. that's the idea of the Blog, these are public postings after all.

#### Testing

> This quote block!

> \--Cool!

```
This is a code block
Here every line is rendered
As entered

```

##### Tables

Unforuntately, the native markdown extension for tables is not supported. Ghost proclaims that all HTML is valid markdown, so one must enter tables like so:

| Feature              | Intel Core2 Quad Q9650 @ 3.00GHz | Intel Core i7-6920HQ @ 2.90GHz                                                                               |
| -------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| Socket Type          | LGA775                           | LGA1151                                                                                                      |
| CPU Class            | Desktop                          | Laptop                                                                                                       |
| Clockspeed           | 3.0 GHz                          | 2.9 GHz                                                                                                      |
| Turbo Speed          | Not Supported                    | Up to 3.8 GHz                                                                                                |
| \# of Physical Cores | 4                                | 4 (2 logical cores per physical)                                                                             |
| Max TDP              | 95W                              | 45W                                                                                                          |
| First Seen on Chart  | Q4 2008                          | Q1 2016                                                                                                      |
| \# of Samples        | 802                              | 48                                                                                                           |
| Single Thread Rating | 1272                             | 2047                                                                                                         |
| CPU Mark             | **4266**                         | 9595 \[Source\]\[CPU Benchmark\] Credits Post cover image by faxdoc licensed under terms of Creative Commons |