The Humble Beginnings of Linux
The histories of many programming projects are maintained by oral tradition. After all, what real programmer would take the time to write down what has happened? Because much of Linux was developed by way of e-mail conversations on the net, a slightly more firm record exists. The following is gleaned from those records.
I first worked with Minix in Fall 1989. Dr. Tanenbaum's system was a perfect vehicle for working with operating systems for those who couldn't afford a VAX. It ran on an 8086 with 640 Kbytes and a floppy drive. You could run a few programs in a multi-tasking environment and, since you had the source, you could change the system to your heart's content.
“But wait,” you say, “Minix isn't Linux. What are you talking about?”
“I'm just setting the stage, bear with me a moment.”
The intended target for Minix was students of operating systems in a computer science curriculum. I used it in teaching an upper division class where the term projects were to “enhance the system in some meaningful way.” The projects varied from a serial port driver, to virtual terminals, to simple memory management. No one took the giant step that Linus Torvalds took at the University of Helsinki. (I wish I could say one of my students was changing the course of personal computing!)
As you may know, the memory model of the 8086 is very limiting. It had easy access to only 640 Kbytes of non-virtual memory. Ugh! But that was the target system for Minix because it was the most common and cheapest system available.
Linus rejected that argument and decided that one needed virtual memory to be able to do anything interesting. Thus, he reckoned that an 80386 was the minimum processor for his system.
His project was to build a kernel for a virtual memory, pre-emptive, multi-user system. It would have much the same user interface as Minix (in fact it used the same file system as Minix for some time) and that of Unix.
From the beginning, Linus made reference to the GNU portable kernel, Hurd, and made it clear that he wasn't planning to supplant Hurd. Since Hurd was expected to be available in late 1992, Linux was clearly just a hackers' delight.
By the time Linus conceived of his project in April 1991, Minix had changed to support the improved Intel processors, but there was still room for extension. Initially Linux was cast in terms of a Minix project, but by late summer the divergence was starting to show.
Early versions were labeled 0.01 (Sept. 91), 0.02 (Oct. 91), 0.03 (Nov. 91), etc., as a hint that they weren't really releases so much as snapshots of work in progress.
Linus gathered a few supporters who would exercise and enhance his work and who appreciated receiving (and contributing) fixes as quickly as they were developed. The kernel soon came to support all the system calls expected of a Unix kernel as more restrictions were removed.
Linus ported gcc and bash, so there was a basic compiler and command interpreter in place. (Although, to be precise, the compilations were done under Minix up to version 0.12.) There was some discussion in comp.os.minix about the wisdom of going off and starting another OS, but Linus had his dream, or, some would say, he was stubborn and he persisted.
By January 1992, the 0.12 version took only modest care to build and operate and, thus, contributed a lot towards popularizing Linux.
It should be noted that this was not the only free Unix system for home computers. 386BSD was being developed in California and was a derivative of the Berkeley Unix that had been widely distributed on university campuses around the world. To some extent, 386BSD was a benchmark against which Linux was compared.
At the same time, the various GNU tools were becoming well established in the Unix domain. The standard C compiler, gcc, was regularly found to be better than most vendors' compilers, and the other tools were generally more robust and feature-full than the vendor versions. The fitting of the GNU applications to the Linux kernel was natural and necessary to the success of Linux.
The growing community of Linux users were not afraid to build up a system from sources around the world. A second outside product, the X Window System, provided a GUI interface for Linux users with high-end displays. A third product, NetBSD, provided a springboard to get full Internet support for Linux.
The initial numbering scheme had some limitations, but questions such as “Does 0.11 come before or after 0.2?” were safely avoided and the numbering quickly arrived at a limiting value of 0.99. That version was widely distributed, and it was regarded as the first full-featured version of the Linux kernel. There was, by then, a sizeable community of users who depended on a stable version of the kernel. Although there were many patches and sub-patches to this version—often arriving daily—the basic version 0.99 was suitable for release.
The Great Release took place at the start of 1994, when Linus identified a stable patch level (0.99pl14r), cleaned up a few last problems, and called it good. This operation was called a “code freeze” and resulted in version 0.99pl15, which held steady long enough for bug fixes, but no enhancements, to arrive.
Part of the code freeze and the Great Release was the recognition that Linux had become a suitable foundation for production systems—systems devoted to doing useful work, instead of being the object of a programmer's machinations. This posed a dilemma: how could Linux continue to evolve and yet be stable?
The solution was simple: have two development paths starting from the same point. The even-numbered releases (1.0.0, 1.0.1, 1.0.2, etc.) followed a slow, careful evolution of a production release system and the odd-numbered releases (1.1.0, 1.1.1, 1.1.2, etc.) were to be the fast-changing, experimental system. Version 0.99pl15, with a few fixes, was the basis of these two systems. Some important fixes moved 1.0.0 to 1.0.9 in the early months of 1994, but that system development path has been unchanged since mid-year. By contrast, 1.1.0 underwent over 50 changes in the first 10 months.
Plans are now afoot for the next major release. Again, the stable and well-tested features of the experimental versions (up past 1.1.60) will be incorporated in a production release called 1.2.0. Its twin, version 1.3.0, will be the basis of yet more experimental work on the kernel.
One thing that also happened with the Great Release was the release itself no longer catalogued its changes. This shortcoming was alleviated when Russell Nelson, nelson@crynwr.com volunteered to distribute a change summary shortly after each patch was distributed.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- RSS Feeds
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Validate an E-Mail Address with PHP, the Right Way
- New Products
- Readers' Choice Awards
- Ahh, the Koolaid.
5 hours 23 min ago - git-annex assistant
11 hours 22 min ago - direct cable connection
11 hours 45 min ago - Agreed on AirDroid. With my
11 hours 55 min ago - I just learned this
11 hours 59 min ago - enterprise
12 hours 29 min ago - not living upto the mobile revolution
15 hours 21 min ago - Deceptive Advertising and
15 hours 56 min ago - Let\'s declare that you have
15 hours 57 min ago - Alterations in Contest Due
15 hours 58 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.





Comments
Re: The Humble Beginnings of Linux
:)