Hacker News Reader

Comment by amoe_ | Hacker News Reader

I was pro-systemd at the time of the controversial discussions. I still think it's a net positive relative to what was there before. But personally speaking, it's only the core of the software (service management) that improved things for me. The other things (timers, journald) I either ignore or don't like, but perhaps they're useful for distributions.

View on HN

I've been quite happy with -boot, -networkd, -resolved. -logind too, what a powerful upshift in routing input.

I forget what but timesync is missing a lot of nice to haves. But ditching grub for something much much much more manageable & a joy to use. Networkd and resolved have both had a lot of nice clear straightforward options, and I love how systemd unit files snap together for these networking concerns.

Journald has been ok for me, and I use it a lot, but not intensively. Having adequate performance is definitely a huge concern.

systemd-resolved is a godsend.

I run, at home and at work, vpns and having a good way to configure split-horizon dns is incredibly useful.

At a previous company we were able to ship a binary that would automatically configure a bunch of company settings on developers' linux laptops and got VPN configurations working with split-horizon dns very easily.

prior to this, doing split-horizon dns on linux basically meant running dnsmasq (!!!) on every linux laptop

I think if it was just service management most people wouldn't mind it nearly as much.

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 more logs? Because journald makes it easier/feasible to collect more logs.

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.

> 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.

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.

Reply on news.ycombinator.com