decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal

User Functions



Don't have an account yet? Sign up as a New User

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

The Daemon, the GNU and the Penguin - Ch. 16, by Dr. Peter Salus
Thursday, July 28 2005 @ 09:30 AM EDT

Here's the next installment in Peter Salus' ongoing book, The Daemon, the GNU and the Penguin, "The Hurd and BSDI" -- Chapter 16.

Here are the earlier chapters of Dr. Salus' book:


The Daemon, the GNU and the Penguin

~ by Dr. Peter H. Salus

Chapter 16. The Hurd and BSDI

The Hurd

Richard Stallman had long wanted a GNU replacement for the UNIX kernel. A first pass, Trix, barely got going in the late 1980s. This changed, however, when Thomas Bushnell came to Boston and joined the GNU effort.

Thomas was born in Albuquerque, NM. He attended Carnegie-Mellon University for a year (1985-86), the University of New Mexico for nearly two years, worked, enrolled at the University of Massachusetts Boston, and received a B.A. summa cum laude in 1999 in philosophy and classics. Thomas is a brother in the Brotherhood of St. Gregory, an Episcopal order. He received his M.A. in Philosophy from the University of California, Irvine, in 2003 and is currently a Ph.D. candidate there.

Thomas worked as an Assistant Systems Administrator at UNM from 1986-89 and for the FSF from 1990-1998. He told me:

I wrote a BASIC interpreter as a demonstration that I could code before I was hired. My interpreter had a feature that would let you dynamically load math functions out of the C library -- before shared libraries existed.

I worked on GNU tar as well, before my main work was the Hurd.

The GNU Hurd is the GNU project's replacement for the UNIX kernel. The Hurd is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the UNIX kernel or similar kernels (such as Linux). Thomas told me:
RMS was a very strong believer -- wrongly, I think -- in a very greedy-algorithm approach to code reuse issues. My first choice was to take the BSD 4.4-Lite release and make a kernel. I knew the code, I knew how to do it. It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today.

RMS wanted to work together with people from Berkeley on such an effort. Some of them were interested, but some seem to have been deliberately dragging their feet: and the reason now seems to be that they had the goal of spinning off BSDI. A GNU based on 4.4-Lite would undercut BSDI.

So RMS said to himself, "Mach is a working kernel, 4.4-Lite is only partial, we will go with Mach." It was a decision which I strongly opposed. But ultimately it was not my decision to make, and I made the best go I could at working with Mach and doing something new from that standpoint.

This was all way before Linux; we're talking 1991 or so.

Currently, the Hurd runs on IA32 machines. The Hurd should, and probably will, be ported to other hardware architectures or other microkernels in the future.

According to Thomas:

`Hurd' stands for `Hird of Unix-Replacing Daemons'. And, then, `Hird' stands for `Hurd of Interfaces Representing Depth'. We have here, to my knowledge, the first software to be named by a pair of mutually recursive acronyms.
The FSF states: "The Hurd, together with the GNU Mach microkernel, the GNU C Library and the other GNU and non-GNU programs in the GNU system, provide a rather complete and usable operating system today. It is not ready for production use, as there are still many bugs and missing features. However, it should be a good base for further development and non-critical application usage."

Unfortunately, the Hurd is late. By 1995, Linux had many users. By 2000, it was a well-understood and popular system. By 2005, Linux had millions of users and the support of IBM. It was seen as a threat by Microsoft. The Hurd, unfortunately, is still "not ready for production use."


BSDI was the first company to offer a full version of BSD Unix for the Intel platform.

Despite the fact that everything was in the public eye and exposed at the USL vs. BSDI trial, there appears to be confusion as to the history of BSDI.

I think Thomas was right, to a certain extent.

While several Berkeley developers were involved in the formation of BSDI in 1990-91, none left the University of California to join Berkeley Software Design, Inc. at the outset. BSDI was founded by Rick Adams, who told me: "It was my idea and my funding. I also handled the logistics (via UUNET) and the little matter of the lawsuit."

Donn Seeley related:

The first organizational meeting occurred at a bar in Boulder during the Boulder Berkeley Workshop in October 1990. I was invited to the meeting without any advance warning and to my surprise, I was offered a job. My recollection is that Rick, Mike, Kirk, Keith, and Bill J[olitz] were present at the meeting. I believe that a more formal meeting was held in early December 1990 at Kirk's house [in Berkeley], where we voted to go ahead with the proposal. I think this meeting was when we came up with the name BSDI.

We decided to work under UUNET's wing for a while so that we would not alert any potential competition; that continued until the summer of 1991. I was to start work as soon as possible; I took an extended vacation from my job at the University of Utah, and set up shop in my parents' basement in Bellingham, WA, with a PC provided by Rick, running mt Xinu Mach/BSD (I think). (I don't remember exactly when I gave notice at Utah, but I set things up so that my employment terminated shortly before the Winter Usenix [21-25 January 1991; Dallas].) I couldn't actually work directly on the OS, since it still contained licensed code at that point.

The BSD distribution was still hung up on the issue of certain possibly licensed files, so my job was to work on freely available software. I started with the compiler toolchain (based on GCC 1). Once it was clear that there would be missing files, I went ahead and wrote a replacement for the Berkeley init(8) program. I'm not sure whether Bill was working on BSDI-related stuff at this point, but I'm pretty sure that he had started by the time of the 1991 Winter Usenix, where we all met again.

At that time Kirk McKusick was President of USENIX, Rick was in Dallas to report on UUNET and recruit, Trent Hein was chairing the session on File Systems, and Keith Bostic and Mike Karels were part of the CSRG. It wasn't hard to call a meeting.

Trent was a student at the University of Colorado, where he was a co-author of both the UNIX and the Linux system administration handbooks. He worked on the 4.4BSD port to the MIPS architecture. More recently, he was co-founder of Applied Trust Engineering. He said:

I can concretely say that the original engineering team "hired" by BSDI (Spring, 1991) consisted of Donn Seeley, Bill Jolitz and myself. Bill left BSDI later that year. Rob Kolstad joined the BSDI team much later. [Kolstad was Secretary of USENIX at that time.]

Mike Karels told me:

I'd say that the founders were Rick Adams, Keith Bostic, Kirk McKusick, me, Bill Jolitz and Donn Seeley, in approximately that historical order. This group was involved at the time of formation. Bill and Donn were the first two full-time employees, and Trent started about the same time at just less than full-time. They worked for UUNET temporarily until the company started operations, which I think was about July 1991. Bill left at the end of November '91, and Rob [Kolstad] started December 1. The proximity of the dates is not a coincidence. I started February 1, 1992, at which time two Russians had also started, and also Jeff Polk. My departure from Berkeley and position at BSDI were announced at USENIX in January '92 [San Francisco], at which Bill made a famous appearance.
I asked Rick to clarify and he affirmed:
The first employees were Donn Seeley and Bill Jolitz. Peter Collinson signed on very early for European sales and Bob Kummerfeld for Australia.

We picked up Vadim Antonov and Igor Belchiskiy from USSR that fall (1991). Rob Kolstad came on as president in December 1991.

Donn Seeley provided yet more detail.
Bill believed that he deserved a larger role as systems architect, press contact and marketer. His coding contributions mainly came before he started working for UUNET/BSDI, by porting to PCs the drivers we'd written at Utah for HP 68k systems, and writing the locore assembly source and related files. As for Bill's departure, the straw that broke the camel's back was an issue with Bill's unauthorized expenses for a trip to Europe, if I recall correctly, but it was clear long before this point that Bill was not happy. Rick was BSDI's original president, but he was asked to separate UUNET from BSDI by UUNET's first big investors, so he enlisted Rob to replace him.
[There is a long and complex tale concerning Jolitz' departure and his appearance at the January 1992 USENIX meeting. I do not think it relevant to this narrative. One view may be found here.]

Insofar as Keith Bostic was concerned, he said:

I joined much later than Mike and the founders, though. I stayed at UC Berkeley for quite some time after BSDI was founded.
Another person mentioned by Rick was Peter Collinson. In 1980-81, Collinson (then at the University of Kent in Canterbury) was offered a USENET feed by Teus Hagen at the CWI in Amsterdam. They couldn't dial out, but the CWI would dial in, via a modem brought into the UK by Martin Levy. In April 1982, he was instrumental in the formation of EUnet.

"I think it was the Fall of 1993 that Rick asked me to sell things in Europe," Collinson told me.

The earliest date on a file that I have is September 1993. I think I was at a BSDI meeting at the Usenix conference in San Francisco in January 1994 [January 21-24].

When did I leave? -- we were forced out by the sales department at the end of 1995 -- we had the fax in September -- we settled and were gone by Jananuary 1996.

We in Europe did OK -- but we were not that good at Sales -- and would have had to think hard about Sales-led sales rather than Techy-led sales very soon anyway.

In 2000, BSDI merged with Walnut Creek CDROM and then with Telenet Systems. The next year, Wind River Systems purchased the software business. Renaming itself iXsystems with plans to specialize in hardware, the server business was acquired by Offmyserver in 2002. I asked Collinson why he thought BSDI had failed.
BSDI didn't really fail. It allowed Linux to flourish unhindered by lawsuits; but it was not really technically viable. BSDI couldn't move quickly enough to keep up with the technical changes -- and Linux could because of the customer base which was a new generation of UNIX hackers and lovers.

Dr. Salus is the author of "A Quarter Century of UNIX" and several other books, including "HPL: Little Languages and Tools", "Big Book of Ipv6 Addressing Rfcs", "Handbook of Programming Languages (HPL): Imperative Programming Languages", "Casting the Net: From ARPANET to INTERNET and Beyond", and "The Handbook of Programming Languages (HPL): Functional, Concurrent and Logic Programming Languages". There is an interview with him, audio and video,"codebytes: A History of UNIX and UNIX Licences" which was done in 2001 at a USENIX conference. Dr. Salus has served as Executive Director of the USENIX Association.

This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs License. To view a copy of this license, visit or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.


The Daemon, the GNU and the Penguin - Ch. 16, by Dr. Peter Salus | 136 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
OT Here
Authored by: meat straw on Thursday, July 28 2005 @ 09:45 AM EDT
like this: <a href=http:// url goes here > link </a>

[ Reply to This | # ]

Authored by: meat straw on Thursday, July 28 2005 @ 09:46 AM EDT
If any.

[ Reply to This | # ]

The Daemon, the GNU and the Penguin - Ch. 16, by Dr. Peter Salus
Authored by: meat straw on Thursday, July 28 2005 @ 09:55 AM EDT
"BSDI didn't really fail. It allowed Linux to flourish unhindered by
lawsuits; but it was not really technically viable. BSDI couldn't move quickly
enough to keep up with the technical changes -- and Linux could because of the
customer base which was a new generation of UNIX hackers and lovers."
I have to say, I love FreeBSD - I need it in the work environment, but it's also
a pleasure to use at home (The ports system ROCKS!). On the down side, it has
become more apparent to me that Linux (Fedora distro, for example) seems to be
on top of much of today's hardware requirements as well as a few full-featured
user interfaces available right out of the box.

[ Reply to This | # ]

BSDI didn't really fail. It allowed Linux to flourish unhindered by lawsuits
Authored by: pogson on Thursday, July 28 2005 @ 10:33 AM EDT
Wow! There are some suit-happy folks out there. I wonder what suits BSDI might
have had in mind?

--- , my homepage, an eclectic survey of topics:
berries, mushrooms, teaching in N. Canada, Linux, firearms and hunting...

[ Reply to This | # ]

Modules with numbers
Authored by: Anonymous on Thursday, July 28 2005 @ 10:48 AM EDT

What is it with widget[1] and thingummy_jig(49)? I've seen them usually in the
context of *n*x software modules or functions. They don't seem to be footnotes,
nor arrays, nor functions with a single numeric parameter, so ... version

Can anyone enlighten a bewildered Groklurker?

[ Reply to This | # ]

Bill Jolitz and DDJ
Authored by: red floyd on Thursday, July 28 2005 @ 11:47 AM EDT
Bill Jolitz also wrote a year-long series in DDJ on the initial 386BSD effor.

I am not merely a "consumer" or a "taxpayer". I am a *CITIZEN* of the United
States of America.

[ Reply to This | # ]

BSDI Failure
Authored by: Anonymous on Thursday, July 28 2005 @ 12:55 PM EDT
In my company (a small ISP), we ran BSDI servers from the day we started until
about 2 years ago, when we switched all our servers to linux. Having gone
through almost all of the versions of BSDI up to version 5, I think I can say
with some certainty what made the distro fail:

1. Lack of hardware support.
2. Lack of software support.

I went through two hardware upgrade cycles where I was forced to consult BSDI's
incomplete and confusing "supported hardware" list simply to be able
to buy equipment that was compatible. Most of the compatible hardware was one
or two generations behind. In some cases, I had to choose more expensive and
slower hardware simply to get something that would work. Certain very basic
drivers were either incomplete or inadequate for a long time (for example, IDE
support - BSDI really only liked SCSI). When the third upgrade cycle came
around, I decided to go with Linux - primarily because of its robust hardware

Software support also slowly eroded from beneath BSDI. When I first started
using BSDI, there were available binary packages compiled for BSDI (and usually
Sun and IRIX and a few others). When I decided to stop using it, it was unusual
even to find source packages that could be configued to compile under it. Many
applications required source modification simply to compile with BSDI's

On the plus side, my BSDI installations were incredibly stable - to the point of
running for years at a time without crashing. For this reason alone, I kept
many systems running longer than I otherwise would have. Also, the official
patch system, while cumbersome to use, never had the same dependancy problems
that I run into with linux.

BSDI was a good system in its day. Once it got bought out (twice!), though, the
updates just weren't keeping up with the times.

[ Reply to This | # ]

  • BSDI Failure - Authored by: stevem on Thursday, July 28 2005 @ 10:20 PM EDT
  • BSDI Failure - Authored by: Anonymous on Sunday, July 31 2005 @ 02:58 AM EDT
What is "late"?
Authored by: jbn on Thursday, July 28 2005 @ 12:59 PM EDT

"Unfortunately, the Hurd is late. By 1995, Linux had many users. By 2000, it was a well-understood and popular system. By 2005, Linux had millions of users and the support of IBM. It was seen as a threat by Microsoft. The Hurd, unfortunately, is still "not ready for production use.""

The first sentence and the remaining sentences are non-sequiturs. If you're going to say that the HURD is late, it reads as if you have a schedule for HURD distribution in mind (one which you're not telling us). That the Linux kernel (remember, Linux is not an operating system, it's a kernel; alone, it does nothing useful for most people until it is used in conjunction with many other programs) achieved this degree of popularity does not mean anything here. Popularity levels of Linux doesn't impose an implicit schedule on the development of the HURD. You're effectively conflating popularity level and distribution schedule even though these are two different things (and I'm completely unaware of a distribution schedule for the HURD).

[ Reply to This | # ]

The Daemon, the GNU and the Penguin - Ch. 16, by Dr. Peter Salus
Authored by: Anonymous on Thursday, July 28 2005 @ 05:35 PM EDT
They distinguish between programs (1, 6, or 8), C functions (2 or 3), file
formats (5), and regular English words. If you say you're going to
"write" something, you're not using a technical term, whereas
"write(1)" means to send a message to someone's terminal and
"write(2)" means to send a string to a file descriptor. The number
lets you use the terms unambiguously without a lot of extra verbiage. (As other
people have said, they refer to sections of the original manual.)

[ Reply to This | # ]

HURD acronym
Authored by: Kevin on Thursday, July 28 2005 @ 10:41 PM EDT
The mutually recursive acronyms are amusing, but even funnier
is the promise that RMS once made that when HURD 1.0 was
available, the announcement would have the subject line,
"Hallelujah! Unix replacement developed!"

73 de ke9tv/2, Kevin (P.S. My surname is not McBride!)

[ Reply to This | # ]

what happened to "CERN and the web"?
Authored by: Anonymous on Thursday, July 28 2005 @ 10:42 PM EDT
The old TOC had this at chap 16, and an excursus about GPL before it. I hope
they haven't been dropped?

[ Reply to This | # ]

Herding cats
Authored by: Anonymous on Friday, July 29 2005 @ 08:36 AM EDT
The reason Linux took off was that people were willing to contribute. The OS
was something a lot of people wanted to do and Linus got everything just right.

Why didn't Hurd and BSDI take off? BSDI was trying to make money so who wants
to contribute to that? I have a harder time understanding why Hurd didn't
prosper. I assume that most of the reason has to do with not attracting

Linus was this unknown guy in Finland. He just put the first version of Linux
out there for people to play with. It was the right thing at the right time.
It seems to me that Linus didn't do anything that discouraged contributors.

Am I barking up the right tree?

[ Reply to This | # ]

A brief history of the HURD microkernel ...
Authored by: Anonymous on Friday, July 29 2005 @ 12:43 PM EDT

Definitions of terms for the uninitiated: Kernels are the basis of operating systems which carry out kernel space functions essential to running user space applications. Two conflicting philosophical approaches to the kernel are referred to as the microkernel and the monolithic kernal approach.

The former type of kernel, the microkernel design used by HURD, is a very small kernel that does almost nothing of itself except what is absolutely required in the kernal space, not even the file system is included in this kernal which then calls upon modularised servers to provide most of the services a traditional operating system provides. Microkernel experts claim that keeping its services to a strict minimum enables microkernels to be extremely stable and secure as well as being easier to maintain. However, it is also claimed that moving some of the traditional kernal functionality out of kernel space brings with it a performance hit in terms of speed.

The latter, i.e. a monolithic kernel design used by Linux for example, creates all the traditional kernel services within the kernel space which results in a large kernel that tries to do as much as possible in the very fast kernal operating space. Monolithic kernel experts point to the speed gains in a monolithic kernel as outweighing the disadvantages of potential instability and maintainability.

The HURD project's microkernel has gone back to the drawing board several times. In 1983, the initial FSF project announced the existance of a microkernel named TRIX, which was said in Feb. 1986 to have been developed at MIT. While 1986 saw some progress on trying to work out the bugs in TRIX, by Jan. 1987 the FSF started to negotiate with Carnegie-Mellon University for the right to use and work on another development microkernel named MACH. It was presumed to have incorporated many improvements over the overall design that had been employed in TRIX.

Unfortunately legal problems snagged the project and it was not until Nov. 1991 that the FSF was finally able to announce that the HURD project was finally running atop the MACH kernel. Linux had now appeared and the most of the GNU software had already been ported to the Linux Kernel because it was working and also developing rapidly.

Despite the appearance now of the FSFs own operating system, development on the HURD continuted at a snails pace in comparison to Linux. The last release of the MACH 1.3 kernel occured in May of 2002. At this point in time those working on HURD appear to have come to the realization that a number of design flaws that had been discovered in the MACH kernel due to subsequent developments in operating systems research and development efforts were too great to fix and that from a idealistic standpoint a superfast 12k kernel named L4 which had been written in 1996 by a Dr. Jochen Liedtke (deceased in 2001) already existed which overcame many of the discovered flaws in MACH. Most importantly, the microkernel performance hit, due to the abstraction of many kernel services into modules running elsewhere, which had hovered at around 15% in the MACH was reduced to about 5% in the L4 microkernel.

Instead of fixing MACH, it was decided to port HURD to the L4 microkernel. This was mostly completed in Feb. 2005 by HURD kernel maintainers: Marcus Brinkmann and Neal Walfield. The release of the HURD/L4 was announced at that time which although still in a highly experimental phase nevertheless was up and running and allowing developers to get down to the business of developing on that HURD system. It must be stressed that this "pure GNU" system while able to run many GNU application software packages, still lacks a lot of the hardware driver support which has made Linux so successful so far in the OS wars. The developers state that it is not ready for production environments or home end users.

While the copyright of the HURD system is fully controlled by the FSF, and the design philosophy makes great promises for the future of OS stability and security ... it has not yet come close to realizing the impact and usability that the GNU/Linux system has made in the computer world. At the present rate of progress it may be many many more years before development reaches commercial viability. But then again, Rome wasn't built in a day!


NB: The author of this comment has never used GNU/HURD and only wrote out of personal interest in the subject a summary of information compiled from numerous reports about HURD on the Internet. For more information and source material please see the following links:

[ Reply to This | # ]

The real achievement of HURD
Authored by: Anonymous on Sunday, July 31 2005 @ 04:24 AM EDT

The real achievement of all the effort on the HURD was, in the end, to demonstrate that the accepted wisdom in the academic community was wrong.

Computer scientists in universities had come to a consensus, even before Linus wrote any code, that the Right Way to build an operating system was to use the microkernel approach. Forgetting that Computer Science is not really a scientific, but an engineering, discipline, they reached this conclusion largely on theoretical grounds.

The HURD project and Linux put this conclusion to the test. The programmers working on HURD were very able people - there is no question about that. But a microkernel-based operating system turned out to be very hard to develop, hard to evolve, hard to maintain. Since the implementors cannot be blamed, the approach is wrong. The HURD project proved that the academic community had it wrong. The microkernel approach is not the best way, or even a good way, to build an operating system.

[ Reply to This | # ]

Maybe the OS is the wrong solution, ya know?
Authored by: Anonymous on Sunday, July 31 2005 @ 10:21 AM EDT
In the earliest days, HW was dumb and simple. Discrete devices. A
flip flop per daughter card. Little processor main memory. Then, a
batch OS was good and a DOS was nirvana.

Today, there are many intelligent subsystems in even the smallest
computer. Bridge chips with little CPUs everywhere. The Northside
Bridge is more powerful than all computers up through the Sixties
and most through the Seventies. One OS to serve them all just
might be the evil lurking in the computer.

Just get rid of the OS by distributing it to all the intelligent subsystems.
How? Well, that is grist for more than one PhD dissertation.

People have been squabbling like children. This is reminiscent of the
big endian versus little endian memory debates.

While you are creating the perfect OS, why not boost the Internet so I
can use IT to replace all my communications media?

God bless!

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )