5 ms·

both systemd and musl developers were talking here: https://github.com/systemd/systemd/issues/10130 https://github.com/systemd/systemd/issues/10130 it seemed l

both systemd and musl developers were talking here: https://github.com/systemd/systemd/issues/10130 https://github.com/systemd/systemd/issues/10130 it seemed like a deadlock

ruthmarx 2y ago
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.
- bigstrat2003 2y ago
  So... choice is great, except when it comes to something you personally dislike?
  - yjftsjthsd-h 2y ago
    No; choice is great, and sometimes the only way to preserve one choice is to limit another.
    - consteval 2y ago
      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.
      - ruthmarx 2y ago
        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.
        consteval 2y ago
        > I don't want to fork and maintain a distro 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.
        ruthmarx 2y ago
        > 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.
IshKebab 2y ago
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.
- asveikau 2y ago
  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.
  - IshKebab 2y ago
    > That is a comically bad interface. 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.
    - awilfox 2y ago
      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.

both systemd and musl developers were talking here: https://github.com/systemd/systemd/issues/10130 https://github.com/systemd/systemd/issues/10130 it seemed like a deadlock

ruthmarx 2y ago

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.

bigstrat2003 2y ago
So... choice is great, except when it comes to something you personally dislike?
- yjftsjthsd-h 2y ago
  No; choice is great, and sometimes the only way to preserve one choice is to limit another.
  - consteval 2y ago
    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.
    - ruthmarx 2y ago
      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.
      - consteval 2y ago
        > I don't want to fork and maintain a distro 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.
        ruthmarx 2y ago
        > 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.

IshKebab 2y ago

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.

asveikau 2y ago
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.
- IshKebab 2y ago
  > That is a comically bad interface. 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.
  - awilfox 2y ago
    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.