Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd Sucks, Long Live Systemd

naftuli.wtf

Post reply on HN
Print view View original

221–230 of 272 posts

Re: Systemd Sucks, Long Live Systemd

#221

Post by jononor »

majewsky wrote: post #201
yjftsjthsd-h wrote: post #187

Earlier quoted context omitted.

Ad hominem aside... "journalctl -u sshd -f" is not straightforward because it's a _redundant_ new command when I already know grep and tail. Small tools handling text is a wonderful way to make a system easy to learn and powerful to use, and we're just throwing that out.

You still have it good. I'm already flipping forward and backward between tail/less on the legacy systems, journalctl on the current systems, and `kubectl logs` on the new systems.

Got myself some "docker logs" and "heroku logs" also...

Re: Systemd Sucks, Long Live Systemd

#222

Post by Elhana »

traviscj wrote: post #215
rkrzr wrote: post #200

Earlier quoted context omitted.

This is indeed an issue in practice: I recently wanted to use the "systemd-journal-gatewayd" component in Ubuntu 16.04, which ships with systemd v229. Yet, the feature I needed was only available in v231. Although I'm only interested in a newer version of "systemd-journal-gatewayd" there is no way to upgrade just this one component, it seems.

I don't get this. How do you know that the v231 for that component will work with older versions of everything else? If you do, why not just compile it yourself? If you don't like that, why not upgrade everything to v231?

That is the point - you often can't just recompile journald part, because it is tied to systemd interfaces and you might not be able to easily upgrade systemd, because it is a production system you can't simply reboot like your home server. The only way to do that is backporting specific patches to the older version.

If it were a separate component, it would have a bunch of ifdefs covering several versions of systemd, possibly with some features disabled if older version doesn't support it. However, that somewhat increases code complexity for developers and systemd devs refuse to do that.

That is the point of 'monolithic' criticism - despite being many binaries, you can't easily just build single one and make that work.

Re: Systemd Sucks, Long Live Systemd

#223

Post by JdeBP »

majewsky wrote: post #204
srslack wrote: post #167

Earlier quoted context omitted.

>they tell other people who do know systemd that they do not know it. I appreciate the concern, thanks. >The journal cannot be turned off. The persistent binary logging is turned off, which is what people bitch about. Obviously, many of systemd's monitoring features are tied to the journal, and as stated journald still needs to be running, obviously writing to a non-persistent journal for these and forwarding logs (i…

Is udev optional on any Linux system? (Okay, you probably don't need it on embedded, but then you likely won't want to afford systemd anyway.)

Yes. For starters, vdev and mdev exist.

* https://news.ycombinator.com/item?id=11302557

* https://news.ycombinator.com/item?id=11609980

Re: Systemd Sucks, Long Live Systemd

#224

Post by marcosdumay »

lksgkjhsgkjh wrote: post #153
semi-extrinsic wrote: post #129

Earlier quoted context omitted.

Yeah, but I'm sure you agree networkd should propagate errors from wpa_supplicant such that they reach the user, instead of piping them to /dev/null (not literally, but you get my point)?

networkd doesn't know about wpa_supplicant, just as it doesn't know about openvpn, vpnc, ... If you want a network manager that does know about those and might give more helpful error messages if they fail, use for example NetworkManager.

And "not knowing about" a service is enough of an excuse to hide any errors of those services it's configured to run?

Re: Systemd Sucks, Long Live Systemd

#225

Post by JdeBP »

rleigh wrote: post #210
skissane wrote: post #63

Earlier quoted context omitted.

I'm not going to defend everything xenadu02 said, but I think there were some points that resonated with me even though I agree they could be expressed more constructively. > Why does ls do sorting? Why does grep do -R recursive searching? How is that "Do one thing and do it well"? I think these are valid examples of how Unix itself fails to follow the "Unix philosophy" of "Do One Thing and Do It Well". > The fork/ex…

Regarding ACLs, I'd say that there's little choice here: it has to be NFSv4. The rationale for this is that POSIX ACLs are firstly too simple to model what we need. And they are also non-standard (POSIX .1e ACLs are a DRAFT specification which was never ratified). NFSv4 ACLs are vastly more featureful, already implemented to support NFSv4 in kernel, though not available in userspace AFAICT. On FreeBSD and other platf…

The irony is that whilst the standards document was never ratified most people implemented it anyway. So actually, they are a standard. (-:

Re: Systemd Sucks, Long Live Systemd

#226

Post by marcosdumay »

tannhaeuser wrote: post #135

Best thing of systemd is that it's putting people behind alternate systemd-free Linuxen. Devuan, Alpine, Gentoo, Void (and particularly the BSDs) come along nicely. I can tolerate systemd on desktops as long as I don't have to deal with it. The moment it craps out with Java-esque error traces in binary logs I'll install Slackware (or is there a modern desktop Linux without systemd I'm not aware of?). Other than for d…

Is any of those as easy to upgrade as Debian?

Because on servers, even the huge repository isn't that much of a gain. But running "apt-get upgrade" beats rebuilding a machine by orders of magnitude. Even more for rented VPS where I must either add an instance or get downtime.

Re: Systemd Sucks, Long Live Systemd

#227

Post by felixgallo »

jcrites wrote: post #71
felixgallo wrote: post #62

Earlier quoted context omitted.

You missed the point completely, I'm afraid. The point was that it's a leaky abstraction composed of half implemented concepts that devs have to add to their brain. It does not replace the existing functionality or improve it.

Respectfully, actually, I think you missed the point. Linux itself offers a number of powerful features such as namespaces to isolate programs, capabilities that can be dropped, etc., including the User Namespace feature we're discussing presently [1]. Systemd's job and goal is to provide a simple configuration file format that makes it easy to enable these features with installed system daemons. You may overlooking…

With all due respect, I'm afraid you're addressing a series of unrelated points and indulging, hopefully unintentionally, in a rhetorical smokescreen, which includes editing your original post to hide an important topic.

I'm aware of what systemd claims to be. I'm aware of the benefits that its fans claim it, and it alone has.

My criticism is not with the Linux kernel (!?!) or user namespacing as a concept. My criticism is that systemd takes all of the rich complexity of user namespacing and, in response, adds the flag 'PrivateUsers=yes' -- a boolean. That's not what user namespacing is for and now we have two problems: systemd, which has no business making that decision and has done it the wrong way, and the continuing need, which has not been solved by a boolean flag, for daemons to have competent, complex user namespaces. Now devs have to know both ways: the half-assed way, and the real way, instead of just having a tool that gives them the real way.

That's what we in the software design business call a shitty design that would make Guy Fieri blush. But I guess we're all in Flavortown now.

Re: Systemd Sucks, Long Live Systemd

#228

Post by bitwize »

krylon wrote: post #117

At the risk of sounding heretical, I kind of find myself in the middle ground regarding systemd - I was initially highly skeptical of it, and I still think it's problematic that it is so Linux-centric and will cause problems maintaining software to run both on Linux/systemd and on *BSD. The way it was pushed on distros was problematic, in my opinion. But having used a couple of Linux systems running systemd - Raspian…

> The way it was pushed on distros was problematic, in my opinion.

The technical term for this is "precommitment", and it comes from Tom Schelling. It's actually quite advantageous: once you're precommitted to a particular direction, you're emotionally invested in getting the most out of it. By precommitting you to systemd, the distros hope to get the community to leverage systemd's benefits.

Re: Systemd Sucks, Long Live Systemd

#229

Post by igor47 »

otabdeveloper wrote: post #94
FeepingCreature wrote: post #14

I'd probably respect SystemD a lot more if it measured itself against a modern init system like Gentoo's OpenRC instead of pretending it's invented dependency handling. https://wiki.gentoo.org/wiki/Comparison_of_init_systems > OpenRC provides a number of features touted as innovative by recent init systems like systemd ...

Systemd isn't an init system, it's a service (a.k.a daemon) management daemon. Its primary purpose is to restart and diagnose failing daemons cleanly. Systemd won for one simple reason: it's the only tool that accomplishes this task without bugs. We've been running daemontools for almost a decade in production, and it's a nightmare of bugs. Very glad to be finally switching to systemd.

> Its primary purpose is to restart and diagnose failing daemons cleanly...it's the only tool that accomplishes this task without bugs.

I've been running runit in production for many years, and it does just this, flawlessly.

Re: Systemd Sucks, Long Live Systemd

#230

Post by astrodust »

detaro wrote: post #189
nvarsj wrote: post #132

Earlier quoted context omitted.

I'm not sure how you could write this with a straight face. Systemd has friction, but writing init scripts doesn't? Are you kidding me? Have you ever had to write init scripts for production servers? Writing systemd unit files is entirely more straightforward and simple than any init script hackery. And how is "journalctl -u sshd -f" not straightforward? Systemd has its issues sure, but your comment is pure FUD.

Given that astrodust was mentioning " systemd init script" I'd think they are praising unit files and just got the terminology "wrong"...

What are they called, anyway? I know them as "that crap that lives in /etc/systemd where you can define services in easy to read INI-like files".
Post reply on HN