HelenOS: a microkernel-based, multiserver OS from scratch(helenos.org)
helenos.org
HelenOS: a microkernel-based, multiserver OS from scratch
http://www.helenos.org/
15 comments
Ok, we've changed the URL from https://github.com/HelenOS/helenos to the project homepage. There's a link to the FAQ from there. Thanks!
I've tried quite some alternative OSes in local qemu VMs.
HelenOS was one of the few that actually worked.
It feels very snappy. Seems also quite robust. I didn't manage to crash it just by playing around, like it's the cases with most other "toy OSes".
One of the most "promising" OS projects out there, imho. (Promising in the sense that it seems to be at least a serous project with constant progress since many years already).
HelenOS was one of the few that actually worked.
It feels very snappy. Seems also quite robust. I didn't manage to crash it just by playing around, like it's the cases with most other "toy OSes".
One of the most "promising" OS projects out there, imho. (Promising in the sense that it seems to be at least a serous project with constant progress since many years already).
How did it compare to, say, Serenity and Haiku?
Serenity is still on the list of things I need to try out. Can't say anything about it at the moment.
But I have to admit that regardless the hype around it I don't think that it's particularly interesting. I see it as just yet another Unix clone; with exactly zero innovation behind it. Even Redox, which I consider being a complete failure, tried some seemingly new concepts (and uses a micro kernel which makes it at least a little bit less "mainstream").
Haiku is rock solid. Very interesting project! But I would not put it in the basket with toy or research OSes, though. It's based on something that had even quite some commercial success. But yes, Haiku is definitely an "alternative OS". It would have been better if I worded this part differently, I guess, as I'm mostly interested in "experimental" OS architectures and less in "random" alternative OSes. (So, for example I've never tried to run TempleOS, or such things; also I didn't put much effort to run historic ones, when they where just Unix clones; there are quite some of these out there I guess).
Haiku is much more complete than HelenOS of course. You can do all the basic computer things with it. It has quite some applications. I still remember the time when BeOS, its successor, was actually even much more usable in a GUI setting than Linux, which barely run X and some fvwm2 windows with terminal emulators—whereas BeOS had fancy multi-media players and 3D graphics at that time. Haiku has this apps still, but that's much less impressive today of course.
Haiku is for example much more polished than say Hurd. There is a "working" Debian/Hurd version out there. But it was so buggy last time I've tried! Things were constantly crashing or not working at all. The last time I've tried to run Haiku I didn't find anything that was servery broken there.
HelenOS feels comparable stable to Haiku. But there is almost nothing besides the bare OS. I think it had a kind of "packet manager" the last time I've tried but this didn't work well for me. Also there were almost no applications available. But that's not a bad sign as I think the most work goes into the OS as such. Which is good! The few things that were there on the surface were like I've said snappy and working without crashes. Which is imho already an achievement when compared with a lot of other OS projects (e.g. Redox, Hurd, unikernel / library-OSes, or just a "tuned" Linux build ;-)).
But I have to admit that regardless the hype around it I don't think that it's particularly interesting. I see it as just yet another Unix clone; with exactly zero innovation behind it. Even Redox, which I consider being a complete failure, tried some seemingly new concepts (and uses a micro kernel which makes it at least a little bit less "mainstream").
Haiku is rock solid. Very interesting project! But I would not put it in the basket with toy or research OSes, though. It's based on something that had even quite some commercial success. But yes, Haiku is definitely an "alternative OS". It would have been better if I worded this part differently, I guess, as I'm mostly interested in "experimental" OS architectures and less in "random" alternative OSes. (So, for example I've never tried to run TempleOS, or such things; also I didn't put much effort to run historic ones, when they where just Unix clones; there are quite some of these out there I guess).
Haiku is much more complete than HelenOS of course. You can do all the basic computer things with it. It has quite some applications. I still remember the time when BeOS, its successor, was actually even much more usable in a GUI setting than Linux, which barely run X and some fvwm2 windows with terminal emulators—whereas BeOS had fancy multi-media players and 3D graphics at that time. Haiku has this apps still, but that's much less impressive today of course.
Haiku is for example much more polished than say Hurd. There is a "working" Debian/Hurd version out there. But it was so buggy last time I've tried! Things were constantly crashing or not working at all. The last time I've tried to run Haiku I didn't find anything that was servery broken there.
HelenOS feels comparable stable to Haiku. But there is almost nothing besides the bare OS. I think it had a kind of "packet manager" the last time I've tried but this didn't work well for me. Also there were almost no applications available. But that's not a bad sign as I think the most work goes into the OS as such. Which is good! The few things that were there on the surface were like I've said snappy and working without crashes. Which is imho already an achievement when compared with a lot of other OS projects (e.g. Redox, Hurd, unikernel / library-OSes, or just a "tuned" Linux build ;-)).
>> I still remember the time when BeOS, its successor...
English is not my native tongue but didn't you mean "BeOS, its predecessor" ?
BeOS lived from 1995 to 2001, and Haiku development started in 2001 with a first release in 2009.
https://en.wikipedia.org/wiki/Haiku_(operating_system)#Relea...
English is not my native tongue but didn't you mean "BeOS, its predecessor" ?
BeOS lived from 1995 to 2001, and Haiku development started in 2001 with a first release in 2009.
https://en.wikipedia.org/wiki/Haiku_(operating_system)#Relea...
Oh, yes, of course!
I'm also not a native speaker…
I've expanded on my initial version and didn't double check the lengthy edit with some translation service because I didn't want to miss the edit window.
But I guess the oversight should be clear form context. Can't edit it anyway.
Thanks for pointing out this mistake! :-) (Now I'm going to check this particular word pair more thoroughly next time).
I'm also not a native speaker…
I've expanded on my initial version and didn't double check the lengthy edit with some translation service because I didn't want to miss the edit window.
But I guess the oversight should be clear form context. Can't edit it anyway.
Thanks for pointing out this mistake! :-) (Now I'm going to check this particular word pair more thoroughly next time).
SerenityOS is interesting because of its monolithic repository concept with everything from the kernel to the web browser as a single unified project. They even write their own image and video codecs and stuff like TLS and OpenGL that everybody just lifts from somewhere else.
I would say that creating their own language to write the system in is pretty innovative. The power of the mono repo is really going to come through when they convert everything from C++ to Jakt.
Perhaps the most impressive and innovative thing about SerenityOS is the way they are building their community though. I cannot think of another project with so many contributors developing so openly on YouTube. The rate at which the project is evolving is amazing.
The SerenityOS project is extremely pragmatic so it is not going to charge off in truly experimental directions. That said, they borrow an impressive number of ideas from a fairly diverse set of influences. The pledge / unveil stuff from OpenBSD is interesting. The way they propagate errors throughout the stack is cool, and the fact that they built their own standard library for C++ is quite interesting.
One area where SerenityOS may truly innovate is in the browser since the project founder used to build web browser engines for a living.
If you do not think SerenityOS is interesting, maybe take a deeper look.
I would say that creating their own language to write the system in is pretty innovative. The power of the mono repo is really going to come through when they convert everything from C++ to Jakt.
Perhaps the most impressive and innovative thing about SerenityOS is the way they are building their community though. I cannot think of another project with so many contributors developing so openly on YouTube. The rate at which the project is evolving is amazing.
The SerenityOS project is extremely pragmatic so it is not going to charge off in truly experimental directions. That said, they borrow an impressive number of ideas from a fairly diverse set of influences. The pledge / unveil stuff from OpenBSD is interesting. The way they propagate errors throughout the stack is cool, and the fact that they built their own standard library for C++ is quite interesting.
One area where SerenityOS may truly innovate is in the browser since the project founder used to build web browser engines for a living.
If you do not think SerenityOS is interesting, maybe take a deeper look.
Sorry to be so direct but exactly the things on which you expanded here are a very large part of my deep skepticism about SerenityOS.
All that NIH without improving anything on the status quo is imho pure insanity!
But OK, the project is mainly meant as a "therapy" for some mental illness, so this "makes sense" actually… (Just coding without thinking or carrying is quite some fun and liberating, indeed!)
Besides the crazy amount of NIH the rate at which this project evolves is another very bad sign. (Reminds me strongly of "80% boy & his Redux OS"…). If you rush everything there is no time for planing or evaluating ideas. OTOH this is of course not needed if you do not intend to innovate on anything—and just rebuild once more things that already been built hundreds of times.
I think alone scope creep will be deadly to this projects in the long run. For example one of the strongest reasons for Linux's success is imho that Linux concentrated solely on the OS. Where you end up when you want to do everything at once (especially without any research projects backing that effort!) at least I'm quite sure to know.
Alone building a serous programming language is a life's work! (But OK, once again, Jakt isn't serous. It's not going to be even competitive with Carbon, as I see it, which itself isn't of any interests at all besides "Google is selling" it. Jakt is just the next fun NIH project, "because we can").
Regarding the community: Well, this dude attracted quite some attention with his personal life story. People seem to feel compassionate about him. So there is a lot of momentum. And sure, he's a nice guy. Only that he's quite off to when it comes to what he's producing. (Which is once again a very good prove of the fact that social circumstances have much more weight than any technological considerations; people care in the end about people, never really about the tech).
Bottom line: I came to my conclusions about SerenityOS because I've looked at it.
I try hard to not have any opinions on things I don't at all know about.
All that NIH without improving anything on the status quo is imho pure insanity!
But OK, the project is mainly meant as a "therapy" for some mental illness, so this "makes sense" actually… (Just coding without thinking or carrying is quite some fun and liberating, indeed!)
Besides the crazy amount of NIH the rate at which this project evolves is another very bad sign. (Reminds me strongly of "80% boy & his Redux OS"…). If you rush everything there is no time for planing or evaluating ideas. OTOH this is of course not needed if you do not intend to innovate on anything—and just rebuild once more things that already been built hundreds of times.
I think alone scope creep will be deadly to this projects in the long run. For example one of the strongest reasons for Linux's success is imho that Linux concentrated solely on the OS. Where you end up when you want to do everything at once (especially without any research projects backing that effort!) at least I'm quite sure to know.
Alone building a serous programming language is a life's work! (But OK, once again, Jakt isn't serous. It's not going to be even competitive with Carbon, as I see it, which itself isn't of any interests at all besides "Google is selling" it. Jakt is just the next fun NIH project, "because we can").
Regarding the community: Well, this dude attracted quite some attention with his personal life story. People seem to feel compassionate about him. So there is a lot of momentum. And sure, he's a nice guy. Only that he's quite off to when it comes to what he's producing. (Which is once again a very good prove of the fact that social circumstances have much more weight than any technological considerations; people care in the end about people, never really about the tech).
Bottom line: I came to my conclusions about SerenityOS because I've looked at it.
I try hard to not have any opinions on things I don't at all know about.
This sounds very much like the Tannenbaum ( sp? ) vs Torvalds argument all over again.
GNU scoffed at Linux as you do SerenityOS but where is HURD? Even BSD was better than Linux technically. So, why did Linux win?
Obviously I have no desire to argue you out of your opinion. For somebody that is claiming the technical high ground however, I find it notable that you went straight for the emotional angle.
You and I clearly disagree about what drives progress in the world. I think Linux changed the world because it ignored the argument that it was pointless and offered nothing new. The joke is that Linus did not expect to build “anything big and professional”.
There is nothing else like SerenityOS. If it succeeds, it will be a new status quo. There is no guarantee at all that it will be successful but an engaged and growing community may be the most important element. How many active contributors does HelenOS have. Where will it be in 4 years?
The one “engineering” argument I will make though is that the mono repo idea is not driven by NIH in the way that you imply. Your core point is that SerenityOS is too derivative and steals too shamelessly from everybody else. The project founder has stated multiple times that the motivation for a mono repo is the reduced complicity, greater agility, and velocity that it brings. The Linux ecosystem is characterized by massive complexity and massive dependency. Innovating in Linux is more politics than technology a lot of the time. Think Wayland, Systemd, GUI toolkits, or many other areas where progress has been slow and fractured for years. SerenityOS can change whatever it wants in the core ecosystem. Of course, not everything is in the core ecosystem. The project has a large and growing ports collection that they celebrate. They just do not want to depend on it. That idea is quite novel if you ask me. Given the progress in the last 4 years, they may be on to something.
Oh, and I cannot resist one emotionally technical argument. Carbon is going nowhere. Time will tell but I am happy to have that on my score card.
GNU scoffed at Linux as you do SerenityOS but where is HURD? Even BSD was better than Linux technically. So, why did Linux win?
Obviously I have no desire to argue you out of your opinion. For somebody that is claiming the technical high ground however, I find it notable that you went straight for the emotional angle.
You and I clearly disagree about what drives progress in the world. I think Linux changed the world because it ignored the argument that it was pointless and offered nothing new. The joke is that Linus did not expect to build “anything big and professional”.
There is nothing else like SerenityOS. If it succeeds, it will be a new status quo. There is no guarantee at all that it will be successful but an engaged and growing community may be the most important element. How many active contributors does HelenOS have. Where will it be in 4 years?
The one “engineering” argument I will make though is that the mono repo idea is not driven by NIH in the way that you imply. Your core point is that SerenityOS is too derivative and steals too shamelessly from everybody else. The project founder has stated multiple times that the motivation for a mono repo is the reduced complicity, greater agility, and velocity that it brings. The Linux ecosystem is characterized by massive complexity and massive dependency. Innovating in Linux is more politics than technology a lot of the time. Think Wayland, Systemd, GUI toolkits, or many other areas where progress has been slow and fractured for years. SerenityOS can change whatever it wants in the core ecosystem. Of course, not everything is in the core ecosystem. The project has a large and growing ports collection that they celebrate. They just do not want to depend on it. That idea is quite novel if you ask me. Given the progress in the last 4 years, they may be on to something.
Oh, and I cannot resist one emotionally technical argument. Carbon is going nowhere. Time will tell but I am happy to have that on my score card.
FWIW, Tannenbaum considers himself vindicated after it was revealed that MINIX was buried in every Intel processor.
> Even BSD was better than Linux technically.
Was it? It's just one Unix clone over the other. This "shadowboxing" is going on since inception of time (I mean, Unix epoch).
> I find it notable that you went straight for the emotional angle.
It is a result of my impression that there is just nothing on the technical ground that is worth investigating.
The whole project builds up on emotions. What else is there to say?
> I think Linux changed the world […]
Did it? It just prolonged the eternal rule of Unix, imho.
Linux, in some sense, freezed the long standing status quo in time… (Which is btw. part of my "no progress" argument).
> There is nothing else like SerenityOS.
I would say there were already quite of those projects.
Nothing else is more popular than building Unix clones! It's a special feature when a system is not a Unix clone. Not the other way around.
> Your core point is that SerenityOS is too derivative and steals too shamelessly from everybody else.
No, that's not my argument.
It's more that SerenityOS does not add anything new, or even mildly interesting. It's technologically stuck far back in the 70's, like almost all Unix clones.
Even Google, know for their "boring tech" mantra, arrived in the late 80's with their Fuchsia OS.
Actually also MS does have more modern concepts stashed in the drawer. But SerenityOS? No, nothing there.
The point is: When you're anyway rebuilding the world this would be the perfect chance to bring some innovation. Stuff that's laying around in academia for 30 - 50 years, where the main reason imho for not using it is the necessity to rebuild too much things form scratch. Now someone started to rebuild things form scratch. And what? Again the exact same stuff that we have already for 50 years… That's more than disappointing!
But I understand: Trying to be innovative has a high risk of failure and it's at times quite likely going to be frustrating. But the person behind this project wanted some fun distraction. A "game" where he knows for sure that he will win eventually (in the sense of getting something up and running). The reason for this undertaking is that such a "game" is stress relieving and distracting from otherwise hard times.
> Innovating in Linux is more politics than technology […]
I would generalize this to "Innovating is in reality always more politics than technology".
And because everything's a people and economical problem real technological (or also scientific) progress is so hard. It's hard to convince people about new ideas. It's hard to find founding for them.
Having something that will quite likely "succeed" (according to a very narrow and / or shallow definition of success usually) is on the other hand an easy sell.
When you're able to present some shiny stuff (especially quickly) that will attract people.
When then again you come with some "abstract nonsense" and some weird ideas nobody ever tried before it's a very hard sell. (You know, "exceptional claims …" and such).
> SerenityOS can change whatever it wants in the core ecosystem.
One could see this in the opposite way also: Nobody can change there anything without approval form the BDFL, or a complete fork of everything.
That works not even 100% proper for Linux, though it works mostly fine there. But it works mostly fine because of the much narrower scope of Linux.
When you have instead just everything in one place there is not much room for anything that could diverge. Which is in the long run a killer to any substantial change. Ever heard the story that Google's not able to update anything in its core anymore because everything depends on everything?
Also there was a project that was not much different than SerenityOS: Redox OS. It was highly hyped in the beginning. It also tried to rewrite the world. It also was an extreme example of NIH syndrome. (The only difference being that I suspect that the Serenity dude is much more skilled than Redox's "80%-boy"). Where is it now? It had at least some promise of slight innovation (Rust, micro kernel, some nonsense around URLs, etc.). SerenityOS doesn't even have that.
> Carbon is going nowhere. Time will tell but I am happy to have that on my score card.
I'm not sure I really understand.
If you're saying that it's not more than a temporal blib in the blogoshere I would fully agree!
I also don't see it going anywhere.
Actually for the same reasons like SerenityOS: It does not offer anything special that could justify its existence. I would even put higher bets on CPP2 (even though I'm skeptical there also, but for other reasons; don't see enough traction there).
Was it? It's just one Unix clone over the other. This "shadowboxing" is going on since inception of time (I mean, Unix epoch).
> I find it notable that you went straight for the emotional angle.
It is a result of my impression that there is just nothing on the technical ground that is worth investigating.
The whole project builds up on emotions. What else is there to say?
> I think Linux changed the world […]
Did it? It just prolonged the eternal rule of Unix, imho.
Linux, in some sense, freezed the long standing status quo in time… (Which is btw. part of my "no progress" argument).
> There is nothing else like SerenityOS.
I would say there were already quite of those projects.
Nothing else is more popular than building Unix clones! It's a special feature when a system is not a Unix clone. Not the other way around.
> Your core point is that SerenityOS is too derivative and steals too shamelessly from everybody else.
No, that's not my argument.
It's more that SerenityOS does not add anything new, or even mildly interesting. It's technologically stuck far back in the 70's, like almost all Unix clones.
Even Google, know for their "boring tech" mantra, arrived in the late 80's with their Fuchsia OS.
Actually also MS does have more modern concepts stashed in the drawer. But SerenityOS? No, nothing there.
The point is: When you're anyway rebuilding the world this would be the perfect chance to bring some innovation. Stuff that's laying around in academia for 30 - 50 years, where the main reason imho for not using it is the necessity to rebuild too much things form scratch. Now someone started to rebuild things form scratch. And what? Again the exact same stuff that we have already for 50 years… That's more than disappointing!
But I understand: Trying to be innovative has a high risk of failure and it's at times quite likely going to be frustrating. But the person behind this project wanted some fun distraction. A "game" where he knows for sure that he will win eventually (in the sense of getting something up and running). The reason for this undertaking is that such a "game" is stress relieving and distracting from otherwise hard times.
> Innovating in Linux is more politics than technology […]
I would generalize this to "Innovating is in reality always more politics than technology".
And because everything's a people and economical problem real technological (or also scientific) progress is so hard. It's hard to convince people about new ideas. It's hard to find founding for them.
Having something that will quite likely "succeed" (according to a very narrow and / or shallow definition of success usually) is on the other hand an easy sell.
When you're able to present some shiny stuff (especially quickly) that will attract people.
When then again you come with some "abstract nonsense" and some weird ideas nobody ever tried before it's a very hard sell. (You know, "exceptional claims …" and such).
> SerenityOS can change whatever it wants in the core ecosystem.
One could see this in the opposite way also: Nobody can change there anything without approval form the BDFL, or a complete fork of everything.
That works not even 100% proper for Linux, though it works mostly fine there. But it works mostly fine because of the much narrower scope of Linux.
When you have instead just everything in one place there is not much room for anything that could diverge. Which is in the long run a killer to any substantial change. Ever heard the story that Google's not able to update anything in its core anymore because everything depends on everything?
Also there was a project that was not much different than SerenityOS: Redox OS. It was highly hyped in the beginning. It also tried to rewrite the world. It also was an extreme example of NIH syndrome. (The only difference being that I suspect that the Serenity dude is much more skilled than Redox's "80%-boy"). Where is it now? It had at least some promise of slight innovation (Rust, micro kernel, some nonsense around URLs, etc.). SerenityOS doesn't even have that.
> Carbon is going nowhere. Time will tell but I am happy to have that on my score card.
I'm not sure I really understand.
If you're saying that it's not more than a temporal blib in the blogoshere I would fully agree!
I also don't see it going anywhere.
Actually for the same reasons like SerenityOS: It does not offer anything special that could justify its existence. I would even put higher bets on CPP2 (even though I'm skeptical there also, but for other reasons; don't see enough traction there).
Thank you for the reply. Truly. To get further into this we would need something more conducive than the comment section.
I wish I understood why you see Redox and SerenityOS as so similar ( other than POSIX of course ). I love Redox but it seems to have very different ambitions and choosing Rust felt like its biggest decision. In terms of innovation, the Redox filesystem seemed to be swinging for the fences the most. The filesystem is the one area that SerenityOS has shown very little interest. I hope Redox is not dead ( though it does “feel” slower ). It would be nice if Relibc got some traction outside of the Redox project as well.
To repeat one point, the hope I have for the mono repo is precisely that it will protect the project from getting trapped in technical stasis and frozen in a wasteland of dependencies. If SerenityOS gets popular, it could be exactly the vehicle for taking some of those academic ideas you cite out of the lab and into the real world. If it is to do this, becoming popular first is why it may succeed where decades of projects have failed. SerenityOS made a change not that long ago which altered what is returned by “main”. The mono repo made that possible.
Oh, and I am not sure Andreas has set himself up as the BDFL. SerenityOS has substantial chunks that have been added without him and I am believe there are already at least a few areas that he does not even have to approve or review. SerenityOS has its own Linus for example and I am pretty sure he can check-in without Andreas now.
Anyway, thank you for the back and forth and I hope you see an OS emerge that interests you. I hear what you are saying.
I wish I understood why you see Redox and SerenityOS as so similar ( other than POSIX of course ). I love Redox but it seems to have very different ambitions and choosing Rust felt like its biggest decision. In terms of innovation, the Redox filesystem seemed to be swinging for the fences the most. The filesystem is the one area that SerenityOS has shown very little interest. I hope Redox is not dead ( though it does “feel” slower ). It would be nice if Relibc got some traction outside of the Redox project as well.
To repeat one point, the hope I have for the mono repo is precisely that it will protect the project from getting trapped in technical stasis and frozen in a wasteland of dependencies. If SerenityOS gets popular, it could be exactly the vehicle for taking some of those academic ideas you cite out of the lab and into the real world. If it is to do this, becoming popular first is why it may succeed where decades of projects have failed. SerenityOS made a change not that long ago which altered what is returned by “main”. The mono repo made that possible.
Oh, and I am not sure Andreas has set himself up as the BDFL. SerenityOS has substantial chunks that have been added without him and I am believe there are already at least a few areas that he does not even have to approve or review. SerenityOS has its own Linus for example and I am pretty sure he can check-in without Andreas now.
Anyway, thank you for the back and forth and I hope you see an OS emerge that interests you. I hear what you are saying.
>It does not offer anything special that could justify its existence.
I am sure there are ideas they're trying out in there.
Doing so in a known framework (unix-like system) means they're not trying too many things at once, which produces better research.
Still, I wish they'd went the microkernel multiserver route like Managarm.
I am sure there are ideas they're trying out in there.
Doing so in a known framework (unix-like system) means they're not trying too many things at once, which produces better research.
Still, I wish they'd went the microkernel multiserver route like Managarm.
So far they have been quite clear that there is no plan on converting everything into Jakt, because they are quite pragmantic about their need to keep using C++ in some parts.
They have been clear that they are not even writing anything new in Jakt because it is not ready yet. If you start seeing them wrote stuff in it, you will see them re-wrote stuff too.
They can make the change whenever they want because of the mono repo. You can make changes all across the project on any given check-in.
As you said, it is a very pragmatic project.
They can make the change whenever they want because of the mono repo. You can make changes all across the project on any given check-in.
As you said, it is a very pragmatic project.
I'm kind of biased towards hypothetical OS'es built from the ground up in a memory-safe system language like Rust (assuming one exists, which I'm not sure). All you have to do is look at the litany of security holes of the past decade or 2 to see how often a lack of memory safety led to a security bug. Do you know of one?
SerenityOS isn't a memory safe OS. That's for sure. No innovation here…
But anyway, there are not much safe OSes out there I guess.
There are all the Rust experiments (with usually a shitload of `unsafe` code in there).
There was the Midori experiment by MS (no clue whether there is source code available).
There have been Java based OSes.
But all in all, there doesn't seem to be anything that has got any traction.
But anyway, there are not much safe OSes out there I guess.
There are all the Rust experiments (with usually a shitload of `unsafe` code in there).
There was the Midori experiment by MS (no clue whether there is source code available).
There have been Java based OSes.
But all in all, there doesn't seem to be anything that has got any traction.
Go have a blast with Genode[0] and Managarm[1].
0. https://www.genode.org
1. https://managarm.org/
0. https://www.genode.org
1. https://managarm.org/
Could you expand on why you think Redox is a failure? Maybe also what you think it got right and what it got wrong?
> But I have to admit that regardless the hype around it I don't think that it's particularly interesting. I see it as just yet another Unix clone; with exactly zero innovation behind it.
I personally think the syscall structure is quite interesting, especially the pledge & unveil taken from BSD. But that is indeed not innovative, it is just taking some really nice ideas from prior art.
I personally think the syscall structure is quite interesting, especially the pledge & unveil taken from BSD. But that is indeed not innovative, it is just taking some really nice ideas from prior art.
What is the status of any GUI toolkit on it? Can you run things like Bash and the rest of the Linux toolchain (this might depend on glibc being ported?)?
Related:
HelenOS 0.8 - https://news.ycombinator.com/item?id=18833124 - Jan 2019 (55 comments)
HelenOS: portable microkernel-based multiserver operating system - https://news.ycombinator.com/item?id=15046249 - Aug 2017 (67 comments)
HelenOS 0.8 - https://news.ycombinator.com/item?id=18833124 - Jan 2019 (55 comments)
HelenOS: portable microkernel-based multiserver operating system - https://news.ycombinator.com/item?id=15046249 - Aug 2017 (67 comments)
Thanks! also this one I guess:
HelenOS GUI – experimental demonstration (2012) - https://news.ycombinator.com/item?id=12784350 - Oct 2016 (12 comments)
p.s. nice formatting. (I want to add software to offer to inline HN links in this format when people include links to past threads in their comments.)
HelenOS GUI – experimental demonstration (2012) - https://news.ycombinator.com/item?id=12784350 - Oct 2016 (12 comments)
p.s. nice formatting. (I want to add software to offer to inline HN links in this format when people include links to past threads in their comments.)
Thanks, doing it by hand is a little bit tedious, I gave some thought to knocking something together that input a group of ids/URLs and spat out a formatted comment (like, presumably, you have). But then this stopped me.
https://xkcd.com/974
https://xkcd.com/974
https://github.com/plibither8/refined-hacker-news
Install this and than look at the bottom of the page. :-D
Install this and than look at the bottom of the page. :-D
Wow multiserver, so it would seamlessly distribute tasks to different servers? That's really cool if I understand it correctly.
No.
“Multiserver” (a term from the microkernel literature) means that the conventional basic OS services are split into several “server” processes with distinct responsibilities (a mounted filesystem, a network card, perhaps a hardware bus, etc.). This is the original conception of a microkernel- (as opposed to e.g. an exokernel-) style system and its architectural promise, although it’s not made necessary by the mere fact of being built on top of a microkernel: AFAIK L4Linux is a single server so the L4 microkernel basically acts as a simple VMM / HAL without further architectural benefits. (For other monolithic but userspace OS servers, look at wineserver in Linux, CSRSS and LXSS in Windows NT, etc. For multiserver systems of varying purity, look at QNX and Minix.)
What you’re thinking of is a “distributed OS”, although those academic efforts look terribly naïve from today’s distributed consensus standpoint. Good points of entry may be Barrelfish and Plan 9.
“Multiserver” (a term from the microkernel literature) means that the conventional basic OS services are split into several “server” processes with distinct responsibilities (a mounted filesystem, a network card, perhaps a hardware bus, etc.). This is the original conception of a microkernel- (as opposed to e.g. an exokernel-) style system and its architectural promise, although it’s not made necessary by the mere fact of being built on top of a microkernel: AFAIK L4Linux is a single server so the L4 microkernel basically acts as a simple VMM / HAL without further architectural benefits. (For other monolithic but userspace OS servers, look at wineserver in Linux, CSRSS and LXSS in Windows NT, etc. For multiserver systems of varying purity, look at QNX and Minix.)
What you’re thinking of is a “distributed OS”, although those academic efforts look terribly naïve from today’s distributed consensus standpoint. Good points of entry may be Barrelfish and Plan 9.
Amoeba is a famous example of a distributed OS https://en.wikipedia.org/wiki/Amoeba_(operating_system)
It’s too bad this research didn’t continue. Instead we got a giant tower of kludges including containers, Kubernetes, service meshes, endless API design problems, endless reinventing of data serialization and protocols, and so on.
The academic environment where that research was the thing to do if you wanted to do systems is the academic environment that produced Pike’s “Systems Software Research Is Irrelevant”[1]. It seems to have succumbed to two relatively common afflictions, though I don’t know of another case of both simultaneously:
- Inbreeding of ideas: researchers inventing and solving problems noöne actually has, without observing the discipline necessary to remain interesting and avoid emotional attachments (as is done in maths, with varying success). In the distributed OS case, the model in people’s heads (including Pike’s with Plan 9!) seems to have been a closed campus network, which is close to some of the areas people care now, but still isn’t quite any of them. The social problem of the system not being able to take over the world, thus necessitating explicitly specified protocols and loose coupling, also does not seem to have received much consideration. (Except for Microsoft, who has tried—deliberately or accidentally—to weaponize the homogeneity requirements of some of that research in building Windows domain networking.) Some of the kludges aren’t—they are solving social problems.
- Being before its time: sounds glorious and heroic, in reality makes people cold, lonely, and more often than not broke. The most commonly known instances of this are for individuals (or other actors capable of having a coherent volition, such as companies), but the distributed OS story feels like this happened to the community as a whole.
[1] http://doc.cat-v.org/bell_labs/utah2000/utah2000.html
- Inbreeding of ideas: researchers inventing and solving problems noöne actually has, without observing the discipline necessary to remain interesting and avoid emotional attachments (as is done in maths, with varying success). In the distributed OS case, the model in people’s heads (including Pike’s with Plan 9!) seems to have been a closed campus network, which is close to some of the areas people care now, but still isn’t quite any of them. The social problem of the system not being able to take over the world, thus necessitating explicitly specified protocols and loose coupling, also does not seem to have received much consideration. (Except for Microsoft, who has tried—deliberately or accidentally—to weaponize the homogeneity requirements of some of that research in building Windows domain networking.) Some of the kludges aren’t—they are solving social problems.
- Being before its time: sounds glorious and heroic, in reality makes people cold, lonely, and more often than not broke. The most commonly known instances of this are for individuals (or other actors capable of having a coherent volition, such as companies), but the distributed OS story feels like this happened to the community as a whole.
[1] http://doc.cat-v.org/bell_labs/utah2000/utah2000.html
Great document, thanks for the link.
I think the main issue is actually more related to the trend in academia in which the 'least publishable unit' is ever more important. Pike's essay touches on this. Coming up with an interesting new OS design is hard, and implementing one is worse, so people don't try because it'd take too long and there wouldn't be enough papers in it for anyone. Companies still do OS research (see Singularity and Midori by Microsoft, Fuschia by Google) but don't publish much about it.
The problem is to become sustainable you need users, and to get users you really have to be above the core OS these days because that's where you can focus on concepts instead of getting distracted by kernel and driver writing (not much interesting to do there). If you want to experiment with microkernels, do it as a collection of processes in the Linux userland and if you want to extend that to get users, make it run on Windows too. Chrome is in effect a kind of microkernel-ish operating system, seen from this perspective. It consists of a pile of sandboxed components connected by a sophisticated IPC system called Mojo. It also handles properly cases that microkernel research sometimes ignores or punts to the user, like how to gracefully handle if the other end of a connection crashes.
I feel strongly that there's still lots of interesting research to do in the operating systems space but if I were to do it, I would not start by writing an actual OS. I'd start by exploring the ideas as an set of ordinary programs that could run on a regular OS. Maximize the window and start gradually eliminating dependencies on high level APIs provided by the host, if you really want to. Then you can explore concepts like single address space OS's, ultra-fine-grained microkernels, better shells, polyglot programming, distributed computing etc, without getting bogged down by irrelevant detail.
I think the main issue is actually more related to the trend in academia in which the 'least publishable unit' is ever more important. Pike's essay touches on this. Coming up with an interesting new OS design is hard, and implementing one is worse, so people don't try because it'd take too long and there wouldn't be enough papers in it for anyone. Companies still do OS research (see Singularity and Midori by Microsoft, Fuschia by Google) but don't publish much about it.
The problem is to become sustainable you need users, and to get users you really have to be above the core OS these days because that's where you can focus on concepts instead of getting distracted by kernel and driver writing (not much interesting to do there). If you want to experiment with microkernels, do it as a collection of processes in the Linux userland and if you want to extend that to get users, make it run on Windows too. Chrome is in effect a kind of microkernel-ish operating system, seen from this perspective. It consists of a pile of sandboxed components connected by a sophisticated IPC system called Mojo. It also handles properly cases that microkernel research sometimes ignores or punts to the user, like how to gracefully handle if the other end of a connection crashes.
I feel strongly that there's still lots of interesting research to do in the operating systems space but if I were to do it, I would not start by writing an actual OS. I'd start by exploring the ideas as an set of ordinary programs that could run on a regular OS. Maximize the window and start gradually eliminating dependencies on high level APIs provided by the host, if you really want to. Then you can explore concepts like single address space OS's, ultra-fine-grained microkernels, better shells, polyglot programming, distributed computing etc, without getting bogged down by irrelevant detail.
I think this misses the whole point.
If you want novel computer systems you can't build them on top of the old ones. That's the whole point of Pike.
An OS is the thing in about Linux (kernel) scope. The whole point is that this is something that is by no mean "done". If you want innovation in this space you need to build exactly such a thing from scratch!
But the OS is only one part of systems design. Doing something novel in this area would be to continue where we stopped around 1970. There was no progress since than. Only one computer architecture with only one OS left. Since than nothing truly innovative was even tried. (OK, to be fair, almost nothing. There been things like Intel's iAPX 432, or Microsoft's Midori, or things like the Connection Machine. But mainstream is still on the std. tech form the 70'. Even mainframes are actually technological more advanced, as they had for example multiprocessing, VMs and containers already decades ago).
I for my part think that if we would rethink computers form the ground up in light of today's possibilities they would be very very different. Alone the security hell today is only there because we still want to run "normal C programs". Everybody knows that this is not fixable without throwing away some of the old concepts. Still nobody wants to move. (Almost perfectly secure computers would be possible. You "just" need to build capability security into CPUs, the OS, and all apps…). Or another example: Scaling to many many cores would be much easier if computers would be fully data-flow aware. But currently we like to pretend that our CPUs are still PDP-7s. They need to offer the exact same interface (conceptually) or else this would not match the C abstract machine any more 1:1… But the CPU than needs to use a built in "hardware JIT" to translate the sequential command streams it receives to its internal data-flow operations. Somethings that's extremely inefficient and overly complicated—besides that it conceptually can't even help much. There is only so much parallelism extractable form an inherently sequential description of computation… (The most crazy part about this is that we have plenty information available on the high level which we happy erase during compilation, so we can present a "nice flat command stream" to the CPU. That's imho pure insanity). But nobody dares to rethink such systems as a whole: which means form the languages and their abstract machines, through the concrete hardware, the OS level, up to application design. Things like the von Neumann bottleneck were discussed already almost 50 years ago. The issue remains open to this day. Just put another layer of caches on top. Nobody cares about efficiency anyway… Because rewriting software would be to expensive. So the hardware can't be improved. So software needs to optimize for the old hardware concepts. Which leads to the dead-lock in which we're currently, where no substantial improvement can be made any more.
We're in this trap since 50 years. And that's why systems research is absolutely dead by now.
My 2ct. Sorry for the long post. But I have strong feelings about that topic.
If you want novel computer systems you can't build them on top of the old ones. That's the whole point of Pike.
An OS is the thing in about Linux (kernel) scope. The whole point is that this is something that is by no mean "done". If you want innovation in this space you need to build exactly such a thing from scratch!
But the OS is only one part of systems design. Doing something novel in this area would be to continue where we stopped around 1970. There was no progress since than. Only one computer architecture with only one OS left. Since than nothing truly innovative was even tried. (OK, to be fair, almost nothing. There been things like Intel's iAPX 432, or Microsoft's Midori, or things like the Connection Machine. But mainstream is still on the std. tech form the 70'. Even mainframes are actually technological more advanced, as they had for example multiprocessing, VMs and containers already decades ago).
I for my part think that if we would rethink computers form the ground up in light of today's possibilities they would be very very different. Alone the security hell today is only there because we still want to run "normal C programs". Everybody knows that this is not fixable without throwing away some of the old concepts. Still nobody wants to move. (Almost perfectly secure computers would be possible. You "just" need to build capability security into CPUs, the OS, and all apps…). Or another example: Scaling to many many cores would be much easier if computers would be fully data-flow aware. But currently we like to pretend that our CPUs are still PDP-7s. They need to offer the exact same interface (conceptually) or else this would not match the C abstract machine any more 1:1… But the CPU than needs to use a built in "hardware JIT" to translate the sequential command streams it receives to its internal data-flow operations. Somethings that's extremely inefficient and overly complicated—besides that it conceptually can't even help much. There is only so much parallelism extractable form an inherently sequential description of computation… (The most crazy part about this is that we have plenty information available on the high level which we happy erase during compilation, so we can present a "nice flat command stream" to the CPU. That's imho pure insanity). But nobody dares to rethink such systems as a whole: which means form the languages and their abstract machines, through the concrete hardware, the OS level, up to application design. Things like the von Neumann bottleneck were discussed already almost 50 years ago. The issue remains open to this day. Just put another layer of caches on top. Nobody cares about efficiency anyway… Because rewriting software would be to expensive. So the hardware can't be improved. So software needs to optimize for the old hardware concepts. Which leads to the dead-lock in which we're currently, where no substantial improvement can be made any more.
We're in this trap since 50 years. And that's why systems research is absolutely dead by now.
My 2ct. Sorry for the long post. But I have strong feelings about that topic.
> But the CPU than needs to use a built in "hardware JIT" to translate the sequential command streams it receives to its internal data-flow operations. Somethings that's extremely inefficient and overly complicated—besides that it conceptually can't even help much. There is only so much parallelism extractable form an inherently sequential description of computation… (The most crazy part about this is that we have plenty information available on the high level which we happy erase during compilation, so we can present a "nice flat command stream" to the CPU. That's imho pure insanity).
Nonsense
ca 30 years ago there were (serious!) efforts to fix this on the CPU level - this whole VLIW CPU/smart compiler with explicit parallelism. Intel Itanium, Transmeta, Elbrus to name a few. It didn't work out well.
System research might produce something looking good but not working out well at the end.
Nonsense
ca 30 years ago there were (serious!) efforts to fix this on the CPU level - this whole VLIW CPU/smart compiler with explicit parallelism. Intel Itanium, Transmeta, Elbrus to name a few. It didn't work out well.
System research might produce something looking good but not working out well at the end.
I'm fully aware of the named things.
But I tried already to explain why I think those things failed: It's all about the software.
You can't build a "sufficiently smart compiler" if the task is to parallelize an inherently sequential command stream.
This endeavor failed because it was part of the wrong effort.
The whole point is that people didn't think in terms of systems design any more at this time! They looked on "the hardware problem" in separation.
The expectation was that you can take a program written for "a fast PDP-7" add some "smart compiler" magic on top, and let this run (hopefully) faster on an improved hardware architecture. This didn't work out. Imho to no surprise.
I think the problem lies in the mental model behind computers which dominates the perception is since some time. We're almost exclusively (at least when it comes to general computation) left with the the model of a sequential command stream machine. CPUs execute (interpret) a sequence of instructions. Those instructions may alter an "infinite" (or at least "gigantic enough") global state in arbitrary ways. That's the basic model.
As long as your software is basically written with this model as background you can't "fix this on the hardware level", at least without real magic.
What we no do is to mitigate the problem as best as we can with methods that reached imho completely insane levels.
I think that we could find much better solutions if we would take a step back and rethink the machine in whole. I mean, software hardware co-design is a thing, only not when it comes to general computation especially not together with also OS / runtime (software) design.
My current personal favorite idea how thing could be improved and simplified is to see a computer as a graph of event-stream processors. This mental picture scales nicely on different "zoom levels". From raw hardware to the runtime level to (distributed?) application design. Only that it would require languages that compile down to such a model in an efficient way. A command stream language wouldn't map good or likely even acceptably (same problem as with the old "more exotic" hardware designs).
BTW: For number crunching VLIW and compiler guided parallelism works quite fine. Vector CPUs anybody? That were the fastest computes once, afik. And since MMX up to AVX the whole idea is a big mainstream success. (We're not even talking about GPUs here of course, that's not the topic; nobody tried to replace "typical" CPUs with GPUs so this does not count).
But I tried already to explain why I think those things failed: It's all about the software.
You can't build a "sufficiently smart compiler" if the task is to parallelize an inherently sequential command stream.
This endeavor failed because it was part of the wrong effort.
The whole point is that people didn't think in terms of systems design any more at this time! They looked on "the hardware problem" in separation.
The expectation was that you can take a program written for "a fast PDP-7" add some "smart compiler" magic on top, and let this run (hopefully) faster on an improved hardware architecture. This didn't work out. Imho to no surprise.
I think the problem lies in the mental model behind computers which dominates the perception is since some time. We're almost exclusively (at least when it comes to general computation) left with the the model of a sequential command stream machine. CPUs execute (interpret) a sequence of instructions. Those instructions may alter an "infinite" (or at least "gigantic enough") global state in arbitrary ways. That's the basic model.
As long as your software is basically written with this model as background you can't "fix this on the hardware level", at least without real magic.
What we no do is to mitigate the problem as best as we can with methods that reached imho completely insane levels.
I think that we could find much better solutions if we would take a step back and rethink the machine in whole. I mean, software hardware co-design is a thing, only not when it comes to general computation especially not together with also OS / runtime (software) design.
My current personal favorite idea how thing could be improved and simplified is to see a computer as a graph of event-stream processors. This mental picture scales nicely on different "zoom levels". From raw hardware to the runtime level to (distributed?) application design. Only that it would require languages that compile down to such a model in an efficient way. A command stream language wouldn't map good or likely even acceptably (same problem as with the old "more exotic" hardware designs).
BTW: For number crunching VLIW and compiler guided parallelism works quite fine. Vector CPUs anybody? That were the fastest computes once, afik. And since MMX up to AVX the whole idea is a big mainstream success. (We're not even talking about GPUs here of course, that's not the topic; nobody tried to replace "typical" CPUs with GPUs so this does not count).
"An OS is the thing in about Linux (kernel) scope"
I'm using the standard street definition in which the OS is everything that you get on a fresh (desktop) OS install, not just the kernel.
There's very little research available on kernels because their shape is largely dictated by the hardware design, and the hardware design is largely dictated by physics and what the manufacturers give us. But as you go further up the stack the options widen considerably. You can start to consider user interfaces, application programming models, etc.
"You just need to build capability security into CPUs, the OS, and all apps…"
Pure cap systems are an old idea that have never worked. They're too cumbersome for programmers and affect API design in problematic ways.
But here's the thing. If you disagree, you can go ahead and prove it. You don't need a custom CPU. Figure out the higher level software issues first, and if you ever get to the point of needing actual CPU changes then fork qemu and virtualize your intended design. Make it so custom hardware is just an optimization once the core ideas are worked out.
That's what I mean by doing stuff at a higher layer. The interesting and tractable problems are all at the level where you can just throw up a fullscreen window, use direct IO to grab a block of disk space and off you go. Start from the top and work down, not bottom and work up.
BTW you'd probably like the Mill architecture. It tackle a lot of the things you're talking about. Comes out of the commercial world though, not academia.
I'm using the standard street definition in which the OS is everything that you get on a fresh (desktop) OS install, not just the kernel.
There's very little research available on kernels because their shape is largely dictated by the hardware design, and the hardware design is largely dictated by physics and what the manufacturers give us. But as you go further up the stack the options widen considerably. You can start to consider user interfaces, application programming models, etc.
"You just need to build capability security into CPUs, the OS, and all apps…"
Pure cap systems are an old idea that have never worked. They're too cumbersome for programmers and affect API design in problematic ways.
But here's the thing. If you disagree, you can go ahead and prove it. You don't need a custom CPU. Figure out the higher level software issues first, and if you ever get to the point of needing actual CPU changes then fork qemu and virtualize your intended design. Make it so custom hardware is just an optimization once the core ideas are worked out.
That's what I mean by doing stuff at a higher layer. The interesting and tractable problems are all at the level where you can just throw up a fullscreen window, use direct IO to grab a block of disk space and off you go. Start from the top and work down, not bottom and work up.
BTW you'd probably like the Mill architecture. It tackle a lot of the things you're talking about. Comes out of the commercial world though, not academia.
We are stuck in the 70s because Unix is free. Those mainframes and such were more advanced but they were expensive. The LISP machines and the connection machines were expensive.
Free doesn’t just succeed because people don’t want to pay. It succeeds because you can just copy it with zero friction. It’s viral.
Free doesn’t just succeed because people don’t want to pay. It succeeds because you can just copy it with zero friction. It’s viral.
Just want to register my disagreement. IMHO unix won purely on technical merit (including simplicity and flexibility), and I'm here because I loved it even before it won. Now that it won, we hear a lot of discontent, but it's just the people who don't like it don't have an alternative because their preferred systems have failed, nothing about unix.
I see Unix (or today Linux) as currently without any alternative. And it's an OK-ish OS by now. I'm using it for over 20 years as the only thing that's allowed to touch hardware.
Still I don't think that it has "won" because it's amazing on the tech level. It really isn't!
It's a big hack. With ridiculously stupid / primitive ideas behind it. (Just to name one of my favorite elephants in the room: A stream of "chars"—whatever a "char" is—is a "data format"? Even a "universal" one? Alone saying such things out loud is absurdly foolish, imho).
But by now legends have formed around the whole story. Most of the "Unix philosophy" for example is a post-hoc invention by people who have some strong urge to "look smart" in retrospective…
The truth is Unix started as a toy without any serous planing behind it. But than business discovered it by chance, and business came to to the conclusion that "a Bobbycar is good enough" as long as it doesn't cost anything. Business is never interested in excellent technical solutions! It's always only interested in "the cheapest shit that gets the job done"™ (barely). Unix fits this pattern very well.
A small reminder where we're still standing mostly:
https://web.mit.edu/~simsong/www/ugh.pdf
Still I don't think that it has "won" because it's amazing on the tech level. It really isn't!
It's a big hack. With ridiculously stupid / primitive ideas behind it. (Just to name one of my favorite elephants in the room: A stream of "chars"—whatever a "char" is—is a "data format"? Even a "universal" one? Alone saying such things out loud is absurdly foolish, imho).
But by now legends have formed around the whole story. Most of the "Unix philosophy" for example is a post-hoc invention by people who have some strong urge to "look smart" in retrospective…
The truth is Unix started as a toy without any serous planing behind it. But than business discovered it by chance, and business came to to the conclusion that "a Bobbycar is good enough" as long as it doesn't cost anything. Business is never interested in excellent technical solutions! It's always only interested in "the cheapest shit that gets the job done"™ (barely). Unix fits this pattern very well.
A small reminder where we're still standing mostly:
https://web.mit.edu/~simsong/www/ugh.pdf
The wonderful technical achievement of free beer, over expensive wine.
Well said.
Problem is likely that people just don't know anything else by now.
If all you've seen is Windows and a Unix clone, well, you could indeed come up with the idea that Unix is "well designed". Even it's actually not designed at all, and more or less everything was just a random accident (and usually even the worst, but "simplest", option around).
Problem is likely that people just don't know anything else by now.
If all you've seen is Windows and a Unix clone, well, you could indeed come up with the idea that Unix is "well designed". Even it's actually not designed at all, and more or less everything was just a random accident (and usually even the worst, but "simplest", option around).
True, true. The marked chooses the cheapest product that can somehow satisfy the current needs.
Nothing beats "free & good enough".
But it blocks now any meaningful progress. That's a pity.
Nothing beats "free & good enough".
But it blocks now any meaningful progress. That's a pity.
Or something like https://en.wikipedia.org/wiki/Sprite_(operating_system) but with a microkernel!
Apparently Python was developed for Amoeba. So in a way some strands of that research continued.
I wish there was a way to run Ameboa and early Python together on QEMU, but the HTTP download links on the Ameboa site are down.
Try the FTP archive at https://archive.org/details/2014.11.ftp.cs.vu.nl maybe, it seems to have the Amoeba files (unlike mirrorservice.org, which only has the Minix ones). The ArchiveOS page at https://archiveos.org/amoeba/ linked from the Wikipedia page also has some.
[deleted]
Apache Mesos, though not a ground up OS, it does have the aim of sharing resources across clusters.
Apache Mesos is an OS??
https://mesos.apache.org/
>Apache Mesos abstracts CPU, memory, storage, and other compute resources away from machines
>Apache Mesos abstracts CPU, memory, storage, and other compute resources away from machines
It's still not an OS in the classical sense.
It's a regular user-mode executable.
The idea is that it provides a kind of "virtual OS" to the applications build against it.
But Mesos needs a regular OS as runtime on the nodes of the cluster.
It's a regular user-mode executable.
The idea is that it provides a kind of "virtual OS" to the applications build against it.
But Mesos needs a regular OS as runtime on the nodes of the cluster.
> It's a regular user-mode executable.
I don't think that necessarily excludes something from being an OS. Historically, a number of Unix ports ran as applications on top of a non-Unix. AT&T's early 1980s port of Unix to IBM S/370 mainframes, ran Unix as an application on top of IBM's TSS/370 operating system. [0] The Interdata 7/32 port done at Wollongong University in Australia, initially ran under Interdata's OS/32 operating system, although once the port had advanced sufficiently to run on bare metal, OS/32 was ripped out from under it. [1] The first versions of Cray's UNIX port, UNICOS, supported running as a guest under their earlier COS operating system (which was a batch processing operating system, modelled after that of CDC mainframes.)
I still don't think Mesos counts though. Applications running under Mesos access resources by calling the Linux APIs; Mesos configures the Linux environment the application runs under, but at runtime it steps out of the way. If, hypothetically, Mesos had exposed its own API to applications running under it – separate from the Linux API, even if ultimately implemented using it – and forced them to use that rather than call the host OS APIs directly – then I would count it as an OS. But, that would be a rather different thing from what Mesos actually is. (And all those points apply to Kubernetes too.)
With talk about WebAssembly as a container format – if you had something like Mesos/Auroroa/K8S/etc which ran WebAssembly containers only, so that applications running under it could only access WASI and other WebAssembly-based APIs – that would be closer to a true OS, even if it happened to run on top of the Linux kernel. You could swap out the Linux kernel for another – BSD, Windows, Illumos, XNU, GNU Hurd, L4, Fuschia, z/OS, whatever – and the apps shouldn't be able to tell the difference.
[0] https://ieeexplore.ieee.org/document/6771917
[1] http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/...
I don't think that necessarily excludes something from being an OS. Historically, a number of Unix ports ran as applications on top of a non-Unix. AT&T's early 1980s port of Unix to IBM S/370 mainframes, ran Unix as an application on top of IBM's TSS/370 operating system. [0] The Interdata 7/32 port done at Wollongong University in Australia, initially ran under Interdata's OS/32 operating system, although once the port had advanced sufficiently to run on bare metal, OS/32 was ripped out from under it. [1] The first versions of Cray's UNIX port, UNICOS, supported running as a guest under their earlier COS operating system (which was a batch processing operating system, modelled after that of CDC mainframes.)
I still don't think Mesos counts though. Applications running under Mesos access resources by calling the Linux APIs; Mesos configures the Linux environment the application runs under, but at runtime it steps out of the way. If, hypothetically, Mesos had exposed its own API to applications running under it – separate from the Linux API, even if ultimately implemented using it – and forced them to use that rather than call the host OS APIs directly – then I would count it as an OS. But, that would be a rather different thing from what Mesos actually is. (And all those points apply to Kubernetes too.)
With talk about WebAssembly as a container format – if you had something like Mesos/Auroroa/K8S/etc which ran WebAssembly containers only, so that applications running under it could only access WASI and other WebAssembly-based APIs – that would be closer to a true OS, even if it happened to run on top of the Linux kernel. You could swap out the Linux kernel for another – BSD, Windows, Illumos, XNU, GNU Hurd, L4, Fuschia, z/OS, whatever – and the apps shouldn't be able to tell the difference.
[0] https://ieeexplore.ieee.org/document/6771917
[1] http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/...
I think this is too broad of a definition.
This would make more or less all VM runtimes "OSes".
In a sense, they are "operating systems", yes, but it's more about how the APIs bind and constrain the applications that build on top of them. For that reason I call K8s "Windows for the cloud". But that's another story.
I would say that, by a "strict definition", OS describes the software that runs on the metal, and operates all the different kinds of (application) runtimes and (OS) services under itself. A type 1 hypervisor would be by this definition an OS for example. But say a bare metal implementation of Doom would be not, I think, as it would not provide any implementation of a ("universal") app runtime. [Please don't say Doom is Turing complete. I hope not!]
And Mesos? Mesos is really something else. It's a distributed "task manager". But even without a scheduler. Everything else should be provided by "frameworks". One could say Mesos is a kind of micro kernel for the data center (and the frameworks are the OS servers). But that is very figuratively speaking.
Mesos is also less a "Windows for the cloud" compared to K8s because it supports different frameworks as runtimes. You can bring our own framework (or plugins for some existing). K8s on the other hand tries to be (more or less) "the one true" all encompassing API. Vendor lock-in works than as with Windows (or Linux, or macOS / iOS)^^.
This would make more or less all VM runtimes "OSes".
In a sense, they are "operating systems", yes, but it's more about how the APIs bind and constrain the applications that build on top of them. For that reason I call K8s "Windows for the cloud". But that's another story.
I would say that, by a "strict definition", OS describes the software that runs on the metal, and operates all the different kinds of (application) runtimes and (OS) services under itself. A type 1 hypervisor would be by this definition an OS for example. But say a bare metal implementation of Doom would be not, I think, as it would not provide any implementation of a ("universal") app runtime. [Please don't say Doom is Turing complete. I hope not!]
And Mesos? Mesos is really something else. It's a distributed "task manager". But even without a scheduler. Everything else should be provided by "frameworks". One could say Mesos is a kind of micro kernel for the data center (and the frameworks are the OS servers). But that is very figuratively speaking.
Mesos is also less a "Windows for the cloud" compared to K8s because it supports different frameworks as runtimes. You can bring our own framework (or plugins for some existing). K8s on the other hand tries to be (more or less) "the one true" all encompassing API. Vendor lock-in works than as with Windows (or Linux, or macOS / iOS)^^.
> This would make more or less all VM runtimes "OSes".
I argued that Mesos is not an OS because it exposes so much of the underlying host OS API - well, the same is true of most language runtime VMs. Java’s famous slogan was “write once run anywhere”, but in practice it exposes a huge amount of the host operating system, such that Java apps often end up with multiple code paths (even entirely separate classes) for different host platforms. The same is true for node.ha, Python, Perl, Ruby, Tcl, most Lisp implementations, etc
But, imagine a language runtime which didn’t do that - that hid the host OS so well, apps written for it couldn’t know or care what the host OS was (or whether it was actually bare metal). Such a runtime would have greater claim to be an actual OS.
Imagine a language runtime which included its own filesystem implemented in userspace - which was a single file on the host filesystem. Maybe it even has its own user space network stack, using TUN/TAP. It treats the host OS basically as a microkernel, only consuming a small subset of services provided by it (such as memory management). Hence you could swap the host OS for an actual microkernel running on bare metal and no app would notice.
> I would say that, by a "strict definition", OS describes the software that runs on the metal
Nowadays, many OS don’t actually run on the “metal” directly, rather under a hypervisor. On some architectures, a hypervisor is architecturally mandatory, there is no ability to run without one. Whether some facility is implemented in the real hardware or the hypervisor may be an implementation detail which can change over time, oblivious to the OS. Given all of this, I don’t think “runs on bare metal” is necessary to be an OS, especially given it is not always clear any more what actually counts as “bare metal”
I argued that Mesos is not an OS because it exposes so much of the underlying host OS API - well, the same is true of most language runtime VMs. Java’s famous slogan was “write once run anywhere”, but in practice it exposes a huge amount of the host operating system, such that Java apps often end up with multiple code paths (even entirely separate classes) for different host platforms. The same is true for node.ha, Python, Perl, Ruby, Tcl, most Lisp implementations, etc
But, imagine a language runtime which didn’t do that - that hid the host OS so well, apps written for it couldn’t know or care what the host OS was (or whether it was actually bare metal). Such a runtime would have greater claim to be an actual OS.
Imagine a language runtime which included its own filesystem implemented in userspace - which was a single file on the host filesystem. Maybe it even has its own user space network stack, using TUN/TAP. It treats the host OS basically as a microkernel, only consuming a small subset of services provided by it (such as memory management). Hence you could swap the host OS for an actual microkernel running on bare metal and no app would notice.
> I would say that, by a "strict definition", OS describes the software that runs on the metal
Nowadays, many OS don’t actually run on the “metal” directly, rather under a hypervisor. On some architectures, a hypervisor is architecturally mandatory, there is no ability to run without one. Whether some facility is implemented in the real hardware or the hypervisor may be an implementation detail which can change over time, oblivious to the OS. Given all of this, I don’t think “runs on bare metal” is necessary to be an OS, especially given it is not always clear any more what actually counts as “bare metal”
> But, imagine a language runtime which didn’t do that - that hid the host OS so well, apps written for it couldn’t know or care what the host OS was (or whether it was actually bare metal). Such a runtime would have greater claim to be an actual OS.
I'm not sure about such a definition.
This would make more or less any ISA implementation on higher level hardware an "OS":
On advanced chips the ISA is just an API. The code gets JIT compiled by the hardware into its actual machine code.
I would not really agree an ISA (implementation) is an OS…
> […] only consuming a small subset of services provided by it (such as memory management).
Well, memory management, I/O, task scheduling, HAL, and all the other things an actual OS provides. ;-)
A runtime (or usually a few of them) is / are part of an OS. But a runtime isn't an OS by itself.
The parts that talk to the hardware are what makes some runtime an OS…
> Nowadays, many OS don’t actually run on the “metal” directly, rather under a hypervisor. On some architectures, a hypervisor is architecturally mandatory, there is no ability to run without one. Whether some facility is implemented in the real hardware or the hypervisor may be an implementation detail which can change over time, oblivious to the OS.
I think I've clarified this point already.
A (type 1) hypervisor is an OS (according to my previous definition).
> I don’t think “runs on bare metal” is necessary to be an OS, especially given it is not always clear any more what actually counts as “bare metal”
Well, the question is more whether it (potentially) can run on bare metal.
You can run any OS in a VM, sure. But you could never run a "non-OS" on bare metal. That's the difference.
A runtime that can't run without an OS (the part that runs on metal) is not an OS. But sure, such a runtime could be in fact a very large part of an OS.
I'm not sure about such a definition.
This would make more or less any ISA implementation on higher level hardware an "OS":
On advanced chips the ISA is just an API. The code gets JIT compiled by the hardware into its actual machine code.
I would not really agree an ISA (implementation) is an OS…
> […] only consuming a small subset of services provided by it (such as memory management).
Well, memory management, I/O, task scheduling, HAL, and all the other things an actual OS provides. ;-)
A runtime (or usually a few of them) is / are part of an OS. But a runtime isn't an OS by itself.
The parts that talk to the hardware are what makes some runtime an OS…
> Nowadays, many OS don’t actually run on the “metal” directly, rather under a hypervisor. On some architectures, a hypervisor is architecturally mandatory, there is no ability to run without one. Whether some facility is implemented in the real hardware or the hypervisor may be an implementation detail which can change over time, oblivious to the OS.
I think I've clarified this point already.
A (type 1) hypervisor is an OS (according to my previous definition).
> I don’t think “runs on bare metal” is necessary to be an OS, especially given it is not always clear any more what actually counts as “bare metal”
Well, the question is more whether it (potentially) can run on bare metal.
You can run any OS in a VM, sure. But you could never run a "non-OS" on bare metal. That's the difference.
A runtime that can't run without an OS (the part that runs on metal) is not an OS. But sure, such a runtime could be in fact a very large part of an OS.
> This would make more or less any ISA implementation on higher level hardware an "OS":
I think – in practice – one of the most distinctive things an OS supplies is file management – APIs to open/close/read/write/etc files/directories, pathname syntax parsing, etc – both the VFS layer and the filesystems (if they are distinguished). I've never seen a hardware ISA (as opposed to a bytecode implemented in software) with instructions to do stuff like that. If that's the yardstick, no "ISA implementation on higher level hardware" counts as an "OS".
Most language runtimes provide those kinds of facilities, but they bulk of the implementation work is actually done by the host OS, with the language runtime often doing little more than providing pass-thru access to host OS services; sometimes adding some virtualisation layer on top (for example, Tcl VFS), but still the host OS file APIs are the by-far most common backend.
Whereas, a language runtime which actually implemented its own filesystem internally, and just asked its host for some block storage, is much closer to being an OS - how much does it matter whether the block storage is files on a host OS filesystem, or a paravirtualized block device, or a "real" block device such as SATA/SAS (which might be virtualized anyway)? The code change to switch between them is relatively small, it could even be pluggable modules. You can even talk SCSI/ATA from userspace: over network (iSCSI or ATAoE) or using SCSI/ATA-passthru support provided by the host OS.
Other features I've never seen in an ISA – a TCP/IP stack, user/group management (as opposed to some capability primitives which that could be built on top of). A language runtime which provides those itself, rather than relying on the host OS, is really a guest OS.
> Well, memory management, I/O, task scheduling, HAL, and all the other things an actual OS provides. ;-)
A lot of those things are at least partially implemented in hardware, although the hardware/software balance varies widely from architecture to architecture. Although a rare feature nowadays, several CISC ISAs include hardware-support for task switching (x86 TSS are most famous example although never saw much use; IMPI, the underlying ISA of the IBM System/38 and CISC AS/400s, is another). Some ISAs have even gone so far as to add hardware acceleration for garbage collection (Lisp machines, Intel iAPX 432). An operating system running on an ISA which provides many of those functions in hardware may delegate most of them to the hardware; what's the difference between delegating those functions to hardware versus to a host OS?
A guest OS asks for relatively few services from its host ("give me 4GB of memory, 100GB of block storage, an Ethernet interface, and here's some threads to run"). A mere language runtime expects the host to provide a filesystem (as opposed to just block storage), Berkeley sockets (as opposed to just a TUN/TAP device), a security database (NSS, PAM, /etc/passwd, Windows LSASS, etc), executable loading (here's the name of an ELF/PE-COFF/Mach-O, please load and run it as a subprocess with these arguments) – a guest OS does all that itself.
I think – in practice – one of the most distinctive things an OS supplies is file management – APIs to open/close/read/write/etc files/directories, pathname syntax parsing, etc – both the VFS layer and the filesystems (if they are distinguished). I've never seen a hardware ISA (as opposed to a bytecode implemented in software) with instructions to do stuff like that. If that's the yardstick, no "ISA implementation on higher level hardware" counts as an "OS".
Most language runtimes provide those kinds of facilities, but they bulk of the implementation work is actually done by the host OS, with the language runtime often doing little more than providing pass-thru access to host OS services; sometimes adding some virtualisation layer on top (for example, Tcl VFS), but still the host OS file APIs are the by-far most common backend.
Whereas, a language runtime which actually implemented its own filesystem internally, and just asked its host for some block storage, is much closer to being an OS - how much does it matter whether the block storage is files on a host OS filesystem, or a paravirtualized block device, or a "real" block device such as SATA/SAS (which might be virtualized anyway)? The code change to switch between them is relatively small, it could even be pluggable modules. You can even talk SCSI/ATA from userspace: over network (iSCSI or ATAoE) or using SCSI/ATA-passthru support provided by the host OS.
Other features I've never seen in an ISA – a TCP/IP stack, user/group management (as opposed to some capability primitives which that could be built on top of). A language runtime which provides those itself, rather than relying on the host OS, is really a guest OS.
> Well, memory management, I/O, task scheduling, HAL, and all the other things an actual OS provides. ;-)
A lot of those things are at least partially implemented in hardware, although the hardware/software balance varies widely from architecture to architecture. Although a rare feature nowadays, several CISC ISAs include hardware-support for task switching (x86 TSS are most famous example although never saw much use; IMPI, the underlying ISA of the IBM System/38 and CISC AS/400s, is another). Some ISAs have even gone so far as to add hardware acceleration for garbage collection (Lisp machines, Intel iAPX 432). An operating system running on an ISA which provides many of those functions in hardware may delegate most of them to the hardware; what's the difference between delegating those functions to hardware versus to a host OS?
A guest OS asks for relatively few services from its host ("give me 4GB of memory, 100GB of block storage, an Ethernet interface, and here's some threads to run"). A mere language runtime expects the host to provide a filesystem (as opposed to just block storage), Berkeley sockets (as opposed to just a TUN/TAP device), a security database (NSS, PAM, /etc/passwd, Windows LSASS, etc), executable loading (here's the name of an ELF/PE-COFF/Mach-O, please load and run it as a subprocess with these arguments) – a guest OS does all that itself.
>Nowadays, many OS don’t actually run on the “metal” directly
Even when they run on metal they don't talk "directly" to it..they often just talk to the firmware's.
Even when they run on metal they don't talk "directly" to it..they often just talk to the firmware's.
Moreover it is also microkernel-based.
How would you classify Genode wrt being a multiserver?
I haven’t found the time to examine it closely for several years now, but after finally skimming a couple of chapters of the Foundations book (thanks!) it looks like a classic multiserver to me.
It's not about clustering, "multiserver" in this context means that parts that are stuffed together in the kernel on Linux or BSD run in separate userspace processes (i.e. networking, file system, device drivers, ...). This approach gives better isolation of those components, so a bug in one is less likely to affect others, and if one crashes, it can potentially be restarted, while the rest of the system keeps running. If done right, it can also make these individual parts simpler.
GNU/Hurd tries the same, but with POSIX compatibility and so far with mixed success. Other multiserver microkernel systems I know off are Minix and QNX. I'm sure there's more.
GNU/Hurd tries the same, but with POSIX compatibility and so far with mixed success. Other multiserver microkernel systems I know off are Minix and QNX. I'm sure there's more.
Modern operating systems are all microkernel-ish to some extent. Linux can run filesystems in usermode processes, Windows does run the graphics subsystem in a separate process, macOS consists of tons of components running in various servers connected by Mach ports and is similar to Android in that they're moving drivers progressively out of the kernel into processes.
The two classic examples of the networking stack and the filesystem generally don't move because they aren't buggy enough to be worthwhile, the performance hit is too great and because it's unreasonable to expect userland processes to cleanly handle a restart of things like that. Like, in 99.99% of real programs if every file descriptor is suddenly invalidated then that program will crash and the devs won't care if you report it as a bug because they'll say, yeah well, actually it's on you to fix your buggy OS not on us to code around it. Other platforms don't crash their network or FS driver every five minutes so why should we do extra work for yours?
So the kernel vs microkernel distinction doesn't seem particularly relevant or interesting anymore, at least not to me.
The two classic examples of the networking stack and the filesystem generally don't move because they aren't buggy enough to be worthwhile, the performance hit is too great and because it's unreasonable to expect userland processes to cleanly handle a restart of things like that. Like, in 99.99% of real programs if every file descriptor is suddenly invalidated then that program will crash and the devs won't care if you report it as a bug because they'll say, yeah well, actually it's on you to fix your buggy OS not on us to code around it. Other platforms don't crash their network or FS driver every five minutes so why should we do extra work for yours?
So the kernel vs microkernel distinction doesn't seem particularly relevant or interesting anymore, at least not to me.
> Modern operating systems are all microkernel-ish to some extent.
This won't become true even it gets repeated more.
A micro kernel requires a micro kernel design form the ground up. (Something like FDs would be only one example of something where you would need different APIs…)
You can't make a micro kernel out of a monolith. That's one of the reasons something like Hurd failed, and something like macOS is a slow and buggy hell.
The story about the graphics drivers on Windows is also not true, afik. I've heard they moved this back into kernel space (with some special encapsulation) long ago because it was way to slow otherwise.
Because you can't move an existing design to be an micro kernel after the if your APIs are all designed for a monolith setting. Alone the fact that you need async "SysCalls" (or better said "ServerCalls") in a proper micro kernel design makes it impossible to make a micro kernel out of a monolith (where all SysCalls are usually sync, because it makes no sense to have an async layer for intra-process calls).
Also micro kernels aren't slow. The canonical link was posted already in a sibling.
The main point about micro kernels, and why they still more than matter, is not about bugs and crashes. The main point is about security. You can't have a secure monolith! The TCB would need to be way to large.
This won't become true even it gets repeated more.
A micro kernel requires a micro kernel design form the ground up. (Something like FDs would be only one example of something where you would need different APIs…)
You can't make a micro kernel out of a monolith. That's one of the reasons something like Hurd failed, and something like macOS is a slow and buggy hell.
The story about the graphics drivers on Windows is also not true, afik. I've heard they moved this back into kernel space (with some special encapsulation) long ago because it was way to slow otherwise.
Because you can't move an existing design to be an micro kernel after the if your APIs are all designed for a monolith setting. Alone the fact that you need async "SysCalls" (or better said "ServerCalls") in a proper micro kernel design makes it impossible to make a micro kernel out of a monolith (where all SysCalls are usually sync, because it makes no sense to have an async layer for intra-process calls).
Also micro kernels aren't slow. The canonical link was posted already in a sibling.
The main point about micro kernels, and why they still more than matter, is not about bugs and crashes. The main point is about security. You can't have a secure monolith! The TCB would need to be way to large.
> The story about the graphics drivers on Windows is also not true, afik. I've heard they moved this back into kernel space (with some special encapsulation) long ago because it was way to slow otherwise.
Yes, if you are stuck using a legacy installation of Windows NT 4 - Windows 7, instead of Windows Vista onwards.
That move happened during Windows NT 3.51 to NT 4.0 transition, and was undone during Vista.
Yes, if you are stuck using a legacy installation of Windows NT 4 - Windows 7, instead of Windows Vista onwards.
That move happened during Windows NT 3.51 to NT 4.0 transition, and was undone during Vista.
Thanks for clarifying.
A better word is non-monolithic.
>the performance hit is too great
I see this myth referenced a lot due to misconceptions constructed around design issues in early, pre-Liedtke microkernels (particularly Mach, used in IOS/OSX) leaving a long-lasting impression.
L4 changed everything, and seL4 takes it to the next level.
Some references:
- https://archive.ph/30hhi
- https://youtu.be/INBEKSkAiTA?list=PLtoQeavghzr3atxNQig-sLGbw...
I see this myth referenced a lot due to misconceptions constructed around design issues in early, pre-Liedtke microkernels (particularly Mach, used in IOS/OSX) leaving a long-lasting impression.
L4 changed everything, and seL4 takes it to the next level.
Some references:
- https://archive.ph/30hhi
- https://youtu.be/INBEKSkAiTA?list=PLtoQeavghzr3atxNQig-sLGbw...
The necessarily poor performance of micro-kernel-ish systems was a myth even for a 1970s design (not to diminish Liedkte's work). In the '80s I used fast (realtime, multi-access) GEC OS4000 systems, thankful not to need VMS often. Whether or not the Nucleus was strictly a micro-kernel, it was at least the moral equivalent, message-passing, and I think influenced by the RC4000 (which didn't work so well). I've been logged in when the filesystem was rebooted, not that it was often necessary.
> and because it's unreasonable to expect userland processes to cleanly handle a restart of things like that
Why would it be more reasonable to handle this in kernel space? Doing well anything in kernel space is always harder and less safe than user space.
Why would it be more reasonable to handle this in kernel space? Doing well anything in kernel space is always harder and less safe than user space.
You don't handle it in kernel space. If your FS driver segfaults then you get a kernel panic and the entire machine restarts, including all apps, therefore the apps aren't expected to handle such failures.
The "apps" wouldn't be expected to handle this failure in a microkernel OS either, only the driver process would. Since it's outside of the kernel it has a much better chance at doing so. At the very least, you can just kill the driver and restart it, which is effectively like restarting the system just without interrupting the programs that don't depend on it. This actually has been done successfully so it's not just a hypothetical benefit.
If the driver process crashes then presumably other processes have to be able to re-establish a connection and resync state.
I think the question is how many programs don't depend on the filesystem. Given that they're loaded from it, you'd presumably need to give up mmap and pre-fault all the code for even very simple programs to survive a loss of connection to the fs driver. It seems like an extreme edge case.
I think the question is how many programs don't depend on the filesystem. Given that they're loaded from it, you'd presumably need to give up mmap and pre-fault all the code for even very simple programs to survive a loss of connection to the fs driver. It seems like an extreme edge case.
I suspect you're still thinking monolithically.
Firstly the driver would not expose a filesystem interface, it might expose something like a block-level interface. The filesystem would be provided by yet another process that operates over that block interface.
Secondly, mmap implies shared address space mappings, but note that the driver process doesn't have to be the owner of those mappings. If the driver restarts then the mmap process reissues any DMA commands to the faulted driver(s) to re-establish those mappings.
So now block devices can be restarted in case of faulty hardware. This might seem like kicking the can down the road a bit, but the point is to partition the statefulness into smaller, more manageable pieces that can be reused.
The filesystem process can preserve its caches and open file descriptors, and it should log mmap commands it issued in case of mmap faults as well. This is pretty robust and not so trivial to do at the kernel level where data structures are all intertwined.
Firstly the driver would not expose a filesystem interface, it might expose something like a block-level interface. The filesystem would be provided by yet another process that operates over that block interface.
Secondly, mmap implies shared address space mappings, but note that the driver process doesn't have to be the owner of those mappings. If the driver restarts then the mmap process reissues any DMA commands to the faulted driver(s) to re-establish those mappings.
So now block devices can be restarted in case of faulty hardware. This might seem like kicking the can down the road a bit, but the point is to partition the statefulness into smaller, more manageable pieces that can be reused.
The filesystem process can preserve its caches and open file descriptors, and it should log mmap commands it issued in case of mmap faults as well. This is pretty robust and not so trivial to do at the kernel level where data structures are all intertwined.
Redox, Fuchsia, Genode, Helios/Ares, are some more recent examples.
Their webpage has this to say about it in the FAQ, so I would say nope.
"Within the scope of microkernel operating systems, a multiserver spreads the operating system functionality over multiple user processes. Note how this differs from a single-server microkernel that concentrates all these functions into a single user process." - http://www.helenos.org/wiki/FAQ
"Within the scope of microkernel operating systems, a multiserver spreads the operating system functionality over multiple user processes. Note how this differs from a single-server microkernel that concentrates all these functions into a single user process." - http://www.helenos.org/wiki/FAQ
Symbian was multiserver and written in C++ - I cannot compare with HelenOS but the fact that there were separate server seemed to go hand in hand with asynchronous system calls which make Linux seem a bit primitive. I'm sure it caused a lot of problems in various ways too but I wasn't working on that at Symbian.
Maybe this is a silly question, but if people are building these from scratch as a hobby project, why don't we have GNU Hurd working yet? Is the problem nowadays that the goal has shifted from "make a kernel" to "make a kernel that's bug-for-bug compatibile with Linux including driver support"?
I'm not an expert, but my understanding is that HURD made some uniquely poor choices that make it difficult to work with in ways that other microcernels don't necessarily suffer from.
Be helpful if you could elaborate on those choices
HURD (mach) -> Hurd-NG -> back to HURD (mach):
http://walfield.org/papers/200707-walfield-critique-of-the-G...
One step forward two steps back...and no actual progress, that kills a project who is in competition with something like linux (who is obviously not a perfect design but just pushes forward)
http://walfield.org/papers/200707-walfield-critique-of-the-G...
One step forward two steps back...and no actual progress, that kills a project who is in competition with something like linux (who is obviously not a perfect design but just pushes forward)
Not a hobby project. Used for teaching at a university. See http://www.helenos.org/wiki/FAQ
[deleted]
I think it came about at a time when Stallman was trying to make a power grab for Linux and a lot of people saw it as empire building rather than as a serious project they could get behind. Meanwhile Linux was hitting The Network Effect at a time when people were itching for a challenger to Windows, and The Hurd was never going to be that.
Because it isn't cool to work on Hurd, most likely.
It would be cool if they had a direction...aka let's build on mach...oh that's old let's make Hurd NG....wait even less people work on that one? ...ok let's get back to mach...and what do we do now?
Having a kernel without goals is like a sandbox without having fun, no one cares.
Having a kernel without goals is like a sandbox without having fun, no one cares.
I missed that that, yeah.
It's fascinating how "everyone knows" that OSes "should" be written with microkernels and servers, but to a first approximation 100% of all general-purpose computing[0] is done on monolithic kernels. Are we hosts to an invasive meme with poor reality correlation, or are we victims of history holding us back from the right way to design systems? And how can we distinguish these, since both theories (by design) offer an explanation about how we might be deceived about the better solution?
[0] Say, anything with a human input device and/or hardwired internet connection, to cover our bases but exclude IoT.
[0] Say, anything with a human input device and/or hardwired internet connection, to cover our bases but exclude IoT.
First thing I've noticed is the lack of a LICENSE file in the repository.
licensing is addressed, though at a glance I don't quite understand it. I didn't read it in detail.
http://www.helenos.org/wiki/License
http://www.helenos.org/wiki/License
>HelenOS is open source, free software. Its source code is available under the BSD license. Some third-party components are licensed under GPL.
https://github.com/HelenOS/helenos#license
https://github.com/HelenOS/helenos#license
Really cool stuff. It still uses GCC, which itself is several million lines of code. I wonder if they have a desire to port to something like QBE (~12k line backend) and cproc (~8k C frontend for QBE).
I've never heard of QBE before. It seems like a competitor to LLVM, is that accurate?
Precisely. (Well competitors that can coexist.) There's a page on their site making a comparison: https://c9x.me/compile/doc/llvm.html.
Why would/should it be attempting to replace the compiler?
It seems like it's trying to simplify the tech stack, so I thought it might be something the author was interested in.
Note that Helen is written in C++14. Currently there isn't a C++ front-end for QBE, let alone one supporting a recent standard. Writing one is not an easy task and one of essentially different domain.
Oh nice! Hopefully it'll receive a RISC-V port at some point.
> I ported the HelenOS kernel to RV64 in 2016, but I've never properly finished the user space support. I hope this board will be a good motivation for me to finally push the entire OS to the same level as x86-64
https://twitter.com/mdecky/status/1397892220225736711
https://twitter.com/mdecky/status/1397892220225736711
Sun and then Oracle used to recruit people that worked on HelenOS for Solaris. Or that's how I remember the story but that was long time ago.
What does it mean by being multiserver here?
It is explained well on the Wikipedia page of MINIX 3[1]:
> To achieve that, the code running in kernel must be minimal, with the file server, process server, and each device driver running as separate user-mode processes. Each driver is carefully monitored by a part of the system named the reincarnation server[2]. If a driver fails to respond to pings from this server, it is shut down and replaced by a fresh copy of the driver. In a monolithic system, a bug in a driver can easily crash the whole kernel. This is far less likely to occur in MINIX 3.
[1] https://en.wikipedia.org/wiki/Minix_3
[2] https://en.wikipedia.org/wiki/Minix_3#Reincarnate_dead_or_si...
> To achieve that, the code running in kernel must be minimal, with the file server, process server, and each device driver running as separate user-mode processes. Each driver is carefully monitored by a part of the system named the reincarnation server[2]. If a driver fails to respond to pings from this server, it is shut down and replaced by a fresh copy of the driver. In a monolithic system, a bug in a driver can easily crash the whole kernel. This is far less likely to occur in MINIX 3.
[1] https://en.wikipedia.org/wiki/Minix_3
[2] https://en.wikipedia.org/wiki/Minix_3#Reincarnate_dead_or_si...
Some microkernel based systems have more monolithic designs where there's one big "most of the os" server that might be derived from a BSD or Linux kernel and the microkernel's role is more like a hypervisor.
Like Gnu Hurd or Minix3:
https://www.gnu.org/software/hurd/
>>It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels
https://www.gnu.org/software/hurd/
>>It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels
What are the minimum hardware requirements of HelenOS for ARM32 ? Can it be used on MMU-less MCUs like Cortex-M4 ?
I find the FAQ to be more enlightening than this page. It explains what it is used for (OS research research in Charles University, Prague) and how it is different than other operating systems (genode, minix, hurd).