Date: Wed, 17 May 2000 18:35:54 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rsidd@physics.iisc.ernet.in (Rahul Siddharthan) Cc: mellon@pobox.com (Anatoly Vorobey), chat@FreeBSD.ORG Subject: Re: Salon article on BSD Message-ID: <200005171835.LAA07917@usr05.primenet.com> In-Reply-To: <20000516115825.B19647@physics.iisc.ernet.in> from "Rahul Siddharthan" at May 16, 2000 11:58:25 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> He also doesn't like kernel debuggers, on the grounds that they make > you try to cure the symptom rather than the problem. He prefers > that people stare at the code until they see what's wrong with it. Kernel debuggers have two nasty attributes: 1) Linking the debugger into the kernel adds another variable, which can preterb the problem space, and thus result in the bug you are trying to examine being masked. This is a general problem with using the object of your attention as the container for the means by which you focus your attention. For example, VMS tended to mask many bugs, including NULL pointer dereferences, when programs were run in the debugger. 2) Kernel debuggers are like the VMS debugger or the majority of debuggers on non-protected mode OS platforms (well, unless you use vmware, like Julian does, in order to externalized the debugger 8-)). The problem with this approach, compared to using a dump image and doing a post moretm, is that you have to keep one step behind in your head. Then you fail catastrophically, and you have to _repeat_ the debug session to the point where you are once again about to imminently reproduce the problem, in order to fix it. There is much less advantage to staring at code... unless you have someone you think is a complete moron do it over your shoulder. In this special case, they will point to the problem with a rapidity inversly proportional to your opinion of their intelligence. 8-). Better formal methods exist, including "not writing bugs into the code in the first place because you have done the design and have verified that the code actually implements the design". > Well, whatever suits him -- and linux has improved phenomenally in the > last 3 years, ie since its 1.2 days, so he must be doing something > right. One can't say what *would* have happened if he'd done things > differently. If he had adopted a constraining tool like CVS, Linux would have forked on no less than 3 (mathematically) documentable occasions. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005171835.LAA07917>