[Toybox] making ./configure executable.
Rob Landley
rob at landley.net
Tue Feb 6 08:45:07 PST 2018
On 02/05/2018 09:41 PM, Robert Thompson wrote:
> Yeah, I ran into some similar issues years ago... In my case, I got
> burned into learning not to assume that bash (or any other shell) is
> correct, or even necessarily *self* consistent(even on linux), so I
> tend to reflexively do differential checks. It's a very small amount
> of effort in the normal case, but months of project time and a major
> missed deadline tend to leave a bit of a scar :)
>
> there was a "posix, we swear" vendor /bin/sh, a classic /bin/bash, a
> "new and sexy" /bin/bash, and the same version/same configuration
> /bin/bash running on a different hardware/os...
>
> We wasted months assuming that the newer bash was most likely correct
> (it was a heisenbug, both rare and inconsistent). In that case, turned
> out that the posix sh was technically correct and consistent, and
> *all* of the bashes exhibited *different* incompatible heisenbugs. And
> they tended to show up only about a day into a massive
> un-checkpointable processing run...
The FSF is bad at writing software, yes. :)
Part of my formative experience with Linux is that the FSF's software
development efforts basically died for five years (1999-2004), so
distros were using fixed stable versions of the userspace stuff. It was
all basically "done". There were some ubiquitous local vendor patches
(adding -j to tar and such in the 5 year gap between 1.13 and 1.14 being
released, for example), and things that DID need to change like compiler
development forked off as other projects (egcs, libc5), but there was a
de-facto set of tools everybody agreed on, and that mostly included
specific _versions_, and nobody had to care what the FSF thought about
anything.
Then the FSF noticed its ftp server had been broken into and was
distributing malware, and they took all the source tarballs down and
replaced them with a note asking if anybody had backup copies (of course
the FSF itself didn't: it's the FSF). I noticed this had happened
because I was doing Linux From Scratch, and three weeks later nobody'd
cared enough to do anything about it so I poked slashdot
(https://developers.slashdot.org/story/03/08/13/1530239/fsf-ftp-site-cracked-looking-for-md5-sums)
and that whole debacle seems to have gotten people to notice the FSF was
dead, but instead of _replacing_ them they volunteered at them and tried
to work through their horrible crazy lens, and when that round of
excitement subsided and the FSF went back to dying they tried suing
people to reclaim attention
(https://www.linux.com/news/gpl-requirement-could-have-chilling-effect-derivative-distros)
and that "all we've got to squeeze money out of people is control of the
license" nonsense snowballed into GPLv3.
Not a net win, really.
Anyway, even back at busybox I was mostly targeting equivalents of those
5-year "stable" versions from 1999, and only cherry-picking newer
features when people asked for them or the kernel grew some new thing I
wanted to take advantage of. These days my baseline is posix-2008 plus
any Y2k-era Linux extensions that posix rejected because That's Not
Solaris I Want Solaris La La La Solaris.
So when I say "a proper bash replacement" I'm _mostly_ targeting bash
2.x with proper utf8 and the occasional new feature like ~= (regex
matches) that are easy to do. Stuff like <(command) and file{1,2}.txt
are over 20 years old.
I really don't care what the FSF's done since about 2005. As far as I'm
concerned the Mepis thing I linked above was a career limiting move
_before_ they split "the GPL" into incompatible versions so the Linux
kernel and Samba can't share code even though they implement 2 ends of
the same protocol and are both "GPL".
(None of this excuses dash, though. :)
Rob
P.S. Yes, I did my own GPLv2 enforcement lawsuits circa 2006. That's
another story...
More information about the Toybox
mailing list