The lovely thing with legacy architectures (6502, 68k, x86, z80, etc.) that were in use during that time is that they were very very simple: all you needed to do was put executable code on a ROM at the correct memory address, and the system would boot it.
There wasn’t anything required other than making sure the code was where the CPU would go looking for it, and then it’d handle it from there.
Sure, booting an OS meant that you needed whatever booted the CPU to then chain into the OS bootloader and provide all the things the OS was expecting (BIOS functions, etc.) but the actual bootstrap from ‘off’ to ‘running code’ was literally just an EPROM burner away.
It’s a lot more complicated now, but users would, for the most part, not tolerate removing the ability to boot any OS they feel like, so there’s enough pressure that locked shit won’t migrate down to all consumer hardware.
There was still real competition in the x86 OS space back then, also. Like IBM had OS/2 and DOS 7, and made hardware, so they certainly wouldn’t want it locked to a Microsoft OS.
On the DOS side you had MS, IBM, and Digital Research.
You also had a bunch of commercial UNIXes: NextStep, Solaris, Xenix/SCO, etc. along with Linux and a variety of BSDs. There were also a ton of Sys4/5 implementations that were single-vendor specific so they could sell their hardware (which was x86 and not something more exotic) that have vanished to time because that business model only worked for a couple of years, if that.
There was of course two different Windows (NT, 9x), OS/2 which of course could also run (some) Windows apps, and a whole host of oddballs like QNX and BeOS and Plan9 or even CP/M86.
It was a lot less of a stodgy Linux-or-Windows monoculture, and I miss it.
…I still have some OS/2 (or, rather, ArcaOS) systems running here.
Mostly for a very limited subset of things that never really migrated across to “modern” windows - I have a BBS running on there because 16 bit DOS apps on OS/2 was pretty much the best way to run them when it was 1994, and in 2024 it’s still the best way to deal with them.
but users would, for the most part, not tolerate removing the ability to boot any OS they feel like, so there’s enough pressure that locked shit won’t migrate down to all consumer hardware.
The same reason people who drive 20 miles a day have worries about range on an EV that’ll do 300, or why people espouse the freedom of Android but then use the default Google apps.
People like the option of choice, even if they’re not necessarily ever going to engage in making a different one.
If there are two options for a computer, one is “will run everything” and the other is “will only run Windows” a good portion of people are still going to pick the first, even though very few of them will ever do anything else, simply because people really really like having the option of choice.
I don’t think they even know that there’s a possible choice. Common people don’t understand computers, not at this level.
Cars is a good example for another reason. Do we have new cars without a built-in internet connection and continuous user (and environment) tracking, and questionable remote control functions? Afaik we don’t.
If you wanted to swap your vendor EFI image to something else, at this point it’s all going to be via a SPI programmer, and if you own one of the two boards that it supports, coreboot/openboot.
But, essentially, you can’t swap because there’s very little supported hardware, and thus are stuck with your vendor proprietary EFI.
What’s hilarious, I guess? is that the EFI setup is more or less it’s own OS that can then chainboot an OS which is how the mid90s workstations (Sun, SGI, HP, etc.) worked.
Seconding that’s a not-how-things-were.
The lovely thing with legacy architectures (6502, 68k, x86, z80, etc.) that were in use during that time is that they were very very simple: all you needed to do was put executable code on a ROM at the correct memory address, and the system would boot it.
There wasn’t anything required other than making sure the code was where the CPU would go looking for it, and then it’d handle it from there.
Sure, booting an OS meant that you needed whatever booted the CPU to then chain into the OS bootloader and provide all the things the OS was expecting (BIOS functions, etc.) but the actual bootstrap from ‘off’ to ‘running code’ was literally just an EPROM burner away.
It’s a lot more complicated now, but users would, for the most part, not tolerate removing the ability to boot any OS they feel like, so there’s enough pressure that locked shit won’t migrate down to all consumer hardware.
There was still real competition in the x86 OS space back then, also. Like IBM had OS/2 and DOS 7, and made hardware, so they certainly wouldn’t want it locked to a Microsoft OS.
Oh yeah: there were a stuuuupid amount of OSes.
On the DOS side you had MS, IBM, and Digital Research.
You also had a bunch of commercial UNIXes: NextStep, Solaris, Xenix/SCO, etc. along with Linux and a variety of BSDs. There were also a ton of Sys4/5 implementations that were single-vendor specific so they could sell their hardware (which was x86 and not something more exotic) that have vanished to time because that business model only worked for a couple of years, if that.
There was of course two different Windows (NT, 9x), OS/2 which of course could also run (some) Windows apps, and a whole host of oddballs like QNX and BeOS and Plan9 or even CP/M86.
It was a lot less of a stodgy Linux-or-Windows monoculture, and I miss it.
I ran OS/2 Warp as my primary for like a year, I loved it, and it could even play many Windows/DOS games with fiddling
…I still have some OS/2 (or, rather, ArcaOS) systems running here.
Mostly for a very limited subset of things that never really migrated across to “modern” windows - I have a BBS running on there because 16 bit DOS apps on OS/2 was pretty much the best way to run them when it was 1994, and in 2024 it’s still the best way to deal with them.
what makes you think that?
The same reason people who drive 20 miles a day have worries about range on an EV that’ll do 300, or why people espouse the freedom of Android but then use the default Google apps.
People like the option of choice, even if they’re not necessarily ever going to engage in making a different one.
If there are two options for a computer, one is “will run everything” and the other is “will only run Windows” a good portion of people are still going to pick the first, even though very few of them will ever do anything else, simply because people really really like having the option of choice.
I don’t think they even know that there’s a possible choice. Common people don’t understand computers, not at this level.
Cars is a good example for another reason. Do we have new cars without a built-in internet connection and continuous user (and environment) tracking, and questionable remote control functions? Afaik we don’t.
I wonder what the newest PC motherboard with the BIOS ROM in a socketed DIP chip is.
At least a decade old, if not more than.
If you wanted to swap your vendor EFI image to something else, at this point it’s all going to be via a SPI programmer, and if you own one of the two boards that it supports, coreboot/openboot.
But, essentially, you can’t swap because there’s very little supported hardware, and thus are stuck with your vendor proprietary EFI.
What’s hilarious, I guess? is that the EFI setup is more or less it’s own OS that can then chainboot an OS which is how the mid90s workstations (Sun, SGI, HP, etc.) worked.