RFC - thoughts about Arch and init freedom?
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.
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.
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.
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.
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.
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.
PS: Please leave out all emotions about hating or loving systemd. I'm trying to do so as well.
-Andy
[1]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... [2]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... [3]https://www.devuan.org/os/init-freedom [4]https://wiki.parabola.nu/Repositories#nonsystemd [5]https://wiki.hyperbola.info/doku.php?id=en:philosophy:systemd_denial [6]https://wiki.artixlinux.org/Main/Installation
[6]
On Fri, Dec 16, 2022 at 10:46 PM Andreas Radke andyrtr@archlinux.org wrote:
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.
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.
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.
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.
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.
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.
PS: Please leave out all emotions about hating or loving systemd. I'm trying to do so as well.
-Andy
Hi, I was a Trusted User when we migrated to systemd and I think it's the good choice...
Right now, we have lots of packages that depends, directly or indirectly, on systemd (for example udev or gnome) and, often, if you want to support a non-systemd system you need to re-build the package with different configure options (or to apply some unofficial patch in some cases) and this is, I think, against, the concept of KISS ArchLinux always had. Moreover, does it means the package maintainer should also write the init files for the packages that only ship systemd service files?
Just my 2 cents.
[1]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... [2]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... [3]https://www.devuan.org/os/init-freedom [4]https://wiki.parabola.nu/Repositories#nonsystemd [5]https://wiki.hyperbola.info/doku.php?id=en:philosophy:systemd_denial [6]https://wiki.artixlinux.org/Main/Installation
[6]
On Fri, Dec 16, 2022 at 10:46:12PM +0100, Andreas Radke wrote:
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.
Arch never had support for more than one init, and implementing this support would be a new feature. The BSD-style init stuff is still in a repository managed by Tom for those curious about this historical thing.
https://github.com/teg/initscripts-arch
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.
This is a faux argument. "unix philosophy" is a principle used for the core unix tooling and was never intended as a guiding principle in software development. How this is an argument against systemd is beyond me and mostly recycled garbage from the anti-systemd crowd.
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.
Who are these people?
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.
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.
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.
Whats the goal? Feature parity with the existing packages? Would we need to seek solutions to common problems solved by systemd which is not solved by other init systems?
Would "choosing another init" imply that the systemd library shouldn't be installed on the system?
The level of complexity and demands depends widely on how you would like to implement this support. And there is not enough information here to judge that accurately.
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.
Artix blindly copies their init-scripts from other distributions like Void, Gentoo and Alpine. They are not a reliable source of any information.
(They have also started blindly copying over our package sources and remove attribute along with it which has left me with a very bad taste for the maintainers.)
Hyperbola I have no opinions and Parabola has largely been nice people to work with.
PS: Please leave out all emotions about hating or loving systemd. I'm trying to do so as well.
It would help if you didn't recite poor arguments from a lot of the anti-systemd crowd though...
tl;dr:
Generally my opinion on this is lukewarm, the effort can't be worth it unless there is an explicit plan on what "init-freedom" actually entails and how you actually intend to support it. We can't even properly support multiple architectures, and I find it hard to believe we can support multiple inits.
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.
That's unfortunately quite common in the Linux space now, but systemd is for sure the worst offender.
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.
Whenever I've pitched Arch to users of other Linuxes or BSDs, the main (or only) complaint is often that it's "a systemd distro." Then Artix gets brought up and promptly rejected for being a much smaller project with fewer developers and users, making it less appealing for anything but casual/hobbyist use. Having a supported alternative on proper Arch would make a lot of people happy.
I'd be very supportive of exploring this possibility from both a security perspective and to promote freedom of choice, but I expect you'll get much more pushback and complaining than support...
Am Fr., 16. Dez. 2022 um 22:46 Uhr schrieb Andreas Radke < andyrtr@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
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.powalowski@googlemail.com wrote:
Am Fr., 16. Dez. 2022 um 22:46 Uhr schrieb Andreas Radke andyrtr@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 tpowa@archlinux.org Archboot Developer https://bit.ly/archboot
St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info@st-martin-apo.de
On Fri, 16 Dec 2022 22:46:12 +0100 Andreas Radke andyrtr@archlinux.org said:
I think various others have said what I would say, so I'll just say +1 to "stay with systemd only". My summary: It's just not worth the effort for the gain to do multiple init systems and is un-Arch like to do this because it certainly does not KISS.
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.
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.
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.
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.
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.
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.
PS: Please leave out all emotions about hating or loving systemd. I'm trying to do so as well.
-Andy
[1]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... [2]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... [3]https://www.devuan.org/os/init-freedom [4]https://wiki.parabola.nu/Repositories#nonsystemd [5]https://wiki.hyperbola.info/doku.php?id=en:philosophy:systemd_denial [6]https://wiki.artixlinux.org/Main/Installation
[6]
Andreas Radke andyrtr@archlinux.org on Fri, 2022/12/16 22:46:
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. [...]
I remember these days, though I was a regular user back then. :)
The biggest argument again systemd is its complexity. Some people do prefer simple init systems with init scripts.
Let's recap: Sure, systemd is complex, but it is well maintained (IMHO). Generally it works well. The benefit is that systemd units can be written quite easily, at least basic ones. Issues are easy to fix, things just work. In contrast to that the complexity comes from the init scripts with the other init systems. For each of them, again and again. Syntax errors, race conditions, what ever.
And please note that systemd provides a lot of security features (limiting privileges, presenting read-only filesystems, ...) for its services. It's nearly impossible to implement this with init scripts, so system security would drop a lot.
Just adding another init system to the repositories is the easy part. Properly supporting it is anything between hard and impossible. I think this would result in a huge amount of issue regarding broken or missing init scripts, for all of us. (Well, at least anybody maintaining a daemon of any kind.) I am not convinced this is a good idea. More the opposite.
On Mon, Dec 19, 2022 at 8:01 AM Christian Hesse list@eworm.de wrote:
Andreas Radke andyrtr@archlinux.org on Fri, 2022/12/16 22:46:
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. [...]
I remember these days, though I was a regular user back then. :)
The biggest argument again systemd is its complexity. Some people do prefer simple init systems with init scripts.
I agree. Wanting the most capable init system and wanting a more
lightweight init system both sound like legitimate arguments.
Let's recap: Sure, systemd is complex, but it is well maintained (IMHO). Generally it works well. The benefit is that systemd units can be written quite easily, at least basic ones. Issues are easy to fix, things just work. In contrast to that the complexity comes from the init scripts with the other init systems. For each of them, again and again. Syntax errors, race conditions, what ever.
Many bugs of this type were filed in Flyspray. If we go back to having
initscripts as the default (which no one is suggesting) they are sure to come back. The mere availability of another init system in the repos though will probably cause much less of a headache.
There are versions of init freedom which would be too much work as people have rightly pointed out. So let me make a concrete proposal.
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).
On Tue, Dec 20, 2022 at 01:52:02AM +0000, Connor Behan wrote:
- 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?
On 12/20/22 at 10:23am, Morten Linderud wrote:
On Tue, Dec 20, 2022 at 01:52:02AM +0000, Connor Behan wrote:
- 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
Hey,
On 20/12/2022 02:52, Connor Behan wrote:
On Mon, Dec 19, 2022 at 8:01 AM Christian Hesse <list@eworm.de mailto:list@eworm.de> wrote:
Andreas Radke <andyrtr@archlinux.org <mailto:andyrtr@archlinux.org>> on Fri, 2022/12/16 22:46: > 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. [...] I remember these days, though I was a regular user back then. :) The biggest argument again systemd is its complexity. Some people do prefer simple init systems with init scripts.I agree. Wanting the most capable init system and wanting a more lightweight init system both sound like legitimate arguments.
How is OpenRC more "capable" or lightweight? Seems a bit of a strange claim, as most systemd components are optional. IIRC Alpine is looking into switching to an s6 fork as service management [1] [2]
Let's recap: Sure, systemd is complex, but it is well maintained (IMHO). Generally it works well. The benefit is that systemd units can be written quite easily, at least basic ones. Issues are easy to fix, things just work. In contrast to that the complexity comes from the init scripts with the other init systems. For each of them, again and again. Syntax errors, race conditions, what ever.Many bugs of this type were filed in Flyspray. If we go back to having initscripts as the default (which no one is suggesting) they are sure to come back. The mere availability of another init system in the repos though will probably cause much less of a headache.
There are versions of init freedom which would be too much work as people have rightly pointed out. So let me make a concrete proposal.
- Put openrc in [community] which I have used on my laptop for two
years without issue.
Sure, but that's one test point. I can point out multiple packages which does not work on openrc.
- 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.
Not supporting devtools is kinda a problem as it's a big part of our distribution. Not being able to follow the official development workflow on OpenRC is kinda a big deal.
- Put openrc-arch-services in [community] as well,
- Bugs for these two packages will be assigned to one of the three
people who've expressed interest (Andreas, TJ and myself).
Right, so we add something "unofficial" as alternative to our repositories and as it's an initsystem this is a big deal.
Some software will just not work with OpenRC, for example Cockpit is hard tied to systemd. The openrc-arch-services repository lacks profiles or how they are named for most of the software in our repository. I for example am not going to add openrc support to Grafana. [3]
If OpenRC is in the repositories users will expect packagers to add support, and will ask in our support channels about OpenRC.
So in essence I find this whole proposal rather naive and I am a bit saddened by the FUD in this thread.
If you want to run OpenRC, we have the AUR which is the perfect place for something unsupported in my opinion. You might run into issues getting support from our support staff then however.
[1] https://skarnet.com/projects/service-manager.html [2] https://ariadne.space/2021/03/25/lets-build-a-new-service-manager-for-alpine... [3] https://gitweb.gentoo.org/repo/gentoo.git/tree/www-apps/grafana-bin/files/gr...
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
On Tue, 20 Dec 2022 14:05:34 +0100 David Runge dave@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
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.
Some have asked about technical layout variants:
What would you expect from freedom of init choice? A half way means to offer at least one 2nd choice for pid1 and a 2nd init system and keep systemd for the other tasks it tries to serve. This would still not offer a true choice for the additional systemd parts if you don't trust or simply don't want anything systemd related on your system or just want the full freedom to use tools by your own choice.
To achieve such a full systemd replacement as some desktop and userland applications depend on functions you cannot split out of systemd anymore there's need to add (e)udev+elogind packages to the repos.
I see two ways an Arch based distro can achieve full (systemd-less) freedom:
1) go with the current repo layout and use extensively libprovides and virtual providers and split systemd further down into useful parts and make it less monolithic allowing user to choose desired parts or not. Then make anything possible only depend on provided libs/virtual providers that can be served by replacements tools as well.
2) add a replacing [nonsystemd] repo above [core] to pacman.conf that users can enable if desired. Packages in the nonsystemd repo provide some of the systemd functions. The systemd and core packages probably wouldn't need major changes.
Either choice would need a decision whether all service initscripts get packaged into one e.g. openrc-service-scripts package or if each service package ships the scripts for all supported init choices in one single package or split out the systemd/initscripts into subpackages.
If this is still Arch and KISS is actually questionable but being forced to have full systemd on my system doing its magic isn't KISS either and I'm afraid systemd is going worse over time (just my opinion and expectation).
Maybe there's some middle way to bring down systemd to its essential parts and leave it up to AUR and custom repos to build something on top of that.
While I've received some support here on the list and more off the list it seems a majority of the core team is against adding some init freedom support at this time.
-Andy
participants (13)
-
Andreas Radke
-
Andrew Gregory
-
Brett Cornwall
-
Carsten Haitzler
-
Christian Hesse
-
Connor Behan
-
David Runge
-
Jelle van der Waa
-
Morten Linderud
-
Pierre Schmitz
-
T.J. Townsend
-
Timothy Redaelli
-
Tobias Powalowski