4 ms·

This would be quite difficult to debug for the average user. A lot of systemd functionality appears to be designed for military environments served by Redhat fo

by throw2016 8y ago

This would be quite difficult to debug for the average user. A lot of systemd functionality appears to be designed for military environments served by Redhat for instance journalctls binary logs for security auditing. But this is not required by the vast majority of Linux users. Offloading complexity to everyone to serve a specific use case is bad design. It's like implementing high security military procedures in the average office, not needed and a waste of time and resources. Shouldn't security features over engineered by design like a time daemon launched by dynamic users in a new mount space left to user choice. Surely those who need that level of security should take the responsibility to enable it, accept the debt and deal with the complexity, rather than imposing it on everyone else. In this case ntpd is a better solution for average users. Most distributions voted for an init system. An init has a limited role. Systemd is proving to be anything but.

djsumdog 8y ago
I agree entirely and the complexity over systemd has been one of the major concerns. I do like having a standardized way of managing processes. Systemd does make packaging deb/rpm files way easier, but I don't really like the price. Everything is abstracted to systemd. Mounts. udev. mult-users/logins (consolekit). I like fstab with UUIDs. I like manually mounting a USB stick when I insert it. I like having the options of using an automounter or not using an automounter. At home I stick to Gentoo and Void. runit is super simple and I like the concept behind it (although it does lack in some exceptions/logging issues). I think ideally on my hosted solutions, the best thing going forward is a thin Alpine with Docker and running all services as docker containers. I really wish the FreeBSD port of Docker was still maintained. I'd switch everything to FreeBSD+Docker if I could.
- derefr 8y ago
  > I think ideally on my hosted solutions, the best thing going forward is a thin Alpine with Docker and running all services as docker containers. That sounds like a lot more trouble than it's worth, compared to CoreOS or Ubuntu Core. If everything is running in Docker, why does the "hypervisor's" use of systemd matter? It's not using it for anything.
derefr 8y ago
> Surely those who need that level of security should take the responsibility to enable it That implies two code paths, one that enables the security and one that doesn't. That is more complicated (and less testable!) than either code-path on its own. Security costs more than insecurity, but sometimes-security is the worst of all worlds.

djsumdog 8y ago

I agree entirely and the complexity over systemd has been one of the major concerns. I do like having a standardized way of managing processes. Systemd does make packaging deb/rpm files way easier, but I don't really like the price. Everything is abstracted to systemd. Mounts. udev. mult-users/logins (consolekit). I like fstab with UUIDs. I like manually mounting a USB stick when I insert it. I like having the options of using an automounter or not using an automounter. At home I stick to Gentoo and Void. runit is super simple and I like the concept behind it (although it does lack in some exceptions/logging issues). I think ideally on my hosted solutions, the best thing going forward is a thin Alpine with Docker and running all services as docker containers. I really wish the FreeBSD port of Docker was still maintained. I'd switch everything to FreeBSD+Docker if I could.

derefr 8y ago
> I think ideally on my hosted solutions, the best thing going forward is a thin Alpine with Docker and running all services as docker containers. That sounds like a lot more trouble than it's worth, compared to CoreOS or Ubuntu Core. If everything is running in Docker, why does the "hypervisor's" use of systemd matter? It's not using it for anything.

derefr 8y ago

> Surely those who need that level of security should take the responsibility to enable it That implies two code paths, one that enables the security and one that doesn't. That is more complicated (and less testable!) than either code-path on its own. Security costs more than insecurity, but sometimes-security is the worst of all worlds.