engineering management practices and systemd (Re: Installing an Alternative Init?)

[Joel Rees]

Sounds good to me, but in reality, since the default *and only* init
system for the last very many years was Sysvinit (this extremely salient
point seems to be completely and totally lost on the systemd
proponents), I think only systemd and sysvinit need to be there... but
allowing for additions once required bugs implementing them are resolved
as fixed.

It doesn't matter Andrei...
1. The *default* is what we are discussing.
The *default* for Debian has been sysvinit since - forever?
2. The systemd proponents pushed to make systemd the *new* default - a
massively major change from *all* previous releases since... forever?
3. A bug was opened to allow for the ability to allow a clean install to
be performed with systemd on wheezy, while sysvinit was still the default.
It should have been made mandatory that the systemd folks get this bug
fully resolved and functional *on wheezy*, *and* commit to maintaining
this ability in jessie, as a pre-condition to even getting the question
of a change of the default init system for jessi on the ballot.
Anything else, as I said, makes no sense.

To explain to the systemd advocates who refuse to understand the
engineering questions, this is the real engineering mistake in
systemd.

The engineering question keeps getting sidetracked by people who
assert that we are talking about technical details, and then proceed
to question (foolishly) the necessity of modularity, or (rightly) the
meaning of modularity, etc. That all was and is still relevant, but if
proper engineering principles had been followed in bringing systemd
in, the open development practices our larger community claims as its
reason for existence would have taken care of the technical details.

Maybe it would help if I said, "engineering management", instead of
just "engineering", although you really can't separate management from
engineering.

It was clear much longer than four years ago how deeply the changes
would effect the infrastructure which defines the system, and on which
the stability of the system depends. Every daemon package would be
effected, even if the systemd project had restrained themselves to
working only on the init part of the infrastructure. Every daemon
package needed to be fixed to the new interface, and tested under it.
(Many still need that.)

They didn't, of course they didn't, they've admitted many times that
the init system was not their ultimate target.

Therefore, every package that uses or provides authentication got
entangled in the changes and needed both careful editing and extensive
testing. The testing is still to be completed, because we are not
talking about context-free grammar simplicity here in any of the
parts.

Then every tool, package, application, etc., that used the
system-supplied copy/paste buffer got entangled, and, while they were
at it, they decided to try to absorb pretty much the entirety of
inter-process communication.

Careful re-write, extensive testing. The testing won't be complete yet
by the very nature of where they are changing things.

This all would have been okay for them, if they had followed proper
engineering (management) principles. As long as they were an
independent maverick, they could do what they want. That was correct,
that was good.

For Fedora, where it was first brought into a major distribution, the
proper way to bring it in would have been to break policy and set up a
parallel fork. Keep the damage that necessarily occurs with this kind
of thing restricted to a sub-community willing _and_ _able_ to deal
with the damage by cooperating in the separate bug tracking, triage,
etc. Keep the questions of direction somewhat independent so that the
systemd side and the "legacy" side don't have to be in lock-step on
every tiny detail. Allow separate of source so that regressions and
merges can be safely scheduled and safely carried out. Etc.

If they had done it right from the start, just about now, they would
be ready for beginning the integration process in earnest, which would
mean that about the beginning of this year, when the question came
formally before the committee here, Fedora would have been
implementing their own version of an installer that would allow
choosing the new init system on install.

The systemd folks were too impatient for whatever reason. They pointed
out that Linux itself was not done that way, but their version of
history is most politely described as colored by their desires for
quick success for their project.

"Throw it against the wall and see what sticks!" engineering is only
appropriate for maverick projects. (And it is very appropriate for
maverick projects.) Fedora may be testing for Red Hat, but it is still
mainstream in terms of the number of users and the broad spectrum of
the user base.

So Fedora is not, itself, really ready yet, except for two groups, a
certain group of workstation users who want and are willing to use
fairly new, relatively high-end hardware, including enough RAM and
processors to use VMs for certain things, and a certain group of
server-farm users who want and have budget for similarly recent,
relatively high-end hardware and lots of RAM and processors for lots
of VMs.

The rest of the Fedora users jumped ship.

Now, you who complain that Fedora and Red Hat are off-topic here,
remember that Debian is inheriting the results of Red Hat's work. Work
that did not allow a choice of inits on install, as one example of
where their work is incomplete. That choice was something we still
haven't got quite right yet, after how many months?

Debian set up kfreebsd to deal with these kinds of issues, relative to
replacing the linux kernel with the freebsd kernel. Setting up a
debian-sysd would not have been as extensive a project as setting up
kfreebsd, but would have been similar, because we are basically
pulling in a new layer between the kernel and the rest of the system.

The systemd folks claimed it wouldn't be necessary. If we had looked
at the situation with an unbiased eye, we would have known they were
being overly optimistic. We still turn a blind eye to the problems,
claiming that the only problems are a bunch of recalcitrant
noisemakers like yours-truly.

It is *the systemd proponents* that wanted this change, so it should be
*on them* to do the work. Period.

[Andrei POPESCU]

Post by Joel Rees

Sounds good to me, but in reality, since the default *and only* init
system for the last very many years was Sysvinit (this extremely salient
point seems to be completely and totally lost on the systemd
proponents), I think only systemd and sysvinit need to be there... but
allowing for additions once required bugs implementing them are resolved
as fixed.

It doesn't matter Andrei...
1. The *default* is what we are discussing.
The *default* for Debian has been sysvinit since - forever?

It was claimed that sysvinit was the default *and only* (emphasis not
mine) init, and therefore no selection was needed, but now that there
are several a selection suddenly is needed.

I was just pointing out that alternatives were indeed available, for
quite some time, it's just that maintainers and users of alternate inits
did not yell at the sysvinit maintainers to implement the choice for
them.

Post by Joel Rees
To explain to the systemd advocates who refuse to understand the
engineering questions, this is the real engineering mistake in
systemd.

[snip another wall of text about engineering principles]

Post by Joel Rees
For Fedora, where it was first brought into a major distribution, the
proper way to bring it in would have been to break policy and set up a
parallel fork. Keep the damage that necessarily occurs with this kind
of thing restricted to a sub-community willing _and_ _able_ to deal
with the damage by cooperating in the separate bug tracking, triage,
etc. Keep the questions of direction somewhat independent so that the
systemd side and the "legacy" side don't have to be in lock-step on
every tiny detail. Allow separate of source so that regressions and
merges can be safely scheduled and safely carried out. Etc.

I'm not familiar with how Fedora evolves as a distribution, so I will
refrain from commenting on this.

Post by Joel Rees
If they had done it right from the start, just about now, they would
be ready for beginning the integration process in earnest, which would
mean that about the beginning of this year, when the question came
formally before the committee here, Fedora would have been
implementing their own version of an installer that would allow
choosing the new init system on install.

What the Fedora installer can or cannot do is irrelevant for Debian,
unless one can use it to install Debian (is this the case?).

Post by Joel Rees
So Fedora is not, itself, really ready yet, except for two groups, a
certain group of workstation users who want and are willing to use
fairly new, relatively high-end hardware, including enough RAM and
processors to use VMs for certain things, and a certain group of
server-farm users who want and have budget for similarly recent,
relatively high-end hardware and lots of RAM and processors for lots
of VMs.
The rest of the Fedora users jumped ship.

Again, I can't comment on Fedora, but my Raspberry Pi runs systemd just
fine. Also my laptop running is quite far from being a speed monster.

Post by Joel Rees
Now, you who complain that Fedora and Red Hat are off-topic here,
remember that Debian is inheriting the results of Red Hat's work. Work
that did not allow a choice of inits on install, as one example of
where their work is incomplete. That choice was something we still
haven't got quite right yet, after how many months?

Even if Fedora and/or Red Hat would have this choice it still wouldn't
have helped Debian in any way, because the bug is in a Debian component
(debootstrap, guess what the "de" stands for).

Post by Joel Rees
Debian set up kfreebsd to deal with these kinds of issues, relative to
replacing the linux kernel with the freebsd kernel. Setting up a
debian-sysd would not have been as extensive a project as setting up
kfreebsd, but would have been similar, because we are basically
pulling in a new layer between the kernel and the rest of the system.

"Debian" as an entity doesn't really do much. There are only one or
several volunteers who start doing things. Setting up a separate "port"
for systemd would have been a major waste of resources (both human and
hardware) with no real gain.

Post by Joel Rees
The systemd folks claimed it wouldn't be necessary. If we had looked
at the situation with an unbiased eye, we would have known they were
being overly optimistic. We still turn a blind eye to the problems,
claiming that the only problems are a bunch of recalcitrant
noisemakers like yours-truly.

You are completely dismissing the work of Debian Developers who *did*
have a very good look at the options and decided switching to systemd is
doable and would be a good thing from a *technical* point of view. And
yes, that included the costs for the migration.

As far as I can tell by watching debian-user, debian-devel and
pkg-systemd-maintainers the integration of systemd is mostly working
fine and remaining issues (not all in systemd itself) will be dealt with
before the release. The freeze could help with that, since the number of
variables is reduced greatly.

However, you and several others are rejecting systemd on ideological
grounds. There's not much that can be done about that, short or
re-implementing systemd according to your vision.

I hope you do understand why neither the systemd developers, maintainers
or users have any interest whatsoever in doing that. After all, systemd
already works fine for them.

Kind regards,
Andrei

[Dimitrios Chr. Ioannidis]

On 14-11-2014 12:26, Andrei POPESCU wrote:

< snip >

Post by Andrei POPESCU
However, you and several others are rejecting systemd on ideological
grounds. There's not much that can be done about that, short or
re-implementing systemd according to your vision.

I personally reject the design of systemd.

To paraphrase Joel Spolsky :

"As i see it every new feature systemd has is a tradeoff, between the
people
who could really use such a feature and the people who are just
going to get overwhelmed by all the options. Even if you think that
the new feature is all good and can't hurt because
"people who don't care can just ignore it," you're forgetting that
the people who allegedly don't care are still forced to look at that
feature
and figure out if they need it."

IMHO, systemd don't have that ineffable quality ( of doing less ) that
will make
knowledgable people to use it even if it doesn't have flaws.

Regards,

[Miles Fidelman]

Post by Dimitrios Chr. Ioannidis
< snip >

Post by Andrei POPESCU
However, you and several others are rejecting systemd on ideological
grounds. There's not much that can be done about that, short or
re-implementing systemd according to your vision.

I personally reject the design of systemd.
"As i see it every new feature systemd has is a tradeoff, between the
people
who could really use such a feature and the people who are just
going to get overwhelmed by all the options. Even if you think that
the new feature is all good and can't hurt because
"people who don't care can just ignore it," you're forgetting that
the people who allegedly don't care are still forced to look at that
feature
and figure out if they need it."

Kind of like Microsoft Word, since v6.

Miles Fidelman

[Dan]

On Fri, Nov 14, 2014 at 11:26 AM, Andrei POPESCU

Post by Andrei POPESCU

Post by Joel Rees

Sounds good to me, but in reality, since the default *and only* init
system for the last very many years was Sysvinit (this extremely salient
point seems to be completely and totally lost on the systemd
proponents), I think only systemd and sysvinit need to be there... but
allowing for additions once required bugs implementing them are resolved
as fixed.

It doesn't matter Andrei...
1. The *default* is what we are discussing.
The *default* for Debian has been sysvinit since - forever?

It was claimed that sysvinit was the default *and only* (emphasis not
mine) init, and therefore no selection was needed, but now that there
are several a selection suddenly is needed.
I was just pointing out that alternatives were indeed available, for
quite some time, it's just that maintainers and users of alternate inits
did not yell at the sysvinit maintainers to implement the choice for
them.

Post by Joel Rees
To explain to the systemd advocates who refuse to understand the
engineering questions, this is the real engineering mistake in
systemd.

[snip another wall of text about engineering principles]

Post by Joel Rees
For Fedora, where it was first brought into a major distribution, the
proper way to bring it in would have been to break policy and set up a
parallel fork. Keep the damage that necessarily occurs with this kind
of thing restricted to a sub-community willing _and_ _able_ to deal
with the damage by cooperating in the separate bug tracking, triage,
etc. Keep the questions of direction somewhat independent so that the
systemd side and the "legacy" side don't have to be in lock-step on
every tiny detail. Allow separate of source so that regressions and
merges can be safely scheduled and safely carried out. Etc.

I'm not familiar with how Fedora evolves as a distribution, so I will
refrain from commenting on this.

Post by Joel Rees
If they had done it right from the start, just about now, they would
be ready for beginning the integration process in earnest, which would
mean that about the beginning of this year, when the question came
formally before the committee here, Fedora would have been
implementing their own version of an installer that would allow
choosing the new init system on install.

What the Fedora installer can or cannot do is irrelevant for Debian,
unless one can use it to install Debian (is this the case?).

Post by Joel Rees
So Fedora is not, itself, really ready yet, except for two groups, a
certain group of workstation users who want and are willing to use
fairly new, relatively high-end hardware, including enough RAM and
processors to use VMs for certain things, and a certain group of
server-farm users who want and have budget for similarly recent,
relatively high-end hardware and lots of RAM and processors for lots
of VMs.
The rest of the Fedora users jumped ship.

Again, I can't comment on Fedora, but my Raspberry Pi runs systemd just
fine. Also my laptop running is quite far from being a speed monster.

Post by Joel Rees
Now, you who complain that Fedora and Red Hat are off-topic here,
remember that Debian is inheriting the results of Red Hat's work. Work
that did not allow a choice of inits on install, as one example of
where their work is incomplete. That choice was something we still
haven't got quite right yet, after how many months?

Even if Fedora and/or Red Hat would have this choice it still wouldn't
have helped Debian in any way, because the bug is in a Debian component
(debootstrap, guess what the "de" stands for).

Post by Joel Rees
Debian set up kfreebsd to deal with these kinds of issues, relative to
replacing the linux kernel with the freebsd kernel. Setting up a
debian-sysd would not have been as extensive a project as setting up
kfreebsd, but would have been similar, because we are basically
pulling in a new layer between the kernel and the rest of the system.

"Debian" as an entity doesn't really do much. There are only one or
several volunteers who start doing things. Setting up a separate "port"
for systemd would have been a major waste of resources (both human and
hardware) with no real gain.

Post by Joel Rees
The systemd folks claimed it wouldn't be necessary. If we had looked
at the situation with an unbiased eye, we would have known they were
being overly optimistic. We still turn a blind eye to the problems,
claiming that the only problems are a bunch of recalcitrant
noisemakers like yours-truly.

You are completely dismissing the work of Debian Developers who *did*
have a very good look at the options and decided switching to systemd is
doable and would be a good thing from a *technical* point of view. And
yes, that included the costs for the migration.
As far as I can tell by watching debian-user, debian-devel and
pkg-systemd-maintainers the integration of systemd is mostly working
fine and remaining issues (not all in systemd itself) will be dealt with
before the release. The freeze could help with that, since the number of
variables is reduced greatly.
However, you and several others are rejecting systemd on ideological
grounds. There's not much that can be done about that, short or
re-implementing systemd according to your vision.
I hope you do understand why neither the systemd developers, maintainers
or users have any interest whatsoever in doing that. After all, systemd
already works fine for them.
Kind regards,
Andrei
--

Hi,

I would like to give my opinion. I have been using Debian for 14
years. I switched to Debian because I believe in freedom. I used to
use fvwm, then switch to blackbox, enlightenment, kde, LXDM, gnome,
etc. We still have those options because that is how Unix works and I
love that. It is very important to keep that approach.

Let's imagine a country where 49% of the population likes blue jeans
and 51% of the population likes black jeans. Then there is a
referendum and the 51% decide to impose by law to wear black jeans.
Although that might be legal, it is certainly not correct.

Debian is a community made by developers and users. Both are equally
important to keep the community alive. The type of users is very broad
and it goes from teenagers to server guys. Because of that we should
keep the freedom of choice an important part of Debian.

This is why I do believe that we should have to the option to choose
the init system and it has to be easy. It has to be clear how to do it
with the installation program. A "geek" approach where you have to
install systemd and then you have to remove it, is in practice: "no
choice". Not everybody is a geek.

Personally I prefer not to use systemd in my servers, but I find
wonderful to have the choice. Do you remember the Gnome/KDE war? Now
we have two great desktop. Let's not impose by law an init system.

Best,
Dani

[Lisi Reisz]

Post by Dan
Do you remember the Gnome/KDE war? Now
we have two great desktop. Let's not impose by law an init system.

Yes, but Gnome is the default and you have to be an "advanced user" to get
KDE.

And anyway, some of us want neither and have to go to even greater lengths to
avoid them. It has always been thus. No-one is imposing an init system by
law. There has to be a default.

Lisi

[Renaud (Ron) OLGIATI]

On Fri, 14 Nov 2014 13:10:22 +0000

Post by Lisi Reisz

Post by Dan
Do you remember the Gnome/KDE war? Now
we have two great desktop. Let's not impose by law an init system.

Yes, but Gnome is the default and you have to be an "advanced user" to get
KDE.

Not really, you just have to choose whether you download the Gnome-CD, the KDE-CD, or the Xfce-CD (which I prefer).

There is choice without being "advanced".

Cheers,

Ron.
--
The liar's punishment is not in the least that he is not believed,
but that he cannot believe anyone else.
--George Bernard Shaw

-- http://www.olgiati-in-paraguay.org --

[Helmut Wollmersdorfer]

Post by Andrei POPESCU
Again, I can't comment on Fedora, but my Raspberry Pi runs systemd just
fine. Also my laptop running is quite far from being a speed monster.

On my two Raspberries I do not care.

On a laptop it depends on your usage profile, and what your requirements are. My Acer One (Atom, 1 GB) got to slow after upgrade to wheezy. To much bloat, to much swapping.

And all this says nothing about big servers, which need some magnitudes more of reliability, stability and scaling. E.g. not using plain text files for logs causes problems in the long run and in daily work.

Helmut Wollmersdorfer

[Lisi Reisz]

Post by Helmut Wollmersdorfer

Post by Andrei POPESCU
Again, I can't comment on Fedora, but my Raspberry Pi runs systemd just
fine. Also my laptop running is quite far from being a speed monster.

On my two Raspberries I do not care.
On a laptop it depends on your usage profile, and what your requirements
are. My Acer One (Atom, 1 GB) got to slow after upgrade to wheezy. To much
bloat, to much swapping.
And all this says nothing about big servers, which need some magnitudes
more of reliability, stability and scaling. E.g. not using plain text files
for logs causes problems in the long run and in daily work.

What is the connection between problems you may have with Wheezy and systemd,
which you have to make a conscious effort to install in wheezy?

Lisi

[Andrei POPESCU]

Post by Helmut Wollmersdorfer
And all this says nothing about big servers, which need some
magnitudes more of reliability, stability and scaling. E.g. not using
plain text files for logs causes problems in the long run and in daily
work.

The default setting for the Debian systemd package is to forward all
messages to your syslog and rsyslog is still installed by default.

Kind regards,
Andrei

[Marty]

<snip>

Jumping in here as myself, not Joel's tag-team member. :)

Post by Andrei POPESCU
"Debian" as an entity doesn't really do much. There are only one or
several volunteers who start doing things. Setting up a separate "port"
for systemd would have been a major waste of resources (both human and
hardware) with no real gain.

By the same token systemd is a major waste with no real gain. It
duplicates equivalent modular alternatives, and also requires
unnecessary effort to repair damage from excessive coupling.

Post by Andrei POPESCU

Post by Joel Rees
The systemd folks claimed it wouldn't be necessary. If we had looked
at the situation with an unbiased eye, we would have known they were
being overly optimistic. We still turn a blind eye to the problems,
claiming that the only problems are a bunch of recalcitrant
noisemakers like yours-truly.

You are completely dismissing the work of Debian Developers who *did*
have a very good look at the options and decided switching to systemd is
doable and would be a good thing from a *technical* point of view.

Non-responsive to his argument. If the work was biased and
over-optimistic then it doesn't matter how much they looked at it.

And

Post by Andrei POPESCU
yes, that included the costs for the migration.

Those are largely TBD ast this time.

Post by Andrei POPESCU
As far as I can tell by watching debian-user, debian-devel and
pkg-systemd-maintainers the integration of systemd is mostly working
fine and remaining issues (not all in systemd itself) will be dealt with
before the release. The freeze could help with that, since the number of
variables is reduced greatly.

From the same lists, I can't tell whether non-systemd use will result
in second-class citizenship and effective vendor lock-in for most users.

Post by Andrei POPESCU
However, you and several others are rejecting systemd on ideological
grounds. There's not much that can be done about that, short or
re-implementing systemd according to your vision.

Many others reject choice and the anti-choice stance is the ideological
position at issue here. It is in direct conflict with Debian policy.
The systemd upstream are the ones with "vision," ideology, rejecting
opponents as "haters" in an overt campaign to establish a Linux
monopoly. They have a financial interest in *psychological projection*
of this kind. I still cannot see what Debian stands to gain by jumping
on their marketing bandwagon.

Post by Andrei POPESCU
I hope you do understand why neither the systemd developers, maintainers
or users have any interest whatsoever in doing that.

But upstreams have other interests, like establishment of a Linux
monopoly via tying and customer lock-in. Why should there not be a
rational effort to counter that?

After all, systemd

Post by Andrei POPESCU
already works fine for them.

Windows already works fine for most people, and it is consistent with
the anti-choice philosophy, so why bother with Linux at all?

Post by Andrei POPESCU
Kind regards,
Andrei

[Andrei POPESCU]

Post by Marty
<snip>
Jumping in here as myself, not Joel's tag-team member. :)

Post by Andrei POPESCU
"Debian" as an entity doesn't really do much. There are only one or
several volunteers who start doing things. Setting up a separate "port"
for systemd would have been a major waste of resources (both human and
hardware) with no real gain.

By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

http://0pointer.de/blog/projects/why.html

Post by Marty

Post by Andrei POPESCU
You are completely dismissing the work of Debian Developers who *did*
have a very good look at the options and decided switching to systemd is
doable and would be a good thing from a *technical* point of view.

Non-responsive to his argument. If the work was biased and over-optimistic
then it doesn't matter how much they looked at it.

This argument cuts both ways :)

Post by Marty

Post by Andrei POPESCU
However, you and several others are rejecting systemd on ideological
grounds. There's not much that can be done about that, short or
re-implementing systemd according to your vision.

Many others reject choice and the anti-choice stance is the ideological
position at issue here. It is in direct conflict with Debian policy.
The systemd upstream are the ones with "vision," ideology, rejecting
opponents as "haters" in an overt campaign to establish a Linux monopoly.
They have a financial interest in *psychological projection* of this kind. I
still cannot see what Debian stands to gain by jumping on their marketing
bandwagon.

At least some of people rejecting systemd demand that it be removed
completely, including libsystemd. How is it pro-choice to forbid me from
being able to use a software at its full potential?

Post by Marty

Post by Andrei POPESCU
I hope you do understand why neither the systemd developers, maintainers
or users have any interest whatsoever in doing that.

But upstreams have other interests, like establishment of a Linux monopoly
via tying and customer lock-in. Why should there not be a rational effort to
counter that?

In my opinion the best "defence" against a monopoly[1] of any kind is to
develop competitive alternatives.

[1] which I don't believe applies, but will ignore for the moment.

Post by Marty
After all, systemd

Post by Andrei POPESCU
already works fine for them.

Windows already works fine for most people, and it is consistent with the
anti-choice philosophy, so why bother with Linux at all?

Doesn't work fine for me. At $dayjob I'm forced to use it and I can tell
you my private laptop with a Dual Core 1,8 GHz and 2 GB RAM runs circles
around a Core i5 with Windows 7. But this is off-topic for d-u.

Kind regards,
Andrei

[Renaud (Ron) OLGIATI]

On Sat, 15 Nov 2014 13:49:18 +0200

Post by Andrei POPESCU
In my opinion the best "defence" against a monopoly[1] of any kind is to
develop competitive alternatives.

We have seen how well that worked with MS Windows over the years...

Cheers,

Ron.
--
Nada es tan peligroso como dejar permanecer
largo tiempo a un mismo ciudadano en el poder.
El pueblo se acostumbra a obedecer,
y él se acostumbra a mandarlo;
de donde se origina la usurpación y la tiranía.
-- Simon Bolivar

-- http://www.olgiati-in-paraguay.org --

[Brian]

Post by Andrei POPESCU

Post by Marty
By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

One picture is worth a thousand words.

https://np237.livejournal.com/34598.html

(Sorry, couldn't resist).

[Dimitrios Chr. Ioannidis]

Post by Brian

Post by Andrei POPESCU

Post by Marty
By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

One picture is worth a thousand words.
https://np237.livejournal.com/34598.html
(Sorry, couldn't resist).

I couldn't resist also ...

"A use case better covered by SysV init: encrypted block devices"

http://tanguy.ortolo.eu/blog/categorie2/debian


Regards,

[Brian]

Post by Dimitrios Chr. Ioannidis

Post by Brian

Post by Andrei POPESCU

Post by Marty
By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

One picture is worth a thousand words.
https://np237.livejournal.com/34598.html
(Sorry, couldn't resist).

I couldn't resist also ...
"A use case better covered by SysV init: encrypted block devices"
http://tanguy.ortolo.eu/blog/categorie2/debian

I'll see you and raise you with a link to a helpful post:

https://lists.debian.org/debian-user/2014/04/msg01286.html
https://lists.debian.org/debian-devel/2014/07/msg01048.html

[Dimitrios Chr. Ioannidis]

Post by Brian

Post by Dimitrios Chr. Ioannidis

Post by Brian

Post by Andrei POPESCU

Post by Marty
By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

One picture is worth a thousand words.
https://np237.livejournal.com/34598.html
(Sorry, couldn't resist).

I couldn't resist also ...
"A use case better covered by SysV init: encrypted block devices"
http://tanguy.ortolo.eu/blog/categorie2/debian

https://lists.debian.org/debian-user/2014/04/msg01286.html
https://lists.debian.org/debian-devel/2014/07/msg01048.html

Irrelevant ... Read carefullty " ... use case better covered ... "

"if systemd requires specific configuration to handle such a case,
whereas SysV init does not, that means this case is better covered by
SysV init;"

systemd :

"[Unit]
Description=Unlock EncFS
DefaultDependencies=no
After=local-fs.target
Before=display-manager.service ***@tty1.service

[Service]
Type=oneshot
RemainAfterExit=true
Environment=RootDir=/home/.encfs/crypt
Environment=MountPoint=/home/crypt
ExecStart=/bin/sh -c "systemd-ask-password --no-tty --timeout=30 'Unlock
EncFS' | encfs --stdinpass $RootDir $MountPoint"
ExecStop=/bin/umount $MountPoint

[Install]
WantedBy=sysinit.target"

This is a specific configuration ...

Any way thx for playing ... ( it was just humor ... )

Regards,

[Miles Fidelman]

Post by Andrei POPESCU

Post by Marty
By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

That assumes that one needs or wants systemd's features.

For some (many?) of us, systemd represents no gain, and significant
operational impact (time required to deal with changes).

Miles Fidelman

[Brian]

Post by Miles Fidelman

Post by Andrei POPESCU

Post by Marty
By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

That assumes that one needs or wants systemd's features.

I rather think Andrei might not regard this as answering his challenge.
(You also didn't say whether the link's picture made you chuckle :) ).

Post by Miles Fidelman
For some (many?) of us, systemd represents no gain, and significant
operational impact (time required to deal with changes).

Fair enough, but working within the realities of a situation is also
part of the deal. The deal for Jessie is systemd. This is not on a take
it or leave basis; quite a lot of work has been put into ensuring the
alternatives you want are there.

We have been here before, so some of what follows is repetition. For
users who feel the same as you it is (AFAIK) the way to get basically
what you want. It cannot be definitive because changes between now and
the release of Jessie are likely to alter the advice.

Upgrading
---------

After changing sources.list and an 'apt-get update' do

apt-get install sysvinit-core systemd-shim

Then proceed with an upgrade and dist-upgrade.

New Install
-----------

Use the apt-get command above immediately after installation or
preseed the installation of sysvinit-core and systemd-shim.

Both of these may or may not have an operational impact in individual
cases but (as an outline) they are (AKAIK) the only ways to avoid
systemd-sysv being installed. After that you are on your own, leaving
aside bugs.

I appreciate any major change to a way of working can be stressful but
(without wishing to teach anyone how to do their job) there are ways of
testing which can increase confidence in the provided methods. The
testing also has the added benefit (should there be problems) of
improving on the already large amount of work done within Debian. The
BTS would be the appropriate place to put one's experiences.

[Erwan David]

Post by Brian

Post by Miles Fidelman

Post by Andrei POPESCU

Post by Marty
By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

That assumes that one needs or wants systemd's features.

I rather think Andrei might not regard this as answering his challenge.
(You also didn't say whether the link's picture made you chuckle :) ).

Post by Miles Fidelman
For some (many?) of us, systemd represents no gain, and significant
operational impact (time required to deal with changes).

Fair enough, but working within the realities of a situation is also
part of the deal. The deal for Jessie is systemd. This is not on a take
it or leave basis; quite a lot of work has been put into ensuring the
alternatives you want are there.

It isq : when you have bugs like
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762623
Once said "oh it works with systemd", then no more activity on the bug,
nothing.

That means that practically, systemd is de facto compulsory. Not the
default, the only way allowed.

So it is take or leave.

[Ludovic Meyer]

Post by Erwan David

Post by Brian

Post by Miles Fidelman

Post by Andrei POPESCU

Post by Marty
By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

That assumes that one needs or wants systemd's features.

I rather think Andrei might not regard this as answering his challenge.
(You also didn't say whether the link's picture made you chuckle :) ).

Post by Miles Fidelman
For some (many?) of us, systemd represents no gain, and significant
operational impact (time required to deal with changes).

Fair enough, but working within the realities of a situation is also
part of the deal. The deal for Jessie is systemd. This is not on a take
it or leave basis; quite a lot of work has been put into ensuring the
alternatives you want are there.

It isq : when you have bugs like
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762623
Once said "oh it works with systemd", then no more activity on the bug,
nothing.

I would suggest to read the url you post. There was a message from the
maintainer saying "sorry, i tought I answered, I already reported it to
udev, please give more information on the bug".

Then indeed, you didn't followed up.

Post by Erwan David
That means that practically, systemd is de facto compulsory. Not the
default, the only way allowed.
So it is take or leave.

I think this conclusion is likely wrong and hasty, given the lack of
activity is a result on waiting on more information from the reporter.

[Erwan David]

Post by Ludovic Meyer

Post by Erwan David

Post by Brian

Post by Miles Fidelman

Post by Andrei POPESCU

Post by Marty
By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

That assumes that one needs or wants systemd's features.

I rather think Andrei might not regard this as answering his challenge.
(You also didn't say whether the link's picture made you chuckle :) ).

Post by Miles Fidelman
For some (many?) of us, systemd represents no gain, and significant
operational impact (time required to deal with changes).

Fair enough, but working within the realities of a situation is also
part of the deal. The deal for Jessie is systemd. This is not on a take
it or leave basis; quite a lot of work has been put into ensuring the
alternatives you want are there.

It isq : when you have bugs like
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762623
Once said "oh it works with systemd", then no more activity on the bug,
nothing.

I would suggest to read the url you post. There was a message from the
maintainer saying "sorry, i tought I answered, I already reported it to
udev, please give more information on the bug".
Then indeed, you didn't followed up.

Sorry, I was not asked more precision since 2 days ago, and could not
answer right away.

Post by Ludovic Meyer

Post by Erwan David
That means that practically, systemd is de facto compulsory. Not the
default, the only way allowed.
So it is take or leave.

I think this conclusion is likely wrong and hasty, given the lack of
activity is a result on waiting on more information from the reporter.

Reporter cannot give info if not asked to...

Moreover even when systemd is not pid 1, it must be used through logind,
pam, etc...

I cannot help more since I do not find any doc on debugging systemd
components, for people not knowng systemd internals.

[Miles Fidelman]

Post by Brian

Post by Miles Fidelman

Post by Andrei POPESCU

Post by Marty
By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

That assumes that one needs or wants systemd's features.

I rather think Andrei might not regard this as answering his challenge.
(You also didn't say whether the link's picture made you chuckle :) ).

Well yes, but also shudder.

Post by Brian

Post by Miles Fidelman
For some (many?) of us, systemd represents no gain, and significant
operational impact (time required to deal with changes).

Fair enough, but working within the realities of a situation is also
part of the deal. The deal for Jessie is systemd. This is not on a take
it or leave basis; quite a lot of work has been put into ensuring the
alternatives you want are there.
We have been here before, so some of what follows is repetition. For
users who feel the same as you it is (AFAIK) the way to get basically
what you want. It cannot be definitive because changes between now and
the release of Jessie are likely to alter the advice.
Upgrading
---------
After changing sources.list and an 'apt-get update' do
apt-get install sysvinit-core systemd-shim
Then proceed with an upgrade and dist-upgrade.
New Install
-----------
Use the apt-get command above immediately after installation or
preseed the installation of sysvinit-core and systemd-shim.
Both of these may or may not have an operational impact in individual
cases but (as an outline) they are (AKAIK) the only ways to avoid
systemd-sysv being installed. After that you are on your own, leaving
aside bugs.
I appreciate any major change to a way of working can be stressful but
(without wishing to teach anyone how to do their job) there are ways of
testing which can increase confidence in the provided methods. The
testing also has the added benefit (should there be problems) of
improving on the already large amount of work done within Debian. The
BTS would be the appropriate place to put one's experiences.

At the risk of repeating myself, I'm going to stick with Wheezy as long
as I can, see of LTS kicks in, and wait to see if bug #668001 ever gets
fixed (and note that an awful lot of conflict might have been avoided if
it had been marked release critical.) Meanwhile, I'm going to start
testing other distros, including BSD and illumos based ones.

Miles Fidelman

[Brian]

Post by Brian
Upgrading
---------
After changing sources.list and an 'apt-get update' do
apt-get install sysvinit-core systemd-shim
Then proceed with an upgrade and dist-upgrade.
New Install
-----------
Use the apt-get command above immediately after installation or
preseed the installation of sysvinit-core and systemd-shim.

In the light of

https://lists.debian.org/debian-ctte/2014/11/msg00063.html

I'd like to revise the above and point out that at some time in
the near future the command

apt-get install sysvinit-core

or preseeding the installation of only sysvinit-core should be
sufficient.

[Miles Fidelman]

Post by Miles Fidelman
For some (many?) of us, systemd represents no gain, and significant
operational impact (time required to deal with changes).

Have you considered, just for a fraction of a second, that a migration
to systemd, however painful it may prove, could in fact make your setup
much more reliable and understandable?

Let me also turn the question back at you:

Have you considered, just for a fraction of a second, that a migration
to systemd, could, in fact, make some systems LESS reliable and understandable?


But in answer to your question:

Sure.

For a long time, I just assumed that Jessie would be an improvement on
Wheezy (otherwise, why release a new version), and like previous
releases, it would be largely backwards compatible, have some bugs
resolved, some security holes tightened, and offer some new features
that might or might not be of interest. To the extent that I thought
about systemd at all, it was to the same degree as I think of any other
core system service - it's there, it works, nothing to see here.

Then, I became aware of how many basic system services were being
incorporated into the systemd collection of stuff, and how many other
things it touched (like, for example, PAM - which I use extensively),
and logging, and so on.

And then I started reading the (conflicting) documentation, such as
there is, describing all the things I'd have to test, change, watch out
for when it came to rebuilding our servers on top of Jessie. Followed by
reading about the design, philosophy, approach, and agenda of its
developers - in their own words, in their own emails, and on their own
blogs. And then, I started seeing the reactions of the developers and
apologists to legitimate criticisms and concerns.

I've sat through an awful lot of design reviews for software and system
projects, on both sides of the table, and personally, I would have
killed this thing early in its life. Joel Rees has this exactly right,
this has all the signs of a death march project, not just for Debian but
for large chunks of the Linux ecosystem.

Miles Fidelman

[Andrei POPESCU]

Have you considered, just for a fraction of a second, that a migration
to systemd, could, in fact, make some systems LESS reliable and understandable?

Sure I did. systemd is not bug-free and it's approach is different, so
it does require learning before understanding it.

However, I fail to see any significant difference compared to any other
major change I've been through since using Debian.

Kind regards,
Andrei

[Miles Fidelman]

Post by Andrei POPESCU

Have you considered, just for a fraction of a second, that a migration
to systemd, could, in fact, make some systems LESS reliable and understandable?

Sure I did. systemd is not bug-free and it's approach is different, so
it does require learning before understanding it.
However, I fail to see any significant difference compared to any other
major change I've been through since using Debian.

I guess that we have different ideas of "major change."

[Ludovic Meyer]

Post by Miles Fidelman

Post by Andrei POPESCU

Post by Marty
By the same token systemd is a major waste with no real gain. It duplicates
equivalent modular alternatives, and also requires unnecessary effort to
repair damage from excessive coupling.

I challenge you to come up with a configuration that duplicates
systemd's features with a combination of other software.

That assumes that one needs or wants systemd's features.
For some (many?) of us, systemd represents no gain, and significant
operational impact (time required to deal with changes).

Well, maybe taking some of the time you used to send 71 mails over the course
of 15 days on this list could be invested into dealing with the changes.

It is not like Jessie will not come with others configuration breaking changes
( such as Apache 2.4, to name one ).

You say "significant operational impact", but all your mails seems to
imply that you are basing your analysis on absolutely no test. If you did things
right with your servers, you would just have to use your configuration management
system to spin a new server to test, either bare metal or a VM if you can't afford
a test machine, and see by yourself, and then, be precise in what is the problem.
( provided you use configuration management, but I would find baffling than any
serious sysadmin do not use one these days )

Cause if no one can reproduce the problem ( because you give no indication ) and
no one can find it ( because people test and have no issues ), it is not different
from having a problem that do not really exist, and insisting on it is then no different
than baseless trolling. You want to make a difference, so just do something useful.

[Laurent Bigonville]

Le Sat, 15 Nov 2014 20:21:49 -0500,
[...]

Post by Andrei POPESCU
At least some of people rejecting systemd demand that it be removed
completely, including libsystemd. How is it pro-choice to forbid me
from being able to use a software at its full potential?

For me it's more about being unable to remove it completely, because
of vendor lock-in. There's no technical reason that I know of that
anything in userspace cannot modular, and replaceable, so when
something cannot be replaced then an alternative must be provided, or
else my default assumption is that vendor lock-in is in effect.

Well, yes there are technical reasons why you cannot remove a library
package when you have symbols provided by this library used in an
executable. You can still recompile the package and remove some
configure flag if you want to remove this dependency.

OTHO there is no technical reasons that I can see, to completely remove
libsystemd package. You have tenth of other libraries on your system
that, like libsystemd, turn them self into a noop if some some
functionality or daemon are not enable. I'm thinking here for example
about libselinux and libaudit (both also written by Red Had and the
NSA, OMG!!!11), and yet I fail to see any outcry here...

So as long as you cannot _prove_ that having libsystemd installed on
your machine is causing any issues, I'll personally mentally classify
your request as "I don't want to see any packages containing the
"systemd" string on my machine" and redirect these to /dev/null.

[Marty]

Post by Laurent Bigonville
Le Sat, 15 Nov 2014 20:21:49 -0500,
[...]

Post by Andrei POPESCU
At least some of people rejecting systemd demand that it be removed
completely, including libsystemd. How is it pro-choice to forbid me
from being able to use a software at its full potential?

For me it's more about being unable to remove it completely, because
of vendor lock-in. There's no technical reason that I know of that
anything in userspace cannot modular, and replaceable, so when
something cannot be replaced then an alternative must be provided, or
else my default assumption is that vendor lock-in is in effect.

Well, yes there are technical reasons why you cannot remove a library
package when you have symbols provided by this library used in an
executable. You can still recompile the package and remove some
configure flag if you want to remove this dependency.
OTHO there is no technical reasons that I can see, to completely remove
libsystemd package. You have tenth of other libraries on your system
that, like libsystemd, turn them self into a noop if some some
functionality or daemon are not enable. I'm thinking here for example
about libselinux and libaudit (both also written by Red Had and the
NSA, OMG!!!11), and yet I fail to see any outcry here...
So as long as you cannot _prove_ that having libsystemd installed on
your machine is causing any issues, I'll personally mentally classify
your request as "I don't want to see any packages containing the
"systemd" string on my machine" and redirect these to /dev/null.

Except that proponents seem more prone to avoiding the hairball issue by
just covering their eyes. ;)

My point is that in a modular design nothing should be so entrenched as
to be irreplaceable. Absence of an alternate should not normally
indicate impossibility of an alternate, but some discussions I've read
about logind, udev and dbus are enough to raise serious concerns.

People who just say, "write your own, it's all FOSS" are missing the
point, I think. Debian is not one guy working in his mom's basement.
It's one of the world's largest software projects. When Debian is
stumped, because its best developers and upstreams are caught in the
entanglement hairball, and see no clear way out, the it's clear case of
*Houston we have a problem.*

[Marty]

<snip>

Post by Marty
My point is that in a modular design nothing should be so entrenched
as to be irreplaceable. Absence of an alternate should not normally
indicate impossibility of an alternate, but some discussions I've
read about logind, udev and dbus are enough to raise serious
concerns.

The problem is that, without any action, the difference between "nothing
can be replaced" and "it can be replaced" is purely theorical.

The problem is very real, but there seems to be no agreement about
solutions, which by itself is evidence of a problem.

Now you

can discuss for years in theory,

In fact, people have been discussing this problem for years.

if this doesn't result in any practical

outcome, you have just stresstested the mailling lists software.

Until there's a rough consensus and a clear way forward, I don't think
many people will commit to specific solutions. There are also unknowns
like kdbus, to further complicate the matter.

Post by Marty
People who just say, "write your own, it's all FOSS" are missing the
point, I think. Debian is not one guy working in his mom's basement.
It's one of the world's largest software projects. When Debian is
stumped, because its best developers and upstreams are caught in the
entanglement hairball, and see no clear way out, the it's clear case
of *Houston we have a problem.*

That's a interesting point, because with all those brillant minds,
a vast majority do not even seems to care about this
"entanglement hairball". Maybe it is time to admit you do not
know the whole details and accept that if developpers do not care,
then they are maybe right in doing so ?
Especially since you have been unable to give any technical reasons
to why you do not want it, and how you would proceed.

For you, I would start by explaining the Unix Philosophy and how it is a
critical aspect of Debian's design:

http://en.wikipedia.org/wiki/Unix_philosophy

Then I would proceed to explain how various aspects of systemd conflict
with this, causing said hairball. Finally, I would explain (to the best
of my ability) how the entanglement issue precludes a quick resolution,
and the delay does not indicate lack of interest.

In fact, a quick google check would even give you the required
http://spootnik.org/entries/2014/11/09_pid-tracking-in-modern-init-systems.html
You can compare the code with "link to systemd library" vs "cut and
paste in every source code". As a exercise, you can
surely add "use dlopen()" and see which one is simpler and easier to maintain
in the long term.
Then it will be your turn to explain why it is better to cut and paste or
link statically the library, or why it is better to have to patch every upstream
to use dlopen().

Not sure how we went from entanglement issues to PID tracking, but
granting your point, it still doesn't explain how we arrive at kdb,
console and qcodes in PID 1. :)

And once you will have been able to justify that on a technical level,
maybe people will start to listen to you.
For the record, see also the discussion on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555980

You did not make much of a case for a complex PID 1 process, and on that
question I defer to a kernel dev who takea a rather dim view of it:
http://lwn.net/Articles/618024/

[Ludovic Meyer]

Post by Marty
<snip>

Post by Marty
My point is that in a modular design nothing should be so entrenched
as to be irreplaceable. Absence of an alternate should not normally
indicate impossibility of an alternate, but some discussions I've
read about logind, udev and dbus are enough to raise serious
concerns.

The problem is that, without any action, the difference between "nothing
can be replaced" and "it can be replaced" is purely theorical.

The problem is very real, but there seems to be no agreement about
solutions, which by itself is evidence of a problem.

There is not even anyone keeping a list of the solution or even the
problem. Even the basis are not done.

If you truly want to iterate on a solution, you should
start doing it and document it.

Post by Marty
Now you

can discuss for years in theory,

In fact, people have been discussing this problem for years.

And how did it change anything ? It didn't. So what make you think that
yet another year is gonna result in something ?

I do not want to be too critical, but that's the exact problem that the troll
in the Hobbit face, by discussing endless on how to cook the dwarfs, they
get petrified.

And maybe the time to test and get something wrong, as itcan hardly be slower
than discussing. The whole agile methodology.

Post by Marty
if this doesn't result in any practical

outcome, you have just stresstested the mailling lists software.

Until there's a rough consensus and a clear way forward, I don't
think many people will commit to specific solutions. There are also
unknowns like kdbus, to further complicate the matter.

"Talk is cheap", as Linus said.
You seems to be in favor of design by comitee, but this doesn't seems to work
for now.

Post by Marty

Post by Marty
People who just say, "write your own, it's all FOSS" are missing the
point, I think. Debian is not one guy working in his mom's basement.
It's one of the world's largest software projects. When Debian is
stumped, because its best developers and upstreams are caught in the
entanglement hairball, and see no clear way out, the it's clear case
of *Houston we have a problem.*

That's a interesting point, because with all those brillant minds,
a vast majority do not even seems to care about this
"entanglement hairball". Maybe it is time to admit you do not
know the whole details and accept that if developpers do not care,
then they are maybe right in doing so ?
Especially since you have been unable to give any technical reasons
to why you do not want it, and how you would proceed.

For you, I would start by explaining the Unix Philosophy and how it
http://en.wikipedia.org/wiki/Unix_philosophy

That's not a technical reason.

Post by Marty
Then I would proceed to explain how various aspects of systemd
conflict with this, causing said hairball. Finally, I would explain
(to the best of my ability) how the entanglement issue precludes a
quick resolution, and the delay does not indicate lack of interest.

And how would that be a technical reason ? If you disagree with the philosophy,
that's not a technical problem. That's just a opinion. Show a real technical issue,
not "here is the design decided 20 years ago and that was ignored by several others
components". heck, even in 1989, people wrote "the unix hater handbook" to
explain how the philosophy is wrong. For example, the example of cat not being
following this design anymore. No one throw a fuse over it, despites being
here, documented and visible by all since more than 20 years.

And I know Debian has popularized the idea of "release when it is ready", but that's
also the exact definition of vaporware. And people do not even have a estimation
of the work. Not knowing what solution to choose do not preclude from saying
the time one of them would take. In fact, it would even help to choose.

Post by Marty

In fact, a quick google check would even give you the required
http://spootnik.org/entries/2014/11/09_pid-tracking-in-modern-init-systems.html
You can compare the code with "link to systemd library" vs "cut and
paste in every source code". As a exercise, you can
surely add "use dlopen()" and see which one is simpler and easier to maintain
in the long term.
Then it will be your turn to explain why it is better to cut and paste or
link statically the library, or why it is better to have to patch every upstream
to use dlopen().

Not sure how we went from entanglement issues to PID tracking, but
granting your point, it still doesn't explain how we arrive at kdb,
console and qcodes in PID 1. :)

Because the blog post say how and why stuff requires to be linked with systemd. As you didn't
explain what you mean by hairballs ( ie, what requires exactly you are speaking about )
it is hard to explain it. I am sure that if you were precise, it can be explained or
it could be seen as a bug.

Post by Marty

And once you will have been able to justify that on a technical level,
maybe people will start to listen to you.
For the record, see also the discussion on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555980

You did not make much of a case for a complex PID 1 process

That was not my point. But you just did.

Post by Marty
and on
that question I defer to a kernel dev who takea a rather dim view of
it: http://lwn.net/Articles/618024/

So all viro think that :
- kernel is not the place for doing interprocess communication at the scale
required by systemd.
- dbus is not the right place either.
his point is that sending too much informations is gonna be a problem anyway.
Either by the kernel, or outside of the kernel.

so the only way left is to not do IPC, so having everything in the same
process. So he is in fact in favor of having a complex process communicating
with himself and doing everything.

We can see that in the design of the kernel, because of the original
design decision of not going the micro kernel way ( ie, minix, hurd )
by Linus, as documented in the debate between him and Andrew Tannenbaum.

I would suggest, when you point to kernel developpers, to keep in mind that
they work on a big entangled code base, without any internal interface.
They kinda endorse that model, or would be working on the hurd. And that's because
people keep referring to Linus or others and at the same time complain
about systemd that some people do not take anti systemds crowd seriously.

The whole kernel design is monolithic, because there is a overhead of doing
the other way. So yeah, Al Viro point in favor of a more monolithic
and complex solution.

--
l.

[Marty]

Post by Ludovic Meyer

Post by Marty
<snip>

Post by Marty
My point is that in a modular design nothing should be so entrenched
as to be irreplaceable. Absence of an alternate should not normally
indicate impossibility of an alternate, but some discussions I've
read about logind, udev and dbus are enough to raise serious
concerns.

The problem is that, without any action, the difference between "nothing
can be replaced" and "it can be replaced" is purely theorical.

The problem is very real, but there seems to be no agreement about
solutions, which by itself is evidence of a problem.

There is not even anyone keeping a list of the solution or even the
problem. Even the basis are not done.
If you truly want to iterate on a solution, you should
start doing it and document it.

There *are* people doing it, e.g. systemd-shim, uselessd, nosh and
eudev, the refracta team, and others. There are so many projects, it's
hard to know where to join in, but I'm willing to help if I can.

Post by Ludovic Meyer

Post by Marty
Now you

can discuss for years in theory,

In fact, people have been discussing this problem for years.

And how did it change anything ? It didn't. So what make you think that
yet another year is gonna result in something ?

Right now Jessie is seems to have acceptable sysvinit support. The main
concerns seem to be about Stretch, but that's 3-4 years away, so I think
there's time to work on solutions.

Post by Ludovic Meyer
I do not want to be too critical, but that's the exact problem that the troll
in the Hobbit face, by discussing endless on how to cook the dwarfs, they
get petrified.
And maybe the time to test and get something wrong, as itcan hardly be slower
than discussing. The whole agile methodology.

Keep in mind this is a mostly volunteer project, with a lot of people
working in their spare time.

Post by Ludovic Meyer

Post by Marty
if this doesn't result in any practical

outcome, you have just stresstested the mailling lists software.

Until there's a rough consensus and a clear way forward, I don't
think many people will commit to specific solutions. There are also
unknowns like kdbus, to further complicate the matter.

"Talk is cheap", as Linus said.
You seems to be in favor of design by comitee, but this doesn't seems to work
for now.

I think small teams are the way to go in FOSS.

Post by Ludovic Meyer

Post by Marty

Post by Marty
People who just say, "write your own, it's all FOSS" are missing the
point, I think. Debian is not one guy working in his mom's basement.
It's one of the world's largest software projects. When Debian is
stumped, because its best developers and upstreams are caught in the
entanglement hairball, and see no clear way out, the it's clear case
of *Houston we have a problem.*

That's a interesting point, because with all those brillant minds,
a vast majority do not even seems to care about this
"entanglement hairball". Maybe it is time to admit you do not
know the whole details and accept that if developpers do not care,
then they are maybe right in doing so ?
Especially since you have been unable to give any technical reasons
to why you do not want it, and how you would proceed.

For you, I would start by explaining the Unix Philosophy and how it
http://en.wikipedia.org/wiki/Unix_philosophy

That's not a technical reason.

It's a philosophy, and not even the dominant one in the software
industry, but it is about technology and engineering, and part of the
culture and design of Debian. I recognize that it also clashes with the
"universal operating system" moniker, because the whole world is not
Unix, so I see a place in Debian for monolithic OSs like systemd and
Android clones, but I would have been more conservative about
introducing it.

Post by Ludovic Meyer

Post by Marty
Then I would proceed to explain how various aspects of systemd
conflict with this, causing said hairball. Finally, I would explain
(to the best of my ability) how the entanglement issue precludes a
quick resolution, and the delay does not indicate lack of interest.

And how would that be a technical reason ? If you disagree with the philosophy,
that's not a technical problem. That's just a opinion. Show a real technical issue,
not "here is the design decided 20 years ago and that was ignored by several others
components".

Design philosophies have major technical implications. If Debian had
started with Windows 3.1, I don't think the project would be where it is
today. Loose package coupling works well with volunteer projects. For
systemd to work in Debian it has to work within the existing modular
framework, and I think it can be done, with difficulty.

heck, even in 1989, people wrote "the unix hater handbook" to

Post by Ludovic Meyer
explain how the philosophy is wrong. For example, the example of cat not being
following this design anymore. No one throw a fuse over it, despites being
here, documented and visible by all since more than 20 years.

You forgot to include lispm and Plan 9. The ancient trappings are more
like relic than Interesting debate, but to me Unix Philosophy is just
the maxim “everything should be as simple as possible, but not simpler.”

Post by Ludovic Meyer
And I know Debian has popularized the idea of "release when it is ready", but that's
also the exact definition of vaporware. And people do not even have a estimation
of the work. Not knowing what solution to choose do not preclude from saying
the time one of them would take. In fact, it would even help to choose.

It's slow and messy, but you can't argue with success. I don't want a
poor man's OS-X, and I'm not waiting for the "year of the Linux
desktop." My desktop works fine (after I purge Gnome).

Post by Ludovic Meyer

Post by Marty

In fact, a quick google check would even give you the required
http://spootnik.org/entries/2014/11/09_pid-tracking-in-modern-init-systems.html
You can compare the code with "link to systemd library" vs "cut and
paste in every source code". As a exercise, you can
surely add "use dlopen()" and see which one is simpler and easier to maintain
in the long term.
Then it will be your turn to explain why it is better to cut and paste or
link statically the library, or why it is better to have to patch every upstream
to use dlopen().

Not sure how we went from entanglement issues to PID tracking, but
granting your point, it still doesn't explain how we arrive at kdb,
console and qcodes in PID 1. :)

Because the blog post say how and why stuff requires to be linked with systemd. As you didn't
explain what you mean by hairballs ( ie, what requires exactly you are speaking about )
it is hard to explain it. I am sure that if you were precise, it can be explained or
it could be seen as a bug.

Already done:
https://lists.debian.org/debian-ctte/2014/02/msg00447.html

debian-ctte, debian-vote and debian-devel may be the best lists to catch
up on the systemd debate.

Post by Ludovic Meyer

Post by Marty

And once you will have been able to justify that on a technical level,
maybe people will start to listen to you.
For the record, see also the discussion on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555980

You did not make much of a case for a complex PID 1 process

That was not my point. But you just did.

Post by Marty
and on
that question I defer to a kernel dev who takea a rather dim view of
it: http://lwn.net/Articles/618024/

- kernel is not the place for doing interprocess communication at the scale
required by systemd.
- dbus is not the right place either.
his point is that sending too much informations is gonna be a problem anyway.
Either by the kernel, or outside of the kernel.

Or solve the problem in a better way. I don't hear him saying there's no
solution.

Post by Ludovic Meyer
so the only way left is to not do IPC, so having everything in the same
process. So he is in fact in favor of having a complex process communicating
with himself and doing everything.

So he wants the opposite of unix philosophy and that is what the clash
with Debian is about, in a nutshell.

Post by Ludovic Meyer
We can see that in the design of the kernel, because of the original
design decision of not going the micro kernel way ( ie, minix, hurd )
by Linus, as documented in the debate between him and Andrew Tannenbaum.

If they improve their social skills they may get a workable solution.
Handling high-volume traffic is where the kernel shines.

Post by Ludovic Meyer
I would suggest, when you point to kernel developpers, to keep in mind that
they work on a big entangled code base, without any internal interface.
They kinda endorse that model, or would be working on the hurd. And that's because
people keep referring to Linus or others and at the same time complain
about systemd that some people do not take anti systemds crowd seriously.

Comparing anything in user space to the kernel seems like a stretch, but
I wish them luck. In the meantime tone down the "unified solution"
rhetoric because I don't think Debian is looking for a Linus to run the
project by proxy.

Post by Ludovic Meyer
The whole kernel design is monolithic, because there is a overhead of doing
the other way. So yeah, Al Viro point in favor of a more monolithic
and complex solution.

I think they may be regretting it now that the overhead is paid in
debugging hours, but Linux started as a hobby project, "nothing big and
professional like GNU."

And with that, I think I just set a personal record for longest post. :)

[Laurent Bigonville]

Le Fri, 14 Nov 2014 12:26:09 +0200,
[...]

Post by Andrei POPESCU

Post by Joel Rees
So Fedora is not, itself, really ready yet, except for two groups, a
certain group of workstation users who want and are willing to use
fairly new, relatively high-end hardware, including enough RAM and
processors to use VMs for certain things, and a certain group of
server-farm users who want and have budget for similarly recent,
relatively high-end hardware and lots of RAM and processors for lots
of VMs.
The rest of the Fedora users jumped ship.

Again, I can't comment on Fedora, but my Raspberry Pi runs systemd
just fine. Also my laptop running is quite far from being a speed
monster.

Also, different embedded projects (the Jolla phone, car board
computers,...) are already using or planning to use systemd.

[Joel Rees]

On Fri, Nov 14, 2014 at 7:26 PM, Andrei POPESCU

Post by Andrei POPESCU

Post by Joel Rees
[...]

[snip another wall of text about engineering principles]

And, thus, once again,

Post by Andrei POPESCU

Post by Joel Rees
The engineering question keeps getting sidetracked by people who
assert that we are talking about technical details, [...]

If you can't deal with it, snip it?

I don't think it becomes you, Andrei.
--
Joel Rees

Conspiracy? What conspiracy?
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

[Andrei POPESCU]

Post by Joel Rees
On Fri, Nov 14, 2014 at 7:26 PM, Andrei POPESCU

Post by Andrei POPESCU

Post by Joel Rees
[...]

[snip another wall of text about engineering principles]

And, thus, once again,

Post by Andrei POPESCU

Post by Joel Rees
The engineering question keeps getting sidetracked by people who
assert that we are talking about technical details, [...]

If you can't deal with it, snip it?

I don't think it brings anything useful to a discussion on -user. That's
much more suitable for some <init-systemd>-devel list.

Kind regards,
Andrei

[Joel Rees]

On Sat, Nov 15, 2014 at 8:51 PM, Andrei POPESCU

Post by Andrei POPESCU

Post by Joel Rees
On Fri, Nov 14, 2014 at 7:26 PM, Andrei POPESCU

Post by Andrei POPESCU

Post by Joel Rees
[...]

[snip another wall of text about engineering principles]

And, thus, once again,

Post by Andrei POPESCU

Post by Joel Rees
The engineering question keeps getting sidetracked by people who
assert that we are talking about technical details, [...]

If you can't deal with it, snip it?

I don't think it brings anything useful to a discussion on -user. That's
much more suitable for some <init-systemd>-devel list.

Re-read the wall of text you deleted, then think again about this suggestion.

If you still don't see how this suggestion is a short-circuit to
ground for objections, I've written a bit more colorfully on the
subject on my general blog, maybe you would care to re-read that as
well.

There's something in this question that is actually entangled in the
difference between declarative and procedural programming, but I can't
really talk with you about it until you start digging in to one or the
other.
--
Joel Rees

Living without understanding programming
is kind of like playing poker without understanding statistics.

[Chris Bannister]

Post by Joel Rees
On Sat, Nov 15, 2014 at 8:51 PM, Andrei POPESCU

Post by Andrei POPESCU

Post by Joel Rees
If you can't deal with it, snip it?

I don't think it brings anything useful to a discussion on -user. That's
much more suitable for some <init-systemd>-devel list.

Re-read the wall of text you deleted, then think again about this suggestion.

Or even the off-topic list, if anyone is interested.
--
"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

[Tanstaafl]

Post by Andrei POPESCU
It was claimed that sysvinit was the default *and only* (emphasis not
mine) init, and therefore no selection was needed, but now that there
are several a selection suddenly is needed.

I don't recall claiming that sysvinit was the *only* init, nor do I
recall anyone else making such a claim.

I merely pointed out that it was the *default* for many, many years
(actual time unknown and googling didn't easily reveal it).

Post by Andrei POPESCU
I was just pointing out that alternatives were indeed available, for
quite some time,

Yes, but obviously no one was switching often enough for any bugs to
allow for easy switching to be opened/scratched.

My very simple point is and has been that, *because* the *default* init
system for debian has been sysvinit since anyone can apparently
remember, the very act of even *suggesting* that it be switched in
jessie to not only a *different*, but a (relatively) *very new* one,
should have invoked a very simple requirement - for which the
responsibility for implementation and maintenance would be on those
calling for the switch - to provide a means for easily switching back
and forth so that everyone else could easily test things, and
ultimately, after the release of jessie with the new default, provide a
means to easily choose the previous default installer at both update
*and* install time, and maintain such at *least* during the life of the
jessie (if not jessie+1).

Post by Andrei POPESCU
it's just that maintainers and users of alternate inits did not yell
at the sysvinit maintainers to implement the choice for them.

And I would argue that the number of people who did switch was probably
miniscule, with respect to the entire debian user base.

[Joel Rees]

Post by Tanstaafl

Post by Andrei POPESCU
It was claimed that sysvinit was the default *and only* (emphasis not
mine) init, and therefore no selection was needed, but now that there
are several a selection suddenly is needed.

I don't recall claiming that sysvinit was the *only* init, nor do I
recall anyone else making such a claim.
I merely pointed out that it was the *default* for many, many years
(actual time unknown and googling didn't easily reveal it).

Post by Andrei POPESCU
I was just pointing out that alternatives were indeed available, for
quite some time,

Yes, but obviously no one was switching often enough for any bugs to
allow for easy switching to be opened/scratched.
My very simple point is and has been that, *because* the *default* init
system for debian has been sysvinit since anyone can apparently
remember, the very act of even *suggesting* that it be switched in
jessie to not only a *different*, but a (relatively) *very new* one,
should have invoked a very simple requirement - for which the
responsibility for implementation and maintenance would be on those
calling for the switch - to provide a means for easily switching back
and forth so that everyone else could easily test things, and
ultimately, after the release of jessie with the new default, provide a
means to easily choose the previous default installer at both update
*and* install time, and maintain such at *least* during the life of the
jessie (if not jessie+1).

Post by Andrei POPESCU
it's just that maintainers and users of alternate inits did not yell
at the sysvinit maintainers to implement the choice for them.

And I would argue that the number of people who did switch was probably
miniscule, with respect to the entire debian user base.

And maybe we can tie some points together here:

Those who have switched init systems without install-level support from the
debian community have generally not made claims like, "It worked for me, so
why should you complain if I try really hard to see that you end up
switching, too, without having a chance to get ready, much less choose?"

--
Joel Rees

[Andrei POPESCU]

Post by Tanstaafl

Post by Andrei POPESCU
It was claimed that sysvinit was the default *and only* (emphasis not
mine) init, and therefore no selection was needed, but now that there
are several a selection suddenly is needed.

I don't recall claiming that sysvinit was the *only* init, nor do I
recall anyone else making such a claim.

https://lists.debian.org/debian-user/2014/11/msg00814.html
Maybe a language issue? (I'm not a native speaker).

Post by Tanstaafl
My very simple point is and has been that, *because* the *default* init
system for debian has been sysvinit since anyone can apparently
remember, the very act of even *suggesting* that it be switched in
jessie to not only a *different*, but a (relatively) *very new* one,
should have invoked a very simple requirement - for which the
responsibility for implementation and maintenance would be on those
calling for the switch - to provide a means for easily switching back
and forth so that everyone else could easily test things, and
ultimately, after the release of jessie with the new default, provide a
means to easily choose the previous default installer at both update
*and* install time, and maintain such at *least* during the life of the
jessie (if not jessie+1).

For fresh installs, given that there is a suitable[1] workaround the
incentive to fix the bug[2] so late in the release cycle is low, as it
might introduce other breakage.

[1] so far the only claims against that workaround have been of the sort
"I don't want systemd anywhere near my systems", without actual proof of
something going wrong.

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001

For dist-upgrades, even assuming systems will be switched automatically
(which is still undecided):

- one can prevent switching by installing sysvinit-core before the
dist-upgrade step
- the sysvinit package contains the binary /lib/sysvinit/init which can
be used with the init= kernel parameter
- there is a grub patch[3] pending integration[4] to offer an
alternative sysvinit boot option

[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757298
[4] https://lists.debian.org/debian-ctte/2014/10/msg00057.html

The transition plan[5] has been posted on -devel since July with no
objections.

[5] https://lists.debian.org/debian-devel/2014/07/msg00611.html

Kind regards,
Andrei

[Joel Rees]

On Sat, Nov 15, 2014 at 9:20 PM, Andrei POPESCU

[(clipping too much, I now realize)]
The transition plan[5] has been posted on -devel since July with no
objections.
[5] https://lists.debian.org/debian-devel/2014/07/msg00611.html

My impression is that objections logged to that thread, had there been
any, would have been to the method or timing, not to the switch
itself.

In other words, members of dev who disagreed to the switch itself
would have needed a different thread to register their continued
disagreement.

And I am under the impression that there was an undercurrent of
"object to this and lose your geek cred."
--
Joel Rees

There is one conspirator against you,
that has not changed.
The only question is whether you will participate
or turn your back to it.

[Andrei POPESCU]

Post by Joel Rees
On Sat, Nov 15, 2014 at 9:20 PM, Andrei POPESCU

[(clipping too much, I now realize)]
The transition plan[5] has been posted on -devel since July with no
objections.
[5] https://lists.debian.org/debian-devel/2014/07/msg00611.html

My impression is that objections logged to that thread, had there been
any, would have been to the method or timing, not to the switch
itself.
In other words, members of dev who disagreed to the switch itself
would have needed a different thread to register their continued
disagreement.

In my impression Debian is most of the times much *less* formalised than
this.

What is actually quite frustrating in this particular case (for me as an
outsider, can't even imagine how it is for people directly involved) is
how people don't engage in such a thread, but instead escalate to the TC
and/or GR directly.

Post by Joel Rees
And I am under the impression that there was an undercurrent of
"object to this and lose your geek cred."

Definitely doesn't match my impression.

Kind regards,
Andrei

[Joel Rees]

Post by Andrei POPESCU

Post by Joel Rees
On Sat, Nov 15, 2014 at 9:20 PM, Andrei POPESCU

[(clipping too much, I now realize)]
The transition plan[5] has been posted on -devel since July with no
objections.
[5] https://lists.debian.org/debian-devel/2014/07/msg00611.html

My impression is that objections logged to that thread, had there been
any, would have been to the method or timing, not to the switch
itself.
In other words, members of dev who disagreed to the switch itself
would have needed a different thread to register their continued
disagreement.

In my impression Debian is most of the times much *less* formalised than
this.
What is actually quite frustrating in this particular case (for me as an
outsider, can't even imagine how it is for people directly involved) is
how people don't engage in such a thread, but instead escalate to the TC
and/or GR directly.

Post by Joel Rees
And I am under the impression that there was an undercurrent of
"object to this and lose your geek cred."

Definitely doesn't match my impression.

Well, Brian posted a link to a repurposed graphic of the waiting forever
meme.

And Dimitrios posted a link to a use case that is, indeed, not well covered
by the _current_ (as of the freeze) systemd package.

Sure, if you know the trick, you can get it to go, with some compromise.
Have to encrypt root too or something equally counterintuitive. And I'm
sure they'll get that fixed, too, put the documentation in, get plymouth
set up to no longer be just a splash screen by default, instruct everyone
to encrypt their root partitions or whatever the other part was. Maybe
after the freeze they get whatever requires that second part fixed as well.

What they are selling is a solution to everyone's problems, and they way it
works is that they
provide a solution after we find the problem.

That is not substantially different from the way it was with sysvinit,
except now the systemd crowd are the go-to guys for all things init, where,
before, you had the expertise spread out. There wasn't a single group.

We teach them and they become our experts.

And it works as long as everyone will just do it their way.

Renaud's sig had a rather interesting quote from Simon Bolivar a few posts
up.

Joel Rees

[Tanstaafl]

Post by Andrei POPESCU

Post by Tanstaafl

Post by Andrei POPESCU
It was claimed that sysvinit was the default *and only* (emphasis not
mine) init, and therefore no selection was needed, but now that there
are several a selection suddenly is needed.

I don't recall claiming that sysvinit was the *only* init, nor do I
recall anyone else making such a claim.

https://lists.debian.org/debian-user/2014/11/msg00814.html
Maybe a language issue? (I'm not a native speaker).

Nope, that was me and I actually did say it... weird that I didn't
remember saying that... but it doesn't really change anything...

Just because other init systems exist doesn't mean they were actually
being used, other than maybe just someone toying around.

Are you seriously suggesting that anything other than a tiny and
insignificant fraction were using anything other than sysvinit (until
systemd came along at least)?

Post by Andrei POPESCU
For fresh installs, given that there is a suitable[1] workaround

<sigh>

how many times does it have to be said - that is not a workaround for a
CLEAN INSTALL.

Post by Andrei POPESCU
For dist-upgrades, even assuming systems will be switched automatically
- one can prevent switching by installing sysvinit-core before the
dist-upgrade step
- the sysvinit package contains the binary /lib/sysvinit/init which can
be used with the init= kernel parameter
- there is a grub patch[3] pending integration[4] to offer an
alternative sysvinit boot option

Yes, and how long after upgrading to jessie staying with sysvinit until
things start breaking (most likely subtle breakage, which is the least
desirable on a server).

Post by Andrei POPESCU
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757298
[4] https://lists.debian.org/debian-ctte/2014/10/msg00057.html
The transition plan[5] has been posted on -devel since July with no
objections.

Maybe because most debian *users* don't follow the dev list because they
aren't devs...

[Ludovic Meyer]

Post by Tanstaafl

Post by Andrei POPESCU

Post by Tanstaafl

Post by Andrei POPESCU
It was claimed that sysvinit was the default *and only* (emphasis not
mine) init, and therefore no selection was needed, but now that there
are several a selection suddenly is needed.

I don't recall claiming that sysvinit was the *only* init, nor do I
recall anyone else making such a claim.

https://lists.debian.org/debian-user/2014/11/msg00814.html
Maybe a language issue? (I'm not a native speaker).

Nope, that was me and I actually did say it... weird that I didn't
remember saying that... but it doesn't really change anything...

That's a attempt at moonlighting people, not very classy.

Post by Tanstaafl
Just because other init systems exist doesn't mean they were actually
being used, other than maybe just someone toying around.
Are you seriously suggesting that anything other than a tiny and
insignificant fraction were using anything other than sysvinit (until
systemd came along at least)?

Post by Andrei POPESCU
For fresh installs, given that there is a suitable[1] workaround

<sigh>
how many times does it have to be said - that is not a workaround for a
CLEAN INSTALL.

Post by Andrei POPESCU
For dist-upgrades, even assuming systems will be switched automatically
- one can prevent switching by installing sysvinit-core before the
dist-upgrade step
- the sysvinit package contains the binary /lib/sysvinit/init which can
be used with the init= kernel parameter
- there is a grub patch[3] pending integration[4] to offer an
alternative sysvinit boot option

Yes, and how long after upgrading to jessie staying with sysvinit until
things start breaking (most likely subtle breakage, which is the least
desirable on a server).

The distinction server/desktop is clearly not relevent. There is huge deployment
of Debian desktop, and they do not want subtle breakage anymore than others people.

Now, if there is breakage ( so far, you speak of the future ), it will be because
no one detected them in the first place, and given the Debian structure,
that mean that not enough people were using that setup on testing and/or unstable.
For this, there is a few fixes :
- find people to test that ( starting by yourself ). If half of the people who rant since a few months
on this list were doing tests and filling bug report, this would be rock solid.
- automate that testing ( Ubuntu has a lot of ressources on the topic https://wiki.ubuntu.com/Testing/Automation
and so does OpenSuse ).
- make sure that bugfixes are propagated faster to stable and provides patches and or bugs when stable is here.

Now of course, if no one take time to do any of theses, that's gonna cause problem. But that's
a problem because people who want the work to happen do not make it happen. ( and no "we do not
have time", if people have time to post on ml, they have time to post bug reports ).

Post by Tanstaafl

Post by Andrei POPESCU
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757298
[4] https://lists.debian.org/debian-ctte/2014/10/msg00057.html
The transition plan[5] has been posted on -devel since July with no
objections.

Maybe because most debian *users* don't follow the dev list because they
aren't devs...

At the same time, most debian users likely do not really care about transition
plan and systemd. It was widely published everywhere in March and yet, no one would have cared if this
mattered ?
And those that care should make the efforts to follow what happen in the distribution, reading
one or two time a week the title on a web archive is not a huge time investment.
( at least not more than following this lists and answering on it )

[Chris Bannister]

Post by Ludovic Meyer
At the same time, most debian users likely do not really care about transition
plan and systemd. It was widely published everywhere in March and yet, no one would have cared if this
mattered ?

I installed systemd to Jessie as soon as it was announced. No problems so
far. I'm happy. :) Ric

Me too. A slight glitch at the start, but easily fixed. Everything
running smooth as!
--
"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

[Joel Rees]

One thing at a time.

[...]
Your definition of mainstream is strange.

What's strange about it? Do I need to provide a link to the dictionary
for you for that? I assume not.

Given a community, there is a mainstream within that community.

We have a community of users of Linux-kernel OSses that provide,
without excessive effort, command-line shells, full C compiler suites,
administrator access to the device owner, etc.

(Sure, Android has No-root Debian and Terminal-IDE, but those are
third-party apps and don't give true administrator access. The sdk is
not something mainstream Android users can figure out without a lot of
effort, and takes a separate machine. Thus, Android is outside the
domain of discussion, and I shouldn't have had to explain why. Unless
you think that Linux OSses should start limiting the device owner from
doing things like adding users and changing the unit infrastructure,
in which case, the reason we can't communicate is clear.)

Now, you note that Fedora claims in the range of a million users. Even
if their estimates are an order of magnitude high, that's hundreds of
thousands.

How can that not be mainstream?

Or are you under the misapprehension that there is only one
mainstream? Fedora and Debian are the mainstreams of what most of us
consider the Linux community. (Ubuntu being part of the greater Debian
community and Cent being part of the greater Fedora community.)

Now, before you throw up any more quibbles, what I am talking about
when I say mainstream users is those users who have not specifically
chosen to be part of an experiment who are being dragged into an
experiment.

Except you'll now point out that Fedora is the "cutting edge" of Red
Hat's stuff, which is ignoring the issue. And Fedora has rawhide, and
Debian has sid, which is ignoring the issue.

sid is locked into the future of stable, just like Rawhide is locked
into the future of Fedora. The release schedule does not allow for
major changes to be unrolled easily. Anything that gets accepted into
sid and passes into testing gets into stable, unless a lot of people
get excited during the testing phase.

Now, is systemd a major change or isn't it?

If you ask Poettering when he wants to sell systemd, it's a MAJOR
improvement. If you ask systemd proponents when they are sandbagging,
NO! NO! It's NOT a major change. (Sorry about the shouting, I'm just
describing how it looks to me. It does look like you guys are being
emphatic.)

If it's a major change, it needs more time, and, I'm asserting, the
special handling of a temporary parallel fork.

If it's not a major change, why do we have problems like the problem
of installing other inits?

[...]

--
Joel Rees

Be careful when you look at conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself, as well.

[Ludovic Meyer]

Post by Joel Rees
One thing at a time.

[...]
Your definition of mainstream is strange.

What's strange about it? Do I need to provide a link to the dictionary
for you for that? I assume not.
Given a community, there is a mainstream within that community.

Well, the point is "what is the community" exactly. Not the community in general
but the community you are refering.

As it could be "debian users", "all regular linux distro users" ( by
regular, I mean desktop/server ), or all linux users ( ie counting embedded
appliance ? ), or do we count android as well ?

if we go just by the number, do we count users or
systems, especially in the light of amazon/yahoo/google/facebook
server, who likely have combined more server than there is desktop users
of linux ( see a estimation in 2009
http://www.datacenterknowledge.com/archives/2009/05/14/whos-got-the-most-web-servers/ )

Post by Joel Rees
We have a community of users of Linux-kernel OSses that provide,
without excessive effort, command-line shells, full C compiler suites,
administrator access to the device owner, etc.

So your definition is the community of people who are root on a linux system.
No problem, but that's not exactly clear.

Post by Joel Rees
(Sure, Android has No-root Debian and Terminal-IDE, but those are
third-party apps and don't give true administrator access. The sdk is
not something mainstream Android users can figure out without a lot of
effort, and takes a separate machine. Thus, Android is outside the
domain of discussion, and I shouldn't have had to explain why. Unless
you think that Linux OSses should start limiting the device owner from
doing things like adding users and changing the unit infrastructure,
in which case, the reason we can't communicate is clear.)
Now, you note that Fedora claims in the range of a million users. Even
if their estimates are an order of magnitude high, that's hundreds of
thousands.
How can that not be mainstream?

Sure, so then Debian waited 3 years after the systemd hit the mainstream,
if you consider Fedora to be mainstream.

Therefore, your request of waiting was fullfilled.

Post by Joel Rees
Or are you under the misapprehension that there is only one
mainstream? Fedora and Debian are the mainstreams of what most of us
consider the Linux community. (Ubuntu being part of the greater Debian
community and Cent being part of the greater Fedora community.)

You have been using the word as singular, so I was wondering which one you
have been using. So based on the definition everybody will understand, Linux
itself not being mainstream

Post by Joel Rees
Now, before you throw up any more quibbles, what I am talking about
when I say mainstream users is those users who have not specifically
chosen to be part of an experiment who are being dragged into an
experiment.

The whole free software movement is mostly experiments.
Experiment in the governance at the internet age, in term of software
methodology, in term of research. There is people trying
new things. The kernel itself is always evolving,
getting new features, etc.

Post by Joel Rees
Except you'll now point out that Fedora is the "cutting edge" of Red
Hat's stuff, which is ignoring the issue. And Fedora has rawhide, and
Debian has sid, which is ignoring the issue.
sid is locked into the future of stable, just like Rawhide is locked
into the future of Fedora. The release schedule does not allow for
major changes to be unrolled easily. Anything that gets accepted into
sid and passes into testing gets into stable, unless a lot of people
get excited during the testing phase.
Now, is systemd a major change or isn't it?
If you ask Poettering when he wants to sell systemd, it's a MAJOR
improvement. If you ask systemd proponents when they are sandbagging,
NO! NO! It's NOT a major change. (Sorry about the shouting, I'm just
describing how it looks to me. It does look like you guys are being
emphatic.)

It depend on how you measure it. Number of impacted packages ? Number
of impacted users ? Change of the name of the software, versionning ?
Debian did switch to parralel init, was it a major change ( as it
required to fix all initscript for lsb )

Gnome 3, kde 4, grub2, was it major change ?
Xfree to xorg ? Glibc to eglibc ?
Linux 2.0 to 2.2 to 2.4 ?

Why none of this had a alternative ?

There is lots of major change anytime and since the start of Debian.
And again, you keep using word as if it was ginving any meaning to what you propose
but there is no actionable items at all.

Post by Joel Rees
If it's a major change, it needs more time, and, I'm asserting, the
special handling of a temporary parallel fork.

You mean like it was the case in the previous stable, where systemd was
present but not as default ?

And you say "more time", how much more time ?
If that's not time based, what are the criteria, what are the bug that
should be solved before saying "this cannot be done". And why aren't they
listed as RC bugs ? And if you do not have those bugs, why aren't you
looking for them, instead of asserting they exist without showing any
proof ?

Post by Joel Rees
If it's not a major change, why do we have problems like the problem
of installing other inits?

Sure, care to give a bug report or that's just some fluffy "there is
problem but I cannot say what" ?

--
l.

[The Wanderer]

I have been informed off-list that some might misinterpret
something I wrote here, so I will attempt to clarify a few things.

Post by Joel Rees
This all would have been okay for them, if they had followed
proper engineering (management) principles. As long as they were
an independent maverick, they could do what they want. That was
correct, that was good.

I want to repeat that. As long as they kept their work out of the
mainstream, it was no problem.

Your definition of mainstream is strange. So far, I didn't see
systemd being on something else than Linux, and GNU/Linux is not
mainstream ( android is, but systemd is out of android ).
So they kept it out of mainstream, unless you define mainstream as
"being used by users", in which way I would love to see how you get
user feedback without having users in the first place.

I suspect that he meant "the mainstream of Linux", which is reasonable
considering the scope of the discussion.

They could refine their API as they went and the repercussions were
limited to their own source tree. That means they could redefine
the API as necessary without interfering with the day-to-day
operations of thousands, or even hundreds of thousands of users.
The more users you have, the harder it is to fix an API error.

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
now, the linux kernel do not have such table, and prevent anyone
from writing a out of kernel module due to that, despites requests.

One important distinction:

The Linux kernel recognizes and maintains a separation between internal
and external interfaces.

They refuse to stabilize and fix on, or I think even particularly to
document (beyond the source code itself), the internal interfaces. Doing
so would constrain them from making structural and design improvements
when and as they think that is necessary.

They do, however, maintain their external interfaces - rigidly so,
sometimes to what others might call the point of insanity. An
intentionally user-visible API from the Linux kernel will essentially
never change, and if an exception to that is ever made, it will be
announced *years* in advance. That is one reason why they try to be
*VERY* careful to get the user-facing interface "right", at least on
some basic level, before ever pulling it into a released kernel.

The kernel interfaces which kernel modules need to use are
kernel-internal interfaces.

The systemd interfaces described on the page you link to appear to be
systemd-external interfaces.

[Ludovic Meyer]

Post by The Wanderer

I have been informed off-list that some might misinterpret
something I wrote here, so I will attempt to clarify a few things.

Post by Joel Rees
This all would have been okay for them, if they had followed
proper engineering (management) principles. As long as they were
an independent maverick, they could do what they want. That was
correct, that was good.

I want to repeat that. As long as they kept their work out of the
mainstream, it was no problem.

Your definition of mainstream is strange. So far, I didn't see
systemd being on something else than Linux, and GNU/Linux is not
mainstream ( android is, but systemd is out of android ).
So they kept it out of mainstream, unless you define mainstream as
"being used by users", in which way I would love to see how you get
user feedback without having users in the first place.

I suspect that he meant "the mainstream of Linux", which is reasonable
considering the scope of the discussion.

Sure, and what does he mean by that ?

because I suspect also that Android, being Linux based, is not the mainstream
he is speaking about. So is Debian more mainstream that Ubuntu ? Is Debian
more mainstream than Mageia or Opensuse ?

if he want to be clearly understood, and I think we all want that, he must
be a bit more clearer in what he say.

Post by The Wanderer

They could refine their API as they went and the repercussions were
limited to their own source tree. That means they could redefine
the API as necessary without interfering with the day-to-day
operations of thousands, or even hundreds of thousands of users.
The more users you have, the harder it is to fix an API error.

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
now, the linux kernel do not have such table, and prevent anyone
from writing a out of kernel module due to that, despites requests.

The Linux kernel recognizes and maintains a separation between internal
and external interfaces.
They refuse to stabilize and fix on, or I think even particularly to
document (beyond the source code itself), the internal interfaces. Doing
so would constrain them from making structural and design improvements
when and as they think that is necessary.

I know the arguments, but this doesn't contradict the fact that there is
demand for such interfaces. This is also something that windows, solaris
or mac osx offer, and that help hardware vendors to support
their systems, and companies to offer software (firewall, antivirus
are the example that came to mind, but i am not dealing with
windows anymore).

Now, that's indeed a costly approach due to the reduced agility,
and while I am sure this can be surely automated, I can see why
kernel coders do not want to take care of that ( coders in general
would prefer not care of boring stuff and constraints, as we
can see in the free software world, who is hard to consume unless you
have group between users and coders to make thing usable ).

Post by The Wanderer
They do, however, maintain their external interfaces - rigidly so,
sometimes to what others might call the point of insanity. An
intentionally user-visible API from the Linux kernel will essentially
never change, and if an exception to that is ever made, it will be
announced *years* in advance. That is one reason why they try to be
*VERY* careful to get the user-facing interface "right", at least on
some basic level, before ever pulling it into a released kernel.
The kernel interfaces which kernel modules need to use are
kernel-internal interfaces.
The systemd interfaces described on the page you link to appear to be
systemd-external interfaces.

I know the difference, and
I know this is just some tradeoff, there is advantages and
disadvantages on doing that, and if I was cynical, I would
postulate that companies like redhat do push for that model of internal/external
interfaces in the kernel, because this give a reason to take
entreprise distributions. ( ie, SLES, RHEL do have a stable promise API
for each release like Windows do, because customers do pay also for that )

My point is not that kernel or systemd devs are right or wrong.
But the point is that people who complain that systemd do not have a internal
interface yet forget that kernel do not have one since the start and will not have
in a near future.

And this, despites having (IMHO) a bigger need for
a internal interface of the kernel than one for systemd.
By bigger needs, I mean that there is a lot more of people wanting to
have out of tree modules, while I guess we wouldn't see more than 5
differents reimplementation of some systemd components.
( and again, having people wanting a internal interface doesn't mean they
should have one, if kernel devs prefer their freedom to innovate, that's
their privileges ).

So yes, systemd do have the same policy as kernel, except no one
write huge wall of text about kernel devs attitude and policy anymore,
and even celebrate them.

[The Wanderer]

[about the Linux kernel developers]

Post by The Wanderer
They do, however, maintain their external interfaces - rigidly so,
sometimes to what others might call the point of insanity. An
intentionally user-visible API from the Linux kernel will
essentially never change, and if an exception to that is ever made,
it will be announced *years* in advance. That is one reason why
they try to be *VERY* careful to get the user-facing interface
"right", at least on some basic level, before ever pulling it into
a released kernel.
The kernel interfaces which kernel modules need to use are
kernel-internal interfaces.
The systemd interfaces described on the page you link to appear to
be systemd-external interfaces.

I know the difference, and I know this is just some tradeoff, there
is advantages and disadvantages on doing that, and if I was cynical,
I would postulate that companies like redhat do push for that model
of internal/external interfaces in the kernel, because this give a
reason to take entreprise distributions. ( ie, SLES, RHEL do have a
stable promise API for each release like Windows do, because
customers do pay also for that )
My point is not that kernel or systemd devs are right or wrong. But
the point is that people who complain that systemd do not have a
internal interface yet forget that kernel do not have one since the
start and will not have in a near future.

Er... were people complaining that systemd does not have a stable
internal interface?

I thought (given the context of that linked-to page) that the complaint
was that systemd does not have a stable *external* interface.

With possible room for dispute about what constitutes an "interface",
what qualifies as "stable", and maybe even what counts as "internal" vs.
"external"... but I didn't see anything that I recognized as being a
complaint about systemd's internal interfaces.

No one is even trying to implement something outside of the systemd
project that talks to systemd's internal interfaces directly, AFAIK -
unless systemd-shim does, but I didn't think systemd-shim talked to
systemd itself at all, just to other tools provided by the systemd
project.

And if the interfaces which those tools use to talk to
systemd-the-init-system are considered "internal" interfaces, which is a
position for which an argument could be made, then that would simply
bring up the argument that since those are separate tools the interfaces
between them should be considered external to each tool. Whether or not
that's a reasonable argument, and the extent to which it might be
possible to treat those interfaces that way, could be a discussion worth
having - but having it would require *getting* to that point first.

[Ludovic Meyer]

Post by The Wanderer
[about the Linux kernel developers]

Post by The Wanderer
They do, however, maintain their external interfaces - rigidly so,
sometimes to what others might call the point of insanity. An
intentionally user-visible API from the Linux kernel will
essentially never change, and if an exception to that is ever made,
it will be announced *years* in advance. That is one reason why
they try to be *VERY* careful to get the user-facing interface
"right", at least on some basic level, before ever pulling it into
a released kernel.
The kernel interfaces which kernel modules need to use are
kernel-internal interfaces.
The systemd interfaces described on the page you link to appear to
be systemd-external interfaces.

I know the difference, and I know this is just some tradeoff, there
is advantages and disadvantages on doing that, and if I was cynical,
I would postulate that companies like redhat do push for that model
of internal/external interfaces in the kernel, because this give a
reason to take entreprise distributions. ( ie, SLES, RHEL do have a
stable promise API for each release like Windows do, because
customers do pay also for that )
My point is not that kernel or systemd devs are right or wrong. But
the point is that people who complain that systemd do not have a
internal interface yet forget that kernel do not have one since the
start and will not have in a near future.

Er... were people complaining that systemd does not have a stable
internal interface?
I thought (given the context of that linked-to page) that the complaint
was that systemd does not have a stable *external* interface.

I think it does. The real question is
- is this interface sufficient
- is the boundary the one we agree on

Post by The Wanderer
With possible room for dispute about what constitutes an "interface",
what qualifies as "stable", and maybe even what counts as "internal" vs.
"external"... but I didn't see anything that I recognized as being a
complaint about systemd's internal interfaces.

Let's take the one about logind. What people complain is that
logind requires systemd as pid1, and the reason about this is because
logind requires the internal and non stable interface of systemd, otherwise,
someone would be able to run it with another init, provided it implement the stable
interface (this particular interface that do not exist).

Or people do complain they cannot replace or remove journald. Again, because
there is no separation between the 2, because there is no documented
separation ie a external interface. I hope this clarify my point, but we seems to
agree on this, if I read well what you said just after.

Post by The Wanderer
No one is even trying to implement something outside of the systemd
project that talks to systemd's internal interfaces directly, AFAIK -
unless systemd-shim does, but I didn't think systemd-shim talked to
systemd itself at all, just to other tools provided by the systemd
project.
And if the interfaces which those tools use to talk to
systemd-the-init-system are considered "internal" interfaces, which is a
position for which an argument could be made, then that would simply
bring up the argument that since those are separate tools the interfaces
between them should be considered external to each tool. Whether or not
that's a reasonable argument, and the extent to which it might be
possible to treat those interfaces that way, could be a discussion worth
having - but having it would require *getting* to that point first.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw