Hello Dana,
> I am not a long time UNIX / UNIX variant user but i have recently adopted a
> desire to pursue ANSI C and have been working through my school (University
> Of New Haven) on some system level programing for UNIX systems.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the Hurd is currently under active development. This means, that it is
currently relatively unstable and I would suggest, that you turn to a
free Unix system like FreeBSD or Linux for ANSI C _Unix_ programming,
but please see below for Hurd/Mach specific informations. The Hurd
may well be your future development environment!
The reasons for this? Well, first of all, GNU/Hurd is _not_ Unix. The
developers of the Hurd are trying to make it as Unix-ish as possible
through the C library glibc, but its not Unix. "System level
programming for Unix systems" probably means to you writing C code for
networking (Sockets), accessing the filesystem, fcntl(), ioctl(),
using processes with fork(), and also writing multithreaded programs,
most likely with pthreads. Of course, writing device drivers falls
also under this category.
If this is what you're looking for, you'll be best served by a real
Unix system with a stable ANSI C development environment. Personally,
I use and recommend the freely available Unix System FreeBSD which
comes with full sources, gcc and all other GNU tools that are needed
for programming and developlement. If you're working at a University,
you'll have a high speed connection to the Internet and will be able
to install FreeBSD over the Net on a free partition of your hard disk
in a pinch! http://www.freebsd.org/
You may be interested in doing systems programming on a non-Intel
architecture (say SPARC, Motorola, Alpha...). In this case, you'll
want to have a look at NetBSD (http://www.netbsd.org/), which is
similar to FreeBSD but which does support multiple CPU types as well.
While Linux developers are struggling to port that excellent system
to the SPARC and to Alpha, NetBSD is already there for a long time.
Compared to Linux, the *BSD variants (there is also OpenBSD, see
http://www.openbsd.org/) rely on the 4.4 BSD-Lite code from the
University of California at Berkeley, which itself evolved from
earlier releases of a very common and very well understood kernel.
Therefore, *BSD kernels tend to be very stable, are very well designed
and documented (not only in source code, but also in the academic
literature). The Linux kernel evolved in a more "chaotic" manner and,
while sporting excellent innovations, it is believed to be not as
stable as a generic BSD kernel (this is not proven though). Needless
to say, that nearly all software running on Linux runs also under the
*BSD variants. Of course, you get X, editors and everything else on
both systems. If you like developing at the "bleeding edge", Linux
developers are faster at providing kernel device drivers for new
hardware.
The Hurd, on the other Hand, is a _Mach_-based system, which tries to
emulates as much as possible of the Unix environment with the help of
userland servers and a modified C-library (and runtime environment).
Ultimately, the Hurd should replace *BSD and Linux kernels completely
and provide a replacement for them which will be as Unix-compliant as
possible. But the Hurd is much more than a simple replacement of a
Unix-Kernel. Its a completely different (and better) system than Unix
and it differs from Unix not only internally, but will be/is already a
true superset of Unix.
This is how the Hurd differs from a conventional Unix system:
1. The Hurd runs on top of the Mach microkernel (currently in its
gnumach variant, which is based upon Mach 3 from CMU and Mach 4
from Utah). Since a microkernel does not support any OS-specific
features like filesystems, memory pagers, networking, ... the Hurd
has to replace those missing features with servers running in
userland.
2. The Mach microkernel provides only four features natively. Everything
else is left to userland programs and -libraries. Those features are:
* Scheduling threads and tasks to CPUs,
* Handling page faults and passing them to a userland memory manager,
* Provide simple support with kernel-native device drivers
* Providing unidirectional ports as the only communicationns facility
between userland programs (talking to each others with
messages) as well as between itself and those userland programs.
3. Every missing functionality, like say filesystems, processes,
networking and more has to be realized in user-level programs.
There are basically two possibilities here: A single-tasked,
multithreaded OS-Server program that runs on top of Mach which
implements a whole operating system kernel. This has been done with
the Lites Server, which runs on top of Utah's Mach4 and which
contains the code of the *BSD kernel. The other possibility is to
split this monolithic OS-Server program into a group of cooperating
servers that specialize in single aspects of the OS-personality
they are trying to emulate. The Hurd is one example of such a
multi-server OS-Personality.
4. The Hurd provides many servers that run on top of gnumach. For
example, the proc server maintains process state common for Unix
systems. Client programs (tasks) register with the proc server once
they start running. (this happens in the glibc implementation of
the fork() function). Another very important Hurd server is the
auth server, which provides the usual Unix authentication rules of
users, root etc... Hurd client programs (re)authhenticate
themselves with the auth server through the glibc, which eventually
does some RPC to this server. Yet another Hurd server is a
filesystem server, like ext2fs or ufs, which can attach to a kernel
device and realize a filesystem on this device, but all in
userland. [...you've got the point... check the sources for more
servers]. There is also a unique concept called 'translator' in the
Hurd. That is basically a program that you write yourself and that
you attach to any node (file or directory) on the filesystem. Once
programs access that node, messages got transparently passed to the
translator, which is expected to respond is some implementation
dependent way. A translator could for example gunzip files on the
fly, encrypt or decrypt them or even fake files that are not
currently there. Translators attached to directories could forward
requests to FTP-servers, fetching files on-demand, simply because a
program opened a "file" on the directory(point) maintained by that
special translator...
5. Since it's Mach-based, the Hurd realizes most of the Unix functionality
through the C library glibc, which in turn uses Mach system calls
(mainly getting ports, sending and receiving messages on them) to
access the microkernel or the other Hurd-servers. Normal Unix-Programs
won't see much of this specific behaviour, but if you're doing systems
level programming, you're bound to notice small changes and specific
idiosyncracies.
6. Since Mach natively supports threads, the Hurd does too. The C-Library
runtime is thread-safe and so you can write multithreaded applications
for the Hurd with a minimum of efforts. Of course, you could do that
too for Unix systems, using the standard pthreads library (which is
unfortunately not yet implemented in the Hurd; the Hurd currently
uses Mach's cthreads library).
WARNING: The following is not implemented in the Hurd, but is what I'm
experimenting with, up until now only on Utah's Mach4 with the Lites
server. It may be interesting for you, if you're doing research in this
area. Please contact me, if you're interested.
The Hurd is much more than just a Unix replacement. Because its based
on Mach, you can use all special features of Mach in your programs. In
fact, the Hurd has become a good development environment for Mach
programs. I used myself to write programs for Mach in the Lites Server
mentioned above and I'm currently switching over to the current Hurd
"distribution", since it provides everything I needed and found in
Lites. I'm not a Hurd developer yet (missing the time to do it), but
I do conduct some experiments on load distribution (LD) and task
migration which uses the NORMA features of Mach. Well, up until now,
I've done those tests with Utah's Mach4 and Lites _only_, but will now
move on to gnumach and the Hurd and will look at the gnumach kernel
more closely for this (NORMA support).
The idea is to build a cluster of Mach nodes and have a load
distribution management system (set of programs) monitoring each node
individually. Single tasks (that are the processes on Mach systems,
which can carry multiple threads) can be then migrated to another
Mach-machine that is supposedly less busy/loaded. The greater the
cluster, the more true parallelity you can achieve. Another aspect of
task migration is providing redundancy with adequate algorithms. Once
a node gives up/crashes, the task would be still running in the
background on another node and will become the master and migrate
itself as slave on yet another/other working node/s. Once such a
system reaches a stable state, it would be extremely useful. Just
imagine a big corp. or University with hunderds and thousands of
mostly idle PCs and workstations. Would they all run a user-friendly
GNU/Hurd system with those extensions, one could imagine distributing
CPU-intensive and/or critical applications over the whole cluster of
Hurd machines. With LD, you would have enormous CPU-power and with the
redundancy, you'll be able to run applications even on systems, that
users may shut down themselves, without stopping the applications that
are running redundently elsewhere.
> I was referred to thins list in my pursuit to find a HURD based
> distribution. I had the understanding that a Debian/HURD distribution
> existed but have not been able to find it. I would love to be pointed in
> the direction of any distribution. Thank you
You will certainly have got more than enough answers from the list on this
topic now. Please feel free to ask again, if you encounter any problems.
Another list that you may contact is '[EMAIL PROTECTED]'
which is specializing on the current debian distribution of the Hurd.
Subscribe at: [EMAIL PROTECTED] in the usual way.
> -Dana
-Farid.
--
Farid Hajji -- Unix Systems and Network Administrator | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Fermat: ...I've found a remarkable proof for this: Let x,y @#$!@$!2@ NO CARRIER
