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

341–350 of 458 posts

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

#341

Post by jude- »

AsyncAwait wrote: post #326
lmm wrote: post #196

Earlier quoted context omitted.

> 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. You do realize even the Linux kernel doesn't make any commitments regarding API stability, right? That's kind of an explicit choice to allow the maintainers to move forward with the limited resources they have without too much red tape. There's always *BSD, if you want compatibility back to the Sun days in some…

> You do realize even the Linux kernel doesn't make any commitments regarding API stability, right?

It does for userspace APIs. Linus is notorious for chewing people out for breaking them (example: https://lkml.org/lkml/2012/12/23/75).

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

#342

Post by nlgza »

AsyncAwait wrote: post #322
josefx wrote: post #301

Earlier quoted context omitted.

> Lennart and the systemd team did exactly that 10 years ago. Why can't you? It would be impressive if Lennart managed that by himself. Red Hat wanted it done, Ret Hat also has its hands in various open source projects that suddenly started to sprout hard dependencies to systemd. Projects like Gnome were Red Hat is by far the biggest contributor. Not much an individual programmer can do compared to a corporation thro…

> It would be impressive if Lennart managed that by himself. Red Hat wanted it done RedHat wanted it done once Lennart convinced them it is the right thing to do and Lennart put in the effort to be at RedHat at the right time to have the ability to convince them. In fact Lennart is one of the few people willing to put in the effort to touch the fundamental building blocks that otherwise rot, but nobody is willing to…

RedHat has several people who take over projects and rewrite everything they see, with little or no benefit other than getting a high commit count.

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

#343

Post by magicalhippo »

Spivak wrote: post #66
throw0101a wrote: post #35

Earlier quoted context omitted.

Translation: We broke long-standing POSIX/Unix behaviour of noHUP and think that's a good thing.

I mean that is their position yes. It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out. This is a feature that sysadmins have been asking for. On any multi-user system you run into this crap where background processes for users who are long-since gon…

> This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out.

But when using remote connections, ie RDP, the default is that your session is disconnected. You have to actively choose to log out of an RDP session.

When using SSH I typically want the same. If I put my laptop to sleep or a networking issue causes the TCP connection to end, I want my terminal session to be restored when I reconnect via SSH.

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

#344

Post by jcynix »

vidarh wrote: post #255
jcynix wrote: post #189

Earlier quoted context omitted.

This must be satire, not? Because soon my .forward won't work, my .procmailrc won't work, my crontab scripts won't (etc pp) unless my encrypted home directory (planned to be decrypted on login) is decrypted. Or all these are moved to other locations.

Or you opt to not encrypt your home separately. But how large a proportion of machines do you think have mail delivery rely on .forward or .procmailrc in $HOME these days? In any case, procmail can be executed directly rather than from .forward in most cases, and can be configured to take the rc file to be a file in /etc/procmail-rcs/ as an alternative to $HOME/.procmailrc (at least the version of procmail in Ubuntu;…

Maybe my point wasn't stated clear enough: the crontab itself is in spool, obviously, but the scripts started from crontab entries reside in my home directory. And while a procmailrc can live in some spool too, the files to be delivered into are in my home directory too.

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

#345

Post by theamk »

downerending wrote: post #72
0zymandiass wrote: post #39

Earlier quoted context omitted.

It's dramatically simpler and more intuitive than what it replaced, so I'm super excited when someone comes up with something even better!

Systemd has many pluses, but simplicity and intuitiveness are most certainly not among them.

Depending how you look? Here is a great example: disable the service before installing -- i.e. make sure that even if someone installs the service, it won't get activated.

On systemd, it is "systemctl mask NAME". On sysvinit? Well, there maybe a file in /etc/default/ -- but each package has its own option name... and some of them cannot be disabled at all.

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

#346

Post by lmm »

AsyncAwait wrote: post #326
lmm wrote: post #196

Earlier quoted context omitted.

> 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. You do realize even the Linux kernel doesn't make any commitments regarding API stability, right? That's kind of an explicit choice to allow the maintainers to move forward with the limited resources they have without too much red tape. There's always *BSD, if you want compatibility back to the Sun days in some…

> You do realize even the Linux kernel doesn't make any commitments regarding API stability, right?

You say "even" the Linux kernel; actually most projects don't and Linux is a rare exception, and I do think it's a bad idea for both technical and nontechnical reasons. (Compare with GCC's refusal to offer a stable API between frontend and backend, which I'd argue is a big reason why LLVM is overtaking it).

> There's always BSD, if you want compatibility back to the Sun days in some cases, (Win32 is another option).

I actually do run FreeBSD these days; one of the reasons this issue still bothers me is that compatibility with BSD is likely to be collateral damage from the systemd push (it's getting harder and harder to run Gnome on BSD, for example). It was particularly frustrating that systemd basically killed off Debian GNU/kFreeBSD just as it was becoming a first-class architecture; that could have been the best of all worlds.

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

#347

Post by theamk »

kelnos wrote: post #205
theamk wrote: post #130

Earlier quoted context omitted.

Usurped how? Who and how forced Debian and Arch to switch to systemd?

GNOME, essentially. If you want to run a fully-functioning GNOME on your distro, you have to be running systemd. Or have the time and patience to maintain a large patch set to work around the systemd dependencies.

This became this way only once systemd has won. At least during Debian systemd debate, both sysvinit and upstart could run Gnome just fine.

(also, what were the alternatives? I don't run GNOME myself, but given what GNOME wants do to, it does need a solid session management. I have seen ConsoleKit, it was worse than systemd.)

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

#348

Post by lmm »

cycloptic wrote: post #331
lmm wrote: post #310

Earlier quoted context omitted.

> 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? Compatibility is the only way it becomes possible to make those changes. E.g. in the pre-systemd days there were at least four different syslog systems and at least three different cron systems. But because they co…

>Since they all follow common standards, any program works with any environment.... If the systemd people want to make a shiny new init with cool features, great. It's when they break compatibility with alternatives that I have a problem with it. That is not relevant because the "common standard" in this case is the logind D-Bus API. There are no other active and viable alternatives to login management. It has two im…

> That is not relevant because the "common standard" in this case is the logind D-Bus API. There are no other active and viable alternatives to login management. It has two implementations, systemd-logind and elogind. You can choose either one, and only the first one requires systemd.

Is there any commitment to treating those as stable interfaces, with a decent deprecation cycle around any incompatible changes? If so then that's a big improvement; there certainly didn't used to be.

> I don't see what this has to do with anything. It's open source. If you want to collaborate, you can submit a pull request, work with the maintainers and get them to spend their paid time reviewing and merging your code.

I saw patches submitted and rejected on the grounds that the project leadership had no interest in supporting non-systemd (and/or non-Linux). Even if the leadership does want to accept a patch, that can take months; in my experience it's not worth making a change if you can't run it on your own systems without upstream getting involved. So if a project is large and not cleanly factored into smaller pieces with stable interfaces between them (or at least open to being factored that way in principle), then it's just not worth trying to contribute unless you can work on it full-time.

> It is not reasonable to expect that every single person will have the time and expertise to contribute to any given project, or that every project will be structured in a way that lets them accept maximum contributions. I don't mean to dismiss your frustration with being unable to contribute. I get that. But you continue to have the opportunity to do so and you will for as long as these projects remain alive. The code is not going to magically disappear one day and it's up to you to find the time to actually dive in. Good luck.

I believe in open source not because it gives me a chance to write code but because it lets me fix bugs or change behaviour that's bothering me. It's the "RMS printer driver" situation; if something goes wrong in Linux these days I feel like I'm no better off than I would be on windows. For the moment I'm using FreeBSD (and KDE) and I can still patch stuff without my patches getting broken every other month, but as things integrate more deeply with systemd it seems like a matter of time before the programs I use go Linux-only.

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

#349

Post by cycloptic »

vezzy-fnord wrote: post #314
cycloptic wrote: post #278

Earlier quoted context omitted.

The entire purpose of designing models is to reduce things that have irreducible differences and then tell people to shut up and deal with it. There is nothing else there. What is it exactly that you think IT gets paid to do other than this? We have finite time on this planet. Also, things are constantly being rethought. That is quite literally what the churn encompasses. You can't complain about this while asking fo…

All models are wrong, some are useful, others not so much. There's no need to treat me with these banalities. The job model ought to have died with Upstart. It did not. Oh well. > The core problem has already moved to a different area and that's why it really doesn't matter if they are doing a bad job. Yes, I agree. Still, the losers of history deserve their voice, too. "Nobody" is a significant overstatement. A lot…

Sorry for the glibness I am just really bored with these complaints, it really feels like the same old bikeshedding. As far as I know there is no way to make a transactional state machine without having the concept of a single, reordable work unit. Daemontools did not solve this or present a different model that was more workable. For every developer that rewrote their daemon to get rid of forking, we got more new developers with outdated learning material coming over who expected services to work like they did on some other crazy environment like Microsoft Windows.

I don't particularly care about who was a "winner" or a "loser" either. In general you cannot get away from TOCTOU on Unix without taking extreme care and avoiding things that would seem reasonable, like storing filenames in other files or using the "kill" command. In practical use I have seen no inits that make any concerned effort to solve these issues at all. That is a situation in which we all lose.

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

#350

Post by brmgb »

josefx wrote: post #301
phatfish wrote: post #254

Earlier quoted context omitted.

Lennart and the systemd team did exactly that 10 years ago. Why can't you? The code is there for someone with enough skill to show how bad systemd is right?

> Lennart and the systemd team did exactly that 10 years ago. Why can't you? It would be impressive if Lennart managed that by himself. Red Hat wanted it done, Ret Hat also has its hands in various open source projects that suddenly started to sprout hard dependencies to systemd. Projects like Gnome were Red Hat is by far the biggest contributor. Not much an individual programmer can do compared to a corporation thro…

> Red Hat wanted it done

Red Hat had zero interest into a new init system when Lennart started systemd. They had just moved to upstart and Red Hat customers don't really care about init systems. Red Hat customers pay for their systems to be stable and to have someone to call when something goes wrong.

Systemd gives Red Hat no competitive advantage whatsoever.

I'm probably not going to make myself a lot of friends by saying this but I don't really understand the systemd opponents.

The components systemd is slowly replacing or sitting on top, most of the low level userspace of linux, is mostly garbage and poorly documented garbage at that. PAM is aweful. I don't even want to talk about ConsoleKit. Cron has one of the worst configuration format ever and I'm certainly not going to miss fstab. I would find journald a step in the right direction even if the only thing it brought to the table was the ability to configure logging from the service file and not have to fiddle with logrotate.

Networkd gives you a nice, uniform and well documented way to configure both interfaces, rules, custom routing tables and vpn tunnels from declarative files. Who in their right mind can miss the hodgepodge of scripts that was there before ?

Post reply on HN