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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel