Am Fr., 16. Dez. 2022 um 22:46 Uhr schrieb Andreas Radke < andy...@archlinux.org>:
> The older Arch developers may remember vaguely how Arch has introduced > [1] and migrated to systemd [2] becoming the new and only supported init > system. Back in these days we had some developers in our team being part > of upstream systemd developers. Not much discussion happened about > supporting any alternative init system. Other alternative init systems > have become niche in Arch and faded out over time. > > The main reason for switching to systemd was because most upstream projects started to implemented systemd as main starting system of the daemons. KISS means supply it as the author wanted to ship the software. Maybe you forgot how many bug reports we had due to not starting the services in correct order or wrong used options. > 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. > Sure it evolved as it should. As example systemd with iwd is much faster than wpa_supplicant solutions. The harmony of kernel/udev/dbus/systemd made a lot of things working in better speed for example. 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. > Well I don't see devs leaving cause of systemd usage. 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. > > Freedom is nice, but this is putting a high risk of breaking and introducing bugs, due to the used init system, which is not supported by upstream. > 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. > Which architectures are you reffering to? > I'm willing to do most of the packaging implementations when a majority > of the team think it's good idea and worth the effort. It's a rather > huge effort and imho not a task for some personal custom repo as it may > affect devtools, infrastructure and maybe more of our core distro. > > This is a huge task which affects most daemon packages and DEs. > If you want to check how some init choice can be implemented I suggest > to start looking at Parabola[4], Hyperbola[5] and [6] Artix Linux forks > first. These are all rather small projects but we being the mother and > true Arch community should have the resources to implement it in a > proper way without any major drawbacks. > I don't think this can be achieved and is worth the hassle it will bring. My 2cents, tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org <http://www.archlinux.org> tp...@archlinux.org Archboot Developer https://bit.ly/archboot St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de i...@st-martin-apo.de
