On submitting trivial patches

Hacker News points to this Linux kernel patch, done by a 4-year old.  With some assistance, of course, but still impressive.  And while the story is cute, the comments are even better.  In particular, a link to this email from Linus Torvalds, talking about the importance of the small and trivial contributions.

To me, the biggest thing with small patches is not necessarily the patch itself. I think that much more important than the patch is the fact that people get used to the notion that they can change the kernel – not just on an intellectual level (“I understand that the GPL means that I have the right to change my kernel”), but on a more practical level (“Hey, I did that small change”).

GPL defense issues

A friend sent me a link to this email from Linus Torvalds to the Kernel Summit Discussion mailing list.  The subject of the conversation is the General Public License (GPL) and whether or not it should be enforced in courts.  Read the whole thing – it’s quite interesting.  Here are a few snippets just to get you started:

Let’s be clear about this: lawsuits destroy. They don’t “protect”.

Lawsuits destroy community. They destroy trust. They would destroy all the goodwill we’ve built up over the years by being nice.

And then this:

Because lawsuits – and even threats of lawsuits – makes companies way less likely to see you as a good guy. Even when you’re threatening
somebody else, everybody else around the target starts getting really
really antsy.

I talked to an Oracle lawyer a few months ago, and told him their
lawsuit just makes Oracle look bad. The lawyer was dismissive, and
tried to explain how it’s silly how people take lawsuits personally,
and talked about how layers _understand_ that lawsuits aren’t
personal, and that they are still friends outside the court.

I’m sure a lawyer can “understand” how lawsuits aren’t actually
something personal at all, but lawyers really seem to be the *only*
people who “understand” that.

The fact is, lawsuits (and threats of lawsuits) do not make for
friends. You just look like a bully.

Linus Torvalds loves GPL

Slashdot links to this CIO article, which quotes Linus Torvalds on the importance of the General Public License (GPL):

“FSF [Free Software Foundation] and I don’t have a loving relationship, but I love GPL v2,” said Torvalds. “I really think the license has been one of the defining factors in the success of Linux because it enforced that you have to give back, which meant that the fragmentation has never been something that has been viable from a technical standpoint.”


“The GPL ensures that nobody is ever going to take advantage of your code. It will remain free and nobody can take that away from you. I think that’s a big deal for community management.”

2016 will be the year of the ARM laptop

Slashdot links to the story that quotes Linus Torvalds’ address of the LinuxCon 2015:

“2016 will be the year of the ARM laptop”

For those who’s rusty on the CPU hardware side, he’s a very easy to follow article, describing the key difference between ARM and x86 architectures.

On acting professionally

A few weeks back, there was this story about Sarah Sharp quitting Linux kernel development due to some issues she had with communications on the Linux kernel mailing list (aka LMKL).  I never cared much about this sort of things, so I skipped the story altogether (people disagree, no big deal).

Today I was catching up with my RSS feeds, and the story came up again (via this post and discussion thread in Russian), which linked to this Slashdot comment nicely summarizing the story.

Among all the other comments, there was a link to the related email from Linus Torvalds, where he opens up a bit about the “professional” behavior and communication.  I think it’s absolutely brilliant and everybody should read the whole thing.  But I’ll leave this small quote here for myself:

Because if you want me to “act professional”, I can tell you that I’m not interested. I’m sitting in my home office wearign a bathrobe. The same way I’m not going to start wearing ties, I’m *also* not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords. Because THAT is what “acting professionally” results in: people resort to all kinds of really nasty things because they are forced to act out their normal urges in unnatural ways.

10 Years of Git: An Interview with Git Creator Linus Torvalds


Linux.com reminds us that git is celebrating its 10th birthday this year.  An interview with git creator Linus Torvalds sheds some light on to how and why it happened, and how long it took.

You can actually see how it all took shape in the git source code repository, except for the very first day or so. It took about a day to get to be “self-hosting” so that I could start committing things into git using git itself, so the first day or so is hidden, but everything else is there. The work was clearly mostly during the day, but there’s a few midnight entries and a couple of 2 a.m. ones. The most interesting part is how quickly it took shape ; the very first commit in the git tree is not a lot of code, but it already did the basics – enough to commit itself. The trick wasn’t really so much the coding but coming up with how it organizes the data.

So I’d like to stress that while it really came together in just about ten days or so (at which point I did my first *kernel* commit using git), it wasn’t like it was some kind of mad dash of coding. The actual amount of that early code is actually fairly small, it all depended on getting the basic ideas right.

Very impressive!

And, of course: HAPPY BIRTHDAY GIT!  The world is a much better place with you.

Linus Torvalds answers Slashdot questions

Linus Torvalds answers Slashdot questions

Once in a while Slashdot runs a story to collect and vote questions to be asked of a person of interest.  This time, it’s Linux kernel’ father – Linus Torvalds.  As always with Slashdot, the questions are on a variety of subjects – Linux kernel, git, books, copyrights, and so on – and, as always with Linus, the answers are to the questions – nothing simple-sentenced or automated.  Some answers are just pointers to history, others are thoughts “as of this moment”, and yet others are reflections generalized much further than source code.

Btw, it’s not just microkernels. Any time you have “one overriding idea”, and push your idea as a superior ideology, you’re going to be wrong. Microkernels had one such ideology, there have been others. It’s all BS. The fact is, reality is complicated, and not amenable to the “one large idea” model of problem solving. The only way that problems get solved in real life is with a lot of hard work on getting the details right. Not by some over-arching ideology that somehow magically makes things work.

Project management tips from Linus Torvalds

Linus Torvalds shares some of his thoughts on software project management in this interview. I have two favorite bits in there. One is on the obsession of the code quality control:

“The other thing—and it’s kind of related—that people seem to get wrong is to think that the code they write is what matters,” says Torvalds. Most software development managers have seen this one. “No, even if you wrote 100% of the code, and even if you are the best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it.”

Just a few years ago I would have completely missed this point. Or argued passionately with it. But not anymore. After spending the last few years working with very dynamic software projects, I realized that no matter how much effort you spend on the code quality control, it will still degrade with time. And even if it becomes horrible and hard to look at, it will still work and you’ll still be able to maintain it. But the time and effort that was lost would have been so much more useful in supporting user requests and improving their experiences.

Even knowing this now, I am still a slave of my habits. I still need to control myself, set tight deadlines, and learn to ignore a lot of things that would have caused me a heart attack back in a day.

The second point that I found interesting in the interview is similar.

I also asked Torvalds about Software Configuration Management (SCM) tools like his own Git version control system. He replied, “I don’t think tools are all that fundamentally  important.”

“Now, what is important is that there’s a good workflow for the project, and tools can certainly help with that,” said Torvalds. “But most projects don’t necessarily really need tools. There’s a lot of projects that simply don’t have enough changes to really require any tools at all for their work flow; if you only have a few hundred patches per release, you can maintain those just about any way you want, including entirely by hand.”

Again, a few years ago (and even sometimes now) I would argue and fight for the perfect setup and ideal toolbox. These days I seem to care less. As long as the work is being done and the project is moving on, I don’t really care which tools are being used. I have my preferences, of course, and I would try to push them through to be used by majority of participants, but I am much more relaxed on this subject than I used to be.

One other thing that I wanted to mention is the difference in perception. In Linus’ world, it seems, changes are always distributed as patches. To the effect that it would even be considered a specialized tool – everyone is using it. And I understand – all of the people with who he works are very experienced technical people and there is indeed no other way. But for the rest of us things aren’t as rosy. On several occasions I worked in a team where people weren’t using any tools. Literally. They had no idea about patches, diff, scripts, merging, version control, any of that. Changes in those projects were maintained by hand. And there would be nothing similar in concept to a release. Which didn’t help.

There was indeed one particular project.  Do you know how I remember it?  I was at one of those PHP conferences somewhere in Europe. And one of the talks I attended was on how to use unit testing during the re-factoring process.  The presentation was filled with examples of ‘horrible’ code which was then surrounded by unit tests and later re-factored into better code.  The code that was presented as ‘horrible’ was some of the best code I’ve seen in my life!  After the presentation I came up to the speaker and showed him the project with which I was involved, which had some truly horrible code.  You should have seen the look on his face… It took him a couple of minutes to compose himself and start thinking on how to work with that nightmare.  He even thanked me and promised that we would include some examples of that crap in the future versions of his talk.

My point here is the difference in perception.  When Linus says that things can be done without any tools at all, and when that guy talked about horrible code, they both, I think, are somewhat spoiled by their surroundings.  I’m sure not everyone even would be able to make sense of a gadzillion tiny little things that Linus uses on a daily basis and doesn’t even consider them as full featured tools.  I’m sure not everyone even would be able to read some of that ‘horrible’ code the other guy spoke about, let alone write something like that (I remember it being OOP, with comments, well-tabulated, etc).  There is a certain minimum level which has to be there.  That minimum level is assumed to be a zero.  But it’s not always there.