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. _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net