Happy Birthday, Linus
Today is the birthday of Linus. Although that's essentially a private event for him, there's an interesting historical link to the creation of the Linux kernel, too.
As is well known, before he started writing Linux, Linus coded on a Sinclair QL, a brilliant if rather bizarre system that was based on a cut-down version of the Motorola 68000 chip used in the Amiga, Atari ST, Apple Lisa and Macintosh. Linus was prepared to put up with the limitations of that chip because it offered multi-tasking – and hence the possibility of some advanced programming.
It was for similarly rigorous reasons that he avoided buying a PC for some time: he disliked the underlying architecture of Intel's chips. But when the 80386 came out, Linus finally succumbed, and at the end of 1990, decided to buy a PC. The only problem was finding the funds to pay for it.
One source was a grant from the Finnish government. This was actually a student loan meant for general living costs during his time at university, rather than specifically for buying computers, but Linus not unreasonably felt that a PC was an indispensable item for a student studying computing science, and hence a permitted expense. He finally paid off that debt in November 1992.
To this student loan, Linus added what he termed “Christmas money”. As anyone who has a birthday very near Christmas will tell you, such “Christmas money” almost invariably includes money for the birthday bundled in too, so it's likely that some funds for the PC arrived in the form of birthday presents. Significantly, Linus wasted no time in buying the new computer after Christmas – and hence his birthday. As he told me in 1996: “ I remember the first non-holiday day of the New Year I went to buy a PC.” The specification is rather sobering:
386, DX33, 4 Megs of RAM, no co-processor, 40 Megs hard disc
Having acquired the hardware, Linus then had to wait for the software he wanted – Tanenbaum's Minix operating system. This was one reason why he had finally opted for the PC: Tanenbaum's Unix-like system had been ported to the 80386, and ran quite quickly on it, as Linus discovered during his university studies, which whetted his appetite for this educational tool.
Minix may have been fast on the PC but it was painfully slow in arriving. In his first published interview, in Linux News, Linus recalled what exactly he got up to in the meantime:
As it turned out, Minix wasn't available in Finland (at least I wasn't able to find it easily), so while I got my machine on January 5th 1991 (easy date to remember due to the monthly payments :-), I was forced to run DOS on it for a couple of months while waiting for the Minix disks. So Jan-Feb was spent about 70-30 playing "Prince of Persia" and getting aquainted with the machine.
When Minix finally arrived, I had solved "PoP", and knew a smattering of 386 machine code (enough to be able to get the machine into protected mode and sit there looping). So I installed Minix (leaving some room for "PoP" on a DOS partition), and started hacking.
Getting Minix wasn't altogether a pleasant experience: the keyboard bindings were wrong, and it didn't exactly act like the suns I was used to (ugghh. I *hate* the bourne shell for interactive work). The keyboard was easy to correct (although I didn't like the Minix keyboard driver code), and applying Bruce Evans' 386-patches made the system a bit more "real".
So somewhere around March-91, I had a 386 system running Minix-386, and I was able to install awb's gcc-1.37.1 port. After that, I was able to port bash to the resulting mess, and things looked a bit better. I also spent my time generally fooling around (porting gcc-1.40 and various other programs), and kept on learning about the 386 while doing so (writing small boot-disks that would set up a protected mode environment and print out various inane messages).
In that interview, Linus modestly described the genesis of Linux thus:
"Linux" didn't really exist until about August-91 - before that what I had was essentially just a very basic protected mode system that had evolved from a glorified "Hello world" program into a even more glorified terminal emulator. Linux stopped for quite a while at the terminal emulator stage: I played around with Minix, and used my protected mode program to read news from the univerity machine. No down/upload, but it did a fair vt100 emulation, and did it by using two tasks which communicated from keybodard->modem and modem->screen.
By mid-summer -91, "Linux" was able to read the disk (joyful moment), and eventually had a small and stupid disk driver and a simple buffer cache. So I started out trying to make a filesystem, and used the Minix fs for simple practical reasons: that way I already had a file layout I could test things on. After some more programming (talk about glossing things over), I had a very simple UNIX that had some of the basic functionalities of the real thing: I could run small test-programs under it.
By that time I looked around for some standards texts - I decided early on that I didn't want to write the user-level programs, and that in order to easily port things I'd either have to make the new system compatible with Minix (ugghh) or follow some other kind of standard. What I wanted was a POSIX guide, not so much to be 100% posix, but in order not to do anything really stupid I'd regret later.
My quest for the posix standards failed, as the posix standard committee sells the standard to feed itself as I found out, but I did get a good pointer to the (then very alpha and unsupported) GNU libc.a, which had an early manual accompanying it. The manual was of some help, but the biggest help was actually the contact to the person who pointed it out to me: email@example.com. He was/is the organizer of the pub/OS subdirectory at nic.funet.fi, and was interested in giving Linux a home at nic.
Back then, I was only idly thinking about making my system available (and I had no real time-table), but arl happily created a pub/OS/Linux subdirectory at nic, and thus also gave the system it's name. I wasn't really ready for a release yet, so the directory contained just a README for about a month ("this directory is for the freely distributable Minix clone" or something like that). Arl probably thought the project wouldn't come to anything.
I think we can safely say that “arl” - Ari Lemmke, a member of the Helsinki University staff – was a little mistaken on that point. It's truly extraordinary to contemplate that Linus's “glorified "Hello world" program” is now running nearly 90% of the world's top supercomputers. And at the other end of the scale, it is making huge in-roads into the smartphone market, which means that one day there may be billions of people with the Linux kernel in their pocket.
Indeed, it is difficult to imagine what the world would be like today had Linus not bought that PC in 1991 with his Christmas and birthday money. There could hardly be a better time than today to thank him for Linux, his amazing gift to us, and to wish him many happy returns.
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
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
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