(from tfa): "Now, let us turn our attention to the benefits that systemd brings us. I believe that these are the reasons that all Linux distributions have adopted systemd."
ahem slackware has not adopted systemd
Systemd Sucks, Long Live Systemd
171–180 of 272 posts
Re: Systemd Sucks, Long Live Systemd
#172[deleted]
Re: Systemd Sucks, Long Live Systemd
#173> The justification for storing logs in a binary format was speed and performance, they are more easily indexed and faster to search. Are there any benchmarks for this? I don't know why, and I may be doing things wrong, but journalctl -lu --since yesterday in our prod env takes a couple of seconds before I see any output, while a (z)grep on a date rotated, potentially compressed log file on a non-journald system is g…
Of course nobody benchmarked. Rarely are there programmers in OSS these days that benchmark anything. (not nearly as common as those who claim "speed") There was a bug though where the journaling was so slow it caused the whole server to crash. (sorry, can't find it right now; something about them using mmaped files and the access pattern was.. or something, interesting stuff:) Binary logs should be faster, in theory…
> Rarely are there programmers in OSS these days that benchmark anything.
Please, don't release such a bold statement without any source. Please!
Re: Systemd Sucks, Long Live Systemd
#174Earlier quoted context omitted.
Plenty of the "separate" components share core code at compile time. If they were truly separate they could be downloaded piecemeal and compiled independently.
OTOH, sharing code between different components developed under an umbrella project is not bad per se - if they require the functionality, re-implementing it from scratch for each component would not be a good idea, either. Duplicating and manually syncing the code also has its share of problems.
It's not only about whether you do it, it's also about HOW you do it. I once saw a slide from FOSDEM which listed lots of CLI tools that systemd replaced. Some of them seemed quite trivial and if they all depend on low-level systemd, I believe it really is bad design.
Re: Systemd Sucks, Long Live Systemd
#175At the risk of sounding heretical, I kind of find myself in the middle ground regarding systemd - I was initially highly skeptical of it, and I still think it's problematic that it is so Linux-centric and will cause problems maintaining software to run both on Linux/systemd and on *BSD. The way it was pushed on distros was problematic, in my opinion. But having used a couple of Linux systems running systemd - Raspian…
I am also in the middle ground, but I have moved from the opposite direction. I used to like systemd a lot, especially for its simple unit files (compared to ugly System V shell scripts) and the fact that it could properly track processes and restart them on failure. I have become a bit more skeptical, because most of the problems that I recently had seemed to be related to systemd. Including some networking problems…
Generally agreed. I know that my priorities for what should be done in systemd are not going to match someone else's but there are also some clearly problematic things that just seem to go unaddressed no matter the scale (e.g. rebooting nspawn containers [1], problems with DNS/resolved [2]).
systemd can do a lot of really useful things but when I can't reliably reboot machines or struggle with resolving things using DNS...it's hard to be optimistic.
[1] https://github.com/systemd/systemd/issues/2809 [2] https://github.com/systemd/systemd/issues/3649
Re: Systemd Sucks, Long Live Systemd
#176Earlier quoted context omitted.
Yeah, but I'm sure you agree networkd should propagate errors from wpa_supplicant such that they reach the user, instead of piping them to /dev/null (not literally, but you get my point)?
networkd doesn't know about wpa_supplicant, just as it doesn't know about openvpn, vpnc, ... If you want a network manager that does know about those and might give more helpful error messages if they fail, use for example NetworkManager.
Indeed, I'm not using networkd anymore. And it was just an example, the phenomenon exists all over systemd.
So basically, you're saying that systemd et al integrate with everything on my system, except for when it's useful?
Re: Systemd Sucks, Long Live Systemd
#177Earlier quoted context omitted.
Yeah, but I'm sure you agree networkd should propagate errors from wpa_supplicant such that they reach the user, instead of piping them to /dev/null (not literally, but you get my point)?
networkd doesn't know about wpa_supplicant, just as it doesn't know about openvpn, vpnc, ... If you want a network manager that does know about those and might give more helpful error messages if they fail, use for example NetworkManager.
Then perhaps networkd should be dropped, because:
repeat after me:
everything eventually fails.
How can you tell when a programmer has graduated from "completely new at this" to "has some valuable experience"? That point comes when they stop assuming success.
Check for error and do something useful with the returned value.
Write tests yourself.
Fail gracefully.
Log status, so you know what was happening just before it failed.
Set reasonable timeouts on external processes.
Systemd is written from the perspective of a laptop user who will hand over the whole thing to a support tech when things go wrong. This is antithetical to the spirit of UNIX, which is not "write programs with one purpose that chain together well".
The spirit of UNIX is this: At any time, a user on the system may decide to become a developer or a sysadmin. The tools and information they need should be available.
Re: Systemd Sucks, Long Live Systemd
#178Earlier quoted context omitted.
Plenty of the "separate" components share core code at compile time. If they were truly separate they could be downloaded piecemeal and compiled independently.
OTOH, sharing code between different components developed under an umbrella project is not bad per se - if they require the functionality, re-implementing it from scratch for each component would not be a good idea, either. Duplicating and manually syncing the code also has its share of problems.
Is there any chance -- any chance at all -- that we cannot do the same dance of ineptly-phrased-objection followed by rebuttal-that-misses-the-point when it comes to this particular facet of the discussion?
Both sides of this are wrong. The people complaining about "monolithic" are groping in the dark for ideas such as low coupling. The people saying "but count the binaries!" are not addressing the questions of fully documented interfaces between said binaries, composability, and interoperability.
The "uselessd guy" explained this quite well, as have many other people. Can you please advance to not dancing this same old dance every time?
* https://news.ycombinator.com/item?id=12879771
Re: Systemd Sucks, Long Live Systemd
#179Earlier quoted context omitted.
Of course nobody benchmarked. Rarely are there programmers in OSS these days that benchmark anything. (not nearly as common as those who claim "speed") There was a bug though where the journaling was so slow it caused the whole server to crash. (sorry, can't find it right now; something about them using mmaped files and the access pattern was.. or something, interesting stuff:) Binary logs should be faster, in theory…
> Rarely are there programmers in OSS these days that benchmark anything. Please, don't release such a bold statement without any source. Please!
How would you cite the lack of testing? GP did discuss several regressions that imply performance wasn't thoroughly tested.
Re: Systemd Sucks, Long Live Systemd
#180(from tfa): "Now, let us turn our attention to the benefits that systemd brings us. I believe that these are the reasons that all Linux distributions have adopted systemd." ahem slackware has not adopted systemd
Nor has Gentoo adopted it as the primary system (and, in fact, OpenRC remains a favorite alternative).