6 ms·

I worked on Apple’s ZFS port, and it was indeed licensing. Apple’s lawyers took a closer look at the CDDL when we were close to shipping and found some provisio

I worked on Apple’s ZFS port, and it was indeed licensing. Apple’s lawyers took a closer look at the CDDL when we were close to shipping and found some provisions that were unacceptable to them.

gsnedders 8y ago
But were acceptable for DTrace?
- Analemma_ 8y ago
  Different risk assessments. DTrace is a non-critical tool, and a totally standalone one. If it suddenly had to be yanked out of macOS because of licensing issues, there would be gnashing of teeth but life would ultimately go on. The filesystem is a different story: if something happened and it had to be immediately removed, Apple would be up shit creek.
  - gsnedders 8y ago
    It's not totally standalone (it has kernel components, for example), but yes, it's clearly something far easier to suddenly drop.
    - jldugger 8y ago
      I think the point is you can rip the kernel components out, and the (non-Dtrace using dev) user doesn't notice. Whereas removing a filesystem driver leaves users without their data.
    - bangonkeyboard 8y ago
      Mojave drops support for DTrace probes in Instruments, so this process may already have begun.
      - tambourine_man 8y ago
        Really? Is there a replacement?
        eridius 8y ago
        Instruments in Xcode 10 has a new way of constructing "custom instruments". I haven't looked into the details though, so I don't know how much of the old DTrace stuff can be replicated.
      - eridius 8y ago
        Very few people internally to Apple cared about DTrace, and the person who was primarily responsible for evangelizing it left that particular role years ago. DTrace support has been slowly degrading over time (to the point that Apple has ended up shipping DTrace scripts on the system that do nothing but spew errors if you try and use them, as the probes changed and nobody updated the scripts). It's a shame, because DTrace is cool and very powerful, but it seems almost nobody bothered to actually learn how to use it or cared about supporting it.
        EdwardCoffin 8y ago
        I've been using DTrace on High Sierra a bit for the past few months, and it has been working fine for me. I'm writing my own scripts though. I did notice that the sample scripts often did not work, but did not think that meant much. DTrace is definitely cool and powerful. I'm surprised to hear that few people at Apple cared about it - I'd have thought it was an essential tool for them to solve certain kinds of problems. It's funny, because the tool itself is relatively simple. It seems to me that most of the knowledge needed to use it effectively is an understanding of the code being instrumented, rather than of DTrace itself. Hopefully the sample scripts degrading does not foreshadow the probes themselves degrading too.
        eridius 8y ago
        I'm not just talking about "sample scripts". The system ships with a few DTrace scripts in /usr/bin as tools and they're rather broken. For example, running /usr/bin/iosnoop just prints an "invalid probe specifier" error. I haven't done an exhaustive catalog of all the /usr/bin DTrace scripts but last I checked there's at least one other broken one as well. Trying to use DTrace with SIP also warns that "some features will not be available", though I don't know offhand what DTrace features don't work with SIP.
  - lemoncucumber 8y ago
    Yep, this was more or less exactly how the conversation went.
    - KindOne 8y ago
      What about this? Does this change anything? https://gnu.wildebeest.org/blog/mjw/2018/02/14/dtrace-for-linux-oracle-does-the-right-thing/ https://gnu.wildebeest.org/blog/mjw/2018/02/14/dtrace-for-li...
      - lemoncucumber 8y ago
        No, for a lot of reasons: 1) AFAICT they didn't relicense any of the ZFS code, just dtrace. 2) Even if they had, GPLv2 code still wouldn't be able to go into xnu. 3) Even if it could, Apple has long since moved on from ZFS. They've taken the time to write a new filesystem (APFS) already, so it's hard to see them having any interest in ZFS at this point (and yes, I know APFS doesn't have all the features of ZFS).
        KindOne 8y ago
        Sorry, I meant the dtrace code, not the zfs. Thanks for the answers.
  - 2trill2spill 8y ago
    Doesn't instruments and activity monitor build on top of Dtrace in MacOS? Which if true doesn't seem so easy to rip out.
    - dkonofalski 8y ago
      You're still comparing, at most, a handful of applications that would need to be removed or updated vs. an entire filesystem that everything is built upon.
      - 2trill2spill 8y ago
        Sure certainly less effort, I guess I was responding to the previous poster saying Dtrace was a "standalone" program, because other programs build on top of it.
  - deleted 8y ago
    [deleted]
lundman 8y ago
Cool, as someone still working with that code (a little bit still remains) thanks for your work :)

I worked on Apple’s ZFS port, and it was indeed licensing. Apple’s lawyers took a closer look at the CDDL when we were close to shipping and found some provisions that were unacceptable to them.

gsnedders 8y ago

But were acceptable for DTrace?

Analemma_ 8y ago
Different risk assessments. DTrace is a non-critical tool, and a totally standalone one. If it suddenly had to be yanked out of macOS because of licensing issues, there would be gnashing of teeth but life would ultimately go on. The filesystem is a different story: if something happened and it had to be immediately removed, Apple would be up shit creek.
- gsnedders 8y ago
  It's not totally standalone (it has kernel components, for example), but yes, it's clearly something far easier to suddenly drop.
  - jldugger 8y ago
    I think the point is you can rip the kernel components out, and the (non-Dtrace using dev) user doesn't notice. Whereas removing a filesystem driver leaves users without their data.
  - bangonkeyboard 8y ago
    Mojave drops support for DTrace probes in Instruments, so this process may already have begun.
    - tambourine_man 8y ago
      Really? Is there a replacement?
      - eridius 8y ago
        Instruments in Xcode 10 has a new way of constructing "custom instruments". I haven't looked into the details though, so I don't know how much of the old DTrace stuff can be replicated.
    - eridius 8y ago
      Very few people internally to Apple cared about DTrace, and the person who was primarily responsible for evangelizing it left that particular role years ago. DTrace support has been slowly degrading over time (to the point that Apple has ended up shipping DTrace scripts on the system that do nothing but spew errors if you try and use them, as the probes changed and nobody updated the scripts). It's a shame, because DTrace is cool and very powerful, but it seems almost nobody bothered to actually learn how to use it or cared about supporting it.
      - EdwardCoffin 8y ago
        I've been using DTrace on High Sierra a bit for the past few months, and it has been working fine for me. I'm writing my own scripts though. I did notice that the sample scripts often did not work, but did not think that meant much. DTrace is definitely cool and powerful. I'm surprised to hear that few people at Apple cared about it - I'd have thought it was an essential tool for them to solve certain kinds of problems. It's funny, because the tool itself is relatively simple. It seems to me that most of the knowledge needed to use it effectively is an understanding of the code being instrumented, rather than of DTrace itself. Hopefully the sample scripts degrading does not foreshadow the probes themselves degrading too.
        eridius 8y ago
        I'm not just talking about "sample scripts". The system ships with a few DTrace scripts in /usr/bin as tools and they're rather broken. For example, running /usr/bin/iosnoop just prints an "invalid probe specifier" error. I haven't done an exhaustive catalog of all the /usr/bin DTrace scripts but last I checked there's at least one other broken one as well. Trying to use DTrace with SIP also warns that "some features will not be available", though I don't know offhand what DTrace features don't work with SIP.
- lemoncucumber 8y ago
  Yep, this was more or less exactly how the conversation went.
  - KindOne 8y ago
    What about this? Does this change anything? https://gnu.wildebeest.org/blog/mjw/2018/02/14/dtrace-for-linux-oracle-does-the-right-thing/ https://gnu.wildebeest.org/blog/mjw/2018/02/14/dtrace-for-li...
    - lemoncucumber 8y ago
      No, for a lot of reasons: 1) AFAICT they didn't relicense any of the ZFS code, just dtrace. 2) Even if they had, GPLv2 code still wouldn't be able to go into xnu. 3) Even if it could, Apple has long since moved on from ZFS. They've taken the time to write a new filesystem (APFS) already, so it's hard to see them having any interest in ZFS at this point (and yes, I know APFS doesn't have all the features of ZFS).
      - KindOne 8y ago
        Sorry, I meant the dtrace code, not the zfs. Thanks for the answers.
- 2trill2spill 8y ago
  Doesn't instruments and activity monitor build on top of Dtrace in MacOS? Which if true doesn't seem so easy to rip out.
  - dkonofalski 8y ago
    You're still comparing, at most, a handful of applications that would need to be removed or updated vs. an entire filesystem that everything is built upon.
    - 2trill2spill 8y ago
      Sure certainly less effort, I guess I was responding to the previous poster saying Dtrace was a "standalone" program, because other programs build on top of it.
- deleted 8y ago
  [deleted]

lundman 8y ago

Cool, as someone still working with that code (a little bit still remains) thanks for your work :)