What is involved in keeping an OS up to date?

[DeepSpaceWhine]

I'm a total noob, longtime programmer but never took an OS class and want to learn more.

Laugh at how little I know, it's okay.

I'm wondering what's involved in maintaining an OS. Take illumos for example. AFAIK it's the only open-source SVR4 OS, and I think it would be cool for computer history reasons to keep it alive. But what does that actually entail?

For a mature 64-bit OS like illumos is it largely a matter of just keeping drivers up to date with the latest hardware? Does the kernel itself need updating for some reason? Can an older OS like that not, for example, hibernate properly when closing a laptop lid? Is it a Wayland/X11 thing? Networking code out of date? I remember 20 years ago on Linux things like wifi and 3D graphics and laptop hiberation were a pain to set up and now they largely work out-of-the-box (except for NVidia). Besides drivers what are the actual OS components responsible for that kind of thing?

If I'm not asking this question right, please say so.

Thanks!

[shibedrill]

I'd say the two biggest things involved in keeping an OS up-to-date, at least from a security perspective, are probably bug fixing & ensuring protocols and crypto suites are modern and properly hardened.

A big part of why older operating systems (like Windows 95, for example) are insecure is because known security problems exist that were never patched since the OS went EOL. And if you want to connect to the Internet, you probably won't be able to use sufficiently modern TLS ciphers. Support for W95 ended in 2001, very shortly after the creation of HTTPS in 1994 and its formal specification being issued in 2000. So I doubt it supports modern ciphers like the ones specified in TLS 1.3, and you'll probably be forced to browse mostly HTTP-only pages.

The amount of protocol integration in an OS really depends on the OS vendor, so obviously this isn't always true. But it's one pretty noticeable issue you get when trying to use older OSs.

And of course, there's also issues with time itself. Y2K is still unpatched on many legacy operating systems which were EOL before 2000, and Y2K38 is still unpatched on a fairly considerable amount of still-used 32-bit systems. TLS will be completely unusable on any system which never gets patched, because the system will not be able to represent the current time after the epoch rollover, and the system will believe that all certificates are only valid in the future.

[DeepSpaceWhine]

Neat. So are drivers not the big deal I thought they were? For example, when I read about things like Illumos or BSD falling behind Linux on things like laptop and GPU support, I'm assuming they can't just take FOSS Linux drivers and recompile them?

Are the main core non-networking-related, non-driver-related features of 90s-era 64-bit UNIXes largely fixed and just need the odd bug fix here and there?

[shibedrill]

Driver support is also a big factor, which I didn't mention because I was mostly thinking in terms of "how long could I keep using a device which shipped with this OS?". Inevitably all software will start lagging behind hardware if nobody maintains it. Obviously, porting something as complex to an OS across CPU architectures (for example, from 32-bit to 64-bit x86) or across major system changes (BIOS to EFI, or ISA to PCI, etc) takes major effort too. And so if you want to maintain market relevance with an OS, not *just* usability and security, you need to put considerable effort if/when OEMs decide on new hardware standards.

With regards to BSD vs Linux drivers, I'm sure the two kernels have very different driver APIs which would take considerable effort to port drivers across. And as hardware changes, the hidden subsystems in the kernel necessary to support the hardware evolves with it. But if you design your driver system to be sufficiently modular, and have support for PCIe & ACPI, you're probably gonna be well-equipped to handle commodity hardware well into the 2030s or even 2040s. Computers changed so rapidly through the 90s and 2000s that tons of stuff needed to be ported, changed, or restructured to adopt new standards. It seems like nowadays we have most of it all figured out and abstracted away into safe, consistent interfaces.

[DeepSpaceWhine]

Thanks for replying.

[bellezzasolo]

Neat. So are drivers not the big deal I thought they were? For example, when I read about things like Illumos or BSD falling behind Linux on things like laptop and GPU support, I'm assuming they can't just take FOSS Linux drivers and recompile them?

Are the main core non-networking-related, non-driver-related features of 90s-era 64-bit UNIXes largely fixed and just need the odd bug fix here and there?

Drivers are a factor, but generally a well designed driver interface should offer enough flexibility for future proofing.

Windows NT 4 recently got an NVMe driver, for instance, using the SCSI miniport infrastructure. https://github.com/techomancer/nvme2k