Awesome talk, though the SystemTap coverage was oddly weak.
Saying 'SystemTap was was created when there weren't Solaris for Linux ports' is a little disingenuous. Linux had live kernel instrumentation with kprobes way before Sun debuted DTrace, and DTrace was deliberately licensed in a way to be incompatible with the Linux kernel.
DTrace was deliberately licensed in a way to be incompatible with the Linux kernel.
This was commented on directly by Bryan Cantrill on HN [1]. You should also watch his "Fork Yeah!" [2] and "Corporate Open Source Anti-Patterns" [3] talks for full context.
I want to point out a comment [1] apparently by the former chief open source evangelist, Danese Cooper [2], on the "Fork Yeah!" video contradicting Bryan Cantrill on this point. Here it is reproduced:
Lovely except it really was decided to explicitly make OpenSolaris incompatible with GPL. That was one of the design points of the CDDL. I was in that room, Bryan and you were not, but I know its fun to re-write history to suit your current politics. I pleaded with Sun to use a BSD family license or the GPL itself and they would consider neither because that would have allowed D-Trace to end up in Linux. You can claim otherwise all you want...this was the truth in 2005
I fully trust in Danese's description of the events in this case.
Not only because she (Danese) was the person who actually created the licence (and thus is the best authority on the prerequisites set by the Sun management), but also because it makes perfect sense.
Sun, a company whose Solaris product was suffering greatly under competition from Linux, would NOT want to offer up their systems technical advantages under a open source licence which would allow Linux to use said technical advantages. It seems purely logical to me.
Listening further to Danese, she describes the Sun management as wanting a copyleft style licence for the code, and that they were eyeing GPLv3, but not GPLv2 which was already available (again, GPLv3 code would not be compatible with the Linux kernel, while GPLv2 obviously would), however GPLv3 was taking to long to be finalized so they set her (Danese) on the task of creating a new licence.
I've recently been using DTrace on Ubuntu. I filed two bugs on the project page (https://github.com/dtrace4linux/linux), and Paul Fox fixed them quickly. I have more bugs to file, but I'm doing my part in making DTrace on Linux a reality.
It's very tempting to join these licensing discussions (I was at Sun, too, and many of us DID want to see DTrace on Linux), but I think that's a distraction from what's happening right now.
There are two projects porting DTrace to Linux, which is really exciting. I'm helping out.
> Lovely except it really was decided to explicitly make OpenSolaris incompatible with GPL.
In fairness to both sides, pretty much everything that isn't GPL can be said to be incompatible with GPL, and almost anyone who decides to use something different than the GPL can be said to be deliberately incompatible with the GPL. That's just the nature of the GPL.
Permissive open-source licenses (MIT, BSD, etc.) are GPL-compatible. But I think the question here is more one of motivation: was a decision made for reason X which had the side-effect of making DTrace's license incompatible with Linux, or was the choice of license made specifically to cause that effect? There appear to be conflicting accounts from people who were at Sun at the time.
> Permissive open-source licenses (MIT, BSD, etc.) are GPL-compatible.
I guess I have a problem characterizing them that way since the traffic is going to be purely one-way. The GPL code can't be used by the projects with more permissive licenses without some kind of dual licensing, can it?
Danese is wrong. Ask the other people involved; they don't agree with her.
Almost any copyleft license that Sun could have chosen at the time would have been incompatible with the GPL; and multi-licensing wasn't seen as a viable option.
It's all a moot point now anyway, but I wish some individuals would stop acting like Danese is the sole truthful source on this just because it fits their armchair conspiracy theories.
Danese actually _wrote the licence_ as per the requirements set to her by the Sun management. She is as such the foremost authority on this of those who has publically spoken on the subject.
Who are these 'other people involved'? Involved in what? Unless they were involved in the licence creation what do they really know?
She (Danese) is not 'wrong', she is either outright lying (to what end?) or telling the truth. Again she, as the person who actually wrote the licence obviously knows the truth.
And how is it an 'armchair conspiracy theory' that the Sun management did not want to allow Linux (their main competitor who was also eating their lunch in the marketplace) to use the technology they (Sun) was open sourcing?
From a business standpoint it makes perfect sense, and thus is entirely plausible.
That doesn't mean that there weren't Sun developers who had no interest in denying Linux use of Solaris 'tech, but they were not calling the shots, Sun management was. And again from a management perspective it makes no sense to give away your advantages to your main competitor.
Danese is not actually the foremost authority on this, and she did not really "write the license". The license is based on the MPL (Mozilla Public License), and was written by Sun's legal staff in consultation with management and others inside of Sun at the time.
I know it would be wonderful to just wrap the licensing conspiracy theories up in a pretty bow because it fits your logical conclusions, but it isn't that simple.
I'm not saying that Danese is lying, just that she is wrong. There is a difference. Danese may have believed that it was done for the reasons she claims, but that doesn't make it so just because it's convenient to believe it.
There are far more people that have said that Danese is wrong that are qualified to do so; with that, I feel safe in saying she is wrong (nevermind my own involvement).
I recently dove into this area in an attempt to find something like strace that didn't cost as much (as the slides mention, it's hundreds of times slower to run something under strace). It seems like dtrace can likely do what I want, but it doesn't sound reliable under linux yet. Does anyone know if the native linux profiling tools can be used to answer questions like "which files is my process accessing"?
As far as I found, various tools can trace syscalls and count them, but the critical thing strace adds is that it decodes the pointer parameters to syscalls into strings, something that e.g. "perf trace" doesn't seem to do.
You could link your library to a passthrough libc that logs calls, if it is dynamically linked. There are various library hijacking solutions to make it easier. ptrace, that strace uses is necessarily slow (ktrace in eg NetBSD is much faster, the kernel does the tracing not userspace).
Correct me if I'm wrong here, but I believe lsof can only display files held open at a given point in time (when you run lsof), no? So if a process opens a file, does something with it, and then immediately closes it, you're unlikely to be able to catch that with lsof unless you happen to run it at exactly the right time.
Saying 'SystemTap was was created when there weren't Solaris for Linux ports' is a little disingenuous. Linux had live kernel instrumentation with kprobes way before Sun debuted DTrace, and DTrace was deliberately licensed in a way to be incompatible with the Linux kernel.
If you want to see some actual useful production taps you can use right now on your Red Hat / CentOS box, check out http://sourceware.org/systemtap/wiki/WarStories