4 ms·

We can speculate on the management decision, but from an engineering point of view Dominic Giampaolo said that he didn't dive into btrfs, ZFS, or HAMMER in orde

by cm3 10y ago

We can speculate on the management decision, but from an engineering point of view Dominic Giampaolo said that he didn't dive into btrfs, ZFS, or HAMMER in order to not get potentially bad influence. At least that's how I read his answer as cited by Adam. It's interesting that Larry (Oracle CEO) being a good friend of the late Steve Jobs didn't result in finding an acceptable ZFS licensing agreement for Apple. I mean, they've incorporated DTrace (into the kernel of all things), so why not ZFS as well?

shmerl 10y ago
> from an engineering point of view Dominic Giampaolo said that he didn't dive into btrfs, ZFS, or HAMMER in order to not get potentially bad influence. I'm not sure I quite understand this approach. It's sounds like a pure NIH kind of method (which is admittedly common for Apple). I.e. of course one can always try to reinvent the wheel, but why is it bad first to analyze what already exists and to evaluate good / bad sides of that? Or his approach is simply always to make everything from scratch and not to look at anything else?
- cm3 10y ago
  I don't believe Dominic and the team were in NIH-mode. There are most likely other factors which due to Apple's secrecy, and this not being a public project like Linux or Firefox, we may or may not learn. Though, with the information we have right now, it's easy to come to your conclusion.
- desdiv 10y ago
  >why is it bad first to analyze what already exists and to evaluate good / bad sides of that? It's a legal defense strategy. ZFS is covered by multiple patents. If someone who have never read about any of ZFS's designs and patents independently reproduces one of ZFS's patented features, then the courts could rule that that was non-infringement. That's why the author said of Giampaolo: "...but didn't delve too deeply for fear, he said, of tainting himself". Reading too much about a patented product effectively taints yourself from being able to freely create your own designs.
  - prutschman 10y ago
    Independent reinvention is not in general a defense to a claim of patent infringement. Is there some fairly specific set of circumstances you're referring to here?
    - antod 10y ago
      No, but it helps you to avoid the potential treble damages bit for wilful infringement.
  - shmerl 10y ago
    So you think it's Apple's paranoia? They should blame themselves for contributing to this sick patent climate.
  - cm3 10y ago
    I understand what you're saying, but I also find it funny that Apple would try to avoid patents. If you're saying that Apple is happy to patent stuff but not so much when it comes to using patents by others, maybe you're right. I wish filesystems were more like media codecs in that Apple had no choice but to support an industry standard.
btbuilder 10y ago
Another possible interpretation of "to avoid becoming tainted" is that it refers to avoiding "residual knowledge" that in some circumstances can be used to make a copyright claim. E.g. if someone reads the ZFS source code to see how they solved a particular problem and then goes and solves it the same way that residual knowledge might cause legal problems. That being said IANAL and have no idea whether residual knowledge has been explored w.r.t. the GPL or CDDL.
rincebrain 10y ago
A tracing framework is much easier to rip out if it presents legal difficulty than a filesystem.
- cm3 10y ago
  How so? If anything, ignoring ZFS's cache subsystem, a filesystem is another module in a pluggable system if many fileystems. DTrace on the other hand to be most effective requires adding probes all over the kernel.
  - acdha 10y ago
    You're forgetting the weight of data and user practice for a mainstream project. Consider how those two scenarios would unfold: Apple makes a mistake in 10.11.6 and ships a kernel without DTrace. Everything runs but a few nerds notice and file bug reports. 10.11.7 quietly ships and all is right with the world. In contrast, shipping a new filesystem is enormously invasive: billions of hours are spent globally rewriting EVERY storage pool in existence. Some percentage of those will fail due to hardware problems or corruption which happened years ago (or even somewhere else) but was previously unnoticed, flooding support and the news with dire predictions. Every crash or performance issue noticed for the next year will probably be vocally blamed on the new filesystem, even if there are clear signs pointing elsewhere. You don't want to deal with that any more than you have to.
    - cm3 10y ago
      Apple will _not_ remove the existing filesystems, and neither will they automatically migrate an existing HFS volume to APFS without first asking, especially not during an OS update. There are many filesystems in the kernel, and compared to DTrace probes, they are very minimally invasive. Adding DTrace probes means touching all kinds of places in the kernel, so it's definitely more invasive.
      - acdha 10y ago
        Again, look at it from the perspective of a user or system administrator rather than a kernel developer. Yes, someone has to remove a bunch of easily searched for and removed code and rerun their test suite but that's a handful of people for a very small amount of time compared to the number of people involved with something which will make a major change on hundreds of millions of running systems. More critically, the development work is completely under Apple's control and shipping can be delayed as long as it takes to complete testing but once they ship a filesystem it will very quickly reach the point where it will be in the wild for years even if they immediately ship a new release which takes a different direction. The question isn't whether Apple will force this on users soon or without notice but rather the observation that they're going to be very careful not to do this more often than actually necessary. That's why despite having implemented and shipped ZFS in the 10.5 beta series they removed it prior to release. Sure, it might have gone okay but if that changed later there would be no easy way to go back without forcing users to migrate existing data and if that hit a licensing/patent case, the other side's lawyers enjoy the extra leverage which that would give them. As an aside, “There are many filesystems in the kernel” is technically true but misleading: HFS+/HFSX is used constantly on every device, FAT/ExFAT are used regularly by many users, and everything else is a rounding error. A few Mac users use NFS or SMB, even fewer use UFS, etc. and no iOS device uses any of those.

by cm3 10y ago

shmerl 10y ago

> from an engineering point of view Dominic Giampaolo said that he didn't dive into btrfs, ZFS, or HAMMER in order to not get potentially bad influence. I'm not sure I quite understand this approach. It's sounds like a pure NIH kind of method (which is admittedly common for Apple). I.e. of course one can always try to reinvent the wheel, but why is it bad first to analyze what already exists and to evaluate good / bad sides of that? Or his approach is simply always to make everything from scratch and not to look at anything else?

cm3 10y ago
I don't believe Dominic and the team were in NIH-mode. There are most likely other factors which due to Apple's secrecy, and this not being a public project like Linux or Firefox, we may or may not learn. Though, with the information we have right now, it's easy to come to your conclusion.
desdiv 10y ago
>why is it bad first to analyze what already exists and to evaluate good / bad sides of that? It's a legal defense strategy. ZFS is covered by multiple patents. If someone who have never read about any of ZFS's designs and patents independently reproduces one of ZFS's patented features, then the courts could rule that that was non-infringement. That's why the author said of Giampaolo: "...but didn't delve too deeply for fear, he said, of tainting himself". Reading too much about a patented product effectively taints yourself from being able to freely create your own designs.
- prutschman 10y ago
  Independent reinvention is not in general a defense to a claim of patent infringement. Is there some fairly specific set of circumstances you're referring to here?
  - antod 10y ago
    No, but it helps you to avoid the potential treble damages bit for wilful infringement.
- shmerl 10y ago
  So you think it's Apple's paranoia? They should blame themselves for contributing to this sick patent climate.
- cm3 10y ago
  I understand what you're saying, but I also find it funny that Apple would try to avoid patents. If you're saying that Apple is happy to patent stuff but not so much when it comes to using patents by others, maybe you're right. I wish filesystems were more like media codecs in that Apple had no choice but to support an industry standard.

btbuilder 10y ago

Another possible interpretation of "to avoid becoming tainted" is that it refers to avoiding "residual knowledge" that in some circumstances can be used to make a copyright claim. E.g. if someone reads the ZFS source code to see how they solved a particular problem and then goes and solves it the same way that residual knowledge might cause legal problems. That being said IANAL and have no idea whether residual knowledge has been explored w.r.t. the GPL or CDDL.

rincebrain 10y ago

A tracing framework is much easier to rip out if it presents legal difficulty than a filesystem.

cm3 10y ago
How so? If anything, ignoring ZFS's cache subsystem, a filesystem is another module in a pluggable system if many fileystems. DTrace on the other hand to be most effective requires adding probes all over the kernel.
- acdha 10y ago
  You're forgetting the weight of data and user practice for a mainstream project. Consider how those two scenarios would unfold: Apple makes a mistake in 10.11.6 and ships a kernel without DTrace. Everything runs but a few nerds notice and file bug reports. 10.11.7 quietly ships and all is right with the world. In contrast, shipping a new filesystem is enormously invasive: billions of hours are spent globally rewriting EVERY storage pool in existence. Some percentage of those will fail due to hardware problems or corruption which happened years ago (or even somewhere else) but was previously unnoticed, flooding support and the news with dire predictions. Every crash or performance issue noticed for the next year will probably be vocally blamed on the new filesystem, even if there are clear signs pointing elsewhere. You don't want to deal with that any more than you have to.
  - cm3 10y ago
    Apple will _not_ remove the existing filesystems, and neither will they automatically migrate an existing HFS volume to APFS without first asking, especially not during an OS update. There are many filesystems in the kernel, and compared to DTrace probes, they are very minimally invasive. Adding DTrace probes means touching all kinds of places in the kernel, so it's definitely more invasive.
    - acdha 10y ago
      Again, look at it from the perspective of a user or system administrator rather than a kernel developer. Yes, someone has to remove a bunch of easily searched for and removed code and rerun their test suite but that's a handful of people for a very small amount of time compared to the number of people involved with something which will make a major change on hundreds of millions of running systems. More critically, the development work is completely under Apple's control and shipping can be delayed as long as it takes to complete testing but once they ship a filesystem it will very quickly reach the point where it will be in the wild for years even if they immediately ship a new release which takes a different direction. The question isn't whether Apple will force this on users soon or without notice but rather the observation that they're going to be very careful not to do this more often than actually necessary. That's why despite having implemented and shipped ZFS in the 10.5 beta series they removed it prior to release. Sure, it might have gone okay but if that changed later there would be no easy way to go back without forcing users to migrate existing data and if that hit a licensing/patent case, the other side's lawyers enjoy the extra leverage which that would give them. As an aside, “There are many filesystems in the kernel” is technically true but misleading: HFS+/HFSX is used constantly on every device, FAT/ExFAT are used regularly by many users, and everything else is a rounding error. A few Mac users use NFS or SMB, even fewer use UFS, etc. and no iOS device uses any of those.