Operating Systems Without Systemd • Hacker News Board

Re: Operating Systems Without Systemd

#161

Post by shawnz » Tue, May 05, 2020, 1:06 AM UTC

isbjorn16 wrote: post #158

shawnz wrote: post #117

Earlier quoted context omitted.

What is the advantage to having to write all the log messages twice instead of once? What is the disadvantage in having to type "journalctl -f" instead of "tail -f"?

My usual "tail" is not tail -f, but tail -n 100. In fact, I jump around a ton doing tails and heads with varying linecounts, and if it gets unweildy even after all of that, that's when I pipe to less and look at it. My major justification is I use tail and head constantly , every single day, and it's rarely on system logging. It's java logs, it's python logs, it's rust logs. I'm not going to be giving up tail or head…

Then it's "journalctl -n 100". Or "journalctl | less".

> Now I have to type "journalctl --help" every single time I want to look at a system or daemon log, which isn't super common, and when I do need to I'm already frustrated something isn't working.

I don't think that keeping users from ever having to learn anything new is a good justification for doing things a particular way.

> I'm not a sysadmin, I don't try to be and I don't want to be, and it seems like systemd is hellbent on forcing me to be one

Personally I don't understand this sentiment. As a user I have found that systemd has made using Linux systems much simpler for me. Yes, I had to read a manual, but I don't think that is anything like "forcing me to be a sysadmin". Didn't you have to read the manual for tail at some point in the past?

Re: Operating Systems Without Systemd

#162

Post by isbjorn16 » Tue, May 05, 2020, 3:05 AM UTC

shawnz wrote: post #161

isbjorn16 wrote: post #158

Earlier quoted context omitted.

My usual "tail" is not tail -f, but tail -n 100. In fact, I jump around a ton doing tails and heads with varying linecounts, and if it gets unweildy even after all of that, that's when I pipe to less and look at it. My major justification is I use tail and head constantly , every single day, and it's rarely on system logging. It's java logs, it's python logs, it's rust logs. I'm not going to be giving up tail or head…

Then it's "journalctl -n 100". Or "journalctl | less". > Now I have to type "journalctl --help" every single time I want to look at a system or daemon log, which isn't super common, and when I do need to I'm already frustrated something isn't working. I don't think that keeping users from ever having to learn anything new is a good justification for doing things a particular way. > I'm not a sysadmin, I don't try to…

Nope, tail is such a trivially easy program to use. There's like 2 switches that matter to me, one of which requires a value as well. Keeping things super simple is a really important thing, and I guess I had taken it for granted that everyone using gnu-style tools would be on the same wavelength - for the most part, at any rate. FWIW, I can't bear to read the awk or sed man pages either.

I fundamentally agree with you; learning something new is not necessarily a bad thing. Forcing you to learn something when you're actively trying to figure something utterly unrelated out is where it gets dicey. Not everyone wants to do the "Malcom in the Middle Hal Changing a Lightbulb" routine when there's already a Very Important Thing to Fix.

The problem with systemd is that it took something that already worked perfectly fine for my needs and said "let's overengineer the everloving pants out of this! get in the car grandpa, it's time to roll!" I didn't ask for it, I have WAY more important (to me!) things to do, and it's actively running interference with that. Surely you can see that level of frustration, right?

Put another way, I'm sure it's a LOVELY bikeshed for some. Some people have wanted a bikeshed this fantastic and wonderful for a long time, and they will use this bikeshed with great joy daily.

Meanwhile, every time I'm trying to get something I actually care about done, it's like pulling teeth. Maybe I'm using it wrong, and I'll be the first to admit I have the patience of a toddler when it comes to reading the man pages. What I can DEFINITELY say, though, is that if systemd never existed my quality of life would be doubtless better than it does with it existing. That's really the only metric I need.

Like I said: definitely in old man yells at cloud territory, maybe crossed with a dash of lazy man commits to further laziness and myopic man can't see the forest for the trees. I'm not saying you are bad to like systemd, I'm saying that it made changes I didn't ask for, it didn't do it in a way that was painless and approachable without a time commitment, and I've yet to be satisfactorily convinced that the value proposition is worth it - not for my uses, at any rate.

Re: Operating Systems Without Systemd

#163

Post by mekster » Tue, May 05, 2020, 3:35 AM UTC

wtallis wrote: post #20

jbnorth wrote: post #11

Maybe I'm just out of the loop but what is the controversy regarding systemd?

There are many. Most amount to complaints about sysadmins having to re-learn a lot of stuff, much of which didn't actually need to be changed, at least not so thoroughly. Early on, most of the complaints centered around the poor migration path, the abandonment of plain text log files, and the absurdity of high-level user-facing software like the Gnome desktop environment having a hard dependency on a particular init…

> at least not so thoroughly.

So you still thought some updates were supposed to happen but it wouldn't have happened if it wasn't for systemd as people are too lazy to touch any mostly working legacy bits.

Re: Operating Systems Without Systemd

#164

Post by TheGoddessInari » Tue, May 05, 2020, 7:26 AM UTC

microcolonel wrote: post #55

sliken wrote: post #38

Earlier quoted context omitted.

Mostly that it WAY more complicated than it needs to be, and it often replaces well written and tested tools with VERY poor implementations. Things like NTP, syslog, DHCPd, cron, iptables, mount, automount, handling /tmp, /dev, DNS, su/sudo, etc. Letting the init system talk to the network before userspace has the ability to setup firewalls gives me the heebie jeebies. Often the implementations of systemd don't handl…

Most of these things are simply untrue. The idea that homed is "incompatible with SSH" is preposterous. > Letting the init system talk to the network before userspace has the ability to setup firewalls gives me the heebie jeebies. Are these just random claims? The init system is userspace , and you can have any service wait for anything to access the network, including disabling the whole network target and triggerin…

Okay, how do you get the ssh folder contents to validate the remote user, if validating the user is required to decrypt?

You can't. And the systemd answer is that you simply throw away ssh.

Re: Operating Systems Without Systemd

#165

Post by JdeBP » Wed, May 06, 2020, 4:32 AM UTC

tssva wrote: post #151

JdeBP wrote: post #146

Earlier quoted context omitted.

Every time that this argument comes up, people don't get their computer science right. The problem is not whether something has modules. It is the degree of coupling amongst and cohesion within said modules that is the metric. * https://news.ycombinator.com/item?id=19132437 * https://news.ycombinator.com/item?id=19028053

There is significant variety between distributions regarding which systemd project modules are used by default. Many distributions also allow systemd modules used by default to be easily replaced with non-systemd alternatives. This speaks to the level of coupling and cohesion between systemd modules being low enough that they don't form a monolith.

Waving around the terms without understanding them, as you are doing, demonstrates exactly what I mentioned. Someone who actually knew the computer science would not be talking of low cohesion here, or of modules forming a monolith.

Re: Operating Systems Without Systemd

#166

Post by happymellon » Sat, May 09, 2020, 3:54 PM UTC

shawnz wrote: post #138

happymellon wrote: post #128

Earlier quoted context omitted.

What I hate is not that it logs to a journal log, it is that the binary db used by journald is non-standard and undocumented. This means that a dead system can potentially not be read by a live system, as the journal can have undocumented breaking changes.

It is documented, but the documentation is unfortunately not authoritative: https://www.freedesktop.org/wiki/Software/systemd/journal-fi... Also, they couldn't make breaking changes to the format or it would prevent people from reading their own old log files after upgrades

Fuck, not this shit again.

If I get some 3rd party documentation, that says it may or may not be correct, and the implementation is literally the only authorative documentation then it isn't actually documented.

> they couldn't make breaking changes to the format or it would prevent people from reading their own old log files after upgrades

This is the point. They do not guarantee that you can.