This paper describes the design of the kaneton microkernel. This system was designed to be ported on many architectures without being intrusive. Moreover, the main goal of this system was to be understandable by everyone interested in operating systems internals. To do so, the kaneton design and implementation are very elegant and easy to understand. Finally, the kaneton microkernel includes modern distributed concepts leading to a powerful, secure, flexible and reliable microkernel based OS. Note: This is the first entry to our Alternative OS Contest which runs through 14th July!

...this really feels like somebody's pet project which isn't getting anywhere. No source, no implementation details, one author. There are more names listed, but the website, this article, and the only documentation on the website (the reference doc under papers) are all created by the same person.
However, just one author doesn't have to be a bad thing. The bad thing is that there's no source! What use is an 'educational' OS if there's nothing to be found about it and nobody can actually see it?
All in all, it really sounds like the author is just grasping the basics about microkernels, and likes writing about it more than actually trying to implement anything. I wish him best of luck, but it gets a general 'meh..' until something's actually done.

Of course, if there *is* an implementation somewhere, I didn't say anything. Besides the fact that I'd like to see it and give it a go.

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?

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.

> To do so, the kaneton design and implementation are very elegant and easy to understand. Finally, the kaneton microkernel includes modern distributed concepts leading to a powerful, secure, flexible and reliable microkernel based OS.

OSNews should be an objective and neutral news source, but this one is heavily biased. And who ever wanted to create an OS that is inelegant or hard?

kaneton is not only intended to engineer students but students in general including for example high school students interested in operating systems.

When the microkernel development will be finished, the kaneton project will be available on the website with papers, documentation and assignments so every person intersted will be able to build its own microkernel based on the kaneton microkernel design.

The kaneton stuff will be available on the website at the end of the year. The developers first need to finish the microkernel implementation, to write tests and documentation etc..

I'm not sure I understand the need for specialised capabitilies..
It make things more complex, and according to the article there is even a performance loss.
I don't understand the 'scalability advantage', if you use 128-bit capabilities, it should be more than enough, no?
For an OS which want to be as simple as possible, it's a bit strange.

I agree on the fact that it seems strange to use specialized capabilities in a microkernel that claims to be simple but we found the use of generic capabilities too restrictive.

The use of specialized capabilities permit the microkernel's servers to build their own capability format.

Indeed, we can imagine a server which does not manage kind of objects but rather a unique entity like for example a physical clock (very precise clock).

In this case, the server dedicated to this task certainly does not want to use a capability with an object field and a permissions fields because needless.

Moreover, the use of generic capabilities with no server interaction to build restricted capabilities implies bigger capabilities. For example, Amoeba uses generic capabilities but the user programs need to call the servers to build restricted capabilities.

Maybe this point is not very clear in the paper, I am sorry for this but I could not go further because the capability concept is a distributed concept and will be explained in a future paper.