[Toybox] diff.c

[Rob Landley]

On 8/26/22 18:11, enh via Toybox wrote:
>     So, nobody reads my blog ("glob") at least not yet. I spent many many
>     hours developing the world's fastest qsort() implementations, but I
>     have no way to get anyone who can get them used to look at it.

Does that have a similar writeup explaining why it's better? Elliott maintains
Bionic (still, I think?) and Rich Felker maintains musl-libc. Personally I'd
poke Rich first (despite Elliott having written the email I'm replying to)
because he doesn't have to run major technical changes through multiple review
committees with a multi-year process before getting it into the hands of end
users, and Rich also has a math degree so is thus MUCH better at reading proof
dialect descriptions than I am. :)

> have you tried? the llvm-libc folks are effectively starting from scratch
> (https://github.com/llvm/llvm-project/blob/main/libc/src/stdlib/qsort.cpp), and
Sigh. I had honestly hoped that particular https://xkcd.com/927/ had died during
the pandemic, or at least quiesced like klibc and newlib. Last I'd heard it
mentioned was
https://hub.packtpub.com/google-proposes-a-libc-in-llvm-rich-felker-of-musl-libc-thinks-its-a-very-bad-idea/
.

If musl/bionic/glibc don't cover it, buildroot is still maintaining uClibc-ng
for some reason, dietlibc inexplicably still exists. (The pandemic hasn't been
kind to its development, but you could argue that the 2019 release happened
because posix-2018 did and they'll do another when necessary?)

The linux kernel's "nolibc.h" WAS one header file without various #defines and
syscall wrappers and a few inline functions but at
https://github.com/torvalds/linux/blob/master/tools/include/nolibc/nolibc.h it's
been broken up into a dozen header files that top one #includes.

If you need a tiny embedded one better than newlib or klibc, the maintainer of
x11 is doing "picolibc" https://keithp.com/picolibc/ which uclinux founder Jeff
Dionne had us looking at for the j-core stuff last year.

In theory the MacOS's libc is based on FreeBSD's but they've forked that so far
it's unrecognizable. There was an open source "darwin" project claiming to
underlie OSX and iOS, but https://rixstep.com/2/20190728,00.shtml explained how
the corporation producing the serial abandonware releases lost interest.

Can we call Solaris dead yet? (There was an OpenSolaris which begat Illumos.)

If you want to go into the proprietary stuff, AIX and HP-UX still exist. Xenix
and Unixware died after SCO committed seppuku (Well, technically Caldera renamed
itself SCO and original SCO renamed itself Tarantella and then there were so
many lawsuits, then their unix business was bought by some private equity dudes
who renamed it UnXis then Xinuos and then in 2015 migrated the remaining
Unixware users to a freeBSD derivative and then in 2021 restarted the SCO
lawsuit against IBM. No really! Say hi to Cravath, Swaine & Moore for me.)

And yes I'm getting bug reports on github from the qnx guys recently because
their libc #defines stdin in a way that makes using a local variable by that
name break:

https://github.com/landley/toybox/issues/371

And because the recent removal of the utmpx.h compile time probe inconvenienced
them:

https://github.com/landley/toybox/issues/372

<tina_turner>We don't need another libc...</tina_turner> (Especially not another
C library written in C++, which is honest and truly NOT the same language...)

> i'd imagine the BSDs would be receptive to improvements, even if it's super
> annoying that there are three BSDs that don't really share code in any
> organized fashion? (we've never found qsort() important enough to do anything
> but track BSD; i forget which one!)

In part it's because BSD's kernel, libc, and userspace have always been
maintained as a single giant monolithic combined repository so if you want to
fork any of the components you have to fork ALL of it. (Linux is modular so you
can swap parts around and then work with each other. BSD very much is not.)

But there's also SO much politics. (Links to the originals on
https://landley.net/history/mirror but you'd be lucky to pull most them out of
archive.org, which is why I mirror stuff.)

History of BSDi:
https://landley.net/history/mirror/unix/special2.htm

Interview with Bill and Lynne Jolitz:
https://landley.net/history/mirror/unix/jolitz1.html
https://landley.net/history/mirror/unix/jolitz2.html

1999 interview with FreeBSD founder Jordan Hubbard (shortly after Apple hired
him away to work on their proprietary FreeBSD fork which became OSX) says he'd
already independently ported BSD to 486 (for his own use) by the time the
Jolitz' first release came out:
https://landley.net/history/mirror/unix/jordanhubbard.html

NetBSD seperately-ish happened in 1993 because 4 people were unhappy with
Jolitz' 386BSD:
https://en.wikipedia.org/wiki/NetBSD

And OpenBSD exists because one of those four people got thrown out of NetBSD a
year later:
https://mail-index.netbsd.org/netbsd-users/1994/12/23/0000.html

Which has kind of continued to be a thing for OpenBSD's maintainer:
https://lwn.net/Articles/29937/
https://slashdot.org/story/05/06/17/127206/linux-for-losers-according-to-de-raadt

Dragonfly BSD forked off of FreeBSD 18 years ago because of another developer
eviction (although that seemed much more of a technical design dispute than
generalized difficulty interacting with other humans).

MirOS (where Android gets its shell) started life as an OpenBSD fork in 2002:
https://en.wikipedia.org/wiki/MirOS_BSD

And those are just the big surviving ones. There are EIGHT GAZILLION dead forks:
https://en.wikipedia.org/wiki/List_of_BSD_operating_systems

And now llvm is writing their own libc without saying which operating system
that libc is for, which smells like Dunning-Kruger to me but what do I know?
(Microsoft's own libc is msvcrt.dll, which is what mingw links against when
cross compiling from Linux to windows. The glibc port to windows in cygwin is a
very thick compatiblity layer, and gnuwin32 is another glibc port with less
compatibility glue. The port of musl to windows is https://midipix.org/ .)

Honestly: people have already done this. A lot. What new niche is not being
served here? Just "not invented here"...?

Ahem. Backing slowly away, as previously mentioned...

>     Now I've written what I hope is a good explanation of a couple of LCS
>     algos. I sure hope you'll read it and give me feedback. If you don't,
>     I may never speak to you again :-).

I have the tab open.

Thanks,

Rob