Live data from Hacker News

Systemd has been a complete, utter, unmitigated success

blog.tjll.net

101–110 of 114 posts

Re: Systemd has been a complete, utter, unmitigated success

#101

Earlier quoted context omitted.

Yes, systemd's weirdly bundled system services largely suck. The ones that I'm sure about: journald is more annoying to use than syslog (it takes forever - like a minute on a top of the line CPU - to scan two months worth of logs) and resolvd has or used to have basic bugs that other systems don't have.

> The ones that I'm sure about: journald is more annoying to use than syslog (it takes forever - like a minute on a top of the line CPU - to scan two months worth of logs) That sounds like an unequal comparison. For the same amount of log data and the exact same filter operation, journald should be strictly faster or equal to text logs. Are you sure this isn't because in your journald test you're going through a lot…

No, journald shouldn't be strictly faster. It signs/encrypts/whatever the logs and stores them in some kind of structured format that needs to be converted to plaintext before processing it as such. That is not faster than just reading the plaintext. Grep and less search etc are very fast.

And no, I don't want to use the structured features. For error diagnosis, I want every occurrence of the search string in every field over a long time for comparison purposes.

Re: Systemd has been a complete, utter, unmitigated success

#102

Earlier quoted context omitted.

> The ones that I'm sure about: journald is more annoying to use than syslog (it takes forever - like a minute on a top of the line CPU - to scan two months worth of logs) That sounds like an unequal comparison. For the same amount of log data and the exact same filter operation, journald should be strictly faster or equal to text logs. Are you sure this isn't because in your journald test you're going through a lot…

No, journald shouldn't be strictly faster. It signs/encrypts/whatever the logs and stores them in some kind of structured format that needs to be converted to plaintext before processing it as such. That is not faster than just reading the plaintext. Grep and less search etc are very fast. And no, I don't want to use the structured features. For error diagnosis, I want every occurrence of the search string in every f…

> stores them in some kind of structured format

No, it stores them with binary metadata, rather than ASCII metadata. "Plaintext" needs to be parsed, which is expensive. You don't really think binary RPC formats like protobuf are slower than JSON because it's "structured format" compared to "plaintext" I hope. Or SQL databases are slower than CSV files.

> And no, I don't want to use the structured features.

I don't see why you'd prefer having to figure out different time formats to parse from different software logs compared to a standard time format.

Re: Systemd has been a complete, utter, unmitigated success

#103

Earlier quoted context omitted.

That is what syslogd has been doing since forever. Journald actually made this harder due to not supporting the established syslog protocol.

And a lot of software don't use syslog because it's easier to print to stderr/stdout or some random log file. Journald makes it easier to capture everything no matter what the software does, including the established syslog protocol, so I don't even see your point. If everything on your machine uses syslog, journald is a drop in replacement for the dozen of possible syslogd implementations.

journald isn't drop-in because it only saves logs locally. syslog also is a protocol to send your logs to a log-server.

And the usual syslog APIs are 2 lines: Initialize with openlog(stream, process_name, flags) and after that do syslog(urgency, message). That is on par with stderr/stdout, and far simpler than handling your own logfiles. Except if you use log4$yourlanguage or something, then everything is just the same, you just configure a different destination.

And if you can't change your code to not use stdout/stderr, you can easily do yourcode | logger -t yourcode -p daemon.info 2| logger -t yourcode -p daemon.err

Re: Systemd has been a complete, utter, unmitigated success

#104
I don't know what to think about Systemd.

I think however that a lot of hate comes from:

- a very opaque structure: it's actually not that opaque, since configuration files are still plain text, and better yet with more structure, but it first appears as inscrutable, since the programs aren't shell scripts;

- a set of new tools to learn: Systemd doesn't make use of the existing Unix tool-set (sed, awk, etc), ie. the vocabulary most sysadmins are familiar with in this ecosystem.

It seems on the outset that Systemd is trying to get away from the traditional Unix "one program should do one and only one thing well" (which is colloquial phrasing for separation of concerns).

Still, one idea that occurred to me is that in the early days of Unix, system programs might have been quite simple, with very few options (that man pages were probably very short), but that's clearly not the case nowadays. So haven't we left the "one program should do one and only one thing well" paradigm a long time ago anyway?

Actually, I think that one crucial issue with systemd is its specialization: can it be used for anything else than service management? At first, this seems to clash with the Unix principle, but even awk and sed are meant to do one thing, yet their field of action is very general, not just confined to handle one style of files or perform one style of transformation.

Re: Systemd has been a complete, utter, unmitigated success

#105

Earlier quoted context omitted.

No, journald shouldn't be strictly faster. It signs/encrypts/whatever the logs and stores them in some kind of structured format that needs to be converted to plaintext before processing it as such. That is not faster than just reading the plaintext. Grep and less search etc are very fast. And no, I don't want to use the structured features. For error diagnosis, I want every occurrence of the search string in every f…

> stores them in some kind of structured format No, it stores them with binary metadata, rather than ASCII metadata. "Plaintext" needs to be parsed, which is expensive. You don't really think binary RPC formats like protobuf are slower than JSON because it's "structured format" compared to "plaintext" I hope. Or SQL databases are slower than CSV files. > And no, I don't want to use the structured features. I don't se…

I'm searching for "service name" and I don't care if it comes from "service" or mentions "service". That's unstructured.

The rest of your comment doesn't even apply. Search is not parsing and not structured data transfer (which is what binary RPC formats are for), and unless you have a fulltext index, there is no faster way to do it than the usual algorithms, which work at 100+ MB/s. With log files, the text is right there ready to be searched. With journald, it needs to be assembled first, and it's pretty slow in practice.

Re: Systemd has been a complete, utter, unmitigated success

#106

Earlier quoted context omitted.

I don't fucking hate systemd. I'm marginally glad it exists. I just don't want to live under it's despotic regime. You might like it because you think trains running on time is more important than freedom. You're the one coming at me with fucking attitude, like a 16 year old who just discovered IntelliJ. I have done the exploration, then looked online for why everything is so damn complicated now. It's because system…

I semi-respectfully disagree that I've given you undue attitude. One of the things I really enjoyed about the Flix programming language submission today was running across their principles section. Right off the top of the list: > Simple is not easy > We believe in Rich Hickey's creed: simple is not easy. We prefer a language that gets things right to one that makes things easy. Such a language might take longer to l…

Systemd is anything but simple. And the past definitely wasn't easy. You seem to have the terms backward. For the end user, yes, it's a polished experience that you mostly don't have to mess with, and the parts of it you're most likely to interact with are, well, fine. Not great, but fine.

> operable understandable system

Every system is understandable, it's just a question of how much work you have to put into understanding it. Good design reduces the amount of this effort needed. Many many systemd components simply aren't well-designed. But they all interop with each other so there's no way to slowly wean a system off of systemd. Trust me I tried.

I don't want to understand systemd. It feels like being at work. Good on you for putting in the effort. I should be able to use software I like and want to use. Maybe even hand-write some replacements, like I'm doing with my shell. Systemd doesn't get in my way there, thankfully, it's been awhile so I don't have specifics off the top of my head for the last time I tried removing a few systemd components only to find hard dependencies on each other.

This is not how Linux needs to be. I agree the old ways sucked. I don't want to go back to them either. But neither do I want to be locked into the big ugly mess that systemd turned into. I want clean, modern, well-designed components that are independent of each other.

Systemd makes me feel like I'm on a Mac.

Re: Systemd has been a complete, utter, unmitigated success

#107

Earlier quoted context omitted.

I used to be fine with it, until I started writing my own software tools, then looking at how to actually do stuff with systemd and I'm like, nope nope nope nope. At some point when I have space for a new project I'm going to migrate from Arch to Obarun, which uses a modern update on the excellent daemontools to provide init. When systemd works it's mostly fine, when it breaks, path of least resistance is often to re…

i have the same sentiment, and for me systemd was getting so slow and hard to tshoot (the tools to analyze boot graphs and sequence showed service sequence breakage, some times there is no problem, sometimes sequence changed and problem happened) and i just changed for another distro without systemd and boom, startup in seconds no problem at all.

Which distro did you land on?

Re: Systemd has been a complete, utter, unmitigated success

#108
post #98

Earlier quoted context omitted.

I don't fucking hate systemd. I'm marginally glad it exists. I just don't want to live under it's despotic regime. You might like it because you think trains running on time is more important than freedom. You're the one coming at me with fucking attitude, like a 16 year old who just discovered IntelliJ. I have done the exploration, then looked online for why everything is so damn complicated now. It's because system…

> It's not just an init system, it's everything below the userland. And a lot of those components are very poorly designed. And it's this big ball of mush where if you use one component, thy must use them all. It's so bad Arch does not support replacing systemd, like at all. You're totally on your own. It's true, it's not only an init system anymore, it's also a service manager, a network manager, a DNS cache and res…

It's an improvement, I'll give you that much. But it's moved in the opposite direction and seeks to reduce freedom, not give more of it. I should be able to run my own DNS cache, network manager, service manager if I want to. Systemd makes that all but impossible.

Re: Systemd has been a complete, utter, unmitigated success

#109
post #9

I wouldn’t call it a success it all. Almost managed to do was moving or forcing other software to get locked in. GDM, Podman, Pipewire…just to name a few.

Gnome is pretty guilty of adding hard dependencies on systemd, but podman and pipewire have worked fine for me without systemd... Not aware of any tight integration there that is mandatory (obviously quadlets, but you don't have to use that feature)

Re: Systemd has been a complete, utter, unmitigated success

#110

Earlier quoted context omitted.

i have the same sentiment, and for me systemd was getting so slow and hard to tshoot (the tools to analyze boot graphs and sequence showed service sequence breakage, some times there is no problem, sometimes sequence changed and problem happened) and i just changed for another distro without systemd and boom, startup in seconds no problem at all.

Which distro did you land on?

I switched to Void Linux, have been great so far.
Post reply on HN