I skimmed it. TL;DR: Musl developers don't want to make it 100% compatible with glibc because a lot of glibc is retarded; Systemd developers don't want to avoid glibc functionality in favour of pure and holy POSIX because a lot of POSIX is retarded, and nobody actually runs pure POSIX Linux systems anyway.
Seems to me they are both right. Probably the best solution is a compromise where Musl implements some of the most commonly used / difficult to emulate functions, and systemd avoids using the rest. Won't hold my breath though.
The systemd people are absolutely not right here. Just look at some of the interfaces they won't give up. malloc_info writes XML to a FILE* with state of the allocator. That is a comically bad interface.
Why you'd even want the state it describes in the first place I can't tell. malloc, realloc and free are the complete primitives for 50 years but somehow systemd can't function until it can spit out a few numbers into XML on top of this, for reasons? In the patchset for TFA, I was surprised to see the comment for the commit that makes this functionality conditional is marked as "this can't be upstreamed." Makes upstream sound like a bunch of babies.
I imagine it was added for debugging purposes. It looks like systemd uses it for that purpose too. Not unreasonable, though I agree, XML is a stupid output format. Supposedly so the output format can change.... and silently break clients.
Really systemd should work with glibc to make their APIs saner, and then musl can copy them.
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:
Honestly thank goodness. Choice is great and all that but I don't want system to infect Alpine or it's ecosystem at all. I never, ever want to see an apk that requires systemd.
I don't know where this widespread hallucination that systemd is "forced" came from.
You're allowed to use another init system, and the distros CHOSE systemd. Nothing is stopping you, it's just that nobody does it because:
1. Pretty much nothing is as good as systemd as a whole project. Stringing together 30 random packages is a huge pain.
2. Other init systems are much slower, and turns out people care about performance.
3. Other init systems are less functional, with less features which some users want.
4. Writing a competing init system is very hard, while complaining is both easy and fun.
In the hypothetical case of Alpine switching to systemd, you're 100% free to maintain your own Alpine distro or even maintain your own init system or just switch to a different one.
I disagree with most of your points, which I will say are very subjective at a minimum, but specifically
> In the hypothetical case of Alpine switching to systemd, you're 100% free to maintain your own Alpine distro
This is the problem. I don't want to fork and maintain a distro. I'm just happy and thankful to find a minimal one which doesn't have systemd. It can really seem sometimes like a damn virus.
Right, so the problem isn't "choice" it's you being lazy.
Alpine HAS the opportunity to make a choice and you're arguing "no don't make a choice that makes it harder for me!"
The only anti-choice position here is YOU. Objectively. Now, I think your position is 100% fine and justified. But don't try to bullshit me with some "oh choice!" argument if that's the case. It makes it very hard to take these anti-systemd arguments seriously when people seem hell-bent on covering them in some ideological bullshit.
There's lots of good arguments against systemd in something like alpine. Use one of those, drop the political, made-up stuff.
> Right, so the problem isn't "choice" it's you being lazy.
I never said the problem was choice, and no, it's not just me being lazy. Be reasonable and debate in good faith, please.
The problem is having an ecosystem 'infected' with something that none, or at least most of the users do not want.
> Alpine HAS the opportunity to make a choice and you're arguing "no don't make a choice that makes it harder for me!"
I'd argue most of the userbase don't want that choice made either.
You're right of course, if Alpine does adopt, a fork will happen and that fork will be maintained, but I'd very much rather that choice not be made. That's all I expressed.
If the people who prefer to use a worse init system out of convenience wish to do so, they have no shortage of options. This constant splintering and forking of distros, is, I would argue, not a good thing in the shortrun. In the longrun it has no effect but time wasted.
Besides, honestly, if the systemd fans want Alpine with systemd, they should fork it, since they are a minority.
> The only anti-choice position here is YOU. Objectively.
Objectively, not a single thing I've said has been anti-choice. If you feel otherwise, could you quote the excerpt that you think can support your claim?
> Now, I think your position is 100% fine and justified.
Then it would seem most of your comment here is just to hear yourself talk.
> But don't try to bullshit me with some "oh choice!" argument if that's the case.
My only stance has been that I don't want systemd to infect alpine. That's it. You already said you think my position is justified, everything else you've written is arguin against men made of straw. Surely that's not the best use of your time?
> It makes it very hard to take these anti-systemd arguments seriously when people seem hell-bent on covering them in some ideological bullshit.
I see what it is now - you're just making a ton of assumptions, and you come from a place where you prefer and believe systemd is superior, so you don't have a ton of empathy for people that disagree.
So, imagine there is an objectively slow, bad init system, the worst of the bunch. We'll call it dunnit. SO now your distro of choice, against your and most users objections has decided to switch to dunnit.
You don't like that. You have a ton of infrastructure built around this distro, you know it inside and out, and now it's just a disruption. So, sure, you have the choice to fork it, or work with others and fork it, and start maintaining it.
But before your distro adopts dunnit, you could also express that you hope they don't and express dismay that they might. There's nothing wrong with that, it's not an anti-choice sentiment, and it's literally all I did in this thread.
If you go back and read my very first comment. The very first line!
> I don't know where this widespread hallucination that systemd is "forced" came from
This is what I'm addressing. I am not addressing systemd itself, but rather the ideological bullshit that's made up around it. You know, the stuff you subscribe to.
As I've already said, there's plenty of arguments you could make against systemd in Alpine. And I'd probably agree. If you're paying attention, I've already said systemd makes no sense in a distro like Alpine.
But don't try to convince me or anyone else systemd was, or is, "forced". That's just not in line with reality, which would make you delusional. Do you want to be delusional? No, right? Okay, we're on the same page then.
> I don't know where this widespread hallucination that systemd is "forced" came from.
Well, it's quite simple; users who didn't want systemd had it added to their systems, and were told things like
> you're 100% free to maintain your own Alpine distro
by people who pretended that that was practical, or
> just switch to a different one
except then that one also switched to systemd.
> Other init systems are less functional, with less features which some users want.
Yes, that's much of why systemd's EEE has been so effective: Nobody ever comes along and says, "we want a nicer service manager, so we'll adopt runit". They inevitably say, "we want this extensive laundry list of features that happens to exactly match what systemd provides, and nothing else provides this exact list, so obviously we should just adopt systemd". Somehow the fact that users want features systemd lacks never comes up.
> Somehow the fact that users want features systemd lacks never comes up
These? Don't exist.
Systemd is the most feature complete and it's not even close. Runit has nothing to offer that systemd cannot provide, but the inverse isn't even close to being true.
You have to realize these distros are usually general purpose who serve A LOT of use cases. They target desktops, home servers, professional servers, enterprise. That's a lot of different users with a lot of different needs.
Now you may think some of those needs/features are stupid, unnecessary, or (everyone's favorite word) "bloat". But the reality is some people rely on them so they push for them to be added.
Now you have a problem where you need all these features. Distros can choose to maintain 2 init systems (hard) or just go with the one that provides features. The choice is, and was, obvious.
> EEE
Oh, drop the delusion. Systemd didn't do anything, the distros chose this and they chose it because it's the best. If that makes you uncomfortable I don't care - in fact nobody cares.
it seemed like a deadlock