Weekly Edition
Return to the Development page
| |||||||||||||
Oracle works on Dtrace for Linux (The H)
The H reports on Oracle's plans to bring DTrace to (Oracle) Linux. "There is no word on what the Linux port of 'Dynamic Tracing Facility' (also known as Dtrace) will look like, but it is considered a major function in newer versions of Solaris. A blog post by Dtrace co-inventor Adam Leventhal indicates that few details are known, though he does say that it will be interesting to see how Oracle clears up licensing issues."
(Log in to post comments)
Oracle works on Dtrace for Linux (The H) Posted Oct 6, 2011 20:11 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] Oracle owns the code, so they are free to relicense their port however they want. On the other hand, they are fiercely competitive and will probably try to find some way of maintaining an advantage over the competition (e.g. Red Hat).
Oracle works on Dtrace for Linux (The H) Posted Oct 6, 2011 20:18 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
it will be very interesting to see what they end up doing. I would not be surprised to see them try something wrong with the licensing here trying to maintain some 'advantage' and then get sued over it.
although, all they really need to do to keep their 'advantage' is to do such a horrible hack job with the 'port' that the result is not acceptable upstream.
Oracle works on Dtrace for Linux (The H) Posted Oct 6, 2011 21:14 UTC (Thu) by drag (subscriber, #31333) [Link]
The only shenanigans they could play that I could see would be to:
1. Take advantage of lack of patent protections in the Linux kernel and keep the patent licensing separate from the copyright licensing.
2. Take advantage of the fact that copyright controls can only be extended to derived works. If they figure out a way to use dtrace in the Linux kernel in a way that leaves it relatively unmodified then there is no effective way that it can be claimed as derived works and thus would be legal to keep licensed under the CDDL. It's something that was written for a different OS entirely and ported to several others, so only the linux-specific parts of dtrace would have to be licensed under the GPLv2.
This is similar to how Nvidia takes their Windows driver and shoves it into the Linux kernel with their 'GPL shim'.
---------
But I don't know why people are so eager to assume that Oracle will pull crap like this. They have released many software patches and such as GPLv2. They are responsible for Btrfs and a lot of other work that was done to enhance the Linux kernel. As far as I can tell Oracle has shown no other signs or desire that they wish to make the Linux they ship be 'proprietary' in any substantial way.
I think most of this line of thinking stems from the common belief that Oracle sees Solaris as a potential competitor to Linux. I don't think that is Oracle's desire at all... I don't think they give a flying-f for Solaris or Sun hardware besides being a legacy OS and system that gets relatively minor updates time to time to keep the big players with solaris-specific applications happily puking huge gobs money at their feet. They Oracle may talk up a good game about Solaris, but I think that is just because big enterprise people tend to be nervous ninnies and need the reassurance that Oracle isn't planning to pull the rug out from underneath them.
Java was their primary concern as far as Sun acquisition goes. I think that Solaris was almost incidental. I don't think they care a whole lot one way or another as long as their is at least one very popular platform available to run their application stack that isn't owned by Microsoft.
We will see if what I say is true based on how Oracle decides to license it. If I am right then they will probably have the Linux-kernel portions be dual licensed and the userland parts may or may not stay under a CDDL-only... which is just fine because CDDL is a friendly free-software license.
Oracle works on Dtrace for Linux (The H) Posted Oct 6, 2011 21:26 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
Oracle's track record since they acquired Sun has not been good. They have killed or alienated many different communities. In fact I can't think of any actions they have taken since that point that would be considered positive (aside from the quiet continuation of pre-existing initiatives)
Oracle works on Dtrace for Linux (The H) Posted Oct 7, 2011 14:13 UTC (Fri) by liljencrantz (subscriber, #28458) [Link]
Oracle is completely indifferent to nurturing a healthy Eco-system of open source projects unrelated to their core strategy. Their behavior towards OpenOffice, Hudson and a long list of other projects is just that: indifference.
The Linux kernel they care about. They want it to flourish, because they _know_ they can't compete with Microsoft alone; if _they_can't be the OS monopolist, the second best option is that nobody is the OS monopolist. That's why they're being good citizens and fixing loads of kernel bugs and working on shiny new features like btrfs within the kernel community. No periodical code drops like some other companies I could mention.
That's why my best guess would be that if something comes of this, the entire kernel space solution will be GPLv2, possibly even the user space component.
Oracle works on Dtrace for Linux (The H) Posted Oct 6, 2011 21:29 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I didn't mean to imply that they would have a _legal_ basis for their 'competitive advantage', merely that I would not be surprised if they tried to maintain one.
Oracle works on Dtrace for Linux (The H) Posted Oct 6, 2011 23:25 UTC (Thu) by cmccabe (guest, #60281) [Link]
> 1. Take advantage of lack of patent protections in the Linux
> kernel and keep the patent licensing separate from the > copyright licensing.
GPLv2 does provide an implicit patent license:
http://en.swpat.org/wiki/GPLv2_and_patents
> 2. Take advantage of the fact that copyright controls can only be extended
I think this is exactly what they'll do. Set up a GPLv2 shim layer, and leave the core code as CDDL.
Of course, it will never be upstreamed, and will need constant maintenance to stay in sync with the rest of the kernel. However, Oracle has the money and the engineers to keep it going.
Hopefully this will motivate people to finally improve and unify the upstream Linux tracing situation...
Oracle works on Dtrace for Linux (The H) Posted Oct 7, 2011 13:00 UTC (Fri) by simlo (subscriber, #10866) [Link]
This is my interpretation of GPLv2:
Linux with DTrace kernel modules will be one program and must as a whole be under GPLv2. Linux+DTrace is a derived work of Linux.
You can distribute Linux with some DTrace stubs as GPLv2. Then DTrace under another license can be distributed as that is clearly not a derived work of Linux - the same way NVidia distributes their grapics driver.
Oracle works on Dtrace for Linux (The H) Posted Oct 6, 2011 20:59 UTC (Thu) by fw (subscriber, #26023) [Link]
We don't really know if they have the rights for a Linux port. Sometimes, big company make odd mistakes, like Ebay buying Skype the company, but not all Skype-related technology.
Oracle works on Dtrace for Linux (The H) Posted Oct 6, 2011 22:28 UTC (Thu) by Wol (guest, #4433) [Link]
No. Sun appears to have owned dtrace, and if they do then Oracle now own it.
The interesting thing, as I see it, is the blog implies that dtrace is going to be released as CDDL. Seeing as that's incompatible with GPL, it means that Oracle will either be unable to distribute, or will be forced to distribute the source on the same medium as the binary (due to a quirk/bug in GPLv2, they will NOT REPEAT NOT be able to distribute compiled kernels electronically eg on the web).
Or force all customers who want to use it to compile their own kernels.
We'll see.
Cheers,
Oracle works on Dtrace for Linux (The H) Posted Oct 6, 2011 22:40 UTC (Thu) by sciurus (subscriber, #58832) [Link]
From the blog post: "some small kernel components and header files will be dual-licensed while the bulk of DTrace the kernel modules, libraries, and commands will use the CDDL"
It sounds like they're trying to release just enough under the GPL to get away with distribution.
But Posted Oct 7, 2011 8:50 UTC (Fri) by robert_s (subscriber, #42402) [Link]
Just what does dtrace do that SystemTap can't (yet) do?
But Posted Oct 7, 2011 10:02 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
Very importantly, it has traction, particularly with Oracle's big audience of administrators and system programmers from a proprietary Unix background. Even if SystemTap does absolutely everything DTrace does, you know DTrace already.
This isn't a _huge_ audience, but it is one that's comfortable paying Oracle money. Making sure these people have a reason to ask specifically for Oracle's Linux, not Red Hat, will pay for itself. Previously DTrace was a reason for Solaris administrators to resist going Linux at all, but Oracle doesn't care about that, so it wants DTrace on Linux.
The license doesn't actually matter so much. If you know you want DTrace, that's a reason to choose Oracle, because the DTrace experts work for Oracle.
But Posted Oct 7, 2011 20:36 UTC (Fri) by bcantrill (guest, #31087) [Link]
A point of clarification: the DTrace experts do not, in fact, work for Oracle; all three of the original team have left, as has Brendan Gregg (author of both the DTraceToolkit and the recent book on DTrace). A minor point, perhaps, but a significant one for those of us who have parted ways with the company -- especially as DTrace has continued to be developed under different ownership.
But Posted Oct 8, 2011 23:53 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
Thanks for that information. It seems as though this would make Oracle's attempt to port DTrace to Linux rather tricky, unless there is now equivalent expertise among a new generation of hackers at Oracle.
But Posted Oct 10, 2011 1:43 UTC (Mon) by vonbrand (subscriber, #4458) [Link] Presumably the variables and functions to monitor are sufficiently different between Solaris and Linux that the supposed advantage of dtrace just doesn't exist.
But Posted Oct 7, 2011 12:01 UTC (Fri) by fuhchee (subscriber, #40059) [Link]
Systemtap has not limited itself to dtrace capabilities as an end goal. It already exceeds it in some interesting ways, and we plan to keep that going.
But Posted Oct 8, 2011 19:02 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
Adoption is very limited at this point and wont grow till it requires no kernel patches and everything is in the mainline kernel. That is a huge problem.
But Posted Oct 8, 2011 19:30 UTC (Sat) by fuhchee (subscriber, #40059) [Link]
"till it requires no kernel patches"
I assume you're referring to utrace/uprobes. Yes, only probing general user-space requires these, and we can hardly wait until these are mainstream.
"and everything is in the mainline kernel"
If you're repeating the previous point, ok.
But Posted Oct 8, 2011 19:59 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
Yes. Utrace/uprobes need to be merged. It doesn't matter much where the user space tool lives.
But Posted Oct 10, 2011 4:20 UTC (Mon) by cmccabe (guest, #60281) [Link]
> Just what does dtrace do that SystemTap can't (yet) do?
There's a comparison of the 4 horses in this race at:
It's worth noting that perf isn't really comparable to the other 3 systems because it has a lot more peformance impact. It's really intended more for profiling than for running in production.
Also, LTT-ng and DTrace are not in mainline.
But Posted Oct 25, 2011 21:36 UTC (Tue) by oak (subscriber, #2786) [Link]
Regarding LTTng, I think this is the most significant thing in the comparison:
"provides analysis tools to navigate in large multi-GB traces"
With LTTng you can profile "everything" happening in the system with pretty low overhead, i.e. when you still aren't sure what exactly is causing the issues. The others are intended for more targeted tracing where you often write your own script to trace things.
On other platforms than x86, one Systemtap issue is that it relies completely on kprobes instruction emulation to be correct. There were a lot of issues in that e.g. on ARM which have been only recently corrected.
But Posted Oct 10, 2011 18:18 UTC (Mon) by khc (subscriber, #45209) [Link]
Work? I tried to evaluate it a while ago (FC15 beta, so it wasn't THAT long ago) but I hit kernel panic whenever I try to put load on it (a heavily multi-threaded program). The redhat guys I chatted with on IRC were really helpful and fixed some issues (but not all), but I didn't have time to pursuit further.
A coworker ported our code to Solaris and dtrace hasn't had a problem with it yet. The situation is not ideal as we actually ship on Linux, but we only use tracing internally now so it's not too big of a deal.
|
|||||||||||||