4 ms·

The huge potential for all this is to contribute these wonderful tools to Linux, but there seems to be reluctance on that front. The code is there for the taki

The huge potential for all this is to contribute these wonderful tools to Linux, but there seems to be reluctance on that front. The code is there for the taking. FreeBSD has ported ZFS and DTrace. Guys at LLNL are using illumos ZFS code as upstream for ZFS on Linux. Others are working on DTrace. One can wait for efforts like that to keep progressing, help in whatever way they can, or just use illumos based distros (e.g. SmartOS) now and not wait around. Choice is a wonderful thing.

shykes 13y ago
Note that I am not complaining or demanding anything. You are right in assuming that I do not miss dtrace and zfs enough on my linux boxes to contribute individually to the porting effort. I am simply observing that porting these tools to Linux doesn't seem to be a priority for either the Linux community (which is already incubating multiple "home-made" alternatives such as btrfs, lxc userland tools etc.) or the SmartOS community (which can understandably be tempted to keep these tools as proprietary "killer apps"). I believe that, if there had been a more concerted and serious effort to get these tools into linux early on, by people knowledgeable and influential enough to get it done (ie. not me), setting aside platform rivalries and NiH, a lot of sysadmins and developers would be having way more fun at their job right now.
- mwcampbell 13y ago
  I'm curious about why you don't think DTrace is that important. If dotCloud were running on a bunch of SmartOS boxes, and assuming that SmartOS was running on the metal and only OS virtaulization was used, then you could use DTrace to observe all levels of the stack from the hardware all the way up to the application. That seems like it would be useful for a PaaS company.
  - shykes 13y ago
    I do think dtrace is awesome, and would certainly not make an argument against using it. We may very well use it in the future. There was no active decision not to use it at dotCloud, our "visibility toolbox" is simply based on other tools - a combination of collectd, nagios, distributed rpc tracing, active and passive checks from the http frontends, and a decent logging setup. I'm sure you could accomplish this with dtrace and probably a dozen other tools, but I guess the same is true for every problem. At some point you just choose a tool that works and move on to the next problem.
- wmf 13y ago
  The license incompatibility killed off any concerted effort before it could start.
  - brendangregg 13y ago
    The better question is: what's stopping a concerted effort now - in 2013 - from helping dtrace4linux (or the OEL port) reach completion?
    - wmf 13y ago
      The fact that it will never be upstreamed due to license incompatibility?
      - brendangregg 13y ago
        I'm using dtrace4linux just fine from another tree, which installs it as an add on, just like a package. It's massively useful for solving customer issues (replicated in the lab, since it isn't production safe yet). Having used it, I don't see a problem with continuing to use it this way, on Linux, forever.

shykes 13y ago

Note that I am not complaining or demanding anything. You are right in assuming that I do not miss dtrace and zfs enough on my linux boxes to contribute individually to the porting effort. I am simply observing that porting these tools to Linux doesn't seem to be a priority for either the Linux community (which is already incubating multiple "home-made" alternatives such as btrfs, lxc userland tools etc.) or the SmartOS community (which can understandably be tempted to keep these tools as proprietary "killer apps"). I believe that, if there had been a more concerted and serious effort to get these tools into linux early on, by people knowledgeable and influential enough to get it done (ie. not me), setting aside platform rivalries and NiH, a lot of sysadmins and developers would be having way more fun at their job right now.

mwcampbell 13y ago
I'm curious about why you don't think DTrace is that important. If dotCloud were running on a bunch of SmartOS boxes, and assuming that SmartOS was running on the metal and only OS virtaulization was used, then you could use DTrace to observe all levels of the stack from the hardware all the way up to the application. That seems like it would be useful for a PaaS company.
- shykes 13y ago
  I do think dtrace is awesome, and would certainly not make an argument against using it. We may very well use it in the future. There was no active decision not to use it at dotCloud, our "visibility toolbox" is simply based on other tools - a combination of collectd, nagios, distributed rpc tracing, active and passive checks from the http frontends, and a decent logging setup. I'm sure you could accomplish this with dtrace and probably a dozen other tools, but I guess the same is true for every problem. At some point you just choose a tool that works and move on to the next problem.
wmf 13y ago
The license incompatibility killed off any concerted effort before it could start.
- brendangregg 13y ago
  The better question is: what's stopping a concerted effort now - in 2013 - from helping dtrace4linux (or the OEL port) reach completion?
  - wmf 13y ago
    The fact that it will never be upstreamed due to license incompatibility?
    - brendangregg 13y ago
      I'm using dtrace4linux just fine from another tree, which installs it as an add on, just like a package. It's massively useful for solving customer issues (replicated in the lab, since it isn't production safe yet). Having used it, I don't see a problem with continuing to use it this way, on Linux, forever.