351–360 of 449 posts
The second real, functional, genuinely working docker support shows up in *BSD and is working - I'll be running it on my desktop.
Earlier quoted context omitted.
Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. It is easier to configure and is convenient to have one holistic system in a lot of ways, but... They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. They have a track…
> They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. This seems like it needs some citation. There certainly have been bugs. I think it's legitimate to talk (with specifics!) about cultural issues with systemd's development and its impact on security. But I don't see that this statement is particularly well supported. In part…
(Just in case, this is an security issue because it enables constant dosing, as well as clears the resolver cache making spoofing easier)
Earlier quoted context omitted.
I had completely forgotten about these directives! It's things like this that make me glad systemd is a choice, honestly.
SystemD did not invent cgroups. Not only is it possible to use cgroups without systemd it is often easier for small cases and binaries can call cgroups themselves for any child processes they create. The timing of these systems releasing does not equate to causation here. Google themselves (creators of cgroups) do not even use systemd on their own hypervisors which leverage cgroups heavily.
Earlier quoted context omitted.
In 2017, the Linux Kernel had over 450 CVEs, while systemd had 5. https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... https://www.cvedetails.com/vulnerability-list/vendor_id-7971... So far in 2019, the gap has narrowed: "only" 45 CVEs so far for the Linux kernel, and 7 for systemd.
As marcosdumay said upthread, “Systemd has a historic of refusing to fill CVEs, even for incredibly bad vulnerabilities.” This contributes to the low rate of CVEs in systemd relative to Linux (for which many less-important bugs get CVEs).
My conclusion is that the systemd project is not its own CNA and therefore not in a position to authoritatively decide which systemd bugs get CVE numbers assigned and which do not.
Earlier quoted context omitted.
Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. It is easier to configure and is convenient to have one holistic system in a lot of ways, but... They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. They have a track…
> Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. The 'Imperialistic Culture' you speak of is one of those made-up things that systemd haters keep repeating, but has no basis in reality. > They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting…
The imperialism part is likely due to score creep into parts they just can't handle well enough. systemd-resolved for example had terrible security and functionality issues still after it was being deployed to many distros. These were simple "point a fuzzer at it and watch it crash" issues which should not be seen in a DNS resolver these days.
SystemD definitely spurred some controversies years ago but is it that bad in 2019? All major distros adopted it and even some that are listed there as "no systemd" in reality just give you choice (e.g. Gentoo). I'd gladly hear the opinion of distro maintainers why did they switch to SystemD if it's as bad as it looks like in people's perception.
> SystemD definitely spurred some controversies years ago but is it that bad in 2019? The reasons for the controversies have not really changed (lennart, the idea that it's not "unixy", a takeover of many subsystems by various systemd components, …) so people who didn't like systemd years ago probably still don't. As somebody who's not really involved, I found Benno Rice's The Tragedy of Systemd[0] interesting and en…
It’s also to the point where Benno states that people don’t like change, but that’s really not true. Everyone jumped on virtualisation (except Theo De Raat), everyone jumped on containers, Kubernetes, GO, Rust, eBPF et al.
There are new technologies which don’t have to eat the universe to function.
Most people who have a problem with systemd don’t actually hate it, they’re upset because the environment that allowed systemd to grow no longer exists for its replacement. Coupled with the fact that we should really consider systemd a proof-of-concept for something better, means that we’ll be stuck with buggy, weird, non-deterministic C++ for decades.
That’s the root of the problem, not that we nerds dislike change, we tend to love change.
Earlier quoted context omitted.
Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. It is easier to configure and is convenient to have one holistic system in a lot of ways, but... They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. They have a track…
> Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. The 'Imperialistic Culture' you speak of is one of those made-up things that systemd haters keep repeating, but has no basis in reality. > They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting…
Maybe it's not for systemd to decide what I'm meant to do. If changes to behavior that they only meant for operating system maintainers to rely on results in angry end-users, they probably made the wrong assumption.
> On the sysvinit side you had thousands and thousands of lines bunch of procedural code of dubious quality that is endlessly rewritten by hundreds of different teams with vastly differing levels of competency and success using a general purpose language for configuration.
Meanwhile, I have ~400 LOC of init scripts (including service scripts) on my daily driver, an init system with <1% the LOC of systemd, and plain text readable system logs. I agree that hand waving about "imperialism" isn't very constructive, but on the other hand I don't think that misrepresenting the alternatives to systemd and exaggerating their faults is particularly useful either, nor is pretending that sysvinit is the only alternative. A lot of people have thought "sysvinit sucks" and done something about it.
Earlier quoted context omitted.
Given the timeframe, something like OCaml would likely have been a better option.
Ocaml parallelism/concurrency story was not that good - but Haskell has just got its fancy new epoll based I/O manager (100000+ lightweight threads) around that time, with the 7.0.1 release (16 November 2010) They could have even take inspiration, imagine: typed, functional, monadic init files - "systemd: avoid success at all costs" :)
Earlier quoted context omitted.
Yes, DBUS is specified [1]. There are multiple implementations shipping (dbus reference implementation and dbus-broker), as well as several different client libraries. As dbus user, or application, you just need some client library. As an operating system, you also need a daemon running, which is routing the messages among all the clients. [1] - https://dbus.freedesktop.org/doc/dbus-specification.html
So it is--and, in reading, it looks like systemd actually ships their own sd-bus client. Huh. TIL. Thanks.