source availablility has nothing to do with tracing [LWN.net]

source availablility has nothing to do with tracing

Posted Nov 22, 2004 23:25 UTC (Mon) by cajal (subscriber, #4167)
In reply to: source availablility has nothing to do with tracing by hppnq
Parent article: Solaris 10

I fail to see how two technical examples constitute a "marketing speech," and I think it's funny that you try to claim that I'm to blame since your entire post was two sentences.

I never claimed that tracing toolkits were the be-all and end-all of debugging. They're a very useful tool for a lot of things, but for other things a debugger is more appropriate. I don't think that Sun (or anyone else) is claiming that DTrace is the *only* tool you need for all computer problems. They are making a big deal about it, but their enthusiasm is justifiable - DTrace is an incredible tool, and they've spent years developing it.

I'm not sure what to make of your claim that "inspection of code is both the ultimate and probably the most common thing to do in the Open Source world." If you actually read my reply, instead of merely dismissing it as "marketing," you'd see that no amount of source code inspection would give you that answer. You dismiss DTrace as "nothing out of the ordinary" -- I diagree strongly. Have you read the Usenix paper on DTrace's design? Do you realize that it's dynamically inserting probe points into a live kernel, and doing so safely? It's data analysis tools are very powerful and easy to use. If you can write a shell or Perl script, you can use DTrace. It's a big step forward for sysadmins, developers and systems programmers. AIX trace is certainly useful, but very different from DTrace. AIX trace activates several static tracing primitives and generates huge output files. DTrace only actives the probes the user specifies and can filter data at the source, greatly reducing the need for post-processing. See this entry on Sun Forums where there some good back-and-forth about AIX trace -vs- DTrace. The Dynamic Tracing Guide is also very useful - it has lots of good examples of how to use DTrace.

(Log in to post comments)

source availablility has nothing to do with tracing

Posted Nov 23, 2004 3:08 UTC (Tue) by cajal (subscriber, #4167) [Link]

"I must say I hesitated for quite a while before adding my previous comment, since it seems like everytime I say something about Sun here you seem to develop an urge to drown me in Ten Interesting Things To Do With DTrace Or Whatever"

Rubbish. In this thread, you've been insuinating that open-source projects don't need tracing toolkits so much because developers can inspect the code:

"...that inspection of code is both the ultimate and probably the most common thing to do in the Open Source world."

What I'm trying to get across is that tracing toolkits in general, and DTrace in particular, are useful for things beyond debugging code. They've also useful to sysadmins trying to track down performance problems, which is why I listed the examples I did.

And, for the record, I included the source specifically to keep it technical and not a marketing speech.

source availablility has nothing to do with tracing

Posted Nov 23, 2004 4:03 UTC (Tue) by hppnq (guest, #14462) [Link]

Sigh.

Not only does it make little sense to accuse me of insinuating something with an almost literal quote of my own words, it really takes the edge off of your razor sharp logic.

*plonk*

source availablility has nothing to do with tracing

Posted Nov 23, 2004 4:10 UTC (Tue) by cajal (subscriber, #4167) [Link]

Do you actually read my replies, or just post attacks? Do you actually have anything to contribute to this thread, or do you just have to have the last word?

source availablility has nothing to do with tracing

Posted Nov 25, 2004 1:44 UTC (Thu) by roelofs (guest, #2599) [Link]

As a disinterested third party with no ties to either combatant (nor to Sun), I have to side with cajal here. His initial comment was to the point and technical: he provided two explicit examples of how a sysadmin could use DTrace to trivially discover two types of manifestly useful information. hppnq, on the other hand, characterized those examples as mere "marketing speech" (or "marketing mumbo jumbo") and claimed that they're "trivial to do using other tools" yet somehow failed to provide a single example of those other tools.

And speaking as a former sysadmin with some very minor kernel-hacking experience, I think I can safely say that inspection of code is not "the most common thing to do" for that category of user. Not only is knowledge of kernel internals fairly rare among sysadmins (at least in my experience, which I think is pretty typical), I've never yet met one who wasn't swamped with work. Five-line script vs. unknown hours poring over kernel source...hmmm. Tough call.

Anyway, consider this a gentle plea to get back to useful technical interchange rather than continued personal attacks. And thank you, cajal, for a pair of instructive examples that conveyed far more relevant info than any marketing spiel I've ever seen. (Not that I go out of my way to see a lot of marketing spiels...)

Greg

source availablility has nothing to do with tracing

Posted Nov 25, 2004 8:05 UTC (Thu) by hppnq (guest, #14462) [Link]

Greg, what I originally meant to say is very, very simple. On a proprietary system you have to resort to trace toolkits or debuggers to be able to look inside your software. With Open Source you don't. That would help explain why Linux does not have a trace toolkit.

tracing does not (necessarily) have anything to do with source availablility

Posted Nov 25, 2004 16:44 UTC (Thu) by josephrjustice (subscriber, #26250) [Link]

It's true that, on a proprietary ^H^H...^H closed source system (unless one is among the blessed elite), a person needs to resort to trace toolkits, debuggers, etc to be able to look inside the guts of software.

It's also true that, on an Open Source / Free(Libre) Software system, one does not _need_ to resort to trace toolkits, debuggers, etc. After all, it is (in theory) possible to look at the source code, in combination with FULL and COMPLETE knowledge of all information leading to the current state of a running process (which, note, depending on the issue being investigated could include needing to have knowledge of the exact runtime history of this process and other processes on the system, information about the layout of files on disk, knowledge of the specifications of the hardware, knowing about any compiler bugs, knowing about any hardware bugs (e.g. divergences from the hardware specification), knowledge of the phase of the moon (e.g. did a random cosmic ray cause a bit to flip in memory causing a run-time error), etc), and be able to deduce exactly how the problematic process got to be the way it is. You know, the old "Let the human pretend sie is a Von Neumann machine" thing.

However, just because this is _possible_ for open source systems does not mean it is _practical_, or that this is always what people _should_ do even if other options are available to them.

I don't use Solaris (other than as a person with a Unix shell account with an ISP that uses Solaris on its shell systems). I'm certainly not an avowed Sun Microsystems booster (tho, neither am I a dedicated detractor of them either). However, it does seem from this particular conversational thread, and other pages linked to from it, that there are, apparently, some _potential_ advantages and uses of this DTrace tool which you are overlooking or dismissing, and which at least some people might find of value if similar functionality (either DTrace itself or a work-alike) was available for Linux. This, despite the fact that source is available for Linux.

And, I think you'd have to agree this (some people finding DTrace, etc to be potentially valuable) is true even if such functionality is not, in principle, absolutely _necessary_ for Open Source / Free(Libre) Software systems.

Joseph, still does all _his_ arithmetic using Peano Numbers, because integers are unnecessary

tracing does not (necessarily) have anything to do with source availablility

Posted Nov 26, 2004 6:09 UTC (Fri) by hppnq (guest, #14462) [Link]

Precisely! This, of course, is what I have been trying to say all along. ;-) Thanks Joseph.

tracing does not (necessarily) have anything to do with source availablility

Posted Nov 29, 2004 5:07 UTC (Mon) by Negation (guest, #26304) [Link]

Since all the participants are much too nice, let me say, "Sir, you are an idiot."

source availablility has nothing to do with tracing

Posted Jan 20, 2005 17:40 UTC (Thu) by htd (guest, #27388) [Link]

Your answer neatly illuminates one of the biggest issues that Linux suffers from.

Developer vs deployer/manager.

If you are a developer then having access to the source code may well be a way of sidestepping the need for sophisticated trace/debug facilites (may well because kernel engineering isn't every developers cup of tea).

However if you are a deployer/manager of these systems then having access to source isn't remotely the answer, you probably have neither the skills not the time or inclination (how many corporations have a VP of kernel engineering).

If Linux is to suceed then the people who deploy and manage Linux based systems need to be in the majority and the OS needs to address their issues and not simply what developers want or can get away with.