Discussion:
RFC: OpenRC as init system for Arch
(too old to reply)
Patrick Lauer
2012-04-25 14:03:19 UTC
Permalink
Greetings,

in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current Arch Linux init system is a bit minimal and gets the job done, but it's not superawesome.
There's things like init script dependencies that would be nice to have, but then it's about the smallest of all init systems around.

On the other hand systemd is just Not The
Unix Way, it consolidates everything into one huge process and forces
some impossible dependencies (dbus? udev? on my server?! and you expect
a linux 3.0+ kernel? waaah!). But "everyone else" is moving to systemd,
so where does that leave us? (One might notice that "everyone else" is
just Fedora/RHEL at the moment, with (open)SuSE tagging along, and most
others still not committed to a migration yet)

As an alternative to the One Process For Everything I'd like to ask you to evalute OpenRC as an init system for Arch Linux.

While Gentoo is by far the largest user it's definitely not the only one
- there are the direct derivatives (Sabayon, pentoo, funtoo,
sysrescuecd, tinhat, ...) and some "foreign" users (Alpine, a debian
derivative, uses OpenRC)

What we offer you is a modern, slim, userfriendly init system with
minimal dependencies. All you need is a C99 compiler and a posix sh!
The list of features is long and tedious (see
http://wiki.gentoo.org/wiki/OpenRC ), but the critical bits are:

* portable - we have it running on Linux, *BSD, and there's no reason
why it should fail on other unixoid platforms
* dependency-based init scripts - no need to manually figure out the
startup order, something like "before apache, after logger" is all you
need to specify
* small footprint - 10k LoC C99, ~3k LoC Posix SH out of the box (plus
your own init scripts, of course)
* friendly responsive upstream (let's figure out how we can cooperate, eh?)
* boring - deterministic reproducable bootup, including interactive mode
and verbose debug output

For a long time we haven't done any active advertising, but OpenRC is
now about 5 years old, and it is a drop-in replacement for our previous
"baselayout" init system (which was started over a decade ago). We don't
try to take over the world, we just create the best solution for our
needs. And those go all the way from embedded systems (where you can use
busybox for all the shell tools) to servers (minimal deps! No mandatory
udev or dbus!) and desktops (including optional splash screen eyecandy
and whatever makes you happy).

There's pretty good support for advanced usage like SELinux, built-in
support for ulimit and cgroups to do per-service resource limits, and it
even comes with a friendly license (although some might say that a
2-clause BSD license it too friendly and promiscuous). And as a random
bonus feature you get stupid-fast bootup - We've seen <5sec from
bootloader handover to login prompt (depending on hardware and amount of
services started, of course) and <5sec for rebooting a kvm guest.

Should you decide to switch (or just evaluate if switching is possible /
makes sense) you'll get full support from us in migrating init scripts
and figuring out all the nontrivial changes. Just visit us on IRC (
#openrc on irc.freenode.net), send us a mail ( ***@gentoo.org ) or
meet us for a beer or two.

Thanks for your consideration,

Patrick Lauer

Gentoo Developer, OpenRC co-maintainer
Kaiting Chen
2012-04-25 14:13:07 UTC
Permalink
Post by Patrick Lauer
Greetings,
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current Arch Linux init system is a bit minimal and gets the job
done, but it's not superawesome.
There's things like init script dependencies that would be nice to have,
but then it's about the smallest of all init systems around.
On the other hand systemd is just Not The
Unix Way, it consolidates everything into one huge process and forces
some impossible dependencies (dbus? udev? on my server?! and you expect
a linux 3.0+ kernel? waaah!). But "everyone else" is moving to systemd,
so where does that leave us? (One might notice that "everyone else" is
just Fedora/RHEL at the moment, with (open)SuSE tagging along, and most
others still not committed to a migration yet)
As an alternative to the One Process For Everything I'd like to ask you to
evalute OpenRC as an init system for Arch Linux.
While Gentoo is by far the largest user it's definitely not the only one
- there are the direct derivatives (Sabayon, pentoo, funtoo,
sysrescuecd, tinhat, ...) and some "foreign" users (Alpine, a debian
derivative, uses OpenRC)
What we offer you is a modern, slim, userfriendly init system with
minimal dependencies. All you need is a C99 compiler and a posix sh!
The list of features is long and tedious (see
* portable - we have it running on Linux, *BSD, and there's no reason
why it should fail on other unixoid platforms
* dependency-based init scripts - no need to manually figure out the
startup order, something like "before apache, after logger" is all you
need to specify
* small footprint - 10k LoC C99, ~3k LoC Posix SH out of the box (plus
your own init scripts, of course)
* friendly responsive upstream (let's figure out how we can cooperate, eh?)
* boring - deterministic reproducable bootup, including interactive mode
and verbose debug output
For a long time we haven't done any active advertising, but OpenRC is
now about 5 years old, and it is a drop-in replacement for our previous
"baselayout" init system (which was started over a decade ago). We don't
try to take over the world, we just create the best solution for our
needs. And those go all the way from embedded systems (where you can use
busybox for all the shell tools) to servers (minimal deps! No mandatory
udev or dbus!) and desktops (including optional splash screen eyecandy
and whatever makes you happy).
There's pretty good support for advanced usage like SELinux, built-in
support for ulimit and cgroups to do per-service resource limits, and it
even comes with a friendly license (although some might say that a
2-clause BSD license it too friendly and promiscuous). And as a random
bonus feature you get stupid-fast bootup - We've seen <5sec from
bootloader handover to login prompt (depending on hardware and amount of
services started, of course) and <5sec for rebooting a kvm guest.
Should you decide to switch (or just evaluate if switching is possible /
makes sense) you'll get full support from us in migrating init scripts
and figuring out all the nontrivial changes. Just visit us on IRC (
meet us for a beer or two.
Thanks for your consideration,
Patrick Lauer
Gentoo Developer, OpenRC co-maintainer
Just want to point out that on my server I've disabled all udev in the init
scripts. It took only a couple of minutes to hack. --Kaiting.
--
Kiwis and Limes: http://kaitocracy.blogspot.com/
Nicholas MIller
2012-04-25 14:19:13 UTC
Permalink
sounds better than systemd to me
Post by Patrick Lauer
Greetings,
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current Arch Linux init system is a bit minimal and gets the job
done, but it's not superawesome.
Post by Patrick Lauer
There's things like init script dependencies that would be nice to have,
but then it's about the smallest of all init systems around.
Post by Patrick Lauer
On the other hand systemd is just Not The
Unix Way, it consolidates everything into one huge process and forces
some impossible dependencies (dbus? udev? on my server?! and you expect
a linux 3.0+ kernel? waaah!). But "everyone else" is moving to systemd,
so where does that leave us? (One might notice that "everyone else" is
just Fedora/RHEL at the moment, with (open)SuSE tagging along, and most
others still not committed to a migration yet)
As an alternative to the One Process For Everything I'd like to ask you
to evalute OpenRC as an init system for Arch Linux.
Post by Patrick Lauer
While Gentoo is by far the largest user it's definitely not the only one
- there are the direct derivatives (Sabayon, pentoo, funtoo,
sysrescuecd, tinhat, ...) and some "foreign" users (Alpine, a debian
derivative, uses OpenRC)
What we offer you is a modern, slim, userfriendly init system with
minimal dependencies. All you need is a C99 compiler and a posix sh!
The list of features is long and tedious (see
* portable - we have it running on Linux, *BSD, and there's no reason
why it should fail on other unixoid platforms
* dependency-based init scripts - no need to manually figure out the
startup order, something like "before apache, after logger" is all you
need to specify
* small footprint - 10k LoC C99, ~3k LoC Posix SH out of the box (plus
your own init scripts, of course)
* friendly responsive upstream (let's figure out how we can cooperate, eh?)
* boring - deterministic reproducable bootup, including interactive mode
and verbose debug output
For a long time we haven't done any active advertising, but OpenRC is
now about 5 years old, and it is a drop-in replacement for our previous
"baselayout" init system (which was started over a decade ago). We don't
try to take over the world, we just create the best solution for our
needs. And those go all the way from embedded systems (where you can use
busybox for all the shell tools) to servers (minimal deps! No mandatory
udev or dbus!) and desktops (including optional splash screen eyecandy
and whatever makes you happy).
There's pretty good support for advanced usage like SELinux, built-in
support for ulimit and cgroups to do per-service resource limits, and it
even comes with a friendly license (although some might say that a
2-clause BSD license it too friendly and promiscuous). And as a random
bonus feature you get stupid-fast bootup - We've seen <5sec from
bootloader handover to login prompt (depending on hardware and amount of
services started, of course) and <5sec for rebooting a kvm guest.
Should you decide to switch (or just evaluate if switching is possible /
makes sense) you'll get full support from us in migrating init scripts
and figuring out all the nontrivial changes. Just visit us on IRC (
meet us for a beer or two.
Thanks for your consideration,
Patrick Lauer
Gentoo Developer, OpenRC co-maintainer
Hector Martinez-Seara
2012-04-25 14:28:48 UTC
Permalink
+1
sounds better than  systemd to me
Post by Patrick Lauer
Greetings,
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current Arch Linux init system is a bit minimal and gets the job
done, but it's not superawesome.
Post by Patrick Lauer
There's things like init script dependencies that would be nice to have,
but then it's about the smallest of all init systems around.
Post by Patrick Lauer
On the other hand systemd is just Not The
Unix Way, it consolidates everything into one huge process and forces
some impossible dependencies (dbus? udev? on my server?! and you expect
a linux 3.0+ kernel? waaah!). But "everyone else" is moving to systemd,
so where does that leave us? (One might notice that "everyone else" is
just Fedora/RHEL at the moment, with (open)SuSE tagging along, and most
others still not committed to a migration yet)
As an alternative to the One Process For Everything I'd like to ask you
to evalute OpenRC as an init system for Arch Linux.
Post by Patrick Lauer
While Gentoo is by far the largest user it's definitely not the only one
- there are the direct derivatives (Sabayon, pentoo, funtoo,
sysrescuecd, tinhat, ...) and some "foreign" users (Alpine, a debian
derivative, uses OpenRC)
What we offer you is a modern, slim, userfriendly init system with
minimal dependencies. All you need is a C99 compiler and a posix sh!
The list of features is long and tedious (see
* portable - we have it running on Linux, *BSD, and there's no reason
why it should fail on other unixoid platforms
* dependency-based init scripts - no need to manually figure out the
startup order, something like "before apache, after logger" is all you
need to specify
* small footprint - 10k LoC C99, ~3k LoC Posix SH out of the box (plus
your own init scripts, of course)
* friendly responsive upstream (let's figure out how we can cooperate,
eh?)
Post by Patrick Lauer
* boring - deterministic reproducable bootup, including interactive mode
and verbose debug output
For a long time we haven't done any active advertising, but OpenRC is
now about 5 years old, and it is a drop-in replacement for our previous
"baselayout" init system (which was started over a decade ago). We don't
try to take over the world, we just create the best solution for our
needs. And those go all the way from embedded systems (where you can use
busybox for all the shell tools) to servers (minimal deps! No mandatory
udev or dbus!) and desktops (including optional splash screen eyecandy
and whatever makes you happy).
There's pretty good support for advanced usage like SELinux, built-in
support for ulimit and cgroups to do per-service resource limits, and it
even comes with a friendly license (although some might say that a
2-clause BSD license it too friendly and promiscuous). And as a random
bonus feature you get stupid-fast bootup - We've seen <5sec from
bootloader handover to login prompt (depending on hardware and amount of
services started, of course) and <5sec for rebooting a kvm guest.
Should you decide to switch (or just evaluate if switching is possible /
makes sense) you'll get full support from us in migrating init scripts
and figuring out all the nontrivial changes. Just visit us on IRC (
meet us for a beer or two.
Thanks for your consideration,
Patrick Lauer
Gentoo Developer, OpenRC co-maintainer
--
Hector Martínez-Seara Monné
mail: ***@gmail.com
Tel: +34656271145
Tel: +358442709253
Tom Gundersen
2012-04-25 15:25:16 UTC
Permalink
Hi Patrick,
Post by Patrick Lauer
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current Arch Linux init system is a bit minimal and gets the job done, but it's not superawesome.
There's things like init script dependencies that would be nice to have, but then it's about the smallest of all init systems around.
While dependencies (done in the right way) might have been nice to
have, I don't see this as a major shortcoming of our current system,
and if we are to change away from initscripts the replacement would
have to provide significantly better benefits than that, in my humble
opinion.
Post by Patrick Lauer
On the other hand systemd is just Not The
Unix Way, it consolidates everything into one huge process
The systemd daemon is bigger than sysvinit's init and it does more.
However, you make it sound like all the extra featuers of systmed are
implemented in the daemon itself, and this is obviously not the case.
Almost all of the real work during boot is not done in PID1, but in
helper programs (/usr/lib/systemd/systemd-*).
Post by Patrick Lauer
and forces
some impossible dependencies (dbus? udev? on my server?! and you expect
a linux 3.0+ kernel? waaah!).
Are you sure systemd does not work without dbus/udev running or with
older kernels? I have had no reason to test this, but from my
knowledge of the code it should work just fine (obviously you'll lose
the features provided by whatever components you remove). That said,
it is not clear to my what benefit you would hope to get from
excluding tiny daemons such as dbus and udev.
Post by Patrick Lauer
As an alternative to the One Process For Everything I'd like to ask you to evalute OpenRC as an init system for Arch Linux.
This is a gross misrepresentation. If you want, you could criticise
that the systemd project encompasses many components, but the systemd
process itself is pretty minimal (IMHO).
Post by Patrick Lauer
While Gentoo is by far the largest user it's definitely not the only one
- there are the direct derivatives (Sabayon, pentoo, funtoo,
sysrescuecd, tinhat, ...) and some "foreign" users (Alpine, a debian
derivative, uses OpenRC)
IMHO, a nice goal would be to increase cross-distro collaboration. How
well are the different major distributions represented in your
contributor base? I think a strong point of systemd is that they have
active contributors from pretty much all major distros (including
gentoo and arch, but possibly with the exception of ubuntu, I'm not
sure).
Post by Patrick Lauer
* portable - we have it running on Linux, *BSD, and there's no reason
why it should fail on other unixoid platforms
This is clearly not relevant to Arch Linux.
Post by Patrick Lauer
* dependency-based init scripts - no need to manually figure out the
startup order, something like "before apache, after logger" is all you
need to specify
As the current initscripts maintainer, I have so far not seen any
requests for this feature, though I'm sure it would be nice to have.
Post by Patrick Lauer
* small footprint - 10k LoC C99, ~3k LoC Posix SH out of the box (plus
your own init scripts, of course)
+ bash itself (which provides our /bin/sh).
Post by Patrick Lauer
* friendly responsive upstream (let's figure out how we can cooperate, eh?)
This is nice (and is also very much true of systemd).
Post by Patrick Lauer
* boring - deterministic reproducable bootup, including interactive mode
and verbose debug output
How can you be both parallelisable and deterministic?
Post by Patrick Lauer
For a long time we haven't done any active advertising, but OpenRC is
now about 5 years old, and it is a drop-in replacement for our previous
"baselayout" init system (which was started over a decade ago). We don't
try to take over the world, we just create the best solution for our
needs. And those go all the way from embedded systems (where you can use
busybox for all the shell tools) to servers (minimal deps! No mandatory
udev or dbus!) and desktops (including optional splash screen eyecandy
and whatever makes you happy).
There's pretty good support for advanced usage like SELinux, built-in
support for ulimit and cgroups to do per-service resource limits, and it
even comes with a friendly license (although some might say that a
2-clause BSD license it too friendly and promiscuous). And as a random
bonus feature you get stupid-fast bootup - We've seen <5sec from
bootloader handover to login prompt (depending on hardware and amount of
services started, of course) and <5sec for rebooting a kvm guest.
If someone would be willing to evaluate and package openrc so we could
all make an informed decision, I think that would be very useful. That
said, my immediate impression is that it is not a great improvement
over initscripts, and its professed benefits over systemd seem based
on misconceptions (the "openrc bonus features" table on the webpage
contains serious errors about systemd) or do not apply to Arch, so I
will not be taking this on myself.

I strongly believe that should we move away from intscripts it needs
to be to an event-driven system (such as systemd or upstart) and it
was not clear from the webpage that OpenRC provides this.

Cheers,

Tom
Rashif Ray Rahman
2012-04-25 15:54:08 UTC
Permalink
Post by Tom Gundersen
I strongly believe that should we move away from intscripts it needs
to be to an event-driven system (such as systemd or upstart) and it
was not clear from the webpage that OpenRC provides this.
I concur.

Although the current init works for me and won't encourage me to shift to
things like systemd anytime soon, efforts towards introducing alternatives
would have to be justified by how much more they're able to bring to the
table. Simply being different or offering a few bonuses won't be enough,
IMO. Systemd is something dynamic and is what fits that ideal model, a
model which satisfies the needs of the present and hopefully the future.

Otherwise, I like my init as simple as it currently is. Dependency is never
a problem as it's very little work to manually ensure they're met.


--
GPG/PGP ID: C0711BF1
Kaiting Chen
2012-04-25 16:38:30 UTC
Permalink
Post by Rashif Ray Rahman
Post by Tom Gundersen
I strongly believe that should we move away from intscripts it needs
to be to an event-driven system (such as systemd or upstart) and it
was not clear from the webpage that OpenRC provides this.
I concur.
Although the current init works for me and won't encourage me to shift to
things like systemd anytime soon, efforts towards introducing alternatives
would have to be justified by how much more they're able to bring to the
table. Simply being different or offering a few bonuses won't be enough,
IMO. Systemd is something dynamic and is what fits that ideal model, a
model which satisfies the needs of the present and hopefully the future.
Otherwise, I like my init as simple as it currently is. Dependency is never
a problem as it's very little work to manually ensure they're met.
--
GPG/PGP ID: C0711BF1
The problem I have with a systemd like init system is that it's way too
much overkill for a server. I like our current situation as we have an
extremely simple init system and users can drop in systemd if they so
choose. --Kaiting.
--
Kiwis and Limes: http://kaitocracy.blogspot.com/
Calvin Morrison
2012-04-25 18:17:17 UTC
Permalink
Post by Kaiting Chen
Post by Rashif Ray Rahman
Post by Tom Gundersen
I strongly believe that should we move away from intscripts it needs
to be to an event-driven system (such as systemd or upstart) and it
was not clear from the webpage that OpenRC provides this.
I concur.
Although the current init works for me and won't encourage me to shift to
things like systemd anytime soon, efforts towards introducing alternatives
would have to be justified by how much more they're able to bring to the
table. Simply being different or offering a few bonuses won't be enough,
IMO. Systemd is something dynamic and is what fits that ideal model, a
model which satisfies the needs of the present and hopefully the future.
Otherwise, I like my init as simple as it currently is. Dependency is never
a problem as it's very little work to manually ensure they're met.
--
GPG/PGP ID: C0711BF1
The problem I have with a systemd like init system is that it's way too
much overkill for a server. I like our current situation as we have an
extremely simple init system and users can drop in systemd if they so
choose. --Kaiting.
+1

Arch follows the nice KISS principle and a bit of DIY. We should have
default a simple and sane system that works, and if anyone feels the
need to install some crazy new fangled type, they can go ahead.

OpenRC works well in Gentoo, i don't see why it would not work well here.
Nicolas Sebrecht
2012-04-26 08:54:55 UTC
Permalink
Post by Calvin Morrison
Post by Kaiting Chen
I like our current situation as we have an
extremely simple init system and users can drop in systemd if they so
choose.
I like our current situation as we have an
extremely simple init system and users can drop in //OpenRC// if they so
choose.
Post by Calvin Morrison
+1
Arch follows the nice KISS principle and a bit of DIY. We should
have default a simple and sane system that works, and if anyone
feels the need to install some crazy new fangled type, they can go
ahead.
OpenRC works well in Gentoo, i don't see why it would not work well here.
So, OpenRC could be proposed as an alternative init system in AUR.
--
Nicolas Sebrecht
Sam Mulvey
2012-04-26 09:23:09 UTC
Permalink
Post by Kaiting Chen
The problem I have with a systemd like init system is that it's way too
much overkill for a server. I like our current situation as we have an
extremely simple init system and users can drop in systemd if they so
choose. --Kaiting.
I concur. For my purposes the Arch init system isn't broken.

For the arch init, even dependencies aren't too big a deal given that the linear way system services are defined in rc.conf, though I know it's been an important feature in other init systems. Having the arch init with systemd as an option if it's needed or wanted is great, but I can imagine trying to keep two init systems in mind while maintaining could get nightmarish.


-Sam
Patrick Lauer
2012-05-07 13:30:46 UTC
Permalink
Post by Rashif Ray Rahman
Post by Tom Gundersen
I strongly believe that should we move away from intscripts it needs
to be to an event-driven system (such as systemd or upstart) and it
was not clear from the webpage that OpenRC provides this.
I concur.
Although the current init works for me and won't encourage me to shift to
things like systemd anytime soon, efforts towards introducing alternatives
would have to be justified by how much more they're able to bring to the
table.
And how many antifeatures they have ;)
For me the feature list of systemd is kinda nice, it's obviously more
comprehensive than the "old" init systems, but it goes against the unix
spirit of having one tool for a job, and do this job well. Having all
the features and being able to not have the antifeatures is what makes
OpenRC extra nice ...
Post by Rashif Ray Rahman
Simply being different or offering a few bonuses won't be enough,
IMO. Systemd is something dynamic and is what fits that ideal model, a
model which satisfies the needs of the present and hopefully the future.
"dynamic" how?
People have thrown "event based" and such words around, but no one has
dared to clarify or properly define what they mean by it. Thus I can't
understand if there's anything missing in OpenRC or people are just
throwing words around because it feels good.
Post by Rashif Ray Rahman
Otherwise, I like my init as simple as it currently is. Dependency is never
a problem as it's very little work to manually ensure they're met.
You only realize what you're missing when you've lost it ;)
For me not having dependencies is very frustrating, it makes restarting
things so random and assumes that I know or care about who depends on
what (hint: that's the job of the init system, not mine)
XeCycle
2012-05-07 14:40:01 UTC
Permalink
Patrick Lauer <***@gentoo.org> writes:

[...]
Post by Patrick Lauer
And how many antifeatures they have ;)
For me the feature list of systemd is kinda nice, it's obviously more
comprehensive than the "old" init systems, but it goes against the unix
spirit of having one tool for a job, and do this job well.
That design philosophy can be overused.

"One tool for a job", yeah, seems to make sense, in that it makes
easy to do it well; but you have to define the job precisely.
Some jobs are cooperative; if you follow that spirit, you may not
want to let the programs know who they're talking to, and you
must invent a nice way of cooperation. While many these ways are
out there, most are either not powerful enough or not general
enough, therefore existing programs still need to know who
they're talking to. That's contradictory.

Violations of this philosophy can be easily found. The Linux
kernel is such one. It is already big, with many misfeatures, or
"anitfeature"s; but we all use it, right? Linus said such a
design simplifies the intercommunication between kernel modules.
Yes, monolithic improves integration. systemd, being a
Linux-only project, in my idea it's quite acceptable to use this
design: it brings together otherwise messy things, and gives a
unified interface, at the same time being easy to get good
performance.

Some jobs are born dirty. If you deal with these using those
elegant and orthogonal tools, it's very likely that you end up
splicing those tools into another strange dirty tool; what's
worse, the user must understand how you built it to actually use
your tool without too many problems.
Post by Patrick Lauer
Having all the features and being able to not have the
antifeatures is what makes OpenRC extra nice ...
Above comments are towards that damn spirit, not OpenRC. I
didn't use OpenRC though, but from all your discussions, it seems
at least more feature-rich than the default init system.

The default init is way too simple in my POV. E.g. it requires
the user to sort out the sequence to start these daemons; that,
while not very hard to do, is unnecessary.
Post by Patrick Lauer
Post by Rashif Ray Rahman
Simply being different or offering a few bonuses won't be enough,
IMO. Systemd is something dynamic and is what fits that ideal model, a
model which satisfies the needs of the present and hopefully the future.
"dynamic" how?
People have thrown "event based" and such words around, but no one has
dared to clarify or properly define what they mean by it. Thus I can't
understand if there's anything missing in OpenRC or people are just
throwing words around because it feels good.
Hate such words too. But I normally ignore that, it's just like
those commercial ads --- no even one cal of gnutrition inside.

Perhaps they assume you have used their software. systemd is
able to start programs when needed, and may stop them when no
longer in use. They don't feel like writing this sentence every
time being asked about its advantage, so they use that word for
it.
Post by Patrick Lauer
Post by Rashif Ray Rahman
Otherwise, I like my init as simple as it currently is. Dependency is never
a problem as it's very little work to manually ensure they're met.
You only realize what you're missing when you've lost it ;)
For me not having dependencies is very frustrating, it makes restarting
things so random and assumes that I know or care about who depends on
what (hint: that's the job of the init system, not mine)
--
Carl Lei (XeCycle)
Department of Physics, Shanghai Jiao Tong University
OpenPGP public key: 7795E591
Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
Kevin Chadwick
2012-05-07 16:19:58 UTC
Permalink
On Mon, 07 May 2012 22:40:01 +0800
Post by XeCycle
Violations of this philosophy can be easily found. The Linux
kernel is such one. It is already big, with many misfeatures, or
"anitfeature"s; but we all use it, right? Linus said such a
design simplifies the intercommunication between kernel modules.
I disagree, your obviously clutching at straws, OpenBSD, no modules but
monolithic yes. Many argue for and against monolithic or kernels such
as QNX where drivers can't hang the kernel (atleast in theory). This is
irrelevent. Simple tools do become more than they're parts. grep, cut,
tr, cat and do they're particular job well and with less bugs. Init is a
simple job.

The main case you didn't bring up is perhaps where speed is paramount.
I can't think of any others of the top of my head and certainly none
that apply to whether the ultimate dependency, init, should be complex.


Imagine a system where the kernel had been stripped down to kilobytes
yet init was megabytes.

p.s. I wouldn't mind knowing more about event driven too. I believe I
was given an impression of what it was when systemd first hit ubuntu but
I can't remember finding out exactly. A quick google just now turned up
nothing.
Tom Gundersen
2012-05-07 15:41:38 UTC
Permalink
Post by Kevin Chadwick
p.s. I wouldn't mind knowing more about event driven too. I believe I
was given an impression of what it was when systemd first hit ubuntu but
I can't remember finding out exactly. A quick google just now turned up
nothing.
To help your googling: ubuntu does not use systemd (in fact they are
the only distro to announce that they are going with something else
(upstart)).

-t
Leonid Isaev
2012-05-07 16:17:59 UTC
Permalink
On Mon, 7 May 2012 17:19:58 +0100
Post by Kevin Chadwick
p.s. I wouldn't mind knowing more about event driven too. I believe I
was given an impression of what it was when systemd first hit ubuntu but
I can't remember finding out exactly. A quick google just now turned up
nothing.
Ubuntu is unlikely to provide an official support for systemd in the mid-term
(i.e. in the next 2+ years): http://www.markshuttleworth.com/archives/1121. My
reading between the lines: "We have an enterprise branch (LTS) so can't afford
to come up with new things every 6 months (especially if upstart does
everything we want), while Fedora is designed exactly for this goal.". I think
that's a reasonable decision, especially now when they are picking up
consolekit.
--
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
XeCycle
2012-05-08 02:27:08 UTC
Permalink
Post by Kevin Chadwick
On Mon, 07 May 2012 22:40:01 +0800
Post by XeCycle
Violations of this philosophy can be easily found. The Linux
kernel is such one. It is already big, with many misfeatures, or
"anitfeature"s; but we all use it, right? Linus said such a
design simplifies the intercommunication between kernel modules.
I disagree, your obviously clutching at straws, OpenBSD, no modules but
monolithic yes. Many argue for and against monolithic or kernels such
as QNX where drivers can't hang the kernel (atleast in theory). This is
irrelevent. Simple tools do become more than they're parts. grep, cut,
tr, cat and do they're particular job well and with less bugs.
You're right, but --- you still need something complex to do with
complex jobs, so I'd say there's nothing wrong with these complex
tools --- right?

In the traditional pipe way of using these Unix tools, each are
acting quite like a finite automata, and you join them
sequentially to perform the job. But a finite automata is not
Turing-complete, you'll need to do a lot more when you need
something missing in this paradigm. So we see many sys admins go
with Perl.
Post by Kevin Chadwick
Init is a simple job.
Depends on what you want out of it. You can surely hand off
parts of the job to something else, say, user session management;
but if that job needs to talk to init to do better, why not just
integrate it with init.
Post by Kevin Chadwick
The main case you didn't bring up is perhaps where speed is paramount.
I can't think of any others of the top of my head and certainly none
that apply to whether the ultimate dependency, init, should be complex.
Imagine a system where the kernel had been stripped down to kilobytes
yet init was megabytes.
That would be a waste of brain cells. If several MiBs is surely
needed to make the system usable, it's okay to call them together
as "kernel".
Post by Kevin Chadwick
p.s. I wouldn't mind knowing more about event driven too. I believe I
was given an impression of what it was when systemd first hit ubuntu but
I can't remember finding out exactly. A quick google just now turned up
nothing.
IIRC Ubuntu goes with Upstart the first time I heard of them.
--
Carl Lei (XeCycle)
Department of Physics, Shanghai Jiao Tong University
OpenPGP public key: 7795E591
Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
Tom Gundersen
2012-05-07 15:39:35 UTC
Permalink
Hi Patrick,
Post by Patrick Lauer
People have thrown "event based" and such words around, but no one has
dared to clarify or properly define what they mean by it. Thus I can't
understand if there's anything missing in OpenRC or people are just
throwing words around because it feels good.
I assumed anyone working with init systems had a firm grasp of the
main selling-points of the competition, but let me try to explain what
I have in mind (by no means take this as authorative, there is plenty
of writing on this both by the upstart guys and the systemd guys who
know it better than me).

I guess it is best explained in terms of an example, let's take
storage: Traditionally we would wait for all the storage devices to be
enumerated, then fsck all of them, then mount all of them, then start
the daemons which might require something from say /var. This no
longer works well with modern hardware and a modern kernel.

The reason is that we don't know when the kernel has finished
enumerating all the devices (sometimes we do, but not always, it
depends on the device), and we certainly don't know in case the user
has not yet plugged in all the devices at boot, or some of them are
network devices that may or may not appear depending on what network
we are currently connecting to.

An event-driven init system would turn this on its head, and never
wait for "all the things to be ready", rather start things on-demand
and whenever their dependencies are satisfied. This leads to a much
simpler system (from the admin/system daemon developers point of
view), but it requires the init system to keep closer control over the
state of the system, listen to events, etc.

This means that there is no difference between "boot time" and any
other time. If you plug in your network cable, or your external hard
drive a week after switching on your computer they will be mounted (if
that's what you configured in your /etc/fstab) in exactly the same way
as if they were connected when you started your computer.
Post by Patrick Lauer
Post by Tom Gundersen
Post by Patrick Lauer
About modules and bloat - for systemd you're going from a few hundred
lines of shell to a few hundred thousand lines of mandatory
dependencies.
I have no idea where you get these numbers from, or why they should matter.
These numbers come from comparing the code that is involved in system
startup. If you get really fancy you use something like "sloccount", or
if you're lazy like me you just use wc -l.
I know how to measure the number of lines of code, and I do
acknowledge that if you can do the same job with less code that's
nice. My question was: what are you counting as "mandatory
dependencies" for systemd. I know of libdbus (the daemon is not
mandatory) and, contrary to what it says on the openrc website, glib2
is not a mandatory dependency.

What do I do when things don't work? Use the awesome debugging tools
that systemd provides. Makes my life a hell of a lot easier compared
to when debugging initscripts.
Post by Patrick Lauer
Already udev lost features and got wrongly renamed, and we haven't even
had a proper release yet.
Udev got slimmed down a bit, but this was the right thing to do even
without systemd. One tool for one job, right? It no longer creates
device nodes, instead it says that that is the job of the kernel
(mostly) or (for the few exceptions the kernel can't deal with) some
separate user-space tool that is called during boot. systemd ships one
such tool, which you could easily copy, or you could make your own. It
would be about three lines of bash ;-)
Post by Patrick Lauer
Post by Tom Gundersen
What's wrong with WantedBy? You don't like the term, or do you have a
technical problem with it?
It's very difficult to handle properly - you have to check all init
scripts / unit files / znargfruzzles every time to see if their
dependencies changes, and if they have any WantedBys.
I'm struggling to follow your line of thought... "every time" what?
WantedBy are simply used when you enable a service. Typically you'll
either have WantedBy=multi-user.target or WantedBy=graphical.target,
to tell systemd which "runlevel" the service should start in, I don't
see why this, of all things, would cause such huge problems.
Post by Patrick Lauer
And you should ask
people that had to debug threaded INTERCAL why it's not as awesome as it
sounds at first glance ...
I didn't know what INTERCAL was:

"INTERCAL is an esoteric programming language that was created as a
parody by [...] two Princeton University students, in 1972. It
satirizes aspects of the various programming languages at the time, as
well as the proliferation of proposed language constructs and
notations in the 1960s."

Doesn't seem very relevant to the current discussion...
Post by Patrick Lauer
"Not possible" is not a valid response to my problem-removal-needs.
SystemD is too big and too undocumented for me to trust my skills, I
wouldn't want to have to rely on a system that I mutilated like that
just to fix a rare corner case that "shouldn't be there" (yeah, great,
thanks, it *is* there. Do you want to make it go away?)
I think some of the point of systemd is that once you find a weird
corner-case that does not work you can bring it to the attention of
the dozens of talented hackers from all
distros/formfactor/architectures/... and someone will be able to fix
it (hopefully without any unwanted side-effects).
Post by Patrick Lauer
You have no idea how much it bothers me to have to repeat myself, again,
for the last time I hope ... but ...
What do people actually *mean* by event driven?
If you had given people a chance to reply to your first email, you
would not have needed to ask twice ;-)
Post by Patrick Lauer
So all in all you just managed to upset some greybeards and turned a
technical discussion into random ad hominems. Nice :)
No he didn't. He was quite right in pointing out that distribution
maintainers are not necessarily great developers, which probably has
lead to lots of bad shell scripts over the years spread around in
different distributions. You are the only one attacking people (in
particular one of the systemd maintainers, who is not even involved in
this discussion). It is really making the OpenRC community look bad.

On a somewhat related note, I was reminded to check your website again
to see if you corrected your table of features. I thought I might let
you know of the errors I found (making these kind of blunders makes it
look like you don't really know the competition):

* systemd is portable to non-x86 (as far as I know, it is tested on a
wide range of architectures and aims to work on anything that works
with the Linux kernel)
* systemd definitely separates code and config, as far as the
admin/user is concerned s/he only has to deal with /etc/systemd/ which
contain declarative .desktop-style configuration files. No code.
* systemd is very extensible, you can easily add in your own .service
files to do whatever you want (I imagine you could even use systemd as
your init and only run openrc as your only service file and it should
just work).
* friendly upstream: no comment.
* complex init scripts: don't know what you mean, but you can use
whatever initsrcipts you want in systemd
* i'd be interested in reading more about how you automatically
calculate dependencies to a greater extent than systemd. do you have a
link, or could you elaborate?
* systemd integrates into virtualization (more so in the next release)
* the architecture is definitely modular, just look at the sourctree,
most of those subfolders correspond to separate tools that can be
disabled or exchanged for something else.
* lots and lots and lots of verbose debugging available if you chose
to enable it. Both from systemd itself and from whatever your daemons
spits out to stderr.

Cheers,

Tom
Kevin Chadwick
2012-05-07 16:54:34 UTC
Permalink
On Mon, 7 May 2012 17:39:35 +0200
Post by Tom Gundersen
An event-driven init system would turn this on its head, and never
wait for "all the things to be ready", rather start things on-demand
and whenever their dependencies are satisfied. This leads to a much
simpler system (from the admin/system daemon developers point of
view), but it requires the init system to keep closer control over the
state of the system, listen to events, etc.
But a much more complicated one from the admin/system user in terms
of troubleshooting. Also in terms of auditing. Rather than seeing what
ports are listening by default, we have to investigate (hopefully in
one location) to know what will be listened to upon any future possible
event. I hope efforts made to make that very clear.


Thanks for the explanation, are there some examples of what this means
we can do that couldn't be done in any way outside of init before.
Tom Gundersen
2012-05-07 16:15:23 UTC
Permalink
Post by Kevin Chadwick
On Mon, 7 May 2012 17:39:35 +0200
Post by Tom Gundersen
An event-driven init system would turn this on its head, and never
wait for "all the things to be ready", rather start things on-demand
and whenever their dependencies are satisfied. This leads to a much
simpler system (from the admin/system daemon developers point of
view), but it requires the init system to keep closer control over the
state of the system, listen to events, etc.
But a much more complicated one from the admin/system user in terms
of troubleshooting. Also in terms of auditing. Rather than seeing what
ports are listening by default, we have to investigate (hopefully in
one location) to know what will be listened to upon any future possible
event. I hope efforts made to make that very clear.
Daemons that are ported to work with the new systemd socket activation
(see dbus and udev for examples, there are also plenty others) will
allow this very easily.

The way it works is that the sockets will be listened to at all times,
even before the daemons are running. So starting a daemon would not,
if it uses pure socket activation, open any new sockets. Once your
daemon does eventually start, the socket will be passed to it so it
can handle any connections that came in while it was not yet ready to
accept them.
Post by Kevin Chadwick
Thanks for the explanation, are there some examples of what this means
we can do that couldn't be done in any way outside of init before.
I guess anything is always possible (bash is Turing complete, right
;-) ). That said, we'll get lots of simplifications and can drop old
workarounds:

We can remove arbitrary timeouts or retry-loops. Especially when it
comes to usb storage we often have issues with booting too fast, so
that the device is not yet ready when we try to mount it. That would
no longer be a problem.

Currently, we support a relatively limited number of storage
configurations (combinations of lvm/md/dm/encryption). With systemd we
now deal with encrypted devices in a nice way, but there is still some
way to go before the whole storage stack is event-driven. Once this is
the case there will no longer be any restrictions on how you combine
storage devices, on top of that the code to do this will be much
simpler than the current code.

Also, by the fact that things are more finegrained we can deal with
some dependencies which were not possible (without a refactor) before.
One example could be that we want to first mount /var, then read our
random-seed from /var so we can use it as a random encryption key for
/tmp. If we mount /tmp and /var at the same time that's not going to
work :-) Obviously we can sort this out by refactoring our initscripts
a bit, but we could think of more complicated scenarios, where you do
not want to have a rigid a system as what our current initscripts are.

Btw, I don't know how any of this compares to OpenRC as I have not
looked at it at all (I was not impressed by the PR campaign...).

-t
Tom Gundersen
2012-05-08 21:14:03 UTC
Permalink
Post by Tom Gundersen
(by no means take this as authorative, there is plenty
of writing on this both by the upstart guys and the systemd guys who
know it better than me).
This was just published, which probably describes the concepts better
than my simple example:
<http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html>.

-t
David C. Rankin
2012-04-26 12:46:22 UTC
Permalink
Post by Tom Gundersen
While dependencies (done in the right way) might have been nice to
have, I don't see this as a major shortcoming of our current system,
and if we are to change away from initscripts the replacement would
have to provide significantly better benefits than that, in my humble
opinion.
KISS - If it "ain't" broke, don't fix it.... I'm sure some may have needs that
exceed what the current initscripts can provide, the simple efficient Arch way
has done, and continues to do, quite well.
--
David C. Rankin, J.D.,P.E.
Kwpolska
2012-04-26 16:01:51 UTC
Permalink
When I first saw the topic, I thought "yet another systemd-like piece
of crap?" Then I read that this is from Gentoo and the rest of the
original post and I think it could be nice and I could even switch to
it one day. But do you actually need to bother with runlevels or is
it like arch (everything in $DAEMONS goes to 3 and 5, and 5 can be set
for X through inittab)?
--
Kwpolska <http://kwpolska.tk>
stop html mail      | always bottom-post
www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
GPG KEY: 5EAAEA16   | Arch Linux x86_64, zsh, mutt, vim.
# vim:set textwidth=70:
Patrick Lauer
2012-05-07 13:57:23 UTC
Permalink
Post by Kwpolska
When I first saw the topic, I thought "yet another systemd-like piece
of crap?" Then I read that this is from Gentoo and the rest of the
original post and I think it could be nice and I could even switch to
it one day. But do you actually need to bother with runlevels or is
it like arch (everything in $DAEMONS goes to 3 and 5, and 5 can be set
for X through inittab)?
Well, you get named runlevels which you can call from inittab:

l0:0:wait:/sbin/rc shutdown
l0s:0:wait:/sbin/halt -dhp
l1:1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
etc. etc.

So if you want to split things like that, yes that's possible.
The advantage is that the runlevels are named, so you have "default",
and you could have "desktop" if you wanted. And if you are really crazy
you could write an acpid rule that switches to "powersave" runlevel if
AC power is removed, etc. etc.

The sky is the limit :)

Take care,

Patrick
Sébastien le Preste de Vauban
2012-04-27 23:54:47 UTC
Permalink
Post by David C. Rankin
KISS - If it "ain't" broke, don't fix it.... I'm sure some may have
needs that exceed what the current initscripts can provide, the simple
efficient Arch way has done, and continues to do, quite well.
+1
Leonid Isaev
2012-04-25 17:57:03 UTC
Permalink
On Wed, 25 Apr 2012 22:03:19 +0800
Post by Patrick Lauer
Greetings,
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current Arch Linux init system is a bit minimal and gets the job done,
but it's not superawesome. There's things like init script dependencies that
would be nice to have, but then it's about the smallest of all init systems
around.
[...]
Patrick Lauer
Gentoo Developer, OpenRC co-maintainer
Thanks for your explanation. However, I sense a confusion regarding an init
system and a boot process. AFAIU openrc still uses /sbin/init -- the
daemons/services are handled through a set of (ba)sh scripts. From what
I learn from systemd documentation, all services are handled by one daemon --
dependencies, tracking, etc. are a natural bonus, so to say. Although I also
dislike the idea of systemd-{journald,logind,...}, as long as those things are
implemented via modules, I don't think they are "bloat". So IMO the only
negative thing in arch's adoption of systemd is that rc.conf will have to go
away :)
--
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Nicholas MIller
2012-04-25 18:07:43 UTC
Permalink
Post by Leonid Isaev
On Wed, 25 Apr 2012 22:03:19 +0800
Post by Patrick Lauer
Greetings,
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current Arch Linux init system is a bit minimal and gets the job done,
but it's not superawesome. There's things like init script dependencies that
would be nice to have, but then it's about the smallest of all init systems
around.
[...]
Patrick Lauer
Gentoo Developer, OpenRC co-maintainer
Thanks for your explanation. However, I sense a confusion regarding an init
system and a boot process. AFAIU openrc still uses /sbin/init -- the
daemons/services are handled through a set of (ba)sh scripts. From what
I learn from systemd documentation, all services are handled by one daemon --
dependencies, tracking, etc. are a natural bonus, so to say. Although I also
dislike the idea of systemd-{journald,logind,...}, as long as those things are
implemented via modules, I don't think they are "bloat". So IMO the only
negative thing in arch's adoption of systemd is that rc.conf will have to go
away :)
rc.conf is one big reason I use arch instead of gentoo...
Post by Leonid Isaev
--
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Patrick Lauer
2012-04-26 00:27:37 UTC
Permalink
Post by Leonid Isaev
On Wed, 25 Apr 2012 22:03:19 +0800
Post by Patrick Lauer
Greetings,
in the last months there have been many discussions about init systems,
especially systemd. The current state seems to make no one really happy
- the current Arch Linux init system is a bit minimal and gets the job done,
but it's not superawesome. There's things like init script dependencies that
would be nice to have, but then it's about the smallest of all init systems
around.
[...]
Patrick Lauer
Gentoo Developer, OpenRC co-maintainer
Thanks for your explanation. However, I sense a confusion regarding an init
system and a boot process. AFAIU openrc still uses /sbin/init
Yes and no, we only use sysvinit to trigger the "we are booting" and "we
are changing runlevel" events. To quote /etc/inittab:

l1:1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
Post by Leonid Isaev
-- the daemons/services are handled through a set of (ba)sh scripts.
most of the logic is posix sh, the dependency resolution and some other
bits are C.
Post by Leonid Isaev
From what
I learn from systemd documentation, all services are handled by one daemon --
dependencies, tracking, etc. are a natural bonus, so to say.
... why should that be a daemon? (And what happens in the unlikely event
that the supercomplexified PID #1 self-terminates? I think there's a
very good set of reasons why sysvinit's "init" is very small and simple ...)
Post by Leonid Isaev
Although I also
dislike the idea of systemd-{journald,logind,...}, as long as those things are
implemented via modules, I don't think they are "bloat". So IMO the only
negative thing in arch's adoption of systemd is that rc.conf will have to go
away :)
Yes. It's redundant ;)
In the end our runlevels are just symlinks to the init scripts in
/etc/init.d and managed with the rc-update / rc-config / rc-status
tools. "rc-update add squid default; rc" is such a boring way to add a
service to the default runlevel and start it ... and once you get hooked
on rc-status you'll be wondering why you didn't have it before.

About modules and bloat - for systemd you're going from a few hundred
lines of shell to a few hundred thousand lines of mandatory
dependencies. There's so many exciting ways you could accidentally
trigger a bug in that, it goes against my philosophy that computers
should be boring and doesn't let me be lazy. It does have a few decent
ideas (like CGroups - which ended up taking me an afternoon to get
initially patched into OpenRC) but at the cost of a rather hostile
upstream that likes writing code more than anything and goes in a
direction that makes some of us very much not happy, especially as it
now corrupts other unrelated projects like udev (oh, systemd-udevd) and
syslog-ng (haha, you get journald now!) and so on. Oh well.

Take care,

Patrick
Tom Gundersen
2012-04-26 09:08:21 UTC
Permalink
Post by Patrick Lauer
About modules and bloat - for systemd you're going from a few hundred
lines of shell to a few hundred thousand lines of mandatory
dependencies.
I have no idea where you get these numbers from, or why they should matter.
Post by Patrick Lauer
but at the cost of a rather hostile
upstream
I do not have this impression at all. systemd devs certainly have been
very open to all the suggestions I have made to make it work better on
Arch.
Post by Patrick Lauer
that likes writing code more than anything and goes in a
direction that makes some of us very much not happy, especially as it
now corrupts other unrelated projects like udev (oh, systemd-udevd) and
syslog-ng (haha, you get journald now!) and so on
This does not make sense. udev still works the same on systemd-less
systems and syslog-ng works just fine with (or without) systemd.

I am very happy that you are trying to educate us about OpenRC, but if
you are going to attack systemd please get your facts straight and
refrain from spreading unsubstantiated FUD.

-t
Patrick Lauer
2012-05-07 13:54:31 UTC
Permalink
Post by Tom Gundersen
Post by Patrick Lauer
About modules and bloat - for systemd you're going from a few hundred
lines of shell to a few hundred thousand lines of mandatory
dependencies.
I have no idea where you get these numbers from, or why they should matter.
These numbers come from comparing the code that is involved in system
startup. If you get really fancy you use something like "sloccount", or
if you're lazy like me you just use wc -l.

It matters because more complexity means more bugs and things are harder
to debug, and that's something where I just can't justify spending more
time on things when they could be kept boringly simple.

If you don't understand that I wonder what you do when something doesn't
work (and please don't answer reinstall)
Post by Tom Gundersen
Post by Patrick Lauer
but at the cost of a rather hostile
upstream
I do not have this impression at all. systemd devs certainly have been
very open to all the suggestions I have made to make it work better on
Arch.
If you agree with them they are kinda ok.
My ideas tend to conflict with their vision, so I usually see that
others who verbalized the same idea get shot down on the mailinglists
with comments that make me wonder if I'm really confused or reality just
got very bizzare.
Post by Tom Gundersen
Post by Patrick Lauer
that likes writing code more than anything and goes in a
direction that makes some of us very much not happy, especially as it
now corrupts other unrelated projects like udev (oh, systemd-udevd) and
syslog-ng (haha, you get journald now!) and so on
This does not make sense. udev still works the same on systemd-less
systems and syslog-ng works just fine with (or without) systemd.
Wanna bet? ;)
Already udev lost features and got wrongly renamed, and we haven't even
had a proper release yet.
At this rate we will have to switch to alternatives before the three
next systemd releases are done.
Post by Tom Gundersen
I am very happy that you are trying to educate us about OpenRC, but if
you are going to attack systemd please get your facts straight and
refrain from spreading unsubstantiated FUD.
Lenny started the FUD. I'm slightly annoyed with that, but I'm relying
on facts (see code size, easy to verify) and don't just call other
people stupid, ignorant or call their product obsolete crap.

Although I could do that, but how does that help me to keep things
boring and predictable for me?


Take care and stop being such a grumpy teddybear,

Patrick
Leon Feng
2012-04-26 02:43:57 UTC
Permalink
Post by Patrick Lauer
Greetings,
...
Post by Patrick Lauer
Should you decide to switch (or just evaluate if switching is possible /
makes sense) you'll get full support from us in migrating init scripts
and figuring out all the nontrivial changes. Just visit us on IRC (
meet us for a beer or two.
Thanks for your consideration,
Patrick Lauer
Gentoo Developer, OpenRC co-maintainer
I am a 2 years Gentoo user and than switch to Arch for about 3 years.
I just think OpenRC does not have too much difference with Arch's
current init system.

Any way, Arch is open to any change. But if you want to propose the
switch, the best way is to make it happen by effort of yourself.

Here is the action taken by people who propose systemd:
1. Make systemd package easily available. First as AUR package, then
official package in the repo.
2. Have a quit good bbs thread and answer every users question quickly.
3. Create a good Wiki page https://wiki.archlinux.org/index.php/Systemd.
And now more and more users are switching to systemd, including me.

People who propose OpenRC should do the same or even better then
systemd and win more users. Recently systemd is gradually getting
momentum. So hurry up. Competition is always a good thing.

Leon Feng
Nicolas Sebrecht
2012-04-26 08:49:26 UTC
Permalink
Hi,
Post by Patrick Lauer
As an alternative to the One Process For Everything I'd like to ask you to evalute OpenRC as an init system for Arch Linux.
<...>
Post by Patrick Lauer
While Gentoo is by far the largest user it's definitely not the only one
- there are the direct derivatives (Sabayon, pentoo, funtoo,
sysrescuecd, tinhat, ...) and some "foreign" users (Alpine, a debian
derivative, uses OpenRC)
Alpine is highly dedicated to small systems with few physical resources
which makes the reference not much relevant.
Post by Patrick Lauer
Should you decide to switch (or just evaluate if switching is possible /
makes sense) you'll get full support from us in migrating init scripts
and figuring out all the nontrivial changes. Just visit us on IRC (
meet us for a beer or two.
Thanks for your consideration,
Patrick Lauer
Gentoo Developer, OpenRC co-maintainer
I wouldn't expect anything else from a OpenRC maintainer to support his
tool to be used on other platforms. :-)

But to be fair, you should say that the future of OpenRC is NOT certain
in Gentoo at least, and as a consequence in all of the forked projects.

Please all, take a look at:
- http://marc.info/?l=gentoo-dev&m=130929913506375&w=4
- https://bugs.gentoo.org/show_bug.cgi?id=373219
- http://marc.info/?l=gentoo-dev&m=132538362810246&w=4

Gentoo might make systemd the default init system in the future. Nobody
can say if and when this could heppen but this is clearly possible for
OpenRC to become a Gentoo init system _alternative_.

This is why I think that switching to OpenRC *now* would be wrong.
--
Nicolas Sebrecht
Kevin Chadwick
2012-04-27 08:53:26 UTC
Permalink
On Thu, 26 Apr 2012 10:49:26 +0200
Post by Nicolas Sebrecht
Gentoo might make systemd the default init system in the future. Nobody
can say if and when this could heppen but this is clearly possible for
OpenRC to become a Gentoo init system _alternative_.
This is why I think that switching to OpenRC *now* would be wrong.
I doubt it would get onto Hardened Gentoo.

So in order to gain a slight speed increase in booting, which can be
done in other ways (Alpine boots faster than any systemd enabled
system). Please give me examples of any other valuable benefits.

We are going to sacrifice, simplicity, amount of code to look for bugs
and most importantly, ease of troubleshooting. One of the beauties of
Unix is the error information. Aren't they all going to be mixed
together on systemd. Imagine if all drivers loaded at once. Ughh Would
many resort to Windows style trial and error more often.


p.s. I'm sure many will disagree on this seperate point but whilst I
like the pretty startup and colors of arch, I have been annoyed in the
past whilst being used to OpenBSD that I have to look at many files for
pacman and functions.sh etc.. If there's a bug I need to fix, I prefer
not to have to dig around and prefer to know it's somewhere right in
front of my eyeballs without thinking about what tab in my editor I'm
on, the sames true to me of overuse of inline functions. Code
location sporadity and use of binary files seems annoyingly on the
increase (not Arches fault).


OpenBSD has several files and recently a directory as part of init.
They have tried to keep this to as few as possible in case the user
wants to lock it down, it has other great benefits. This simplicity
surely fits with Arch.
Jan Steffens
2012-04-27 17:08:34 UTC
Permalink
Post by Kevin Chadwick
We are going to sacrifice, simplicity, amount of code to look for bugs
and most importantly, ease of troubleshooting. One of the beauties of
Unix is the error information. Aren't they all going to be mixed
together on systemd. Imagine if all drivers loaded at once. Ughh Would
many resort to Windows style trial and error more often.
One of the features of systemd is the large amount of metadata the
journal colllects. This allows filtering on the message source, for
example. Right now that's just the process (and service) that
generated them, but with the coming udev integration and kernel
logging improvements, you will also be able to view kernel messages by
device or module.
Kevin Chadwick
2012-04-28 17:58:01 UTC
Permalink
On Fri, 27 Apr 2012 19:08:34 +0200
Post by Jan Steffens
Post by Kevin Chadwick
We are going to sacrifice, simplicity, amount of code to look for bugs
and most importantly, ease of troubleshooting. One of the beauties of
Unix is the error information. Aren't they all going to be mixed
together on systemd. Imagine if all drivers loaded at once. Ughh Would
many resort to Windows style trial and error more often.
One of the features of systemd is the large amount of metadata the
journal colllects. This allows filtering on the message source, for
example. Right now that's just the process (and service) that
generated them, but with the coming udev integration and kernel
logging improvements, you will also be able to view kernel messages by
device or module.
Hmmm, interesting, but if it just hangs without a panic then there may
be no kernel message and working out what it was doing by looking at
what it had just done before it hung, would be extremely difficult,
wouldn't it?
Kevin Chadwick
2012-04-28 18:12:02 UTC
Permalink
On Sat, 28 Apr 2012 18:58:01 +0100
Post by Kevin Chadwick
but if it just hangs without a panic
I still like KISS for init but thinking about it, The chances of that
are I'd guess next to none, once the drivers are loaded?

I presume you will be able to get to this journal information even if
you switch off and access the drive in another machine?
Tom Gundersen
2012-04-28 20:29:55 UTC
Permalink
Post by Kevin Chadwick
I presume you will be able to get to this journal information even if
you switch off and access the drive in another machine?
You can configure the journal to be saved to disk and process it on a
different machine later on.

-t
C Anthony Risinger
2012-04-28 21:05:54 UTC
Permalink
Post by Jan Steffens
Post by Kevin Chadwick
We are going to sacrifice, simplicity, amount of code to look for bugs
and most importantly, ease of troubleshooting. One of the beauties of
Unix is the error information. Aren't they all going to be mixed
together on systemd. Imagine if all drivers loaded at once. Ughh Would
many resort to Windows style trial and error more often.
One of the features of systemd is the large amount of metadata the
journal colllects. This allows filtering on the message source, for
example. Right now that's just the process (and service) that
generated them, but with the coming udev integration and kernel
logging improvements, you will also be able to view kernel messages by
device or module.
yes this is nice :-)

by far and large, systemd is the init system as i imagined it *should*
be, when i first started using linux ... i can't count the number of
times i thought "/sbin/init doesn't do a damn thing, and is utterly
useless"

"bloat" is not measured by LOC, but rather by degrees of uselessness.

i have converted several desktops -- and servers -- to use systemd
*exclusively*. by this i mean i subsequently "pacman -R initscripts
sysvinit". haven't looked back, and not a single issue that wasn't my
own doing.

after a small amount of learning you can bang out unit files with EASE
... just the other day, i wrote a fwknop.service in probably 5 minutes
or less. now i get to do this ...

-----------------------------------
# systemctl status fwknopd.service
fwknopd.service - firewall knock operator daemon
Loaded: loaded (/etc/systemd/system/fwknopd.service; enabled)
Active: active (running) since Sat, 28 Apr 2012 16:06:08
-0400; 37min ago
Main PID: 18452 (fwknopd)
CGroup: name=systemd:/system/fwknopd.service
└ 18452 /usr/sbin/fwknopd --config-file
/etc/fwknop/fwknopd.conf.local --foreground

Apr 28 16:06:08 some-server.xtfx.net fwknopd[18452]: Starting fwknopd
Apr 28 16:06:08 some-server.xtfx.net fwknopd[18452]: Added jump rule
from chain: INPUT to chain: FWKNOP_INPUT
Apr 28 16:06:09 some-server.xtfx.net fwknopd[18452]: PCAP filter is:
udp port 62201
Apr 28 16:06:09 some-server.xtfx.net fwknopd[18452]: Starting fwknopd
main event loop.
Apr 28 16:06:19 some-server.xtfx.net fwknopd[18452]: (stanza #1) SPA
Packet from IP: 1.2.3.4 received with access source match
Apr 28 16:06:19 some-server.xtfx.net fwknopd[18452]: Added Rule to
FWKNOP_INPUT for 1.2.3.4, tcp/22 expires at 1335643609
Apr 28 16:06:49 some-server.xtfx.net fwknopd[18452]: Removed rule 1
from FWKNOP_INPUT with expire time of 1335643609.
-----------------------------------

... (root needed to see journal) see all that extra info after the
status? that's the systemd journal capturing the stdout of the
foreground process it monitors. the syslog-like timestamps are added
by systemd.

i have custom units managing daemons like this, timers syncing
archlinux mirrors, units modifying /sys/ tunables (there is no
`sysctl` for sysfs!), some that run/reboot XBMC on my HTPC ...

... and on servers especially, i even have units bound to ethernet
devices, automatically managing the interface, and/or starting dhcp!

-----------------------------------
# systemctl status net-dyn-***@eth0.service
Password:
net-dyn-***@eth0.service - dynamic inet interface [phys:eth0]
Loaded: loaded
(/etc/systemd/system/sys-subsystem-net-devices-eth0.device.wants/../net-dyn-***@.service;
enabled)
Active: active (running) since Thu, 26 Apr 2012 23:38:40
-0400; 1 day and 17h ago
Main PID: 175 (dhcpcd)
CGroup: name=systemd:/system/net-dyn-***@.service/eth0
└ 175 /usr/sbin/dhcpcd --config /etc/dhcpcd.conf.local eth0

Apr 26 23:38:45 some-server.xtfx.net dhcpcd[175]: eth0: leased 5.6.7.8
for 86400 seconds
Apr 27 11:37:57 some-server.xtfx.net dhcpcd[175]: eth0: renewing lease
of 5.6.7.8
Apr 27 11:37:57 some-server.xtfx.net dhcpcd[175]: eth0: acknowledged
5.6.7.8 from 74.207.239.122
Apr 27 11:37:57 some-server.xtfx.net dhcpcd[175]: eth0: leased 5.6.7.8
for 86400 seconds
-----------------------------------

... and i plan to make this even more automatic/intelligent in the
future. i also use a handful of other units developed by Exherbo
(git-daemon) that required no changes whatsoever to work for
Archlinux. how's that for cross-platform?

in summary: systemd is fanta-bulous ... and IMO, anything less is just
as useless as that which preceded it. i have no reservations
for-or-against OpenRC, but systemd is the new precedent for
how-to-build-an-init-system-for-modern-systems.
--
C Anthony
Kevin Chadwick
2012-04-29 00:16:46 UTC
Permalink
On Sat, 28 Apr 2012 16:05:54 -0500
Post by C Anthony Risinger
"bloat" is not measured by LOC, but rather by degrees of uselessness.
I disagree here. If many don't use/need those features aside from an
init system initialising things then it is bloat and will have bugs
that will even affect simple firewall systems. Of course I'd use
OpenBSD for a firewall but I know some build a highly stripped down
Linux (kernel).


I hope there's no, well this is cool, and this bits wrong fundamentally
but we and others have done so much work, lets just carry on. Windows
registry springs to mind. Recent events like binary and random config
file locations keep me wondering if the support companies so heavily
involved in Linux have motives to make Linux harder to fix and
customise. I like sed and diff, thankyou very much, I don't want to
learn a thousand different config tools and formats ironically in the
name of 'ease' or 'speed/compatibility' to shut many complainers up.

OpenBSD - hotplugd, sudo - nice and simple.

Linux - udev, polkit and friends - what a mess, where shall I start. Oh
the beginning, right I'll read this book and then I'll know where the
beginning is, of course if somethings configured this then actually
there's a new beginning.

Sorry didn't mean to rant just saying what I see from over complex
newness disregarding strong unix heritage like cross-distro things
such as dconf and gconf bring.

Rather than some conspiracy I'd hope/expect it's simply that having
many many coders bring wanted features but also unstoppable misdirected
trains as there aren't enough top notch respected eyes to notice before
it's too late. Elephantitis.
Post by C Anthony Risinger
i have custom units managing daemons like this, timers syncing
archlinux mirrors, units modifying /sys/ tunables (there is no
`sysctl` for sysfs!), some that run/reboot XBMC on my HTPC ...
... and on servers especially, i even have units bound to ethernet
devices, automatically managing the interface, and/or starting dhcp!
Could you be explicit in what you've gained. Maybe I'm ignorrant of the
details but I see perhaps this functionality being more universal and
that's it?
C Anthony Risinger
2012-04-29 03:10:13 UTC
Permalink
Post by Kevin Chadwick
On Sat, 28 Apr 2012 16:05:54 -0500
Post by C Anthony Risinger
"bloat" is not measured by LOC, but rather by degrees of uselessness.
I disagree here. If many don't use/need those features aside from an
init system initialising things then it is bloat and will have bugs
that will even affect simple firewall systems. Of course I'd use
OpenBSD for a firewall but I know some build a highly stripped down
Linux (kernel).
perhaps it is a matter of taste, but i don't think the init system's
purpose is to simply "initialize" things. it is a state manager, esp.
considering it has abilities no other process has. i wish i could
find the link now, but i read an excerpt regarding the original design
philosophy of the init program ... and while it wasn't 100% straight
forward, the original goals heavily alluded that init was a
intelligent supervisor, and not nearly as dumb as we now know it.

for LXC systems, i previously wrote an "init" in bash, that could
parse inittab, and respond to SIGPWR and SIGINT (powerfail and
crtlaltdelete in inittab), i probably 100 LOC of bash. basic
functionality was implemented in far less ... what's the point? now i
have to write everything in shell scripts for stuff that could
perfectly well be handled by the supervisor.

i write a lot of shell code, and have literally read the bash man page
enough times to be able to jump to any point for reference ... shell
code is anything but secure and rather fragile. it's just not meant
to do as much as we make it. you are probably right about the
firewall case, maybe it wouldn't be needed. but my guess is that you
could actually make the firewall much more fault tolerant and
intelligent by using such a powerful supervisor as systemd. for the
most part though, most systems *do* require intricate and complex
relationships between services, and systemd fills that need
splendidly, *because* it does more that "fire and forget" [initialize]
processes.
Post by Kevin Chadwick
I hope there's no, well this is cool, and this bits wrong fundamentally
but we and others have done so much work, lets just carry on. Windows
registry springs to mind. Recent events like binary and random config
file locations keep me wondering if the support companies so heavily
involved in Linux have motives to make Linux harder to fix and
customise. I like sed and diff, thankyou very much, I don't want to
learn a thousand different config tools and formats ironically in the
name of 'ease' or 'speed/compatibility' to shut many complainers up.
what binary configs? are you referencing? in systemd's case anyway,
the unit files all look like simple key/value environment files, and
are easily parseable by anything. my favorite in this arena is
augeas, because it takes any config file and makes it reliably
editable ... sed is nice and all, and i use it rather heavily for
daily tasks, but it's not suitable for editing other peoples stuff in
an automatic and predictable way.

personally, i'd like to see a configfs of sorts so i could edit all
configs from a single hierarchy (python + augeas + FUSE ... *hint
hint* ... someday :-)
Post by Kevin Chadwick
OpenBSD - hotplugd, sudo - nice and simple.
Linux - udev, polkit and friends - what a mess, where shall I start. Oh
the beginning, right I'll read this book and then I'll know where the
beginning is, of course if somethings configured this then actually
there's a new beginning.
Sorry didn't mean to rant just saying what I see from over complex
newness disregarding strong unix heritage like cross-distro things
such as dconf and gconf bring.
Rather than some conspiracy I'd hope/expect it's simply that having
many many coders bring wanted features but also unstoppable misdirected
trains as there aren't enough top notch respected eyes to notice before
it's too late. Elephantitis.
i think systemd offers a nice way to not only start your processes,
but also maintian their relationship to the rest of the system.
traditional init systems work fine ... so long as everything works
correctly on first try. if you want to have any kind of faul
tolerance, or even recovering from minor outages/hiccups, you suddenly
need all this extra infrastructure to watch pid files, watch
directories, watch watch watch ... while meanwhile, your init system
is standing in the corner picking it's nose, because it "did it's job
already" and all it needed to do was "start some stuff in the first 5
seconds".
Post by Kevin Chadwick
Post by C Anthony Risinger
i have custom units managing daemons like this, timers syncing
archlinux mirrors, units modifying /sys/ tunables (there is no
`sysctl` for sysfs!), some that run/reboot XBMC on my HTPC ...
... and on servers especially, i even have units bound to ethernet
devices, automatically managing the interface, and/or starting dhcp!
Could you be explicit in what you've gained. Maybe I'm ignorrant of the
details but I see perhaps this functionality being more universal and
that's it?
i just want things to happen at the right moments without worry, reuse
as much as possible, and not need to introduce additional requirements
... in the end i'm quite sure we have the same goals :-)

i know this isn't the final way i'll do it, but i currently use this
unit file on ~3 servers:

-----------------------------------
# Bindings to physical interfaces

[Unit]
Description=dynamic inet interface [phys:%I]
Wants=network.target
Before=network.target
BindTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
After=systemd-user-sessions.service rc-local.service

[Service]
Type=simple
TimeoutSec=0
Restart=always
RestartSec=10
EnvironmentFile=/etc/conf.d/dhcpcd
PIDFile=/run/dhcpcd-%I.pid
ExecStart=-/usr/sbin/dhcpcd $DHCPCD_ARGS %I
ExecStop=-/usr/sbin/dhcpcd --exit %I

[Install]
Alias=sys-subsystem-net-devices-eth0.device.wants/net-dyn-***@eth0.service
-----------------------------------

... with just what you see above, and no modifications between
systems, i can run a dhcp service on any interface, whether it exists
or not, by only making a single symlink for each interface needed.
when a particular interface comes into being, dhcp will be started.
when the interface disappears, dhcp will be killed and the unit
"shutdown". if dhcp dies but the interface still exists, it will be
restarted. this unit activates the network.target, but guarantees
that all units depending on the network will wait until it's finished
before being started themselves.

... doing to same with an init script requires a much more work, a lot
more boilerplate code, and probably another process or two+.
--
C Anthony
Patrick Lauer
2012-04-29 04:51:11 UTC
Permalink
Post by C Anthony Risinger
Post by Kevin Chadwick
On Sat, 28 Apr 2012 16:05:54 -0500
Post by C Anthony Risinger
"bloat" is not measured by LOC, but rather by degrees of uselessness.
I disagree here. If many don't use/need those features aside from an
init system initialising things then it is bloat and will have bugs
that will even affect simple firewall systems. Of course I'd use
OpenBSD for a firewall but I know some build a highly stripped down
Linux (kernel).
perhaps it is a matter of taste, but i don't think the init system's
purpose is to simply "initialize" things. it is a state manager, esp.
considering it has abilities no other process has. i wish i could
find the link now, but i read an excerpt regarding the original design
philosophy of the init program ... and while it wasn't 100% straight
forward, the original goals heavily alluded that init was a
intelligent supervisor, and not nearly as dumb as we now know it.
well, the sysvinit /sbin/init is very good at being PID 1 ... the state
manager gets started and/or kept alive by it - and there's so little
code involved that there are no surprises.
The sysvinit code is so "boring" that there are still typos in the
comments because not enough people even look at it to notice ...
Post by C Anthony Risinger
for LXC systems, i previously wrote an "init" in bash, that could
parse inittab, and respond to SIGPWR and SIGINT (powerfail and
crtlaltdelete in inittab), i probably 100 LOC of bash. basic
functionality was implemented in far less ... what's the point? now i
have to write everything in shell scripts for stuff that could
perfectly well be handled by the supervisor.
acpid for SIGPWR, ca:12345:ctrlaltdel:/sbin/shutdown -r now for SIGINT,
oh wait, my defaults already do that

And I didn't have to write any code for that ...
Post by C Anthony Risinger
i write a lot of shell code, and have literally read the bash man page
enough times to be able to jump to any point for reference ... shell
code is anything but secure and rather fragile. it's just not meant
to do as much as we make it. you are probably right about the
firewall case, maybe it wouldn't be needed. but my guess is that you
could actually make the firewall much more fault tolerant and
intelligent by using such a powerful supervisor as systemd. for the
most part though, most systems *do* require intricate and complex
relationships between services, and systemd fills that need
splendidly, *because* it does more that "fire and forget" [initialize]
processes.
Worse than OpenRC, especially as it has insane nuggets like "WantedBy"
(hello threaded Intercal!)

In my opinion, if I have to start hacking random C to add or adapt
features (which happens as soon as the builtins do the wrong things -
that's about twice a year for me) it'll be a lot more crashy than a
simple shell script where I add one line of code.


[snip]
Post by C Anthony Risinger
Rather than some conspiracy I'd hope/expect it's simply that having
many many coders bring wanted features but also unstoppable misdirected
trains as there aren't enough top notch respected eyes to notice before
it's too late. Elephantitis.
i think systemd offers a nice way to not only start your processes,
but also maintian their relationship to the rest of the system.
So the only weak argument in favour of systemd is dependency handling,
which has been around for a decade. Oh, and if you have stateful init
scripts (yeah, radical, I know) you can just check if all services you
wanted to start are started and still alive. (running "rc-status" and
"rc" with openrc does exactly that)

No need for systemd at all :)
Post by C Anthony Risinger
traditional init systems work fine ... so long as everything works
correctly on first try. if you want to have any kind of faul
tolerance, or even recovering from minor outages/hiccups, you suddenly
need all this extra infrastructure to watch pid files, watch
directories, watch watch watch ...
that's why I offered OpenRC as an alternative - it does all those things
while still being boring and manageable.
Post by C Anthony Risinger
while meanwhile, your init system
is standing in the corner picking it's nose, because it "did it's job
already" and all it needed to do was "start some stuff in the first 5
seconds".
So fix your init system :)
Post by C Anthony Risinger
Post by Kevin Chadwick
Post by C Anthony Risinger
i have custom units managing daemons like this, timers syncing
archlinux mirrors, units modifying /sys/ tunables (there is no
`sysctl` for sysfs!), some that run/reboot XBMC on my HTPC ...
... and on servers especially, i even have units bound to ethernet
devices, automatically managing the interface, and/or starting dhcp!
Could you be explicit in what you've gained. Maybe I'm ignorrant of the
details but I see perhaps this functionality being more universal and
that's it?
i just want things to happen at the right moments without worry, reuse
as much as possible, and not need to introduce additional requirements
... in the end i'm quite sure we have the same goals :-)
i know this isn't the final way i'll do it, but i currently use this
[snip]
Post by C Anthony Risinger
... with just what you see above, and no modifications between
systems, i can run a dhcp service on any interface, whether it exists
or not, by only making a single symlink for each interface needed.
when a particular interface comes into being, dhcp will be started.
when the interface disappears, dhcp will be killed and the unit
"shutdown". if dhcp dies but the interface still exists, it will be
restarted. this unit activates the network.target, but guarantees
that all units depending on the network will wait until it's finished
before being started themselves.
ln -s /etc/init.d/net.lo /etc/init.d/net.eth3; /etc/init.d/net.eth3
start <-- there's eth3 running with dhcp

And for the dynamic case where you don't know the device name ahead of
time I'd suggest using NetworkManager - it's built to handle all that
jazz. Oh, and if you have a sane init system it'll know in what state NM
is and thus be able to delay starting services that rely on a network
connection.

Or, if you are really kinky, write udev rules to do such things. It's
less code than the unit file ... and udev *is* the event handler for
such things.
Post by C Anthony Risinger
... doing to same with an init script requires a much more work, a lot
more boilerplate code, and probably another process or two+.
You could do it like that, yes ... but isn't that a bit overengineered?

Oh well. It's great that you're discovering features, but systemd isn't
without alternative. Most of the features you mention have been in
OpenRC since the beginning (and that's just a rewrite of the old
baselayout scripts that are about a decade old).

Take care,

Patrick
C Anthony Risinger
2012-04-29 06:12:15 UTC
Permalink
Post by Patrick Lauer
Post by C Anthony Risinger
perhaps it is a matter of taste, but i don't think the init system's
purpose is to simply "initialize" things.  it is a state manager, esp.
considering it has abilities no other process has.  i wish i could
find the link now, but i read an excerpt regarding the original design
philosophy of the init program ... and while it wasn't 100% straight
forward, the original goals heavily alluded that init was a
intelligent supervisor, and not nearly as dumb as we now know it.
well, the sysvinit /sbin/init is very good at being PID 1 ... the state
manager gets started and/or kept alive by it - and there's so little
code involved that there are no surprises.
The sysvinit code is so "boring" that there are still typos in the
comments because not enough people even look at it to notice ...
yeah ... i'm a C novice, and i'm pretty sure i can write a stable init
... that's kinda the point. init is so incredibly dumb that it
requires no code. is that really what "unix philosophy" is meant to
convey? so little code and functionality?

#include <stdio.h>
int main() {
printf( "Hello Unix!\n" );
return 0;
}

... done! and rock-solid stable! :-)
Post by Patrick Lauer
Post by C Anthony Risinger
for LXC systems, i previously wrote an "init" in bash, that could
parse inittab, and respond to SIGPWR and SIGINT (powerfail and
crtlaltdelete in inittab), i probably 100 LOC of bash.  basic
functionality was implemented in far less ... what's the point?  now i
have to write everything in shell scripts for stuff that could
perfectly well be handled by the supervisor.
acpid for SIGPWR, ca:12345:ctrlaltdel:/sbin/shutdown -r now for SIGINT,
oh wait, my defaults already do that
And I didn't have to write any code for that ...
traditional init will lock up the container because it thinks it must
reboot/shutdown the system. there is absolutely no way to make it
kill itself, and end the container "normally". it has to be kill
-9'ed from the outside.

... systemd on the other had, realizes it's running in a container,
and simply exit()'s.
Post by Patrick Lauer
Post by C Anthony Risinger
i write a lot of shell code, and have literally read the bash man page
enough times to be able to jump to any point for reference ... shell
code is anything but secure and rather fragile.  it's just not meant
to do as much as we make it.  you are probably right about the
firewall case, maybe it wouldn't be needed.  but my guess is that you
could actually make the firewall much more fault tolerant and
intelligent by using such a powerful supervisor as systemd.  for the
most part though, most systems *do* require intricate and complex
relationships between services, and systemd fills that need
splendidly, *because* it does more that "fire and forget" [initialize]
processes.
Worse than OpenRC, especially as it has insane nuggets like "WantedBy"
(hello threaded Intercal!)
In my opinion,  if I have to start hacking random C to add or adapt
features (which happens as soon as the builtins do the wrong things -
that's about twice a year for me) it'll be a lot more crashy than a
simple shell script where I add one line of code.
well, i've used systemd for quite some time, and have never needed to
hack any C. you can always ruin shellscripts from unit files if you
like, no one is preventing that.

the introspective and investigation tools in systemd are excellent and
unmatched by any other "alternative" i've encountered ... have you
actually tried it yet? if i want to know what my systems is doing as
a whole, who better to ask that the ONE process capable of telling me?
pid 1 can do stuff no other can ... why squander such powers?
Post by Patrick Lauer
[snip]
Post by C Anthony Risinger
Rather than some conspiracy I'd hope/expect it's simply that having
many many coders bring wanted features but also unstoppable misdirected
trains as there aren't enough top notch respected eyes to notice before
it's too late. Elephantitis.
i think systemd offers a nice way to not only start your processes,
but also maintian their relationship to the rest of the system.
So the only weak argument in favour of systemd is dependency handling,
which has been around for a decade. Oh, and if you have stateful init
scripts (yeah, radical, I know) you can just check if all services you
wanted to start are started and still alive. (running "rc-status" and
"rc" with openrc does exactly that)
No need for systemd at all :)
and doing that from a remote tool? right ... run command XYZ over
ssh, parse for ABC, etc etc. what about timed stuff? what about
events/services that are not daemons? i'm a developer; i want real
interfaces to use, with precise endpoints and clear methods. dbus
does this nicely. in time, i can query more and more over dbus.

when i have a hundred systems, i very much do not want to babysit
them. systemd and the associated thought path really is a great step
forward. yes shell is nice. i write uber-tons of shell. but the
unit files are clean, simple, consistent, and powerful. read some of
the man pages ... tell me how to do all that with shell and/or OpenRC
alone, because people *want* this! else systemd would not exist, nor
have so much impetus.
Post by Patrick Lauer
Post by C Anthony Risinger
traditional init systems work fine ... so long as everything works
correctly on first try.  if you want to have any kind of faul
tolerance, or even recovering from minor outages/hiccups, you suddenly
need all this extra infrastructure to watch pid files, watch
directories, watch watch watch ...
that's why I offered OpenRC as an alternative - it does all those things
while still being boring and manageable.
manageable? any init system that claims to only be /sbin/init is
deluding itself. "init" is all the rc scripts, the init app itself,
all the daemon rc scripts ... *everything*. systemd will spew out a
graphviz chart if i want. or let me start units one by one during
boot in an interactive way ... what can OpenRC do above-and-beyond,
for ME, the interrogator?
Post by Patrick Lauer
Post by C Anthony Risinger
 while meanwhile, your init system
is standing in the corner picking it's nose, because it "did it's job
already" and all it needed to do was "start some stuff in the first 5
seconds".
So fix your init system :)
luckily someone did it for me!
Post by Patrick Lauer
Post by C Anthony Risinger
... with just what you see above, and no modifications between
systems, i can run a dhcp service on any interface, whether it exists
or not, by only making a single symlink for each interface needed.
when a particular interface comes into being, dhcp will be started.
when the interface disappears, dhcp will be killed and the unit
"shutdown".  if dhcp dies but the interface still exists, it will be
restarted.  this unit activates the network.target, but guarantees
that all units depending on the network will wait until it's finished
before being started themselves.
ln -s /etc/init.d/net.lo /etc/init.d/net.eth3; /etc/init.d/net.eth3
start <-- there's eth3 running with dhcp
And for the dynamic case where you don't know the device name ahead of
time I'd suggest using NetworkManager - it's built to handle all that
jazz. Oh, and if you have a sane init system it'll know in what state NM
is and thus be able to delay starting services that rely on a network
connection.
heyo! networkmanager on a server is going to be an even tougher sell
than systemd. in virtualized environments, hardware can be much more
dynamic than physical servers would experience ... but this was only
an example, and far more interesting examples exist on the
inter-tubes.
Post by Patrick Lauer
Or, if you are really kinky, write udev rules to do such things. It's
less code than the unit file ... and udev *is* the event handler for
such things.
udev is meant to manage symlinks to stuff in dev, and trigger
short-lived apps to do similar book-keeping, not manage or kickoff
services. in systemd's case, a single udev rule is used to tag
devices which are then exported and usable by unit files.
Post by Patrick Lauer
Post by C Anthony Risinger
... doing to same with an init script requires a much more work, a lot
more boilerplate code, and probably another process or two+.
You could do it like that, yes ... but isn't that a bit overengineered?
how so? what if dhcpcd has a bug, and spontaneously blows up?
systemd will catch the output, the exit code, and other infos, then
restart it for me. when something does exactly what i need, in 10
lines of key/val declarations, that's more like precise engineering in
my book.
--
C Anthony
Kevin Chadwick
2012-04-30 08:51:42 UTC
Permalink
On Sun, 29 Apr 2012 01:12:15 -0500
Post by C Anthony Risinger
yeah ... i'm a C novice, and i'm pretty sure i can write a stable init
... that's kinda the point. init is so incredibly dumb that it
requires no code. is that really what "unix philosophy" is meant to
convey? so little code and functionality?
Unix philosophy is many small tools that do a single job well. These
tools can do MORE than they're constituent parts when used with other
tools. Init does have spawn abilities too. There's also supervise,
monit.


Binary files have nothing to do with systemd sorry, just one of my
bones of contention from various recent conf tools. I love text in .
files, they're easy to find and can even be recovered from disk by
grepping sectors, almost no matter what and with ease. Heck, I save my
documents as .txt for secondary backup purposes. I wish I knew that
when I was a teenager doing work for school at 3AM and Word lost
everything spectacularly well.
Gour
2012-04-30 09:30:23 UTC
Permalink
On Mon, 30 Apr 2012 09:51:42 +0100
Heck, I save my documents as .txt for secondary backup purposes. I
wish I knew that when I was a teenager doing work for school at 3AM
and Word lost everything spectacularly well.
Heh...similar lesson when I was workin on OS2 with Lotus Word Pro (or
how it was called)...saved one day, was not able to open it next day and
since then I said: "No more binaries documents!" and that's have we did
embrace LaTeX/LyX etc.


Sincerely,
Gour
--
The intricacies of action are very hard to understand.
Therefore one should know properly what action is,
what forbidden action is, and what inaction is.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Kevin Chadwick
2012-04-30 10:55:48 UTC
Permalink
On Mon, 30 Apr 2012 11:30:23 +0200
we did embrace LaTeX/LyX etc.
To get the benefit of your experience. Do you use Lyx as your editor or
something else.
Lorenzo Bandieri
2012-04-30 11:35:56 UTC
Permalink
Post by Kevin Chadwick
On Mon, 30 Apr 2012 11:30:23 +0200
we did embrace LaTeX/LyX etc.
To get the benefit of your experience. Do you use Lyx as your editor or
something else.
Sorry if I "jump in", but as a LaTeX user I usually suggest to stay
away from Lyx. Basically it's an editor that attempt to make LaTeX
work like Words, which IMHO it's not the best approach. I suggest to
use an editor that doesn't try to hide how LaTeX works, and one of my
favourite is TexMaker.

Just my opinion.

Regards,

Lorenzo
--
"Imagine an idea that occupies your mind the way an army occupies a city."
Ralf Mardorf
2012-04-30 11:43:19 UTC
Permalink
Post by Lorenzo Bandieri
Post by Kevin Chadwick
On Mon, 30 Apr 2012 11:30:23 +0200
we did embrace LaTeX/LyX etc.
To get the benefit of your experience. Do you use Lyx as your editor or
something else.
Sorry if I "jump in", but as a LaTeX user I usually suggest to stay
away from Lyx. Basically it's an editor that attempt to make LaTeX
work like Words, which IMHO it's not the best approach. I suggest to
use an editor that doesn't try to hide how LaTeX works, and one of my
favourite is TexMaker.
Just my opinion.
Regards,
Lorenzo
Keep in mind that blind people can't read nice formated documents on
braille, they anyway need to read the source code ;).
Gour
2012-04-30 14:17:52 UTC
Permalink
On Mon, 30 Apr 2012 13:43:19 +0200
Post by Ralf Mardorf
Keep in mind that blind people can't read nice formated documents on
braille, they anyway need to read the source code ;).
Whatever...I found that when working on non-technical texts, LaTeX
markup takes away focus from writing...and therfore LyX was perfect tool
to work on the content and then just do fine tuning using LaTeX.

That's why we now consider to use AsciiDoc and produce output using
dblatex or LaTeX back-end.


Sincerely,
Gour
--
Bewildered by the modes of material nature, the ignorant fully
engage themselves in material activities and become attached. But
the wise should not unsettle them, although these duties are inferior
due to the performers' lack of knowledge.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Rashif Ray Rahman
2012-04-30 15:16:54 UTC
Permalink
Post by Lorenzo Bandieri
Post by Kevin Chadwick
On Mon, 30 Apr 2012 11:30:23 +0200
we did embrace LaTeX/LyX etc.
To get the benefit of your experience. Do you use Lyx as your editor or
something else.
Sorry if I "jump in", but as a LaTeX user I usually suggest to stay
away from Lyx. Basically it's an editor that attempt to make LaTeX
work like Words, which IMHO it's not the best approach. I suggest to
use an editor that doesn't try to hide how LaTeX works, and one of my
favourite is TexMaker.
There is nothing wrong in using LyX. I don't know why you have that
perception. It helps when your writing is qualitative rather than
quantitative (in which case LaTeX and a more involved process can be
adopted).

It does not work "like Words", because it is very clear that it is _not_
WYSIWYG. It is also not an "editor", which is a term suitable for things
like Kile. It is simply a document processor which is a LaTeX front-end,
but the end-user need not know this.


--
GPG/PGP ID: C0711BF1
Manolo Martínez
2012-04-30 15:24:24 UTC
Permalink
Post by Rashif Ray Rahman
Post by Lorenzo Bandieri
Post by Kevin Chadwick
On Mon, 30 Apr 2012 11:30:23 +0200
we did embrace LaTeX/LyX etc.
To get the benefit of your experience. Do you use Lyx as your editor or
something else.
Sorry if I "jump in", but as a LaTeX user I usually suggest to stay
away from Lyx. Basically it's an editor that attempt to make LaTeX
work like Words, which IMHO it's not the best approach. I suggest to
use an editor that doesn't try to hide how LaTeX works, and one of my
favourite is TexMaker.
There is nothing wrong in using LyX. I don't know why you have that
perception. It helps when your writing is qualitative rather than
quantitative (in which case LaTeX and a more involved process can be
adopted).
LyX is the only qt (or gtk) program I use in a regular basis, and the main
reason why I type xinit at all -- another reason being that elinks sometimes
does not make sense of webpages.

Manolo
Lorenzo Bandieri
2012-04-30 16:06:30 UTC
Permalink
Post by Rashif Ray Rahman
Post by Lorenzo Bandieri
Post by Kevin Chadwick
On Mon, 30 Apr 2012 11:30:23 +0200
we did embrace LaTeX/LyX etc.
To get the benefit of your experience. Do you use Lyx as your editor or
something else.
Sorry if I "jump in", but as a LaTeX user I usually suggest to stay
away from Lyx. Basically it's an editor that attempt to make LaTeX
work like Words, which IMHO it's not the best approach. I suggest to
use an editor that doesn't try to hide how LaTeX works, and one of my
favourite is TexMaker.
There is nothing wrong in using LyX. I don't know why you have that
perception.
Probably because I used to edit LaTeX documents in a simple text
editor from the beginning. I learned LaTeX that way, so I feel
comfortable only when I can see and edit the "code". I gave it a
chanche more than once, but everytime I tried to write something in
LyX I felt extremely uneasy and it seemed it was standing in my way.
Also, I don't like the fact that it saves the files in *.lyx. For the
same reasons, I suggest those who want to use LaTeX to start by
writing the code, learning the syntax, etc. Having learned myself that
way, I find it the best way, I guess.
Post by Rashif Ray Rahman
It helps when your writing is qualitative rather than
quantitative (in which case LaTeX and a more involved process can be
adopted).
It does not work "like Words", because it is very clear that it is _not_
WYSIWYG.
I partially disagree on this. LaTeX is not WYSIWYG, but LyX's
environment IMHO is a pseudo-WYSIWYG frontend.

Howerver, I acknowledge that in certain settings LyX can be useful; I
just like to edit LaTeX source by hand.

Regards

Lorenzo
--
"Imagine an idea that occupies your mind the way an army occupies a city."
Gour
2012-04-30 12:48:46 UTC
Permalink
On Mon, 30 Apr 2012 11:55:48 +0100
Post by Kevin Chadwick
To get the benefit of your experience. Do you use Lyx as your editor
or something else.
As LaTeX 'front-end'.


your servant,
Gour-Gadadhara Dasa
--
One who is able to withdraw his senses from sense objects,
as the tortoise draws its limbs within the shell,
is firmly fixed in perfect consciousness.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Jayesh Badwaik
2012-04-30 14:29:02 UTC
Permalink
Post by Gour
On Mon, 30 Apr 2012 09:51:42 +0100
Heck, I save my documents as .txt for secondary backup purposes. I
wish I knew that when I was a teenager doing work for school at 3AM
and Word lost everything spectacularly well.
Heh...similar lesson when I was workin on OS2 with Lotus Word Pro (or
how it was called)...saved one day, was not able to open it next day and
since then I said: "No more binaries documents!" and that's have we did
embrace LaTeX/LyX etc.
Sincerely,
Gour
You are very correct, master documents should always be plain text. The
generated documents can be binary however. Also, there should be a fallback
system where the plain text documents are used rather than binary documents
so that the faults in generator do not affect the bootability of the system.
--
Jayesh Badwaik
stop html mail | always bottom-post
www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Kevin Chadwick
2012-04-30 15:12:26 UTC
Permalink
On Mon, 30 Apr 2012 19:59:02 +0530
Post by Jayesh Badwaik
You are very correct, master documents should always be plain text. The
generated documents can be binary however. Also, there should be a fallback
system where the plain text documents are used rather than binary documents
so that the faults in generator do not affect the bootability of the system.
What's the point. To me that's just adding an extra redundant layer
that could have bugs. I see no point using binaries for configuration
whatosever. RAM is crazy fast and some SSDs are now as fast as a PIIIs
ram. How many nanoseconds does it take to parse config files???

Heck it would be fast on our spectrum ZX.

The other argument is cross program similar formatting. To me that just
adds difficulty and a usage barrier to possibly very different programs.

Qmail, dovecot and sudoers are all very different, it causes no
problem. Binaries and xml in odd multiple locations expecting
users to use a conf tool with rediculously long and custom non self
explanatory terminal lines does!!!!!

I installed mint for a friend. It came with gconf. I had to
google and install dconf to configure lockscreen, WTF!. Configuring
gnome as an admin takes ages because it's custom. A textfile with
examples would take seconds!!

I'm sure these things wouldn't have happened years ago!!
Auguste Pop
2012-04-30 15:17:40 UTC
Permalink
Post by Kevin Chadwick
On Mon, 30 Apr 2012 19:59:02 +0530
Post by Jayesh Badwaik
You are very correct, master documents should always be plain text. The
generated documents can be binary however. Also, there should be a fallback
system where the plain text documents are used rather than binary documents
so that the faults in generator do not affect the bootability of the system.
What's the point. To me that's just adding an extra redundant layer
that could have bugs. I see no point using binaries for configuration
whatosever. RAM is crazy fast and some SSDs are now as fast as a PIIIs
ram. How many nanoseconds does it take to parse config files???
and don't forget to mention some stupid binary configuration system,
like gconf, that incapable of removing erroneous entries created by a
typo.
Tom Gundersen
2012-04-30 15:35:22 UTC
Permalink
Post by Kevin Chadwick
What's the point. To me that's just adding an extra redundant layer
that could have bugs. I see no point using binaries for configuration
whatosever. RAM is crazy fast and some SSDs are now as fast as a PIIIs
ram. How many nanoseconds does it take to parse config files???
Heck it would be fast on our spectrum ZX.
The other argument is cross program similar formatting. To me that just
adds difficulty and a usage barrier to possibly very different programs.
Qmail, dovecot and sudoers are all very different, it causes no
problem. Binaries and xml in odd multiple locations expecting
users to use a conf tool with rediculously long and custom non self
explanatory terminal lines does!!!!!
I installed mint for a friend. It came with gconf. I had to
google and install dconf to configure lockscreen, WTF!. Configuring
gnome as an admin takes ages because it's custom. A textfile with
examples would take seconds!!
Are you guys still discussing init systems? (I might have lost some
context, if so: my appologies, and please change the Subject).

None of initscripts, OpenRC, systemd or upstart use binary or XML
configuration files.

Gnome might, but that seems off-topic. If you wish you could always
use KDE instead, which uses .desktop-like files (as does systemd for
what that's worth).

Cheers,

Tom
P .NIKOLIC
2012-04-29 06:50:22 UTC
Permalink
On Sun, 29 Apr 2012 12:51:11 +0800
Post by Patrick Lauer
No need for systemd at all :)
As someone that has used Linux exclusively since the very early days
kernel version 0.99-a i have to say

+1 to no need for systemd at all it is just another un-needed
uncalled for over complication of a process that works well as it is .

Pete .
--
Linux 7-of-9 3.3.3-1-ARCH #1 SMP PREEMPT Mon Apr 23 09:41:07 CEST 2012
x86_64 AMD Phenom(tm) 9600B Quad-Core Processor AuthenticAMD GNU/Linux
Tom Gundersen
2012-04-29 15:22:46 UTC
Permalink
Post by Patrick Lauer
The sysvinit code is so "boring" that there are still typos in the
comments because not enough people even look at it to notice ...
The lack of maintenance of sysvinit is a bit worrying, isn't it?
Post by Patrick Lauer
Post by C Anthony Risinger
i write a lot of shell code, and have literally read the bash man page
enough times to be able to jump to any point for reference ... shell
code is anything but secure and rather fragile.  it's just not meant
to do as much as we make it.  you are probably right about the
firewall case, maybe it wouldn't be needed.  but my guess is that you
could actually make the firewall much more fault tolerant and
intelligent by using such a powerful supervisor as systemd.  for the
most part though, most systems *do* require intricate and complex
relationships between services, and systemd fills that need
splendidly, *because* it does more that "fire and forget" [initialize]
processes.
Worse than OpenRC, especially as it has insane nuggets like "WantedBy"
(hello threaded Intercal!)
What's wrong with WantedBy? You don't like the term, or do you have a
technical problem with it?
Post by Patrick Lauer
In my opinion,  if I have to start hacking random C to add or adapt
features (which happens as soon as the builtins do the wrong things -
that's about twice a year for me) it'll be a lot more crashy than a
simple shell script where I add one line of code.
By "builtins" do you mean PID1? If so, this is not something an admin
should be hacking on (just like an admin would not hack on sysvinit's
/sbin/init). Have you actually looked at the code?
Post by Patrick Lauer
So the only weak argument in favour of systemd is dependency handling,
which has been around for a decade. Oh, and if you have stateful init
scripts (yeah, radical, I know) you can just check if all services you
wanted to start are started and still alive. (running "rc-status" and
"rc" with openrc does exactly that)
As has been mentioned by several people in this thread, and also on
the other lists where you sent your proposal: the main reason people
are interested in systemd is due to its event-driven design (similar
to upstart, but unlike sysvinit and, as far as I can tell, OpenRC).

-t
Patrick Lauer
2012-05-07 14:13:54 UTC
Permalink
Post by Tom Gundersen
Post by Patrick Lauer
The sysvinit code is so "boring" that there are still typos in the
comments because not enough people even look at it to notice ...
The lack of maintenance of sysvinit is a bit worrying, isn't it?
Au contraire ... it's so boring-stable that no one *needs* to even look
at it.
That's how I like my software best, so boring that most people don't
even notice it exists :)
Post by Tom Gundersen
Post by Patrick Lauer
Post by C Anthony Risinger
i write a lot of shell code, and have literally read the bash man page
enough times to be able to jump to any point for reference ... shell
code is anything but secure and rather fragile. it's just not meant
to do as much as we make it. you are probably right about the
firewall case, maybe it wouldn't be needed. but my guess is that you
could actually make the firewall much more fault tolerant and
intelligent by using such a powerful supervisor as systemd. for the
most part though, most systems *do* require intricate and complex
relationships between services, and systemd fills that need
splendidly, *because* it does more that "fire and forget" [initialize]
processes.
Worse than OpenRC, especially as it has insane nuggets like "WantedBy"
(hello threaded Intercal!)
What's wrong with WantedBy? You don't like the term, or do you have a
technical problem with it?
It's very difficult to handle properly - you have to check all init
scripts / unit files / znargfruzzles every time to see if their
dependencies changes, and if they have any WantedBys. And you should ask
people that had to debug threaded INTERCAL why it's not as awesome as it
sounds at first glance ...
Post by Tom Gundersen
Post by Patrick Lauer
In my opinion, if I have to start hacking random C to add or adapt
features (which happens as soon as the builtins do the wrong things -
that's about twice a year for me) it'll be a lot more crashy than a
simple shell script where I add one line of code.
By "builtins" do you mean PID1? If so, this is not something an admin
should be hacking on (just like an admin would not hack on sysvinit's
/sbin/init). Have you actually looked at the code?
Yes, I have read a good chunk of systemd (and upstart). My liver doesn't
appreciate that much.
And "should be hacking on" - yeah, that's the theory. But I usually hit
that point once or twice a year where the given structure is either
buggy or incomplete and I *need* to mangle such internals.

"Not possible" is not a valid response to my problem-removal-needs.
SystemD is too big and too undocumented for me to trust my skills, I
wouldn't want to have to rely on a system that I mutilated like that
just to fix a rare corner case that "shouldn't be there" (yeah, great,
thanks, it *is* there. Do you want to make it go away?)
Post by Tom Gundersen
Post by Patrick Lauer
So the only weak argument in favour of systemd is dependency handling,
which has been around for a decade. Oh, and if you have stateful init
scripts (yeah, radical, I know) you can just check if all services you
wanted to start are started and still alive. (running "rc-status" and
"rc" with openrc does exactly that)
As has been mentioned by several people in this thread, and also on
the other lists where you sent your proposal: the main reason people
are interested in systemd is due to its event-driven design (similar
to upstart, but unlike sysvinit and, as far as I can tell, OpenRC).
You have no idea how much it bothers me to have to repeat myself, again,
for the last time I hope ... but ...

What do people actually *mean* by event driven?

Would be useful to define it well enough so we can evaluate how OpenRC
(or the current init) doesn't do what you want, and maybe fix it until
next week.

Have a nice day,

Patrick
Ralf Mardorf
2012-05-07 14:19:02 UTC
Permalink
Post by Patrick Lauer
Post by Tom Gundersen
Post by Patrick Lauer
The sysvinit code is so "boring" that there are still typos in the
comments because not enough people even look at it to notice ...
The lack of maintenance of sysvinit is a bit worrying, isn't it?
Au contraire ... it's so boring-stable that no one *needs* to even look
at it.
That's how I like my software best, so boring that most people don't
even notice it exists :)
With typos where they belong to, to the comments instead of the code :).
Speaking for software in general, not especially for the one this thread
is about. Software never should be dropped, because it's not maintained,
when there's no need to maintain it.
Nicolas Sebrecht
2012-04-30 07:22:42 UTC
Permalink
Post by Patrick Lauer
In my opinion, if I have to start hacking random C to add or adapt
features (which happens as soon as the builtins do the wrong things -
that's about twice a year for me) it'll be a lot more crashy than a
simple shell script where I add one line of code.
Having most of the distribution maintainers playing in with boot
critical shell scripts is worse. I've been faced with so many poorly
written shell scripts over distributions for decades that I can't
believe in your "C is more crashy" statement.
--
Nicolas Sebrecht
Kevin Chadwick
2012-04-30 08:59:34 UTC
Permalink
On Mon, 30 Apr 2012 09:22:42 +0200
Post by Nicolas Sebrecht
Post by Patrick Lauer
In my opinion, if I have to start hacking random C to add or adapt
features (which happens as soon as the builtins do the wrong things -
that's about twice a year for me) it'll be a lot more crashy than a
simple shell script where I add one line of code.
Having most of the distribution maintainers playing in with boot
critical shell scripts is worse. I've been faced with so many poorly
written shell scripts over distributions for decades that I can't
believe in your "C is more crashy" statement.
If it makes it easier to find and stop things like avahi then that's
one bonus. That's one of the reasons I chose Arch. I wouldn't put it
past Ubuntu to build avahi spawning into systemd itself so it can't
be stopped, mu wha ha ha.
Patrick Lauer
2012-05-07 14:25:41 UTC
Permalink
Post by Nicolas Sebrecht
Post by Patrick Lauer
In my opinion, if I have to start hacking random C to add or adapt
features (which happens as soon as the builtins do the wrong things -
that's about twice a year for me) it'll be a lot more crashy than a
simple shell script where I add one line of code.
Having most of the distribution maintainers playing in with boot
critical shell scripts is worse. I've been faced with so many poorly
written shell scripts over distributions for decades that I can't
believe in your "C is more crashy" statement.
SRSLY?

You misread my statement (I said if *I* have to write C blindly it'll be
crashy, I'm quite confident about that)

And claiming that someone like Lenny who doesn't even use comments and
uses memcpy instead of strcpy writes better code than the admins that
you usually don't even notice because their stuff is just working (so
you have no reason to even look for them) .... sigh. That's marginally
rude and inconsiderate.

Lastly, claiming that shell is bad because people write bad code ...
most code is bad. If you get bored, please, read all 12 lines of the
Gentoo rsyncd init script and tell me how it is buggy, unmaintainable
etc. :)
(bonus: out of those 12 4 are comments (including shebang) and 2 are
whitespace)

So all in all you just managed to upset some greybeards and turned a
technical discussion into random ad hominems. Nice :)

So anyway. If you complain about bad shell, fix it, or throw some
examples at me so I can rewrite them cleanly. Don't think rewriting in
Modula-3 will make it any better, the same people you condemned for not
writing good shell won't write good INTERCAL either. Educate them, fix
any bug you find, enjoy.

Have fun,

Patrick
Nicolas Sebrecht
2012-05-09 10:30:34 UTC
Permalink
Post by Patrick Lauer
So anyway. If you complain about bad shell, fix it, or throw some
examples at me so I can rewrite them cleanly.
"Patch it yourself" is exactly the opposite of what I would expect. This
is not peace of mind to add patches to already too much stressed code in
pieces of core tools. I'm not talking about you especially and vanilla
OpenRC scripts but those written and tuned by maintainers.
Post by Patrick Lauer
Don't think rewriting in
Modula-3 will make it any better, the same people you condemned for not
writing good shell won't write good INTERCAL either. Educate them, fix
any bug you find, enjoy.
Traking down what maintainers do with stderr and how error code is
handled in init shell scripts is most of the time a good example of how
educated people can write poor shell code.

As you're asking for it, here is a random example of shell code in sysfs
(a very core script) taken from official repository(1):

if [ ! -d /sys ]; then
if ! mkdir -m 0755 /sys; then
ewarn "Could not create /sys!"
return 1
fi
fi

This code is exposed to race conditions as the directory creation could
happen in a slice between the first condition check and the next mkdir
call. Of course, in this particular case we can sanely expect the
creation of /sys beeing not concurrency at all, but this way of
"checking for conditions and then handle the missing condition after the
facts" is almost everywhere in the code. This is RACY and plain WRONG.

You should turn them all in things like:

mkdir /sys 2> /dev/null 2>&1
cd /sys || {
ewarn "<the error message>"
return 1
}

If this kind of problem was only for creating directories, I wouldn't
even mention it. But in real life these shell code scripts make
debugging and maintaining init a nightmare. Writing good shell code is
MUCH harder than it looks at a first glance, including for educated
people.

(1) http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=blob_plain;f=init.d/sysfs.in;hb=HEAD
--
Nicolas Sebrecht
Kevin Chadwick
2012-05-09 11:35:59 UTC
Permalink
On Wed, 9 May 2012 12:30:34 +0200
Post by Nicolas Sebrecht
mkdir /sys 2> /dev/null 2>&1
cd /sys || {
ewarn "<the error message>"
return 1
}
That's just a little less racy and certainly not
atomic, /usr/bin/install would be atomic. As you have said
your race point doesn't actually matter. You call it plain wrong and
admit there is nothing wrong at the same time?

There's another point, shell is easily editable and understandable and
that's a good thing and not a bad one and also one of arches values I
believe, hence pacman uses so much shell!

On occasions I have had to resort to editing shell init scripts because
I don't agree with the distro or devs. People shouldn't be forced to
Gentoo and damaging the environment.
Patrick Lauer
2012-05-09 11:45:51 UTC
Permalink
Post by Kevin Chadwick
On Wed, 9 May 2012 12:30:34 +0200
Post by Nicolas Sebrecht
mkdir /sys 2> /dev/null 2>&1
cd /sys || {
ewarn "<the error message>"
return 1
}
That's just a little less racy and certainly not
atomic, /usr/bin/install would be atomic. As you have said
your race point doesn't actually matter. You call it plain wrong and
admit there is nothing wrong at the same time?
Well, the problem here is -
that script will be the only one running, and the only one manipulating
sysfs, and it's fail-safe - if anyone else creates the directory we
still end up in a state where it exists (modulo permissions)

So yes, it's technically racy and could fail, but all failure modes are
benign (directory already there, directory really already there) or
really confusing (we can't create a dir - is / mounted readonly? Why are
we being run then?!), so either it's good or something really bad you
can't catch anyway.
Post by Kevin Chadwick
There's another point, shell is easily editable and understandable and
that's a good thing and not a bad one and also one of arches values I
believe, hence pacman uses so much shell!
And it's on-the-fly editable. If you just need to disable that check for
a minute because ... err ... long story, but you have to do it ...
trivial. And sh -x gives you an instant "debugger" that makes finding
silly mistakes a lot easier.
Post by Kevin Chadwick
On occasions I have had to resort to editing shell init scripts because
I don't agree with the distro or devs. People shouldn't be forced to
Gentoo and damaging the environment.
Wat :)
I presume you got distracted and meant to write something else,
otherwise I have to claim that you are a donkey ;) Thanks for the most
surreal quote of the day (so far)

Take care,

Patrick
Kevin Chadwick
2012-05-09 12:14:05 UTC
Permalink
On Wed, 09 May 2012 19:45:51 +0800
Post by Patrick Lauer
Post by Kevin Chadwick
On occasions I have had to resort to editing shell init scripts because
I don't agree with the distro or devs. People shouldn't be forced to
Gentoo and damaging the environment.
Wat :)
I presume you got distracted and meant to write something else,
otherwise I have to claim that you are a donkey ;) Thanks for the most
surreal quote of the day (so far
Was it cryptic. I didn't get your humour either?

With init and shell rc. You are guaranteed control and adaptability and
easier understanding of all executions. With systemd you may have to
work within the expected configurations.

Basically, the premise is that a minimal Linux system should be X times
bigger.

This means you may have to recompile like the Gentoo distro to get the
system you want. Like you currently have to do if you want a smaller
kernel.
Nicolas Sebrecht
2012-05-09 11:57:14 UTC
Permalink
Post by Kevin Chadwick
On Wed, 9 May 2012 12:30:34 +0200
Post by Nicolas Sebrecht
mkdir /sys 2> /dev/null 2>&1
cd /sys || {
ewarn "<the error message>"
return 1
}
That's just a little less racy and certainly not
atomic, /usr/bin/install would be atomic. As you have said
your race point doesn't actually matter. You call it plain wrong and
admit there is nothing wrong at the same time?
The way used to handle conditions is wrong. And I admit that for /this/
particular case, this is not much relevant.
Post by Kevin Chadwick
There's another point, shell is easily editable and understandable and
that's a good thing and not a bad one and also one of arches values I
believe, hence pacman uses so much shell!
I don't find pacman much editable, sorry. I've given examples of nice
features not easy to implement, here in the past. ,-p
--
Nicolas Sebrecht
Kevin Chadwick
2012-05-09 12:20:04 UTC
Permalink
On Wed, 9 May 2012 13:57:14 +0200
Post by Nicolas Sebrecht
The way used to handle conditions is wrong. And I admit that for /this/
particular case, this is not much relevant.
I actually prefer the first case with multiple ifs. It helps newbie
techs dive in and read the code. So what if they break it they will
learn fixing it.
Post by Nicolas Sebrecht
Post by Kevin Chadwick
There's another point, shell is easily editable and understandable and
that's a good thing and not a bad one and also one of arches values I
believe, hence pacman uses so much shell!
I don't find pacman much editable, sorry. I've given examples of nice
features not easy to implement, here in the past. ,-p
There are a lot of functions and files to get a handle on
aren't there. Is that the reason? I don't think that detracts from the
point though?

Tom Gundersen
2012-04-28 20:27:49 UTC
Permalink
Post by Kevin Chadwick
Imagine if all drivers loaded at once.
Just a piece of information: the way kernel modules are loaded is not
changed, currently they are (for most intents and purposes) loaded at
once.

-t
Kevin Chadwick
2012-04-28 23:43:15 UTC
Permalink
On Sat, 28 Apr 2012 22:27:49 +0200
Post by Tom Gundersen
Just a piece of information: the way kernel modules are loaded is not
changed, currently they are (for most intents and purposes) loaded at
once.
I didn't know that, annoying. There aren't that many though as I
manually enable them before disabling module loading. I believe core
kernel drivers are loaded nice and sequentially? There's still some
searching in the dark just less dark to search in, without enabling
debugging features.
Patrick Lauer
2012-05-07 13:48:35 UTC
Permalink
Post by Nicolas Sebrecht
Hi,
Post by Patrick Lauer
As an alternative to the One Process For Everything I'd like to ask you to evalute OpenRC as an init system for Arch Linux.
<...>
Post by Patrick Lauer
While Gentoo is by far the largest user it's definitely not the only one
- there are the direct derivatives (Sabayon, pentoo, funtoo,
sysrescuecd, tinhat, ...) and some "foreign" users (Alpine, a debian
derivative, uses OpenRC)
Alpine is highly dedicated to small systems with few physical resources
which makes the reference not much relevant.
Well, it's just one example of a non-gentoo-derived user. Shows that
it's highly portable and not twisted towards one specific confiuguration.
Post by Nicolas Sebrecht
Post by Patrick Lauer
Should you decide to switch (or just evaluate if switching is possible /
makes sense) you'll get full support from us in migrating init scripts
and figuring out all the nontrivial changes. Just visit us on IRC (
meet us for a beer or two.
Thanks for your consideration,
Patrick Lauer
Gentoo Developer, OpenRC co-maintainer
I wouldn't expect anything else from a OpenRC maintainer to support his
tool to be used on other platforms. :-)
But to be fair, you should say that the future of OpenRC is NOT certain
in Gentoo at least, and as a consequence in all of the forked projects.
Nyet. Future very certain. Most of us will stick with OpenRC, and do
whatever is needed to keep it working.
Post by Nicolas Sebrecht
- http://marc.info/?l=gentoo-dev&m=130929913506375&w=4
- https://bugs.gentoo.org/show_bug.cgi?id=373219
- http://marc.info/?l=gentoo-dev&m=132538362810246&w=4
Gentoo might make systemd the default init system in the future.
Nein. That'd be a proper schism that will make the exherbo split look
like happy sunshine happy happy.

Now that systemd upstream has assimilated udev (which confuses nicely,
but their decision in the end) there's even work to get rid of that
silly udev, err, systemd-udev, err, systemd dependency. The harder some
people try to force their ideas on others the faster we get replacements
to route around the damage.
Post by Nicolas Sebrecht
Nobody
can say if and when this could heppen but this is clearly possible for
OpenRC to become a Gentoo init system _alternative_.
Maybe there will be a Gentoo fork with systemd as default. Maybe systemd
will be better supported than it is now. But we've invested too much
energy into a surprise-free solution that "Just Works" and isn't 100k
LoC with almost no comments to just switch to something that is a lot
harder to manage and doesn't even have all the same features.
(Sidenote: if anyone ever claims the kernel is bad code - let them read
systemd or upstart. It gives a good perspective. Kernel is about the
best code you can find for bedside reading)
(And another sidenote: we have almost no control over systemd upstream,
so ... no thanks. If they decide to integrate syslog into ... oh wait
... uhm, if they decide to integrate consolekit ... eerrrrr, if they ...
uhm ... add ... an X server? I hope I didn't give anyone a silly idea
now, but that'd be bad.
I have some machines that boot with <64MB memory used, I would like for
things to stay small and efficient)
Post by Nicolas Sebrecht
This is why I think that switching to OpenRC *now* would be wrong.
I think not switching now would be wrong, but in the end it's your loss
and not mine ;)

Have fun,

Patrick
Nicolas Sebrecht
2012-05-09 08:58:01 UTC
Permalink
Post by Patrick Lauer
Nyet. Future very certain. Most of us will stick with OpenRC, and do
whatever is needed to keep it working.
I don't think so, like developers from inside the Gentoo community
itself...
Post by Patrick Lauer
Now that systemd upstream has assimilated udev (which confuses nicely,
but their decision in the end) there's even work to get rid of that
silly udev, err, systemd-udev, err, systemd dependency. The harder some
people try to force their ideas on others the faster we get replacements
to route around the damage.
...because udev is merged into systemd (which makes perfect sense to get
an event-driven boot system).

And dbus will be part of the kernel, soon.

So, what you call "silly dependencies" *are the core* of a Linux system.

These are needed changes to really have expected features in the
beginning of this century. Of course, you could support the old way of
maintaining services and handling init. But the price is to add more
complexity/workload in the middle/long term and become esoteric to
upcoming killer features which will just (or almost, at least) work out
of the box with an event driven init system.
--
Nicolas Sebrecht
Kevin Chadwick
2012-05-09 09:54:52 UTC
Permalink
On Wed, 9 May 2012 10:58:01 +0200
Post by Nicolas Sebrecht
And dbus will be part of the kernel, soon.
So, what you call "silly dependencies" *are the core* of a Linux system.
So is that sentiment, we'll force it upon you. How lovely.

You have read all the security papers about dbus, right?

Unless your willing to give up lots of your own or machine time
compiling of course.

I wouldn't run the as admitted by and somewhat out of Linus's control
bloated linux kernel on servers, adding dbus would just re-affirm that
even if it wasn't used.

I wonder and am not suggesting whether the unix/posix world is going to
divulge completely due to linux only tech.


I wonder when/if a new linux kernel will gather steam. Perhaps called
something like genux. Or if techs will eventually flock even more to the
BSDs.


They're retorical by the way.
Guus Snijders
2012-04-26 23:41:48 UTC
Permalink
Post by Patrick Lauer
Greetings,
[init, systemd]
Post by Patrick Lauer
As an alternative to the One Process For Everything I'd like to ask
you to evalute OpenRC as an init system for Arch Linux.
Possibly a stupid idea and probably OT, but i was just thinking; as
systemd appears to take off more and more, how about parsing the unit
files it uses in OpenRC?

I really like the simplicity of the current init scripts, but i could
imagine systemd taking over at some point. It would be very nice to have
an alternative in that case.
If OpenRC could be made to use the same config files (or at least, the
daemon-specific files) then it could very well be a nice alternative
whilst keeping it simple for the developers.

But for the moment, i prefer the current Arch Init system. Coming from a
debian background, this was the first thing I noticed and came to love
in Arch. Pacman was a close second ;).


mvg,
Guus
Continue reading on narkive:
Loading...