It feels disrespectful of the intentions of the work that went into the tools that are being cloned.
Whatever the masses do can always have impact on what you can do, or are forced to do. For example quitting your job, because you want to use the libre tool, when your employer tries to force you to use the proprietary tool. "Why can't you be a good employee like eeeeveryone else?"
Only the original as delivered by the original dev-team. The derivatives can be, and often are, closed off. That's the opposite of "free and open source".
very freedom
C'mon... It improves memory safety!
I agree with GPL being a way to protect the investment in the commons so it remains "freer" than with MIT/BSD licensed code. But in the cloud platform world this is has show to be not so helpful (hence we need the AGPL). Both GPL and AGPL are (AGPL more so) shunned by big biz: this is a blessing (fuck 'm) and a curse (they have much money to invest).
All open source releases are extending the commons (freely available to everyone), so if MIT/BSD code is released I still cheer for that (even if it clones GPL code).
A bit of a distinction, there.
The goal of the GNU effort was to empower users, hence the pro-user license.
The goal of the Rust coreutils cloning is to spread fast, hence the pro-corporate license.
Whether you prefer GPL or not, attempting to displace a pro-user tool with a pro-corporate tool is more than simply "disrespectful".
I really appreciate the permissive licensing in the Rust ecosystem as it greatly eases the task of writing code for pay. While the finished product may have a commercial license, I often find bits to improve in the permissively licensed parts and contribute them back upstream. Customers seem perfectly fine with this arrangement. Tough to do the same with the GPL - even LGPL'd libraries complicate contract terms and distribution a little by comparison.
With the huge productivity increase LLMs provide for writing code, it seems to me that we're rapidly entering an era in which libraries and tools for everything are available in every language, and under every license, which seems like a good thing. It is nice not to feel limited by one's language choice or work environment.
I did a fair amount of work on the RepRap project, which is mostly GPL'd, and that worked out OK, but there have definitely been opportunities lost over the last 15 years or so due to license constraints which more permissive licenses would have allowed. Finding a balance which helps developers put food on the table while writing open source code also seems like a good thing.
The GPL is great. I think there are important projects which really benefit from the strong incentive it provides to share. But there's definitely room for more than one way to do things.
Ultimately, Everything Is A Remix (https://www.youtube.com/watch?v=X9RYuvPCQUA)
It isn't only Rust, it is any language that favours static linking by default.
Look at Mac OS. That's what happens when freedoms don't have to be honoured. Corporations have spent a lot of effort trying to work around the GPL, whether it was via network services or something else.
If everyone had gone down the BSD route we would have been there, just a lot quicker. This is why I would never licence any of my work as anything other than GPL or AGPL (dual so that people can pay to avoid GPL, but they still contribute financially).
This is all a team effort to make the world a better place and BSD is too idealistic.
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)
Coreutils may have started as a clone, but quickly became so much more. While the 'traditional' unix tools were pretty much frozen when it came to new features, GNU was experimenting and adding new features and trying to improve the UX (which not everybody approved of). There's a reason why the first thing many people would do on a new Unix install was to add GNU coreutils, and in fact many of the GNU features eventually made it back into the traditional tools.
So the real question is will uutils eventually reach a point where it is better/different enough that people will actively want to replace coreutils on their GNU systems, or will it remain 'just' a clone.
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.
There were things people wanted to do with a good C++ compiler, like output a high-quality parse tree (which is useful for all kinds of things), which would have been easy to add to gcc, but were explictly forbidden from being merged into gcc under any circumstances.
This was just in case some closed-source person used that parse tree for non-GPL purposes.
This is why the C++ LSP (language server protocol, used in various text editors) used by basically everyone is based on clang, and there still isn't a gcc-based one.
I just think that trying to make a permissive drop-in replacement for software that emphasises the very freedoms that have allowed the creation of the replacement in the first place is unfortunate and short-sighted. It’s a good thing that the authors have every right to do it all the same though.
I think systemd is a useful evolution in the problem of "Linux plumbing"
Even if it ends up being replaced by something else, for better or worse Lennart sat down and tried something. That's better than 99% of the systemd haters who sit and postulate on reddit and phoronix
Conversely replacing GPL tools with more permissively licensed ones just seems like the "time is a flat circle" idiom
We'll use our GPL'd systems to build BSD/MIT/Apache licensed ones where benevolent mega corporations "allow" our contributions. Until they don't
And then we'll begin the cycle all over again trying to liberate ourselves from corporate controlled software
> If the version you've created is considerably more useful than the original, then it's worth copylefting your work, for all the same reasons we normally recommend copyleft.
Wouldn't you consider this advice disrespectful to the original authors as well? The FSF is directly telling you to take the existing project, not even your own re-implementation, and take over and GPL it.
That's not the way to do it (in Gentoo). He should have added coreutils to /etc/portage/profile/package.provided. Portage would then assume the package is installed even if it's not. This is used to install self-built binaries or packages from other distributions instead of packages provided by portage.
https://wiki.gentoo.org/wiki//etc/portage/profile/package.pr...
I think I'd need to add `sys-apps/coreutils` to `package.provided`, then install uutils coreutils while telling Portage to ignore file collisions (because I'd be overwriting GNU coreutils binaries). However, that would have hidden the fact that I would have also been overwriting binaries from other packages (for example `hostname`, which is provided by `sys-apps/net-tools` in Gentoo).
I'm a fish-shell developer and I just dealt with a user that was getting bizarre test failures. Turns out the developers didn't account for basic things like the normalcy of `cat` having its output fd closed mid-stream (e.g. you are piping cat to something and that something exits before cat does) and their vesrion bails with an exception dumped to stderr instead of silently closing with a non-zero exit code.
uutils uses the coreutils test suite, so it makes sense to add a test case for that, which uutils will eventually get to. I'll do that now.
If you only read the comments, you think Gentoo was switching out core utils and doing it in the worst technical way possible.
Eventually it boiled down to today where we have the BSD's and Linux. Other than helping force compatibility with the BSD's, who else stands to benefit from breaking away from "GNU-isms"? MacOS?
I'm also sceptical to the whole idea. There are tons of more interesting problems to solve than replacing an stable solution with a new one just because you don't like GPL.
I agree it's not what I would spend my time on, but I guess some people found this problem more interesting than us. I don't see a problem with that. Security vulnerabilities in GNU coreutils are rare but they happen. Also this would make building and editing the tools more accessible.
I think the argument is usually memory safety rather than licensing.
This is after all cp and ls we are talking about. For me personally compatibility would be a much bigger issue
Problem #5 is not well explained: if /usr/bin and /usr/sbin are conflated, how could cowsay not find its templates? Paths relative to the two directories are the same. For example, if cowsay is looking for its templates in ../share/cows, such relative path points to the same destination no matter if the binary is in bin or sbin.
You are totally right on problems 1 and 2 being swapped.
For problem #5, you caught me taking too large a logical leap and making some assumptions there. Turns out the issue is just that cowsay special cases directories called `bin` (and thus treats directories called `sbin` differently)[0].
I just pushed an update to the post correcting both of these.
[0]: https://github.com/cowsay-org/cowsay/blob/d8c459357cc2047235...
Leaving the should uutils be used over coreutils debate aside, this was a fun read for me and the urge to install Gentoo one one of my many old Thinkpads is flaring up hard.
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.
Good work, Joshua Mcguigan!
What can go wrong ? /s
One tool to rule them all.
Okay but seriously - what would you expect to go wrong? Tools explicitly looking for and breaking on symlinks is a bug on their side; that's a perfectly reasonable approach to take.
I hope this isn't going to be the norm in the future, but Gentoo has been making my life difficult for years as it is... it's as if the developers don't test or use what they are forcing on everyone.
(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.)
The separate paths were originally done for reasons but since you can't install a mainstream distro with < 512MB RAM these days (not even Alpine) some of those reasons are moot.
Linux is becoming less and less like UNIX every day.
These reasons were not originally philosophical in nature: http://lists.busybox.net/pipermail/busybox/2010-December/074...
IMO, keeping /usr/bin and /usr/local/bin separate from /bin doesn’t serve any useful purpose except historical continuity. You can’t really get rid of those paths without breaking things (e.g. since /usr/bin/env is usually hardcoded in shebangs), but symlinking them together is a practical way of effectively merging them.
The `local` does. It is were
I use it all the time for custom scripts/programs I don't want the package manager to interfere with.
https://unix.stackexchange.com/questions/4186/what-is-usr-lo...
