> 1) Am I right if I think that a microkernel has nothing to do > with small size? Although Mach and the servers are not > _really_ big (like NT), they seem to be bigger than Linux > (and modules) for the first sight. How will this (and the > advantage, that the whole system is in several parts) affect > its applicability in - say - embedded devices? > The current implementation of GNUMach has just about every driver included. This is analogous to a Linux kernel with no modules and every driver built in (much like the default Kernels found in install sets).
If you compile your own GNUmach for your system, you will most likely see a much smaller size. Furthermore, most drivers are based on the Linux device drivers, and have not been abstracted out of the microkernel as the design goal dictates. So, you are looking at an incomplete implementation. > 2) You say it is good to put the servers in user space. Is it > the same as user space vs. kernel space? Yes > If I understand well, the separation provides memory > protection as well (crashes, garbage in memory). Yes. And user-defined drivers that could be different for different users on the same system. > If yes, don't you loose something with not separating? > I'm not sure I understand this question. > 3) If there is no centralization in the kernel, how can a > developer make such a server that is transparently usable > for those softwares, that are not explicitly designed to > support the new features. In other words: if there is nothing like > the kernel release (and syncing) in Linux, what makes the > _whole_ thing coherent? > The C runtime library provides much of the standard Kernel features in Linux. These are all system calls (at least what you are referring to). The program generally does not care if he is making a call that exercises some Kernel code (as in Linux) or activates functionality in a translator or external driver (as in the Hurd). The result is the same. Still, sometimes special handling is needed to do things on the Hurd. This is to be expected since the two systems have different architectures. It is actually amazing to me how easy it is to get things running on the Hurd based on standard Unix source code. > 4) Is it possible to develop a translator that turns the ext2 > filesystem to something like the one of the "Be"? If I have seen it well, > it can record auxiliary data for a file regarding to the author, the topic, > the project it is a part of. > I think you may have this backwards. It would be possible to create a translator for the Be file system standard so it could be used on the Hurd. It is generally not possible to add new features to an existing file system, simply because the necessary framework to generate those features (such as allocated areas in the file system structure for storing data, etc.) are not present. > 5) Can something like a "database filesystem" created? > Something than can produce views of the underlying files > according to properties (like above). Like a directory with all > my data files, one with all my documents, one with all my > programs, and just another with data per preject. Doing this > with symlinks is a nightmare (updating). > I'm going to punt this to Roland or someone knowledgable. Still, it seems possible. I mean, we have an ftp-based file system, so anything goes in my book. > 6) Will the Hurd be ready (to the extent like Linux is now) > when Debian releases 2.2? No. We freeze potato (Debian 2.2) this weekend. It will release in a month or so. There are still issues with the Hurd needing to be resolved. Still, the Hurd is very usable for many things right now. > 7) I am Hungarian and miss the keyboard layout very much. Is > it available? If not, can I make one? Please let me know... > I believe that someone has started support for keymaps. Unfortunately, our console code is still rather simple. -Brent
