A dream of an ultimate OS (1995)

The issue I'm having is that Nvidia driver 418 doesn't support my HDMI out (still haven't figured out why), but 390 has atrocious power management. So when I'm mobile, I switch to 418 (restart), and at my desk back to 390 (restart again).

ElementryOS is heading that way, if you haven't heard of it yet. But the ecosystem is no where near close to MacOS. Sadly, for me, cause I mostly run Linux. :P

I think it'd be possible to automate that at some level, generatively code just the minimum needed at the machine level for the task, and no extra fluff.

I do like the idea of weaving database functionality into the OS, but I also have concerns. Oracle has, on a few occasions, taken to extending their database technology to areas like this and the result was obtuse and perverse. I am thinking of a large system I worked on forged in early Oracle Forms and Reports. Each form (window) would have trigger procedures stored in the package that represented it, and you were left with the kludged-in features of PL/SQL for basic things like looping and control flow. SQL was never intended to define software. And attempting to take it and mutate it in that direction is starting from a false premise I think. Sure, with anything that is Turing Complete you can build anything. But that doesn't mean you should.

If that danger is avoided, the broad concept itself might have merit, most especially in replacing the way we deal with filesystems which should have changed decades ago. I believe that storage should be separated into mutable and immutable categories. Immutable data (software packages and the like) should be managed by a universal networked content-addressable versioned immutable data store. Something like Perkeep mixed with the Internet. If you did something like 'apt-get install firefox', it would lookup the current versions GUID from a DNS-esque service and check the local store, then the local network store, and then hit the Internet store of data if necessary to pull down the content. It could be thought of like extending storage from registers, L1 cache, L2 cache, L3 cache, main memory, disk outward to the network, with data traversing each level only when necessary as a kind of overgrown cache control. Very storage-constrained contexts could purge anything immutable with confidence that it would be able to pull it back in when necessary. Call it 'swap to the cloud' if you're a marketer who doesn't realize how horrific that sounds to technical folks.

Mutable storage would be handled as a local database, it would be all of your personal content and similar, stored and indexed with ways that are efficient for data which can change rapidly and which must be preserved as it may be the only copy. Individual disks should, ideally, be presented to the user as a unified whole with reliability information baked in and managed by the OS in the background. Whether and which data is replicated, striped, etc should just be something people set with their hardware providing maximums (if you have 3 drives, you can choose 300% reliability as its max and based on the drive reliability, age, SMART status, etc, the system will rebalance what is stored where in order to best preserve the users desires, only bothering the user when things cross a certain threshold of uncertainty). Data is important. Not just for corporations, but for everyone.

Software Transactional Memory should be built into the hardware level and supported at the OS level, and can be supported at the OS level before hardware has a chance to catch up and accelerate it.

The OS should present itself sort of like Smalltalk "images" operate to the user, albeit with most of the moving pieces covered by a thin veil unless you launch a 'system edit' sort of mode which would make the running objects editable and present live development tools. Code editors should not simply be text editors, but tools which know they are operating on code and treat it as such, allowing one to operate on an AST or syntax tree view for certain operations.

Vector graphics and the concept of graphics 'surfaces' rather than a simple framebuffer should be the 'step 0' of supporting moving to a more modern system. Take advantage of modern pixel densities on high-resolution screens.

Re: #1, when I said “highly-integrated”, I was referring to base-OS features that depend tightly on things (maybe third-party) drivers do. I.e., having more kernel or userland code, on the OS side of the fence, that calls into untrusted driver code through specialized (rather than generic “device-class” API) interfaces. Things like kernel serial-debugger-over-USB support, or how Windows elevation prompts interact with screen-reader software. Another example, not from desktop OSes, is how Android/iOS treat being plugged into a car.

In all these cases, a third-party driver is essentially being given the the reins to the system, intentionally, as part of the user’s expected workflow. Windows and macOS (and, I would suspect, any OS solving for enterprise requirements) both have places where they allow third-party drivers to participate in these elevated APIs; while Linux doesn’t really (Linux only has third-party driver-blobs that fit to specific isolated in-kernel sandboxes.)

My thought re: #3 was that:

• with Linux (and disregarding the few large corporate binary blobs for wi-fi and GPU), mostly corporate-sponsored FOSS devs write PRs for the kernel, and then the kernel maintainers “take receipt” of that code by merging it, taking all further responsibility for that merged code, making it essentially equivalent to code they wrote themselves (and at that point, the code is now owned by the kernel project, such that new development should not occur out-of-tree against the original development, but as in-tree patches against the merged code);

• with Windows, corporate third-parties (but often fly-by-night Shenzhen ones, if that’s the hardware you buy) maintain most drivers, and Microsoft just certifies them, like apps in an app-store (which ensures mostly that they don’t crash Windows, and isn’t a security audit);

• with macOS, Apple writes most drivers. Of the drivers third-parties do write, Apple takes ultimate control and responsibility for QAing that code and customizing it for macOS—Apple does their own builds, hardware-matrix testing, packaging/deployment, etc., essentially making each particular point-release of a driver into a part of the base OS. However, they don’t take ownership of this code; the driver will rot unless the third-party sends them a new version to start integration on all over again.

• with Hackintosh’ed macOS, random FOSS hobbyist developers write the (extra required-for-your-build) drivers, and nobody is guaranteed to be maintaining or QAing them.

A security-vulnerability surface isn’t just about surface area, but also about how much control and visibility—essentially, trust—the OS maintainer has into that surface area.

Windows forces updates as often as it does, because Microsoft doesn’t have good visibility into which third-party drivers will be affected by which updates (which they could use to bunch together all driver updates addressing a particular CVE); nor do they have control of those third-party drivers enough to structure them such that their updates can be woven into a seamless, non-restarting update process. Security-critical updates just... show up, on their doorstep, coded in arbitrary silly ways (to deal with the arbitrary silliness of the original background services and/or tray utilities that talk to the driver) and they have to deal with that.

Linux—at least where the base OS is concerned—doesn’t have any such “opaque-to-the-maintainers” surface area, so Linux can get away with fewer “restart required” conditions. They have both visibility and control.

macOS—because Apple demands ultimate control of all macOS drivers (to the chagrin of companies like Nvidia)—can demand that drivers take a particular form (i.e. microkernel daemon servers with activation ports) where Apple are easily able to just in-place upgrade many drivers as part of a package installation, without restarting the OS. The fact that they’re already in relationships with these driver developers also gives them visibility into the progress of addressing CVEs.

(macOS does want to restart for point-release updates pretty often, but that’s down more to Apple’s BSDish philosophy of “the base OS is a whole that should be replaced with a new whole, rather than getting into a state where both old and new components are running.”)