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 202793
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[9]: oh no
by jamesd on Wed 17th Jan 2007 17:33 UTC 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

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

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.

No. But I can't imagine ever wanting to do that either. I've not yet run up against the limitations of SystemTap, although I'm sure they exist.

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.

Agreed, having access to the debugging data is part of the core design. Note that ISV don't have to include the source to include the debugging information. This just doesn't seem like an issue that will cause any practical problems.

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.

Granted. Let's revisit in a year or two and see if SystemTap has produced similar success stories.

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.

Nice visual ;o)

Reply Parent Score: 2