Linus Torvalds经典语录（一）

一

On Sun, Dec 23, 2012 at 6:08 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
>
> Are you saying that pulseaudio is entering on some weird loop if the
> returned value is not -EINVAL? That seems a bug at pulseaudio.

Mauro, SHUT THE FUCK UP!

It's a bug alright - in the kernel. How long have you been a
maintainer? And you *still* haven't learnt the first rule of kernel
maintenance?

If a change results in user programs breaking, it's a bug in the
kernel. We never EVER blame the user programs. How hard can this be to
understand?

To make matters worse, commit f0ed2ce840b3 is clearly total and utter
CRAP even if it didn't break applications. ENOENT is not a valid error
return from an ioctl. Never has been, never will be. ENOENT means "No
such file and directory", and is for path operations. ioctl's are done
on files that have already been opened, there's no way in hell that
ENOENT would ever be valid.

> So, on a first glance, this doesn't sound like a regression,
> but, instead, it looks tha pulseaudio/tumbleweed has some serious
> bugs and/or regressions.

Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious
garbage and idiocy from a kernel maintainer again. Seriously.

I'd wait for Rafael's patch to go through you, but I have another
error report in my mailbox of all KDE media applications being broken
by v3.8-rc1, and I bet it's the same kernel bug. And you've shown
yourself to not be competent in this issue, so I'll apply it directly
and immediately myself.

WE DO NOT BREAK USERSPACE!

Seriously. How hard is this rule to understand? We particularly don't
break user space with TOTAL CRAP. I'm angry, because your whole email
was so _horribly_ wrong, and the patch that broke things was so
obviously crap. The whole patch is incredibly broken shit. It adds an
insane error code (ENOENT), and then because it's so insane, it adds a
few places to fix it up ("ret == -ENOENT ? -EINVAL : ret").

The fact that you then try to make *excuses* for breaking user space,
and blaming some external program that *used* to work, is just
shameful. It's not how we work.

Fix your fucking "compliance tool", because it is obviously broken.
And fix your approach to kernel programming.

               Linus

二

On Wed 5 Sep 2007, Dmitry Kakurin wrote:
>
> 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. 

*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 system-level 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.

			Linus

On 9/6/07, Linus Torvalds <torvalds <at> linux-foundation.org> wrote:
> On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
> >
> > 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.
>
> *YOU* are full of bullshit.

nice

> 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.

As dinosaurs (who code exclusively in C) are becoming extinct, you
will soon find yourself alone with attitude like this.

Measuring number of people who contributed to Git is incorrect metric.
Obviously C++ developers can contribute C code. But assuming that they
prefer it that way is wrong.

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.
Bad developers will write bad code in any language. But penalizing
good developers for this illusive reason of repealing bad contributors
is nonsense.

Anyway I don't mean to start a religious C vs. C++ war. It's a matter
of beliefs and as such pointless.
I just wanted to get a sense of how many people share this "Git should
be in pure C" doctrine.
-- 
- Dmitry

On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
> 
> As dinosaurs (who code exclusively in C) are becoming extinct, you
> will soon find yourself alone with attitude like this.

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.

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 friggin idea 
about what you're talking about.

			Linus

On 9/6/07, Linus Torvalds <torvalds <at> linux-foundation.org> wrote:
>
>
> On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
> >
> > As dinosaurs (who code exclusively in C) are becoming extinct, you
> > will soon find yourself alone with attitude like this.
>
> Unlike you, I actually gave reasons for my dislike of C++, and pointed to
> examples of the kinds of failures that it leads to.

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.

> You, on the other hand, have given no sane reasons *for* using C++.

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.

> The fact is, git is better than the other SCM's. And good taste (and C) is
> one of the reasons for that.

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.

> 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.
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.
-- 
- Dmitry

On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
> 
> 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 nin 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
> lan

On 9/6/07, Linus Torvalds <torvalds <at> linux-foundation.org> wrote:
> On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
> >
> > 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.

Not only have I looked at the code, I've also debugged it quite a bit.
Granted most of my problems had to do with handling paths on Windows
(i.e. string manipulations).

Let me snip "C is better than C++" part ...
> [ snip ]
... and explain where I'm coming from:
My goal is to *use* Git. When something does not work *for me* I want
to be able to fix it (and contribute the fix) in *shortest time
possible* and with *minimal efforts*. As for me it's a diversion from
my main activities.
The fact that Git is written in C does not really contribute to that goal.
Suggestion to use C++ is the only alternative with existing C codebase.
So while C++ may not be the best choice "academically speaking" it's
pretty much the only practical choice.

"Democracy is the worst form of government except for all those others
that have been tried." - Winston Churchill

Now, I realize that I'm a very infrequent contributor to Git, but I
want my opinion to be heard.
People who carry the main weight of developing and maintaining Git
should make the call.
-- 
- Dmitry

三

So NVIDIA, FUCK YOU!!! -- Linus Torvalds
My name is Linus Torvalds and I am your god. -- Linus Torvalds
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. -- Linus Torvalds
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. -- Linus Torvalds
OS X in some ways is actually worse than Windows to program for. Their file system is complete and utter crap, which is scary. -- Linus Torvalds
Microsoft isn't evil, they just make really crappy operating systems. -- Linus Torvalds
I think the OpenBSD crowd is a bunch of masturbating monkeys. -- Linus Torvalds
I claim that Mach people (and apparently FreeBSD) are incompetent idiots. -- Linus Torvalds
Your code is shit … Are you just making changes by randomly inserting and deleting characters until you don't see warnings? Or what? … I don't want to see obvious and shitty crap like this … Fuck me, what's wrong with you people? -- Linus Torvalds
Comprende? None of this "there is no way to continue" bullshit. Because it is pure and utter SHIT. -- Linus Torvalds
What the FUCK, guys? This piece-of-shit commit is marked for stable, but you clearly never even test-compiled it, did you? … 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. -- Linus Torvalds
As it is, the patches are COMPLETE AND UTTER GARBAGE. They do literally insane things. They do things that do not make
sense. That makes all your arguments questionable and suspicious. The patches do things that are not sane. WHAT THE F*CK IS GOING ON? And that's actually ignoring the much _worse_ issue, namely that the whole hardware interface is literally mis-designed by morons. -- Linus Torvalds