On 2022-12-20 14:05, David Runge wrote:
On 2022-12-16 22:46:12 (+0100), Andreas Radke wrote:Nowadays systemd has become much more than a plain init system and plans to grow further. This may leadd to problems from a user and system administrator perspective once you are hit by some bug. Systemd as a whole thing doesn't care about the Unix philosophy to do only one thing but well.Many and often highly skilled users left and leave Arch therefor or choose some different distribution or an Arch fork because there's no init choice in Arch Linux.The statements here are quite vague and as others have already commented on their accuracy I will abstain from going into that. What I'm missing: What specific problem do you intend to solve (how) and what are the numbers backing the other claims (e.g. users leaving, bringing back lost parts of the community, better portability)?I suggest to fix this lack of init choice/alternative. I'd like to implement it into the official Arch Linux repos allowing to choose some different init replacement. We can either just add a 2nd init system in the most simple way or allow real init-freedom[3] offering full choice and leave it up to be further filled by the community.Frankly, I believe this work would not justify the gain but instead complicate things (e.g. writing of unit files, support, etc.) and introduce overhead for package maintainers.Arch Linux could take advantage of this bringing back some lost parts of the community. With more choice and better portability Arch could become a better base for porting to new architectures. And freedom and alternatives is always good in the open source world. The clear drawback would become some added complexity allowing to choose either systemd or its replacement parts and to make all of them to work with existing packages especially daemon services.The porting to other architectures does not depend on what init system we are using (FWIW, I think systemd is quite flexible there), but rather our own distribution tooling. There are ongoing efforts to improve our tooling (e.g. dbscripts [1], devtools [2], keyringctl [3], repod [4], archlinux-buildbot [5], arch-release-promotion [6]), so that we can have a more flexible approach to (mass) rebuilding and releasing packages and artifacts. If you intend to support more architectures, the above are a must and something that needs to see more attention from all of us (however, currently these efforts are - on a very good day - led by less than a handful of people). I consider time on our distribution tooling more wisely spent than losing ourselves in a dogmatic approach to what PID1 is or should be.
Couldn't have put it better myself. It's exhausting that this is being brought again. This is a pragmatic distribution that ships software that works and isn't encumbered by unhelpful crusades.
signature.asc
Description: PGP signature
