Discussion:
I wonder… why systemd provokes this amount of polarity and resistance
(too old to reply)
Martin Steigerwald
2014-09-21 13:31:15 UTC
Permalink
Hello!

I know this is a daring post.

I just have one question. In the light of

http://boycottsystemd.org/

http://uselessd.darknedgy.net/

developing some systemd compatible services for BSD:
http://undeadly.org/cgi?action=article&sid=20140915064856


in the light of

Debian Bug report logs - #727708
tech-ctte: Decide which init system to default to in Debian.
https://bugs.debian.org/727708


Debian Bug report logs - #746715
the foreseeable outcome of the TC vote on init systems
https://bugs.debian.org/bug=746715


in the light of the ongoing discussions on linux-kernel, debian-devel, debian-
user and other mailing lists more than some dozens threads meanwhile:

Did you ever ask yourself why your project provokes that amount of resistance
and polarity? Did you ever ask yourself whether this really is just resistance
against anything new from people who just do not like "new" or whether it
contains *valuable* and *important* feedback?


I am taking this upstream with you, cause I think too much of this is
resignately been discussed elsewhere, discussed elsewhere for as I got the
feedback on various occasions where I recommended to take feedback upstream
that people have no hope in having their feedback considered at all.


For now I use systemd. I like quite some features. But on the other hand I am
vary about it myself. I look at a 45 KiB binary for /sbin/init as PID1 and a
1,3 MiB binary in systemd 215 and wonder myself. I see systemd --user
processes running and wonder: Why does the user related stuff need to be in the
systemd binary. I had it that it didn´t mount an NFS export and while in the
end it was a syntax error in fstab that sysvinit happily ignored, I needed a
bug report and dev help to even find that cause. I wonder about the complexity
involved in one single large binary.

Well… its not about my thoughts about systemd, it is about my perception that
I never seen any free software upstream project creating this amount of
polarity and discussion in a decade or more.

Is it really all just nay-sayers for the sake of nay-saying? Or do they – at
least partly – provide *valuable* and *important* feedback.


That said I will continue to provide constructive bugreports for as long as
systemd is behaving for me on my systems, for as long as I want to give it a
chance to prove its benefits.

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Tom Gundersen
2014-09-21 21:52:37 UTC
Permalink
Post by Martin Steigerwald
I just have one question. In the light of
http://boycottsystemd.org/
Please note that this is just (to the best of my knowledge), the
misinformed rants of an anonymous individual (despite it appearing a
lot more serious due to the guy buying a domain).
Post by Martin Steigerwald
http://uselessd.darknedgy.net/
Hm, missing content?
Post by Martin Steigerwald
Debian Bug report logs - #746715
the foreseeable outcome of the TC vote on init systems
https://bugs.debian.org/bug=746715
"this package no longer exists" ?
Post by Martin Steigerwald
Did you ever ask yourself why your project provokes that amount of resistance
and polarity? Did you ever ask yourself whether this really is just resistance
against anything new from people who just do not like "new" or whether it
contains *valuable* and *important* feedback?
We occasinoally got some very critical feedback that is also very
good. However, when you look at the various "debates" in other forums
(such as the ones you mentioned), my impression is that it is almost
entirely useless noise. I.e., either people are complaining about
things that are based entirely on misconceptions, or they are
complaining about things that had a root in something reasonable once
upon a time, but have long since been either explained or fixed.
Post by Martin Steigerwald
I am taking this upstream with you, cause I think too much of this is
resignately been discussed elsewhere, discussed elsewhere for as I got the
feedback on various occasions where I recommended to take feedback upstream
that people have no hope in having their feedback considered at all.
If people bring useful and at least moderately civil feedback upstream
(i.e., technical feedback in terms of bug reports, questions, RFE's or
similar, not rants amounting to "please stop what you are doing and go
away"), we do take it very seriously, and answer them to the best of
our abilities. That does not mean that every patch is accepted, nor
every request is adhered to, but at least you should get an answer
with an explanation.

The only way to find out is to try though.
Post by Martin Steigerwald
For now I use systemd. I like quite some features. But on the other hand I am
vary about it myself. I look at a 45 KiB binary for /sbin/init as PID1 and a
1,3 MiB binary in systemd 215 and wonder myself.
systemd is a lot more powerful than sysvinit, and does take up more
space. We are not really optimizing the size of the binary, so if you
are interested in looking into making it smaller that's certainly
possible.
Post by Martin Steigerwald
I see systemd --user
processes running and wonder: Why does the user related stuff need to be in the
systemd binary.
This is rather the other way around: the problem solved by PID1, is
almost entirely the same as the problem that needs to be solved by the
user session manager, so we allow the same code to be reused. The
amount of code specific to user sessions in PID1 is really very small.
Post by Martin Steigerwald
I had it that it didn´t mount an NFS export and while in the
end it was a syntax error in fstab that sysvinit happily ignored, I needed a
bug report and dev help to even find that cause. I wonder about the complexity
involved in one single large binary.
PID1 does not parse your fstab, it is done by an external binary. That
said, if there is a lack of output when a malformed entry is found, we
should probably improve on that (I don't have the bug report in front
of me, but please open an RFE if you think this is still not ideal).
The reason we reject invalid fstab entries, is that we think it is
safer to fail hard if we cannot know for certain what the admin
intended to do. It is regrettable that this means that the transition
is not as smooth as it otherwise would be, but overall we believe it
is the correct thing to do.

Cheers,

Tom
Mantas Mikulėnas
2014-09-21 21:58:27 UTC
Permalink
Post by Tom Gundersen
Post by Martin Steigerwald
http://uselessd.darknedgy.net/
Hm, missing content?
Apparently someone attacked and wiped their website.

It's mostly a trimmed-down systemd fork:
https://bitbucket.org/bcsd/uselessd (or slashdot, phoronix, etc.)
Post by Tom Gundersen
Post by Martin Steigerwald
Debian Bug report logs - #746715
the foreseeable outcome of the TC vote on init systems
https://bugs.debian.org/bug=746715
"this package no longer exists" ?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746715
--
Mantas Mikulėnas <***@gmail.com>
Michael Biebl
2014-09-21 22:01:08 UTC
Permalink
Post by Tom Gundersen
Post by Martin Steigerwald
I had it that it didn´t mount an NFS export and while in the
end it was a syntax error in fstab that sysvinit happily ignored, I needed a
bug report and dev help to even find that cause. I wonder about the complexity
involved in one single large binary.
PID1 does not parse your fstab, it is done by an external binary. That
said, if there is a lack of output when a malformed entry is found, we
should probably improve on that (I don't have the bug report in front
of me, but please open an RFE if you think this is still not ideal).
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755506#25
Jóhann B. Guðmundsson
2014-09-21 22:15:32 UTC
Permalink
Post by Martin Steigerwald
in the light of the ongoing discussions on linux-kernel
Could you provide a link to that ongoing discussion that is taking place
in the kernel community regarding systemd?
Post by Martin Steigerwald
Did you ever ask yourself why your project provokes that amount of resistance
and polarity? Did you ever ask yourself whether this really is just resistance
against anything new from people who just do not like "new" or whether it
contains*valuable* and*important* feedback?
I'm not sure why you are under the assumption that we do not consider
and have not and are not gathering feedback from individuals,
communities or companies for that matter but I'm going to address your
questions anyway.

Have we ever asked ourselves why our project provokes that amount of
resistance and polarity?

The answer to that question is yes, yes we have and yes we will continue
to do so since resistance and polarity provides with the valuable
information amongst other things if the implementation is bad and
alternative approach is better ( which often reveals itself at the same
time those friction take place ).

Dont get me wrong we will not do so when those discussion involve
nothing but personal attack on our community member(s) which more often
than not happens to be Lennart, Lennart is and never has been the sole
person behind this effort, he's part of ever growing community.

Nor when it involves us having to implement somekind of hack as opposed
to have the problem properly fixed where it belongs ( which could be us
or not ) or when those discussion criticizes that we have chosen to
tightly integrate ourselves specifically to the linux kernel it's
ecosystem and with glibc in mind just like bsd based distribution as
well as solaris and other nixes are tightly integrating their components
to their kernels but for some dumbfound reason people on the internet
are under the assumption that they have the authority of refusing us the
freedom of doing the same o_O and the answer to those individuals we
dont care about their opinion on this matter.

Now alot of the resistance and polarity that is taking place like in the
url you pointed at is hiding itself behind their misinterpretation of
the so called "Unix philosophy" and claiming that we somehow fall short
on the guidelines originates from few things Doug McIlroy,Rob Pike,Ken
Thompson said sometime in the 70's or rather the "Unix philosophy" was
implied not by what these individuals said but rather by what they did
which more or less boils down to this..

1. Write simple parts connected by clean interfaces.
2. Clarity is better than cleverness.
3. Design programs to be connected to other programs.
4. Separate policy from mechanism; separate interfaces from engines.
5. Design for simplicity; add complexity only where you must.
6. Write a big program only when it is clear by demonstration that
nothing else will do.
7. Rule of Transparency: Design for visibility to make inspection and
debugging easier.
8. Robustness is the child of transparency and simplicity.
9. Fold knowledge into data so program logic can be stupid and robust.
10. In interface design, always do the least surprising thing.
11. When a program has nothing surprising to say, it should say nothing.
12. When you must fail, fail noisily and as soon as possible.
13. Programmer time is expensive; conserve it in preference to machine time.
14. Avoid hand-hacking; write programs to write programs when you can.
15. Prototype before polishing. Get it working before you optimize it.
16. Distrust all claims for “one true way”.
17. Design for the future, because it will be here sooner than you think.

Now after you have read these more of an guidelines than actual
philosophy I would like to hear from you where you think systemd has and
is falling short of them during it's development phase and lifetime so I
can better understand why people seem to be claiming it's not following
these guidelines?

That being said acceptance and approval are outweighing resistance and
polarity in the Linux ecosystem as things currently stand ( otherwise we
would not be so widely accepted and adopted ) because we are and
continue to solve real problems through close collaboration with wide
variety of upstream and distribution, In the long run freeing up
contributors time while doings so through the consolidation that takes
place while we are at it.

If you are wondering as well if we are against emerging alternative init
system like the one you refereed to, the answer to that question is no
we are not.

We welcome and embrace them and hope they evolve to the point they
become competing solution so we can continue to evolve ourselves ( or
advance beyond us and eventually replace us ) but being frank that wont
happen anytime soon.

Systemd has been what ca 7 years in the making now with what 5 of those
years being direct integration with wide variety of components and
distribution so this is not a simple matter of writing an new init
system, this is so much much more work which I dont think those new or
existing init project and it's developers realize.

Now just a word of advice...

You should take it with a grain of salt what alot anti-systemd sites or
individuals are saying on the interweb since more often than not those
things are based on misinformation ( like most recently on post on
linux.com "Red Hat is the inventor and primary booster of systemd," this
is false ) and since the internet is expert in spreading ignorance and
we can only fight back ignorance with enlightenment and we can only do
so with people that are willing to listen, which unfortunately more
often than not, these individuals will not.

With regards to anykind of anti systemd discussion taking place in wide
varity of Debians community mailinglists if I was you, I would simply
remind those individuals that an democratic voting has taken place
within the community and not accepting the outcome of that voting and
help in the process integrate systemd better into Debian ( which in turn
will result in feedback either there to here or directly here ) is an
utterly and total disrespect to it's community members and Debians
democracy ( from my stand point ).


JBG
Reindl Harald
2014-09-21 22:23:11 UTC
Permalink
Now alot of the resistance and polarity that is taking place like in the url you pointed at is hiding itself behind
their misinterpretation of the so called "Unix philosophy" and claiming that we somehow fall short on the
guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said sometime in the 70's or rather the
"Unix philosophy" was implied not by what these individuals said but rather by what they did which more or less
boils down to this..
11. When a program has nothing surprising to say, it should say nothing
then flood logs with nothing relevant should not happen
https://bugzilla.redhat.com/show_bug.cgi?id=1072368
https://bugzilla.redhat.com/show_bug.cgi?id=1053315

appeared the first time: 2014-01-14
reported: 2014-03-04
refused to fix: 2014-03-24
Jóhann B. Guðmundsson
2014-09-21 22:48:38 UTC
Permalink
Post by Reindl Harald
Now alot of the resistance and polarity that is taking place like in the url you pointed at is hiding itself behind
their misinterpretation of the so called "Unix philosophy" and claiming that we somehow fall short on the
guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said sometime in the 70's or rather the
"Unix philosophy" was implied not by what these individuals said but rather by what they did which more or less
boils down to this..
11. When a program has nothing surprising to say, it should say nothing
then flood logs with nothing relevant should not happen
https://bugzilla.redhat.com/show_bug.cgi?id=1072368
https://bugzilla.redhat.com/show_bug.cgi?id=1053315
?

I dont see the connection here systemd is informing you what
start/stopped when these cron job ran.

If you dont like it filter it and retrieve only the information you
want/need with journalctl.

JBG
Reindl Harald
2014-09-21 23:09:18 UTC
Permalink
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Now alot of the resistance and polarity that is taking place like in the url you pointed at is hiding itself
behind
their misinterpretation of the so called "Unix philosophy" and claiming that we somehow fall short on the
guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said sometime in the 70's or rather the
"Unix philosophy" was implied not by what these individuals said but rather by what they did which more or less
boils down to this..
11. When a program has nothing surprising to say, it should say nothing
then flood logs with nothing relevant should not happen
https://bugzilla.redhat.com/show_bug.cgi?id=1072368
https://bugzilla.redhat.com/show_bug.cgi?id=1053315
?
I dont see the connection here systemd is informing you what start/stopped when these cron job ran
with *that many* lines?

that information already exists in /var/log/secure and /var/log/cron
these lines are completly useless for a non-developer

consider that not refuse that often what a user wants to
see or not to see *as default* because as developer you
have other needs is one of the reasons *endusers* get
sometimes really angry
If you dont like it filter it and retrieve only the information you want/need with journalctl
if they would have a prefix i would filter them to nowhere in rsyslog

please understand that not everybody is using journalctl and if it
is only because using centralized logs in databases since long
before systemd was introduced
Jóhann B. Guðmundsson
2014-09-21 23:48:49 UTC
Permalink
Post by Reindl Harald
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Now alot of the resistance and polarity that is taking place like in the url you pointed at is hiding itself
behind
their misinterpretation of the so called "Unix philosophy" and claiming that we somehow fall short on the
guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said sometime in the 70's or rather the
"Unix philosophy" was implied not by what these individuals said but rather by what they did which more or less
boils down to this..
11. When a program has nothing surprising to say, it should say nothing
then flood logs with nothing relevant should not happen
https://bugzilla.redhat.com/show_bug.cgi?id=1072368
https://bugzilla.redhat.com/show_bug.cgi?id=1053315
?
I dont see the connection here systemd is informing you what start/stopped when these cron job ran
with *that many* lines?
The reason for increased log entries in the journal is that more things
are happening now since this is what happening when a job is run.
Post by Reindl Harald
that information already exists in /var/log/secure and /var/log/cron
these lines are completly useless for a non-developer
Irrelevant to us what is stored in text files so that needs to be
handled downstream.
Post by Reindl Harald
consider that not refuse that often what a user wants to
see or not to see *as default* because as developer you
have other needs is one of the reasons *endusers* get
sometimes really angry
Depends on personal preference and practices

Cron users already are divided into two religious notification groups.

Those that have cron job that send email that notifies every time that
it ran ( to know it ran ) and those that do not send an email unless the
job it was running failed and rely on logwatch to inform them if the
cron job ran or not.
Post by Reindl Harald
If you dont like it filter it and retrieve only the information you want/need with journalctl
if they would have a prefix i would filter them to nowhere in rsyslog
please understand that not everybody is using journalctl
Well this is upstream that ships nothing but journalctl whether they use
it or not.

JBG
Reindl Harald
2014-09-22 09:23:23 UTC
Permalink
Post by Jóhann B. Guðmundsson
The reason for increased log entries in the journal is that more things
are happening now since this is what happening when a job is run.
that don't change the fact that a user not acting as
systemd-developer and not debugging his system don't
need that flood

you need to distinct between users and developers
users want to have *abnormal* things logged and
not burried inside noise
Post by Jóhann B. Guðmundsson
Those that have cron job that send email that notifies every time that it ran ( to know it ran ) and those that do
not send an email unless the job it was running failed and rely on logwatch to inform them if the cron job ran or not.
Post by Reindl Harald
If you dont like it filter it and retrieve only the information you want/need with journalctl
if they would have a prefix i would filter them to nowhere in rsyslog
please understand that not everybody is using journalctl
Well this is upstream that ships nothing but journalctl whether they use it or not
then add at least *prefixes* to write filter rules
what you say is "we don't ship nothing but" and "we don't care about nothing but"

that is the reason for the polarity "we are upstream and don't care"
just give "journald.conf" a verbosity option and all are happy

honestly the messages about "reaching target" are nonsense without
a prefix pointing out that it is about a *user session* because it
looks like a bootlog every minute

Mar 4 13:01:01 rawhide systemd[1559]: Starting Paths.
Mar 4 13:01:01 rawhide systemd[1559]: Reached target Paths.
Mar 4 13:01:01 rawhide systemd[1559]: Starting Timers.
Mar 4 13:01:01 rawhide systemd[1559]: Reached target Timers.
Mar 4 13:01:01 rawhide systemd[1559]: Starting Sockets.
Mar 4 13:01:01 rawhide systemd[1559]: Reached target Sockets.
Mar 4 13:01:01 rawhide systemd[1559]: Starting Basic System.
Mar 4 13:01:01 rawhide systemd[1559]: Reached target Basic System.
Mar 4 13:01:01 rawhide systemd[1559]: Starting Default.
Mar 4 13:01:01 rawhide systemd[1559]: Reached target Default.
Mar 4 13:01:01 rawhide systemd[1559]: Startup finished in 9ms.
Jóhann B. Guðmundsson
2014-09-22 11:45:05 UTC
Permalink
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
The reason for increased log entries in the journal is that more things
are happening now since this is what happening when a job is run.
that don't change the fact that a user not acting as
systemd-developer and not debugging his system don't
need that flood
I guess we have different meaning of message flood
again: we talk about rsyslog, like it or not
Then file a bug report against rsyslog and provide a patch which fixes
the default log filtering in Fedora to your expectation but leave
systemd out of it.
what you filter below is what i have in /var/log/cron and /var/log/secure
but the other messages spit to the log are a lot more
here you have a simple calculation
https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8
why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368
and the workaround "loginctl enable-linger" leads to another bugreport
open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54
so what we have now is log flooding or hanging shutdowns
why don't upstream just what users would help and reduce logging
in a non-debug mode to a minimum so one can see without filter
if something unusal happens on a system?
if the developers would accept the need of their users then likely the users
would also be more positive, just don't explain me how to maintain my servers
i am fine with distribute-command.sh "cat /var/log/messages" all they
years because the general log is silent until something bad happens
you can't do that if systemd floods it for 30 machines
# journalctl -f
Sep 22 11:13:01 localhost.localdomain systemd[1]: Starting Session 59 of user johannbg.
Sep 22 11:13:01 localhost.localdomain systemd[1]: Started Session 59 of user johannbg.
Sep 22 11:13:01 localhost.localdomain CROND[7336]: (johannbg) CMD (/bin/systemd-cat -t "CROND" /bin/echo "Systemd
journal cron job log test every minute" )
Sep 22 11:13:01 localhost.localdomain CROND[7336]: Systemd journal cron job log test every minute
Hey let's filter this even further
# journalctl -f SYSLOG_IDENTIFIER=CROND
-- Logs begin at Thu 2013-10-24 11:47:22 GMT. --
Sep 22 11:14:01 localhost.localdomain CROND[7401]: (johannbg) CMD (/bin/systemd-cat -t "CROND" /bin/echo "Systemd
journal cron job log test every minute" )
Sep 22 11:14:01 localhost.localdomain CROND[7401]: Systemd journal cron job log test every minute
Anything regarding an text file and local and or remote logging using either rsyslog or syslog-ng is and it's
default is not relevant to us and usually set by distribution maintainers.
For remote logging I would assume administrator would create an cron filter which has the syslog identifier crond
or CROND, the syslog facility 9 and an priority 6 and send that to the remote server
So if systemd output is too much in any text file <-- file a bug against rsyslog or syslog-ng depending on which
the distribution and have *them* fix their default filtering
JBG
Reindl Harald
2014-09-22 12:07:41 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
The reason for increased log entries in the journal is that more things
are happening now since this is what happening when a job is run.
that don't change the fact that a user not acting as
systemd-developer and not debugging his system don't
need that flood
I guess we have different meaning of message flood
again: we talk about rsyslog, like it or not
Then file a bug report against rsyslog and provide a patch which fixes
the default log filtering in Fedora to your expectation but leave
systemd out of it.
wow - in any other case the systemd developers saying that
they don't workround things because problems has to be
solved at the root-cause - practice what you preach and
make the log-verbosility configureable!

* rsyslog is *not* responsible for the message flood produced by systemd
* systemd is the one producing it without prefixes

produce 80000 loglines noise on a small infrastructure is insane
that's the same all other services produce together

is it really that hard to accept that this level of informations
is only helpful for debugging, produces overhead if it could
be filtered away and anyways has the bad impact that journald
in rsyslog envoironments has the whole day to do with rotate

[Journal]
Storage=volatile
Compress=yes
RateLimitInterval=10s

frankly i have seen more or less idle machines where journald is
one of the top ressource consumers
Post by Jóhann B. Guðmundsson
what you filter below is what i have in /var/log/cron and /var/log/secure
but the other messages spit to the log are a lot more
here you have a simple calculation
https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8
why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368
and the workaround "loginctl enable-linger" leads to another bugreport
open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54
so what we have now is log flooding or hanging shutdowns
why don't upstream just what users would help and reduce logging
in a non-debug mode to a minimum so one can see without filter
if something unusal happens on a system?
if the developers would accept the need of their users then likely the users
would also be more positive, just don't explain me how to maintain my servers
i am fine with distribute-command.sh "cat /var/log/messages" all they
years because the general log is silent until something bad happens
you can't do that if systemd floods it for 30 machines
# journalctl -f
Sep 22 11:13:01 localhost.localdomain systemd[1]: Starting Session 59 of user johannbg.
Sep 22 11:13:01 localhost.localdomain systemd[1]: Started Session 59 of user johannbg.
Sep 22 11:13:01 localhost.localdomain CROND[7336]: (johannbg) CMD (/bin/systemd-cat -t "CROND" /bin/echo "Systemd
journal cron job log test every minute" )
Sep 22 11:13:01 localhost.localdomain CROND[7336]: Systemd journal cron job log test every minute
Hey let's filter this even further
# journalctl -f SYSLOG_IDENTIFIER=CROND
-- Logs begin at Thu 2013-10-24 11:47:22 GMT. --
Sep 22 11:14:01 localhost.localdomain CROND[7401]: (johannbg) CMD (/bin/systemd-cat -t "CROND" /bin/echo "Systemd
journal cron job log test every minute" )
Sep 22 11:14:01 localhost.localdomain CROND[7401]: Systemd journal cron job log test every minute
Anything regarding an text file and local and or remote logging using either rsyslog or syslog-ng is and it's
default is not relevant to us and usually set by distribution maintainers.
For remote logging I would assume administrator would create an cron filter which has the syslog identifier crond
or CROND, the syslog facility 9 and an priority 6 and send that to the remote server
So if systemd output is too much in any text file <-- file a bug against rsyslog or syslog-ng depending on which
the distribution and have *them* fix their default filtering
Jóhann B. Guðmundsson
2014-09-22 12:44:19 UTC
Permalink
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
The reason for increased log entries in the journal is that more things
are happening now since this is what happening when a job is run.
that don't change the fact that a user not acting as
systemd-developer and not debugging his system don't
need that flood
I guess we have different meaning of message flood
again: we talk about rsyslog, like it or not
Then file a bug report against rsyslog and provide a patch which fixes
the default log filtering in Fedora to your expectation but leave
systemd out of it.
wow - in any other case the systemd developers saying that
they don't workround things because problems has to be
solved at the root-cause - practice what you preach and
make the log-verbosility configureable!
Serves no purpose whatsoever doing that.
Post by Reindl Harald
* rsyslog is*not* responsible for the message flood produced by systemd
No but it is responsible for the filtering <-- of log messages.
Post by Reindl Harald
* systemd is the one producing it without prefixes
This is simply untrue as "journalctl -o export" will show you.

I suggest you stop blaming systemd for your own administrative
incompetence and broken implementation of rsyslog and syslog-ng in
Fedora ( I tried to get it fixed before we defaulted to journal YES IT
WAS BROKEN BEFORE AND STILL IS but was not allowed to do so thank those
Red Hatters in the governing body's of Fedora ( FESCO/FPC ) for it's
brokeness ) and write an rsyslog template suited for your environment
which will filter things to your liking and expectation or better yet
complain to those FESCO/FPC members since they need to learn a hard
lesson of accepting responsibility for their own actions in the
distribution.

You can find how to write an rsyslog template in the upstream rsyslog
documentation using it's powerful filtering capabilities and by looking
at for example the one spice-vdagentd /etc/rsyslog.d/spice-vdagentd.conf
in Fedora.

JBG
Reindl Harald
2014-09-22 12:58:46 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Then file a bug report against rsyslog and provide a patch which fixes
the default log filtering in Fedora to your expectation but leave
systemd out of it.
wow - in any other case the systemd developers saying that
they don't workround things because problems has to be
solved at the root-cause - practice what you preach and
make the log-verbosility configureable!
Serves no purpose whatsoever doing that.
Post by Reindl Harald
* rsyslog is *not* responsible for the message flood produced by systemd
No but it is responsible for the filtering <-- of log messages.
Post by Reindl Harald
* systemd is the one producing it without prefixes
it is ridiculous to have the need of filtering
Post by Jóhann B. Guðmundsson
This is simply untrue as "journalctl -o export" will show you.
where is it in the message?
the process is "systemd"

how to distinct between user sessions and systemn boot?
":programname" don't work and ":msg, startswith" don't work

Mar 18 23:01:01 rawhide systemd[577]: Stopped target Default.
Mar 18 23:01:01 rawhide systemd[577]: Stopping Basic System.
Mar 18 23:01:01 rawhide systemd[577]: Stopped target Basic System.
Mar 18 23:01:01 rawhide systemd[577]: Stopping Paths.
...................
Post by Jóhann B. Guðmundsson
I suggest you stop blaming systemd for your own administrative incompetence
i suggest you get rid of that arrogance and some other developers
too because it's the reason for the subject and proves that you
*do not* care about users as long you have not the same opinion

you are the one demanding a friendly tone from me, well, than
practice what you preach or stop whining if someone calls you
names the next time

who do you think you are to assess others incompetence?
Post by Jóhann B. Guðmundsson
and broken implementation of rsyslog and syslog-ng in Fedora
(I tried to get it fixed before we defaulted to journal YES IT
WAS BROKEN BEFORE AND STILL IS but was not allowed to do so
thank those Red Hatters in the governing body's of Fedora
( FESCO/FPC ) for it's brokeness)
just don't create messages the majority of users don't want and need
to see until debugging and even systemd needs to realize that the
world is not turning around it
Post by Jóhann B. Guðmundsson
and write an rsyslog template suited for your environment which
will filter things to your liking and expectation or better yet
complain to those FESCO/FPC members since they need to learn a
hard lesson of accepting responsibility for their own actions
in the distribution
who do you think you are?

that arrogance and pure ignorance is the reason for subject and
related websites as well as for users from time to time not
complaining as nice as you would like it

hence fedora devel CC'ed
__________________________________________________________________________

here the relevant links you decided to strip out and replace
with your arrogant abuse as you always do if someone has a
differnt opinion but demand from others not act the same way

here you have a simple calculation
https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8

why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368
and the workaround "loginctl enable-linger" leads to another bugreport
open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54
Philippe De Swert
2014-09-22 13:40:52 UTC
Permalink
Hi,
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Then file a bug report against rsyslog and provide a patch which fixes
the default log filtering in Fedora to your expectation but leave
systemd out of it.
wow - in any other case the systemd developers saying that
they don't workround things because problems has to be
solved at the root-cause - practice what you preach and
make the log-verbosility configureable!
Serves no purpose whatsoever doing that.
Could you elaborate? As generating 80000 lines of log seems a bit
excessive (seems in one bug which is linked it is rather a
calculationg). I would definitly classify that as a bug. (It could for
example keep a cpu or system from sleeping, thus draining more power).

Anyway usually less debug is better as it is more obvious where a
problem might be imho. Of course it is always a question about finding a
balance.
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
* rsyslog is *not* responsible for the message flood produced by systemd
No but it is responsible for the filtering <-- of log messages.
Post by Reindl Harald
* systemd is the one producing it without prefixes
it is ridiculous to have the need of filtering
Post by Jóhann B. Guðmundsson
This is simply untrue as "journalctl -o export" will show you.
where is it in the message?
the process is "systemd"
Instead of blaming someone for being incompetent you could just have
given the solution. Especially as you mentioned you knew something like
that might happen but blamed Red Hat for not implementing a potential
fix. Which you could have even documented and somebody could have found
googling for it. That would have saved time for everybody involved.

Although from what I know I rather agree there is a bug in systemd.

You also seem to forget systemd adds a lot of layers of complexity that
just did not exist with the old init. It makes it a lot harder to find
out what is going on (despite all the available documentation). So if
the prefix does not show in an obvious manner I could categorize that as
a bug too. In this case it might actually make sense to have a different
prefix as it will clearly indicate user vs system session.

Also despite the loglevels available in journald. It is unclear from the
documentation how the classification gets done
http://www.freedesktop.org/software/systemd/man/journald.conf.html

Maybe for our problem MaxLevelSyslog=err might work? But how do we know
it won't suppress certain messages we would like to see and actually
suppresses the one we don't want?

Regards,

Philippe
Jóhann B. Guðmundsson
2014-09-22 13:55:41 UTC
Permalink
Post by Reindl Harald
i suggest you get rid of that arrogance and some other developers
too because it's the reason for the subject and proves that you
*do not* care about users as long you have not the same opinion
you are the one demanding a friendly tone from me, well, than
practice what you preach or stop whining if someone calls you
names the next time
who do you think you are to assess others incompetence?
I think I'm the one based on your own actions as in after you cant even
take your time to a read upstream rsyslog documentation then insert a
single line of filtering in rsyslog, similar or equivalent of

":programname, isequal, "systemd" -/var/log/systemd.log"

to filter out systemd message from /var/log/message or fine tune the
filtering through the use of rsyslog templates and submit that as a
patch against rsyslog in Fedora so the distribution can improve it's
default filtering in rsyslog based on your input but instead choose to
file gazillion bug reports against systemd which has nothing to do with
the text file filtering in the distribution, clutter the comment
sections with useless output in those bug reports "to prove your point
over and over again" and call the lead developer of the project an idiot
in one of those reports then show up upstream cursing and demanding
fixes saying that systemd message cant be filtering even thou I pointed
to "journalctl -o export" which shows all the messages fields each log
contains including all the syslog entries which should provide an
capable administrator pleathora of ideas how to filter message in
conjunction with rsyslog powerful filtering capabilities and all that
rant for something that is not our to fix in the firstplace.

1. https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c4
Reindl Harald
2014-09-22 14:08:18 UTC
Permalink
Post by Reindl Harald
i suggest you get rid of that arrogance and some other developers
too because it's the reason for the subject and proves that you
*do not* care about users as long you have not the same opinion
you are the one demanding a friendly tone from me, well, than
practice what you preach or stop whining if someone calls you
names the next time
who do you think you are to assess others incompetence?
I think I'm the one based on your own actions as in after you cant even take your time to a read upstream rsyslog
documentation then insert a single line of filtering in rsyslog, similar or equivalent of
":programname, isequal, "systemd" -/var/log/systemd.log"
no you refuse to understand that *nobody* wants to split
out *all* systemd logs because just the excessive *user
session* logging and that this messages should not exist
at all in a non-debugging environment

you also refuse to understand that the intention in
production environments using a *centralized* SQL
logging is do *drop that messages* but hardly to
drop anything from systemd

so the next time before you take "incompetence"
in your mouth try to understand the context or
ask yourself on which side it exists
clutter the comment sections with useless output in those bug
reports "to prove your point over and over again" and call the
lead developer of the project an idiot
cause and effect - what reaction did he expect by
follow a link to a for weeks existing bugreport and
as only action close it with "NOBUG" a minute later
in one of those reports then show up upstream cursing and demanding fixes
saying that systemd message cant be filtering even thou I pointed to "journalctl
-o export" which shows all the messages fields each log contains including all the
syslog entries which should provide an capable administrator pleathora of ideas
how to filter message in conjunction with rsyslog powerful filtering capabilities
and all that rant for something that is not our to fix in the firstplace.
surely - you have no need to produce that flood in the first instance
and if you as systemd-developer want that informations then enable
deugging but stop to decide what every user needs to have in his logs
or actively to filter

realize that the world don't turn around systemd developers and
just stop your arrogance and ignorance - you will wonder how
friendly the same people become complaining all the time if
upstream stops to handle users like someone who disturbs
1. https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c4
Tom Gundersen
2014-09-22 15:04:54 UTC
Permalink
On Mon, Sep 22, 2014 at 2:44 PM, "Jóhann B. Guðmundsson"
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
The reason for increased log entries in the journal is that more things
are happening now since this is what happening when a job is run.
that don't change the fact that a user not acting as
systemd-developer and not debugging his system don't
need that flood
I guess we have different meaning of message flood
again: we talk about rsyslog, like it or not
Then file a bug report against rsyslog and provide a patch which fixes
the default log filtering in Fedora to your expectation but leave
systemd out of it.
wow - in any other case the systemd developers saying that
they don't workround things because problems has to be
solved at the root-cause - practice what you preach and
make the log-verbosility configureable!
Serves no purpose whatsoever doing that.
* rsyslog is *not* responsible for the message flood produced by systemd
No but it is responsible for the filtering <-- of log messages.
* systemd is the one producing it without prefixes
This is simply untrue as "journalctl -o export" will show you.
I suggest you stop blaming systemd for your own administrative incompetence
and broken implementation of rsyslog and syslog-ng in Fedora
Please let's not stoop to this level of name-calling. I haven't
followed this debate in detail, so I don't know how this should be
solved, but it seems fair to say that Harald's experience is
suboptimal, so let's focus on making constructive suggestions for how
journald/rsyslog or the local/distro config could be improved, rather
than who is to blame.

Anyway, I think this is decidedly off-topic for this thread, so please
move this elsewhere.

Cheers,

Tom
Post by Reindl Harald
( I tried to
get it fixed before we defaulted to journal YES IT WAS BROKEN BEFORE AND
STILL IS but was not allowed to do so thank those Red Hatters in the
governing body's of Fedora ( FESCO/FPC ) for it's brokeness ) and write an
rsyslog template suited for your environment which will filter things to
your liking and expectation or better yet complain to those FESCO/FPC
members since they need to learn a hard lesson of accepting responsibility
for their own actions in the distribution.
You can find how to write an rsyslog template in the upstream rsyslog
documentation using it's powerful filtering capabilities and by looking at
for example the one spice-vdagentd /etc/rsyslog.d/spice-vdagentd.conf in
Fedora.
JBG
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Simon McVittie
2014-09-22 14:41:46 UTC
Permalink
Post by Reindl Harald
honestly the messages about "reaching target" are nonsense without
a prefix pointing out that it is about a *user session* because it
looks like a bootlog every minute
You can tell this is not the system instance of systemd (init) because
its process ID is > 1. systemd[1] indicates the system instance,
systemd[anything else] is a user instance. This might be a useful
basis for a filter.

Configuring a higher (more severe) LogLevel in /etc/systemd/user.conf
would probably also help in your situation.

S
Reindl Harald
2014-09-22 14:51:01 UTC
Permalink
Post by Simon McVittie
Post by Reindl Harald
honestly the messages about "reaching target" are nonsense without
a prefix pointing out that it is about a *user session* because it
looks like a bootlog every minute
You can tell this is not the system instance of systemd (init) because
its process ID is > 1. systemd[1] indicates the system instance,
systemd[anything else] is a user instance. This might be a useful
basis for a filter.
first: thank you for a normal answer instead "shut up and go away"

if you take that as decision for drop messages you have several problems

* drop anything from "systemd" with PID != 1 will also affect
future things nobody knows now and not related to user-sessions
and so not happening every minute caused by cron
* it is wasting of ressources for produce *and* filter the messages
Post by Simon McVittie
Configuring a higher (more severe) LogLevel in /etc/systemd/user.conf
would probably also help in your situation
why is it refused with such a vehemence to consider make
default loggings not that verbose in general and act like
many other software packages: configured log levels with
non verbose defaults

* informational
* warning
* error
* fatal error

the goal should not be produce a growing amount over the time
and then force users how to filter it away - it should not
be produced (produce and filter both taking ressources)

the relevant information "New session started" was already
produced by systemd-logind before introduce the new verbose
log and that was easy to direct to /var/log/secure because
the process name

the normal user cares about

* started
* no error logged
* ended

but not about more details until something needs debugging
which is unusual as long you are not a systemd-developer
Dale R. Worley
2014-09-22 14:16:36 UTC
Permalink
From: "Jóhann B. Guðmundsson"
Post by Martin Steigerwald
Did you ever ask yourself why your project provokes that amount of
resistance and polarity? Did you ever ask yourself whether this
really is just resistance against anything new from people who
just do not like "new" or whether it contains*valuable*
and*important* feedback?
I'm not sure why you are under the assumption that we do not consider
and have not and are not gathering feedback from individuals,
communities or companies for that matter but I'm going to address your
questions anyway.
I've brought a complaint about one of systemd's behaviors here. I
have gotten useful feedback allowing me to refine what I think would
be a good solution to the problem. What I *haven't* gotten is any
useful feedback on how to implement a solution. I suspect others have
had similar experiences.

One metric that might be useful is to ask: Of the people who complain
about one or another aspect of systemd, what fraction ultimately
consider their complaint to be satisfactorily resolved?

There are also "architectural" issues about systemd that I've
noticed. I don't know to what degree these indicate quality control
problems with the code, or whether they are just a matter of things
being done in ways that are not common in the Un*x universe. But they
do seem to me to be things that are going to inhibit adoption.

1. Systemd has some very large binaries, each of which implements many
aspects of the system. Conversely, the typical Un*x approach is to
separate functions into many executablels, many of which are scripts.
The latter approach makes customization easier, especially for
sysadmins who aren't deeply familiar with the system.

2. Systemd includes a tremendous number of features and behaviors, but
a lot of them aren't documented very well. That's not so unusual in
Un*x, but if you're introducing something new, nobody has any prior
knowledge of it, and the lack of documentation becomes visible.

Ultimately, writing e-mail messages saying "They're wrong" is useless,
even if they *are* wrong. If there is a substantial body of people
out there who dislike systemd, it's going to prevent its adoption.
The fix is adjusting systemd (or the project surrounding it) so that
people like it better.

Dale
Ian Malone
2014-09-22 15:23:06 UTC
Permalink
Post by Dale R. Worley
2. Systemd includes a tremendous number of features and behaviors, but
a lot of them aren't documented very well. That's not so unusual in
Un*x, but if you're introducing something new, nobody has any prior
knowledge of it, and the lack of documentation becomes visible.
It's maybe not so unusual in *nix, globbed to include Linux and
starting in the past decade, but is unusual in Unix. When I started on
Linux it was still possible to use all that documentation
(http://www.opengroup.org/ was massively useful) and I spent quite
some time understanding Posix standards and how things fitted
together. You could teach yourself how to programme, use cron,
administer the system, from man pages.
--
imalone
http://ibmalone.blogspot.co.uk
Dale R. Worley
2014-09-23 14:44:51 UTC
Permalink
Let me offer this as a suggestion of what might be the root of some
issues:

One of the lessons in Fred Brooks' "The Mythical Man-Month" is that it
takes three times more effort to produce a *program product* as it
does to produce the *program*. That is, 2/3 of the effort is not to
make the software do what it is supposed to, but rather to adjust the
software to work in the (software and human) environment that it must
work in, interacting with customers, etc.

It might be worth examining the project and asking whether the
non-software part of the work has been carried out with the same care
as the software part of the work.

Dale
Zbigniew Jędrzejewski-Szmek
2014-09-23 15:23:34 UTC
Permalink
Post by Dale R. Worley
From: "Jóhann B. Guðmundsson"
Post by Martin Steigerwald
Did you ever ask yourself why your project provokes that amount of
resistance and polarity? Did you ever ask yourself whether this
really is just resistance against anything new from people who
just do not like "new" or whether it contains*valuable*
and*important* feedback?
I'm not sure why you are under the assumption that we do not consider
and have not and are not gathering feedback from individuals,
communities or companies for that matter but I'm going to address your
questions anyway.
I've brought a complaint about one of systemd's behaviors here. I
have gotten useful feedback allowing me to refine what I think would
be a good solution to the problem. What I *haven't* gotten is any
useful feedback on how to implement a solution. I suspect others have
had similar experiences.
One metric that might be useful is to ask: Of the people who complain
about one or another aspect of systemd, what fraction ultimately
consider their complaint to be satisfactorily resolved?
Hm, if you looked at any of the bugtrackers, most systemd issues are
resolved (e.g. on bugs.freedesktop.org we have about 140 of of 950
issues still opened). Most of the time they are actually fixed, and
the ones that are left open are either RFEs or more complicated issues.
Post by Dale R. Worley
There are also "architectural" issues about systemd that I've
noticed. I don't know to what degree these indicate quality control
problems with the code, or whether they are just a matter of things
being done in ways that are not common in the Un*x universe. But they
do seem to me to be things that are going to inhibit adoption.
1. Systemd has some very large binaries, each of which implements many
aspects of the system. Conversely, the typical Un*x approach is to
separate functions into many executablels, many of which are scripts.
The latter approach makes customization easier, especially for
sysadmins who aren't deeply familiar with the system.
Actually, based on what I've read e.g. in the UNIX haters' handbook,
the idea of separating into many separate binaries wasn't all that
common in UNIX. Also, historically programs used to be real binaries,
not scripts.

More seriously, the idea of having shell scripts which you're going
to modify to customize your setup is simply crazy. How robust would
your changes be? How would you ever handle upgrades? How would more
than one admin manage a machine without sitting in the same room?

I don't know where you get the idea that systemd has "big binaries".
Existing source code compiles to ~140 binaries and a few libraries.
Many of them are really tiny, a few that do more complicated things
are bigger. And things are very much separated by function between
daemons.
Post by Dale R. Worley
2. Systemd includes a tremendous number of features and behaviors, but
a lot of them aren't documented very well. That's not so unusual in
Un*x, but if you're introducing something new, nobody has any prior
knowledge of it, and the lack of documentation becomes visible.
Again, this seems rather ignorant of the status quo. Between the blog
posts and wiki documentation and the 164 man pages, systemd is rather
copiously documented. Not to say that things can't be improved, but
by Linux standards we are at least making an effort. Bugs for missing
or unclear documentation and usually handled, and any patches for
documentation are applied fairly quickly.
Post by Dale R. Worley
Ultimately, writing e-mail messages saying "They're wrong" is useless,
even if they *are* wrong. If there is a substantial body of people
out there who dislike systemd, it's going to prevent its adoption.
The fix is adjusting systemd (or the project surrounding it) so that
people like it better.
Sometimes, sometimes not. Doing everything that is requested, especially
by newcomers to the project, would quickly cause the project to
lose focus and consistency and turn into an unmaintainable mess.

Zbyszek
Dale R. Worley
2014-09-23 19:13:08 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
More seriously, the idea of having shell scripts which you're going
to modify to customize your setup is simply crazy. How robust would
your changes be? How would you ever handle upgrades? How would more
than one admin manage a machine without sitting in the same room?
I've been editing init scripts since around 1992, and I'll bet that a
lot of other people have, too. It's reasonably robust, since you know
where the edits are and what they're for. You upgrade by bringing
forward the edits into each new release you load.

But there's no way around that. Suppose I'd like to adjust systemd's
behavior regarding mounting devices (as I do). Is that going to be
*easier* to do if I have to download the C, modify it, and recompile?
I still have the same problems with upgrading, etc.

In the end, what wins is usually what makes it easiest to accomplish
the tasks people have at hand. E.g., in many ways, C is an inferior
language to Pascal, but there are enough things that Pascal makes hard
or impossible that C won out. Similarly with customizations.
Post by Zbigniew Jędrzejewski-Szmek
Again, this seems rather ignorant of the status quo. Between the blog
posts and wiki documentation and the 164 man pages, systemd is rather
copiously documented. Not to say that things can't be improved, but
by Linux standards we are at least making an effort. Bugs for missing
or unclear documentation and usually handled, and any patches for
documentation are applied fairly quickly.
OK, I'd like to modify systemd's handling of mounts. I've been told
only that the units that are created from /etc/fstab are created and
handled by the main systemd binary. What documentation do I look at
that explains how systemd actually does that, what the relevant source
is, etc.? With init scripts, I know it's somewhere in a script in
/etc/rc.d/init.d; searching for "mount" probably reveals a couple of
hundred lines of shell script within which the functionality is
hiding.

Another more generically useful pointer would be something that
explains what the algorithm that does the sequencing between units
*really* is. I've heard breezy descriptions of what the various
dependency types mean, but I'm certain that there's a bunch of tricky
details which a lot of thought has been spent on.

Dale
Reindl Harald
2014-09-23 19:16:28 UTC
Permalink
Post by Dale R. Worley
OK, I'd like to modify systemd's handling of mounts. I've been told
only that the units that are created from /etc/fstab are created and
handled by the main systemd binary. What documentation do I look at
that explains how systemd actually does that, what the relevant source
is, etc.? With init scripts, I know it's somewhere in a script in
/etc/rc.d/init.d; searching for "mount" probably reveals a couple of
hundred lines of shell script within which the functionality is
hiding
to be fair here: just type "systemd.mount" in Google
http://www.freedesktop.org/software/systemd/man/systemd.mount.html
Tom Gundersen
2014-09-23 20:24:07 UTC
Permalink
Post by Dale R. Worley
OK, I'd like to modify systemd's handling of mounts. I've been told
only that the units that are created from /etc/fstab are created and
handled by the main systemd binary. What documentation do I look at
that explains how systemd actually does that, what the relevant source
is, etc.? With init scripts, I know it's somewhere in a script in
/etc/rc.d/init.d; searching for "mount" probably reveals a couple of
hundred lines of shell script within which the functionality is
hiding.
Try "systemctl status home.mount" (or some other mount unit generated
from your fstab), then there will be pointers to the relevant
documentation there ("Doc:"). To be dropped directly into the man
pages, just do "systemctl help home.mount".
Post by Dale R. Worley
Another more generically useful pointer would be something that
explains what the algorithm that does the sequencing between units
*really* is. I've heard breezy descriptions of what the various
dependency types mean, but I'm certain that there's a bunch of tricky
details which a lot of thought has been spent on.
I do not understand this question. Could you give an example of what
you are struggling with? I mean, the gist is that the After/Before
orderings are respected and everything else is done in parallel. To
get the precise orderings applied to a unit try "systemctl show
bar.service".

Cheers,

Tom
Lennart Poettering
2014-10-01 21:42:44 UTC
Permalink
Post by Dale R. Worley
Post by Zbigniew Jędrzejewski-Szmek
Again, this seems rather ignorant of the status quo. Between the blog
posts and wiki documentation and the 164 man pages, systemd is rather
copiously documented. Not to say that things can't be improved, but
by Linux standards we are at least making an effort. Bugs for missing
or unclear documentation and usually handled, and any patches for
documentation are applied fairly quickly.
OK, I'd like to modify systemd's handling of mounts. I've been told
only that the units that are created from /etc/fstab are created and
handled by the main systemd binary. What documentation do I look at
that explains how systemd actually does that, what the relevant source
is, etc.? With init scripts, I know it's somewhere in a script in
/etc/rc.d/init.d; searching for "mount" probably reveals a couple of
hundred lines of shell script within which the functionality is
hiding.
As mentioned on this thread "systemctl help" on a unit is a really
easy way to get more information about it. Pretty much all units we
ship with systemd upstream contains the necessary meta information to
link it up directly with its docs.

mount units for /etc/fstab entries are nowadays generated from a so
called "generator", see systemd-fstab-generator(8).

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2014-10-01 21:37:54 UTC
Permalink
Post by Dale R. Worley
1. Systemd has some very large binaries, each of which implements many
aspects of the system. Conversely, the typical Un*x approach is to
separate functions into many executablels, many of which are scripts.
The latter approach makes customization easier, especially for
sysadmins who aren't deeply familiar with the system.
We split up things into 80+ binaries.
Post by Dale R. Worley
2. Systemd includes a tremendous number of features and behaviors, but
a lot of them aren't documented very well. That's not so unusual in
Un*x, but if you're introducing something new, nobody has any prior
knowledge of it, and the lack of documentation becomes visible.
Please let us know where documentation is missing. I know a couple of
areas where documentation is lacking (such as the too muc hof the C
APIs we expose currently), but at least the user-facing stuff should
be pretty comprehesively documented. If you are missing docs for
something I'd be quite interested to know for which parts so that we
can actually fix it.

Lennart
--
Lennart Poettering, Red Hat
Martin Steigerwald
2014-10-05 11:44:35 UTC
Permalink
Hi Jóhann,
Post by Jóhann B. Guðmundsson
Post by Martin Steigerwald
in the light of the ongoing discussions on linux-kernel
Could you provide a link to that ongoing discussion that is taking place
in the kernel community regarding systemd?
I think this is the one I meant:

OT: Open letter to the Linux World
https://lkml.org/lkml/2014/8/12/459

It seems to have ceased meanwhile.

Also on some other occasion a kernel developer agreed on my concerns regarding
binary size of PID 1 with systemd.
Post by Jóhann B. Guðmundsson
Post by Martin Steigerwald
Did you ever ask yourself why your project provokes that amount of
resistance and polarity? Did you ever ask yourself whether this really is
just resistance against anything new from people who just do not like
"new" or whether it contains*valuable* and*important* feedback?
I'm not sure why you are under the assumption that we do not consider
and have not and are not gathering feedback from individuals,
communities or companies for that matter but I'm going to address your
questions anyway.
Have we ever asked ourselves why our project provokes that amount of
resistance and polarity?
The answer to that question is yes, yes we have and yes we will continue
to do so since resistance and polarity provides with the valuable
information amongst other things if the implementation is bad and
alternative approach is better ( which often reveals itself at the same
time those friction take place ).
Dont get me wrong we will not do so when those discussion involve
nothing but personal attack on our community member(s) which more often
than not happens to be Lennart, Lennart is and never has been the sole
person behind this effort, he's part of ever growing community.
I am not willing to tolerate personal attacks on Debian user. I just
remembered that I can act on it and filed an abuse complaint about some of
those.
Post by Jóhann B. Guðmundsson
Nor when it involves us having to implement somekind of hack as opposed
to have the problem properly fixed where it belongs ( which could be us
or not ) or when those discussion criticizes that we have chosen to
tightly integrate ourselves specifically to the linux kernel it's
ecosystem and with glibc in mind just like bsd based distribution as
well as solaris and other nixes are tightly integrating their components
to their kernels but for some dumbfound reason people on the internet
are under the assumption that they have the authority of refusing us the
freedom of doing the same o_O and the answer to those individuals we
dont care about their opinion on this matter.
Now alot of the resistance and polarity that is taking place like in the
url you pointed at is hiding itself behind their misinterpretation of
the so called "Unix philosophy" and claiming that we somehow fall short
on the guidelines originates from few things Doug McIlroy,Rob Pike,Ken
Thompson said sometime in the 70's or rather the "Unix philosophy" was
implied not by what these individuals said but rather by what they did
which more or less boils down to this..
1. Write simple parts connected by clean interfaces.
Well, I for one wonder what is all in that 1,3 MiB binary of systemd running
as PID 1? In my estimation it can´t be just some services handling and control
groups management. As that would be much smaller I believe. There is systemd
--user running just a fraction of code of this binary as Lennart explained.

To me, this is a huge binary and to me its not clear what things it does and
how they operate with one another via a clean interface if packed all into one
binary.
Post by Jóhann B. Guðmundsson
2. Clarity is better than cleverness.
Using debug commands was needed to diagnose a fstab syntax error:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755506#25

As I pointed out (with wrong bug link, sorry).

Its arguable whether to fail hard on syntax errors in fstab, but if systemd
fails hard, I expect put me a *big fat* error message on the screen explaining
the issue at hand. Except expecting me to use debug commands to find out whats
wrong.
Post by Jóhann B. Guðmundsson
3. Design programs to be connected to other programs.
Well we appear to have quite some binaries. But according to binary size, very
much of the functionality appears to be in systemd main binary. But even other
binaries are quite large for what they do.

merkaba:~> ( for FILE in $( dpkg -L systemd | egrep "lib|bin" ); do test -f
"$FILE" && test -x "$FILE" && stat --format "%s %n" "$FILE" ; done ) | sort -
rn
1309064 /lib/systemd/systemd
538904 /bin/systemctl
522480 /lib/systemd/systemd-networkd
506096 /lib/systemd/systemd-logind
366856 /usr/bin/systemd-nspawn
325872 /lib/systemd/systemd-machined
309488 /bin/loginctl
297192 /lib/systemd/systemd-localed
293096 /lib/systemd/systemd-timedated
289000 /lib/systemd/systemd-hostnamed
288992 /lib/systemd/systemd-bus-proxyd
280816 /bin/machinectl
276712 /usr/bin/busctl
272616 /usr/bin/systemd-analyze
260328 /usr/bin/timedatectl
256232 /usr/bin/localectl
256224 /usr/bin/systemd-run
252144 /lib/systemd/systemd-fsck
248048 /usr/bin/systemd-cgls
248040 /usr/bin/hostnamectl
239840 /lib/systemd/systemd-update-utmp
239840 /lib/systemd/systemd-initctl
235768 /bin/systemd-inhibit
231664 /lib/systemd/systemd-journald
231648 /lib/systemd/systemd-cgroups-agent
219392 /bin/journalctl
104680 /lib/systemd/systemd-timesyncd
88312 /lib/systemd/systemd-shutdown
84600 /lib/systemd/systemd-bootchart
80104 /bin/systemd-tmpfiles
76008 /lib/systemd/systemd-resolved
76000 /lib/systemd/systemd-socket-proxyd
76000 /lib/systemd/systemd-networkd-wait-online
67832 /lib/systemd/system-generators/systemd-gpt-auto-generator
67832 /lib/systemd/systemd-readahead
63728 /lib/systemd/systemd-cryptsetup
59632 /bin/systemd-tty-ask-password-agent
51456 /lib/systemd/system-generators/systemd-fstab-generator
51448 /usr/bin/systemd-cgtop
51440 /lib/systemd/system-generators/systemd-sysv-generator
51424 /lib/systemd/systemd-sleep
51424 /lib/systemd/systemd-backlight
47352 /lib/systemd/system-generators/systemd-cryptsetup-generator
47344 /usr/bin/systemd-delta
43240 /lib/systemd/systemd-activate
43232 /lib/systemd/systemd-rfkill
39160 /bin/systemd-ask-password
39144 /lib/systemd/systemd-shutdownd
39144 /lib/systemd/systemd-modules-load
39136 /lib/systemd/systemd-sysctl
35056 /lib/systemd/system-generators/systemd-insserv-generator
35048 /lib/systemd/systemd-remount-fs
35048 /bin/systemd-machine-id-setup
35040 /usr/bin/systemd-path
35040 /lib/systemd/systemd-binfmt
30968 /lib/systemd/system-generators/systemd-debug-generator
30960 /lib/systemd/system-generators/systemd-getty-generator
30944 /bin/systemd-escape
26864 /lib/systemd/system-generators/systemd-rc-local-generator
26856 /usr/bin/systemd-cat
26856 /lib/systemd/systemd-random-seed
26856 /lib/systemd/systemd-quotacheck
26848 /usr/bin/systemd-detect-virt
26848 /bin/systemd-notify
22760 /lib/systemd/system-generators/systemd-system-update-generator
22752 /lib/systemd/systemd-user-sessions
22752 /lib/systemd/systemd-reply-password
14336 /lib/systemd/systemd-multi-seat-x
14328 /lib/systemd/systemd-ac-power
546 /lib/systemd/debian-fixup
462 /lib/systemd/systemd-logind-launch
31 /usr/bin/systemd-stdio-bridge
20 /bin/systemd
Post by Jóhann B. Guðmundsson
4. Separate policy from mechanism; separate interfaces from engines.
I don´t know much about this one. At least it seems to be possible to provide
part of systemd functionality by providing compatible interfaces. As cgmanager
does or systembsd… but I read in one feedback the documentation states that if
the code differs from the documentation the code is right. Yet I also know you
guarentee stability of some parts of the interface to systemd.
Post by Jóhann B. Guðmundsson
5. Design for simplicity; add complexity only where you must.
Well…
Post by Jóhann B. Guðmundsson
6. Write a big program only when it is clear by demonstration that
nothing else will do.
I doubt that for /lib/systemd/systemd

What are the reasons why it can´t be split up further? Why does user session
functionality aka systemd --user need to be in there? Lennart said less memory
footprint – but that sounds different from "nothing else will do".
Post by Jóhann B. Guðmundsson
7. Rule of Transparency: Design for visibility to make inspection and
debugging easier.
So far if systemd failed on something it often was not immediately obvious as
to say. One more little example for that is: If by accident in depend (there
are some bugs with init-select), instead of systemd /sbin/init is run as PID 1
systemctl just complains along the lines of:

merkaba:~> LANG=C systemctl
Failed to get D-Bus connection: Unknown error -1

Subject: systemd fails to get dbus connection while dbus is running
https://bugs.debian.org/762558

This is as intransparent as it can get, especially for someone who wasn´t
aware that even systemctl used dbus to communicate with systemd.

"unknown error" to me is an unacceptable error message. Usually the error is
known. Here it is just that systemd isn´t even running and systemctl is
supposed to tell me that.
Post by Jóhann B. Guðmundsson
8. Robustness is the child of transparency and simplicity.
I see:

merkaba:~> mount | grep cgroup
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-
cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup
(rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup
(rw,nosuid,nodev,noexec,relatime,hugetlb)

I also look in there and I know a bit about control groups. Yet I didn´t yet
completely figure out how system sorts processes into groups for CPU
scheduling.

As

merkaba:~> ls -l /sys/fs/cgroup/cpu,cpuacct
insgesamt 0
-rw-r--r-- 1 root root 0 Okt 5 13:23 cgroup.clone_children
-rw-r--r-- 1 root root 0 Okt 5 11:28 cgroup.procs
-r--r--r-- 1 root root 0 Okt 5 13:23 cgroup.sane_behavior
-r--r--r-- 1 root root 0 Okt 5 13:23 cpuacct.stat
-rw-r--r-- 1 root root 0 Okt 5 13:23 cpuacct.usage
-r--r--r-- 1 root root 0 Okt 5 13:23 cpuacct.usage_percpu
-rw-r--r-- 1 root root 0 Okt 5 13:23 cpu.cfs_period_us
-rw-r--r-- 1 root root 0 Okt 5 13:23 cpu.cfs_quota_us
-rw-r--r-- 1 root root 0 Okt 5 13:23 cpu.rt_period_us
-rw-r--r-- 1 root root 0 Okt 5 13:23 cpu.rt_runtime_us
-rw-r--r-- 1 root root 0 Okt 5 13:23 cpu.shares
-r--r--r-- 1 root root 0 Okt 5 13:23 cpu.stat
-rw-r--r-- 1 root root 0 Okt 5 13:23 notify_on_release
-rw-r--r-- 1 root root 0 Okt 5 13:23 release_agent
-rw-r--r-- 1 root root 0 Okt 5 13:23 tasks

doesn´t have any groups in it.

But I have them in:

/sys/fs/cgroup/systemd/user.slice and system.slice

Which pretty much does not relate to any in kernel doc I read about control
groups so far. Why are those groups still isolated cpu wise?

I know it works, as I can start stress -c 10000 on my machine and continue to
work. Yet I don´t know *why* it works. And I briefly looked at it several
times.

So, this right now is completely intransparent to me and seems to require
reading up additionally documentation on how systemd handles control groups to
understand what it does in there.

It seems to work tough, but I couldn´t even test for correctness right now as
I don´t understand how it needs to look like for it to be correct.

It might be very easy, but frankly I didn´t get yet how this works.

I know this may look easier with unified control groups, but yet, then its only
one binary who can access this interfaces at a time, or is allowed to do that,
as far as I understand. Which makes this differ some other programming
interfaces to the kernel. Anyone can mount a filesystem for example. Actually
running 3.17-rc6 here already, so is systemd unified control group hierarchy?
No, doesn´t seem to have CPU related settings in there.
Post by Jóhann B. Guðmundsson
9. Fold knowledge into data so program logic can be stupid and robust.
systemd unit files contain a *ton* of options for this and that and this. All,
as far as I am aware implemented in C code.

So if I have a new scenario or want an option to work differently, I am stuck.
Unless upstream decides to implement it in C code. Arguably with shell
scripts, I could make the adaption myself.

That said, it seems possible to still use shell scripts for these case. But
still, to me thats a lot of logic that was in the shell scripts – arguably
also code, yet treated as configuration files by dpkg for example – before moved
into a binary.
Post by Jóhann B. Guðmundsson
10. In interface design, always do the least surprising thing.
11. When a program has nothing surprising to say, it should say nothing.
12. When you must fail, fail noisily and as soon as possible.
13. Programmer time is expensive; conserve it in preference to machine time.
14. Avoid hand-hacking; write programs to write programs when you can.
15. Prototype before polishing. Get it working before you optimize it.
16. Distrust all claims for “one true way”.
It is a perception of some of the feedback givers that systemd upstream
developers believe theirs is the one true way.
Post by Jóhann B. Guðmundsson
17. Design for the future, because it will be here sooner than you think.
Now after you have read these more of an guidelines than actual
philosophy I would like to hear from you where you think systemd has and
is falling short of them during it's development phase and lifetime so I
can better understand why people seem to be claiming it's not following
these guidelines?
I commented on some of these inline.

But well… I´d love for some other subscribers of debian-user to comment on
these as well. Actually I am doing work to channel some of the feedback I read
upstream… self-appointed work.

But well, I raised some of my own impressions above as well.
Post by Jóhann B. Guðmundsson
That being said acceptance and approval are outweighing resistance and
polarity in the Linux ecosystem as things currently stand ( otherwise we
would not be so widely accepted and adopted ) because we are and
continue to solve real problems through close collaboration with wide
variety of upstream and distribution, In the long run freeing up
contributors time while doings so through the consolidation that takes
place while we are at it.
If you are wondering as well if we are against emerging alternative init
system like the one you refereed to, the answer to that question is no
we are not.
We welcome and embrace them and hope they evolve to the point they
become competing solution so we can continue to evolve ourselves ( or
advance beyond us and eventually replace us ) but being frank that wont
happen anytime soon.
Systemd has been what ca 7 years in the making now with what 5 of those
years being direct integration with wide variety of components and
distribution so this is not a simple matter of writing an new init
system, this is so much much more work which I dont think those new or
existing init project and it's developers realize.
Well… part of the resistance might be that this is not obvious to users. For
Debian users systemd appeared in sid / unstable and then jessie. And
understandably it can feel like: "Wow it now installs systemd, yet I didn´t
ask for it. And wow, if I try to remove it, it removes GNOME, what gives? I am
forced onto it."

That said, neither Sid nor Jessie are stable and there have been changes in
the set of packages that need to be installed for something before.

I expect the release notes to contain a good and thorough explaination of this
deep change.

So some of it may also be how Debian developers handled the transition. The
decision took a very long time. Debian developers themselves weren´t able to
agree on it, so they called the tech-ctte, which admirably, did just decide
quickly and easily. And then freeze was approaching more and more… And what
the users now face is: Suddenly there is systemd. Only those aware of the long
discussion before, can appreciate it wasn´t just forced.

But as can clearly be seen: Even amongst the developers this decision is still
*highly* controversial. Its not just debian-user also debian-devel had and
AFAIK still has systemd related debates.
Post by Jóhann B. Guðmundsson
Now just a word of advice...
You should take it with a grain of salt what alot anti-systemd sites or
individuals are saying on the interweb since more often than not those
things are based on misinformation ( like most recently on post on
linux.com "Red Hat is the inventor and primary booster of systemd," this
is false ) and since the internet is expert in spreading ignorance and
we can only fight back ignorance with enlightenment and we can only do
so with people that are willing to listen, which unfortunately more
often than not, these individuals will not.
I think I read it with my own thinking still awake. I do see advantages and I
have concerns about systemd.

Its not all black or all white to me.
Post by Jóhann B. Guðmundsson
With regards to anykind of anti systemd discussion taking place in wide
varity of Debians community mailinglists if I was you, I would simply
remind those individuals that an democratic voting has taken place
within the community and not accepting the outcome of that voting and
help in the process integrate systemd better into Debian ( which in turn
will result in feedback either there to here or directly here ) is an
utterly and total disrespect to it's community members and Debians
democracy ( from my stand point ).
Well, the tech ctte is eight people and it 4:4 systemd upstart, the vote of
the president (I think it is another term) of the tech ctte decided.

While the tech ctte was called upon, I wouldn´t call this anything near a
representative democracy. Yet, I wouldn´t Debian call one anyway. In my eyes
it isn´t. (And probably doesn´t need to be one.)

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Uoti Urpala
2014-09-22 00:32:02 UTC
Permalink
Post by Martin Steigerwald
Did you ever ask yourself why your project provokes that amount of resistance
and polarity? Did you ever ask yourself whether this really is just resistance
against anything new from people who just do not like "new" or whether it
contains *valuable* and *important* feedback?
I think that in general the existence of significant amounts of
resistance is explained by opposition to anything new. Systemd changes
many things, and as distros won't keep support for sysvinit at the same
time, people can't easily keep using the old stuff they're used to.
That's enough to explain complaints, and their existence does not by
itself mean there would be anything wrong with systemd.
Post by Martin Steigerwald
For now I use systemd. I like quite some features. But on the other hand I am
vary about it myself. I look at a 45 KiB binary for /sbin/init as PID1 and a
1,3 MiB binary in systemd 215 and wonder myself.
Sysvinit as PID 1 lacks many essential things, so that is not a valid
size comparison (and just having the code running with a PID other than
1 is not an improvement).

In general, any complaints about the size/"bloat" of PID 1 are rather
silly if you still use it with the Linux kernel, which contains a lot
more code in a more central role than PID 1.
Post by Martin Steigerwald
I had it that it didn´t mount an NFS export and while in the
end it was a syntax error in fstab that sysvinit happily ignored, I needed a
bug report and dev help to even find that cause. I wonder about the complexity
involved in one single large binary.
I think this works as an example of how change leads to people
complaining, completely unrelated to the existence of any actual quality
issues. Sysvinit behavior or debuggability wrt mount issues was not
better than systemd is, much less by so much that this would illustrate
any general issue with systemd (that's not to say that systemd
diagnostics could not be improved). Yet because you were first familiar
with sysvinit and had created dubious configuration which happened to
work with it, you now feel this is a problem in systemd, just because
things have changed. Someone who started with systemd and used it for
years before encountering sysvinit would hit a lot more problems.
Post by Martin Steigerwald
Well… its not about my thoughts about systemd, it is about my perception that
I never seen any free software upstream project creating this amount of
polarity and discussion in a decade or more.
I don't think the reactions to systemd are in any way unique. I've seen
similar reactions to other changes. The difference in the systemd case
is that a lot of developers interact with the init system at least on a
superficial level, and init system choice is mostly done on the distro
level, so people can't easily ignore systemd and keep using their old
software. That increases the volume of the complaints.
Post by Martin Steigerwald
Is it really all just nay-sayers for the sake of nay-saying? Or do they – at
least partly – provide *valuable* and *important* feedback.
"nay-sayers" as in people who oppose the adoption of systemd because
they think that some alternative is less flawed tend to have no clue.
You're more likely to get *valid* criticism from people who are at least
competent enough to recognize that whatever problems systemd has, the
alternatives are worse.
Lennart Poettering
2014-10-01 21:33:43 UTC
Permalink
Post by Martin Steigerwald
I just have one question. In the light of
[...]
Post by Martin Steigerwald
in the light of the ongoing discussions on linux-kernel, debian-devel, debian-
Did you ever ask yourself why your project provokes that amount of resistance
and polarity? Did you ever ask yourself whether this really is just resistance
against anything new from people who just do not like "new" or whether it
contains *valuable* and *important* feedback?
That's already two questions...

But anyway. Let me turn your question around: we swapped out one of
the most central pieces of Linux systems, one of the pieces that is
probably the most core of what administrators interface with every
day. How could this change ever have gone *without* any noise?

Administrators probably are a generally more conservative bunch,
anything that interferes with their day-to-day workflow that they are
used to is a distraction. That's quite understandable. In fact, I used
to be an admin myself a long time ago, and I still administer a couple
of machines. I have similar feelings when I update them, and in
particular when some component I don't want to spend the time to relearn
changes I end up being annoyed (dovecot config file changes!).

Moreover, init systems are just an auxiliary tool to run
things. Nobody starts a computer up to run systemd on it. People start
up a computer to run a web app or database server software on
it. Because of that, systemd is just a tool to make something else
work, and the focus is always on that other thing, and any time spent
on systemd or relearning it feels like wasted time to many. I totally
and absolutely understand these feelings.

However, I also believe that the change we are making is for the good,
and even though it might not be obvious to many immediately, it brings
major benefits when administering machines, and they massively
outweigh the disadvantage of changing things. And apparently I am not
entirely alone with this, as the folks who make technical decision for
the various distributions ended up deciding in favour of systemd in
most cases.

Yes, we knew exactly we'd be getting a lot of heat for all this. We
have been getting it from the day on we announced the project. And I
am pretty sure it will continue this way for a while still.

(What I didn't expect though is how awful the Linux community can
actually be. That people collect Bitcoins to hire a hitman on me, that
people start petitions to make me stop working, and all that other
really hateful, personal stuff is really apalling. I guess I have a
thick skin, because I don't care too much, but jeezus christ, it's
really disgusting sometimes.)

I monitor the feedback posted on the Internet regularly. I browse
reddit and the debian and gentoo mailing list archives sometimes, and
try to distill the useful bits out of all the noise and hate dumped
there. This actually used to be very productive for quite some time,
and much of the polishing that systemd got over the years was a result
of the feedback I read through this way, even if I had to read between
the lines of all the hateful mails. Today, it's much less useful, I
figure partially because the worst usability issues with systemd have
long been fixed, but also because the crowd commenting changed from
folks who were genuinely interested (early adopter folks) to a more
general audience which also includes a lot of haters.

The current increase noised level around systemd adoption I attribute
to three things: the fact that RHEL7 is out now, the fact that due to
the adoption of systemd as default by Debian and Ubuntu the folks who
ignored the discussion so far now are faced with this change, and also
to a big part to certain "columnists" who in the interest of
generating traffic to their sites try to create a hubbub out of very
little.

Anyway, long story short: we knew what we did, and yeah, I read
feedback, even if it is written in a hateful style, and we learn from
it.
Post by Martin Steigerwald
For now I use systemd. I like quite some features. But on the other hand I am
vary about it myself. I look at a 45 KiB binary for /sbin/init as PID1 and a
1,3 MiB binary in systemd 215 and wonder myself. I see systemd --user
Well, note that systemd used for user services actually saves you
resources, as the systemd binary only needs to be mapped into memory
once and then is shared between all user instances and the system
instance.
Post by Martin Steigerwald
Is it really all just nay-sayers for the sake of nay-saying?
No, it's not that simple.
Post by Martin Steigerwald
Or do they – at least partly – provide *valuable* and *important*
feedback.
Well, some is valuable and important, but much certainly isn't. The
200nd complaint that systemd was "monolithic" or so is something I am
genuinely not interested in anymore, for example...

I will continue to scan reddit and the mailing list archives for stuff
I find, but of course, I always prefer if people would contact us
directly and constructively with feature or change requests, instead
of requiring me to follow these forums...

Let me stress this: constructive feedback is *always* welcome!

Lennart
--
Lennart Poettering, Red Hat
Martin Steigerwald
2014-10-05 10:20:01 UTC
Permalink
Hi Lennart,
Post by Lennart Poettering
Post by Martin Steigerwald
I just have one question. In the light of
[...]
Heck, I started a thread here and then didn´t manage to take time to carefully
read it and reply here and there as I see fit. But I challenged people on
debian-user mailing list to constructively voice their concerns upstream, and
even pointed them to this mailing list. As far as I saw *no one* of the
posters in debian-user took up on that challenge. Which I view as a pity.
Cause now actually you invited constructive feedback. I wonder whether I may
forward your answer to debian-user so they see your statement of inviting
constructive feedback.
Post by Lennart Poettering
Post by Martin Steigerwald
in the light of the ongoing discussions on linux-kernel, debian-devel,
debian- user and other mailing lists more than some dozens threads
Did you ever ask yourself why your project provokes that amount of
resistance and polarity? Did you ever ask yourself whether this really is
just resistance against anything new from people who just do not like
"new" or whether it contains *valuable* and *important* feedback?
That's already two questions...
But anyway. Let me turn your question around: we swapped out one of
the most central pieces of Linux systems, one of the pieces that is
probably the most core of what administrators interface with every
day. How could this change ever have gone *without* any noise?
Yet… I think it is not just noise.
Post by Lennart Poettering
Administrators probably are a generally more conservative bunch,
anything that interferes with their day-to-day workflow that they are
used to is a distraction. That's quite understandable. In fact, I used
to be an admin myself a long time ago, and I still administer a couple
of machines. I have similar feelings when I update them, and in
particular when some component I don't want to spend the time to relearn
changes I end up being annoyed (dovecot config file changes!).
Oh, I know this one. I moved all the gazillion config files away and told it to
use my old single file config. And for my setup using a ton of config files just
adds immensively to my maintenance overheard, when I can write down the
configuration in a page of text.
Post by Lennart Poettering
Moreover, init systems are just an auxiliary tool to run
things. Nobody starts a computer up to run systemd on it. People start
up a computer to run a web app or database server software on
it. Because of that, systemd is just a tool to make something else
work, and the focus is always on that other thing, and any time spent
on systemd or relearning it feels like wasted time to many. I totally
and absolutely understand these feelings.
Well I do see advantages. I am one of the early adopters of systemd. And I
would need to hold hands before my eyes to not see the advantages. But I can
also resonate with some of the concerns.
Post by Lennart Poettering
However, I also believe that the change we are making is for the good,
and even though it might not be obvious to many immediately, it brings
major benefits when administering machines, and they massively
outweigh the disadvantage of changing things. And apparently I am not
entirely alone with this, as the folks who make technical decision for
the various distributions ended up deciding in favour of systemd in
most cases.
Why do you believe so? What key points make you believe so?

Here the feedback I read over and over again is that you and RedHat basically
forced the systemd decision onto other distributions. While I do not see how
you actually can be powerful enough to do that, as we live in a free will
zone. I do see tendencies that more and more stuff *depends* on systemd cause
it needs features only available there.

On of the most talked on things on debian-user is the logind thing. GNOME
actually depends on it, as far as I know. While KDE in Debian still uses
ConsoleKit, as it seems to me when looking at the process list and finding:

/usr/bin/ck-launch-session /usr/bin/dbus-launch --exit-with-session
/usr/bin/startkde

Dependencies like this actually create some force to adopt systemd.

Now I know ConsoleKit isn´t developed anymore, but also I never got why a
logind implementation needs to depend on systemd base package in such a way
that at least in Debian systemd package has to be installed if someone wants
to use GNOME.

Also some parts of KDE seem to depend on systemd meanwhile in Debian –
basically udisks related parts and Network-Manager:

merkaba:~> LANG=C apt-get purge systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer
required:
amor analitza-common blinken cantor cantor-backend-kalgebra
filelight kaccessible kalgebra kalgebra-common kalzium
kalzium-data kanagram kbruch kcharselect kcolorchooser
kde-config-cron kde-icons-mono kdeaccessibility kdeadmin
kdeartwork kdeartwork-style kdeartwork-theme-window
kdeartwork-wallpapers kdeedu kdeedu-kvtml-data kdegraphics
kdegraphics-mobipocket kdegraphics-strigi-analyzer
kdegraphics-thumbnailers kdemultimedia kdenetwork
kdenetwork-filesharing kdetoys kdeutils kdf kgamma kgeography
kgeography-data kgpg khangman kig kiten klettres
klettres-data kmag kmousetool kmplot kolourpaint4 kppp krdc
kremotecontrol krfb kruler ksaneplugin kscd kstars
kstars-data ksystemlog kteatime ktimer ktouch ktouch-data
kturtle ktux kuser kwordquiz libanalitza5abi1
libanalitzagui5abi1 libanalitzaplot5abi1 libgnuinet-java
libgnumail-java libgtk-vnc-1.0-0 libidl0 libkdeedu-data
libkeduvocdocument4 libkiten4abi1 liborbit2
libsystemd-id128-0:i386 libsystemd-journal0:i386
libsystemd-login0 marble pairs parley parley-data
plasma-scriptengine-superkaramba print-manager python-gconf
python-gnome2 python-gtk-vnc python-ipy python-pyorbit
qtdeclarative4-kqtquickcharts-1 rocs step
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
colord* gvfs* gvfs-backends* gvfs-daemons* hplip* hplip-gui*
kde-full* kde-plasma-desktop* kde-plasma-netbook*
kde-standard* libpam-systemd* network-manager* packagekit*
packagekit-tools* plasma-nm* plasma-widget-networkmanagement*
policykit-1* policykit-1-gnome* polkit-kde-1*
printer-driver-postscript-hp* systemd* udisks2*
0 upgraded, 0 newly installed, 22 to remove and 129 not upgraded.
After this operation, 37.4 MB disk space will be freed.
Do you want to continue? [Y/n]


And I wonder why exactly is this an *advantage* or in what way is this a
disadvantage that makes a bigger advantage possible?

But business does network management, device management have to depend on
something that started as I perceived it, as a init system replacement.

Much of the feedback is related to that. Many would appreciate something like
systemd if it just did *services* stuff. That is also what seemed to have
motivated the dev behind the use less d fork.
Post by Lennart Poettering
Yes, we knew exactly we'd be getting a lot of heat for all this. We
have been getting it from the day on we announced the project. And I
am pretty sure it will continue this way for a while still.
(What I didn't expect though is how awful the Linux community can
actually be. That people collect Bitcoins to hire a hitman on me, that
people start petitions to make me stop working, and all that other
really hateful, personal stuff is really apalling. I guess I have a
thick skin, because I don't care too much, but jeezus christ, it's
really disgusting sometimes.)
I am sad about this kind of feedback. Not only do I think its inapprobiate.
Not only do I have compassion with you that as I imagine it is not easy to be
on the receiving side of personal attacks like this, but I also think that
people choosing that way of communication do not help at all to facilitate
change.

I personally wouldn´t expect you do read through such kind of feedback. I
think I personally would try my best to ignore it *completely*. Anyone who
wants to facilitate change needs to understand that accusing someone in person
is a powerful way of sabotaging to facitilitate change. I never seen attacking
another one in person every created any beneficial result. That could only be
achieved if at least one person in that communication steps out of this way of
communication. As… it seems you did if you read the feedback between the lines
of hate.

I´d even by fine with people expressing anger. I am angry at that and that and
that. But personal attacks like the recent troll postings on several
mailinglists are off limits for me.
Post by Lennart Poettering
I monitor the feedback posted on the Internet regularly. I browse
reddit and the debian and gentoo mailing list archives sometimes, and
try to distill the useful bits out of all the noise and hate dumped
there. This actually used to be very productive for quite some time,
[…]
Post by Lennart Poettering
The current increase noised level around systemd adoption I attribute
to three things: the fact that RHEL7 is out now, the fact that due to
the adoption of systemd as default by Debian and Ubuntu the folks who
ignored the discussion so far now are faced with this change, and also
to a big part to certain "columnists" who in the interest of
generating traffic to their sites try to create a hubbub out of very
little.
Anyway, long story short: we knew what we did, and yeah, I read
feedback, even if it is written in a hateful style, and we learn from
it.
Well, I for myself have been concerned and surprised by *such an mount* of
uproar. Not even GNOME 3 triggered anywhere near that amount of threads and
mails.

And I worry regarding various attempts to replace systemd functionality (by
systembsd services) and by use less d or using different inits. I think quite
some of them are based on solid technical arguments. I wonder whether systemd
might be missing out on something here.

And I worry about a deep split between people who are into the UNIX mantra to
do one thing and do it well… and highly integration people, systemd upstream
and adopters. Actually I do see vadility in the UNIX mantra. In the KISS
principle. It has a point to it.
Post by Lennart Poettering
Post by Martin Steigerwald
For now I use systemd. I like quite some features. But on the other hand I
am vary about it myself. I look at a 45 KiB binary for /sbin/init as PID1
and a 1,3 MiB binary in systemd 215 and wonder myself. I see systemd
--user
Well, note that systemd used for user services actually saves you
resources, as the systemd binary only needs to be mapped into memory
once and then is shared between all user instances and the system
instance.
But what about the argument of stability? Arguably a 1,3 MiB binary have more
chances for bugs and security problems. What happens if PID 1 crashes? I heard
about that systemd would in some circumstances have the chance to get
restarted.

And… with two binaries and a library or so… wouldn´t the result – i.e. the
memory footprint – the same? Except some per process data area all would be
mapped once.
Post by Lennart Poettering
Post by Martin Steigerwald
Is it really all just nay-sayers for the sake of nay-saying?
No, it's not that simple.
Post by Martin Steigerwald
Or do they – at least partly – provide *valuable* and *important*
feedback.
Well, some is valuable and important, but much certainly isn't. The
200nd complaint that systemd was "monolithic" or so is something I am
genuinely not interested in anymore, for example...
Why do you think there is no point or vadility in it?

systemd does a lot. And an 1,3 MiB binary is a hug binary size for something
that started out as managing services and sessions via control cgroups.
Post by Lennart Poettering
I will continue to scan reddit and the mailing list archives for stuff
I find, but of course, I always prefer if people would contact us
directly and constructively with feature or change requests, instead
of requiring me to follow these forums...
Let me stress this: constructive feedback is *always* welcome!
Well… I may post much more in this thread. As I find time I will read through
it… yet I invitated anyone on debian-user to voice their concern there… as
long as no one does, I for myself try to refrain from discussions there… cause
its pointless. If its just venting frustration endlessly and repeating the
same arguments over and over and over and over again… I´d rather – despite my
mixed feelings and also technical doubts about systemd – I give it a chance
nonetheless to see how it actually works out in practice. While repeating each
and any bug I find with scrutiny. For me systemd still have to prove itself. I
didn´t see any PID 1 crash so far. But I will watch it carefully for any
erratic behaviour.

Actually I did a step to point and the concerns and raise user voices here, if
users do not chime in and just think you wouldn´t be receptive to constructive
feedback… well… some may argue they provided constructive feedback and got
ignored… well… I pointed at various ways to handle systemd adoption in Debian.
Users can also decide to help test the alternatives. Unlike other distros
Debian still supports them.

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Martin Steigerwald
2014-10-05 10:25:08 UTC
Permalink
Post by Martin Steigerwald
Well… I may post much more in this thread.
not post much more
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Lennart Poettering
2014-10-06 12:57:17 UTC
Permalink
Post by Martin Steigerwald
Post by Lennart Poettering
However, I also believe that the change we are making is for the good,
and even though it might not be obvious to many immediately, it brings
major benefits when administering machines, and they massively
outweigh the disadvantage of changing things. And apparently I am not
entirely alone with this, as the folks who make technical decision for
the various distributions ended up deciding in favour of systemd in
most cases.
Why do you believe so? What key points make you believe so?
Believe what precisely? Why I believe systemd is better than sysvinit?
Well, that's a big question, and I am pretty sure already well enough
discussed elsewhere, that we really do't have to repeat this here.
Post by Martin Steigerwald
Here the feedback I read over and over again is that you and RedHat basically
forced the systemd decision onto other distributions. While I do not see how
you actually can be powerful enough to do that, as we live in a free will
zone. I do see tendencies that more and more stuff *depends* on systemd cause
it needs features only available there.
Well, we provide good APIs. We provide them for a reason, because
applications benefit from them. App developers see that, so they adopt
them. That's pretty natural and obvious, no? If you want to know more,
about why they do that, then ask them.

What I find so puzzling about certain aspects of the criticism is that
some people apparently assume that logind and similar things were
entirely redundant, and that the APIs that it provides were so
redundant, that one could trivially write the same app, but not make
use of them... This idea that logind had exactly no merits, and was
little more than just an evil tool to drive systemd adoption...
Post by Martin Steigerwald
Dependencies like this actually create some force to adopt systemd.
Well, I certainly don't force anybody. We provide APIs for technical
reasons, and because we believe that people might benefit from them,
even need them. And apparently I am not too wrong with that, after all
they tend to adopt them...
Post by Martin Steigerwald
Now I know ConsoleKit isn´t developed anymore, but also I never got why a
logind implementation needs to depend on systemd base package in such a way
that at least in Debian systemd package has to be installed if someone wants
to use GNOME.
Well, logind talks to systemd to manage user sessions and user
processes in cgroups. That's why it depends on systemd. And since only
systemd implements that, we couldn't even support anything else even
if we wanted.

Our intention with systemd is to provide a strong platform. One
platform. If people want to use our code in other contexts, then
that's totally fine, but please understand that I am not going to do
any work for that, I am not going to maintain it, and I don't want to
see that in my code.
Post by Martin Steigerwald
Much of the feedback is related to that. Many would appreciate something like
systemd if it just did *services* stuff. That is also what seemed to have
motivated the dev behind the use less d fork.
Well, I am sorry, but systemd is more than that. If systemd is no what
people want, they can roll their own thing, can continue to use
sysvinit, or even fork systemd, That's completely OK. But for what we
have in mind for systemd it's definitely a goal to make Linux more
attractive for developers, by providing a good set of core OS APIs
that people can just make use of, instead of a zoo of things that are
combined in wild combinations.
Post by Martin Steigerwald
Post by Lennart Poettering
The current increase noised level around systemd adoption I attribute
to three things: the fact that RHEL7 is out now, the fact that due to
the adoption of systemd as default by Debian and Ubuntu the folks who
ignored the discussion so far now are faced with this change, and also
to a big part to certain "columnists" who in the interest of
generating traffic to their sites try to create a hubbub out of very
little.
Anyway, long story short: we knew what we did, and yeah, I read
feedback, even if it is written in a hateful style, and we learn from
it.
Well, I for myself have been concerned and surprised by *such an mount* of
uproar. Not even GNOME 3 triggered anywhere near that amount of threads and
mails.
Well, I am not sure this is really that way. GNOME 3 noise was pretty bad too,
maybe you just weren't involved so closely... But even if it wasn't,
our stuff touches most of the Linux community, which is larger than
the GNOME community.
Post by Martin Steigerwald
And I worry regarding various attempts to replace systemd functionality (by
systembsd services) and by use less d or using different inits. I think quite
some of them are based on solid technical arguments. I wonder whether systemd
might be missing out on something here.
Well, some competition would be great. I am pretty sure that uselessd
is not based on solid technical arguments though, and pretty sure
it's maintainer will figure that out pretty soon too...

Anyway, more power to him, at least he does soemthing, and isn't just
one of the do-nothing complainers, even if I certainly disagree with
much of his technical reasonings and decisions.
Post by Martin Steigerwald
Post by Lennart Poettering
Well, note that systemd used for user services actually saves you
resources, as the systemd binary only needs to be mapped into memory
once and then is shared between all user instances and the system
instance.
But what about the argument of stability? Arguably a 1,3 MiB binary have more
chances for bugs and security problems. What happens if PID 1 crashes? I heard
about that systemd would in some circumstances have the chance to get
restarted.
So far we are doing pretty well with stability. And why would be
multiple different binaries from different projects be any more stable
than a single one we reuse at multiple places?

systemd does a lot more than sysvinit. It's larger because of
that. That's hardly surprising.

systemd is a fraction in size of the Linux kernel. If something in the
Linux kernel goes wrong it's a lot worse than if it goes wrong in PID
1. If the Linux kernel can manage the stability, so can we for
systemd.

(Heck! even wpa_supplicant has more lines of code and binary footprint
that the systemd binary!)
Post by Martin Steigerwald
And… with two binaries and a library or so… wouldn´t the result – i.e. the
memory footprint – the same? Except some per process data area all would be
mapped once.
Not following? Are you suggesting that systemd would be more stable if
we built the systemd binary in two versions and would link the common
code as shared library?

I am sorry, but that's not really how this works...
Post by Martin Steigerwald
Post by Lennart Poettering
Well, some is valuable and important, but much certainly isn't. The
200nd complaint that systemd was "monolithic" or so is something I am
genuinely not interested in anymore, for example...
Why do you think there is no point or vadility in it?
Because it has been discussed 199 times before. Because it isn't true,
unless you define what "monolithic" means to your own taste?

I mean, I am pretty sure the "monolithic" argument is really not about
anything technical. It's more about the fear that the systemd folks
monopolize too much influence over the whole system, and that they'd
rather see that splinter.

I can understand that feeling. We try to work against it, by
diversifying who can commit to systemd and things like that, but
ultimately, if people don't like if only the systemd group pushes the
OS forward all alone, then we can do little about it. People would
have to actually do something on their own, and if people just talk
and don't act, then yes, there will be only us left...

We will not split up systemd into multiple tarballs or repos, just to
create fake sense of "bazaar"... The stuff we do is supposed to be
streamlined, and uniform in its appearance. While you can adjust it
pretty neatly to your specific needs by picking only the components
you care about it, ultimately whether it's one repo or more, or one
tarball or multiple is just a boring technical detail that matters
only for building things and reusing code...
Post by Martin Steigerwald
systemd does a lot. And an 1,3 MiB binary is a hug binary size for something
that started out as managing services and sessions via control
cgroups.
Well, it does a lot more these days.

The Linux kernel also started out pretty small too. Nowadays it does a
lot more, which makes it so unversially applicable. I figure systemd
goes a similar path. (Though hopefully will never grow as massive,
complex and monolithic as the kernel...)

Lennart
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2014-10-06 14:34:27 UTC
Permalink
Post by Lennart Poettering
Post by Martin Steigerwald
systemd does a lot. And an 1,3 MiB binary is a hug binary size for something
that started out as managing services and sessions via control cgroups.
Well, it does a lot more these days.
The Linux kernel also started out pretty small too. Nowadays it does a
lot more, which makes it so unversially applicable. I figure systemd
goes a similar path. (Though hopefully will never grow as massive,
complex and monolithic as the kernel...)
This is an interesting question, where this 1.3 MB comes from.

objdump -t ./systemd|sed -r -n 's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ \t]*([0-9a-z]+)[ \t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail

0000000000000a13 service_deserialize_item -- .text
0000000000000a6e cgroup_context_apply -- .text
0000000000000ae2 socket_apply_socket_options -- .text
0000000000000b00 rtnl_types -- .data.rel.ro.local
0000000000000b32 exec_context_dump -- .text
0000000000000d50 bus_exec_vtable -- .data.rel.ro
0000000000000d62 transaction_add_job_and_dependencies -- .text
0000000000000e40 bus_unit_vtable -- .data.rel.ro
00000000000011d7 bus_cgroup_set_property -- .text
0000000000001410 bus_manager_vtable -- .data.rel.ro
0000000000001453 exec_child -- .text
0000000000001470 wordlist.7848 -- .data.rel.ro.local
0000000000002b90 main -- .text
000000000000e1c0 wordlist.14097 -- .data.rel.ro

wordlist.14097 is a generated table for all configuration options in
load-fragment-gperf.c.

wordlist.7848 is for errno_from_name (5k for this is a bit of a
stretch though).

There's pretty complex code (main is 11k), combined with a large
number of configuration and reporting code (the wordlists, vtables,
exec_context_dump).

This shows that splitting the binary into two would not be really
effective: this code would essentially have to be duplicated, once for
communication between PID 1 and the helper, and second time for
communication between the helpers and the rest, i.e. the existing code.

--

I think this hasn't been mentioned in this thread, but PID1 is
shrinking at least a bit, because a bunch of things which used to be
implemented in PID1 have been outsourced to generators.
./systemd-sysv-generator, ./systemd-fstab-generator are relatively
recent and significant.

Zbyszek
Lennart Poettering
2014-10-06 15:14:17 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Post by Martin Steigerwald
systemd does a lot. And an 1,3 MiB binary is a hug binary size for something
that started out as managing services and sessions via control cgroups.
Well, it does a lot more these days.
The Linux kernel also started out pretty small too. Nowadays it does a
lot more, which makes it so unversially applicable. I figure systemd
goes a similar path. (Though hopefully will never grow as massive,
complex and monolithic as the kernel...)
This is an interesting question, where this 1.3 MB comes from.
objdump -t ./systemd|sed -r -n 's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ \t]*([0-9a-z]+)[ \t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail
0000000000000a13 service_deserialize_item -- .text
0000000000000a6e cgroup_context_apply -- .text
0000000000000ae2 socket_apply_socket_options -- .text
0000000000000b00 rtnl_types -- .data.rel.ro.local
0000000000000b32 exec_context_dump -- .text
0000000000000d50 bus_exec_vtable -- .data.rel.ro
0000000000000d62 transaction_add_job_and_dependencies -- .text
0000000000000e40 bus_unit_vtable -- .data.rel.ro
00000000000011d7 bus_cgroup_set_property -- .text
0000000000001410 bus_manager_vtable -- .data.rel.ro
0000000000001453 exec_child -- .text
0000000000001470 wordlist.7848 -- .data.rel.ro.local
0000000000002b90 main -- .text
000000000000e1c0 wordlist.14097 -- .data.rel.ro
wordlist.14097 is a generated table for all configuration options in
load-fragment-gperf.c.
wordlist.7848 is for errno_from_name (5k for this is a bit of a
stretch though).
I wonder if any of these tables might have holes in them? i.e. some
enums skip a few numbers in the middle, and are thus not really
appropriate for the usual DEFINE_STRING_TABLE() stuff we do?
Post by Zbigniew Jędrzejewski-Szmek
I think this hasn't been mentioned in this thread, but PID1 is
shrinking at least a bit, because a bunch of things which used to be
implemented in PID1 have been outsourced to generators.
./systemd-sysv-generator, ./systemd-fstab-generator are relatively
recent and significant.
And I'd be willing to split out more, but I am not sure currently what
could be a good candidate.

Lennart
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2014-10-06 15:38:15 UTC
Permalink
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Post by Martin Steigerwald
systemd does a lot. And an 1,3 MiB binary is a hug binary size for something
that started out as managing services and sessions via control cgroups.
Well, it does a lot more these days.
The Linux kernel also started out pretty small too. Nowadays it does a
lot more, which makes it so unversially applicable. I figure systemd
goes a similar path. (Though hopefully will never grow as massive,
complex and monolithic as the kernel...)
This is an interesting question, where this 1.3 MB comes from.
objdump -t ./systemd|sed -r -n 's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ \t]*([0-9a-z]+)[ \t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail
0000000000000a13 service_deserialize_item -- .text
0000000000000a6e cgroup_context_apply -- .text
0000000000000ae2 socket_apply_socket_options -- .text
0000000000000b00 rtnl_types -- .data.rel.ro.local
0000000000000b32 exec_context_dump -- .text
0000000000000d50 bus_exec_vtable -- .data.rel.ro
0000000000000d62 transaction_add_job_and_dependencies -- .text
0000000000000e40 bus_unit_vtable -- .data.rel.ro
00000000000011d7 bus_cgroup_set_property -- .text
0000000000001410 bus_manager_vtable -- .data.rel.ro
0000000000001453 exec_child -- .text
0000000000001470 wordlist.7848 -- .data.rel.ro.local
0000000000002b90 main -- .text
000000000000e1c0 wordlist.14097 -- .data.rel.ro
wordlist.14097 is a generated table for all configuration options in
load-fragment-gperf.c.
wordlist.7848 is for errno_from_name (5k for this is a bit of a
stretch though).
I wonder if any of these tables might have holes in them? i.e. some
enums skip a few numbers in the middle, and are thus not really
appropriate for the usual DEFINE_STRING_TABLE() stuff we do?
I think it's like a hash table, i.e. approx %50 empty on purpose.

At least in case load load-fragment-gperf, we are trading a bit of
space for speed in an important code path, so I'm sure it is worth
it. The errno stuff isn't probably that important, because iiuc we
won't even load this page until it is used, so again, this seems fine.

Zbyszek
Rob Owens
2014-10-06 18:56:22 UTC
Permalink
----- Original Message -----
Post by Martin Steigerwald
Heck, I started a thread here and then didn´t manage to take time to carefully
read it and reply here and there as I see fit. But I challenged people on
debian-user mailing list to constructively voice their concerns upstream, and
even pointed them to this mailing list. As far as I saw *no one* of the
posters in debian-user took up on that challenge. Which I view as a pity.
Cause now actually you invited constructive feedback. I wonder whether I may
forward your answer to debian-user so they see your statement of inviting
constructive feedback.
I am here from debian-user, due to Martin's suggestion. So now that he's calling me out, I guess I'll post my questions :)

For the record, I'm a sysadmin and not a developer. I imagine my questions and opinions will reflect that.
Post by Martin Steigerwald
Here the feedback I read over and over again is that you and RedHat basically
forced the systemd decision onto other distributions. While I do not see how
you actually can be powerful enough to do that, as we live in a free will
zone. I do see tendencies that more and more stuff *depends* on systemd cause
it needs features only available there.
On of the most talked on things on debian-user is the logind thing. GNOME
actually depends on it, as far as I know. While KDE in Debian still uses
On Debian, I came across an unusual dependency. Installing a cd burner (brasero) required me to change my init system to systemd. Sounds kind of ridiculous, I think. The dependency chain went like this:

brasero -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd -> systemd-sysv

I don't know enough about this stuff to comment very intelligently, which is why I haven't said anything up until now. But my research shows that each of these dependencies is indeed valid in the sense that each dependency represents some real requirement for functionality. The issue, I think, is that some of these packages provide very broad functionality. As I put it in a Debian bug report:

Brasero needs X functionality, which can be found in package W. Package W also provides Y functionality, which depends on systemd-sysv. So therefore brasero depends on systemd-sysv, even though it doesn't *need* it.

I gather that this has something to do with logind and/or cgroups. I can appreciate the benefits (on some systems) of giving only the local user access to removable media. But I don't understand why this functionality requires the use of systemd-sysv (the init system), particularly if my understanding is correct that this functionality used to be separate from the init portion of systemd.
Post by Martin Steigerwald
Dependencies like this actually create some force to adopt systemd.
Based on Lennart's and others' comments in this thread, forced adoption does not seem to be a goal. But forced adoption is a reality due to dependencies like the one above. I think there would be a lot less skepticism about systemd if the perception of forced adoption weren't so strong, and I'd love to see something done about this situation.
Post by Martin Steigerwald
Now I know ConsoleKit isn´t developed anymore, but also I never got why a
logind implementation needs to depend on systemd base package in such a way
that at least in Debian systemd package has to be installed if someone wants
to use GNOME.
Is this what Debian's systemd-shim is for? If not, well I'm going to talk about that anyway...

Systemd-shim provides some functionality that systemd-sysv provides, and allows admins to use init systems other than systemd while still installing things like brasero. I think this is a great thing, except I wonder why the systemd project didn't separate this functionality from the init system in the first place. Systemd-shim is a duplication of effort. Not only that, but it must time its releases with the releases of systemd-sysv. That's no big deal for Debian's stable release, but it can be problematic in Debian's unstable and testing branches.

Wouldn't the systemd developers prefer to have their implementation of this functionality be used, regardless of the chosen init system?
Post by Martin Steigerwald
Post by Lennart Poettering
Let me stress this: constructive feedback is *always* welcome!
The following may not concern you personally, but Debian is attempting to support multiple kernels (Linux, BSD and Hurd I think). As I understand it, systemd is Linux-only. Defaulting to a Linux-only init system makes supporting non-Linux kernels more work, because an alternate init system must be maintained, as well as init scripts for that init system. If functionality was separated as I described above, and the systemd project provided a very basic init-only package, would that be portable to non-Linux kernels?
Post by Martin Steigerwald
Users can also decide to help test the alternatives. Unlike other distros
Debian still supports them.
But systemd's approach of incorporating additional "non-init" features into its init system (what some people mean when they say "monolithic") is making it difficult to support the alternatives. Which is one reason I'm asking you to consider keeping the init portion of systemd and all the other stuff separately installable. I see good benefits in all that other stuff for some/many applications. In other applications sysvinit is jsut fine, in which case switching to systemd really just represents a waste of the sysadmin's resources because he has to learn new syntax/methodology/etc for no new functionality (that he cares about).

I hope that last paragraph didn't come across as too harsh. I do mean all my criticisms to be constructive.

-Rob
Martin Pitt
2014-10-06 19:45:33 UTC
Permalink
Hello Rob,

this is higly Debian specific (doesn't even apply to Ubuntu) and thus
a bit off-topic, but as the question already is on the upstream ML..
sorry!
Post by Rob Owens
brasero -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd -> systemd-sysv
You can break it up after libpam-systemd, as this has dependency
alternatives to systemd-shim. With that you can use sysvinit or
upstart. But currently systemd-sysv is the preferred alternative, so
if you don't specify anything else it will pick systemd-sysv. You can
do e. g. "apt-get install brasero systemd-shim" to select another (or
install -shim first).
Post by Rob Owens
I gather that this has something to do with logind and/or cgroups.
That's correct; in fact most desktop-y software talks to logind
only, but logind is a crucial component on a modern desktop.
Post by Rob Owens
Systemd-shim is a duplication of effort.
It's a looong story/history, but systemd-shim itself is actually
fairly small. It's mostly glue to provide systemd's D-BUS API and
implement it in terms of other components like cgmanager and pm-utils.
And its development was quite inevitable at least from
Debian's/Ubuntu's perspective as it is just practically impossible to
do a SysV/upstart → systemd migration on a flag day.
Post by Rob Owens
Not only that, but it must time its releases with the releases of
systemd-sysv.
Mostly not. That needs to happen for D-BUS API changes like they
happened around version 209, but that happens fairly seldomly.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Zbigniew Jędrzejewski-Szmek
2014-10-06 19:53:04 UTC
Permalink
Post by Rob Owens
----- Original Message -----
Post by Martin Steigerwald
Heck, I started a thread here and then didn´t manage to take time to carefully
read it and reply here and there as I see fit. But I challenged people on
debian-user mailing list to constructively voice their concerns upstream, and
even pointed them to this mailing list. As far as I saw *no one* of the
posters in debian-user took up on that challenge. Which I view as a pity.
Cause now actually you invited constructive feedback. I wonder whether I may
forward your answer to debian-user so they see your statement of inviting
constructive feedback.
I am here from debian-user, due to Martin's suggestion. So now that he's calling me out, I guess I'll post my questions :)
For the record, I'm a sysadmin and not a developer. I imagine my questions and opinions will reflect that.
Post by Martin Steigerwald
Here the feedback I read over and over again is that you and RedHat basically
forced the systemd decision onto other distributions. While I do not see how
you actually can be powerful enough to do that, as we live in a free will
zone. I do see tendencies that more and more stuff *depends* on systemd cause
it needs features only available there.
On of the most talked on things on debian-user is the logind thing. GNOME
actually depends on it, as far as I know. While KDE in Debian still uses
brasero -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd -> systemd-sysv
Brasero needs X functionality, which can be found in package W. Package W also provides Y functionality, which depends on systemd-sysv. So therefore brasero depends on systemd-sysv, even though it doesn't *need* it.
I gather that this has something to do with logind and/or cgroups. I can appreciate the benefits (on some systems) of giving only the local user access to removable media. But I don't understand why this functionality requires the use of systemd-sysv (the init system), particularly if my understanding is correct that this functionality used to be separate from the init portion of systemd.
I'll assume that this is a serious question, despite being rather
elementary...

You describe a dependency chain. First of all, it is important to note
that it does not matter if brasero actually uses the part of gvfs that
uses the part of udisk2 that uses the part of libpam-systemd that
requires systemd to be running. Possibly not, and maybe brasero would
still function correctly w/o systemd. But dependencies are expressed
on package level, so if systemd is required for some functionality of
libpam-systemd, which is used by any package depending on
libpam-systemd, then libpam-systemd must depend on systemd-sysv, and
transitively so must brasero.

To break this chain at some point, it is necessary replace the strict
dependency with "recommends/suggests" or provide a different different
package which satisfies the dependency. The first option is only
possible if the functionality provided by the dependent package
is not essential. In some cases it is really clear, e.g. a binary
requires a library to be installed to be able to run, but in
other cases it's a judgment call by the maintainers, whether some
part of functionality is important enough to add a dependency.
In this case brasero, gvfs, udisks2, and systemd maintainers decided
that yes, it is.

The second option requires someone to step up and provide an
alternative implementation. So far, systemd-shim is one candidate, but
it took months to appear and still has occasional problems. (I don't
follow the situation quite closely, but Michael seems to find serious
bugs with very light testing). At some point, systemd-shim might
become a viable replacement. This work should be done by people who
want the alternatives, not the maintainers of systemd, who happily use
the existing stack. So if the alternatives are not in the shape you
would like them to be, inquire with the maintainers of the said
alternatives.

But even assuming that an alternative is functional, using it is not
without costs for the maintainers of dependent packages. Let's say
that we have some systems with systemd, some with systemd-shim. It is
likely that a bug report for udisk2 might require the maintainer to
ask which of the alternatives is used. For such basic functionality
that influences the whole OS, if the maintainer uses a different
init, it is like being on a different architecture. It makes things
hard to debug, hard to test, and greatly distracts from the time
the maintainer has available to really fix bugs. It is not free, and
diminishes the appeal of the whole distribution. It might be that
this alternative dependency has advantages which outweigh this cost.
But seriously, is SysV init that great?
Post by Rob Owens
Post by Martin Steigerwald
Dependencies like this actually create some force to adopt systemd.
Based on Lennart's and others' comments in this thread, forced adoption does not seem to be a goal. But forced adoption is a reality due to dependencies like the one above. I think there would be a lot less skepticism about systemd if the perception of forced adoption weren't so strong, and I'd love to see something done about this situation.
Post by Martin Steigerwald
Now I know ConsoleKit isn´t developed anymore, but also I never got why a
logind implementation needs to depend on systemd base package in such a way
that at least in Debian systemd package has to be installed if someone wants
to use GNOME.
Is this what Debian's systemd-shim is for? If not, well I'm going to talk about that anyway...
Systemd-shim provides some functionality that systemd-sysv provides,
and allows admins to use init systems other than systemd while still
installing things like brasero. I think this is a great thing,
except I wonder why the systemd project didn't separate this
functionality from the init system in the first place. Systemd-shim
is a duplication of effort. Not only that, but it must time its
releases with the releases of systemd-sysv. That's no big deal for
Debian's stable release, but it can be problematic in Debian's
unstable and testing branches.

Because it's additional work and complications. Apparently providing
systemd functionality without systemd running is not a trivial
undertaking, as the lag between systemd and systemd-shim releases
shows. I could spend my time for open source development on a
(technically) pointless (from my vantage point) split, but I
prefer to improve systemd instead.

Debian as a project already paid significant to support systemd as an
alternative, when systemd version was held back for a year waiting
for systemd-shim to catch up. This is certainly not the last time.

[snip]

Zbyszek
Rob Owens
2014-10-07 18:15:20 UTC
Permalink
----- Original Message -----
Post by Zbigniew Jędrzejewski-Szmek
Post by Rob Owens
On Debian, I came across an unusual dependency. Installing a cd burner
(brasero) required me to change my init system to systemd. Sounds kind of
brasero -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd -> systemd-sysv
I don't know enough about this stuff to comment very intelligently, which
is why I haven't said anything up until now. But my research shows that
each of these dependencies is indeed valid in the sense that each
dependency represents some real requirement for functionality. The issue,
I think, is that some of these packages provide very broad functionality.
Brasero needs X functionality, which can be found in package W. Package W
also provides Y functionality, which depends on systemd-sysv. So
therefore brasero depends on systemd-sysv, even though it doesn't *need*
it.
I gather that this has something to do with logind and/or cgroups. I can
appreciate the benefits (on some systems) of giving only the local user
access to removable media. But I don't understand why this functionality
requires the use of systemd-sysv (the init system), particularly if my
understanding is correct that this functionality used to be separate from
the init portion of systemd.
I'll assume that this is a serious question, despite being rather
elementary...
My question really isn't "why are the Debian dependencies the way they are". I understand that. I was trying to highlight the strange situation of a desktop application requiring a particular init system. I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd. To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate. Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains.

I am trying to demonstrate the drawbacks of the decision to combine logind with the init portion of systemd. I'm giving you an outsider's point of view. I realize that most of the folks on this list probably love all of systemd and couldn't imagine why anyone would want to have just bits and pieces of it. But I think my previous email gave some good reasons. If not, let me know and I'll try to be more clear about it.
Post by Zbigniew Jędrzejewski-Szmek
The second option requires someone to step up and provide an
alternative implementation. So far, systemd-shim is one candidate, but
it took months to appear and still has occasional problems. (I don't
follow the situation quite closely, but Michael seems to find serious
bugs with very light testing). At some point, systemd-shim might
become a viable replacement. This work should be done by people who
want the alternatives, not the maintainers of systemd, who happily use
the existing stack. So if the alternatives are not in the shape you
would like them to be, inquire with the maintainers of the said
alternatives.
But even assuming that an alternative is functional, using it is not
without costs for the maintainers of dependent packages. Let's say
that we have some systems with systemd, some with systemd-shim. It is
likely that a bug report for udisk2 might require the maintainer to
ask which of the alternatives is used. For such basic functionality
that influences the whole OS, if the maintainer uses a different
init, it is like being on a different architecture. It makes things
hard to debug, hard to test, and greatly distracts from the time
the maintainer has available to really fix bugs. It is not free, and
diminishes the appeal of the whole distribution. It might be that
this alternative dependency has advantages which outweigh this cost.
I think everything you said in these two paragraphs could be used to support the argument of keeping logind separate from init. Then everybody would be using your logind code, and there would be no need for systemd-shim. There still would be the issue for package maintainers of supporting multiple init systems, but that's Debian's decision to do so.
Post by Zbigniew Jędrzejewski-Szmek
But seriously, is SysV init that great?
I never thought much about my init system until recently. I never really had any complaints with SysV init, although I do recognize that systemd provides real improvements for some use cases. So for me as a sysadmin the wisest thing to do is stick with what I already know, as long as it's working well enough (and for me, it is).
Post by Zbigniew Jędrzejewski-Szmek
Post by Rob Owens
Systemd-shim provides some functionality that systemd-sysv provides,
and allows admins to use init systems other than systemd while still
installing things like brasero. I think this is a great thing,
except I wonder why the systemd project didn't separate this
functionality from the init system in the first place. Systemd-shim
is a duplication of effort. Not only that, but it must time its
releases with the releases of systemd-sysv. That's no big deal for
Debian's stable release, but it can be problematic in Debian's
unstable and testing branches.
Because it's additional work and complications. Apparently providing
systemd functionality without systemd running is not a trivial
undertaking, as the lag between systemd and systemd-shim releases
shows. I could spend my time for open source development on a
(technically) pointless (from my vantage point) split, but I
prefer to improve systemd instead.
I have to take your word for it, because I don't know enough to accurately judge the amount of work it would take. Is the act of splitting up the functionality the part that creates the work? Or is it in maintaining such a code base? In other words, is the additional work a one-time thing or would it be additional work from now until eternity?

For the record, I am finding that systemd-shim is doing a pretty good job of providing timely updates. In fact, recently in Debian Testing we had the situation where a newer version of systemd-shim was available before that version of systemd was available. I don't expect that to happen often, but it did happen! But I feel for the systemd-shim guys because they will constantly be under the gun to duplicate the systemd functionality in a timely manner. And I can't help but wonder if this whole situation is avoidable.

-Rob
Uoti Urpala
2014-10-07 20:40:45 UTC
Permalink
Post by Rob Owens
My question really isn't "why are the Debian dependencies the way they are". I understand that. I was trying to highlight the strange situation of a desktop application requiring a particular init system. I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd. To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate. Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains.
"Single binary" is false of course. Logind is developed as a separate
program, which is why systemd-shim is possible at all.

AFAIK the actual relevant dependencies go as follows: First, there's a
good reason why logind requires cgroup functionality. And there's a good
reason why cgroup functionality is best implemented together with init
(see
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
for more info). So it's not quite directly "logind has to depend on
systemd as init", but "logind has to depend on the system having cgroup
support, and there's no equally good cgroup support available for inits
other than systemd". It is possible to provide the relevant cgroup
interfaces in or on top of another init, as the systemd-sysv + cgmanager
combination attempts to do. But it is not trivial to do, as bugs and
implementation delays with that combo have shown, and it's quite likely
that there will be more problems in the future. It's not a particularly
good idea to use the less-tested and less-reliable systemd-shim instead
of the more reliable systemd. Thus the overall result is that yes, it
does make sense to switch machines to systemd when you add certain
functionality, even if that functionality does not appear to be directly
tied to the init system at first glance.
Post by Rob Owens
I never thought much about my init system until recently. I never really had any complaints with SysV init, although I do recognize that systemd provides real improvements for some use cases. So for me as a sysadmin the wisest thing to do is stick with what I already know, as long as it's working well enough (and for me, it is).
The issue with "I should be able to stay with sysvinit because it worked
fine for me" is that keeping sysvinit working is COSTLY. The reason
sysvinit used to mostly work was not that it would have been a reliable
system - it mostly worked because people kept using a lot of effort to
work around and paper over various issues that kept popping up. And
there's no justification to keep up that effort for the minority who
wants to stay with sysvinit. So, you can keep running your old systems
unchanged if you want, but you shouldn't expect to be able to upgrade
them or install new software without switching to systemd.
Lennart Poettering
2014-10-08 08:54:00 UTC
Permalink
Post by Uoti Urpala
Post by Rob Owens
My question really isn't "why are the Debian dependencies the way they are". I understand that. I was trying to highlight the strange situation of a desktop application requiring a particular init system. I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd. To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate. Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains.
"Single binary" is false of course. Logind is developed as a separate
program, which is why systemd-shim is possible at all.
AFAIK the actual relevant dependencies go as follows: First, there's a
good reason why logind requires cgroup functionality. And there's a good
reason why cgroup functionality is best implemented together with init
(see
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
for more info). So it's not quite directly "logind has to depend on
systemd as init", but "logind has to depend on the system having cgroup
support, and there's no equally good cgroup support available for inits
other than systemd". It is possible to provide the relevant cgroup
interfaces in or on top of another init, as the systemd-sysv + cgmanager
combination attempts to do. But it is not trivial to do, as bugs and
implementation delays with that combo have shown, and it's quite likely
that there will be more problems in the future. It's not a particularly
good idea to use the less-tested and less-reliable systemd-shim instead
of the more reliable systemd. Thus the overall result is that yes, it
does make sense to switch machines to systemd when you add certain
functionality, even if that functionality does not appear to be directly
tied to the init system at first glance.
Also note that the systemd concepts logind makes use of are also
exported in its own API. The "scopes" and "slices" that logind uses
are exposed on its bus objects, and they are used by tools like
"loginctl" to do their work.

The "scopes" and "slices" concept does not exist elsewhere, and
there's nothing comparable around, so even if we wanted we couldn't
make logind work on anything else.

Lennart
--
Lennart Poettering, Red Hat
Martin Steigerwald
2014-10-21 09:25:21 UTC
Permalink
Post by Lennart Poettering
Post by Uoti Urpala
Post by Rob Owens
My question really isn't "why are the Debian dependencies the way they
are". I understand that. I was trying to highlight the strange
situation of a desktop application requiring a particular init system.
I *think* this is a result of the init portion of systemd being bundled
together with the logind portion of systemd. To me (unfamiliar with
the systemd code) those two functions seem distinct enough to merit
being separate. Debian can't easily separate what the systemd devs
have developed as a single binary, so we end up with these strange
dependency chains.>
"Single binary" is false of course. Logind is developed as a separate
program, which is why systemd-shim is possible at all.
AFAIK the actual relevant dependencies go as follows: First, there's a
good reason why logind requires cgroup functionality. And there's a good
reason why cgroup functionality is best implemented together with init
(see
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
for more info). So it's not quite directly "logind has to depend on
systemd as init", but "logind has to depend on the system having cgroup
support, and there's no equally good cgroup support available for inits
other than systemd". It is possible to provide the relevant cgroup
interfaces in or on top of another init, as the systemd-sysv + cgmanager
combination attempts to do. But it is not trivial to do, as bugs and
implementation delays with that combo have shown, and it's quite likely
that there will be more problems in the future. It's not a particularly
good idea to use the less-tested and less-reliable systemd-shim instead
of the more reliable systemd. Thus the overall result is that yes, it
does make sense to switch machines to systemd when you add certain
functionality, even if that functionality does not appear to be directly
tied to the init system at first glance.
Also note that the systemd concepts logind makes use of are also
exported in its own API. The "scopes" and "slices" that logind uses
are exposed on its bus objects, and they are used by tools like
"loginctl" to do their work.
The "scopes" and "slices" concept does not exist elsewhere, and
there's nothing comparable around, so even if we wanted we couldn't
make logind work on anything else.
Then why in the first hand are the "scopes" and "slices" concepts within
systemd *tightly* coupled when it is functionality that makes sense to be
utilitizes in a component that provides a different functionality.

I wonder what functionality systemd provides right now in one more or less
tightly coupled package:

- early boot process
- managing kernel drivers and device files (via coupled udev)
- resource control for process groups
- logging
- core dumping
- network while I think a distro-unified way to approaching network that
replaces the current distro specific ways like ifupdown and so on, why does it
have to be coupled with systemd?
- cron, although that at least in Debian is separate as systemd-cron

Thats rather much.

Really rather much.

Way more than traditonal sysvinit covered.

What of this actually *needs* to be coupled with systemd? What of this needs
to be coupled tightly to Linux kernel?

systemd is driving a road where its all of this functionality by default is
only available for Linux and where upstream said they just won´t accept
patches – is that still true? – for portability. systemd provides more and
more functionality that desktops like to use, that other tools like to use.

When Microsoft back then did something like this it was called "Embrace,
Extend and Extinguish"¹…

a) Embrace: systemd provides functionality that is mostly compatible or
similar with what sysvinit and other components provided

b) Extend: systemd extends on that functionality and makes it more and more
difficult for desktops and apps to ignore that kind of functionality offers

c) Extinguish: The scope of systemd becomes so broad, the functionality it
offers in a – admittedly – convenient package to often needed and used, that
other ways of providing the functionality are extinguished.

Really… it matches quite closely.

I don´t think this was your plan. But… when looking at the currently visible
outcome this is quite exactly what is happening here.

So if you can follow this just a tiny bit: Do you start to understand why
systemd triggers the uproar, polarity and split so obvious that one needs to
have hands before both eyes for not seeing it?

So as I see it: there are *real* concerns. And if systemd is meant to be a
tool for users and admins, I *highly* and *strongly* recommend that you as
systemd closely look at these concerns. Unless you are willing to trigger the
polarity, the split and the uproar that it creates.

In KDE more and more voices come up that developers need to talk to their
users. Sure… its a do-ocracy. But still… if you want to become really broadly
accepted and successful with something you offer… its important to listen for
feedback. And in my oppinion you are in a good opportunity here, cause I think
there is no lack on feedback on systemd.

[1] https://de.wikipedia.org/wiki/Embrace,_Extend_and_Extinguish

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Martin Steigerwald
2014-10-21 10:01:44 UTC
Permalink
Post by Martin Steigerwald
When Microsoft back then did something like this it was called "Embrace,
Extend and Extinguish"¹…
Oh come on. You are just being a dick now.
For now just this:

Thats a personal accusation.

I didn´t attack you personally.

Please refrain from attacking me personally. Thats not the way of discussing I
am willing to lower my communication into.

I shared my thoughts and observations… thats all.

To me what I perceive has similarities regarding the outcome. I didn´t say
that it was your intention to create this.
I don´t think this was your plan. But… when looking at the currently visible
outcome this is quite exactly what is happening here.
So I didn´t say anything about your intention. And how could I? I don´t know
them.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Colin Guthrie
2014-10-21 21:14:48 UTC
Permalink
Post by Martin Steigerwald
Post by Lennart Poettering
Post by Uoti Urpala
Post by Rob Owens
My question really isn't "why are the Debian dependencies the way they
are". I understand that. I was trying to highlight the strange
situation of a desktop application requiring a particular init system.
I *think* this is a result of the init portion of systemd being bundled
together with the logind portion of systemd. To me (unfamiliar with
the systemd code) those two functions seem distinct enough to merit
being separate. Debian can't easily separate what the systemd devs
have developed as a single binary, so we end up with these strange
dependency chains.>
"Single binary" is false of course. Logind is developed as a separate
program, which is why systemd-shim is possible at all.
AFAIK the actual relevant dependencies go as follows: First, there's a
good reason why logind requires cgroup functionality. And there's a good
reason why cgroup functionality is best implemented together with init
(see
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
for more info). So it's not quite directly "logind has to depend on
systemd as init", but "logind has to depend on the system having cgroup
support, and there's no equally good cgroup support available for inits
other than systemd". It is possible to provide the relevant cgroup
interfaces in or on top of another init, as the systemd-sysv + cgmanager
combination attempts to do. But it is not trivial to do, as bugs and
implementation delays with that combo have shown, and it's quite likely
that there will be more problems in the future. It's not a particularly
good idea to use the less-tested and less-reliable systemd-shim instead
of the more reliable systemd. Thus the overall result is that yes, it
does make sense to switch machines to systemd when you add certain
functionality, even if that functionality does not appear to be directly
tied to the init system at first glance.
Also note that the systemd concepts logind makes use of are also
exported in its own API. The "scopes" and "slices" that logind uses
are exposed on its bus objects, and they are used by tools like
"loginctl" to do their work.
The "scopes" and "slices" concept does not exist elsewhere, and
there's nothing comparable around, so even if we wanted we couldn't
make logind work on anything else.
Then why in the first hand are the "scopes" and "slices" concepts within
systemd *tightly* coupled when it is functionality that makes sense to be
utilitizes in a component that provides a different functionality.
I wonder what functionality systemd provides right now in one more or less
- early boot process
PID 1
Post by Martin Steigerwald
- managing kernel drivers and device files (via coupled udev)
Not PID 1
Post by Martin Steigerwald
- resource control for process groups
PID 1.
Post by Martin Steigerwald
- logging
Not PID 1
Post by Martin Steigerwald
- core dumping
Not PID 1
Post by Martin Steigerwald
- network while I think a distro-unified way to approaching network that
replaces the current distro specific ways like ifupdown and so on, why does it
have to be coupled with systemd?
Not PID 1
Post by Martin Steigerwald
- cron, although that at least in Debian is separate as systemd-cron
Partly PID 1
Post by Martin Steigerwald
Thats rather much.
Really rather much.
Way more than traditonal sysvinit covered.
This is because traditional sysvinit covered PID 1 and performing it's
job (if you consider e.g. killall5 and friends).

You seem to be conflating systemd as PID 1 and systemd as a project.
These are two completely different things.

There are many related things here and a lot of the sub components
obviously use a lot of the same functionality and utility functions.
This is achieved via a shared library with a private API.

The only reason that all these separate parts are developed as part of
the systemd project is that it's *easier*. It's just the easiest way to
develop.

An alternative would be to make the utility functions API stable and
export the shared library publicly and give API guarantees, but that
puts a lot of pressure and it's a difficult thing to provide and it has
long term maintenance overhead. This is something that *costs*. It costs
in time/man hours and therefore it carries real overheads. Doing this
for the convenience of splitting things out is simply not worth it -
especially so as the main people working on these things are the same
people.

It also increases the test matrix. If logind v300 has to work with
libsystemd v300 and all future versions then the testing side of things
increases in complexity *massively*. Again this causes problems that
translate to time and effort of developers that could better be
allocated to building a better overall set of building blocks.


The other option would be to just split out the git repos but keep the
API a private one - with releases still in lockstep. This is ultimately
*no* different to keeping it all in one repo but gives an outward
impression of separate components. Doing this would be purely political
and would provide no technical benefit. It would also cost. It would
cost because developers would have to post patches to separate patches
to the mailing list for review. This makes both git send-email and git
am harder to manage and is just pure avoidable overhead. It also pushes
a lot of additional effort to downstreams where all the separate
components still have to be updated at the same time.

So overall, keeping things developed as one project is a technical
decision that has real benefits both for the developers doing the work
and the downstreams consuming it. Changing the approach would be 100%
political and, quite frankly, the systemd developers have very little
time for such games. They just want to get on and build better systems.
Post by Martin Steigerwald
What of this actually *needs* to be coupled with systemd? What of this needs
to be coupled tightly to Linux kernel?
If people want to provide implementations of such components outside of
systemd they would be more than welcome to do so.

As systemd provides a lot of the functionality and shared API functions
that are convenient to use (i.e. the base building blocks) and as people
who are working on the systemd project are doing the actual work, and as
these are seen as core building blocks of a modern OS, then it makes
sense to do this under the systemd umbrella.

There is no conspiracy here. It's just convenient. If other people want
to do this work, great.
Post by Martin Steigerwald
systemd is driving a road where its all of this functionality by default is
only available for Linux and where upstream said they just won´t accept
patches – is that still true? – for portability.
systemd developer hs have stated this clearly several times over, but to
say it again, it's not that systemd *won't* accept patches for
portability, it's just that there will not be a codebase littered with
#ifdefs and optional codepaths that are not well tested by the core devs.

systemd makes use of APIs that are currently *only* available on Linux.
If other kernels implement the same APIs, then systemd will work with
them just fine. If they implement equivilent functionality under
different APIs, then it's unlikely the systemd developers would support
this upstream directly as this would result in these #ifdefs and
untestable paths (by the core developers) that are very unattractive for
the upstream project.

But you know what? This doesn't matter! Those developers who are
interested in those other kernels will just maintain their own fork of
systemd (and by form I mean a true fork - one which git facilitates well
where upstream changes can be merged periodically) where the linux calls
are split out into $whatever calls.

This separate project can be tested by those developers and they can act
as the first port of call for bugs in their version but collaborate with
the original systemd for issues that are present in their upstream. In
many cases the developers of this fork would have upstream commit access
to. Such a world is perfectly feasible and it allows systemd to keep a
clean codebase and the downstream too. This is one of the cases where
committing everything upstream is not beneficial to either systemd or
the fork. Both are more individually readable and maintainable by their
relative maintainers. Everyone wins.


Having everything "committed upstream" is not necessarily the holy
grail. There are good, solid technical arguments not to work that way
and yet still get on and work well.

Forking and doing stupid things like renaming functions for the sake of
it, or changing commenting or code style is obviously something that any
well intentioned forker would not do. Not everyone will agree with
everything in this sphere but everyone can adapt and get on. That's just
part of working on FOSS projects.
Post by Martin Steigerwald
systemd provides more and
more functionality that desktops like to use, that other tools like to use.
When Microsoft back then did something like this it was called "Embrace,
Extend and Extinguish"¹…
a) Embrace: systemd provides functionality that is mostly compatible or
similar with what sysvinit and other components provided
b) Extend: systemd extends on that functionality and makes it more and more
difficult for desktops and apps to ignore that kind of functionality offers
c) Extinguish: The scope of systemd becomes so broad, the functionality it
offers in a – admittedly – convenient package to often needed and used, that
other ways of providing the functionality are extinguished.
Really… it matches quite closely.
Oh come on! This is just an attack and FUD. You make repeated claims of
coming in good faith etc. and seem to dismiss any technical defence
being made with vague references and then you bring out a aggressive and
argumentative statement like the above.

Again, you're totally confusing systemd as a project and systemd as a
PID 1. You need to accept and understand that distinction before anyone
here will take you even remotely seriously.
Post by Martin Steigerwald
I don´t think this was your plan. But… when looking at the currently visible
outcome this is quite exactly what is happening here.
No. Looking at the visible outcome of this to me is that huge progress
is being made in documented APIs that solve real world projects backed
up by solid, supported and maintained implementations. To me this is a
great thing. You are reading into it what you want based on your
preconceptions and then building up a case based on that. This is really
a case of apophenia, but people just don't see that because they are so
blinkered by their prejudices.
Post by Martin Steigerwald
So if you can follow this just a tiny bit: Do you start to understand why
systemd triggers the uproar, polarity and split so obvious that one needs to
have hands before both eyes for not seeing it?
What do you expect? Ultimately, haters gonna hate. There are a group of
people who are predisposed to hating change. systemd replaces a lot of
core functionality. If that was rolled out *without* causing a group of
people to complain I would have been surprised.

Of course this criticism is listened to and often actions are taken
because of it, but what do you expect the outcome to be? Do you expect
all the repos to be split up? Stable APIs exported and supported? What
outcome do you actually *want* here? You seem to be doing lots of
complaining, but very little in the actual suggesting what could be done
different that has not already been addressed technically. You may
disagree about that end decision but that's just the way it is
sometimes? The people doing the work ultimately get to make the decisions.
Post by Martin Steigerwald
So as I see it: there are *real* concerns. And if systemd is meant to be a
tool for users and admins, I *highly* and *strongly* recommend that you as
systemd closely look at these concerns. Unless you are willing to trigger the
polarity, the split and the uproar that it creates.
In KDE more and more voices come up that developers need to talk to their
users. Sure… its a do-ocracy. But still… if you want to become really broadly
accepted and successful with something you offer… its important to listen for
feedback. And in my oppinion you are in a good opportunity here, cause I think
there is no lack on feedback on systemd.
You also seem to think that this feedback is somehow special or new.
Such feedback has been coming in for years and much of it has already
been listened to and acted on or decided as something not to be
supported or irrelevant. All of your posts so far seem to be worded like
you think this process has not happened at all. There is a wealth of
archive information, blog posts, conference talks and such like out
there to document this process. You need to be proactive to consume it
all, and you cannot expect to be spoon fed it all.


Honestly, I've been following this project since it's very inception and
I from what I see your opinion of it has been formed around notions that
are pretty much entirely fictional or based on second hand
information/FUD. The accusations you make are often wildly technically
inaccurate and you seem to offer no credit to the devlopers with regards
to their collaboration.

I've been doing the rounds on mailing lists, distros and conferences for
years. systemd is one of the most open projects with regards to doing
the conference circuit and talking to people - all over the world and
with interested parties both commercial and community run. There is no
end of opportunity to speak with the systemd developers - often in
person - and discuss the issues. The regurgitation of the same old stuff
on mailing lists today no longer warrants further discussion for the
most part. Doing so just soaks up developer time (and it takes a *lot*
of time to reply to these things - this email alone has likely taken me
20mins+ - I'd much rather developers give such "feedback" a brief read
over for any salient points and then ignore it and get on with designing
and writing code and making a difference.

Sorry, but I just do not see things they way you do and your repeated
regurgitation of factually incorrect statements is doing nothing but
making you appear to be someone to not waste time replying to further.
This is not ignorance or not listening to feedback or anything of the
like... it's ultimately, I'm sorry to say, just not feeding the
trolls[1] - or, if you prefer a more sanguine version, not replying is
just agreeing to disagree.

Col

1. for the avoidance of doubt, I don't mean anything nasty by this - I
just mean replying just continues a pseudo "discussion" with someone who
is not in any way listening to your arguments or accepting your
technical opinion - it's just a never ending discussion that leads
nowhere - it has to be starved to die off and cannot be fed.
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Martin Steigerwald
2014-10-22 00:13:17 UTC
Permalink
Colin,

I had the feeling that is a bad idea to read your mail before I go to sleep.
But I was interested in what you have to say since you made quite an effort in
your reply to me. And now I can´t sleep since my head if full of thoughts and
I am full of emotions as well.

With that I perceive starts an answer on a technical matter ends with what I
received as a dire personal attack: I.e. calling me names.

I received this twice on this mailing list. Once from Lennart ("being a dick
now") and now from you calling me a troll.

I will make an effort to reply to your mail and then most likely unsubscribe,
cause for me I feel like being in an hostile environment.
Post by Colin Guthrie
Post by Martin Steigerwald
Post by Lennart Poettering
Post by Uoti Urpala
Post by Rob Owens
My question really isn't "why are the Debian dependencies the way they
are". I understand that. I was trying to highlight the strange
situation of a desktop application requiring a particular init system.
I *think* this is a result of the init portion of systemd being bundled
together with the logind portion of systemd. To me (unfamiliar with
the systemd code) those two functions seem distinct enough to merit
being separate. Debian can't easily separate what the systemd devs
have developed as a single binary, so we end up with these strange
dependency chains.>
"Single binary" is false of course. Logind is developed as a separate
program, which is why systemd-shim is possible at all.
AFAIK the actual relevant dependencies go as follows: First, there's a
good reason why logind requires cgroup functionality. And there's a good
reason why cgroup functionality is best implemented together with init
(see
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
for more info). So it's not quite directly "logind has to depend on
systemd as init", but "logind has to depend on the system having cgroup
support, and there's no equally good cgroup support available for inits
other than systemd". It is possible to provide the relevant cgroup
interfaces in or on top of another init, as the systemd-sysv + cgmanager
combination attempts to do. But it is not trivial to do, as bugs and
implementation delays with that combo have shown, and it's quite likely
that there will be more problems in the future. It's not a particularly
good idea to use the less-tested and less-reliable systemd-shim instead
of the more reliable systemd. Thus the overall result is that yes, it
does make sense to switch machines to systemd when you add certain
functionality, even if that functionality does not appear to be directly
tied to the init system at first glance.
Also note that the systemd concepts logind makes use of are also
exported in its own API. The "scopes" and "slices" that logind uses
are exposed on its bus objects, and they are used by tools like
"loginctl" to do their work.
The "scopes" and "slices" concept does not exist elsewhere, and
there's nothing comparable around, so even if we wanted we couldn't
make logind work on anything else.
Then why in the first hand are the "scopes" and "slices" concepts within
systemd *tightly* coupled when it is functionality that makes sense to be
utilitizes in a component that provides a different functionality.
I wonder what functionality systemd provides right now in one more or less
- early boot process
PID 1
Post by Martin Steigerwald
- managing kernel drivers and device files (via coupled udev)
Not PID 1
Post by Martin Steigerwald
- resource control for process groups
PID 1.
Post by Martin Steigerwald
- logging
Not PID 1
Post by Martin Steigerwald
- core dumping
Not PID 1
Post by Martin Steigerwald
- network while I think a distro-unified way to approaching network that
replaces the current distro specific ways like ifupdown and so on, why
does it have to be coupled with systemd?
Not PID 1
Post by Martin Steigerwald
- cron, although that at least in Debian is separate as systemd-cron
Partly PID 1
Post by Martin Steigerwald
Thats rather much.
Really rather much.
Way more than traditonal sysvinit covered.
This is because traditional sysvinit covered PID 1 and performing it's
job (if you consider e.g. killall5 and friends).
You seem to be conflating systemd as PID 1 and systemd as a project.
These are two completely different things.
No. I am concerned about both. The functionality that is stuffed inside PID 1
which is more than 1,3 MiB and also sports user session functionality. And
what is coupled inside on project, more or less tight.
Post by Colin Guthrie
There are many related things here and a lot of the sub components
obviously use a lot of the same functionality and utility functions.
This is achieved via a shared library with a private API.
The only reason that all these separate parts are developed as part of
the systemd project is that it's *easier*. It's just the easiest way to
develop.
An alternative would be to make the utility functions API stable and
export the shared library publicly and give API guarantees, but that
puts a lot of pressure and it's a difficult thing to provide and it has
long term maintenance overhead. This is something that *costs*. It costs
in time/man hours and therefore it carries real overheads. Doing this
for the convenience of splitting things out is simply not worth it -
especially so as the main people working on these things are the same
people.
I don´t think it would be just for the convenience of splitting things. It
would also be to address the concerns I summarized and that have been made
elsewhere. You may heard these concerns often, you may not agree to them. Yet,
if you say later that some of these concerns were made 5 years ago already… If
those concerns are still there… either… its due to Debian adopting systemd
now, but its not only Debian users and devels here giving that concerns… or it
is due to that the once voicing the concerns have the impression that systemd
upstream did not address them.
Post by Colin Guthrie
It also increases the test matrix. If logind v300 has to work with
libsystemd v300 and all future versions then the testing side of things
increases in complexity *massively*. Again this causes problems that
translate to time and effort of developers that could better be
allocated to building a better overall set of building blocks.
I do think that the easiest way to do something is not necessarily the best.

It took KDE developers several years to split out KDE 4 into modules. Yet they
did it. And from what I read on their mailinglists so far, usually their
discussions are in a much more friendly tone.

Now systemd is not KDE, granted… but I think thats not the only example where
developers took quite some extra effort in order to split things out.
Post by Colin Guthrie
So overall, keeping things developed as one project is a technical
decision that has real benefits both for the developers doing the work
and the downstreams consuming it. Changing the approach would be 100%
political and, quite frankly, the systemd developers have very little
time for such games. They just want to get on and build better systems.
It would be 100% political if the concerns where 100% political. But in my
oppinion they are not.
Post by Colin Guthrie
Post by Martin Steigerwald
What of this actually *needs* to be coupled with systemd? What of this
needs to be coupled tightly to Linux kernel?
If people want to provide implementations of such components outside of
systemd they would be more than welcome to do so.
As systemd provides a lot of the functionality and shared API functions
that are convenient to use (i.e. the base building blocks) and as people
who are working on the systemd project are doing the actual work, and as
these are seen as core building blocks of a modern OS, then it makes
sense to do this under the systemd umbrella.
There is no conspiracy here. It's just convenient. If other people want
to do this work, great.
Again, again and again:

I never assumed bad intentions.

Well… as it doesn´t seem to sink in:

I never assumed a conspiracy.

I never assumed bad intentions.

Do you need it again?

Ok, here is:

I never assumed a conspiracy.

I never assumed bad intentions.


I see you received what I wrote as such and I am puzzled, cause I carefully
took care to make that perfectly clear in all what I wrote so far.

It seems I still didn´t bring this point accross.

This may be due to history and Lennart and others here, systemd upstream
having been called names and worse.

Yet *I* didn´t.
Post by Colin Guthrie
Post by Martin Steigerwald
systemd is driving a road where its all of this functionality by default is
only available for Linux and where upstream said they just won´t accept
patches – is that still true? – for portability.
systemd developer hs have stated this clearly several times over, but to
say it again, it's not that systemd *won't* accept patches for
portability, it's just that there will not be a codebase littered with
#ifdefs and optional codepaths that are not well tested by the core devs.
systemd makes use of APIs that are currently *only* available on Linux.
If other kernels implement the same APIs, then systemd will work with
them just fine. If they implement equivilent functionality under
different APIs, then it's unlikely the systemd developers would support
this upstream directly as this would result in these #ifdefs and
untestable paths (by the core developers) that are very unattractive for
the upstream project.
But you know what? This doesn't matter! Those developers who are
interested in those other kernels will just maintain their own fork of
systemd (and by form I mean a true fork - one which git facilitates well
where upstream changes can be merged periodically) where the linux calls
are split out into $whatever calls.
This separate project can be tested by those developers and they can act
as the first port of call for bugs in their version but collaborate with
the original systemd for issues that are present in their upstream. In
many cases the developers of this fork would have upstream commit access
to. Such a world is perfectly feasible and it allows systemd to keep a
clean codebase and the downstream too. This is one of the cases where
committing everything upstream is not beneficial to either systemd or
the fork. Both are more individually readable and maintainable by their
relative maintainers. Everyone wins.
Ok, how would these forks address compatibility issues with upstream systemd?
Upstream systemd has a very high development speed. Which you may view as
good. And heck, yes, it has its advantages I agree. But to me it also seems
that this speed partly come due to what you wrote above as the easy way of
developing things. And that easy way to develop things, I argue now, makes it
more difficult for people wanting to port to different platforms, people only
wanting a subset of systemd and people who want to adapt systemd.

It is your free choice to handle things like this.

I just again and again also see the pattern of "This is not our business"
where it was systemd creating friction for others. Heck, I even had this in
some of my own bug reports regarding systemd in Debian where I was about to
help systemd integration with Debian by pointing out issues.

I saw this here, I saw this with Kay Sievers and Linus reaction to him, I saw
this on this mailing list with patches people send in.

I could put examples to it, but right now as I am feeling to be in an hostile
environment and don´t want to stay up much longer this night, I won´t. For
now.
Post by Colin Guthrie
Post by Martin Steigerwald
systemd provides more and
more functionality that desktops like to use, that other tools like to use.
When Microsoft back then did something like this it was called "Embrace,
Extend and Extinguish"¹…
a) Embrace: systemd provides functionality that is mostly compatible or
similar with what sysvinit and other components provided
b) Extend: systemd extends on that functionality and makes it more and more
difficult for desktops and apps to ignore that kind of functionality offers
c) Extinguish: The scope of systemd becomes so broad, the functionality it
offers in a – admittedly – convenient package to often needed and used,
that other ways of providing the functionality are extinguished.
Really… it matches quite closely.
Oh come on! This is just an attack and FUD. You make repeated claims of
coming in good faith etc. and seem to dismiss any technical defence
being made with vague references and then you bring out a aggressive and
argumentative statement like the above.
That is the impression you get.

I think I replied to technical arguments as well.

But I also see more social and how do I develop things, how do I treat
portability people, how do I treat long year sysadmins, how do I treat bug
reports and so on… I see much of the issue in this.

Sure, doing it like this initially makes it easier for you.

But it also creates the outcome you perceive.

It triggers and summons the polarity it triggers and summons.

It is your choice.
Post by Colin Guthrie
Again, you're totally confusing systemd as a project and systemd as a
PID 1. You need to accept and understand that distinction before anyone
here will take you even remotely seriously.
Okay, again my obversation:

1) Embrace: Systemd implements functionality that is available elsewhere. As
PID 1 – service handling – and as project – DNS, DHCP, logging, handling core
dumps… and others.

2) Extend: Systemd extends on this functionality. Which even makes sense.
systemctl status is wonderful. But it still does. Again I see this for PID 1
and for project.

3) Extinguish: More and more on the first sight unrelated projects, apps and so
on depend on functionality that comes to distros as one entity: Systemd. More
and more it becomes difficult to run a fully fledged LInux desktop with an
alternative init system. More and more alternative init system developers need
to play catchup game by implementing stuff systemd implements, but which was
never fed into some standardization or stable API.

Again, again, and again: I see no bad intention. I see no conspiracy.

This is just what I *observe* and partly how I see similarities to Embrace,
Extend and Extinguish.

Heck, I am not even sure Microsoft had this strategy from the beginning.

I am pretty sure you didn´t have this strategy. I am pretty sure Lennart did
not have it. I am even pretty sure you or Lennart has it now.

But I see outcomes of the way how you currently handle things. Not *intended*
outcomes, but still outcomes.

And I stand by it by pointing this out.

If you can´t handle this… fine… don´t. But thats how I see it.
Post by Colin Guthrie
Post by Martin Steigerwald
I don´t think this was your plan. But… when looking at the currently
visible outcome this is quite exactly what is happening here.
No. Looking at the visible outcome of this to me is that huge progress
is being made in documented APIs that solve real world projects backed
up by solid, supported and maintained implementations. To me this is a
great thing.
I am fine with this.
Post by Colin Guthrie
You are reading into it what you want based on your
preconceptions and then building up a case based on that. This is really
a case of apophenia, but people just don't see that because they are so
blinkered by their prejudices.
I am not fine with it. You don´t know what I do. You just interpret it.

As do I.

Its the only access I have to this world. I interpret what I see.

No what does make your interpretation more valid, than mine? What?
Post by Colin Guthrie
Post by Martin Steigerwald
So if you can follow this just a tiny bit: Do you start to understand why
systemd triggers the uproar, polarity and split so obvious that one needs
to have hands before both eyes for not seeing it?
What do you expect? Ultimately, haters gonna hate. There are a group of
people who are predisposed to hating change. systemd replaces a lot of
core functionality. If that was rolled out *without* causing a group of
people to complain I would have been surprised.
I seen feedback of haters. Yes.

But not almost all of the feedback I saw in debian-user, on debian-devel is
that of haters or trolls.

Calling someone a hater or a troll is still calling names to me.

Its accusing and attacking persons to me.

What I tried to achieve is to describe and interpret what I see regarding the
state of systemd as I understand it now, and granted my understanding may not
be complete, sure, and also describe and interpret behavior I have seen. And
also summarize some of this from the feedback I read elsewhere.

What I didn´t try to achieve was attacking persons.

Yet, I interpret your reaction to me as if I attacked you.

So I am obviously not producing the outcome I wanted to produce. And thats one
reason why I think I will stop doing what I am doing after this mail and
unsubscribe from this list for a while.

Actually I think I made my point. I tried to channel some of the dire concerns
and uproar and polarity and split tendencies upstream.

I see this happening to my beloved distribution Debian and I am not happy
about it. The systemd debates and polarity within Debian I consider as being
harmful.

And it was my intention to address some of this upstream in order to discuss
what can be done to first *understand* why it triggers this polarity and what
can be done to address this.

Its causing harm.

Very much so. Right now. As we speak. And I am concerned about it.

I am confident that Debian as a project will manage. But I see the cost it has
to the project. And I am very deeply concerned about it.
Post by Colin Guthrie
Of course this criticism is listened to and often actions are taken
because of it, but what do you expect the outcome to be? Do you expect
all the repos to be split up? Stable APIs exported and supported? What
outcome do you actually *want* here? You seem to be doing lots of
complaining, but very little in the actual suggesting what could be done
different that has not already been addressed technically. You may
disagree about that end decision but that's just the way it is
sometimes? The people doing the work ultimately get to make the decisions.
Yeah, thats the do-ocracy aspect of things. Still if what I do again and again
and again triggers much of polarity and resistance, I´d ask myself whats going
on there. Which brings me back to the point why I started this thread here.
Post by Colin Guthrie
Post by Martin Steigerwald
So as I see it: there are *real* concerns. And if systemd is meant to be a
tool for users and admins, I *highly* and *strongly* recommend that you as
systemd closely look at these concerns. Unless you are willing to trigger
the polarity, the split and the uproar that it creates.
In KDE more and more voices come up that developers need to talk to their
users. Sure… its a do-ocracy. But still… if you want to become really
broadly accepted and successful with something you offer… its important
to listen for feedback. And in my oppinion you are in a good opportunity
here, cause I think there is no lack on feedback on systemd.
You also seem to think that this feedback is somehow special or new.
Such feedback has been coming in for years and much of it has already
been listened to and acted on or decided as something not to be
supported or irrelevant. All of your posts so far seem to be worded like
you think this process has not happened at all. There is a wealth of
archive information, blog posts, conference talks and such like out
there to document this process. You need to be proactive to consume it
all, and you cannot expect to be spoon fed it all.
Well, okay. I don´t follow this list for that long already. I read here and
there about systemd. Blog posts from Lennart but also critical feedback. Yet…
as Debian was not affected, it was kinda remote to me. So… I think its
understandable I don´t know five years of history.

I voice concerns I see now.

And as these concerns are now this tells to me that those who have the
concerns either are not up to date that they have been address or otherwise
don´t have the impression that it they got addresses. In some time concerns
may have been addressed but information about it didn´t get throw. But in
other cases it may just mean you deemed the concerns as being "irrelevant".

And this, in my eyes, it not quite a respectful way to deal with concerns.
Post by Colin Guthrie
Honestly, I've been following this project since it's very inception and
I from what I see your opinion of it has been formed around notions that
are pretty much entirely fictional or based on second hand
information/FUD. The accusations you make are often wildly technically
inaccurate and you seem to offer no credit to the devlopers with regards
to their collaboration.
This is your impression. I, as should be obvious right now, see this
differently.

I see openness and technical discussion here, but I also see "not our
business, go away" kind of reactions, in bug reports as someone pointed out in
this thread already, but also here on this list.

Actually what you write above follows a similar pattern: Its the easiest way
to develop things. Okay, it may is. For you. But did you consider the cost it
creates for others?
Post by Colin Guthrie
I've been doing the rounds on mailing lists, distros and conferences for
years. systemd is one of the most open projects with regards to doing
the conference circuit and talking to people - all over the world and
with interested parties both commercial and community run. There is no
end of opportunity to speak with the systemd developers - often in
person - and discuss the issues. The regurgitation of the same old stuff
on mailing lists today no longer warrants further discussion for the
most part. Doing so just soaks up developer time (and it takes a *lot*
of time to reply to these things - this email alone has likely taken me
20mins+ - I'd much rather developers give such "feedback" a brief read
over for any salient points and then ignore it and get on with designing
and writing code and making a difference.
It is your free choice to do with your time what you want to do. I am in no
way forcing you to respond to my mail.

It seems to me you felt some urge to respond, as I felt urge to respond to
you… thats okay. But thats something you feel or think, or I feel or think. So
I give all responsibility on how you spend your time back to you.

I am not responsible for it.

As you are not responsible for that I read your mail so late and then not
being able to sleep and just put it away till tomorrow.
Post by Colin Guthrie
Sorry, but I just do not see things they way you do and your repeated
regurgitation of factually incorrect statements is doing nothing but
making you appear to be someone to not waste time replying to further.
This is not ignorance or not listening to feedback or anything of the
like... it's ultimately, I'm sorry to say, just not feeding the
trolls[1] - or, if you prefer a more sanguine version, not replying is
just agreeing to disagree.
Col
1. for the avoidance of doubt, I don't mean anything nasty by this - I
just mean replying just continues a pseudo "discussion" with someone who
is not in any way listening to your arguments or accepting your
technical opinion - it's just a never ending discussion that leads
nowhere - it has to be starved to die off and cannot be fed.
That I received as a personal accusation.

I work with Linux for more than 10 years. I do system admin work, I give Linux
trainings and and and…

Even if you try to do it politely. For me I received it as "You are a troll
anyway."


Now I agree to disagree.

From the thread so far I understand way better why people are concerned, why
systemd as a project of developers, as a umbrella projects of building blocks
as you call it and as PID 1 triggers the amount of polarity it does:

Or as Aaron Seigo carefully tried to put it:

Aaron Seigo, four paths, 7th of October 2014:
http://aseigo.blogspot.com/2014/10/four-paths.html

How the way Lennart and other developers here treat people as I perceive here
and there also in how I feel being treated here has a contribution to the
reaction and outcome they get. That doesn´t excuse name calling or worse. But
it partly makes it understandable or explainable.

And as to the

"who is not in any way listening to your arguments or accepting your technical
opinion"

I can give back. I even wrote to Lennart once I have the impression he doesn´t
even relate to what I just wrote.

So I made my point. I made clear what my intentions were.

And I think there is nothing more to say for now.

I wish you success.

And thanks for putting the effort in the response you put into it.

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Uoti Urpala
2014-10-22 02:29:23 UTC
Permalink
Post by Martin Steigerwald
With that I perceive starts an answer on a technical matter ends with what I
received as a dire personal attack: I.e. calling me names.
I think it was a mostly justified criticism of your posting style here.
Post by Martin Steigerwald
I will make an effort to reply to your mail and then most likely unsubscribe,
cause for me I feel like being in an hostile environment.
If you post such strongly worded criticism of people's work (which I
don't consider really justified criticism either) then IMO you should
tolerate that level negative response without starting to complain about
"hostile environment".
Post by Martin Steigerwald
Upstream systemd has a very high development speed. Which you may view as
good. And heck, yes, it has its advantages I agree. But to me it also seems
that this speed partly come due to what you wrote above as the easy way of
developing things. And that easy way to develop things, I argue now, makes it
more difficult for people wanting to port to different platforms, people only
wanting a subset of systemd and people who want to adapt systemd.
Those latter are much smaller groups than the number of people who just
need a well-working init system for their Linux machine. It wouldn't
make sense to sacrifice the functionality of init just to make porting
easier.
Post by Martin Steigerwald
Post by Colin Guthrie
Post by Martin Steigerwald
systemd provides more and
more functionality that desktops like to use, that other tools like to use.
When Microsoft back then did something like this it was called "Embrace,
Extend and Extinguish"¹…
Really… it matches quite closely.
Oh come on! This is just an attack and FUD. You make repeated claims of
coming in good faith etc. and seem to dismiss any technical defence
being made with vague references and then you bring out a aggressive and
argumentative statement like the above.
That is the impression you get.
I think I replied to technical arguments as well.
The above does not match the definition of "Embrace, extend and
extinguish" (see for example the Wikipedia definition at
http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
). It's a lot more specific than just "a product manager to push
competing ones out of the market", and pretty much requires intentional
malice to apply. IMO it was quite accurate to call your claim
attack/FUD.
Post by Martin Steigerwald
What I tried to achieve is to describe and interpret what I see regarding the
state of systemd as I understand it now, and granted my understanding may not
be complete, sure, and also describe and interpret behavior I have seen. And
also summarize some of this from the feedback I read elsewhere.
What I didn´t try to achieve was attacking persons.
Yet, I interpret your reaction to me as if I attacked you.
So I am obviously not producing the outcome I wanted to produce. And thats one
reason why I think I will stop doing what I am doing after this mail and
unsubscribe from this list for a while.
Actually I think I made my point. I tried to channel some of the dire concerns
and uproar and polarity and split tendencies upstream.
I see this happening to my beloved distribution Debian and I am not happy
about it. The systemd debates and polarity within Debian I consider as being
harmful.
And it was my intention to address some of this upstream in order to discuss
what can be done to first *understand* why it triggers this polarity and what
can be done to address this.
Maybe your *intention* was to address reasons for controversy in a
constructive manner, but I do not think you succeeded very well. Several
of your points had already been made by others before - many, many
times. You bring up little that systemd authors would not have already
addressed before. Things like your "Embrace, extend and extinguish"
comparison above are attacks with little constructive content. And when
presented with technical justification to develop certain things in the
same project, or keep certain functionality in PID 1, you seem to
largely ignore it. Yes, it is a tradeoff, and you can always find some
negative side. But you won't achieve anything by ignoring the answers
and talking about the negative sides, if you can't make a better
argument why the tradeoff would be wrong overall.
Post by Martin Steigerwald
Post by Colin Guthrie
Of course this criticism is listened to and often actions are taken
because of it, but what do you expect the outcome to be? Do you expect
all the repos to be split up? Stable APIs exported and supported? What
outcome do you actually *want* here? You seem to be doing lots of
complaining, but very little in the actual suggesting what could be done
different that has not already been addressed technically. You may
disagree about that end decision but that's just the way it is
sometimes? The people doing the work ultimately get to make the decisions.
Yeah, thats the do-ocracy aspect of things. Still if what I do again and again
and again triggers much of polarity and resistance, I´d ask myself whats going
on there. Which brings me back to the point why I started this thread here.
What *do* you expect to achieve with this thread then? Do you believe
that you have convincing arguments why something should be done
technically differently? Or do you believe the controversy will go away
if the systemd project just has different publicity, even if things are
done exactly the same technically?

You again ignore the replies you've already got and repeat the
implication that systemd must be doing "something" wrong to get
resistance. Several people have already told you that a fairly high base
level of resistance is really something you should expect when doing
things like a substantial init change. But you just ignore that and
repeat the same thing.
d***@wipro.com
2014-10-22 00:45:25 UTC
Permalink
The system project seems to have made great strides to the point that now there are definite philosophical differences. The people on both sides have their own opinions of what the direction should be given how much progress has occurred.
I think this would a very good time for a fork of the project. The systemd developers have rightly pointed out that this is free ware and if there is disagreement as has happened in the past, fork the project.
The people who disagree with the current direction have a solid base to build on, fork the project take it in the direction you feel it should go.
It will be interesting to see how the two sides progress.

-----Original Message-----
From: systemd-devel [mailto:systemd-devel-***@lists.freedesktop.org] On Behalf Of Martin Steigerwald
Sent: Tuesday, October 21, 2014 7:13 PM
To: Colin Guthrie
Cc: systemd-***@lists.freedesktop.org
Subject: Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

Colin,

I had the feeling that is a bad idea to read your mail before I go to sleep.
But I was interested in what you have to say since you made quite an effort in your reply to me. And now I can´t sleep since my head if full of thoughts and I am full of emotions as well.

With that I perceive starts an answer on a technical matter ends with what I received as a dire personal attack: I.e. calling me names.

I received this twice on this mailing list. Once from Lennart ("being a dick
now") and now from you calling me a troll.

I will make an effort to reply to your mail and then most likely unsubscribe, cause for me I feel like being in an hostile environment.
Post by Colin Guthrie
Post by Martin Steigerwald
Post by Lennart Poettering
Post by Uoti Urpala
Post by Rob Owens
My question really isn't "why are the Debian dependencies the way
they are". I understand that. I was trying to highlight the
strange situation of a desktop application requiring a particular init system.
I *think* this is a result of the init portion of systemd being
bundled together with the logind portion of systemd. To me
(unfamiliar with the systemd code) those two functions seem
distinct enough to merit being separate. Debian can't easily
separate what the systemd devs have developed as a single binary,
so we end up with these strange dependency chains.>
"Single binary" is false of course. Logind is developed as a
separate program, which is why systemd-shim is possible at all.
AFAIK the actual relevant dependencies go as follows: First,
there's a good reason why logind requires cgroup functionality.
And there's a good reason why cgroup functionality is best
implemented together with init (see
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInter
face/ for more info). So it's not quite directly "logind has to
depend on systemd as init", but "logind has to depend on the
system having cgroup support, and there's no equally good cgroup
support available for inits other than systemd". It is possible to
provide the relevant cgroup interfaces in or on top of another
init, as the systemd-sysv + cgmanager combination attempts to do.
But it is not trivial to do, as bugs and implementation delays
with that combo have shown, and it's quite likely that there will
be more problems in the future. It's not a particularly good idea
to use the less-tested and less-reliable systemd-shim instead of
the more reliable systemd. Thus the overall result is that yes, it
does make sense to switch machines to systemd when you add certain
functionality, even if that functionality does not appear to be
directly tied to the init system at first glance.
Also note that the systemd concepts logind makes use of are also
exported in its own API. The "scopes" and "slices" that logind uses
are exposed on its bus objects, and they are used by tools like
"loginctl" to do their work.
The "scopes" and "slices" concept does not exist elsewhere, and
there's nothing comparable around, so even if we wanted we couldn't
make logind work on anything else.
Then why in the first hand are the "scopes" and "slices" concepts
within systemd *tightly* coupled when it is functionality that makes
sense to be utilitizes in a component that provides a different functionality.
I wonder what functionality systemd provides right now in one more
- early boot process
PID 1
Post by Martin Steigerwald
- managing kernel drivers and device files (via coupled udev)
Not PID 1
Post by Martin Steigerwald
- resource control for process groups
PID 1.
Post by Martin Steigerwald
- logging
Not PID 1
Post by Martin Steigerwald
- core dumping
Not PID 1
Post by Martin Steigerwald
- network while I think a distro-unified way to approaching network
that replaces the current distro specific ways like ifupdown and so
on, why does it have to be coupled with systemd?
Not PID 1
Post by Martin Steigerwald
- cron, although that at least in Debian is separate as systemd-cron
Partly PID 1
Post by Martin Steigerwald
Thats rather much.
Really rather much.
Way more than traditonal sysvinit covered.
This is because traditional sysvinit covered PID 1 and performing it's
job (if you consider e.g. killall5 and friends).
You seem to be conflating systemd as PID 1 and systemd as a project.
These are two completely different things.
No. I am concerned about both. The functionality that is stuffed inside PID 1 which is more than 1,3 MiB and also sports user session functionality. And what is coupled inside on project, more or less tight.
Post by Colin Guthrie
There are many related things here and a lot of the sub components
obviously use a lot of the same functionality and utility functions.
This is achieved via a shared library with a private API.
The only reason that all these separate parts are developed as part of
the systemd project is that it's *easier*. It's just the easiest way
to develop.
An alternative would be to make the utility functions API stable and
export the shared library publicly and give API guarantees, but that
puts a lot of pressure and it's a difficult thing to provide and it
has long term maintenance overhead. This is something that *costs*. It
costs in time/man hours and therefore it carries real overheads. Doing
this for the convenience of splitting things out is simply not worth
it - especially so as the main people working on these things are the
same people.
I don´t think it would be just for the convenience of splitting things. It would also be to address the concerns I summarized and that have been made elsewhere. You may heard these concerns often, you may not agree to them. Yet, if you say later that some of these concerns were made 5 years ago already… If those concerns are still there… either… its due to Debian adopting systemd now, but its not only Debian users and devels here giving that concerns… or it is due to that the once voicing the concerns have the impression that systemd upstream did not address them.
Post by Colin Guthrie
It also increases the test matrix. If logind v300 has to work with
libsystemd v300 and all future versions then the testing side of
things increases in complexity *massively*. Again this causes problems
that translate to time and effort of developers that could better be
allocated to building a better overall set of building blocks.
I do think that the easiest way to do something is not necessarily the best.

It took KDE developers several years to split out KDE 4 into modules. Yet they did it. And from what I read on their mailinglists so far, usually their discussions are in a much more friendly tone.

Now systemd is not KDE, granted… but I think thats not the only example where developers took quite some extra effort in order to split things out.
Post by Colin Guthrie
So overall, keeping things developed as one project is a technical
decision that has real benefits both for the developers doing the work
and the downstreams consuming it. Changing the approach would be 100%
political and, quite frankly, the systemd developers have very little
time for such games. They just want to get on and build better systems.
It would be 100% political if the concerns where 100% political. But in my oppinion they are not.
Post by Colin Guthrie
Post by Martin Steigerwald
What of this actually *needs* to be coupled with systemd? What of
this needs to be coupled tightly to Linux kernel?
If people want to provide implementations of such components outside
of systemd they would be more than welcome to do so.
As systemd provides a lot of the functionality and shared API
functions that are convenient to use (i.e. the base building blocks)
and as people who are working on the systemd project are doing the
actual work, and as these are seen as core building blocks of a modern
OS, then it makes sense to do this under the systemd umbrella.
There is no conspiracy here. It's just convenient. If other people
want to do this work, great.
Again, again and again:

I never assumed bad intentions.

Well… as it doesn´t seem to sink in:

I never assumed a conspiracy.

I never assumed bad intentions.

Do you need it again?

Ok, here is:

I never assumed a conspiracy.

I never assumed bad intentions.


I see you received what I wrote as such and I am puzzled, cause I carefully took care to make that perfectly clear in all what I wrote so far.

It seems I still didn´t bring this point accross.

This may be due to history and Lennart and others here, systemd upstream having been called names and worse.

Yet *I* didn´t.
Post by Colin Guthrie
Post by Martin Steigerwald
systemd is driving a road where its all of this functionality by
default is only available for Linux and where upstream said they
just won´t accept patches – is that still true? – for portability.
systemd developer hs have stated this clearly several times over, but
to say it again, it's not that systemd *won't* accept patches for
portability, it's just that there will not be a codebase littered with
#ifdefs and optional codepaths that are not well tested by the core devs.
systemd makes use of APIs that are currently *only* available on Linux.
If other kernels implement the same APIs, then systemd will work with
them just fine. If they implement equivilent functionality under
different APIs, then it's unlikely the systemd developers would
support this upstream directly as this would result in these #ifdefs
and untestable paths (by the core developers) that are very
unattractive for the upstream project.
But you know what? This doesn't matter! Those developers who are
interested in those other kernels will just maintain their own fork of
systemd (and by form I mean a true fork - one which git facilitates
well where upstream changes can be merged periodically) where the
linux calls are split out into $whatever calls.
This separate project can be tested by those developers and they can
act as the first port of call for bugs in their version but
collaborate with the original systemd for issues that are present in
their upstream. In many cases the developers of this fork would have
upstream commit access to. Such a world is perfectly feasible and it
allows systemd to keep a clean codebase and the downstream too. This
is one of the cases where committing everything upstream is not
beneficial to either systemd or the fork. Both are more individually
readable and maintainable by their relative maintainers. Everyone wins.
Ok, how would these forks address compatibility issues with upstream systemd?
Upstream systemd has a very high development speed. Which you may view as good. And heck, yes, it has its advantages I agree. But to me it also seems that this speed partly come due to what you wrote above as the easy way of developing things. And that easy way to develop things, I argue now, makes it more difficult for people wanting to port to different platforms, people only wanting a subset of systemd and people who want to adapt systemd.

It is your free choice to handle things like this.

I just again and again also see the pattern of "This is not our business"
where it was systemd creating friction for others. Heck, I even had this in some of my own bug reports regarding systemd in Debian where I was about to help systemd integration with Debian by pointing out issues.

I saw this here, I saw this with Kay Sievers and Linus reaction to him, I saw this on this mailing list with patches people send in.

I could put examples to it, but right now as I am feeling to be in an hostile environment and don´t want to stay up much longer this night, I won´t. For now.
Post by Colin Guthrie
Post by Martin Steigerwald
systemd provides more and
more functionality that desktops like to use, that other tools like to use.
When Microsoft back then did something like this it was called
"Embrace, Extend and Extinguish"¹…
a) Embrace: systemd provides functionality that is mostly compatible
or similar with what sysvinit and other components provided
b) Extend: systemd extends on that functionality and makes it more
and more difficult for desktops and apps to ignore that kind of
functionality offers
c) Extinguish: The scope of systemd becomes so broad, the
functionality it offers in a – admittedly – convenient package to
often needed and used, that other ways of providing the functionality are extinguished.
Really… it matches quite closely.
Oh come on! This is just an attack and FUD. You make repeated claims
of coming in good faith etc. and seem to dismiss any technical defence
being made with vague references and then you bring out a aggressive
and argumentative statement like the above.
That is the impression you get.

I think I replied to technical arguments as well.

But I also see more social and how do I develop things, how do I treat portability people, how do I treat long year sysadmins, how do I treat bug reports and so on… I see much of the issue in this.

Sure, doing it like this initially makes it easier for you.

But it also creates the outcome you perceive.

It triggers and summons the polarity it triggers and summons.

It is your choice.
Post by Colin Guthrie
Again, you're totally confusing systemd as a project and systemd as a
PID 1. You need to accept and understand that distinction before
anyone here will take you even remotely seriously.
Okay, again my obversation:

1) Embrace: Systemd implements functionality that is available elsewhere. As PID 1 – service handling – and as project – DNS, DHCP, logging, handling core dumps… and others.

2) Extend: Systemd extends on this functionality. Which even makes sense.
systemctl status is wonderful. But it still does. Again I see this for PID 1 and for project.

3) Extinguish: More and more on the first sight unrelated projects, apps and so on depend on functionality that comes to distros as one entity: Systemd. More and more it becomes difficult to run a fully fledged LInux desktop with an alternative init system. More and more alternative init system developers need to play catchup game by implementing stuff systemd implements, but which was never fed into some standardization or stable API.

Again, again, and again: I see no bad intention. I see no conspiracy.

This is just what I *observe* and partly how I see similarities to Embrace, Extend and Extinguish.

Heck, I am not even sure Microsoft had this strategy from the beginning.

I am pretty sure you didn´t have this strategy. I am pretty sure Lennart did not have it. I am even pretty sure you or Lennart has it now.

But I see outcomes of the way how you currently handle things. Not *intended* outcomes, but still outcomes.

And I stand by it by pointing this out.

If you can´t handle this… fine… don´t. But thats how I see it.
Post by Colin Guthrie
Post by Martin Steigerwald
I don´t think this was your plan. But… when looking at the currently
visible outcome this is quite exactly what is happening here.
No. Looking at the visible outcome of this to me is that huge progress
is being made in documented APIs that solve real world projects backed
up by solid, supported and maintained implementations. To me this is a
great thing.
I am fine with this.
Post by Colin Guthrie
You are reading into it what you want based on your preconceptions and
then building up a case based on that. This is really a case of
apophenia, but people just don't see that because they are so
blinkered by their prejudices.
I am not fine with it. You don´t know what I do. You just interpret it.

As do I.

Its the only access I have to this world. I interpret what I see.

No what does make your interpretation more valid, than mine? What?
Post by Colin Guthrie
Post by Martin Steigerwald
So if you can follow this just a tiny bit: Do you start to
understand why systemd triggers the uproar, polarity and split so
obvious that one needs to have hands before both eyes for not seeing it?
What do you expect? Ultimately, haters gonna hate. There are a group
of people who are predisposed to hating change. systemd replaces a lot
of core functionality. If that was rolled out *without* causing a
group of people to complain I would have been surprised.
I seen feedback of haters. Yes.

But not almost all of the feedback I saw in debian-user, on debian-devel is that of haters or trolls.

Calling someone a hater or a troll is still calling names to me.

Its accusing and attacking persons to me.

What I tried to achieve is to describe and interpret what I see regarding the state of systemd as I understand it now, and granted my understanding may not be complete, sure, and also describe and interpret behavior I have seen. And also summarize some of this from the feedback I read elsewhere.

What I didn´t try to achieve was attacking persons.

Yet, I interpret your reaction to me as if I attacked you.

So I am obviously not producing the outcome I wanted to produce. And thats one reason why I think I will stop doing what I am doing after this mail and unsubscribe from this list for a while.

Actually I think I made my point. I tried to channel some of the dire concerns and uproar and polarity and split tendencies upstream.

I see this happening to my beloved distribution Debian and I am not happy about it. The systemd debates and polarity within Debian I consider as being harmful.

And it was my intention to address some of this upstream in order to discuss what can be done to first *understand* why it triggers this polarity and what can be done to address this.

Its causing harm.

Very much so. Right now. As we speak. And I am concerned about it.

I am confident that Debian as a project will manage. But I see the cost it has to the project. And I am very deeply concerned about it.
Post by Colin Guthrie
Of course this criticism is listened to and often actions are taken
because of it, but what do you expect the outcome to be? Do you expect
all the repos to be split up? Stable APIs exported and supported? What
outcome do you actually *want* here? You seem to be doing lots of
complaining, but very little in the actual suggesting what could be
done different that has not already been addressed technically. You
may disagree about that end decision but that's just the way it is
sometimes? The people doing the work ultimately get to make the decisions.
Yeah, thats the do-ocracy aspect of things. Still if what I do again and again and again triggers much of polarity and resistance, I´d ask myself whats going on there. Which brings me back to the point why I started this thread here.
Post by Colin Guthrie
Post by Martin Steigerwald
So as I see it: there are *real* concerns. And if systemd is meant
to be a tool for users and admins, I *highly* and *strongly*
recommend that you as systemd closely look at these concerns. Unless
you are willing to trigger the polarity, the split and the uproar that it creates.
In KDE more and more voices come up that developers need to talk to
their users. Sure… its a do-ocracy. But still… if you want to become
really broadly accepted and successful with something you offer… its
important to listen for feedback. And in my oppinion you are in a
good opportunity here, cause I think there is no lack on feedback on systemd.
You also seem to think that this feedback is somehow special or new.
Such feedback has been coming in for years and much of it has already
been listened to and acted on or decided as something not to be
supported or irrelevant. All of your posts so far seem to be worded
like you think this process has not happened at all. There is a wealth
of archive information, blog posts, conference talks and such like out
there to document this process. You need to be proactive to consume it
all, and you cannot expect to be spoon fed it all.
Well, okay. I don´t follow this list for that long already. I read here and there about systemd. Blog posts from Lennart but also critical feedback. Yet… as Debian was not affected, it was kinda remote to me. So… I think its understandable I don´t know five years of history.

I voice concerns I see now.

And as these concerns are now this tells to me that those who have the concerns either are not up to date that they have been address or otherwise don´t have the impression that it they got addresses. In some time concerns may have been addressed but information about it didn´t get throw. But in other cases it may just mean you deemed the concerns as being "irrelevant".

And this, in my eyes, it not quite a respectful way to deal with concerns.
Post by Colin Guthrie
Honestly, I've been following this project since it's very inception
and I from what I see your opinion of it has been formed around
notions that are pretty much entirely fictional or based on second
hand information/FUD. The accusations you make are often wildly
technically inaccurate and you seem to offer no credit to the
devlopers with regards to their collaboration.
This is your impression. I, as should be obvious right now, see this differently.

I see openness and technical discussion here, but I also see "not our business, go away" kind of reactions, in bug reports as someone pointed out in this thread already, but also here on this list.

Actually what you write above follows a similar pattern: Its the easiest way to develop things. Okay, it may is. For you. But did you consider the cost it creates for others?
Post by Colin Guthrie
I've been doing the rounds on mailing lists, distros and conferences
for years. systemd is one of the most open projects with regards to
doing the conference circuit and talking to people - all over the
world and with interested parties both commercial and community run.
There is no end of opportunity to speak with the systemd developers -
often in person - and discuss the issues. The regurgitation of the
same old stuff on mailing lists today no longer warrants further
discussion for the most part. Doing so just soaks up developer time
(and it takes a *lot* of time to reply to these things - this email
alone has likely taken me
20mins+ - I'd much rather developers give such "feedback" a brief read
over for any salient points and then ignore it and get on with
designing and writing code and making a difference.
It is your free choice to do with your time what you want to do. I am in no way forcing you to respond to my mail.

It seems to me you felt some urge to respond, as I felt urge to respond to you… thats okay. But thats something you feel or think, or I feel or think. So I give all responsibility on how you spend your time back to you.

I am not responsible for it.

As you are not responsible for that I read your mail so late and then not being able to sleep and just put it away till tomorrow.
Post by Colin Guthrie
Sorry, but I just do not see things they way you do and your repeated
regurgitation of factually incorrect statements is doing nothing but
making you appear to be someone to not waste time replying to further.
This is not ignorance or not listening to feedback or anything of the
like... it's ultimately, I'm sorry to say, just not feeding the
trolls[1] - or, if you prefer a more sanguine version, not replying is
just agreeing to disagree.
Col
1. for the avoidance of doubt, I don't mean anything nasty by this - I
just mean replying just continues a pseudo "discussion" with someone
who is not in any way listening to your arguments or accepting your
technical opinion - it's just a never ending discussion that leads
nowhere - it has to be starved to die off and cannot be fed.
That I received as a personal accusation.

I work with Linux for more than 10 years. I do system admin work, I give Linux trainings and and and…

Even if you try to do it politely. For me I received it as "You are a troll anyway."


Now I agree to disagree.

From the thread so far I understand way better why people are concerned, why
systemd as a project of developers, as a umbrella projects of building blocks
as you call it and as PID 1 triggers the amount of polarity it does:

Or as Aaron Seigo carefully tried to put it:

Aaron Seigo, four paths, 7th of October 2014:
http://aseigo.blogspot.com/2014/10/four-paths.html

How the way Lennart and other developers here treat people as I perceive here
and there also in how I feel being treated here has a contribution to the
reaction and outcome they get. That doesn´t excuse name calling or worse. But
it partly makes it understandable or explainable.

And as to the

"who is not in any way listening to your arguments or accepting your technical
opinion"

I can give back. I even wrote to Lennart once I have the impression he doesn´t
even relate to what I just wrote.

So I made my point. I made clear what my intentions were.

And I think there is nothing more to say for now.

I wish you success.

And thanks for putting the effort in the response you put into it.

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
_______________________________________________
systemd-devel mailing list
systemd-***@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com
Tom Gundersen
2014-10-22 10:38:33 UTC
Permalink
Hi Martin,

If you were to phrase your complaints/questions in terms of technical
issues, we could probably have a much more useful debate. What is
clear is that the systemd project will not do or change anything
merely based on some bystanders gut feeling (which is basically what
you have argued from).

If you are concerned about portability, go ahead, follow the advice
given here, start the port and once you hit issues come back and ask
questions. Until someone does this, I think we should consider the
whole portability issue closed.

Same for modularity, make a fork (in the sense Colin used) of the
parts of systemd you want to use in isolation, and come back when you
run into problems (there surely will be some, but maybe you can still
do the things you want).
Post by Martin Steigerwald
I will make an effort to reply to your mail and then most likely unsubscribe,
cause for me I feel like being in an hostile environment.
When you ignore technical answers, and more than insinuate that we use
the same vile practices as Microsoft once did (despite you claiming
you don't mean to accuse anyone, the way it comes out is a quite
strong accusation), you should expect some less than friendly
responses. That said, I think Lennart and Colin both went after your
arguments not your person (if you bother reading carefully what they
wrote).
Post by Martin Steigerwald
No. I am concerned about both. The functionality that is stuffed inside PID 1
which is more than 1,3 MiB and also sports user session functionality. And
what is coupled inside on project, more or less tight.
I already answered the issue with user sessions (and so have others),
I'm disappointed that you would bring it up again without seeming to
have read our replies. As to the size of PID1, why don't you go and
study why this is so? The code is there, there are tools to study the
binary. Then hopefully you would either agree that the size is
unproblematic, or you would come up with some constructive
suggestions/patches to change things.
Post by Martin Steigerwald
Post by Colin Guthrie
It also increases the test matrix. If logind v300 has to work with
libsystemd v300 and all future versions then the testing side of things
increases in complexity *massively*. Again this causes problems that
translate to time and effort of developers that could better be
allocated to building a better overall set of building blocks.
I do think that the easiest way to do something is not necessarily the best.
If you think there is a better way to do things, go ahead, do it.
Vaguely complaining that we should have done this or that differently
is not going to change any minds. It is worth noting (again) that the
way we manage our repository does not mean that others could not make
replacements for parts of systemd, the stuff is very modular. But
don't take my word for it, start coding and when you run into problems
come back with questions.

You are probably not getting out of this discussion what you hoped for
(I assume). Sorry about that. If you come back with bug reports,
feature requests or patches, you will have a much easier time
influencing things.

Cheers,

Tom
Colin Guthrie
2014-10-22 12:28:39 UTC
Permalink
Hello Martin,

Firstly, I apologise if you took what I said as a personal insult. It
was not my intention to do so (and I did try to make that explicitly
clear in a footnote).

I will certainly admit that some of my wording was more directed than I
had intended. This is something I would normally edit out and soften on
a read over, but time constraints didn't allow me that luxury.

That said, I do stand by my general comments. I will attempt a briefer
reply below [Spoiler: I failed!]
Post by Martin Steigerwald
I received this twice on this mailing list. Once from Lennart ("being a dick
now") and now from you calling me a troll.
For the avoidance of doubt, I didn't directly call you a troll. I was
trying to point out that even well intentioned discussions, like yours,
cat at times become indistinguishable from a trolling discussion. Not
deliberate (which trolling is), but because no matter what reply is
sent, the participants will not be satisfied with the answers and will
continue the discussion. It would appear that this discussion has
reached that stage.

Over various points, there have been answers given and corrections made,
and yet still no acceptance is really given to those decisions - it's at
a time like this where further discussion is counter productive to your
goal and just serves to alienate people rather than get them any closer
to sharing your opinion.
Post by Martin Steigerwald
I will make an effort to reply to your mail and then most likely unsubscribe,
cause for me I feel like being in an hostile environment.
I disagree that this is a hostile environment. It's just that people
here will (by definition) generally just disagree with you. I apologise
if my reply was worded in an overly-hostile way (I'll try better in this
email), but ultimately you're going to get replies here that will
generally disagree with your stance.
Post by Martin Steigerwald
Post by Colin Guthrie
Post by Martin Steigerwald
Thats rather much.
Really rather much.
Way more than traditonal sysvinit covered.
This is because traditional sysvinit covered PID 1 and performing it's
job (if you consider e.g. killall5 and friends).
You seem to be conflating systemd as PID 1 and systemd as a project.
These are two completely different things.
No. I am concerned about both. The functionality that is stuffed inside PID 1
which is more than 1,3 MiB and also sports user session functionality.
You use the term "stuffed" which is preloaded with negativity. Your
wording here would be better if you'd used the more neutral term
"included in" rather than "stuffed inside". By using this phrasing
you're already building up a barrier and will be polarising upstream
developers and will be reflected in their replies.

As another technical correction, PID 1 does NOT sport user session
functionality. It sports a general resource management concept (scopes
and slices) that is a userspace abstraction of the kernel cgroups
concept used for resource management. This is seen as core functionality
as it's PID1's job to fundamentally fork off other processes. I don't
think this is a point of contention.

Some people have argued that resource management should NOT be PID1's
job, and it should handled by a separate daemon. The argument thus far
from the systemd side is that doing this out of process would create a
chicken and egg problem. It's PID1's job to fork of processes and
configure their resources, but the "resource manager" processes' forking
would have to be special cased as there would be no "resource manager"
available when it was forked. If this sub component fails, then PID1
fails too. It's so tightly coupled that the arguments for doing it out
of process are simply not sufficiently compelling, so this special
casing is not something systemd developers are comfortable with
technically due to both startup and runtime requirements.

The user session functionality you speak of is implemented outside of
PID1 in logind. Because it also needs to manager resources, it has to
work with the resource manager which, as described above, is PID1 in
systemd.

If other init systems want to do this differently they are welcome to do so.
Post by Martin Steigerwald
Post by Colin Guthrie
An alternative would be to make the utility functions API stable and
export the shared library publicly and give API guarantees, but that
puts a lot of pressure and it's a difficult thing to provide and it has
long term maintenance overhead. This is something that *costs*. It costs
in time/man hours and therefore it carries real overheads. Doing this
for the convenience of splitting things out is simply not worth it -
especially so as the main people working on these things are the same
people.
I don´t think it would be just for the convenience of splitting things. It
would also be to address the concerns I summarized and that have been made
elsewhere. You may heard these concerns often, you may not agree to them. Yet,
if you say later that some of these concerns were made 5 years ago already… If
those concerns are still there… either… its due to Debian adopting systemd
now, but its not only Debian users and devels here giving that concerns… or it
is due to that the once voicing the concerns have the impression that systemd
upstream did not address them.
With the utmost respect, I think in many cases the only way upstream
could "address" some of the voiced concerns would be to simply stop
developing. This is obviously not something that can happen.

From what I can tell (feel free to correct me if I'm wrong) all of the
technical concerns you've raised in this thread have been addressed. You
may disagree with the response, but that doesn't mean the topic has not
been discussed and put to bed. I've not seen too much counter-discussion
actually around these technical points however.
Post by Martin Steigerwald
Post by Colin Guthrie
It also increases the test matrix. If logind v300 has to work with
libsystemd v300 and all future versions then the testing side of things
increases in complexity *massively*. Again this causes problems that
translate to time and effort of developers that could better be
allocated to building a better overall set of building blocks.
I do think that the easiest way to do something is not necessarily the best.
And sometimes the best way to do something is not always easy ;)
Post by Martin Steigerwald
It took KDE developers several years to split out KDE 4 into modules. Yet they
did it. And from what I read on their mailinglists so far, usually their
discussions are in a much more friendly tone.
I'm sorry, but I have to disagree about KDE4 here. As you may know I
have been a KDE developer (still am technically!) and participated in
packaging of KDE downstream. Splitting things up like this has very
little practical benefit. Downstreams (distros) still update things in
lockstep, so it's actually more work for distros although I do concede
at times it's easier to make a small tweak to something that builds
quickly, but systemd doesn't cross the threshold into taking forever to
build yet. In addition, some parts are still huge and contain, from an
outsiders perspective, many disparate parts (e.g. kde-runtime).

But overall, I don't think that splitting everything up to the n'th
degree works. I agree there is a balance, but IMO, by it's nature as a
base building block of OSes, systemd would not benefit from this.

Putting together an OS used to be a complex myriad of different scripts
and baroque tools pulled in from all over the place. systemd solved a
lot of that. It's easy to document and work with in it's current form.
Having split up modules that are kept in lockstep would just make that
more complex. An it doesn't address the vast majority of the concerns
I've heard voiced, so would be a pointless exercise as I've previously
stated.
Post by Martin Steigerwald
Now systemd is not KDE, granted… but I think thats not the only example where
developers took quite some extra effort in order to split things out.
I don't mean to put words in your mouth, but you seem to suggest that
splitting things out would be the right course of action? If that's the
case, have you looked over the components of systemd and thought about
that split, or are you just talking about this from a purely
philosophical perspective? Do you honestly think that if all the
components were split out in separate git repos, and thus required
distributions to glue things together downstream (still in lockstep),
that this would help?

One argument I've heard that says it would, is that this allows
independent implementations of the various sub-components. Personally, I
really don't buy this argument. Who is going to reimplement those
components? Lone users on their own systems, distributions, or some
commercial entity? To be honest it doesn't matter! If they want to
replace those components they totally can. Just do it, plug them in in
your operating system, make sure you implement the same ABI - including
DBus interfaces (if you don't want to rebuild other components) or API
(if you don't mind rebuilding) and you're fine. The documentation of the
APIs in systemd is very good. It's one of the best documented projects
I've seen. The fact the sub-component is in a separate git repo makes
absolutely zero difference to this end goal; it's just perception pure
and simple. It doesn't make sense for upstream to go out of their way
here to do something that's already easy for any sufficiently motivated
person or entity.

WHehter they are a distribution or a commercial company creating a
product, they can engineer things however they like. They can put the
subcomponents together as they see fit.

Honestly, I cannot think of any practical reason why splitting things
out would be better.
Post by Martin Steigerwald
Post by Colin Guthrie
So overall, keeping things developed as one project is a technical
decision that has real benefits both for the developers doing the work
and the downstreams consuming it. Changing the approach would be 100%
political and, quite frankly, the systemd developers have very little
time for such games. They just want to get on and build better systems.
It would be 100% political if the concerns where 100% political. But in my
oppinion they are not.
I think we just have to agree to disagree here. I've not yet seen any
compelling technical arguments as to why this would be a good idea.
Post by Martin Steigerwald
Post by Colin Guthrie
Post by Martin Steigerwald
What of this actually *needs* to be coupled with systemd? What of this
needs to be coupled tightly to Linux kernel?
If people want to provide implementations of such components outside of
systemd they would be more than welcome to do so.
As systemd provides a lot of the functionality and shared API functions
that are convenient to use (i.e. the base building blocks) and as people
who are working on the systemd project are doing the actual work, and as
these are seen as core building blocks of a modern OS, then it makes
sense to do this under the systemd umbrella.
There is no conspiracy here. It's just convenient. If other people want
to do this work, great.
I never assumed bad intentions.
I never assumed a conspiracy.
I never assumed bad intentions.
Do you need it again?
I never assumed a conspiracy.
I never assumed bad intentions.
I see you received what I wrote as such and I am puzzled, cause I carefully
took care to make that perfectly clear in all what I wrote so far.
It seems I still didn´t bring this point accross.
This may be due to history and Lennart and others here, systemd upstream
having been called names and worse.
Yet *I* didn´t.
I have to say, this reply to my comment is quite strange to me. Your
reply seems to be completely focused on the part of my response which
said "There is no conspiracy here". I made some technical observations
about why things are structured the way they are and you're reply didn't
address or provide counter arguments or example.

I'm trying not to be directing anything at you specifically, but you've
neatly avoided all the technical points and moved the discussion in a
different direction that is more personal and emotive. I've gone out of
my way to provide you technical examples as to why the organisation of
the code is the way it is and yet nothing I can see in your reply so far
has attempted to discuss things on that level, and instead focused on
one small statement.
Post by Martin Steigerwald
Post by Colin Guthrie
Post by Martin Steigerwald
systemd is driving a road where its all of this functionality by default is
only available for Linux and where upstream said they just won´t accept
patches – is that still true? – for portability.
systemd developer hs have stated this clearly several times over, but to
say it again, it's not that systemd *won't* accept patches for
portability, it's just that there will not be a codebase littered with
#ifdefs and optional codepaths that are not well tested by the core devs.
systemd makes use of APIs that are currently *only* available on Linux.
If other kernels implement the same APIs, then systemd will work with
them just fine. If they implement equivilent functionality under
different APIs, then it's unlikely the systemd developers would support
this upstream directly as this would result in these #ifdefs and
untestable paths (by the core developers) that are very unattractive for
the upstream project.
But you know what? This doesn't matter! Those developers who are
interested in those other kernels will just maintain their own fork of
systemd (and by form I mean a true fork - one which git facilitates well
where upstream changes can be merged periodically) where the linux calls
are split out into $whatever calls.
This separate project can be tested by those developers and they can act
as the first port of call for bugs in their version but collaborate with
the original systemd for issues that are present in their upstream. In
many cases the developers of this fork would have upstream commit access
to. Such a world is perfectly feasible and it allows systemd to keep a
clean codebase and the downstream too. This is one of the cases where
committing everything upstream is not beneficial to either systemd or
the fork. Both are more individually readable and maintainable by their
relative maintainers. Everyone wins.
Ok, how would these forks address compatibility issues with upstream systemd?
Upstream systemd has a very high development speed. Which you may view as
good. And heck, yes, it has its advantages I agree. But to me it also seems
that this speed partly come due to what you wrote above as the easy way of
developing things. And that easy way to develop things, I argue now, makes it
more difficult for people wanting to port to different platforms, people only
wanting a subset of systemd and people who want to adapt systemd.
So are you suggesting that progress be deliberately impeded to cater for
the lowest common denominator? I can't see that being popular!! :)

Such forks would obviosuly be by people who are interested and involved
in upstream projects. The fact that they do not have to keep up exactly
the same pace as upstream is *exactly* why they would be a fork in the
first place - if you consider the alternative would be supporting the
things they added in the fork upstream via a myriad of #ifdefs or
similar. As the core developers won't be testing this #ifdefery, they
either have to: 1) wait for a developer who does test such things to ACK
it, or 2) Do the release anyway, perhaps with broken support for $FOO.

However, if support for $FOO was in a fork, then the core developers
would be able to do their release unimpeded and the developer (or
developers) who care about $FOO can catch up when they get the time and
motivation to do so.

While it would be nice to do the release at around the same time, it's
certainly not mandatory. git makes these kind of things quite easy to
manage and I don't think such an arrangement is problematic.

If you, as a downstream, want support for $FOO, then you're accepting
that your decisions have consequences and repercussions. It might mean
you cannot update to certain other things until you've done the
underlying work, but that's fine. That's the choices you've made. This
is ultimately what happened with the systemd-shim stuff from what I can
tell and it's also what happens with some distro spins (e.g. Ubuntu
might be released before it's Kubuntu derivative).

Forcing the upstream to wait is not going to help.

As I mentioned, the people interested in $FOO would also hopefully be
upstream contributors too. Changes they make that make sense for
everyone will be implemented upstream and then merged into their
downstream. I don't see such developers working in complete isolation -
it's a symbiotic arrangement but ultimately upstream does not get held
to ransom or held back if some downstream becomes unsupported or it's
popularity fades.

The problem is that people have been so far very big on talk about
opposition, but very few have actually put their money where their mouth
is (metaphorically speaking) and come up with the code. git makes things
easy here, so what is stopping people?
Post by Martin Steigerwald
I just again and again also see the pattern of "This is not our business"
where it was systemd creating friction for others.
I really don't see this. If you don't want systemd, don't use it. It's
free software and you have a choice. It can only cause friction if you
want to use it. If you don't want to use it but some project you do want
to use does, then your complaints should be directed at that project,
not upstream. It's totally unfair to blame upstream for this!

If you see friction, then get involved, write patches or make
non-emotive, but specific and technical requests and accept the answers
given (perhaps with a little to-ing and fro-ing to ensure things are
properly understood, but ultimately there will always be cases where
upstream decisions are simply things that you, as a downstream consumer,
will disagree with - that's just life!)

I'm sorry to say, but large complaints about very vague and general
things like this thread are really not useful in such a perspective -
things have to be specific and clearly bounded. Each case then has to be
treated on it's own merits.
Post by Martin Steigerwald
Post by Colin Guthrie
Again, you're totally confusing systemd as a project and systemd as a
PID 1. You need to accept and understand that distinction before anyone
here will take you even remotely seriously.
1) Embrace: Systemd implements functionality that is available elsewhere. As
PID 1 – service handling – and as project – DNS, DHCP, logging, handling core
dumps… and others.
2) Extend: Systemd extends on this functionality. Which even makes sense.
systemctl status is wonderful. But it still does. Again I see this for PID 1
and for project.
3) Extinguish: More and more on the first sight unrelated projects, apps and so
on depend on functionality that comes to distros as one entity: Systemd. More
and more it becomes difficult to run a fully fledged LInux desktop with an
alternative init system. More and more alternative init system developers need
to play catchup game by implementing stuff systemd implements, but which was
never fed into some standardization or stable API.
Again, again, and again: I see no bad intention. I see no conspiracy.
OK, so for the record I will say I agree with your first two points
here. I just totally disagree with your third.

I'll turn it around and ask you a question. If systemd is providing
things that others want to consume, is this really *systemd* making it
harder? Or is it just that the apps and projects in question that are
depending on these things see a very specific need that is being
fulfilled in only one place? Is this a failing of systemd or is it a
failing of other people who actively want to provide an alternative? I
would suggest the latter. The fact that other projects are not popping
up that solve these problems suggest that actually *developers* are
quite happy. If they were not happy, there would be more projects that
do these things. From what I can see, the complaints about this are
coming from people who are not actually prepared to do the work to
create said alternative - perhaps with the goal to spur some people on.
Good luck to them I say. Healthy "competition" is good!

Now personally, I'd *prefer* if developers actually work and hack on
systemd rather than something that implements the same thing. This is
open source so while 100 implementations of varying quality is totally
allowed, I'd rather see the effort involved in creating those 100
implementation actually focused on one, best of bread implementation.
systemd is a building block, a plumbing layer. It should be devoid of
the "preferences" and "each to their own" nature of things like Desktop
Environments which see various different approaches. But really that
doesn't matter, as that's just what I would like to see.

Ultimately, if this apathy of the developers to create competing
infrastructure is your definition of "extinguish", then I'll agree with
you. That's what's happening, but, importantly, this is NOT something
that's being done *by* systemd. It's happening because those that are
able to do such a thing are clearly unwilling to do it. Again, one has
to ask why?
Post by Martin Steigerwald
This is just what I *observe* and partly how I see similarities to Embrace,
Extend and Extinguish.
Heck, I am not even sure Microsoft had this strategy from the beginning.
I am pretty sure you didn´t have this strategy. I am pretty sure Lennart did
not have it. I am even pretty sure you or Lennart has it now.
Form the context I'm not sure if your last sentence in the above is as
you intended? I think it's saying the opposite of what I *think* you
were wanting to say, but please do clarify.
Post by Martin Steigerwald
But I see outcomes of the way how you currently handle things. Not *intended*
outcomes, but still outcomes.
And I stand by it by pointing this out.
If you can´t handle this… fine… don´t. But thats how I see it.
I accept your observation but I think you're attributing it wrongly and
unfairly. The way in which you're suggesting it appears to be designed
to impose a prejudiced, negative view point and I don't think it's
something that is beneficial to discuss in such a way here.
Post by Martin Steigerwald
Post by Colin Guthrie
You are reading into it what you want based on your
preconceptions and then building up a case based on that. This is really
a case of apophenia, but people just don't see that because they are so
blinkered by their prejudices.
I am not fine with it. You don´t know what I do. You just interpret it.
As do I.
My statement above was indeed poorly written. This is my observation
based on your writing here and several similar posts I've read over the
last couple years. Sorry if this came across too personal.
Post by Martin Steigerwald
Its the only access I have to this world. I interpret what I see.
No what does make your interpretation more valid, than mine? What?
This is an interesting point actually.

I'm not directing this at your or my opinion here but this is a related
and useful read:
http://www.iflscience.com/brain/no-youre-not-entitled-your-opinion
Post by Martin Steigerwald
What I tried to achieve is to describe and interpret what I see regarding the
state of systemd as I understand it now, and granted my understanding may not
be complete, sure, and also describe and interpret behavior I have seen. And
also summarize some of this from the feedback I read elsewhere.
What I didn´t try to achieve was attacking persons.
I appreciate that's not your intention, but I hope you appreciate that
when you're the first person to say such things that's fine, you can
discuss things and get a response you disagree with and let the
discussion fade and die out. When the topic is discussed over and over
then there is a point when, regardless of the intentions of the
individual, by going over old ground *again*, it takes the patience of a
saint to not treat any such discussions some kind of continued attack
against the project.
Post by Martin Steigerwald
Yet, I interpret your reaction to me as if I attacked you.
I apologise if it came across that way. I concede some of the wording at
times was more directed than I had intended and should have been phrased
differently. It was more meant to be general observations of things I'd
seen before time and time again that also fitted the patterns of your
interactions, regardless of your no doubt good natured intent.
Post by Martin Steigerwald
Actually I think I made my point. I tried to channel some of the dire concerns
and uproar and polarity and split tendencies upstream.
I see this happening to my beloved distribution Debian and I am not happy
about it. The systemd debates and polarity within Debian I consider as being
harmful.
I consider it (mildly) harmful too, but I think it's a natural thing at
the same time. People are afraid of change. I am thankful that the
distribution community I work with were generally very open minded. They
didn't see this as a fundamental departure and once they started using
the features provided they where pretty happy generally and just go on
with using their systems. I watch on the debates around the issue with a
not insignificant amount of disbelief about how passionate people can be
about something that in many, many cases, has very obviously not been
tested properly in a clean, solidly deployed and integrated environment.
I obviously can't tar everyone with the same brush and this is a massive
generalisation, but this is generally what I've observed.
Post by Martin Steigerwald
And it was my intention to address some of this upstream in order to discuss
what can be done to first *understand* why it triggers this polarity and what
can be done to address this.
Its causing harm.
Very much so. Right now. As we speak. And I am concerned about it.
I am confident that Debian as a project will manage. But I see the cost it has
to the project. And I am very deeply concerned about it.
I think you should try to relax a bit (if you can find a way to do so).
I know it's a turbulent time, but it will fade and it will settle.

There will always be a section of the community that will disagree. I
don't think Ian Jackson will wake up one morning and say "ahh well, I
tried, I'll just install systemd now and do something else". Some things
will always stay fundamentally divergent and I think accepting that is
the way to being at peace with it! (I've seen very much the same
reaction to the polarising referendum choice here in Scotland - its a
fundamental facet of human nature!)
Post by Martin Steigerwald
Post by Colin Guthrie
Of course this criticism is listened to and often actions are taken
because of it, but what do you expect the outcome to be? Do you expect
all the repos to be split up? Stable APIs exported and supported? What
outcome do you actually *want* here? You seem to be doing lots of
complaining, but very little in the actual suggesting what could be done
different that has not already been addressed technically. You may
disagree about that end decision but that's just the way it is
sometimes? The people doing the work ultimately get to make the decisions.
Yeah, thats the do-ocracy aspect of things. Still if what I do again and again
and again triggers much of polarity and resistance, I´d ask myself whats going
on there. Which brings me back to the point why I started this thread here.
There is an expression too here that fits: You can't make an omelette
without breaking eggs!

I guess you're probably seeing all the people who are disagreeing
however. I see all the people collaborating - people from different
companies, communities; doing things in embedded, in massive server
deployments and management. I see all the things where people are
putting together awesome things. I see people enjoying a tasty omelette!

Believe me when I say I spend far too much time reading all the negative
and complaining things. I'm usually fairly good at not getting drawn
into lengthy email discussions, but I failed here :)
Post by Martin Steigerwald
Well, okay. I don´t follow this list for that long already. I read here and
there about systemd. Blog posts from Lennart but also critical feedback. Yet…
as Debian was not affected, it was kinda remote to me. So… I think its
understandable I don´t know five years of history.
Yes this is understandable, but you will appreciate that going over such
things again and again for upstream people is very, very frustrating and
this will likely be reflected in the tone of their replies (or implied
by the complete absence of them). Interpreting such things as
fundamental hostility or non-engagement is unfair. It's will often be a
product of the circumstance.
Post by Martin Steigerwald
And as these concerns are now this tells to me that those who have the
concerns either are not up to date that they have been address or otherwise
don´t have the impression that it they got addresses. In some time concerns
may have been addressed but information about it didn´t get throw. But in
other cases it may just mean you deemed the concerns as being "irrelevant".
And this, in my eyes, it not quite a respectful way to deal with concerns.
Perhaps it's not respectful if considered individually and in isolation.
But it's also not exactly respectful to come to upstream and ask the
same things over and over again. It could be argued that it also shows a
lack of respect not to properly research and reference previous
discussions. Ultimately respect is a two way street and it has to be earned.
Post by Martin Steigerwald
Post by Colin Guthrie
Honestly, I've been following this project since it's very inception and
I from what I see your opinion of it has been formed around notions that
are pretty much entirely fictional or based on second hand
information/FUD. The accusations you make are often wildly technically
inaccurate and you seem to offer no credit to the devlopers with regards
to their collaboration.
This is your impression. I, as should be obvious right now, see this
differently.
Another case of agree to disagree I think :)
Post by Martin Steigerwald
Actually what you write above follows a similar pattern: Its the easiest way
to develop things.
I also said a lot of other things too. The ease of development is one
factor. As I've outlined there are lots of others too. I've tried to
give a balance of reasons that all contribute, so summarising it as
"this is easiest" is a bit unfair.
Post by Martin Steigerwald
Okay, it may is. For you. But did you consider the cost it
creates for others?
Yes. This has been considered and the balance has been found and that
shapes the way things are done currently. It will continue to evolve
over time as it has up until now. There are costs all over the place in
doing things in certain ways (I've outlined some of them already) and
these are all factors.
Post by Martin Steigerwald
Post by Colin Guthrie
I've been doing the rounds on mailing lists, distros and conferences for
years. systemd is one of the most open projects with regards to doing
the conference circuit and talking to people - all over the world and
with interested parties both commercial and community run. There is no
end of opportunity to speak with the systemd developers - often in
person - and discuss the issues. The regurgitation of the same old stuff
on mailing lists today no longer warrants further discussion for the
most part. Doing so just soaks up developer time (and it takes a *lot*
of time to reply to these things - this email alone has likely taken me
20mins+ - I'd much rather developers give such "feedback" a brief read
over for any salient points and then ignore it and get on with designing
and writing code and making a difference.
It is your free choice to do with your time what you want to do. I am in no
way forcing you to respond to my mail.
It seems to me you felt some urge to respond, as I felt urge to respond to
you… thats okay. But thats something you feel or think, or I feel or think. So
I give all responsibility on how you spend your time back to you.
I am not responsible for it.
As you are not responsible for that I read your mail so late and then not
being able to sleep and just put it away till tomorrow.
Again, as with a previous reply chunk pointed out above, your reply to
this section has completely missed any technical and relevant point to
the fundamental matter at hand and focused on a personally discussion
point - that about finding time and desire to reply to mails in discussions.

I'm sorry to say, but you've again sidestepped the actual core
discussion in any qualitative way and not responded to my technical points.
Post by Martin Steigerwald
Post by Colin Guthrie
1. for the avoidance of doubt, I don't mean anything nasty by this - I
just mean replying just continues a pseudo "discussion" with someone who
is not in any way listening to your arguments or accepting your
technical opinion - it's just a never ending discussion that leads
nowhere - it has to be starved to die off and cannot be fed.
That I received as a personal accusation.
I work with Linux for more than 10 years. I do system admin work, I give Linux
trainings and and and…
Even if you try to do it politely. For me I received it as "You are a troll
anyway."
I apologise if you interpreted it that way. I think I clarified this
above already to the best of my ability, so won't go over it again here.
I will restate that I didn't intend this personally, but accept that you
interpreted it that way. So, I'm sorry for that.
Post by Martin Steigerwald
Now I agree to disagree.
From the thread so far I understand way better why people are concerned, why
systemd as a project of developers, as a umbrella projects of building blocks
http://aseigo.blogspot.com/2014/10/four-paths.html
How the way Lennart and other developers here treat people as I perceive here
and there also in how I feel being treated here has a contribution to the
reaction and outcome they get. That doesn´t excuse name calling or worse. But
it partly makes it understandable or explainable.
I think that's unfair. You're already joining in a loaded discussion.
I've already outlined above why you are, by the very nature of your
intervention, pre-loaded with the history of that topic, even if that's
not fair on you!

If the reply to your initial mail was simple "Sorry, but this has been
discussed before. If you want to discuss any specific points, please
grab me in the corridor at the next conference for 10 mins and we can
chat it over." would you have let the discussion die? I doubt it very
much. That would be a cordial reply, but it won't help you. A lack of
further reply would likely have left you with a similar degree if
disappointment and disillusionment with the project. Of course this is
impossible to say for certain and I don't want to project any feelings
on to you for situations that didn't happen!


Also I know Aaron fairly well. We've met on several occasions and I
follow his posts and blogs and I consider him a friend. At the same
time, I disagree with his stance on things at times and have always
disagreed with his feelings regarding Lennart. I won't go into the
details, but I feel it's in many cases the responsibility of interested
parties to get involved and pull, rather than for upstreams to push. I
think the latter imbibes some concept of entitlement that is not how
things can (or do) really work. I'm someone who will get involved in the
things I think I need to know more about. I've always been happy with
that approach over a myriad of projects that have piqued my interest
over the years. I think accepting peoples opinions of people without
dealing with them with your own issues on your own terms, is inherently
prejudicial.
Post by Martin Steigerwald
And thanks for putting the effort in the response you put into it.
I know the effort it takes to write such replies. I hope you are able to
put as much effort into integrating systemd cleanly in Debian in a way
that most users would not even notice! (if they don't notice, you've won!)

I hope this further response to you has been more cordial than my first.
I haven't read over it, so I hope it flows OK and I've not accidentally
slipped into any kind of personally directed statement again like I did
occasionaly last time. If I have, please try to read it as if I hadn't
as it was likely just the default prose style when replying to an
individual regarding a pattern that generally occurs, and entirely
unintentional.

Anyway, I wish you all the best.

Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Martin Steigerwald
2014-10-21 09:08:41 UTC
Permalink
Post by Uoti Urpala
Post by Rob Owens
My question really isn't "why are the Debian dependencies the way they
are". I understand that. I was trying to highlight the strange
situation of a desktop application requiring a particular init system. I
*think* this is a result of the init portion of systemd being bundled
together with the logind portion of systemd. To me (unfamiliar with the
systemd code) those two functions seem distinct enough to merit being
separate. Debian can't easily separate what the systemd devs have
developed as a single binary, so we end up with these strange dependency
chains.
"Single binary" is false of course. Logind is developed as a separate
program, which is why systemd-shim is possible at all.
AFAIK the actual relevant dependencies go as follows: First, there's a
good reason why logind requires cgroup functionality. And there's a good
reason why cgroup functionality is best implemented together with init
(see
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
for more info). So it's not quite directly "logind has to depend on
systemd as init", but "logind has to depend on the system having cgroup
support, and there's no equally good cgroup support available for inits
other than systemd". It is possible to provide the relevant cgroup
interfaces in or on top of another init, as the systemd-sysv + cgmanager
combination attempts to do. But it is not trivial to do, as bugs and
implementation delays with that combo have shown, and it's quite likely
that there will be more problems in the future. It's not a particularly
good idea to use the less-tested and less-reliable systemd-shim instead
of the more reliable systemd. Thus the overall result is that yes, it
does make sense to switch machines to systemd when you add certain
functionality, even if that functionality does not appear to be directly
tied to the init system at first glance.
I can´t point my finger at it why… but I really feel uncomfortable with this
tight coupling. I think that the systemd-shim + cgmanager combination may have
bugs does not *prove* that such a think isn´t workable.

But due to the design choice of you systemd developers to have it all in one
people who do believe that separating different functionality is for the long
term benefit of interoperability and avoiding what I´d call vendor lock in,
although I clearly see that systemd upstream community isn´t a single vendor
as in one company who produces a comercial product.

In other areas where the Linux kernel requires user space helpers things
initially have been separated. The whole do it all in once hald daemon was
split into udev, libudev, udisks and upower… yet now, systemd and udev is in
one upstream again.

What speaks against putting the cgroup functionality and other stuff from
systemd into shared libraries with clearly defined APIs – which are documented
and where the documentation is the reference, not the source code – and
allowing it to be used elsewhere?

Then systemd may use it as PID 1, but if someother wants to use it in own
project, can use it as well. I consider cgroups as part of the kernel API and
I highly dislike the battle on which of the available solutions will get
control over it. Actually I still think the API is broke if it cannot allow
for mutiple processes accessing it. I don´t know an easy way to fix it, but I
think such a kind of API as kernel interface… anyone can read a file, mount a
filesystem, open a network socket, set a nice value depending on permissions
but when it comes to control groups it is down to "one to rule them all". I
can´t help it, but this just seems utterly broke to me.

I can´t help it but I don´t consider this to be a sane operating system API.
Post by Uoti Urpala
Post by Rob Owens
I never thought much about my init system until recently. I never really
had any complaints with SysV init, although I do recognize that systemd
provides real improvements for some use cases. So for me as a sysadmin
the wisest thing to do is stick with what I already know, as long as it's
working well enough (and for me, it is).
The issue with "I should be able to stay with sysvinit because it worked
fine for me" is that keeping sysvinit working is COSTLY. The reason
sysvinit used to mostly work was not that it would have been a reliable
system - it mostly worked because people kept using a lot of effort to
work around and paper over various issues that kept popping up. And
there's no justification to keep up that effort for the minority who
wants to stay with sysvinit. So, you can keep running your old systems
unchanged if you want, but you shouldn't expect to be able to upgrade
them or install new software without switching to systemd.
What you write here basically comes down to a forced adoption. At least this
is how I receive what you write.

I know understand much more clearly on why systemd triggers split and polarity
and I am quite worried about it.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Jan Alexander Steffens
2014-10-21 09:26:16 UTC
Permalink
On Tue, Oct 21, 2014 at 11:08 AM, Martin Steigerwald
Post by Martin Steigerwald
Then systemd may use it as PID 1, but if someother wants to use it in own
project, can use it as well. I consider cgroups as part of the kernel API and
I highly dislike the battle on which of the available solutions will get
control over it. Actually I still think the API is broke if it cannot allow
for mutiple processes accessing it. I don´t know an easy way to fix it, but I
think such a kind of API as kernel interface… anyone can read a file, mount a
filesystem, open a network socket, set a nice value depending on permissions
but when it comes to control groups it is down to "one to rule them all". I
can´t help it, but this just seems utterly broke to me.
I can´t help it but I don´t consider this to be a sane operating system API.
Note that the maintainers of the kernel-side cgroup API (primarily
Tejun Heo, AFAIK) consider the current interface insane. In the
future, the kernel will expect a single userspace process to control a
single hierarchy. Systemd has already been adapted to provide this
schema using the current API. See
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html
.
Martin Steigerwald
2014-10-21 09:41:41 UTC
Permalink
Post by Jan Alexander Steffens
On Tue, Oct 21, 2014 at 11:08 AM, Martin Steigerwald
Post by Martin Steigerwald
Then systemd may use it as PID 1, but if someother wants to use it in own
project, can use it as well. I consider cgroups as part of the kernel API
and I highly dislike the battle on which of the available solutions will
get control over it. Actually I still think the API is broke if it cannot
allow for mutiple processes accessing it. I don´t know an easy way to fix
it, but I think such a kind of API as kernel interface… anyone can read a
file, mount a filesystem, open a network socket, set a nice value
depending on permissions but when it comes to control groups it is down
to "one to rule them all". I can´t help it, but this just seems utterly
broke to me.
I can´t help it but I don´t consider this to be a sane operating system API.
Note that the maintainers of the kernel-side cgroup API (primarily
Tejun Heo, AFAIK) consider the current interface insane. In the
future, the kernel will expect a single userspace process to control a
single hierarchy. Systemd has already been adapted to provide this
schema using the current API. See
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html
Well I concur with that.

I think the mutiple hierarchy API is inconsistent and insane. I see the point
of having a unified hierarchy. But I never understand the requirement of one
process controlling it and then having a battle over which process it will be.

Whereever else we had something like this, it was tightly reduced to one
functionality and available separate. Like udev, but still tightly coupled
with the kernel and free to anyone to use – *just* this part of the
functionality. Just like the Performance Events with the perf tools. Or
iproute. Or you name it: Everyone providing one functionality. And… in its
part being replacable.

But with systemd it appears to be an all or nothing approach. I don´t only get
control groups, but everything else… or else I need to duplicate the
functionality myself.

That just doesn´t make any sense to me. For udev I had the impression it was
some quite approved part of the Linux kernel userspace utility.

So while I think the old mutiple hierarchy API is broke, and heck I teached it
in my Linux Performance analysis and tuning courses… I do think the new API is
broke as well.

Sometimes I think better ditch it all and redo it from scratch.

Anyone can open a file, mount a fs, set a nice value, but only one process can
do resource control of process groups via cgroups. This doesn´t make any sense
to me.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Lennart Poettering
2014-10-21 09:36:35 UTC
Permalink
Post by Martin Steigerwald
Post by Uoti Urpala
systemd as init", but "logind has to depend on the system having cgroup
support, and there's no equally good cgroup support available for inits
other than systemd". It is possible to provide the relevant cgroup
interfaces in or on top of another init, as the systemd-sysv + cgmanager
combination attempts to do. But it is not trivial to do, as bugs and
implementation delays with that combo have shown, and it's quite likely
that there will be more problems in the future. It's not a particularly
good idea to use the less-tested and less-reliable systemd-shim instead
of the more reliable systemd. Thus the overall result is that yes, it
does make sense to switch machines to systemd when you add certain
functionality, even if that functionality does not appear to be directly
tied to the init system at first glance.
I can´t point my finger at it why… but I really feel uncomfortable with this
tight coupling. I think that the systemd-shim + cgmanager combination may have
bugs does not *prove* that such a think isn´t workable.
Well, you can do tons of things, that simple fact doesn't really make
all of them a good idea.

PID1 is supposed to start and maintain services. In our eyes this is
best done with cgroups, because that allows us to keep track of the
service processes, label them, list them, kill them, get notifications
about them. All this functionality is implicitly done by the kernel
for us, we just need to make use of it, with a few mkdir()s and
open()+write()s, awesome! That's why we use it.

Now, of course you can split that out in multiple daemons, but then
you have to do IPC between these daemons. That's already bad enough,
for complexity and stability reasons. However, what's worse is that it
creates a chicken and egg problem: if PID forks of a service like
cgmanager in order to *manage* a service like cgmanager, then you have
a cyclic dependency. You can of course hackishly work around this, but
this would mean to exclude cgmanager from service supervision. And
moreover: for what even? For executing a few mkdir()s and write()s
out-of-process? Really?

Hence: while these things are certainly possible I am strongly of the
opinion that they would be a systematically bad design, and we will
hence not do such a fuckup in systemd. Sorry.
Post by Martin Steigerwald
But due to the design choice of you systemd developers to have it all in one
people who do believe that separating different functionality is for the long
term benefit of interoperability and avoiding what I´d call vendor lock in,
although I clearly see that systemd upstream community isn´t a single vendor
as in one company who produces a comercial product.
We are open source. There is no such thing as vendor lockin. You are
just fudding around now. I really don't appreciate what you are
writing here.

This has been discussed a million times before. If you want to discuss
this again then find another forum.
Post by Martin Steigerwald
In other areas where the Linux kernel requires user space helpers things
initially have been separated. The whole do it all in once hald daemon was
split into udev, libudev, udisks and upower… yet now, systemd and udev is in
one upstream again.
I think you misunderstand the history of hal really.
Post by Martin Steigerwald
What speaks against putting the cgroup functionality and other stuff from
systemd into shared libraries with clearly defined APIs – which are documented
and where the documentation is the reference, not the source code – and
allowing it to be used elsewhere?
See above.

Our APIs are actually pretty well documented, in documentation, not
source code. You seem to imply otherwise. What do you want more
documentation for? Can you be more explicit please?
Post by Martin Steigerwald
Then systemd may use it as PID 1, but if someother wants to use it in own
project, can use it as well. I consider cgroups as part of the kernel API and
I highly dislike the battle on which of the available solutions will get
control over it. Actually I still think the API is broke if it cannot allow
for mutiple processes accessing it. I don´t know an easy way to fix it, but I
think such a kind of API as kernel interface… anyone can read a file, mount a
filesystem, open a network socket, set a nice value depending on permissions
but when it comes to control groups it is down to "one to rule them all". I
can´t help it, but this just seems utterly broke to me.
Well, if you think the cgroup interface is broken, please bring this
up with the kernel folks not us.
Post by Martin Steigerwald
I can´t help it but I don´t consider this to be a sane operating system API.
Maybe instead of criticising the kernel folks and us for technical
choices you should really get your hands dirty and try to make it
better?
Post by Martin Steigerwald
Post by Uoti Urpala
The issue with "I should be able to stay with sysvinit because it worked
fine for me" is that keeping sysvinit working is COSTLY. The reason
sysvinit used to mostly work was not that it would have been a reliable
system - it mostly worked because people kept using a lot of effort to
work around and paper over various issues that kept popping up. And
there's no justification to keep up that effort for the minority who
wants to stay with sysvinit. So, you can keep running your old systems
unchanged if you want, but you shouldn't expect to be able to upgrade
them or install new software without switching to systemd.
What you write here basically comes down to a forced adoption. At least this
is how I receive what you write.
Forced???

We don't force anyone. The technical committees of the various distros
make their choices. If they don't like systemd, then they don't like
it. If they do, they do. We can live with either. But I really don't
see how we as upstream would "force" anything.

How could it even be "forcing"? We provide you something for
free. Take it or leave it. How can you be so impolite to call
something "forcing" if you get it as an optional offer, for free? I
mean, if anything you should be thankful for our work or at least
ignore it, but not be a dick about it.

Lennart
--
Lennart Poettering, Red Hat
Martin Steigerwald
2014-10-21 08:53:40 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Rob Owens
Systemd-shim provides some functionality that systemd-sysv provides,
and allows admins to use init systems other than systemd while still
installing things like brasero. I think this is a great thing,
except I wonder why the systemd project didn't separate this
functionality from the init system in the first place. Systemd-shim
is a duplication of effort. Not only that, but it must time its
releases with the releases of systemd-sysv. That's no big deal for
Debian's stable release, but it can be problematic in Debian's
unstable and testing branches.
Because it's additional work and complications. Apparently providing
systemd functionality without systemd running is not a trivial
undertaking, as the lag between systemd and systemd-shim releases
shows. I could spend my time for open source development on a
(technically) pointless (from my vantage point) split, but I
prefer to improve systemd instead.
Debian as a project already paid significant to support systemd as an
alternative, when systemd version was held back for a year waiting
for systemd-shim to catch up. This is certainly not the last time.
[snip]
I think exactly this kind of attitude is what triggers most of the polarity
around systemd.

Its like "We don´t force systemd on anyone, but we provide as lots of
functionality tightly coupled with it and if you do not implement it
elsewhere, i.e. catch up, you need systemd anyway".

While I believe it is *extra* work to separate functionality, I think it is
*important* work. It would raise the acceptance of systemd, it would reduce
the polarity it triggers. And it would make it more interoperable.

Right now people are duplicating systemd stuff in several other areas. The
reluctance to adopt systemd with certain distributions creates friction. Other
implementations need to catch up and at any point in time may not be
compatible.

So, aside from it being additional work, is there any *solid* or even
*unavoidable* technical reason to couple functionality that tightly?

Wherever I look free software projects do great extra work to modularize and
separate out functionality that can be separate. For a reason. See KDE
community for example. They spend years of development work into separating
things out into separate packages and have a clear ruling on what may depend
on what. There are other examples for sure, OpenStack for example, while I do
not yet know it in detail consists of a ton of separate packages in Debian.

So or so… I think its this kind of attitude that triggers most of the polarity
and split.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Tom Gundersen
2014-10-21 09:07:01 UTC
Permalink
On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald
Post by Martin Steigerwald
Post by Zbigniew Jędrzejewski-Szmek
Post by Rob Owens
Systemd-shim provides some functionality that systemd-sysv provides,
and allows admins to use init systems other than systemd while still
installing things like brasero. I think this is a great thing,
except I wonder why the systemd project didn't separate this
functionality from the init system in the first place. Systemd-shim
is a duplication of effort. Not only that, but it must time its
releases with the releases of systemd-sysv. That's no big deal for
Debian's stable release, but it can be problematic in Debian's
unstable and testing branches.
Because it's additional work and complications. Apparently providing
systemd functionality without systemd running is not a trivial
undertaking, as the lag between systemd and systemd-shim releases
shows. I could spend my time for open source development on a
(technically) pointless (from my vantage point) split, but I
prefer to improve systemd instead.
Debian as a project already paid significant to support systemd as an
alternative, when systemd version was held back for a year waiting
for systemd-shim to catch up. This is certainly not the last time.
[snip]
I think exactly this kind of attitude is what triggers most of the polarity
around systemd.
Its like "We don´t force systemd on anyone, but we provide as lots of
functionality tightly coupled with it and if you do not implement it
elsewhere, i.e. catch up, you need systemd anyway".
While I believe it is *extra* work to separate functionality, I think it is
*important* work. It would raise the acceptance of systemd, it would reduce
the polarity it triggers. And it would make it more interoperable.
Right now people are duplicating systemd stuff in several other areas. The
reluctance to adopt systemd with certain distributions creates friction. Other
implementations need to catch up and at any point in time may not be
compatible.
So, aside from it being additional work, is there any *solid* or even
*unavoidable* technical reason to couple functionality that tightly?
Wherever I look free software projects do great extra work to modularize and
separate out functionality that can be separate. For a reason. See KDE
community for example. They spend years of development work into separating
things out into separate packages and have a clear ruling on what may depend
on what. There are other examples for sure, OpenStack for example, while I do
not yet know it in detail consists of a ton of separate packages in Debian.
So or so… I think its this kind of attitude that triggers most of the polarity
and split.
Most of the modules in systemd do not depend on eachother. However,
logind does depend on the cgroups dbus API of systemd (PID1). In the
past logind interacted with the cgroups fs directly, but this had to
be changed as the kernel is moving to a model where only one process
may be in charge of cgroups. On systemd systems that one process is
PID1 (why that is so has been discussed elsewhere so won't repeat
that), so anything needing to deal with cgroups needs to go through
the systemd API.

I hope that explains why logind has to depend on systemd (or at least
something implementing the systemd API).

Cheers,

Tom
Martin Steigerwald
2014-10-21 09:35:29 UTC
Permalink
Post by Tom Gundersen
On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald
Post by Martin Steigerwald
Post by Zbigniew Jędrzejewski-Szmek
Post by Rob Owens
Systemd-shim provides some functionality that systemd-sysv provides,
and allows admins to use init systems other than systemd while still
installing things like brasero. I think this is a great thing,
except I wonder why the systemd project didn't separate this
functionality from the init system in the first place. Systemd-shim
is a duplication of effort. Not only that, but it must time its
releases with the releases of systemd-sysv. That's no big deal for
Debian's stable release, but it can be problematic in Debian's
unstable and testing branches.
Because it's additional work and complications. Apparently providing
systemd functionality without systemd running is not a trivial
undertaking, as the lag between systemd and systemd-shim releases
shows. I could spend my time for open source development on a
(technically) pointless (from my vantage point) split, but I
prefer to improve systemd instead.
Debian as a project already paid significant to support systemd as an
alternative, when systemd version was held back for a year waiting
for systemd-shim to catch up. This is certainly not the last time.
[snip]
I think exactly this kind of attitude is what triggers most of the polarity
around systemd.
Its like "We don´t force systemd on anyone, but we provide as lots of
functionality tightly coupled with it and if you do not implement it
elsewhere, i.e. catch up, you need systemd anyway".
While I believe it is *extra* work to separate functionality, I think it is
*important* work. It would raise the acceptance of systemd, it would reduce
the polarity it triggers. And it would make it more interoperable.
Right now people are duplicating systemd stuff in several other areas. The
reluctance to adopt systemd with certain distributions creates friction.
Other implementations need to catch up and at any point in time may not
be compatible.
So, aside from it being additional work, is there any *solid* or even
*unavoidable* technical reason to couple functionality that tightly?
Wherever I look free software projects do great extra work to modularize
and separate out functionality that can be separate. For a reason. See
KDE community for example. They spend years of development work into
separating things out into separate packages and have a clear ruling on
what may depend on what. There are other examples for sure, OpenStack for
example, while I do not yet know it in detail consists of a ton of
separate packages in Debian.
So or so… I think its this kind of attitude that triggers most of the
polarity and split.
Most of the modules in systemd do not depend on eachother. However,
logind does depend on the cgroups dbus API of systemd (PID1). In the
past logind interacted with the cgroups fs directly, but this had to
be changed as the kernel is moving to a model where only one process
may be in charge of cgroups. On systemd systems that one process is
PID1 (why that is so has been discussed elsewhere so won't repeat
that), so anything needing to deal with cgroups needs to go through
the systemd API.
I hope that explains why logind has to depend on systemd (or at least
something implementing the systemd API).
Thanks, Tom.

As explained in another post – I didn´t read all the new answers… but it makes
sense to do so – actually I feel uncomfortable about the new cgroup API. Its a
kernel API. The Linux Kernel is a kernel supporting preemptive multitasking.
Yet the new cgroup API requires or at least strongly recommends that only one
process uses it. And… additionally to that that is a change that has been
proposed by developers that to me oppinion are quite near or even working for
systemd upstream.

To me a single-process-usable API in the kernel seems broke. It may be hard to
get the locking right… but still… I think the current cgroup API is still as
broke as it can get. The unified hierarchy approach makes some sense to me, but
requiring that only one process modifies it, instead of providing an API
mutiple processes can use just seems plain broke to me.

And I know, thats probably something to raise on LKML. And I may be inclined
to do so.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Tom Gundersen
2014-10-21 09:45:53 UTC
Permalink
On Tue, Oct 21, 2014 at 11:35 AM, Martin Steigerwald
Post by Martin Steigerwald
Post by Tom Gundersen
On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald
Post by Martin Steigerwald
Post by Zbigniew Jędrzejewski-Szmek
Post by Rob Owens
Systemd-shim provides some functionality that systemd-sysv provides,
and allows admins to use init systems other than systemd while still
installing things like brasero. I think this is a great thing,
except I wonder why the systemd project didn't separate this
functionality from the init system in the first place. Systemd-shim
is a duplication of effort. Not only that, but it must time its
releases with the releases of systemd-sysv. That's no big deal for
Debian's stable release, but it can be problematic in Debian's
unstable and testing branches.
Because it's additional work and complications. Apparently providing
systemd functionality without systemd running is not a trivial
undertaking, as the lag between systemd and systemd-shim releases
shows. I could spend my time for open source development on a
(technically) pointless (from my vantage point) split, but I
prefer to improve systemd instead.
Debian as a project already paid significant to support systemd as an
alternative, when systemd version was held back for a year waiting
for systemd-shim to catch up. This is certainly not the last time.
[snip]
I think exactly this kind of attitude is what triggers most of the polarity
around systemd.
Its like "We don´t force systemd on anyone, but we provide as lots of
functionality tightly coupled with it and if you do not implement it
elsewhere, i.e. catch up, you need systemd anyway".
While I believe it is *extra* work to separate functionality, I think it is
*important* work. It would raise the acceptance of systemd, it would reduce
the polarity it triggers. And it would make it more interoperable.
Right now people are duplicating systemd stuff in several other areas. The
reluctance to adopt systemd with certain distributions creates friction.
Other implementations need to catch up and at any point in time may not
be compatible.
So, aside from it being additional work, is there any *solid* or even
*unavoidable* technical reason to couple functionality that tightly?
Wherever I look free software projects do great extra work to modularize
and separate out functionality that can be separate. For a reason. See
KDE community for example. They spend years of development work into
separating things out into separate packages and have a clear ruling on
what may depend on what. There are other examples for sure, OpenStack for
example, while I do not yet know it in detail consists of a ton of
separate packages in Debian.
So or so… I think its this kind of attitude that triggers most of the
polarity and split.
Most of the modules in systemd do not depend on eachother. However,
logind does depend on the cgroups dbus API of systemd (PID1). In the
past logind interacted with the cgroups fs directly, but this had to
be changed as the kernel is moving to a model where only one process
may be in charge of cgroups. On systemd systems that one process is
PID1 (why that is so has been discussed elsewhere so won't repeat
that), so anything needing to deal with cgroups needs to go through
the systemd API.
I hope that explains why logind has to depend on systemd (or at least
something implementing the systemd API).
Thanks, Tom.
As explained in another post – I didn´t read all the new answers… but it makes
sense to do so – actually I feel uncomfortable about the new cgroup API. Its a
kernel API. The Linux Kernel is a kernel supporting preemptive multitasking.
Yet the new cgroup API requires or at least strongly recommends that only one
process uses it. And… additionally to that that is a change that has been
proposed by developers that to me oppinion are quite near or even working for
systemd upstream.
To me a single-process-usable API in the kernel seems broke. It may be hard to
get the locking right… but still… I think the current cgroup API is still as
broke as it can get. The unified hierarchy approach makes some sense to me, but
requiring that only one process modifies it, instead of providing an API
mutiple processes can use just seems plain broke to me.
And I know, thats probably something to raise on LKML. And I may be inclined
to do so.
The systemd project does not have much (any?) influence over what
interfaces the kernel provides, so I suggest you take your concerns up
with them. That said, you will likely get further with technical
arguments, and preferably an alternate implementation, than just
claiming you have a bad feeling.

Cheers,

Tom
Lennart Poettering
2014-10-21 09:21:36 UTC
Permalink
Post by Martin Steigerwald
So, aside from it being additional work, is there any *solid* or even
*unavoidable* technical reason to couple functionality that tightly?
Yes, there always is. For logind for example we need to be able to
group the processes of a session, so that we can keep track of them,
list them, kill them, get notifications about them, and so on. For
that we need the "scope" concept of PID1. That's why logind talks to
PID 1.

You know, it really annoys me if you imply that we just made these
choices because we are assholes. We use the APIs we use because we
need their technical functionality. It's that simple. It would be
great if you'd grant us the benefit of the doubt at least, instead of
implying anything else.
Post by Martin Steigerwald
Wherever I look free software projects do great extra work to modularize and
separate out functionality that can be separate. For a reason. See KDE
community for example. They spend years of development work into separating
things out into separate packages and have a clear ruling on what may depend
on what. There are other examples for sure, OpenStack for example, while I do
not yet know it in detail consists of a ton of separate packages in Debian.
Well, we are not KDE, and not OpenStack. We provide a basic toolbox to
build an OS from. Compare us with Busybox if you must. I don't hear
you complaining about busybox all the time!
Post by Martin Steigerwald
So or so… I think its this kind of attitude that triggers most of the polarity
and split.
Well, our priority is to solve technical problems in a way we perceive
elegant and minimal. Your priority appears to be appeasing people who
prefer religious reasoning over technical reasoning. I am pretty sure
you cannot appease those, and we will not compromise our technical
necessesities for that.

Anyway, can we please end this discussion on this ML please? Please
continue this somewhere else, this ML is really for technical
discussions.

Sorry,

Lennart
--
Lennart Poettering, Red Hat
Martin Steigerwald
2014-10-21 09:47:06 UTC
Permalink
Post by Lennart Poettering
Post by Martin Steigerwald
So, aside from it being additional work, is there any *solid* or even
*unavoidable* technical reason to couple functionality that tightly?
Yes, there always is. For logind for example we need to be able to
group the processes of a session, so that we can keep track of them,
list them, kill them, get notifications about them, and so on. For
that we need the "scope" concept of PID1. That's why logind talks to
PID 1.
You know, it really annoys me if you imply that we just made these
choices because we are assholes. We use the APIs we use because we
need their technical functionality. It's that simple. It would be
great if you'd grant us the benefit of the doubt at least, instead of
implying anything else.
Lennart, I didn´t imply that, and I didn´t say that.
Post by Lennart Poettering
Post by Martin Steigerwald
Wherever I look free software projects do great extra work to modularize
and separate out functionality that can be separate. For a reason. See
KDE community for example. They spend years of development work into
separating things out into separate packages and have a clear ruling on
what may depend on what. There are other examples for sure, OpenStack for
example, while I do not yet know it in detail consists of a ton of
separate packages in Debian.
Well, we are not KDE, and not OpenStack. We provide a basic toolbox to
build an OS from. Compare us with Busybox if you must. I don't hear
you complaining about busybox all the time!
Lennart, I get the impression you feel being accused. Yet I tried honestly to
keep my mails to be polite and respectful. I tried to discuss about systemd
and attitudes, not about persons.

Busybox is highly more optional than systemd. I can use bash and coreutils, or
mksh and BSD commands or whatnot.
Post by Lennart Poettering
Post by Martin Steigerwald
So or so… I think its this kind of attitude that triggers most of the
polarity and split.
Well, our priority is to solve technical problems in a way we perceive
elegant and minimal. Your priority appears to be appeasing people who
prefer religious reasoning over technical reasoning. I am pretty sure
you cannot appease those, and we will not compromise our technical
necessesities for that.
Anyway, can we please end this discussion on this ML please? Please
continue this somewhere else, this ML is really for technical
discussions.
Sorry,
Well… actually I tried to discuss the concerns I and others have openly.

I went through the hassle to provide the feedback where it matters… upstream…
instead of joining the flamefests elsewhere or calling you names…

… but it seems to me you are so sensitive to feedback that I don´t have the
impression you even relate to the concerns I voiced here, which in part is a
summary of the part of concerns I read elsewhere I see as being founded.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Lennart Poettering
2014-10-21 09:59:09 UTC
Permalink
Post by Martin Steigerwald
Post by Lennart Poettering
Post by Martin Steigerwald
So or so… I think its this kind of attitude that triggers most of the
polarity and split.
Well, our priority is to solve technical problems in a way we perceive
elegant and minimal. Your priority appears to be appeasing people who
prefer religious reasoning over technical reasoning. I am pretty sure
you cannot appease those, and we will not compromise our technical
necessesities for that.
Anyway, can we please end this discussion on this ML please? Please
continue this somewhere else, this ML is really for technical
discussions.
Sorry,
Well… actually I tried to discuss the concerns I and others have openly.
I went through the hassle to provide the feedback where it matters… upstream…
instead of joining the flamefests elsewhere or calling you names…
… but it seems to me you are so sensitive to feedback that I don´t have the
impression you even relate to the concerns I voiced here, which in part is a
summary of the part of concerns I read elsewhere I see as being founded.
We are always interested in technical feedback.

We are not very interested in FUD mails that tell us how we'd "force"
people, how we'd behave like microsoft and so on. That's not useful,
that's pretty much only hurtful.

Sorry,

Lennart
--
Lennart Poettering, Red Hat
Martin Steigerwald
2014-10-21 10:06:10 UTC
Permalink
Post by Lennart Poettering
Post by Martin Steigerwald
Post by Lennart Poettering
Post by Martin Steigerwald
So or so… I think its this kind of attitude that triggers most of the
polarity and split.
Well, our priority is to solve technical problems in a way we perceive
elegant and minimal. Your priority appears to be appeasing people who
prefer religious reasoning over technical reasoning. I am pretty sure
you cannot appease those, and we will not compromise our technical
necessesities for that.
Anyway, can we please end this discussion on this ML please? Please
continue this somewhere else, this ML is really for technical
discussions.
Sorry,
Well… actually I tried to discuss the concerns I and others have openly.
I went through the hassle to provide the feedback where it matters…
upstream… instead of joining the flamefests elsewhere or calling you
names…
… but it seems to me you are so sensitive to feedback that I don´t have the
impression you even relate to the concerns I voiced here, which in part is
a summary of the part of concerns I read elsewhere I see as being
founded.
We are always interested in technical feedback.
We are not very interested in FUD mails that tell us how we'd "force"
people, how we'd behave like microsoft and so on. That's not useful,
that's pretty much only hurtful.
Sorry,
I didn´t intend to hurt you. I am sorry if you used what I wrote to hurt
yourself.

I just compared regarding the outcome. And to me there are similarities
regarding the outcome.

I never said you intended this. I never said you behaved intently in this way.

That is *where* I differ from any of the personal accusation stuff.

I am not assuming bad intent.

Not at all.

But I see similarities in the outcome.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Rob Owens
2014-10-22 16:11:13 UTC
Permalink
----- Original Message -----
Post by Lennart Poettering
We are always interested in technical feedback.
I have seen this comment several times from the systemd devs, and I don't doubt it. But I think much of the criticism of systemd is not technical. It has a more social/political nature, and I think you should be interested in that feedback as well (even if it is technically un-interesting).

Here is an example of what I consider a social/political problem stemming from technical decisions:

Say you are a housing developer. After many calculations, you have decided that the best design for housing is a cube. It has a high volume-to-surface-area ratio, which allows it to house the most people with minimal heating/cooling loss to the outside environment. It is easier to build than a sphere (which would have a higher volume-to-surface-area ratio). To further maximize efficiency, each building will be a multi-unit dwelling. Interior units will have very little heat transfer to the outside, because the surrounding units help insulate them.

However, I don't want to share walls with another family, so I decide to buy a standalone house even though it is technically less efficient. That's my choice, and choice is great, right. But then I try to buy an air conditioner (cooling unit), and I find out that it is only compatible with your multi-dwelling cube house. Why? Because you have integrated some wonderful sensor technology into your buildings that the air conditioner manufacturer wants to take advantage of.

So now I have a choice: live in the house of my choice with no air conditioner, or live in your building with an air conditioner.

If you had designed your sensor system to be a separate piece, rather than integrating it directly into the building, I could buy any house I want and still have an air conditioner. But because of your design choices (as well as the choices of the air conditioning manufacturer), my choice of housing is limited or even eliminated. Tightly integrating the sensor system into the building may have been the technically best solution, but it has negative consequences in non-technical areas.

I hope you will give consideration to the non-technical as well as the technical when making your design decisions.

In case anybody's having trouble with the analogy:

The cube house is systemd.
The sensor technology is logind.
The air conditioner is pretty much any Gnome application.
The non-cube house is any other init system besides systemd.

-Rob
Lennart Poettering
2014-10-22 16:13:43 UTC
Permalink
Post by Rob Owens
Post by Lennart Poettering
We are always interested in technical feedback.
I have seen this comment several times from the systemd devs, and I
don't doubt it. But I think much of the criticism of systemd is not
technical. It has a more social/political nature, and I think you
should be interested in that feedback as well (even if it is
technically un-interesting).
Please, let's discuss this elsewhere. Let's keep a strict technical
focus on this ML!

Thank you for your understanding!

Lennart
--
Lennart Poettering, Red Hat
Rob Owens
2014-10-22 19:21:03 UTC
Permalink
----- Original Message -----
Post by Lennart Poettering
Post by Rob Owens
Post by Lennart Poettering
We are always interested in technical feedback.
I have seen this comment several times from the systemd devs, and I
don't doubt it. But I think much of the criticism of systemd is not
technical. It has a more social/political nature, and I think you
should be interested in that feedback as well (even if it is
technically un-interesting).
Please, let's discuss this elsewhere. Let's keep a strict technical
focus on this ML!
Thank you for your understanding!
Lennart
It is your ML, so I will oblige. But I think it is a mistake to not consider a broader view of your project than just the strictly technical aspects.

-Rob
Cristian Rodríguez
2014-10-23 00:27:11 UTC
Permalink
Post by Rob Owens
It is your ML, so I will oblige. But I think it is a mistake to not consider a broader view of your project than just the strictly technical aspects.
It is not *his* mailing list..but it is the place where *technical*
discussions about the systemd project take place. I can only speak for
myself but if you have been subscribed for a reasonable amount of time,
you will see the concurrence is mostly if not completely only in the
technical aspect and does not seem to have any interest on the topic of
philosophical wanking.
d***@wipro.com
2014-10-23 17:00:04 UTC
Permalink
One thing I would like to point out, on the project website there is NO mailing list for advocacy. The comment "this is for technical email only use a different ML" is for all purposes just a brush off. If the project would create an advocacy mailing list it would go a long way toward segregating the email.

-----Original Message-----
From: systemd-devel [mailto:systemd-devel-***@lists.freedesktop.org] On Behalf Of Cristian Rodríguez
Sent: Wednesday, October 22, 2014 7:27 PM
To: systemd-***@lists.freedesktop.org
Subject: Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Post by Rob Owens
It is your ML, so I will oblige. But I think it is a mistake to not consider a broader view of your project than just the strictly technical aspects.
It is not *his* mailing list..but it is the place where *technical* discussions about the systemd project take place. I can only speak for myself but if you have been subscribed for a reasonable amount of time, you will see the concurrence is mostly if not completely only in the technical aspect and does not seem to have any interest on the topic of philosophical wanking.



_______________________________________________
systemd-devel mailing list
systemd-***@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com
Tomasz Torcz
2014-10-23 17:14:22 UTC
Permalink
Post by d***@wipro.com
One thing I would like to point out, on the project website there is NO
mailing list for advocacy. The comment "this is for technical email only use a
different ML" is for all purposes just a brush off. If the project would
create an advocacy mailing list it would go a long way toward segregating the
email.
Who would participate in such list? I wouldn't, personally. I prefer
technical discussions.
--
Tomasz Torcz Morality must always be based on practicality.
xmpp: ***@chrome.pl -- Baron Vladimir Harkonnen
Reindl Harald
2014-10-23 17:19:51 UTC
Permalink
Post by Tomasz Torcz
Post by d***@wipro.com
One thing I would like to point out, on the project website there is NO
mailing list for advocacy. The comment "this is for technical email only use a
different ML" is for all purposes just a brush off. If the project would
create an advocacy mailing list it would go a long way toward segregating the
email.
Who would participate in such list? I wouldn't, personally. I prefer
technical discussions.
that is fine, but than "use a different ML" means "use one which we
don't read"
d***@wipro.com
2014-10-23 19:25:45 UTC
Permalink
That is fine and your choice. It doesn't seem like there is anything similar to an RFC process for systemd, so say that the "General Development and Discussion Mailing List" is changed to a new ML. The name of this list is changed to "Developer and Technical question" but remains the same list, systemd-***@lists.freedesktop.org, so that no one needs to re-subscribe.
There doesn't seem to be anything like an RFC process for systemd, so all the people who want to discuss changes in scope, changes in implementation strategy have a place to vent. If you want to listen in you can, if you don't you don't have to see the emails in this list.

-----Original Message-----
From: systemd-devel [mailto:systemd-devel-***@lists.freedesktop.org] On Behalf Of Tomasz Torcz
Sent: Thursday, October 23, 2014 12:14 PM
To: systemd-***@lists.freedesktop.org
Subject: Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Post by d***@wipro.com
One thing I would like to point out, on the project website there is
NO mailing list for advocacy. The comment "this is for technical email only use a
different ML" is for all purposes just a brush off. If the project would
create an advocacy mailing list it would go a long way toward
segregating the email.
Who would participate in such list? I wouldn't, personally. I prefer technical discussions.
--
Tomasz Torcz Morality must always be based on practicality.
xmpp: ***@chrome.pl -- Baron Vladimir Harkonnen

_______________________________________________
systemd-devel mailing list
systemd-***@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com
Dale R. Worley
2014-10-27 22:25:56 UTC
Permalink
Post by Lennart Poettering
Please, let's discuss this elsewhere. Let's keep a strict technical
focus on this ML!
I believe that you mean that outsiders are welcome here to provide
assistance to systemd as it has already been implemented. One
difficulty is that outsiders are usually not able to provide such
assistance.

It would be useful if there was a mailing list where outsiders could
come with problems -- "systemd does not implement what I need as it is
provided by the distro". I would expect such a mailing list to be
named "systemd-users". But no such list seems to exist. (And thus,
they show up in systemd-devel.)

This leaves users with the sense that they are expected to use systemd
as it is provided, and it makes it hard for them to customize systems
that do what they need. This reminds them of Microsoft products and
makes them unhappy.

Dale
Lennart Poettering
2014-10-27 23:13:46 UTC
Permalink
Post by Dale R. Worley
Post by Lennart Poettering
Please, let's discuss this elsewhere. Let's keep a strict technical
focus on this ML!
I believe that you mean that outsiders are welcome here to provide
assistance to systemd as it has already been implemented. One
difficulty is that outsiders are usually not able to provide such
assistance.
It would be useful if there was a mailing list where outsiders could
come with problems -- "systemd does not implement what I need as it is
provided by the distro". I would expect such a mailing list to be
named "systemd-users". But no such list seems to exist. (And thus,
they show up in systemd-devel.)
Well, systemd is a suite of components that people build OSes from. As
such it isn't really an app you install on top of your OS, it's more a
toolset for distro and device builders. Now, if end users have
questions about details how they can uses these devices and distros,
then I figure they should always contact the manufacturers of these
devices, and the distro developers first.

Or in other words: we are not the final product that people should
interface with, we just provide a set of components where other people
can build final products out, and by doing so they also need to take
the responsibility for providing a first level of help for it.

Now, of course, the more technical things get, sometimes its better to
ask upstream, and we currently do not have a separate ML for questions
like that, we use systemd-devel for that, which of course is primarily
used for development. But I think it's still OK that way, as the
amount of technical user question we get is still managable, and by
not making the distinction between the group of developers and the
group of users too strict I guess our community can only win.

systemd-devel is the place for *technical* discussions only though. If
you have a technical point to make, a technical question to ask, a
patch to send, a technical suggestion to make, a technical feature
request to post, it's the right place.

However, it's not the place for UNIX philosophy discussions, about
discussions what we should be and what we shouldn't be. Now we could
open a new ML for that philosphical kind of stuff, but I have serious
doubts that many of us developers would subscribe there, hence I think
it would be better to do those discussions elsewhere, maybe on blogs,
g+ posts, on twitter, on lwn, on reddit... The discussions are being
had there anyway, and that's OK that way. Some of the systemd
developers scan and post on these forums anyway[1], regularly, hence I
really don't see the need for a new ML.

Lennart

[1] I scan and sometimes post on LWN. I think Tom does the same on g+
and lwn. Daniel on twitter, and so on...
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2014-10-27 23:23:54 UTC
Permalink
Post by Dale R. Worley
Post by Lennart Poettering
Please, let's discuss this elsewhere. Let's keep a strict technical
focus on this ML!
I believe that you mean that outsiders are welcome here to provide
assistance to systemd as it has already been implemented. One
difficulty is that outsiders are usually not able to provide such
assistance.
No really, people do feature requests here and on the bug trackers all
the time [1].

Nevertheless, systemd is a low level compenent, and not really
directed at *users* as such, more at os developers, packagers, etc.
So the distinction between "development" and "use" is not clearly
cut. Questions and bug reports often lead directly to changes in
the codebase. Creating a split into two lists would only slow
things down here.

Creating a separate systemd-users list was discussed, but who would
answers the questions there? If you expect the developers do it,
then there isn't much difference than simply answering those questions
on -devel. If you expect other people to do it, then wiki style
distribution-specific documentation is better in the long run,
since systemd is a fast moving target and the best practice often
changes over time.

What I think you're really thinking about is "systemd-advocy" to
discuss lofty ideals and deep motivaitions. But nobody has time for
that ;)

[1] https://bugs.freedesktop.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=PLEASETEST&component=general&known_name=systemd%20RFEs&list_id=485720&product=systemd&query_based_on=systemd%20RFEs&query_format=advanced&resolution=---&short_desc=^RFE&short_desc_type=regexp
Post by Dale R. Worley
It would be useful if there was a mailing list where outsiders could
come with problems -- "systemd does not implement what I need as it is
provided by the distro". I would expect such a mailing list to be
named "systemd-users". But no such list seems to exist. (And thus,
they show up in systemd-devel.)
This leaves users with the sense that they are expected to use systemd
as it is provided, and it makes it hard for them to customize systems
that do what they need. This reminds them of Microsoft products and
makes them unhappy.
That mostly applies to people who actually don't use systemd and are
commenting from the peanut gallery. Actual *users* when they are unhappy
are unhappy about bugs.

Zbyszek
Dale R. Worley
2014-10-28 15:28:38 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
That mostly applies to people who actually don't use systemd and are
commenting from the peanut gallery. Actual *users* when they are unhappy
are unhappy about bugs.
That is not entirely true. I'm a user (because systemd is in Fedora
19), and I've complained that if I mark an /etc/fstab entry as
"nofail", some part of systemd will wait *forever* to see if the
partition becomes available, whereas the behavior that I want (which
was provided in earlier Fedora releases) is that once the system
gets to the point of user logins, it will give up on automatic booting
(and leave it to manual control).

I've not received any useful feedback on how to customize my system to
behave that way, and no indication that there is any intention to add
it as a feature.

So it is clear that this is not a "bug", as it is the behavior
intended by the designers, but I'm still not happy.

Dale
Daniele Nicolodi
2014-10-28 15:34:18 UTC
Permalink
Post by Dale R. Worley
Post by Zbigniew Jędrzejewski-Szmek
That mostly applies to people who actually don't use systemd and are
commenting from the peanut gallery. Actual *users* when they are unhappy
are unhappy about bugs.
That is not entirely true. I'm a user (because systemd is in Fedora
19), and I've complained that if I mark an /etc/fstab entry as
"nofail", some part of systemd will wait *forever* to see if the
partition becomes available, whereas the behavior that I want (which
was provided in earlier Fedora releases) is that once the system
gets to the point of user logins, it will give up on automatic booting
(and leave it to manual control).
I've not received any useful feedback on how to customize my system to
behave that way, and no indication that there is any intention to add
it as a feature.
So it is clear that this is not a "bug", as it is the behavior
intended by the designers, but I'm still not happy.
What you write above is not entirely true either:

On 22/10/14 20:55, Lennart Poettering wrote:> On Fri, 12.09.14 15:25,
Post by Dale R. Worley
Post by Zbigniew Jędrzejewski-Szmek
Step back, and define exactly what it is you actually need^Wwant to do.
For a certain entry in /etc/fstab (which will in practice always have
the option "nofail"), if the device is not available "until booting is
over" (which I'm willing to denote with a specified period of time),
after that, it will not be automatically mounted if it becomes
available.
This is currently not available, and it sounds very special and racy
to support it upstream I think. Sorry!
If you want to hack something up like this, I'd recommend writing a
timer unit/cronjob that creates a file $PATH after $SECONDS after
boot. Then, add
Post by Dale R. Worley
a drop-in file to /etc/systemd/system/$MOUNTUNIT.d/foobar.conf, and
[Unit]
ConditionFileExists=!/the/file/you/create
That way the mount unit will always be queued, but will actually be
conditionalized out $SECONDS after boot, if you follow what I mean.
Hope this is helpful.
Lennart
Cheers,
Daniele
Lennart Poettering
2014-10-28 16:05:37 UTC
Permalink
Post by Dale R. Worley
Post by Zbigniew Jędrzejewski-Szmek
That mostly applies to people who actually don't use systemd and are
commenting from the peanut gallery. Actual *users* when they are unhappy
are unhappy about bugs.
That is not entirely true. I'm a user (because systemd is in Fedora
19), and I've complained that if I mark an /etc/fstab entry as
"nofail", some part of systemd will wait *forever* to see if the
partition becomes available, whereas the behavior that I want (which
was provided in earlier Fedora releases) is that once the system
gets to the point of user logins, it will give up on automatic booting
(and leave it to manual control).
I have already replied to this, and pointed out that such a scheme is
inherently racy, and that this is something we will unlikely support
natively in systemd. Sorry for that.

And please don't make this a "but it worked fine in sysvinit!" thing,
because it was racy there as well.
Post by Dale R. Worley
I've not received any useful feedback on how to customize my system to
behave that way, and no indication that there is any intention to add
it as a feature.
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024325.html

I am sorry, if this reply doesn't make you happy, but I guess we will
not be able to mke everybody happy. But please be fair enough to admit
that you did get a response from us, and a clear explanation that we
will not support this upstream, and why we won't do so.
Post by Dale R. Worley
So it is clear that this is not a "bug", as it is the behavior
intended by the designers, but I'm still not happy.
I am sorry for that,

Lennart
--
Lennart Poettering, Red Hat
Jan Alexander Steffens
2014-10-28 16:16:38 UTC
Permalink
Post by Lennart Poettering
Post by Dale R. Worley
That is not entirely true. I'm a user (because systemd is in Fedora
19), and I've complained that if I mark an /etc/fstab entry as
"nofail", some part of systemd will wait *forever* to see if the
partition becomes available, whereas the behavior that I want (which
was provided in earlier Fedora releases) is that once the system
gets to the point of user logins, it will give up on automatic booting
(and leave it to manual control).
I have already replied to this, and pointed out that such a scheme is
inherently racy, and that this is something we will unlikely support
natively in systemd. Sorry for that.
I think the actual issue here is the behavior of Type=idle, which delays
the gettys for an annoying amount of time.

Maybe launching the getty should shut off boot messages instead. Or maybe
this should happen after a configurable IdleTimeout instead of having
Type=idle always wait until end of transaction.
Zbigniew Jędrzejewski-Szmek
2014-10-28 16:48:39 UTC
Permalink
Post by Jan Alexander Steffens
Post by Lennart Poettering
Post by Dale R. Worley
That is not entirely true. I'm a user (because systemd is in Fedora
19), and I've complained that if I mark an /etc/fstab entry as
"nofail", some part of systemd will wait *forever* to see if the
partition becomes available, whereas the behavior that I want (which
was provided in earlier Fedora releases) is that once the system
gets to the point of user logins, it will give up on automatic booting
(and leave it to manual control).
I have already replied to this, and pointed out that such a scheme is
inherently racy, and that this is something we will unlikely support
natively in systemd. Sorry for that.
I think the actual issue here is the behavior of Type=idle, which delays
the gettys for an annoying amount of time.
Maybe launching the getty should shut off boot messages instead. Or maybe
this should happen after a configurable IdleTimeout instead of having
Type=idle always wait until end of transaction.
You mean like the code in execute.c does?

#define IDLE_TIMEOUT_USEC (5*USEC_PER_SEC)
...
r = fd_wait_for_event(idle_pipe[0], POLLHUP, IDLE_TIMEOUT_USEC);

if (idle_pipe[3] >= 0 && r == 0 /* timeout */) {
/* Signal systemd that we are bored and want to continue. */

;)

Zbyszek
Pacho Ramos
2014-10-28 19:52:16 UTC
Permalink
El mar, 28-10-2014 a las 17:05 +0100, Lennart Poettering escribió:
[...]
Post by Lennart Poettering
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024325.html
Looks interesting. Have you think in having some kind of wiki or page
listing this kind of "tricks" to solve things like that. That way we
prevent people from applying many different solutions that could have
different drawbacks and also have them in a place a bit more easily
accessible

Thanks a lot

Dale R. Worley
2014-10-22 19:54:51 UTC
Permalink
Post by Lennart Poettering
We are always interested in technical feedback.
We are not very interested in FUD mails that tell us how we'd "force"
people, how we'd behave like microsoft and so on. That's not useful,
that's pretty much only hurtful.
I haven't read this full thread, and it probably isn't useful for me
to do so. But it seems that the first question to be answered by the
developers is:

Are they concerned that uptake is not as fast as they'd like?

and if the answer to that is Yes, then:

Would they like to hear feedback from users as to what they
might do about it?

There's no point in jabbering about it unless the answer to the second
question is Yes.

Dale
Lennart Poettering
2014-10-22 20:38:01 UTC
Permalink
Post by Dale R. Worley
Post by Lennart Poettering
We are always interested in technical feedback.
We are not very interested in FUD mails that tell us how we'd "force"
people, how we'd behave like microsoft and so on. That's not useful,
that's pretty much only hurtful.
I haven't read this full thread, and it probably isn't useful for me
to do so. But it seems that the first question to be answered by the
Are they concerned that uptake is not as fast as they'd like?
No. We are not concerned. Within three years all most major distros opted
for systemd as default. That's way more and way quicker than what we
could ever hope for.
Post by Dale R. Worley
Would they like to hear feedback from users as to what they
might do about it?
Yes, we always ask for good feedback. Much of what systemd is today is
the result of getting and incorporating feedback.

However, we are not really interested in constantly repeated claims of
"forcing" and "being like microsoft", because that's neither original,
nor true, nor interesting, nor technical, nor relevant.

Also, note that while we care a lot for useful feedback we will not
implement everything people ask for, and even deny patches. Saying
"no" to patches and suggestions is necessary to keep the project on
track. We will continue to do so. If figure by average though, we
probably implement two suggestions we got through feedback for every
one suggestion we refuse. And if we say "no" to a suggestion or patch
you'll at least get an explanation why.

hence, please keep the feedback coming, we appreciate it, but please
stay relevant, and please don't be put off if we say "no" to
something. if we say "no" to some thing, try again with something
else.

Thanks,

Lennart
--
Lennart Poettering, Red Hat
Martin Steigerwald
2014-10-21 08:45:13 UTC
Permalink
Hi Rob,
Post by Rob Owens
----- Original Message -----
Post by Martin Steigerwald
Heck, I started a thread here and then didn´t manage to take time to carefully
read it and reply here and there as I see fit. But I challenged people on
debian-user mailing list to constructively voice their concerns upstream,
and even pointed them to this mailing list. As far as I saw *no one* of
the posters in debian-user took up on that challenge. Which I view as a
pity. Cause now actually you invited constructive feedback. I wonder
whether I may forward your answer to debian-user so they see your
statement of inviting constructive feedback.
I am here from debian-user, due to Martin's suggestion. So now that he's
calling me out, I guess I'll post my questions :)
For the record, I'm a sysadmin and not a developer. I imagine my questions
and opinions will reflect that.
Thank you for voicing your concerns as one of the many users who where not so
hesitant to voice their concerns on the debian-user mailing list.
Post by Rob Owens
Post by Martin Steigerwald
Here the feedback I read over and over again is that you and RedHat
basically forced the systemd decision onto other distributions. While I
do not see how you actually can be powerful enough to do that, as we live
in a free will zone. I do see tendencies that more and more stuff
*depends* on systemd cause it needs features only available there.
On of the most talked on things on debian-user is the logind thing. GNOME
actually depends on it, as far as I know. While KDE in Debian still uses
On Debian, I came across an unusual dependency. Installing a cd burner
(brasero) required me to change my init system to systemd. Sounds kind of
brasero -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd -> systemd-sysv
I really find this kind of chain quite ridiculous.

But if its breakable at least as Martin told… still.

I think its important to make sure that installing brasero does not
accidentally switch a sysvinit system to systemd. As it would be the least a
user would expect here and from common sense it does not even make sense. It
may make sense technically as explained, but from a user and sysadmin point of
view it does not make any sense at all and is quite disruptive.

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Martin Steigerwald
2014-10-05 10:51:33 UTC
Permalink
Post by Lennart Poettering
(What I didn't expect though is how awful the Linux community can
actually be. That people collect Bitcoins to hire a hitman on me, that
people start petitions to make me stop working, and all that other
really hateful, personal stuff is really apalling. I guess I have a
thick skin, because I don't care too much, but jeezus christ, it's
really disgusting sometimes.)
I just filed an abuse complaint about some personal attacks to you and systemd
supporters in general with Debian listmasters. They were way out of bounds of
netiquette. I am not willing to tolerate such abuse.

Also went to LKML, but I am not aware of any netiquette reporting for it.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Martin Steigerwald
2014-10-21 08:37:25 UTC
Permalink
Post by Martin Steigerwald
Hello!
I know this is a daring post.
I just have one question. In the light of
http://boycottsystemd.org/
http://uselessd.darknedgy.net/
http://undeadly.org/cgi?action=article&sid=20140915064856
in the light of
Debian Bug report logs - #727708
tech-ctte: Decide which init system to default to in Debian.
https://bugs.debian.org/727708
Debian Bug report logs - #746715
the foreseeable outcome of the TC vote on init systems
https://bugs.debian.org/bug=746715
in the light of the ongoing discussions on linux-kernel, debian-devel,
debian- user and other mailing lists more than some dozens threads
In my long years of using Debian and also doing some packages for it in the
last years I never saw that any introduced changed caused a serious "we may
need to fork" like announcement like this:

http://debianfork.org/

Also the upcoming GR decision about whether to require that packages may not
depend on PID 1 it refers to.

I think I never saw that kind of uproar in Debian. In my view its worrying and
damaging. And I think it points at a real problem.

There is a dire problem with the acceptance of systemd in Debian (and not only
there). In Debian this is not only with users, but also with developers.

Wherever I look systemd triggers a split into "pro" and "contra". Even here at
work. I still use it, I test it, it seems to work. But I am concerned. Some
co-workers dislike it highly.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Simon McVittie
2014-10-21 11:03:20 UTC
Permalink
Post by Martin Steigerwald
In my long years of using Debian and also doing some packages for it in the
last years I never saw that any introduced changed caused a serious "we may
need to fork" like announcement
I've seen several instances of Debian people *actually* forking it, and
that isn't one of them (at least, not yet). There are currently 63
derivatives listed on <https://wiki.debian.org/Derivatives/Census>,
variously booted via all the major init systems, and there are more that
are not listed on that page.

Perhaps the most prominent example is Ubuntu, which basically started as
a fork that would iterate faster and focus on ease-of-use, wandered off
into various subsequent goals from there, and incidentally funded
development of a new init system along the way. Another interesting
derivative is Tanglu, which is desktop-focused and has adopted systemd
much more aggressively than Debian.

Fundamentally, what needs to happen, if people want a version of Debian
that boots with LSB/sysvinit scripts to remain available indefinitely,
is for someone to do the work. That is all. They can do the work in
Debian or in a fork, whichever, but if the work is not done, the goal
will not be achieved. At the moment, I'm seeing a lot of noise, and a
lot of suggestions that the people who do the work should be coerced
into doing different work (which is unlikely to succeed in a volunteer
project), but a relatively small amount of actual software development
or maintenance.

S
Continue reading on narkive:
Loading...