Linus Torvalds

25 Years Later: Interview with Linus Torvalds

Robert Young — Tue, 02 Apr 2019 17:59:48 +0000

Linux Journal's very first issue featured an interview between LJ's first Publisher, Robert Young (who went on to co-found Red Hat among other things), and Linus Torvalds (author of the Linux kernel). After 25 years, we thought it'd be interesting to get the two of them together again. You can read that first interview from 1994 here.

Interview: Linus Torvalds and Robert Young

Robert Young: It is a great pleasure to have an excuse to reach out to you. How are you and your family? Your kids must be through college by now. Nancy and I and our three daughters are all doing well. Our eldest, Zoe, who was 11 when Marc and I started Red Hat, is expecting her second child—meaning I'm a grandparent.

Linus Torvalds: None of my kids are actually done with college yet, although Patricia (oldest) will graduate this May. And Celeste (youngest) is in her senior year of high school, so we'll be empty-nesters in about six months.

All three are doing fine, and I suspect/hope it will be a few years until the grandparent thing happens.

Bob: When I first interviewed you back in 1994, did you think that you'd be still maintaining this thing in 2019?

Linus: I think that by 1994 I had already become surprised that my latest project hadn't just been another "do something interesting until it does everything I needed, and then find something else to do" project. Sure, it was fairly early in the development, but it had already been something that I had spent a few years on by then, and had already become something with its own life.

So I guess what I'm trying to say is not that I necessarily expected to do it for another few decades, but that it had already passed the bump of becoming something fairly big in my life. I've never really had a long-term plan for Linux, and I have taken things one day at a time rather than worry about something five or ten years down the line.

Bob: There is a famous old quote about the danger of achieving your dreams—your running joke back in the day when asked about your future goals for Linux was "world domination". Now that you and the broader Open Source/Free Software community have achieved that, what's next?

Linus: Well, I stopped doing the "world domination" joke long ago, because it seemed to become less of a joke as time went on. But it always was a joke, and it wasn't why I (or any of the other developers) really did what we did anyway. It was always about just making better technology and having interesting challenges.

Go to Full Article

Removing Profanity from the Source Tree

Zack Brown — Tue, 12 Feb 2019 12:45:00 +0000

by Zack Brown

Warning: this article contains profanity.

Linus Torvalds recently stepped away from kernel development temporarily in order to think about how to be less harsh with developers in certain situations. Simultaneous with his departure was a patch introducing a new Code of Conduct into the kernel source tree. The effects of this are beginning to be felt.

Jarkko Sakkinen recently posted a patch to change a kernel comment containing the word "fuck" to use the word "hug" instead. So the code comment, "Wirzenius wrote this portably, Torvalds fucked it up" would become "Wirzenius wrote this portably, Torvalds hugged it up".

Steven Rostedt replied to this, saying that the code in question had changed so much that the original comment was out of date, and it should just be removed entirely. He said, "that will be an accurate change with or without CoC."

Jonathan Corbet remarked, "I'd much rather see either deletion or a rewrite over bleeping out words that somebody might not like." And Jiri Kosina agreed, saying, "turning comments into something that often doesn't make sense to anybody at all is hardly productive."

Sergey Senozhatsky pointed out that Linus was the author of the original self-deprecating comment. He asked, "Linus has made a comment, in his own words, about his own code. Why would anyone be offended by this?"

And Tobin C. Harding remarked of the original code comment, "This is my favourite comment to date in the kernel source tree. Surely there are still some people working on the kernel that do so for fun. I actually laughed out loud when I first stumbled upon this file."

In a different thread, Kees Cook said he agreed with removing "fuck" from the source tree, but felt that the word "hug" was not a good replacement, since it didn't maintain the original meaning. He said:

"This API is hugged" doesn't make any sense to me. "This API is hecked" is better, or at least funnier (to me). "Hug this interface" similarly makes no sense, but "Heck this interface" seems better. "Don't touch my hecking code", "What the heck were they thinking?" etc...."hug" is odd.

He added, "Better yet, since it's only 17 files, how about doing context-specific changes? 'This API is terrible', 'Hateful interface', 'Don't touch my freakin' code', 'What in the world were they thinking?' etc.?"

Go to Full Article

Why Linux Is Spelled Incorrectly

Bryan Lunduke — Wed, 30 Jan 2019 13:15:15 +0000

by Bryan Lunduke

You ever see an injustice in the world—one so strong, so overwhelming—that, try as you might, you just can't ignore it? A crime that dominates your consciousness beyond all others? That drives you, even in the face of certain defeat, to action?

Mine is...Linux.

Not the existence of Linux. Linux is amazing. Linux powers the world. Linux is, as the kids say, totally tubular.

It's the name. It's the name that makes me Hulk out. Specifically, it's that confounded "X". It just plain should not be there.

Linux should be spelled L-I-N-U-C-S. Linucs.

Seriously.

That's not a joke.

To make my case for why I believe this, with every fiber of my being, let's start by understanding why "Linux" has that X in the first place. It happened back in the early 1990s, when the first snapshot of Linucs (ahem) code was first uploaded to an FTP server.

Back then, Linus Torvalds wanted to name his kernel "Freax" ("Free" + "Freak" + "Unix"). Linus felt naming the kernel after himself would be a bit, you know, weird. A friend of his disagreed, and when he uploaded the source, he named the folder "Linux".

See that "X" there at the end? It was meant to represent the "X" in UNIX. There's just one problem with that.

UNIX was never supposed to have an "X" in the name at all.

You see, "UNIX" originally was spelled U-N-I-C-S, which stands for UNiplexed Information and Computing Service. This was, itself, based off the name for an operating system made by some of the same folks—Multics (MULTiplexed Information and Computing Service).

(Note: neither Unics or Multics is spelled with an "X".)

The people that created, engineered and ran the project named it "Unics", and, here's the kicker, nobody is 100% sure where that X even came from. I cover the topic a bit further in my video "The Complete History of Linux (Abridged)" around the five-minute mark. But, the gist is this: the most viable, detailed theory for "the X" is that "maybe someone in PR did it?"

In other words, Linucs—possibly the most critical and valuable piece of software in human history—is incorrectly named "Linux" because an unknown person may or may not have accidentally written Unics as "UNIX" once. Maybe. We're not really sure.

But, because everyone else uses the X, so must I. In every article. Every video. Every presentation.

Whenever I write the word "Linux"—which is about 80 bajillion times every day—I let out a whisper-quiet, short, tortured scream, followed by a subtle wimper of defeated acceptance. If you've ever seen me at a conference, writing an article on my laptop, now you know why I look like a completely insane person.

It's that stupid, friggin' X.

So. There you have it.

Go to Full Article

On Linus' Return to Kernel Development

Zack Brown — Thu, 06 Dec 2018 14:08:08 +0000

by Zack Brown

On October 23, 2018, Linus Torvalds came out of his self-imposed isolation, pulling a lot of patches from the git trees of various developers. It was his first appearance on the Linux Kernel Mailing List since September 16, 2018, when he announced he would take a break from kernel development to address his sometimes harsh behavior toward developers. On the 23rd, he announced his return, which I cover here after summarizing some of his pull activities.

For most of his pulls, he just replied with an email that said, "pulled". But in one of them, he noticed that Ingo Molnar had some issues with his email, in particular that Ingo's mail client used the iso-8859-1 character set instead of the more usual UTF-8. Linus said, "using iso-8859-1 instead of utf-8 in this day and age is just all kinds of odd. It looks like it was all fine, but if Mutt has an option to just send as utf-8, I encourage everybody to just use that and try to just have utf-8 everywhere. We've had too many silly issues when people mix locales etc and some point in the chain gets it wrong."

On the 24th, Linus continued pulling from developer trees. One of these was a batch of networking updates from David Miller, and it included contributions from a lot of different people. Linus noticed that the Kconfig rules were running into unmet dependency warnings because the code expected to run on the Qualcomm architecture, which Linus didn't use. He suggested it was a simple matter of updating the dependency list in the code. He also asked why the developers didn't notice that problem when testing their patches. Kalle Valo explained, "Mostly bad timing due to my vacation. I did do allmodconfig build but not sure why I missed the warning, also the kbuild bot didn't report anything. Jeff did report it last week, but I was on vacation at the time and just came back yesterday and didn't have time to react to it yet."

That seemed fine to Linus, who said he'd pull the fix when it became available. He remarked, "I just don't want my tree to have warnings that I see, and that may hide new warnings coming in when I do my next pull request."

On the 25th, Linus continued pulling from developer trees. In one instance, the issue of minimal tool versions came up. Linus prefers to support as many regular users as possible, which means supporting tool versions from the Linux distributions.

In response to a hard-to-read patch, Andi Kleen suggested changing the minimum supported binutils version from 2.20 to 2.21, which would support some useful assembler opcodes that would make the patch easier to review. Andy Lutomirski, another of the patch reviewers, said this would be fine. And Linus said:

Go to Full Article

When the Problem Is the Story

Doc Searls — Fri, 19 Oct 2018 17:02:18 +0000

by Doc Searls

Linux isn't a story anymore.

That's a good thing, but not an interesting one. Let me explain.

Journalism's main product is the story. In newsrooms, the three words uttered most often by editors to reporters are "What's the story?"

As I was taught by an editor long ago—and as I have found to be true constantly ever since—all stories are about three things:

A character. Usually human, but not always. Could be a cause. A sports team. A political party. Could be good, or bad, or neither. All that matters is that the character is interesting. You can also have more than one, but a single one is better.
A problem or conflict. A situation that challenges the character, or characters, further defining them and making them more interesting. Problems and conflict keep people interested, so they keep reading, watching, listening, turning pages, talking to others about it, and "move the narrative along" (as the news watchers like to say).
Movement toward resolution. Doesn't matter if the end never arrives. Hell, look at soap operas. You just have to keep the story moving in the direction of conclusion. Newsroom aphorism: "No story ever starts with 'Happily ever after'." Another: "If your team is up forty points with five minutes left, your new story is about how you get out of the parking lot ahead of traffic."

All three of those are why Linux isn't much of a story any more, even though it's bigger in the world than it has ever been.

Linux had character when it was easy to cast as an underdog operating system, and the problem was beating Windows. Linus Torvalds, the father of Linux, did his best not to be interesting, but his fans made him interesting anyway:

Us included. The above is from a slide show that was featured in a story I wrote back in 2002 that's off-web at the moment, but also beside the point, which is that Linus and his penguins were characters in stories that were interesting at the time and aren't anymore.

That's because Linux has achieved the world domination it longed for in the early years.

Go to Full Article

Linus' Behavior and the Kernel Development Community

Zack Brown — Tue, 09 Oct 2018 13:08:08 +0000

by Zack Brown

WARNING: This article contains profanity.

On September 16, 2018, Linus Torvalds released the 4.19-rc4 version of the kernel, and he also announced he was taking a break from Linux development in order to consider his own behavior and to come up with a better approach to kernel development. This was partly inspired by his realization that he wasn't looking forward to the Kernel Summit event, and he said that "it wasn't actually funny or a good sign that I was hoping to just skip the yearly kernel summit entirely."

He also wrote that it was partly inspired when:

...people in our community confronted me about my lifetime of not understanding emotions. 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.

So he said, "I am going to take time off and get some assistance on how to understand people's emotions and respond appropriately."

He compared the situation to the kind of "pain points" the Linux kernel project has experienced on a technical level in the past, like moving from tarballs to BitKeeper, and from BitKeeper to git. And he remarked that "We haven't had that kind of pain-point in about a decade. But this week felt like that kind of pain point to me."

He also added, by way of clarification, that "This is not some kind of 'I'm burnt out, I need to just go away' break. I'm not feeling like I don't want to continue maintaining Linux. Quite the reverse. I very much *do* want to continue to do this project that I've been working on for almost three decades."

That was the last post Linus sent to the mailing list, up to the time of this writing. However, he and several other kernel developers signed off on a patch to the kernel tree, incorporating a new Code of Conduct policy. It's fairly boilerplate—basically, don't be mean, don't discriminate, violations will be investigated, and appropriate measures taken.

It's not a new idea. Long ago, Richard Stallman used to troll the mailing list trying to start an argument about "Linux" vs. "GNU/Linux", until the mailing list maintainers threatened to ban him if he kept it up. They phrased it as a general rule, not unlike a code of conduct.

There's been a wide range of responses to Linus' announcement and to the Code of Conduct itself. Some felt that Linus' earlier behavior had been community-strengthening, encouraging people to respond as equals and duke it out with Linus on the issues they cared about.

Some felt that Linus was taking a really wonderful step, seeking feedback and reflecting on the issues, and they in turn offered their own insights and assistance.

Go to Full Article

Good Lockdown vs. Bad

Zack Brown — Wed, 08 Aug 2018 12:00:00 +0000

by Zack Brown

There's an ongoing series of skirmishes between corporations who want to sell products that users don't fully control and the kernel developers who want users to be the highest authority. Sometimes these skirmishes manifest in the form of security patches intended to lock down the kernel. Do they lock down the kernel against outside attackers? Or do they lock down the kernel against change from anyone at all, including the user who owns the device?

David Howells recently pushed a patch out of the linux-next, submitting it for inclusion in the main source tree. As he put it, the patch "adds kernel lockdown support for EFI secure boot". And a man page included in the patch said:

The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorized modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded.

The patch gave birth to an odd debate, but a familiar one by now. Matthew Garrett, ultimately the main proponent of the patch, kept defending it on technical grounds that Linus Torvalds felt were meaningless and dishonest, hiding a secret agenda that included helping companies like Microsoft lock users out of making changes to their own systems.

Andy Lutomirski was another critic of Matthew's defense of the patch. The debate circled around and around, with Linus and Andy trying to get Matthew to admit the true motivation they believed he had and Matthew attempting to give solid reasons why the patch should go into the kernel. Things got ugly.

James Morris initially accepted the patch, planning to send it up to Linus for inclusion, and Andy reviewed the code. Among his comments, Andy said the goal of the patch was not clearly stated. He said for the purpose of his code review he would assume the goal was to prevent the root user from either reading kernel memory or intentionally corrupting the kernel.

But, he didn't think those were proper goals for a kernel, even a UEFI Secure Boot kernel. He said, "the kernel should try to get away from the idea that UEFI Secure Boot should imply annoying restrictions. It's really annoying and it's never been clear to me that it has a benefit." He singled out the idea of preventing the root user from accessing kernel memory as one of these annoying restrictions.

Kees Cook replied with his overall justification for this patch. He said:

Go to Full Article

A Git Origin Story

Zack Brown — Fri, 27 Jul 2018 11:45:00 +0000

by Zack Brown

A look at Linux kernel developers' various revision control solutions through the years, Linus Torvalds' decision to use BitKeeper and the controversy that followed, and how Git came to be created.

Originally, Linus Torvalds used no revision control at all. Kernel contributors would post their patches to the Usenet group, and later to the mailing list, and Linus would apply them to his own source tree. Eventually, Linus would put out a new release of the whole tree, with no division between any of the patches. The only way to examine the history of his process was as a giant diff between two full releases.

This was not because there were no open-source revision control systems available. CVS had been around since the 1980s, and it was still the most popular system around. At its core, it would allow contributors to submit patches to a central repository and examine the history of patches going into that repository.

There were many complaints about CVS though. One was that it tracked changes on a per-file basis and didn't recognize a larger patch as a single revision, which made it hard to interpret the past contributions of other developers. There also were some hard-to-fix bugs, like race conditions when two conflicting patches were submitted at the same time.

Linus didn't like CVS, partly for the same reasons voiced by others and partly for his own reasons that would become clear only later. He also didn't like Subversion, an open-source project that emerged around the start of the 2000s and had the specific goal of addressing the bugs and misfeatures in CVS.

Many Linux kernel developers were unhappy with the lack of proper revision control, so there always was a certain amount of community pressure for Linus to choose something from one of the available options. Then, in 2002, he did. To everyone's shock and dismay, Linus chose BitKeeper, a closed-source commercial system developed by the BitMover company, run by Larry McVoy.

The Linux kernel was the most important open-source project in history, and Linus himself was the person who first discovered the techniques of open-source development that had eluded the GNU project, and that would be imitated by open-source projects for decades to come, right up to the present day. What was Linus thinking? How could he betray his community and the Open Source world like this? Those were the thoughts of many when Linus first started using BitKeeper for kernel development.

Go to Full Article

Minimum GCC Version Likely to Jump from 3.2 to 4.8

Zack Brown — Wed, 11 Jul 2018 11:45:00 +0000

by Zack Brown

The question of the earliest GCC compiler version to support for building the Linux kernel comes up periodically. The ideal would be for Linux to compile under all GCC versions, because you never know what kind of system someone is running. Maybe their company's security team has to approve all software upgrades for their highly sensitive devices, and GCC is low on that list. Maybe they need to save as much space as possible, and recent versions of GCC are too big. There are all sorts of reasons why someone might be stuck with old software. But, they may need the latest Linux kernel because it's the foundation of their entire product, so they're stuck trying to compile it with an old compiler.

However, Linux can't really support every single GCC version. Sometimes the GCC people and the kernel people have disagreed on the manner in which GCC should produce code. Sometimes this means that the kernel really doesn't compile well on a particular version of GCC. So, there are the occasional project wars emerging from those conflicts. The GCC people will say the compiler is doing the best thing possible, and the kernel people will say the compiler is messing up their code. Sometimes the GCC people change the behavior in a later release, but that still leaves a particular GCC version that makes bad Linux code.

So, the kernel people will decide programmatically to exclude a particular version of GCC from being used to compile the kernel. Any attempt to use that compiler on kernel code will produce an error.

But, sometimes the GCC people will add a new language feature that is so useful, the kernel will people decide to rely heavily on it in their source code. In that case, there may be a period of time where the kernel people maintain one branch of code for the newer, better compiler, and a separate, less-fast or more-complex branch of code for the older, worse compiler. In that case, the kernel people—or really Linus Torvalds—eventually may decide to stop supporting compilers older than a certain version, so they can rip out all those less-fast and more-complex branches of code.

For similar reasons, it's also just an easier maintenance task for the kernel folks to drop support for older compilers; so this is something they would always prefer to do, if possible.

But, it's a big decision, typically weighed against the estimated number of users that are unable to upgrade their compilers. Linus really does not want even one regular (that is, non-kernel-developer) user to be unable to build Linux because of this sort of decision. He's willing to let the kernel carry a lot of fairly dead and/or hard-to-maintain code in order to keep that from happening.

Go to Full Article

diff -u: Linus Posting Habits

Zack Brown — Tue, 06 Mar 2018 15:55:51 +0000

by Zack Brown

A look into how, when and why Linus posts to the kernel mailing list.

Linus Torvalds sometimes is criticized for bombastically cursing out kernel developers. He does do this, but it's not his default behavior, and I think the real nature of when and how he posts to the mailing list is interesting. For example, he stayed out of the whole discussion of how to replace the BitKeeper revision control system for a long time, letting various projects guess frustratingly at his desires, before he finally took a break from Linux development to design and implement git.

In other cases, he's allowed developers to lambaste each other savagely for days or longer over key elements of the kernel or the behaviors of new hardware peripherals, only to enter the debate later on, generally to propose a simpler solution that neither camp had thought of.

Sometimes he'll enter a discussion for apparently no other reason than that a particular bug or piece of code interests him, and he works with whoever posted a given patch to get the kinks out or track down underlying problems.

In general, Linus tends to stay out of most discussions, coming in primarily only on controversial issues after he's developed a position of his own.

But yes, sometimes he comes down pretty hard on developers, generally saying they already should know better than to do a particular thing, or when he feels the developer is hawking a particular corporate goal that goes against the spirit of open-source development—although I doubt he'd put it that way himself. He doesn't seem to like making overtly evangelical statements and tends to stick to the "if it works, I like it" attitude that he took when adopting BitKeeper.

Occasionally, Linus gets a technical issue wrong—he'll claim something about the kernel as being true that isn't. An example of that happened recently, when Amir Goldstein posted a patch to alter a string hashing function. It was a small patch that preserved some dropped bits in the 64-bit case and left the 32-bit case virtually unchanged. Amir asked for Linus' advice because he couldn't find a maintainer for the file, and Linus had been one of the people most recently to change the code.

Linus didn't agree that Amir's code left the 32-bit case unchanged. And he singled out a call to the __hash_32() function as being particularly time-consuming. He rejected Amir's patch, saying, "the patch as-is doesn't seem to buy anything, and only adds cost."

But when Amir pointed out that his patch hadn't actually added the call to __hash_32(), that the call had been there already, Linus took another look and replied, "Oh, duh. My bad. It was indeed there already. Let me go back and look at the history of this thing."

He later replied to his own post, saying:

Go to Full Article