As a programmer and manager of embedded software products for a living, I think that operating system programming is so much fun that it will eventually be outlawed. I've previously published two articles on OSNews, So, you want to write
an operating system and Climbing
the kernel mountain, and tried to summarize my experience in designing operating system kernels as well as technical traps that can be easily avoided.
Permalink for comment
To read all comments associated with this story, please click here.
As you know, the "claim to fame" of EROS is orthogonal persistence, i.e. the ability to pull the plug on your computer, power it back on, and find your environment exactly as it was, modulo a few minutes work lost, inbetween the last "checkpoint" and the time you pulled the plug.
On paper, this is a wonderful concept. There are two ways of doing it, (1) applications need to support it and you need to rewrite the universe, or (2) applications need not bother with it.
EROS claims to be in category (2) but in practice, applications need to be written to take advantage of all sorts of EROS-specific implementations of capabilities and whatnot, so in essence you have to rewrite the universe, or as they did, do a clever hack so as to support UNIX applications which in essence equates to saying that you could do modify a UNIXy kernel in the first place.
In practice, the world has scratched that itch, starting with laptops (the most exposed to the problem of power going out) by implementing a "freeze execution, store physical memory to disk, power down" strategy. This is not as elegant, but it works, and by not rewriting the universe, you can channel efforts on making that technique quick, use less disk space, etc.
On top of this, as it turns out, the EROS way is not that clean, even if they did manage to rewrite the universe better than the staggering amount of developers for existing platforms. For instance, some things need to be re-started when the system boots up, such as network connections.
As you know, the "claim to fame" of EROS is orthogonal persistence, i.e. the ability to pull the plug on your computer, power it back on, and find your environment exactly as it was, modulo a few minutes work lost, inbetween the last "checkpoint" and the time you pulled the plug.
On paper, this is a wonderful concept. There are two ways of doing it, (1) applications need to support it and you need to rewrite the universe, or (2) applications need not bother with it.
EROS claims to be in category (2) but in practice, applications need to be written to take advantage of all sorts of EROS-specific implementations of capabilities and whatnot, so in essence you have to rewrite the universe, or as they did, do a clever hack so as to support UNIX applications which in essence equates to saying that you could do modify a UNIXy kernel in the first place.
In practice, the world has scratched that itch, starting with laptops (the most exposed to the problem of power going out) by implementing a "freeze execution, store physical memory to disk, power down" strategy. This is not as elegant, but it works, and by not rewriting the universe, you can channel efforts on making that technique quick, use less disk space, etc.
On top of this, as it turns out, the EROS way is not that clean, even if they did manage to rewrite the universe better than the staggering amount of developers for existing platforms. For instance, some things need to be re-started when the system boots up, such as network connections.
Don't take the latter point from me, but do take it from Shapiro himself:
http://osnews.com/story.php?news_id=5316