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 -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com quixote@xxxxxxxxxxxxxxxx -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
