I'm glad to see real OS research hasn't stalled. This feels very Plan 9-esque in its boldness and commitment to its ideas. We need to let go of Unixisms.
From the looks of USENIX papers it is as alive as always, researchers prefer to focus on distributed computing OSes, as there is where the research money now lives on, the classical desktop is done.
Mobile OSes (which can be turned into desktop like experiences) is where most research activities in managed stacks and improved security are now going on.
I remember this OS project starting about 20 years ago. Since then, it haven't shipped much.
The idea behind it is to make the whole OS into basically a giant Java heap. Everything is an object, referring to other objects. It gives you some nice properties, because everything can become a capability which can't be forged. Also, everything can automatically be persisted and restored, Smalltalk-style.
The problem here is, of course, garbage collection. When not just your whole RAM but your disk storage is a mesh of pointers, GC becomes a resource-intensive task.
I wish they pivoted to building an OS for Opteron architecture; there the approach might have a chance to shine.
This has a POSIX layer so it's not free of 'unixisms' by design.
I agree it's a always great idea to explore new ideas from zero without any conceptual baggage. I'm sure that unix-like OSes will still have a lot to offer for some usecases though.
well for starters some of the machinery is useless and requires constant stepping over.
some design decisions (fork, signals) have really shown themselves to be mistakes as time goes on
for what it does on a server system for example (manage processes), there is a lot of useless genuflecting and papering over problems. remote manageability being a big one
so no, no one is going to die. but we could do a lot better.
What would you propose instead of forks/signals/process management? There needs to be some way of managing different tasks whether that's threads or otherwise
Personally, if I were designing a replacement, I would probably try something like this:
* The lowest level API to create a new process just creates an empty address space with nothing running in it.
* All kernel APIs for manipulating processes take an extra parameter to specify which one.
* Together, these replace "fork, exec" with "create a new address space, map these pages into it, create a thread running in it at this address." (With the right APIs on the side for custom page fault handling and synchronization, you can even reimplement fork+exec yourself on top of this if you want- but you don't have to.)
* Signal handlers would never run on an existing thread- this is too fundamentally fragile. Instead, for cases where you do actually want that sort of asynchronous callback, it runs in its own separate context, where it can act like normal multithreaded code. (Not every use of signals actually needs this, though- a lot of process management signals get routed to threads that explicitly asked for them, and that sort of API probably still makes sense.)
Arguably you don't even need "threads" at the kernel level. You just need to allocate CPU time somehow. I might try to make the API for that look like a callback into userspace (similar to the replacement for signal handlers above) that is then responsible for doing any further scheduling on its own, e.g. among threads in that process.
process_create(executable) would be nice start. the current model of cloning the current process creates a bit of a mess about what the parent and the child should share, and has overhead even in the exec case. now that we have threads, is there any utility in keeping the old fork() model?
not saying anything novel here, but just design a sane and uniform api.
there should be a way for the kernel to do a more controlled upcall into process space. that would scrape out quite a bit of rotten asynch implementation.
Yes macOS is now a certified UNIX, however just like its NeXTSTEP predecessor, its UNIXisms are meant to bring people into the platform, not to get them out of it.
Every single user experience that actually matters to Apple customers lives outside UNIX, relying on Objective-C frameworks, and nowadays Swift ones as well.
This is the mindset that those that buy Apple products as shinny UNIX keep failing to grasp, and then start blogging all those posts about going back to BSD/Linux, which they should have done in first place to start with, sponsoring BSD/Linux hardware OEMs.
Could you (or someone) summarize some important points? I greatly appreciate the link but I can't read 360 pages right now on a topic I have almost no background in.
I think you should properly read it and see if you still agree.
Granted it’s all very dated, so the idea of poor stability and taking up a lot of RAM is no longer an issue, but if you see what came before it and the comparisons you might wonder how we ended up where we are across all commercial operating systems.
One simple reason: too similar & then everything gets ported over, & the OS becomes YET Another Annoying OS Because It's Familiar But Feels Wrong. Yes, it's not great to have to make new, basic tools, but having tools that fit the environment is better than shoehorning in tools & demanding that compromises be made in the environment so that the old tools work more easily.
