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

141–150 of 332 posts

Re: Systemd, 10 years later (2020)

#141

Post by dijit »

Blikkentrekker wrote: post #65
pengaru wrote: post #45

Earlier quoted context omitted.

It's not like systemd is written in deliberately obfuscated C or something inscrutable altogether like Brainfuck. A monorepo containing well-organized boring C, developed on github of all places, is the polar opposite of raising the barrier to contributing vs. what was replaced. Full-disclosure: I contribute to systemd.

Of course, but I would not like to have to patch it to modify something that on other systems can be modified with either a configuration option, or a shell script. To me, the most poisonous example that contrasts the traditional design with Freedesktop's design is acpid contrasting logind. In the former case, an acpi event is sent, and acpid simply executes a file such as `/etc/acpi/action/lid_down.sh`. That file ca…

And this means we can’t do things like force disconnect an eGPU or whatever on acpi events.

I think I figured out my issue with systemd. It does not apply Chesterton Fence when redeveloping things… and how could it, when it redevelops so much.

Maybe it’s fine if it’s all you’ve ever know (or you never hacked on your system) but those that did have lost something.

Re: Systemd, 10 years later (2020)

#142

Post by GekkePrutser »

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…

Yeah OpenRC is pretty great and much lighter than systemd. It's way better than sysvinit. Less daemons running than systemd and it doesn't try to be more than just an init system. I use alpine on all my servers for this reason. And because it's so minimalistic as a distribution, I can just install what I need and nothing else at all. On a desktop system with the OS being suspended, USB devices coming and going systemd makes more sense I think.

But on the desktop I use FreeBSD which has a different system again.

By the way alpine is also working on a full service manager init system (like systemd) but more minimalistic, based on s6 service manager. Looking forward to seeing how that pans out.

https://skarnet.com/projects/service-manager.html

When something comes from the alpine team I have a much higher confidence that I'll like it than from RedHat :) I don't care for Gnome either as it has become so opinionated.

Re: Systemd, 10 years later (2020)

#143

Post by wruza »

10 years and I still can't figure out how to view custom service logs, darn, so I redirect them into a logfile.txt in my .service files. Well, okay.

I don't care how it works and didn't take part in condemning it back then either, and I think that probably it made something better (? not that I felt it), but from a pure sudo-user perspective it is a strange ini-based tech-ridden(?) launcher to me. I've managed small networks before it and haven't really experienced any trouble that it supposed to remove(?).

Tldr: I still don't know what it is and what is it for. Servers worked before and after it, maybe that is already a good experience.

Re: Systemd, 10 years later (2020)

#144

Post by tremon »

CogitoCogito wrote: post #84
Spooky23 wrote: post #67

Earlier quoted context omitted.

Exactly. “Idempotent” is one of the key words used as a cudgel in this way. It’s great for the bullshit artist, as to a layman the dictionary definition is completely inscrutable.

> Exactly. > “Idempotent” is one of the key words used as a cudgel in this way. It’s great for the bullshit artist, as to a layman the dictionary definition is completely inscrutable. Are you saying that being "idempotent" is completely inscrutable? Is it not a fairly straight-forward concept?

If we're going to be pedantic, "idempotent" (or rather non-idempotent) as used in the description is rather vapid and meaningless. Idempotency is a quality that describes the result of an action; as such, only actions can be thought of as idempotent. Applying the word idempotent to any noun that does not describe an action (such as "dataflow" in this case) is meaningless.

What does it mean for a dataflow to be idempotent in the first place? What purpose does it then serve to describe a dataflow as non-idempotent? What they meant to say, I guess, is that the dataflow may contain multiple actions for the same unit, and that systemd makes no guarantees about the end state of the unit in such a case. But even then, it is the execution which should be described as non-idempotent, and not the dataflow.

Re: Systemd, 10 years later (2020)

#145

Post by zozbot234 »

vanviegen wrote: post #94
Blikkentrekker wrote: post #65

Earlier quoted context omitted.

Of course, but I would not like to have to patch it to modify something that on other systems can be modified with either a configuration option, or a shell script. To me, the most poisonous example that contrasts the traditional design with Freedesktop's design is acpid contrasting logind. In the former case, an acpi event is sent, and acpid simply executes a file such as `/etc/acpi/action/lid_down.sh`. That file ca…

Although I like the acpid approach, the logind way is probably safer to abstract behind a user friendly GUI. That's what most people will be using. :-/

> the logind way is probably safer to abstract behind a user friendly GUI.

How so? The canonical solution would be to ship a default `lid_down` script that could take the currently-active policy as set by the GUI as an input. But the nice thing is that adding/tweaking policies is a fully-supported operation, you just edit the script and the GUI config mechanism to support them.

Re: Systemd, 10 years later (2020)

#146

Post by massysett »

taftster wrote: post #91
imoverclocked wrote: post #69

Earlier quoted context omitted.

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

Yes, this. The problem with systemd isn't systemd. It's that it never really replaced the other "legacy" parts effectively. Networking is a fantastic example. I'd be OK if there was one-definitive-place to configure networking, but when I read an article or follow a stack-overflow post, I'm not sure if what I'm changing is the most correct change or if its deprecated in favor of something newer. Systemd, I thought, w…

Isn’t the number one problem here that you’re following a Stack Overflow post? Your system should have good documentation on how to configure networking, or some obvious sanctioned way to do it, such as a GUI widget. If your system has neither, that’s the problem. If it has one or the other and you’re using Stack Overflow anyway, that’s the problem.

Note I said “good” documentation - many Linux systems have lousy documentation and they lack an obvious, sanctioned way to do it. Again, that’s the problem.

Re: Systemd, 10 years later (2020)

#147

Post by hanselot »

eslaught wrote: post #32
a-dub wrote: post #12

Earlier quoted context omitted.

it's kind of like locked bootloaders and pentalobe screwdrivers for organizing a unix system where most users were used to easy to inspect and modify scripts and single purpose programs . yes, it's still open source, but modifications and inspection are far more complicated creating a much higher barrier to entry. in the earlier days when it was still buggy, even linus himself was screaming about not being able to ea…

I have to hard disagree on this one. As someone who had half a foot in sysvinit, half in upstart, and half in systemd (don't try to do math with those numbers), sysvinit was always the hardest to use by wide margin. It was ridiculously complicated to get anything nontrivial to work. It was error prone, and the number of corner cases you had to think about was extreme. And the worst part was I kept having to relearn i…

No post body was provided.

Re: Systemd, 10 years later (2020)

#148

Post by crazy_hombre »

jcrawfordor wrote: post #77
Denvercoder9 wrote: post #66

Earlier quoted context omitted.

> If you are doing something weird it can make your life a living hell. I find it much easier to reliably accomplish non-standard things with systemd unit definitions, than it used to be with the ill-defined complex set of shell scripts we had before.

This issue is a lot bigger outside of services... I think the systemd service architecture is a clear improvement over SysV. The bigger issues I run into with systemd flexibility are related to the many other aspects of it. systemd-resolved, for example, has a very "opinionated" (to be polite) set of expectations about the environment and the systemd project tends to view any complaints about it not working outside o…

There's no such thing as systemd-firewalld.

Re: Systemd, 10 years later (2020)

#149

Post by Gigachad »

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…

What Wayland changed is that Wayland is not a piece of software like Xorg was. It is simply a specification. Which means you don't have potentially have a 100 line C program as your wm which just relies on xorg to do the heavy lifting.

KDE and Gnome have their own wayland implementation but this isn't really a problem. You can still write you minimal WM because their is a project called WLRoots which does the same job as the old x11 package. It lets you trivially interact and be compatible with the wayland spec without having to implement it yourself.

Screen capture and keyboard privacy is essential for the future of linux IMO. I don't know the exact state of it but I did not have any issues screen sharing with wayland compatible apps. There were some issues with x11 only apps but I think PipeWire solved that.

Re: Systemd, 10 years later (2020)

#150

Post by hanselot »

shawnz wrote: post #115
a-dub wrote: post #112

Earlier quoted context omitted.

just like pentalobe screws! i'm not going to argue it's a bad thing, i actually really like macs and think they hide a lot of details making time and space for other pursuits, although since you cede user serviceability it's important to purchase a service plan and that you don't try anything that wasn't provided for in the design. maybe simple composable parts are past their prime. i always loved the simplicity of i…

> i always loved the simplicity of inetd. it was both self describing and inclusive. you could write an internet service without any knowledge at all of sockets and learn about the system by simply looking at it. You could achieve the same thing with systemd socket activation :)

No post body was provided.
Post reply on HN