4 ms·

With systemd, any really tricky low-level bug is systemd's fault, because systemd tries to do everything, in the most "advanced" way. And due gnome3 dependencie

With systemd, any really tricky low-level bug is systemd's fault, because systemd tries to do everything, in the most "advanced" way. And due gnome3 dependencies it's been adopted by all major distros. Before systemd, a difficult bug was not always the fault of one newfangled opinionated and unavoidable package. I read the first blog post about systemd when it was written, and thought it was really interesting. Then I read the second blog post and thought "eh this is getting a bit complicated". And since then of course systemd has relentlessly taken over and added much more ... so of course practically any low-level system bug, randomly distributed, has a really high chance of being in systemd. And again, it does lots of stuff that was never needed before - in this case it's un-sharing a mount namespace for extra isolation of a small trusted service, which is overkill and complicated, and this struggle to figure out what the hell happened seems particularly unnecessary.

fooker 8y ago
>And due gnome3 dependencies it's been adopted by all major distros. That's not correct. It has been adopted by all major distros due to ease of use and maintaibility of unit files. That is very clear from nearly all mailing list discussions. Also, people can and do use gnome3 without systemd. (https://wiki.gentoo.org/wiki/GNOME/GNOME_Without_systemd https://wiki.gentoo.org/wiki/GNOME/GNOME_Without_systemd).
- majewsky 8y ago
  > That's not correct. It has been adopted by all major distros due to ease of use and maintaibility of unit files. Or rather, because unit files work the same across all systemd-using distros, they can actually be upstreamed to the application developers and distros just package them, which is a huge time-saver compared to having to maintain init scripts for hundreds of daemons.
  - fooker 8y ago
    Makes sense.
nickez 8y ago
timesyncd is a network connected daemon. Why would you not isolate it as much as possible?
- dsr_ 8y ago
  The job of synchronizing the system clock is not a job that belongs to the init system. It is a job that belongs to people who can write and debug the very complex cases of NTP. The init system simply has to fire it up, take it down, and report on whether it's still running. Any further elaborations are features of the init system. All the problems mentioned here were failures of the init system in doing things that the init system should be doing, but were hard to diagnose because this particular init system does not and never has put "easy to debug" as a high priority item.
- ploxiln 8y ago
  "as much as possible" would be to put it in a virtual machine, or actually separate physical hardware, maybe in a multi-million-dollar bank vault to prevent physical tampering. Then there's a reasonable amount of isolation, which would be to run it under its own user, which can only write to one or two directories, and can't read user directories or non-world-readable system config files. This is already common practice. (Creating this user at package install time, or in the initial base distro config, is completely sufficient. And simpler.) "as much as possible" is really not worth it (and sucks resources away from implementing reasonable security practices elsewhere).

fooker 8y ago

>And due gnome3 dependencies it's been adopted by all major distros. That's not correct. It has been adopted by all major distros due to ease of use and maintaibility of unit files. That is very clear from nearly all mailing list discussions. Also, people can and do use gnome3 without systemd. (https://wiki.gentoo.org/wiki/GNOME/GNOME_Without_systemd https://wiki.gentoo.org/wiki/GNOME/GNOME_Without_systemd).

majewsky 8y ago
> That's not correct. It has been adopted by all major distros due to ease of use and maintaibility of unit files. Or rather, because unit files work the same across all systemd-using distros, they can actually be upstreamed to the application developers and distros just package them, which is a huge time-saver compared to having to maintain init scripts for hundreds of daemons.
- fooker 8y ago
  Makes sense.

nickez 8y ago

timesyncd is a network connected daemon. Why would you not isolate it as much as possible?

dsr_ 8y ago
The job of synchronizing the system clock is not a job that belongs to the init system. It is a job that belongs to people who can write and debug the very complex cases of NTP. The init system simply has to fire it up, take it down, and report on whether it's still running. Any further elaborations are features of the init system. All the problems mentioned here were failures of the init system in doing things that the init system should be doing, but were hard to diagnose because this particular init system does not and never has put "easy to debug" as a high priority item.
ploxiln 8y ago
"as much as possible" would be to put it in a virtual machine, or actually separate physical hardware, maybe in a multi-million-dollar bank vault to prevent physical tampering. Then there's a reasonable amount of isolation, which would be to run it under its own user, which can only write to one or two directories, and can't read user directories or non-world-readable system config files. This is already common practice. (Creating this user at package install time, or in the initial base distro config, is completely sufficient. And simpler.) "as much as possible" is really not worth it (and sucks resources away from implementing reasonable security practices elsewhere).