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:

DTrace is not really a tool that sysadmins use to fix their own problems, it's a mechanism that your support provider and/or OS vendor uses to provide support.

(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.)

Written on 16 November 2012.
« A learning experience: internal mail flow should never be allowed to bounce
Why Google's handling of multiple domains on inbound messages is okay »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Nov 16 01:33:56 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.