7 ms·

This is highly biased opinion piece. I like BSD. I liked pre-Oracle Solaris. And I like Linux at lot too. And it is factually inaccurate. Deprecation of ifconf

by fargle 7y ago

This is highly biased opinion piece. I like BSD. I liked pre-Oracle Solaris. And I like Linux at lot too. And it is factually inaccurate. Deprecation of ifconfig is a distro issue. "Linux" did not deprecate it. And the reason is that it was unmaintained, not that it couldn't handle multiple IP addresses. In fact it can, I still use it 50% of the time. Works fine for setting and displaying multiple addresses. The Debian maintainers wanted to drop it, and the other distros all followed suit a couple years later. Good information and links here: https://serverfault.com/questions/633087/where-is-the-statement-of-deprecation-of-ifconfig-on-linux https://serverfault.com/questions/633087/where-is-the-statem... "Linux maintains known bugs – and actively refuses to fix them. In fact, if you attempt to fix them, Linus will curse at you, as manifest by this email." That is a bold statement but is not at all supported by the linked email. You'll see Linus cursing at a bad patch that would break something in userland, not for "maintaining a bug". He's preventing at least two bugs (unnecessary change to behavior and ENOENT is indeed the wrong return value). I think I liked the old Linus better... So it's a shame. I'd love to read a series about BSD, but this is really just inaccurate propaganda.

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.
- 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.
Jasper_ 7y ago
If you follow the email thread through to the end, nobody was trying to intentionally break userspace. An internal error code was being leaked to userspace accidentally. That was the bug. The original patch was actually fixing a different issue, where some V4L2 devices were returning the wrong error codes! So userspace was already seeing an inconsistent API. I don't like this email thread, because some people are clearly trying to carefully find the breakage and fix it, but Linus yelling at people is all that people ever see from it. So the conversation changes from fixing a bug to insults and anger.
deano 7y ago
I agree this is opinionated. By this same token you could say that FreeBSD maintains bugs in the name of backwards compatibility and performance. https://vez.mrsk.me/freebsd-defaults.txt https://vez.mrsk.me/freebsd-defaults.txt
rstuart4133 7y ago
> And the reason is that it was unmaintained, not that it couldn't handle multiple IP addresses. Unmaintained sounds like a very good reason to me. It's not just whether there is 1 or 2 addresses per interface. The rot set in when Alexy re-did the Linux kernels network infrastructure back god knows when (its decades ago now), and wrote his own user space tool to configure it. That tool was ip. It not only handled multi ip addresses per interface - it handled multiple routing tables, multiple link types, routing rules and a whole pile of other things. And that single tool has been growing ever since - it's now huge. Type typing "man ip-<tab><tab>" on a cli that supports tab completion some time. Effectively the task of keeping up with the kernel's new features kept growing and at some point the ifconfig maintainers gave up. It was all over bar the shouting at the point. The only surprising thing is the shouting has gone on for literally decades, and as this article demonstrates continues to this day. Lets hope the same angst over systemd doesn't continue for the same amount of time. Just like like systemd there are things that rub me the wrong way of course. Coping the Cisco IOS style of command line usage rather than using the Linux style is for me one of those things. But it happened for a reason - Alexy set the standard when he wrote the first version of ip, and he was trying to emulate the features provided by a Cisco router at the time.

by fargle 7y ago

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.
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.

Jasper_ 7y ago

If you follow the email thread through to the end, nobody was trying to intentionally break userspace. An internal error code was being leaked to userspace accidentally. That was the bug. The original patch was actually fixing a different issue, where some V4L2 devices were returning the wrong error codes! So userspace was already seeing an inconsistent API. I don't like this email thread, because some people are clearly trying to carefully find the breakage and fix it, but Linus yelling at people is all that people ever see from it. So the conversation changes from fixing a bug to insults and anger.

deano 7y ago

I agree this is opinionated. By this same token you could say that FreeBSD maintains bugs in the name of backwards compatibility and performance. https://vez.mrsk.me/freebsd-defaults.txt https://vez.mrsk.me/freebsd-defaults.txt

rstuart4133 7y ago

> And the reason is that it was unmaintained, not that it couldn't handle multiple IP addresses. Unmaintained sounds like a very good reason to me. It's not just whether there is 1 or 2 addresses per interface. The rot set in when Alexy re-did the Linux kernels network infrastructure back god knows when (its decades ago now), and wrote his own user space tool to configure it. That tool was ip. It not only handled multi ip addresses per interface - it handled multiple routing tables, multiple link types, routing rules and a whole pile of other things. And that single tool has been growing ever since - it's now huge. Type typing "man ip-<tab><tab>" on a cli that supports tab completion some time. Effectively the task of keeping up with the kernel's new features kept growing and at some point the ifconfig maintainers gave up. It was all over bar the shouting at the point. The only surprising thing is the shouting has gone on for literally decades, and as this article demonstrates continues to this day. Lets hope the same angst over systemd doesn't continue for the same amount of time. Just like like systemd there are things that rub me the wrong way of course. Coping the Cisco IOS style of command line usage rather than using the Linux style is for me one of those things. But it happened for a reason - Alexy set the standard when he wrote the first version of ip, and he was trying to emulate the features provided by a Cisco router at the time.