Hello Marcus,
> > 2. There are other Mach implementations besides gnumach with a
> > richer or different set of features. Besides using the Hurd
> > as main OS-Server on top of those Mach(s), one could also use
> > the Hurd as 2nd OS-Server, inheriting X11, networking etc...
^^^^^^^^^^^^^
sorry for not being more precise; of course, it should have read:
"2nd [set of] OS-Server[s]" ;-) Actually, I'm moving to the Hurd
while experimenting with task migration, LD and DSM because of the
potential to distribute/replicate all/some Hurd servers on a cluster.
This is a completely different setup from the single server OS of
type Lites and UX and requires a detailed analysis of the RPC flow
between the servers and the client programs (glibc etc...).
> The Hurd is not a single server OS, it is one of the rare multiserver
> systems, which makes it so special. The only thing I could probably see
> fitting this point is booting a subhurd, which is already possible with the
> "boot" command, and it is pretty straightforward to use. I tested it
> recently, and it worked quite well.
Yes, I also booted a subhurd, while trying to slightly modify some core
servers and debugging them, and it worked very well for me too. My point
was, that as long as the Hurd _distribution_ is not yet complete, one
could as well work on the Hurd servers inside a somewhat more versatile
environment like the ones provided by Lites and OSF Servers.
BTW, have you tried the RT-Mach system? Two features are especially
interesting:
1. The Real-Time semantics and RT-Mach itself, its scheduling policies,
netmsgserver is back, old norma/xmm present.
2. RT-Mach can be added to a 2.2.x FreeBSD system like any other simple
package (I just tried it with a 2.2.7 FreeBSD-RELEASE minimal setup and
it worked/works like a charm!).
The first point is very useful for "traditional" Mach programming,
especially if you want to reuse existing Mach client code and
experiment with distributed shared memory etc. RT-Features also seem very
promising, though I didn't have the time to look at them im more
detail yet.
More important and also relevant to Debian/Hurd is the second point.
While you are struggling with porting as much software as possible to
the Hurd, the RT-Mach people just dropped their system into a fullscale
existing OS. While the Debian approach works better in the long run and
is definitly preferred, the RT-Mach (or more generally the Lites) approach
provides right now faster (and sometimes better) results.
I'll mail more thoughts about binary compatibility with existing OS
in a separate mail.
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
