Live data from Hacker News

Swapping GNU coreutils for uutils coreutils on Gentoo Linux

joshmcguigan.com

21–30 of 134 posts

Re: Swapping GNU coreutils for uutils coreutils on Gentoo Linux

#21
Two thoughts on the whole "alternate" thing:

1. When I first learned about the alternatives system, I initially assumed that it was in use for every single binary - that there was an alternatives selection to decide what provided /bin/ls, and one to choose /bin/sh, and one to determinue /bin/chmod, etc. (I mean, /bin/sh sometimes is depending on your distro and how they feel about bash/dash/ash but you get the idea.) And honestly I still kinda feel like that's a good idea, though it leans toward redoing how packages work in a way that reminds me of nix and Gobo; /bin becomes just a symlink farm pointing into per-package bin directories.

2. Although this kind of bulk-replacement is a good initial test, I feel like letting packages directly depend on GNU coreutils or not is maybe a good way to go - you can test packages one by one and switch them to point to a virtual package as they're validated, thereby letting the package manager properly manage dependencies by giving it enough information to asses the situation.

Re: Swapping GNU coreutils for uutils coreutils on Gentoo Linux

#22

Earlier quoted context omitted.

That would imply that I've drank the Fedora/FDO/systemd Kool-Aid and trashed a perfectly working FHS. I have no interest in wasting the time trying to conform to their nonsense.

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 correctly after the change (see lack of testing).

I'm sure there's more but I'm not their personal testing infrastructure. 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".

Re: Swapping GNU coreutils for uutils coreutils on Gentoo Linux

#23
post #10

Earlier quoted context omitted.

Yes, and undoing this means it's no longer UNIX as it will no longer run on that PDP-11! (Unless you can afford a bigger disk I guess.)

If "being UNIX" hinges on the fucking filesystem structure I honestly am fine with it "not being UNIX"

It does, however it is actually less strict than I had in mind,

https://pubs.opengroup.org/onlinepubs/9699919799/

Re: Swapping GNU coreutils for uutils coreutils on Gentoo Linux

#24

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.

The GNU effort was driven by dissatisfaction with the license on the prior implementations, and was probably considered disrespectful by the copyright holders of those too...

Re: Swapping GNU coreutils for uutils coreutils on Gentoo Linux

#25

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

IOW, nobody should tell anyone else they shouldn't exist.

Re: Swapping GNU coreutils for uutils coreutils on Gentoo Linux

#26
post #10
post #6

Earlier quoted context omitted.

The original history behind a lot of original UNIX directory structure is engineers running out of disk space on a PDP-11 50 years ago and shuffling things around to keep the system operating. Other reasoning has been piled on top over the years.

Yes, and undoing this means it's no longer UNIX as it will no longer run on that PDP-11! (Unless you can afford a bigger disk I guess.)

A lot of thoughts [1] have been put into the usr merge, and compatibility with unix is one of them, and one other unix that has done this merge is Solaris, so Linux distros doing the merge are not even that special.

(note: it's not about merging /bin and /sbin)

[1] https://systemd.io/THE_CASE_FOR_THE_USR_MERGE/

Re: Swapping GNU coreutils for uutils coreutils on Gentoo Linux

#27
post #25

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…

I don't think there should be a monopoly, but I do wish the alternatives would be copyleft too.

Re: Swapping GNU coreutils for uutils coreutils on Gentoo Linux

#28

Earlier quoted context omitted.

That would imply that I've drank the Fedora/FDO/systemd Kool-Aid and trashed a perfectly working FHS. I have no interest in wasting the time trying to conform to their nonsense.

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 also stored in /usr/bin and not /bin.

Re: Swapping GNU coreutils for uutils coreutils on Gentoo Linux

#29

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.

GNU coreutils is to a very large extent nearly exactly copied functionality from other unix distributions (unix system v, BSDs). It's not like GNU is getting ripped off here.

GNU coreutils is a clone, nobody's feelings should be hurt if somebody else makes another clone of the same functionality. (license zealots will have hurt feelings but for different reasons)

Re: Swapping GNU coreutils for uutils coreutils on Gentoo Linux

#30

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…

Are there actually plans to remove the symlink? My impression was that it’s intended to stay around pretty much forever.
Post reply on HN