Live data from Hacker News

Systemd 252

github.com

121–130 of 317 posts

Re: Systemd 252

#121

Earlier quoted context omitted.

I'm not a Linux expert, but I thought that systemd was generally hated?

On my laptop, systemd is awesome; I love it. Everything works together nicely. On my servers, systemd gets in my way, tries to do too many things, and gets in my way more then it helps. On a laptop things are much more dynamic. From sleep/hibernation/wifi-LAN-wifi (+/- VPN) switching/etc.... these fiddly bits were much harder to manage on Linux for DECADES then they are now. The reboot interval on laptops is huge com…

Systemd should never be used on a server. Or any other desktop init system for that matter.

Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations.

A production filesystem should contain a kernel, an init binary, and either a container runtime or a static binary of your target application. At most a production init binary just needs to setup virtual filesystems and be a reaper for a target application binary.

Re: Systemd 252

#122
post #100

Earlier quoted context omitted.

I'm not a Linux expert, but I thought that systemd was generally hated?

A couple years ago, absolutely. To decide whether to generally hate systemd, and with what intensity, you should follow a curve that decreases proportionally with how long ago the change was made, and that starts as high as the multiplication of how much churn it causes times how old the thing it replaced was, all of which is of course multiplied again against the buggyness curve When pipewire replaced pulse, despite…

It's worth remembering that much of the churn was caused not by having to rewrite configuration, but by the multitude of bugs that plagued systemd early on, and the way they were treated did not help. systemd upstream was extremely difficult to work with and made a lot of people reluctant to embrace change, because when something didn't work -- which we all understood was natural for software developed in the open -- you were pretty much screwed. Shell scripts and duct tape were bad but it could take less time to fix something than it took to get people "up there" to admit that they're really looking at a bug, not a feature.

I ran systemd very early on because it gave me some things I liked from SMF but I completely understand why so many people hated it. It's a (suite of) program(s) with good ideas that was hampered by extremely poor maintainership and relation with other open source projects.

Re: Systemd 252

#123
post #94

Earlier quoted context omitted.

Never had this issue. Sounds like they need to recreate the symlink.

It apparently needs specific tweaking for lxd: https://linuxcontainers.org/lxd/docs/master/howto/network_br...

Maybe I'm wrong, but that just seems to show that if you want to resolve lxd domains (hostnames?), you need to inform systemd-resolved to ask lxd for those domains, which is... sensible?

> you should notify resolved of the domains that LXD can resolve

You'd have the same issues if you replaced systemd-resolved with e.g. dnsmasq. Split DNS always needs resolver configuration.

Re: Systemd 252

#124
post #118
post #2

Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.

I'd argue the success of the Steam Deck is evidence of the Linux desktop's maturity. The normal game UI is just another Wayland session, and it's a fully functional PC running Arch Linux. KDE is installed and easily accessible.

I'd say the success of the Steam Deck is a testament to the maturity of the Windows API[0]. Old enough and reliable enough that it is a better target for games on Linux than Linux Desktop's own shit show.

[0] and of course the efforts of the WINE project and proton.

Re: Systemd 252

#125

Earlier quoted context omitted.

Not sure I fully understand this argument. Can you expand? I'm not familiar with nohup and its role.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/n... blocks SIGHUP and captures output in a file. That lets me type nohup ./long_batch_job.sh & and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost. systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end use…

Today you still have this functionality as an unprivileged user via systemd --user units in .config. Unlike nohup you get proper logging and processes can even restart automatically on reboot if you want.

Re: Systemd 252

#126

It feels like the time is ripe for something simpler and more modern to replace* systemd. The timing of this release coincides with me being bitten with yet another bug** on the weekend. How long until “Systemd: The Good Parts”? *The most trivial new name would be système which would at least be in keeping with the French naming. **In Debian stable if you create a new user, ssh in as that user, logout, then delete th…

It happened for PulseAudio, perhaps something compatible but leaner can emerge for systemd.

It happened to Pulse after the project stopped being a moving target. Just look at the changelog of this systemd release.

Re: Systemd 252

#127
post #59

I love systemd for everything except its cron replacement, somehow it's a real mess. Yet I desperately want something more modern to play with journald well. Any advice?

Systemd timers are more complicated than cron, but there's a reason for the complexity. Once you've put in the extra effort to understand the logic, they're really powerful.

If you don't want the complexity, then just run crond.

Re: Systemd 252

#128
post #2

Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.

...the year of the Linux Desktop I keep wondering about this year of the Linux Desktop. So often I see it used as a snide towards Linux users (not by you). I think it shows naivety. What does it mean? Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with…

> Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable.

Damning with faint praise. The success of Linux gaming is due to the efforts of projects that re-implement Windows APIs, and things moving to the web are obviously not targeting Linux either.

Re: Systemd 252

#129
post #2

Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.

+1 for systemd-networkd too: it let me declaratively describe some netns/ipvlan interfacing the other day that netplan et al simply couldn't. It could use with some more netns awareness but its pretty great at the current stage

systemd-networked + systemd-resolved is also really awesome.

It lets you configure DNS Server per link and resolve only certain domains via a specific DNS Server configured from a link.

e.g. multiple customer specific wireguard Tunnels that resolve the specific project related domains, but dont resolve all your other DNS.

Re: Systemd 252

#130
post #123
post #94

Earlier quoted context omitted.

It apparently needs specific tweaking for lxd: https://linuxcontainers.org/lxd/docs/master/howto/network_br...

Maybe I'm wrong, but that just seems to show that if you want to resolve lxd domains (hostnames?), you need to inform systemd-resolved to ask lxd for those domains, which is... sensible? > you should notify resolved of the domains that LXD can resolve You'd have the same issues if you replaced systemd-resolved with e.g. dnsmasq. Split DNS always needs resolver configuration.

I think it's just someone unhappy that they used to be able to edit resolve.conf before systemd-resolved took it over. I recall being annoyed about it as well, but that was some time ago.
Post reply on HN