To view parent comment, click here.
To read all comments associated with this story, please click here.
Sharing ideas is always good! In that case only kudos to writing a 7 page article without intention of actually participating in the actual 'contest'. On those terms, I feel obliged to give some more constructive feedback to it.
For starters, the following two quotes are very contradictive;
"leading to a powerful *snip* microkernel based OS"
"the microkernel translates every event into a message"
Ouch! Microkernels' *main* (and when going exo~ it's basically it's *only*) task is doing the IPC. And you guys give that even more overhead? It really gets me thinking about the performance of this OS. How did you tackle this?
Second; Your discussion about the set-manager rings a bell. How much is your OS based on L4? If I recall correctly, they have a similar concept.
Third; A basic idea of a microkernel is 'if something goes down, reboot just that'. How do you deal with such situations? This is even more relevant (and interesting) when you take the network-distributed part in mind. Some info about that would be really nice.
Lastly; the main objective was to build an educational OS. But the article discusses things like network-distributed file-descriptor encryption. Besides the obvious 'what algorithm and how easy will it be to crack', isn't that a little far-fetched for an educational OS?
Ok first thanks for your constructive comments.
By powerful we do not mean performant but flexible, reliable, scalable etc.. As I remember, I wrote in the article that the performances was not a goal of the kaneton microkernel.
Nevertheless, the kaneton portability system is powerful enough to make optimizations based on the microprocessor architecture facilities. But, needless to say, the performance loss is the price to pay when introducing concepts and genericity.
Our choice was to build a microkernel with a very clear and powerful design not to be as fast as Linux.
Our microkernel is not based on L4 since I do not know anything about L4 microkernel internals. It simple to understand why: L4 goal was to prove microkernels could be fast enough while kaneton microkernel goal is certainly not the speed. Two very different approaches.
It is possible L4 has a similar concept but I do not know I am sorry.
The paper's subject was the microkernel and not the distributed operating system. For this reason, the distributed aspects were not discussed in this article. Another article will be dedicated to this but this is a bit too early since the microkernel development is not finished yet.
Finally, the paper introduced some distributed problems but this was just to permit the reader to understand the problems. If I had just talked about capabilities, the reader would had never understood their usefulness.






Member since:
2006-06-27
I can add something to the kaneton website like "source code for sale: 3 billion dollars"...
More seriously we are not doing this contest to win. just to share our ideas.