Why systemd is the way forward: technical arguments

[confuseling]

Right... that sounds a lot to me like a higher level interface superseding a lower level one.

Which could be a good or a bad thing, but certainly isn't a problem on principle.

[tomazzi]

- extensions for systemd (like DNS resolved daemon - it lacks of even most basic protection <not to mention RFC> against cache poisoning) are completely broken, untested piece of crap

Seriously? You use the state of a part of systemd that is in early development and discouraged to use in the current state by its developer as indicator for the quality of all parts of the tree besides the core components? Way to go!
http://lwn.net/Articles/622445/

Yes I'm preparing my way to go (or perhaps emergency exit) ... seriously.
...
My point is that there are generally 2 kinds of projects:
(a) Developer knows the old truth, that is: "if one claims, that his code is free from bugs, then it only means, that he haven't tested it fully".
Such developers are saying (on the blogs or project' web pages) :
"Hello guys, I think I have solution for *this*, the code is experimental and any suggestions/patches are welcome."

(b) I'm the master of disaster - my code is the only solution, and my company is using/selling it to its clients. Clients are morons, because they want a proove that my perfect code is perfect - so You, as the poor users of *a distro* are unfortunately important at the moment - take my code and use it. All the bug reports will be ignored anyway...

Systemd is using development model B.
And in such situation, I will say: You are dumb and arrogant, go F***CK your self. If Your code is so perfect, then why it smells like crap?

^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...

Yes, systemd infroduces some really nice features, but even the authors are not sure if it's safe...

systemd should not be included as a default in such a serious distro like Debian...

Anyway, the battle is lost.

Fortunatelly, I can handle my OS in a way I want - I'm not necessarily sentenced to take that crap upstream version of systemd

Eventaully, when I test my patches I will release a fork, somewhere on github or maybe even sourceforge...

[confuseling]

Two obvious questions:

1) Does it compile / run without those options?

2) Will it ship with them in Stable?

[TobiSGD]

Two obvious questions:

1) Does it compile / run without those options?

2) Will it ship with them in Stable?

If you mean the security options, I don't know if it can be compiled without them, but AFAIK using them is optional.
If Jessie will make use of them, I don't know, but as it seems they are definitely present in systemd 215.

[confuseling]

So is that unusual? Are there many programs in Testing with debugging symbols / no optimisation?

[TobiSGD]

So is that unusual? Are there many programs in Testing with debugging symbols / no optimisation?

Sorry, I don't get the question. Is what unusual? And where come debugging symbols and optimization in the mix?

[confuseling]

I presume those are the build options specified in the version in Jessie? Is it unusual for a package in Testing to have such options?

(apologies for not checking this myself - my router is dead, and checking on my phone sounds complicated...)

What I'm getting at is the implication of tomazzi's post seems to be that packages shouldn't have those options. I have no idea if that's true...

[schnuller]

iirc -g is usually not used, only for debugging, as the resulting binary (or whatever the name of that thing created after running gcc) will be way bigger. Once debugging is done and you found the problem, you compile without said option.

Gotta say i lost track somewhere in this thread (cause lots of things i don't understand, not as it's a confusing thread).

Thing is: I don't want to think about such. I want to trust the OS i use.

More clear: I have no clue myself. Doing a bit of chat, in the middle of the night.

[Bulkley]

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.

[edbarx]

-ftrapv
This option generates traps for signed overflow on addition, subtraction, multiplication operations.

As I see it, there are two explanations for using this compiler option:
i) either the code is not written so that it makes sure there is no overflow
ii) or the publishers recognize they have a complex project and want to play as safe as possible

[schnuller]

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.

[twoflowers]

Please provide a bug number, I definitely want to look at that. One question though, wouldn't it be the correct way to start your backup process as a systemd service (probably one-shot type) instead of starting the program directly from udev?

see http://lists.freedesktop.org/archives/s ... 07390.html - the bug was still here last week, a college ran into it and got a bloody nose.

There is no "correct way" to do things with stupidd as stupidd is uttery broken

[edbarx]

My actual trial of systemd has started. This is SID, reknown for breakages. The proof of the pudding is in the eating, they say. Let us see what happens.

Code: Select all

root@sid-inst:/home/edbarx# history | tail
  492  ifup wlan0
  493  apt-get update
  494  apt-get upgrade
  495  exit
  496  ifup wlan0
  497  apt-get install systemd
  498  apt-get remove systemd-shim
  499  apt-get remove sysvinit
  500  reboot

Code: Select all

root@sid-inst:/home/edbarx# pstree
systemd-+-acpid
        |-at-spi-bus-laun-+-{dconf worker}
        |                 `-{gdbus}
        |-cron
        |-2*[dbus-daemon]
        |-dbus-launch
        |-2*[dhclient]
        |-login---bash---startx---xinit-+-Xorg
        |                               `-sh---xfce4-session-+-Thunar
        |                                                    |-xfce4-panel-+-iceweasel-+-2*[{Analysis Helper}]
        |                                                    |             |           |-{Cache I/O}
        |                                                    |             |           |-{Cache2 I/O}
        |                                                    |             |           |-{Cert Verify}
        |                                                    |             |           |-{DNS Resolver #1}
        |                                                    |             |           |-{DNS Resolver #2}
        |                                                    |             |           |-{DNS Resolver #3}
        |                                                    |             |           |-3*[{DOM Worker}]
        |                                                    |             |           |-{Gecko_IOThread}
        |                                                    |             |           |-{HTML5 Parser}
        |                                                    |             |           |-{Hang Monitor}
        |                                                    |             |           |-{ImageDecoder #2}
        |                                                    |             |           |-{JS GC Helper}
        |                                                    |             |           |-{JS Watchdog}
        |                                                    |             |           |-{MediaManager}
        |                                                    |             |           |-{Network Seer}
        |                                                    |             |           |-{Proxy R~olution}
        |                                                    |             |           |-{SSL Cert #3}
        |                                                    |             |           |-{Socket Thread}
        |                                                    |             |           |-{StreamTrans #21}
        |                                                    |             |           |-{Timer}
        |                                                    |             |           |-{URL Classifier}
        |                                                    |             |           |-{dconf worker}
        |                                                    |             |           |-{gdbus}
        |                                                    |             |           |-{gmain}
        |                                                    |             |           |-{localStorage DB}
        |                                                    |             |           |-{mozStorage #1}
        |                                                    |             |           |-{mozStorage #2}
        |                                                    |             |           |-{mozStorage #3}
        |                                                    |             |           |-{mozStorage #4}
        |                                                    |             |           |-{mozStorage #5}
        |                                                    |             |           |-{mozStorage #6}
        |                                                    |             |           `-{mozStorage #7}
        |                                                    |             |-panel-2-actions
        |                                                    |             |-panel-6-systray
        |                                                    |             `-{gmain}
        |                                                    |-xfdesktop---{gmain}
        |                                                    |-xfwm4
        |                                                    |-{gdbus}
        |                                                    `-{gmain}
        |-rsyslogd-+-{in:imklog}
        |          |-{in:imuxsock}
        |          `-{rs:main Q:Reg}
        |-syndaemon
        |-systemd-journal
        |-systemd-logind
        |-systemd-udevd
        |-tumblerd-+-{gmain}
        |          `-2*[{pool}]
        |-wpa_supplicant
        |-xfce4-notifyd
        |-xfce4-terminal-+-bash---su---bash---pstree
        |                |-gnome-pty-helpe
        |                |-{gdbus}
        |                `-{gmain}
        |-xfce4-volumed-+-{gdbus}
        |               `-{task0}
        |-xfconfd
        |-xfsettingsd---{gmain}
        `-xscreensaver

[TobiSGD]

Nevermind, I misread that post.

[TobiSGD]

Please provide a bug number, I definitely want to look at that. One question though, wouldn't it be the correct way to start your backup process as a systemd service (probably one-shot type) instead of starting the program directly from udev?

see http://lists.freedesktop.org/archives/s ... 07390.html - the bug was still here last week, a college ran into it and got a bloody nose.

There is no "correct way" to do things with stupidd as stupidd is uttery broken

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.

[tomazzi]

There are two main reasons for disabling optimisations with -O0 :
1. For testing the assembler and the compiler itself.
2. Experimental software: coredumps and stack backtrace are obvoiusly different between optimised and non-optimised assembly (and the differences are sometimes really huge).
Since systemd uses ancient ways to handle errors and because it is complex, then often the only way to tell what caused the crash in particular situation is to read the coredump. Non-optimised code dumps core files which are easier to read.

Trapv: In short, it generates SIGABRT on overflows and is a compiler-level version of assert() - which just kills the problematic process. Due to a significant overhead that is produced by additional code injected by the compiler, this option is used mainly in experimental code to quickly discover programming errors. However, in production (tested) code this is normally removed - mainly due to performance issues.

And thus, for me it's obvious that the autors are "recommending" using non-optimised code which is just crashing with coredump on any trivial error, only because they have completely no idea what may happen - because it's just experimental and untested solution.

[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.

[edbarx]

Memory use with systemd running:

Code: Select all

root@sid-inst:/home/edbarx# free -m
             total       used       free     shared    buffers     cached
Mem:          1940        613       1327         64         18        246
-/+ buffers/cache:        348       1592
Swap:         3071          0       3071
root@sid-inst:/home/edbarx# uptime
 11:16:29 up 20 min,  2 users,  load average: 0.25, 0.22, 0.21

The two users are root and edbarx.

[keithpeter]

Memory use with systemd running:

Code: Select all

root@sid-inst:/home/edbarx# free -m
             total       used       free     shared    buffers     cached
Mem:          1940        613       1327         64         18        246
-/+ buffers/cache:        348       1592
Swap:         3071          0       3071
root@sid-inst:/home/edbarx# uptime
 11:16:29 up 20 min,  2 users,  load average: 0.25, 0.22, 0.21

The two users are root and edbarx.

http://0pointer.de/blog/projects/systemd-pdf.html

Perhaps working through these tutorials might give you a sense of how the author of the systemd project thinks it might work for admins? Seems to be based on progressively different versions of the systemd project but has commands to try out.

[edbarx]

Thanks for the link, it will provide me with very useful information.