Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Why systemd is the way forward: technical arguments
-
- Posts: 2121
- Joined: 2009-10-21 01:03
Re: Why systemd is the way forward: technical arguments
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.
Which could be a good or a bad thing, but certainly isn't a problem on principle.
The Forum's search box is terrible. Use site specific search, e.g.
https://www.google.com/search?q=site%3A ... terms+here
https://www.google.com/search?q=site%3A ... terms+here
Re: Why systemd is the way forward: technical arguments
Yes I'm preparing my way to go (or perhaps emergency exit) ... seriously.TobiSGD wrote: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!tomazzi wrote: - 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
http://lwn.net/Articles/622445/
...
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:
-g - include all debugging symbolsecho "----------------------------------------------------------------"
echo "Initialized build system. For a common configuration please run:"
echo "----------------------------------------------------------------"
echo
echo "./configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs --enable-kdbus $args"
-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...
Odi profanum vulgus
-
- Posts: 2121
- Joined: 2009-10-21 01:03
Re: Why systemd is the way forward: technical arguments
Two obvious questions:
1) Does it compile / run without those options?
2) Will it ship with them in Stable?
1) Does it compile / run without those options?
2) Will it ship with them in Stable?
The Forum's search box is terrible. Use site specific search, e.g.
https://www.google.com/search?q=site%3A ... terms+here
https://www.google.com/search?q=site%3A ... terms+here
Re: Why systemd is the way forward: technical arguments
If you mean the security options, I don't know if it can be compiled without them, but AFAIK using them is optional.confuseling wrote:Two obvious questions:
1) Does it compile / run without those options?
2) Will it ship with them in Stable?
If Jessie will make use of them, I don't know, but as it seems they are definitely present in systemd 215.
-
- Posts: 2121
- Joined: 2009-10-21 01:03
Re: Why systemd is the way forward: technical arguments
So is that unusual? Are there many programs in Testing with debugging symbols / no optimisation?
The Forum's search box is terrible. Use site specific search, e.g.
https://www.google.com/search?q=site%3A ... terms+here
https://www.google.com/search?q=site%3A ... terms+here
Re: Why systemd is the way forward: technical arguments
Sorry, I don't get the question. Is what unusual? And where come debugging symbols and optimization in the mix?confuseling wrote:So is that unusual? Are there many programs in Testing with debugging symbols / no optimisation?
-
- Posts: 2121
- Joined: 2009-10-21 01:03
Re: Why systemd is the way forward: technical arguments
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...
(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...
The Forum's search box is terrible. Use site specific search, e.g.
https://www.google.com/search?q=site%3A ... terms+here
https://www.google.com/search?q=site%3A ... terms+here
Re: Why systemd is the way forward: technical arguments
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.
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.
Re: Why systemd is the way forward: technical arguments
. . . and CLI reboot and poweroff. https://wiki.archlinux.org/index.php/al ... o_shutdownHead_on_a_Stick wrote:I have installed Debian 7.2 and dragged it up through jessie & sid and it still allows me a CLI-only login.
Code: Select all
$ systemctl poweroff
$ systemctl reboot
Re: Why systemd is the way forward: technical arguments
As I see it, there are two explanations for using this compiler option:https://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Code-Gen-Options.html wrote: -ftrapv
This option generates traps for signed overflow on addition, subtraction, multiplication operations.
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
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.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
Re: Why systemd is the way forward: technical arguments
The more i think about it, the better the idea sounds.Bulkley wrote:. . . and CLI reboot and poweroff. https://wiki.archlinux.org/index.php/al ... o_shutdownHead_on_a_Stick wrote:I have installed Debian 7.2 and dragged it up through jessie & sid and it still allows me a CLI-only login.
As with many things, ArchWiki is way ahead of Debian with documentation.Code: Select all
$ systemctl poweroff $ systemctl reboot
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.
Re: Why systemd is the way forward: technical arguments
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.TobiSGD wrote: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?
There is no "correct way" to do things with stupidd as stupidd is uttery broken
Re: Why systemd is the way forward: technical arguments
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
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.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
Re: Why systemd is the way forward: technical arguments
Nevermind, I misread that post.
Last edited by TobiSGD on 2014-11-26 09:23, edited 1 time in total.
Re: Why systemd is the way forward: technical arguments
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.twoflowers wrote: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.TobiSGD wrote: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?
There is no "correct way" to do things with stupidd as stupidd is uttery broken
It would only be a bug if they would support it and it would fail, but not if it is not supported at all.
Re: Why systemd is the way forward: technical arguments
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.
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
Re: Why systemd is the way forward: technical arguments
It's a regression, 'cause udev in wheezy supports it. --> bug.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.
Re: Why systemd is the way forward: technical arguments
Memory use with systemd running:
The two users are root and edbarx.
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
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.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
- keithpeter
- Posts: 502
- Joined: 2009-06-14 08:06
- Location: 5230n 0155w
Re: Why systemd is the way forward: technical arguments
http://0pointer.de/blog/projects/systemd-pdf.htmledbarx wrote:Memory use with systemd running:The two users are root and edbarx.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
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.
Re: Why systemd is the way forward: technical arguments
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.
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.