On Wed, Jan 21, 2004 at 04:07:26PM +0100, Olivier Galibert wrote: > Security is essentially dependant on userspace. And frankly the linux > and bsd kernels have been way more reviewed in that area, so I'd trust > them more. The security model of the translators in presence of crons > runs from priviledged accounts with find in them can be interesting in > particular.
This is indeed a concern, and can be fixed by disabled the translator mechanism on untrusted nodes by default. This means that depending on the owner of the node, you get to see the translator as a translator, or transparently as the filesystem it provides. This can be configurable per-task, with root:$USER as the default (well, you get the idea). > I've heard a lot of things about Mach, but never that it was well > designed. Its task/thread model sucks, its VM model sucks, the > marshalling/unmarshalling on syscalls is a performance nightmare. You have to put it into the perspective of OS design history. The success of Mach is to show that splitting up a kernel in a generic core part and a specific server component (or multiple) is possible. It's only a first step in a new branch of the still short history of OS design. Also, you will have a hard time to substantiate your criticism. I don't say that your criticism is wrong (in fact, I agree), but "sucks" is an evaluation that tells us more about you than about Mach :) If you want to analyze for example the IPC performance, you will find out that a lot of research was necessary to find out exactly _why_ it sucked and what can be done to fix it (and it _can_ be fixed). I don't say that the burden is on you to do this. You can very well lean back and watch if it happens, and until then you can feel comfortable knowing about the superiority of existing traditional solutions. However, this is not a contest. We are not in competition with anyone in terms of performance, security, etc. There is no price to win if we are better in any category. We are most interested in exploring the possibilities of microkernel OS design. We are interested in exploring its limitations, too. But we don't stop at the "it sucks" level. We try to go beyond it and point out why it sucks, what can be done to make it not suck. > Hurd itself is better, but still has its problems, the main one being > the lack of distributed memory caching management. And it still has > to cope with the mach annoyances, in particular cthreads. Indeed one of the major problems with Mach is its centralistic VM system. You should be interested to learn that in Hurd on L4, we plan to have tasks be self-paged, and be provided with physical memory. Clever protocols will allow untrusted tasks to share memory and even allows zero-copying from the device driver directly into an untrusted user's buffer. Again, this is all "dream land", as you called it. But you can not even hope to get there by "accident", or by incremental optimization of a working traditional solution. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org [EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/ _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd