Why DTrace does not attract people to Solaris very often
November 16, 2012
Back when Solaris 10 was fresh and new, DTrace was supposed to be one of its significant competitive advantages, one of the major things that made it attractive to system administrators (and organizations). In practice Solaris 10 got a tepid reception, DTrace included, despite all of the banging on drums that supporters of Solaris did (and somewhat to their disbelief, at least in my impression of things). Having now used DTrace somewhat, I have an opinion on why.
It's pretty simple:
(This idea was first expressed by a commentator on my entry on why we haven't taken to DTrace and has probably been percolating in the back of my mind ever since.)
You can certainly use DTrace to write your own diagnostic tools; after all, we did. But DTrace's almost complete lack of useful documented tracepoints means that doing this basically requires that you can read and understand (Open)Solaris code. Or, to put it another way, you need a system programmer. And system programmers are now uncommon; most places do not have one around and so will never write their own DTrace scripts (beyond at most very simple ones).
As for DTrace as a mechanism to help your OS vendor, well, sysadmins and organizations don't care how OS vendors provide support, just that they do (or don't). A mechanism to provide diagnostic tools is not a selling feature; at best, the diagnostic tools themselves are.
(Also, as I've sort of written before, most sysadmins don't expect to run into problems.)
The less pleasant way to put this is that people are not attracted to technologies, they are attracted to solutions to problems. DTrace is a fine technology but for most places it is not a solution.
(I don't know what Sun's true vision for DTrace was. If they planned for it to be a serious competitive advantage as opposed to mostly an internal tool, I think that they dropped the ball badly.)
* * *
Atom feeds are available; see the bottom of most pages.