A FOSS proposal for a new type of OS for a new type of computer (2021)

And errors are forever.

There were once LISP, Smalltalk, and Forth environments where you saved the entire state of the system, rather than using files. This was not a good thing. Only one person could really work on something. If you messed up the image, undoing the mess was hard. Revision control? What's that?

Progress has been made by learning how to minimize and discard state. What makes the web backend application industry go is that almost all the state is in the database. Database systems are well debugged and reliable today. This allows for mediocre quality in web apps.

Containers are another example of discarding state. Don't sysadmin, just flush and reload. So is the transition from object-oriented to functional programming.

No, making memory persistent is not the answer.

We do need to be thinking about new OS designs, because the hardware world is changing.

- Lots of RAM. Swapping out to disk, even SSD, is so last-cen. The moment that happens performance degrades so badly you may as well restart.

- Lots of CPUs. There are now 128-core CPUs. NVidia just announced a 144-core ARM CPU. The OS and hardware need to be really serious about interprocess communication. It's an afterthought in Unix/Linux. Needs to be at least as good as QNX. Probably better, and with hardware support.

- Different kinds of compute units. GPUs need to be first-class players in the OS. There are going to be more special purpose devices, for machine learning.

- SSD is fast enough that buffering SSD in RAM is mostly unnecessary.

We could have OSes that don't use files, that save state and are able to resume in seconds, and we can do all of that in C (I don't think we would want to but we could). Also there doesn't exist a world where grandma (or even the Kool kids today) is going to learn smalltalk in order to use an OS.

The main hurdle I see with all of this is hardware initialization -- how to handle, from cold boot, the fact that your network card has no idea what frames has been sent and what have it has been received.

The first step I see in all of this is creating an operating system where the kernel has no concept of being booted. One thing people struggle to wrap their head around with optane is "what does kernel upgrades look like" which would be messy in existing OSes.

No matter how it is presented, all addressable storage in modern computing systems is hierarchical. Pretending these latency hierarchies don't exist doesn't make them go away.

If you obscure this by making it all look like RAM, the implied access latency variance due to access patterns and underlying concurrency control is still operative, just opaque. Computer science is full of data structures and algorithms designed to be fitted to the latency hierarchies of real hardware; it is difficult to make algorithms well-behaved when the hardware is designed to make it difficult to reason about these latency hierarchies.

Ironically, I always worked around this by reading the low-level system hardware documentation that described how the hierarchy was being hidden and scheduled so that the memory access patterns could be engineered to elicit specific hierarchy aware behaviors that the code wasn't supposed to know about. We ended up writing the same hierarchy aware code required for systems that don't use RAM as an abstraction, but with a much worse and more difficult to control API.

Working on different exotic computing architectures was extremely educational. It gave me an appreciation for the practical tradeoffs of various weird hardware models that most people only talk about in theory. It is similar to the perspective you gain from experience writing software in many different programming language paradigms. There are no silver bullets, just a different set of problems you have to deal with.

2) Then I went to the slides, and found what appeared to be a talk about programming languages and desktop environments.

3) Filesystems are often thought of as ways of finding data on some storage medium, and that's not wrong. But files are also a way to organize data, largely independently of the technical details of the filesystem itself.

And yes, if your battery died, you lost everything. Palm devices were designed to by synced to PCs at least daily, so you’d just restore by syncing again.

The speaker does not touch at all the details of *why* all of these were superseded by supposedly worse and more complex systems, "What went wrong?"

The systems that are being romanticized in the talk were a coder's delight, a peak of personal productivity, discoverability, malleability. They did have an integrated rich UI, where everything is a programmable action, everything is traceable and introspectable, wrapped by human-usable keyboard/mouse actions and UI presentation.

Still, they handled structuring, versioning and communicating *complex data* badly, something which was solved much better even by Unix/Windows-style filesystems and utilities. Plan 9 was an improvement over Unix in many aspects, but handling data complexity was not one of them.

My suspicion is that what is still very lacking today is well structured and introspectable data, system-wide schemas, rigorously defined ABIs, serialization and IPC mechanisms, transactional guarantees. Mo more raw streams/blobs of bytes everywhere, no more untyped pipes, no more poorly defined structs in C headers that implicitly define ever-changing ABIs, no more file systems without transactional guarantees, no more reimplementation of sorting and filtering in every Unix utility. I hope that the state of the art has advanced far enough to finally have a useful and comprehensive common language for data and interaction (Fuchsia's FIDL + capnproto + a kind of Kaitai Struct on steroids?), including network communication (kind of a global IPFS-like database of schemas?).

So no, moving back to the "good old days" of a magic old programming language is not the answer, in my opinion. There are other pressing issues that have never been solved well before and may be finally solved now.

I don't know if the author intended this to be rhetorical, but the reason "disk" file storage exists is to store files, right? Files will outlive a system like books have outlived entire societies.

At the same time we're clinging to programming using empirical thinking that came from the first machine language programs ever written. We should be at a point that we can think and write more declaratively even when executed sequentially. Numbers of cores has continued to go up and any language that doesn't parallelize well isn't worth investing in for the long term.

But I think there's always some essential state that we'll want to persist. And I agree that modern filesystems are way too janky. Its hard to store anything safely because there's no transactional support. Its hard to share edits between computers because files are totally opaque to the operating system. So my changes will clobber your changes. And the save-load loop is inefficient. Why do I have to write out my entire file again after making a single character change?

But the core promise of persistent values is important. Why can't I just bless a variable in my program (and give it a name) and have it persist between instantiations? Like, if I give x some persistent identity, then set x = 5, it should still be 5 when I restart my computer, reload my webpage, or open a second web browser.

I'm not sure if persistent memory is the answer. My take is that I think we need to start using CRDTs more deeply in our operating systems.

A well written operation based CRDT (Concurrent Replicated Data Type) is an append-only log of patches, which together create a mutable value. Treating it as an append-only log makes it easy to store on disk or replicate over the network. And treating it like a value makes it easy to program against. The log of changes grows over time, but you don't have to store all of it. (Or really, any of it). You have a tunable knob of how much history you want to keep around. More history data means you can support branches, merging and time travel. Less history makes it smaller. (And the data you need to keep for merging is really tiny in practice, btw.)

With CRDTs we can make magic variables which work like that if we want. And unlike persistent memory, CRDTs can share their value with other processes, other devices and other users.

Rather than sysfs, procfs, etc, I want all the OS's internal state exposed as live variables I can just subscribe to. And I want my own data (documents, etc) to work exactly the same way. For some data sets (like my source code), I want to keep a full change history. And for other data sets (my CPU temperature) that should be something I explicitly opt in to.

But regardless, all of this data should be able to be shared with a flick of the mouse.

I mean any user space program can harm all (same) user space data and since often there is only one user in a system this is fatal.

Before the first benchtop data systems came along you had to evaluate the curves from the graph paper yourself and then calculate numerical results by hand. A single-point report like CO2 content alone is quite easy & quick manually, but when you have dozens of hydrocarbons on the same graph that all need to be calculated in parallel it was not so quick and more prone to error.

Programmable calculators could then be used to save time on some of the purely numerical work for the high-data runs, and this is about like what would become the final part of the built-in workflow for these early application-specific computerized gas workstations.

Offices didn't have PCs yet, just typewriters, copiers, filing cabinets and simple calculators.

For laboratories the built-in gas report printers were leapfrogging technology with each generation, the inkjet first appeared in a HP model for the instrument lab before they began to apply it to office equipment.

The evolution has been interesting.

One particular series of late 1970's design benchtop data system was multi-user and multi-tasking way before Windows. Like others it took in the raw analog signal (still do but they're "black box" interfaces connected to PC's for further calculation now) from the benchtop gas analyzer in real time and produced digital data from the curves on the graph. This electronically accomplished that first manual procedure of measuring the curve to begin with.

From that point on it's all calculation.

Each gas run was autosaved in memory as a file having an automatically-assigned file number, no more than 3 digits. There was no way anybody had enough memory to record the entire analog signal at the time so this was just the key geometric features in digital form.

There was no file system.

Today on PCs the entire analog gas signal is recorded to HDD in digital format routinely. And people still lose files all the time, don't ask me how I know.

But for that antique data system there was no storage other than memory absolutely required, many bare-bones consoles were issued without the optional micro-cassette tape drive. The tape was quite slow and best for long-term storage or disaster recovery. An optional COM port became available years later which was faster, but there was no workflow change for most users. A great deal of fairly advanced work could be accomplished by many without need for any storage device I/O over a period of years. Just a one-page printout about each gas destined for the physical filing cabinet.

You never were supposed to turn the console off. Except whenever you wanted to! The major use case is 24/7 so there were expensive battery backup units to protect from short- or long-term power failures, which only preserved the memory. If the power failed the battery kept everything the same and you only lost a gas run if it was in progress and had not been saved in memory.

But you could also power down the console from the main switch any time and its high-power-consuming hardware, processor, and power-supply would go cold. Like when you're done for the day, the gas runs are over, and you were finished sitting at the console. The memory alone would still be powered by the battery backup unit without depleteing the battery at all unless the backup unit itself lost power. Under backup power you could also change any circuit board other than the dedicated memory PCB, including the main power supply, and it would power back up with the memory intact.

The OS was immutable and in ROM where it should be.

Also the default OS performance upon cold power-up was adequate for many simple gas tests without need for user programs or reference data files to be loaded beforehand. For many operators a few minutes of manual parameter entry gave full disaster recovery. So those guys didn't even need the expensive batteries, tapes or COM port. It was basically application-specific enough for the simple stuff already.

You could then extend that with optional user programs to more complex automation & calculations but only up to the limitations of memory.

User programs ended up as file numbers too so you were your own file system.

And to just get a truly worthwhile file listing, you had to write your own program.

Glad there were only 3 digits.

These things did achieve nearly zero show-stoppers per year on average, unlike modern PC systems which are in the handfuls at minumum and dozens for many operators on average.

There was no booting, the OS ran from ROM and the memory was accessed as needed from there. Optional storage devices were only needed for user items, the OS did not require any files from storage, and only one file present by default in memory. Simply its own memory work area.