[arch-general] Alternative init system proposal
Hello, I have a proposal for Arch Linux developers and by mailing on this list I would also appreciate feedback from non-developers that use Arch Linux. Note: I am not here to hate on the current status, nor to disapprove of current Arch choices. So, to get to the point... I would like to propose development and official support of an alternative init system and service manager. My main preference would be OpenRC + sysvinit. The combination of those two has shown to work surprisingly well even with the current Arch's binary packages which are compiled with systemd support/dependencies. There are OpenRC packages already in the AUR, as well as an unofficial repository called "openrc-eudev" that replaces udev with Gentoo's eudev. See http://systemd-free.org for more info. (Please disregard the hate on the website, I am not pro-systemd-hate) Now, I realize this is not the correct way to do this stuff, and if we want an alternative system, a lot of compiling might have to be done, Or is it possible to keep systemd support? 1. Udev... Well, there are two alternatives worth mentioning. The first is, obviously, Gentoo's eudev that works really well, and keeps udev compatibility. Another alternative worth mentioning is vdev (https://github.com/jcnelson/vdev). It is also maintained in the AUR. vdev is developed to be completely non-dependent on systemd and I think it might be a nice option to consider. Note that it is still under development. 2. Packaging... If current and furure builds are kept with systemd support, then there's only the option of including an OpenRC-compatible script in the same package, along with the systemd.service file, and then depending on what's used on the machine, install the according one (in most cases). Otherwise, new compilation will have to be done, and that brings up the issue of storage space, which, in the worst case - gets cut in half. I would need more feedback on this. 2.1. Repositories... core, extra, community and multilib would not need any -openrc offsprings. If we would build new packages, without systemd support, pacman would need code modifications to distinguish between the two - systemd and openrc. An idea is to modify the package naming scheme somehow, possibly -openrc and -systemd. 3. Support... The biggest drawback is definitely the support that goes on in ArchBBS, ArchWiki, Bugtracker and eventually #archlinux on freenode IRC. The ArchBBS and the IRC wouldn't be detriment(?) because they don't really have any *specific* support threads or sections. However, the ArchWiki would need a lot of rewriting/editing, but honestly, the community is big enough to handle it. As for the bugtracker, it might get a bit more bugs than usually :D To conclude, this is still a mere draft and a proposal. I realize that there are a lot more things to be discussed about this. So, please give me feedback on all of this and let's see what we can do about it and what it can develop into... Kind regards to the entire mailinglist, ~ parazyd
On Mon, 8 Feb 2016 01:58:19 +0100 Ivan <parazyd@dyne.org> wrote:
Hello, I have a proposal for Arch Linux developers and by mailing on this list I would also appreciate feedback from non-developers that use Arch Linux. Note: I am not here to hate on the current status, nor to disapprove of current Arch choices. [snip]
The big question you have to answer, the one you need to start with, is: Why is it in the Arch dev's interests to maintain two init systems and that much more area for incompatibility, that many more packages and bugs to wrangle? Especially if they are happy using systemd? Nobody could answer that question a few years ago, so the original Arch initscripts were dropped in favour of a systemd-only distro. If you have a serious answer, by all means, present it — but that *is* the stumbling block here. ~Celti
No. Systemd is here to stay. Maintaining another's init would be a waste of time and too much work. Plus, why on earth would people want to waste time maintaining another init system when the one we have works? Is there anything lacking in systemd that is available in openrc? On Feb 7, 2016 18:11, "Patrick Burroughs (Celti)" <celti@celti.name> wrote:
On Mon, 8 Feb 2016 01:58:19 +0100 Ivan <parazyd@dyne.org> wrote:
Hello, I have a proposal for Arch Linux developers and by mailing on this list I would also appreciate feedback from non-developers that use Arch Linux. Note: I am not here to hate on the current status, nor to disapprove of current Arch choices. [snip]
The big question you have to answer, the one you need to start with, is:
Why is it in the Arch dev's interests to maintain two init systems and that much more area for incompatibility, that many more packages and bugs to wrangle? Especially if they are happy using systemd?
Nobody could answer that question a few years ago, so the original Arch initscripts were dropped in favour of a systemd-only distro.
If you have a serious answer, by all means, present it — but that *is* the stumbling block here.
~Celti
On Sun, 7 Feb 2016 18:30:15 -0700 Devon Smith <devo8604@gmail.com> wrote:
Is there anything lacking in systemd A clear, logical and consistant naming convention for the services, units, etc used by systemd, on a number of occasions I have spent an hour or more looking for the script that controls a particular service. Admittedly there seems to be less of them now than when systemd first invaded. cups is a pet hate of mine, wouldn't 'cupsd' be much more intuitive than 'org.cups.cupsd.service' or am I missing something?
that is available in openrc? probably not.
It's much better to fix whats there and mostly works than go through the trauma of getting to grips with a new mostly works tool. mick
On Mon, 8 Feb 2016 02:37:57 +0000 mick <bareman@tpg.com.au> wrote:
On Sun, 7 Feb 2016 18:30:15 -0700 Devon Smith <devo8604@gmail.com> wrote:
Is there anything lacking in systemd A clear, logical and consistant naming convention for the services, units, etc used by systemd, on a number of occasions I have spent an hour or more looking for the script that controls a particular service. Admittedly there seems to be less of them now than when systemd first invaded. cups is a pet hate of mine, wouldn't 'cupsd' be much more intuitive than 'org.cups.cupsd.service' or am I missing something?
Yeah, pacman -Ql <package> | grep service Should take significantly less than an hour.
On Sun, 7 Feb 2016 20:51:50 -0600 Doug Newgard <scimmia@archlinux.info> wrote:
On Mon, 8 Feb 2016 02:37:57 +0000 mick <bareman@tpg.com.au> wrote:
On Sun, 7 Feb 2016 18:30:15 -0700 Devon Smith <devo8604@gmail.com> wrote:
Is there anything lacking in systemd A clear, logical and consistant naming convention for the services, units, etc used by systemd, on a number of occasions I have spent an hour or more looking for the script that controls a particular service. Admittedly there seems to be less of them now than when systemd first invaded. cups is a pet hate of mine, wouldn't 'cupsd' be much more intuitive than 'org.cups.cupsd.service' or am I missing something?
Yeah, pacman -Ql <package> | grep service
Should take significantly less than an hour.
Now that I know about it, but I still think cupsd.service is more intuitive.
On Mon, Feb 08, 2016 at 03:28:36AM +0000, mick wrote:
On Sun, 7 Feb 2016 20:51:50 -0600 Doug Newgard <scimmia@archlinux.info> wrote:
On Mon, 8 Feb 2016 02:37:57 +0000 mick <bareman@tpg.com.au> wrote:
On Sun, 7 Feb 2016 18:30:15 -0700 Devon Smith <devo8604@gmail.com> wrote:
Is there anything lacking in systemd A clear, logical and consistant naming convention for the services, units, etc used by systemd, on a number of occasions I have spent an hour or more looking for the script that controls a particular service. Admittedly there seems to be less of them now than when systemd first invaded. cups is a pet hate of mine, wouldn't 'cupsd' be much more intuitive than 'org.cups.cupsd.service' or am I missing something?
Yeah, pacman -Ql <package> | grep service
Should take significantly less than an hour.
Now that I know about it, but I still think cupsd.service is more intuitive.
That's why I still use Debian 5 stable in a container as a print server... Cups 2.0+ is a real piece of crap. And yes, these org.xxx.xxx names _are_ stupid especially for filenames. But after using modern Fedoras, I think that systemd services are no longer supposed to be managed manually, but rather through some frontend... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Mon, Feb 8, 2016 at 4:56 AM, Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
That's why I still use Debian 5 stable in a container as a print server... Cups 2.0+ is a real piece of crap. And yes, these org.xxx.xxx names _are_ stupid especially for filenames. But after using modern Fedoras, I think that systemd services are no longer supposed to be managed manually, but rather through some frontend...
On Sun, 07 Feb 2016, Devon Smith wrote:
No. Systemd is here to stay. Maintaining another's init would be a waste of time and too much work. Plus, why on earth would people want to waste time maintaining another init system when the one we have works? Is there anything lacking in systemd that is available in openrc?
systemd isn't going anywhere. I'm not here acting as a GNU preacher or whatever. I do not want to replace systemd, I am merely proposing an alternative to systemd for Arch Linux users. And users do want alternatives. Especially Arch Linux users. After all, to put it simple: Arch was always about control and customization. Why wouldn't users be able to choose their initsystem/servicemanager? Time maintaining for sure would not be wasted. Reading the emails that started as a reply to you might give you some insight. Arch is arguably one of the biggest distributions around today. By offering an alternative init system, the community would undoubtly become even bigger, and eventually, bring in more donations, and support from all kinds of folks. Is there anything lacking in systemd? Honestly, I would say there's too much... ~ parazyd
On Sun, 07 Feb 2016, Patrick Burroughs (Celti) wrote:
The big question you have to answer, the one you need to start with, is:
Why is it in the Arch dev's interests to maintain two init systems and that much more area for incompatibility, that many more packages and bugs to wrangle? Especially if they are happy using systemd?
Nobody could answer that question a few years ago, so the original Arch initscripts were dropped in favour of a systemd-only distro.
If you have a serious answer, by all means, present it — but that *is* the stumbling block here.
I would start by taking out some quotes out of https://wiki.archlinux.org/index.php/Arch_Linux "Arch is installed as a minimal base system, configured by the user upon which their own ideal environment is assembled by installing only what is required or desired for their unique purposes." "Arch Linux has always been, and shall always remain user-centric. The distribution is intended to fill the needs of those contributing to it rather than trying to appeal to as many users as possible." "... it is the user who decides what his system will be." I know everyone always cites this in their anti-systemd rands, but Linux really has always been about choice, and yet all the major distributions seem to embrace the same init system: systemd. Thus, distros are giving up on their "distinctiveness" Now I keep seeing almost all the "big" GNU/Linux embracing nothing but systemd and that's very dissapointing. (Arch) Users aren't picking systemd because it's there and it's perfect, but because there is no other choice, and was to a certain point imposed to them... I am most certainly not going back to the past and referencing the mailinglist discussions where initscrips was dropped in favor of systemd. That was the decision, and I fully respect it. Nevertheless, consider: does Arch really have to *demand* systemd to be the only init system? Not saying it will happen, and this being really farfetched: Eventually the difference between distros seems to boil down to having a different distribution name and a different package manager. It may eventually become impossible to use Linux without also using systemd. For me, and many other communities out there this is not a very pleasant thing. I don't want to impose it here, but I'm sure you are aware of all the init/systemd wars going on... Since 2012, a lot of things happened. systemd gained a lot more traction, maybe even due to the fact Arch implemented it. Note: OpenRC is actively developed since 2007. by developers coming from the Gentoo community. Since then, it has grown into a very big project. As for udev (it was integrated into systemd, and knowing hotplugging is necessary for most users nowadays), The Gentoo developers have forked it and named it eudev. Since then, eudev is also under active development. It provides everything udev does, and doesn't break current udev stuff. I can even personally confirm this, since I use OpenRC and eudev on my personal computer (running Arch Linux, of course) instead of systemd. To those saying "What does OpenRC have that systemd doesn't?": OpenRC isn't made as a clone of systemd. It's a tool for itself, and works the way it's made to work. If you still with to ask that question, note that OpenRC can actually do as much as systemd (possibly even more, but I'm no systemd wizard). Also here is the forum post where tomegun talks about systemd adoption and lists some key points. Feel free to compare it to OpenRC and the tools OpenRC is used with. https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 Anyone willing to discuss this in more depth, feel free to reply. Let's go back to Arch itself, as the distro. As we all know, Arch is built around the KISS principle. (Yes, I know this is contradictory to my request, but also note the beginning of this email) So, the KISS principle... I'm still sticking to OpenRC, and now I will have to make some short notes: * Daemon management is as simple as systemd. As a matter of fact, most (if not all) OpenRC users I've talked to say that it's even simpler than systemd because we can find everything in /etc/init.d/ as opposed to `systemctl edit` and its tmpfiles/overrides. (Again, I'm not a systemd wizard, don't take things for granted) * Simplicity through /etc/init.d helps you fix misconfigured daemons more easily than systemd in case you forgot what you did. (Sort /etc/init.d/* by latest file modification) * "Networking is difficult" - Absolutely not! In fact, even NetworkManager works just fine with OpenRC. With proper packaging, users will not need to do anything. * "It's for power users" - Again, no. While many power users and (older system administrators prefer not using systemd, this does not mean OpenRC is necessarily complicated to use. Quite the opposite, OpenRC makes management very user-friendly and simple. Also, in my case (being shell-literate), I find editing init scripts much better than systemd services, I would dare to say it even offers you more customization. Cliche-time: I would like to mention, through the past 14 years, Arch Linux has evolved into one amazing GNU/Linux distribution and has managed to build a community truly worth mentioning. The developers behind Arch are some very smart people, I would like to believe they have grown to have more than enough experience and capability to maintain an alternatative init system alongside the current one. ~ parazyd
Hi, On Mon, Feb 08, 2016 at 01:58:19AM +0100, Ivan wrote:
1. Udev...
You don't need udev in most cases. For instance, on a workstation, you can simply create device nodes by hand.
2. Packaging...
Not an issue really.
2.1. Repositories... core, extra, community and multilib would not need
People who would be running an alternative init system wouldn't need much support.
I realize that there are a lot more things to be discussed about this.
And here is a can of worms. What are you going to do with logind and various desktop integrations? What about systemd-tmpfiles snippets that do magic in the background? Regarding former, before you say consolekit2, it's not an answer. Yes, systemd may be getting in too many places, but the previous state of affairs was not better (I think everyone would agree that ck is a broken concept). Also, don't forget about wayland. I strongly suspect that it is not going to run without logind. Regarding latter, you'll have to roll out lots of install files in existing packages, even those that have no relation to an init system. You see, by itself, systemd is a stupid and irrelevant piece of software. It is things around it that create real problems... HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sun, 07 Feb 2016, Leonid Isaev wrote:
On Mon, Feb 08, 2016 at 01:58:19AM +0100, Ivan wrote:
I realize that there are a lot more things to be discussed about this.
And here is a can of worms. What are you going to do with logind and various desktop integrations? What about systemd-tmpfiles snippets that do magic in the background?
Regarding former, before you say consolekit2, it's not an answer. Yes, systemd may be getting in too many places, but the previous state of affairs was not better (I think everyone would agree that ck is a broken concept). Also, don't forget about wayland. I strongly suspect that it is not going to run without logind.
While I don't think it's time to debate consolekit yet, I would have to say that it currently is an option. Gnome (being made systemd-dependent) can still be patched to work without systemd. Wayland is also proven to run without systemd. Though I am not sure what will happen with future development (see your last two sentences)...
Regarding latter, you'll have to roll out lots of install files in existing packages, even those that have no relation to an init system.
You see, by itself, systemd is a stupid and irrelevant piece of software. It is things around it that create real problems...
Hypothetically, if Arch Linux was to adopt an alternative init, it's a process that does not happen overnight. Through time, solutions will surface. I'm not a magic lamp genie that has all the answers.
On Mon, Feb 08, 2016 at 06:02:34AM +0100, Ivan wrote:
Hypothetically, if Arch Linux was to adopt an alternative init, it's a process that does not happen overnight. Through time, solutions will surface. I'm not a magic lamp genie that has all the answers.
Then you have to ask yourself, what defines a distribution. If you are going to bring in ck, patch polkit, gnome, kde, xfce, etc, and introduce customizations to lots of other packages, isn't it easier to start from gentoo or alpine and maintain pacman for those distros? I am asking because you are going to duplicate a fair share of official repos... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
I still don't get what makes OpenRC so great. Doesn't it still depend entirely on SysV Init? That ALONE makes me want to keep it off my system. If it makes us fall back on an init system that is frankly backward and was badly in need of replacement then I don't see why it should be considered an alternative. Systemd ain't perfect, but when the best alternative is something that relIes on dated components bona fide Unix systems don't even use anymore, then they simply aren't alternatives. On Feb 7, 2016 11:36 PM, "Leonid Isaev" <leonid.isaev@jila.colorado.edu> wrote:
On Mon, Feb 08, 2016 at 06:02:34AM +0100, Ivan wrote:
Hypothetically, if Arch Linux was to adopt an alternative init, it's a process that does not happen overnight. Through time, solutions will surface. I'm not a magic lamp genie that has all the answers.
Then you have to ask yourself, what defines a distribution. If you are going to bring in ck, patch polkit, gnome, kde, xfce, etc, and introduce customizations to lots of other packages, isn't it easier to start from gentoo or alpine and maintain pacman for those distros? I am asking because you are going to duplicate a fair share of official repos...
Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Mon, 08 Feb 2016, Yaro Kasear wrote:
I still don't get what makes OpenRC so great. Doesn't it still depend entirely on SysV Init? That ALONE makes me want to keep it off my system. If it makes us fall back on an init system that is frankly backward and was badly in need of replacement then I don't see why it should be considered an alternative.
Systemd ain't perfect, but when the best alternative is something that relIes on dated components bona fide Unix systems don't even use anymore, then they simply aren't alternatives.
No, as a matter of fact, OpenRC works with any init. It's not necessary to use sysvinit.
On 02/08/2016 07:27 AM, Yaro Kasear wrote:
I still don't get what makes OpenRC so great. Doesn't it still depend entirely on SysV Init? By default it uses sysvinit as PID1. That's all that it does. If it makes you unhappy you can easily use s6 or runit as PID1 ... or write your own.
That ALONE makes me want to keep it off my system. If it makes us fall back on an init system that is frankly backward and was badly in need of replacement then I don't see why it should be considered an alternative. So far I've never seen sysvinit's PID1 misbehave or crash. No idea why you dislike it so much, but as said above ... No need to use it, it's just a convenient default. Systemd ain't perfect, but when the best alternative is something that relIes on dated components bona fide Unix systems don't even use anymore, then they simply aren't alternatives. Change is not Progress.
Are you, by chance, confusing sysvinit with debian's sysv-rc or something similar?
On Feb 7, 2016 11:36 PM, "Leonid Isaev" <leonid.isaev@jila.colorado.edu> wrote:
Hypothetically, if Arch Linux was to adopt an alternative init, it's a process that does not happen overnight. Through time, solutions will surface. I'm not a magic lamp genie that has all the answers. Then you have to ask yourself, what defines a distribution. If you are going to bring in ck, patch polkit, gnome, kde, xfce, etc, and introduce customizations to lots of other packages, isn't it easier to start from gentoo or alpine and
On Mon, Feb 08, 2016 at 06:02:34AM +0100, Ivan wrote: maintain pacman for those distros? I am asking because you are going to duplicate a fair share of official repos...
Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Wed, Feb 10, 2016 at 10:13:49AM +0100, Patrick Lauer wrote:
Change is not Progress.
Are you, by chance, confusing sysvinit with debian's sysv-rc or something similar?
A lot of people make two huge mistakes in such debates: 1) sysvinit != Debian's initscripts. 2) sysvinit vs systemd is a very bad comparison as well as a false dichotomy. It's ignorance instead of malice most of the time, but it's still sad how people keep arguing over this while knowing *nothing*.
On Sun, 07 Feb 2016, Leonid Isaev wrote:
On Mon, Feb 08, 2016 at 06:02:34AM +0100, Ivan wrote:
Hypothetically, if Arch Linux was to adopt an alternative init, it's a process that does not happen overnight. Through time, solutions will surface. I'm not a magic lamp genie that has all the answers.
Then you have to ask yourself, what defines a distribution. If you are going to bring in ck, patch polkit, gnome, kde, xfce, etc, and introduce customizations to lots of other packages, isn't it easier to start from gentoo or alpine and maintain pacman for those distros? I am asking because you are going to duplicate a fair share of official repos...
Well, for starters, Arch isn't just about pacman. I get the feeling you think it is. For me, the "killer" features of Arch are the AUR and its huge, excellent community. I could just run off and start a new distro, but this is not the point. I realize, and I've talked about it in one of the previous emails where I discussed the way packages could/should be built.
On Mon, Feb 08, 2016 at 01:58:19AM +0100, Ivan wrote:
Hello, I have a proposal for Arch Linux developers and by mailing on this list I would also appreciate feedback from non-developers that use Arch Linux. ...
It's not reasonable to demand Arch devs maintain several init systems. You can pretty easily maintain that out of the main repos for yourself and others. There are several maintained solutions already. http://systemd-free.org details one such solution (openrc + sysvinit). https://wiki.archlinux.org/index.php/Runit there's also runit. https://fleshless.org/pages/spark.html I have a personal solution. And there are others I can't quite remember right now. Let the dev team focus on a stable base and modify it if you need to.
Op 8 feb. 2016 01:59 schreef "Ivan" <parazyd@dyne.org>:
Hello, I have a proposal for Arch Linux developers and by mailing on this list I would also appreciate feedback from non-developers that use Arch Linux. Note: I am not here to hate on the current status, nor to disapprove of current Arch choices.
So, to get to the point... I would like to propose development and official support of an alternative init system and service manager. My main preference would be OpenRC + sysvinit. The combination of those two has shown to work surprisingly well even with the current Arch's binary packages which are compiled with systemd support/dependencies.
I love the idea, even just from a technical pov. However... It may be a bit much to ask from the developers to officially support another init system. That said, how about a archbang-like approach? Archbang is basically Archlinux and uses the Arch packages. I could imagine the same sort of approach, perhaps offering custom packages and/or add-ons where necessary. This approach gives users a simple way to choose (and possibly switch!), while giving developers an easier way to experiment with options. Where things work without too much overhead, they could be incorporated into Arch, whereas packages with compatibility problems could be confined to this specific projects repositories. Perhaps I'm being ignorant here and has this approach already been tried. If so, my apologies. Mvg, Guus Snijders
On Mon, 08 Feb 2016, Guus Snijders wrote:
Op 8 feb. 2016 01:59 schreef "Ivan" <parazyd@dyne.org>:
Hello, I have a proposal for Arch Linux developers and by mailing on this list I would also appreciate feedback from non-developers that use Arch Linux. Note: I am not here to hate on the current status, nor to disapprove of current Arch choices.
So, to get to the point... I would like to propose development and official support of an alternative init system and service manager. My main preference would be OpenRC + sysvinit. The combination of those two has shown to work surprisingly well even with the current Arch's binary packages which are compiled with systemd support/dependencies.
I love the idea, even just from a technical pov. However... It may be a bit much to ask from the developers to officially support another init system.
That said, how about a archbang-like approach? Archbang is basically Archlinux and uses the Arch packages. I could imagine the same sort of approach, perhaps offering custom packages and/or add-ons where necessary.
This approach gives users a simple way to choose (and possibly switch!), while giving developers an easier way to experiment with options. Where things work without too much overhead, they could be incorporated into Arch, whereas packages with compatibility problems could be confined to this specific projects repositories.
Perhaps I'm being ignorant here and has this approach already been tried. If so, my apologies.
Mvg, Guus Snijders
Definitely not a bad idea, but I would need a team that would help me maintain it. All Arch Linux packages are compiled with systemd support, so lots of recompiling and package editing would need to be done.
Hi Ivan, On Tue, Feb 9, 2016 at 9:17 AM, Ivan <parazyd@dyne.org> wrote:
That said, how about a archbang-like approach? <snip> Definitely not a bad idea, but I would need a team that would help me maintain it. All Arch Linux packages are compiled with systemd support, so lots of recompiling and package editing would need to be done.
Almost all packages depend on libsystemd only and that is just a wrapper that allows applications to use systemd if available and do something else if not. So the amount of work should be manageable, if that library does not bother your sense of aesthetics. Best Regards, Tobias
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 A note about using shell scripts in systemd: Who said you can't? and I don't talk about systemd's init.d compatibility that is disabled in arch. Although you have to write unit files, you can start scripts, so you do not really lose flexibility. Also systemd's isolation capabilities are superior, there are some things you currently cannot do from scripts, like PrivateTmp=yes and stuff. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWuhNFAAoJEHb1CzgxXKwYiZAQAI5CCNULoGoCJfp+faXV+huN xOCtuJ1M4AcjJW1TE412HcLn2rB9fo6NEE/IDHbe1HogksKFQX59qVKmKh6Xesq2 V26/4lHrLJPRIX0Tr99tRGeXkz3fofHmCmfErvz2gMbCw1Qq8BVx8fbPGIxi9Vm/ nAn4x0mexFNPPz9l1P27mGPUBjpUvKJtUcvk8BzH2oTskRJiYeZ3kkpEXP2dib6t bWZMeihYnQ11jynX38tZwZQltjZLuyITBnrT0TZb1sTSnTjLWWEW5ggNgr0ZOtcp M1Z5ZvgMaVUGXa7rkFo5nR9Jt8HMdi58R380kmU8+TTaaMHMTAKdaWI6hZim9hFG vNTO0jvBTv4KIOVuwZj2zAbC7MPcSVenBK2WE+M1tJlqtmheqDcj7DE1YY6dos9m OJ87ZE1iVK9IHSr3pwPqxif2ZZzUNJa2LsD6EnIk/WocfF1/VIee/nphdQepUWjv A7cTREyUc4sFlqGiDkCfDU3iDldv5m/tQcvTBmtjp2P2PJ4rrpJAcHI7jRna8mlY jV9fUmUjTPrkmzfEdRHVBLaiFhHPaql4sJ0Htu728Pie9/OsiN3CncpdtD/vy2Gh aG/8VEMkM3a+3YmjCSXZmSj/bphXcsYSdOcHQdst0cuHnmu5ST0+W0nmFsvI0WcI v6lnh0nSuyqfedIkZzW8 =QNfn -----END PGP SIGNATURE-----
Op 9 feb. 2016 17:27 schreef "Michał Zegan" <webczat_200@poczta.onet.pl>:
A note about using shell scripts in systemd: Who said you can't? and I don't talk about systemd's init.d compatibility that is disabled in arch. Although you have to write unit files, you can start scripts, so you do not really lose flexibility. Also systemd's isolation capabilities are superior, there are some things you currently cannot do from scripts, like PrivateTmp=yes and stuff.
Isolation is AFAIK based on cgroups, not the easiest subject, but certainly not impossible to implement. PrivateTmp: Does that more then setting $TEMP to a custom value? I'm just being curious here. Mvg, Guus Snijders
On 9 February 2016 at 17:34, Guus Snijders <gsnijders@gmail.com> wrote:
Op 9 feb. 2016 17:27 schreef "Michał Zegan" <webczat_200@poczta.onet.pl>:
A note about using shell scripts in systemd: Who said you can't? and I don't talk about systemd's init.d compatibility that is disabled in arch. Although you have to write unit files, you can start scripts, so you do not really lose flexibility. Also systemd's isolation capabilities are superior, there are some things you currently cannot do from scripts, like PrivateTmp=yes and stuff.
Isolation is AFAIK based on cgroups, not the easiest subject, but certainly not impossible to implement.
not impossible, if you reimplement systemd :)
PrivateTmp: Does that more then setting $TEMP to a custom value?
I'm just being curious here.
yes, it creates a filesystem/mount namespace for the process(es) and mount's a /tmp/systemd-private-xxxx/ directory as /tmp. from the point of view of the process it will never see anything else from the outer /tmp -- damjan
Op 9 feb. 2016 17:52 schreef "Damjan Georgievski" <gdamjan@gmail.com>:
On 9 February 2016 at 17:34, Guus Snijders <gsnijders@gmail.com> wrote:
Op 9 feb. 2016 17:27 schreef "Michał Zegan" <webczat_200@poczta.onet.pl :
Although you have to write unit files, you can start scripts, so you do not really lose flexibility. Also systemd's isolation capabilities are superior, there are some things you currently cannot do from scripts, like PrivateTmp=yes and stuff.
Isolation is AFAIK based on cgroups, not the easiest subject, but
certainly
not impossible to implement.
not impossible, if you reimplement systemd :)
;)
PrivateTmp: Does that more then setting $TEMP to a custom value?
I'm just being curious here.
yes, it creates a filesystem/mount namespace for the process(es) and mount's a /tmp/systemd-private-xxxx/ directory as /tmp. from the point of view of the process it will never see anything else from the outer /tmp
Ok, that is a nice trick. Mvg, Guus Snijders
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The isolation is not fully cgroup based, also cgroups require/prefer a single manager, this is going to be enforced in kernel someday, so it is better for init to do it as it is a parent of everything. PrivateTmp uses namespaces, so it is a real isolation. same with PrivateNetwork, ProtectSystem, etc. I do not say that you cannot do this from script, but you would have to make cmdline utilities for some of those things, so it is currently not possible. W dniu 09.02.2016 o 17:34, Guus Snijders pisze:
Op 9 feb. 2016 17:27 schreef "Michał Zegan" <webczat_200@poczta.onet.pl>:
A note about using shell scripts in systemd: Who said you can't? and I don't talk about systemd's init.d compatibility that is disabled in arch. Although you have to write unit files, you can start scripts, so you do not really lose flexibility. Also systemd's isolation capabilities are superior, there are some things you currently cannot do from scripts, like PrivateTmp=yes and stuff.
Isolation is AFAIK based on cgroups, not the easiest subject, but certainly not impossible to implement.
PrivateTmp: Does that more then setting $TEMP to a custom value?
I'm just being curious here.
Mvg, Guus Snijders
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWuhmOAAoJEHb1CzgxXKwYns8P/24XkWt9vC/Sngfmcgkjc77I IFjshUljV5sVO4oOHvDb4oPQcPIsACc24feN1pvy/MNtWdeMJJg2MyFYmNy9GkYc z3WqnRr+pFbQZWCCbdtMIvshvJi141DBrPSVoI1T6hfD0wR3ptkHh0n72bcH1HTH VkkjfhAsz4V7i6G8Bt4vOK89kjPKQJF1HieBPiUNZgNBjbhoq/1Nv5jfCW47Dvgl TA3gXJlSAshkCGdogL0WqFyzA/78MDQ3x90DfdLITZ7Yk/G0bpNM9Lk6MJbW/y3E eNnfy8S/D9TcTE5k4ST6DBl3XSLMbr3HlxSUmme+0sfDa4BUz5asTmgMYrdZ5Zfl DIReoDvgld2BEK2sgKk2BkQPPmnblZ7OwDLYPC8QmWCWBzIESshHWgYs0Ditsq8N f3Q15Cj6QDALfxYTlk3TasQ2DRul6S8wFwotEktGYO9Gvi9ktWoFhaVGem1hBB6X 7p3kdEzrwOXQvfqOxqblzPQpTu/0FS9LxRwRcNCKqtqgi6MuRcWeVcKw8pBBJeKe QJudU7pXvjbwovZzPKEfmL2RsJ4Cb+PFR6nnRUUkXjuCfDj69l5LbnnijnLf4U34 ofJYo2MSSlqqjR+MaSUo8DNbZcTmRaVq8TsnUHZHoRbhOPgXKYr4B9HXG3lwSCmF YoP+zd75A/xB51DnVoHq =3gQy -----END PGP SIGNATURE-----
On Tue, 9 Feb 2016 17:26:57 +0100, Michał Zegan wrote:
A note about using shell scripts in systemd: Who said you can't? and I don't talk about systemd's init.d compatibility that is disabled in arch. Although you have to write unit files, you can start scripts, so you do not really lose flexibility.
I'm doing this. However, if you remove and mount cards, in my case just audio related, not network related cards, then even network device names are not consistent. It's not a serious issue, you just need to decide to use one or the other workaround, but some users who have portable scripts, perhaps dislike to check all scripts against systemd/udev pitfalls. [rocketmouse@archlinux ~]$ grep enp?s0 /usr/local/sbin/alice-dhcp echo ; dhcpcd $(basename $(ls -d /sys/class/net/enp?s0)) ; echo echo ; dhcpcd -x $(basename $(ls -d /sys/class/net/enp?s0)) ; echo
Hello everone, First of all I want to remind you that systemd is no longer an init system. Systemd has become to be much more than just starting/stopping some daemons. You must see systemd with every part. You cannot just strip systemd from every package, ignore the other parts of systemd and run openRC. This will not work. This is just one part.. the other part is: I don't think that the Arch Linux developers would be happy if they would need to maintain an alternative init system like openRC. Here are some reasons for it: 1. Maintaining: The maintaining of systemd and another init-system would be a lot of double work. We would need every package twice. One systemd version and one version without systemd. Moreover some packages like netctl depend on systemd. You cannot just repackage netctl without systemd. You would have to change the codebase of netctl. Moreover I think that the developer team has other work todo. For example I would prefer to have full SELinux support this would be for me much more important as another init system. 2. Arch Linux itself: When I think about Arch Linux i must think about: - rolling release - a very fast release system. Upstream version == package version in the official repositories. What does this mean? It means that I prefer a linux distribution that supports the newest changes in the linux development. Systemd is one of thesee changes. Systemd improves a lot of stuff. There is a reason why all other big distribtions are also moving to systemd. It's the future. All the shellscript-based init systems are the past. Also, with systemd comes a lot of new cool stuff like cgroups, systemd-nspawn, networkd, logind and a lot more. I really think that Arch Linux shouldn't be a rock in this flow of development. We should do it like fedora and support it. We shouldn't help to tube-fed all other init systems. Furthermore there will be (maybe) kdbus in the kernel. Kdbus is at the moment still systemd only. I am sure there will come more systemd-specific interfaces for the kernel. Kdbus is just one example. 3. The ISO and Arch Linux installation process If Arch Linux would support openRC we would have to offer two ISOs. One with systemd and one with openRC. Also the way of the installation process would be different. We would need to edit all wikipages. I often hear that the Arch Linux wiki is one of the best wikis for GNU/Linux. I think this would change if we would have a second init system. We would have a lot of chaos. And for what? Only for making 'some' people happy. This is just my humble opinion, best regards, chris -------------------------------------------------------------- Christian Rebischke Website : www.nullday.de Twitter : @sh1bumi Jabber : shibumi@jabber.ccc.de PGP : 0xDFE2060D Fingerprint: 6DAF 7B80 8F9D F251 3962 0000 D214 61E3 DFE2 060D --------------------------------------------------------------
On Tue, Feb 09, 2016 at 10:33:55PM +0100, Christian Rebischke wrote:
Hello everone, First of all I want to remind you that systemd is no longer an init system. Systemd has become to be much more than just starting/stopping some daemons. You must see systemd with every part. You cannot just strip systemd from every package, ignore the other parts of systemd and run openRC. This will not work. This is just one part..
You actually can get systemd out and something else to do parts of what it does. Most packages depend not on systemd, but on libsystemd and will happily just *not use it* if systemd is not present. I've been using such a system (Arch with systemd and some other stuff never put in) and it has been fine.
the other part is: I don't think that the Arch Linux developers would be happy if they would need to maintain an alternative init system like openRC.
Here are some reasons for it:
1. Maintaining: The maintaining of systemd and another init-system would be a lot of double work. We would need every package twice. One systemd version and one version without systemd. Moreover some packages like netctl depend on systemd. You cannot just repackage netctl without systemd. You would have to change the codebase of netctl.
1) See my previous point. 2) I think you have to be completely mad to demand Arch devs rewrite netctl to support something other than systemd. It depends on systemd. If you choose not to use systemd, just use some other method of network configuration.
Moreover I think that the developer team has other work todo. For example I would prefer to have full SELinux support this would be for me much more important as another init system.
2. Arch Linux itself: When I think about Arch Linux i must think about: - rolling release - a very fast release system. Upstream version == package version in the official repositories.
What does this mean? It means that I prefer a linux distribution that supports the newest changes in the linux development. Systemd is one of thesee changes. Systemd improves a lot of stuff. There is a reason why all other big distribtions are also moving to systemd. It's the future. All the shellscript-based init systems are the past.
As another person on here said, change is not progress. It's new, but it's debatabe if it's a net positive.
Also, with systemd comes a lot of new cool stuff like cgroups, systemd-nspawn, networkd, logind and a lot more.
cgroups are not systemd-specific. systemd-nspawn is just another container solution, it's not the only one. networkd is just a network configurator, we have hundreds of those. logind is actually *needed* in a number of cases while doing nothing in others.
I really think that Arch Linux shouldn't be a rock in this flow of development. We should do it like fedora and support it. We shouldn't help to tube-fed all other init systems.
Furthermore there will be (maybe) kdbus in the kernel. Kdbus is at the moment still systemd only. I am sure there will come more systemd-specific interfaces for the kernel. Kdbus is just one example.
A detour from the point of this discussion, but I don't think that's a good thing that the kernel might actually depend on systemd in some ways.
3. The ISO and Arch Linux installation process If Arch Linux would support openRC we would have to offer two ISOs. One with systemd and one with openRC.
What? Why? Having a handful of new packages in the repos doesn't mean anything has to change. If you want to be extra nice about it, then maybe a separate base group (base-openrc or something), but not a separate iso.
Also the way of the installation process would be different.
Not by much. You're overestimating the whole thing greately.
We would need to edit all wikipages. I often hear that the Arch Linux wiki is one of the best wikis for GNU/Linux. I think this would change if we would have a second init system. We would have a lot of chaos. And for what? Only for making 'some' people happy.
This is just my humble opinion,
best regards,
chris
Now all that said, I still won't advocate for the Arch devs to actually support configs other than the current base. All the things I just wrote should clue you in that it's pretty easy to maintain a system without systemd without any official support for it beyond the systemd/libsystemd split (thank you, devs, btw, it made my life so much easier!). Let the Arch team focus on providing a solit base to build upon and modify to your needs. The reason I felt the need to address the point in this email is I'm tired of the overwhelming ignorance about the topic from people discussing it. It's staggering.
On 02/10/2016 12:53 PM, Jack L. Frost wrote:
On Tue, Feb 09, 2016 at 10:33:55PM +0100, Christian Rebischke wrote:
What does this mean? It means that I prefer a linux distribution that supports the newest changes in the linux development. Systemd is one of thesee changes. Systemd improves a lot of stuff. There is a reason why all other big distribtions are also moving to systemd. It's the future. All the shellscript-based init systems are the past.
As another person on here said, change is not progress. It's new, but it's debatabe if it's a net positive.
"change is not progress" has no bearing on whether systemd is a net positive or not. The person you responded to explicitly said -- in the very part you quoted, no less! -- "systemd improves a lot of stuff", so clearly they're _not_ relying on the fallacious reasoning of "change = progress"... so why bring it up unless you're just being argumentative for no good reason?
I really think that Arch Linux shouldn't be a rock in this flow of development. We should do it like fedora and support it. We shouldn't help to tube-fed all other init systems.
Furthermore there will be (maybe) kdbus in the kernel. Kdbus is at the moment still systemd only. I am sure there will come more systemd-specific interfaces for the kernel. Kdbus is just one example.
A detour from the point of this discussion, but I don't think that's a good thing that the kernel might actually depend on systemd in some ways.
Other way around: systemd may at some future point depend on a Linux-only IPC protocol. (One assumes that this would be indirectly via a DBUS-like client library, but whatever...) (Kind of ironic considering your point about ignorance.)
3. The ISO and Arch Linux installation process If Arch Linux would support openRC we would have to offer two ISOs. One with systemd and one with openRC.
What? Why? Having a handful of new packages in the repos doesn't mean anything has to change. If you want to be extra nice about it, then maybe a separate base group (base-openrc or something), but not a separate iso.
Also the way of the installation process would be different.
Not by much. You're overestimating the whole thing greately.
There's a huge difference between "I maintain systemd-free systems for my own use" and "I maintain packages for a very popular distribution". The latter has to work in a huge number of cases you haven't thought of. Anyway, can we please end this thread now? It's not constructive. Regards,
Other way around: systemd may at some future point depend on a Linux-only IPC protocol. (One assumes that this would be indirectly via a DBUS-like client library, but whatever...)
My brain went completely derp there, so yeah, disregard that statement.
On Wed, Feb 10, 2016 at 04:44:34PM +0100, Bardur Arantsson wrote:
"change is not progress" has no bearing on whether systemd is a net positive or not. The person you responded to explicitly said -- in the very part you quoted, no less! -- "systemd improves a lot of stuff", so clearly they're _not_ relying on the fallacious reasoning of "change = progress"... so why bring it up unless you're just being argumentative for no good reason?
I am replying to the statement that “systemd is the future, everything else is the past”. It's made with one vague argument: “systemd improves a lot of stuff”, which is pretty much equivalent to “it changes things, so it's better”. If you're making grand statements like “X is better than everything else”, you better be prepared to provide evidence for that.
There's a huge difference between "I maintain systemd-free systems for my own use" and "I maintain packages for a very popular distribution". The latter has to work in a huge number of cases you haven't thought of.
I was saying that the installation procedure doesn't change much. Yes, I agree that the number of possible points where stuff might go wrong increases when you add new variables. That's specifically why I don't like the idea of putting it on the shoulders of the Arch maintainers. If you want a flavour of Arch that does things a bit differently, then make one. I did, it works great for me and a few others.
Anyway, can we please end this thread now? It's not constructive.
Agreed. The question of “should the Arch team maintain several bases” was answered many times, and it's always “no”. Arch is so flexible and nice to work with that it's not in any way useful to multiply their workload.
On Mon, Feb 8, 2016 at 12:58 AM, Ivan <parazyd@dyne.org> wrote:
Hello, I have a proposal for Arch Linux developers and by mailing on this list I would also appreciate feedback from non-developers that use Arch Linux. Note: I am not here to hate on the current status, nor to disapprove of current Arch choices.
So, to get to the point... I would like to propose development and official support of an alternative init system and service manager. My main preference would be
snip
me feedback on all of this and let's see what we can do about it and what it can develop into...
This kind of long-running, and in the end pointless, discussion that has developed in recent days, on this ML, was the underlying reason for a huge and extended set of threads on a number of linux forums a few years ago, including on the Fedora Forums, that led a significant number of users to unsubscribe from those forums because they did not want their inboxes filled up with discussions that looked increasingly like they were going nowhere. At the end of the day the arch developers made the decision to support systemd as the arch linux daemon and initialisation software. They have devoted their time to make arch linux a beautifully efficient distribution keeping to the "Arch Way", and with the most efficient of package manager compared to most other linux distros. It is likely no surprise that a number of senior kernel developers use arch linux rather than other distributions. The required systemd packages were made available to the arch repos, advice on transisioning to systemd for those on other inits broadcast, and over time all of the necessary unit files and support structures were put in place, keeping arch close to upstream, and the current arch linux system works exceptionally well on a huge range of different types of hardware. Users are free to write their own unit files or to adapt the default unit files (and I do this in a few cases too where I want behaviour to match my own needs). My systems (both laptops and desktops) start up quickly and, like many users, I am very happy with the performance of my arch linux installed machines. It is tough enough for TUs to voluntarily keep the packages in the repos as close to current upstream as they do already, and adding an unnecessary layer of additional support for a small percentage of the user base who wish to have a second init system available, because they think it is better than systemd, is not a proposal that looks like it would get majority support even if there are a few people who continue to flood the mailing list with ongoing thread postings about this. Perhaps those who wish to pursue the alternative init idea could do so in private on a separate mailing list devoted to that topic alone and any interested parties can of course freely join in that discussion if they should wish to do so. The number of users who subscribe to that specific ML would be a gauge of any real interest from significant numbers of users. If that turns out to be a small handful of people only, then that would be at least some evidence of the level of support for that proposal. However filling people's inboxes with this discussion I suspect is not being found valuable by quite a few people I expect. Anyone is of course free to develop the proposed alternative init system for their own use, or form their own developer subgroup, and could provide their own repos if they wish, and anyone wanting to use the alternative can then do so. I certainly see many helpful concise and brief threads that seek to resolve or inform in a way that is digestible. However long running flame wars between systemd antagonists and supporters is counter-productive. The real question is whether or not any TUs or developers think that this is worthy of further investigation or not. Users who wish to volunteer to do the work can of course make themselves known. -- mike c
It is tough enough for TUs to voluntarily keep the packages in the repos as close to current upstream as they do already, and adding an unnecessary layer of additional support for a small percentage of the user base who wish to have a second init system available, because they think it is better than systemd, is not a proposal that looks like it would get majority support even if there are a few people who continue to flood the mailing list with ongoing thread postings about this.
Perhaps those who wish to pursue the alternative init idea could do so in private on a separate mailing list devoted to that topic alone and any interested parties can of course freely join in that discussion if they should wish to do so. The number of users who subscribe to that specific ML would be a gauge of any real interest from significant numbers of users. If that turns out to be a small handful of people only, then that would be at least some evidence of the level of support for that proposal. However filling people's inboxes with this discussion I suspect is not being found valuable by quite a few people I expect.
Anyone is of course free to develop the proposed alternative init system for their own use, or form their own developer subgroup, and could provide their own repos if they wish, and anyone wanting to use the alternative can then do so.
I certainly see many helpful concise and brief threads that seek to resolve or inform in a way that is digestible. However long running flame wars between systemd antagonists and supporters is counter-productive. The real question is whether or not any TUs or developers think that this is worthy of further investigation or not. Users who wish to volunteer to do the work can of course make themselves known. I agree with you, the devs have more work to do, etc., but the cause of these never-ending discussions must be pointed out: community attitude. Bear with me for a moment:
OpenRC was working fine in Arch. Artoo's way was the most updated and way to run it. Then some users thought: "Very tiny number of Arch users use OpenRC and they have to choose from two methods" (actual quote). I came for Linux because of choice! Why would they be bothered to remove information on something that worked? Saying it "breaks often"? It's bleeding edge! And it seldom breaks. Users in the forums just want to know why a version isn't working, why can't we host that type of content? What's wrong with people? Artoo was pushed far enough to leave Arch, now there are no AUR packages for OpenRC. Please, just let people be. Accept the possibility of different stuff and opinions, instead of trying to make everyone conform to what you think they should do/use/choose/write... João Miguel
On 11-02-16 17:12, João Miguel wrote:
now there are no AUR packages for OpenRC.
You are wrong, please be more specific. This is current situation: - run AL without using systemd as PID1 / init system : Aur and AL wiki have everything you need for that. You will still have systemd installed and use udev from it. (i am one of the AL users that uses this setup on my laptop and desktop) - remove systemd completely from AL : Some people do that, but documentation how to do this was removed from wiki. The aur packages that helped with this setup were removed by the creator/maintainer. Lone_Wolf
now there are no AUR packages for OpenRC. You are wrong, please be more specific. Sorry, I mean Artoo's way is no longer available in the AUR. openrc-core and all init srcipts he posted are gone (because of the bad community pressure, which was my point).
This is current situation:
- run AL without using systemd as PID1 / init system : Aur and AL wiki have everything you need for that. Apg's way. Many people were using Artoo's. You will still have systemd installed and use udev from it.
- remove systemd completely from AL : Some people do that, but documentation how to do this was removed from wiki. For no good reason (confirming my point). See it from my perspective: I'm using eudev, openrc-core, never had trouble, then suddenly all documentation and packages just disappear.
The aur packages that helped with this setup were removed by the creator/maintainer. Again, because of a community pressure, he was peacefully contributing before. If some people didn't push him to do things their way, he would've happily stayed contributing packages to the AUR which were better documented than some official ones. No dev/TU work required. Just people accepting other people.
It's ok now not because of the wiki and the AUR, but thanks to the existence of systemd-free.org. It had to be created because of the above, which would'nt have happened with a better community. João Miguel
It's ok now not because of the wiki and the AUR, but thanks to the existence of systemd-free.org. It had to be created because of the above, which would'nt have happened with a better community.
So far I've not seen anyone in this thread, or in the replies by Poettering referenced by systemd-free.org as "Arrogance and crappy attitude", actually pressure anyone into doing (or not doing) anything. Choices have been made based on what those making the choices think is sane, and you are free to undo that choice at any time. What/who in "the community" motivates even having this endless discussion when the (in MHO excellent) choice to package systemd by default has already been made and it works perfectly well? If something was removed from the Wiki for "no good reason", just add it back, or put systemd-free.org up as a reference and be done with it.
It's ok now not because of the wiki and the AUR, but thanks to the existence of systemd-free.org. It had to be created because of the above, which would'nt have happened with a better community.
So far I've not seen anyone in this thread, or in the replies by Poettering referenced by systemd-free.org as "Arrogance and crappy attitude", actually pressure anyone into doing (or not doing) anything. Choices have been made based on what those making the choices think is sane, and you are free to undo that choice at any time. What/who in "the community" motivates even having this endless discussion when the (in MHO excellent) choice to package systemd by default has already been made and it works perfectly well? I never said systemd shouldn't be packaged by default!
If something was removed from the Wiki for "no good reason", just add it back, or put systemd-free.org up as a reference and be done with it. Someone already talked about putting it back in the forums. They were turned down because of those points («no reason for 2 methods», etc.). This among other things (which are evident in any discussion in Arch about OpenRC) signals a bad community. There were many great users that stopped using Arch because of this, it is a problem that needs to be recognized. I don't anything near this kind of attitude, say, in Gentoo mailing lists.
João Miguel
Someone already talked about putting it back in the forums. They were turned down because of those points («no reason for 2 methods», etc.). This among other things (which are evident in any discussion in Arch about OpenRC) signals a bad community.
When it comes to Linux there are often many ways to accomplish the same goal. On the Arch wiki we try, wherever possible, to only mention the "right way" of doing things. Solutions that fix a particular problem while making other things worse are removed. The difficulty with OpenRC is that it is very hard to replace systemd without a) replacing a lot of packages, b) significantly complicating system maintenance and, c) straight up breaking your system; so when it comes to choosing the "right way" to replace systemd with OpenRC, the answer isn't clear. Alad made the call that apg's approach was "better" than artoo's and so removed artoo's from the wiki article. I can understand how that might be frustrating for some users, but please try to see how this isn't some systemd conspiracy to stifle users choice and this isn't a sign of a bad community. It's simply a matter of providing a single clear set of instructions on the wiki for users who wish to switch to OpenRC. Is the systemd-free approach better? I don't know, but Alad seems to think that it was causing a significant number of problems for many users on the forums. Can we stop you from using alternative means of switching to OpenRC? Nope! If you want to make OpenRC easier to use on Arch, here's how: 1. Get more involved in the AUR to develop more/better OpenRC-specific packages 2. Draft a new OpenRC wiki article on your User page 3. Work on 1 and 2 until you feel like you have a clearly superior method 4. Open a discussion on the OpenRC talk page about replacing the article (this will most likely involved discussion on your User page as well on how to improve your draft) 5. Success Max
I had asked Nous and Artoo whether it was worth placing those packages back in the AUR, and they said it wasn't, so I gave up. But maybe systemd-free.org can be referred instead of the AUR. About "the right way", I'm not sure it's true, for example, the Wiki lists at least 3 ways to use an nvidia graphic card. Nonetheless, what you said does sound like a good idea. Thank you. João Miguel
If you want to make OpenRC easier to use on Arch, here's how: 1. Get more involved in the AUR to develop more/better OpenRC-specific packages There are 4 mirrors for an unnoficial user repository with packages that are officially used in Manjaro. 2. Draft a new OpenRC wiki article on your User page Done. https://wiki.archlinux.org/index.php/User:JMCF125/OpenRC 3. Work on 1 and 2 until you feel like you have a clearly superior method The method already existed, I just wanted to make it visible. 4. Open a discussion on the OpenRC talk page about replacing the article (this will most likely involved discussion on your User page as well on how to improve your draft) 5. Success Or in this case, failure: https://wiki.archlinux.org/index.php?title=Talk:OpenRC&oldid=420556
Max
João Miguel
There are 4 mirrors for an unnoficial user repository with packages that are officially used in Manjaro.
3. Work on 1 and 2 until you feel like you have a clearly superior method The method already existed, I just wanted to make it visible.
I think you misunderstood. I was not suggesting that you simply re-add the information to the wiki with different wording. artoo's method was already rejected from the wiki for several reasons as pointed out on the talk page. If you find the current method on the wiki lacking, then you will need to come up with some new method that both improves on the wiki's method and avoids the pitfalls of artoo's. Again, this is not about lack of choice. This is about a particular choice being deemed unfit for the wiki. Any method that *relies* on an unofficial repository (i.e. has no AUR alternative) is certainly not appropriate. Max
There are 4 mirrors for an unnoficial user repository with packages that are officially used in Manjaro.
3. Work on 1 and 2 until you feel like you have a clearly superior method The method already existed, I just wanted to make it visible.
I think you misunderstood. I was not suggesting that you simply re-add the information to the wiki with different wording. In the Wiki, Alad said the problem were the instructions at systemd-free.org. He talked about FUD, so I supposed he was simply looking for something with a neutral point of view, suitable for the Wiki.
artoo's method was already rejected from the wiki for several reasons as pointed out on the talk page. If you find the current method on the wiki I pointed out the "several reasons" were not nearly enough to remove a legitimate and well supported method. lacking, then you will need to come up with some new method that both improves on the wiki's method and avoids the pitfalls of artoo's. But what are the pitfalls? (I do mean this question in good faith. Pointing out bugs in a package once in a while is not an answer.) That it needs to replace lots of packages? It replaces systemd as service manager, but systemd is not just that, lots of things depend on it and need to be patched, and in fact are *already* patched.
Note: no work from *anyone* is being asked here, just a place in the Wiki to document the method. All improvement welcome. Alad is considering respiranto's suggestion (thank you, I wouldn't have thought of breaking it in 2). FWIW, I have installed OpenRC with Artoo's method several times and never had any trouble.
Again, this is not about lack of choice. This is about a particular choice being deemed unfit for the wiki. Any method that *relies* on an unofficial repository (i.e. has no AUR alternative) is certainly not appropriate. Then I shall contact Artoo and add the packages back to the AUR as Nous suggested. Though I don't see how a repository officially trusted by Manjaro is less trusted than the AUR. Nevertheless, I do like the AUR, and packages being there might help.
Have a good day, João Miguel
On 14-02-16 17:17, João Miguel wrote:
Then I shall contact Artoo and add the packages back to the AUR as Nous suggested. Though I don't see how a repository officially trusted by Manjaro is less trusted than the AUR. Nevertheless, I do like the AUR, and packages being there might help. Have a good day, João Miguel
Not long ago Artoo renamed his manjaro packages to openrc without any discusssion with apg or apg openrc users. Before artoo packages can be put back in AUR, that naming conflict needs to be solved. Even if that naming conflict were resolved, the division in the small AL openrc community would continue to exist. Maybe the AL users wanting to remove systemd completely could investigate if switching from openrc artoo way to openrc apg way is possible ? Lone_Wolf Active user of openrc apg way co-maintainer of apg openrc (since this weekend)
A 2016-02-14T23:13:44 +0100, LoneVVolf escreveu:
On 14-02-16 17:17, João Miguel wrote:
Then I shall contact Artoo and add the packages back to the AUR as Nous suggested. Though I don't see how a repository officially trusted by Manjaro is less trusted than the AUR. Nevertheless, I do like the AUR, and packages being there might help. Have a good day, João Miguel
Not long ago Artoo renamed his manjaro packages to openrc without any discusssion with apg or apg openrc users. It was after he was asked to remove his pakages from the AUR and after a discussion in the Manjaro forums
Before artoo packages can be put back in AUR, that naming conflict needs to be solved. FWIW, there are currently at least 13 packages in the AUR (found by searching and reading PKGBUILDs) from different people that install init scripts to /etc/init.d and not Apg's /etc/openrc/init.d.
Even if that naming conflict were resolved, the division in the small AL openrc community would continue to exist. I think the easiest way to unite efforts would be to forget /etc/openrc. I see that you want to avoid a conflict with initscripts, but if you installed to /etc as Artoo, you'd be closer to upstream (Gentoo). I'm ok with any directory, but I don't see the point in using /etc/openrc; who uses both initscripts-fork and openrc, except for testing purposes? Maybe you could change the default of that SYSCONFDIR variable to /etc, and have the rare users of both systems change it to /etc/openrc (they could get a warning in a post-install file or something like that).
Maybe the AL users wanting to remove systemd completely could investigate if switching from openrc artoo way to openrc apg way is possible ? I wouldn't put it off the chart, but note that users in Manjaro and those of systemd-free.org already have binaries for Artoo's way, so a middle ground between the ways, starting with identifying the differences and figuring which way is best for each of those, would be preferred IMHO.
Lone_Wolf
Active user of openrc apg way co-maintainer of apg openrc (since this weekend) Thank you for you efforts in maintaining an alternative, they are very much appreciated.
Regards, João Miguel
On 15-02-16 16:54, João Miguel wrote:
A 2016-02-14T23:13:44 +0100, LoneVVolf escreveu:
On 14-02-16 17:17, João Miguel wrote:
Then I shall contact Artoo and add the packages back to the AUR as Nous suggested. Though I don't see how a repository officially trusted by Manjaro is less trusted than the AUR. Nevertheless, I do like the AUR, and packages being there might help. Have a good day, João Miguel Not long ago Artoo renamed his manjaro packages to openrc without any discusssion with apg or apg openrc users. It was after he was asked to remove his pakages from the AUR and after a discussion in the Manjaro forums I guess you mean the discussion here: https://forum.manjaro.org/index.php?topic=27333.0 ?
Everyone (interested) can read that and draw their own conclusion about what happened. personally, i'm ok with "agreeing to disagree" on that subject.
Before artoo packages can be put back in AUR, that naming conflict needs to be solved. FWIW, there are currently at least 13 packages in the AUR (found by searching and reading PKGBUILDs) from different people that install init scripts to /etc/init.d and not Apg's /etc/openrc/init.d.
Even if that naming conflict were resolved, the division in the small AL openrc community would continue to exist. I think the easiest way to unite efforts would be to forget /etc/openrc. I see that you want to avoid a conflict with initscripts, but if you installed to /etc as Artoo, you'd be closer to upstream (Gentoo). I'm ok with any directory, but I don't see the point in using /etc/openrc; who uses both initscripts-fork and openrc, except for testing purposes? Maybe you could change the default of that SYSCONFDIR variable to /etc, and have the rare users of both systems change it to /etc/openrc (they could get a warning in a post-install file or something like that).
Maybe the AL users wanting to remove systemd completely could investigate if switching from openrc artoo way to openrc apg way is possible ? I wouldn't put it off the chart, but note that users in Manjaro and those of systemd-free.org already have binaries for Artoo's way, so a middle ground between the ways, starting with identifying the differences and figuring which way is best for each of those, would be preferred IMHO. using /etc/openrc makes it easy to use multiple init systems on 1 machine, i think that is a good thing. There is another good reason for it though : Let's assume at some point in the future an arch developer or TU considers adding openrc/udev-alternatives to community repo. They will look into the existing packages and check if they are high enough quality.
From arch packaging standards : *Configuration files* should be placed in the |/etc| directory. If there is more than one configuration file, it is customary to *use a subdirectory* in order to keep the |/etc| area as clean as possible. Use |/etc/{pkgname}/| where |{pkgname}| is the name of the package (or a suitable alternative, eg, apache uses |/etc/httpd/|). I feel in this specific case following arch packaging standards is more important then using the same path for configuration files as gentoo. I've checked recent openrc init.d servicefiles, and it appears they work fine in any location provided openrc can find them. If artoo way users want to stick to using /etc : we can use an environment variable, say _OPENRC_SYSCONFDIR . the openrc packages could set this var to the correct location. Packages providing additional openrc services can then use that var to determine where they should install the files. That would allow sharing of servicefiles.
Lone_Wolf
Active user of openrc apg way co-maintainer of apg openrc (since this weekend) Thank you for you efforts in maintaining an alternative, they are very much appreciated.
Regards, João Miguel Thank you. Your posts in this thread convinced me it was worth the effort to re-try to bring artoo & apg way closer together.
Lone_Wolf
It seems we've come to an understanding in this thread, which is great. But I would recommend further OpenRC development be discussed elsewhere (perhaps aur-general or the PKGBUILD requests subforum?). Thanks, Max
.... when the (in MHO excellent) choice to package systemd by default has already been made and it works perfectly well? I never said systemd shouldn't be packaged by default!
Apologies, poor wording on my part. That wasn't meant to imply you ever did. I understood you wanted an alternative, not a replacement. I meant more to emphasize that they only wanted one init system by default and the reasoning for denying your request just seemed clear and simple.
If something was removed from the Wiki for "no good reason", just add it back, or put systemd-free.org up as a reference and be done with it. Someone already talked about putting it back in the forums. They were turned down because of those points («no reason for 2 methods», etc.).
So, a decision was made that one method was better than the other by someone who felt confident enough to remove the other one. I would personally prefer if there was only one method listed if I was to ever attempt such a big task myself, so that's fine by me. I have no experience with either method so in the technicalities about which metod was better I will trust the person who made the call. If I knew the removed method had major advantages, I would either add the information back and make the [dis]advantages of them clearer, and perhaps include some guidance to why the reader gets to see two methods. Or, put the information somewhere else and add the link instead. This among other things (which are evident in any discussion in Arch
about OpenRC) signals a bad community.
Being told the reason for removal is that the wiki should be focused on one way to accomplish things isn't a sign of a bad community. It's a sign that people care about the wiki stays being focused on offering a clear way to accomplish something.
There were many great users that stopped using Arch because of this, it is a problem that needs to be recognized.
I don't personally know anyone else using Arch, or anyone who ever did, so I can't tell why they stopped using Arch. If they stopped using Arch because of a disagreement with the distribution maintainers' decisions, they've likely stopped for the same reason anyone else ever stopped using a distribution. The maintainers' decisions take the distribution to where it's going, more or less influenced by user opinions. If your opinions aren't matched, you leave. Nothing more to it. If there was an argument of some kind (I really have no idea since I don't care), that's between those parties. I don't anything near this kind of attitude, say, in Gentoo
mailing lists.
I have no experience with the Gentoo lists either, but I doubt this list is any different in tone as it's pretty much the same anywhere you go, online or offline. It's perhaps not not overly friendly and more to the point than some other things I follow, but I don't see any reason to read more into what anyone writes here than that.
I feel it pertinent to point out that a different rolling-release distrobution ( http://www.voidlinux.eu/ ) does not use systemd, openrc, or sysvinit. Void Linux uses runit exclusively, and thus patches projects like KDE4 and Gnome3 to work without systemd (I don't mention KDE5 since nobody has cared enough yet to put in the effort). It is possible to run a modern linux distro without systemd, still be user friendly, and have reasonably updated packages.
On 02/12/2016 11:50 PM, Toyam Cox wrote:
I feel it pertinent to point out that a different rolling-release distrobution ( http://www.voidlinux.eu/ ) does not use systemd, openrc, or sysvinit. Void Linux uses runit exclusively, and thus patches projects like KDE4 and Gnome3 to work without systemd (I don't mention KDE5 since nobody has cared enough yet to put in the effort).
Well, that's *amazing*... what does it mean for me, the user? I can only re-iterate: Can we please stop this thread?
I feel it pertinent to point out that a different rolling-release distrobution ( http://www.voidlinux.eu/ ) does not use systemd, openrc, or sysvinit. Void Linux uses runit exclusively, and thus patches projects like KDE4 and Gnome3 to work without systemd (I don't mention KDE5 since nobody has cared enough yet to put in the effort). Well, that's *amazing*... what does it mean for me, the user? To me, the user, it means I there is a possibility for an alternative init system without the devs having to do anything. It means there are people out there working on this and work towards alternatives does not need to start from scratch. You're on Linux: you ought not to be only a user, but also a contributor, thus "voting" with your actions. That's why you're on a mailing list, or at least why I am.
I can only re-iterate: Can we please stop this thread? I deleted the first half of it. I think it may turn out to be productive now. Void Linux is a distribution besides Gentoo we can base off to allow different init systems to be used.
Regards, João Miguel
On 02/13/2016 04:17 PM, João Miguel wrote:
I feel it pertinent to point out that a different rolling-release distrobution ( http://www.voidlinux.eu/ ) does not use systemd, openrc, or sysvinit. Void Linux uses runit exclusively, and thus patches projects like KDE4 and Gnome3 to work without systemd (I don't mention KDE5 since nobody has cared enough yet to put in the effort). Well, that's *amazing*... what does it mean for me, the user? To me, the user, it means I there is a possibility for an alternative init system without the devs having to do anything. It means there are people out there working on this and work towards alternatives does not need to start from scratch. You're on Linux: you ought not to be only a user, but also a contributor, thus "voting" with your actions. That's why you're on a mailing list, or at least why I am.
I don't think you've presented any plausible "use case" except "I want to be different" -- which is fine, btw, but shouldn't drive development decisions in the large. I mean, if you really want to you can still write your own /sbin/init, but I'm not seeing the point here. (If your goal is to *learn*, then yes $DEITY yes, do that, but for practical things... you need some more concrete and tangible goals to challenge the decision of systemd-only for Arch Linux.) Regards,
(If your goal is to *learn*, then yes $DEITY yes, do that, but for practical things... you need some more concrete and tangible goals to challenge the decision of systemd-only for Arch Linux.) The decision was to have systemd as a default, not to forbid any other init system to be mentioned. I don't agree with the OP of this thread when he said there should be an official version of Arch with OpenRC, that's too much work.
I mean this: https://wiki.archlinux.org/index.php/User:JMCF125/OpenRC should be here: https://wiki.archlinux.org/index.php/OpenRC. So that this: http://systemd-free.org/ is not necessary, but instead just a nice plus. Best regards, João Miguel
On 02/13/2016 05:35 PM, João Miguel wrote:
(If your goal is to *learn*, then yes $DEITY yes, do that, but for practical things... you need some more concrete and tangible goals to challenge the decision of systemd-only for Arch Linux.) The decision was to have systemd as a default, not to forbid any other init system to be mentioned
Again... no "use case" apart from "I don't want to use systemd". . I don't agree with the OP of this thread
when he said there should be an official version of Arch with OpenRC, that's too much work.
OK, so thread over? Regards,
On Sat, Feb 13, 2016 at 05:58:38PM +0100, Bardur Arantsson wrote:
Again... no "use case" apart from "I don't want to use systemd".
That seems like a reasonable use case to me. My previous desktop box ran Arch. After setting it up Arch switched to systemd. When it came time to upgrade to a new desktop box I switched to Gentoo because I didn't want to use systemd. If the Arch devs had given users a choice of a systemd alternative I probably would have stuck with Arch. I was recently impressed with Arch. I fired up my retired desktop PC after it had been shut down for about a year. I wanted to see of Kodi would run well enough on it to use it as a Kodi box. I had to remove a couple of packages I didn't need any more, and delete a couple of files to work around some conflicts, but after that pacman updated something like 800 packages without a hitch. I love most things about pacman, except some of its naming conventions. Synchronizing a package to install it never made sense to me. Back when I was using Arch regularly I ended up creating a wrapper script that called pacman, package-query, yaourt, pacaur, etc., depending on what I was doing. So on my Arch box, applying updates usually looks something like: pdr update pdr lu pdr upgrade The second command lists updates. I usually like to list what's going to be updated including old and new version numbers before updating. Anyway, if I use the old box as a Kodi box I'll probably stick with Arch on it, at least for a while. There are a lot of things I miss about Arch. -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz http://www.WacoAgilityGroup.org Bruceville, TX What's the definition of a legacy system? One that works! Errare humanum est, ignoscere caninum.
On 2016-02-13 17:35, João Miguel wrote:
The decision was to have systemd as a default, not to forbid any other init system to be mentioned. I don't agree with the OP of this thread when he said there should be an official version of Arch with OpenRC, that's too much work.
I mean this: https://wiki.archlinux.org/index.php/User:JMCF125/OpenRC should be here: https://wiki.archlinux.org/index.php/OpenRC. So that this: http://systemd-free.org/ is not necessary, but instead just a nice plus.
Best regards, João Miguel
I agree with you on the point, that the possibility of choice should not be suppressed, but instead be welcome on the Wiki. However, I also see how having two ways of doing something rather unusual and officially unsupported may create notable confusion or at least makes the article hard to read. Hence I would suggest creating a totally new Wiki entry which explains solely artoo's way, named e.g. 'OpenRC (eudev)'. To prevent identical sections of both articles, your one should only address the differences, i.e. sections 1{,.3} (Installation and Booting) and 2.3 (Network) and some notes on further differences. Obviously, the two articles should point to each other as a respective alternative.
Just throwing this out there: Given nosh's support for importing systemd units, that one might be another viable option.
On Thursday, February 11, 2016 4:12:24 PM CST João Miguel wrote:
I agree with you, the devs have more work to do, etc., but the cause of these never-ending discussions must be pointed out: community attitude. Bear with me for a moment:
OpenRC was working fine in Arch. Artoo's way was the most updated and way to run it. Then some users thought: "Very tiny number of Arch users use OpenRC and they have to choose from two methods" (actual quote). I came for Linux because of choice! Why would they be bothered to remove information on something that worked? Saying it "breaks often"? It's bleeding edge! And it seldom breaks. Users in the forums just want to know why a version isn't working, why can't we host that type of content? What's wrong with people? Artoo was pushed far enough to leave Arch, now there are no AUR packages for OpenRC.
Please, just let people be. Accept the possibility of different stuff and opinions, instead of trying to make everyone conform to what you think they should do/use/choose/write...
:) The question comes from me. The full question is: "Very tiny number of Arch users use OpenRC and they have to choose from two methods. Why? Could they be unified into just one?"[1] When I ask the question, each section of Openrc wiki page is seperated into two ways. There is no comparsing of the two. Even as a three years gentoo daily user, I could not grasp why there need two methods. So the why is just a '''plain''' why. I want to know more info and add the to the wiki. I am sorry if my words make you feel that I want to kill choice. Just want you to know my real intention. I hope Arch openrc users could settle down on the difference and unite together to win more. With my ArchWiki admin hat on: The removal of artoo way is announced in advance and wating for objection for more than one month. No one reply. So it is removed. This is the same process as any other wiki pages. Archwiki is open to anyone after all, so if you really want to add artoo way back, here is my suggestion: 1. Create a seperately page about openrc artoo way. 2. Explain the difference between the two ways. Give their advantage and disadvantage so reader's could make their own choice. 3. Add a link to artoo way in the openrc main page. Fengchao [1] - https://wiki.archlinux.org/index.php?title=Talk:OpenRC&oldid=390102
João Miguel
Sorry if I was too harsh. But the methods are for fundamentally different purposes, apg's intends to remain compatible with systemd and is backed up by the AUR, while artoo's intends to replace systemd and has its own repositories elsewhere. AFAIK, artoo tried to convince apg to join forces, with no success. So 2 methods remain, each with their merits. However, as you say, it's true it wasn't clear in the original article why were there 2 methods. So I copied the article before the edit that removed artoo's method to a sandbox [1]. Then I'll add new info from the current article and finally present in the discussion page reasons for it to be added back as it will be in the sandbox. I think a sandbox is necessary because the original article with artoo's way is too much out of date and incomplete. Thank you for understanding, João Miguel [1] - https://wiki.archlinux.org/index.php/User:JMCF125/OpenRC
participants (27)
-
Bardur Arantsson
-
Carsten Mattner
-
Chao Feng
-
Christian Rebischke
-
Damjan Georgievski
-
Devon Smith
-
Doug Newgard
-
Guus Snijders
-
Henrik Danielsson
-
Ivan
-
Jack L. Frost
-
Jan Alexander Steffens
-
João Miguel
-
Kevin Monceaux
-
Leonid Isaev
-
LoneVVolf
-
Maxwell Anselm
-
Michał Zegan
-
mick
-
Mike Cloaked
-
Patrick Burroughs (Celti)
-
Patrick Lauer
-
Ralf Mardorf
-
respiranto
-
Tobias Hunger
-
Toyam Cox
-
Yaro Kasear