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

Systemd, 10 years later (2020)

blog.darknedgy.net

Post reply on HN
Print view View original

151–160 of 332 posts

Re: Systemd, 10 years later (2020)

#151

Post by rahen »

Blikkentrekker wrote: post #71
dharmab wrote: post #58

Earlier quoted context omitted.

For the init system, the most common predecessor was a combination of sysvnit and "initscripts" (a shell script for each daemon on your system). Writing the init scripts was simple for the most basic cases but quite complex for complete, bug free case coverage. A big appeal of systemd for packagers and sysadmins was the relative simplicity of unit files. Now we just have to fill out a simple boilerplate INI style fil…

It was not. There is strange false history that systemd replaced sysvinit, which occurred only on Debian, because Debian was the last major system to discard sysvinit. Gentoo had replaced sysvinit with OpenRC in 2006; Fedora and Ubuntu were using Upstart in 2005. systemd primarily replaced Upstart and systems that used Runit or OpenRC tended to have stayed with them. Frankness be, this false history seems to be craft…

> The issue is whether it compares favorably to Upstart, runit, and OpenRC

I would add S6 to the list, as this would be the better challenger to systemd. That said, I use OpenRC daily on Alpine servers with little to complain about.

Re: Systemd, 10 years later (2020)

#152

Post by zozbot234 »

hedora wrote: post #131
Gigachad wrote: post #82

Earlier quoted context omitted.

Linux users tend to come up with whatever "philosophy" suits their agenda of complaining about all change. The unix philosophy gets thrown out the window as soon as it comes to Wayland which took a huge, bloated, and buggy Xorg and broke it down to something more sane and manageable.

Doesn’t wayland force window managers to be integrated into some behemoth bloated monolith? My preferred WM is evilwm. I read the entire source to it in a few hours, and occasionally edit the source when I want to customize it for my odd workflows. I don’t think that’s possible with wayland. Also, wayland forced a bunch of questionable security policies around screen capture and keyboard handling, and didn’t provide…

> Doesn’t wayland force window managers to be integrated into some behemoth bloated monolith?

Well, the wayland protocols are very poorly documented compared to X. But most WM's have to support a bunch of obscure X extensions to get a reasonable featureset, that bring in much the same complexity as Wayland.

Re: Systemd, 10 years later (2020)

#153

Post by wruza »

Blikkentrekker wrote: post #71
dharmab wrote: post #58

Earlier quoted context omitted.

For the init system, the most common predecessor was a combination of sysvnit and "initscripts" (a shell script for each daemon on your system). Writing the init scripts was simple for the most basic cases but quite complex for complete, bug free case coverage. A big appeal of systemd for packagers and sysadmins was the relative simplicity of unit files. Now we just have to fill out a simple boilerplate INI style fil…

It was not. There is strange false history that systemd replaced sysvinit, which occurred only on Debian, because Debian was the last major system to discard sysvinit. Gentoo had replaced sysvinit with OpenRC in 2006; Fedora and Ubuntu were using Upstart in 2005. systemd primarily replaced Upstart and systems that used Runit or OpenRC tended to have stayed with them. Frankness be, this false history seems to be craft…

And we can excuse Debian for that, because it was an OS of choice for those who plan to run things for a decade or two. If Debian included modern web frameworks into the distro, most of them wouldn't make it into stable.

Re: Systemd, 10 years later (2020)

#154

Post by GekkePrutser »

cfors wrote: post #21
wrycoder wrote: post #17

Earlier quoted context omitted.

Right. I have a simple rule: don’t use a GNU/Linux system that uses systemd. It doesn’t respect the Unix philosophy. It’s trying to turn it into Windows. I’m waiting for Microsoft to buy Red Hat. Failing that, IBM.

IBM already purchased red hat for $34b 3 years ago, so no need to wait any longer :)

I think he means that MS would buy IBM and RedHat with it.

I doubt they will though. Like others have said MS buying Canonical would make a lot more sense. And there have already been a lot of overtures.

Re: Systemd, 10 years later (2020)

#155

Post by [deleted] »

zozbot234 wrote: post #44
an_d_rew wrote: post #23

This was an amazing review, and love systemd or hate it, this article gives a fantastic history and exposition of what systemd actually is . My favorite quote (and when taken in context is much less tongue-in-cheek thank you might think): systemd is an event-driven object manager with dependency-like side effects which ‘boxes’ primitive kernel resources and userspace subsystems into a generic object type called Unit.…

...so, how does a systemd unit definition differ from a Makefile (other than using a different syntax, obviously)? What features would you need to add to UNIX make (and PID 1, for that matter) in order to be able to separate out this whole dependency management business from the other stuff PID 1 has to deal with already?

[deleted]

Re: Systemd, 10 years later (2020)

#156

Post by wruza »

imoverclocked wrote: post #69
akagusu wrote: post #26

I am old enough to remember that problems with systemd were less technical and more political. People didn't like the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency. Unfortunately,people don't remember this today, and think users resisted to systemd adoption only because they didn't like systemd.

Network configuration (on say, Debian) is still a pain and has a lot of different ways of accomplishing similar tasks. Anything beyond the plain vanilla singular network device that is either dhcp/static is often painful. Systemd has some sauce, there is legacy /etc/network* stuff, there are daemons which can be configured graphically… it’s still a mess. In this arena, I think systemd has failed for the last decade.…

For me the best battle test was to set up a re-establishing vpn-pptp (or was it lptp?). The issue was that the daemon, name long forgotten, used a default route to establish a VPN connection, then rewrote it with an in-channel ip received at the handshake. But when it crashed or stalled, the default route didn't exist in the segment anymore and you had to re-dhcp it, somehow automagically detecting the situation.

Wonder if it solved it. If not, what's the fuss.

Re: Systemd, 10 years later (2020)

#157

Post by morelisp »

hedora wrote: post #120
MuffinFlavored wrote: post #49

Earlier quoted context omitted.

Like what if you don't mind me asking, and what did people used to use as an alternative?

Take a look at OpenBSD. They managed to sidestep all this drama, and still ship a sane, well-documented init. If you spend an afternoon installing it and configuring a few network services, you’ll already know most of what there is to know about how init used to work. It used to be extremely elegant and robust. The main flaw in the design was that the “service” files were written in a Turing complete language, which…

> Also, the organizations that somehow couldn’t figure out how to use and maintain traditional init systems were the ones that produced the current generation replacements and pushed them so hard.

This is revisionist. The organizations that built the current generation were those who had to support those who couldn't figure out how to use and maintain "traditional" init systems. Distro init scripts were (usually, and at great effort) decent, whether from Red Hat, SuSE, Debian, etc. (just don't ask too hard about why they were different). But the third-party (often, but not exclusively, proprietary) software vendors looking to support even a single distro were godawful. Eventually the support burden for e.g. Red Hat got large enough it made more sense to replace it wholesale than keep mentoring the latest batch of e.g. Oracle interns in how to write half-decent shell scripts.

Re: Systemd, 10 years later (2020)

#158

Post by justin66 »

ADSSDA wrote: post #135
justin66 wrote: post #121

Earlier quoted context omitted.

> it clearly describes systemd It really doesn’t.

Agree to disagree. Maybe because I've worked in embedded Linux for so long (including on inits of various forms), but that description clearly articulates exactly what systemd is and does and I appreciate the direct, crystal clear technical language rather than some long form essay written assuming a clueless reader with 0 technical background.

You’re pulling my leg, right? The description could be improved, for starters, by forcing the author to not use the word “object.” That overuse alone makes me wonder if the description is satire.

I expect everyone here commenting is familiar with systemd. I doubt very much that anyone who was unfamiliar with systemd and read that description would then have any idea what it does or how it works.

Re: Systemd, 10 years later (2020)

#159

Post by tremon »

xarthna wrote: post #130

I used systemd for a time, and after looking into all the documentation I found it hard to understand and it's scope overreaching. It doesn't stand by the unix philosophy of mechanism not policy and is prescriptive in it's inplementation. As another comment stated, the politics behind how it was pushed never sat right with me and I believe it is leading the Linux community to vendor lock in. I have been using s6 on A…

Another happy s6 user here, and pretty much for the same reasons. I like the clear supervision process tree it creates. I'm not sold on the execline syntax, but it's relatively clean and easy to work with and since I already use a configuration management system, generating custom startup files (from a single template) isn't that much of a challenge.

I'm currently exploring how to generate minimal service environments from Guix package manifests. Being able to spawn svscan as a child under the root supervision tree means I can create each environment with its own service directory, and never worry about cross-contamination from whatever else is on the host.

Re: Systemd, 10 years later (2020)

#160

Post by wruza »

NotAWorkNick wrote: post #92

".... and found that someone was about to release TCP/IP for Linux" (Fred van Kempen, linked interview 1992) Wow. I had forgotten how ropey early Linux was. I mean, I rip on Windows folk about early versions of Windows prior to 98SE or NT4 (and can recall having to install Winsock on a home Win95 install and thinking why the hell????) but finding out 30 years later that my early struggles with Linux were not entirely…

Have a spare generic PC or make sure you didn't mess double boot. Heck, now I don't understand either how we fixed network issues when phones could only play midi or call a friend for support. Good handbooks were a rescue.
Post reply on HN