[systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Martin Steigerwald
Martin at lichtvoll.de
Sun Oct 5 04:44:35 PDT 2014
Hi Jóhann,
Am Sonntag, 21. September 2014, 22:15:32 schrieb Jóhann B. Guðmundsson:
> On 09/21/2014 01:31 PM, Martin Steigerwald wrote:
> > 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.
> > 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.
> 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.
> 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.
> 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
> 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.
> 5. Design for simplicity; add complexity only where you must.
Well…
> 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".
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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
More information about the systemd-devel
mailing list