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

221–230 of 332 posts

Re: Systemd, 10 years later (2020)

#221

Post by xarthna »

rfraile wrote: post #214
tremon wrote: post #159

Earlier quoted context omitted.

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

Any distro with s6 as default init manager?

I'm not sure of any distros that have default s6, but Artix[1] allows you to pick your init/service manager. It is what I used and I am very happy with it.

[1] https://artixlinux.org/

Re: Systemd, 10 years later (2020)

#222

Post by jcrawfordor »

crazy_hombre wrote: post #148
jcrawfordor wrote: post #77

Earlier quoted context omitted.

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.

Yeah, sorry, I'm blaming more on Poettering than is really fair. But firewalld is closely coupled with the overall systemd architecture and the projects are interconnected.

Re: Systemd, 10 years later (2020)

#223

Post by phendrenad2 »

The systemd "culture war" is just a side-effect of the hegemony server Linux enjoys over desktop Linux.

A very small percentage of sysadmins really care about what init system is running on their servers. If you look at who's forking distros and making systemd-free variants, and look at who the vocal anti-systemd users are, they're overwhelmingly desktop-focused users. But this is strange because desktop Linux barely needs an init system at all. The long-running daemons on a desktop Linux system only need be started on startup, if they crash, restarting them is unlikely to leave the system in a workable state anyway.

However, because server Linux dominates the Linux ecosystem discourse and distro news, people have an inflated view of how important these components are.

So my take-away has been: it's safe to ignore systemd criticism, since it's overwhelmingly coming from hobbyists who have no real use for an init system anyway.

Re: Systemd, 10 years later (2020)

#224

Post by spc476 »

tomxor wrote: post #175
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.…

> Network configuration (on say, Debian) is still a pain What specifically is a pain? Have you used it recently? Maybe my end-user desktop network requirements aren't complex enough but it's been pretty damn smooth in my experience for the last few years. I used to avoid network-manager with wicd, but now it seems pretty stable. I use the network-manager and network-manager-gnome packages to get the toolbar thingy in…

I recently installed two Linux VMs on my laptop. One, running the latest Ubuntu, got the network interfaces (yes, I have two defined) working as I wanted. The other one, running CentOS 7.9 (because that's what we're stuck with at $JOB) doesn't, with the same network setup. Both are using systemd (something I've tried to avoid as I'm very old school when it comes to Unix administration [1]) and I've yet to figure out what is going on. The set up is easy, first interface, non-NAT, gets address via DHCP. Second interface, NATted through the laptop. CentOS interfaces are completely borked upon boot up, and it takes about 10 minutes of constant enabling/disabling the interfaces to get them "up". Pre-systemd, I might have had a chance to just hard code the network settings (which would work for my setup). These days? I'm feeling more and more computer illiterate as time goes on.

[1] I'm a developer who can admin a Unix system if forced to, but how to administrate Unix has changed at least three times since I first learned in the mid 90s, and I'm tired of the constant changes (shakes my old-man fists at the sky).

Re: Systemd, 10 years later (2020)

#225

Post by arpa »

eadmund wrote: post #191
ChuckMcM wrote: post #170

Earlier quoted context omitted.

" For me and most users, the transition was fully imperceptible." So far. I hope for your sake it continues to be so.

'I am altering the deal, pray I do not alter it further.' --Darth Lennart I actually appreciate, now, what systemd is trying to do, but I am not certain why it has to take over home directories and everything else to do it. And I am really uncertain why it has to have such bad taste. I can get why it uses C, even though IMHO that is a mistake. But .ini files? D-Bus? XML ‽‽‽ Oh well, at least it's not YAML.

No post body was provided.

Re: Systemd, 10 years later (2020)

#226

Post by rixed »

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…

acpid vs logind is another illustration of the trade offs involved when moving towards GUIfication of the bazar that is (was?) unix.

Basically the proposition is akin to a weapon exchange program: hand over your powerful but dangerous Turing complete configuration language in exchange for nicer looking desktops.

Who would not prefer a better looking desktop?

Re: Systemd, 10 years later (2020)

#227

Post by junon »

The only bit about SystemD I'm not fully sold on is D-Bus. I love that everything is exposed via D-Bus, but the C API is incredibly difficult to reason about. I've tried writing some higher-level bindings for it and it's still pretty difficult to get right.

Perhaps at some point they'll switch to something that's established instead of maintaining their own IPC protocol.

Re: Systemd, 10 years later (2020)

#228

Post by vladvasiliu »

roenxi wrote: post #194
marcodiego wrote: post #3

Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.

> the transition was fully imperceptible A normal user will never really link the features they see or do not see back to the init system. I'll draw a parallel with the worst subsystem being cut out of modern Linux - X Windows. As far as I can tell Linux is missing good macro systems that can record actions taken by a user, then replay them. For loops for non programmers, basically. This isn't because the idea is rad…

> Similarly, the monoculture created by systemd is influencing how the future of Linux evolves by making some things easier and others harder.

While I agree with the broader point about (any) monoculture, I don't think that this can be blamed on systemd.

Systemd did not itself create the monoculture. When it came up, it was one of a multiculture. Distro maintainers then chose it en masse so that it became a de facto monoculture.

I'm not saying that necessarily makes it the best choice, though.

On a slightly different note, I find such comments funny in a way, because one of the reasons given for Linux's lack of market share on "the desktop" and, broadly, as a platform for "enterprise" software (think Adobe, etc.) is because the ecosystem is so fragmented. So, essentially, the platform isn't considered because it's not a monoculture (as would be Windows and Mac).

Re: Systemd, 10 years later (2020)

#229

Post by mariusor »

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.

> the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency.

Do you have any links for these statements? My memory is not great but I think I would remember anything similar to this.

Re: Systemd, 10 years later (2020)

#230

Post by Blikkentrekker »

rixed wrote: post #226
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…

acpid vs logind is another illustration of the trade offs involved when moving towards GUIfication of the bazar that is (was?) unix. Basically the proposition is akin to a weapon exchange program: hand over your powerful but dangerous Turing complete configuration language in exchange for nicer looking desktops. Who would not prefer a better looking desktop?

It's what you consider nicer. I consider dialog windows to be a slow and frustrating way to configure anything and on top of that in this case it loses me the ability for my computer to do what I want it to when I close my lid.

And if it simply remained at that, but left me alone I wouldn't be so irate, but I don't feel left alone and “Who would not prefer a better looking desktop?” already borders on this “My way, of the highway.” philosophy of Freedesktop, whose developers all too often tell one that one's subjective likings are wrong and that one is somehow “wrong” or “outdated” for favoring a machine that is fast to configure and does what one wants.

It also doesn't help much that on a purely visual level there design choices look ugly to me, and that these are also the same people that remove theme options lest the holy “brand identity” be compromised, as well as that their design blasts too much bright white light into my face when I'm already tiring my eyes out trying to learn to read a language that's not written in a script I'm accustomed to.

Post reply on HN