4 ms·

It seems that open-source operating system projects either never quite get past the point of having a kernel that can print stuff, read/write FAT32, and run a c

It seems that open-source operating system projects either never quite get past the point of having a kernel that can print stuff, read/write FAT32, and run a couple of userland processes, or they attempt to implement POSIX. There's a couple of attempts to build something different - Haiku, based on the design of BeOS; and Redox, written in Rust and implementing access to the filesystem as URLs - but where's all the actual OS research? Where's the service-oriented OS built on capabilities with a typed object store for a filesystem?

adrianratnapala 10y ago
I expect it is because people who want to provide something like your service-oriented OS will do it as an application layer over existing operating systems. This also gives them the flexibility to factor the problem into smaller bits. Cap'n Proto is a service-oriented something-or-other, built on capabilities and even typed objects. But it does not give a flying -ck about storage.
- kentonv 10y ago
  To be fair, Cap'n Proto is a sub-project of Sandstorm.io which is basically an operating system and cares deeply about storage. But Cap'n Proto can be used independently...
  - deleted 10y ago
    [deleted]
- vertex-four 10y ago
  The issue is that all these bits and pieces are wonderful for developers, and to a lesser extent sysadmins, but not so wonderful for users, who still get to interact with their systems using much the same paradigm as when the first desktop operating systems came out. The closest I can find would be Sandstorm, which ends up being a frankenstein mashup of Linux and a capability system.
pjmlp 10y ago
If you want something different, research SPIN OS with Modula-3, Oberon with Oberon [1]. The work done by Xerox with Interlisp-D, Smalltalk and Mesa/Cedar [2] Or before Multics and UNIX were even born, the work done in Burroughs B5000. [3] There are plenty more examples, one just needs to dive into the history of computing. [0] - http://www-spin.cs.washington.edu/ http://www-spin.cs.washington.edu/ [1] - http://www.projectoberon.com/ http://www.projectoberon.com/ [2] - https://archive.org/details/bitsavers_xerox https://archive.org/details/bitsavers_xerox [3] - http://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...
- vertex-four 10y ago
  Absolutely, there's been various approaches researched in the past - and I've used Oberon before, really enjoyed it - I'm just curious as to why it doesn't seem to happen any more.
  - nickpsecurity 10y ago
    Takes academics being paid to create it basically. Most academics just focus on getting papers published and citations. The number that will try to do useful stuff, esp OS's, are usually a rarity. Btw, here's a few: Active development with strong features: https://www.genode.org https://www.genode.org http://www.minix3.org/ http://www.minix3.org/ http://redox-os.org/ http://redox-os.org/ http://www4.cs.fau.de/Projects/JX/index.html http://www4.cs.fau.de/Projects/JX/index.html Older, less active, or inactive but still interesting http://www.xtreemos.eu/about/about-xtreemos/ http://www.xtreemos.eu/about/about-xtreemos/ https://sourceforge.net/projects/a2oberon/files/ https://sourceforge.net/projects/a2oberon/files/ http://www.eros-os.org/ http://www.eros-os.org/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheribsd.html https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri... http://fsd-amoeba.sourceforge.net/ http://fsd-amoeba.sourceforge.net/ So, there you go. THey don't all do what you describe. Some cool stuff worth emulating or building on in the pages above. Especially EROS or A2 Bluebottle for security and ease-of-picking-up respectively.
  - signa11 10y ago
steveklabnik 10y ago
one issue is that it can take a long time to get to just that point, and so doing further, more interesting research comes after you've already done a ton of hacking.
anta40 10y ago
Have you tried MenuetOS, for example? It does have a quite nice UI, TCP/IP support, etc And without any attempt to be 'yet another UNIX clone', I think.
danieljh 10y ago
> where's all the actual OS research? Where's the service-oriented OS built on capabilities with a typed object store for a filesystem? Once you realize there's not much a difference between Microkernels are the recent microservices architectures, they become interesting again. Then you might want to look in recent advances such as Unikernels or Anykernels. Here's a good start summarizing lessons in Microkernels learned in the last decades: http://dl.acm.org/citation.cfm?id=2522720 http://dl.acm.org/citation.cfm?id=2522720
ArkyBeagle 10y ago
Perhaps there's something I'm missing but for the last two on your list there's no reason to build a full on O/S. "A service" these days means "something that lives on a TCP or UDP port" and URL means HTTP or HTTPD. I've built a couple or three microkernels[1] to use for real work, and it's just not interesting past a certain point. Once you get the equivalent of the Linux ucontext.h stuff done the rest is ... stamp collecting. [1] one back in the dark ages on top of DOS to enable getting a project rolling in parallel with the hardware, another specifically for providing sandboxed services on top of an existing RTOS, mainly to pretend this was a different computer/virtual machine, again as leverage because of schedule. These days, you would put up a hypervisor or just use a COTS virtual machine. I keep hoping something will be done with BeOS but ...
- vertex-four 10y ago
  > there's no reason to build a full on O/S. While there might be no reason to build a kernel - most modern ones will let you lock down a process well enough, although it "looks weird" - building good UX around capabilities and objects instead of permissions and files requires starting from the ground up. The vast majority of applications, tools, and workflows that people use right now don't fit within that paradigm. > "A service" these days means "something that lives on a TCP or UDP port" and URL means HTTP or HTTPD. A service consists of an administration protocol and a usage protocol. In Linux, the administration protocol is usually some ad-hoc text format and SIGHUP, in Windows it's Powershell, and the usage protocol is almost always ad-hoc over TCP, requiring a library to interact with it. It's possible to abstract services away from how you communicate with them, provided that you're working within an environment where everyone buys into that abstraction. Communicating with a file on your desktop, a file on a file server, a database server, and your coworker's spreadsheet window all become something you can do without having to find the relevant library which speaks the right protocol, or have ad-hoc mechanisms for sharing each of these things over a network - the relevant services self-describe how to communicate with them, in the same way that you can connect Powershell to an Exchange server and have all the tools for managing Exchange without installing anything. You get to do away with SSHing into another box with a completely different shell environment, or trying to wrangle your local tools to work over sshfs. You could work on drafting an important email with a coworker as easily as dragging the window into your chat application, with neither the chat application nor the email client having to care how that works - the chat application just needs to be able to transport capabilities, and the window manager needs to be able to create a "window view" capability. You can also start playing with really fancy things like dynamic constraint-based load balancing across a network, once your services don't care about how they're communicating with each other or where they are - where services get farmed out onto the network automatically when you perform resource-intensive tasks. Plan 9 gets some of the way there, although I believe a filesystem is not discoverable enough - can I reliably get a lightweight IDE to tell me what "echo swap > /dev/mouse" does, vs "mouse.swapButtons()" where mouse is a typed variable? There's also no formalized way of doing request/response (especially out-of-order), and accessing a certain field of a message requires ad-hoc string parsing which is easy to get wrong. This needs to be done as an operating system - a complete set of tools which enables a certain way of managing and interacting with resources, both as a developer and a user - because otherwise you keep hitting on the boundary of things you can interact with within the system and things you need to interact with outside the system. If you can interact with your text editor and chat application but not your spreadsheet tool or database server this way, that diminishes its use significantly. I've been playing with minimal systems which do some of this. It's interesting, but hard work to build entire new user experiences from scratch instead of being able to port a libc to a new kernel and get a bunch of stuff for free.

adrianratnapala 10y ago

I expect it is because people who want to provide something like your service-oriented OS will do it as an application layer over existing operating systems. This also gives them the flexibility to factor the problem into smaller bits. Cap'n Proto is a service-oriented something-or-other, built on capabilities and even typed objects. But it does not give a flying -ck about storage.

kentonv 10y ago
To be fair, Cap'n Proto is a sub-project of Sandstorm.io which is basically an operating system and cares deeply about storage. But Cap'n Proto can be used independently...
- deleted 10y ago
  [deleted]
vertex-four 10y ago
The issue is that all these bits and pieces are wonderful for developers, and to a lesser extent sysadmins, but not so wonderful for users, who still get to interact with their systems using much the same paradigm as when the first desktop operating systems came out. The closest I can find would be Sandstorm, which ends up being a frankenstein mashup of Linux and a capability system.

pjmlp 10y ago

If you want something different, research SPIN OS with Modula-3, Oberon with Oberon [1]. The work done by Xerox with Interlisp-D, Smalltalk and Mesa/Cedar [2] Or before Multics and UNIX were even born, the work done in Burroughs B5000. [3] There are plenty more examples, one just needs to dive into the history of computing. [0] - http://www-spin.cs.washington.edu/ http://www-spin.cs.washington.edu/ [1] - http://www.projectoberon.com/ http://www.projectoberon.com/ [2] - https://archive.org/details/bitsavers_xerox https://archive.org/details/bitsavers_xerox [3] - http://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...

vertex-four 10y ago
Absolutely, there's been various approaches researched in the past - and I've used Oberon before, really enjoyed it - I'm just curious as to why it doesn't seem to happen any more.
- nickpsecurity 10y ago
  Takes academics being paid to create it basically. Most academics just focus on getting papers published and citations. The number that will try to do useful stuff, esp OS's, are usually a rarity. Btw, here's a few: Active development with strong features: https://www.genode.org https://www.genode.org http://www.minix3.org/ http://www.minix3.org/ http://redox-os.org/ http://redox-os.org/ http://www4.cs.fau.de/Projects/JX/index.html http://www4.cs.fau.de/Projects/JX/index.html Older, less active, or inactive but still interesting http://www.xtreemos.eu/about/about-xtreemos/ http://www.xtreemos.eu/about/about-xtreemos/ https://sourceforge.net/projects/a2oberon/files/ https://sourceforge.net/projects/a2oberon/files/ http://www.eros-os.org/ http://www.eros-os.org/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheribsd.html https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri... http://fsd-amoeba.sourceforge.net/ http://fsd-amoeba.sourceforge.net/ So, there you go. THey don't all do what you describe. Some cool stuff worth emulating or building on in the pages above. Especially EROS or A2 Bluebottle for security and ease-of-picking-up respectively.
- signa11 10y ago

steveklabnik 10y ago

one issue is that it can take a long time to get to just that point, and so doing further, more interesting research comes after you've already done a ton of hacking.

anta40 10y ago

Have you tried MenuetOS, for example? It does have a quite nice UI, TCP/IP support, etc And without any attempt to be 'yet another UNIX clone', I think.

danieljh 10y ago

> where's all the actual OS research? Where's the service-oriented OS built on capabilities with a typed object store for a filesystem? Once you realize there's not much a difference between Microkernels are the recent microservices architectures, they become interesting again. Then you might want to look in recent advances such as Unikernels or Anykernels. Here's a good start summarizing lessons in Microkernels learned in the last decades: http://dl.acm.org/citation.cfm?id=2522720 http://dl.acm.org/citation.cfm?id=2522720

ArkyBeagle 10y ago

Perhaps there's something I'm missing but for the last two on your list there's no reason to build a full on O/S. "A service" these days means "something that lives on a TCP or UDP port" and URL means HTTP or HTTPD. I've built a couple or three microkernels[1] to use for real work, and it's just not interesting past a certain point. Once you get the equivalent of the Linux ucontext.h stuff done the rest is ... stamp collecting. [1] one back in the dark ages on top of DOS to enable getting a project rolling in parallel with the hardware, another specifically for providing sandboxed services on top of an existing RTOS, mainly to pretend this was a different computer/virtual machine, again as leverage because of schedule. These days, you would put up a hypervisor or just use a COTS virtual machine. I keep hoping something will be done with BeOS but ...

vertex-four 10y ago
> there's no reason to build a full on O/S. While there might be no reason to build a kernel - most modern ones will let you lock down a process well enough, although it "looks weird" - building good UX around capabilities and objects instead of permissions and files requires starting from the ground up. The vast majority of applications, tools, and workflows that people use right now don't fit within that paradigm. > "A service" these days means "something that lives on a TCP or UDP port" and URL means HTTP or HTTPD. A service consists of an administration protocol and a usage protocol. In Linux, the administration protocol is usually some ad-hoc text format and SIGHUP, in Windows it's Powershell, and the usage protocol is almost always ad-hoc over TCP, requiring a library to interact with it. It's possible to abstract services away from how you communicate with them, provided that you're working within an environment where everyone buys into that abstraction. Communicating with a file on your desktop, a file on a file server, a database server, and your coworker's spreadsheet window all become something you can do without having to find the relevant library which speaks the right protocol, or have ad-hoc mechanisms for sharing each of these things over a network - the relevant services self-describe how to communicate with them, in the same way that you can connect Powershell to an Exchange server and have all the tools for managing Exchange without installing anything. You get to do away with SSHing into another box with a completely different shell environment, or trying to wrangle your local tools to work over sshfs. You could work on drafting an important email with a coworker as easily as dragging the window into your chat application, with neither the chat application nor the email client having to care how that works - the chat application just needs to be able to transport capabilities, and the window manager needs to be able to create a "window view" capability. You can also start playing with really fancy things like dynamic constraint-based load balancing across a network, once your services don't care about how they're communicating with each other or where they are - where services get farmed out onto the network automatically when you perform resource-intensive tasks. Plan 9 gets some of the way there, although I believe a filesystem is not discoverable enough - can I reliably get a lightweight IDE to tell me what "echo swap > /dev/mouse" does, vs "mouse.swapButtons()" where mouse is a typed variable? There's also no formalized way of doing request/response (especially out-of-order), and accessing a certain field of a message requires ad-hoc string parsing which is easy to get wrong. This needs to be done as an operating system - a complete set of tools which enables a certain way of managing and interacting with resources, both as a developer and a user - because otherwise you keep hitting on the boundary of things you can interact with within the system and things you need to interact with outside the system. If you can interact with your text editor and chat application but not your spreadsheet tool or database server this way, that diminishes its use significantly. I've been playing with minimal systems which do some of this. It's interesting, but hard work to build entire new user experiences from scratch instead of being able to port a libc to a new kernel and get a bunch of stuff for free.