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.
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.
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.
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.
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.
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.
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.
I think your problem with /usr/bin/iosnoop might be due to SIP. I no longer remember exactly which I did, but I know that I either partially or completely disabled SIP when I started to use DTrace, a number of months ago. I might have used one of the procedures outlined in this post [1] to do so. I do know that /usr/bin/iosnoop seems to work for me - at least, I just this moment invoked it, and got regular DTrace-style output with no errors like you mention. I am running an up-to-date High Sierra (10.13.6).
Edit: SIP is only partially disabled on my system, just enough to allow DTrace to work.
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).
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.
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.
But were acceptable for DTrace?
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.
It's not totally standalone (it has kernel components, for example), but yes, it's clearly something far easier to suddenly drop.
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.
Mojave drops support for DTrace probes in Instruments, so this process may already have begun.
Really? Is there a replacement?
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.
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.
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.
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.
I think your problem with /usr/bin/iosnoop might be due to SIP. I no longer remember exactly which I did, but I know that I either partially or completely disabled SIP when I started to use DTrace, a number of months ago. I might have used one of the procedures outlined in this post [1] to do so. I do know that /usr/bin/iosnoop seems to work for me - at least, I just this moment invoked it, and got regular DTrace-style output with no errors like you mention. I am running an up-to-date High Sierra (10.13.6).
Edit: SIP is only partially disabled on my system, just enough to allow DTrace to work.
[1] https://web.archive.org/web/20160809042951/https://internals...
Yep, this was more or less exactly how the conversation went.
What about this? Does this change anything?
https://gnu.wildebeest.org/blog/mjw/2018/02/14/dtrace-for-li...
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).
Sorry, I meant the dtrace code, not the zfs. Thanks for the answers.
Doesn't instruments and activity monitor build on top of Dtrace in MacOS? Which if true doesn't seem so easy to rip out.
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.
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.
Cool, as someone still working with that code (a little bit still remains) thanks for your work :)