| |||||||||||||
Give Sun their due.Give Sun their due.Posted Nov 20, 2004 7:45 UTC (Sat) by hppnq (guest, #14462)In reply to: Give Sun their due. by brugolsky Parent article: Solaris 10 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.
(Log in to post comments)
source availablility has nothing to do with tracing Posted Nov 21, 2004 0:48 UTC (Sun) by cajal (subscriber, #4167) [Link] 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
#!/usr/bin/dtrace -s
This will give you a histogram of what processes are causing pageins. What processes are generating disk I/O?
#!/usr/sbin/dtrace -s
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 highly suggest this blog entry by Bryan Cantrill, one of DTrace's developers.
source availablility has nothing to do with tracing Posted Nov 22, 2004 21:14 UTC (Mon) by hppnq (guest, #14462) [Link] I was replying to the "Linux appears behind" remark of the top poster, not soliciting for a Solaris marketing speech. You apparently didn't quite understand what I meant, so I'll try to make it clearer.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.
source availablility has nothing to do with tracing Posted Nov 22, 2004 23:25 UTC (Mon) by cajal (subscriber, #4167) [Link] 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.
source availablility has nothing to do with tracing Posted Nov 23, 2004 0:41 UTC (Tue) by hppnq (guest, #14462) [Link] 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.
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.
|
|||||||||||||