4 ms·

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

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] [1] - http://paco.sourceforge.net http://paco.sourceforge.net [2] - http://www.opensource.apple.com/darwinsource/10.5.5/dtrace-48/DTTk/dtruss http://www.opensource.apple.com/darwinsource/10.5.5/dtrace-4... [3] - http://www.opensource.apple.com/darwinsource/10.5.5/dtrace-48/DTTk/Proc/pathopens.d http://www.opensource.apple.com/darwinsource/10.5.5/dtrace-4... [4] - http://ctistrategy.com/2008/12/17/sun-storage-7000-analytics-overview http://ctistrategy.com/2008/12/17/sun-storage-7000-analytics...

tptacek 18y ago
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.
- bayareaguy 18y ago
  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.
  - tptacek 18y ago
    You think Python is less a moving target than a newly invented Unix-bound domain specific language for system tracing?
    - bayareaguy 18y ago
      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.

tptacek 18y ago

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.

bayareaguy 18y ago
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.
- tptacek 18y ago
  You think Python is less a moving target than a newly invented Unix-bound domain specific language for system tracing?
  - bayareaguy 18y ago
    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.