On Tue, 20 Dec 2022 14:05:34 +0100 David Runge <d...@sleepmap.de> said:
> 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 think this is a very good point. Systemd has absolutely nothing to do with porting to architectures and won't add any more barrier than already exist in getting a toolchain, glibc and base utils port going. > I consider time on our distribution tooling more wisely spent than > losing ourselves in a dogmatic approach to what PID1 is or should be. Indeed - this is what I see - arguments for or against systemd... having more than 1 init system (and udev etc. etc.) is going to add a significant amount of friction, bugs, and busy work and likely always end up with openrc being a distant 2nd class citizen. Not worth the friction it's going to create IMHO. > 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 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com
