▲ 157 points
back
119 comments
It's not that new an idea. Keeping everything in persistent memory has been tried quite a few times. LISP went down that road, with Interlisp and Symbolics. Everything is in one persistent LISP image, and you save entire images if desired. Symbolics had some extra hardware support to tag objects in memory and get some level of pointer safety.
OS/400, and to a lesser extent the B5500 and successor machines, went down that road too. That model was "everything is a relational database." OS/400 had a 20 year run; released in 2008, end of life in 2018.
Other ideas that never really caught on include hardware key/value stores, or "Smart RAM". That may come back, since accessing non-volatile RAM through disk drivers is inefficient.
The talk seems mostly focused on GUIs, which is a separate issue.
If you want to think about a new generation of operating systems, think about what to do in the GPU space. That's the future of hardware. Single CPUs have hit the wall on speed, but there's plenty of room for GPUs with more functional units.
GPU programs are almost stateless. Very functional. But at some level you need state. How should that interact with a near-stateless GPU? Big unsolved problem.
I was stuck in the planning phase for a pet project up until a week ago, for a reason why Lisp and Smalltalk always made me nervous.
Bugs can put your persistent state into uncharted territory, and there may be no clear path back. There's a reason we still have 'turn it off and back on again' in our bag of tools. Often it's the only thing that reliably works. This makes systems designed never to be shut down and turned back on again deeply unimpressive to the more practically minded members of the audience.
One of the places persistent state crashes and burns is when the system of record and the source of truth combine. Once the source of truth breaks we can't know what's true anymore.
My breakthrough was figuring out that I'm trying to get data from something that is already a pretty good system of record, I can just keep letting it do that job indefinitely. My source of authority needs to transform that data, not own it. As long as I can detect out-of-band changes to the system of record (which I can), I can always rebuild my models from scratch. That allows me some excellent test fixtures. That also gives me the option to do manual 'surgery' on the system of record rather than sinking my roadmap to implement a full feature to do something I might not need to do again for another year, or that no customer will ever see.
I am just on the same continuum as everybody else. My code needs to make a lot of decisions. I can't afford to make them all from first principles every time. I need to store intermediate values. I also need to identify intermediate values and question them. If I don't get help with this from my architecture, myself and coworkers will blur the lines every time a problem seems a little beyond our abilities, and eventually nobody will know what's true anymore except the delusional ones. How do I know this? Because I have never seen any other outcome. The only differences are in how much surprise the team exhibits.
> OS/400 had a 20 year run; released in 2008, end of life in 2018
Err, setting aside the math inconsistency there, AS/400 was released in 1988, and the 2 most recent versions are still supported..
Real applications don't hit CPU walls, they're bottlenecked by I/O more often, and the biggest CPU wall is memory accesses. There is a lot of room for innovation there if you shirk off POSIX compatibility.
Also, state is not a problem for functional semantics. Remember "functional" is a semantic distinction, it doesn't imply a ton about optimized implementations of those semantics. For a stateful system the only thing different about a functional approach is the programmer cannot express a program where yielding next state invalidates current state. Most of the time a sound, functional program can be compiled into in place (mutable) operations on the state, the difference is they're free of logical errors.
You are making the author's point for them :-). Now add in that some of the stuff that was "custom hardware" that supported the concept of 'always resident' OS state is now off the shelf (specifically Optane/Crosspoint stuff) Of course Intel killed of consumer Optane for SSDs so one wonders what is going on there.
The second point, about how to think about GPUs in the context of "modern" computing is, for me, the more interesting one. As mobile processors have for years been a GPU with a processor accessory laptops and desktop computers seem to be headed that way as well. To be honest I'm surprised there isn't a GPU "motherboard that you can plug one or two CPU daughter cards into.
[Author of the piece here]
Thanks for the comment.
You do make me wonder if you listened to the whole talk, or read the script (https://docs.google.com/document/d/1wM1-c7euvQaRaCL4hKCaE8VR...)
I specifically addressed and discussed Lisp, Symbolics, & OS/400 (which is still alive and well).
IBM i (as it's now called) seems to more or less treat everything as a single giant disk than as a single memory space, though. However, it's been hard to find solid info for non-IBM-specialists.
It is not at all focussed on GUIs, no. However, I needed something pretty to put on the slides.
The focus is explicitly, as discussed, on end-user general-purpose computers, not servers. Servers are very well-served (pun intended) already.
Yes, I _know_ that this is not all-new. Indeed, that was one of my core points. The reasons are:
[1] I think there is more significance to something obscure or niche that has survived for decades and is still actively maintained and used than almost any flashy new offering which could fizzle out again just as fast.
[2] Using existing tech means that there are people out there with experience in it. It is not all-new for everyone. That's helpful.
[3] I personally am not very interested in GPU tech, and I think the new Apple M1 ARM chips bear out why: the standalone super-powerful GPU with its own RAM is probably a temporary artifact of PC designs and the gaming market.
I believe there are only two problems in computing: how data is divided up, and how data is bound together. They function nearly the same because you can use one to get the other, but the choice of which one to apply is critical and influences the shape of the media built on top. Where division is easy, things get shoved into countless categories. Where binding is easy, everything gets glued together.
With respect to the issues of operating systems, "data" maps to "hardware resources". With execution logic, "data" maps to "software architecture". And so on.
>If you want to think about a new generation of operating systems, think about what to do in the GPU space. That's the future of hardware. Single CPUs have hit the wall on speed, but there's plenty of room for GPUs with more functional units.
Will it be more like the web with HTTP?
As long as the problem you are trying to solve is shaped like rendering pixels on a screen, GPUs are great!
The future is multicore processors not bottle necked by the bus to a GPU. And coroutines.
OS/400 is very much alive, its called System i now.
Wait, OS/400 is going to be EOL-ed? How, why? :-/
I feel like I have so many problems with this. Like, look, I have some huge projects in Adobe Illustrator and they are quite deliberately spread out among a ton of files because anything over a certain size is just asking for working on it to become super-slow, and for some obscure edge case to completely trash the file.
I'm skimming the PDF of his slides and I'm just seeing a long list of quirky environments that have continued to be dead-ends. Maybe he talks about how this would actually work with huge power tools if I watch the talk, maybe he grapples with issues like "programs crash" and "iterative backups are good". Maybe he even deals with things like "files are a metaphor based in the physical world and perhaps the reason we keep on coming back to them is because they provide a good way to say that this particular piece of information is over here". I dunno, I'm not seeing suggestions of anything that makes me want to invest the time in listening to the talk.
I wish him the best of luck, maybe he will be the one to finally find a way out of the world of files to something so clearly better that it's worth dealing with the raw edges of it only being a few years old vs a modern GUI atop a filesystem, but I sure ain't gonna hold my breath.
I can say this. I highly doubt we’re done innovating with how software is made. I feel like systems development has gone extremely out of fashion in the past couple decades. The OS’s and tools we have are good enough to get a lot of stuff done.
However, there’s still quite a few problems, and we don’t even know the productivity level we could get to, because we haven’t seen the future. There’s nothing wrong with not being a dreamer or not trying wanting progress the industry. But, there’s also nothing wrong with doing those things either.
[Author of the piece here]
The slides are just decoration and can be safely ignored.
You would be much better off reading the script: https://docs.google.com/document/d/1wM1-c7euvQaRaCL4hKCaE8VR...
I applaud the drive and vision to experiment with a fundamentally different operating system paradigm. But even if your persistent storage is RAM, I don't see why you wouldn't still want a filesystem. Filesystems arose as a method of organizing data. However fast your access time, you still want that. Maybe you could have some kind of database backed tagging system instead of a directory hierarchy, but the benefits and drawbacks of such a system should apply to an SSD or even HDD as much as to something in RAM. This goes for user data (eg. photos, documents) as well the organization of the operating system.
Anyway, I'm curious to see what what this project comes up with. I suspect it will be something that looks and functions a lot like a filesystem, but I'd be happy to be proven wrong.
I see what you are saying but I think it misses the point. We need a filesystem right now because data disappears from RAM when electricity goes away.
With persistent memory you don't need that extra serialization/deserialization step to/from the filesystem. Look, think it like this:
1. In memory we store our program code and data as blobs in various parts, in the stack, in a heap, some only for the current program, other stuff like shared libraries linked at runtime to various programs. It's a rats nest of pointers.
2. When we "save" or "restore" we takes that rats nest and pull out some of the important parts (e.g. we ignore the shared libraries in memory and the app code) and we serialize that state out to disk.
3. Then the file system takes that logically contiguous "file" and breaks it up into pieces and stores those across the disk in various blocks and writes metadata which describe how to put the pieces back together again.
With persistent memory we can ignore steps 2 and 3 most of the time, but they still might be useful for sending data to other computers, especially step 2.
Disclaimer: I read the slides but didn't watch the talk
I think the main benefits would be rethinking the core of persistence to be more about atomic operations on datastructures as opposed to POSIX filesystem IO.
I personally believe that files are still a useful metaphor, and this hypothetical OS that we're discussing would likely still provide them, at least for interop.
An example being a database. Provided we didn't have to batch writes, be aware of dirty pages, write things in certain order to maintain coherence in the event of a crash, etc... we could build something really simple. Ultimately it would depend a lot on the details like memory bandwidth+latency between DRAM and NVRAM
Even AWS S3 is a key-value storage system. Meaning your key can be anything.
But over time, people tend to name the key using a path structure, separated by forward slashes, to give a logical separation of data into subdirectories.
Advances in performance are largely about impedance matching, from sequential access tapes to registers in a CPU. You want to use an efficient interface and abstraction for the level you're at. The direction of progress is toward faster, more randomly accessible with less seek cost: HDD -> SSD -> XPoint, etc. This totally makes sense--using RAM through a disk interface (e.g. RAM disk) is useful if you want a faster disk, to get something faster change the interface to take advantage of the medium.
This part:
> A possible next evolutionary step for computers is persistent memory: large capacity non-volatile main memory. With a few terabytes of nonvolatile RAM, who needs an SSD any more? I will sketch out a proposal for how to build an versatile, general-purpose OS for a computer that doesn't need or use filesystems or files, and how such a thing could be built from existing FOSS code and techniques, using lessons from systems that existed decades ago and which inspired the computers we use today.
reminds me a bit of something I've long wanted to experiment with (or see someone else experiment with). Here's how I described it in a comment here on HN a while back [1]:
> I've toyed with the idea of replacing files with processes. If you have some data that you want to keep, you have a process that holds it in its process memory, and can give it other process via an IPC mechanism (if the other process is local) or over the network (if remote, although you could of course also use the network locally).
> I never got around to trying it out. I think I may have tried to start some discussion on usenet along these lines maybe 10-15 years ago, but no one seemed interested.
> A "directory" would simply by a process that provides some kind of lookup service to let other processes find the data storage processes that contain the data they are looking for.
> You'd still have disks on your computer, but they would be mostly used as swap space.
> The system would include some standard simple data holding and directory processes that implement a Unix-like namespace and permission system, but it would be easy to override this for data that needs special treatment. Just write a new data holding program that implements the special treatment you want and knows how to register with the standard directory processes.
> If you have some data that you want to keep, you have a process that holds it in its process memory, and can give it other process via an IPC mechanism.
Basically this is how Erlang / Elixir programs store state. Look for Elixir's GenServer behavior.
I may be misunderstanding your proposal, but wouldn't this make privilege escalation vulnerabilities both more severe and more common?
You should definitely look into Erlang then.
This is basically how the Palm Pilot worked.
The RAM in the system was a developer-invisible cache that sat on top of a record-oriented access layer on top of the nonvolatile flash and system ROM.
I'm simplifying slightly but it's the same idea. It worked okay but had its quirks.
[Author of the piece here]
Yes, indeed - I specifically discussed that in the talk.
The Palm platform sold over 50 million units, with no filesystem at all. This shows the tech is valid for end-user devices, IMHO.
In fact, Palm Pilot didn't have proper non-volatile memory, instead, it had static RAM, which would preserve data for some time even if you swapped the batteries.
The author is conflating hardware and logic. A hard drive is hardware but a file system is a logical tree. The author provided simplistic reasoning for abandoning a type of hardware but no reasoning for abandoning file systems.
If not a file system then what? Don’t say RAM, because that is still hardware.
decades ago i was following a kid's graduation project of a OS with full permanence design. that was before Android and other always on "computers".
it was called something like unununium (yeah, same name as the element, for extra hard-to-search points). I noticed the project when he suggested unununium-time as an alternative to linux time in a list was at, to fix some time skew problems... But what caught my interest was his vision that in the near future (remember, before android/IOS) computers would not care about offline data storage and a OS should be optimized for always-on and RAM only.
I can still find some of the assembly versions, but the fun stuff and interesting ideas showed up on a rewrite in python(!) and that i can't find anything any more.
edit: here's the best i could find https://web.archive.org/web/20060208191407/http://en.wikiped...
seems the vision was to threat the persistent storage as the only system memory.
I also don't quite get why you would ditch files/directories which are just a way of organizing data. You still have to organize them if everything is in main memory. Also, sharing data between programs has to be possible somehow. You will need some kind of reference/pointer to the data you talk about. Why are directories, files, and paths such a bad idea for that?
I'm not a kernel dev, or anything remotely close to it, but it seems to me that purely nonvolatile memory would have the unhappy side effect of not being able to just reboot the machine when things aren't running quite right. It's amazing how often this fixes problems, even in 2021.
Surprised no one mentioned https://en.wikipedia.org/wiki/Phantom_OS
I went through the slides, saw bunch of pictures of old computers, but where is the proposal?
Isn't this just a SASOS?
https://en.wikipedia.org/wiki/Single_address_space_operating...
Looks to me like an outdated idea, at least on the concept level :) . Had similar thoughts around 2002, the closest thing to it was Ousterhout's RAMCloud. Today an approach would be to look at merging CPU and RAM.
I don't see what's so groundbreaking here. It looks like a lot of back patting.
You've basically described a classical von Neumann architecture. The only reason hard drives were added to that is because volatile memory is expensive and the only reason why we don't use flash memory instead is because flash is not performant enough.
The proposal has never been impossible. Just impractical and non performant in the real world. There's no such thing as "terabytes of non volatile memory" without either spending hundreds of thousands of dollars on RAM or settling for slow flash RAM.
I think this is really interesting, but I don't see any reason why you'd abandon the idea of a filesystem. UNIX has been consistently useful for all sorts of purposes largely because of the everything-is-a-file concept.
Are we going to keep only a single copy of everything in memresister or whatever? someone will reinvent raid, and someone will reinvent the disk controller.
i'm sure this tech will change all kinds of things but why wouldn't i want a simple hierarchial naming system to refer to all of the different blobs i have?
that said, i'm sure i'll watch this!
There're so many screenshots of GUIs. But there is a heavy path dependence on customer-facing GUI systems. A starting over on OS seems more likely to happen on cloud OS.
In any case, the question is do we really need the existing OS abstractions if we implement everything in managed languages?
[1] https://www.microsoft.com/en-us/research/publication/singula...
Intel actually discontinued Optane for consumers so this won't really fly... At least not yet.
I do think a completely out-of-the-box rethink of computing could lead to very interesting results though!
I love people experimenting with new OS paradigm. Although I was expecting something else.
But getting 8GB of Super Fast Memory + SSD will forever be cheaper than persistent memory. Not to mention persistent memory is nowhere as fast as DRAM. There are far more benefits with CPU and GPU sitting next to each other sharing the same memory address space, this requires high bandwidth memory. Which basically means there is no cost incentive unless this shift provides some gigantic leap forward in value.
I have had this thought about much web software these days. Requesting a lot of data from DB instead of just keeping a persistent object system in the memory.
Persistent memory sounds whole lot like OS/400.
I've never used Multics myself, but from what I understand it was also based on the idea of mapping files in memory. When I first heard this, I thought the idea was pretty neat, but then the person I was speaking to remarked that it wasn't all that great in practice. I'm not really sure why, but I'm curious.
Doesn't iOS have some kind of persistent memory abstraction? It seems more like a single level to me.
Safari on iOS saves tons of tab state going back months, but it's not using all your memory, etc. I have never really done iOS programming so I don't know the details.
Doesn't this almost say no to the con Neumann architecture? Is this a good idea?
Isn't the point of having multiple files to simplify managment and reduce risk of corruption?
parahrqph five before mentioning lisp and Psion. pretty restrained for Liam!
The problem with starting over is that you don’t understand how the current state came to be, so you’ll probably just reinvent it instead of getting anywhere new. See Chesterton’s fence.
To me things that are worth starting over would be the CPUs that we no longer understand and the OSes that are debugged into existence. Not a computer that has no SSD because memory is persistent.
For me at least this link breaks the browser back button and prevents me from coming back to HN (iOS Safari)