Linus Torvalds Reveals 30‑Year Linux Journey: Kernel Insights & Git Origins
Celebrating Linux’s 30th anniversary, Linus Torvalds discusses the kernel’s evolution from a hobby project to a ubiquitous OS, the creation of Git, licensing choices, development processes, community governance, and future challenges, offering deep insights into open‑source engineering and collaborative software development.
Linux was born in 1991, thirty years ago. Although it started as Linus’s personal project rather than a grand dream to develop a new operating system, today Linux is everywhere.
Thirty years ago, when Linus Torvalds first released the Linux kernel, he was a 21‑year‑old student at the University of Helsinki. He announced, “I’m developing a (free) operating system (just as a hobby, not going to be big or professional…)”. Thirty years later, more than 70% of smartphones and all top‑500 supercomputers run Linux. Clearly, Linux is both massive and professional.
For the past 30 years, Linus Torvalds has led Linux kernel development, inspiring countless developers and open‑source projects. In 2005 he created Git to manage kernel development. Git has become the most popular version‑control system, trusted by countless open‑source and proprietary projects. To mark Linux’s 30th anniversary, Linus answered an interview by Tag 1 Consulting’s founder Jeremy Andrews; InfoQ translated the interview for readers. This article focuses on Linux kernel development and Git.
Linux Kernel Development
Jeremy Andrews: Linux is everywhere, the inspiration for the whole open‑source world. Of course, it wasn’t like that from the start. In 1991 you posted a Linux kernel on the comp.os.minix Usenet newsgroup. Ten years later you wrote a book called “Just for Fun: The Story of an Accidental Revolutionary”. When did you realize Linux was more than a hobby?
Linus Torvalds: It may sound absurd, but I realized it very early. By the end of 1991 (and early 1992) Linux was already much bigger than I expected.
At that time there were only a few hundred users (actually not “users”, because people kept fixing and patching it), and I never imagined Linux would grow so large. The biggest turning point was when I realized other people were using it and were interested; it started to have its own life. People began sending patches, and the system could do far more than I had imagined.
In April 1992 X11 was ported to Linux – a major step that gave Linux a GUI and a whole new set of functions.
Initially I had no grand plan. It was just a personal project, not a great dream to build a new OS. I wanted to understand my new PC hardware.
When I released the first version I mainly wanted to “see what I had done”. I hoped others would find it interesting, but it was not a truly usable OS – more a proof‑of‑concept and a few months of personal work.
The shift from a personal project to others using it, giving feedback, reporting bugs, and sending patches was a huge change for me.
The original license was “you may distribute the source, but you may not sell it”.
At the time commercial Unix was too expensive for a poor student, so I wanted the source to be openly available so people could provide patches, especially those who could not afford expensive computers and OSes.
By the end of 1991 (or early 1992) I changed the license to GPLv2 because someone wanted to distribute it on floppy disks to a local Unix user group and recoup the cost. I thought “free” wasn’t the most important thing; “open source” was.
Later changes were incremental, though some (IBM joining, Oracle port, Red Hat IPO, Android on phones) were big steps. But the initial realization that strangers were using Linux was the most revolutionary.
Jeremy Andrews: Did you ever regret changing the license? Did you ever regret others making money from your system?
Linus Torvalds: I have never regretted it. I’m doing well, not rich but a well‑paid software engineer, and I fully believe the license was crucial to Linux’s and Git’s success. When everyone has equal rights and no one has special privileges, people are happier.
Building a good community under a “second‑class citizen” model is hard. Dual‑licensing introduces extra paperwork and friction.
BSD‑style licenses can lead to projects splitting and becoming proprietary when they become commercially valuable.
GPLv2 strikes a perfect balance between equal rules and requiring contributions back to the community.
Anyone can fork the project, maintain their own version, and that openness is a strength of GPLv2.
Branching isn’t a problem as long as good parts can be merged back; that’s where GPLv2 shines.
Beyond licensing, the mindset matters: merging branches can be hindered by “rivalry” rather than technical issues, but Linux avoids that by treating branching as natural.
Money isn’t a good motivator; shared purpose and partnership are.
Jeremy Andrews: How did you find the GPLv2 license? How much time did you spend researching other licenses?
Linus Torvalds: The BSD vs GPL debate was intense. I read newsgroups (comp.arch, comp.os.minix) and saw discussions. Two main influences were gcc and Lars Wirzenius, who liked discussing licenses.
Choosing GPLv2 wasn’t a big political decision; I chose a known license with some legal backing.
Jeremy Andrews: How does a typical day look for you? How much time on coding, code review, email? How do you balance personal life?
Linus Torvalds: I write very little code now; most of my work is email and communication. When I do code, it’s usually to illustrate a solution with a small snippet, not a full program.
Most of my time is spent on email, which I consider part of my job. I also do some code review, but often patches have already been reviewed by others.
My main role is “being there”, managing and releasing, rather than writing low‑level code.
Jeremy Andrews: What is your work environment like? Do you prefer a dark room, quiet, music? What hardware and editor do you use?
Linus Torvalds: I keep the blinds closed, work at a cluttered desk with two 4K monitors, a powerful PC, and several laptops for testing. I prefer quiet, SSDs, and no noisy fans.
Code review is done in a terminal using “micro‑emacs”, a very old editor I’ve customized, not vi.
I run Fedora on all machines; I’m not attached to any particular distro.
Jeremy Andrews: How do you handle the massive volume of kernel mailing‑list email?
Linus Torvalds: I don’t read the mailing list directly; I let it archive and only look at messages that require my attention.
We use lore.kernel.org for archiving and tooling, which has improved the workflow.
Email remains the primary communication channel because patches can be attached and it works across time zones.
Jeremy Andrews: Summarize interesting things in kernel development since version 3.0.
Linus Torvalds: ARM matured, ARM64 became a main architecture, many new drivers and core features. The release model stabilized with time‑based releases; the process has been consistent for the past ten years.
Jeremy Andrews: What is the current release process? How do rc1 and rc2 differ? What happens if regressions appear after release?
Linus Torvalds: Two‑week merge window, then 6‑8 weeks of release candidates, then final release – about every 10 weeks. If regressions appear, we fix them in the stable tree or backport patches.
Jeremy Andrews: Will Linux support Apple’s ARM64 Macs soon?
Linus Torvalds: Early support may land in 5.13, but hardware drivers are the main challenge. ARM64 is growing in servers (Graviton2, Altra) and will improve over time.
Jeremy Andrews: If you could rewrite the kernel from scratch, what would you change?
Linus Torvalds: We would rewrite where needed, but we value backward compatibility, so many compatibility layers would stay.
Some legacy drivers are removed when they no longer make sense.
Jeremy Andrews: Could Rust replace C in the kernel?
Linus Torvalds: I don’t think Rust will replace C, but it may be used for new drivers or subsystems.
Jeremy Andrews: What part of the kernel are you most proud of?
Linus Torvalds: The VFS layer (especially pathname lookup) and the VM layer. VFS handles caching, locking, and serialization across many filesystems using lock‑free algorithms (RCU) and special lockref locks.
Jeremy Andrews: How does Linux’s pathname lookup outperform other OSes?
Linus Torvalds: It must be fast, scalable on SMP, and handle caching and locking centrally, which we achieve with RCU and lockref, giving performance that scales to thousands of CPUs.
Jeremy Andrews: How did COVID‑19 affect kernel development?
Linus Torvalds: Very little; we already work almost entirely via email, so the impact was minimal aside from the kernel summit being moved online.
Version Control System Git
Jeremy Andrews: Linux is one of many contributions you’ve made. In 2005 you created Git. Why did you hand over its maintenance to Junio Hamano so quickly, and how did you choose him?
Linus Torvalds: I didn’t set out to create a new SCM; I needed one because BitKeeper was no longer viable. I wanted others to maintain it. Junio was one of the first contributors and showed “good taste” – the ability to choose clean solutions.
Git’s biggest improvement is its speed and usability for ordinary users, and many early shell scripts have been replaced, making patch application faster.
Git’s governance mirrors Linux’s: no special “commit bit”, everyone can clone, develop, and merge back, avoiding political “cliques”.
Jeremy Andrews: Any Git features that impressed you or that you’d like to add?
Linus Torvalds: Most features I need were there from the start; recent improvements focus on user experience and performance.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
MaGe Linux Operations
Founded in 2009, MaGe Education is a top Chinese high‑end IT training brand. Its graduates earn 12K+ RMB salaries, and the school has trained tens of thousands of students. It offers high‑pay courses in Linux cloud operations, Python full‑stack, automation, data analysis, AI, and Go high‑concurrency architecture. Thanks to quality courses and a solid reputation, it has talent partnerships with numerous internet firms.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
