Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Rubenerd
Podcast: Play in new window | Download 37:37 – A feedback episode, reading comments about the show from Adam, Alistair, and Abdullah. Discussing my favourite personal shows that are still going (Into Your Head, The Overnightscape Underground), task management (Getting Things Done™, the spark to get something started), 1980s British retrocomputers (Spectrums, Amstrads, Orics, and Acorns), coffee (my own snobbery, instant coffee, how supermarkets sell it), and what constitutes a mathematics coprocessor! Recorded late September 2026. Recorded in Sydney, Australia. Licence for this track: Creative Commons Attribution 3.0. Attribution: Ruben Schade. Released October 2026 on The Overnightscape Underground, an Internet talk radio channel focusing on a freeform monologue style, with diverse and fascinating hosts; this one notwithstanding. Hosted graciously by the Internet Archive. Subscribe with iTunes, Pocket Casts, Overcast or add this feed to your podcast client. By Ruben Schade in Sydney, 2026-10-01.
I feel like I righted a wrong in some small way recently. It also gives me an excuse to write another of my shaggy dog posts about old computers, which I’ll never pass up the opportunity to do. Behold, our boxed copy of Digital Research DOS 6.0 from 1992: The first OS I ever used was MS-DOS 5.x on the family 486, upgraded shortly after to MS-DOS 6.2 [sic], then Windows 95. DOS was “what came with computers” to me at the time, so the idea there were alternatives didn’t even cross my mind. MS-DOS’s origins lay with QDOS, itself a broad clone of Digital Research’s CP/M operating system. CP/M-86 was compiled and offered for the original PC, but IBM famously went with Microsoft instead. The circumstances surrounding this decision remain… contentious. Either way, I’ve had a soft spot for Gary Kildall since I first saw him on those archived episodes of the Computer Chronicles. People like exploring an alternative universe where IBM went with CP/M over DOS, and Gary had become the billionaire tyrant instead of Gates. We can only speculate, but Gary always struck me as more of a self aware, Woz-type character than Bill. I’ve mentioned how Digital Research’s GEM desktop was a big part of the reason why I got into the Atari ST, but I haven’t talked much about DR DOS, the OS Digital Research released to compete with Microsoft and IBM. I never used it as a kid, but I wondered what Gary and his team had been able to deliver. Last year I acquired disk images for every major release, in part for a blog post series about DOS that I never ended up publishing. Version 6.0 quickly supplanted IBM PC DOS 7 as my preferred DOS; everything from the installer to the included utilities are vastly superior, and it even came with ViewMAX, a file manager based on GEM/3. Awesomesause! Pair this with Turbo Pascal, Commander Keen, Sim City 2000, The Games: Winter Challenge, the Brief editor, and the DOS port of Lemmings, and I’ve got all the bases covered! DR DOS 6 was released in 1992, around the time Digital Research was acquired by Novell. For context, Lynne and William Jolitz released 386BSD at the same time, and Microsoft was selling MS-DOS 5.0 to my dad for our first family PC. He could have ended up with DR DOS 6.0 instead, which makes this all the more interesting. This boxed set of DR DOS 6 includes the instruction manuals for DOS and ViewMAX, along with a handy reference card. The “Value Pack” sleeve contained the install disks, but I’m not sure if it previously had something else. The OS itself is contained on two 5.25-inch high density disks, along with the original voucher for 360 KiB disk versions. So many of the disk labels from the time seem to have developed this blotchy appearance, but fortunately it’s only cosmetic. Funnily enough, my PC DOS 2.1 disk is about the only one from the early 1980s that hasn’t developed this odd label issue. In the next post, I’ll get a basic install of DR DOS 6 going, to demonstrate why I like it so much. Only took me (checks calendar) two and half decades. By Ruben Schade in Sydney, 2026-09-02.
Snow Leopard was a version of Mac OS X released in 2010. It was billed by Apple as having “0 new features”, with a focus on refining the system, improving efficiency, and fixing bugs. Those of us using Macs at the time welcomed the news after living with updates that seemingly broke as many things as they introduced with each release. This idea is so powerful—and so longed for—that it’s escaped containment among the Apple crowd. I’ve seen everything from Linux distro to phone updates referred to as Snow Leopard releases, when their vendors cite stability and bug fixes over new features. Likewise, people plead with their vendors for a Snow Leopard release when they feel quality has slipped. The reality at the time was a bit different. As I wrote at the time: This could be the first time I’ve ever downgraded an Apple OS. As we speak I’m downgrading the Snow Leopard partition on my trusty old Core Duo 2006 MacBook Pro back to Leopard (and while I’m at it, I’m finally getting around to upgrading the FreeBSD partition to 8.0!). I kept waiting for updates to fix the severe stability problems in the Finder, my FireWire 800 ExpressCard and my iMovie HD plugins, but I’ve decided to give up for now. This was putting it mildly. When I tried it again a few months later, I still had so many problems that I downgraded again, then leapfrogged it for Lion when it was released in 2011. Jeff Johnson has a great post discussing all the problems Snow Leopard introduced and had to have patched. It was a mess. Still, whether Snow Leopard really was this bastion of stability and polish, the myth surrounding its development and stated purpose obviously resonates today. People invoke its memory because they’re broadly craving stability and quality of life improvements, something almost everyone has wilfully discarded as they chase the next rung of enshittification. Apple’s marketing team hit on something so popular that it has staying power sixteen years later. By Ruben Schade in Sydney, 2026-08-02.
I worked briefly in process control when I was younger, and saw Things.™ One of those Things™ was a wall of LEDs to indicate statuses of various valves and sensors across the entire plant. It was old school, but it worked. It also made you feel like you were on a 1960s-era sci-fi set. What does this have to do with databases? That’s an extremely excellent, and dare I say handsome, question. While we’re on the topic of things I used to do, I used to work against a large database that had a schema with a specific quirk that used to drive me up the wall. Take this contrived example of a table for an account: username | active | paid ---------------+--------+------ nagato_yuki | true | true takarada_rikka | true | false And another for some basic infrastructure: hostname | running | error ------------------+---------+------- retro.rubenerd.au | true | false www.sasara.moe | true | true Do you spot the subtle difference between the two? Why is the first table well designed, and the second one horrible? The first table has uniform positive attributes. Having an active account is good, and being paid is good. This means one can tell at a glance whether an account is in good standing or not. You can also do trivial boolean algebra to derive a status. The second table has a mix of positive and negative attributes. Having a running state of true is good, but having an error state of true is bad. This means you can’t as easily tell at a glance the status of an instance. You can’t also as easily derive an overall status. The value of consistent booleans was something that was immediately obvious when looking at that status wall. It mostly had white lights. When one of these changed colour, you knew there was something actionable. If that status wall instead was designed with some lights being positive, and some being negative, it would be almost (but perhaps not entirely) useless. ☕︎ ☕︎ ☕︎ Why am I thinking about this today? I’ll admit it’s for an incredibly embarrassing reason: I had a dream about databases last night. I know, some people have fun dreams involving flight, reliving something they enjoyed, or exploring a new side of themselves. I dreamed I was back at uni with my DB professor who insisted that all booleans should have positive assertions. Anyway, I was shy at the time when I went to that class in the real world, and said nothing. But what I wanted to say was that uniformity is more important. Most of the time there’s an unambiguous, convenient term to describe something positive, but I also acknowledge there are some circumstances where forcing this naming can get clumsy, such as having a schema full of not_$foo attributes. It’s not a data science to me, but I’m reminded of the sixth rule from The Economist Style Guide: Break any of these rules sooner than say anything outright barbarous. The same applies for software variables, but that would be a whole other post, can of worms, and kettle of fish. By Ruben Schade in Sydney, 2026-07-01.
More in technology
Here are the Vim forks I know about: Neovim: “a Vim-based text editor engineered for extensibility and usability, to encourage new applications and contributions.” Vim Classic: “a stable, long-term support fork of the ubiquitous text editor, maintained without the assistance of generative AI tools.” EVi: “a hard-fork of Vim v9.1.0 (Jan 2024) before AI was used in the project.” MacVim: “a macOS version of the Vim text editor, providing a graphical user interface for Vim, while tightly integrating with macOS and providing features specific to the platform.” This list doesn’t include Vim-inspired editors like Kakoune, Vim-style plugins for other editors like IdeaVim, or Vim “distributions” like LazyVim. Contact me if you know of other forks!
Thought I’d make a quick blog post about some weird behavior I’m seeing on iOS 27 and Dynamic Island live activities, that I initially thought was restricted to the Duo, but turns out affects everything. Yay. Maybe this post can save some others some time, and hopefully Apple can fix it. Long story short, ever since iOS 16.1 introduced “Live Activities”, where we can display handy little widgets in the Dynamic Island, there’s been a bunch of different configurations for showing things up there: something on the left, the right, when expanded, when two apps are showing things and yours gets a bit smaller, and on the lock screen. One interesting one is if you only need to show a small indicator in the Dynamic Island (screen recording indicator, electric vehicle charging status, etc.) you can do so, which just shows on the left on older iPhones, and on the Duo a single one below the camera cutout. Apple describes how to do this in their developer documentation (emphasis added): If you can’t find a solution to display views for leading and trailing compact presentations with limited width, provide a compact leading presentation that best represents your Live Activity, such as the view you use for the minimal presentation, and an empty view for the trailing compact presentation. The system hides the empty trailing view automatically. Unfortunately, in iOS 27 (and 27.1, and 27.2), this only half works, due to a new addition in iOS 27: isDynamicIslandLimitedInWidth. It’s a variable that basically tells you if the Dynamic Island is even narrower than normal, presumably because they knew the Duo was coming with its vertical Dynamic Island, but also because as of iOS 27, Live Activities now show in the Dynamic Island when the device is in landscape too. So it’s handy to know if you have a bit less space than usual. In this new narrow view however, it seems like they didn’t test all the configurations thoroughly, as if you provide EmptyView for that trailing compact presentation, it’s not empty at all, and in fact enforces a quite large minimum size so the Dynamic Island looks hilariously tall. In other words: The system hides the empty trailing view automatically Left: what it should look like. Right: reality You can imagine this is especially rough on the Duo, where navigation buttons, toolbar buttons, tab bar buttons, etc. are all competing for precious space on the right. But that’s only half true. It displays perfectly fine (hiding it) when isDynamicIslandLimitedInWidth is false (AKA how it always used to be), but in the new cases where it can be true, like the Duo and iPhones in landscape, that’s when it breaks. So tl;dr: In iOS 27, Dynamic Island Live Activities are improperly sized if you use the listed EmptyView configuration and isDynamicIslandLimitedInWidth is true. This makes it especially bad on the Duo, womp womp. Complications Now, you might be saying “That’s weird, I haven’t seen that behavior! This is nothing but hogwash!”. But it is not hogwash, just a little complicated. There’s basically three categories of apps. Apple apps Maps, for instance, displays this single, small Dynamic Island live activity perfectly well and sized, and has been beautifully compiled with the iOS 27.2 SDK. By all accounts it should show this bug, too! Apple apps don’t have to use the same APIs as us normies, so funnily enough through really cool tools like REA we can disassemble the iOS Simulator and see that it’s in fact true, the Apple Maps live activity just completely bypasses WidgetKit and instead just renders plain UIKit through MapsBannerViewController which shows the cute little cyan widget through a ManeuverAccessoryView and then for the hidden trailing view simply returns a DistanceAccessoryView with CGSizeZero, which iOS actually respects, unlike our paltry SwiftUI EmptyView. Third-party apps NOT updated to iOS 27 If your app hasn’t been compiled with any of the iOS 27 SDKs, it only knows about iOS 26, and thus doesn’t know about (or have to worry about) the new, troublesome isDynamicIslandLimitedInWidth property, so it just… displays perfectly well. Here’s the Rivian app, which hasn’t been updated for iOS 27 yet, which shows the Live Activity displaying perfectly sized on the Duo (indicating vehicle charging): (Technical disassembly detail for the nerds: iOS shows the app’s minimal config, a smaller config normally used when multiple apps are in the Dynamic Island together, rather than the normal compact config, so it bypasses this issue entirely.) Developers who updated their apps for iOS 27 Surprise! That picture from before? On the left is just me compiling with the old 26 SDK that works! Unfortunately if you are a good developer who updated their app for iOS 27 and all the new features, you kind of get punished through this bug, because your live activity displays the improperly sized way described above, and you can’t just use raw UIKit like Apple. So you’re kinda stuck where I am: do I ship a weirdly sized Dynamic Island experience for everyone? Do I shove something extraneous in the compactTrailing spot just so it doesn’t look as empty? Do I not update the app at all until Apple fixes this bug? Widgets are techincally a separate extension from your main app, so you could compile them with a different SDK (26) than your main app (27) which fixes this bug, but I’m not sure Apple approves of that. Apple On the bright side hopefully it’s an easy enough fix, treating EmptyView like you used to on iOS 26 and per the documentation (the part that is weirdly right beside the mention of the new API that introduces this craziness in the first place). Radar/feedback assistant ID: FB25301955 Easy reproduction code if you’re curious: import ActivityKit import SwiftUI import WidgetKit struct CircleAttributes: ActivityAttributes { struct ContentState: Codable, Hashable {} } struct BlueCircle: View { var body: some View { Circle() .fill(.blue) .frame(width: 20, height: 20) } } @main struct CircleLiveActivity: Widget { var body: some WidgetConfiguration { ActivityConfiguration(for: CircleAttributes.self) { _ in BlueCircle() } dynamicIsland: { _ in DynamicIsland { DynamicIslandExpandedRegion(.center) { BlueCircle() } } compactLeading: { BlueCircle() } compactTrailing: { EmptyView() // pls respect me } minimal: { BlueCircle() } } } }
Vicky, driving me home from O'Hare, got sixteen dollars for the best conversation I had in months. The last line is hers.
I’ve had “AI usage statements” in the back of my mind ever since I read Ethan Marcott’s blog post sharing a round-up of his favorite ones. I didn’t consider writing one for this site, since it had the smell of status-signaling. Like a quasi-political declaration of allegiance to some sort of in-group (be it pro-AI, anti-AI, etc). I couldn’t be less interested in that.1 But then something happened that caught me completely off-guard. I was reading a post on my friend’s personal blog. This was a guy that I knew personally and looked up to. I’ve been reading everything he had been writing for years. About two-thirds of the way through a long (and fairly insightful) blog post, I had a sudden realization that the post had been written by AI. I’m not the best at detecting this kind of thing, but once I saw it, I couldn’t unsee it. It was unmistakable. And the thing is, I didn’t feel indifferent or even disappointed, as I might have predicted. I felt betrayed. For somebody who considers themselves open-minded—even optimistic—towards the development of AI, I didn’t know where this feeling was coming from. I have theories… maybe it has something to do with the social contract between the writer and the reader. Whatever it is, I didn’t want anyone who was reading my blog (hi mom 👋) to feel the same thing. So for the sake of transparency, here is my AI usage statement: The content of this website is written by me. I do not use AI to generate the text you are reading because writing from scratch helps me process my thoughts (which is one of the main reasons I blog in the first place). I don’t currently use AI-powered writing tools (grammar-check, spell-check, dictation tools, etc), but I may experiment with them as long as they don’t undermine the thinking process. The code for this website was originally hand-written, but I have since used AI to make several useful updates. I expect to continue using AI to write code for this website and other personal coding projects. When I create a public project exclusively with AI, I mention that fact in the project README.2 I am experimenting and my AI usage may change. When it does, I’ll update the policy here on my /about page, which is where it will live long-term. To explain why, see Paul Graham's Keep your Identity Small. ↩ For an example, see s-tier ↩ Thanks for reading this post via RSS! Let me know your thoughts by leaving a comment on the original post or sending me an email.
