Visual summary of operating lessons from Linus Torvalds.

Lessons from Linus Torvalds

Linus Torvalds created the Linux kernel and Git, the underlying software for most modern servers and version control. He proved that open collaboration yields better technology than centralized corporate models, provided someone strictly enforces practical design. This collection draws from decades of his mailing list arguments and interviews to explain his approach to building infrastructure and protecting data structures.

Part 1: The Philosophy of Open Source

  1. On the survival of the best: "In open source, we feel strongly that the design which is best is the one which is used." — Source: [AZ Quotes]
  2. On Linus's Law: "Given enough eyeballs, all bugs are shallow." — Source: [Wikipedia]
  3. On practical superiority: "The theory was that if you have a lot of people looking at the code, you'll find the bugs. The practice is that if you have a lot of people looking at the code, you'll find the bugs and you'll find the people who can fix them." — Source: [TED]
  4. On free software: "Software is like sex: it's better when it's free." — Source: [Goodreads]
  5. On corporate adoption: "If Microsoft ever does applications for Linux it means I've won." — Source: [Wired]
  6. On pragmatic engineering: "I’m not a visionary. I’m a very pragmatic engineer. I just want to write good code and the open source model lets me do that without the artificial constraints of a corporate structure." — Source: [Linux Foundation]
  7. On controlling projects: "I don't think you can ever control an open source project. You can guide it, you can sometimes gently prod it, but you can never control it." — Source: [Just for Fun]
  8. On sharing code: "Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it." — Source: [LKML]
  9. On standards: "Standards are paper. I use paper to wipe my butt every day. That's how much that paper is worth." — Source: [Quora]
  10. On world domination: "I stopped doing the 'world domination' joke long ago, because it seemed to become less of a joke as time went on." — Source: [Linux Journal]

Part 2: Software Design and Architecture

  1. On data structures: "I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships." — Source: [Git Mailing List]
  2. On simple design: "git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around." — Source: [Git Mailing List]
  3. On ugly systems: "An ugly system is one in which there are special interfaces for everything you want to do. Unix is the opposite." — Source: [Just for Fun]
  4. On what users actually want: "Nobody wants an operating system. What everybody wants is this magical toy that can be used to browse the Web, write term papers, play games, balance the checkbook." — Source: [Just for Fun]
  5. On trial and error: "Don't ever make the mistake of thinking that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence much too much credit." — Source: [Git Mailing List]
  6. On execution over ideas: "Talk is cheap. Show me the code." — Source: [LKML]
  7. On theory versus practice: "Theory and practice sometimes clash. And when that happens, theory loses. Every single time." — Source: [LKML]
  8. On software complexity: "The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence." — Source: [Wikiquote]
  9. On the cost of abstraction: "Inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app." — Source: [LKML]

Part 3: Programming Languages and Compilers

  1. On C++: "C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it." — Source: [LKML]
  2. On filtering out bad programmers: "Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C." — Source: [LKML]
  3. On hidden language features: "C++ leads to really really bad design choices. You invariably start using the 'nice' library features of the language like STL and Boost and other total and utter crap, that may 'help' you program, but causes infinite amounts of pain when they don't work." — Source: [LKML]
  4. On kernel development in C++: "In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA." — Source: [LKML]
  5. On exception handling: "The whole C++ exception handling thing is fundamentally broken. It's especially broken for kernels. Any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel." — Source: [LKML]
  6. On C transparency: "When I read C, I know what the assembly language will look like. And that's something I care about." — Source: [TED]
  7. On hardware interaction: "I have yet to see a language that comes even close to C in that respect... if you think like a computer, writing C actually makes sense." — Source: [YouTube]
  8. On early compiler constraints: "The reason it works that way is the people who designed C designed it at a time when compilers had to be simple and the language had to be kind of geared towards what the output was." — Source: [YouTube]
  9. On object models: "Any language that lets you hide things like memory allocations behind your back isn't a good choice for a kernel. You get abstraction without realizing what it costs you." — Source: [LKML]

Part 4: Leadership and Management

  1. On his management style: "Much of Linux's success can be attributed to my own personality flaws: 1) I'm lazy; and 2) I like to get credit for the work of others." — Source: [Just for Fun]
  2. On motivation: "I did learn fairly early that the best and most effective way to lead is by letting people do things because they want to do them, not because you want them to." — Source: [Just for Fun]
  3. On being a dictator: "Benevolent dictator? No, I'm just lazy. I try to manage by not making decisions and letting things occur naturally. That's when you get the best results." — Source: [Just for Fun]
  4. On enabling others: "The best leaders enable others to make decisions for them." — Source: [Goodreads]
  5. On intelligence and work: "Intelligence is the ability to avoid doing work, yet getting the work done." — Source: [AZ Quotes]
  6. On maintainership: "One of the most important things for a maintainer isn't that he's a super engineer. It's that you're responsive and people can rely on you being there 24/7, 52 weeks a year." — Source: [Linux Foundation]
  7. On responsibility: "I am not willing to take patches from people who don't clean up after their problems, and don't admit that it's their problem to fix." — Source: [LKML]
  8. On predictability: "In this context, 'trustworthy' is a lot about not surprising people... it's not some kind of fuzzy, feel-good Kumbaya trust where we all love each other; it's more about the fact that people know my opinions and where I stand on things." — Source: [CIO.com]
  9. On being the boss: "If you still don't like it, that's OK: that's why I'm boss. I simply know better than you do." — Source: [USENET]
  10. On admitting mistakes: "Part of being honest is ending up having to sometimes say, 'I was wrong.' That can be hard. But I make it easier for me by often writing my flames something along the lines of: 'You're a completely incompetent idiot...'" — Source: [CIO.com]

Part 5: Git and Version Control

  1. On creating Git: "So Git is my second big project, which was only created for me to maintain my first big project. This is literally how I work." — Source: [TED]
  2. On SCM hatred: "I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world, and I hated all SCMs with a passion." — Source: [Linux Foundation]
  3. On naming conventions: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'." — Source: [GitHub Blog]
  4. On the meaning of Git: "git can mean anything, depending on your mood. Random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of 'get' may or may not be relevant." — Source: [Git README]
  5. On CVS: "I saw it as a solution to my problems, and I obviously thought it was superior. Even literally 20 years ago to the day, I thought that first version, which was pretty raw—to be honest, even that version was superior to CVS." — Source: [GitHub Blog]
  6. On BitKeeper: "BK got most things right and having a local copy of the repository and distributed merging was a big deal." — Source: [Linux Foundation]
  7. On branching and merging: "If you have a centralized system, branching is hard, and merging is even harder. In a distributed system, branching and merging are the only things you do." — Source: [Google Tech Talk]
  8. On SVN: "Subversion has been the most pointless project ever started... it used CVS as a role model. If you are starting a version control system and you look at CVS and say 'let's do that, but better', you are already entirely missing the point." — Source: [Google Tech Talk]
  9. On local speed: "In Git, everything is local, which means it's fast. I can do a diff of the whole kernel tree in less than a tenth of a second." — Source: [Google Tech Talk]

Part 6: Security and Bug Fixing

  1. On security bugs: "Some security people have scoffed at me when I say that security problems are primarily 'just bugs.' Those security people are fcking morons. Because honestly, the kind of security person who doesn't accept that security problems are primarily just bugs, I don't want to work with." — Source: [LKML]*
  2. On the security industry: "The economics of the security world are all horribly, horribly nasty and are largely based on fear, intimidation and blackmail." — Source: [Wired]
  3. On security absolutists: "Security people are often the black-and-white kind of people that I can't stand." — Source: [Google Tech Talk]
  4. On single-minded security: "I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them." — Source: [LKML]
  5. On trust networks: "If you have ever done any security work — and it did not involve the concept of 'network of trust' — it wasn't security work, it was masturbation." — Source: [Google Tech Talk]
  6. On usability: "If you force people to bypass security to do ordinary tasks, and train them to constantly enter the root password for everything, you don't actually have any security. It's like the password policy that's so impractical that everyone sticky-notes passwords to their monitors." — Source: [Google+]
  7. On backdoors: "Oh, Christ. It was obviously a joke, no government agency has ever asked me for a backdoor in Linux. Really. Cross my heart and hope to die, really." — Source: [Mashable]
  8. On hardware RNGs: "The fact is, even if you worry about some back door for the NSA... we can pretty much depend on it. We still do our own hashing on top of whatever entropy we get out of rdrand, and we would still have all our other stuff. Plus the instruction is public and testable — if Intel did something wrong, they'll be very embarrassed." — Source: [LKML]
  9. On bugs vs regressions: "We don't fix bugs because they are bugs, we fix bugs because they cause regressions. If a bug has been there since day one, and fixing it breaks something else, we don't fix the bug." — Source: [LKML]

Part 7: Motivation and Work Environment

  1. On coding for fun: "Most of the good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program." — Source: [Just for Fun]
  2. On the three stages of evolution: "Everything in life progresses in that order. The first is survival. The second is social order. The third is entertainment. The meaning of life is to reach that third stage." — Source: [Just for Fun]
  3. On needing problems to solve: "I don't code for — well, I do code for fun — but I want to code for something meaningful, so every single project I've ever done has been something I needed." — Source: [TED]
  4. On sleep: "I'm a firm believer in sleep. Some people think that's just being lazy, but I want to throw my pillow at them... You may lose a few hours of your productive daytime if you sleep, oh, say, ten hours a day, but those few hours when you are awake you're alert, and your brain functions on all six cylinders." — Source: [Just for Fun]
  5. On stubbornness: "That's about being stubborn. That's about, like, just starting something and not saying, 'OK, I'm done, let's do something else—Look: shiny!'" — Source: [TED]
  6. On nature: "I wouldn't know nature if it jumped out and bit me." — Source: [Linux Journal]
  7. On not being a people person: "I'm not a people person; it's not something I'm particularly proud of, but it's part of me... sometimes I'm also—shall we say, 'myopic' when it comes to other people's feelings." — Source: [TED]
  8. On his work environment: "My office is the most boring office you'll ever see. And I sit there alone in the quiet. If the cat comes up, it sits in my lap. And I want to hear the cat purring, not the sound of the fans in the computer." — Source: [TED]
  9. On making things: "I like to read code, I like to write code. But what I really like is the feeling of creating something that is actually used by people." — Source: [Linux Foundation]

Part 8: Communication and Conflict

  1. On being subtle: "On the Internet, nobody can hear you being subtle... I'd rather flame people for doing stupid things and call them stupid, rather than try to be too polite to the point where people didn't understand how strongly I felt about something." — Source: [LKML]
  2. On strong language: "One of the reasons we have this culture of strong language... is that when it comes to technical people with strong opinions and with a strong drive to do something technically superior, you end up having these opinions show up as sometimes pretty strong language." — Source: [TED]
  3. On offending people: "I like offending people, because I think people who get offended should be offended." — Source: [LKML]
  4. On hardware vendors: "Nvidia, fck you!" — Source: [Aalto University]*
  5. On politeness vs truth: "I care about the truth, and I care about being honest, even if it sometimes means being abrasive." — Source: [LKML]
  6. On email as a medium: "The advantage of email is that it removes the personal interactions and forces you to focus on the technical arguments. The disadvantage is that it removes the personal interactions and makes it easy to be an a-hole." — Source: [Linux Foundation]
  7. On breaking user space: "WE DO NOT BREAK USERSPACE! Seriously, how hard is this to understand? If a change causes a user program to break, it's a regression, and it gets reverted." — Source: [LKML]
  8. On arguments: "I don't think it's healthy to agree all the time. If everybody agrees, you're not pushing the boundaries enough." — Source: [TED]
  9. On apologizing for personal attacks: "My flippant attacks in emails have been both unprofessional and uncalled for. Especially at times when I made it personal. In my quest for a better patch, this made sense to me. I know now this was not OK and I am truly sorry." — Source: [LKML]
  10. On learning empathy: "I need to change some of my behavior, and I want to apologize to the people that my personal behavior hurt and possibly drove away from kernel development entirely... I am going to take time off and get some assistance on how to understand people’s emotions and respond appropriately." — Source: [LKML]