Discussion:
Survey answers part 3: systemd is not portable and what this means for our ports
(too old to reply)
Michael Stapelberg
2013-07-13 21:46:12 UTC
Permalink
Hi,

since some people might not read planet debian, here is a link to my
third blog post in a series of posts dealing with the results of the
Debian systemd survey:

http://people.debian.org/~stapelberg/2013/07/13/systemd-not-portable.html
--
Best regards,
Michael
John Paul Adrian Glaubitz
2013-07-13 22:10:09 UTC
Permalink
Post by Michael Stapelberg
since some people might not read planet debian, here is a link to my
third blog post in a series of posts dealing with the results of the
http://people.debian.org/~stapelberg/2013/07/13/systemd-not-portable.html
This has risen a question here: How many people are actually using the
kFreeBSD port. Are there any rough numbers?

I have checked popcon for the kFreeBSD kernel image and it seems the
numbers from popcon are very low [1].

Adrian
Post by Michael Stapelberg
[1] http://qa.debian.org/popcon.php?package=kfreebsd-9
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Moritz Mühlenhoff
2013-07-14 10:26:13 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Michael Stapelberg
since some people might not read planet debian, here is a link to my
third blog post in a series of posts dealing with the results of the
http://people.debian.org/~stapelberg/2013/07/13/systemd-not-portable.html
This has risen a question here: How many people are actually using the
kFreeBSD port. Are there any rough numbers?
If the kfreebsd port wants to have a chance to succeed it should be trimmed down
to sensible use cases, e.g.
- file server, where people want to run ZFS
- firewall system, where people want to run pf

For these narrowed down set there would even be a chance to have tested/working
sysv init scripts.

kfreebsd and freebsd are simply lacking too many features (starting with
graphics drivers el al) to ever be a viable base for a desktop system.

Cheers,
Moritz
Thomas Goirand
2013-07-14 04:45:23 UTC
Permalink
Hi there,
Post by Michael Stapelberg
Hi,
since some people might not read planet debian, here is a link to my
third blog post in a series of posts dealing with the results of the
http://people.debian.org/~stapelberg/2013/07/13/systemd-not-portable.html
Amazing. You're just discarding what has been already discussed in this
Post by Michael Stapelberg
We, the Debian project, have two realistic options in my point of
We stay with sysvinit, the least common denominator, forever.
We use a modern init system such as systemd on Debian GNU/Linux.
These aren't the only viable option and you know it. FYI, OpenRC port to
Debian is doing well, and it is already able to boot a Debian system
with current init script unmodified. Remaining to do:
- support for update-rc.d
- support for invoke-rc.d
- finish the init.d script compatibility (not much remaining to do)
- make it work with an unmodified /etc/inittab
- add support for X-Start-Before (that might be the hardest part)

These issues are fixable, and I have a good hope that it will happen
before the end of the GSoC project. And there's also upstart as a quite
realistic option too.

You also wrote more or less that systemd is the only way to support
cgroups, while this is untrue. OpenRC at least has support for it (and
probably upstart too? I'm not sure...), and it also builds on FreeBSD
(not yet Debian kFreeBSD, but that also should be easy to fix). The
argument that to support modern things like cgroups, an init system has
to be incompatible with anything else than Linux is just simply false.

You know all this (if you don't, then you should read replies of others
before posting such a blog post), so why writing this? You don't want to
create another monster troll thread, do you?

Thomas Goirand (zigo)

Note: I haven't even debated things, just only debunked your post.
John Paul Adrian Glaubitz
2013-07-14 08:57:23 UTC
Permalink
Post by Thomas Goirand
These aren't the only viable option and you know it. FYI, OpenRC port to
Debian is doing well, and it is already able to boot a Debian system
- support for update-rc.d
- support for invoke-rc.d
- finish the init.d script compatibility (not much remaining to do)
- make it work with an unmodified /etc/inittab
- add support for X-Start-Before (that might be the hardest part)
OpenRC has already been discussed for Debian for over a year, it's still
not fully ported and working, yet you claim the port is doing well.

Are you seriously expecting anyone to use such a patch work on a
productive machine?
Post by Thomas Goirand
These issues are fixable, and I have a good hope that it will happen
before the end of the GSoC project. And there's also upstart as a quite
realistic option too.
The difference is, however, systemd is already there, has matured and a
strong upstream community. Why should we settle for something which
doesn't even have a foreseeable future of upstream maintainership?
Post by Thomas Goirand
You also wrote more or less that systemd is the only way to support
cgroups, while this is untrue. OpenRC at least has support for it (and
probably upstart too? I'm not sure...), and it also builds on FreeBSD
(not yet Debian kFreeBSD, but that also should be easy to fix). The
argument that to support modern things like cgroups, an init system has
to be incompatible with anything else than Linux is just simply false.
upstart is (or is going to use) the prctl Linux system call and
therefore no longer compatible with non-Linux kernels.

Adrian
Post by Thomas Goirand
[1]
https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Respawning_user_jobs_and_PID_tracking
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Marco d'Itri
2013-07-14 09:26:29 UTC
Permalink
Post by John Paul Adrian Glaubitz
OpenRC has already been discussed for Debian for over a year, it's
still not fully ported and working, yet you claim the port is doing
well.
And even if ported and fully working it will still lack the features
needed by a modern init system.
OpenRC is too little and too late, and it's a shame a GSoC project is
wasted on this dead end.
--
ciao,
Marco
Nicolas Dandrimont
2013-07-14 11:48:13 UTC
Permalink
Post by Marco d'Itri
Post by John Paul Adrian Glaubitz
OpenRC has already been discussed for Debian for over a year, it's
still not fully ported and working, yet you claim the port is doing
well.
And even if ported and fully working it will still lack the features
needed by a modern init system.
OpenRC is too little and too late, and it's a shame a GSoC project is
wasted on this dead end.
It's a shame that such objections haven't been raised in a timely manner
and through the proper channels.
--
Nicolas Dandrimont
wearing his Debian GSoC Org Admin hat
Marco d'Itri
2013-07-14 12:23:34 UTC
Permalink
Post by Nicolas Dandrimont
Post by Marco d'Itri
OpenRC is too little and too late, and it's a shame a GSoC project is
wasted on this dead end.
It's a shame that such objections haven't been raised in a timely manner
and through the proper channels.
I did it here and in #684396, so I think that it counts as "timely and
through the proper channels".
--
ciao,
Marco
David Kalnischkies
2013-07-14 11:09:21 UTC
Permalink
On Sun, Jul 14, 2013 at 10:57 AM, John Paul Adrian Glaubitz
Post by Thomas Goirand
These aren't the only viable option and you know it. FYI, OpenRC port to
Debian is doing well, and it is already able to boot a Debian system
- support for update-rc.d
- support for invoke-rc.d
- finish the init.d script compatibility (not much remaining to do)
- make it work with an unmodified /etc/inittab
- add support for X-Start-Before (that might be the hardest part)
OpenRC has already been discussed for Debian for over a year, it's still not
fully ported and working, yet you claim the port is doing well.
Are you seriously expecting anyone to use such a patch work on a productive
machine?
At least I am seriously expecting that Debian isn't discarding the outcome
of a project it has officially endorsed to be under its umbrella for GSoC
without even the slightest bit of consideration.

GSoC in Debian was announced a long time ago, enough time to raise
any objections against any proposed project. Either this wasn't done or
it wasn't done loud enough as the OpenRC project was accepted and is now
being worked on by a student, so its too late to voice any concerns now
as this is just slapping the student right across the face. Its at least
nothing I would do while trying to hook a student to continue working
in/on Debian even long after a specific project is done (and GSoC ended).

Feel free to evaluate (any project) after it is finished and draw your
conclusions from that (for the specific project, GSoC in general, …),
but don't complaining about it without even trying.

Last I heard, that was exactly systemd fanbase complain: that everyone
just complained without even trying it based on hearsay.
So, lets try "leading by example", shall we?
Post by Thomas Goirand
These issues are fixable, and I have a good hope that it will happen
before the end of the GSoC project. And there's also upstart as a quite
realistic option too.
The difference is, however, systemd is already there […]
It is not "already there".
That was the whole freaking point of this "survey".

There is still enough time for anythings fanbase to bash each other.
Just avoid beating new contributors in the process who might not have
developed a thick enough skin just yet.


Best regards

David Kalnischkies, who couldn't care less about init systems^W^W"System and
Service Managers" so try to avoid putting him in some fanbase camp please.
Marco d'Itri
2013-07-14 12:31:52 UTC
Permalink
Post by David Kalnischkies
At least I am seriously expecting that Debian isn't discarding the outcome
of a project it has officially endorsed to be under its umbrella for GSoC
without even the slightest bit of consideration.
I am seriously expecting that Debian will not waste time with what is
clearly an inferior solution just because somebody approved a GSoC
project for it.
Post by David Kalnischkies
GSoC in Debian was announced a long time ago, enough time to raise
any objections against any proposed project. Either this wasn't done or
it wasn't done loud enough as the OpenRC project was accepted and is now
It was done by me and others in the related BTS bug (#684396), and I
believe that I was loud enough.
Post by David Kalnischkies
being worked on by a student, so its too late to voice any concerns now
as this is just slapping the student right across the face. Its at least
I am quite sure that the quality of Debian and its continued viability
as a modern OS is way more important than anybody's feelings.
Post by David Kalnischkies
Feel free to evaluate (any project) after it is finished and draw your
conclusions from that (for the specific project, GSoC in general, 
),
but don't complaining about it without even trying.
There is no reason to wait, since the GSoC project cannot solve the
fundamental issues about GSoC.
Post by David Kalnischkies
Last I heard, that was exactly systemd fanbase complain: that everyone
just complained without even trying it based on hearsay.
I am not a systemd fan, I am a modern init fan. We have at least two of
these around: systemd and upstart. OpenRC does not qualify.
--
ciao,
Marco
Thomas Goirand
2013-07-14 14:41:53 UTC
Permalink
Post by Marco d'Itri
Post by David Kalnischkies
At least I am seriously expecting that Debian isn't discarding the outcome
of a project it has officially endorsed to be under its umbrella for GSoC
without even the slightest bit of consideration.
I am seriously expecting that Debian will not waste time with what is
clearly an inferior solution just because somebody approved a GSoC
project for it.
Me as well! Though I don't think working on OpenRC is a waste, and it
isn't my view that it is an inferior solution: at least it will work for
kFreeBSD and Hurd, provide cgroup supports, and simplify init scripts.
The fact that it doesn't do too much and rewrite absolutely everything
from syslog to I-don't-know-what can be seen as a good thing, not a bad
one (this is my view that systemd is bloated).
Post by Marco d'Itri
Post by David Kalnischkies
GSoC in Debian was announced a long time ago, enough time to raise
any objections against any proposed project. Either this wasn't done or
it wasn't done loud enough as the OpenRC project was accepted and is now
It was done by me and others in the related BTS bug (#684396), and I
believe that I was loud enough.
Don't worry, you were loud enough, no doubts about that! :)
Post by Marco d'Itri
As I said before
No need to repeat yourself then!
Post by Marco d'Itri
this whole OpenRC in Debian has been announced almost over
a year ago
Absolutely nobody made any announcement. Zero, none...
Also,
Post by Marco d'Itri
yet there isn't any fully working implementation
I'm not sure what you call "fully working". If you are talking about the
software itself, well, Gentoo has been using it for years. For what I
can see in Debian, it currently boots and runs init scripts, and the
status I gave shows that only a few Debian integrations are missing. The
core system works, which was the biggest concern.

Is it your view that reimplementation of update-rc.d and invoke-rc.d
will need many years of testings to make sure they are correct? In that
case, systemd needs a millennium to be tested correctly!
Post by Marco d'Itri
while systemd is already in production use.
Maybe you should give OpenRC (and the GSoC student) a chance. That's all
we asked. Please respect this project.

Seeing the shape the discussion is taking, it is very clear that people
like you, Marco and Michael, will dismiss OpenRC as a possibility,
whatever happens. It doesn't mater, feel free to do that, but *later on*
please, when we have the results at the end of the summer. Please
respect this project, and the people that believe in it.

Also, anyway what happens, even if we switch to systemd or upstart, both
wont work for anything else than Linux (as stated earlier in this
thread). So whatever happens, it will not be a waste.

Thomas
Holger Levsen
2013-07-14 15:40:13 UTC
Permalink
Hi,
Post by Thomas Goirand
Post by John Paul Adrian Glaubitz
yet there isn't any fully working implementation
I'm not sure what you call "fully working".
one which is at least installable with apt-get + sid sources.
that's still not the case, despite 684396 being announced here a year ago.


cheers,
Holger
Thomas Goirand
2013-07-14 17:40:12 UTC
Permalink
Post by Holger Levsen
Hi,
Post by Thomas Goirand
Post by John Paul Adrian Glaubitz
yet there isn't any fully working implementation
I'm not sure what you call "fully working".
one which is at least installable with apt-get + sid sources.
that's still not the case, despite 684396 being announced here a year ago.
That's right, we're not there yet.

Thomas
heroxbd
2013-07-15 11:37:59 UTC
Permalink
Dear Guys,
one which is at least installable with apt-get + sid sources. that's
still not the case, despite 684396 being announced here a year ago.
(Replying generally)

There seems to be some doubts concerning why #684396 has taken a whole
year without being finished. This fact is quoted by people to infer
OpenRC is not serious and not for production.

They are two things and should not be mixed. I am only going to respond
to the first question here.

On my side, I am offering to package OpenRC. I did not have a deep
understanding of Debian packaging and learnt as I went, although I
myself had been a user for 10 years. (My servers are Debian and Gentoo,
laptop/desktops are Debian.) I was not in a hurry. After composing a
wiki page[1] and having all my Debian boxes with OpenRC, I just spent a
bit more time to evaluate the solution by actually using it for my own
daily life and production. And yeah, it's partially because of laziness.
I haven't seen people ping this bug and thought there is not a wide
audience so I took my own pace.

I don't think we are in a race with systemd. It feels that people
developing or supporting systemd are competing against the world, as if
they can dominate the community by rolling out more modern features,
advancing fast enough, pushing others hard and finally rendering
everything alternative into the museum. This is a nice commercial
strategy and is more likely to succeed in competition. But I don't care
about it.

Things changed when it evolves into a GSoC project, where we have a
student actively working on it. It becomes my duty to co-mentor with
Thomas to realize the ITP. We are gaining momentum after the student,
Bill Wang, has digested the basics.

I can visualize that within two months we will have a off-the-shelf
OpenRC package working with initscripts/sysvinit vanilla offering modern
features like cgroups, at users' choice.

Voice from upstream, the OpenRC team is well aware of the effort and is
eager to take patches necessary to support Debian, provided it can both
benefit Debian and Gentoo, as is often the case when we come down to
this level of OS.

Relax fellows. let's see what we can get and have fun.

Cheers,
Benda

1. http://wiki.debian.org/OpenRC
John Paul Adrian Glaubitz
2013-07-15 12:30:43 UTC
Permalink
Post by heroxbd
I can visualize that within two months we will have a off-the-shelf
OpenRC package working with initscripts/sysvinit vanilla offering modern
features like cgroups, at users' choice.
Good, I'll take your word on that.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Geoffrey Thomas
2013-07-14 18:55:06 UTC
Permalink
Post by Marco d'Itri
Post by David Kalnischkies
being worked on by a student, so its too late to voice any concerns now
as this is just slapping the student right across the face. Its at least
I am quite sure that the quality of Debian and its continued viability
as a modern OS is way more important than anybody's feelings.
Sorry, I have to respond to this -- I have no strong opinions about init
systems, but I do have strong opinions about how Debian treats new
contributors.

The quality of Debian and its continued viability as a modern OS is
directly dependent on people being willing to work on it, and the actions
of Debian towards new contributors will last far longer than any technical
decision today. And people's feelings impact their retention as
contributors.

It's not very meaningful to say that a thing is more important than
another thing that it depends on.

And if it turns out that systemd is today necessary for Debian's
"viability as a modern OS", there are ways for the project to make that
decision without being rude to folks who have been working on other
systems (and, of course, without them being rude to folks working on
systemd either). The objection is to the manner in which the statement was
made; it was not a claim about the truth of the statement.
--
Geoffrey Thomas
http://ldpreload.com
***@ldpreload.com
Josselin Mouette
2013-07-15 12:09:20 UTC
Permalink
Post by Geoffrey Thomas
And if it turns out that systemd is today necessary for Debian's
"viability as a modern OS", there are ways for the project to make that
decision without being rude to folks who have been working on other
systems (and, of course, without them being rude to folks working on
systemd either). The objection is to the manner in which the statement was
made; it was not a claim about the truth of the statement.
What I find rude is that a minority of idiots is taking the project
hostage of their ridiculous demands, preventing a quick switch to a
decent init systems, for reasons that are anything but technical.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@pi0307572
Wouter Verhelst
2013-07-15 13:03:21 UTC
Permalink
Post by Josselin Mouette
Post by Geoffrey Thomas
And if it turns out that systemd is today necessary for Debian's
"viability as a modern OS", there are ways for the project to make that
decision without being rude to folks who have been working on other
systems (and, of course, without them being rude to folks working on
systemd either). The objection is to the manner in which the statement was
made; it was not a claim about the truth of the statement.
What I find rude is that a minority of idiots is taking the project
hostage of their ridiculous demands, preventing a quick switch to a
decent init systems, for reasons that are anything but technical.
What I find rude is that a minority of idiots is taking the project
hostage of their ridiculous demands, preventing anything but endless and
pointless discussion about init systems, for reasons that are anything
but technical.

I thought we'd released, and that the time for "I'm bored, so let's talk
about something silly on -devel" was over.
--
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

-- http://xkcd.com/1133/
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@debian.org
Geoffrey Thomas
2013-07-16 02:57:52 UTC
Permalink
Post by Josselin Mouette
Post by Geoffrey Thomas
And if it turns out that systemd is today necessary for Debian's
"viability as a modern OS", there are ways for the project to make that
decision without being rude to folks who have been working on other
systems (and, of course, without them being rude to folks working on
systemd either). The objection is to the manner in which the statement was
made; it was not a claim about the truth of the statement.
What I find rude is that a minority of idiots is taking the project
hostage of their ridiculous demands, preventing a quick switch to a
decent init systems, for reasons that are anything but technical.
There are ways to express this without calling anyone "idiots". Or do you
believe that Debian is incapable of making solid technical decisions
without namecalling?
--
Geoffrey Thomas
http://ldpreload.com
***@ldpreload.com
Mathias Behrle
2013-07-16 10:00:58 UTC
Permalink
* Geoffrey Thomas: " Re: Survey answers part 3: systemd is not portable and
There are ways to express this without calling anyone idiots.
+2
Marco d'Itri
2013-07-16 11:30:23 UTC
Permalink
Post by Geoffrey Thomas
There are ways to express this without calling anyone "idiots". Or
do you believe that Debian is incapable of making solid technical
decisions without namecalling?
We may consider it as character evidence.
--
ciao,
Marco
Marc Haber
2013-07-17 07:24:21 UTC
Permalink
Post by Josselin Mouette
What I find rude is that a minority of idiots is taking the project
hostage of their ridiculous demands, preventing a quick switch to a
decent init systems, for reasons that are anything but technical.
Once more, I find your wording utterly offensive and thus
inacceptable. This is not helping. You are doing harm to your causes.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
John Paul Adrian Glaubitz
2013-07-17 08:20:19 UTC
Permalink
Post by Marc Haber
Post by Josselin Mouette
What I find rude is that a minority of idiots is taking the project
hostage of their ridiculous demands, preventing a quick switch to a
decent init systems, for reasons that are anything but technical.
Once more, I find your wording utterly offensive and thus
inacceptable. This is not helping. You are doing harm to your causes.
I think Joss was just responding to the other guy who claimed that
everyone who needs advanced features in a init daemon to manage
their systems is an idiot.

I understood it as a form of sarcasm.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
2013-07-14 12:38:02 UTC
Permalink
Post by David Kalnischkies
At least I am seriously expecting that Debian isn't discarding the outcome
of a project it has officially endorsed to be under its umbrella for GSoC
without even the slightest bit of consideration.
I didn't know that someone is working on OpenRC under the umbrella of
GSoC. Don't make any assumptions, please.
Post by David Kalnischkies
GSoC in Debian was announced a long time ago, enough time to raise
any objections against any proposed project. Either this wasn't done or
it wasn't done loud enough as the OpenRC project was accepted and is now
being worked on by a student, so its too late to voice any concerns now
as this is just slapping the student right across the face. Its at least
nothing I would do while trying to hook a student to continue working
in/on Debian even long after a specific project is done (and GSoC ended).
Well, if I had known it, I'd have voted against it. And, I am sorry, but
just because a GSoC student is working on OpenRC in Debian doesn't make
it any more appealing or sensible in my eyes.

If we made decisions based on this fact, Hurd would have to be a
release kernel by now.
Post by David Kalnischkies
Feel free to evaluate (any project) after it is finished and draw your
conclusions from that (for the specific project, GSoC in general, …),
but don't complaining about it without even trying.
As I said before, this whole OpenRC in Debian has been announced almost
over a year ago, yet there isn't any fully working implementation while
systemd is already in production use.
Post by David Kalnischkies
Last I heard, that was exactly systemd fanbase complain: that everyone
just complained without even trying it based on hearsay.
So, lets try "leading by example", shall we?
There is no systemd fanbase. I am not favoring systemd because I like
Lennart or because I think the name is cool, but because systemd is
objectively the far superior solution developed by experienced developers.

Debian isn't a toy project, it's supposed to be used on production systems.
Post by David Kalnischkies
Post by Thomas Goirand
These issues are fixable, and I have a good hope that it will happen
before the end of the GSoC project. And there's also upstart as a quite
realistic option too.
The difference is, however, systemd is already there […]
It is not "already there".
That was the whole freaking point of this "survey".
You can install and use it. It's unfortunately just horribly outdated in
Debian for whatever reason I still don't know of.
Post by David Kalnischkies
There is still enough time for anythings fanbase to bash each other.
Just avoid beating new contributors in the process who might not have
developed a thick enough skin just yet.
Could you please leave the "fan base" accusations out of here? I am not
a fan, I don't care about what init system we are using as long it's the
best solution.
Post by David Kalnischkies
David Kalnischkies, who couldn't care less about init systems^W^W"System and
Service Managers" so try to avoid putting him in some fanbase camp please.
You don't sound like you're not biased, however.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@physik.fu-berlin.de
Игорь Пашев
2013-07-14 13:54:28 UTC
Permalink
Why not to use different init systems on different kernels?
Debian already supports 3 (three) init systems *at once*, sysvinit,
upstart, systemd.
This is much harder that using single system.

FYI, on Dyson [1] I've made dh_installinit noop, and working on dh-smf [2]


[1] http://osdyson.org
[2] http://cgit.osdyson.org/dh-smf.git
Marco d'Itri
2013-07-14 19:16:04 UTC
Permalink
Post by Игорь Пашев
Why not to use different init systems on different kernels?
Because it would be stupid, since it requires either one of:
- implementing the equivalent of init scripts for each init system
- dumbing down the init systems to the lowest common denominator (and
when you have sysvinit or OpenRC then it's quite low)
Post by Игорь Пашев
Debian already supports 3 (three) init systems *at once*, sysvinit,
upstart, systemd.
No, not really: Debian supports sysvinit and allows installing upstart
or systemd in a way that they will use the sysvinit init scripts. This
is not very useful (especially with upstart), because it does not bring
many improvements over sysvinit.
Then some people start duplicating in every package the init scripts for
upstart and systemd, which is a waste of time and adds code which cannot
be well tested.
--
ciao,
Marco
Игорь Пашев
2013-07-14 19:39:06 UTC
Permalink
Post by Marco d'Itri
which is a waste of time and adds code which cannot
be well tested.
Isn't Debian itself is a waste of time, while we have RedHat? :-P

Let a hundred flowers bloom; let a hundred schools of thought contend.
David Kalnischkies
2013-07-14 18:10:16 UTC
Permalink
On Sun, Jul 14, 2013 at 2:38 PM, John Paul Adrian Glaubitz
Post by David Kalnischkies
At least I am seriously expecting that Debian isn't discarding the outcome
of a project it has officially endorsed to be under its umbrella for GSoC
without even the slightest bit of consideration.
I didn't know that someone is working on OpenRC under the umbrella of GSoC.
Don't make any assumptions, please.
I am sorry, but I figured that because Thomas was talking about this project
with the keyword Debian and GSoC in his mail that this would be known.
Post by David Kalnischkies
Last I heard, that was exactly systemd fanbase complain: that everyone
just complained without even trying it based on hearsay.
So, lets try "leading by example", shall we?
There is no systemd fanbase. I am not favoring systemd because I like
Lennart or because I think the name is cool, but because systemd is
objectively the far superior solution developed by experienced developers.
Debian isn't a toy project, it's supposed to be used on production systems.
The benefit of being the "objectively far superior solution" is that you don't
need to be scared of competing with inferior solutions, as you will always
win in Debian. No name calling, no politics, no popularity contest, just pure
clear objective facts everyone can validate by trying it out.

If the student delivers a project which can be evaluated for its technical
merits, we have won a lot, as this automatically shuts up every "what if
we adapted this to our needs" …
That path was explored, it didn't prove useful because … kthxbye.
A lot better than trying to argue with not objective arguments.


I am not going to comment the other parts as I assume it is not meant to be
commented – especially as your second to last sentence suggests that we
actually have the same goal and just approach it differently.
I am suggesting to read about GSoC (and similar) in Debian though.


Best regards

David Kalnischkies
Steve Langasek
2013-07-15 16:54:39 UTC
Permalink
Post by David Kalnischkies
Post by John Paul Adrian Glaubitz
Post by David Kalnischkies
Last I heard, that was exactly systemd fanbase complain: that everyone
just complained without even trying it based on hearsay.
So, lets try "leading by example", shall we?
There is no systemd fanbase. I am not favoring systemd because I like
Lennart or because I think the name is cool, but because systemd is
objectively the far superior solution developed by experienced developers.
Debian isn't a toy project, it's supposed to be used on production systems.
The benefit of being the "objectively far superior solution" is that you don't
need to be scared of competing with inferior solutions, as you will always
win in Debian. No name calling, no politics, no popularity contest, just pure
clear objective facts everyone can validate by trying it out.
This ignores the cost of having to repeatedly deal with mailing list
threads, bug reports, etc. from people who are blind to the technical
limitations of the solution they're championing. People aren't bothered by
OpenRC because it might win, they're bothered because its advocates fail to
understand why they've already lost before they've begun.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
John Paul Adrian Glaubitz
2013-07-15 17:50:40 UTC
Permalink
People aren't bothered by OpenRC because it might win, they're
bothered because its advocates fail to understand why they've
already lost before they've begun.
I fully agree on this with you! I cannot really imagine OpenRC to
be ever a viable alternative to systemd (or even upstart). It
just lacks too much behind and would be a minor improvement over
System V Init only.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Thomas Goirand
2013-07-16 01:16:16 UTC
Permalink
Post by John Paul Adrian Glaubitz
People aren't bothered by OpenRC because it might win, they're
bothered because its advocates fail to understand why they've
already lost before they've begun.
I fully agree on this with you! I cannot really imagine OpenRC to
be ever a viable alternative to systemd (or even upstart). It
just lacks too much behind and would be a minor improvement over
System V Init only.
Adrian
You have to define what problem we are trying to solve. And this still
hasn't been defined yet in this list. Please do so instead of just
writing a statement with no argumentation.

Thomas
Paul Tagliamonte
2013-07-14 19:19:51 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by David Kalnischkies
At least I am seriously expecting that Debian isn't discarding the outcome
of a project it has officially endorsed to be under its umbrella for GSoC
without even the slightest bit of consideration.
I didn't know that someone is working on OpenRC under the umbrella
of GSoC. Don't make any assumptions, please.
There was a mail to d-d-a. (***@loki.localdomain)
surely you read d-d-a :)
Post by John Paul Adrian Glaubitz
Post by David Kalnischkies
GSoC in Debian was announced a long time ago, enough time to raise
any objections against any proposed project. Either this wasn't done or
it wasn't done loud enough as the OpenRC project was accepted and is now
being worked on by a student, so its too late to voice any concerns now
as this is just slapping the student right across the face. Its at least
nothing I would do while trying to hook a student to continue working
in/on Debian even long after a specific project is done (and GSoC ended).
Well, if I had known it, I'd have voted against it. And, I am sorry,
To quote another DD I respect a great deal: "This is not a fucking
vote". They had a sane project that had a great chance of improving
Debian, and gives us options.

It's also about the *student*. We want more contributors. Why throw away
someone willing to do great work within Debian?
Post by John Paul Adrian Glaubitz
but just because a GSoC student is working on OpenRC in Debian
doesn't make it any more appealing or sensible in my eyes.
It gives us an option.

[...]

Cheers,
Paul
--
.''`. Paul Tagliamonte <***@debian.org>
: :' : Proud Debian Developer
`. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`- http://people.debian.org/~paultag
Matthias Klumpp
2013-07-14 19:41:10 UTC
Permalink
Hi!
Post by Paul Tagliamonte
[...]
It's also about the *student*. We want more contributors. Why throw away
someone willing to do great work within Debian?
Post by John Paul Adrian Glaubitz
but just because a GSoC student is working on OpenRC in Debian
doesn't make it any more appealing or sensible in my eyes.
It gives us an option.
I have to agree with that statement, even as strong supporter of
systemd. There is nothing wrong with exploring different options, even
if they might not be viable in future (who knows?). And even if we
switch to systemd completely, OpenRC might be a nice option for
non-Linux ports to use or for possible other use-cases.
Also, I am certain that the SoC student will gain a lot of knowledge
about the init-process and the structures in Debian itself, which
mages this GSoC project a perfectly sane choice.
Cheers,
Matthias
--
I welcome VSRE emails. See http://vsre.info/
Florian Weimer
2013-07-14 13:47:01 UTC
Permalink
Post by David Kalnischkies
GSoC in Debian was announced a long time ago, enough time to raise
any objections against any proposed project.
Not really, a GSoC project doesn't come with any guarantee, implied or
otherwise, that any deliverable is actually used by the mentoring
organization.

(Of the twelve 2012 projects, only two were actually picked up by
Debian, as far as I could tell.)
David Kalnischkies
2013-07-14 18:12:24 UTC
Permalink
Post by Florian Weimer
Post by David Kalnischkies
GSoC in Debian was announced a long time ago, enough time to raise
any objections against any proposed project.
Not really, a GSoC project doesn't come with any guarantee, implied or
otherwise, that any deliverable is actually used by the mentoring
organization.
That is fine (at least for some definitions of fine. Ideally everything would
be picked up – and of course also proposed in a way that it can be picked
up – but that is unrealistic).

But there is a difference between "not used after its done as the project
proofed that it is not able to deliver something more valuable" and
"saying midway that whatever the student does, it will be discarded".

We have a student who works on that stuff, so the least we can do is check
if whatever the outcome will be can be useful for Debian, even if the outcome
is that it is not useful for Debian at all – that is at least a
technical argument
someone can work with and removes a candidate from the pool.


Best regards

David Kalnischkies
Marco d'Itri
2013-07-14 19:20:15 UTC
Permalink
Post by David Kalnischkies
But there is a difference between "not used after its done as the project
proofed that it is not able to deliver something more valuable" and
"saying midway that whatever the student does, it will be discarded".
Whatever the student will do it cannot change the fact that OpenRC is
still going to be a minor improvement over sysvinit and too much far
from upstart and systemd[1].
And again, this was explained clearly when the project was proposed.


[1] and let's not even start discussing the wisdom of adopting a totally
unknown init system which nobody but Gentoo uses, because the people
who don't even get this just make me sad.
--
ciao,
Marco
Thomas Goirand
2013-07-15 08:18:17 UTC
Permalink
Post by Marco d'Itri
Post by David Kalnischkies
But there is a difference between "not used after its done as the project
proofed that it is not able to deliver something more valuable" and
"saying midway that whatever the student does, it will be discarded".
Whatever the student will do it cannot change the fact that OpenRC is
still going to be a minor improvement over sysvinit and too much far
from upstart and systemd[1].
And again, this was explained clearly when the project was proposed.
[1] and let's not even start discussing the wisdom of adopting a totally
unknown init system which nobody but Gentoo uses, because the people
who don't even get this just make me sad.
If OpenRC goes up to the shape I expect, it will have a huge advantage
over systemd and Upstart: it will not be controversial, throwing away
non-Linux ports, and taking over the whole of the system. It will just
be an improvement, and that's it.

When thinking about switching from one init system to another, it should
all come down to what objective we are trying to aim at. These haven't
been clearly defined, and I think it's a shame, because that should be
what influences our decision. Personally, the most important bit is to
get rid of the huge init scripts, and make them simple and declarative.
Best is to do it without disturbing any other package (or port). OpenRC
has the potential to do that, so it is worth exploring this path.

Calling OpenRC unkonwn is by the way stretched to say the least. Saying
that it's used only by Gentoo is simply just wrong (it has ports for
*BSD systems).

Thomas
Charles Plessy
2013-07-15 09:02:34 UTC
Permalink
Post by Thomas Goirand
If OpenRC goes up to the shape I expect, it will have a huge advantage
over systemd and Upstart: it will not be controversial, throwing away
non-Linux ports, and taking over the whole of the system. It will just
be an improvement, and that's it.
Hi Thomas,

I am very surprised that you advocate the use of init scripts over
declarative systems such as Upstart or systemd. On debian-cloud
we are just having a thread about the init-scripts of cloud-init,
which are being rewritten from scratch for Debian, because the ones
in the upstream sources "are for CentOS".

cloud-init-0.7.2 $ wc -l systemd/* upstart/* sysvinit/*
17 systemd/cloud-config.service
10 systemd/cloud-config.target
17 systemd/cloud-final.service
16 systemd/cloud-init-local.service
17 systemd/cloud-init.service
9 upstart/cloud-config.conf
10 upstart/cloud-final.conf
9 upstart/cloud-init.conf
57 upstart/cloud-init-container.conf
9 upstart/cloud-init-local.conf
69 upstart/cloud-init-nonet.conf
19 upstart/cloud-log-shutdown.conf
121 sysvinit/cloud-config
121 sysvinit/cloud-final
121 sysvinit/cloud-init
121 sysvinit/cloud-init-local

Doesn't that underline that "classical" init scripts are a big waste of time
for maintainers, and a workload that can not be shared between distributions ?

Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@falafel.plessy.net
Roger Leigh
2013-07-15 09:26:09 UTC
Permalink
Post by Charles Plessy
cloud-init-0.7.2 $ wc -l systemd/* upstart/* sysvinit/*
17 systemd/cloud-config.service
10 systemd/cloud-config.target
17 systemd/cloud-final.service
16 systemd/cloud-init-local.service
17 systemd/cloud-init.service
9 upstart/cloud-config.conf
10 upstart/cloud-final.conf
9 upstart/cloud-init.conf
57 upstart/cloud-init-container.conf
9 upstart/cloud-init-local.conf
69 upstart/cloud-init-nonet.conf
19 upstart/cloud-log-shutdown.conf
121 sysvinit/cloud-config
121 sysvinit/cloud-final
121 sysvinit/cloud-init
121 sysvinit/cloud-init-local
Doesn't that underline that "classical" init scripts are a big waste of time
for maintainers, and a workload that can not be shared between distributions ?
Not without knowing the specifics of why this package requires so many
separate scripts. Normally I understood that systemd was more granular
than the corresponding init scripts, so would have more files in
general. But without knowing more about what all those separate
scripts are doing and why, it's not possible to draw any useful
conclusion from these numbers.


Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Stephen Gran
2013-07-15 18:40:14 UTC
Permalink
Post by Roger Leigh
Post by Charles Plessy
cloud-init-0.7.2 $ wc -l systemd/* upstart/* sysvinit/*
17 systemd/cloud-config.service
10 systemd/cloud-config.target
17 systemd/cloud-final.service
16 systemd/cloud-init-local.service
17 systemd/cloud-init.service
9 upstart/cloud-config.conf
10 upstart/cloud-final.conf
9 upstart/cloud-init.conf
57 upstart/cloud-init-container.conf
9 upstart/cloud-init-local.conf
69 upstart/cloud-init-nonet.conf
19 upstart/cloud-log-shutdown.conf
121 sysvinit/cloud-config
121 sysvinit/cloud-final
121 sysvinit/cloud-init
121 sysvinit/cloud-init-local
Doesn't that underline that "classical" init scripts are a big waste of time
for maintainers, and a workload that can not be shared between distributions ?
Not without knowing the specifics of why this package requires so many
separate scripts. Normally I understood that systemd was more granular
than the corresponding init scripts, so would have more files in
general. But without knowing more about what all those separate
scripts are doing and why, it's not possible to draw any useful
conclusion from these numbers.
It's not clear to me why they need to be so large - there are 4 scripts
that need to be run in a certain order, once, at boot time. I'm sure
that that complexity could be expressed in fewer than 484 lines of shell.

This is not to knock cloud-init - it's a wonderful piece of software.

Cheers,
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : ***@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Thomas Goirand
2013-07-15 18:00:47 UTC
Permalink
Post by Charles Plessy
Post by Thomas Goirand
If OpenRC goes up to the shape I expect, it will have a huge advantage
over systemd and Upstart: it will not be controversial, throwing away
non-Linux ports, and taking over the whole of the system. It will just
be an improvement, and that's it.
Hi Thomas,
I am very surprised that you advocate the use of init scripts over
declarative systems such as Upstart or systemd.
This is a miss-understanding. OpenRC does have a declarative system.
It's just not mandatory (you can decide to implement what you wish).
Post by Charles Plessy
Doesn't that underline that "classical" init scripts are a big waste of time
for maintainers, and a workload that can not be shared between distributions ?
They are, which is why we need to get out of using sysv-rc.

Thomas
Josselin Mouette
2013-07-15 12:07:07 UTC
Permalink
Post by Thomas Goirand
If OpenRC goes up to the shape I expect, it will have a huge advantage
over systemd and Upstart: it will not be controversial, throwing away
non-Linux ports, and taking over the whole of the system. It will just
be an improvement, and that's it.
You want some controversy?

I don’t even want to hear about such a piece of junk at the base of any
system under my responsibility.

At least sysvinit/insserv is maintained by competent people.
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@pi0307572
The Wanderer
2013-07-15 13:00:23 UTC
Permalink
Post by Josselin Mouette
Post by Thomas Goirand
If OpenRC goes up to the shape I expect, it will have a huge
advantage over systemd and Upstart: it will not be controversial,
throwing away non-Linux ports, and taking over the whole of the
system. It will just be an improvement, and that's it.
You want some controversy?
I don’t even want to hear about such a piece of junk at the base of
any system under my responsibility.
At least sysvinit/insserv is maintained by competent people.
Which is preferable: software maintained by competent people with an
ideology (or, if you prefer, a design philosophy) which you starkly
disagree with, or software maintained by less- (or even less-than-)
competent people with whose ideology / philosophy you do not disagree?


My personal objections to systemd come down to the fact that I don't
trust its developers /maintainers. Part of that is bleedover from the
fact that I've so far had only poor experiences with pulseaudio (and
have heard several negative reviews of it not purely based on user
experience, mostly summing up to "why did they start a new audio system
from scratch instead of adding the missing capabilities on to JACK?"),
but most of it hangs from the discussion I once read in which Lennart
expressed - and, when objections were raised to it, reiterated - the
desire to eventually drop support for using udev without systemd.

Joining together the overwhelmingly-dominant device-node-management
system with one of several init systems would not only serve to more
effectively lock out the other init systems, but would act as a sizable
additional obstacle to someone down the line who wants to design another
new init system - one which might differ as much in design and interface
from systemd as systemd does from sysvinit, and which might not need to
interface with (or might need a completely different interface to) a
device-management system. The potential to impede further innovation and
improvement in that way, more than any current technical problems or
limitations, is what I find problematic about the idea.

That attitude as a whole, in fact, is the major offputting thing about
the entire systemd-et-al. project(s) from my perspective; it reminds me
of proprietarianism, and a little bit of "embrace, extend, extinguish",
and I very much want to avoid lock-in.


I actually *like* most of what I've read about systemd's capabilities,
performance, and behavior, as compared to at least sysvinit; I'm even
reasonably willing to accept that it's superior to the other alternative
init systems in those regards. I'm just not at all sure that those
improved capabilities, performance, and behavior are enough of a benefit
to be worth the trade-off of being essentially at the mercy of
developers whose philosophies and attitudes I find so strongly
objectionable.

(I get enough of that nowadays with the Mozilla project; I don't need
more of it elsewhere.)
--
The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@fastmail.fm
John Paul Adrian Glaubitz
2013-07-15 13:43:32 UTC
Permalink
Post by The Wanderer
My personal objections to systemd come down to the fact that I don't
trust its developers /maintainers. Part of that is bleedover from the
fact that I've so far had only poor experiences with pulseaudio
I haven't had any problems with PulseAudio for ages. PulseAudio is
installed by default by all major distributions and I have had heard
little to no complaints ever since it has matured.

Some older versions prior 1.0.x were broken or had exposed bugs in ALSA
drivers which needed to be fixed. These days, however, PulseAudio is
rock-stable.

It usually breaks only for people who tinker too much with it without
understanding the concept behind it.

(and
Post by The Wanderer
have heard several negative reviews of it not purely based on user
experience, mostly summing up to "why did they start a new audio system
from scratch instead of adding the missing capabilities on to JACK?"),
Because JACK and PulseAudio target completely different audiences. JACK
is designed for professional audio and is usually an overkill for most
desktop users. No one, including the PA developers, ever claimed that
PulseAudio is a replacement for JACK.
Post by The Wanderer
but most of it hangs from the discussion I once read in which Lennart
expressed - and, when objections were raised to it, reiterated - the
desire to eventually drop support for using udev without systemd.
While this is still not the case, I don't really see why this shouldn't
be done. udev is Linux-only and so is systemd and neither of them will
probably ever ported to non-Linux kernels.
Post by The Wanderer
That attitude as a whole, in fact, is the major offputting thing about
the entire systemd-et-al. project(s) from my perspective; it reminds me
of proprietarianism, and a little bit of "embrace, extend, extinguish",
and I very much want to avoid lock-in.
Which can be a good thing, sometimes, since it simplifies work for other
developers whose software builds on top of the kernel plumberland when
they know which software to expect on the target system.
Post by The Wanderer
I actually *like* most of what I've read about systemd's capabilities,
performance, and behavior, as compared to at least sysvinit; I'm even
reasonably willing to accept that it's superior to the other alternative
init systems in those regards. I'm just not at all sure that those
improved capabilities, performance, and behavior are enough of a benefit
to be worth the trade-off of being essentially at the mercy of
developers whose philosophies and attitudes I find so strongly
objectionable.
systemd has many independent developers and contributors. I don't think
we're at the mercy of a small group of people when using it.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
The Wanderer
2013-07-15 14:44:21 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by The Wanderer
My personal objections to systemd come down to the fact that I
don't trust its developers / maintainers. Part of that is bleedover
from the fact that I've so far had only poor experiences with
pulseaudio
I haven't had any problems with PulseAudio for ages. PulseAudio is
installed by default by all major distributions and I have had heard
little to no complaints ever since it has matured.
Some older versions prior 1.0.x were broken or had exposed bugs in
ALSA drivers which needed to be fixed. These days, however,
PulseAudio is rock-stable.
It usually breaks only for people who tinker too much with it without
understanding the concept behind it.
My most recent experience with PulseAudio came when I noticed that WoW
(run through Wine) was producing crackling, stuttering sound again; this
was during the late months before the wheezy release.

I tried half-a-dozen things, without noticeable change (except for the
things which led to no sound at all); eventually I noticed that some
PulseAudio packages had been installed, apparently as recommendations or
dependencies of other things. I tried a few things to disable use of
PulseAudio without removing it, without affecting the problem; I then
removed all *pulse* packages I could, rebooted, and the problem was
gone.

I can't guarantee that that was a PulseAudio problem, but I haven't been
able to track it to anything else, and there does seem to be a
correlation. Other people have reported similar "crackling sound in some
programs when using PulseAudio" problems, though I don't recall offhand
how recent those were, and last time I searched there didn't seem to be
any indication of work being done to address that.

The fact that I wasn't able to find a way to disable use of PulseAudio
without uninstalling it is another negative; the fact that even
uninstalling it didn't work until after a *reboot* is an even bigger
one.
Post by John Paul Adrian Glaubitz
Post by The Wanderer
(and have heard several negative reviews of it not purely based on
user experience, mostly summing up to "why did they start a new
audio system from scratch instead of adding the missing
capabilities on to JACK?"),
Because JACK and PulseAudio target completely different audiences.
JACK is designed for professional audio and is usually an overkill
for most desktop users. No one, including the PA developers, ever
claimed that PulseAudio is a replacement for JACK.
The people I've heard discuss these things seem to think that PulseAudio
now essentially implements everything that JACK does plus some, and that
the approach JACK uses is fundamentally the right way to do Linux audio
in the first place. I admit that I haven't investigated this personally,
but I generally trust the understandings of at least one of those
people.


That's irrelevant to the current discussion anyway, however; I only
mentioned pulseaudio because leaving it out in explaining the reasons I
don't trust systemd's developers would have been dishonest.
Post by John Paul Adrian Glaubitz
Post by The Wanderer
but most of it hangs from the discussion I once read in which
Lennart expressed - and, when objections were raised to it,
reiterated - the desire to eventually drop support for using udev
without systemd.
While this is still not the case,
Could you clarify what you mean?

I recognize that support has not yet been dropped, but Lennart's
statements in that discussion (early August 2012 on systemd-devel,
apparently) seem quite clear, and if he's changed his mind I haven't
heard about it.
Post by John Paul Adrian Glaubitz
I don't really see why this shouldn't be done. udev is Linux-only and
so is systemd and neither of them will probably ever ported to
non-Linux kernels.
Not being able to use udev without systemd would mean you couldn't use
any non-systemd init system with udev.

If you don't see why that's a problem, both for other current init
systems and for people who might someday want to implement another new
init system (of perhaps a different design from either current older
ones or systemd), I'm not sure how well I could explain it.
Post by John Paul Adrian Glaubitz
Post by The Wanderer
That attitude as a whole, in fact, is the major offputting thing
about the entire systemd-et-al. project(s) from my perspective; it
reminds me of proprietarianism, and a little bit of "embrace,
extend, extinguish", and I very much want to avoid lock-in.
Which can be a good thing, sometimes, since it simplifies work for
other developers whose software builds on top of the kernel
plumberland when they know which software to expect on the target
system.
There are upsides to that paradigm, yes. There are also downsides.
That's a very large discussion of its own, and I'm not prepared to have
it at the moment, even if this were an appropriate place for it.
Post by John Paul Adrian Glaubitz
Post by The Wanderer
I actually *like* most of what I've read about systemd's
capabilities, performance, and behavior, as compared to at least
sysvinit; I'm even reasonably willing to accept that it's superior
to the other alternative init systems in those regards. I'm just
not at all sure that those improved capabilities, performance, and
behavior are enough of a benefit to be worth the trade-off of being
essentially at the mercy of developers whose philosophies and
attitudes I find so strongly objectionable.
systemd has many independent developers and contributors. I don't
think we're at the mercy of a small group of people when using it.
During the last cycle of this discussion here (in May), IIRC Steve
Langasek dug up statistics indicating that if you ignored udev, close to
78% of systemd code by line count was from Lennart.

And this doesn't matter anyway if the bulk of those independent
developers and contributors all share the same philosophies in this
respect - which, while not certain, is far from impossible, since those
who do not share those philosophies are less likely to contribute to
systemd in the first place.
--
The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
Chris Bannister
2013-07-17 04:29:37 UTC
Permalink
Post by The Wanderer
My most recent experience with PulseAudio came when I noticed that WoW
(run through Wine) was producing crackling, stuttering sound again; this
was during the late months before the wheezy release.
I tried half-a-dozen things, without noticeable change (except for the
things which led to no sound at all); eventually I noticed that some
PulseAudio packages had been installed, apparently as recommendations or
dependencies of other things. I tried a few things to disable use of
PulseAudio without removing it, without affecting the problem; I then
removed all *pulse* packages I could, and the problem was
gone.
Me too, and I don't even use a DE! One day sound just stopped working.
Removing all of the *pulse* packages I could got sound working again.
I didn't mess with anything either.

If there _suddenly_ appears a bad smell in your house and you find the
cause, do you a) Remove the cause? b) Waste time by trying to find out why
it smells?
--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X
Ondřej Surý
2013-07-17 07:05:42 UTC
Permalink
Post by Chris Bannister
Post by The Wanderer
My most recent experience with PulseAudio came when I noticed that WoW
(run through Wine) was producing crackling, stuttering sound again; this
was during the late months before the wheezy release.
I tried half-a-dozen things, without noticeable change (except for the
things which led to no sound at all); eventually I noticed that some
PulseAudio packages had been installed, apparently as recommendations or
dependencies of other things. I tried a few things to disable use of
PulseAudio without removing it, without affecting the problem; I then
removed all *pulse* packages I could, and the problem was
gone.
Me too, and I don't even use a DE! One day sound just stopped working.
Removing all of the *pulse* packages I could got sound working again.
I didn't mess with anything either.
If there _suddenly_ appears a bad smell in your house and you find the
cause, do you a) Remove the cause? b) Waste time by trying to find out why
it smells?
I recommend reading up on what 'anecdotal evidence' is, and filling the bug
report on PA next time when you encounter a problem instead of pilling up
PA issues in debian-devel in order to bash systemd.

O.
--
Ondřej SurÃœ <***@sury.org>
Marc Haber
2013-07-17 07:26:00 UTC
Permalink
On Mon, 15 Jul 2013 15:43:32 +0200, John Paul Adrian Glaubitz
Post by John Paul Adrian Glaubitz
Some older versions prior 1.0.x were broken or had exposed bugs in ALSA
drivers which needed to be fixed. These days, however, PulseAudio is
rock-stable.
It usually breaks only for people who tinker too much with it without
understanding the concept behind it.
Where are the end-user docs that explain the concept?

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
John Paul Adrian Glaubitz
2013-07-17 08:24:01 UTC
Permalink
Post by Marc Haber
Where are the end-user docs that explain the concept?
Was that a troll question? Just use your favorite
search engine.
Post by Marc Haber
http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/
http://freedesktop.org/software/pulseaudio/doxygen/
PA also has excellent support on their IRC channels. I have been
able to solve any problem I had with it so far and in all
cases it turned out to be a user error.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Wouter Verhelst
2013-07-17 08:48:58 UTC
Permalink
Post by John Paul Adrian Glaubitz
PA also has excellent support on their IRC channels. I have been
able to solve any problem I had with it so far and in all
cases it turned out to be a user error.
So have I, with alsa. Mainly because I've never had any problem with
alsa beyond "my hardware is shiny new and the driver hasn't been written
yet". Okay, and there was also this one time where I wanted to figure
out how you enable analog 5.1 surround sound. I've never been able to do
that with PulseAudio, mind you.

PulseAudio piles another layer of possible failures on top of a kernel
driver, and hides most of the audio mixer for no particularly good
reason other than "it might confuse the poor user". It just doesn't make
any sense to me.
--
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

-- http://xkcd.com/1133/
John Paul Adrian Glaubitz
2013-07-17 08:58:49 UTC
Permalink
Post by Wouter Verhelst
So have I, with alsa. Mainly because I've never had any problem with
alsa beyond "my hardware is shiny new and the driver hasn't been written
yet". Okay, and there was also this one time where I wanted to figure
out how you enable analog 5.1 surround sound. I've never been able to do
that with PulseAudio, mind you.
Alsa is a completely different layer in the sound stack. It doesn't even
make sense to compare these two.
Post by Wouter Verhelst
PulseAudio piles another layer of possible failures on top of a kernel
driver, and hides most of the audio mixer for no particularly good
reason other than "it might confuse the poor user". It just doesn't make
any sense to me.
Some sound cards expose two dozens or more level adjustments which most
people don't even understand. I don't think it's a bad idea in general
to clean that up and make the whole interface more consistent and
easier to understand.

Also, your sound setup probably just consists of one sound card in your
desktop/laptop PC which sure enough works just fine with only Alsa.

However, if you have more than one sound device, PulseAudio is a
blessing. For example, my video card has an HDMI output. When
I hook up my PC to my television via HDMI, I want the sound from
VLC to go through HDMI rather than through my sound card. It's
a matter of opening a preferences pane, change the output device
to HDMI and I am done.

How do I do that with just plain Alsa without using a text editor?

What do I do when I want my Skype input going through the USB
webcam's microphone and the audio of Skype through my bluetooth
headset instead of my primary sound card?

I am sorry, but in my eyes, people who claim that PulseAudio is useless
simply don't realize that there can be sound setups which are a little
more sophisticated than just a single sound card and configuring
these can be PITA when you don't have PA.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Timo Juhani Lindfors
2013-07-17 09:06:39 UTC
Permalink
Post by John Paul Adrian Glaubitz
I am sorry, but in my eyes, people who claim that PulseAudio is useless
simply don't realize that there can be sound setups which are a little
more sophisticated than just a single sound card and configuring
these can be PITA when you don't have PA.
Simply being able to switch between laptop headphones and speakers was a
really important feature for me when I switched to PA ages ago. That
might be possible with plain ALSA but at least I haven't managed to find
any UI for it.
Samuel Thibault
2013-07-17 09:09:15 UTC
Permalink
Post by John Paul Adrian Glaubitz
I am sorry, but in my eyes, people who claim that PulseAudio is useless
simply don't realize that there can be sound setups which are a little
more sophisticated than just a single sound card and configuring
these can be PITA when you don't have PA.
That these setups exist is completely fine. That the additional
PulseAudio layer is being imposed even on systems that have a single
sound card, is not.

Samuel
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@type.bordeaux.inria.fr
John Paul Adrian Glaubitz
2013-07-17 09:13:37 UTC
Permalink
Post by Samuel Thibault
That these setups exist is completely fine. That the additional
PulseAudio layer is being imposed even on systems that have a single
sound card, is not.
Unless your PC was made in 1995, I am pretty sure it has one of these
"advanced" setups. Secondly, I am not seeing PA imposed onto anyone,
it's just the default setup as it's the sensible choice for installation
on a modern desktop.

If you don't like it, uninstall it.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Samuel Thibault
2013-07-17 09:20:48 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Samuel Thibault
That these setups exist is completely fine. That the additional
PulseAudio layer is being imposed even on systems that have a single
sound card, is not.
Unless your PC was made in 1995, I am pretty sure it has one of these
"advanced" setups. Secondly, I am not seeing PA imposed onto anyone,
It's getting pulled through various packages.
Post by John Paul Adrian Glaubitz
If you don't like it, uninstall it.
It becomes more and more difficult to do it.

Samuel
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@type.bordeaux.inria.fr
Holger Levsen
2013-07-17 10:04:24 UTC
Permalink
Hi,

On Mittwoch, 17. Juli 2013, Samuel Thibault wrote:
[PA]
Post by Samuel Thibault
It's getting pulled through various packages.
same with bluetooth
Post by Samuel Thibault
Post by John Paul Adrian Glaubitz
If you don't like it, uninstall it.
It becomes more and more difficult to do it.
same with bluetooth

I don't use bluetooth, I don't want the bluetooth stack installed but yet I do
see how this is a sensible thing to install with the default desktop. Same
with PA I'd say.


cheers,
Holger

Steve Langasek
2013-07-15 18:19:15 UTC
Permalink
Post by Thomas Goirand
If OpenRC goes up to the shape I expect, it will have a huge advantage
over systemd and Upstart: it will not be controversial,
That's not true at all.
Post by Thomas Goirand
throwing away non-Linux ports, and taking over the whole of the system.
It will just be an improvement, and that's it.
It will be a minor improvement that does nothing to address the problems
with sysvinit that upstart and systemd aim to solve, which means
implementing it in Debian will be a waste of our time and distract from
solving the real problems.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Thomas Goirand
2013-07-16 01:17:58 UTC
Permalink
Post by Steve Langasek
Post by Thomas Goirand
If OpenRC goes up to the shape I expect, it will have a huge advantage
over systemd and Upstart: it will not be controversial,
That's not true at all.
Post by Thomas Goirand
throwing away non-Linux ports, and taking over the whole of the system.
It will just be an improvement, and that's it.
It will be a minor improvement that does nothing to address the problems
with sysvinit that upstart and systemd aim to solve
Like?

Thomas
Gergely Nagy
2013-07-16 08:30:49 UTC
Permalink
Post by Thomas Goirand
If OpenRC goes up to the shape I expect, it will have a huge advantage
over systemd and Upstart: it will not be controversial,
If it would not be controversial, we wouldn't have this conversation
about whether it is worth it at all. Just saying.
--
|8]
Thomas Goirand
2013-07-16 09:36:53 UTC
Permalink
Post by Gergely Nagy
Post by Thomas Goirand
If OpenRC goes up to the shape I expect, it will have a huge advantage
over systemd and Upstart: it will not be controversial,
If it would not be controversial, we wouldn't have this conversation
about whether it is worth it at all. Just saying.
What I was saying was that the upgrade to sysv-rc to OpenRC should be an
improvement, and that's it. Nothing should break in the process, and
nothing else than the init process will be affected. While with systemd
lots of components are affected, and with both Upstart and Systemd,
non-Linux wont be supported. That's why I was saying it would be a less
controversial choice.

However, I denied that there's a big controversy going on on this list! :)

Thomas
Thomas Goirand
2013-07-16 11:35:45 UTC
Permalink
Post by Thomas Goirand
However, I denied that there's a big controversy going on on this list! :)
Everybody understood: of course, there's a heated debate.

Thomas
Ben Hutchings
2013-07-15 00:56:48 UTC
Permalink
Post by David Kalnischkies
On Sun, Jul 14, 2013 at 10:57 AM, John Paul Adrian Glaubitz
Post by Thomas Goirand
These aren't the only viable option and you know it. FYI, OpenRC port to
Debian is doing well, and it is already able to boot a Debian system
- support for update-rc.d
- support for invoke-rc.d
- finish the init.d script compatibility (not much remaining to do)
- make it work with an unmodified /etc/inittab
- add support for X-Start-Before (that might be the hardest part)
OpenRC has already been discussed for Debian for over a year, it's still not
fully ported and working, yet you claim the port is doing well.
Are you seriously expecting anyone to use such a patch work on a productive
machine?
At least I am seriously expecting that Debian isn't discarding the outcome
of a project it has officially endorsed to be under its umbrella for GSoC
without even the slightest bit of consideration.
[...]

GSoC Debian projects are not 'officially endorsed by Debian'. So far as
I understand it, they are supported by at least one DD (proposer and
mentor, may be the same person) and accepted by the GSoC coordinator;
that's all. And they can be quite experimental, which is OK so long as
the project in general recognises that.

Neither do John or Marco speak for Debian, so nothing has been discarded
yet.

Ben.
--
Ben Hutchings
Humans are not rational beings; they are rationalising beings.
David Kalnischkies
2013-07-15 08:45:23 UTC
Permalink
Post by Ben Hutchings
Post by David Kalnischkies
On Sun, Jul 14, 2013 at 10:57 AM, John Paul Adrian Glaubitz
Post by Thomas Goirand
These aren't the only viable option and you know it. FYI, OpenRC port to
Debian is doing well, and it is already able to boot a Debian system
- support for update-rc.d
- support for invoke-rc.d
- finish the init.d script compatibility (not much remaining to do)
- make it work with an unmodified /etc/inittab
- add support for X-Start-Before (that might be the hardest part)
OpenRC has already been discussed for Debian for over a year, it's still not
fully ported and working, yet you claim the port is doing well.
Are you seriously expecting anyone to use such a patch work on a productive
machine?
At least I am seriously expecting that Debian isn't discarding the outcome
of a project it has officially endorsed to be under its umbrella for GSoC
without even the slightest bit of consideration.
[...]
GSoC Debian projects are not 'officially endorsed by Debian'. So far as
I understand it, they are supported by at least one DD (proposer and
mentor, may be the same person) and accepted by the GSoC coordinator;
that's all.
Having Delegates working on it makes it sound pretty official, but I agree
that I have worded it a bit (too) strong in an ill attempt to match the style
of the sentence above. Sorry for that.


Best regards

David Kalnischkies
Thomas Goirand
2013-07-14 14:03:18 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Thomas Goirand
These aren't the only viable option and you know it. FYI, OpenRC port to
Debian is doing well, and it is already able to boot a Debian system
- support for update-rc.d
- support for invoke-rc.d
- finish the init.d script compatibility (not much remaining to do)
- make it work with an unmodified /etc/inittab
- add support for X-Start-Before (that might be the hardest part)
OpenRC has already been discussed for Debian for over a year, it's still
not fully ported and working, yet you claim the port is doing well.
Are you seriously expecting anyone to use such a patch work on a
productive machine?
I'm mentoring the GSoC port, and yes, it's doing well: there is
improvements every week. I was impressed last time I tried by what has
been done.
Post by John Paul Adrian Glaubitz
The difference is, however, systemd is already there, has matured and a
strong upstream community. Why should we settle for something which
doesn't even have a foreseeable future of upstream maintainership?
Ah... So you believe Gentoo will die? Interesting view point!

Thomas
Steve Langasek
2013-07-15 17:11:31 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Thomas Goirand
You also wrote more or less that systemd is the only way to support
cgroups, while this is untrue. OpenRC at least has support for it (and
probably upstart too? I'm not sure...), and it also builds on FreeBSD
(not yet Debian kFreeBSD, but that also should be easy to fix). The
argument that to support modern things like cgroups, an init system has
to be incompatible with anything else than Linux is just simply false.
upstart is (or is going to use) the prctl Linux system call and
therefore no longer compatible with non-Linux kernels.
Not sure where this idea comes from. upstart has never supported non-Linux
kernels; we're open to it being ported to other kernels, but prctl is a
minor detail for kernel compatibility compared with other, more significant
features that upstart relies on.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
John Paul Adrian Glaubitz
2013-07-15 17:48:22 UTC
Permalink
Post by Steve Langasek
Not sure where this idea comes from. upstart has never supported non-Linux
kernels; we're open to it being ported to other kernels, but prctl is a
minor detail for kernel compatibility compared with other, more significant
features that upstart relies on.
I am pretty sure you wrote it yourself in [1]:

"By making use of a Linux-specific prctl(2) call, we effectively tie
Upstart to systems running with a Linux kernel. This is a major
restriction, but porting to other systems is already complicated by the
fact that even the BSDs do not provide a full POSIX environment (missing
"waitid(2)" for example)."

Cheers,

Adrian
Post by Steve Langasek
[1]
https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Disadvantages
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Steve Langasek
2013-07-15 18:13:53 UTC
Permalink
Post by John Paul Adrian Glaubitz
Post by Steve Langasek
Not sure where this idea comes from. upstart has never supported non-Linux
kernels; we're open to it being ported to other kernels, but prctl is a
minor detail for kernel compatibility compared with other, more significant
features that upstart relies on.
"By making use of a Linux-specific prctl(2) call, we effectively tie
Upstart to systems running with a Linux kernel. This is a major
restriction, but porting to other systems is already complicated by
the fact that even the BSDs do not provide a full POSIX environment
(missing "waitid(2)" for example)."
[1] https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Disadvantages
These are not my words. :) One can discuss whether this constitutes a
"major" restriction, but in any case this only pertains to the use of
upstart for user session management which is not what's being discussed
here.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Kevin Chadwick
2013-07-14 19:19:58 UTC
Permalink
Post by Michael Stapelberg
since some people might not read planet debian, here is a link to my
third blog post in a series of posts dealing with the results of the
Well I am behind on my mailing list reading just at the time when it
matters for my concerns for debian. I disagree with many of the points
roger has/atleast had settled on for merging /usr and especially
discounting arguments but haven't had time to collate them and formulate
a comprehensive response as I had planned and unfortunately my care
for Linux is diminishing daily.

I certainly wouldn't run systemd on any of our systems including
production systems or products and in fact could never run it on some
of our embedded products because it is simply too resource hungry.

What this survey that I have only just heard about after the fact and
don't know how the questions were put has pointed out to me is that
there are many very clever devs who disagree with the so-called
majority () and have very valid reasons against systemd. It is also of
such low total participants that it should be discarded on that alone.

What percentage would be perfectly happy with sticking to a simple and
standard script based system? Probably a far higher percentage, after
all anything useful systemd can do, a script based system like openrc
and optional daemons can do.

It is a far better and prove more workable and less problematic default
for corner case and controversial features (almost all of systemd can be
put under that category) that increase complexity and the number of
lines of code to be optionally installable such as monit, redundant
systems and carp or nagios for user access uptime than to make users
work backwards.

p.s. I haven't the time to talk about or even recollect a 20th of the
problems that systemd poses which should be enough for anyone to say
hang on, what is this mess, it is obviously not optimal or very
close to suitable for all as any init system should and always
has rightly been.

What do you really lose by sticking with a script based system,
potentially nothing is the point.

P.s. whenever I hear someone talk about Linux and Modern it is simply
proving to show that commenter's inexperience. Only idiots *require*
cgroups or parallelisation the latter being only required/beneficial
when the fastest bootup is required, which is almost never the case else
bioses wouldn't conduct post tests or memory checks.
--
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________
Russ Allbery
2013-07-14 20:04:45 UTC
Permalink
Post by Kevin Chadwick
P.s. whenever I hear someone talk about Linux and Modern it is simply
proving to show that commenter's inexperience. Only idiots *require*
cgroups or parallelisation the latter being only required/beneficial
when the fastest bootup is required, which is almost never the case else
bioses wouldn't conduct post tests or memory checks.
I've been administering UNIX systems professionally for 20 years, from
SunOS and ULTRIX through AIX, HP-UX, IRIX, Solaris, and Linux. In my
professional, *experienced* opinion, proper deployment of a modern init
system will make Debian considerably more robust, simpler to develop, and
simpler to administer.

You are certainly entitled to disagree. There are valid reasons for
disagreement, which mostly amount to the weights that one puts on
different possible risks. But it is simply not the case that everyone who
disagrees with you is simply an idiot.

This is the wrong mailing list to try to make an argument from personal
authority. There are many people here who have just as much experience as
you do, if not more, and are not going to be impressed by your assertions
of expertise.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
Henrique de Moraes Holschuh
2013-07-15 19:50:18 UTC
Permalink
Post by Russ Allbery
I've been administering UNIX systems professionally for 20 years, from
SunOS and ULTRIX through AIX, HP-UX, IRIX, Solaris, and Linux. In my
professional, *experienced* opinion, proper deployment of a modern init
system will make Debian considerably more robust, simpler to develop, and
simpler to administer.
How much of that improvement would be realised if we added a dependable,
declarative (i.e. config-based instead of shell-script-based) service
configuration support to sysvinit ?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Russ Allbery
2013-07-15 20:08:20 UTC
Permalink
Post by Henrique de Moraes Holschuh
How much of that improvement would be realised if we added a dependable,
declarative (i.e. config-based instead of shell-script-based) service
configuration support to sysvinit ?
Some, mostly on the maintenance side. I think the major short-term win is
eliminating the massive amounts of buggy shell boilerplate that make up a
typical init script, most of which are only trying to do something fairly
simple and easily describable in a declarative syntax.

However, that doesn't help with early boot ordering (for which you need
deep integration with kernel events), with boot speed and parallelization
(we made a lot of improvements with the dash switch and with our current
parallelization, but we can better), with tracking daemon processes and
getting rid of the fragile and annoying PID file dances or process table
searches, or, probably most significant in the long run, socket
activation. It mostly just helps Debian maintainers write better init
scripts, but it doesn't reposition us to take advantage of innovation in
daemon management and control.

That innovation is a big deal. The way we're handling daemons right now
is awful, and I think a lot of people don't realize it just because
they've never had experience with something better.

For example, here at Stanford, we've been using daemontools since shortly
after djb originally wrote it to manage many of the cases that init
scripts do an awful job at, and that experience has taught me just how bad
of a job init scripts do for a lot of common use cases. My coworkers spin
up new daemontools /service scripts all the time, and grumble mightily
when they have to write an init script instead because a /service script
won't work for some reason. It makes a huge difference. But daemontools
has a bunch of its own problems (as does runit) and are not general
replacements. systemd and upstart both do everything useful that those
tools do and much more.

This is something that's also been independently understood by other UNIX
vendors. For example, one of the major overhauls in Solaris 10 was
building in this sort of management framework for daemons, and (like a lot
of Solaris innovations) the idea was quite solid, even if the
implementation (XML, ew) was dubious. And of course Mac OS X has had
launchd for quite some time, which isn't quite as comprehensive of a
solution, but tackles some of the same problems.

Basically, Debian is seriously behind the curve on this, but we're so used
to our familiar, comfortable problems that we don't necessarily see the
amount of pain that we're enduring that we don't have to endure. As
Charles noted elsewhere on this thread, once you start looking at and
maintaining either systemd or upstart configurations instead of init
scripts, you realize what sort of rock you were beating your head against
and how nice it feels for the pain to stop.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
John Paul Adrian Glaubitz
2013-07-15 20:13:02 UTC
Permalink
Post by Henrique de Moraes Holschuh
How much of that improvement would be realised if we added a dependable,
declarative (i.e. config-based instead of shell-script-based) service
configuration support to sysvinit ?
You can't trivially add these features to sysvinit without fundamentally
rewriting it. systemd uses many modern Linux kernel features and system
calls which means you would have to use these features in a rewritten
sysvinit as well to be able to provide the reliability and features
of systemd which means you'd loose the portability again.

Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - ***@debian.org
`. `' Freie Universitaet Berlin - ***@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Stig Sandbeck Mathisen
2013-07-15 20:17:08 UTC
Permalink
Post by Henrique de Moraes Holschuh
Post by Russ Allbery
I've been administering UNIX systems professionally for 20 years,
from SunOS and ULTRIX through AIX, HP-UX, IRIX, Solaris, and Linux.
In my professional, *experienced* opinion, proper deployment of a
modern init system will make Debian considerably more robust, simpler
to develop, and simpler to administer.
How much of that improvement would be realised if we added a
dependable, declarative (i.e. config-based instead of
shell-script-based) service configuration support to sysvinit ?
The "declarative configuration" part, of course. :)
--
Stig Sandbeck Mathisen (…who really could not resist)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@dagon.fnord.no
Roger Leigh
2013-07-14 20:38:50 UTC
Permalink
Post by Kevin Chadwick
Post by Michael Stapelberg
since some people might not read planet debian, here is a link to my
third blog post in a series of posts dealing with the results of the
Well I am behind on my mailing list reading just at the time when it
matters for my concerns for debian. I disagree with many of the points
roger has/atleast had settled on for merging /usr and especially
discounting arguments but haven't had time to collate them and formulate
a comprehensive response as I had planned
Assuming you're referring to myself, I'd certainly be happy to discuss
any of this--feel free to mail me privately if you like.

I don't think that we agreed on merging /usr at all. I have written
some patches for initramfs-tools to permit fsck and mount of /usr
in the initramfs in addition to the rootfs, but that's as far as this
has gone. There's no merging here, just changing where /usr is
mounted in the boot process.

I'll be happy to consider anything you want to raise in more detail;
nothing as yet has been changed, and there's certainly plenty of time
to revise things.


Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Paul Wise
2013-07-16 15:37:09 UTC
Permalink
Post by Roger Leigh
I don't think that we agreed on merging /usr at all. I have written
some patches for initramfs-tools to permit fsck and mount of /usr
in the initramfs in addition to the rootfs, but that's as far as this
has gone. There's no merging here, just changing where /usr is
mounted in the boot process.
Is this implemented by just mounting /usr, by discovering which
partitions need mounting for each binary that is to be run from the
initramfs or by copying stuff from /usr into the initramfs too?
--
bye,
pabs

http://wiki.debian.org/PaulWise
Roger Leigh
2013-07-16 16:07:39 UTC
Permalink
Post by Paul Wise
Post by Roger Leigh
I don't think that we agreed on merging /usr at all. I have written
some patches for initramfs-tools to permit fsck and mount of /usr
in the initramfs in addition to the rootfs, but that's as far as this
has gone. There's no merging here, just changing where /usr is
mounted in the boot process.
Is this implemented by just mounting /usr, by discovering which
partitions need mounting for each binary that is to be run from the
initramfs or by copying stuff from /usr into the initramfs too?
Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr
using that information. When init starts, /usr is therefore
available from the beginning. Note that the objective here isn't
to allow the initramfs to run binaries from /usr, but to ensure
that /usr is available at all times when the system is running--
this means that all programs, libraries, modules, datafiles etc.
are available before init starts.

There are some complicating details:
- we need to ensure that the modules needed to mount /usr are
available in the initramfs (copy the needed modules and
mount helpers into the initramfs)
- we can't fsck /usr when mounted, so this needs doing in the
initramfs (/ and /usr are fscked, with the appropriate
helpers copied into the initramfs)
- fsck's -R option updated to skip /usr as well as root.
- /etc/init.d/checkroot.sh updated to handle /usr as well
as root (e.g. remounting r/w).

- using the same infrastructure, it's also possible to
mount /etc in the initramfs so that you can have e.g. a
separately encrypted /etc filesystem. This is a separate
feature though and can be split out.


Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Dmitrijs Ledkovs
2013-07-16 17:38:18 UTC
Permalink
Post by Roger Leigh
Post by Paul Wise
Post by Roger Leigh
I don't think that we agreed on merging /usr at all. I have written
some patches for initramfs-tools to permit fsck and mount of /usr
in the initramfs in addition to the rootfs, but that's as far as this
has gone. There's no merging here, just changing where /usr is
mounted in the boot process.
Is this implemented by just mounting /usr, by discovering which
partitions need mounting for each binary that is to be run from the
initramfs or by copying stuff from /usr into the initramfs too?
Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr
using that information. When init starts, /usr is therefore
available from the beginning. Note that the objective here isn't
to allow the initramfs to run binaries from /usr, but to ensure
that /usr is available at all times when the system is running--
this means that all programs, libraries, modules, datafiles etc.
are available before init starts.
- we need to ensure that the modules needed to mount /usr are
available in the initramfs (copy the needed modules and
mount helpers into the initramfs)
- we can't fsck /usr when mounted, so this needs doing in the
initramfs (/ and /usr are fscked, with the appropriate
helpers copied into the initramfs)
- fsck's -R option updated to skip /usr as well as root.
- /etc/init.d/checkroot.sh updated to handle /usr as well
as root (e.g. remounting r/w).
Up to here, all sounds good.

Making the $mountpoints which above are treated / mounted in
initramfs, makes sense.
To be able to default to "/" only and change to "/ and /usr" if one desires.
And even plugin in the feature below.
Post by Roger Leigh
- using the same infrastructure, it's also possible to
mount /etc in the initramfs so that you can have e.g. a
separately encrypted /etc filesystem. This is a separate
feature though and can be split out.
Imho the overhead between having just "/etc" vs "/" encrypted is
small, if "/var", "/usr", "/home", "/opt" are separate mountpoints.
Thus to me, treating "/etc" separately is a misfeature, considering a
mounted "/" assumes /etc must be present.
At least, it would go against my expectation.

I haven't yet reviewed the 17 patches log patch series on [1]. But is
"/etc" handling clearly separated in it already, or some
rebasing/reshuffling needed?

Regards,

Dmitrijs.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459
Roger Leigh
2013-07-16 18:39:45 UTC
Permalink
Post by Dmitrijs Ledkovs
Post by Roger Leigh
Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr
using that information. When init starts, /usr is therefore
available from the beginning. Note that the objective here isn't
to allow the initramfs to run binaries from /usr, but to ensure
that /usr is available at all times when the system is running--
this means that all programs, libraries, modules, datafiles etc.
are available before init starts.
- we need to ensure that the modules needed to mount /usr are
available in the initramfs (copy the needed modules and
mount helpers into the initramfs)
- we can't fsck /usr when mounted, so this needs doing in the
initramfs (/ and /usr are fscked, with the appropriate
helpers copied into the initramfs)
- fsck's -R option updated to skip /usr as well as root.
- /etc/init.d/checkroot.sh updated to handle /usr as well
as root (e.g. remounting r/w).
Up to here, all sounds good.
Making the $mountpoints which above are treated / mounted in
initramfs, makes sense.
To be able to default to "/" only and change to "/ and /usr" if one desires.
And even plugin in the feature below.
Post by Roger Leigh
- using the same infrastructure, it's also possible to
mount /etc in the initramfs so that you can have e.g. a
separately encrypted /etc filesystem. This is a separate
feature though and can be split out.
Imho the overhead between having just "/etc" vs "/" encrypted is
small, if "/var", "/usr", "/home", "/opt" are separate mountpoints.
Thus to me, treating "/etc" separately is a misfeature, considering a
mounted "/" assumes /etc must be present.
At least, it would go against my expectation.
This is certainly the case at present. The rationale for doing this
is that if you have / and /usr on a single filesystem, but you want
to encrypt the content of /etc, you can now encrypt just /etc. It
also means you can have the rootfs read-only with a writable /etc,
have /etc as a writable overlay or separate fs on a common image for
cluster environments, etc. For encrypting stuff, it's moving the
boundary from one of simple convienience (/usr) to where it's actually
needed. But I can accept that this won't have universal appeal.
Post by Dmitrijs Ledkovs
I haven't yet reviewed the 17 patches log patch series on [1]. But is
"/etc" handling clearly separated in it already, or some
rebasing/reshuffling needed?
It's just patch number 11/17 with some minor documentation comments in
patch 12/17, so it can be easily dropped without problems (intentionally).
However, even if applied, it's a strictly optional feature that won't be
used by default unless you provide etc= options to match the root=
options on the kernel command-line.


Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Dmitrijs Ledkovs
2013-07-16 20:42:00 UTC
Permalink
Post by Roger Leigh
Post by Dmitrijs Ledkovs
Post by Roger Leigh
Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr
using that information. When init starts, /usr is therefore
available from the beginning. Note that the objective here isn't
to allow the initramfs to run binaries from /usr, but to ensure
that /usr is available at all times when the system is running--
this means that all programs, libraries, modules, datafiles etc.
are available before init starts.
- we need to ensure that the modules needed to mount /usr are
available in the initramfs (copy the needed modules and
mount helpers into the initramfs)
- we can't fsck /usr when mounted, so this needs doing in the
initramfs (/ and /usr are fscked, with the appropriate
helpers copied into the initramfs)
- fsck's -R option updated to skip /usr as well as root.
- /etc/init.d/checkroot.sh updated to handle /usr as well
as root (e.g. remounting r/w).
Up to here, all sounds good.
Making the $mountpoints which above are treated / mounted in
initramfs, makes sense.
To be able to default to "/" only and change to "/ and /usr" if one desires.
And even plugin in the feature below.
Post by Roger Leigh
- using the same infrastructure, it's also possible to
mount /etc in the initramfs so that you can have e.g. a
separately encrypted /etc filesystem. This is a separate
feature though and can be split out.
Imho the overhead between having just "/etc" vs "/" encrypted is
small, if "/var", "/usr", "/home", "/opt" are separate mountpoints.
Thus to me, treating "/etc" separately is a misfeature, considering a
mounted "/" assumes /etc must be present.
At least, it would go against my expectation.
This is certainly the case at present. The rationale for doing this
is that if you have / and /usr on a single filesystem, but you want
to encrypt the content of /etc, you can now encrypt just /etc. It
also means you can have the rootfs read-only with a writable /etc,
have /etc as a writable overlay or separate fs on a common image for
cluster environments, etc. For encrypting stuff, it's moving the
boundary from one of simple convienience (/usr) to where it's actually
needed. But I can accept that this won't have universal appeal.
Thinking about it more, it's possibly not the encryption case which
might be most prominent here.
I have seen containers / images made readonly, with /etc mounted using
overlayfs to provide easily clonable machines (chroots,
lxc-containers, "cloud-images").
Not sure, but probably, capser was used to do the mounting there.
Post by Roger Leigh
Post by Dmitrijs Ledkovs
I haven't yet reviewed the 17 patches log patch series on [1]. But is
"/etc" handling clearly separated in it already, or some
rebasing/reshuffling needed?
It's just patch number 11/17 with some minor documentation comments in
patch 12/17, so it can be easily dropped without problems (intentionally).
However, even if applied, it's a strictly optional feature that won't be
used by default unless you provide etc= options to match the root=
options on the kernel command-line.
Ok, thanks for the heads up.

Regards,

Dmitrijs.
Helmut Grohne
2013-07-16 19:15:39 UTC
Permalink
Post by Dmitrijs Ledkovs
Imho the overhead between having just "/etc" vs "/" encrypted is
small, if "/var", "/usr", "/home", "/opt" are separate mountpoints.
Thus to me, treating "/etc" separately is a misfeature, considering a
mounted "/" assumes /etc must be present.
At least, it would go against my expectation.
Having /etc on a separate filesystem can have a different advantage. If
just /var and /home are on separate filesystems and RAMTMP is set to
yes, then / can possibly be mounted read-only. Having a read-only /etc
is still a difficult thing to do, because a number of packages assume it
to be writeable. Examples include cups, denyhosts, fake-hwclock, lvm2,
openvpn, passwd, samba, and util-linux. This list is not exhaustive.

I think that read-only / is an interesting feature to investigate.
Fixing all the packages above has been proven to be a hard thing to do.
Having a writeable /etc is different way to achieve the same thing, so I
think investigating that option should not be prematurely dismissed.

It is not like that the availability of this feature will suddenly make
everyone use it. Chances are you wouldn't notice when it is introduced.
So why complain?

Helmut
Steve Langasek
2013-07-16 18:25:42 UTC
Permalink
Post by Roger Leigh
- using the same infrastructure, it's also possible to
mount /etc in the initramfs so that you can have e.g. a
separately encrypted /etc filesystem. This is a separate
feature though and can be split out.
This reflects poorly on the infrastructure in question. Handling /etc as a
separate filesystem from /, aside from not being a feature anyone else
has asked for and not being a requirement for reducing deltas with upstreams
/ other distros, implies that the initramfs has to have a copy of the
information from /etc/fstab. This is *not* how this should be handled. The
initramfs should take the information about the root filesystem from the
kernel commandline, and its information about /usr from /etc/fstab *on the
root filesystem once it has been mounted*.

Anything else is a wrong design.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Roger Leigh
2013-07-16 19:06:27 UTC
Permalink
Post by Steve Langasek
Post by Roger Leigh
- using the same infrastructure, it's also possible to
mount /etc in the initramfs so that you can have e.g. a
separately encrypted /etc filesystem. This is a separate
feature though and can be split out.
This reflects poorly on the infrastructure in question.
I'm merely referring to the generalisation of the local/nfs
scripts to allow mounting of arbitrary filesystems. There's
nothing wrong with this this support code.
Post by Steve Langasek
Handling /etc as a
separate filesystem from /, aside from not being a feature anyone else
has asked for and not being a requirement for reducing deltas with upstreams
/ other distros, implies that the initramfs has to have a copy of the
information from /etc/fstab. This is *not* how this should be handled.
I certainly didn't mean to imply this, because this is not what
is being done here. Nothing is stored in the initramfs.
Post by Steve Langasek
The
initramfs should take the information about the root filesystem from the
kernel commandline, and its information about /usr from /etc/fstab *on the
root filesystem once it has been mounted*.
Anything else is a wrong design.
We certainly do this for / and /usr.

The information for mounting /etc is passed on the kernel command-line
exactly as for the rootfs; while I've so far only tested it by hand,
tools such as update-grub could potentially add it in the same way
they handle the rootfs, if such a feature was in use.

Note that this part was merely added as a proposal only as a
demonstration of what could be done /if this was desirable to have/.
If not, then it can be dropped. It was included solely that it could
be reviewed.


Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Marco d'Itri
2013-07-17 08:37:06 UTC
Permalink
Post by Steve Langasek
This reflects poorly on the infrastructure in question. Handling /etc as a
separate filesystem from /, aside from not being a feature anyone else
has asked for and not being a requirement for reducing deltas with upstreams
/ other distros, implies that the initramfs has to have a copy of the
information from /etc/fstab. This is *not* how this should be handled. The
I have said so from the beginning...
This does not solve any real life problem and only causes useless
discussions from people who understandably do not see the point.
--
ciao,
Marco
Steve Langasek
2013-07-16 18:28:28 UTC
Permalink
Post by Roger Leigh
Post by Paul Wise
Post by Roger Leigh
I don't think that we agreed on merging /usr at all. I have written
some patches for initramfs-tools to permit fsck and mount of /usr
in the initramfs in addition to the rootfs, but that's as far as this
has gone. There's no merging here, just changing where /usr is
mounted in the boot process.
Is this implemented by just mounting /usr, by discovering which
partitions need mounting for each binary that is to be run from the
initramfs or by copying stuff from /usr into the initramfs too?
Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr
using that information. When init starts, /usr is therefore
available from the beginning. Note that the objective here isn't
to allow the initramfs to run binaries from /usr, but to ensure
that /usr is available at all times when the system is running--
this means that all programs, libraries, modules, datafiles etc.
are available before init starts.
- we need to ensure that the modules needed to mount /usr are
available in the initramfs (copy the needed modules and
mount helpers into the initramfs)
Yes.
Post by Roger Leigh
- we can't fsck /usr when mounted, so this needs doing in the
initramfs (/ and /usr are fscked, with the appropriate
helpers copied into the initramfs)
I think this is a bug in e2fsprogs for treating / specially wrt fsck after
mount. We should fix this in e2fsprogs, not work around it by changing the
semantics of fsck-at-boot.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Roger Leigh
2013-07-16 19:10:53 UTC
Permalink
Post by Steve Langasek
Post by Roger Leigh
- we can't fsck /usr when mounted, so this needs doing in the
initramfs (/ and /usr are fscked, with the appropriate
helpers copied into the initramfs)
I think this is a bug in e2fsprogs for treating / specially wrt fsck after
mount. We should fix this in e2fsprogs, not work around it by changing the
semantics of fsck-at-boot.
I certainly support this point of view. However, the scope of the
required changes isn't immediately clear to me. We might potentially
need to patch every single fsck program; e2fsck is sort-of patchable
but Ted wasn't happy with the idea. And worse, we have to deal with
btrfs, which currently isn't fsckable if mounted *at all*, let alone
read-only /. While I live in the hope that one day btrfs will be
sane, I won't be holding my breath.


Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Thijs Kinkhorst
2013-07-15 08:03:02 UTC
Permalink
my care for Linux is diminishing daily.
p.s. I haven't the time to talk about or even recollect a 20th of the
problems that systemd poses
P.s. whenever I hear someone talk about Linux and Modern it is simply
proving to show that commenter's inexperience. Only idiots
If you do not really care about the subject, do not have time to write up
arguments but do have time to attack others, please save yourself the
effort of posting.


Thijs
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@aphrodite.kinkhorst.nl
Josselin Mouette
2013-07-15 08:32:44 UTC
Permalink
Post by Kevin Chadwick
I certainly wouldn't run systemd on any of our systems including
production systems or products and in fact could never run it on some
of our embedded products because it is simply too resource hungry.
If you have requirements that are so low that the systemd memory
footprint is a problem, you should probably switch away from Linux and
definitely switch away from Debian. We do not practically support
systems with less than 256 MiB of memory.
Post by Kevin Chadwick
It is a far better and prove more workable and less problematic default
for corner case and controversial features (almost all of systemd can be
put under that category) that increase complexity and the number of
lines of code to be optionally installable such as monit, redundant
systems and carp or nagios for user access uptime than to make users
work backwards.
What you do not understand is that systemd dramatically *reduces*
complexity.
Post by Kevin Chadwick
p.s. I haven't the time to talk about or even recollect a 20th of the
problems that systemd poses which should be enough for anyone to say
hang on, what is this mess, it is obviously not optimal or very
close to suitable for all as any init system should and always
has rightly been.
“We’ve been doing things this way for 30 years, and it never was a
problem!”
You know, I hear this sentence a lot. People who don’t want to migrate
from rsh to ssh despite the reduced user-level complexity. People who
don’t want to automate deployment because they already have a huge stack
of buggy scripts that often works.

And now people who want to stick with buggy shell scripts instead of
migrating to a much simpler, declarative mechanism.

Change resistance is normal. There is a cost to any change, and
questioning it is fine. But if we never actually did any change, we
would be stuck with Multics.
Post by Kevin Chadwick
P.s. whenever I hear someone talk about Linux and Modern it is simply
proving to show that commenter's inexperience. Only idiots *require*
cgroups or parallelisation the latter being only required/beneficial
when the fastest bootup is required, which is almost never the case else
bioses wouldn't conduct post tests or memory checks.
Systemd was not written to reduce boot time. It was written to handle
the boot process *correctly*. Reducing the boot time is a nice
side-effect for teenagers, but it was never the point.

Cgroups are not used to improve the boot time - and I’m pretty sure they
actually delay the boot process. They are used to put each daemon and
each user session in a container that can be throughly cleaned up when
needed, which is a giant step forwards in terms of reliability.

Parallelisation is not something new in systemd: we already have it in
Debian with insserv. And just like with insserv (which uses declarative
fields too, see how that makes things better), it is just a side-effect
of having done things more correctly.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@pi0307572
Thomas Goirand
2013-07-15 18:19:47 UTC
Permalink
Post by Josselin Mouette
And now people who want to stick with buggy shell scripts instead of
migrating to a much simpler, declarative mechanism.
Please point at a single person on any threads about init systems over
the last year who wishes that. I haven't see any. Did I miss it?

Thomas
Florian Weimer
2013-07-16 19:26:28 UTC
Permalink
Post by Thomas Goirand
Post by Josselin Mouette
And now people who want to stick with buggy shell scripts instead of
migrating to a much simpler, declarative mechanism.
Please point at a single person on any threads about init systems over
the last year who wishes that. I haven't see any. Did I miss it?
Actually, this is a fairly common sentiment. Here's an example I
could locate quickly:

<http://lists.debian.org/debian-devel/2012/03/msg00610.html>

(And yes, I believe there are more recent examples.)
Ondřej Surý
2013-07-15 09:27:22 UTC
Permalink
On Sat, Jul 13, 2013 at 11:46 PM, Michael Stapelberg
Post by Michael Stapelberg
Hi,
since some people might not read planet debian, here is a link to my
third blog post in a series of posts dealing with the results of the
http://people.debian.org/~stapelberg/2013/07/13/systemd-not-portable.html
Just a quick idea:

Can we (the mysterious somebody) write a drop-in simple dummy init.d script
which would take a(ny) systemd service file and run the daemon on
non-Linux-kernel systems?

That would reduce complexity for most packages. The maintainers could stay
with handwritten shell scripts if the init.d script is more complex, but I
suspect that it would be ok for most packages to just have a simple
compatibility layer on top of systemd service files.

O.
--
Ondřej SurÃœ <***@sury.org>
Arto Jantunen
2013-07-15 10:10:48 UTC
Permalink
Post by Ondřej Surý
Can we (the mysterious somebody) write a drop-in simple dummy init.d script
which would take a(ny) systemd service file and run the daemon on
non-Linux-kernel systems?
This has been discussed several times, there was even a GSoC project to
implement a systemd service -> init script converter (essentially
providing the same thing). Sadly this isn't even nearly as simple as it
sounds. The systemd service files are simple to write exactly since the
magic has been moved from them into the daemon, this converter or
wrapper needs to implement all of that for this to work.

To me it seems that porting the whole thing might actually be simpler,
considering that you'll still need to solve the process tracking issue
either way (this is what systemd needs cgroups for).
--
Arto Jantunen
Ondřej Surý
2013-07-15 11:51:02 UTC
Permalink
Post by Thomas Goirand
Post by Ondřej Surý
Can we (the mysterious somebody) write a drop-in simple dummy init.d
script
Post by Ondřej Surý
which would take a(ny) systemd service file and run the daemon on
non-Linux-kernel systems?
This has been discussed several times, there was even a GSoC project to
implement a systemd service -> init script converter (essentially
providing the same thing). Sadly this isn't even nearly as simple as it
sounds. The systemd service files are simple to write exactly since the
magic has been moved from them into the daemon, this converter or
wrapper needs to implement all of that for this to work.
I think this task is majestic only if you setup a goal of supporting every
stanzas in systemd files.

But If I look at .service files in my packages, I need to have support only
for:

ExecStartPre, ExecStart, PidFile and Reload

The insserv headers might be written by hand.

O.
--
Ondřej SurÃœ <***@sury.org>
Arto Jantunen
2013-07-15 12:32:42 UTC
Permalink
Please don't CC me, I read the list.
Post by Ondřej Surý
Post by Arto Jantunen
This has been discussed several times, there was even a GSoC project to
implement a systemd service -> init script converter (essentially
providing the same thing). Sadly this isn't even nearly as simple as it
sounds. The systemd service files are simple to write exactly since the
magic has been moved from them into the daemon, this converter or
wrapper needs to implement all of that for this to work.
I think this task is majestic only if you setup a goal of supporting every
stanzas in systemd files.
But If I look at .service files in my packages, I need to have support only
ExecStartPre, ExecStart, PidFile and Reload
The insserv headers might be written by hand.
In addition to that the wrapper also needs to be able to track the
processes started by the systemd service (the admin might want to stop
or restart services in addition to starting them), which systemd does by
using cgroups. Either you need the systemd unit files to have additional
info (how to make the daemon produce a pid file, or force it to never
fork, or what have you), or you need to implement reliable process
tracking without cgroups, at which point you have ported the essential
non-portable part of systemd.

Considering that we are still ignoring all of the difficult systemd
features (socket activation, network and fs restrictions, etc), it seems
to me that the wrapper isn't easy at all.
--
Arto Jantunen
Helmut Grohne
2013-07-15 13:38:57 UTC
Permalink
Post by Arto Jantunen
In addition to that the wrapper also needs to be able to track the
processes started by the systemd service (the admin might want to stop
or restart services in addition to starting them), which systemd does by
using cgroups. Either you need the systemd unit files to have additional
info (how to make the daemon produce a pid file, or force it to never
fork, or what have you), or you need to implement reliable process
tracking without cgroups, at which point you have ported the essential
non-portable part of systemd.
This could use some data. Download all .service files. Grep the Type.
Count occurances. Drop those with count <= 2.

6 Type=notify
8 Type=simple
10 Type=forking
20 Type=dbus
42 Type=oneshot

For 42 services no process tracking is necessary at all, because we can
simply wait for them to complete. Most of them likely originate from
systemd itself, so this number is to be considered exagerated.

Then Type=simple means that the daemon does not fork. Again no process
tracking is needed. We can write a pid file and be happy with it. If we
work towards making more services "simple", this will benefit upstart as
well, as it maps to the absense of an "expect" stanza. Note that
Type=simple is also the default so the number of services actually using
it is likely higher.

I omitted Type=dbus so far, because it is a variant of Type=simple. Here
too, no process tracking is needed as the daemon is expected not to
fork. All we need to do now is connect to dbus and wait for the declared
busname to appear.

Indeed we are out of luck with Type=forking. In the presence of a decent
init system daemonizing is the job of the init system. It is uselessly
duplicated code. Let's rip that code out of daemons and turn them into
"simple" ones.

Type=notify is similar to Type=dbus except that the notification happens
over $NOTIFY_SOCKET instead of dbus. Again no process tracking is
needed.
Post by Arto Jantunen
From these numbers I conclude that the issue of process tracking is a
non-issue for the majority of .service files. Solving the majority of
cases is just enough here.
Post by Arto Jantunen
Considering that we are still ignoring all of the difficult systemd
features (socket activation, network and fs restrictions, etc), it seems
to me that the wrapper isn't easy at all.
By far the more severe issue is socket activation, because it removes
the need to spell out service dependencies. We cannot infer these
dependencies later on. Instead such a wrapper must implement socket
activation in order to work correctly. This is the non-trivial problem.

The most prominent example here is that services should not longer
declare After=syslog.target. All syslog implementations supported by
systemd must[1] implement socket activation. Any of the 14 occurances in
.service files shipped by Debian simply is a bug. The syslog.target unit
will vanish at some point in the future.

Helmut

[1] Since version 35, see
http://www.freedesktop.org/wiki/Software/systemd/syslog/
Simon McVittie
2013-07-15 14:14:43 UTC
Permalink
Post by Helmut Grohne
Indeed we are out of luck with Type=forking. In the presence of a decent
init system daemonizing is the job of the init system. It is uselessly
duplicated code. Let's rip that code out of daemons and turn them into
"simple" ones.
It does matter where there are dependencies. systemd considers "simple"
services to be ready (for use by the services that depend on them) as
soon as they have been exec'd, whereas "forking" services aren't
considered to be ready until they have forked (and the parent process
has exited). sysvinit scripts block as long as one of their processes
blocks, so they automatically get that behaviour.

"simple" systemd services mostly avoid dependency problems by using
socket-activation: for instance, it doesn't matter if things try to use
dbus-daemon before it's ready to start accept()ing connections, because
systemd was already listen()ing on the appropriate socket on its behalf,
so anything that tries to connect to D-Bus will just block in connect()
until dbus-daemon can accept() it. Init systems that don't have socket
activation can't use that trick.

S
Helmut Grohne
2013-07-15 14:57:11 UTC
Permalink
Post by Simon McVittie
Post by Helmut Grohne
Indeed we are out of luck with Type=forking. In the presence of a decent
init system daemonizing is the job of the init system. It is uselessly
duplicated code. Let's rip that code out of daemons and turn them into
"simple" ones.
It does matter where there are dependencies. systemd considers "simple"
services to be ready (for use by the services that depend on them) as
soon as they have been exec'd, whereas "forking" services aren't
considered to be ready until they have forked (and the parent process
has exited). sysvinit scripts block as long as one of their processes
blocks, so they automatically get that behaviour.
My comment to convert to "simple" was a bit shortsighted here. Thanks
for your clarification. When taking into account readiness the
conversion would probably arrive at "dbus" or "notify" services instead.
This is slightly more work to do, but still we can rid the useless
duplication of daemonizing code and contain it into a few places. Every
other instance of this code has bugs such as leaking file descriptors or
environment variables. We can get rid of those bugs altogether. All we
need to do here is to shift the work towards the init system as has
rightfully been done by the systemd and upstart people.

The actual argument I tried to make here was a different one. I
acknowledged that Type=forking would pose a hard to solve problem to the
proposed wrapper. The number of uses of this type is a minority though.
The reasonable thing for a wrapper to do, is not to cover this case and
stick with a few init scripts.

If the wrapper can avoid 50% of the init scripts, we have already gained
a lot in terms of maintenance cost.

Helmut
Zbigniew Jędrzejewski-Szmek
2013-07-15 14:08:28 UTC
Permalink
Post by Helmut Grohne
Post by Arto Jantunen
In addition to that the wrapper also needs to be able to track the
processes started by the systemd service (the admin might want to stop
or restart services in addition to starting them), which systemd does by
using cgroups. Either you need the systemd unit files to have additional
info (how to make the daemon produce a pid file, or force it to never
fork, or what have you), or you need to implement reliable process
tracking without cgroups, at which point you have ported the essential
non-portable part of systemd.
This could use some data. Download all .service files. Grep the Type.
Count occurances. Drop those with count <= 2.
6 Type=notify
8 Type=simple
10 Type=forking
20 Type=dbus
42 Type=oneshot
For 42 services no process tracking is necessary at all, because we can
simply wait for them to complete. Most of them likely originate from
systemd itself, so this number is to be considered exagerated.
Then Type=simple means that the daemon does not fork. Again no process
Hi,

in Type=forking, forking is used to notify the init system that the
service is ready to serve requests. In Type=simple, it is assumed that
the service is ready immediately. But both Type=simple and Type=forking
services can do further forking at will. So tracking processes is still
needed — to reliably shut down the service, killing the main process and
all children.
Post by Helmut Grohne
tracking is needed. We can write a pid file and be happy with it. If we
work towards making more services "simple", this will benefit upstart as
well, as it maps to the absense of an "expect" stanza. Note that
Type=simple is also the default so the number of services actually using
it is likely higher.
I omitted Type=dbus so far, because it is a variant of Type=simple. Here
too, no process tracking is needed as the daemon is expected not to
fork. All we need to do now is connect to dbus and wait for the declared
busname to appear.
Indeed we are out of luck with Type=forking. In the presence of a decent
init system daemonizing is the job of the init system. It is uselessly
duplicated code. Let's rip that code out of daemons and turn them into
"simple" ones.
This would only work if all those services were ready (sockets opened
and whatever other changes are visible to other processes performed)
immediately at exec. Since this is not possible, Type=simple only works
for services which do not open sockets or mount stuff or write anything
to disk for other processes to read, etc.

Zbyszek
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@in.waw.pl
heroxbd
2013-07-15 19:49:19 UTC
Permalink
Post by Helmut Grohne
By far the more severe issue is socket activation, because it removes
the need to spell out service dependencies. We cannot infer these
dependencies later on. Instead such a wrapper must implement socket
activation in order to work correctly. This is the non-trivial problem.
Interesting point. I am wondering if it is feasible to use x/inetd for
the socket activation.
Zbigniew Jędrzejewski-Szmek
2013-07-16 04:15:19 UTC
Permalink
Post by heroxbd
Post by Helmut Grohne
By far the more severe issue is socket activation, because it removes
the need to spell out service dependencies. We cannot infer these
dependencies later on. Instead such a wrapper must implement socket
activation in order to work correctly. This is the non-trivial problem.
Interesting point. I am wondering if it is feasible to use x/inetd for
the socket activation.
Yes, that's the major selling point of inetd, but only for a single
socket services (so no port 80 and port 443 for single apache
process), only for AF_INET or unix (no fifos, no netlink sockets, and
none of the other kinds supported by systemd), only for standard
options (no SO_REUSEPORT, no SO_KEEPALIVE, no IP_TRANSPARENT, queue
sizes, ...). And of course inetd doesn't do any process
supervision. In short, yes, but really no.

Zbyszek
--
they are not broken. they are refucktored
-- alxchk
Helmut Grohne
2013-07-15 12:05:19 UTC
Permalink
Post by Ondřej Surý
Can we (the mysterious somebody) write a drop-in simple dummy init.d script
which would take a(ny) systemd service file and run the daemon on
non-Linux-kernel systems?
I proposed[1] this earlier. The environment for such a wrapper was paved
by upstart already. There is very little to change on the side of
sysvinit to integrate such a wrapper. I have not yet found enough time
to implement this. If someone would be interested to join this effort,
that would be great. The most important requirement here would be time,
then knowledge of C[2]. For completeness sake I am attaching my very
rough draft. Please contact me if you are interested.
Post by Ondřej Surý
That would reduce complexity for most packages. The maintainers could stay
with handwritten shell scripts if the init.d script is more complex, but I
suspect that it would be ok for most packages to just have a simple
compatibility layer on top of systemd service files.
From memory I recall that roughly half of the .service files I examined
a few months ago from Debian packages could be quite easily run using
such a wrapper. The main issue here is the need for a new service to be
started very early and binding all the sockets, since we lack dependency
information elided by socket activation.

Again I would like to stress that a more uniform way of interfacing with
services is urgently needed. Currently upstart and systemd have vastly
differing interfaces from the point of view of a service. This is not
limited to the configuration syntax, but extends to the socket
activation API and other aspects. Having either of them adopt an
interface aspect of the other is a net win for everyone, but this has
proven difficult so far.

Helmut

[1] http://lists.debian.org/debian-devel/2013/05/msg01337.html
[2] Even though implementing this in a scripting language such as Perl
or Python is easier, I do not believe that such a system component
should depend on an interpreter.
Continue reading on narkive:
Loading...