Sh*t Linus Says is in no way authorized, prepared, approved, or

endorsed by Linus Torvalds and is not affiliated with or endorsed

by any of his past or present organizations.

.................................................................................................................. 10
............................................................................................................. 12
................................................................................................... 13
..................................................................................................... 13
.................................................................. 13
...................................................................................................................... 14
............................................................................................................. 14
.............................................................................................................. 14
.......................................................................................................................... 15
.......................................................................................................................... 15
........................................................................................................ 16
.......................................................................................................... 17
..................................................................................................................... 18
.................................................................................................................. 18
................................................................................................................ 18
........................................................................................................................... 19
................................................................................................................. 19
................................................................................................................. 19
............................................................................................................. 20
................................................................................................................................. 20
.................................................................................................................................. 20
........................................................................................................................... 21
.......................................................................................... 21
................................................................................................................. 22
.................................................................................................... 25

................................................................................................................. 25
................................................................................................................. 25
......................................................................................................... 26
............................................................................................................................... 26
........................................................................... 27
................................................................................................................................ 28
............................................................................................................. 28
.................................................................................................................... 29
............................................................................................................... 30
................................................................................................................................ 30
................................................................................................................................ 30
..................................................................................................................... 30
................................................................................................................... 31
.............................................................................................................................. 31
........................................................................................................ 31
.................................................................................................................................. 32
................................................................................................................................ 32
.................................................................................................................... 32
................................................................................................................................. 34
............................................................. 35
............................................................................................................................ 35
........................................................................................................... 35
................................................................................................................ 36
................................................................................................................... 36
........................................................................................................ 36
.................................................................................................................... 37
................................................................................................................................ 37
................................................................................................................................. 37

...................................................................................................................... 38
................................................................................................................................. 38
....................................................................................................... 39
................................................................................................................... 39
.............................................................................................................. 40
................................................................................................................................... 40
................................................................................................................................... 41
............................................................................................................................... 41
........................................................................................................................ 41
.......................................................................................................................... 42
................................................................................................... 42
................................................................................................................................ 42
............................................................................................................................... 43
............................................................................. 43
......................................................................................................... 44
............................................................................................................................. 44
............................................................................................... 44
.............................................................................................................................. 44
.................................................................................. 45
........................................................................................................... 45
.................................................................................................................. 45
................................................................................................................................. 46
................................................................................................................ 47
.................................................................................................. 49
C++................................................................................................................................. 50
................................................................................................................................ 56
...................................................................................................................... 57
................................................................................................................... 57

............................................................................................................ 57
.................................................................................................... 58
....................................................................................... 59
....................................................................................... 59
.......................................................................................... 59
.............................................................. 59
.................................................... 60

......................................................................................................................... 60
.................................................................................................... 61
........................................................................................................... 61
......................................................................................................................... 61
............................................................................................................................. 62
................................................................................................................. 62
...................................................................................................................... 62
.................................................................................................. 63
..................................................................................................................... 63
..................................................................................................................... 63
.............................................................................................. 64
......................................................................................................... 64
......................................................................................................................... 65
.......................................................................................................... 66
...................................................................................................................... 66
..................................................................................................... 68
.......................................................................................................................... 70
..................................................................................................................... 71
.............................................................. 71
............................................................................................................. 73

........................................................................................................... 74
........................................................................................................................ 74
............................................................................................................................. 74
.......................................................................................................................... 75
................................................................................................................... 75
........................................................................................................ 76
.............................................................................................................. 76
..................................................... 77
....................................................................................................................... 82
.......................................................................................................................... 87
................................................................................................................... 87
................................................................................................................ 87
.............................................................................................................. 88
............................................................................................................................... 88
....................................................................................................... 88
................................................................................................. 89
......................................................................................... 97
.................................................................................... 98
.............................................................................................................. 99
.............................................................................................................................. 101
........................................................................................................................ 101
............................................................................................... 102
................................................................................................................ 102
............................................................ 103
............................................................................................... 105
.............................................................................................................. 107
......................................................................................................................... 108
......................................................................................... 111

................................................................... 112
......................................................................................... 115

I'm sure that there is no other person in IT world that can make
you feel the way Linus does. In fact, I think nobody else can afford
managing the communities the way Linus does. Torvalds can get
away saying things like trying to come up with some code of
conduct that says that people should be respectful and polite is
just so much crap and bullshit. I certainly cant and chances are
you cant either.
This book is a collection of Linus Torvalds' best quotes about life,
programming and Linux. You can get it on
https://gum.co/shitlinussays
Happy reading!

Hello everybody out there using minix I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been
brewing since April, and is starting to get ready. I'd like any
feedback on things people like/dislike in minix, as my OS
resembles it somewhat (same physical layout of the file-system
(due to practical reasons) among other things).
I've currently ported bash (1.08) and gcc (1.40), and things seem
to work. This implies that I'll get something practical within a few
months, and I'd like to know what features most people would
want. Any suggestions are welcome, but I won't promise I'll
implement them :-)
Linus (torvalds@kruuna.helsinki.fi)
PS. Yes - it's free of any minix code, and it has a multi-threaded
fs.
It is NOT portable (uses 386 task switching etc), and it probably
never will support anything other than AT-harddisks, as that's all I
have :-(.
news:comp.os.minix,
August 25, 1991

Do you pine for the nice days of minix-1.1, when men were men
and wrote their own device drivers?
Free minix-like kernel sources for 386-AT, news:comp.os.minix
October 5, 1991

The Hurd 0.0 was released in August 1996 and as of 2015, is still
not complete.
I can (well, almost) hear you asking yourselves "why?". Hurd will
be out in a year (or two, or next month, who knows), and I've
already got minix.
Free minix-like kernel sources for 386-AT, news:comp.os.minix
October 5, 1991

Your job is being a professor and researcher: That's one hell of a

good excuse for some of the brain-damages of Minix.
comp.os.minix newsgroup
January 29, 1992

Portability is for people who cannot write new programs.

comp.os.minix newsgroup
January 29, 1992

Well, with a subject like this, I'm afraid I'll have to reply.
Apologies to minix-users who have heard enough about linux
anyway. I'd like to be able to just "ignore the bait", but time for
some serious flamefesting!

Well, I probably won't get too good grades even without you: I
had an argument (completely unrelated not even pertaining to
OS's) with the person here at the university that teaches OS
design. I wonder when I'll learn :)
comp.os.minix: LINUX is obsolete
January 31, 1992

No. That's it. The cool name, that is. We worked very hard on
creating a name that would appeal to the majority of people, and it
certainly paid off: thousands of people are using linux just to be
able to say "OS/2? Hah. I've got Linux. What a cool name".

386BSD made the mistake of putting a lot of numbers and weird

abbreviations into the name, and is scaring away a lot of people
just because it sounds too technical.
comp.unix.pc-clone.32bit,
March 16, 1993

If 386BSD had been available when I started on Linux, Linux

would probably never had happened.
The Choice of a GNU Generation,
1993

When you say, "I wrote a program that crashed Windows," people
just stare at you blankly and say, "Hey, I got those with the
system, for free."
comp.os.linux.development.apps
March 8, 1995

You know you're brilliant, but maybe you'd like to understand

what you did 2 weeks from now.

Some people will claim that having 8-character indentations makes

the code move too far to the right, and makes it hard to read on a
80-character terminal screen. If you need more than 3 levels of
indentation, you're screwed anyway, and should fix your program.

Comments are good, but there is also a danger of overcommenting. NEVER try to explain HOW your code works in a
comment: it's much better to write the code so that the working is
obvious, and it's a waste of time to explain badly written code.
Generally, you want your comments to tell WHAT your code
does, not HOW.

You've made a mess of it? That's OK, we all do.

An infinite number of monkeys typing into GNU emacs would

never make a good program.
1995

Software is like sex; it's better when it's free.

FSF conference
1996

The memory management on the PowerPC can be used to frighten

small children.
95 percent of all software developers believe they are in the top 5
percent when it comes to knowledge and skills
Linux now has a logo thanks to the artistic talents of Larry Ewing,
and one version (the pretty version) is included with the kernel.
Some people have told me they dont think a fat penguin really
embodies the grace of Linux, which just tells me they have never
seen an angry penguin charging at them in excess of 100mph.
Theyd be a lot more careful about what they say if they had
In short, at least give the penguin a fair viewing. If you still dont
like it thats ok: thats why Im boss. I simply know better than
you do.
comp.os.linux.misc
July 22, 1996

It's a bird it's a plane no, it's KernelMan, faster than a

speeding bullet, to your rescue. Doing new kernel versions in
under 5 seconds flat
Announcement for Linux 1.3.27
November 14, 1995

The main reason there are no raw devices [in Linux] is that I
personally think that raw devices are a stupid idea.
LKML
October 17, 1996

Some people have told me they don't think a fat penguin really
embodies the grace of Linux, which just tells me they have never
seen an angry penguin charging at them in excess of 100 mph.
They'd be a lot more careful about what they say if they had.
comp.os.linux.announce newsgroup.
June 09, 1996

Only wimps use tape backup: real men just upload their important
stuff on ftp, and let the rest of the world mirror it ;)
LKML
July 20, 1996

If you still don't like it, that's OK: that's why I'm boss. I simply
know better than you do.
comp.os.linux.advocacy newsgroup.
July 22, 1996

the Linux philosophy is "laugh in the face of danger". Oops.

Wrong one. "Do it yourself". That's it.
linux.dev.kernel newsgroup
October 16, 1996

See, you not only have to be a good coder to create a system like
Linux, you have to be a sneaky bastard too ;-)
comp.os.linux.development.system
July 5, 1996

Making Linux GPL'd was definitely the best thing I ever did.
The Pragmatist of Free Software
November 11, 1997

In the extreme case, if it was just you doing all the code, and the rest
of the world quietly used it, would it make sense to give it away free?
Unless you're particularly grateful for other free things you've got off
the Net, would the answer be No?"
I don't necessarily think so. It might be true in certain niche areas,
but almost any project will give a developer that "feel good" feeling
when he has users and he feels he is doing something worthwhile.
I really don't think you need all that much "quid pro quo" in
programming - 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.
What motivates free software developers?
March 02, 1998

"Regression testing"? What's that? If it compiles, it is good; if it

boots up, it is perfect.
LKML,
April 8, 1998.

I'd like to say that I knew this would happen, that it's all part of
the plan for world domination.
Open Sources: Voices from the Open Source Revolution,
1999

In article <7aresh$mh4$1@news.tuwien.ac.at>,
<tharsos@bigfoot.com> wrote:
>Funny how people tend to quote Linus Torvalds
> on technical issues in order
> to prove a point. I hear the guy barely made it through college.
Actually, I lied about even that. I was thrown out of fourth grade
because I couldn't write my own name, and it's been all downhill
from there.
I had to lie about getting into college just so that I'd have better
chances of making a career here at McDonalds - if you have a
college degree (or you lied about having one), they don't make you
scrape the burger pans.

> Linus might be a fine role model for the Linux clerasil crowd,
> but there are much smarter people than him working in the
> CS field.
I resent your remark about the clerasil crowd. The people I know
wouldn't get a date even if they didn't have bad skin, so they don't
bother with that fancy expensive skin treatment stuff anyway. So
we call ourself the "brown paper bag" crowd - those clerasil guys
are snobs.

> Avie Tevanian,

> Senior Vice President of Software Engineering at Apple and
inventor of the
> Mach microkernel, is one of them.
Ehh.
Have you actually met him? I have.
He may be smart, and he freely admits that I'm not the only one
slamming
Mach as an OS. Think about it.
February 22, 1999

>Hm. So one can make Linus go non-linear, too. Pretty fun.

It's actually not all that hard. If I didn't have strong opinions, I
wouldn't be in this business. I'd be just another random user using
DOS and Windows, I'm afraid.
And also, in my opinion, it is just worthless trying to write a nice
and polite article to an advocacy newsgroup. The whole _point_
of advocacy newsgroups is to have heated discussion. It should be
coherent and reasonably thought out, but does it need to be
polite? No.
comp.os.linux.advocacy
1 Mar 1999

Note that nobody reads every post in linux-kernel. In fact, nobody

who expects to have time left over to actually do any real kernel
work will read even half. Except Alan Cox, but he's actually not
human, but about a thousand gnomes working in under-ground
caves in Swansea. None of the individual gnomes read all the
postings either, they just work together really well.
LKML
May 2, 2000

Talk is cheap. Show me the code.

LKML
August 25, 2000

I'm a bastard. I have absolutely no clue why people can ever think
otherwise. Yet they do. People think I'm a nice guy, and the fact is
that I'm a scheming, conniving bastard who doesn't care for any
hurt feelings or lost hours of work, if it just results in what I
consider to be a better system. And I'm not just saying that. I'm
really not a very nice person. I can say "I don't care" with a straight
face, and really mean it.
LKML
September 6, 2000

To kind of explain what Linux is, you have to explain what an

operating system is. And the thing about an operating system is
that you're never ever supposed to see it. Because nobody really
uses an operating system; people use programs on their computer.
And the only mission in life of an operating system is to help those
programs run. So an operating system never does anything on its
own; it's only waiting for the programs to ask for certain resources,
or ask for a certain file on the disk, or ask to connect to the outside
world. And then the operating system steps in and tries to make it
easy for people to write programs.
Revolution OS,
2001

In short: just say NO TO DRUGS, and maybe you won't end up

like the Hurd people.
mlist.linux.kernel
October 4, 2001

Hey, that's not a bug, that's a feature! You know what the most
complex piece of engineering known to man in the whole solar
system is? Guess what it's not Linux, it's not Solaris, and it's not
your car. It's you. And me. And think about how you and me
actually came about not through any complex design. Right.
"Sheer luck". Well, sheer luck, and:
Free availability and crosspollination through sharing of "source
code", although biologists call it DNA.
A rather unforgiving user environment, that happily replaces bad
versions of us with better working versions and thus culls the herd
(biologists often call this "survival of the fittest").
Massive undirected parallel development ("trial and error").
I'm deadly serious: we humans have never been able to replicate
something more complicated than what we ourselves are, yet
natural selection did it without even thinking. Don't underestimate
the power of survival of the fittest. And don't ever make the
mistake 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. Quite
frankly, Sun is doomed. And it has nothing to do with their
engineering practices or their coding style.
Coding style - a non-issue
November 30, 2001

It is a reference from David Braben following the release of Elite

Yeah. And as Linus once said: most numerical problems today in
pure CPU cycles are actually 3D games. It's not "incorrect" to
say that you want the result faster, even if that result doesn't match
your theoretical models.
GCC mailing list
July 30, 2001

Once you realize that documentation should be laughed at, peed

upon, put on fire, and just ridiculed in general, THEN, and only
then, have you reached the level where you can safely read it and
try to use it to actually implement a driver.
Re: ide.2.4.1-p3.01112001.patch
January 12, 2001

My name is Linus Torvalds and I am your god.

Jokingly introducing himself at the 1998 Linux Expo

Oh fuck. If I kill this guy, I'll have millions of nerds on my case.

My personal opinion of Mach is not very high. Frankly, it's a piece

of crap. It contains all the design mistakes you can make, and even
managed to make up a few of its own.

You see. I don't think any new thoughts. I think thoughts that
other people have thought, and I rearrange them. But Sara, she
thinks thoughts that never were before.

Most days I wake up thinking I'm the luckiest bastard alive.

I'm personally convinced that computer science has a lot in

common with physics. Both are about how the world works at a
rather fundamental level. The difference, of course, is that while in
physics you're supposed to figure out how the world is made up,
in computer science you create the world. Within the confines of
the computer, you're the creator. You get to ultimately control
everything that happens. If you're good enough, you can be God.
On a small scale.
2001

Personally, I'm not interested in making device drivers look like

user-level. They aren't, they shouldn't be, and microkernels are just
stupid.
mlist.linux.kernel
2002-05-25

I allege that SCO is full of it.

Torvalds Speaks Out on SCO
June 23, 2003

Those that can, do. Those that can't, complain.

LKML
September 23, 2003

Really, I'm not out to destroy Microsoft. That will just be a

completely unintentional side effect.
The Way We Live Now: Questions for Linus Torvalds
September 28, 2003

Modern PCs are horrible. ACPI is a complete design disaster in

every way. But we're kind of stuck with it. If any Intel people are
listening to this and you had anything to do with ACPI, shoot
yourself now, before you reproduce.
Linus & the Lunatics, Part II
November 25, 2003

They are smoking crack.

Torvalds Slams SCO
August 20, 2003

There are literally several levels of SCO being wrong. And even if
we were to live in that alternate universe where SCO would be
right, they'd still be wrong.
BusinessWeek Online, "Linus Torvalds: SCO Is 'Just Too Wrong'".
February 2, 2004

The NIH syndrome (Not Invented Here) is a disease.

CNet, "Newsmaker: Torvalds: A Solaris skeptic"
December 21, 2004

Anybody who tells me I can't use a program because it's not open
source, go suck on rms. I'm not interested. 99% of that I run tends
to be open source, but that's my choice, dammit.
LKML
October 26, 2004

Nobody should start to undertake a large project. You start with a

small trivial project, and you should never expect it to get large. If
you do, you'll just overdesign and generally think it is more
important than it likely is at that stage. Or worse, you might be
scared away by the sheer size of the work you envision. So start
small, and think about the details. Don't think about some big
picture and fancy design. If it doesn't solve some fairly immediate

need, it's almost certainly over-designed. And don't expect people

to jump in and help you. That's not how these things work. You
need to get something half-way useful first, and then others will
say "hey, that almost works for me", and they'll get involved in the
project.
Linux Times
October 25, 2004

On Tue, 20 Jan 2004, Robin Rosenberg wrote:

> This is the "We've always used COBOL^H^H^H^H" argument.

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.
The fact is, C++ compilers are not trustworthy. They were even
worse in 1992, but some fundamental facts haven't changed:
- 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.
- you can write object-oriented code (useful for filesystems
etc) in C, without the crap that is C++.
In general, I'd say that anybody who designs his kernel modules
for C++ is either
a) looking for problems
b) a C++ bigot that can't see what he is writing is really just C
anyway
c) was given an assignment in CS class to do so.
Feel free to make up (d).
January 19, 2004

OK, I admit it. I was just a front-man for the real fathers of Linux,
the Tooth Fairy and Santa Claus.
May, 2004

A lot of people still like Solaris, but I'm in active competition with
them, and so I hope they die.
Torvalds: Waiting To See Sun's Open Solaris
February 1, 2005

2.6.<odd>: still a stable kernel, but accept bigger changes leading

up to it (timeframe: a month or two).
2.<odd>.x: aim for big changes that may destabilize the kernel for
several releases (timeframe: a year or two)
<odd>.x.x: Linus went crazy, broke absolutely everything, and
rewrote the kernel to be a microkernel using a special messagepassing version of Visual Basic. (timeframe: "we expect that he will
be released from the mental institution in a decade or two").
LKML
March 2, 2005

Which mindset is right? Mine, of course. People who disagree with

me are by definition crazy. (Until I change my mind, when they
can suddenly become upstanding citizens. I'm flexible, and not
black-and-white.)
"Linus compares Linux and BSDs", NewsForge
June 13, 2005

Don't bother. Bram doesn't know what he's talking about.

Linus vs. Bram Cohen.
April 27, 2005

It was such a relief to program in user mode for a change. Not

having to care about the small stuff is wonderful.
Git mailing list
April 14, 2005

I chose 1000 originally partly as a way to make sure that people

that assumed HZ was 100 would get a swift kick in the pants.
LKML
July 8, 2005

I'm always right. This time I'm just even more right than usual.
LKML
July 14, 2005

The fact that ACPI was designed by a group of monkeys high on

LSD, and is some of the worst designs in the industry obviously
makes running it at any point pretty damn ugly.
LKML
July 31, 2005

I personally just encourage people to switch to KDE.

This "users are idiots, and are confused by functionality" mentality
of Gnome is a disease. If you think your users are idiots, only
idiots will use it. I don't use Gnome, because in striving to be
simple, it has long since reached the point where it simply doesn't
do what I need it to do.
Please, just tell people to use KDE.
usability@gnome.org
December 12, 2005

Now, most of you are probably going to be totally bored out of

your minds on Christmas day, and here's the perfect distraction.
Test 2.6.15-rc7. All the stores will be closed, and there's really
nothing better to do in between meals.
LKML,
December 24, 2005

For example, the GPLv2 in no way limits your use of the software.
If you're a mad scientist, you can use GPLv2'd software for your
evil plans to take over the world ("Sharks with lasers on their
heads!!"), and the GPLv2 just says that you have to give source
code back.
And that's OK by me. I like sharks with lasers. I just want the mad
scientists of the world to pay me back in kind. I made source code
available to them, they have to make their changes to it available
to me. After that, they can fry me with their shark-mounted lasers
all they want.
"Linux Licensing". Forbes.
March 9, 2006

I claim that Mach people (and apparently FreeBSD) are

incompetent idiots.
LKML,
April 21, 2006

I got slashdotted!
I also claim that Slashdot people usually are smelly and eat their
boogers, and have an IQ slightly lower than my daughters pet
hamster (that's "hamster" without a "p", btw, for any slashdot
posters out there. Try to follow me, ok?).
Furthermore, I claim that anybody that hasn't noticed by now that
I'm an opinionated bastard, and that "impolite" is my middle
name, is lacking a few clues.
Finally, it's clear that I'm not only the smartest person around, I'm
also incredibly good-looking, and that my infallible charm is also
second only to my becoming modesty.
So there. Just to clarify.
Linus "bow down before me, you scum" Torvalds
fa.linux.kernel
April 21, 2006

I like colorized diffs, but let's face it, those particular color choices
will make most people decide to pick out their eyes with a fondue
fork.
And that's not good. Digging in your eye-sockets with a fondue
fork is strictly considered to be bad for your health, and seven out
of nine optometrists are dead set against the practice.
So in order to avoid a lot of blind git users, please apply this patch.
Git mailing list
June 22, 2006

git actually has a simple design, with stable and reasonably welldocumented data structures. In fact, I'm a huge proponent of
designing your code around the data, rather than the other way
around, and I think it's one of the reasons git has been fairly
successful.
[]
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.
Git mailing list.
June 27, 2006

EFI is this other Intel brain-damage (the first one being ACPI).
LKML
May 28, 2007

even if the Hurd didn't depend on Linux code (and as far as I

know, it does, but since I think they have their design heads firmly
up their *sses anyway with that whole microkernel thing, I've never
felt it was worth my time even looking at their code), I don't
believe a religiously motivated development community can ever
generate as good code except by pure chance.
LKML,
September 27, 2006

I'm a huge believer in evolution (not in the sense that "it

happened" anybody who doesn't believe that is either
uninformed or crazy, but in the sense "the processes of evolution
are really fundamental, and should probably be at least thought
about in pretty much any context").
LKML,
September 28, 2006

Dijkstra probably hates me.

Comment in Linux kernel 1.1.42's kernel/sched.c file.
August 28, 2006

It's one of those rare "perfect" kernels. So if it doesn't happen to

compile with your config (or it does compile, but then does
unspeakable acts of perversion with your pet dachshund), you can
rest easy knowing that it's all your own damn fault, and you
should just fix your evil ways.
LKML
November 29, 2006

GCC is crap.
Re: [PATCH] Don't compare unsigned variable for <0 in sys_prctl()
November 28, 2006

Friends don't let friends use [gcc] "-W".

Re: [PATCH] Don't compare unsigned variable for <0 in sys_prctl()
November 28, 2006

I think people can generally trust me, but they can trust me exactly
because they know they don't have to.
LKML
June 7, 2008

Nobody actually creates perfect code the first time around, except
me. But there's only one of me.
Tech Talk: Linus Torvalds on git
October 3, 2007.

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. I don't know what you were doing. But trust me, it's
the only way you can do security, it's the only way you can do
development.
Tech Talk: Linus Torvalds on git
October 3, 2007

Microsoft: Linux kernel infringes upon 42 of their patents.

So the whole "We have a list and we're not telling you" should tell
you something. Don't you think that if Microsoft actually had
some really foolproof patent, they'd just tell us and go, "nyaah,
nyaah, nyaah!"?
Torvalds tells Microsoft to put up or shut up.
May 18, 2007

You try to claim that the GPLv3 causes "More developers", and
that, my idiotic penpal, is just crazy talk that you made up.
LKML
June 18, 2007

I don't ask for money. I don't ask for sexual favors. I don't ask for
access to the hardware you design and sell. I just ask for the thing I
gave you: source code that I can use myself.
LKML
June 14, 2007

Controlling a laser with Linux is crazy, but everyone in this room

is crazy in his own way. So if you want to use Linux to control an

industrial welding laser, I have no problem with your using

PREEMPT_RT.
Kernel development
2007

To the hardware manufacturers that refuse to release the

specifications of their hardware so they could operate with the Linux
kernel.
Is "I hope you all die a painful death" too strong?
Linus Torvalds talks future of Linux.
August 22, 2007

I'm an egotistical bastard, and I name all my projects after myself.

First Linux, now git.
First Linux, now git.
June 14, 2007

Me, I just don't care about proprietary software. It's not "evil" or
"immoral," it just doesn't matter. I think that Open Source can do
better, and I'm willing to put my money where my mouth is by
working on Open Source, but it's not a crusade it's just a
superior way of working together and generating code.

It's superior because it's a lot more fun and because it makes
cooperation much easier (no silly NDA's or artificial barriers to
innovation like in a proprietary setting), and I think Open Source
is the right thing to do the same way I believe science is better than
alchemy. Like science, Open Source allows people to build on a
solid base of previous knowledge, without some silly hiding.
But I don't think you need to think that alchemy is "evil." It's just
pointless because you can obviously never do as well in a closed
environment as you can with open scientific methods.
Why I 'Absolutely Love' GPL Version 2
March 19, 2007

I have an ego the size of a small planet, but I'm not always right
[...].
Re: clarification on git, central repositories and commit access lists. kde-coredevel@kde.org
August 20, 2007

On Fri, 3 Aug 2007, Miller, Marc wrote:

>
> I recently came across an article claiming that virtualization
> "liberates" the OS from the hardware, basically implying that
> the hypervisor can now contain all of the drivers and that
> the OS just needs to have a standard abstraction layer
> for accessing the true driver involved.
I think what you're seeing is virtualization proponents being
absolutely desperate for any reason to use virtualization.
The fact is, the absolute last place you want to see drivers is in the
hypervisor, not only because the added abstraction layer is
inevitably a big performance problem, but because hardware and
drivers are by definition buggier than "generic" code that can be
tested.
I expect hardware and drivers to reach the same kind of stability
we have in generic code the moment people no longer develop
hardware actively. At that point, drivers probably become stable
too, and can be put in the hypervisor. Any time before that
happens, you want the drivers "further out", rather than "closer in"
to the system.
So next time you hear about hypervisors doing anything at all, ask
yourself where the message comes from. Does it come from a
group of people who are desperately trying to make themselves
appear relevant? Or does it come from forty years of actual real-life
practice?

Side note: I don't doubt at all that virtualization is useful in some

areas. What I doubt rather strongly is that it will ever have the
kind of impact that the people involved in virtualization want it to
have. It would appear that virtualization is the "message-passing
microkernel" of this decade, and that people have a really hard
time accepting that the reason operating systems still basically
look 100% the same today as they did almost forty years ago, is
that that is simply a very practical arrangement!
So every decade, you'll find somebody who "reinvents" the OS.
Apparently just because they are bored with the fact that operating
systems have really been the same-old, same-old for a long time.
Guess what? Wheels have been round for a really long time, and
anybody who "reinvents" the new wheel is generally considered a
crackpot. It turns out that "round" is simply a good form for a
wheel to have. It may be boring, but it just tends to roll better than
a square, and "hipness" has nothing what-so-ever to do with it.
[Desktop_architects] Drivers - below the OS?
August 3, 2007

First off, I'm actually perfectly well off.

I live in a good-sized house, with a nice yard, with deer
occasionally showing up and eating the roses (my wife likes the
roses more, I like the deer more, so we don't really mind). I've got
three kids, and I know I can pay for their education. What more
do I need?
The thing is, being a good programmer actually pays pretty well;
being acknowledged as being world-class pays even better. I
simply didn't need to start a commercial company. And it's just
about the least interesting thing I can even imagine. I absolutely
hate paperwork. I couldn't take care of employees if I tried. A
company that I started would never have succeeded it's simply
not what I'm interested in! So instead, I have a very good life,
doing something that I think is really interesting, and something
that I think actually matters for people, not just me.
And that makes me feel good.
August 15, 2007

C++
From: Dmitry Kakurin
Subject: Re: Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 04:48:47 GMT

When I first looked at Git source code, two things struck me as

odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about
portability, it's BS.
2. Brute-force, direct string manipulation. It's both verbose and
error-prone. This makes it hard to follow high-level code logic.
YOU are full of bullshit.
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.
In other words: the choice of C is the only sane choice. I know
Miles Bader jokingly said "to piss you off", but it's actually true.
I've come to the conclusion that any programmer that would
prefer the project to be in C++ over C is likely a programmer that I
really would prefer to piss off, so that he doesn't come and screw
up any project I'm involved with.
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 (and

anybody who tells me that STL and especially Boost are
stable and portable is just so full of BS that it's not even
funny)
- 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.
In other words, the only way to do good, efficient, and systemlevel and portable C++ ends up to limit yourself to all the things
that are basically available in C. And limiting your project to C
means that people don't screw that up, and also means that you
get a lot of programmers that do actually understand low-level
issues and don't screw things up with any idiotic "object model"
crap.
So I'm sorry, but for something like git, where efficiency was a
primary objective, the "advantages" of C++ is just a huge mistake.
The fact that we also piss off people who cannot see that is just a
big additional advantage.
If you want a VCS that is written in C++, go play with Monotone.
Really. They use a "real database". They use "nice object-oriented
libraries".
They use "nice C++ abstractions". And quite frankly, as a result of
all these design decisions that sound so appealing to some CS
people, the end result is a horrible and unmaintainable mess.
But I'm sure you'd like it more than git.
gmane.comp.version-control.git
September 6, 2007

From: Dmitry Kakurin

Subject: Re: Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-07 00:21:37 GMT

I was coding in Assembly when there was no C.

Then in C before C++ was created.
Now days it's C++ and C#, and I have never looked back.

Unlike you, I actually gave reasons for my dislike of C++, and

pointed to examples of the kinds of failures that it leads to.
You, on the other hand, have given no sane reasons for using
C++.
The fact is, git is better than the other SCM's. And good taste (and
C) is one of the reasons for that.
To be very specific:
- simple and clear core data structures, with very lean and
aggressive code to manage them that takes the whole
approach of "simplicity over fancy" to the extreme.
- a willingness to not abstract away the data structures and
algorithms, because those are the whole point of core git.
And if you want a fancier language, C++ is absolutely the worst
one to choose. If you want real high-level, pick one that has true
high-level features like garbage collection or a good system
integration, rather than something that lacks both the sparseness
and straightforwardness of C, and doesn't even have the high-level
bindings to important concepts.
IOW, C++ is in that inconvenient spot where it doesn't help make
things simple enough to be truly usable for prototyping or simple

GUI programming, and yet isn't the lean system programming

language that C is that actively encourages you to use simple and
direct constructs.
It has nothing to do with dinosaurs. Good taste doesn't go out of
style, and comparing C to assembler just shows that you don't
have a frigging idea about what you're talking about.
gmane.comp.version-control.git
September 7, 2007

From: Dmitry Kakurin

Subject: Re: Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-07 01:08:40 GMT

As I said, it's a matter of believes. As such, any reasoning and

arguing will be endless and pointless, as for any other religious
issue.
I'll give you reasons why to use C++ for Git (not why C++ is better
for any project in general, as that again would be pointless):
1. Good String class will make code much more readable (and
significantly shorter)
2. Good Buffer class - same reason
3. Smart pointers and smart handles to manage memory and
file/socket/lock handles.
As it is right now, it's too hard to see the high-level logic thru
this endless-busy-work of micro-managing strings and memory.
Git has a brilliant high-level design (object database, using
hashes, simple and accessible storage for data and metadata).
Kudos to you!

The implementation: a mixture of C and shell scripts, command

line ninterface that has evolved bottom-up is so-so.
I don't see myself comparing assembler to C anywhere.
I was pointing out that I've been programming in different
languages (many more actually) and observed bad developers
writing bad code in all of them. So this quality "bad developer" is
actually language-agnostic.

> As it is right now, it's too hard to see the high-level logic thru
> this endless-busy-work of micro-managing strings and memory.
Total BS. The string/memory management is not at all relevant.
Look at the code (I bet you didn't). This isn't the important, or
complex part.
> IMHO Git has a brilliant high-level design (object database,
> using hashes, simple and accessible storage for data and
> metadata). Kudos to you!
> The implementation: a mixture of C and shell scripts, command
> line interface that has evolved bottom-up is so-so.
The only really important part is the design. The fact that some of
it is in a "prototyping language" is exactly because it wasn't the
core parts, and it's slowly getting replaced. C++ would in no way
have been able to replace the shell scripts or perl parts.
And C++ would in no way have made the truly core parts better.

> > and comparing C to assembler just shows that you don't have
>> a friggin idea about what you're talking about.

>> I don't see myself comparing assembler to C anywhere.

You made a very clear "assembler -> C -> C++/C#" progression in
your life, comparing my staying with C as a "dinosaur", as if it was
some inescapable evolution towards a better/more modern
language.
With zero basis for it, since in many ways C is much superior to
C++ (and even more so C#) in both its portability and in its
availability of interfaces and low-level support.

> I was pointing out that I've been programming in different

> languages (many more actually) and observed bad developers
> writing bad code in all of them. So this quality "bad developer"
> is actually language-agnostic.

You can write bad code in any language. However, some

languages, and especially some mental baggages that go with
them are bad.
The very fact that you come in as a newbie, point to some
absolutely trivial patches, and use that as an argument for a
language that the original author doesn't like, is a sign of you being
a person who should be disabused on any idiotic notions as soon
as possible.
The things that actually matter for core git code is things like
writing your own object allocator to make the footprint be as small
as possible in order to be able to keep track of object flags for a
million objects efficiently. It's writing a parser for the tree objects

that is basically fairly optimal, because there *is* no abstraction.

Absolutely all of it is at the raw memory byte level.
Can those kinds of things be written in other languages than C?
Sure. But they can not be written by people who think the "highlevel" capabilities of C++ string handling somehow matter.
The fact is, that is exactly the kinds of things that C excels at. Not
just as a language, but as a required mentality. One of the great
strengths of C is that it doesn't make you think of your program as
anything high-level. It's what makes you apparently prefer other
languages, but the thing is, from a git standpoint, "high level" is
exactly the wrong thing.
gmane.comp.version-control.git
September 7, 2007

So LSM stays in. No ifs, buts, maybes or anything else. When I see
the security people making sane arguments and agreeing on
something, that will change. Quite frankly, I expect hell to freeze
over before that happens, and pigs will be nesting in trees. But hey,
I can hope.
Pluggable Security
October 1, 2007

The fact is, there aren't just two sides to any issue, there's almost
always a range of responses, and "it depends" is almost always the
right answer in any big question.
Linus' blog: Black and white.
November 2, 2008

Real quality means making sure that people are proud of the code
they write, that they're involved and taking it personally.
Interview with Linus Torvalds of The Linux Foundation.
September 15, 2008

Security people are often the black-and-white kind of people that I

can't stand. 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.
Linux 2.6.25.10.
July 15, 2008

It's what I call "mental masturbation", when you engage is some

pointless intellectual exercise that has no possible meaning.
Geek of the Week Interview
July 17, 2008

My personal guiding principle is that I try very hard to find people

I can trust, and then try to get out of their way as much as
possible. I don't mean totally unconditional trust; but on the other
hand, once somebody maintains something, he really should be
able to make all the normal daily decisions.
I, in turn, try to make myself as trustworthy as I can. And in this
context, "trustworthy" is a lot about not surprising people. In
other words, 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. While they may
not necessarily like or agree with them all, at least they can trust
me to be reliable.
Part of that, by the way, is not feeling shy about saying impolite
things or showing some emotion. So 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.
There's the saying, "On the Internet, nobody can hear you being
subtle." Okay, so the saying is really, "On the Internet, nobody
knows you're a dog" or any number of other things, but my saying
is the "hear you being subtle" one. That's because, to be blunt,
subtlety or sarcasm simply doesn't get through, or it may not
translate to other cultures.

Part of that, of course, 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, and I'm not going to apply this
patch because it's obviously broken and is a total piece of shit. And
here's why..." But then at the end I'll include:
"And hey, maybe I'm just being a dick, and you can prove me
right, so please explain to me why you did that horrible thing.
Please? Hmm?"
This gives people the ability to tell me I'm being a dickhead and I
was wrong, and that all the reasons I called them idiots were
actually bogus.
Of course, it doesn't happen all that often. Or maybe it does, and
people are just too polite to point it out in public. Not that I've
met all that many polite people in kernel development, but that's
probably because I've scared them all away.

Anyway, the theory goes that it's better that people know how you
feel than then to be surprised by it later when you simply refuse to
take their code. Oreven worseif you end up taking crap code
because you feel it's too hard to call it crap and to tell them why
you refuse.
CIO.com,
Five Things Linus Torvalds Has Learned About Managing Software Projects
August 4, 2008

Sometimes "pi = 3.14" is (a) infinitely faster than the "correct"

answer and (b) the difference between the "correct" and the
"wrong" answer is meaningless. And this is why I get upset when
somebody dismisses performance issues based on "correctness".
The thing is, some specious value of "correctness" is often
irrelevant because it doesn't matter. While performance almost
always matters. And I absolutely detest the fact that people so
often dismiss performance concerns so readily.
Git mailing list,
August 8, 2008

I think Leopard is a much better system [than Windows Vista]

but OS X in some ways is actually worse than Windows to
program for. Their file system is complete and utter crap, which is
scary.
linux.conf.au conference
February 5, 2008

And what's the Internet without the rick-roll?

Redhat Bugzilla Bug 439858: swf mozilla plugin - no youtube
March 31, 2008

On Thu, 18 Dec 2008, jidanni@jidanni.org wrote:

>
> Gentlemen, I have found the solution to your problem.
YOUR problem.
Your problem has nothing to do with git, and everything to do
with emacs. And then you have the gall to talk about unix
design and not gumming programs together, when you yourself
use the most gummed-up piece of absolute shit there is!
Re: git-diff should not fire up $PAGER, period!
December 17, 2008

Crying that it's an application bug is like crying over the speed of
light: you should deal with reality, not what you wish reality was.
Theory and practice sometimes clash. And when that happens,
theory loses. Every single time.
LKML
March 25, 2009

The thing that has always disturbed me about O_DIRECT is that

the whole interface is just stupid, and was probably designed by a
deranged monkey on some serious mind-controlling substances.
[*]
[*] In other words, it's an Oracleism.
From NOTES topic of open(2) manpage
April 13, 2009

I may make jokes about Microsoft at times, but at the same time, I
think the Microsoft hatred is a disease.
Microsoft Patches Linux; Linus Responds
June 22, 2009

There are "extremists" in the free software world, but that's one
major reason why I don't call what I do "free software" any more. I
don't want to be associated with the people for whom it's about
exclusion and hatred.
Microsoft Patches Linux; Linus Responds.
June 22, 2009

Your code is shit your argument is shit too.

In reply to: Ingo Molnar: ""Re: announce new tree: fix all build warnings, on all
configs"
October 20, 2008

So I would not be surprised if the globbing libraries, for example,

will do NFD-mangling in order to glob "correctly", so even
programs ported from real Unix might end up getting pathnames
subtly changed into NFD as part of some hot library-on-library
action with UTF hackery inside.
Piece of crap it is, though. Apple has painted themselves into a
nasty corner there.
Git,
23 Jan 2008

We're getting bloated and huge. Yes, it's a problem.

I'd love to say we have a plan. Sometimes it's a bit sad that we are
definitely not the streamlined, small, hyper-efficient kernel that I
envisioned 15 years ago...The kernel is huge and bloated, and our
cache footprint is scary. I mean, there is no question about that.
And whenever we add a new feature, it only gets worse.
However, stability is not a problem. I think we've been pretty
stable. We are finding the bugs as fast as we're adding them
even though we're adding more code.

No, I'm not saying that the current level of integration is

acceptable under those terms. Acceptable and avoidable are two
different things. It's unacceptable but it's also probably
unavoidable.
LinuxCon 2009,
September 22, 2009

Every time I see some piece of medical research saying that caffeine
is good for you, I high-five myself.
Because I'm going to live forever.
Linus Blog
August 3, 2010

And pointing fingers at Adobe and blaming them for creating bad
software is doubly irresponsible if you are then not willing to set a
higher standard for your own project. And "not my problem" is
not a higher standard.
Quite frankly, I find your attitude to be annoying and downright
stupid. So please just fix it.
How hard can it be to understand the following simple sentence:
THE USER DOESN'T CARE.
Pushing the blame around doesn't help anybody. The only thing
that helps is being helpful, not being obstinate.
November 30, 2010

Standards are paper. I use paper to wipe my butt every day. That's
how much that paper is worth.
Reality is what matters.
November 30, 2010

Torvalds contemplating his appearance at an Oscar Party

My life isn't glamorous.

I know that comes as a big shock to everybody, since geeks in
general are seen as the crme de la crme of society, and the
common perception is that we live the life of rock-stars and party
all night with all the other glamorous people.
Not so.
I sit in my office (which used to be in the basement, now it's a
room above the garage), usually in my ratty bathrobe, reading and
writing email all day. And a lot of wasting time while waiting for
people to answer or just report problems. I go to bed at ten, and
wake up at seven to get the kids to school. And then it all repeats.
So not glamorous. When I actually write code (which is usually in
the mail reader these days - mostly telling people "do it like this"
rather than actually writing real code), that's about the most
exciting part of the day.
But then, once in a while, I get to live the high life. This weekend,
we got invited to the Night Before Oscar party (thanks Rene and
Doug!) because sometimes the companies I work with apparently
think that I need to get a night out.
Toto, I don't think we're talking white-socks-and-sandals any
more.

So me and the wife were completely out of our depth, and knew
absolutely nobody. We go out for a date night every week, so we a
fair number of movies, but we really aren't movie people - the
kinds of movies we go to don't make a huge impression. So there
we were, cram-packed with celebrities, not remembering names or
faces.
The good news was, that as Tove said, there was no real downside.
Nobody knew us, and nobody would ever remember us the next
day. So we could go whole retard quite openly, and brazenly just
ask people "You look really familiar, who are you?". Which we
did. With some discreet google image searches when we could
guess, and just wanted to verify it ("John Cusack or Paul Rudd?").
Everybody seemed to take it in good cheer. We interrupted David
Spade chatting up Natalie Portman and Mila Kunis (that's what
Tove says, I was oblivious - it's those famous geek social graces
again. I told her I'm sure I'd have noticed Natalie Portman and that
she can't possibly have been there, but whatever), and Tove pissed
off Warren Beatty by asking his name not just once, but twice.
So here's a shout-out to my new BFF's Jon Hamm and DJ.
We probably won't be invited again. But we have pictures for the
kids, to prove to them that their parents are cool people.
Linus' Blog,
February 28, 2011

Linus Torvalds on the issue of Android

potentially violating the Linux kernel's copyright

It seems totally bogus. We've always made it very clear that the
kernel system call interfaces do not in any way result in a derived
work as per the GPL, and the kernel details are exported through
the kernel headers to all the normal glibc interfaces too.
The kernel headers contain various definitions for the interfaces to
user space, and we even actively try to make sure that the headers
can be used by user space (and try to mark which of the headers
are expected to be usable in such a way). Exactly because we know
user space needs those details in order to interact with the kernel.
So I haven't looked at exactly what Google does with the kernel
headers, but I can't see that they'd want to do anything
fundamentally different from glibc in this respect.
Of course, we do have our own 'internal' headers too, and we have
stuff that is meant to be relevant only for the kernel. But there
would be no point for Google to even use those, since they are
useless outside of the kernel, so I don't see what the whole
brouhaha would be all about. Except if it's somebody politically
motivated (or motivated by some need of attention)," he
continued.
If it's some desperate cry for attention by somebody, I just wish
those people would release their own sex tapes or something,
rather than drag the Linux kernel into their sordid world.
Letter to ITWorld
March 21, 2011

Why don't we write code that just works? Or absent a "just works"
set of patches, why don't we revert to code that has years of
testing? This kind of "I broke things, so now I will jiggle things
randomly until they unbreak" is not acceptable. [...] Don't just
make random changes. There really are only two acceptable
models of development: "think and analyze" or "years and years of
testing on thousands of machines". Those two really do work.
gmane.linux.kernel, Linux 2.6.39-rc3
April 13, 2011

Technologies that lock things down tend to lose in the end. People
want freedom and markets want freedom.
Im an optimist: openness is successful in the long run, secure boot
is another one of these passing fads.
LinuxCon Brazil
November 18, 2011

Venting.
I don't think I can talk about "security" people without cursing, so
you might want to avert your eyes now.
I gave OpenSUSE a try, because it worked so well at install-time
on the Macbook Air, but I have to say, I've had enough. There is
no way in hell I can honestly suggest that to anybody else any
more.
I first spent weeks arguing on a bugzilla that the security policy of
requiring the root password for changing the timezone and adding
a new wireless network was moronic and wrong.
I think the wireless network thing finally did get fixed, but the
timezone never did - it still asks for the admin password.
And today Daniela calls me from school, because she can't add the
school printer without the admin password.
Whoever moron thought that it's "good security" to require the
root password for everyday things like this is mentally diseased.
So here's a plea: if you have anything to do with security in a
distro, and think that my kids (replace "my kids" with "sales
people on the road" if you think your main customers are
businesses) need to have the root password to access some wireless
network, or to be able to print out a paper, or to change the dateand-time settings, please just kill yourself now. The world will be a
better place.
.. and now I need to find a new distro that actually works on the
Macbook Air.

Google+
February 28, 2012

We're not masturbating around with some research project. We

never were. Even when Linux was young, the whole and only
point was to make a usable system. It's why it's not some crazy
drug-induced microkernel or other random crazy thing.
LKML
March 8, 2012

Northeast Portland man who stripped naked at airport is acquitted

of indecent exposure charge
Good job. More public indecency, less TSA, that's what I say.
Google+
July 18, 2012

Somebody is trying to kill all the kernel developers.

First we had two earthquakes - fine, this week God not only hates
republicans, but apparently us kernel developers too. But we
kernel developers laugh in the face of danger, and a 5.5 earthquake
just makes us whimper and hide in the closet for a while.
But after we've stopped cowering in the closet, there's a knock on
the door, and the conference organizers are handing out skate

boards, with the innocent explanations of "We're in San Diego,

after all".
If that's not a sign of somebody trying to kill us, I don't know what
is. Handing out skate boards to a bunch of geeks sounds like a
seriously misguided thing to do.
Google+
August 26, 2012

I really hate big laptops. I can't understand people who lug around
15" (or 17"!) monsters. The right weight for a laptop is 1kg, no
more.
Obsessing about things is important, and things really do matter,
but if you can't let go of them, you'll end up crazy.
Slashdot Interview
October 11, 2012

WE DO NOT BREAK USERSPACE!

LKML
December 23, 2012

Of course, I'd also suggest that whoever was the genius who
thought it was a good idea to read things ONE FUCKING BYTE
AT A TIME with system calls for each byte should be retroactively
aborted. Who the fuck does idiotic things like that? How did they
not die as babies, considering that they were likely too stupid to
find a tit to suck on?
LKML
June 6, 2012

I'm not sentimental. Good riddance.

Linux Nukes 386 Support
December 12, 2012

I don't do Github pull requests.

Github throws away all the relevant information, like having even
a valid email address for the person asking me to pull. The diffstat
is also deficient and useless.
Git comes with a nice pull-request generation module, but Github
instead decided to replace it with their own totally inferior version.
As a result, I consider Github useless for these kinds of things. It's
fine for hosting, but the pull requests and the online commit
editing, are just pure garbage.
I've told Github people about my concerns, they didn't think they
mattered, so I gave up. Feel free to make a bugreport to Github.
github.com
11 May 2012

I have no problem with people using Github as a hosting site.

But in order for me to pull from Github, you need to
a) make a real pull request, not the brain damaged crap that
Github does when you ask it to request a pull: real
explanation, proper email addresses, proper shortlog, and
proper diffstat.
b) since Github identities are random, I expect the pull request
to be a signed tag, so that I can verify the identity of the
person in question.

I also refuse to pull commits that have been made with the Github
web interface. Again, the reason for that is that the way the Github
web interface work, those commits are invariably pure crap.
Commits done on Github invariably have totally unreadable
descriptions, because the Github commit making thing doesn't do
*any* of the simplest things that the kernel people expect from a
commit message:
- no "short one-line description in the first line"
- no sane word-wrap of the long description you type: github
commit messages tend to be (if they have any description at
all) one long unreadable line.
- no sign-offs etc that we require for kernel submissions.
Github could make it easy to write good commit messages and
enforce the proper "oneliner for shortlogs and gitk, full
explanation for full logs". But Github doesn't. Instead, the Github
"commit on the web" interface is one single horrible text-entry
field with absolutely no sane way to write a good-looking message.
Maybe some of this has changed, I haven't checked lately. But in
general, the quality of stuff I have seen from people who use the
Github web interfaces has been so low that it's not worth my time.
I'm writing these explanations in the (probably vain) hope that
people who use Github will actually take them to heart, and
Github will eventually improve. But right now Github is a total
ghetto of crap commit messages and unreadable and unusable pull
requests.
And the fact that other projects apparently have so low
expectations of commit messages that these things get used is just
sad. People should try to compare the quality of the kernel git logs
with some other projects, and cry themselves to sleep.

By the way, Joseph, you're a quality example of why I detest the

Github interface. For some reason, Github has attracted people
who have zero taste, don't care about commit logs, and can't be
bothered.
The fact that I have higher standards then makes people like you
make snarky comments, thinking that you are cool.
You're a moron.
I think I've been able to reach my goals on the internet better than
most people. The fact that I'm very clear about my opinions is
probably part of it. If people get offended by accurate portrayals of
the current state of Github pull requests, that's their problem. I
hate that whole "victim philosophy". The truth shouldn't be
sugarcoated.
Anyway, you are obviously free to do your commit messages any
way you want. However, these are the rules we try to follow in the
kernel, and in git itself.
And quite frankly, anybody who thinks they have better rules had
better prove their point by showing a project with better commit
messages. Quite frankly, I've seen a lot of open-source projects,
and I have yet to see any project that does a better job of doing
good commit messages than the kernel or git. And I've seen a lot
of projects that do much worse.
So I would suggest taking the cue for good log messages from
projects that have proven that they really can do good log
messages. Linux and git are both good examples of that.
We do have standards, and the standards are there to make for
better logs.

I think Github does some things very well.

So sure, you may think I hate Github. I don't. I hate very specific
parts of Github that I think are done badly.
But other parts are done really, really well.
I think Github does a stellar job at the actual hosting part. I really
do. There is no question in my mind that Github is one of the
Absolute best places to host a project. It's fast, it's efficient, it
Works, and it's available to anybody.
That's wonderful. I think Github is absolutely lovely in many
respects.
And that then makes me really annoyed at the places where I think
Github does a subpar job: pull requests and committing changes
using the web interface.
I'm not a "rules over everything else" kind of black-and-white
person.
I'm basically describing what my requirements are. Not all Linux
sub-maintainers are necessarily as critical as I am, and yes, there
are ugly commit messages in the kernel too (and some of them are
very much about lacking proper word wrapping, for example).
So things slip through occasionally. I'm not German - rules are
good, and they set a standard that people should really try to strive
for (and quite frankly, hopefully exceed: the "formatting rules"
should preferably go with "really good and readable message that
really explains what is going on"), but rules are not some kind of
absolute thing that have to be 100% guaranteed.
So I don't worry about "still get soiled". Crap happens, we try to
minimize it.

What I dislike about the Github thing is that it's not "crap
happens, we'll try to minimize it", it's "crap absolutely WILL
happen". Instead of trying to minimize it, the commit message
editor actively revels in it, and makes it hard not to make a crappy
message.
Similarly, the pull request interface of Github makes it literally
impossible to make a good pull request. You literally cannot make
a good pull request using the Github web interface.
So right now, I encourage people to use Github as a hosting site,
but as a hosting site only. Don't create commits there, and don't
use Github for pull requests. Do your commits on your own
machine, push them to Github, and then when you're ready for a
pull request, again do it on your own machine and email it to the
maintainer that way.
So I'm really not trying to hate on Github. I only despise a few of
the small details of Github.
I read email. I don't look at web interface.
Github as a hosting site for open-source (or closed, for that
matter) projects is wonderful. Github as a place to generate
commits and pull requests? Not so much.
A good example of a pull request contains:
-

the real person with a real email asking me to pull,

the *explanation* of why I should pull,
a shortlog of the changes (a single line),
a proper diffstat.
github.com
12 May 2012

I wish everybody was as nice as I am.

I like offending people, because I think people who get offended
should be offended.
I started Linux as a desktop operating system. And it's the only
area where Linux hasn't completely taken over. That just annoys
the hell out of me.
People say that you should not micro-optimize. But if what you
love is micro-optimization... that's what you should do.
Nvidia has been one of the worst trouble spot we've had with
hardware manufacturers. And that is really sad, because Nvidia
tries to sell chips, a lot of chips, into the Android market,
and Nvidia has been the single worst company we've ever dealt
with.
So Nvidia, fuck you!
-

Audience Q&A at Aalto University Center,

June 14, 2012

From: George Spelvin

Huh. I prefer sizeof without parens, like I prefer return without
parens.
It actually annoys me when I see someone write
return(0);
Because it's not a function (our language is too low-level to use
continuation-passing style), it's magic syntax.
Sizeof likewise. I tend to use "p = malloc(sizeof *p)" a lot.
It just reads more nicely, to my eyes, than "p = malloc(sizeof(*p))".
If I wanted my code to be cluttered with parens, I'd write it in
Lots of Irritating Silly Parenthese.
Certainly, tha paren-less style is all over the kernel. It's heavily
used in arch/x86/boot, for example.
I guess it's what you're used to.

> Huh. I prefer sizeof without parens, like I prefer return without
parens.
Umm. The two have nothing to do with each other.

> It actually annoys me when I see someone write

>
>
return(0);
Absolutely. Anybody who does that is just terminally confused.
"return()" is in no way a function.
But "sizeof()" really *is* a function. It acts exactly like a function
of it's argument. There is no reason to not treat it that way. Sure,
the C standard *allows* you to not have parenthesis around an
expression argument, but you should treat that as the parsing
oddity it is, nothing more. There is zero reason not to have the
parenthesis there.
In contrast, "return" can never be part of an expression, and the
parenthesis never make any sense.
With "return", there's no precedence issues, for example.
With "sizeof()" there are: sizeof(x)+1 is very different from
sizeof(x+1), and having the parenthesis there make it clearer for
everybody (sure, you can write the first one as "sizeof x + 1", but
let's face it, the precedence is way more obvious if you just think of
sizeof as a function).
Here's an example of a really bad use of "sizeof" that doesn't have
the parenthesis around the argument: sizeof(*p)->member. Quite
frankly, if you do this, you should be shot. It makes people have to
parse the C precedence rules by hand. In contrast, parsing
sizeof((*p)->member) is *way* easier for humans.
And let's face it: if you write your code so that it's easy to parse for
a machine, and ignore how easy it is to parse for a human, I don't

want you writing kernel code. There's a reason we have the coding
standards. They aren't for the *compiler*. They are for *humans*.
And humans should think of sizeof() as a function, not as some
ass-backwards special case C parsing rule that is subtle as hell.
July 11, 2012

I realize that lawyers are brought up (probably from small

children) to think that "technically true" is what matters, but when
you make public PR statements, they should be more than
"technically" true. They should be honest. There's a big fucking
difference.
Google+
January 10, 2013

Intelligence is the ability to avoid doing work, yet getting the work
done.
January 29, 2013

But this is definitely another of those "This is our most desperate

hour. Help me, Al-biwan Ke-Viro, you're my only hope" issues. Al?
Please don't make me wear that golden bikini.
Re: fasync_remove_entry oops, gmane.linux.kernel
March 7, 2013

I hope I won't end up having to hunt you all down and kill you in
your sleep.
Google+
2013-04-05

Whoever came up with "hold the shift key for eight seconds to
turn on 'your keyboard is buggered' mode" should be shot.
Google+
June 23, 2013

There aren't enough swear-words in the English language, so now

I'll have to call you perkeleen vittup just to express my disgust
and frustration with this crap.
Re: [GIT pull] x86 updates for 3.11
July 13, 2013

From: Sarah Sharp

Seriously, guys? Is this what we need in order to get improve stable?
Linus Torvalds is advocating for physical intimidation and
violence. Ingo Molnar and Linus are advocating for verbal abuse.
Not *fucking* cool. Violence, whether it be physical intimidation,
verbal threats or verbal abuse is not acceptable. Keep it
professionalon the mailing lists.
Let's discuss this at Kernel Summit where we can at least yell at
each other in person. Yeah, just try yelling at me about this. I'll
roar right back, louder, for all the people who lose their voice
when they get yelled at by top maintainers. I won't be the nice girl
anymore.
July 15, 2013

That's the spirit.

Greg has taught you well. You have controlled your fear. Now,
release your anger. Only your hatred can destroy me.
Come to the dark side, Sarah. We have cookies.
July 15, 2013

From: Sarah Sharp

However, I am serious about this. Linus, you're one of the worst
offenders when it comes to verbally abusing people and publicly
tearing their emotions apart.
July 15, 2013

Yes. And I do it partly (mostly) because it's who I am, and partly
because I honestly despise being subtle or "nice".
The fact is, people need to know what my position on things are.
And Ican't just say "please don't do that", because people won't
listen. Isay "On the internet, nobody can hear you being subtle",
and I mean it.
And I definitely am not willing to string people along, either. I've
had that happen too - not telling people clearly enough that I don't
like their approach, they go on to re-architect something, and get
really upset when I am then not willing to take their work.
Sarah, first off, I don't have that many tools at hand. Secondly, I
simply don't believe in being polite or politically correct. And you
can point at all those cultural factors where some cultures are not
happy with confrontation (and feel free to make it about gender
too - I think that's almost entirely cultural too). And please bring
up "cultural sensitivity" while at it. And I'll give you back that
same "cultural sensitivity". Please be sensitive to my culture too.

Google "management by perkele".

Do you really want to oppress a minority? Because Finns are a
minority compared to almost any other country. If you want to
talk cultural sensitivity, I'll join you. But my culture includes
cursing.
And some of the above is written tonge-in-cheek, but all of it is
also serious. I really fundamentally believe that being honest and
open about your emotions about core/process is good. And
because it's damn hard to read people over email, I think you need
to be *more* honest and *more* open over email. I'm generally
nicer in person. Not always.
And yes, I'll happily be part of the discussion at the KS. But I think
you also need to be aware that your "high horse" isn't necessarily
all that high.
July 15, 2013

From: Sarah Sharp

Bullshit.
I've seen you be polite, and explain to clueless maintainers why
there's no way you can revert their merge that caused regressions,
and ask them to fit it without resorting to tearing them down
emotionally:
You just don't want to take the time to be polite to everyone.
Don't give me the "I'm not polite" card. Go write some
documentation about what's acceptable for stable. While you're at
it, write some more documentation about why it's impossible for
you to revert merges, so maintainers know not to send you crap,
or piss away time trying to argue with you that they don't need to

fix regressions. When maintainers challenge you, point them to it,

and say, "Fix this now."
If they protest, then you can bring out the big threats and say, "If
you don't fix this, I won't pull from you the next merge window.
Go find a backup maintainer that can handle your tree, and train
them for the next release. You may need to hand over your
maintainer ship to them."
If the maintainer doesn't have sub-maintainers that could take
over, that's a problem we need to fix *before* things like this
happen.
There are other tools at hand. You just don't use them.
July 15, 2013

Oh, I'll be polite when it's called for.

But when people who know better send me crap, I'll curse at them.
I suspect you'll notice me cursing *way* more at top developers
than random people on the list. I expect more from them, and
conversely
I'll be a lot more upset when they do something that I really think
was not great.
For example, my latest cursing explosion was for the x86
maintainers, and it comes from the fact that I *know* they know to
do better. The x86 tip pulls have generally been through way more
testing than most other pulls I get (not just compiling, but even
booting randconfigs etc). So when an x86 pull request comes in
that clearly missed that expected level of quality, I go to town.
Similarly, you will see fireworks if some long-term maintainer
makes excuses for breaking user space etc. That will make me go
into incoherent rages.

The "polite Linus" example that you point to? That was a
maintainer asking for direction for when things went wrong and
*before* sending me something dubious. Of course I'm polite then.
Sarah, I don't have Tourettes syndrome. You seem to think that
my cursing is uncontrolled and random. I argue that it has causes.
Big difference.
July 15, 2013

> BTW, I was amazed that you managed to get him have a much
softer tone in his last e-mail, you probably found a weakness here
in his management process :-)
Hey, I like arguing, and "cursing" and "arguing" are actually not at
all the same thing.
And I really don't tend to curse unless people are doing something
stupid and annoying. If people have concerns and questions that I
feel are valid, I'm more than happy to talk about it.
I curse when there isn't any argument. The cursing happens for the
"you're so fucking wrong that it's not even worth trying to make
logical arguments about it, because you have no possible excuse"
case.
.. and sometimes people surprise me and come back with a valid
excuse after all. "My whole family died in a tragic freak accident
and my pony got cancer, and I was distracted".
And then I might even tell them I'm sorry.
No. Not really.
2013-07-15

From: Sarah Sharp

Oh, FFS, I just called out on private email for "playing the victim
card". I will repeat: this is not just about me, or other minorities.
I should not have to ask for professional behavior on the mailing
lists.
Professional behavior should be the default.
July 15, 2013

Bullshit.
The thing is, the "victim card" is exactly about trying to enforce
your particular expectations on others, and trying to do so in a
very particular way. It's the old "think of the children" argument.
And it's bogus. Calling things "professional" is just more of the
same - trying to enforce some kind of convention on others by
trying to claim that it's the only acceptable way.
Since you seem to want to keep this in public, I'll justcut-and-paste
from my reply, so you have already seen this part of my argument,
it's only slightly edited because now I'm no longer typing on my
cellphone.
The thing is, different people act and react differently. On both
sides. And I think we should recognize that and also allow for
that.

And sometimes it means, for example, that people interact

primarily with certain people that they like more - because they are
a better "fit".
I think we actually do it very naturally, simply because we are
human, and this is how people interact in real life too. Sometimes
we do it consciously - the way we have people at various
companies that act as go-betweens - but most of the time we do it
just because humans are all about social interactions and we don't
even think about what we do and why.
For example, you work mostly through Greg. I don't think either
of you *planned* it that way, but it's likely because you guys work
well together.
See what I'm saying? People are different. I'm not polite, and I get
upset easily but generally don't hold a grudge - I have these
explosive emails. And that works well for some people. And it
probably doesn't work well with you.
And you know what? That's fine. Not everybody had to get along
or work well with each other. But the fact that it doesn't work with
you doesn't make it "wrong".
This isn't all that different from working around language issues
etc by having certain people work as in-betweens on that front.
And where we differ is in thinking either side has to necessarily
change. You think people need to act "nicer". While I think it's
*natural* that people have different behavior - and different
expectations. We all have issues somewhere and don't all like each
other. There are certain people I refuse to work with, for example.
They may be good engineers, but they just aren't people I can
work with.

And hey, I don't actually think we've personally even had any
problems. And I realize that you may react very strongly and get
nervous about us having problems, but realistically, do you
actually expect to like all the other kernel engineers?
And equally importantly, not everybody has to like you, or
necessarily think they have to be liked by you. OK?
So as far as I'm concerned, the discussion is about "how to work
together DESPITE people being different". Not about trying to
make everybody please each other. Because I can pretty much
guarantee that I'll continue cursing. To me, the discussion would
be about how to work together despite these kinds of cultural
differences, not about "how do we make everybody nice and sing
songs sound the campfire"
Do you think you might be interested in that kind of discussion
instead of the "you are abusing me" kind of discussion?
Because if you want me to "act professional", I can tell you that I'm
not interested. I'm sitting in my home office wearing 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.
Re: 3.10.1-stable review,
July 15, 2013

Hello everybody out there using Linux I'm doing a (free) operating system (just a hobby, even if it's big
and professional) for 486+ AT clones and just about anything else
out there under the sun. This has been brewing since april 1991,
and is still not ready. I'd like any feedback on things people
like/dislike in Linux 3.11-rc7.
I originally ported bash(1.08) and gcc(1.40), but others have taken
over user space and things still seem to work. This implies that I'll
get the final 3.11 release within a week, and I'd like to know what
features most people would want. Any suggestions are welcome,
but I won't promise I'll implement them :-)
Yeah, I don't really want to get feature requests this late in the rc
series.
But it is 22 years today since that email, and I would like people to
try the current 3.11-rc7 kernel I just cut and uploaded to the usual
places.
August 26, 2013

Im happy with the current timing of releases every 3 months

because it allows developers to take their time building new
features. If we miss the merge window, its not very long until the
next one comes, so we dont feel rushed to send in our code.
Don't hurry your code. Make sure it works well and is well
designed. Don't worry about timing.
One of the most important things for a maintainer isn't that he's a
super engineer. Its that you're responsive and people can rely on
you being there 24/7, 52 weeks a year.

Bugs in the code and other technical problems dont worry me as

much. The thing with technology is if you do something stupid
you can fix it.
What really keeps me up at night are the social issues and
problems with the development process. When tempers flare it
can be really stressful for a few days. I have flare-ups and that
works fine for me Other people tend to mull over things. It eats
at them for weeks on end, and those issues tend to be the painful
ones.
LinuxCon Europe, Edinburgh,
October 23, 2013

I do hope that the desktop people would try to work together and
work more on technology that trying to make the log-in screen
look really nice.
LinuxCon Europe, Edinburgh,
October 23, 2013

XML is crap. Really. There are no excuses. XML is nasty to parse

for humans, and it's a disaster to parse even for computers. There's
just no reason for that horrible crap to exist.
Google+
March 6, 2014

Lookie here, your compiler does some absolutely insane things

with the spilling, including spilling a constant. For Christs sake,
that compiler shouldn't have been allowed to graduate from
kindergarten. We're talking "sloth that was dropped on the head
as a baby" level retardation levels here.
Torvalds, Linus (2014-07-24). LKML: Linus Torvalds: Re: Random panic in
load_balance() with 3.16-rc.
July 24, 2014

I don't respect people unless I think they deserve the respect.

There are people who think that respect is something that should
be given, and I happen to be one of the people who is perfectly
happy saying no; respect should be earned. And without being
earned, you don't get it. It's really that simple.
DebConf 14: Q&A with Linus Torvalds
October 3, 2014

One of the things, none of the distributions have ever done right is
application packaging [...] making binaries for Linux desktop
applications is a major fucking pain in the ass.
DebConf 14: Q&A with Linus Torvalds
October 3, 2014

[GPL] version 3 was not a good "here we give you version 2" and
then we try to sneak in this new rules and try force everyone to
upgrade; that was the part I disliked. The FSF did really sneaky
stuff, downright immoral in my opinion.
DebConf 14: Q&A with Linus Torvalds
October 3, 2014

On the internet nobody can hear you being subtle.

One of the reasons we have this culture of strong language, that
admittedly many people find off-putting, 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.
Most people even if though they don't always necessarily like each
other, do tend to respect the code they generate. For Linux that's
the important part. What really matters is people are very involved
in generating the best technology we can.
LinuxCon Europe 2014,

October 18, 2014

The boldest prediction I can say is, I will probably release rc1 in
about a week.
LinuxCon Europe 2014,
October 18, 2014

Some people think I'm nice and are shocked when they find out
different. I'm not a nice person, and I don't care about you. I care
about the technology and the kernelthat's what's important to
me.
The most important part of open source is that people are allowed
to do what they are good at. All that diversity stuff is just details
and not really important.
- Linux.conf.au Conference in Auckland, New Zealand,
January 15, 2015

What I wanted to say and clearly must have done very badly
is that one of the great things about open source is exactly the
fact that different people are so different. I think people sometimes
look at it as being just 'programmers,' which is not true. It's about
all the people who are more oriented toward commercial things,
too. It's about all those people who are interested in legal issues
and the social ones, too!
There's a lot of talk about gender and sexual preferences and race,
but we're different in so many other ways too.
'Open source' as a term and as a movement hasn't been about 'you
have to be a believer. It's not a religion. It's not an 'us vs them'
thing. We've been able to work with all those 'evil commercial
interests' and companies who also do proprietary software. And I
think that was one of the things that the Linux community (and
othersdon't get me wrong, it's not unique to us) did and does
well.

Which is not to say that a lot of people aren't around because they
believe it's the ethical thing to do (I do myself too). But you don't
have to believe that, and you can just do it because it's the most
fun, or the most efficient way to do technology development.
-

Letter to Ars Technica,

January 16, 2015

I don't know where you happen to be based, but this 'you have to
be nice' seems to be very popular in the US. This concept is like an
ideology. The same way we have developers and marketing people
and legal people who speak different languages, I think we can
have some developers who are used toand prefera
more confrontational style, and still also have people who don't.
Brainstorming? Maybe it works for some people, but I happen to
simply not believe in it. I'd rather be really confrontational, and
bad ideas should be [taken] down aggressively. Even good ideas
need to be vigorously defended.
Maybe it's just because I like arguing. I'm just not a huge believer
in politeness and sensitivity being preferable over bluntly letting
people know your feelings. But I also understand that other people
are driven away by cursing and crass language when it all gets a bit
too carried away. The open source movement might simply need
more people who are good at mediating.
-

Letter to Ars Technica,

January 16, 2015

I'd expect just more of (and much fancier) rather targeted AI,
rather than anything human-like at all. Language recognition,
pattern recognition, things like that.
I just don't see the situation where you suddenly have some
existential crisis because your dishwasher is starting to discuss
Sartre with you. The whole 'Singularity' kind of event? Yeah, it's
science fiction, and not very good Sci-Fi at that, in my opinion.
Unending exponential growth? What drugs are those people on?
slashdot.org
July 8, 2015

On Wed, Sep 2, 2015 at 10:35 PM, David Miller

<davem@davemloft.net> wrote:
>
> Another merge window, another set of networking
> changes. I've heard rumblings that the lightweight
> tunnels infrastructure has been voted networking
> change of the year.
.. and others say that the most notable feature is the idiotic bugs
that it introduces, and the compiler even complains about.
Christ, people. Learn C, instead of just stringing random
characters together until it compiles (with warnings).
This:
static bool rate_control_cap_mask(struct ieee80211_sub_if_data *sdata,
struct ieee80211_supported_band *sband,
struct ieee80211_sta *sta, u32 *mask,
u8 mcs_mask[IEEE80211_HT_MCS_MASK_LEN])

is horribly broken to begin with, because array arguments in C

don't actually exist. Sadly, compilers accept it for various bad
historical reasons, and silently turn it into just a pointer argument.
There are arguments for them, but they are from weak minds.
But happily gcc has a really really valid warning (kudos - I often
end up ragging on the bad warnings gcc has, but this one is a

keeper), because a few lines down the mistake then turns into pure
and utter garbage.
It's garbage that was basically encouraged by the first mistake
(thinking that C allows array arguments), namely:
for (i = 0; i < sizeof(mcs_mask); i++)

the "sizeof(mcs_mask)" is shit. Since array arguments don't

actually exist in C, it is the size of the pointer, not the array. The
first mistake makes the bug look like reasonable code. Although
I'd argue that the code would actually be bad regardless, since
"sizeof" is the size in bytes, and the code actually wants the
number of entries (and we do have ARRAY_SIZE() for that).
Sure, in this case the entries are just one byte each, so it would
have worked had it not been for the array argument issue, but it's
misleading and the code is just fundamentally buggy and
nonsensical in two entirely different ways that fed on each other.
That line should read
for (i = 0; i < IEEE80211_HT_MCS_MASK_LEN; i++)

and the argument should just have been declared as the pointer it
actually is.
A later patch then added onto the pile of manure by adding
another broken array argument, but at least that one then used the
proper loop for traversal of that array.
The fact that I notice this bug from a very basic "let's just compile
each pull request and make sure it isn't complete crap" is sad.

Now, it looks like the code was just moved, and the "sizeof()" was
initially correct (because it was a size of an actual array). Well, it
was "correct" in the sense that it generated the right code, even if
the whole confusion between "number of entries" and "size in
bytes" was still there. Then it got moved and turned from
"confused but happens to generate correct code" into "buggy pile
of bovine manure". See commit 90c66bd2232a ("mac80211:
remove ieee80211_tx_rate dependency in rate mask code").
So I can see how this bug happened, and I am only slightly upset
with Lorenzo who is the author of that commit.
What I can't see is why the code has existed in at least two
maintainer trees (Johannes' and David's) for a couple of weeks,
and nobody cared about the new compiler warnings? And it was
sent to me despite that new warning?
I really want people to take a really hard look at functions that use
arrays as arguments. It really is very misleading, even if it can look
"prettier", and some people will argue that it's "documentation"
about how the pointer is a particular size. But it's neither. It's
basically just lying about what is going on, and the only thing it
documents is "I don't know how to C". Misleading documentation
isn't documentation, it's a mistake.
I see it in that file for at least the functions rate_idx_match_mask()
and rate_control_cap_mask(). I tried - and failed - to come up
with a reasonable grep pattern to try to see how common it is, and
I'm too lazy to add some sparse check for it.
Please people. When I see these kinds of obviously bogus code
problems, that just makes me very upset. Because it makes me

worry about all the non-obvious stuff that I miss. Sadly, this time I
had pushed out the merge early (because I wanted to test the
wireless changes on my laptop), so now the bug is out there.
I'm not sure what the practical impact of the bug is. Yes, it only
traverses four or eight rate entries (depending on 32-bit or
64-bitness of the kernel) out of the ten that it should. But maybe in
practice one of the first entries are always good enough matches.
So maybe testing doesn't actually show this bug, but I sure wish
people just took compiler warnings more seriously (and were a lot
more careful about moving things to functions, and never ever
used the "function argument is an array" model).
LKM mailing list,
September 03, 2015

Security people will always be unhappy.

LinuxCon Europe, Dublin
October 9, 2015

I don't see any challenge in finding people to contribute. It's fairly

easy but a bit scary to approach the kernel and do small patches.
I'm more worried about the next step and finding the people that
go from trivial patches to being active maintainers.
LinuxCon Europe, Dublin,
October 9, 2015

Torvalds himself is a maintainer of the kernel as a whole, and a

question that is repeatedly asked is, "What if Linus were to get hit by
a bus?"
It's a question that moved a tad closer to reality at the Linuxcon EU
event in Dublin. Hohndel said he had to warn Torvalds while on
route to his keynote to avoid being hit by a bus when he was crossing
a street.
Where I live there are no buses. Here they're coming from the
wrong side of the road and they're aiming for you.
LinuxCon Europe, Dublin,
October 9, 2015

I'm happy to see that ARM is making progress. One of these days,
I will actually have a machine with ARM. They said it would be
this year, but maybe it'll be next year. 2016 will be the year of the
ARM laptop.
LinuxCon Europe, Dublin
October 9, 2015

"On the internet, nobody can hear you being subtle"

.. and it turns out that apparently you can replace "internet" with
"stage".
The real point that I was trying to make (and clearly failed at) is
that I've been waiting for widely available ARM kernel
development machines for years now, but it seems to always be
next year.
Im hoping that we'll actually see a real ARM (well, preferably
ARM64) machine one of these days that you can actually develop
on, rather than treat just as a development target. The Rasberry
PI's, Beagleboards etc are all fun, and all the cellphones and
Chromebooks are clearly selling well, but as a developer I feel
something is still missing in the market.
I guess the journalists in the audience weren't familiar with the
"The year of the <select something that never seems to happen>"
meme in the Linux community.
Google+
October 10, 2015