Why systemd is the way forward: technical arguments

Here you can discuss every aspect of Debian. Note: not for support requests!

Re: Why systemd is the way forward: technical arguments

Postby tomazzi » 2014-11-26 09:58

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.
Odi profanum vulgus
tomazzi
 
Posts: 730
Joined: 2013-08-02 21:33

Re: Why systemd is the way forward: technical arguments

Postby twoflowers » 2014-11-26 10:14

TobiSGD wrote: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.
twoflowers
 

Re: Why systemd is the way forward: technical arguments

Postby edbarx » 2014-11-26 10:20

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.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
User avatar
edbarx
 
Posts: 5402
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: Why systemd is the way forward: technical arguments

Postby keithpeter » 2014-11-26 11:42

edbarx wrote: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.
User avatar
keithpeter
 
Posts: 502
Joined: 2009-06-14 08:06
Location: 5230n 0155w

Re: Why systemd is the way forward: technical arguments

Postby edbarx » 2014-11-26 11:49

Thanks for the link, it will provide me with very useful information.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
User avatar
edbarx
 
Posts: 5402
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: Why systemd is the way forward: technical arguments

Postby reinob » 2014-11-26 12:02

tomazzi wrote:^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 shit. 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).
reinob
 
Posts: 869
Joined: 2014-06-30 11:42

Re: Why systemd is the way forward: technical arguments

Postby TobiSGD » 2014-11-26 13:37

twoflowers wrote:
TobiSGD wrote: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.
User avatar
TobiSGD
 
Posts: 859
Joined: 2010-05-08 22:27
Location: Hannover, Germany

Re: Why systemd is the way forward: technical arguments

Postby edbarx » 2014-11-26 13:39

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 
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
User avatar
edbarx
 
Posts: 5402
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: Why systemd is the way forward: technical arguments

Postby twoflowers » 2014-11-26 14:03

TobiSGD wrote:
twoflowers wrote:
TobiSGD wrote: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.
twoflowers
 

Re: Why systemd is the way forward: technical arguments

Postby confuseling » 2014-11-26 16:48

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.
The Forum's search box is terrible. Use site specific search, e.g.
https://www.google.com/search?q=site%3A ... terms+here
confuseling
 
Posts: 2143
Joined: 2009-10-21 01:03

Re: Why systemd is the way forward: technical arguments

Postby TobiSGD » 2014-11-26 19:01

twoflowers wrote:
TobiSGD wrote:[

"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?
User avatar
TobiSGD
 
Posts: 859
Joined: 2010-05-08 22:27
Location: Hannover, Germany

Re: Why systemd is the way forward: technical arguments

Postby reinob » 2014-11-26 19:06

confuseling wrote: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.
reinob
 
Posts: 869
Joined: 2014-06-30 11:42

Re: Why systemd is the way forward: technical arguments

Postby confuseling » 2014-11-26 19:26

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...
The Forum's search box is terrible. Use site specific search, e.g.
https://www.google.com/search?q=site%3A ... terms+here
confuseling
 
Posts: 2143
Joined: 2009-10-21 01:03

Re: Why systemd is the way forward: technical arguments

Postby twoflowers » 2014-11-26 20:12

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

Re: Why systemd is the way forward: technical arguments

Postby confuseling » 2014-11-26 20:23

Presumably you've got examples of recent problematic changes in its external interfaces then.
The Forum's search box is terrible. Use site specific search, e.g.
https://www.google.com/search?q=site%3A ... terms+here
confuseling
 
Posts: 2143
Joined: 2009-10-21 01:03

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 12 guests

fashionable