💾 Archived View for thrig.me › blog › 2023 › 07 › 22 › rejecting-dual-boot.gmi captured on 2023-11-04 at 11:37:42. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-07-22)

➡️ Next capture (2023-11-14)

-=-=-=-=-=-=-

Duelin' Boots

I tried dual-booting back in the very late 1990s, Mac OS and I think it was Yellow Dog Linux. Since then, not so much. Problems include the installers or updators elbowing one another, which may result in one or more systems that cannot boot, and do you have the time and skill to debug and fix that? Or how many on IRC or a forum will be dragged along when the waters turn out to be a bit too swift and deep? There is also generally a lack of security updates until the other operating system(s) can be booted, which means frequent reboots, or a virtual mandate that urgent security updates be installed before the long-since-rebooted OS can more safely be used. Also dual-booting may not mix well with configuration management, in particular the kind that is push based. Or maybe the different OS do different things to set the clock on the motherboard, and now you have unexpected time sync problems? Dual booting is more complicated and time consuming than any benefit provided, in my view: you have not only multiple operating systems to maintain, but also the potential for bootloader and hardware level interactions between them, and various security and configuration management drawbacks. Do you have the time for that?

"Mac OS" probably needs to be tagged with "Classic" these days; this was before Mac OS X 10.0.0 came out. Also I guess postings are supposed to have stock photos in them? I haven't used any modern AI, so here's something cropped with ImageMagick.

grumpy-unix-sysadmin-teapot.jpg

Alternatives would be to run one or more operating systems under a virtual machine, or to find a clunker laptop to put probably not Windows on. The clunker presently attached to the synth took four spins of the "find a working linux distro" bottle (2023 edition), and the wifi is still a little broken. The install was done over wifi, by the way. Why would I want to dual-boot even more operating systems that would only add to my woes?

There are probably cases where dual-booting might work out. Maybe on a very well isolated test network, where IT need not be involved when things break horribly, or there is enough local documentation and people to keep things mostly running, and some critical need to actually boot multiple operating systems at the hardware level, and without this being done by swapping out the boot device or using a USB stick. A (hidden!) PXE boot menu might offer memtest or other rarely used options over the network, such as a FreeDOS instance for applying firmware updates. The PXE boot menu was always hidden so that users would be less likely to find it and get into some "they need help now" state, such as their hardware being wiped and reinstalled by an automated installer for one of the supported operating systems. ("VLAN" was a new and scary word on the networks involved. I will neglect to mention what decade that was.) Maintaining the PXE system did take time, though was probably worth it for the automated installs.

bphflog links

bphflog index

next: Redefined