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

Re: some newbie questions



CJ wrote:

> hello,
>
> I was just reading you Debian GNU/HURD web page and I am really
> confused about the term OS and kernel.
>
> For sure, I know that "Linux" is a kernel and "Debian GNU/Linux" is an OS
> that ported on the "Linux" kernel.

Things can definitely get even more confused than you think you are already.

An "operating system kernel" is generally a pretty precise term, referring to some
base set ("kernel," which is vaguely like the vector space/abstract algebra
concept of "kernel") of code that represents the basis for the overall system.

The term "operating system" is then somewhat more fuzzy, as one can call into
question just what ought to be considered "part of the system" and what represents
an "add-on."

The RMS view is that Linux is a kernel, but that in order to build a usable
*system,* one must then add further libraries, utilities, daemons, and other
programs, which, in his terms, make up "a GNU system."

I would gripe a little at the implicit agenda, but certainly agree that whether
it's termed a "Linux system" or a "GNU system," in order to be *useful* there
needs to be a reasonably rich set of additional software added on.  (I want my
Perl.  I want my Python.  I want Ghostscript.  I want TeX, Emacs, X, EXMH, ...)

> >>> But what about "HURD", is it an OS or is it a kernel like Linux?
>
> The reason I ask the question because on the web page the webmaster
> refers to "HURD" as OS and a kernel. The webmaster says that "Debian Gnu/Hurd"
> is a porting project to an operating system kernel and core component, the
> "HURD". And then he continues to say that "Debian Gnu/Hurd"'s goal is to
> build application on top of the "HURD" OS.

Hurd takes a fairly different approach to that used traditionally.

Linux is a good example of an OS kernel that is "monolithic."  That is, the Linux
kernel is one big program.  There is a microkernel version, namely MkLinux, which
Apple assisted with, where the Linux kernel is modified to run, still as one big
"monolithic" program atop the Mach microkernel.

In contrast, Hurd is implemented as a "multiserver," where the system is
implemented as a whole host of intercommunicating programs running atop the Mach
microkernel.

An upside to the multiserver approach is that pieces of the system perhaps become
simpler and will have clearer interfaces.  (They can't just communicate through
shared kernel memory.)  Further, you should be able to restart or even replace
some of these "servers" while the system is running, which gives the possibility
of making the system both more dynamically configurable and more robust.
Furthermore, a suitably designed microkernel can provide efficient multiprocessor
support, thus meaning that introducing SMP support (which has taken a *lot* of
design effort for Linux) nearly comes "for free."

Downside: New kinds of deadlocks are introduced, and new and subtle bugs are
possible since components need to intercommunicate through explicit subsystems
that now can fail.

At the time that Hurd was envisioned, Mach was expected to be ported *everywhere,*
and it was expected that it would be made extremely efficient, and there would be
a substantial population of grad students familiar with it.  Unfortunately
(arguably), the IBM Workplace OS project failed, and Mach development efforts
became something of a "hot potato" that finally was laid to rest at University of
Utah.  They now really care about FluxOS (which, encouragingly, just recently had
a new release), and it is likely only Hurd development that is both modern and
dependent on Mach.

There have been thoughts of moving Hurd to use L4 or its successor (whose name
escapes me).  It seems more sensible to actually get Hurd working and useful
first.

Much of the point to Hurd is to build a multiserver microkernelled system, as
there have been very few of them implemented, and see what cool things come out of
that.

It may well be that it is used to test out things that are later reimplemented (at
greater effort) on a monolithic system like Linux, and will otherwise be mostly a
curiosity rather than a production system.  If useful things are learned, both of
things to do and of things not to do, that can be worthwhile.



Reply to: