Feeling defensive are we? On Wed, Jan 21, 2004 at 02:11:02PM +0100, Alfred M. Szmidt wrote: > Mach has some issues that seem to make it intrinsically slow[1], > Hurd has its own issues on top of it that makes it even worse[2], > and functionality-wise it doesn't really seem to give much more > than a pair of funky userspace filesystems like the ftp translator, > compared to monolithic kernels like a modern linux or bsd. And the > userspace is the same. > > And better security,
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. > well designed, 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. 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. > far more stable since the system > won't crash if the file-system/driver/etc fubars. You're leaving in dream land here. Modern linux, and I have first-hand experience with failures there, usually won't crash on driver/fs problems if the problem is recoverable. And if it isn't (stuck shared irq, runaway dma all over the kernel memory, / fs lost...), userspace drivers won't do any better. > Hurd is neither, and is so behind the curve that it's hard to find > developers motivated by it. Especially since it's very hard to see > what Hurd could propose that is not already in the other ones. > > And you base these claims on what? On several years of keeping an eye on hurd and installing it from time to time, and on the amount of development and innovation done in here compared to say lkml. > What is has to do, and how fast it does it are completely different > things; also note that the Hurd is completely unoptimised. To the point of been unusable. And that's one of the reasons why it is unsuccessful. Avoiding premature optimization does not mean "if you have multiple ways of implementing something, use the slowest". OG. _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
