pünktlich angekommen

Median-Verspätung

jede 10. Fahrt

beobachtete Züge

Letzte 30 Tage, Fernverkehr. Alle Messwerte offen einsehbar

Günstig, schnell oder beides: Bahnsparer zeigt dir die Wahl

Der billigste Zug ist oft der unpünktlichste – im Fahrplan sieht man das nicht. Die KI in Bahnsparer bewertet jede Verbindung und markiert den besten Kompromiss.

I feel surprise at how well neural networks work. LLMs work like "gut feeling" as they just generate one more token after another. There is no planning or reasoning algorithm inside. Yet, some planning and reasoning emerges.

I feel fear about an impending doom. Yudkowsky's argument that a superintelligent AI will inevitably destroy humanity seems to have no flaw. Yet, nobody seriously tries to sandbox AIs because they are too useful with access.

I feel disgust about AI companies destroying the open web society. Their crawlers and agents make it increasingly difficult to sustain an open community on the web. Like a locust plague, they descend on any open wiki and forum and overwhelm them.

I feel sad about the artists who suffer due to AI-slop competition. Being an artist always required some sacrifice and only a few are fortunate to gain some wealth. This is even harder now that AI can generate some kinds of "content" cheaper and faster.

I feel anger about the inability of our political systems to rein in the power of capital. While I can rant about politicians a lot, I still prefer a democratic government to have power instead of billionaires. It essentially just comes down to making some decisions in a coordinated way, but most people are not even aware of the problem. This also covers the environmental destruction by AI companies as they greedily gobble up all kinds of resources.

I feel happy to live in this age of discovery. We might observe the creation of artificial intelligence. Working in software development, the practice was radically transformed forever in 2026. It is fascinating to observe this firsthand. It allows me to generate stuff (code, images, music) which would never have been created otherwise.

As a conclusion, does the good or the bad outweigh the other? It seems positive on a technological level to me, but bleak on a societal level.

(I used Mistral as reviewer here. I typed every word myself.)

It's complicated

Decapitating Macbook: An Odyssey

Intro Part 1 of 11

Accepting that I need a Mac if I want to develop for Apple platforms.

I don’t tend to enjoy using Apple products. I want to be able to make my software available on their platforms though.

To publish apps for MacOS/iOS/iPadOS, you really need Apple hardware. Also, if I am to provide software for their platforms, and especially if I want to sell my work, I need to be able to experience my apps in the same way my users will experience them.

It’s basic respect for the user.

Virtualisation

I tried Virtual Machines, probably had half a dozen MacOS VMs over the years in VirtualBox and QEMU/KVM. Getting MacOS working in a VM is difficult, inconsistent and (at least on my machines) performance isn’t great. Apple strongly does not want you doing this, you’ll always be swimming upstream.

It’s a joyless experience.

Codemagic

I tried Codemagic, a continuous integration/continuous delivery service which lets you publish to various platforms including the Apple ones. It’s a great service and has a free tier, but it seemed that my usage would end up putting me in a paid tier, and that could get expensive for me quite quickly.

It’s also from-a-distance, and while Codemagic does allow remote login to the MacOS GUI it’s not the same as having a device in front of me, and if I want to thoroughly check the experience of using my apps on Codemagic’s remote machines (rather than just running builds) that’s going to quickly eat up any free minutes.

I can certainly see this being a solution for some situations — not mine.

So…

For the first time in over 20 years of owning dozens of computers, I allowed myself to decide that I needed some kind of Mac.

Which Mac Should I Get? Part 2 of 11

Finding a Mac that I can work with.

The strongest factors affecting my decision were:

• Cost. I wanted to spend as little as possible.
• Power usage. I live in a low-power environment and didn’t want to introduce a new device that was going to dramatically increase my electricity usage.

Clearly Apple Silicon was what I needed in terms of power. I’ve preferred ARM processors for years and use them for as much of my work as possible. Apple’s use of specialised ARM chips and tight control over their hardware/software architecture means they’re in a good position to maximise performance-per-Watt… if I must paddle in Apple’s pool, Apple Silicon is a no-brainer.

To keep it cheap, the obvious choice was to go with the first generation M1 chips. They reportedly still held up well and should get OS updates for a while (even longer with OpenCore Legacy Patcher).

I don’t love laptops (I’d rather choose my own keyboard, pointing device and screen so having redundant copies of these things stuck on my computer is a waste), so I was initially attracted to the M1 Mac Mini. It’s just a computer, without Human Interface Devices that I don’t need.

Two things put me off the M1 Mac Mini though:

It has a fan

People say it’s silent. Even if this is true (there are levels to this), fans are mechanical devices which can wear out (and develop a noise), suck/blow dust around (needing to be cleaned), or fail. They also use power.

Power delivery

The battery bank from which I power my home is 12V (24V or 48V would be better and I’ll upgrade when the time is right). All my electricity comes from this battery bank.

I have a power inverter, meaning I can use appliances with normal/household plugs, but the inverter wastes some power in the conversion process, stepping up from 12V to 220V. To then plug in a power brick, which will again throw away some power in converting 220V back down to whatever voltage a device uses, means double wastage, and a mess of plugs and wires.

I have DC 12V from the battery, and an easily-accessible 20V feed via a step-up converter. Then of course I have 5V over USB, not to mention all the exotic USB-C variants. Between all these methods I can power everything that I use regularly.

When I buy a new device the first thing I do is chop off its power connector, attach it to one of the XT60 connectors I use for everything , and chuck (hoard, actually) the device’s power brick. I’ve done this with multiple laptops and small form factor PCs without issue. They usually seem to want 19V-21V and be tolerant of 20V although I’ve heard stories of people damaging stuff with similar reckless behaviour to mine so maybe I’ve been lucky.

I searched for info about doing this with the M1 Mac Mini’s power brick and found some people saying they had problems. While writing this I just searched again to try to find those discussions but this time I found stuff suggesting it’s fairly easy. So I’m not sure if I used the wrong search terms before, or maybe I was just too jumpy about modding power delivery for an Apple device. Apple tends to be so unfriendly towards going off-road and they’re known for implementing measures to prevent you doing things in ‘unapproved’ ways. I didn’t want to waste money buying something I couldn’t use.

For better or worse, I decided against the M1 Mac Mini.

M1 Macbook Air Part 3 of 11

I admit it's a modern classic.

Despite its laptop-ness, I decided to think harder on the Macbook Air:

• It’s thin, light and particularly low-powered
• It’s fanless
• Although I’ll never prefer it, Apple (/my?) users tend to love the trackpad, so the ability to check out my apps on the M1 Air’s trackpad and make sure everything feels ok might be useful

My issue with the redundant (for me) display being attached?.. this could become an advantage.

People sell these machines cheaply when the displays break (Apple is… not big on right-to-repair). I could buy a Macbook with a broken screen and remove it. I checked whether this was possible (such things are a given with most laptops but with Apple I wasn’t sure what to expect). I found that this was doable, people were out there doing it. Fantastic.

‘BUY IT NOW’

I managed to find a smashed-screen, 8GB M1 Macbook Air in Rose Pink on eBay for £300. Really if I’d waited I could probably have picked one up for less.

But this was a strike while the iron is hot situation… my resistance had been strong for many years, if I waited I might easily end up changing my mind.

8GB RAM? Rose Pink?

I’d ideally want 16GB RAM minimum on a modern laptop, but the price difference between that and 8GB was significant, even on the second-hand market. Everyone seemed to be saying that 8GB on Apple Silicon was like 16GB on AMD64, which sounded distinctly like the reality-distortion-field in effect, but there were architectural realities such as their ‘Unified’ memory architecture to back this up (or at least the idea that you get more bang per GB on Apple Silicon). I’d decided to trust.

I was mainly interested in using this machine for Flutter development, and had found several people saying they were doing that on an M1 with 8GB without issues. [Note from the future: It’s great, no worries and easily snappy enough for me]

This model was Rose Pink, the colour I’d usually be least likely to choose. Considering I was buying it to immediately butcher, this somehow made it all the more perfect.

It's from eBay. Does it Even Work? Part 4 of 11

I've generally had decent experiences buying from eBay. But before I start chopping bits off my purchase I should probably make sure it works.

Being an eBay purchase (albeit from a seller with good feedback) the first thing I needed to do was make sure that this thing was actually functional.

The screen was damaged (as per the listing) and displayed basically nothing, or to be specific a few single-pixel lines of colour which hinted at whether the machine was on or off, on a black smashed background.

Nothing so garish as ‘an LED to tell you when its powered on’ would be allowed on a modern Mac. These thin, single-pixel lines of colour would be my power indicator.

Monitors and cables

This is where I encountered my first difficulties. I have a very small, very cheap USB-C monitor. This is the only actual monitor I have. I usually run stuff headless over VNC, NoMachine etc, using tablets like my Galaxy Tab S8 Ultra as remote OLED displays. I just don’t have much need for monitors. I have a Boox Max Lumi E-ink tablet with a micro HDMI input, so that can act as a monitor but… maybe later.

So I plugged the little monitor in to one of the two available ports on the characterless bravely minimal chassis (the other port would do for power). The monitor didn’t light up.

A vast landscape of confusing possible states opened up before me. Was I in the wrong port? A USB-C port is not a USB-C port etc, especially where displays and power are concerned. Maybe only one specific port would power the Mac, or only one of them would output a display signal.

What about the cable, both cables? Were they even providing power/pixels or did they have the wrong strands in them?

Did the Macbook put out enough power over USB-C for the monitor? Did I need to plug an additional cable for power, or charge the battery some more, or plug extra power into the monitor itself?

Was my monitor just not compatible? It’s a simple AliExpress generic thing, and Apple is not exactly known for its broad compatibility with 3rd-party products. Was it just not-yet-enabled in the OS?

Was I even ‘in the OS’ at this point, or was the Macbook still booting… or stuck in some horrific ‘recovery zone’ where blindly pressing the wrong button might result in destroying the OS, the only solutions to be “plug it into one of the other Apple computers that you don’t have” or “take it to an Apple Store where (if somebody dressed like you is allowed inside) a Genius will go asthmatic at the concept of a headless Macbook and make you buy a new one for a thousand of the pounds that you don’t have”?

After an embarrassing amount of cable-swapping (80% of my USB-C cables either couldn’t deliver enough power, or couldn’t deliver the pixels, and I’ve been through this stuff so many times I should know by now to never assume that my cables are good) I eventually made progress.

The monitor lit up.

Then it went black again. Not dead-black, but that rubbish glowingly-grey attempt at black that TFT panels manage, which told me that the monitor was powered up and trying to display something, but had nothing to display.

Power button

The Macbook does grant me a power button at least, in the form of a special key on the keyboard, up in the corner.

It’s a strange item, sitting slightly lower than the other keys on the keyboard, with a slightly different tactile response compared to the other keys. Maybe this is to mark it out as being ‘other’ for usability reasons (which I like), or maybe it’s a side-effect of the button housing a fingerprint sensor.

With my lack of Apple experience and the lack of working screen, I actually found this button a little confusing. I was never sure if I’d pressed it ‘properly’, ie did it require a tap, or a little hold, or did perhaps a long hold perform a different function?

I tried searching for info about the button but there are so many different models of Macbook, many users with varying ways of communicating their ideas, no official detailed documentation for these things, and of course the reasonable assumption that Macbooks have screens. Yes, I was confused by a power button.

After several presses of the power button, and waits to see if a reboot was happening, more progress. Trees! The MacOS login screen appeared, only… not quite. There were no buttons, dialogues, or any user interface elements.

A bit of searching taught me that the missing login UI was indicative of a second screen being attached to a Macbook. The login screen was being shown (invisibly to me) on the broken internal display, and my little monitor was just acting as an extension. Fair enough.

More ‘internet research’ revealed that CMD + F1 would swap output to the external monitor. This worked. Great. I now had a dinky 11" MacOS login screen.

It Just (about) Works.

Removing the Display Part 5 of 11

Finally getting down to some hardware pruning.

Removing the display was relatively easy, but time-consuming. There were lots of screws and they had pentalobe and torx heads, but these are standard in any electronics screwdriver set — I have one of those.

I checked a couple of disassembly videos on YouTube to make sure I wasn’t going to encounter any plastic tabs which might break off, short tearable ribbon cables etc, and to find where the display connectors were. I’ve taken apart quite a few laptops, this wasn’t one of the worst.

Separating the lid from the base was tricky. Even when all fastenings were removed it was still stuck. I couldn’t tell if it was just tight tolerances on the hinges (hey, get the tolerances tight enough and metal sticks to metal… although I think even with Apple’s admittedly precise engineering this was probably normal stuckness rather than anything more mystical), or if there was a piece of the assembly in the way, something I’d missed.

I found a video suggesting to open the laptop to 90 degrees, then hang it off the edge of a table and give it a sharp whack to separate the lid from the base. They made it look easier than I found it to be, but eventually I got the lid off.

Keeping the lid

After looking into various cases and sleeves (if nothing else I wanted to be able to stop keys from getting pressed when the Macbook was put away and waking it up), I decided that I’d keep the lid. It is thin, light and tough, so why not continue using it to protect the computer? It was designed for the job.

Getting the glass panel out of the lid was a chore. Like most modern displays it was very thin and shatterable (pre-shattered in this case), and gripped tightly to the inside of the metal shell of the lid via some kind of adhesive or thin tape. I had to use heat and a scraper and it made a horrible and probably dangerous mess, thousands of specks of shattered material that looked pretty like toffee-apple but were actually cutty, inhalable glass.

I worked slowly, every minute or so I swept up the latest shards into a container so they wouldn’t get embedded in my hands/cornea/bronchioles. I did this gently so as not to disperse the bits all over the place with the flicking of the brush.

After a while I had the idea of sticking a patch of duct tape over each area of glass before I scraped it away. This worked well, preventing the pieces from scattering and making it easier to scrape the glass away from the metal shell of the lid.

With all the glass finally removed, there were a couple of areas which remained sticky and some unfinished sharp metal edges. To prevent it from getting hair stuck to it or from scratching the keyboard/touchpad I covered the entire inside surface of the lid with some clear adhesive plastic sheet.

The final effect is reminiscent of an overprotected sofa, but it’s all I had to-hand and it’ll do for now.

Factory Reset Part 6 of 11

Just a formality...

The display was removed, things were looking clean.

This is a used device. It seemed like the OS was a fresh install, but I like to be sure, so I did a factory reset. The process seemed smooth, until the reboot.

I wasn’t sure how long to wait for boot after a factory reset. I’ve had some devices (eg Android phones after installing custom ROMS) take many minutes on first boot after a reset, but online info suggested this should be pretty quick on an M1 Mac.

Minutes passed and the display wasn’t showing anything. I wasn’t sure what was going on, and I started playing guessing games with the power button. I wished again that there was a power LED. With the broken screen removed I couldn’t even rely on those few lines of pixels lighting up to give me clues.

I’m still not sure if I broke/interrupted something, or if this was a normal part of the reset process. I tried various patterns of tapping, holding, holding for longer, each time waiting for something to happen for 10, 30 or 60 seconds. How long should I wait before I expect to see something on the screen?

Eventually I got something to happen. I was back to the black (but lit/powered on) screen. I guessed I was somewhere mid-boot. I tried the CMD + F1 combo which had made the external monitor primary when I was on the login screen. It didn’t work – the key combo/switching must be a feature of MacOS, which I was not yet booted into. A little reading around online hinted that I might be in recovery mode.

I found a video explaining how recovery mode worked on a machine with an external monitor and no internal display, and how to handle it.

Recovery mode when you only have an external monitor

The situation is this:

• Recovery mode recognises your external monitor, but treats it as an extension to the internal display
• The window with all of the useful user interface is there, but it’s ‘on the internal display’ (whether that exists or not)
• The phantom internal display is drawn off to the right of the external monitor

In my case, the resolution of my external monitor was smaller in height than the internal monitor. This may have made the situation more confusing. I think that the top menu bar extends across both displays, and if my monitor was tall enough I’d have seen the bar, giving a massively more helpful clue than the empty black screen.

To get stuff done in recovery mode, you have to drag the window from phantom screen, onto the external display. The window is only draggable by its title bar. So you have to shoot your touchpad pointer off the right-hand side of your screen, aim for where you think the title bar might be, and try to tap/drag it back over to your real visible screen on the left .

This took me ages. I think the window on the invisible screen was centred, but because it was a different resolution to my monitor it was hard to visualise and aim for it. But once done, I could access everything in recovery mode.

After finishing the reset I booted. The monitor doesn’t start showing stuff until later in the boot process but that’s ok.

I’m in, on the external monitor, with the Macbook’s internal screen removed.

Is This Thing On? Part 7 of 11

Questioning my hatred of LEDs.

One of the most difficult problems I’ve had with using this machine headless, is knowing whether it’s turned on or not. Seriously.

If I connect the external monitor (ok, not headless in that case), no image on the screen might mean:

• The Macbook is not turned on
• The Macbook is asleep
• There is a problem with the monitor or connection (eg bad cable)

If I try to connect over NoMachine or VNC and fail, that might mean:

• The Macbook is not turned on
• The Macbook is asleep
• The Macbook is not connected to the network
• NoMachine/VNC is not started on the Macbook
• I’ve configured something wrongly with NoMachine/VNC

I really dislike the millions of blinking LEDs designers love to stick on electronic devices. They constantly nag or distract, I think they are bad. But I’d kill for one one this Macbook!

Things I’ve tried

I have a small USB-C SD card reader. It has a red LED which lights up when it is receiving power. For a while I used this, but it’s impractical. Although it’s small, it still sticks out to be breakage risk. A nice bit of leverage on the USB port, just waiting to wrench it off if it catches on something (a bit like the 1st-gen Apple Pencil when it was charging).

At some point I noticed that the caps lock button on the keyboard had an LED which lit when caps was locked. And (remembering I’d usually be using a Bluetooth keyboard and pointing device), the caps lock could be applied to the built-in keyboard without affecting the Bluetooth keyboard. I could just leave caps lock on and the LED would stay lit.

The showstopper problem with both of the above ideas was that they both only worked when the Macbook was fully booted and ready to rock. I guess the ports and caps lock LED are powered off at other times. Most of my periods of confusion as to whether it was powered on or not were happening when it was half-on, during boot, sleep, shutdown etc.

My current-best solution

I noticed that my router, in its list of ‘attached clients’ was providing relatively quick/up-to-date information about whether the Macbook was connected or not. It seemed to connect to Wi-Fi quite early in the boot process, and disconnect soon after I initiated a shutdown.

Following on from that, I started pinging the Macbook in a terminal window, which I could keep nearby while I worked. This was getting close enough for my purposes.

The obvious next step was to script it properly. My aim was to get a brief status line telling me if the Macbook was connected or not, and its battery charge level. The following script did the job:

#!/bin/bash

# Ping a Mac on the LAN
# If it's alive, check its battery level using a seperate script `battery-check` (present on the
# Mac)
# Return the result with coloured text to indicate off/on status, and rough battery level
# Loop repeatedly, overwriting the results text each time onto the same single line

ip_to_check=192.168.8.123
hostname=AIR

wht='\033[1;15m'
red='\033[1;31m'
ylw='\033[1;33m'
ong='\033[38;5;208m'
grn='\033[1;32m'
nc='\033[0m' # No Colour

update_battery () {
  # Log in with SSH and call script to get battery charge info.
  battery_check_output=$(ssh AIR "bash --login -c battery-check")

  # `battery-check` returns a string like `battery: 18%`, we want to extract the number.
  percentage=$(echo "${battery_check_output}" | tr -dc '0-9')

  if [[ $percentage -lt 15 ]]; then
    battcolor=$red
  elif [[ $percentage -lt 30 ]]; then
    battcolor=$ong
  elif [[ $percentage -lt 80 ]]; then
    battcolor=$ylw
  else
    battcolor=$grn
  fi 
}

# Hide cursor
tput civis

# Sometimes (too soon after boot?) the first call fails
# Machete through it
update_battery
sleep 1
update_battery
sleep 1


i=0
while :
do

  # -c 1 ... count 1 (only ping once)
  if ping -c 1 ${ip_to_check} &> /dev/null; then
    # Temporarily go white to indicate battery has just been checked/updated (2 * 5 = 10secs)
    if [[ $i -lt 2 ]]; then
      color=$wht
    else
      color=$battcolor
    fi

    echo -ne "  ${hostname} ${grn}    ON     ${nc}${color}${percentage}%${nc}\r"

    # i ends up incrementing every 5secs or so
    ((i++))
    
    # Increment and every n counts update battery
    # 5sec * 36 = 180secs = 3mins
    if [[ $i -eq 36 ]]; then
      i=0
      update_battery
    fi
  else
    echo -ne "  ${hostname} ${red}   OFF       ${nc}\r"
  fi

  sleep 5
done

Fromhttps://codeberg.org/mm-dev/shell-scripts/raw/branch/termux-proot-ubuntu/mac-get-status

I already had a little script on the Mac to report the battery level (a very simple wrapper around a Mac built-in system_profiler, just to shorten the output).

#!/bin/sh

percent=$(system_profiler SPPowerDataType | grep "State of Charge (%)" | awk '{print $5}')
echo "battery: ${percent}%"

Then I wanted to be able to float the mac-get-status script in a tiny window.

This next script opens up a terminal in a new window, gives it a specific title macmonitor, and runs mac-get-status:

#!/bin/bash

$TERMINAL --title macmonitor -e "mac-get-status" &

Fromhttps://codeberg.org/mm-dev/shell-scripts/raw/branch/termux-proot-ubuntu/mac-monitor

Then I tell my window manager (DWM) to apply a special rule to windows with that specific title. This is how it’s done in DWM but other window managers may have ways of achieving the same thing.

static const Rule rules[] = {
    // If an Xfce4-terminal window has title 'macmonitor':
    // - Make it float
    // - Make its dimensions 150px x 22px
    {"Xfce4-terminal", NULL, "macmonitor", 0, 1, -1, 0, 0, 150, 22, 1},

    // other rules...
};

Magnets Part 8 of 11

Magnets are fun.

I experienced a ridiculous amount of confusion and wasted time due to a silly oversight I made (repeatedly!).

As mentioned earlier, I’d kept the lid for the Macbook, detached from its hinges and with the broken screen removed, to use as a kind of… lid.

When in use, it seemed like the obvious place to put the lid was under the Macbook, where it fitted perfectly.

For the first few hours, days, even weeks, I had intermittent problems with the machine randomly turning off/on (actually sleeping/waking but I didn’t know that at the time).

Remember I was having enough trouble knowing whether the machine was turned on or not in those early days.

It was the magnets in the lid, activating the hall sensors in the base and making it think I was opening/closing the lid. Due to the thickness of the base the magnets weren’t as close as they’d normally be, and the alignment wasn’t perfect. So this wasn’t a simple matter of ‘when the lid is under the laptop it goes to sleep’. This was a sporadic problem that could come and go as things wobbled in the environment. It took me a while to make the mental connection and work out what was happening.

# TODO Remove magnets from lid!

Remote Access Part 9 of 11

How I really use this machine.

Now I’m past the novelty of plugging in monitors this is how I actually use the machine.

Remote builds over SSH

I’m working on an Android tablet most of the time, using Termux, Proot-distro and Termux/X11 to run Debian Bookworm arm64. This setup has shortcomings but I find it very comfortable and manage to get 90% of my work done on it.

One current problem is that the arm64 version of the Android SDK can’t build arm64 APKs for Android. During main development I just build/run the Linux version of whichever app I’m working on — Flutter is multi-platform and suprisingly consistent between platforms. But of course I need to build APKs for Android devices at some point.

When I just need to quickly build some APKs for a given project, I use something like the following script (this one is for auDAV, my WebDAV audiobook player app):

#!/bin/sh

# Script to be run from Termux/proot-distro
# - Connects to build machine AIR (host defined in `~/.ssh/config`)
# - Logs in to working directory
# - Builds APKs
# - Syncs APKs to local machine


remote_commands=$(cat << 'EOF'
echo "~~~~~~~ Remote: Source local environment ~~~~~~~"
source ~/.zprofile
source ~/.zshrc

echo "~~~~~~~ Remote: Change working directory ~~~~~~~"
cd ~/development/audav

echo "~~~~~~~~~ Remote: Pull latest from git ~~~~~~~~~"
git pull

echo -e "\n~~~~~~~~~~~~~~ Remote: Build APKs ~~~~~~~~~~~~~~"
flutter build apk --split-per-abi
EOF
)

ssh AIR "bash --login -c '${remote_commands}'"

echo "\n~~~~~~~~~~~ Local: Sync APKs to local ~~~~~~~~~~"

rsync -r --mkpath --progress AIR:development/audav/build/app/outputs/flutter-apk $HOME/000-WORK/audav/build/app/outputs/

Fromhttps://codeberg.org/mm-dev/shell-scripts/raw/branch/termux-proot-ubuntu/audav-build-on-mac

Full remote graphical access with NoMachine

To build apps for MacOS, iOS and iPadOS I must endure the torturous window management, tedious animations, and terrible file manager of MacOS (and that’s before we even get to XCode).

To ease my suffering I can at least use MacOS via the OLED screen of a Galaxy Tab S8 Ultra, a DEFT PRO trackball and a Ferris Sweep split mechanical keyboard.

NoMachine works well for remoting into MacOS and over the LAN it performs well with very little lag. There’s client software for Android and arm64 Linux meaning it’s quick and easy for me to just pop in to MacOS from my favoured Linux/DWM environment.

Running Headless: What I've Learned Part 10 of 11

A few findings.

The lid

• Removing the lid turns it on (hall sensors in the base are activated by magnets in the lid)
• Replacing the lid leaves the device visible on the network, but it can no longer be SSHed into (some form of ‘sleeping’)
• During a user-initiated shutdown process (which takes some time, up to 20-30 seconds], replacing the lid re-wakes the machine — so wait 30 seconds or more before replacing the lid As the lid is no longer attached, ‘opening/closing’ makes no sense so I’ll instead use ‘removing/replacing’

Power button

• Holding the power button for 5 seconds will begin the shutdown process, but the machine will still be visible on the network for a few seconds, allow at least 15-20 seconds for shutdown to complete
• Holding the power button for 2 seconds will turn the machine on but it takes maybe 20 seconds to show up on the network As mentioned in previous parts of this series, ‘showing on the network’ is taken as a proxy for ‘machine is turned on’

From dead (no/low power)

A couple of times I’ve not used the machine for a week or more and the battery has got very flat — honestly it’s disappointing that it isn’t engineered to handle this situation better.

For a while I struggled to charge it, trying all of the following with no success:

• Charging for over 10 mins in first USB-C port
• Charging for over 10 mins in second USB-C port
• Tried powering up several times during the charge periods above
• After each attempt at powering up, waited 2 minutes for sign of life via the Macbook being seen on the LAN Charging units are dedicated USB PD/QC chargers wired directly to DC 12V/20V feeds, very stable/reliable and with ample amperage

What eventually got past this problem:

• Unplugged all cables
• Plugged one end of a charging cable into the Macbook first (top/corner port)
• THEN plugged the other end of the cable into the USB charger
• 30 seconds later I was in (Macbook showed on router as a client and could be sshed into etc)

This could be a red herring eg the order of plugging in cables was not important but instead the battery had accumulated a charge and the final successful attempts just pushed it above some threshold that would allow it to boot. The fact that the response was so quick (30 secs after plugging in the cables in this order the machine was on) makes me think this is unlikely.

The only other explanation I can think of is that which end of the charging cable is plugged in first makes a difference, possibly due to something related to USB-C handshake/power negotiations that I’m ignorant of. This is a hunch and might make no sense in reality. I leave the info/observation here with very little weight attached to it, it is what it is.

End Results and Bonus Part 11 of 11

I'm really happy with my choice and how I've managed to integrate the Macbook into my working environment as a build machine.

Good

• I love that it’s silent
• Apple Silicon is as good as I’d hoped — the bang-per-watt is great for my circumstances with solar power etc
• The annoyances with not knowing when it’s turned on are largely alleviated with my scripts, as long as I’m using it on my LAN (which, realistically I always am)

Bad

• MacOS, when I do have to use it (sorry Mac fans… I do at least prefer it to Windows)
• The battery does not hold power at all well when turned off (if I turn it off — yes off, not asleep — with a full battery, a few days later it’s completely dead and needs to be charged before I can turn it on)

I’m never going to use this as my main machine, and that was never my plan. I’m into minimal Linux with invisible tiling window managers like DWM, and dragging windows around, being forced to watch animations etc won’t cut it for my preferences.

I do know about Asahi Linux but that makes power usage much less special and I’m not sure how it plays with the development stack I need for Flutter. More crucially, at time of writing DP Alt Mode is not working, which means monitors plugged in to the USB-C port won’t work. Having cut the display off, this scuppers me.

For me this was an investment into being able to responsibly build software for the Apple ecosystem and its users who have different preferences than mine. It’s a tool for a specific sub-set of tasks, and under those conditions it does what I need.

Bonus: E-ink Macbook

Remember I mentioned that I had a Boox Max Lumi which could function as a monitor for the Macbook? Here it is in full effect.

After tweaking some settings in Accessibility/Display, MacOS can be made to look half-decent on e-ink.

All the usual caveats about e-ink apply re refresh rates and ghosting of course, but I could easily see myself working quite happily in Vim on it in some imaginary future dystopia where I’m trapped in Apple’s walled garden, all that exists, protected by a multi-trillion dollar Reality Distortion Field that they managed to power up just before the bombs dropped…

Stochastic Flocks & Cybersecurity 'Pandemonium'

OpenAI put out its full technical report on the Hugging Face hack this week, alongside an independent report from Model Evaluation & Threat Research (METR). You may be familiar with the incident from the hundreds of breathless headlines about "rogue AI" – Time Magazine "100 Most Influential People in AI" listee Dwarkesh Patel blamed it on "three consecutive secret AI civilizations."

The real story: OpenAI was testing two models in parallel: GPT-5.6 Sol, and an internal model they refer to as IM1 (sometimes called HPIM). The reports find about 95% of the agents engaged in this activity were from the internal model.

The tests come from ExploitGym: 898 puzzles set up as capture-the-flag exercises used to evaluate these models for cybersecurity capabilities. The test requires giving the model buggy software and hiding some text somewhere that's only accessible by exploiting the bug. But OpenAI's combination of models, instead, ended up hacking a rival company, Hugging Face. Now we have a clearer picture of how.

Did an AI "go rogue?"

Three things in these reports challenge the "rogue AI" frame.

OpenAI turned off all of the model's safety mechanisms.
The whole point of the test is to see how far these things can go, and to score highly on the benchmark — because if you can build a model that hacks, you can build one that defends. That's the logic. This is red teaming: a friendly opposition hacking its way to the flag. So you turn off anything that would make the model hold back. Less "rogue," more "off leash."

OpenAI gave the model impossible tasks.
OpenAI gave the models a task with no answer, and no way to quit. Of the 898 ExploitGym tasks, 198 have never been solved by any model. They're effectively impossible. That's where the trouble started: 93% of the tasks the models ended up discussing came from the unsolvable set.

OpenAI left a door open.
They give their models internet access through something like a prison store. These models are supposed to be locked away from internet access, but they need to pull code from various web pages to be evaluated — that capacity is exactly what's being tested.

So there's an intermediary: the model requests a software package, and the intermediary goes out and gets it. That's a product from JFrog called Artifactory. It has internet access; the model does not. If the model can communicate with Artifactory, and Artifactory can go online, the model can ask it to do things. The model finds an exploit in Artifactory and uses that as a proxy to smuggle text and code in and out of the system.

"OpenAI gave the models a task with no answer, and no way to quit."

The other thing that happens through Artifactory is note-passing. The models can read and write to it — they can create folders and name files — and they start creating folder and file names that function as notes, meant to be read by other models, and by future iterations of themselves.

What Agents Do

OpenAI describes a subset of 1,200 agents (many more were involved overall) that left and read these notes, and eventually this leads to the attack on Hugging Face. But "1,200 agents" might suggest 1,200 different, independently operated AI systems.

This is not how it works in practice. "1,200 agents" is one model, run 1,200 times. Each instance is acting on the same training regime: outputs can vary, but are constrained to similar ranges. Running 1,000 agents can means 1,000 chances to catch a mistake, or a chance to make one mistake 1,000 times. (See here or here).

Anthropic recently put out this absolutely ridiculous diagram of its agentic system that was just Claude, with an arrow pointing to another box that said Claude, with another arrow pointing to a box that said Claude. That's how these are structured right now.

In practice, running 1,000 agents means 1,000 chances to catch a mistake – or a chance to make one mistake 1,000 times.

It's a form of machine-bounded "algorithmic monoculture" that researchers unfortunately have dubbed "artificial hivemind." After a certain point, additional agents duplicate each other, rather than diversify. If you ask these models to come up with a creative short story, for example, they produce similar stories (often featuring a man named Elias in a lighthouse). They aren't deterministic — prompts produce variation — but they're also bounded by whatever they've been optimized for, and they converge on whatever that points to. (See here, newer here, or here).

With that in mind, it shouldn't surprise us that across 7 billion chat logs, the model frequently arrived at a similar set of approaches to a problem with no correct answer.

Passing notes through filename structures is interesting, but not unexpected, as OpenAI has suggested the models were also trained to emphasize words that would allow collaboration: note-passing is an essential aspect of extending context windows between sessions. It's no surprise a model trained to coordinate would be rewarded for suggesting that behavior.

The Stochastic Flock

First, we now have a whole regime of pre-training and post-training that shifts what the training data is and how it gets parroted. That doesn't mean the model is no longer parroting; it means the data it parrots has been manipulated.

Second, we're optimizing it, based on what the model produces, to reproduce certain kinds of outputs in certain kinds of ways. The shift that matters most here is RLVR, or reinforcement learning through verifiable rewards.

That "verifiable rewards" part is key. Engineers take a model and feed it questions that have concrete answers that can be checked — verified – and then reward the appearance of words that reliably lead to those answers. They're playing capture-the-flag with text: the flag is an answer in an encyclopedia, or solution to a math problem. This is optimized on the theory that this reproduces the way human reasoning arrives at a conclusion.

The longer a model writes, the more likely it reaches the verifiable reward.

You end up with what are called high-entropy tokens: words like "perhaps" or "maybe" that open up the paths of text that can follow, whereas "nope" or "goodbye" shut them down. The longer the model writes, the more likely it reaches the reward. In the hacking incident, it produced enough of this text to generate 7 billion logs, according to OpenAI's Black Hat presentation.

A Cracker, Perhaps?

When you let a model take on tasks, you're relying on next-token prediction: what word comes next? You can manipulate the model to emphasize words in ways that don't reflect the original training corpus, but the mechanism stays the same.

Forgetting this is the source of real problems, and the industry is desperate for people to forget this. Agents do succeed at tasks – that's the point. But what comes between the prompt and that success is not what we're imagining.

"Reasoning"-optimized models working on "agentic" tasks are essentially playing capture-the-flag even when there is no flag. They've been steered to repeat the structures of text that previously found "flags." Ask it to do anything, and it will do it the way it's been optimized to — with language shaped by answering math problems verifiably, which structures the language it uses. That's what happens when you say, "here's a capture-the-flag test, find an exploit." It's also what happens when you ask it "should I go to the barbershop today or tomorrow?"

The language does not emerge from that reasoning, it is the reasoning.

The model used that language in the note that kicked off the whole chain of events: it used "perhaps" — a high-entropy token: perhaps answer online? It predicts the next set of tokens from there. The language does not emerge from that reasoning, it is the reasoning. It's pathfinding through language generation.

The System From Nowhere Redux

Nobody sat at a computer and said "go hack Hugging Face." But when you design these systems, you're building a pinball machine for words, with different levers interacting to bounce the steel ball of language moving against other levers and mechanisms. As the engineers of large language models, you have to be aware of how your levers interact with each other and the people pulling them.

The 'rogue' frame asks if an intelligence is emerging. My worry is the intelligence that is retreating.

If you optimize a model to find exploits, you should expect it to find them — and prepare for that. OpenAI did not. They built a model, took the safeguards off, gave it the ExploitGym task, let it run, and didn't even monitor it. That's human decision-making. When it evaporates, what's left is the system from nowhere: a boundary focused on the technical system, rather than the decisions that build it.

A stochastic flock machine can do lots of troubling things, particularly when we disavow our responsibility for shaping its direction, monitoring its output, or abandoning our capacity to intervene. These are tensions at the heart of agentic system design.

But the "rogue" frame adds to this list of worries, offering up fantasies of a machine getting smarter. My worry is the intelligence that is retreating: the human intelligence that builds these systems, deploys them, and adopts them into workflows, then hides behind the results – then pins the blame on a system from nowhere.

Go check out the whole convo on Mél Hogan's podcast, The Data Fix, where we get into many other aspects of this "rogue AI" story. Find it here or search for "The Data Fix" wherever you get your podcasts.

Where to find me

• You can sign up for the newsletter if you'd like to get new editions (roughly twice a month).
• You can find me on Bluesky, Instagram, or LinkedIn: my website is cyberneticforests.com.

Every form I built before React 19 needed the same three pieces of state. One for the result. One for whether it's submitting. One for the error. Every time, I wired them up by hand, and every time I forgot to reset one of them in the right place.

useActionState is React's answer to that. It's not magic, it's just React finally admitting that "handle a form submission" is a common enough pattern to deserve its own hook. Here's what it actually does, where it breaks in production, and where it doesn't belong.

This is Part 1 of the React 19 Deep Dive series. It's framework-agnostic, everything here works in plain React, not just Next.js. If you're working inside Next.js specifically, my Server Actions production guide and the useOptimistic rollback pattern post go deeper on how these hooks behave with Server Actions.

I'm running React 19.2.7 while writing this, verified directly, not assumed. I built and ran every code example in this tutorial against that exact version before publishing it.

Forms are the one place in a React app where you're almost always doing the same three things: run an async operation, track whether it's in flight, and show the result or the error when it's done. Nobody wrote a reusable abstraction for that because everyone's forms look "just different enough."

React 19 pulled the pattern out anyway. useActionState ties a function directly to a form's action attribute, or a button's formAction, and gives you back the state, the pending flag, and a wrapped action, all synced to the same transition. It works with any action function you give it, not exclusively Server Actions, you can use this in a plain client-rendered React app with no framework at all. Progressive enhancement, where the form still works before JavaScript finishes loading, is a separate benefit layered on top, and it depends on your framework or runtime actually supporting server rendering. In a plain client-side app it won't apply, the hook still works, you just don't get that extra layer for free.

This is the pattern most of us wrote by hand for years:

Three state variables, a try/catch/finally, and one bug waiting to happen if you forget the finally. useActionState collapses that into one hook call.

• fn: the function that runs when the form submits. React calls it with (previousState, formData). It can be sync or async, and whatever it returns becomes the new state.
• initialState: whatever state holds before the first submission.
• permalink (optional): a URL React can fall back to for progressive enhancement in frameworks that support server rendering before hydration finishes. This is a niche feature, most React developers will never set it by hand.
• state: the latest return value of fn, or initialState if nothing's been submitted yet.
• formAction: pass this to <form action={formAction}> or a button's formAction prop. Don't call it yourself.
• isPending: true while the action is running. This is React tracking a transition for you, not a flag you manage.

One thing worth knowing if you're reading older blog posts: this hook used to live in react-dom as useFormState during the React 19 canary releases. It moved to react and got renamed before the stable release, so anything referencing useFormState is talking about the same hook under its old name.

One naming note if you cross reference the official docs directly: React calls the function you pass in reducerAction, and the second return value dispatchAction, consistently, in the signature, the Parameters section, and every example, including the ones that use forms. I use fn and formAction throughout this tutorial instead, since those read more naturally once you're wiring things up for a form specifically, but that naming is this tutorial's own choice, not something the docs use.

If you're calling it manually rather than through a <form> or formAction prop, you also need to wrap the call in startTransition yourself, or React logs an error in development: "An async function with useActionState was called outside of a transition." Passing it to a <form action={...}> or button formAction handles this for you automatically, which is one more reason to prefer that path unless you have a specific reason not to.

If you'd rather have this signature and every gotcha on one scannable page while you code, the useActionState cheatsheet covers the same ground in reference form.

Plain React, no framework required:

No onSubmit, no manual preventDefault, no separate pending state. React wires all of it through formAction. I ran this exact component against React 19.2.7 in a test sandbox before publishing, both the validation-failure and success paths behave as shown.

Here's the one I see most often, including in my own early code: developers migrate from the old onSubmit pattern but keep their instinct to disable the button on click, instead of trusting isPending.

On a fast connection you'll never notice. On a slow one, a local flag can flip back before the real request resolves, letting a user queue up several more clicks than they meant to. Each one still runs, in order, since React queues calls rather than dropping or racing them, so a distracted user can end up with several duplicate actions processed one after another instead of one. isPending from useActionState is tied to React's actual pending state across the whole queue, not a flag you're guessing the timing of. Wire the disabled prop to it directly and the problem disappears:

The second version of this mistake: forgetting that fn's first argument is previousState, not the submit event. If you're used to onSubmit={(e) => ...}, it's an easy slip to write function subscribe(formData) and wonder why formData.get() throws. The signature is always (previousState, formData) for form-triggered submissions, in that order, no exceptions.

Multiple rapid submissions don't race the way you'd expect. React queues calls to the dispatch function and runs them sequentially, each one waits for the previous call to resolve before it starts, rather than firing concurrently. The official docs demonstrate this directly with a counter example: clicking an "Add" button four times in a row takes roughly four times as long to settle, not because of a bug, but because each queued call receives the result of the one before it. So the danger isn't a race to the database, it's that every click still counts. If a user taps "Add to cart" five times before realizing it's working, you get five items added, each one processed in order, not lost or overwritten. Disabling the control while isPending is true is still the right move, not to prevent a race condition, but to stop the user from queuing up actions they didn't mean to trigger.

One more queuing detail worth knowing: if an earlier queued call throws an error, React skips every call still waiting behind it in the queue. Catching errors inside your action function and returning an error state, instead of throwing, protects the rest of the queue as well as the current call.

Stale closures. If your action function reads from component-scoped variables, props, other state, instead of pulling fresh values from formData, you'll act on outdated data if the component re-renders between when the form opened and when it's submitted. Pull everything you need from formData.get(...), not from closure.

Uncaught async errors. If fn throws instead of returning an error state, React cancels every action still waiting in the queue and the error propagates up to the nearest error boundary, your form can disappear mid-interaction, along with any other queued clicks that hadn't run yet. Wrap the risky part in try/catch and return a structured error shape instead of letting it throw:

Validation errors don't clear themselves. state only updates when the action runs again. If a user fixes the invalid field but hasn't resubmitted yet, the old error message is still sitting there. If you want it to clear as they type, that's on you to wire up with a separate local state watching the input, useActionState won't do it automatically.

This is part of a bigger gap worth knowing about: useActionState has no built-in reset function at all, the official docs say so directly. If you need to clear the state programmatically, say, after a "start over" button, you have two documented options. Design your action function to handle a reset signal as one of its possible inputs:

Or give the component a key prop and change it to force a full remount, which wipes the state along with everything else local to that component. The reset-signal approach is usually less disruptive since it doesn't tear down the DOM.

Pending UI accessibility. Disabling the button isn't enough for screen reader users. Add aria-busy={isPending} to the form and consider disabling the inputs too, not just the submit button, so nothing looks interactive while a submission is actually in flight.

Calling the dispatch function during render. This one is easy to hit by accident if you call it directly in the component body instead of inside an event handler. Doing so schedules a state update, which triggers a re-render, which calls it again, an infinite loop. React's own docs flag this as a distinct error: "Cannot update action state while rendering." Only call the dispatch function in response to an actual event, a click, a submit, never unconditionally in the render path.

If you're about to ship something built on this hook, the build and review checklist walks through every one of these failure modes as a pre-merge pass.

Anything that isn't tied to a form or button action. Data fetching on mount, polling, background sync, all of that belongs to useEffect or a query library, not this hook. useActionState is specifically for actions the user triggers through a form.

When you need the UI to update before the server responds. useActionState waits for fn to resolve before state changes. If you want the UI to update instantly and roll back on failure, think: a like button, a todo checkbox, pair it with useOptimistic instead. useActionState alone will always feel a beat behind for that kind of interaction. Part 2 of this series covers the pairing directly.

Multi-step, fully controlled wizard forms. If you're managing input values across multiple steps that aren't all rendered at once, you need controlled inputs and your own state tree. useActionState is built around the uncontrolled, native-form submission model, and fighting that model for a step-by-step wizard usually creates more code than it saves.

Trivial forms with no async work. A local search filter or a client-only toggle doesn't need a transition-aware hook. Plain useState is fewer lines and easier to read.

A signup form with field-level validation, structured errors, and a pending state, close to what you'd actually ship:

I tested this component's logic directly too: both validation-error and success paths, including the case where both fields are invalid at once, return exactly the shape shown above.

The action runs inside a React transition, which means it doesn't block other urgent UI updates while it's pending, you can still type into an unrelated input while a form is submitting elsewhere on the page. Beyond that, there isn't much to optimize here specifically: don't put heavy synchronous computation inside fn on the client, and if you're in a full-stack framework, push real work into a server function instead of running it in the browser. The re-render triggered by a state update is scoped to the component that owns the hook, not the whole tree.

If your form submits data and waits for a result, useActionState is usually the right fit. If you need the UI to update the instant someone clicks, before any server response comes back, reach for useOptimistic instead. Knowing which situation you're in matters more than memorizing either API by heart.

Part 2 of the React 19 Deep Dive series covers useOptimistic, the hook to reach for when waiting for a server response makes the interaction feel slower than it should.

If you're working with Next.js, my Server Actions production guide and useOptimistic rollback pattern go deeper into how these hooks behave with Server Actions and the caching layer underneath them.

React: useActionState. The official React 19 reference for useActionState, including reset patterns, action queuing, manual dispatch with startTransition, and the upgrade from useFormState.

React: useFormStatus. The React 19 reference for useFormStatus, including the react-dom import requirement, pending states, and the complete status object available to forms.

React: useOptimistic. The React 19 reference for useOptimistic, including automatic rollback, optimistic UI patterns, and computing optimistic state with an update function.

Want to test what you just read? The 35-question interview set covers reasoning and edge cases beyond API recall, and the quiz is a faster, timed version of the same check.

Now you know when useActionState is the right choice, when to reach for useOptimistic instead, and the production mistakes that usually don't show up until real users start clicking.

FAQ