Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
The thing is, with Open Source you don't need trace toolkits as much as with proprietary systems. Lacking support in the Linux world often means: no one asked for it.
source availablility has nothing to do with tracing
Posted Nov 21, 2004 0:48 UTC (Sun) by cajal (subscriber, #4167)
That's just silly. DTrace (and tracing toolkits in general) having nothing to do with source
availablity. They're used to debug and profile individual applications and even entire systems.
Consider these two questions which a sysadmin might be asked in a typical day:
* What processes are causing so much swapping?
* What processes are generating disk I/O?
Without tracing toolkits, these questions can be difficult, if not impossible to answer. With
DTrace, each takes a 5-line script:
What processes are causing so much swapping
@[pid, execname] = count();
This will give you a histogram of what processes are causing pageins.
What processes are generating disk I/O?
@[execname, uid] = sum(args->b_bcount);
That'll give you a histogram of disk I/O broken down by process name and uid.
Even if you had all the source to the OS, you couldn't answer these questions without an
appropriate tool. DTrace is one such tool. It can, of course, do a lot more. For a nice overview, I
this blog entry by Bryan Cantrill, one of DTrace's developers.
Posted Nov 22, 2004 21:14 UTC (Mon) by hppnq (guest, #14462)
Of course source code inspection and the use of trace toolkits are not equivalent. At best they complement each other (see for instance the collaboration between Ingo Molnar and the people testing his -RT patches), but there are also classes of real world problems in which either one will prove to be completely useless. Trace toolkits do tend to look more like a hammer than a couple of C files, so some problems might develop an uncanny resemblance to a nail if you're not careful -- well, that's my opinion, YMMV.
The fact that the Linux kernel does not have the tracing capabilities that DTrace offers is attributable to a number of factors; one of them is undoubtedly the fact that inspection of code is both the ultimate and probably the most common thing to do in the Open Source world.
As for the marketing mumbo jumbo: from what I've seen, DTrace looks quite okay but nothing out of the ordinary. All examples of its use I have seen so far are trivial to do using other tools, but I imagine much more elaborated tracing a la AIX's trace facility is possible, so more power to you.
Posted Nov 22, 2004 23:25 UTC (Mon) by cajal (subscriber, #4167)
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'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.
Posted Nov 23, 2004 0:41 UTC (Tue) by hppnq (guest, #14462)
I never claimed that tracing toolkits were the be-all and end-all of debugging.
And I never said you did.
I've had this kind of discussion with you before and 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. And your continuous misinterpretation of my comments is not believable anymore.
This could have been a normal, technical discussion but you'll hopefully forgive me for not wanting to continue it.
Posted Nov 23, 2004 3:08 UTC (Tue) by cajal (subscriber, #4167)
"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
Posted Nov 23, 2004 4:03 UTC (Tue) by hppnq (guest, #14462)
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.
Posted Nov 23, 2004 4:10 UTC (Tue) by cajal (subscriber, #4167)
Posted Nov 25, 2004 1:44 UTC (Thu) by roelofs (guest, #2599)
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...)
Posted Nov 25, 2004 8:05 UTC (Thu) by hppnq (guest, #14462)
tracing does not (necessarily) have anything to do with source availablility
Posted Nov 25, 2004 16:44 UTC (Thu) by josephrjustice (subscriber, #26250)
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
Posted Nov 26, 2004 6:09 UTC (Fri) by hppnq (guest, #14462)
Posted Nov 29, 2004 5:07 UTC (Mon) by Negation (guest, #26304)
Posted Jan 20, 2005 17:40 UTC (Thu) by htd (guest, #27388)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds