6 ms·

That's a great theory, but Linus picks and chooses when to decide it's outrageous to make changes that break userland tools based on his personal preferences.

by tw04 7y ago

That's a great theory, but Linus picks and chooses when to decide it's outrageous to make changes that break userland tools based on his personal preferences. They intentionally broke ZFS - then Linus follows up with a wildly inaccurate statement about why he thinks nobody should use ZFS. It's difficult to take him seriously when he picks and chooses when to enforce his supposed "never break userland" ethos.

sheepdestroyer 7y ago
ZFS is not user land. It's kernel code but without being in the kernel. So it has to be built separately and may not even be compliant with GPL (still has to be tested in court AFAIK). Linux's promise to not break userspace is just that, It can not be held responsible for code that should be in the kernel but does not play fair with the license.
- michaelmrose 7y ago
  It's not that it doesn't play fair. Sun published under a license that made inclusion in the kernel impossible thus the current developers are bound by the same decisions regardless of their opinion on the matter. Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux becomes by virtue of a bridge a derivative work of Linux. It's magical thinking. It is entirely acceptable that they aren't responsible for out of tree code working but it would be great if they didn't deliberately sabotage other projects which is what they did here. >My tolerance for ZFS is pretty non-existant. Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly? The extra work is 10 seconds of work. How childish and unprofessional.
  - wtallis 7y ago
    > Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux becomes by virtue of a bridge a derivative work of Linux. It's magical thinking. It's not magical thinking. A work can be a derivative of multiple other works. It's completely plausible that adding Linux stuff to ZFS can make it a derivative work of Linux in addition to being a derivative work of whatever else it is already a derivative work of. There's room for debate about how much Linux stuff (and of what nature) something like ZFS can incorporate before it becomes a derivative work according to copyright law and the GPLv2, but you cannot dismiss the idea outright.
  - ferzul 7y ago
    > Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux becomes by virtue of a bridge a derivative work of Linux. It's magical thinking. please don't confuse the source code and the resulting binaries. to the extent that the zsh source code does not derive from Linux, it is not a derivative work. but the binaries built for Linux will necessarily be derivative of both. and we regularly redistribute binaries; this indeed is what Linux distributions ordinarily do. if you only write the bridging code and/or distribute the module source, you may be quite protected. but if you distribute a patch from the mainline to include zsh, or a mixed tarball of Linux+zsh, or even compiled Linux kernels complete with a loadable zsh module, you may be in breach. all of these clearly derive from multiple sources with incompatible licences.
  - aidenn0 7y ago
    > Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux becomes by virtue of a bridge a derivative work of Linux. It's magical thinking. Let's say I make a movie M. It's a nice movie, but it doesn't have music. Someone else wrote some music S that is quite lovely. If anybody takes my movie M and mixes in music S, then the new movie is a derivative work of both M and S.
  - inshadows 7y ago
    > The extra work is 10 seconds of work. How childish and unprofessional. While Oracle keeping the code under incompatible license for more than 10 years is totally OK.
    - michaelmrose 7y ago
      What does it have to do with the zfs developers who no longer work for oracle?
      - inshadows 7y ago
        It has to do with people barking at the wrong tree.
  - tylerl 7y ago
    Magical indeed. Except that public opinion counts for nothing in copyright law; you have to fight it out in court. Luckily, Sun isn't the kind of company that would file questionable lawsuits against Linux users just to... wait.. wasn't Sun bought by another company? Well, whoever owns the copyright now, you're probably reasonably safe unless they're a hyper-litigious corporation with deep pockets and an army of lawyers, who see lawsuits about software licensing as a potential source of income.... I mean, what are the chances?
deleted 7y ago
[deleted]
loeg 7y ago
For a scary few days he was considering completely breaking the ABI of getrandom(2). If he decides to break interfaces, I don't know that anyone can stop him. It is a downside to the BDFL model. Edit: Breaking ZFS is not a great example — as sibling comment points out, that is a kernel module using kernel-internal APIs, not userspace syscall ABI. The Linux kernel notoriously considers all kernel interfaces unstable. GregKH has in the past characterized this as a feature, not a bug.
- teddyh 7y ago
  > The Linux kernel notoriously considers all kernel interfaces unstable. “You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree.” — Greg Kroah-Hartman <greg@kroah.com> https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html https://www.kernel.org/doc/html/latest/process/stable-api-no...
- inshadows 7y ago
  I think that it is a upside of BDFL model, unless it's someone incompetent. If you dig deep in the threads you'll find that so far his judgement on what to break or not has always been stellar. As long as you have someone as competent as Linus making the call, BDFL model is perfect. RE getrandom(2): As Linus said several times, we don't break userspace rule does not apply to security bugs. If there's no other way to fix security bug other than breaking userspace, then userspace has to be broken, for obvious reason. If you don't understand that reason, you shouldn't really have a say in any such critical decision.
  - loeg 7y ago
    > unless it's someone incompetent. Unfortunately, Linus is dangerously incompetent at cryptography. As was the case with getrandom(2). > RE getrandom(2): As Linus said several times, we don't break userspace rule does not apply to security bugs. I don't think you understand or correctly recall the scenario in which Linus nearly broke getrandom(2). The bug Linus was attempting to fix by breaking getrandom(2) was not a security bug. It was an availability bug, in userspace, caused by broken userspace code deadlocking itself.
deleted 7y ago
[deleted]
gnulinux 7y ago
Did you read his mail though? He literally answers this criticism. ZFS is not userland so kernel developers are free to break it, just like they can break ext4 and do, and then they fix them. The problem with ZFS is that they can't fix it because it's not part of linux. It's a 3rd party kernel module. So your entire comment reads like a misunderstanding of the situation.
- cyphar 7y ago
  The breakage of ZoL wasn't a side-effect of some big technical change. They literally just made the SIMD enable/disable barriers no longer usable from non-GPL modules (the changed an EXPORT_SYMBOL to EXPORT_SYMBOL_GPL). This means you can't use SIMD-accelerated hashing functions from ZoL -- and there is no way to fix it without hurting performance other than reverting the "license change". And the entire justification for this change was "there are no in-kernel users". Now, they are obviously free to do that and ZoL needs to work around it. But it's silly to argue that this was not an intentional breakage of a system which many people use and cannot be worked around out-of-kernel. Yes, it's not userspace code but it did cause regressions for users. Linus and GregKH have always disliked ZFS because they feel it was designed to be incompatible with Linux (and they're entitled to that view, however wrong it may be) so it's unsurprising that they are against doing anything that may help ZoL.
  - blibble 7y ago
    ZoL already worked around it months ago
    - deleted 7y ago
      [deleted]
  - tylerl 7y ago
    > ...disliked ZFS because they feel it was designed to be incompatible with Linux... Ya... That may have just a bit to do with the fact that ZFS is released under a licence that was explicitly designed to be incompatible with Linux. "Mozilla was selected partially because it is GPL incompatible. That was part of the design when they released OpenSolaris. ... the engineers who wrote Solaris ... had some biases about how it should be released, and you have to respect that." I can see how that might suggest to Linux maintainers that they are not welcome to use this code. Maybe sorta.

by tw04 7y ago

sheepdestroyer 7y ago

ZFS is not user land. It's kernel code but without being in the kernel. So it has to be built separately and may not even be compliant with GPL (still has to be tested in court AFAIK). Linux's promise to not break userspace is just that, It can not be held responsible for code that should be in the kernel but does not play fair with the license.

michaelmrose 7y ago
It's not that it doesn't play fair. Sun published under a license that made inclusion in the kernel impossible thus the current developers are bound by the same decisions regardless of their opinion on the matter. Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux becomes by virtue of a bridge a derivative work of Linux. It's magical thinking. It is entirely acceptable that they aren't responsible for out of tree code working but it would be great if they didn't deliberately sabotage other projects which is what they did here. >My tolerance for ZFS is pretty non-existant. Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly? The extra work is 10 seconds of work. How childish and unprofessional.
- wtallis 7y ago
  > Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux becomes by virtue of a bridge a derivative work of Linux. It's magical thinking. It's not magical thinking. A work can be a derivative of multiple other works. It's completely plausible that adding Linux stuff to ZFS can make it a derivative work of Linux in addition to being a derivative work of whatever else it is already a derivative work of. There's room for debate about how much Linux stuff (and of what nature) something like ZFS can incorporate before it becomes a derivative work according to copyright law and the GPLv2, but you cannot dismiss the idea outright.
- ferzul 7y ago
  > Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux becomes by virtue of a bridge a derivative work of Linux. It's magical thinking. please don't confuse the source code and the resulting binaries. to the extent that the zsh source code does not derive from Linux, it is not a derivative work. but the binaries built for Linux will necessarily be derivative of both. and we regularly redistribute binaries; this indeed is what Linux distributions ordinarily do. if you only write the bridging code and/or distribute the module source, you may be quite protected. but if you distribute a patch from the mainline to include zsh, or a mixed tarball of Linux+zsh, or even compiled Linux kernels complete with a loadable zsh module, you may be in breach. all of these clearly derive from multiple sources with incompatible licences.
- aidenn0 7y ago
  > Furthermore it is profoundly curious to claim that a cross platform filesystem that began life on Solaris and existed for years as a stable complete work before being ported to several OS including Linux becomes by virtue of a bridge a derivative work of Linux. It's magical thinking. Let's say I make a movie M. It's a nice movie, but it doesn't have music. Someone else wrote some music S that is quite lovely. If anybody takes my movie M and mixes in music S, then the new movie is a derivative work of both M and S.
- inshadows 7y ago
  > The extra work is 10 seconds of work. How childish and unprofessional. While Oracle keeping the code under incompatible license for more than 10 years is totally OK.
  - michaelmrose 7y ago
    What does it have to do with the zfs developers who no longer work for oracle?
    - inshadows 7y ago
      It has to do with people barking at the wrong tree.
- tylerl 7y ago
  Magical indeed. Except that public opinion counts for nothing in copyright law; you have to fight it out in court. Luckily, Sun isn't the kind of company that would file questionable lawsuits against Linux users just to... wait.. wasn't Sun bought by another company? Well, whoever owns the copyright now, you're probably reasonably safe unless they're a hyper-litigious corporation with deep pockets and an army of lawyers, who see lawsuits about software licensing as a potential source of income.... I mean, what are the chances?

deleted 7y ago

[deleted]

loeg 7y ago

For a scary few days he was considering completely breaking the ABI of getrandom(2). If he decides to break interfaces, I don't know that anyone can stop him. It is a downside to the BDFL model. Edit: Breaking ZFS is not a great example — as sibling comment points out, that is a kernel module using kernel-internal APIs, not userspace syscall ABI. The Linux kernel notoriously considers all kernel interfaces unstable. GregKH has in the past characterized this as a feature, not a bug.

teddyh 7y ago
> The Linux kernel notoriously considers all kernel interfaces unstable. “You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree.” — Greg Kroah-Hartman <greg@kroah.com> https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html https://www.kernel.org/doc/html/latest/process/stable-api-no...
inshadows 7y ago
I think that it is a upside of BDFL model, unless it's someone incompetent. If you dig deep in the threads you'll find that so far his judgement on what to break or not has always been stellar. As long as you have someone as competent as Linus making the call, BDFL model is perfect. RE getrandom(2): As Linus said several times, we don't break userspace rule does not apply to security bugs. If there's no other way to fix security bug other than breaking userspace, then userspace has to be broken, for obvious reason. If you don't understand that reason, you shouldn't really have a say in any such critical decision.
- loeg 7y ago
  > unless it's someone incompetent. Unfortunately, Linus is dangerously incompetent at cryptography. As was the case with getrandom(2). > RE getrandom(2): As Linus said several times, we don't break userspace rule does not apply to security bugs. I don't think you understand or correctly recall the scenario in which Linus nearly broke getrandom(2). The bug Linus was attempting to fix by breaking getrandom(2) was not a security bug. It was an availability bug, in userspace, caused by broken userspace code deadlocking itself.

deleted 7y ago

[deleted]

gnulinux 7y ago

Did you read his mail though? He literally answers this criticism. ZFS is not userland so kernel developers are free to break it, just like they can break ext4 and do, and then they fix them. The problem with ZFS is that they can't fix it because it's not part of linux. It's a 3rd party kernel module. So your entire comment reads like a misunderstanding of the situation.

cyphar 7y ago
The breakage of ZoL wasn't a side-effect of some big technical change. They literally just made the SIMD enable/disable barriers no longer usable from non-GPL modules (the changed an EXPORT_SYMBOL to EXPORT_SYMBOL_GPL). This means you can't use SIMD-accelerated hashing functions from ZoL -- and there is no way to fix it without hurting performance other than reverting the "license change". And the entire justification for this change was "there are no in-kernel users". Now, they are obviously free to do that and ZoL needs to work around it. But it's silly to argue that this was not an intentional breakage of a system which many people use and cannot be worked around out-of-kernel. Yes, it's not userspace code but it did cause regressions for users. Linus and GregKH have always disliked ZFS because they feel it was designed to be incompatible with Linux (and they're entitled to that view, however wrong it may be) so it's unsurprising that they are against doing anything that may help ZoL.
- blibble 7y ago
  ZoL already worked around it months ago
  - deleted 7y ago
    [deleted]
- tylerl 7y ago
  > ...disliked ZFS because they feel it was designed to be incompatible with Linux... Ya... That may have just a bit to do with the fact that ZFS is released under a licence that was explicitly designed to be incompatible with Linux. "Mozilla was selected partially because it is GPL incompatible. That was part of the design when they released OpenSolaris. ... the engineers who wrote Solaris ... had some biases about how it should be released, and you have to respect that." I can see how that might suggest to Linux maintainers that they are not welcome to use this code. Maybe sorta.