That would be amazing, but I don't imagine that malloc internal probes would be readily accepted to musl even if they were improved. One of the things musl admits is the ability to swap allocators around; you can just LD_PRELOAD a new one. Or even, with Chimera, replace the stock one too! Having internal debug probes would mean every allocator you want to use would need to provide those same APIs, and I don't find that particularly reasonable.
How is musl special when it comes to interposing malloc? As far as I’m aware, (dynamically) swapping out malloc implementations is a messy business no matter what. Most libc implementations only “support” the behavior in the sense that they won’t stop users from “swimming in the deep end”, so to speak.
malloc_info() is not consumed internally but it is only wired up as a debugging utility via systemd-analyze, which is sorely needed when things go bad in strange and weird ways. It would be entirely fine for a libc to just implement a stub that returns a fixed string:
It's true. systemd has a lot of good ideas with questionable implementations. I'd love networkd if it didn't have silly decisions made.
And it has some questionable ideas with good implementations. For example, I hate the journal, but admit it is implemented well.
At the end of the day, it's about tradeoffs and using what suits the system at hand. For some people that will be systemd, and bringing systemd to Adélie and other musl libc distributions means that it can be used by those people.
Call me old-fashioned, but I also hold out hope that at least some of those questionable implementations could be fixed if only someone with the desire would write a patch and send it upstream. Bringing systemd to musl means the people in musl land that aren't knee-jerk anti-systemd maybe might be more enthused to do just that, improving it for everyone using it.
A lot of people care about BSDs and embedded Linux systems. Such as: Netflix (FreeBSD), anyone with a Linux-based router or cable/DSL modem, and so on.
That said, parallel startup is possible on those systems too. There was an out-of-tree patch for parallel rc(8) on FreeBSD some time ago, and dinit is parallel, etc. I think OpenRC should move towards making parallel startup stable and supported so that those systems can do that as well.
I don't think Lennart changed his opinion, if you look further in this thread[1] Lenart wasn't ever against musl per se, it is more like "we use non-POSIX features from glibc that we found useful, and we are not going to reinvent them, so either convince musl to implement those features or carry patches fixing the issues". That I kind concur with him, instead of workaround missing functions it may be better to just write a compatibility library that complements musl with the missing functions. This way, any program that needs those functions could just import this library if they're compiling in a non-glibc system.
I am seeing that lots of the fixes proposed by the author are things like "missing import because glibc exposes some symbols by mistake and musl does not". And this is definitely the kind of fix that upstream would accept[2].
> This library is designed to be used for binaries that are already compiled
against glibc. It does not contain any headers, and cannot be used to build
software that requires glibc. It is instead recommended that any software that
requires glibc APIs be modified to become more portable.
This is exactly the opposite that I was talking about. What I was talking is a library that expose glibc compatible headers to compile software that uses Glibc-isms with minor or zero modifications, but this instead is a compatibility layer for binaries and doesn't expose headers (probably for proprietary software that can't be recompiled).
I care deeply, and was one of the early adopters of the Talos. I do my graphics and design work on an iMac G5, still. Power is the hill I'm willing to die on, technologically speaking. The bi-endianness matters a lot to me. I prefer to do my development on BE, and I get hardware accelerated LE VMs for free on Power.
But the rest of this thread is correct: right now it is a huge cost sink. I recommend people buy Apple Silicon Macs for new hardware unless they really need the owner controlled firmware of a Talos. There's just no denying the M2/M3 spank the Power9 core in every bench, single and multi thread.
I'm eternally optimistic - I was told I was crazy in the dark days of P7 and P8, then the Talos came. Maybe the LibreSoC or PPC Notebook projects deliver? Maybe Talos 3 isn't stupid high cost? I hope, but I don't hold my breath.
LibreOffice is a known pain point we are trying to resolve. Flatpak is on my list of things to package. Firefox and Thunderbird 102 need Rust toolchain updates that are queued but not yet live.
Chromium is a non-starter: it doesn't support musl libc, and even if it did, it doesn't support 3 of our 5 Tier 1 architectures. It also has significant issues regarding reliability, security, portability, and a rapid release schedule that would severely drain our presently limited resources testing all of the patch sets we would need to ship with it to make it work for us. But, when we have Flatpak available, you can always <s>punish yourself with</s> run Chromium via that, I suppose.
I'll look in to Gnome Boxes; thanks for the report.
KDE really, really needs logind - it can't really use ConsoleKit any more. Same with SDDM, though I think the CK2 backend is still writhing in agony somewhere in its codebase.
And KDE's touchpad integration relies on libinput, which relies on udevd. I think libinput might work with mdev if you really try hard enough?
I am not aware of KDE having dependencies on any other bits of systemd, at least Plasma 5 LTS doesn't.
