[arch-general] Alternative init system proposal

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

[Patrick Burroughs (Celti)]

On Mon, 8 Feb 2016 01:58:19 +0100

Post by 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.
[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

[Devon Smith]

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?

Post by Patrick Burroughs (Celti)
On Mon, 8 Feb 2016 01:58:19 +0100

Post by 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.
[snip]

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

[mick]

On Sun, 7 Feb 2016 18:30:15 -0700

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

[Doug Newgard]

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

Post by mick
On Sun, 7 Feb 2016 18:30:15 -0700

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.

[mick]

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

Post by Doug Newgard
On Mon, 8 Feb 2016 02:37:57 +0000

Post by mick
On Sun, 7 Feb 2016 18:30:15 -0700

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.

[Leonid Isaev]

Post by mick
On Sun, 7 Feb 2016 20:51:50 -0600

Post by Doug Newgard
On Mon, 8 Feb 2016 02:37:57 +0000

Post by mick
On Sun, 7 Feb 2016 18:30:15 -0700

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,

[Jan Alexander Steffens]

On Mon, Feb 8, 2016 at 4:56 AM, Leonid Isaev

Post by Leonid Isaev
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...

http://cockpit-project.org/

[Ivan]

Post by Devon Smith
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

[Ivan]

Post by Patrick Burroughs (Celti)
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

[Leonid Isaev]

Hi,

Post by Ivan
1. Udev...

You don't need udev in most cases. For instance, on a workstation, you can
simply create device nodes by hand.

Post by Ivan
2. Packaging...

Not an issue really.

Post by Ivan
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.

Post by Ivan
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,

[Ivan]

Post by Leonid Isaev

Post by Ivan
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)...

Post by Leonid Isaev
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.

[Leonid Isaev]

Post by Ivan
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,

[Yaro Kasear]

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.

Post by Leonid Isaev

Post by Ivan
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

[Ivan]

Post by Yaro Kasear
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.

[Patrick Lauer]

Post by Yaro Kasear
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.

Post by Yaro Kasear
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.

Post by Yaro Kasear
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?

Post by Yaro Kasear

Post by Leonid Isaev

Post by Ivan
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

[Jack L. Frost]

Post by Patrick Lauer
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*.

[Ivan]

Post by Leonid Isaev

Post by Ivan
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.

[Jack L. Frost]

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

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.

[Guus Snijders]

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

[Ivan]

Post by Guus Snijders

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

[Tobias Hunger]

Hi Ivan,

Post by Ivan

Post by Guus Snijders
That said, how about a archbang-like approach?

<snip>

Post by Ivan
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

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

[Guus Snijders]

Post by Michał Zegan
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

[Damjan Georgievski]

Post by Guus Snijders

Post by Michał Zegan
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 :)

Post by Guus Snijders
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

[Guus Snijders]

Post by Damjan Georgievski

Post by Guus Snijders

Post by Michał Zegan
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 :)

;)

Post by Damjan Georgievski

Post by Guus Snijders
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

[Michał Zegan]

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.

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

[Ralf Mardorf]

Post by Michał Zegan
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.

[***@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

[Christian Rebischke]

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 : ***@jabber.ccc.de
PGP : 0xDFE2060D
Fingerprint: 6DAF 7B80 8F9D F251 3962 0000 D214 61E3 DFE2 060D
--------------------------------------------------------------

[Jack L. Frost]

Post by Christian Rebischke
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.

Post by Christian Rebischke
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.
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.

Post by Christian Rebischke
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.
- 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.

Post by Christian Rebischke
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.

Post by Christian Rebischke
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.

Post by Christian Rebischke
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.

Post by Christian Rebischke
Also the way of the installation process would be different.

Not by much. You're overestimating the whole thing greately.

Post by Christian Rebischke
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.

[Bardur Arantsson]

Post by Jack L. Frost

Post by Christian Rebischke
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?

Post by Jack L. Frost

Post by Christian Rebischke
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.)

Post by Jack L. Frost

Post by Christian Rebischke
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.

Post by Christian Rebischke
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,

[Jack L. Frost]

Post by Bardur Arantsson
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.

[Jack L. Frost]

Post by Bardur Arantsson
"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.

Post by Bardur Arantsson
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.

Post by Bardur Arantsson
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.

[Mike Cloaked]

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

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.

[João Miguel]

Post by Mike Cloaked
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

[LoneVVolf]

Post by João Miguel
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

[João Miguel]

Post by LoneVVolf

Post by 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).

Post by LoneVVolf
Aur and AL wiki have everything you need for that.

Apg's way. Many people were using Artoo's.

Post by LoneVVolf
You will still have systemd installed and use udev from it.
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.

Post by LoneVVolf
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

[Henrik Danielsson]

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

[João Miguel]

Post by Henrik Danielsson

Post by 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!

Post by Henrik Danielsson
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

[Maxwell Anselm]

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

[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

[João Miguel]

Post by Maxwell Anselm
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.

Post by Maxwell Anselm
2. Draft a new OpenRC wiki article on your User page

Done. https://wiki.archlinux.org/index.php/User:JMCF125/OpenRC

Post by Maxwell Anselm
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.

Post by Maxwell Anselm
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

Post by Maxwell Anselm
Max

João Miguel

[Maxwell Anselm]

Post by João Miguel
There are 4 mirrors for an unnoficial user repository with packages that
are officially used in Manjaro.

Post by Maxwell Anselm
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

[João Miguel]

Post by Jack L. Frost

Post by João Miguel
There are 4 mirrors for an unnoficial user repository with packages that
are officially used in Manjaro.

Post by Maxwell Anselm
3. Work on 1 and 2 until you feel like you have a clearly superior

method

Post by João Miguel
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.

Post by Jack L. Frost
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.

Post by Jack L. Frost
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.

Post by Jack L. Frost
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

[Maxwell Anselm]

Post by João Miguel
Though I don't see how a repository officially trusted by
Manjaro is less trusted than the AUR.

They are completely different. An unofficial repository of non-AUR packages
is for installing binary packages that have no affiliation with Arch Linux.
I think it's pretty obvious why that would not be an appropriate
recommendation on the Arch Linux wiki.

The AUR lets users view the PKGBUILD before installing and also to comment
and vote in order to establish trust. This is why wiki articles cannot
recommend AUR helpers, since they bypass these mechanisms.

Max

[João Miguel]

Post by Maxwell Anselm

Post by João Miguel
Though I don't see how a repository officially trusted by
Manjaro is less trusted than the AUR.

They are completely different. An unofficial repository of non-AUR packages
is for installing binary packages that have no affiliation with Arch Linux.
I think it's pretty obvious why that would not be an appropriate
recommendation on the Arch Linux wiki.

I see your point, I hadn't thought of that.

Post by Maxwell Anselm
The AUR lets users view the PKGBUILD before installing and also to comment
and vote in order to establish trust. This is why wiki articles cannot
recommend AUR helpers, since they bypass these mechanisms.

They still do ask to check out the PKGBUILDs, but I see what you mean.

So in conclusion, to have a Wiki page about the method, the packages
need to be in the AUR. Fair enough.

João Miguel

[LoneVVolf]

Post by João Miguel
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)

[João Miguel]

Post by LoneVVolf

Post by João Miguel
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

Post by LoneVVolf
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.

Post by LoneVVolf
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).

Post by LoneVVolf
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.

Post by LoneVVolf
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

[LoneVVolf]

Post by João Miguel

Post by LoneVVolf

Post by João Miguel
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.

Post by João Miguel

Post by LoneVVolf
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.

Post by LoneVVolf
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).

Post by LoneVVolf
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.

Post by João Miguel

Post by LoneVVolf
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

[Maxwell Anselm]

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

[Henrik Danielsson]

Post by João Miguel

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

Post by João Miguel

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

Post by João Miguel
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.

Post by João Miguel
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

Post by João Miguel
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.

[Toyam Cox]

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.

[Bardur Arantsson]

Post by Toyam Cox
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?

[João Miguel]

Post by Bardur Arantsson

Post by Toyam Cox
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.

Post by Bardur Arantsson
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

[Bardur Arantsson]

Post by João Miguel

Post by Bardur Arantsson

Post by Toyam Cox
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,

[João Miguel]

Post by Bardur Arantsson
(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

[Bardur Arantsson]

Post by João Miguel

Post by Bardur Arantsson
(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

Post by João Miguel
when he said there should be an official version of Arch with OpenRC,
that's too much work.

OK, so thread over?

Regards,

[Kevin Monceaux]

Post by Bardur Arantsson
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.

[respiranto]

Post by João Miguel
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.

[Carsten Mattner]

Just throwing this out there: Given nosh's support for importing
systemd units, that one might be another viable option.

[Chao Feng]

Post by João Miguel
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.
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

Post by João Miguel
João Miguel

[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