On Friday 14. September 2018 05.58.09 Andrew Warkentin wrote:
Yes, I guess that would work, but you still have the problem of a rather complex language runtime being part of the TCB, which you don't get with an OS based on safer native code.
I am very fond of dynamic languages which usually their own runtimes, but I would also be somewhat wary of deploying some of these runtimes in any kind of privileged role. (I don't know if that is what is being suggested, not having digested every word of this discussion - sorry!)
As I recall, there are just-in-time compilers being used in the Linux kernel, maybe in the network firewall/rules functionality, and it is possible that this has already caused security problems. Of course, there are so many sources of such problems that it might be mean-spirited to single out just one of them.
Developers probably aren't going to port to (or completely rewrite for in the case of non-.NET languages) some obscure alternative OS.
I see that nobody (prominently) mentioned JX whose documentation was quite approachable, I thought:
https://en.wikipedia.org/wiki/JX_(operating_system)
But one of the lessons from the phenomenon of Java is that people don't like to be told to rewrite all their stuff in a particular language, and although you can try and make the runtime language-neutral, some languages end up being more equal than others.
They'll just say "oh, it runs Linux applications, so our Linux port is good enough", and users will probably pass it over because there will be few native applications, and Linux applications will be second-class citizens (unless you actually manage to integrate Linux applications and allow them to take advantage of your OS's advanced features, but that sounds like it might be tricky in a non-Unix-like language-based OS).
It is interesting to consider Nemesis, which evolved into Xen, in this regard:
https://en.wikipedia.org/wiki/Nemesis_(operating_system)
One of the goals was to support POSIX applications, and it was apparently a usable system in its day, maybe still is.
An advanced Unix-like OS would have a much easier time integrating Linux applications (even in its native environment, UX/RT will implement Linux-specific APIs where it makes sense to do so, and its Linux binary compatibility layer will be more or less transparent, allowing Linux programs to integrate reasonably well with the rest of the OS and take advantage of many of its advanced features).
It is also interesting to see the UX/RT label given the heritage of Unix systems:
https://en.wikipedia.org/wiki/Multi-Environment_Real-Time
In the L4 microkernel-related materials I have seen, nobody seems to mention this work or even the foundational influences on it. Indeed, one set of slides calls the Mach microkernel "The mother of all microkernels", later to discuss IBM Workplace OS and to note that "OS personalities did not work". Presumably such remarks are made in that specific context given that DMERT apparently supported multiple personalities (Unix-RTR and RSX-11).
However, if you're writing your OS for some reason other than practical real-world usage, then I guess compatibility doesn't matter as much.
Who is to say that an incompatible system does not have "practical real-world usage", though? I agree that compatibility would be helpful, and there are plenty of systems that exist only through the perseverence of their creators, only to fade away at some point, partly due to a lack of interest and difficulties integrating mainstream software.
Personally, I am also interested in what it would take to develop a vaguely standard multiserver system, albeit leveraging L4 technologies. A while back, people tried to get the Hurd working on L4 (Pistachio, I think), and I think there is potential to get something like that going on Fiasco.OC, particularly since the lack of capability support was supposedly the reason why the Hurd-L4 work was abandoned.
On that note, since documentation was discussed at the start of this thread, I should note that for Fiasco.OC, things like the register usage employed in IPC appears different from certain specifications. So, for example, the L4 X.2 (revision 6) and V2/MIPS specifications differ from what Fiasco.OC uses, defined here in the sources:
pkg/l4re-core/l4sys/include/ARCH-mips/L4API-l4f/ipc.h
Obviously, I'm only focusing on MIPS for various reasons. Maybe there is similar documentation describing these interfaces and a particular specification that Fiasco.OC implements, but I didn't find it.
Paul