Linux 0.01 at 35: The First Release Was an Invitation to Read

On September 17, 1991, Linux 0.01 entered computing history. Thirty-five years later, its most surprising feature is the expectation it set: read the source, understand the limitations and help make the next version possible.

Picture the moment before a familiar machine becomes infrastructure. There is no polished installer, no distribution chooser and no promise that your hardware will cooperate. There is a small kernel, a demanding build process and a document that explains what still needs work. The interesting question is how that could count as a meaningful release.

The answer lies in what was being handed over. Linux 0.01 made an unfinished design inspectable. Its first audience could examine the mechanisms, challenge the decisions and attempt to make it run. On this anniversary in the Nerd Calendar, those modest expectations deserve more attention than a retrospective victory lap.

Why Linux has more than one birthday

August 25, September 17 and October 5, 1991 refer to different steps. Torvalds asked the MINIX newsgroup for feedback in August. September 17 is the date associated with the first source release, version 0.01. In October, a new public announcement described a more usable system. Combining these moments into one launch erases the change between announcing an experiment and giving other people something to work on.

The historical Linux archive entry for 0.01 records September 17, 1991, while also showing that the Git import happened in 2007. That distinction matters: the page preserves a historical release date; it is not evidence that a Git commit was made in 1991.

In his 1992 retrospective, which preserves the early newsgroup posts, Torvalds remembered the first release as occurring around mid-September. The precise archival date and his approximate recollection fit together, but they are different kinds of evidence. Today's anniversary marks the source release, rather than the first public mention of the project.

What did you actually receive?

The original Linux 0.01 release notes describe a kernel for 386-based AT computers, supplied as source that needed configuration and compilation. They list a VGA or EGA display, an AT-style hard-disk controller and even a hard-wired Finnish keyboard layout among the practical assumptions. Torvalds reported producing a working kernel on two machines.

Those details reveal the distance between a developer's successful experiment and a general-purpose product. A machine can work in one room while remaining difficult to reproduce elsewhere. Hardware support, installation tools and helpful error messages are separate pieces of engineering. A version number does not magically supply them.

A kernel is the part of an operating system that manages resources and mediates between programs and hardware. A usable environment also needs programs, libraries and tools. The notes explicitly separate the kernel from those surrounding components and identify GNU software as an important source of tools. Calling 0.01 a complete modern Linux distribution would therefore give readers the wrong picture.

The MINIX dependency that was not a code dependency

One apparent contradiction dissolves as soon as we distinguish code from a development environment. The notes say Linux contained no MINIX code, yet explain that MINIX was needed to bootstrap the system. A program can be built with the help of another system without copying that system's implementation.

Think of a workshop. Borrowing a bench and tools does not make the object you build a piece cut out of the bench. Early Linux needed a place from which its files could be prepared and its build process could be run. Compatibility with the MINIX filesystem also helped the two environments exchange data. These are practical relationships, not proof that one kernel was simply the other with a new name.

This distinction is useful far beyond Linux history. Whenever software claims independence, ask what kind: independent source, independent build tools, independent installation or independent maintenance? Those questions can have different answers. The first release did not need to solve all of them simultaneously to make its own design available for inspection.

Could Linux 0.01 really run?

The sources do not give us one tidy slogan. The contemporary release notes describe a working kernel on two computers, but also say the release was primarily for reading. Torvalds's later retrospective characterises the 0.01 sources as not actually runnable. It would be misleading to suppress either account.

The narrow conclusion is that 0.01 was a source release with severe practical limitations, not a dependable installation experience for strangers. The documents alone do not resolve exactly which preparation, local changes or expectations account for the difference in wording. We should not invent a missing explanation.

That uncertainty improves the story. “It worked for the author,” “the archive builds” and “a reader can reproduce it” are three different claims. A release becomes more useful when its documentation says which claim has been tested. Reading 0.01 today is an opportunity to notice that distinction before a familiar success story makes every early step look inevitable.

The portable future was not the starting design

Early Linux took advantage of the 386 instead of beginning as a neutral blueprint for every processor. The release notes acknowledge the resulting difficulty of porting it. They also describe the kernel, filesystem and memory-management code sharing one runtime space, an early expression of its monolithic design.

These choices help explain what the word “unfinished” meant. Some limitations were missing work; others followed from deliberate tradeoffs. Supporting one concrete machine made it possible to test a real implementation. Supporting many machines would require revisiting assumptions about where hardware-specific behaviour belonged.

Our article on Dennis Ritchie, C and Unix portability explores the larger idea of moving software between machines. Linux 0.01 offers a useful companion case: writing much of a system in C does not automatically remove processor dependencies. A language can make adaptation easier while the design still relies heavily on one architecture.

The GPL story came afterwards

It is easy to project today's licensing story backwards. The 0.01 terms required source availability and intact copyright notices, but prohibited charging for distribution, even handling costs. That was not the later GPL arrangement.

In the release notes for Linux 0.12, Torvalds proposed removing the restriction and adopting GNU copyleft terms, subject to objections from contributors. The document names February 1 as the intended effective date. In its early-1992 context, that is a later milestone than September 1991.

For this anniversary, the historical lesson is straightforward: publishing source and choosing the rules for redistribution are separate decisions. The permissions attached to a project shape how other people can participate. We can recognise the importance of the first source release without pretending that its eventual collaboration model arrived fully formed on the same day.

How to celebrate a release meant for reading

Start with the release notes rather than a modern feature list. Mark three kinds of statement: what the author says works, what remains incomplete and what depends on a particular machine. Then compare the contemporary document with the later recollection. You will have practised a small but valuable form of technical history: separating an artefact from the story eventually told about it.

Linux 0.01 matters because people could begin examining the work while its limitations were still visible. Thirty-five years on, the most useful thing to celebrate is that opening: a design became something others could question, understand and improve. The first release did not have to contain the whole future to make a next step possible.