Why systemd is the way forward: technical arguments

[reinob]

^That was definitely not a technical describtion, but this is what I think about the situation.
Want technical? Here it is:

echo "----------------------------------------------------------------"
echo "Initialized build system. For a common configuration please run:"
echo "----------------------------------------------------------------"
echo
echo "./configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs --enable-kdbus $args"

-g - include all debugging symbols
-O0 - disable ALL compiler-level optimisations
"trapv" would need a lot more explanations, but the conclusion is:
This is not even Alpha software, this is totally experimental piece of crap. I would never even dare to release a software of which I'm not sure that it can be safely used in non-debug mode. This a joke, this alone is a proove that Debian stabilty has been fucked up...

Where did you find this? I grep'd for "trapv" in systemd-215 source (from jessie). No hits.
Did you find this in a debian-provided package or upstream? (Debian does include a number of patches).

[TobiSGD]

OK, I read that mailing list post and the follow ups. They explain why starting long running programs is not supported by udev and how to do it properly. If anyone still tries it and fails I will not blame it on the developers.
It would only be a bug if they would support it and it would fail, but not if it is not supported at all.

It's a regression, 'cause udev in wheezy supports it. --> bug.

So when someone removes a feature it is automatically a bug? Then GNOME 3 in Wheezy is a regression, since it doesn't support gnome-panel applets, while GNOME 2 in Squeeze did.
Get real, if you use something that is not supported and it fails don't blame the developers.

[edbarx]

Excuse me for posting some fiddling with systemd, but it is new to me... This is SID, the ADHD 'naughty' child!

Code: Select all

edbarx@sid-inst:~$ systemctl status udev.service
● systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static)
   Active: active (running) since Wed 2014-11-26 10:56:06 UTC; 3h 31min ago
     Docs: man:systemd-udevd.service(8)
           man:udev(7)
 Main PID: 166 (systemd-udevd)
   CGroup: /system.slice/systemd-udevd.service
           └─166 /lib/systemd/systemd-udevd

I am noticing that with sysvinit, i.e. /sbin/init as PID 1, programs took longer to load, whereas with systemd as PID 1, the same programs are taking far less time to load.

For instance, loading a C code file in medit took about two seconds with sysvinit as PID 1. With systemd as PID 1, the same file loads instantly!

Memory consumption at the time of posting:

Code: Select all

edbarx@sid-inst:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          1940       1080        859         57         68        632
-/+ buffers/cache:        379       1561
Swap:         3071          0       3071

Processor load:

Code: Select all

Tasks: 102 total,   2 running, 100 sleeping,   0 stopped,   0 zombie
%Cpu(s): 13.0 us,  1.5 sy,  0.0 ni, 84.9 id,  0.6 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   1987132 total,  1113604 used,   873528 free,    70620 buffers
KiB Swap:  3145724 total,        0 used,  3145724 free.   651876 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
 4886 edbarx    20   0  792372 265428  61884 S   8.6 13.4   0:29.96 iceweasel   
  465 root      20   0  197584  31712  14904 S   3.0  1.6   7:32.52 Xorg        
 4770 edbarx    20   0  393988  23792  19080 S   2.7  1.2   0:01.38 xfce4-term+ 
 1515 root      20   0       0      0      0 S   0.3  0.0   0:06.87 kworker/0:0 
 4950 edbarx    20   0   23992   2956   2532 R   0.3  0.1   0:00.02 top         
    1 root      20   0   28856   4988   3112 S   0.0  0.3   0:00.90 systemd     
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd    
    3 root      20   0       0      0      0 S   0.0  0.0   0:03.97 ksoftirqd/0 
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:+ 
    7 root      20   0       0      0      0 S   0.0  0.0   0:04.28 rcu_sched  

[twoflowers]

OK, I read that mailing list post and the follow ups. They explain why starting long running programs is not supported by udev and how to do it properly. If anyone still tries it and fails I will not blame it on the developers.
It would only be a bug if they would support it and it would fail, but not if it is not supported at all.

It's a regression, 'cause udev in wheezy supports it. --> bug.

So when someone removes a feature it is automatically a bug? Then GNOME 3 in Wheezy is a regression, since it doesn't support gnome-panel applets, while GNOME 2 in Squeeze did.
Get real, if you use something that is not supported and it fails don't blame the developers.

"ls" deletes files 'cause it's cool. feature or bug? generally any undocumented change isn behaviour is a bug.

[confuseling]

If it's undocumented sure, it's a bug - possibly in the documentation.

You're not really trying to persuade me that a) no interfaces should ever be deprecated or b) the old way of doing it is better, though.

[TobiSGD]

[

"ls" deletes files 'cause it's cool. feature or bug? generally any undocumented change isn behaviour is a bug.

If ls deletes a file this is clearly a bug, because ls isn't intended in any circumstance to delete files. Just as udev is intended to react to hardware events with making changes to the system, for example with telling the service manager to start the backup service when a certain device is plugged in.
Also, they did not change this behavior "'cause it's cool", this behavior is inherent to how systemd uses cgroups to manage services.
It might have been a bug if this behavior would come up with sysvinit, but systemd is not sysvinit and for systemd this behavior is correct. Expecting systemd to behave exactly as sysvinit is kind of weird, what would be the point of systemd if it would be an exact sysvinit clone?

[reinob]

You're not really trying to persuade me that a) no interfaces should ever be deprecated or b) the old way of doing it is better, though.

One of my complaints about systemd is that its development model doesn't care about maintaining compatibility with previous versions. This may be OK as long as the program is in development, but once it is adopted by a "stable" distribution, then one'd need to make sure that the rest of programs interfacing with the init system (a la update-rc.d, etc.) should continue to work even if the init system is updated.

The Linux kernel, i.e. Linus, has a strict policy where any regression in userspace is treated as a bug in the kernel(-patch). This is something that systemd (or any sane alternative thereof) should also have to adapt in order to be successful.

Look at Windows. It's success comes mainly from maintaining compatibilty with all previous versions, including MS-DOS, which itself was succesful because it was sort-of compatible with CP/M (call 0005h et al).

Sysvinit, in its current Debian form, is IMHO a piece of hacky crap that just happens to barely work. Systemd has gotten a lot of things right, at least in the underlying idea. As long as the distribution maintainers don't have a lot of work to do (patching around API/ABI breaks) nobody will complain and everybody will be happy with it.

Just like the kernel. Distributions patch this or that, but vanilla kernel works just fine and nobody (userspace and users themselves) worries about whatever happens inside the kernel. If the kernel kept breaking compatibility then people (distributions) would perhaps think of moving to BSD or whatever.

[confuseling]

I agree with that. It'd also do a lot to quell the RedHat conspiracy / monolith fears - as soon as its external interfaces stabilise, it's forkable, and if its internal interfaces stabilise too so much the better, because people can cherrypick / reimplement parts of it...

[twoflowers]

Sprry, but "not stabilised" == "alpha".

[confuseling]

Presumably you've got examples of recent problematic changes in its external interfaces then.

[twoflowers]

This does not lead anywhere. Like in GNOME any bug is called feature. What's there left to debate? May you live in interesting times

[Bulkley]

So far, I'm not finding any more problems with my transition into Jessie and Systemd than I have had with any previous dist-upgrade. One thing that I could not do (as I suspected) is break it up into bite sized chunks; with Systemd it is all at once. (rest assured, I did it CLI from a console - no GUI to muck it up) Control is different; thus, a learning curve.

[buntunub]

So far, I'm not finding any more problems with my transition into Jessie and Systemd than I have had with any previous dist-upgrade. One thing that I could not do (as I suspected) is break it up into bite sized chunks; with Systemd it is all at once. (rest assured, I did it CLI from a console - no GUI to muck it up) Control is different; thus, a learning curve.

Systemd has been in development for a long time now. If it did not work then it would not have adoption amongst the major distro's, so it works fine, or at least some versions of it does. Besides, nobody in the anti-Systemd camp (that knows what they are talking about anyway) is complaining about Systemd not working as intended. They are complaining that Systemd is working as intended.

[schnuller]

People seem to try to tell us that Debian uses an init system which works at all.
Damnit: I assumed all the time it wouldn't even boot.

Technical argument for systemd:
1) At least it works at all.

upstart, runit, openrc, sysvinit and what not don't work, of course. That *is* the main problem with all other init systems.

[TobiSGD]

I have installed Debian 7.2 and dragged it up through jessie & sid and it still allows me a CLI-only login.

. . . and CLI reboot and poweroff. https://wiki.archlinux.org/index.php/al ... o_shutdown

Code: Select all

$ systemctl poweroff
$ systemctl reboot

As with many things, ArchWiki is way ahead of Debian with documentation.

The more i think about it, the better the idea sounds.
Mainly on multi-user machines, with people from other places connecting via ssh, etc. (argh ... does not work from remote. How lame is that? Add it).

rkhunter considers the ability to shutdown via keyboard-shortcut as a "problem". iirc.
But hey: it is a feature, it offers comfort. Why not?
I wouldn't bother at all if the machine shuts down while i am busy doing my work (Let it happen three times each day and people will ove it).

I probably missed the point.

This bothered me a bit so I searched for information on it and found this in the ArchWiki:
https://wiki.archlinux.org/index.php/Sy ... management

polkit is necessary for power management as an unprivileged user. If you are in a local systemd-logind user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password.
Shut down and reboot the system:
$ systemctl reboot
Shut down and power-off the system:
$ systemctl poweroff
Suspend the system:
$ systemctl suspend
Put the system into hibernation:
$ systemctl hibernate
Put the system into hybrid-sleep state (or suspend-to-both):
$ systemctl hybrid-sleep

So you don't need to worry about the machine shutting down while you are working at it remotely.

[schnuller]

Isn't that awesome?
systemd users finally can shutdown their system. A technical revolution ...
I for one simply kick against the left side of the computer, in a Bruce Lee style.

Weird that you checked it at all. The whole idea would sound so plain mad that anyone would expect something like that only from systemd, it seems ....
(around the same lines is the "joke" by Poettering to implement libreoffice into systemd. I was not able to figure out if he was serious about it, but i sure could imagine it).

[thanatos_incarnate]

The shutdown behaviour with policykit was there before, even without systemd.
I'm not sure why that is suddenly an issue or reason to spew bile again.

[edbarx]

I would like to comment about systemd's source organisation and style.

The source's tree is logically organised into directories, while the coding style clearly shows, that whoever wrote that code, is a very meticulous person.

It is not a secret that, the police use caligraphy experts in their investigations, which means caligraphy, uncovers one's character. Therefore, the same can be said about a programmer's source, which is a programmer's 'caligraphy'.

Since, my first glimpse at Poettering's et al code, I had these impressions.
-------------------------------------------

Many members of these fora may be astonished at my U-Turn, but, my very first inspections of systemd's code, immediately gave me the impression, that something in my standing with respect to the adoption of systemd in Debian, did not resonate well logically.

Now, to add insult to injury, at debianfork, it was decided that they form the same type of government Debian has! My standing about this is: if one rejects a form of government, one doesn't accept to take part in any government of that form. debianfork, criticised that Debian didn't allow for users' participation in the decision making mechanism, while they are adopting the same policy.

My second reason for quitting debianfork, is I wanted to contribute in coding. I made it clear from the very beginning of my conversations on debianfork, that I am not formally qualified to code. However, it is not the first time that university students ask for my assistance to help them in their assignments and dissertations, therefore, I have enough education to educate myself if I need to further improve my coding ability. Last time a student asked me to help her to code a compiler. Both of us consulted books and discussed the methodology, with the end result being, a tokenizer and compiler. The task was to create a compiler for a fictitious programming language. So, we had to study how to make sure the tokens were in the correct syntactical order, and report errors where appropriate. We used several recursive calls to syntactically check expressions, sub-expressions, statements, etc.

However, the elders at debianfork, thought otherwise of my ability. They assumed I use 'words I do not understand', probably, like a twelve year old who wants to impress his peers! Yes, I do not hold degrees in programming, but I can cope as my education level enables me to study on my own to further improve my skills. Denying this fact, is adding insult to injury, and is reminiscent of sheer elitism.

This is why I quit. Hypocrisy is not among my values.

[schnuller]

Not that the character of someone who writes code would have anything to do with the problems,
but many would not agree with your conclusion:
https://en.wikipedia.org/wiki/Systemd#Reception

Pretty sure that i read somewhere (Gentoo wiki) that a big part of systemd is uncommented (That really isn't what bugs me, but it isn't a sign of being a meticulous programmer).

I am not astonished.

[reinob]

Presumably you've got examples of recent problematic changes in its external interfaces then.

Not many, but in my experience with systemd there's been a number of WTF-events, where I tried doing something according to the official documentation and it didn't work, or I tried to do something according to the Arch Wiki but didn't work in Debian, etc.

One concrete examples (if I can remember well) was "systemctl mask", which didn't work in debian so you had to use the symlink method.

Also with systemd-networkd I've had to change config files a couple of times. The "[DHCP]" section in a .network file was previously split into "[DHCPv4]" and "[DHCPv6]". The "MTUBytes" option in a .netdev file seems to be ignored, but will perhaps be honored at some point in the future. The bonding mode (section "[Bond]") is also ignored because it is set when the module is loaded and systemd doesn't pass the option to the module, so you have to tweak in /etc/modprobe.d.

This is more a problem with the documentation and/or downstream packaging, but as long as implementation and documentation are not aligned the situation is a bit messy and unstable. As I said, this is OK for now (jessie is still testing, and Arch is AFAIK not claimed to be stable, don't know about Fedora). But once Jessie becomes Stable I'd expect a consistent documentation of whatever is implemented (or not) in systemd.