Linked by Thom Holwerda on Wed 17th Jan 2007 00:19 UTC
Sun Solaris, OpenSolaris Sun Microsystems is set to license OpenSolaris under the upcoming GNU GPLv3 in addition to the existing Common Development and Distribution License, sources close to the company have told eWEEK. "The next version of Solaris will include things like GNU Userland, which is already being attempted with OpenSolaris, while open-source solutions from other communities for things like package management also look very promising. Dual-licensing OpenSolaris with GPLv3 could make this even easier," said a source who declined to be named.
Thread beginning with comment 202783
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: oh no
by jamesd on Wed 17th Jan 2007 17:05 UTC in reply to "RE[6]: oh no"
jamesd
Member since:
2006-01-17

They are saying that the target audience of Dtrace is not Developpers (!), that you can not use Dtrace for debugging (!).

sorry, to burst your bubble, Dtrace is very good at debugging as documented at http://uadmin.blogspot.com/2006/05/what-is-dtrace.html

Here is a small list of apps that have been debugged with DTrace, Network streams, Zones scaling problem,
Application Tuning, Gnome Load times, AutoMounter restarting, Finding Memory Leaks, NTP, Java Applet,
Libst, Timer, Mozilla, StarOffice, Zone monitoring,
Andrew Tridgell's lock scaling problem, BONOBO, setlocale, links to the explanations of the related bugs are in the above link, note that DTrace has bugged userland applications that has helped Solaris and Linux as well.

I agree with you that the omission of debugging is a bit odd for the DTrace column. However, they don't go so far as to say you _can not_ use DTrace for debugging, just listing the main usage. I don't know enough about DTrace to say whether or not that's a fair statement.

DTrace is an excellent tool, not only is it useful for the developer, the user can figure out details without knowing the code in question, and it doesn't even require that the code be compiled with debugging enabled. For example if a user wants to know which code path kdeinit is spending all its time here is a simple script that can be modified for any userland app and I bet the average user can figure out how to modify it.

tick-1234hz /* fire a probe 1234 times a second */
/execname=='kdeinit'/
{ @[ustack()]= count(); } /* store a copy of userstack trace */

Based on my limited exposure to Dtrace, I think it "only" comes with a fixed number of probes (~31,000). Whereas, SystemTap uses kprobes to allow dynamic probes to be inserted anywhere (with a few restrictions) on the fly.

I love how Systemtap fans love to bring this up, but never never seem to mention that no one has managed to consistently create a script that works with more than a few 100 probes. A simple task like probing each kernel function 99 out of 100 times ends up with the system crashing. Systemtap fans also love pointing out that they can probe any point in the kernel, but what kind of programmer can't figure out what is happening in a function if he knows what function was called with what values, and what functions are being called and a complete userland and kernel stack trace?

Now lets show the DTrace facts, DTrace comes with over 48,000 probes in the kernel alone.

enterprise:~# dtrace -l | wc -l
48790
enterprise:~#

but wait DTrace has userland probes as well what happens when we probe every function in say mozilla?

enterprise:~# dtrace -s max.d -c /usr/sfw/bin/mozilla | head
dtrace: script 'max.d' matched 531966 probes


Now lets go over the facts again, systemtap may be able to probe every line in the kernel in theory, but why does anyone need to do that? Of course when you actually try to probe even every function in the kernel (about 35,000 probes) its a recipe for crashing the system. There is no userland probes in systemtap, there isn't even a userland stack trace function that works. DTrace on the other hand can activate concurrently 48,000 probe points in the kernel, and another 530,000 in userland and not crash the system, which one is more useful? By the way DTrace has had the ability to do this for over 2 years now so was more stable and useful even when it was at the same age in development as systemtap is now.

Reply Parent Score: 4

RE[8]: oh no
by tux68 on Wed 17th Jan 2007 17:14 in reply to "RE[7]: oh no"
tux68 Member since:
2006-10-24

sorry, to burst your bubble, Dtrace is very good at debugging as documented at...

I did not write the section you quoted.

I love how Systemtap fans love to bring this up, but never never seem to mention that no one has managed to consistently create a script that works with more than a few 100 probes. A simple task like probing each kernel function 99 out of 100 times ends up with the system crashing. Systemtap fans also love pointing out that they can probe any point in the kernel, but what kind of programmer can't figure out what is happening in a function if he knows what function was called with what values, and what functions are being called and a complete userland and kernel stack trace?

I am not a systemtap "fan", just a new user and happy it worked for me. Guess we must have been very lucky to be that 1 in 100 that didn't have a system crash; or maybe the odds aren't that bad.

I'm sure Dtrace is great but SystemTap is already a useful tool which is sure to improve even more.

Cheers.

Reply Parent Score: 2

RE[9]: oh no
by jamesd on Wed 17th Jan 2007 17:33 in reply to "RE[8]: oh no"
jamesd Member since:
2006-01-17

I'm combining my comments to numerous of your posts into one.

I am not a systemtap "fan", just a new user and happy it worked for me. Guess we must have been very lucky to be that 1 in 100 that didn't have a system crash; or maybe the odds aren't that bad.

did you try and probe every function in the kernel? I bet you didn't... go ahead and give it a try on a customers machine.... and watch it generate a nice oops report as it crashes.

For instance, where DTrace would limit those developers to the ~47k probe points, SystemTap puts no such limitation on the developer. Plus it works very closely with the debug info produced by the compiler; just like a source level debugger works.

Two problems here, number one systemtap can't enable more than a few hundred probes at a time. Systemtap is so intergrated with the debugging information that it is almost completely useless without it. Systemtap can't even get data out of a struct or class without debugging information. Want to use systemtap on a application that an ISV created but isn't including the source? too bad, systemtap can't help even when they do get userland probes they still require debugging information.

DTrace wasn't meant to replace source level debuggers that developers typically use. It was meant for a totally different situation where source level debuggers couldn't be employed.

DTrace can replace normal debuggers, because it has all the same functionality in userland, it can probe any line of a userland application, it can stop the program which is what the programmer is usually ends up doing when he finds the problem because he needs to go and fix the bug.

This seems a bit overly dramatic...

The amount of bugs that dtrace has found and helped fix is dramatic, Systemtap is limited to tracing kernel functions and syscalls... and there is no list of userland bugs that systemtap has fixed.

I think I can best sum up systemtap is a hammer, too bad there are a very limited number of nails for it, but a hell of a lot of broken windows and walls left in its wake.

Reply Parent Score: 4