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. Best, David [1] https://gitlab.archlinux.org/archlinux/dbscripts [2] https://gitlab.archlinux.org/archlinux/devtools [3] https://gitlab.archlinux.org/archlinux/keyringctl [4] https://gitlab.archlinux.org/archlinux/repod [5] https://gitlab.archlinux.org/foxboron/archlinux-buildbot [6] https://gitlab.archlinux.org/archlinux/arch-release-promotion -- https://sleepmap.de
signature.asc
Description: PGP signature
