[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Newbie questions again...



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 <Marcus.Brinkmann@ruhr-uni-bochum.de>


Reply to: