6 ms·

Part of it is that it is a more or less monolithic package that started as an init system and now does more than some people would like. This results in certai

Part of it is that it is a more or less monolithic package that started as an init system and now does more than some people would like. This results in certain packages switching to require systemd modules(gnome & udev) and essentially locking systems without systemd out of using said software. Communities supporting non-systemd init systems now have to maintain forks of these modules so that they can keep these packages supported on their distros. The other issue, which is the issue I care more about is that it does these things in a way that breaks compatibility with existing workflows and exposes it to a number of different issues due to its increased complexity. Don't get me wrong, systemd is excellent in many ways but like many others, I am not a fan of it overall and choose not to use it where possible. An example of something very controversal about systemd: journald. journald is a replacement for the system journaling daemon and is a generally very good journaling daemon. It is in many ways more performant than other journaling daemons and can be easier to use as well. The issues however come largely from the fact that it uses a binary log format. This breaks the ability for other tools access logs nearly as easily unless explicit support for the interaction is added by either journald or the tool in question.

megous 6y ago
I find systemd journals much more accessible. Instead of passing a log file to the tool, you pass journalctl's output to the tool, and you can serialize the output to any of the supported formats (incl. json) and use much more tools, more directly, than you could previously. Compare that with random older default debian log line from one of my systems: Feb 14 01:15:30 shakes kernel: [ 4.014481] [drm] No driver support for vblank timestamp query. Is that from 2008 or 2020? Noone knows. You have to do a lot to even be able to select by date correctly in your log processing tools. Such a basic thing.
- jacoblambda 6y ago
  My biggest issues personally are the lock-in of systemd overall and for journald the binary file format. If I could use journald on its own with OpenRC first and foremost and preferably have it store logs as text be it json or whatever then I would use it hands down. Journald just works for the most part and is much more convenient in most regards nowadays. If I remember correctly, interop was more of an issue before the big distros started to switch to systemd but now things seem to have mostly worked themselves out. With regard to my comment about wanting logs stored as text, it really just comes down to having had to deal with corrupted binary files one too many times and unless it is absolutely unavoidable I find myself preferring text files for that reason. I'd imagine file system based compression leaves most if any storage benefit from binary logs rendered moot. I know you can run a secondary syslog daemon from the output of journald or alternatively use a job to backup to a text based format but it would be so much more convenient to be able to just set a config setting. Having easy config and things "just working" is supposed to be one of systemd's strengths anyway. Final thing to note is that at least from the perspective of someone running Gentoo w/ OpenRC, issues with traditional loggers are typically config mistakes more than anything. As for your debian log example, syslog-ng which I believe Debian had used should default to isodate for the datetime format. At least this is the case after RFC 5424 was adopted in 2009. That should give something along the lines of "1985-04-12T19:20:50.52-04:00". Nowadays unless the defaults are changed, most logging systems shouldn't have that datetime issue.
  - megous 6y ago
    Hmm, that particular system is up since 2008, so maybe it inherited some config from that time during upgrades. :)
    - jacoblambda 6y ago
      Not really on topic but this brings up a pain point that I wish more distros addressed. Sane defaults are obviously important and over time what classifies as the "ideal" default config changes. Most package managers seem to apply a default config on the first install and then never update it again. At least from my experience, the only distro I have used that has offered any facilities in the package manager for handling config updates is Gentoo. Whenever there is a package update, if the default configuration files for the package change during an update, you are notified to run `etc-update`. This command then allows you to diff your current config with the new defaults, choose to use the entire file for the current config or the new default, or patch certain lines from the new default into your existing config. Personally I find this super convenient, especially because whenever you perform a package update or install it will let you know whether you have any outstanding configuration files or important upgrade notes to address. I'd be greatly interested to know if other package managers have these types of config and service management utilities. I looked around but I didn't really find anything.

megous 6y ago

I find systemd journals much more accessible. Instead of passing a log file to the tool, you pass journalctl's output to the tool, and you can serialize the output to any of the supported formats (incl. json) and use much more tools, more directly, than you could previously. Compare that with random older default debian log line from one of my systems: Feb 14 01:15:30 shakes kernel: [ 4.014481] [drm] No driver support for vblank timestamp query. Is that from 2008 or 2020? Noone knows. You have to do a lot to even be able to select by date correctly in your log processing tools. Such a basic thing.

jacoblambda 6y ago
My biggest issues personally are the lock-in of systemd overall and for journald the binary file format. If I could use journald on its own with OpenRC first and foremost and preferably have it store logs as text be it json or whatever then I would use it hands down. Journald just works for the most part and is much more convenient in most regards nowadays. If I remember correctly, interop was more of an issue before the big distros started to switch to systemd but now things seem to have mostly worked themselves out. With regard to my comment about wanting logs stored as text, it really just comes down to having had to deal with corrupted binary files one too many times and unless it is absolutely unavoidable I find myself preferring text files for that reason. I'd imagine file system based compression leaves most if any storage benefit from binary logs rendered moot. I know you can run a secondary syslog daemon from the output of journald or alternatively use a job to backup to a text based format but it would be so much more convenient to be able to just set a config setting. Having easy config and things "just working" is supposed to be one of systemd's strengths anyway. Final thing to note is that at least from the perspective of someone running Gentoo w/ OpenRC, issues with traditional loggers are typically config mistakes more than anything. As for your debian log example, syslog-ng which I believe Debian had used should default to isodate for the datetime format. At least this is the case after RFC 5424 was adopted in 2009. That should give something along the lines of "1985-04-12T19:20:50.52-04:00". Nowadays unless the defaults are changed, most logging systems shouldn't have that datetime issue.
- megous 6y ago
  Hmm, that particular system is up since 2008, so maybe it inherited some config from that time during upgrades. :)
  - jacoblambda 6y ago
    Not really on topic but this brings up a pain point that I wish more distros addressed. Sane defaults are obviously important and over time what classifies as the "ideal" default config changes. Most package managers seem to apply a default config on the first install and then never update it again. At least from my experience, the only distro I have used that has offered any facilities in the package manager for handling config updates is Gentoo. Whenever there is a package update, if the default configuration files for the package change during an update, you are notified to run `etc-update`. This command then allows you to diff your current config with the new defaults, choose to use the entire file for the current config or the new default, or patch certain lines from the new default into your existing config. Personally I find this super convenient, especially because whenever you perform a package update or install it will let you know whether you have any outstanding configuration files or important upgrade notes to address. I'd be greatly interested to know if other package managers have these types of config and service management utilities. I looked around but I didn't really find anything.