

Linus - I'm a bastard Speech (2000) - vinutheraj
http://lwn.net/2000/0914/a/lt-debugger.php3

======
scottdw2
Personally, I find arguments against using debuggers to be absurd. More
importantly, I think they tend to promote ponitification over science.

Using a debugger is, effectively, taking a scientific approach to
understanding a software system. It's similar to using a microscope to examine
bacteria. The programmer sets up an experiment, and then uses the debugger to
observe the software system and learn about how it works.

The approach Linus advocates is one of "ponitification", where the wise pontif
examines his scrolls, and makes a declaration of truth.

Its interesting to note that the barrier to understanding how software works
via experimentation is much lower than the barrier to understanding it by
reading every line of source code.

In the mail, Linus states that his goals in excluding debuggers from the main
kernel sources is to discourage people from using debuggers to develop
features, because developing with a sense of deep understanding results in
better software. However, it also excludes one of the most useful tools for
developing that sense of understanding.

I can't speak to personal motivations, because I don't know the man, but that
type of behavior does smell somewhat of self-preservation. Ensuring that it is
difficult to acquire a complete understanding of Linux, makes it more
difficult for him to loose his position of influence.

Regardless of his motivations, however, lies the central fact that barriers to
knowledge are detrimental to an open society.

Given the value that the linux community places on "openness", "freedom", and
"egalitarnisim", and his position as a leader in that community, I would think
he should want to eliminate those barriers.

If that increases the burden of incorporating change into the kernel, because
the quality of developers is diluted by use of debuggers, than so be it.

This is equivalent to the notion that the burden of proof in acquiring a
criminal conviction is placed on the state, not the defendant. Yes this means
that everyone needs to work harder at justice, and that sometimes guilty
people go free. However, in the end, it ensures that people actually remain
free.

------
nearestneighbor
Linus's general attitude "developer time does not matter" is appropriate only
when you have free slave labor that you can afford to waste.

~~~
DougBTX
Sure, developer time matters. But you've got to be able to recognise sunk
cost, the product of 100 hours work should only ship if it is better than what
came before. The end result matters more than the developers time - if it
fails, there won't be any money to pay the developer, no matter how long he
has been working.

~~~
nearestneighbor
I'm not talking about "sunk cost", but developer productivity. He doesn't care
about it, but most people should.

~~~
JanezStupar
I believe productivity does matter to him. It's just that he wants people who
can a-ha their way out of the problem, the gifted people.

So loosing thousands of good/average people in favor of couple of elites is
the price he is willing to pay. Meaning he does care for productivity.

It's just that this "care" manifests in a utterly devious and fiendish manner.

Because he is a bastard. And I understand, because I am a bastard. And I don't
care either. We don't care about being nice, because being nice to weak people
doesn't help anyone. Weak people fail if you are nice to them or not. Strong
people don't care if you are nice. If you are not nice they will challenge
you. If you are strong you earn respect and allies. If your a weak wise guy,
you better GTFO :).

Essentially it's about being nice to weak people (giving debugger). And in the
world of Elite it doesn't make sense.

Think thermopylae It's an wonderful example of what a group of elites can do.
And I believe the Spartans weren't known as nice and understanding bunch.

~~~
ajb
What's your company called? I'd like to avoid doing business with it.

~~~
JanezStupar
Sadly, the company I work for is full of weak, ordinary people :).

Now you see, what I said above could only be understood by people who are
fundamentally different.

Should everybody be like that? No way! Are people like that suitable for any
job? No way! But there are jobs that they CAN and DO better than other people.

The whole weak/strong argument does not mean that people like us kick old
ladies. But it's pretty likely that we are willing to go against the odds to
prove a point or make a difference.

I'm sad that you don't understand the underlying meaning, but I will not shed
a tear.

~~~
nostrademons
I see what you're saying. I've felt that way myself sometimes.

It's usually called "arrogance". ;-)

------
DannoHung
I would like to mock propose the following idea: A Debugger License. Like a
driver's license, you have to have a certain amount of experience and
qualification to operate a debugger. Improper use of your debugger may incur
fines and penalties up to the revocation of your license.

Licensing should involve operational demonstration of design capacity,
testing, and reasoning. After passing the initial phase of licensing, you may
operate the debugger under supervision to learn the full spectrum of debugger
capabilities (no point using a tool poorly, after all). [/tongue:cheek]

I don't really blame people for using debuggers badly though. They're one of
the few practical coding tools that time is actually spent on in university
classes. In my experience, we were expected to use them to understand the
operation of the stack frame and heap in decoding a program especially built
around having funny tricks. To throw back to my analogy, it's a bit like
teaching a new driver how to do a powerslide before teaching them to obey stop
signs.

------
btilly
That speech fed into an interesting discussion on the merits of debuggers at
<http://www.perlmonks.org/?node_id=48495>. Note that "merlyn" in that
discussion is Randal Schwartz, who is well-known in both Perl and Smalltalk
circles.

------
lsc
hm. "And sure, when things crash and you fsck and you didn't even get a clue
about what went wrong, you get frustrated."

It seems that a serial console, even though it doesn't give you as much info
as a full kernel dump, would at least give you the panic message and a back
trace, which is usually enough clue to figure out what happened or to ask for
help.

~~~
antonovka
Putting aside the live debugger issue, most UNIXes support generating a full
kernel core dump that can be used post-facto to debug the panic using the
standard debugging tools -- you get full access to the memory contents,
machine state, a backtrace, etc.

It's very, very useful when you have a difficult to reproduce problem that
only occurs on a small subset of your machines while in production.

Up until relatively recently, Linux had no support for this, and I believe
still has no official support. RedHat EL ships a modified system with crash
dump support, and other hacked in implementations exist.

When we had Linux machines regularly crashing once every couple weeks in
~2003, we couldn't even get a usable oops out of them -- we just gave up and
rebooted them regularly. When we saw the same thing occur on a new FreeBSD
release a few years later, we enabled crash dumps and found and fixed the
issue immediately.

Linus is intelligent, but his oft-unchecked arrogance begets some particularly
unfortunate foolishness.

~~~
lsc
you did not get an oops or a backtrace out of your logging serial consoles? I
mean, I understand that a kernel dump does give you even more information, but
a logging serial console does give you a lot of information, usually enough.

the kernel support for kdump is in the upstream kernel.org tree, I believe.
you've gotta monkey with your initrd and the userland tools, though, last time
I looked. It does seem pretty silly that linux seems to want to change the
standard way to do crash dumps every two years. *BSD is much cleaner in this
regard. But in my experience, a logging console is usually as useful (and
sometimes more useful; logging consoles help in cases when the problem isn't a
kernel panic, but is instead a weird network issue.) than kernel dumps. I
remember last time I tried to debug an issue with kdump, the kernel would
crash, then it would load the kdump kernel, but that, too would crash before
dumping the kernel. (It turns out it was a hardware issue with the raid
controller. Dumping to disk when disk is the problem doesn't work so well.)

But then, I'm a computer janitor, and not a kernel developer. I imagine there
are reasons to get a full kernel dump when you are concerned with more than
"Is this a kernel issue or is it bad hardware?"

------
thras
_"I happen to believe that not having a kernel debugger forces people to think
about their problem on a different level than with a debugger. I think that
without a debugger, you don't get into that mindset where you know how it
behaves, and then you fix it from there. Without a debugger, you tend to think
about problems another way. You want to understand things on a different
_level_."_

This seems to be the most worthwhile part of the post. I've never gotten into
the habit of using debuggers myself, so I can't say how strong his argument
is.

~~~
Deestan
I also find that a debugger encourages a technique of just tracing through the
code until " _a-hah_ , _that's_ where fooBing get reset to dingy. I should add
a clause to reset it to dingy only if barBong is set."

Without a debugger, I would have to write tests, clean up the code until it
made sense, or design it in such a way that that particular kind of bug could
not occur.

~~~
antonovka
_I also find that a debugger encourages a technique of just tracing through
the code until "a-hah, that's where fooBing get reset to dingy. I should add a
clause to reset it to dingy only if barBong is set."_

Someone actually skilled in their craft would say:

"a-hah, that's where fooBing get reset to dingy. now I understand _what's_
happening, let's understand _why_ ".

Remember, this is kernel code we're talking about here. In user-space, I
rarely need to use a debugger because nearly all issues are caught during
initial development by unit and regression testing.

However, there are still times where something goes terribly wrong --
sometimes in vendor code (or in the case of the kernel, hardware) -- and I
wouldn't give up my debugger for the world.

~~~
Deestan
No disagreement that debuggers are helpful, but they allow unskilled people to
do more crap work without having to learn or think or improve, and _that_ is
what I believe Linus is going on about.

By all means, I don't _agree_ with him that debuggers should be forbidden, but
I believe I know where he's coming from.

~~~
trebor
Do you mean that, only masochistic programmers ought to survive? Or, didn't we
all start out as an unskilled programmer before we gained any skill?

~~~
Deestan
No.

