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)" wrote:

On Mon, 8 Feb 2016 01:58:19 +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. 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 Mon, 8 Feb 2016 02:37:57 +0000 mick wrote:

On Sun, 7 Feb 2016 18:30:15 -0700 Devon Smith 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 Mon, Feb 08, 2016 at 03:28:36AM +0000, mick wrote:

On Sun, 7 Feb 2016 20:51:50 -0600 Doug Newgard wrote:

...

On Mon, 8 Feb 2016 02:37:57 +0000 mick wrote:

...

On Sun, 7 Feb 2016 18:30:15 -0700 Devon Smith 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 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 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 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 Mon, 08 Feb 2016, Guus Snijders wrote:

Op 8 feb. 2016 01:59 schreef "Ivan" :

...

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.

-----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-----

On 9 February 2016 at 17:34, Guus Snijders wrote:

Op 9 feb. 2016 17:27 schreef "Michał Zegan" :

...

...

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

-----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" :

...

...

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-----

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 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,

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.

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

...

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? 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

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

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

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)

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

...

.... 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.

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?

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,

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 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.

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