I would prefer to not start such discussions with abstract concepts about freedom, philosophy and vague issues users might have with systemd. As already stated, systemd provides tools that solve a lot more problems than simply starting a few daemons in a defined order. Our discussion should start about alternative tools that offer solutions to issues which cannot be handled by systemd or are in a way superior in their implementation. Most arguments I have read about these projects barely apply to Arch (e.g. embedded devices, containers or non-Linux kernels) or simply state not being systemd.
Greetings, Pierre On Sat, Dec 17, 2022 at 10:15 AM Tobias Powalowski <tobias.powalow...@googlemail.com> wrote: > > 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 > 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 -- Pierre Schmitz, https://pierre-schmitz.com
