A general history question

[scott]

On 11/05/2011 03:10 PM, Don Quixote de la Mancha wrote:
> Richard Stallman and his colleagues at The Freesoftware Foundation
> assert that the proper term is "GNU/Linux", because in reality linux
> is just - "just!" - the operating system kernel.
>
> There's not a whole lot you can do with a kernel all by itself.  While
> the kernel is the first program to run in a complete operating system,
> with all the other programs being launched via the facilities of the
> kernel, a complete system - what we know as a "distribution" or
> "distro" - requires user space runtime libraries such as the Standard
> C Library, "daemons" that run invisibly in the background, some way to
> set up the configuration of the system - for GNU/Linux, these are text
> files mostly located in /etc - tools to allow the user to create,
> delete and edit various file formats, and for a computer with a
> graphical user interface, a way for the screen "real estate" to be
> divided up among programs that want to display graphics, as well as to
> send keyboard and mouse input to the appropriate GUI program.
>
> Richard Stallman originally set out to write a complete new - and
> better - source code-compatible clone of the very proprietary,
> expensive and closed-source operating system UNIX.
>
>   Among his reasons for wanting to do so was that the source to UNIX
> was at first distributed more or less freely by AT&T, when AT&T was
> broken up into many competing telephone companies.  The AT&T breakup
> also lifted many of the regulatory restrictions once placed on AT&T as
> a natural monopoly.  Now free of the restrictions that prevented it
> from competing in the computer business, AT&T realized there was money
> to be made in selling UNIX.
>
> A UNIX SystemV binary-executable license was expensive, with the
> license price increasing with the number of allowable logged-in users.
>
> A SystemV source code license was collosally expensive, with the
> licensees being bound by restrictive non-disclosure agreements, as
> well as the obligation to pay AT&T for any source or binaries that the
> licensees passed on to others.  Such source licenses were only
> affordable to those who found some way to charge a lot of money for
> whatever they produced from it.
>
> Stallman - or RMS as he prefers to be called - started out by
> developing GNU - which stands for "GNU's Not UNIX", which itself
> expands to "GNU's Not UNIX Not UNIX" and so on - from the outside in.
> That is, rather than writing a kernel from scratch than adding user
> space software that ran on top of that kernel, RMS and his colleagues
> at The Free Software Foundation developed a great deal of user space
> software first.
>
> RMS and I share a common trait for which we are both often criticized:
> we are very picky about our work, and don't particularly care if it
> takes a long time to get it right.
>
> More or less the first program that RMS wrote for use by GNU was a
> text editor called GNU Emacs.  That originally stood for "Editor
> Macros", as it was originally a set of simple macros, more or less
> like Word or Excel macros, for the editor that was built in to the
> LISP artificial intelligence workstations that RMS used at the MIT AI
> Laboratory in Cambridge, Massachusetts.
>
> Writing Emacs in C, with an integrated LISP interpreter enabled Emacs
> to be portable to other kinds of computers, with Emacs being quite
> powerfuly extensible by writing Emacs LISP (or elisp) programs for it.
>
> Emacs is pretty small and quick by today's standards, compared to say
> Firefox or the Gnome or KDE desktops, but back in the day it was said
> to stand for not "Editor Macros" but "Eight Megs And Constantly
> Swapping" - I first used it on a 16 MHz Sun Workstation with but four
> megabytes of memory! - as well as "Emacs Makes A Computer Slow".
>
> When Emacs was used on a GUI computer, it was popular to give it a
> Kitchen Sink icon!
>
> It could readily be argued that RMS would have by now made a lot more
> progress with GNU had he not spent so much time writing Emacs,
> improving it as well as porting it to so many completely alien
> computing platforms.  However, if you learn to use Emacs really,
> really well, you well find that it can do a great deal more than edit
> text.  For most coders who are Emacs fans, it does everything that
> today's Integrated Development Environments such as Visual Studio,
> CodeWarrior, Xcode and KDevelop can do.  It can actually do a great
> deal more, and is readily customizable by writing elisp programs.
>
> Thus Emacs all by itself empowered all of us coders to accomplish a
> great deal more with less effort and in less time than we could have
> with the programmer's editors of the day, such as the original UNIX
> vi.  Today's Vim (VI iMproved) works just like the UNIX vi, but it can
> do a great deal more than vi could.
>
>   I used to really suffer under the SunOS 3 vi; when some consultant
> dropped by with an Emacs source tape and showed me how to build and
> run it, I thought he was a Heaven-sent prophet!
>
> RMS, despite being notorious for never getting anything done, in
> reality is just about the most brilliant and productive engineer in
> all of human history.  It's just that he doesn't like to do anything
> the simple way.  If you Google up the GNU coding standards document,
> you will find the advice that while GNU programs as well as subroutine
> libraries are expected to work much like the UNIX originals they
> replace, they are expected to improve on them in just about every way
> possible.
>
> The GNU programs all have extensive documentation, the most essential
> parts of which can be accessed by giving the "--help" command-line
> option to the programs.  No such online help existed in the original
> UNIX command-line tools, I expect because they were originally written
> for such resource-constrained computers that the executable files of
> all the software really did have to be as small as possible.
>
> Many of the older UNIX programs, as well as the UNIX kernel itself,
> had fixed-size buffers, or memory areas in which they stored their
> data.  The GNU coding standard explicitly forbids such fixed-length
> buffers when it is at all possible to dynamically allocate buffers of
> any desired size.
>
> Dynamic allocation has many advantages, but the code that implements
> it is a great deal more complex than code that uses fixed-size
> buffers.  It can be slower and use more memory as well, because there
> is some invisible overhead due to the bookkeeping requirements of the
> dynamic memory manager.
>
> I first got into UNIX in a real way right around the time that work
> was commencing to make the kernel fully dynamic.  That might not sound
> like such a big deal, but operating system kernels of any sort are a
> lot harder to write than just about any userspace program.  A big
> advantage of fixed-size buffers in the kernels is that, to the extent
> you didn't try to exceed their capacity, you could count on them to
> work right!
>
> The SunOS 3 kernel on my old 3/160 workstations had a filesize -
> uncompressed - of about 500 kilobytes.  The entire Microport
> SystemV/AT UNIX distribution for the 80386 PC clones was distributed
> on a half-dozen or so 5 1/4 inch 360 kb floppy disks.
>
> The bane of my existence when I worked phone support for Microport was
> some customer ringing me up to shout at me about the message "Inode
> Table Overflow!" spewing all over his console.  His box didn't
> actually crash, but had become largely broken.
>
> That message occured when all the processes - running programs - on
> the system all together tried to open too many files and directories.
> On Linux, and the UNIXen of todays, the number of open files is
> limited only by the avialable memory installed in the computer, but
> back then, each open file was represented by an inode data structure
> that was an element of a fixed-sized array of such structures.
>
> Opening too many files would never overflow that array, as that would
> corrupt your kernel memory and crash your machine.  Instead your file
> open would fail, and you'd get that overflow message on the console.
>
> For most of my callers, the only way to fix that overflow would be to
> send them a configuration kit - we called it the Link Kit - that
> contained the object code - but NOT source code! - for the kernel,
> except that we did provide source for certain user-configurable items,
> such as the inode table array.  One would edit a header file to
> increase the size of that array, compile what sources we provided,
> then link all the objects together to make a new kernel that could
> have more files open all at one time than would otherwise be the case.
>
> But why didn't we at Microport just configure the kernel with a big
> inode table to start with?  That was because the entire inode table
> occupied precious physical memory - the kernel memory is never swapped
> out as user space programs often are - so an inode table that was
> larger than you actually needed not only wasted memory, but could
> cause other operating systems that used a lot of memory to fail!
>
> While adjusting the inode table size was the most common use for our
> Link Kit, there were lots of other configurable parameters.  Devices
> drivers were all hardwired in, for example.  Dynamically loadable
> driver modules as we have today were yet to be implemented.  Again
> linking in drivers you didn't really, really need took up a lot of
> wasted memory.
>
> RMS and his colleagues eventually got to the point that most of the
> software that was of any real use to developers who wrote code for Sun
> Workstations in particular, as well as most other UNIX variants, and
> to a lesser extent VAX/VMS, Microsoft Windows and even, just a little
> bit, the Classic Mac OS, could be downloaded in source code form from
> FTP servers all over the Internet.
>
> Getting that stuff to compile could be a chore, so the FSF financed
> itself to a large extent by selling tapes - TAPES! not DISKS! - of
> ready-to-install precompiled executable programs.  They also offered a
> custom service of making such a tape for just about any platform of
> your heart's desire, but for a hefty price.
>
> While some of that code could be gotten to work on inexpensive 16-bit
> MS-DOS and Windows 3.1 computers, a lot of it either had not yet been
> ported to the 16-bit x86 architecture, or just could not be ported at
> all.  To enjoy the full power of the GNU software, one had to drop a
> lot of dollars on an expensive UNIX computer, only to replace the
> proprietary software - which you had no choice but to pay a lot of
> money for - with the GNU software.
>
> RMS by this time was well into the development of HURD, the GNU
> operating system kernel, but in his usual fashion he wanted it to be
> light-years ahead of existing UNIX kernel technology.  It was a long,
> long time before HURD could do anything useful at all.
>
> While it was developed with portability in mind, a kernel is a very
> least portable of any kind of software, because its source code
> depends on all kinds of minute, picky, arbitrary and often downright
> disgusting ways on the hardware that operates the kernel.  Quite a lot
> of those hardware details are only available to developers who sign
> non-disclosure agreements.  Even when the hardware interface isn't a
> trade secret, it happens all the time that the document is just plain
> wrong, or doesn't even exist!
>
> Eventually a Finnish Computer Science undergraduate student by the
> name of Linus Torvalds got really tired of waiting around for HURD to
> be usable as well as ported to the 80386 PC clones, so he wrote from
> scratch, and more or less all by himself, just about the simplest
> possible operating system kernel that would work more or less like
> UNIX did, but ONLY on 80386 PCs.
>
> That kernel was called "linux", and it still is.
>
> Without the work of Richard Stallman, his colleagues at The Free
> Software Foundation, as well as countless others who contributed to
> the GNU source code, the linux kernel all by itself would have been
> largely useless.
>
> The original distributions were little more than the Linux kernel and
> the GNU user space software.  That's why they should be properly known
> as GNU/Linux.
>
> The distributions of today come with a great deal more software than
> the kernel and the original GNU stuff.  There are some who argue that
> we should call it "Mozilla Linux" because most of us spend most of our
> time using the Firefox web browser, which was developed by the Mozilla
> project.
>
> But the essential core of all of our distributions - not just Fedora,
> but Ubuntu, Slackware, Debian, all the Live CDs - is the GNU software.
>
> If you don't want to call it "GNU/Linux" instead of just "Linux", it
> would really be better not to call it Linux at all.  Call it by a name
> that gives credit to ALL of its contributors.  For us, that is just
> "Fedora".  On my MacBook Pro, it is Ubuntu.
>
> I'm really beat, so I'm not going to address your question about the
> package managers quite yet.  The package management is an important
> part of creating a usable distribution that end-users or system
> administrators can easily install, upgrade and maintain.
>
>   In particular the mind-numbingly idiotic way in which all UNIX-like
> operating systems spread vitally important programs, code libraries,
> configuration files and other data files such as national language
> localizations All Over Creation makes it damn near impossible for
> anyone but an expert to UNINSTALL a program without the use of a
> package manager.
>
> The package managers didn't used to work so well though.  It's not as
> bad these days, but it used to happen all the time to just about
> everyone that installation, upgrading or uninstallations would totally
> break a system.
>
> Debian did a better job with the packaging at first.  Red Hat with RPM
> - the Red Hat Package Manager - had a well-deserved reputation for
> being totally brain-damaged.
>
> But those days are largely behind us.  Not completely though; for no
> reason I can fathom, just last night, without doing anything at all,
> the Ubuntu Natty Narwhale installation on my MacBook Pro started
> reporting that it had broken dependencies that so far I have been at a
> total loss to repair.
>
> I'll Send You My Bill In The Mail.
>
> Sincerely,
>
> A Grey-Bearded Old-Time UNIX Hacker
  You just put more grey on my head, and in my beard that I care to 
admit to. Nice write-up.

Scott....another old grey-hair