On Mon, Nov 08, 1999 at 11:05:59AM +0100, Zsombor Gergely wrote: > Hi there, new questions arrived... (Reading through the docs helped a lot, but > many things are not clear yet) > > 1) Reading on disk/partition names (like the easy guide) state that "IDE hard > disks are numbered in order...". What happens if I had Primary/Master (hd0) > and > Secondary/Master (hd1) and added Primary slave? Will this shift hd1 to hd2? > [Beides: it would be nice to sync the disk naming conventions int Hurd and > GRUB!]
The comment applies only to GRUB, not to Mach naming convention. So hd* never changes, but grub style (hd*,*) does indeed shift. There is ahrdly anyway to sync those names, as GRUB is limited by BIOS functionality. Erich said that there were a way, but it's definitely hard. > 2) I was told previously that drivers are compiled into Mach and I can > decrease > its size by recompiling. Great, but what happens if a) I try to wake up my ppa > Zip drive _after_ booting, c) insert a PCMCIA card [when support will be > ready] > or c) [although not frequent, but very plausible for servers] insert new > hardware when the system is on? How can the HURD (Mach?) Handle this? Not at all. > 3) I feel that Linux compatibility is a major concern of the developers > (true?), > but will they be able both to exploit the full power of the system _and_ > remain > compatible? Yes. Compatibility will be possible on a binary level. Linux binaries will simply not be aware of cool hurd features. This provides a smooth migration path from linux but feature less (hehe) software to Hurd full featured software. In a microkernel model, several architectures can coexist, although they might not be able to communicate and share ressources easily or only to some extend. > 4) I also read that this is not a place for talking about things like EROS. > But > after touching their introduction on security, I felt that the HURD have > built-in chance (with dynamicall adjustable and 32 bit uids) to prectially > circumvent the issues mentioned on an Access List System by generating new > uids > for critical processes on both sides of a transaction, and destroying them > after > they are finished. Is it possible? I think this question is more suited for help-hurd or bug-hurd :) I definitely can't answer it. (The charter of debian-hurd is building an operating system distribution. Discussing fundamental issues of Hurd design is stressing it a bit. Again, I am not opposed to it, but you will probably miss out people who can help you who are subscribed to other lists). > [5) I also miss the possible "lstrans" command for all of the translators. > Should not they register themselves somewhere? Probably separated by users and > with listing controlled by permission...] Of course registering should not be mandatory. Optional registration may be useful, for example to emulate stuff like mtab. If you want to work on this, be my guest. I am sure the authors of the Hurd have some ideas about it. But then you have a problem, as passive translators are only scribbled in the filesystem (you could find them with a "find" command after modyfying find, probably. But stat on a translator wakes it up so be careful). Active translators are listed in the process list, so as a work around, use alias lstrans="ps Aux" Thanks, Marcus -- "The purpose of Free Software is Free Software. The End and the Means are the same." -- Craig Sanders Marcus Brinkmann <[EMAIL PROTECTED]>
