31–40 of 134 posts
It’s a shame to see all this effort going toward replacing core GPL licensed utilities with permissive ones. It seems like a particularly common thing in the Rust community. It feels disrespectful of the intentions of the work that went into the tools that are being cloned.
Earlier quoted context omitted.
Okay; what problems would you expect to hit if you used a system where they were merged? (My best thought so far is having multiple hosts sharing a single /usr over NFS while having per-host root filesystems, but I've never actually seen that done. I've also thought about building a distro that kept its initramfs as root and just mounted everything else into it, but that's even further off the beaten path.)
I can think of a few off the top of my head... - broken shell scripts that are hardcoded to "/bin/bash" rather than "/usr/bin/env bash" (this might work for a while, but what happens when they remove the symlink?) - broken compiles because "/lib" and "/lib64" no longer exist, because of the lack of testing prior to making the change on behalf of users - broken boots because initramfs (dracut/etc) isn't structured cor…
Earlier quoted context omitted.
I can think of a few off the top of my head... - broken shell scripts that are hardcoded to "/bin/bash" rather than "/usr/bin/env bash" (this might work for a while, but what happens when they remove the symlink?) - broken compiles because "/lib" and "/lib64" no longer exist, because of the lack of testing prior to making the change on behalf of users - broken boots because initramfs (dracut/etc) isn't structured cor…
Are there actually plans to remove the symlink? My impression was that it’s intended to stay around pretty much forever.
I wouldn't be surprised if they remove the symlink in a year because they consider it useless cruft.
Earlier quoted context omitted.
Are there actually plans to remove the symlink? My impression was that it’s intended to stay around pretty much forever.
The wiki doesn't say, and the mailing list reader hasn't worked since March 2023. (Yes I know MARC exists, but their interface is terrible) I wouldn't be surprised if they remove the symlink in a year because they consider it useless cruft.
It’s a shame to see all this effort going toward replacing core GPL licensed utilities with permissive ones. It seems like a particularly common thing in the Rust community. It feels disrespectful of the intentions of the work that went into the tools that are being cloned.
You could say the same thing about LLVM/Clang. Apple and Google only cooperated on that because they really really dont want a restrictive licence like the GPL. But then again, after a while, Clang is a nice alternative... Which makes me think: Why exactly are you indirectly lobbying for a monopoly? Just because there is a GNU version of something can not mean there shouldnt be any other version. It just can not mean…
Earlier quoted context omitted.
Okay; what problems would you expect to hit if you used a system where they were merged? (My best thought so far is having multiple hosts sharing a single /usr over NFS while having per-host root filesystems, but I've never actually seen that done. I've also thought about building a distro that kept its initramfs as root and just mounted everything else into it, but that's even further off the beaten path.)
I can think of a few off the top of my head... - broken shell scripts that are hardcoded to "/bin/bash" rather than "/usr/bin/env bash" (this might work for a while, but what happens when they remove the symlink?) - broken compiles because "/lib" and "/lib64" no longer exist, because of the lack of testing prior to making the change on behalf of users - broken boots because initramfs (dracut/etc) isn't structured cor…
As to testing... yeah obviously this stuff should be thoroughly tested long before it hits users, but I was rather under the impression that it was tested extensively before getting to users. Again, if you've seen actual problems that made it past testing, feel free to point them out since that would greatly strengthen your criticism.
> I just want an OS that works without having to fight someone every 3 weeks because "everyone else is doing it, so we should too".
Are you super committed to Linux OSs? Because you might find the one of the BSDs or illumos more comfortable. Not that they never change (er, well, illumos might not), but at least it's not because of what anyone else does.
(And as an aside: Don't take this as an endorsement of merged usr; I actually prefer a separate /usr myself because I lean towards thinking that it's reasonable to have a read-only root and a rw /usr, or /usr on shared NFS, or any number of other "weird" systems... but I also culturally favor the BSDs, so take that as you will. I just think that if we're going to find fault, we should have the best evidence/arguments possible.)
It’s a shame to see all this effort going toward replacing core GPL licensed utilities with permissive ones. It seems like a particularly common thing in the Rust community. It feels disrespectful of the intentions of the work that went into the tools that are being cloned.
GPL only took off, because Berkeley was rather busy with AT&T, and GNU was there for Linus to reach for. It isn't only Rust, it is any language that favours static linking by default.
Earlier quoted context omitted.
I can think of a few off the top of my head... - broken shell scripts that are hardcoded to "/bin/bash" rather than "/usr/bin/env bash" (this might work for a while, but what happens when they remove the symlink?) - broken compiles because "/lib" and "/lib64" no longer exist, because of the lack of testing prior to making the change on behalf of users - broken boots because initramfs (dracut/etc) isn't structured cor…
I would think your first couple points are actually better on a merged system - if /bin==/usr/bin and /lib==/lib64==/usr/lib then scripts can use either /bin/bash or /usr/bin/bash and it'll work (and ditto for libraries). Granted, removing those symlinks would then be painful, but I haven't heard of that being proposed; if it has been and I'm just out of the loop then yeah that'd make me nervous. (Though in fairness,…
You know, I would... but Linux has already won the battle... FBSD and Illumos corporate support is already jumping ship to Linux.
Earlier quoted context omitted.
Okay; what problems would you expect to hit if you used a system where they were merged? (My best thought so far is having multiple hosts sharing a single /usr over NFS while having per-host root filesystems, but I've never actually seen that done. I've also thought about building a distro that kept its initramfs as root and just mounted everything else into it, but that's even further off the beaten path.)
> My best thought so far is having multiple hosts sharing a single /usr over NFS while having per-host root filesystems HPC systems already have better systems for this sort of thing, e.g. Lmod which is modular. I don’t think it’s a great idea to have /usr itself on NFS, given that things like /usr/bin/env is in most script shebangs and IMO should be stored locally. On some systems, many potential login shells are al…
Though part of me agrees that there are reliability concerns to keep in mind, the other part of me still thinks root on NFS is normal, at which point /usr seems rather minor in comparison:) I suspect some of this is cultural or a result of what you're used to.