[Toybox] Lots of libc's.

[David Seikel]

On 2022-08-27 04:06:58, Rob Landley wrote:
> 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...

Have you stumbled across https://github.com/jart/cosmopolitan yet?

"Cosmopolitan Libc makes C a build-once run-anywhere language, like Java,
except it doesn't need an interpreter or virtual machine. Instead, it
reconfigures stock GCC and Clang to output a POSIX-approved polyglot
format that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD +
NetBSD + BIOS with the best possible performance and the tiniest
footprint imaginable."

Does all manner of wierd things, including turning zip files into cross
platform executables.  Their flagship application is redbean, a stand
alone web server in an executable zip file.  You add your web site to the
contents of the zip file, and it can run Lua based web pages.

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

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.