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

201–210 of 272 posts

Re: Systemd Sucks, Long Live Systemd

#201

Post by majewsky »

yjftsjthsd-h wrote: post #187
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.

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.

Re: Systemd Sucks, Long Live Systemd

#202

Post by scrollaway »

jcadam wrote: post #197
scrollaway wrote: post #181

Earlier quoted context omitted.

It's kind of annoying reading people lecturing projects they clearly don't know the internals of on how much better their code would be if they did X. This applies not just to your comment here but to a ton of comments that pop up on HN all the time. Why not in Go? Why not in Rust? Why not in React and node and electron and why don't you use my library that's still in alpha? It's not OOP. You're not using tabs. MIT i…

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 user, for example, one of the distros that switched the earliest, you'd have been more than welcome to discuss counter-points to systemd on the mailing list.

Of course, most of those that attempted doing so were ridiculed out because in free software, or at least on the Arch ML, there is very little tolerance for bullshit. Most (MOST, not all) of the arguments against systemd are in fact bullshit. Hell, even on HN I've seen people crap on systemd because "it's lennartware".

PS: To be clear, there is plenty wrong with systemd. It's far from perfect, it's still very young and I'm not particularly fond of its "all in one" tendencies myself. But most people in this thread have clearly zero ground to comment on its internals, yet many do.

Re: Systemd Sucks, Long Live Systemd

#203

Post by throw2016 »

rkangel wrote: post #165
microtonal wrote: post #152

Earlier quoted context omitted.

I am also in the middle ground, but I have moved from the opposite direction. I used to like systemd a lot, especially for its simple unit files (compared to ugly System V shell scripts) and the fact that it could properly track processes and restart them on failure. I have become a bit more skeptical, because most of the problems that I recently had seemed to be related to systemd. Including some networking problems…

> The most annoying part is that some of the problems take quite a bit of work to debug due to the opaque nature of modern systemd/d-bus/...-based systems. This is a reasonable criticism of systemd. The other points seem mostly to be a criticisum of the various distro implementations that use systemd. The sort of thing that gets tidied up over time anyway.

The bigger question is whether an init should be a continuously developed project with rapidly increasing scope as now various distributions are on differing versions of systemd with widely varying compatibility and feature sets.

Re: Systemd Sucks, Long Live Systemd

#204

Post by majewsky »

srslack wrote: post #167
JdeBP wrote: post #159

Earlier quoted context omitted.

> you can turn off the binary logging Every time that people write that they tell other people who do know systemd that they do not know it. The journal cannot be turned off. Making it be stored in files in /run/log/journal/ instead of in files in /var/log/journal/ is not turning it off . It's making it non-persistent so that it doesn't last across system restarts, delegating the job of writing persistent logs to pos…

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

Re: Systemd Sucks, Long Live Systemd

#205

Post by msimpson »

nvarsj wrote: post #130

I get the feeling anyone who complains about systemd is just a hobbyist jumping on a hate bandwagon. For anyone who manages production systems, systemd is a godsend compared to the homegrown-per-distro shell based init systems.

Did you actually read the article or just these comments?

Re: Systemd Sucks, Long Live Systemd

#206

Post by koverstreet »

marios wrote: post #158
otabdeveloper wrote: post #94

Earlier quoted context omitted.

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.

systemd works somewhat ok for me, because I decided to stick to a very limited subset of the functionality it attempts to provide. I've also used runit (which follows the daemontools model) as a service manager and I've never had an issue with that. I may just have been lucky though. For me systemd fails because of some bugs I have repeatedly experienced: - systemd stops reaping zombies for some reason; the OS's PID…

if you need to hard reset remotely, and you've still got a shell:

# echo b > /proc/sysrq-trigger

Re: Systemd Sucks, Long Live Systemd

#207

Post by msimpson »

Personally, I love Systemd for Web development as it makes the job of managing Node.js projects a breeze. I simply pack a Systemd unit file into a project's repository as part of its multi-environment configuration and construct deployment tasks to copy, enable, then start the unit file.

1. Copy to the sever, which looks like:

  [Unit]
  Description= Service
  After=network.target

  [Service]
  Restart=always
  StandardOutput=syslog
  StandardError=syslog
  SyslogIdentifier=node-
  User=
  Group=
  WorkingDirectory=/srv/node//current/
  Environment="NODE_ENV=production"
  Environment="PORT=2580"
  ExecStart=/usr/bin/node server.js

  [Install]
  WantedBy=multi-user.target
2. Enable the unit file in place:

  sudo systemctl enable /srv/node//config/
3. Start the unit file:

  sudo systemctl start
And, of course, destroying that deployment is just as easy.

Re: Systemd Sucks, Long Live Systemd

#208

Post by sevensor »

pawadu wrote: post #169
microtonal wrote: post #152

Earlier quoted context omitted.

I am also in the middle ground, but I have moved from the opposite direction. I used to like systemd a lot, especially for its simple unit files (compared to ugly System V shell scripts) and the fact that it could properly track processes and restart them on failure. I have become a bit more skeptical, because most of the problems that I recently had seemed to be related to systemd. Including some networking problems…

I think systemd would benefit from a slower adaptation. The network and boot issues that practically everyone have encountered are mostly due to incorrect default configurations. This shows that the maintainers are not ready to use systemd as they don't yet fully understand it.

Like PulseAudio in its early years, systemd bothers a lot of people because it was pushed out before it was quite ready, and therefore breaks things that used to work. But also like PulseAudio, it solves a whole lot of problems for which the solutions were becoming increasingly hacky and unstable. I don't believe a slower roll-out would have helped in either case, because many of the issues were undetectable without a broad user base.

Anti-Lennart partisans would say here that both pieces of software are broken by design and leave in a huff. I sympathize with their aversion to complexity, but I'll take a complex init system and simple configuration over a simple init system with baroque configuration.

Re: Systemd Sucks, Long Live Systemd

#209

Post by aaronmdjones »

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…

> (or is there a modern desktop Linux without systemd I'm not aware of?)

I've been using Linux Mint, Debian Edition, as my main workstation OS for more than 3 years now.

It has systemd, but does not use it as init; it has a Makefile-style boot process as far as I know.

Re: Systemd Sucks, Long Live Systemd

#210

Post by rleigh »

skissane wrote: post #63
jjnoakes wrote: post #50

Earlier quoted context omitted.

Most of the statements aren't really conducive to rebuttals because they are lacking substance. But I can imagine what xenadu02 might have meant, if you like, and provide some counter arguments. Signals aren't "garbage" (whatever that means). Signals can call APIs (the set of async-signal-safe APIs). They can't call non-async-signal-safe APIs not because of threads, but because signals can interrupt a routine at any…

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 platforms using ZFS, they are also used by ZFS and are directly exposed to userspace, making rich ACLs usable as the default permissions model system-wide when running on ZFS. Linux, unfortunately, doesn't yet do any of this, even when using ZFS.

Post reply on HN