Re: [arch-general] Alternative init system proposal

[Christos Nouskas]

On 23 February 2016 at 09:43, Eric Vidal  wrote:
> Hello everyone,
>
> I'm the creator of Obarun
> I use runit for PID1 and managing service. Repo is available for all package 
> builded without systemd support.

It's good to see people contributing to the Arch community with
interesting projects, instead of empty words. Thank you for your
efforts.


-- 
X
http://systemd-free.org
https://aur.archlinux.org/packages/?SeB=m=nous

Re: [arch-general] Alternative init system proposal

[Øyvind Heggstad]

On Tue, 23 Feb 2016 11:43:41 +0400
Eric Vidal  wrote:

> Hello everyone,
> 
> I'm the creator of Obarun
> I use runit for PID1 and managing service. Repo is available for all
> package builded without systemd support. All this package have the
> name xxx-systemd to avoid trouble with original package. Package are
> maintained every week (one time per week). all this package doesn't
> have service declaration to allow other distro to use it like
> manjaro, alphaos etecetera... A github with all the pkgbuild used is
> available here https://github.com/Obarun + some personnal scripts A
> complete site is available too with forum and a little wiki here
> www.obarun.org Proposal an alternative to systemd on arch system
> isn't impossible even for complex desktop environment. KF5, XFCE4
> work on it.(using consolekit for the moment) dev is managed by gentoo
> eudev (working with jcnelson vdev is in progress, but not working for
> the moment). I use my system from almost one year now and share it
> from july 2015. This system is not perfect (i'm not a good dev) and
> i'm alone to make all the stuff (site, maintaining, new features and
> so one) but i'm the proof that can be possible and without so much
> efford.
> 
> Isn't the work to arch to propose an alternative. Pacman, makepkg,
> pkgbuild are beautiful tools which allow user to make every his want.
> So use it and don't ask anything to arch dev :)
> 

and foo-systemd isn't ambiguous at all! :p

Re: [arch-general] Alternative init system proposal

[Stefan Tatschner]

On 23.02.2016 08:43, Eric Vidal wrote:
> Hello everyone,
> 
> I'm the creator of Obarun
> I use runit for PID1 and managing service. Repo is available for all package 
> builded without systemd support. All this package have the name xxx-systemd 
> to avoid trouble with original package. Package are maintained every week 
> (one time per week). all this package doesn't have service declaration to 
> allow other distro to use it like manjaro, alphaos etecetera...
> A github with all the pkgbuild used is available here 
> https://github.com/Obarun + some personnal scripts
> A complete site is available too with forum and a little wiki here 
> www.obarun.org
> Proposal an alternative to systemd on arch system isn't impossible even for 
> complex desktop environment. KF5, XFCE4 work on it.(using consolekit for the 
> moment)
> dev is managed by gentoo eudev (working with jcnelson vdev is in progress, 
> but not working for the moment).
> I use my system from almost one year now and share it from july 2015. This 
> system is not perfect (i'm not a good dev) and i'm alone to make all the 
> stuff (site, maintaining, new features and so one) but i'm the proof that can 
> be possible and without so much efford.
> 
> Isn't the work to arch to propose an alternative. Pacman, makepkg, pkgbuild 
> are beautiful tools which allow user to make every his want. So use it and 
> don't ask anything to arch dev :)
> 

Please stop spamming our inboxes with this topic over and over again!
There has been a gigantic thread a few days ago on arch-general.

Stefan

Re: [arch-general] Alternative init system proposal

[Paul Gideon Dann]

On 23 February 2016 at 08:32, Frank Schaffhaeuser 
wrote:

> This topic again? Seriously? The last 'discussion' from Feb.8th thankfully
> just died down
> and apart from spamming subscriber's inboxes had no useful effect...
> Please, not again


Hang on, I absolutely agree with you that I'm sick of the "alternative init
system" argument, but Eric here is saying something quite positive: Arch is
a system that gives its users the freedom to do whatever they want with
their system. His point is that we should not be bothering the devs with
this stuff: he is proof that we as users have everything we need to make
our system work however we want it to, and for that we can be grateful.
Good for you, Eric. It's great to see someone scratching their own itch in
true Open Source style :)

Paul

Re: [arch-general] Alternative init system proposal

[Frank Schaffhaeuser]

 On Tue, 23 Feb 2016 07:43:41 + Eric Vidale...@obarun.org wrote 
 

Hello everyone, 
 
I'm the creator of Obarun 
I use runit for PID1 and managing service. Repo is available for all package 
builded without systemd support. All this package have the name xxx-systemd to 
avoid trouble with original package. Package are maintained every week (one 
time per week). all this package doesn't have service declaration to allow 
other distro to use it like manjaro, alphaos etecetera... 
A github with all the pkgbuild used is available here https://github.com/Obarun 
+ some personnal scripts 
A complete site is available too with forum and a little wiki here 
www.obarun.org 
Proposal an alternative to systemd on arch system isn't impossible even for 
complex desktop environment. KF5, XFCE4 work on it.(using consolekit for the 
moment) 
dev is managed by gentoo eudev (working with jcnelson vdev is in progress, but 
not working for the moment). 
I use my system from almost one year now and share it from july 2015. This 
system is not perfect (i'm not a good dev) and i'm alone to make all the stuff 
(site, maintaining, new features and so one) but i'm the proof that can be 
possible and without so much efford. 
 
Isn't the work to arch to propose an alternative. Pacman, makepkg, pkgbuild are 
beautiful tools which allow user to make every his want. So use it and don't 
ask anything to arch dev :) 
 
-- 
Eric Vidal e...@obarun.org 

This topic again? Seriously? The last 'discussion' from Feb.8th thankfully just 
died down
and apart from spamming subscriber's inboxes had no useful effect...
Please, not again.

Re: [arch-general] Alternative init system proposal

[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

Re: [arch-general] Alternative init system proposal

[LoneVVolf]

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

Re: [arch-general] Alternative init system proposal

[João Miguel]

A 2016-02-14T23:13:44 +0100, LoneVVolf escreveu:
> On 14-02-16 17:17, João Miguel wrote:
> >Then I shall contact Artoo and add the packages back to the AUR as Nous
> >suggested. Though I don't see how a repository officially trusted by
> >Manjaro is less trusted than the AUR. Nevertheless, I do like the AUR, and
> >packages being there might help. Have a good day, João Miguel
> 
> Not long ago Artoo renamed his manjaro packages to openrc without any
> discusssion with apg or apg openrc users.
It was after he was asked to remove his pakages from the AUR and after a
discussion in the Manjaro forums

> Before artoo packages can be put back in AUR, that naming conflict needs to
> be solved.
FWIW, there are currently at least 13 packages in the AUR (found by
searching and reading PKGBUILDs) from different people that install init
scripts to /etc/init.d and not Apg's /etc/openrc/init.d.

> Even if that naming conflict were resolved, the division in the small AL
> openrc community would continue to exist.
I think the easiest way to unite efforts would be to forget /etc/openrc.
I see that you want to avoid a conflict with initscripts, but if you
installed to /etc as Artoo, you'd be closer to upstream (Gentoo). I'm ok
with any directory, but I don't see the point in using /etc/openrc; who
uses both initscripts-fork and openrc, except for testing purposes?
Maybe you could change the default of that SYSCONFDIR variable to /etc,
and have the rare users of both systems change it to /etc/openrc (they
could get a warning in a post-install file or something like that).

> Maybe the AL users wanting to remove systemd completely could investigate if
> switching from openrc artoo way to openrc apg way is possible ?
I wouldn't put it off the chart, but note that users in Manjaro and
those of systemd-free.org already have binaries for Artoo's way, so a
middle ground between the ways, starting with identifying the
differences and figuring which way is best for each of those, would be
preferred IMHO.

> Lone_Wolf
> 
> Active user of openrc apg way
> co-maintainer of apg openrc (since this weekend)
Thank you for you efforts in maintaining an alternative, they are very
much appreciated.

Regards,
João Miguel

Re: [arch-general] Alternative init system proposal

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

> 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

Re: [arch-general] Alternative init system proposal

[LoneVVolf]

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)

Re: [arch-general] Alternative init system proposal

[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.
In the Wiki, Alad said the problem were the instructions at
systemd-free.org. He talked about FUD, so I supposed he was simply
looking for something with a neutral point of view, suitable for the
Wiki.

> artoo's method was already rejected from the wiki for several reasons as
> pointed out on the talk page. If you find the current method on the wiki
I pointed out the "several reasons" were not nearly enough to remove a
legitimate and well supported method.
> lacking, then you will need to come up with some new method that both
> improves on the wiki's method and avoids the pitfalls of artoo's.
But what are the pitfalls? (I do mean this question in good faith.
Pointing out bugs in a package once in a while is not an answer.) That
it needs to replace lots of packages? It replaces systemd as service
manager, but systemd is not just that, lots of things depend on it and
need to be patched, and in fact are *already* patched. 

Note: no work from *anyone* is being asked here, just a place in the
Wiki to document the method. All improvement welcome. Alad is
considering respiranto's suggestion (thank you, I wouldn't have thought
of breaking it in 2). FWIW, I have installed OpenRC with Artoo's method
several times and never had any trouble.

> Again, this is not about lack of choice. This is about a particular choice
> being deemed unfit for the wiki. Any method that *relies* on an unofficial
> repository (i.e. has no AUR alternative) is certainly not appropriate.
Then I shall contact Artoo and add the packages back to the AUR as Nous
suggested. Though I don't see how a repository officially trusted by
Manjaro is less trusted than the AUR. Nevertheless, I do like the AUR,
and packages being there might help.

Have a good day,
João Miguel

Re: [arch-general] Alternative init system proposal

[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

Re: [arch-general] Alternative init system proposal

[João Miguel]

> > I feel it pertinent to point out that a different rolling-release
> > distrobution ( http://www.voidlinux.eu/ ) does not use systemd, openrc, or
> > sysvinit. Void Linux uses runit exclusively, and thus patches projects like
> > KDE4 and Gnome3 to work without systemd (I don't mention KDE5 since nobody
> > has cared enough yet to put in the effort).
> Well, that's *amazing*... what does it mean for me, the user?
To me, the user, it means I there is a possibility for an alternative
init system without the devs having to do anything. It means there are
people out there working on this and work towards alternatives does not
need to start from scratch. You're on Linux: you ought not to be only a
user, but also a contributor, thus "voting" with your actions. That's
why you're on a mailing list, or at least why I am.

> I can only re-iterate: Can we please stop this thread?
I deleted the first half of it. I think it may turn out to be productive
now. Void Linux is a distribution besides Gentoo we can base off to
allow different init systems to be used.

Regards,
João Miguel

Re: [arch-general] Alternative init system proposal

[Bardur Arantsson]

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,

Re: [arch-general] Alternative init system proposal

[João Miguel]

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

Re: [arch-general] Alternative init system proposal

[Bardur Arantsson]

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,

Re: [arch-general] Alternative init system proposal

[João Miguel]

> If you want to make OpenRC easier to use on Arch, here's how:
> 1. Get more involved in the AUR to develop more/better OpenRC-specific
> packages
There are 4 mirrors for an unnoficial user repository with packages that
are officially used in Manjaro.
> 2. Draft a new OpenRC wiki article on your User page
Done. https://wiki.archlinux.org/index.php/User:JMCF125/OpenRC
> 3. Work on 1 and 2 until you feel like you have a clearly superior method
The method already existed, I just wanted to make it visible.
> 4. Open a discussion on the OpenRC talk page about replacing the article
> (this will most likely involved discussion on your User page as well on how
> to improve your draft)
> 5. Success
Or in this case, failure:
https://wiki.archlinux.org/index.php?title=Talk:OpenRC=420556
> 
> Max

João Miguel

Re: [arch-general] Alternative init system proposal

[respiranto]

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.

Re: [arch-general] Alternative init system proposal

[Carsten Mattner]

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

Re: [arch-general] Alternative init system proposal

[Maxwell Anselm]

> 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

Re: [arch-general] Alternative init system proposal

[LoneVVolf]

On 11-02-16 17:12, João Miguel wrote:


now there are no AUR packages for OpenRC.


You are wrong, please be more specific.

This is current situation:

- run AL without using systemd as PID1 / init system :
Aur and AL wiki have everything you need for that.
You will still have systemd installed and use udev from it.

(i am one of the AL users that uses this setup on my laptop and desktop)

- remove systemd completely from AL :
Some people do that, but documentation how to do this was removed from wiki.
The aur packages that helped with this setup were removed by the 
creator/maintainer.


Lone_Wolf

Re: [arch-general] Alternative init system proposal

[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

Re: [arch-general] Alternative init system proposal

[Henrik Danielsson]

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

Re: [arch-general] Alternative init system proposal

[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

Re: [arch-general] Alternative init system proposal

[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

Re: [arch-general] Alternative init system proposal

[Maxwell Anselm]

> 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

Re: [arch-general] Alternative init system proposal

[Henrik Danielsson]

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

Re: [arch-general] Alternative init system proposal

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

Re: [arch-general] Alternative init system proposal

[Bardur Arantsson]

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?

Re: [arch-general] Alternative init system proposal

[Chao Feng]

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

> 
> João Miguel

Re: [arch-general] Alternative init system proposal

[João Miguel]

> 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

Re: [arch-general] Alternative init system proposal

[Bardur Arantsson]

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,

Re: [arch-general] Alternative init system proposal

[Jack L. Frost]

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


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Jack L. Frost]

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.


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Mike Cloaked]

On Mon, Feb 8, 2016 at 12:58 AM, 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.
>
> So, to get to the point...
> I would like to propose development and official support of an
> alternative init system and service manager. My main preference would be
>
> >snip


> me feedback on all of this and let's see what we can do about it and
> what it can develop into...
>
>
This kind of long-running, and in the end pointless, discussion that has
developed in recent days, on this ML, was the underlying reason for a huge
and extended set of threads on a number of linux forums a few years ago,
including on the Fedora Forums, that led a significant number of users to
unsubscribe from those forums because they did not want their inboxes
filled up with discussions that looked increasingly like they were going
nowhere. At the end of the day the arch developers made the decision to
support systemd as the arch linux daemon and initialisation software. They
have devoted their time to make arch linux a beautifully efficient
distribution keeping to the "Arch Way", and with the most efficient of
package manager compared to most other linux distros. It is likely no
surprise that a number of senior kernel developers use arch linux rather
than other distributions. The required systemd packages were made available
to the arch repos, advice on transisioning to systemd for those on other
inits broadcast, and over time all of the necessary unit files and support
structures were put in place, keeping arch close to upstream, and the
current arch linux system works exceptionally well on a huge range of
different types of hardware. Users are free to write their own unit files
or to adapt the default unit files (and I do this in a few cases too where
I want behaviour to match my own needs). My systems (both laptops and
desktops) start up quickly and, like many users, I am very happy with the
performance of my arch linux installed machines.

It is tough enough for TUs to voluntarily keep the packages in the repos as
close to current upstream as they do already, and adding an unnecessary
layer of additional support for a small percentage of the user base who
wish to have a second init system available, because they think it is
better than systemd, is not a proposal that looks like it would get
majority support even if there are a few people who continue to flood the
mailing list with ongoing thread postings about this.

Perhaps those who wish to pursue the alternative init idea could do so in
private on a separate mailing list devoted to that topic alone and any
interested parties can of course freely join in that discussion if they
should wish to do so.  The number of users who subscribe to that specific
ML would be a gauge of any real interest from significant numbers of users.
If that turns out to be a small handful of people only, then that would be
at least some evidence of the level of support for that proposal. However
filling people's inboxes with this discussion I suspect is not being found
valuable by quite a few people I expect.

Anyone is of course free to develop the proposed alternative init system
for their own use, or form their own developer subgroup, and could provide
their own repos if they wish, and anyone wanting to use the alternative can
then do so.

I certainly see many helpful concise and brief threads that seek to resolve
or inform in a way that is digestible. However long running flame wars
between systemd antagonists and supporters is counter-productive. The real
question is whether or not any TUs or developers think that this is worthy
of further investigation or not. Users who wish to volunteer to do the work
can of course make themselves known.

-- 
mike c

Re: [arch-general] Alternative init system proposal

[Patrick Lauer]

On 02/08/2016 07:27 AM, Yaro Kasear wrote:
> I still don't get what makes OpenRC so great. Doesn't it still depend
> entirely on SysV Init?
By default it uses sysvinit as PID1. That's all that it does.
If it makes you unhappy you can easily use s6 or runit as PID1 ... or
write your own.

>  That ALONE makes me want to keep it off my system.
> If it makes us fall back on an init system that is frankly backward and was
> badly in need of replacement then I don't see why it should be considered
> an alternative.
So far I've never seen sysvinit's PID1 misbehave or crash. No idea why
you dislike it so much, but as said above ...
No need to use it, it's just a convenient default.
> Systemd ain't perfect, but when the best alternative is something that
> relIes on dated components bona fide Unix systems don't even use anymore,
> then they simply aren't alternatives.
Change is not Progress.

Are you, by chance, confusing sysvinit with debian's sysv-rc or
something similar?

> On Feb 7, 2016 11:36 PM, "Leonid Isaev" 
> wrote:
>
>> On Mon, Feb 08, 2016 at 06:02:34AM +0100, Ivan wrote:
>>> Hypothetically, if Arch Linux was to adopt an alternative init, it's a
>>> process that does not happen overnight. Through time, solutions will
>>> surface. I'm not a magic lamp genie that has all the answers.
>> Then you have to ask yourself, what defines a distribution. If you are
>> going to
>> bring in ck, patch polkit, gnome, kde, xfce, etc, and introduce
>> customizations
>> to lots of other packages, isn't it easier to start from gentoo or alpine
>> and
>> maintain pacman for those distros? I am asking because you are going to
>> duplicate a fair share of official repos...
>>
>> Cheers,
>> --
>> Leonid Isaev
>> GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
>>   C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
>>

Re: [arch-general] Alternative init system proposal

[Jack L. Frost]

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


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Jack L. Frost]

On Tue, Feb 09, 2016 at 10:33:55PM +0100, Christian Rebischke wrote:
> Hello everone,
> First of all I want to remind you that systemd is no longer an init system.
> Systemd has become to be much more than just starting/stopping some daemons.
> You must see systemd with every part. You cannot just strip systemd from
> every package, ignore the other parts of systemd and run openRC. This will
> not work. This is just one part..

You actually can get systemd out and something else to do parts of what it
does. Most packages depend not on systemd, but on libsystemd and will happily
just *not use it* if systemd is not present.

I've been using such a system (Arch with systemd and some other stuff never put 
in)
and it has been fine.

> the other part is: I don't think that the Arch Linux developers would be
> happy if they would need to maintain an alternative init system like openRC.
> 
> Here are some reasons for it:
> 
> 1. Maintaining:
> The maintaining of systemd and another init-system would be a lot of double
> work. We would need every package twice. One systemd version and one version
> without systemd. Moreover some packages like netctl depend on systemd. You
> cannot just repackage netctl without systemd. You would have to change the
> codebase of netctl.

1) See my previous point.
2) I think you have to be completely mad to demand Arch devs rewrite netctl to
support something other than systemd. It depends on systemd. If you choose not
to use systemd, just use some other method of network configuration.

> Moreover I think that the developer team has other work todo. For example I
> would prefer to have full SELinux support this would be for me much more
> important as another init system.
> 
> 2. Arch Linux itself:
> When I think about Arch Linux i must think about:
> - rolling release
> - a very fast release system. Upstream version == package version in the
>   official repositories.
> 
> What does this mean? It means that I prefer a linux distribution that
> supports the newest changes in the linux development. Systemd is one of
> thesee changes. Systemd improves a lot of stuff. There is a reason why all
> other big distribtions are also moving to systemd. It's the future. All the
> shellscript-based init systems are the past.

As another person on here said, change is not progress. It's new, but it's
debatabe if it's a net positive.

> Also, with systemd comes a lot
> of new cool stuff like cgroups, systemd-nspawn, networkd, logind and a lot
> more. 

cgroups are not systemd-specific.
systemd-nspawn is just another container solution, it's not the only one.
networkd is just a network configurator, we have hundreds of those.
logind is actually *needed* in a number of cases while doing nothing in others.

> I really think that Arch Linux shouldn't be a rock in this flow of
> development. We should do it like fedora and support it. We shouldn't help
> to tube-fed all other init systems. 
> 
> Furthermore there will be (maybe) kdbus in the kernel. Kdbus is at the
> moment still systemd only. I am sure there will come more systemd-specific
> interfaces for the kernel. Kdbus is just one example.

A detour from the point of this discussion, but I don't think that's a good
thing that the kernel might actually depend on systemd in some ways.

> 3. The ISO and Arch Linux installation process
> If Arch Linux would support openRC we would have to offer two ISOs. One with
> systemd and one with openRC.

What? Why? Having a handful of new packages in the repos doesn't mean anything
has to change. If you want to be extra nice about it, then maybe a separate
base group (base-openrc or something), but not a separate iso.

> Also the way of the installation process would be different.

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

> We would need to edit all wikipages. I often hear that the
> Arch Linux wiki is one of the best wikis for GNU/Linux. I think this would
> change if we would have a second init system. We would have a lot of chaos.
> And for what? Only for making 'some' people happy.
> 
> This is just my humble opinion,
> 
> best regards,
> 
> chris

Now all that said, I still won't advocate for the Arch devs to actually support
configs other than the current base. All the things I just wrote should clue
you in that it's pretty easy to maintain a system without systemd without any
official support for it beyond the systemd/libsystemd split (thank you, devs,
btw, it made my life so much easier!).

Let the Arch team focus on providing a solit base to build upon and modify to
your needs.

The reason I felt the need to address the point in this email is I'm tired of
the overwhelming ignorance about the topic from people discussing it. It's
staggering.


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Ivan]

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.


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Tobias Hunger]

Hi Ivan,

On Tue, Feb 9, 2016 at 9:17 AM, Ivan  wrote:
>> That said, how about a archbang-like approach?

> 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

Re: [arch-general] Alternative init system proposal

[Michał Zegan]

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

Re: [arch-general] Alternative init system proposal

[Michał Zegan]

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

Re: [arch-general] Alternative init system proposal

[Damjan Georgievski]

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-/ directory as /tmp. from the point of view
of the process it will never see
anything else from the outer /tmp

-- 
damjan

Re: [arch-general] Alternative init system proposal

[Guus Snijders]

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

Re: [arch-general] Alternative init system proposal

[Guus Snijders]

Op 9 feb. 2016 17:52 schreef "Damjan Georgievski" :
>
> On 9 February 2016 at 17:34, Guus Snijders  wrote:
> > Op 9 feb. 2016 17:27 schreef "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 :)

;)

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

Re: [arch-general] Alternative init system proposal

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



signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Ralf Mardorf]

On Tue, 9 Feb 2016 17:26:57 +0100, Michał Zegan wrote:
>A note about using shell scripts in systemd:
>Who said you can't? and I don't talk about systemd's init.d
>compatibility that is disabled in arch. Although you have to write
>unit files, you can start scripts, so you do not really lose
>flexibility.

I'm doing this. However, if you remove and mount cards, in my case just
audio related, not network related cards, then even network device
names are not consistent. It's not a serious issue, you just need to
decide to use one or the other workaround, but some users who have
portable scripts, perhaps dislike to check all scripts against
systemd/udev pitfalls.

[rocketmouse@archlinux ~]$ grep enp?s0 /usr/local/sbin/alice-dhcp
  echo ; dhcpcd $(basename $(ls -d /sys/class/net/enp?s0)) ; echo
  echo ; dhcpcd -x $(basename $(ls -d /sys/class/net/enp?s0)) ; echo

Re: [arch-general] Alternative init system proposal

[Ivan]

On Sun, 07 Feb 2016, Leonid Isaev wrote:

> On Mon, Feb 08, 2016 at 06:02:34AM +0100, Ivan wrote:
> > Hypothetically, if Arch Linux was to adopt an alternative init, it's a
> > process that does not happen overnight. Through time, solutions will
> > surface. I'm not a magic lamp genie that has all the answers. 
> 
> Then you have to ask yourself, what defines a distribution. If you are going 
> to
> bring in ck, patch polkit, gnome, kde, xfce, etc, and introduce customizations
> to lots of other packages, isn't it easier to start from gentoo or alpine and
> maintain pacman for those distros? I am asking because you are going to
> duplicate a fair share of official repos...

Well, for starters, Arch isn't just about pacman. I get the feeling you
think it is. For me, the "killer" features of Arch are the AUR and its
huge, excellent community. I could just run off and start a new distro,
but this is not the point.

I realize, and I've talked about it in one of the previous emails where
I discussed the way packages could/should be built.


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Ivan]

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.


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Guus Snijders]

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

[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


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

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

Re: [arch-general] Alternative init system proposal

[Doug Newgard]

On Mon, 8 Feb 2016 02:37:57 +
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  | grep service

Should take significantly less than an hour.

Re: [arch-general] Alternative init system proposal

[Jan Alexander Steffens]

On Mon, Feb 8, 2016 at 4:56 AM, Leonid Isaev
 wrote:
> That's why I still use Debian 5 stable in a container as a print server... 
> Cups
> 2.0+ is a real piece of crap. And yes, these org.xxx.xxx names _are_ stupid
> especially for filenames. But after using modern Fedoras, I think that systemd
> services are no longer supposed to be managed manually, but rather through 
> some
> frontend...

http://cockpit-project.org/

Re: [arch-general] Alternative init system proposal

[mick]

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?

> 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

Re: [arch-general] Alternative init system proposal

[Leonid Isaev]

On Mon, Feb 08, 2016 at 03:28:36AM +, mick wrote:
> On Sun, 7 Feb 2016 20:51:50 -0600
> Doug Newgard  wrote:
> 
> > On Mon, 8 Feb 2016 02:37:57 +
> > 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  | 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

Re: [arch-general] Alternative init system proposal

[Ivan]

On Sun, 07 Feb 2016, Patrick Burroughs (Celti) wrote:

> The big question you have to answer, the one you need to start with, is:
> 
> Why is it in the Arch dev's interests to maintain two init systems and
> that much more area for incompatibility, that many more packages and
> bugs to wrangle? Especially if they are happy using systemd?
> 
> Nobody could answer that question a few years ago, so the original Arch
> initscripts were dropped in favour of a systemd-only distro.
> 
> If you have a serious answer, by all means, present it — but that *is*
> the stumbling block here.

I would start by taking out some quotes out of
https://wiki.archlinux.org/index.php/Arch_Linux

"Arch is installed as a minimal base system, configured by the user upon
which their own ideal environment is assembled by installing only what
is required or desired for their unique purposes."

"Arch Linux has always been, and shall always remain user-centric. The
distribution is intended to fill the needs of those contributing to it
rather than trying to appeal to as many users as possible."

"... it is the user who decides what his system will be."

I know everyone always cites this in their anti-systemd rands, but Linux
really has always been about choice, and yet all the major distributions
seem to embrace the same init system: systemd. Thus, distros are giving
up on their "distinctiveness" Now I keep seeing almost all the "big" 
GNU/Linux embracing nothing but systemd and that's very dissapointing.
(Arch) Users aren't picking systemd because it's there and it's perfect,
but
because there is no other choice, and was to a certain point imposed to
them... I am most certainly not going back to the past and referencing
the
mailinglist discussions where initscrips was dropped in favor of
systemd. That was the decision, and I fully respect it. Nevertheless,
consider: does Arch really have to *demand* systemd to be the only init
system? Not saying it will happen, and this being really farfetched:
Eventually the difference between distros seems to boil down to having a
different distribution name and a different package manager. It may
eventually become impossible to use Linux without also using systemd.
For me, and many other communities out there this is not a very pleasant
thing. I don't want to impose it here, but I'm sure you are aware of all
the init/systemd wars going on...

Since 2012, a lot of things happened. systemd gained a lot more
traction, maybe even due to the fact Arch implemented it. 
Note: OpenRC is actively developed since 2007. by developers coming from
the Gentoo community. Since then, it has grown into a very big project.
As for udev (it was integrated into systemd, and knowing hotplugging is
necessary for most users nowadays), The Gentoo developers have forked it
and named it eudev. Since then, eudev is also under active development.
It provides everything udev does, and doesn't break current udev stuff.
I can even personally confirm this, since I use OpenRC and eudev on my
personal computer (running Arch Linux, of course) instead of systemd.

To those saying "What does OpenRC have that systemd doesn't?": OpenRC
isn't made as a clone of systemd. It's a tool for itself, and works the
way it's made to work. If you still with to ask that question, note that
OpenRC can actually do as much as systemd (possibly even more, but I'm
no systemd wizard). Also here is the forum post where tomegun talks
about 
systemd adoption and lists some key points. Feel free to compare it to
OpenRC and the tools OpenRC is used with.
https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
Anyone willing to discuss this in more depth, feel free to reply.

Let's go back to Arch itself, as the distro. 
As we all know, Arch is built around the KISS principle. (Yes, I know
this is contradictory to my request, but also note the beginning of this
email)
So, the KISS principle... I'm still sticking to OpenRC, and now I will
have to make some short notes:
* Daemon management is as simple as systemd. As a matter of fact,
  most (if not all) OpenRC users I've talked to say that it's even
  simpler than systemd because we can find everything in /etc/init.d/ 
  as opposed to `systemctl edit` and its tmpfiles/overrides. (Again, 
  I'm not a systemd wizard, don't take things for granted)
* Simplicity through /etc/init.d helps you fix misconfigured daemons
  more easily than systemd in case you forgot what you did. (Sort
  /etc/init.d/* by latest file modification)
* "Networking is difficult" - Absolutely not! In fact, even
  NetworkManager works just fine with OpenRC. With proper packaging,
  users will not need to do anything.
* "It's for power users" - Again, no. While many power users and (older
  system administrators prefer not using systemd, this does not mean
  OpenRC is necessarily complicated to use. Quite the opposite,
  OpenRC makes management very user-friendly and simple. Also, 

Re: [arch-general] Alternative init system proposal

[Patrick Burroughs (Celti)]

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


pgpAM4VFXloKj.pgp
Description: OpenPGP digital signature

Re: [arch-general] Alternative init system proposal

[Leonid Isaev]

Hi,

On Mon, Feb 08, 2016 at 01:58:19AM +0100, Ivan wrote:
> 1. Udev...

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

> 2. Packaging...

Not an issue really.
 
> 2.1. Repositories... core, extra, community and multilib would not need

People who would be running an alternative init system wouldn't need much
support.

> I realize that there are a lot more things to be discussed about this.

And here is a can of worms. What are you going to do with logind and various
desktop integrations? What about systemd-tmpfiles snippets that do magic in
the background?

Regarding former, before you say consolekit2, it's not an answer. Yes, systemd
may be getting in too many places, but the previous state of affairs was not
better (I think everyone would agree that ck is a broken concept). Also, don't
forget about wayland. I strongly suspect that it is not going to run without
logind.

Regarding latter, you'll have to roll out lots of install files in existing
packages, even those that have no relation to an init system.

You see, by itself, systemd is a stupid and irrelevant piece of software. It is
things around it that create real problems...

HTH,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

Re: [arch-general] Alternative init system proposal

[mick]

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

> On Mon, 8 Feb 2016 02:37:57 +
> 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  | grep service
> 
> Should take significantly less than an hour.
> 

Now that I know about it, but I still think cupsd.service is more intuitive.

Re: [arch-general] Alternative init system proposal

[Leonid Isaev]

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

Re: [arch-general] Alternative init system proposal

[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.
On Feb 7, 2016 11:36 PM, "Leonid Isaev" 
wrote:

> On Mon, Feb 08, 2016 at 06:02:34AM +0100, Ivan wrote:
> > Hypothetically, if Arch Linux was to adopt an alternative init, it's a
> > process that does not happen overnight. Through time, solutions will
> > surface. I'm not a magic lamp genie that has all the answers.
>
> Then you have to ask yourself, what defines a distribution. If you are
> going to
> bring in ck, patch polkit, gnome, kde, xfce, etc, and introduce
> customizations
> to lots of other packages, isn't it easier to start from gentoo or alpine
> and
> maintain pacman for those distros? I am asking because you are going to
> duplicate a fair share of official repos...
>
> 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
>

Re: [arch-general] Alternative init system proposal

[Jack L. Frost]

On Mon, Feb 08, 2016 at 01:58:19AM +0100, Ivan wrote:
> Hello, I have a proposal for Arch Linux developers and by mailing
> on this list I would also appreciate feedback from non-developers that
> use Arch Linux. 
> ...

It's not reasonable to demand Arch devs maintain several init systems.
You can pretty easily maintain that out of the main repos for yourself
and others.

There are several maintained solutions already.
http://systemd-free.org details one such solution (openrc + sysvinit).
https://wiki.archlinux.org/index.php/Runit there's also runit.
https://fleshless.org/pages/spark.html I have a personal solution.

And there are others I can't quite remember right now.

Let the dev team focus on a stable base and modify it if you need to.


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Ivan]

On Sun, 07 Feb 2016, Leonid Isaev wrote:
> On Mon, Feb 08, 2016 at 01:58:19AM +0100, Ivan wrote:
> 
> > I realize that there are a lot more things to be discussed about this.
> 
> And here is a can of worms. What are you going to do with logind and various
> desktop integrations? What about systemd-tmpfiles snippets that do magic in
> the background?
> 
> Regarding former, before you say consolekit2, it's not an answer. Yes, systemd
> may be getting in too many places, but the previous state of affairs was not
> better (I think everyone would agree that ck is a broken concept). Also, don't
> forget about wayland. I strongly suspect that it is not going to run without
> logind.

While I don't think it's time to debate consolekit yet, I would have to
say that it currently is an option.
Gnome (being made systemd-dependent) can still be patched to work
without systemd. Wayland is also proven to run without systemd. Though I
am not sure what will happen with future development (see your last two
sentences)...
 
> Regarding latter, you'll have to roll out lots of install files in existing
> packages, even those that have no relation to an init system.
> 
> You see, by itself, systemd is a stupid and irrelevant piece of software. It 
> is
> things around it that create real problems...

Hypothetically, if Arch Linux was to adopt an alternative init, it's a
process that does not happen overnight. Through time, solutions will
surface. I'm not a magic lamp genie that has all the answers. 


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Ivan]

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


signature.asc
Description: PGP signature