Bsdutils: Alternative to GNU coreutils using software from FreeBSD
github.com
github.com
I am very happy about this. This means that there is not much energy put into implementing new coreutils features or fixing bugs. I think this is good. This means they are more or less finished. Mature. Software that is done and usable. That is something outstanding.
This is an example of software that does not need to be in an never-ending flow of changes, not because it is abandoned, but because it is finished. I think we need more of that.
Doesn't GNU utils have more features?
GNU project code is infamously cluttered and hard to grok (mostly since it's a pretty old codebase and GNU has always favored having too many chefs in the kitchen over fewer, but competent, chefs).
FreeBSD code is also usually much more stable than the Linux counterparts; tends to be less buggy from my experience at least.
GNU also has gotten in the habit over the years of randomly shifting flags around for no real reason other than to make sure that they stay as the coreutils. They have the effective monopoly on usage (I want to say that BusyBox is the only realistic other competition due to how frequently it's used on smaller resource devices), so that way other implementers are forced to adapt. There's also have a tedency of making their software have really weird Unix pipe interop. The most infamous example I can think of is that there's one GNU coreutils command with the "human-readable" flag, which doesn't do what it usually does (adjust the output of commands displaying filesizes and the like to kb/mb/gb) but instead reformats the output to be usable in a different GNU command which also has a "human-readable" flag that works as expected.
There's a couple of reasons to not want to use the GNU coreutils specifically at least.
I was under the impression that it was a result of 1. supporting a terrifying spread of platforms - by the time the code handles the quirks of AIX, IRIX, Minix, Solaris, all the BSDs, and oh yeah also Linux, yes it has a rather lot of clutter, and 2. specifically implementing things in a different way than commercial UNIX™ so nobody could accuse them of copyright violation.
Do you have examples of this?
Sounds like they've been studying the works of The Enemy ;)
Poor choice of name though. Debian has a bsdutils package since forever [1].
No copy-left license?
Compatibility on Linux with BSD-like operating systems such as FreeBSD, MacOS?
To annoy Richard Stallman?
Are you planning to make proprietary changes to `cat` you are unwilling to share?
> Compatibility ...
GNU coreutils work fine on all the mentioned plattforms
> To annoy Richard Stallman?
Not really sure if pettiness would be sufficient motivation for me, but then again, I'm writing this response...
Presenting to you Panthera(TM) - the Enterprise Ready cat that you were waiting for!
* LDAP support
* Office 365 integration
* SAP integration
* GDPR compliant outputs
* 24/7 SLA
Plenty of GPL software is available on osx.
The decision is also affected by the Tivoization clause introduced to GPL v3.
> If MacOS included GPLv3 software, Apple wouldn't be able to pre-install it unless they provided all users with signing keys to install their own modified versions of the GPLv3 software on-target. Check out the GPLv3's "User Product" and "Installation Information" sections for more details - they're written in plain English, and are pretty clear. [2]
[0]: https://meta.ath0.com/2012/02/05/apples-great-gpl-purge/
But Apple holds lots of patents[1], and while it's hard for me to imagine Apple enforcing patents against users of bash, I can easily imagine Apple lawyers making a strong enough case to management that the potential value of all patent licenses that would be implicitly granted by GPL 3 was likely to exceed the cost of feature-freezing or replacing affected macOS components that they would have agreed to a blanket ban.
Note that I'm not defending this decision: for the record, I detest software patents, dislike tivoization, and the only problem I have with GPL 3 is when companies that might otherwise contribute to GPL 3 projects are uncomfortable with it. Which is unfortunate, but certainly not a flaw in the license itself.
[1] https://patents.google.com/?assignee=%22Apple+Inc%22&oq=assi...
And even then companies are famous for leeching on open source projects, with gpl you at least have some hope of companies leaving you alone or giving back something.
How is it "leeching" if I deliberately release my source code under a BSD license because I don't care if other people use it or not? It can't be "leeching" if I don't care about their contributions either. The only other scenario that would apply is if I wanted to be paid for my work... in which case neither a BSD-like license, nor the GPL, would be adequate.
This is the problem I have with GPL partisans: They refuse to accept that projects can be completed, or that anyone can have any interests other than GPL-compatible ones.
Monetization in FOSS is a systemic issue, with few exceptions, but even then you are far more likely that companies won't want to risk leeching with a GPL like license than a permissive one because of the code sharing requirement, which MIT/BSD at best only incentives as goodwill because of complexity maintaining the project they rely on.
I also find it funny you create a strawman, i never stated any adoration of GPL.
Especially when you make clear the option to dual license and let them use it under a MIT/BSD style license, or something custom, if they pay you an appropriate amount.
What downfall, exactly? If I want to get paid, the GPL doesn't help me with that. If I don't care about outside contributions, the GPL doesn't provide any advantage. Insofar as I have written something that is complete in itself then a BSD license makes perfect sense.
Meanwhile regular commits from / sponsored by Netflix, Dell-EMC Isilon, Juniper, Mellanox, Intel, Amazon and Microsoft (for network drivers), etc.
An absolute great OS?
>hardly any upstream contribution (Apple, Sony, etc)
Sony paid FreeBSD dev's, and the Apple kernel and coreutils are opensource, it's just they have not done anything FreeBSD is interested in, not like for example Netflix with in-kernel tls.
>At this rate BSDs will be deader than dead within a few years.
Yes yes you said that already 20 years ago, it's probably time to overthink it.
[1] https://github.com/sagemathinc/cowasm/tree/main/core/coreuti... [2] https://cowasm.sh/
Your point about "compatible" is well made. I should have been clearer.
Wasn't gentoo born as Linux userspace on BSD kernel at one point?
== Example #1:
$ hyperfine -r 10 \ "target/release/coreutils sort -R shakespeare.txt > shakespeare.txt.rand; \ target/release/coreutils sort shakespeare.txt.rand > /dev/null" \ "sort -R shakespeare.txt > shakespeare.txt.rand; \ sort shakespeare.txt > /dev/null" é [...] Summary 'target/release/coreutils sort -R shakespeare.txt > shakespeare.txt.rand; target/release/coreutils sort shakespeare.txt.rand > /dev/null' ran 4.63 ± 0.19 times faster than 'sort -R shakespeare.txt > shakespeare.txt.rand; sort shakespeare.txt > /dev/null'
To be fair, we can be slower too
Example #3:
$ hyperfine "seq 18446744073708551615 18446744073709551615 | factor" \ "./target/release/coreutils seq 18446744073708551615 18446744073709551615| ./target/release/coreutils factor" [...] 'seq 18446744073708551615 18446744073709551615 | factor' ran 5.08 ± 0.01 times faster than './target/release/coreutils seq 18446744073708551615 18446
===
Redox-OS is rewriting the BSD coreutils in Rust for their own OS. https://github.com/redox-os/coreutils
I wonder what the most efficient and usable alternative operating system tradeoff choice tradeoff would be, perhaps mesalock (a linux with userspace tools compiled with rust)
syllable, haiku, redox, menuet64/kolibri, serenity, icaros desktop, postmarketos, drauger, mesalock
MIT license
How is letting me know that apple can use it without contributing back going to affect my decision on which coreutil to use?
Apple using those utilities could be a good thing. I've used MS PowerShell and WSL a bit, and their implementations of common CLI software is sometimes incompatible. To work around the incompatibilities you end up using proprietary features or doing something inferior. I would be better if they just dropped in the standard utilities. OTOH I understand the fear that they may provide useful proprietary extensions because of an MIT license.
Example, their version of ssh does not allow a script to hand it a password, hence my script was changed to print out "hey, type this password 'blah'" and required user interaction in the middle of an otherwise totally automated process.
Every OS should use the standard (GNU) utilities, or at least a set that aims for complete compatibility (Rust versions).
Not sure which ssh you're referring to but openssh doesn't allow it either. There are several hacks to script a ssh login with password.
Are you implying that Microsoft would use the common CLI software interfaces if GNU coreutils weren't GPL? Because I deeply believe they wouldn't. Embrace, extend, extinguish.
WSL (v2) is just a fancy wrapper around a Linux VM though, so the tools you get there are from the distro, not Windows.
Maybe, and maybe not. I was specifically asking why should I worry with apple's licensing considerations in my choice of tools to use.
For apple GPL license is a negative thing, they might go for a subpar solution just to avoid it. But for me? As a user, MIT or GPL license changes nothing for me.
I like the idea of setting some variable somewhere, and the Rust Coreutils output JSON, and we can use 'select' and 'where' rather than shaky scraping libraries.
20 years again people wanted rewrite stuff written in C/C++ in Java.
Now people wanted to rewrite stuff written in C/C++/Java in Rust.
Meanwhile core infrastructure of humanity still runs on COBOL, C, C++, Java in that order.
20 years from now people ask AI to rewrite all stuff written in C/C++/Java/Rust and it picks ADA SPARK as implementation language.
Sometimes being slow and careful is wise. Think of XML, hard to read and hard to parse. And an implementation language with broad support and reliability is a good thing for projects which should remain for decades.
There are projects that aim for a better user experience, with better command line interface, defaults, performance and UI. These are of course breaking changes and the programs can’t be used as drop in replacements. Some examples are
- ls => exa (https://github.com/ogham/exa)
- grep => ripgrep (https://github.com/BurntSushi/ripgrep)
- cat => bat (https://github.com/sharkdp/bat)
- tree => broot (https://github.com/Canop/broot)
The person you’re replying to was speaking of a different project - uutils (https://github.com/uutils/coreutils). These are drop in replacements with identical interfaces (modulo bugs).