Live data from Hacker News

Operating Systems Without Systemd

annihilatormodule.com

141–150 of 166 posts

Re: Operating Systems Without Systemd

#141
post #107

Earlier quoted context omitted.

Oh. That's a linuxism. BSD has never had them, iirc. I don't think any of the other simpler init systems (eg, runit) did either.

No that’s a SysVism.

... that went away in parts of the System 5 world a year before Linux even existed.

* http://jdebp.uk./FGA/run-levels-are-history.html

getty was obsolete in the System 5 world two years earlier than that, in 1988.

* http://jdebp.uk./FGA/inittab-getty-is-history.html

Whilst not peculiar to Linux, it after all having been created for Minix, the van Smoorenburg init+rc system did resurrect some things that were already years gone in the System 5 world. Calling them "sysv" has always been somewhat of a misnomer. They are Linux/Minux clones of old System 5 mechanisms that were out of date at the time.

Re: Operating Systems Without Systemd

#142
post #112

Earlier quoted context omitted.

Cargo culting is the practice of blindly copying a solution without understanding why it makes sense and when it might not apply. You're describing the opposite.

Fictional Debian dev A: "Why do we have /etc/debian-release? Can't we have a release declaration file with a neutral name, like maybe /etc/os-release, in a format that all other distros can adopt?" Fictional Debian dev B: "That's how we've always done it. Plus if we touch it it might break some guy's script." It may not be exactly cargo culting, but at least an adjacent concept.

That's a story invented years after the fact without historical basis. The actual conversations amongst Debian developers went rather differently.

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444678

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659891

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659853

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703677

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914287

Re: Operating Systems Without Systemd

#143
post #47

Earlier quoted context omitted.

Agreed 100%. Systemd is a pretty good init system IMO. Service files are good, timers are good, dependency-based init is good. Easy sandboxing is nice. I absolutely _don't_ think that my init system should also be my bootloader. It also shouldn't manage my network configuration, or be responsible for controlling the system clock. And it shouldn't assert control of my home folders. And it shouldn't be spidering its wa…

> And it shouldn't be spidering its way into the Gnome login manager, which grew a systemd dependency a couple of years ago. gnome-shell used by the Gnome/Ubuntu login process also depends upon evolution-data-server !! See `apt-cache depends gnome-shell` for other dependencies... Debian chose systemd instead of upstart because of licensing, not features, according to https://wiki.debian.org/Debate/initsystem/upstart

If you have only read the wiki pages, written to summarize arguments by their various proponents, then you do not know why Debian people made this choice. The wiki pages do not relate that. Start by reading Debian bug #727708 in its entirety.

Re: Operating Systems Without Systemd

#144
post #105
post #57

Earlier quoted context omitted.

> My problem with systemd isn't pid 1. It's all the rest of the shovelware that comes along for the ride. And it's the "you'll use what we tell you to use" attitude of the project. This could not be further from the truth.

At some point, systemd introduced a RemainAfterExit= option, which killed all user started programs when the user logged out. IIRC, this is because of some misbehaving gnome application that wouldn't quit properly. Of course, since this hack solved the gnome bug, it was enabled by default by many, thus breaking applications like screen and tmux. What should have been done is fix the issue in whatever offending applic…

You have wildly mis-spelled "KillUserProcesses".

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221

Re: Operating Systems Without Systemd

#145
post #105

Earlier quoted context omitted.

At some point, systemd introduced a RemainAfterExit= option, which killed all user started programs when the user logged out. IIRC, this is because of some misbehaving gnome application that wouldn't quit properly. Of course, since this hack solved the gnome bug, it was enabled by default by many, thus breaking applications like screen and tmux. What should have been done is fix the issue in whatever offending applic…

> At some point, systemd introduced a RemainAfterExit= option, which killed all user started programs when the user logged out. IIRC, this is because of some misbehaving gnome application that wouldn't quit properly. The backstory is actually enlightening to me. To me, RemainAfterExit just seemed like the obvious sane decision and I actually wondered why it ever was different. When a user logs out, I absolutely want…

Now read https://news.ycombinator.com/item?id=11798458 .

Re: Operating Systems Without Systemd

#146
post #37

Earlier quoted context omitted.

The argument is not about the init system. systemd’s is probably fine. It’s about an ever expanding take-over of userspace by a single module, which is not the Unix way. And about a high-handed project leader who is paid by Redhat to do it full time.

If the issue is a single module take over of userspace then I have good news for you. The systemd project is made up of multiple modules handling differing tasks not all of which you have to use.

Every time that this argument comes up, people don't get their computer science right. The problem is not whether something has modules. It is the degree of coupling amongst and cohesion within said modules that is the metric.

* https://news.ycombinator.com/item?id=19132437

* https://news.ycombinator.com/item?id=19028053

Re: Operating Systems Without Systemd

#147

Earlier quoted context omitted.

> If someone is able to create something that is half as good as systemd then distros will switch time it. Not a given, since one of the issues with systemd is its integrations. Replacing init now requires you to replace your system logging and session manager, at a minimum, as well as replace all your service files.

systemd-logind is optional and you would be able to use ConsoleKit instead if anybody had maintained it in the last 5 years. Unlike e.g. upstart in its native mode, systemd can run SysV init scripts. https://unix.stackexchange.com/questions/233468/how-does-sys...

By "system logging" yjftsjthsd-h was referring to systemd-journald, not systemd-logind.

Re: Operating Systems Without Systemd

#148
post #147

Earlier quoted context omitted.

systemd-logind is optional and you would be able to use ConsoleKit instead if anybody had maintained it in the last 5 years. Unlike e.g. upstart in its native mode, systemd can run SysV init scripts. https://unix.stackexchange.com/questions/233468/how-does-sys...

By "system logging" yjftsjthsd-h was referring to systemd-journald, not systemd-logind.

True, but on that point xe was correct because it's the one part of systemd that is neither PID1 nor optional; I was assuming session manager referred to systemd-logind.

Re: Operating Systems Without Systemd

#149
post #119

Earlier quoted context omitted.

Part of it is that it is a more or less monolithic package that started as an init system and now does more than some people would like. This results in certain packages switching to require systemd modules(gnome & udev) and essentially locking systems without systemd out of using said software. Communities supporting non-systemd init systems now have to maintain forks of these modules so that they can keep these pac…

I find systemd journals much more accessible. Instead of passing a log file to the tool, you pass journalctl's output to the tool, and you can serialize the output to any of the supported formats (incl. json) and use much more tools, more directly, than you could previously. Compare that with random older default debian log line from one of my systems: Feb 14 01:15:30 shakes kernel: [ 4.014481] [drm] No driver suppor…

My biggest issues personally are the lock-in of systemd overall and for journald the binary file format. If I could use journald on its own with OpenRC first and foremost and preferably have it store logs as text be it json or whatever then I would use it hands down.

Journald just works for the most part and is much more convenient in most regards nowadays. If I remember correctly, interop was more of an issue before the big distros started to switch to systemd but now things seem to have mostly worked themselves out.

With regard to my comment about wanting logs stored as text, it really just comes down to having had to deal with corrupted binary files one too many times and unless it is absolutely unavoidable I find myself preferring text files for that reason. I'd imagine file system based compression leaves most if any storage benefit from binary logs rendered moot.

I know you can run a secondary syslog daemon from the output of journald or alternatively use a job to backup to a text based format but it would be so much more convenient to be able to just set a config setting. Having easy config and things "just working" is supposed to be one of systemd's strengths anyway.

Final thing to note is that at least from the perspective of someone running Gentoo w/ OpenRC, issues with traditional loggers are typically config mistakes more than anything. As for your debian log example, syslog-ng which I believe Debian had used should default to isodate for the datetime format. At least this is the case after RFC 5424 was adopted in 2009. That should give something along the lines of "1985-04-12T19:20:50.52-04:00". Nowadays unless the defaults are changed, most logging systems shouldn't have that datetime issue.

Re: Operating Systems Without Systemd

#150
post #11

Maybe I'm just out of the loop but what is the controversy regarding systemd?

> Maybe I'm just out of the loop but what is the controversy regarding systemd?

The problem with Systemd is that every time they introduce new non necessary feature they break something in the system. https://bugs.kde.org/show_bug.cgi?id=417038 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 Do they run tests ever?

Now when I launch my desktop I have to login in tty console first, start tmux, detach it, logout from tty, then login into desktop session normally. Otherwise logout from desktop session will hang and logging in again will fail.

They suggest using `systemd-run` instead, but it's broken too at this time. https://github.com/systemd/systemd/issues/3388

Post reply on HN