It's *Not* The 15th Birthday of Linux – and Why That Matters
Last week, I wondered whether I'd gone back in time. Everywhere I went online – on news sites, blogs and Twitter – people were celebrating the 15th birthday of Linux, it seemed. “How is this possible?” I asked myself. “Since Linux was started in 1991, that must mean we are in 2006: have I fallen through a wormhole into the past?”
When I actually read some of these birthday pieces, it turned out that they were celebrating the release of version 1.0 of Linux, which took place at 22.38 on 13 March, 1994. Fortunately, it seemed like I would not need to live through the last three years again. But then I was left with the perplexing question why people were marking this arbitrary event.
Just how arbitrary it was can be seen from the consolidated Linux kernel history. This shows that on 16 January 1992 the kernel was at version 0.12, but became version 0.95 a couple of months later. Version 0.99 was released in December 1993, and there then followed the most extraordinary series of incremental updates, passing through 0.99.1, 0.99.12, 0.99.12a, 0.99.12z, 0.99.15a, 0.99.15j and finally Pre-1.0. Towards the end of this odyssey, there were updates every few days – sometimes even several on one day.
Clearly what was going on over these months was an almost obsessive honing of the Linux kernel. But the difference between version 0.99.14z, say, and version 1.0 is slight: it's not that the former was unusable, and the latter sheer perfection. Indeed, there is nothing extraordinarily special about version 1.0 compared to its immediate forebears, except for its numbering.
This is one of the most profound strengths of free software - that the software is never really “finished”, with the corollary that it is also never really *not* finished. Huge quantum jumps are rare: mostly it's more granular.
That's why I think it's misguided to “celebrate” Linux 1.0: it gives the impression that free software is like any other proprietary bit of code, rubbish until you hit the magic release number, and somehow finished when you do. If you want to celebrate Linux (and that's an eminently sensible thing to do), the only possible date to choose is when the project was started - after all, that's what the "birth" bit in birthday means. The trouble is, even that date doesn't exist.
Linus never really intended to create what he first called Freax – and what later became Linux. The journey began in one sense when he bought his shiny new PC on 5 January, 1991: “386, DX33, 4 Megs of RAM, no co-processor; 40 Megs hard disc” as he told me over a decade ago. He spent most of his time playing the original “Prince of Persia” game, as well as exploring the capabilities of his machine.
One important aspect that intrigued him was task-switching:
I was testing the task-switching capabilities, so what I did was I just made two processes and made them write to the screen and had a timer that switched tasks. One process wrotes “A”, the other wrote “B”, so I saw “AAABBBB” and so on.
Was that the start of Linux? Clearly not, in the sense that Linus was just playing around with a bit of rough code, trying things out. And yet those two processes later began to morph into something else – to begin with, into a simple terminal emulator so that he could read Usenet newsgroups on the computer system at Helsinki University:
I changed those two processes to work like a terminal emulation package. You have one process that is reading from the keyboard and sending to the modem, and the other is reading from the modem and sending to the screen.
Again, that may not sound much like an operating system, but to create his terminal emulation software he had to write drivers for the peripherals. When he added a file system based on the Minix operating system (which was the main reason he had bought the PC in the first place) the combined result was more than the sum of its parts. As he himself said:
Essentially when you have task-switching, you have a file system, you have device drivers – that's Unix.
Not only did Linux grow organically as it edged towards (and past) 1.0, but it began in exactly the same unplanned fashion: some hacking around produced something, that something turned into something else, and before he knew it, Linus had an operating system.
This is typical of many other open source projects, and increasingly of other projects inspired by their processes – and success. Think of Apache, which began as a series of patches to the NCSA Web server; think of Larry Wall's Perl, which began as a simple tool for use with his rn newsreader; think of Wikipedia, which was designed as a quick hack to provide a feed of half-finished articles for the main Nupedia system. All these stand in stark contrast to the top-down approach of traditional software development, where people sit down to design a product, with a bunch of features that it is felt the consumers need.
Marking anniversaries of nominal “major” releases for Linux or any other project is harmless enough, but tends to obscure one of the key differences between free software and traditional projects. What we should really be celebrating is the extraordinary power of serendipity that this kind of free creation allows – something that does not happen by numbers.
You can follow me on Twitter at @glynmoody.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide