Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Thijs Kinkhorst]

On Sun, July 14, 2013 21:19, Kevin Chadwick wrote:
> 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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/89776c3d3699db724369ac314e7e59a2.squir...@aphrodite.kinkhorst.nl

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Thomas Goirand]

On 07/15/2013 03:20 AM, Marco d'Itri wrote:
> On Jul 14, David Kalnischkies  wrote:
> 
>> 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e3b049.4020...@debian.org

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Josselin Mouette]

Le dimanche 14 juillet 2013 à 20:19 +0100, Kevin Chadwick a écrit : 
> 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.

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

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

> 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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1373877164.2461.703.camel@pi0307572

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[David Kalnischkies]

On Mon, Jul 15, 2013 at 2:56 AM, Ben Hutchings  wrote:
> On Sun, 2013-07-14 at 13:09 +0200, David Kalnischkies wrote:
>> On Sun, Jul 14, 2013 at 10:57 AM, John Paul Adrian Glaubitz
>>  wrote:
>> > On 07/14/2013 06:45 AM, Thomas Goirand wrote:
>> >>
>> >> 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)
>> >
>> >
>> > 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caaz6_fc77cqxezjd_kkky38ghljnu-+t0zt0czogobvybnw...@mail.gmail.com

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Charles Plessy]

Le Mon, Jul 15, 2013 at 04:18:17PM +0800, Thomas Goirand a écrit :
> 
> 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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130715090234.ga30...@falafel.plessy.net

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Roger Leigh]

On Mon, Jul 15, 2013 at 06:02:34PM +0900, Charles Plessy wrote:
> 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/Linuxhttp://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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130715092609.gw31...@codelibre.net

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Ondřej Surý]

On Sat, Jul 13, 2013 at 11:46 PM, Michael Stapelberg
wrote:

> 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


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ý 

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Arto Jantunen]

Ondřej Surý  writes:
> 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?

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874nbwgml3@kirika.int.wmdata.fi

SONAME migration: from liblambda0 to liblambda1

[Jerome BENOIT]

Hello List:

When the SONAME increments the associated binary library package has a new name,
so the SONAME suffix has to increment as well accordingly: for a library package
lambda, the binary library package could be renamed from liblambda0 to 
liblambda1.
I thought that I could manage all of the change, but it appeared a last issue 
that
I have just noticed by installing the new package: the former binary package
liblambda0 is not discarded by the new binary package liblambda1, neither in Sid
nor at the upgrading stage with aptitude.
I guess that something is missing in `debian/control', any clue ?

Thanks in advance,
Jerome


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e3d618.6000...@rezozer.net

Re: SONAME migration: from liblambda0 to liblambda1

[Игорь Пашев]

2013/7/15 Jerome BENOIT :
> the former binary package
> liblambda0 is not discarded by the new binary package liblambda1, neither in 
> Sid
> nor at the upgrading stage with aptitude.
> I guess that something is missing in `debian/control', any clue ?

I think this is intentional. And this is why package names follow SONAMES.
If old package is removed all dependent packages will be broken.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/call-q8xjhtnwuwgv3eaev+qk-pzzh9f5yv619ozexaegjno...@mail.gmail.com

Re: openrc packaging status (Re: Survey answers part 3: systemd is not portable and what this means for our ports)

[heroxbd]

Dear Guys,

Holger Levsen  writes:

> 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


pgpCmSlMH3VxH.pgp
Description: PGP signature

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Ondřej Surý]

On Mon, Jul 15, 2013 at 12:10 PM, Arto Jantunen  wrote:

> Ondřej Surý  writes:
> > 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?
>
> 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ý 

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Helmut Grohne]

On Mon, Jul 15, 2013 at 11:27:22AM +0200, Ondřej Surý wrote:
> 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?

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.

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


s3c.tar.gz
Description: Binary data

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Josselin Mouette]

Le lundi 15 juillet 2013 à 16:18 +0800, Thomas Goirand a écrit : 
> 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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1373890027.2461.722.camel@pi0307572

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Josselin Mouette]

Le dimanche 14 juillet 2013 à 11:55 -0700, Geoffrey Thomas a écrit : 
> 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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1373890160.2461.724.camel@pi0307572

Re: openrc packaging status (Re: Survey answers part 3: systemd is not portable and what this means for our ports)

[John Paul Adrian Glaubitz]

On 07/15/2013 01:37 PM, heroxbd wrote:

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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e3eb73.1090...@physik.fu-berlin.de

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Arto Jantunen]

Please don't CC me, I read the list.

Ondřej Surý  writes:
> On Mon, Jul 15, 2013 at 12:10 PM, Arto Jantunen  wrote:
>> 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.

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y598f1g5@kirika.int.wmdata.fi

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[The Wanderer]

On 07/15/2013 08:07 AM, Josselin Mouette wrote:


Le lundi 15 juillet 2013 à 16:18 +0800, Thomas Goirand a écrit :


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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e3f267.40...@fastmail.fm

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Wouter Verhelst]

On 15-07-13 14:09, Josselin Mouette wrote:
> Le dimanche 14 juillet 2013 à 11:55 -0700, Geoffrey Thomas a écrit : 
>> 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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e3f319.1080...@debian.org

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Helmut Grohne]

On Mon, Jul 15, 2013 at 03:32:42PM +0300, Arto Jantunen wrote:
> 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.

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

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130715133857.GA15422@localhost

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[John Paul Adrian Glaubitz]

On 07/15/2013 03:00 PM, The Wanderer wrote:

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

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.



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.



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.



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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e3fc84.6030...@physik.fu-berlin.de

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Simon McVittie]

On 15/07/13 14:38, Helmut Grohne wrote:
> 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e403d3.3060...@debian.org

Bug#716981: ITP: libcore-cache-clojure -- cache abstraction library

[Eugenio Cano-Manuel Mendoza]

Package: wnpp
Severity: wishlist
Owner: "Eugenio Cano-Manuel Mendoza" 

* Package name: libcore-cache-clojure
  Version : 0.6.2
  Upstream Author : Michael Fogus 
* URL : https://github.com/clojure/core.cache
* License : EPL-1.0
  Programming Lang: Java, Clojure
  Description : cache abstraction library

core.cache provides a cache abstraction as well as different
implementations of caching strategies such as FIFO, LRU, TTL, LIRS etc.
Programmers can also choose to create their own implementation of the
base cache abstraction and nest different implementations together.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130715143830.5827.78587.reportbug@localhost

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[The Wanderer]

On 07/15/2013 09:43 AM, John Paul Adrian Glaubitz wrote:


On 07/15/2013 03:00 PM, The Wanderer wrote:


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.


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


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.


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.



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.


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
n

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 15, 2013 at 03:38:57PM +0200, Helmut Grohne wrote:
> On Mon, Jul 15, 2013 at 03:32:42PM +0300, Arto Jantunen wrote:
> > 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.

> 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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130715140828.gg28...@in.waw.pl

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Helmut Grohne]

On Mon, Jul 15, 2013 at 03:14:43PM +0100, Simon McVittie wrote:
> On 15/07/13 14:38, Helmut Grohne wrote:
> > 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130715145710.ga9...@alf.mars

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Steve Langasek]

On Sun, Jul 14, 2013 at 08:10:16PM +0200, David Kalnischkies wrote:

> >> 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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Steve Langasek]

On Sun, Jul 14, 2013 at 10:57:23AM +0200, John Paul Adrian Glaubitz wrote:
> >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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[John Paul Adrian Glaubitz]

On 07/15/2013 07:11 PM, Steve Langasek wrote:

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

> [1] 
https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Disadvantages


--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e435e6.5010...@physik.fu-berlin.de

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[John Paul Adrian Glaubitz]

On 07/15/2013 06:54 PM, Steve Langasek wrote:


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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e43670.1010...@physik.fu-berlin.de

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Thomas Goirand]

On 07/15/2013 05:02 PM, Charles Plessy wrote:
> Le Mon, Jul 15, 2013 at 04:18:17PM +0800, Thomas Goirand a écrit :
>>
>> 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).

> 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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e438cf.9030...@debian.org

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Thomas Goirand]

On 07/15/2013 04:32 PM, Josselin Mouette wrote:
> 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e43d43.9030...@debian.org

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Steve Langasek]

On Mon, Jul 15, 2013 at 07:48:22PM +0200, John Paul Adrian Glaubitz wrote:
> On 07/15/2013 07:11 PM, Steve Langasek wrote:
> >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)."

> [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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Steve Langasek]

On Mon, Jul 15, 2013 at 04:18:17PM +0800, Thomas Goirand wrote:

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

> 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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Stephen Gran]

This one time, at band camp, Roger Leigh said:
> On Mon, Jul 15, 2013 at 06:02:34PM +0900, Charles Plessy wrote:
> > 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 |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Systemd support in Debian packages: how to help

[Michael Stapelberg]

Hi,

I am sorry for starting yet another thread on systemd, but we feel this
particular post is important and should spread as widely as possible
(i.e. beyond just readers of planet debian):

http://people.debian.org/~stapelberg/2013/07/14/systemd-how-to-help.html

tl;dr: whatever you end up doing, please coordinate with us first!

Thanks!

-- 
Best regards,
Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/x6y597obol@midna.lan

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Henrique de Moraes Holschuh]

On Sun, 14 Jul 2013, Russ Allbery wrote:
> 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130715195018.ga7...@khazad-dum.debian.net

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[heroxbd]

Helmut Grohne  writes:

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9ln7ge8@proton.in.awa.tohoku.ac.jp

Re: Systemd support in Debian packages: how to help

[John Paul Adrian Glaubitz]

On 07/15/2013 09:39 PM, Michael Stapelberg wrote:

http://people.debian.org/~stapelberg/2013/07/14/systemd-how-to-help.html


Thanks for the guidelines and the idea to coordinate future work!

This actually leads me to something I have been wondering for
some time: Are there already plans to update systemd in Debian?

I am eagerly waiting to try one of the recent versions of systemd,
especially since I am having trouble with remote filessystems which
Lennart claims to have been remedied in later versions of systemd.

Cheers,

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e455e5.50...@physik.fu-berlin.de

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Russ Allbery]

Henrique de Moraes Holschuh  writes:

> 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 (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwpnlh6z@windlord.stanford.edu

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[John Paul Adrian Glaubitz]

On 07/15/2013 09:50 PM, Henrique de Moraes Holschuh wrote:

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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e457ce.8050...@physik.fu-berlin.de

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Stig Sandbeck Mathisen]

Henrique de Moraes Holschuh  writes:

> On Sun, 14 Jul 2013, Russ Allbery wrote:
>> 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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wqortw6z@dagon.fnord.no

Re: Systemd support in Debian packages: how to help

[Michael Biebl]

Am 15.07.2013 22:04, schrieb John Paul Adrian Glaubitz:
> On 07/15/2013 09:39 PM, Michael Stapelberg wrote:
>> http://people.debian.org/~stapelberg/2013/07/14/systemd-how-to-help.html
> 
> Thanks for the guidelines and the idea to coordinate future work!
> 
> This actually leads me to something I have been wondering for
> some time: Are there already plans to update systemd in Debian?
> 
> I am eagerly waiting to try one of the recent versions of systemd,
> especially since I am having trouble with remote filessystems which
> Lennart claims to have been remedied in later versions of systemd.

Sorry that this takes a bit longer then expected, but packages based on
v204 are in preparation and expect them soonish.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Systemd support in Debian packages: how to help

[John Paul Adrian Glaubitz]

On 07/16/2013 01:03 AM, Michael Biebl wrote:

Sorry that this takes a bit longer then expected, but packages based on
v204 are in preparation and expect them soonish.


Thanks for the update! Rock on! :)

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e48e2d.3040...@physik.fu-berlin.de

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Thomas Goirand]

On 07/16/2013 01:50 AM, John Paul Adrian Glaubitz wrote:
> On 07/15/2013 06:54 PM, Steve Langasek wrote:
>>
>> 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e49ee0.2010...@debian.org

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Thomas Goirand]

On 07/16/2013 02:19 AM, Steve Langasek wrote:
> On Mon, Jul 15, 2013 at 04:18:17PM +0800, Thomas Goirand wrote:
> 
>> 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.
> 
>> 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e49f46.1090...@debian.org

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Geoffrey Thomas]

On Mon, 15 Jul 2013, Josselin Mouette wrote:


Le dimanche 14 juillet 2013 à 11:55 -0700, Geoffrey Thomas a écrit :

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
geo...@ldpreload.com

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 16, 2013 at 04:49:19AM +0900, heroxbd wrote:
> Helmut Grohne  writes:
> 
> > 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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130716041519.gh28...@in.waw.pl