Live data from Hacker News

Systemd 252

github.com

281–290 of 317 posts

Re: Systemd 252

#281
post #9

Earlier quoted context omitted.

Alpine linux seems to be doing fine without systemd.

But I almost never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora. Without systemd, bootstrapping a complicated desktop environment would be a hot mess. Well, maybe you would say Alpine is not intented to run heavyweight stuff like that and is mostly focused on security and containers. That's exactly what Alpine is, the OpenBSD of Linux distros…

> Without systemd, bootstrapping a complicated desktop environment would be a hot mess

What is a complicated desktop environment? Why should I run it? I want to run simple desktop environment, like Xfce. I run startx in tty, and get unprivileged Xorg with Xfce on sysvinit system. It's rock solid.

Re: Systemd 252

#282
post #95
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.

Absolutely. I've started managing my user services using systemd --user and portable services and it's just amazing how well the individual components work together to create fully isolated, containerized, per-user services. I'm lovin' it and I'm not missing the hot mess of the dozens of shell scripts that I needed before.

What kind of user services and "portable services" are you managing? I have trouble imagining what that means. User pulseaudio daemon on your laptop/desktop? Or some server services for many clients?

Re: Systemd 252

#283

Earlier quoted context omitted.

That isn't so true anymore, given their focus on home directory management and killing all user processes on logout (desktop-focused and doesn't work well with tmux or ssh)

> killing all user processes on logout This is a good default for the server use-case, to prevent developers and sysadmins launching stealth long-running jobs. (Especially if they steal resources.) The idea is you'd run batch jobs and services explicitly via systemd-run.

Why is systemd developers preventing sysadmins/developers from something they want to do on their own/assigned machines a "good default"?

Why is their systemd-run idea valid and decades of established unix practice is not?

This is really bonkers, don't invent or repeat "rationale" from the vendorthat obviously is anti-user and makes no sense.

Re: Systemd 252

#284
post #216

Earlier quoted context omitted.

"e" following "d" in the alphabet, the successor to systemd would be called "systeme", which is the french translation (système) for "system".

Thanks, but I was refering to the "...in keeping with the French naming" part, as if systemd previously had a french name or something

“[The] name is suitably reminiscent of the French term "système D", an expression that relates to thinking on your feet and describes high-speed technical problem-solving abilities such as those displayed by TV action hero MacGyver.”

— Poettering, Sievers and Leemhuis, the Systemd authors, in http://www.h-online.com/open/features/Control-Centre-The-sys...

Re: Systemd 252

#285

I just never get why people always flame on systemd. Sure, it's kinda bloated in the sense that it is "battery included" just like Python, but the intention to have a stable init with great system and service management is very good from both a DevOps and Sysadmin perspective. It is at least much better than writing your adhoc init.d script that may not guarantee to run on other Linux distros.

At the very top of this page, there are two features listed which will be removed in the future. This means that anyone who relies on this feature is now tasked with all the extra work and cognitive load of finding replacements for those features, changing and testing their configuration, and the risk of deploying these changes. To me, that is a "non-consensual" change, and I try to avoid any technology that has a hi…

> To me, that is a "non-consensual" change, and I try to avoid any technology that has a history of these non-consensual changes, because I want my systems to run without extra maintenance.

Then stop using Linux. The Linux kernel replaces subsystems with different, incompatible subsystems all the time. For example packet filtering was once ipfwadm then ipchains followed by iptables and now nftables.

Re: Systemd 252

#286
post #37

Earlier quoted context omitted.

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

>thought that systemd was generally hated? If it was generally hated there would be a lot more support for the distros that don't have systemd. There isn't. Except for alpine, all of them are extremely niche, half of them are dead, the other half barely have enough people to stick around for a release a year. Even alpine is kinda niche, it's mostly used as a way to make lightweight docker containers, rather than as a…

Impressive. They have even a document that describes the problems with systemd. And not just any document, it's the most viewed research thesis of all time! Wow!

The Devuan founder is truly the most impressive person in the universe.

"The most viewed research thesis of all time published by Univ. Plymouth pearl.plymouth.ac.uk/handle/… by Devuan's founder @jaromil" https://twitter.com/DevuanOrg/status/1587168838071816193

Re: Systemd 252

#287

Earlier quoted context omitted.

At the very top of this page, there are two features listed which will be removed in the future. This means that anyone who relies on this feature is now tasked with all the extra work and cognitive load of finding replacements for those features, changing and testing their configuration, and the risk of deploying these changes. To me, that is a "non-consensual" change, and I try to avoid any technology that has a hi…

> To me, that is a "non-consensual" change, and I try to avoid any technology that has a history of these non-consensual changes, because I want my systems to run without extra maintenance. Then stop using Linux. The Linux kernel replaces subsystems with different, incompatible subsystems all the time. For example packet filtering was once ipfwadm then ipchains followed by iptables and now nftables.

Excuse me, who do you think you are, to tell me what to do?

Re: Systemd 252

#288
post #266
post #206

Earlier quoted context omitted.

Rubbish. Linux+GNU is either a Unix operating system or it is not. Having systemd on board changes exactly nothing, since there never was a system services interface anyway. Files in a directory you say? That's not an interface, it's a recipe for failure. Or why do you think that every distribution used to ship their own init scripts? You EV car dealership is awfully flawed, especially with Linux+GNU you can even bui…

Why are we complaining? You're right that systemd provides useful things that sysvinit was not strong about. That is not enough to make systemd as distributed a good init system. It is a bloated C codebase with no definition of goals, instead it suffers never-ending mission creep. In mainstream distros, while it does init, it also meddles in too many things it should not, like spawning zillions of needless user sessi…

systemd ist not an init system and it never was intended to be "just" an init system; from the very start was conceived a system services management layer.

https://0pointer.de/blog/projects/systemd.html

If there's an expansion of scope in the systemd project, that's because these use-cases were not sufficiently covered in the past. And while I wish you good luck with s6; how do you intend to replace all the functionality that systemd already delivers?

Let's pick an example; KDE and Gnome used to write their own session management software, to make sure certain applications and services that the desktop needs (like; e.g. accessibility tools). This is nowadays handled by systemd, since it - as a system services management layer - already implements all the required functionality. So instead of three half-backed systems (one by KDE, one by Gnome, one for the system, all incompatible and unable to talk to each other) we have one good implementation. User session are also now handled in systemd - one less component to be developed by the "Desktops" - yay!

Where you see feature creep I see consolidation. A consolidation that - in my opinion - is painfully necessary.

Re: Systemd 252

#289
post #282
post #95

Earlier quoted context omitted.

Absolutely. I've started managing my user services using systemd --user and portable services and it's just amazing how well the individual components work together to create fully isolated, containerized, per-user services. I'm lovin' it and I'm not missing the hot mess of the dozens of shell scripts that I needed before.

What kind of user services and "portable services" are you managing? I have trouble imagining what that means. User pulseaudio daemon on your laptop/desktop? Or some server services for many clients?

Portable services are a systemd thing: https://systemd.io/PORTABLE_SERVICES/

In short it allows you to bundle your application in one file and have it run in a sandbox. Like a docker container, but without docker, managed by systemd.

https://wiki.archlinux.org/title/Systemd/User

User services are also a systemd thing; you can create systemd unit files (service descriptions) and have them run as a user. So as a user you can manage your own running processes using the same systemctl interface as system processes. If you are allowed to "linger" on a system, you can run user processes as a service, set them up and tear them down without root permissions.

I have several systems where I run i.e. webservices without having full root access. I build an portable systems image, deploy it to the server and then can manage that service with my unprivileged user account.

Systemd does all the usual things, like logging, supervision, resource quotas, and so on.

Re: Systemd 252

#290

Earlier quoted context omitted.

Thanks, but I was refering to the "...in keeping with the French naming" part, as if systemd previously had a french name or something

“[The] name is suitably reminiscent of the French term "système D", an expression that relates to thinking on your feet and describes high-speed technical problem-solving abilities such as those displayed by TV action hero MacGyver.” — Poettering, Sievers and Leemhuis, the Systemd authors, in http://www.h-online.com/open/features/Control-Centre-The-sys...

Interesting. However, the link they provide as reference where apparently "The developers thought that its name is suitably reminiscent of the French term système D" does not have this term anywhere. My guess is this was just made up by a 3rd party (h-online in this case) and everyone just went with it?

I have that c't magazine they're referring to somewhere, I'll look it up there

Post reply on HN