
Whatever happened to the Hurd? (2012) - ramblenode
https://www.gadgetdaily.xyz/whatever-happened-to-the-hurd-the-story-of-the-gnu-os/
======
ChuckMcM
I always like to give the Hurd its due. It is a great lesson in motivation,
ego, and effectiveness.

Motivation, because it was solving a problem that didn't need to be solved by
the people working on it. Specifically they had access to other UNIX systems
but they "wanted" one which was open source. Linus on the other hand was a kid
without access to such operating systems and he wanted to learn about them and
play with them. His motivation was to simply build something he could play
with.

Egos were another interesting part of the problem, at the time the great micro
kernel / monolithic kernel debate was going strong. "Big brains" were arguing
one side or the other and it was an area of research. So on Hurd, what had
been thrust very much into the local spotlight, if it was going to be "big"
then the people working on it wanted to be "right" and arguing over what was
the right way to do it consumed an amazing amount of time and energy.

And finally effectiveness. By far the most effective thing to come out of the
free software project is gcc (and by proxy the binary utilities binutils).
These were tools that were built so that the "real project" could be built,
and as such were just re-implementing an existing thing (C and C++ compiler)
which was a little more than a senior undergraduate project in most
universities. But gcc was _useful_ because people could get operating systems
when they bought hardware but the industry was really trying to make money by
selling them the compiler tools.

So gcc/binutils came into the world with little ego (it wasn't changing the
world, just re-implementing it). Was highly effective, and people were
motivated to use it because it was an alternative to an expensive compiler
suite. But Hurd, was no better, and significantly worse in that it was less
developed than, the OS that came with the hardware that these folks bought
(workstations) it was just that it had source and you probably didn't have
source to the OS you were using (or you did but you couldn't share it).

Linux on the other hand, while still a toy was a better OS than MS-DOS in that
it was already more 'unix like' than DOS was, and more useful than Minix
because rather than just teach concepts Linus was using them to make the other
parts of the OS as well. So the motivation was there to try it, Linus was not
the egotistical "expert" who didn't listen to alternate ideas, and it was at
least as effective an OS as MS-DOS if you didn't care too much about
applications. As a result it was much more successful.

~~~
todd8
Yes, your observations make a lot of sense. You are right about the industry
trying to make money by selling compiler's and development tools.

For perspective, I've programmed since well before the first personal
computers. When they came out I had to buy compilers and development tools
from Microsoft, Borland, and others (for the Apple systems and MS-DOS and
early Windows) in order to program at home. I estimate that is cost me
thousands of dollars over the years; I even had to buy Emacs-like editors so I
could program on a PC. Around 1985 I bought Epsilon from Lugaru Software, its
a nice Emacs-like editor still sold today!! I always wonder how profitable
that product has been over the last _thirty years_.

Because I wanted do do document preparation on something other than Word I
ended up buying a number of word processors (XYWrite, WordPerfect, MS Word for
MSDOS); finally, I found a MSDOS markup based system by Mark of the Unicorn
(which now sells high end Midi audio gear[2]). Mark of the Unicorn's markup
system was based on Scribe (described in Brian Reid's influential CMU PhD 1980
dissertation[3] for which he won the ACM Grace Murray Hopper Award) that ran
on PC's.

My first personal Unix system was a Dec Workstation, I think it cost me over
$20,000 in 1990 for disk drive (maybe 300MB), monitor, and computer!! I put it
to good use doing consulting and development, but nevertheless I am so so
grateful to the open-source community for gcc, freebsd, linux, tex, and every
other tool I use not just because it doesn't cost me as much to try out new
things but because it has made it possible for people all over the world to
access the power of computers.

[1] [http://www.lugaru.com/](http://www.lugaru.com/)

[2] [http://www.motu.com/](http://www.motu.com/)

[3] [http://reports-archive.adm.cs.cmu.edu/anon/scan/CMU-
CS-81-10...](http://reports-archive.adm.cs.cmu.edu/anon/scan/CMU-
CS-81-100.pdf)

------
ddp
This article's a little dated. Just for the record, work on the Hurd
continues:
[https://www.debian.org/ports/hurd/](https://www.debian.org/ports/hurd/)

------
oconnor0
I'm far more interested in why his girlfriend Alix changed her name after she
and Stallman broke up. :)

~~~
kol
Nothing special. She just couldn't come up with a proper recursive
interpretation for ALIX. Now she is called MIRIAM (= MIRIAM Isn't RIchard's
AnyMore).

------
erikb
So, microkernel's promise is to have a bigger part of the system in userland.
But isn't that what happens around Linux as well, over time? I'm not deep
enough into that topic to name reasonable examples but I remember to have
heard something like "A can now be savely run in userland." "B can be
configured to be run in userland or the kernel." etc. Am I interpreting these
kind of statements correctly?

In my opinion software is a fluid thing. No matter what the design decisions
where if some change is necessary over time it will happen. So despite being
an idealist (and therefore wishing for a more idealistic kernel as well) I
don't feel bad about Linux making these decisions early on at all. But of
course I may be wrong. Feel free to correct me.

~~~
lucozade
The use of the term microkernel has stronger connotations than just having a
bigger part of the system in userland. The intent was to have the minimum
possible functionality in the kernel.

At the extreme this meant just resource allocation and messaging between
processes. I would say that it then becomes a matter of opinion how much more
one can add to the kernel before it stops being a microkernel.

The advantage of a microkernel is that it should be able to be made more
robust and secure than its more monolithic cousins as the code that is, in
principle, capable of taking out the whole system is small and slow moving. On
that basis, saying that Linux is not considered a microkernel is a fairly safe
statement.

Where I believe general purpose microkernels have struggled is in the
performance of the messaging (often because of the increased access checking).
More targeted uses have been successful. Probably the standout one being QNX
which has been used extensively in the embedded space.

~~~
digi_owl
I think QNX is more famous as a real time kernel than a microkernel.

~~~
jacquesm
QNX is famous as a real time kernel _because_ it is a microkernel.

All the scheduling power of QNX derives directly from having _all_ non-
essential code in user processes rather than in the kernel, which does only
one thing and does that very well (message passing).

I've re-implemented a 32 bit version of QNX long ago, maybe one day I'll
attempt to move it to the 64 bit era if I can figure out a way to
automatically convert linux device driver source code to an 'administrator'
(QNX parlance for a daemon). That should take the sting out of re-writing each
and every driver under the sun.

I strongly believe that Linux not being micro kernel based (and not in a
'minix' sense but a real micro kernel with _all_ services as user processes)
is one thing that is currently holding us back.

Many real world interactions require hard real time and with monolithic
kernels you are just not going to be able to meet your guarantees.

~~~
wolfgke
> Many real world interactions require hard real time and with monolithic
> kernels you are just not going to be able to meet your guarantees.

Lots of hard realtime systems (e.g. on microcontrollers) use a RTOS where
there is even no distinction between user and system mode, thus one cannot
even talk about microkernels vs. monolithic. From a software engineering
architectural perspective this is not a good design, but it is very fast (thus
the time guarantees you can give are smaller) and sometimes easier to
guarantee runtime guarantees. And it is easier to write a RTOS where all
things run in system mode (which does not imply it is easier to debug bugs or
to maintain).

~~~
jacquesm
It is _much_ easier to develop drivers and system processes for a micro kernel
because they run in isolation, you can hot re-load any one of them and if it
is designed properly you can even upgrade the kernel on a running system
without a reboot.

------
tzs
> [...] Linus Torvalds had begun his project to write a UNIX-like kernel for
> the IBM 386.

IBM 386? Did they mean to say Intel 386, or did Linus actually have a computer
that used an IBM 386SLC, which was an 80386 that IBM designed and manufactured
under license from Intel?

~~~
to3m
It means a 386 that was IBM-compatible, presumably.

Not sure there were all that many 386 systems that weren't, though I'm sure
they exist...

~~~
nsxwolf
A UK company called Jarogate had a line of 386 based CP/M machines that didn't
use an IBM PC compatible architecture.

CMOS versions of the 386 also showed up in some mobile phones and other
embedded systems.

------
reality_czech
When you name your project something that's only one letter away from "turd,"
that's poor UX. They should have hired an enterprise naming consultant.

------
snvzz
It failed to timely move away from MACH into the post-Liedtke world, and as a
consequence it fell into irrelevance.

------
davidgerard
_tl;dr_ absolutely nobody at any time has cared, because there is no reason
to, and if it weren't a GNU pet project it would be a "whatever happened to"
My Favourite Toy OS filed in dusty history with all the others.

------
lmm
Not obsolete. Just illegal.

~~~
koenigdavidmj
Uh, what?

~~~
sfifs
Reference to Rainbows End by Vernor Vinge. The characters use Hurd boxes to
hack into the "Secure Hardware Environment"

