3 ms·

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 a

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

HeckFeck 4y ago
> 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. Sounds like they've been studying the works of The Enemy ;)
rascul 4y ago
> 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?
- rascul 4y ago
  After some thinking, I do recall GNU Tar in I think the late '90s changed the bzip2 options a few times. Not sure the reasoning. Might be something in mailing lists but I don't really care to go digging.
yjftsjthsd-h 4y ago
> 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). 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.

HeckFeck 4y ago

> 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. Sounds like they've been studying the works of The Enemy ;)

rascul 4y ago

> 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?

rascul 4y ago
After some thinking, I do recall GNU Tar in I think the late '90s changed the bzip2 options a few times. Not sure the reasoning. Might be something in mailing lists but I don't really care to go digging.

yjftsjthsd-h 4y ago

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