| |||||||||||||
source availablility has nothing to do with tracingsource availablility has nothing to do with tracingPosted Nov 23, 2004 0:41 UTC (Tue) by hppnq (guest, #14462)In reply to: source availablility has nothing to do with tracing by cajal Parent article: Solaris 10
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.
(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.
|
|||||||||||||