Linus Torvalds: Debugging hell
torvalds-family.blogspot.com
torvalds-family.blogspot.com
What's so newsworthy about Linus being frustrated about debugging?
Still, I can't help suspecting that many voters wouldn't care if some John Doe had written this story.
This happens all the time with commercial products.
Commodity hardware debug sucks more.
When working at this level, access to hardware probes and external monitoring and manufacturing taps can be invaluable.
Boundary and edge conditions and timing races and part steppings and errata rule. For those cases where the errata was written down, or where the vendor deigned to describe what changed between the steppings.
There are a number of device-level drivers and operating systems in use where only a very few folks really know the code sufficient to debug this level, too.
Because for a long time, apple only had one architecture to worry about.
Because linux has only gotten "big enough to pay attention to" in the last few years.
Here is another of his rants against debuggers. Just substitute 'kernel debugger' by 'simple chipset debugging facilities' (whatever that means) in that email and basically he has his response for why Intel isn't adding it. http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.h...
Intel engineers are saying, 'simple chipset debugging facilities' are for sissies!
This is his logic, not mine.
It seems like a simple transitive relation to me; are you saying his logic neglects transitivity?
To elaborate: Yes, I've actually written an os, yes, bad hardware was my 'standard' in those days (a simple lack of money), imagine a pc built out of parts bolted to an old print-file trolley, more flakey than I care to remember.
A kernel panic in a microkernel presumes a memory or a cpu error, anything else the kernel simply does not deal with so that would lead to driver process issues, not kernel panics.
A faulty memory controller or cpu would lead to a kernel panic because of (apparent) datastructure inconsistencies.
One of the hardest drivers to write (even in a microkernel environment) was an X.25 board that a friend of mine had designed around some comm chip, for one the X.25 spec is pretty convoluted and there were a lot of layers of the protocol to be implemented in a single driver. That thing was an absolute nightmare to debug, other than that most drivers (harddisk controller, network cards, graphic boards) were a walk in the park compared to doing the same under a macro kernel.
Simply telnet in to the machine, start up the vga driver process and run it (under the debugger) until you manage to crash it. Most of the times a simple 'where' and close inspection of the source would be enough to solve the problem, recompile and run for the next iteration. No kernel panics.
Also, it is funny that people who succeed in the first place due to what you call as ego, are expected to magically lose it and become "nice" once they are above a certain level of success.
[edit: +1. Downvote is not from me.]