whoever doing this has some serious time wasting issue. Check the previous project https://news.ycombinator.com/item?id=26303996
Says the guy who writtes nonsense on HN....bravo.
Bsdutils: Alternative to GNU coreutils using software from FreeBSD
51–60 of 85 posts
Re: Bsdutils: Alternative to GNU coreutils using software from FreeBSD
#52Earlier quoted context omitted.
> 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?
>> 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 t…
> 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.
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.
Re: Bsdutils: Alternative to GNU coreutils using software from FreeBSD
#53What would be an advantage of switching from GNU coreutils to BSD coreutils? Doesn't GNU utils have more features?
Stability, readable code and unchanging flags. 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…
> 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.
Do you have examples of this?
Re: Bsdutils: Alternative to GNU coreutils using software from FreeBSD
#54Re: Bsdutils: Alternative to GNU coreutils using software from FreeBSD
#55Earlier quoted context omitted.
> 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?
>> 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 t…
> Apple using those utilities could be a good thing.
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.
Re: Bsdutils: Alternative to GNU coreutils using software from FreeBSD
#56Re: Bsdutils: Alternative to GNU coreutils using software from FreeBSD
#57Earlier quoted context omitted.
But BSD devs have their own argument https://docs.freebsd.org/en/articles/bsdl-gpl/
Yeah. Just look what they got from that. Big corps using their work with hardly any upstream contribution (Apple, Sony, etc). At this rate BSDs will be deader than dead within a few years.
>Yeah. Just look what they got from that.
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.
Re: Bsdutils: Alternative to GNU coreutils using software from FreeBSD
#58Earlier quoted context omitted.
GPL v3 is unsable for embedded/locked hardware, e.g. Macbook, Android phones. That's why Mac OS and Android dodged GPL v3 software.
How so? If Apple chose to distribute GNU cat, they'd need to release any modifications to cat under the GPL but the license's vitality would not "infect" the rest of OSX. Plenty of GPL software is available on osx.
No. Apple don’t ship anything that is licensed under GPL v3 [0]. In fact, they are still shipping bash 3 (the last version under GPL v2) with Mac OS [1], released 16 years ago.
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/
Re: Bsdutils: Alternative to GNU coreutils using software from FreeBSD
#59The incompatibility between the two versions of sed (I have both installed on my macOS) is super annoying.
Isn't BSD Sed a subset of GNU Sed? I can't think of any outright incompatibilities that would make a BSD Sed script invalid for GNU Sed.
Re: Bsdutils: Alternative to GNU coreutils using software from FreeBSD
#60Earlier quoted context omitted.
How so? If Apple chose to distribute GNU cat, they'd need to release any modifications to cat under the GPL but the license's vitality would not "infect" the rest of OSX. Plenty of GPL software is available on osx.
Available and used by Apple themselves are two very different things.
yes, Apple obviously hates GPL and wants it to die. But I'm confused what you're responding to. The claim was that GPL is unusable on OSX and that's obviously not the case. Whether Apple uses GPL is irrelevant to the matter at hand.