to be absolutely clear: alpine is *not* switching to systemd or implementing a 'systemd compatibility layer'.

https://www.linuxjournal.com/content/alpine-linux-experiments-systemd-compatibility-while-keeping-its-lightweight-identity is literally AI slop

you can tell this is AI slop, because there is not a single link to anything from that article to an original source confirming anything asserted in that article.

*always* check publications for citations back to original sources.

what alpine *has* done is ship the systemd unit files included with upstream packages in aports. and this is not new, we have been doing this for a while now.

alpine *also* ships some systemd components as isolated components, such as systemd-boot. we may also use systemd's udev in the future as well.

but these are, and in the case of udev, would be properly integrated into alpine, not the other way around.

why does alpine ship the systemd unit files? so that downstream derivatives using systemd can use them.

simple as that.

@ariadne Why are people freaking out about this? It doesn't matter. The sloppy article aside, nothing about this is new as far as I knew...

@ariadne you can use systemd-udevd separately?

@whitequark yes

@neal because the article is disinformation

@ariadne I guess linuxjournal.com is all slop all the time now. A few days ago there was a similar [1] sloppy clickbait article about Debian.

Dunno who "George Whittaker" is, but if they are real person they should be ashamed of impersonating a journalist.

[1]: https://www.linuxjournal.com/content/debian-experiments-ai-assisted-bug-triage-open-source-projects-face-growing-report-overload

@bremner debian is using AI huh? yeah, i'm sure debbugs is really super friendly to AI tooling, right?

@ariadne Sigh...

@neal like linuxjournal.com right now, last two articles are totally AI slop disinformation

one about alpine and one about debian

i'm sure "george" will do fedora in time

@ariadne Yeah, it's probably going to happen with something particularly dumb too. I can already see it coming...

@bremner @ariadne it's so sad... the Linux Journal used to be an institution and now it's devolved into this

@sakurina @bremner honestly i wonder if the site has been compromised because it is pretty wild to publish that Debian is using AI to filter bugs and Alpine is adopting a 'systemd compatibility layer'

@ariadne Is it safe to assume that shims for systemd APIs needed by things like GNOME aren’t a “systemd compatibility layer” for this purpose?

@alwayscurious i do not know *what* the article means by 'systemd compatibility layer', but it describes libsystemd coming to alpine which has not happened

also, it is funny that the article talks about proprietary software not working on alpine

in general, this is not a concern in the alpine community, and we do support flatpak

@ariadne it's annoying to see stuff like this which suggests you can't use alpine on a desktop system

@weirdtreething
Yeah, it is really unfortunate as Alpine is what finally convinced me Linux was viable as a personal computing OS after two decades of distrohopping, multibooting, and virtualizing Linux.

@ariadne

@Brett_E_Carlock @weirdtreething indeed, maybe some of us have different priorities than the typical GNU/Linux user/developer

@ariadne 12 bullet lists in an article ? I love them as much as the next person, but even I know not to abuse them. No serious editor would have let this pass, seriously this is slop without even as much as a review pass.

@ariadne "this looks like a normal article to me"

-- high school bullies who couldn't write an essay and never figured out why they got an E

@whitequark @ariadne yep Gentoo has been packaging systemd-{tmpfiles,udevd,boot} separately on OpenRC systems for a long while.

@zyx @ariadne I had assumed the eudev fork needed to happen bc this wasn't possible

@zyx @whitequark at one point in time it was necessary, but it's a lot easier now with meson.

@ariadne how does meson help here? just out of curiosity

@dysfun we can easily build specific subcomponents of systemd with meson while still getting the internal dependencies right. with autotools it was a nightmare.

@ariadne makes sense

@ariadne I dunno, all I get out of our admin team is anatomically unlikely suggestions for scraper operators.

@moses_izumi @hikari I see "George" has done it again!

@ariadne Woho! Thanks for considering using udev in Alpine! It was the thing which forced me to return to Arch, while I would prefer to use Alpine. I've tried to use mdev + libudev-zero but it had a lot of quirks, so I switched to eudev but it had problems with mounting encrypted USB drives and some other quirks, so I tried to just use mount, but while on (some?) BSDs you can allow mount without root when user have permissions for both a device and a mount point, Linux does not.

Almost everything depends on libudev…

@aelspire Alpine already uses a udev implementation, eudev which is basically compatible with libudev.

@whitequark @zyx @ariadne

eudev exists, at least today, primarily because there's a vocal subset of people who get extremely angry if a package name or file on disk includes the word "systemd" in it, and will not consent to running a udev implementation if any internal filename happens to be /usr/lib/systemd

These people literally configure their package manager to silently delete any files from ANY package matching the glob `*systemd*`. Prank tip: write a program including "systemdetails.py".

@whitequark @zyx @ariadne

Also relevant, Gentoo dropped eudev a year and a half ago on the grounds that it serves no purpose given systemd-utils can install standalone udev, and eudev was unmaintained and broken and did not in fact provide the library APIs which software compiled against, due to its being unmaintained:

https://public-inbox.gentoo.org/gentoo-dev/7802203.lOV4Wx5bFT@kona/

Nonetheless, Gentoo still proudly supports non-systemd installs. :)

@eschwartz @zyx @ariadne oh man maybe i should switch back to gentoo

@eschwartz @zyx @whitequark its time to INSTALL GENTOO

@ariadne @eschwartz @zyx like it's not even about systemd, i'm using systemd right now, it's about people generally seeming to make more sensible decisions than my experience with debian as a maintainer which has left me very sour

@eschwartz @zyx @whitequark I mean I don't really have an opinion on systemd. the reason I use and work on Alpine is because it is an integrated OS. systemd offers some of the same benefits for the GNU/Linux crowd and that seems like a positive for GNU/Linux...

@ariadne @eschwartz @zyx i think a lot of the concepts are sound, but a significant part of how it was implemented historically shows a lack of care that i wouldn't really consider acceptable in my work but switching away from it would break KDE which i like enough that it's a nonstarter

@whitequark @ariadne @zyx

I'm not really sure what you mean by that... Switching away from systemd would break KDE? Shouldn't be -- KDE Plasma is packaged by alpine (no systemd option) and supported just fine on Gentoo's openrc profiles.

@eschwartz @ariadne @zyx to be clear this isn't a deeply researched opinion, i just used to run systemd-less debian and at some point half of plasma (networkmanager, power management, etc) broke due to some consolekit related thing i eventually traced down to "i guess i need systemd now"

@whitequark @zyx @eschwartz yes can confirm I use plasma as my daily driver on alpine.

@ariadne @zyx @eschwartz does NM work?

@whitequark @ariadne @zyx

The Gentoo gui installation ISO uses kde and openrc, and connecting to WiFi to begin installation means using the NM applet. It works quite well, except for the part where kde really wants to encrypt your wifi password with the account keyring, which as a live ISO doesn't exist. (So, routine "fail to store the password and then go back into settings and re-enter the password" on every ISO boot.) But that's not the fault of an init system. :D

@eschwartz @ariadne @zyx thanks, this is very useful to me :3

@whitequark @ariadne @zyx

I have no particular idea what Debian might have done there, but generally the preferred alternative to systemd is using elogind anyways. Which should work fine. You could also try speaking to the upstream maintainers of $PACKAGE about using libseat where possible. Gentoo should support any configurations possible upstream, and possibly relevantly, Gentoo will *rebuild* if you change your configuration, not use libsystemd.so compiled binaries on openrc.

@whitequark @ariadne @zyx

Basically, if you're gonna support a frankensystem where packages can either be compiled against one init system / seat manager / udev impl / lots more, or another one, it really helps to have the concept of USE flags, and I don't know what Debian does to try to support "packages depend on systemd, but we also support openrc instead" without USE flags. Maybe "foo-systemd" and "foo-openrc" packages? Sounds terrifying. "Openrc derivative with overridden repos"? Pain².

@eschwartz @ariadne @zyx "pain" is a good summary

@ariadne @whitequark @zyx @eschwartz do you run edge or stable? (I run edge on my laptop with KDE Plasma and occasionally stuff breaks)

@noisytoot @eschwartz @whitequark @zyx edge, but i am patient

@whitequark @ariadne @zyx

On the distro maintainer thing... I didn't realize that you were a Debian maintainer but I guess I see it now on qa.debian.org -- luckily you've only been tortured with a single package?

I've now been a maintainer for two distros, I'm a maintainer upstream for Meson, I have an interest in build systems and package managers (and have written lots of code for both, not just packaged). And I really just think Debian is uniquely bad and cannot find any compliments for it.

@eschwartz @ariadne @zyx nonono, I'm not a Debian maintainer. I'm a maintainer of software that is included in Debian and in the past (not currently) this was a pretty miserable experience

@whitequark @ariadne @zyx

Debian is designed to be about politics, and even its packaging recipe format is about politics because they have multiple competing implementations for "build a package", some of which are bad for Quality Assurance reasons, and they can't actually stop anyone from using either those, or one they NIH'ed for personal use. Every decision they make isn't really made because the decision is good, but because it doesn't offend someone's incompatible workflow.

@eschwartz @whitequark @zyx if i never have to read another debian/rules file as long as i live, that will be very alright with me

@whitequark @ariadne @zyx

Oh sorry, it looks like Debian thinks you are a comaintainer of solvespace but looking at salsa version history, the current active uploader produced the first git import in 2016 with you listed as an uploader, and just kind of rolled with it ever since?

We have officially found today's qualifying lmao.

@eschwartz @ariadne @zyx I had a debian/ directory upstream in solvespace that I put quite a bit of effort into and the Debian maintainer just rm -rf's it in the recipe and starts over. when questioned I was informed that this wasn't welcome. but also Debian loves unvendoring shit by policy that is vendored for very good reasons and without downsides to end users which is occasionally breaking stuff in opaque ways

@eschwartz @ariadne @zyx yosys-abc is built from the forked source because the upstream build regularly results in unusable bitstreams with no debug output suggesting it may be so. so obviously the debian maintainer would insist on using upstream abc for years

i just hate this pattern of arrogance

@eschwartz @ariadne @zyx in theory end users are supposed to report problems to Debian first but in practice basically nobody knows about this and so I end up sometimes having to debug someone else's idea of a good patch (which isn't)

this is not a desired relationship

@whitequark @ariadne @zyx

Yeah but why are you nonconsensually listed as the maintainer??? Like, help. Whaaaaaaaat.

@eschwartz @ariadne @zyx I literally just learned this lmao. I am not even a part of SolveSpace project any more (I quit due to what probably amounts to harassment from a xenophobic and virulently transphobic Ukrainian user who would try to leverage his participation in defense as some kind of argument for his OSS contributions). I have since learned to just tell these people to fuck off but I didn't know that then

@whitequark @ariadne @zyx

I mean, I like unvendoring just as much as the next distro dev.

But it is sooorta important that you only do that when the "vendored" library isn't a full blown fork with unique features which the project that is vendoring it, added specifically for their private use and has a critical dependency on.

And also the project is a python application so you cannot tell this by getting a compiler error, it just crashes at runtime.

Yes, this is a real life thing I reported.

@eschwartz @ariadne @zyx fwiw aside from this case I don't think dependencies that aren't exposed to untrusted inputs should be unvendored by default. you don't know whether this will cause issues so you should by default assume that it will (unless the vendoring is done explicitly to simplify the build or something like that). as a distro package maintainer you simply do not have the same expertise or resources as the team who originally made the decision

you can also just ask, which is at the core of my contention.

@eschwartz @ariadne @zyx why is the default relationship with the distro package maintainer an essentially adversarial one, where people automatically assume that whatever patch they write is correct even though the motivation for the patch is policy? this is one way of how you end up with "don't use distro packages" in README

@whitequark @ariadne @zyx

Meson actually tries to make this really easy, with the rationale that if you don't provide a buildsystem integrated way to vendor a dependency, people will simply cp the sources, call it a day, and you'll never know why.

You lookup a dependency() as normal, and then add a small ini file with the upstream tarball url, and it only builds it if no system dep is found. If it's not the "expected" upstream url, it's prolly a fork and forced via subproject() so don't touch.

@whitequark @ariadne @zyx

I do think asking is a good idea, but the answer is sometimes "we only test CI with this patchlevel version therefore we forbid you from using the system zlib because you never know" and I kind of feel very qualified to say "we have investigated and it's okay to devendor, upstream is being a bit lame".

I encourage projects to include tests that assert whatever bizarre behavior is involved, though. Then it's impossible to mess up unless "we" don't test packages (eww?).

@whitequark @ariadne @zyx

That being said, stuff like this is kind of rare and there's usually bigger issues than vendored dependencies. Or the vendored dependency is a very old version of Qt6.

@eschwartz @ariadne @zyx as an example of what I think shouldn't be devendored: nextpnr includes a small Qt tree widget library, it's basically two files. it's only exposed in the GUI. there are no tests for that behavior and no resources to write tests for it. the functionality itself is used by like 1% of people

are you gonna roll the dice on it? I sure fucking hope you wouldn't, because the tradeoff is not there

with something like zlib, which actually makes sure to maintain a compatible ABI (or even Qt, to a lesser extent) it's much more reasonable to devendor

@whitequark @ariadne @zyx

I think that it should be mandatory for all patches to either have a documented link to where the patch has been submitted as an upstream PR, or the software is dead sourceforge stuff from 2005, or some other explanation is provided for why it is physically impossible to attempt to send the patch upstream.

Meanwhile Debian has "Forwarded: not-needed" metadata, indicating this is normal to "not need it", with no reason specified.

@eschwartz @ariadne @zyx yeah I'd be happy with that kind of relationship to packagers

@eschwartz @zyx @whitequark generally alpine only patches to make things work or devendor appropriate libraries

or in the case of some abusive software, disable the antifeatures (e.g. telemetry)

@whitequark @ariadne @zyx

Really, ideally the only patches a distro should have are "make it work with bleeding edge gcc" or "the system libs that upstream uses were upgraded and an incompatibility occurred" and in both cases, both sides want that patch to be submitted upstream.

Unfortunately sometimes even this is too high a bar. Certain distros (naming no names) just want to "make it work right now". And sometimes that patch is subtly wrong but the maintainer didn't see it to say so.

@eschwartz @whitequark @ariadne @zyx This list is way too limited. Only a minority of build problems are caused by "bleeding edge GCC" or "dependency upgraded". Most of the build problems are caused by -Werror, incorrect (C|CPP|LD)FLAGS usage, hardcoded/missing libs on linker invocation, hardcoded include/linker path, missing headers, libc vs linux include conflicts, earlier GCC or linux headers, glibcism, not supporting cross-compilation or basically just not using the same distribution as the developer.

And that is just the build problems. There is also -march=native, reproducible builds, systemd, precompiled binaries, bundled CA or timezone, telemetry, FHS, documentation, security or many other issues that are often controversial of which the packager may be tired of arguing about.

I can totally understand being tired of explaining all that and not submitting patches to upstream. This is OSS after all, nobody is contractually obligated to do these chores.

@gantua @eschwartz @ariadne @zyx however if you're going to apply patches I strongly disagree with, I reserve the right to be actively hostile to your distribution and work against inclusion of the patched software in it

@gantua @eschwartz @ariadne @zyx in other words: there is definitely a potential consent issue here, in addition to all of the possible technical issues. you may have a legal right to distribute my software or its derivatives, but that doesn't give you the moral right to do so if i think that makes me look bad or causes me other issues.

@whitequark @eschwartz @ariadne @zyx Well that's the problem here. That a mere "i patch this because otherwise it does not work here" triggers so much hostility. Which is precisely why some packagers do not upstream patches.

@gantua @eschwartz @ariadne @zyx that is not what I said

@whitequark @eschwartz @ariadne @zyx
You said upstream should consent to patches. Except upstream often reject or ignore patches that fix compiling or running on distro X for a variety of reasons (e.g. "i don't care", "it's not supported", "works for me", "use docker instead").

What to do here ? Other than to ignore upstream (and stop sending them patches).

@gantua @eschwartz @ariadne @zyx no, that's not what I said. patching software is obviously core to what FOSS is about. however when the result of you patching the software is breaking it, and you refuse to fix it while shipping it under the upstream's name, that's when it becomes a problem. not when the upstream doesn't care, but when the upstream is actively looking worse because of something you did and doesn't want to be in that situation

@ariadne LJ has been full-time slop for a while now. Truly a sad development.

@ariadne Didn't I read recently that flatpak could become dependent on systemd ?

@philfr "systemd" can mean many different things. in this case, it means systemd-appd, which is API surface that can be used and/or reimplemented without adopting systemd as a whole.

for example, we have GNOME running on alpine, which also depends on "systemd", but it is not a problem.

@whitequark

I've read the same concerns from GNOME folks and I can understand their perspective — users complaining about software not working as intended even though those specific complaints are either absent (downstream patching à la Debian) or no longer present (outdated packages à la Debian) may make the upstream project look bad or send unnecessary bug reports their way.

The way I see it, this can either be resolved by registering and imposing trademarks (Iceweasel in Debian), centralising distribution of said software through app stores like Flathub and not providing any instructions or support to distributions for building said software, automatically closing any and all bug reports from users who report using said software from a distribution with downstream patches, or not using a FOSS license at all.

The 3rd option sounds reasonable to me but I guess other options are on the table as well depending on who or what the upstream is.

@gantua @eschwartz @ariadne @zyx

@ayushnix @gantua @eschwartz @ariadne @zyx it's telling that "distributions changing their behavior" is not on the table, apparently!

@whitequark

It's definitely on the table for distributions themselves but the options I presented are on the table for the upstream to act upon.

In some cases, however, I don't see how it's feasible to not (inevitably) patch some things downstream when they freeze thousands of packages in their repositories for several years like Debian (or god forbid enterprise distributions like RHEL) does.

For the record, I, for one, am in support of rolling release distributions which ship the latest software without any downstream patches and when patching is done, it's done for a good reason and those reasons are tried to be removed by working with upstream.

@gantua @eschwartz @ariadne @zyx

@ayushnix @whitequark @gantua @ariadne @zyx

The reason for Debian sometimes applying patches that upstream doesn't like, is not actually connected in any way with "stable repositories". It is typically about Debian's vision of what software should look like.

Case study: the "Debian openssl fiasco" was a distro patch because the distro had opinions about whether libraries should be valgrind-clean. It was not at all needed "because of the stable freeze".

@eschwartz

Sure, but IINM, doesn't that vision also include backporting bug and security fix patches to the stable repositories and such patches may not always have clear boundaries and be well defined? Besides, even if a software is not patched downstream, keeping it "stable" while upstream has moved forward and fixed bugs is something I've seen being a source of complaints from GNOME.

It works for Debian (and other LTS distributions) and its users but it looks like this is at odds with some upstream projects, which is why I was wondering that if an upstream doesn't like the way FOSS software distribution works in practice, it can take measures to change that (which is arguably one of the reasons why we're seeing what we're seeing with Flathub).

@whitequark @gantua @ariadne @zyx

@ayushnix @whitequark @eschwartz @ariadne @zyx We all know what happens with "ship the latest software without any patches": Everything is broken. There is a reason why distributions are not all out on the new GCC 16 released last month. Most developers are not going to use GCC 16 until it is packaged by a distribution, but a distribution will not use it as default it if it breaks everything.

Large package managers like npm or cargo learnt this the hard way and attempt to fix it with vendoring. But of course now the vendored dependencies have known security vulnerabilities and known bugs.

@gantua I didn't mean ship the latest software without any testing either. It's not a race and there are no awards. I meant it in the sense of how most well run rolling release distributions work. For example, the latest big python rebuild going on in Chimera.

@eschwartz @ariadne @whitequark @zyx

@gantua @ayushnix @ariadne @whitequark @zyx

I dunno, here I am on my Gentoo system with official binary packages for gcc 16 and 17 too, even.

gcc 16 is the default compiler for Gentoo users on the testing branch, also.

But that's okay! I already said that I think "patch to fix compilation with newer gcc" is always a valid reason for a distro patch! And it doesn't make upstream look bad.

@ayushnix @whitequark @gantua @ariadne @zyx

In reality, stable distributions do not actually backport bug fixes or security patches for the vast majority of software, both because most software doesn't have something to backport and because the security team has too much on their plate already and only considers specific packages to be covered by security guarantees.

And if it's not patched, the gripes about its bugs are irrelevant to the discussion about whether *patches* reflect badly.

@eschwartz

And if it's not patched, the gripes about its bugs are irrelevant to the discussion about whether patches reflect badly.

Irrelevant to the discussion, agreed. I guess I made that segue because not updating has itself become a source of complaints from some upstream projects.

@whitequark @gantua @ariadne @zyx

@gantua @ariadne @whitequark @zyx

Werror is a *problem* because upgrading gcc adds new warnings. "Earlier gcc headers" is surely agreeing with me, "missing headers" is porting notes for every gcc upgrade. Missing libs can be passed with LDFLAGS, no patch needed. Hardcoded flags or incorrect usage, sure, I agree.

Cross compilation isn't a critical requirement. Nice if it works but finicky even if upstream is doing everything right.

@gantua @ariadne @whitequark @zyx

Glibcisms is a you problem, not an upstream problem, because musl has elected to make the choice to move into a preexisting market, not offer feature parity for existing software, and then rejected the possibility of detecting its presence for software that has genuine need to interact with the low-level platform layer. I can sympathize with musl users, without condoning the decisions of the people in charge of it.

@gantua @ariadne @whitequark @zyx

Many musl users (not all) are quite good at complaining about "glibcisms" (that projects usually fix if approached nicely) while mis-attributing unwillingness upstream that's actually caused by the need for musl-isms.

Any project that needs a musl-ism has a genuine, *correct* reason to be hostile to musl, in reciprocation for the fact that hostility against upstream came first (and can be very toxic) and "being hostile to musl" is just "obey code of conduct"!

@gantua @ariadne @whitequark @zyx

Reproducible builds and producing trust in build automation cannot be fixed by making every build automation use custom patches, it's an oxymoron. Please, upstream *only*.

systemd dependencies, telemetry? Be honest and fork, don't "patch".

Bundled CA/timezone, fine, yes fixing user TLS is a good reason to patch.

I strip html docs. /opt exists for non-FHS stuff.

@eschwartz @ariadne @whitequark @zyx
You can't add missing libs with LDFLAGS since the order is important.

cross-compilation is required to target any 32bit arch, since modern compilers require more RAM over time, and the 4 GB address space is a hard limit. It was already a problem for e.g. compiling firefox.

glibcism didn't need musl to be a problem. During the drepper days, the only usable libc on ARM was uclibc or uclibc-ng. They have a define and everything, but of course it didn't define __GLIBC__. And the reaction to any other libc than glibc was already hostile.

Problems with reproducible builds are mostly caused by the build system being broken, so of course this needs to be patched.

/opt is not for distribution packages, it must be left to the user.

@gantua @ariadne @whitequark @zyx

I'm afraid virtually everyone disagrees with you about the purpose of /opt so you're simply tilting at windmills there.

I mean, as a distro developer I can definitely confirm that /opt is a common and well utilized place to package certain types of software. It has nothing to do with whether it was triggered by a package manager or a user manually extracting software from a tarball.

@eschwartz @ariadne @whitequark @zyx To sum up, you don't want your software to be cross-compiled (when i said 32bit, i mean all 32bit archs, not just i686, ARM has the same problem, that and most ARM CPU are too slow to compile stuff with them), to support musl or uclibc-ng (why do you bring up musl when i complain about glibcism ? uclibc-ng is not dead and there is also the BSDs actually), and you don't want to install anywhere else than in /opt.

Which means if i want to package your stuff for a distribution that require any of these things, the only option is to patch your stuff without your consent and make you look bad. Not to mention that even innocent patches for upgrading GCC can also create bugs and make your software look bad. Even upgrading GCC itself can create bugs due to bad or buggy compiler optimizations.

@gantua @eschwartz @ariadne @zyx you always have the option of not packaging the software of people who don't want you to be packaging their software. what is so hard to understand about that?

@gantua @ariadne @whitequark @zyx

You can try using autotools LIBS instead of LDFLAGS, if it makes you happier. :) Meson places LDFLAGS after objects though, which is all you need. At least, if you use shared libraries which you should. :)

@gantua @ariadne @whitequark @zyx

Still lol re cross compilation. The odd software that needs it because it's the size of Firefox, doesn't need patches to fix cross. And such software really is rather fringe, as a general rule.

And really you don't exactly need a cross environment to begin with, you just need a 64-bit compiler which isn't exactly the same thing. It would suffice to, say, have an ordinary i686 with 64-bit kernel and gcc -m32 install.

@gantua @ariadne @whitequark @zyx

Also nice dodge with reproducible builds, again, upstream-only please. My rationale for why it needs to be upstreamed does not differentiate between build system fixes and C source fixes.

@gantua @ariadne @whitequark @zyx

Nice dodging my point about musl? You think all the world is drepper?

I am talking about specific actionable issues with musl, please don't pretend none of this exists because dead software from a previous era was "required" (?) and pretending that its lack of support was due to hostility rather than due to it being yet another "exists for embedded" libc with even less production readiness.

@gantua @eschwartz @ariadne @zyx or even just... admitting that you've functionally made a fork

@corbet Yep...what a downfall ...meh