In article <[EMAIL PROTECTED]> you write: >> The Hurd uses the Mach microkernel: microkernels are supposedly more >> efficient, but somewhere I read (I vaguely think it was by Linus, arguing >> with Tanenbaum about whether Minix was superior to Linux) that in the Real >> World, microkernels aren't as superior to monolithic kernels as they are >> theoretically supposed to be. Also, loadable modules give Linux some of >> the flexibility of microkernels. > >A very interesting and important difference as far as I understand it, >is that _users_ may write, compile and install there own drivers into >the kernel, without becoming root or rebooting, and without affecting >the drivers used by others on the system. This goes as far as >giving the possibility to provide different OS environments to >different users, so in theory you could have `windows98' and `linux' >running at the same time on the same machine without the kind of >overhead you'd expect from an emulator.
Also, unlike most kernels (even microkernel), Hurd is very modular. Every operating system service can be implemented as a seperate Mach process. That would mean - As explained above, modules can be written and customized by any user, without rebooting, and without affecting the security of the computer. - If a module, eg NFS client system fails, it can be restarted, without doing any damage to the rest of the system, as it would run as a seperate Mach process. - Any user can mount extra filesystems (aka translators), not just root. - In theory (mine at least) the amount of code running as root code can be minimized. A process can give extra user privileges to any other process (within security limits of course, I am not sure how these are defined). For instance, a telnet daemon would not have to run as root, but instead could run as the special user "nobody" (that means the process has no UIDs). As soon as it gets the password from the user, it can send it to a password process, which changes the priviliges of the telnet process to that user after checking that the password matches. This password process is the only process running on the system that would need access to the shadow password file. I believe the same concept could be applied to most other processes that need to run as root, as typically only a small amount of code actually needs to be root. Of course, it is important not to let the terminology get confusing. For instance, the above poster said "drivers" can be customized without being root or rebooting. I don't think this includes low level drivers though, such as physical ethernet, harddisk, SCSI, CD-ROM access, which must be compiled in to the MACH kernel (I might be wrong). Instead it applies to high-level support, such as filesystems, program execution, shared-library support and distributed program execution.
