4 ms·

This is Linux's legacy. Rejecting already solved problems only to try reinvent the wheel their way and often their wheel is broken and horribly engineered if en

by X86BSD 10y ago

This is Linux's legacy. Rejecting already solved problems only to try reinvent the wheel their way and often their wheel is broken and horribly engineered if engineered at all. See btrfs v zfs, kqueue vs their current poll of the month method, dtrace vs system tap, the list goes on a mile long. It's so frustrating to watch this. To see all these projects being developed on Linux where it's easier for others to simply reimplement the idea from scratch than try and remove all the Linux only code from them. The Linux world only thinks about itself. In a spectacularly selfish way.

technofiend 10y ago
This is why you need to update the phrase "GNU's not UNIX" to "Linux is not UNIX." I use systemd and it works fine but it's a great example of a complete departure from the idea of small single-task tools.
- Grishnakh 10y ago
  >..."Linux is not UNIX." I use systemd and it works fine but it's a great example of a complete departure from the idea of small single-task tools. And how does this approach compare to other UNIXes? And I don't mean UNIXes from the 1970s, I mean ones which are currently in use: FreeBSD, OpenBSD, Solaris, MacOSX. Last I heard, they all had roughly equivalent init systems to systemd.
  - digi_owl 10y ago
    Solaris and MacOS perhaps, if we are talking strict init. but both of the BSDs use BSD init. There is a push by Jordan Hubbard to get FreeBSD to adopt Launchd (the MacOS init) but so far he has been rebuffed and has instead set out to fork FreeBSD into NextBSD. Frankly this is what should have happened with the likes of Debian regarding systemd as well. A parallel release offering systemd as the default, alongside sysv. Then it would be up to the admins to pick, rather than have to apply contortions during or right after install to switch from systemd to sysv. Instead Debian adopted systemd, and we got Devuan as a sysv fork...
  - technofiend 10y ago
    Well I can't speak to other systemd competitors but BSD and System V's scripts never had the concept of bundling in firewall configuration, cgroup config, mount points, etc into PID 1.
rleigh 10y ago
I spent a couple of decades being a die hard Linux fanatic, and contributor to many parts. The amount of work being done is incredible. But I'd have to say that I've become over time increasingly annoyed by the vast duplication of effort, pointless wheel reinvention and pointless scrapping of perfectly good code just because someone wanted to rewrite it rather than carefully refactor it. Looking at the long term effects over the last 20 years, a lot of that work was utterly pointless and detrimental; my patches to fix the GNOME canvas were ignored in the bug tracker for over a decade before it was closed--meanwhile they wrote in parallel over six replacements, all of which are now dead and none of which improved the canonical (and now also dead) implementation! All the power management and hardware abstraction stuff has gone through multiple rewrites from scratch, and with little thought to backward compatibility. This is not to denigrate the effort people put in, but effort needs to be directed effectively or else it is ultimately wasted. The success of Linux has lead to a disturbing amount of NIH attitudes--we're so big we don't need to care about compatibility and interoperability--foolishly forgetting that these things are what caused the original adoption of Linux, being compatible with everything under the sun was it's big selling point. In the case of Btrfs it's a laudable effort, but has yet to approach production readiness in an awfully long time. Even if the licences are incompatible, the on-disk structures of ZFS could have been used to create a compatible implementation. So I'm afraid I'm increasingly using other systems such as FreeBSD (with ZFS) and leaving Linux behind somewhat. Ultimately open systems, open standards and free software and software freedom are more important than a single implementation.
emmelaich 10y ago
Linux's 'legacy' is a policy of accepting code before it is known to be perfect. I don't know anyone who runs BTRFS and I certainly would not do so myself. Getting accepted as part of the kernel code is not an imprimatur of some sort. I'd much rather this than the *BSD policies. Oh and talking about FreeBSD, it's hardly bug free. Look at these Golang issues and tell me it doesn't indicate something wrong in the FreeBSD kernel threads/fork/exec code. 1. https://golang.org/issue/16136 https://golang.org/issue/16136 2. https://golang.org/issue/15658 https://golang.org/issue/15658 3. https://golang.org/issue/16396 https://golang.org/issue/16396
- emmelaich 10y ago
  ... and even if I did use BTRFS, I wouldn't use raid5/6. I'd never use raid5/6 on anything. Hardware is cheap.
- X86BSD 10y ago
  I'm not sure it indicates anything. They are all incredibly vague and no one seems to have any idea what's going on.
kbenson 10y ago
Well, I think the problem is somewhat more subtle, but to an end effect that's the same. That is, it's useful to have people trying new things, and even throwing shit at the wall and seeing what sticks. Interesting new ideas come out of that. The problem is that you don't want that to necessarily be the de facto strategy for your accepted solutions to problems, and definitely not how a major player in your ecosystem routinely progresses. If Linux was a research experiment with exposure but little use compared to the other Unix systems, we would probably all look at it much more favorably, not because they are doing things right, but because they are willing to try crazy shit that we would all get to see the post-mortems for. The problem is that Linux is not some semi-obscure OS, so instead of these experiments being interesting reading for the weekend, we're often forced to become users of them, whether we like to or not.

by X86BSD 10y ago

technofiend 10y ago

This is why you need to update the phrase "GNU's not UNIX" to "Linux is not UNIX." I use systemd and it works fine but it's a great example of a complete departure from the idea of small single-task tools.

Grishnakh 10y ago
>..."Linux is not UNIX." I use systemd and it works fine but it's a great example of a complete departure from the idea of small single-task tools. And how does this approach compare to other UNIXes? And I don't mean UNIXes from the 1970s, I mean ones which are currently in use: FreeBSD, OpenBSD, Solaris, MacOSX. Last I heard, they all had roughly equivalent init systems to systemd.
- digi_owl 10y ago
  Solaris and MacOS perhaps, if we are talking strict init. but both of the BSDs use BSD init. There is a push by Jordan Hubbard to get FreeBSD to adopt Launchd (the MacOS init) but so far he has been rebuffed and has instead set out to fork FreeBSD into NextBSD. Frankly this is what should have happened with the likes of Debian regarding systemd as well. A parallel release offering systemd as the default, alongside sysv. Then it would be up to the admins to pick, rather than have to apply contortions during or right after install to switch from systemd to sysv. Instead Debian adopted systemd, and we got Devuan as a sysv fork...
- technofiend 10y ago
  Well I can't speak to other systemd competitors but BSD and System V's scripts never had the concept of bundling in firewall configuration, cgroup config, mount points, etc into PID 1.

rleigh 10y ago

I spent a couple of decades being a die hard Linux fanatic, and contributor to many parts. The amount of work being done is incredible. But I'd have to say that I've become over time increasingly annoyed by the vast duplication of effort, pointless wheel reinvention and pointless scrapping of perfectly good code just because someone wanted to rewrite it rather than carefully refactor it. Looking at the long term effects over the last 20 years, a lot of that work was utterly pointless and detrimental; my patches to fix the GNOME canvas were ignored in the bug tracker for over a decade before it was closed--meanwhile they wrote in parallel over six replacements, all of which are now dead and none of which improved the canonical (and now also dead) implementation! All the power management and hardware abstraction stuff has gone through multiple rewrites from scratch, and with little thought to backward compatibility. This is not to denigrate the effort people put in, but effort needs to be directed effectively or else it is ultimately wasted. The success of Linux has lead to a disturbing amount of NIH attitudes--we're so big we don't need to care about compatibility and interoperability--foolishly forgetting that these things are what caused the original adoption of Linux, being compatible with everything under the sun was it's big selling point. In the case of Btrfs it's a laudable effort, but has yet to approach production readiness in an awfully long time. Even if the licences are incompatible, the on-disk structures of ZFS could have been used to create a compatible implementation. So I'm afraid I'm increasingly using other systems such as FreeBSD (with ZFS) and leaving Linux behind somewhat. Ultimately open systems, open standards and free software and software freedom are more important than a single implementation.

emmelaich 10y ago

Linux's 'legacy' is a policy of accepting code before it is known to be perfect. I don't know anyone who runs BTRFS and I certainly would not do so myself. Getting accepted as part of the kernel code is not an imprimatur of some sort. I'd much rather this than the *BSD policies. Oh and talking about FreeBSD, it's hardly bug free. Look at these Golang issues and tell me it doesn't indicate something wrong in the FreeBSD kernel threads/fork/exec code. 1. https://golang.org/issue/16136 https://golang.org/issue/16136 2. https://golang.org/issue/15658 https://golang.org/issue/15658 3. https://golang.org/issue/16396 https://golang.org/issue/16396

emmelaich 10y ago
... and even if I did use BTRFS, I wouldn't use raid5/6. I'd never use raid5/6 on anything. Hardware is cheap.
X86BSD 10y ago
I'm not sure it indicates anything. They are all incredibly vague and no one seems to have any idea what's going on.

kbenson 10y ago

Well, I think the problem is somewhat more subtle, but to an end effect that's the same. That is, it's useful to have people trying new things, and even throwing shit at the wall and seeing what sticks. Interesting new ideas come out of that. The problem is that you don't want that to necessarily be the de facto strategy for your accepted solutions to problems, and definitely not how a major player in your ecosystem routinely progresses. If Linux was a research experiment with exposure but little use compared to the other Unix systems, we would probably all look at it much more favorably, not because they are doing things right, but because they are willing to try crazy shit that we would all get to see the post-mortems for. The problem is that Linux is not some semi-obscure OS, so instead of these experiments being interesting reading for the weekend, we're often forced to become users of them, whether we like to or not.