I'm really kind of mystified by how DTrace has captured people's imaginations. How could something like DTrace justify an entire server platform? I have it on my Mac, I'm a professional reverser, and it's never the first thing I reach for. I'm serious, what's the huge win here?
You never, ever hear people say that Detours is a reason to switch to Win32. But Detours seems, if anything, more useful than DTrace.
Dtrace is useful because you can run it without having to interrupt any processes on the machine, and it is safe (won't cause kernel panics) and lightweight (won't slow the machine down too much) enough to use on a production site.
DTrace lets you instrument either 1 process, a collection of processes, or all processes at the syscall level. Want to know which processes are usinng disk IO; then what the size of the IO writes is? You can do that. For instance, you might want to tune your RAID controller stripe size to your IO-intensive application.
I'm pretty sure syscall-level instrumentation isn't the win with DTrace, since every modern Unix provides a safe, lightweight method for collecting that info. In fact, if you know how DTrace actually works, what Sun is doing is actually scarier than, say, truss.
I'm not saying there isn't a DTrace win; just that you haven't shown it.
DTrace's innovation is that it provides an easy to use interface which
allows people to get results they want in a way that would otherwise
require significant low-level expertise and engineering time. That people like it should come as no suprise to the entrepreneurial crowd here - it's just another twist on Make Something People Want.
One thing I particularly like about DTrace is its awk-like language
makes it easy to borrow snippets of useful code from existing DTrace
scripts. When I needed the equivalent of linux's Paco [1] tool on my
OSX box I found I could easily build it from the code of /usr/bin/dtruss[2] and
/usr/bin/pathopens.d[3]
DTrace is also what apparently powers Sun's Storage Analytics[4]
It's funny, because the awk-like D language is my least favorite aspect of the system. DTrace had an example to build on in this space: libpcap, which is the lingua franca of packet-level network programming on every platform at every performance level. If they had just took their probes and promoted an API with Python bindings, I'd have been all over it.
While there are benefits to that approach, I'm glad they didn't do things that way. Putting performance issues aside, I think it's a lot easier to develop, test and maintain a small single purpose language then a cross-platform library with a public API and suite of bindings to an evolving language like Python.
Given the size of its team, DTrace would never have succeeded as a
library with bindings to even one dynamic language like Python because
the support burden of doing that is enormous. Developing, maintaining
and testing dynamic language bindings on multiple platforms has got to
be one of the suckiest programming tasks in the industry. Just ask
anyone who has ever had to support a PyQT or PyWx application on
multiple platforms. There's a good reason why Python's only stable
cross-platform gui is the one whose underlying gui library has been
dead for a decade.
Maintaining cross-platform bindings to a popular dynamic language like
Python, Ruby or Perl is like fighting a war on three fronts. You have
to expose the basic features of the library in a useful way while the
os vendors are breaking things in their zeal to support new features
and and hardware while at the same time the dynamic language
developers languages are "improving" their languages in significant
semantic ways.
In contrast the DTrace developers and porters only need to worry about
kernel internals - the D language is trivial to maintain and nobody
who matters in that community wants it to be anything other than what
it is: a tool for admins to find out who or what to blame when
something isn't working as it should. The people who love DTrace the
most and are willing to part with their cash for it aren't programmers
or hackers, they're DBAs and storage guys who get wet dreams about
stability, uptime and security who don't tolerate willy-nilly changes
to things that work for them and worrying that D will evolve too quickly
is like worrying about the something like gdb command set will get out
of control.
"Want to know which processes are usinng disk IO; then what the size of the IO writes is?"
You don't need dtrace for that, or even strace. The IO accounting built into most operating systems will tell you. iotop exposes it in an easy to read form that doesn't require learning a new programming language.
Oddly enough, the last reason I heard for ZFS was intercepting printfs to show SQL calls. Kind of like using MySQLs debug mode, but like the previous example requiring learning a new programming language for no benefit.
It seems many dtrace advocates lack basic system administration skills.
dtrace (and systemtep on Linux) are useful for tracing kernel level issues if you're a kernel developer. Most people pay a vendor to do this.
I think the idea is that Sun is the technical steward for the project and it's worth supporting Sun (via Solaris) to continue to fund efforts to create tools of these types. I don't believe the idea is "I need a platform with great debugging so I pester my management to get me a Sun to keep around".
I don't know that I agree, but I believe that's the rationale.
Interesting and wrong-headed: the idea was both to optimize the architecture for C functional calls and to allow the processor to "scale" (hence the name) by adding to the register file without breaking the ABI (which you'd have to do to, say, add an %EFX register to x86).
But: call stack depth on modern programs pushed register performance up against L1 cache performance for the C stack, and SPARC's convolution register spill/fill seems to have been a liability. More importantly, adding registers has not over the last decade been the primary mechanism by which processor speed is "scaled".
There are hardware people here that could articulate this more accurately and correctly than me; I've got some SPARC assembly game, but I'm not a hardware design guy. But when I say the ISA has been discredited, I'm talking about things like register windows.
