It's always cool to see various OS-projects and new kernel designs. It serves to remind me that even the most basic parts of the stack we take for granted can still be shaken up. So congrats to Daeken for getting this far.
That said, what are the big points that drove you spend so much effort on this project? What did you think would be unique in your offering?
Thanks for the kind words, it's greatly appreciated.
Renraku is really motivated by two things: 1) I believe that by going to pure managed code and getting rid of address space separation, we'll see great increases in performance, and compiler technology is getting better by the day. 2) Existing OSes simply aren't built for the world we're in now. With everything interconnected, OSes that make it hard for computers to interact are simply holding back progress.
Renraku aims to change the landscape by leaving unmanaged code completely behind, making everything in the OS an object, and making all objects network transparent. The goal is to make it easy to develop for, easy to use, and incredibly fast. I believe we can do it, even if it does take us years (and it will).
I'm very eagerly watching your progress! For a while now, I have wanted to try something like this on my own, but I've just never found (or made?) the time to do it. Hopefully when things free up a bit down the road, I'll be able to contribute some code towards this awesome project.
Network transparent objects were tried and found wanting before - how are you going to do it differently? Specifically, distributed programs normally have to be network aware in order to avoid large numbers of round trip times.
How does managed code & one address space improve performance? I can see that system calls will get cheaper, but is that a performance bottleneck? Or are there other improvements?
Basically when you switch between processes you have to update this. In 64 bit and some 32 bit operating systems you don't need to update the TLB to make system calls, the kernel shares address space with whatever process is running.
With a single process running I don't think the overhead is anything to concern yourself with, but if you have a lot of processes running I think it can measurably affect performance.
As eggnet said, you avoid the overhead of context switches, but you also avoid the restrictions of interprocess communication. That is typically done with sockets and marshalling, which can be orders of magnitude slower and more difficult to program than simple function calls.
I know this question wasn't directed at me, but as another small OS developer, I'll give you an additional perspective.
I'm developing a kernel (and later an OS around it) called XOmB. It's an exokernel design.
Originally, we started our project as a reason to learn the D language. We were tossing around project ideas, and someone brought up an OS. We started bouncing around some ideas, and we decided that this could actually be a pretty cool project. In addition, the systems space is interesting, because you hear less about it. A lot of people are interested in web apps, or desktop apps, but not nearly as many people are interested in systems. Most of the time, this is due to a supposition that systems are 'too hard for me.' We wanted to help educate others, and try to get more people interested in systems programming.
As far as uniqueness goes, first of all, there hasn't been a real exokernel written yet. The original paper had a small one with it, but it was mostly just for the paper, nothing huge. We're also writing a lot of documentation, and trying to aim it at a beginner. We started a spin-off project named XOmB Bare Bones that does all of the lowest-level work for someone who would want to write an OS in D, letting them jump straight to kmain. About 35 pages of documents were written on this process, with code citations and such... we hope to have our full kernel documented in this way.
If you're interested in checking out the source, we're actually going through a huge code review / restructuring, so the main repo is actually fairly outdated. But until the new version is up to the same feature level as the old, we don't feel comfortable pushing that out. If you'd like to see the new source, it's here: http://github.com/wilkie/xomb/tree/ldc
As an aside, the whole "everything is an object" model makes me think of Zope. It's apples and oranges (web framework vs. OS) but I don't think the object model really helps Zope, and in my experience had made things needlessly confusing, and I've never used any of the extra power of the OO model.
Not going to get into a big license debate while on my Kindle,but simply put I beleive the CDDL preserves the rights I want better than any other license.
Cosmos has focused more on building little pieces of an OS than on trying to build a real OS with a solid set of goals. This approach isn't better or worse, but very different than ours. In addition, Cosmos is built using C#, which I find far slower to work with than Boo.
That said, what are the big points that drove you spend so much effort on this project? What did you think would be unique in your offering?