[Toybox] diff.c

[enh]

On Sat, Aug 27, 2022 at 1:59 AM Rob Landley <rob at landley.net> 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,


i think you're thinking of the wrong axis here. i think far more
interesting than OS is cpu architecture. right now there's no one place
everyone can pull from that has optimized code for arm/x86/etc. even
getting the different parts of arm or intel to coordinate can be hard ("oh,
yeah, we own math libraries, but only for the _server_" --- not throwing
any stones; i work for a company with 100k employees too, and that's just
the way large organizations end up). llvm is one of the few pieces of
common ground (and it's not GPL, so it doesn't have the "oh, shit, we
worked on glibc but didn't realize you couldn't take code from there"
problem).

so for string/memory, math, etc, i actually think it's a good idea. (i
reserve the right to change my mind when they want to break "memcpy ==
memmove", say, but that's fine --- they're not making me take any code i
don't actually want. and i won't be able to take any code that involves ABI
anyway, since i can't change ABI.)

hell, even if it just gives the three(+) BSDs a common source to share
from, that would be a step in the right direction!


> 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
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220829/4196ce7b/attachment.htm>