Rust-Written Coreutils 0.0.25 With Improved GNU Compatibility

[Quackdoc]

You have fd-find which is more featureful and faster.
It is not directly compatible with find-utils though.

while true, (I do use it on my desktop), I find immense value in having a single binary tool that works pretty much everywhere

[chocolate]

i believe there is a speed increase, the main benefit is memory safety however (less bugs), and also less bloat (gnu software is infamously spaghetti code)

Infamously as in "directed by Quentin Inventino"??

[q66_]

yeah ok, but how many people use it? the 10000 commits are relative to the cports, and the rest of the base system? I don't even see Linux news websites talking about it anymore. Also are they not alpha quality anymore? Because this is the important part at the end of the day!

you seem confused and mixing things up

what linux news sites write about is ultimately meaningless, because that's their choice and indicates nothing about the project

how many people use it is impossible to tell because there are no statistics (that would require telemetry), and as far as being alpha quality goes, that's something the project declared itself (and therefore subject to personal quality standards) and i don't see how it has anything to do with success, considering development does not happen overnight and literally any project has to go through it

it sounds like your definition of success is "grows debian-sized repositories from thin air" and well, if that's the case i don't think any answer will satisfy you anyway

[elatllat]

...how many people use it is impossible to tell because there are no statistics (that would require telemetry)...

Or just a look at repo web server logs.

[cb88]

Thats a downside. It just means that overall it will get less quality contributions.

You mean the kind of quality contributions that have resulted in GNU coreutills being a bug ridden spaghetti storm?

I mean its already proven that GPL blocks many corporate contributions.... because its a viral license especially in version 3, Linux itself is an anomaly because of the critical mass it reached that something like coreutils is never going to have. MIT or something like 0BSD are ideal for coreutils. Rust itself does the gatekeeping on code quality in contributions. And if the code quality is bad, a minimalist license lets you do whatever you want to make it suit your purpose, such licenses are about maximum DEVELOPER freedom.

I mean if someone forks it and adds 50 commands so what, uutils is already free and will continue forward on its own despite that. What most developers find is that the litigation to enforce GPL is worse than just ignoring the problem and getting along with the people that DO want to code contribute and collarborate.

[chocolate]

You mean the kind of quality contributions that have resulted in GNU coreutills being a bug ridden spaghetti storm?

This thread is crazy. Now I really want to know where you folks are pulling this from. I sincerely want to understand whether this argument is FUD from script kiddies or if it's grounded in reality even remotely. If I search for a few keywords on this matter via search engine(s), particularly referring to code quality, I get the opposite, or nothing at all. So please, illuminate me, maybe the search engines are biased in my case.
Heck, judging by my own expertise, I only see signs of a project in perfect health, starting from the GNU website page with many useful links, to the code I see with my own eyes by scrolling here and there when I open random source code files (link to GH mirror so you can do this yourself without cloning), to a third party extensively exploring the design of each utility. Sure, you make take grief with code style, or the fact that it's not 100% consistent across files, or that it's not as paranoid as embedded C for spacecraft (I've seen way worse in that field), but it's perfectly adequate to me as far as "desktop C" goes.
No offense, but you sound like a BSD lunatic from 2008 lamenting how GNU is true to its name, when in reality it was just gratuitous slander motivated by ideological differences around software licenses, and your stance on the GPL reflects that. Please don't take this personally. Have a good day.

[ayumu]

How is that a benefit? It's the major downside.

What downside? You can continue to use the GPL'd coreutils for as long as you wish.

It is an upside because there's the option of using a MIT licensed implementation, now. And some of us prefer the MIT license.

Which, by the way, is GPL compatible.

[imaami]

Rust itself does the gatekeeping on code quality in contributions.

Since you're the one who brought up spaghetti, please explain which compiler features automatically sweeten the cursed fruits of some tortured soul whose code can make your eyes bleed.

No, you can't cure stupid with static analysis.

You do know Rust is also a Turing-complete language, don't you? It's not magically impervious to an infinite range of human failure. Memory safety features alone do fuck all for "code quality".

a minimalist license lets you do whatever you want to make it suit your purpose, such licenses are about maximum DEVELOPER freedom.

This is ass-backwards talk. A minimalist license maximizes corporate freedom to profit off of source code. Regardless of your personal values, it is objectively false to turn the question of developer freedom on its head.

It is corporations who have always described GPL as "viral".

GPL and similar licenses prevent companies from leveraging free software for profit without giving back to the developer community.

I mean if someone forks it and adds 50 commands so what, uutils is already free and will continue forward on its own despite that.

Obvious and irrelevant. Any of the licenses mentioned allow forking, it's the lowest common denominator. The question of developer freedom encompasses more that that.

A minimalist license allows a corporation to fork a project, modify it, and never release the changes as source code. This includes adding vendor lock-in features that effectively render the open source options incompatible.

If a company has monopoly position, it can attempt to capture a widely used open source tool, file format, or protocol by forking it, gaining market share, and finally replacing the free de facto standard with their preferred lock-in derivative.

Embrace, extend, extinguish.

Don't buy the corporate mantra of "virality". Developers aren't the target host.

What most developers find

[citation needed]

the litigation to enforce GPL is worse than just ignoring the problem and getting along with the people that DO want to code contribute and collarborate.

Well there's your problem - you're confusing developers and corporations. The ones who might face litigation are companies that bake GPL-licensed code into their software and keep the fact (and their derivative work) a secret. That's called breaking the terms of a license agreement, a.k.a. being a parasite that profits off of other people's work against their explicit terms.

Again: developers don't face litigation for forking. Businesses that break the law do.