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

231–240 of 272 posts

Re: Systemd Sucks, Long Live Systemd

#231

Post by astrodust »

nvarsj wrote: post #132
astrodust wrote: post #72

Earlier quoted context omitted.

The idea of systemd isn't bad. What's annoying is the friction involved in using it. It's just a shade too ornate, a little too magical, in both cases only by a small degree, but it's an important one. Creating a workable systemd init script is actually pleasant. Getting it running is easy. Checking for errors with status is nice, but searching the logs is annoying. pm2 ( https://github.com/Unitech/pm2 ) has a neat f…

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.

A) Yes I have had to write init scripts for production servers, and I've had to write whatever the hell they were before we had sysvinit. It wasn't always pleasant. There were times when you'd just edit things like /etc/rc.d/network and hack in some more commands.

B) I'm talking specifically about systemd init files, or whatever they're called. Given that they initialize things, that they replace conventional init files, the term applies.

Re: Systemd Sucks, Long Live Systemd

#232

Post by rdslw »

scrollaway wrote: post #202
jcadam wrote: post #197

Earlier quoted context omitted.

Ah, but did you force others to use your project? People find that sort of thing annoying at best, infuriating at worst, and they will tend to act out in various ways (to include finding fault with the thing they never asked for that's being shoved down their throat).

All my life I've been forced to use things such as Windows, Flash, Skype and Photoshop. Forced because of lock-in strategies in a field with difficult alternatives. "Forced" is not a term that applies to systemd. People say "forced" because their distro adopted it - guess why their distro adopted it? Because they researched it and found it was good. That is the common theme. Nobody forced you. If you're an arch linux…

You're plainly wrong.

1) You write "Most (MOST, not all) of the arguments against systemd are in fact bullshit".

2) And yet you (wrongly) write "there is plenty wrong with systemd"

To be in line with your 1) statement you should write 'it is only small things with systemd which are wrong. Because everything - MOST = small, and not 'plenty'.

Yet you dont do, and you write 'plenty'. Why? Because you know, the moment you write 'there is only a small amount of things wrong with systemd' you will be easily challenged.

So, from logic perspective, you're wrong and you contradict yourself.

Re: Systemd Sucks, Long Live Systemd

#233

Post by detaro »

astrodust wrote: post #230
detaro wrote: post #189

Earlier quoted context omitted.

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

unit files: https://www.freedesktop.org/software/systemd/man/systemd.uni...

Re: Systemd Sucks, Long Live Systemd

#234

Post by ripdog »

rkrzr wrote: post #200
digi_owl wrote: post #150

Earlier quoted context omitted.

Plenty of the "separate" components share core code at compile time. If they were truly separate they could be downloaded piecemeal and compiled independently.

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.

There is systemctl reexec, so can't you upgrade systemd without a reboot using that?

Re: Systemd Sucks, Long Live Systemd

#235

Post by lksgkjhsgkjh »

marcosdumay wrote: post #224
lksgkjhsgkjh wrote: post #153

Earlier quoted context omitted.

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?

Umm, how did you configure networkd to run wpa_supplicant?

Hint: Networkd doesn't run wpa_supplicant. So it can't "hide" anything about it. Or only as much as `ifconfig` "hides" errors from wpa_supplicant.

Re: Systemd Sucks, Long Live Systemd

#236

Post by lksgkjhsgkjh »

JdeBP wrote: post #223
majewsky wrote: post #204

Earlier quoted context omitted.

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

vdev was already given up again:

> This system is mothballed.

From its Github page at https://github.com/jcnelson/vdev

Re: Systemd Sucks, Long Live Systemd

#237

Post by scrollaway »

rdslw wrote: post #232
scrollaway wrote: post #202

Earlier quoted context omitted.

All my life I've been forced to use things such as Windows, Flash, Skype and Photoshop. Forced because of lock-in strategies in a field with difficult alternatives. "Forced" is not a term that applies to systemd. People say "forced" because their distro adopted it - guess why their distro adopted it? Because they researched it and found it was good. That is the common theme. Nobody forced you. If you're an arch linux…

You're plainly wrong. 1) You write "Most (MOST, not all) of the arguments against systemd are in fact bullshit". 2) And yet you (wrongly) write "there is plenty wrong with systemd" To be in line with your 1) statement you should write 'it is only small things with systemd which are wrong. Because everything - MOST = small, and not 'plenty'. Yet you dont do, and you write 'plenty'. Why? Because you know, the moment yo…

If you're going to try to use "the logic perspective" and be hostile for the sake of being hostile, at least have the decency of running your own post through that filter. "Everything - most = small" is a mathematically nonsensical statement.

Of course, you could also tone the hostility down before reading my post. Maybe that'd have helped you catch the fact that a flaw in systemd does not necessarily equal an argument against systemd, and vice versa.

6 years on Hacker News and this is what you've learned?

Re: Systemd Sucks, Long Live Systemd

#238

Post by yrro »

z3t4 wrote: post #138

My main complain about systemd is that it does not log the stderr stream !!

It does log the standard error stream. The default value of StandardError= is inherit, which will cause stderr to go to the same place that stdout goes, which by defaults to journal. This is documented in systemd.exec(5).

If not overriden in an individual service's unit file, perhaps you have set DefaultStandardError= in /etc/systemd/system.conf?

Re: Systemd Sucks, Long Live Systemd

#239

Post by rektide »

takeda wrote: post #73
alyandon wrote: post #56

At first I didn't care much for the idea of having to learn yet another init system but as I had to write ansible automation stuff for services on Centos 7 it was kind of required that I have some basic understanding of systemd. I have to say now that I'm more familiar with it it has begun to grow on me. There is something subjectively nice to me about running systemctl status and seeing a nice, clear picture of what…

No it's nice, the biggest issues are IMO two: * it replaces significant part of the OS and creates a new APIs. It's not really problem of systemd itself, but once other applications start depend on the API you would need systemd to use it. This is especially bad for non-linux systems, like BSD for example, which need to write tools that will emulate such API. It doesn't help that Lennart openly is against any non-lin…

This (creates a new APIs) I feel is very much at the root of many people's dislike. But it's also exactly what was most important for advancing star-nix.

Historically we've had very little for managing processes. Start stop restart is about all we get for public interfaces, and they all involve shelling out via system().

The entire rest of the computing world has gotten immensely rich and powerful and grown. It's grown because there have been APIs. OpenStack, AWS, Kubernetes- once other applications start depend on the API (as you say) things start getting really good and powerful. The API makes it usable, gives the thing having an API programmability.

Process management has not had a decent API until systemd. Now we can write programs that watch for units being started, watch for them failing. Everything, the whole world, suddenly has a consistent well integrated API. It's appalling to me that people would disfavor this, when the past has been a bunch of hand jammed /etc/init.d/ scripts with varying capabilities and little introspectability.

I agree that being non-Linux is absurd and unfortunate. There really can't be that much special sauce that was relied on. Umass-PLASMA group has systemgo which is an interesting alternative, imo. https://github.com/plasma-umass/systemgo

Re: Systemd Sucks, Long Live Systemd

#240

Post by merb »

lksgkjhsgkjh wrote: post #185
dsr_ wrote: post #177

Earlier quoted context omitted.

Then perhaps networkd should be dropped, because: repeat after me: everything eventually fails. How can you tell when a programmer has graduated from "completely new at this" to "has some valuable experience"? That point comes when they stop assuming success. Check for error and do something useful with the returned value. Write tests yourself. Fail gracefully. Log status, so you know what was happening just before i…

`ifconfig`, `ip`, `dhclient` or Debian's `ifupdown` don't care about errors from wpa_supplicant either. Let's drop them too? Or actually all of them (including networkd) work fine, but are not the right tool for every usecase.

well ifconfig (net-tools) actually is not pre-installed for fedora > 19 or 20, basically because not everybody uses them and ip addr gives a more simple output for (most users)
Post reply on HN