Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


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

GNU/Linux naming debate



I'll need to wear my flame-proof vest to post this, but one important
aspect of the Linux/GNU naming debate is the fairly obvious:  The GNU
project started out, by definition ("Gnu's Not Unix"), with the goal
of creating an alternative freeware Unix--and failed to meet that
goal on its own.  The kernel portion of the project, named the Hurd,
was delayed for several years.

I don't know all the inside details of these delays, but a similar
delay occured within Linux for several months back in 1993 (three
different TCP/IP stacks evolved, and contributors waited in vain for
the developer of 'cleanest' version to publish a final version--we're
now using a patched-up version of one of the older ones).

GNU critics (and I'm not one) can point to the fact that the Hurd had
plenty of opportunity for development; Linux simply filled an obvious
void in the various niches appropriate for freeware distribution.  A
run-time kernel only takes a few weeks to write, and is often a required
part of commercial or university R&D activities--sooner or later someone
was going to publish one which conformed to previously established
POSIX standards.

Here are a couple of kernel developments in which I've participated:  (1)
in '85, I took a crufty piece of PLM-51 code which simply invoked a series
of functions in a round-robin loop, and replaced it with a home-brew
multitasking kernel to make the A-320 cockpit printer run 3 times faster;
and (2) in '93 I did some maintenance and testing on a David Cutler kernel
which drives the DEC (now Quantum) RZ series of hard drives.  Cutler is
famed for two major products:  the MicroVAX I, and the NT operating system.
That kernel he wrote for DEC eons ago has grown perhaps a bit beyond his
early ambitions.  ;-)

As I understand it, Linus originally set out to write a terminal
emulator back in '91 or early '92.  Having written one for Wang myself
back in '86, I know that one of the essential ingredients of a good
terminal emulator is a simple barebones multitasking kernel.  The
ingredients are a boot loader, task initiator, priority queue manager,
interprocess communication, memory allocation and VM mapping, hooks
for device drivers, and one or two other essential items.  At that
time someone else had developed a free 386 BSD variant, but it hadn't
yet stabilized; I don't know if Linus noticed this, or simply
independently observed that he could take his terminal emulator code
and make it compatible with gcc, emacs, and stdio libraries to create
a freeware Unix variant.  Freeware seems to succeed best when the work
is divvied up into bite-size chunks of a few weeks' of effort by
independent developers.  Over time, of course, Linus surely put in more
than a few several-week intervals of effort--but success depended on
releases every few weeks, with invitations to others to add similar-
sized feature sets.

I should also point out that Linus had a much narrower goal than the
FSF:  to make his initial contribution, he needed only to make his
boot-loader and device interface work on the 386 chip.  The FSF was
hamstrung primarily by the stated goal to simultaneously release the
Hurd on multiple hardware platforms (pretty much all Unix hardware
environments except the Macintosh; and in fact one of the trickier
requirements was that it specifically *not* run on the Mac, owing to
antipathy between Apple and FSF founders).  This goal worked well for
the GNU user environment's remarkably wide global adoption, but it got
in the way of kernel development.

-rich
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org