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

Systemd 252

github.com

Post reply on HN
Print view View original

271–280 of 317 posts

Re: Systemd 252

#271

Post by effie »

WastingMyTime89 wrote: post #174
teddyh wrote: post #52

Earlier quoted context omitted.

Unix traditionally has never had proper seat and/or session management, with all the chaos this entails. With systemd, they added it. You’re effectively proposing that systemd (or anything else) should never implement session management. The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup comm…

> The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session. That was proposed to nohup when systemd introduced the modification. It’s what nohup does on macOS. A very productive discussion was happening but then the anti-systemd mob showed up with pitchforks, brigaded…

> I personally decided Linux was a lost cause and definitely switched to macOS.

That is an strange course of action. So because you saw some low quality discussion on the internet, you switched from free software you can influence to commercial one you can't?

Re: Systemd 252

#272

Post by effie »

kaba0 wrote: post #64
erik_seaberg wrote: post #60

Earlier quoted context omitted.

I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?

How is systemd not under the user’s control? It is an init and service management system and long-running processes are services. Where else should it be managed? Systemd is the only component that knows whether you are logged in/out, whether you still have another seat open, etc. And its responsibility is to properly close resources, and not let unannounced processes to linger needlessly in the background.

systemd is usually a root process, regular user does not control it. Whether user being logged off means no such user processes should run is a policy question that has different answer on different systems and depends on the user as well. Systemd "unified solution" - killing user processes on logout - is not working well for many people especially on shared machines.

Re: Systemd 252

#273

Post by effie »

erik_seaberg wrote: post #72
teddyh wrote: post #68

Earlier quoted context omitted.

systemd-logind(1) manages user sessions. If you want to replicate the functionality of what “nohup” used to give you, I am reliably informed that “systemd-run --scope --user $command” does the right thing. Or, you can enable it permanently for your user with “loginctl enable-linger”.

When I see “manages user sessions,” I don’t know what that phrase means. What is a “session” (again assuming not a POSIX session leader) and what are we concretely doing to “manage” it? Is there a guide that explains the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years? I would never expect a non-sysadmin to have read the “systemd-run” or “loginctl” m…

> the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years?

That is bound to be a losing strategy. Systemd development (of breaking changes) is not stopping anytime soon. The simplest solution is to switch to an OS without systemd, like Devuan or Alpine or BSD.

Re: Systemd 252

#274

Post by forgotmypw17 »

stevefan1999 wrote: post #71

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 history of these non-consensual changes, because I want my systems to run without extra maintenance.

Re: Systemd 252

#275

Post by forgotmypw17 »

rainbow29822 wrote: post #258
Maursault wrote: post #182

Earlier quoted context omitted.

> and there should be Linux distros packaged without systemd. systemd should be an optional package on all distros. Shoving it down throats is one of the valid major criticisms. What should have happened instead is systemd was optional on Debian at setup and Debian was forked to include it by default. It is simply backwards that Debian needed to be forked for purity. Duvuan shouldn't need to exist, but it very much d…

>systemd should be an optional package on all distros. Why? Should glibc also be optional? What about the Linux kernel? What about apt-get? You can technically replace those things but it's a ton of extra work, almost like shipping a completely different distro. At the end of the day, a distro decides what packages it wants to support and what it doesn't. The specific choice of supported packages is often what define…

> Should glibc also be optional? What about the Linux kernel? What about apt-get?

In my opinion, yes, they should absolutely be optional. Whether or not that is feasible today does not change the advantages of each component of the system being optional and replaceable. It is more failure tolerant both from a purely technical perspective, and also from an organizational perspective.

Re: Systemd 252

#276

Post by E39M5S62 »

HNDV wrote: post #37
europeanguy wrote: post #3

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…

Void Linux doesn't use systemd because it doesn't build against musl libc. Void ships musl and glibc packages for multiple CPU architectures and has a very lively development team and update cycle. It's not dead, it's just not insanely huge, either.

Re: Systemd 252

#277

Post by forgotmypw17 »

effie wrote: post #267
VancouverMan wrote: post #203

Earlier quoted context omitted.

It's quite simple: many people had atrocious experiences with systemd. Systemd ruined Debian for me, for example. I'd been using Debian testing for years and years, on multiple systems. Despite its name, I'd always found Debian testing to be more reliable than the stable releases of other major distros. When performing updates and upgrades during those many years of using Debian testing, I had only ever experienced t…

I recall part of the problem was that in some cases, Debian packagers/developers did not know how to integrate systemd with sysvinit properly, there were weird problematic constructions such as sysvinit scripts calling systemctl or vice versa and some breakage due to the way they used systemd. Of course, one could ask whether this was partly due to bad systemd documentation and unfulfilled expectations of promised sy…

Seems like three different problems coming together here:

a) Poor documentation

b) Overly complex

c) Not a choice

Re: Systemd 252

#278

Post by E39M5S62 »

t43562 wrote: post #224

I'm enjoying dinit in artix. I think Artix is not terribly mainstream but the dinit part of it seems easy to deal with so far. It would be interesting to see it get polished in a different distro. Living without systemd is sometimes a rough choice at the moment but I think it can be polished.

Take a look at Chimera Linux - https://chimera-linux.org/ . It's a desktop-focused distribution that uses dinit. It'll be one to watch once it stabilizes.

Re: Systemd 252

#279

Post by effie »

lrvick wrote: post #121
UI_at_80x24 wrote: post #105

Earlier quoted context omitted.

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

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

That is a very restrictive work methodology (unikernels,exokernels). Although interesting and certainly useful in some cases (high security, rare updates), Bryan Cantrill was partially right on this - in the real world, we often need to debug stuff running in production and support paying customers who require that. Your idea of "production systems" and "servers" seems very specific and the "should" statements are often not true in practice.

Developer tools definitely belong on the server too, you need them to determine how to build your stack binaries in the best way for the OS and HW architecture there and keep them updated and secure.

Re: Systemd 252

#280

Post by effie »

lrvick wrote: post #133
traverseda wrote: post #113

Earlier quoted context omitted.

I mean have you actually used the alternatives? I find most of the people with that opinion are young pups who jumped on the linux train after most of the systemd bugs have been ironed out, but who still have zero experience with the alternatives.

I have used all the alternatives, and written my own init systems from 0. Systemd is really well designed and makes Linux workstation use predictable and more secure across distros in numerous ways. You can have any service you want now, even xorg/ wayland, as an unprivileged user. It basically removes all need to use root if used correctly. Systemd however is however not designed for server use, but neither is OpenR…

> Systemd is really well designed and makes Linux workstation use predictable and more secure across distros in numerous ways. You can have any service you want now, even xorg/ wayland, as an unprivileged user. It basically removes all need to use root if used correctly.

It sometimes randomly fails to boot, waiting for some strange condition, while I am not able to intervene via keyboard in any way. That is "well designed"?

I run Xorg as unprivileged user by executing startx, on sysvinit system. There is no problem that needs systemd solution here.

Post reply on HN