Re: RFC - thoughts about Arch and init freedom?
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
Re: RFC - thoughts about Arch and init freedom?
On 12/20/22 at 10:23am, Morten Linderud wrote: > On Tue, Dec 20, 2022 at 01:52:02AM +, Connor Behan wrote: > > > > 1. Put openrc in [community] which I have used on my laptop for two years > > without issue. > > 2. Make it depend on systemd (so it is clear we are not packaging eudev) > > and make installation print a warning that users of netctl and devtools > > will need to find alternatives. > > 3. Put openrc-arch-services in [community] as well, > > 4. Bugs for these two packages will be assigned to one of the three people > > who've expressed interest (Andreas, TJ and myself). > > I think you are being overly optimistic if you only expect bugs though. > > The openrc-arch-services has not been developed by anyone for 10 years and I > doubt Andrew is picking it up again based off on this discussion. If the three > of you intend to support this project you can start by adopting the project > from > Andrew and make a plan of you intend to maintain it? 7.5 years, thank you, stop trying to make me feel even older! I honestly could not care less about the pro/cons of systemd vs openrc or any other pid 1, init, service manager, whatever. We have at least 3 developers with an interest in working toward adding software to our repositories as an alternative to what we officially support. It's not like we have a policy of picking a single provider for services and refusing any alternatives. We have several kernels, desktop environments, shells, etc, etc, etc. Much of the resistance to non-systemd pid 1 seems to be the fact that for some reason a number of people on the internet have chosen to express their personal distaste for systemd in some very unhealthy ways over the years. I would consider using that as a reason for refusing to allow members of our team to put energy into a project an equally unhealthy response. The plan laid out above does not require any broad changes or effort from other developers. Only time will tell whether the interested developers will ultimately have the time and energy to maintain the required components on their own, but that's true anytime somebody adds something new to the repos. When I first ported OpenRC to Arch, upstream was competent and responsive and the process was generally pretty smooth and I'm glad to hear it's still working. I stopped maintaining the services mostly because I didn't want to merge scripts untested or take the time to test dozens of scripts for services I didn't actually use. Honestly, I don't know that we really need to provide scripts. For the foreseeable future, nothing else is going to have the same level of support as systemd; I think it's perfectly reasonable to tell users who choose to use an alternative to write their own service scripts. It's been several years now since I've used OpenRC, but I'd be happy to see it in the repos as long as it can still be done without needing invasive distro-wide changes. apg
