Re: Different approach - harder to understand
> 1. Transparent FTP - for example: cd /ftp/ftp.uu.net
Yes, the current hurd version (not 0.2) has the hostmux and ftpfs
translators that make this possible. It has not been heavily tested,
so it probably has some bugs.
> "This mechanism is used quite obviously for mount. A mount point would
> have a translator associated with it. When a user opens the mount
> point, the translator, in this case, a program which understands the
> disk format of the mounted filesystem, is executed, and returns a port
> to the user."
>
> What's this port !? It's a number ?
> It's the same idea of port like: port 25 for mail, 22 for ssh, etc ...?
No, it's a Mach port. See the CMU/OSF Mach documentation.
> 4. Modularity
>
> On Linux it's also possible to insert modules, rigth ?
Yes, but that is a very different thing from the way in which the Hurd
architecture is modular. Linux kernel modules are dynamically loaded parts
of the kernel. The kernel is still one huge program with no really
well-defined interfaces between the pieces of it, and loading a kernel
module is just more convenient way to put more code into the same one big
program than recompiling your kernel.
> The big differences on HURD are : (!?)
> - doesn't need to be root user (uid=0)
Yes, there are many things that non-root Hurd users can do that are not
possible on Linux. For example, any user can write his own filesystem. To
get access to physical resources such as kernel memory or i/o devices, one
still must be root or have access to the right devices through the normal
means (permissions on /dev/foobar, etc).
> - modules are not inserted inside kernel
Correct. Many things that might be a "kernel module" in a system such as
Linux (or any other monolithic kernel system) such as filesystems and
network protocols are done entirely outside of the microkernel (Mach) in
the Hurd. Hurd servers do these tasks. These servers are somewhat similar
to a daemon program running on a Unix-like system, but they are started in
special ways and interact differently with clients.
> - can be inserted as much modules has we want (there's no
> limitation)
That is correct. Only the microkernel itself and a few essential system
servers need to reserve physical memory. Most of the Hurd servers, and any
new servers you write, run in virtual memory just like any normal program.
> - it's not called modules but program servers
It's a bigger difference than a name. A Hurd server is a normal program
that anyone can write, and you debug normally with gdb, etc--much easier
than debugging a kernel. (A translator is a particular kind of server that
provides a filesystem interface, and most Hurd servers are in fact
translators.)
> 5. Authentication Server
>
> Could you explain me, on a simple way, for what it's needed ?
> Authenticate users ? Kind of login server !?
No, it is a lower level of functionality than that. You don't need to
worry about it. The auth server is one of the essential Hurd servers that
implement part of the functionality that most people think of as "in the
kernel" (and that is in fact in the kernel in Linux and other systems).
Because different parts of the system are implemented in separate server
programs, there is no universal inherent notion of uid and so forth as
there is in a kernel like Linux. The Hurd auth server is the server in
charge of uids and gids, and every other Hurd server talks to the auth
server to figure out the uids and gids of a user process that asks that
server to do something.
So the short answer is, it's needed because without it there would be no
concept of a UID. Likewise, the proc server (another essential server) is
needed because without it there would be no concept of a PID.
Reply to: