Re: What is hurd?
In article <[🔎] 199808250806.KAA05037@sg10.chem.tue.nl> 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.
Reply to: