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.
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.
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.
"I believe the Spartans weren't known as nice and understanding bunch."
Actually, I think it was the opposite in terms of their general personalities. They were renown and respected for doing the "right thing" no matter what the personal cost may be. There's a story to that effect, which might be only a legend, but it goes like this:
"An old man wandering around the Olympic Games looking for a seat was jeered at by the crowd until he reached the seats of the Spartans, whereupon every Spartan younger than him, and some that were older, stood up and offered him their seat. The crowd applauded and the old man turned to them with a sigh, saying "All Greeks know what is right, but only the Spartans do it." (http://www.pbs.org/empires/thegreeks/background/8c.html)
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.
That's just misplaced arrogance, backed by confirmation bias. Truly gifted individuals are smart enough to use the best tool to solve the problem at hand as efficiently as possible. That tool is sometimes a debugger.
Here's a quick survey:
FreeBSD: Kernel Debugger.
Solaris: Kernel Debugger.
NetBSD: Kernel Debugger.
OpenBSD: Kernel Debugger.
IRIX: Kernel Debugger.
Darwin: Kernel Debugger.
Linux: Nope.
Now of all those operating systems, would you really say that the developers that added a debugger for their own use are not the gifted and 'elite'?
Sadly, the company I work for is full of weak, ordinary people :).
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.
You had me until you compared yourself to the Spartans, a people who were strong because they let their weaker babies die. http://en.wikipedia.org/wiki/Infanticide
There's a moral line between "it's not my job to help you succeed" and "it's not my job to help you live".
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.
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.
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.
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.
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?"
"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.
Sometimes a debugger is simply the fastest route to isolating and solving an issue.
I recently had to track down a kernel issue caused by an piece of code unrelated to my current work casting a signed value to unsigned and eventually triggering a kernel panic. Thanks to remote kernel debugging, I could simply step through the code path and track the changes. If I accidentally overstepped the failure point, I just reset the virtual machine back to the snapshot point and reattached the debugger.
Did this mean that I didn't know how the code behaved? No -- I had to understand the code, but there was very little chance that I would quickly eyeball a single incorrect cast in a comparison 6 degrees of separation from where my own code was being run without being able to trace the issue a couple times in a debugger as it happened.
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.
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.
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.
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.