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

Systemd, ten years later: a historical and technical retrospective

blog.darknedgy.net

Post reply on HN
Print view View original

211–220 of 458 posts

Re: Systemd, ten years later: a historical and technical retrospective

#211

Post by jka »

lmm wrote: post #176
thristian wrote: post #91

Earlier quoted context omitted.

The trouble is that 'nohup' is not a particular state that specifically marks processes that want to survive logout. Instead, the rule is that processes running inside a particular terminal are killed when that terminal closes, and processes running outside any terminal run as they please. If you SSH to a server, or telnet, or login on the text console, or via a serial port, you get a terminal and everything you run…

> Since the kernel's idea of "a login session" is wrong (it only includes text-terminals), and it can't easily be changed for compatibility reasons This is a CADT attitude. Improving existing interfaces while maintaining compatibility is hard; it's also what makes the difference between a serious software professional and an incompetent vandal.

'CADT' was new to me - noting my search findings, to save someone a little time:

[redacted jwz domain]/doc/cadt.html

(and yep, agreed, incremental safe progress towards a goal can be prone to disruption when people don't want to spend the time to consider existing use cases and the work required for gradual, graceful migration)

Re: Systemd, ten years later: a historical and technical retrospective

#212

Post by cycloptic »

lmm wrote: post #196
cycloptic wrote: post #177

Earlier quoted context omitted.

This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd. So…

> This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility. It's like saying that windows programs work on Linux, you just have to use wine - it's sort of true for now, but it's not something you can rely on. > And, there were valid technical reasons to have gnome depen…

>elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility

Isn't that the whole reason for using another init? Because you see full compatibility with systemd as being undesirable and you have the means yourself to maintain things yourself using other solutions? I don't get it, it sounds to me like you're now saying the opposite of what you did before.

>I remember multi-seat working fine long before either systemd or ConsoleKit, so that seems pretty questionable.

Multi-seat might have worked but it did not do so securely. The issue is that you need a daemon to multiplex the display and input devices, and programs that want to request logins must be able to speak a specialized IPC protocol to that daemon. Otherwise all you have is a bunch of setuid root programs that do not communicate and can easily clobber each other at any time. Remember that the kernel does not have any built-in support for this, these are just device nodes in /dev like anything else, and in the old days the X server just used to run as setuid root at all times and sessions running in the background could read the keyboard whenever they wanted or take control of the display. The issue doesn't just affect multi-seat either. Even on your laptop you basically need a login manager to do secure screen-locking. There are an absurd number of ways that pure X- or Wayland-based screenlockers can be escaped. In an ideal world the kernel would probably prevent this stuff, but it doesn't right now, so login managers remain necessary.

>"The needs of gnome" are a constantly moving set of goalposts under the control of RedHat.

1. GNOME is an open source project not in control of any one company or organization, and anyone can contribute or fork the project if they so desire.

2. Nothing was "forced through" as the decision was agreed upon by the current and previous maintainers. If you disagree, you can revert to an old version as previously stated. This may be unpalatable to you but it is not realistically possible for anyone besides you to write code that you will agree with 100% of the time. It's up to you to make the tradeoffs you want on your system.

3. Also as previously stated, there is no hard-dependency on systemd. You can get it working with elogind. If you refuse to because you fear it will break in the future, that's on you. The fact is that it works now.

Re: Systemd, ten years later: a historical and technical retrospective

#213

Post by kelnos »

nn3 wrote: post #31

The dependency problems he's describing sound like they could be relatively easily fixed with some new systemd keywords? Of course it would take some time to migrate existing unit files. It doesn't sound like a fundamental critique. Would be nice to turn this into a constructive proposal to fix systemd.

It feels like a lot of the existing keywords were added in order to paper over previously-discovered dependency issues. And the result has been a) confusion, and b) more dependency issues. I don't think adding more is going to help the matter.

Re: Systemd, ten years later: a historical and technical retrospective

#214

Post by aerique »

anewvillager wrote: post #199
gorgoiler wrote: post #119

When writing software, it’s comparatively easy to come up with grand new ideas and turn them into lines of code and files filled with modules. What’s much harder is (1) to expand ones code without coupling everything together (2) present it in a persuasive way that naturally builds a user base. SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to…

Why do systemd detractors keep styling it as SystemD? I'm honestly curious. You know it's written all lowercase, right?

Basically to annoy you. Yes, it's childish but also very satisfying. Do you want us to even give that up now that we're stuck with SystemD?

Re: Systemd, ten years later: a historical and technical retrospective

#216

Post by hnarn »

nine_k wrote: post #168
hnarn wrote: post #154

Earlier quoted context omitted.

"Not in upstream" doesn't seem to correspond with the comment you replied to.

Quoting: "Killing of user process are enabled by default in upstream but disabled by default in every distro that I know."

I really shouldn't write HN comments right after waking up.

Re: Systemd, ten years later: a historical and technical retrospective

#217

Post by gjvc »

Karunamon wrote: post #94
gjvc wrote: post #38

If you don't like something, put your energy into implementing it the way you do. With any luck, the ensuing distraction will be more effective at weakening the original than simply complaining about it.

Sadly, systemd has corporate backing, which is a very hard fight to win for a ragtag bunch of nerds with dayjobs who have the completely unreasonable expectation of not having their shit broken , regardless of how much energy we have. Money and full-time devs beats energy every day of the week.

My point was that there is nothing (no competing implementation) to be judged against, so it rather wins de facto.

Re: Systemd, ten years later: a historical and technical retrospective

#219

Post by novok »

sneak wrote: post #118
nine_k wrote: post #86

My beef with systemd is not its reinventing things. That part may actually be good. One problem is that a number of reinventions were poorly made. E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we take some ridiculously well-tested, reliable embedded database or serialization format (like sqlite) and use it as log storage? Alas. Another problem is the "I know better" attitude. Are user proce…

It's astounding to me the issues people have with this. systemd's existence doesn't preclude anyone from using the old, pre-systemd ways of doing things. There are thousands of linux distributions, and afaik there are at least a dozen which are primarily defined as never-using-systemd. Face it: the linux userspace has always sucked. Linus punted on it way-back-when (to be fair, he was a solo dev working on a kernel,…

Linux types I've noticed tend to be more holy war orientated. Where did the classic vim vs emacs holy war come from also?

Re: Systemd, ten years later: a historical and technical retrospective

#220

Post by bkor »

lmm wrote: post #171
sneak wrote: post #118

Earlier quoted context omitted.

It's astounding to me the issues people have with this. systemd's existence doesn't preclude anyone from using the old, pre-systemd ways of doing things. There are thousands of linux distributions, and afaik there are at least a dozen which are primarily defined as never-using-systemd. Face it: the linux userspace has always sucked. Linus punted on it way-back-when (to be fair, he was a solo dev working on a kernel,…

> Face it: the linux userspace has always sucked. Linus punted on it way-back-when (to be fair, he was a solo dev working on a kernel, he had his hands full) and opted for the gnu tools, but those (other than the compiler and libc and a few other spots like grep) have never been best-in-class. Which userspace are you claiming is better then? Linux used to offer the best userland experience in the world, because you h…

> pressured other projects to hard-depend on it (e.g. Gnome).

GNOME wasn't pressured in depending on it. There deciding to depend on logind over ConsoleKit. Initially logind could be used without systemd, that changed after a systemd version due to cgroups v2. There's quite a bit of overlap between the people maintaining ConsoleKit and the people wanting to make use of logind, so there was a push by some GNOME maintainers to use logind.

The arguments against were often quite weak. When pointed out that ConsoleKit was unmaintained for years the answer could often be summarized as "why does it need development".

> It's a betrayal of everything those projects stand for.

Stuff like this makes maintainers of things just ignore you. There might be a valid point in your argumentation, but why bother.

Post reply on HN