Linus Torvalds
Linus Torvalds is the creator of the Linux kernel. His preferred programming language is C. Linus started out programming in what he assumed to be "assembler" when he was really just hard-coding binaries with 0's and 1's. This may be why he is very good at micro-optimizations when coding in C.
Creator of the Linux Kernel
Linus Torvalds at Aalto Center for Entrepreneurship (ACE) in Otaniemi on June 14, 2012.
Torvalds created the Linux kernel because wanted something Unix-like which he could use on a regular computer. He fell in love with regular Unix at the University and wanted something similar on his home computer. There was nothing like that available at the time so he wrote his own Unix-clone.
Torvalds wrote this in the "Notes for linux release 0.01" when he first released his kernel to the public in 1991:
"This is a free minix-like kernel for i386(+) based AT-machines. Full source is included, and this source has been used to produce a running kernel on two different machines. Currently there are no kernelbinaries for public viewing, as they have to be recompiled for different machines. You need to compile it with gcc (I use 1.40, don't know if 1.37.1 will handle all __asm__-directives), after having changed the relevant configuration file(s). "
Other Notable Projects
Torvalds is the author of the very popular git version control software which has been adopted by most free software project as well as many commercial projects. The largest source code repository as of 2019 is Microsoft GitHub. It is, as the name implies, based on the git software.
View on C++
Torvalds had this to say about C++ in an e-mail exchange in 2007:
"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. 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."
Kernel development model
The Linux kernel is known to be very stable. This is in a large part due to Linus policy of "We do NOT break user-space". If a kernel change breaks a user-space program then it is, in his view, a kernel bug - regardless even if it's because a user-space program relies on some quirk in the kernel.
Ability to say no
There are many examples of the importance of saying no to code which would be bad for the kernel.
David Howells submitted a patch which would allow a secure kernel to add keys willy nilly in 2013.
"Hi Linus,
Can you pull this patchset please?
It provides a facility by which keys can be added dynamically to a kernel that is running in secure-boot mode. To permit a key to be loaded under such a condition, we require that the new key be signed by a key that we already have (and trust) - where keys that we "already have" could include those embedded in the kernel, those in the UEFI database and those in cryptographic hardware.
Now, "keyctl add" will already handle X.509 certificates that are so signed, but Microsoft's signing service will only sign runnable EFI PE binaries.
We could require that the user reboot into the BIOS, add the key, and then switch back, but under some circumstances we want to be able to do this whilst the kernel is running."
Torvalds had this to say about said patch-set:
"Not without a lot more discussion first.
Quite frankly, this is f*cking moronic. The whole thing seems to be designed around stupid interfaces, for completely moronic reasons. Why should we do this?
I already dislike our existing X.509 parser. And this makes the idiotic complicated interfaces, and now it goes up to 11."
Torvalds has known to be a bit harsh when he has had to explain kernel development fundamentals to incompetent people. This resulted in him being sent to a re-education camp and the introduction of a CoC with Linux Kernel 4.19. Many feared that this would hamper his ability to clearly say no to buggy code and foolish design decisions. These fears were unfounded and Linus remains very based.
Personal Life
Torvalds lives in the US. Further information about his personal life is not required or desired as it has little to no relevance on his management of the Linux kernel.
Videos
Interviews:
Notable Quotes
Announcing Linux 0.01
"This is a free minix-like kernel for i386(+) based AT-machines. Full source is included, and this source has been used to produce a running kernel on two different machines. Currently there are no kernel binaries for public viewing, as they have to be recompiled for different machines. You need to compile it with gcc (I use 1.40, don't know if 1.37.1 will handle all __asm__-directives), after having changed the relevant configuration file(s). "
- See Notes for linux release 0.01 for the full Linux 0.1 release announcement.
On breaking user-space programs
"WE DO NOT BREAK USERSPACE!
Seriously. How hard is this rule to understand? We particularly don't break user space with TOTAL CRAP. I'm angry, because your whole email was so _horribly_ wrong, and the patch that broke things was so obviously crap. The whole patch is incredibly broken shit. It adds an insane error code (ENOENT), and then because it's so insane, it adds a few places to fix it up ("ret == -ENOENT ? -EINVAL : ret").
The fact that you then try to make *excuses* for breaking user space, and blaming some external program that *used* to work, is just shameful. It's not how we work.
Fix your f*cking "compliance tool", because it is obviously broken. And fix your approach to kernel programming."
On Code Which Does Not Compile
"> KVM: nVMX: Emulate MTF when performing instruction emulation
This was committed today, and it's complete and utter garbage:
- CommitDate: 7 hours ago
It doesn't even compile. Just in the patch itself - so this is not a merge issue, I see this:
- +static void vmx_skip_emulated_instruction(struct kvm_vcpu *vcpu)
- + return skip_emulated_instruction(vcpu);
- ..
- - .skip_emulated_instruction = skip_emulated_instruction,
- + .skip_emulated_instruction = vmx_skip_emulated_instruction,
ie note how that vmx_skip_emulated_instruction() is a void function, and then you have
- return skip_emulated_instruction(vcpu);
in it, and you assign that garbage to ".skip_emulated_instruction" which is supposed to be returning 'int'.
So this clearly never even got a _whiff_ of build-testing. The thing is completely broken.
Stop sending me garbage.
You're now on my shit-list, which means that I want to see only (a) pure fixes and (b) well-tested such. Nothing else will be pulled."
February 12th, 2020
On Build-Testing
" On Wed, Feb 12, 2020 at 11:19 AM [REDACTED] <[REDACTED]@redhat.com> wrote:
- >> So this clearly never even got a _whiff_ of build-testing.
- >
- > Oh come on.
Seriously - if you don't even _look_ at the warnings the build generates, then it hasn't been build-tested.
I don't want to hear "Oh come on". I'm 100% serious.
Build-testing is not just "building". It's the "testing" of the build too. You clearly never did _any_ testing of the build, since the build had huge warnings.
Without the checking of the result, "build-testing" is just "building", and completely irrelevant.
If you have problems seeing the warnings, add a "-Werror" to your scripts.
I do not want to see a _single_ warning in the kernel build. Yes, we have one in the samples code, and even that annoys the hell out of me.
And exactly because we don't have any warnings in the default build, it should be really really easy to check for new ones - it's not like you have to wade through pages of warnings to see if any of them are your new ones.
So no "Oh come on". You did *zero* testing of this crap, and you need to own that fact instead of making excuses about it.
Linus"
("Re: [GIT PULL] KVM changes for Linux 5.6-rc2")
On Critics
""Honestly, I think those emails are more about Debian culture than they are about me, and you should probably ask the Debian people about them rather than me,""
Links
Linux Torvalds does not have anything which resembles a personal website or a blog. What he does have is linux.git at git.kernel.org.
Enable comment auto-refresher