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

291–300 of 317 posts

Re: Systemd 252

#291

Post by Nursie »

kaba0 wrote: post #202
Nursie wrote: post #191

Earlier quoted context omitted.

No, I don't have to do that at all, I can in fact use the standard unix way of making a process not terminate on SIGHUP by telling it to ignore SIGHUP. SIGHUP is not a signal to shut down, it's a signal that says the controlling terminal is gone. The action taken by the process at that point is the decision of the process and the user that launched it, not the init system. This is exactly what it is for. Changing tha…

>And it showed off just how little the writers of the service knew about how users actually use their systems. Huge red flag. Why do you assume they didn't know about this quite basic mechanism? They added 2 configuration options, one at compile time (to set the default) and another configurable by the user. In fact, distro maintainers didn't look up what it did and they just compiled it as is, resulting in the surpr…

It might be the “correct” behaviour under systemd, it was not the correct behaviour under multiple other unix systems for decades, nor was it the expectation of Linux users or admins.

Paint it how you like, systemd broke decades-old, desirable behaviour for no good reason.

The attitude that everyone else is clearly wrong is unhelpful, and seems a red hat pathology. You see it with this and with Gnome, and it drives people away.

Re: Systemd 252

#292

Post by Nursie »

Shorel wrote: post #243
Nursie wrote: post #200

Earlier quoted context omitted.

There were a lot of noises made about it, yes, because people had been "nohup"ing things for decades, and using stuff like screen and tmux to keep sessions going over poor connections. All of a sudden, without much warning, someone made the decision to kill all user processes on logout. It broke a lot of folks workflow.

One would be tempted to say that deleting a user and logging out are definitely different operations with expected different outcomes.

It’s part of the same session-management feature that had unexpected (and undesirable) effects.

Re: Systemd 252

#293

Post by WastingMyTime89 »

effie wrote: post #271
WastingMyTime89 wrote: post #174

Earlier quoted context omitted.

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

I don’t care about having this kind of influence. These are tools. I want the tools I use to be good so I buy good tools.

It’s not about low quality discussion. A significant part of the Linux community seems to me to be deeply toxic and that leads to what I consider to be suboptimal technical choices.

Re: Systemd 252

#294

Post by otabdeveloper4 »

effie wrote: post #283
otabdeveloper4 wrote: post #75

Earlier quoted context omitted.

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

Security by default is usually a good default, yes.

systemd-run exists because a) you can use it to limit resources, b) it registers long-running processes under systemctl so you can interact with them under another session, and c) logs go into a central place.

Established Unix practice doesn't give you any of that unless you write a mountain of very opinionated shell scripts, which at that point why not just use the standard systemd instead?

Re: Systemd 252

#295

Post by effie »

otabdeveloper4 wrote: post #294
effie wrote: post #283

Earlier quoted context omitted.

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.

Security by default is usually a good default, yes. systemd-run exists because a) you can use it to limit resources, b) it registers long-running processes under systemctl so you can interact with them under another session, and c) logs go into a central place. Established Unix practice doesn't give you any of that unless you write a mountain of very opinionated shell scripts, which at that point why not just use the…

Security is a spectrum, and too much security means less freedom and shitty life experience.

I don't have a problem with a new tool such as systemd-run.

I do have a problem with breaking well established workflows in the name of security/efficiency/ideology, when users didn't ask for it. That is a policy question with different answers on different systems.

Anybody who cares about that kind of restrictions has to think and implement policies on their systems on their own. Relying on systemd to do the right policy thing for everybody is unrealistic, naive and warped idea of what users need.

Re: Systemd 252

#296

Post by effie »

WastingMyTime89 wrote: post #293
effie wrote: post #271

Earlier quoted context omitted.

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

I don’t care about having this kind of influence. These are tools. I want the tools I use to be good so I buy good tools. It’s not about low quality discussion. A significant part of the Linux community seems to me to be deeply toxic and that leads to what I consider to be suboptimal technical choices.

> I want the tools I use to be good so I buy good tools

Right, good strategy.

> A significant part of the Linux community seems to me to be deeply toxic and that leads to what I consider to be suboptimal technical choices.

Do you mean toxic users influence some developers to make bad decisions? Any examples? Toxic users dumping on systemd may be one, but I don't think they have that much impact, systemd seems pretty successful in not giving away. Anyway systemd is a very specific case, this is not representative of all linux software projects.

Re: Systemd 252

#297

Post by WhyNotHugo »

cultofmetatron wrote: post #151
gizzlon wrote: post #138

Earlier quoted context omitted.

No: "Alpine Linux is an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency. "

who out there is using alpine as their daily driver desktop? the only time I've ever seen it used is as the base image for docker containers precisely because its so minimal (ie: lower attack surface area)

pmOS[1] is based on alpine (for phones and tablets). I believe ddvault uses alpine on his daily driver, and sourcehut itself also runs on alpine.

I've considered it a lot, but I'm still to attached to service activations and a few other features from systemd --user.

[1]: https://postmarketos.org/

Re: Systemd 252

#298

Post by WhyNotHugo »

panick21_ wrote: post #76
stopdropnhotpot wrote: post #22

systemd is fine for single user systems and perhaps verts, but I would never deploy it on a server. The deprecation of cgroup v1 is a welcome change. It's come a long way, but it still has a very long way to go.

Facebook runs lots of Systemd but I'm sure on your infrastructure you couldn't run it.

Facebook also uses PHP. The fact that somebody made a huge service work with a specific tool doesn't automatically imply it's the best tool, or even a good tool.

Re: Systemd 252

#299

Post by effie »

esarbe wrote: post #288
effie wrote: post #266

Earlier quoted context omitted.

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

> these use-cases were not sufficiently covered in the past.

Many systems do not have those use cases. Everybody needs an init system, so that's where systemd could have been the fix to the deficiencies of sysvinit (as marketed). Instead, it merely kind of works as init, sometimes with random errors and disrespecting the keyboard input when things go wrong. And then instead of fixing and polishing that experience, developers expanded into million other directions, including DNS, container management and what not. Systemd is becoming a bad OS like Windows is.

> User session are also now handled in systemd - one less component to be developed by the "Desktops" - yay!

But systemd is used on servers too, and the user sessions and broken behaviour it introduces are a needless pain best to be disabled there. User sessions and related is really something Desktops should be handling, since it only makes sense on Desktops.

Re: Systemd 252

#300

Post by AnIdiotOnTheNet »

tristanbvk wrote: post #209
AnIdiotOnTheNet wrote: post #124

Earlier quoted context omitted.

I'd say the success of the Steam Deck is a testament to the maturity of the Windows API[0]. Old enough and reliable enough that it is a better target for games on Linux than Linux Desktop's own shit show. [0] and of course the efforts of the WINE project and proton.

You're not wrong regarding Wine but that may be the ONLY good aspect of Windows on a technical note.

There's a lot of good aspects of Windows. The NT kernel is actually really good, the driver model is largely user mode, it had application-specific sound mixing, PowerShell is really good, etc.

Don't succumb to fanboyism.

Post reply on HN