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

Operating Systems Without Systemd

annihilatormodule.com

Post reply on HN
Print view View original

101–110 of 166 posts

Re: Operating Systems Without Systemd

#101

Post by sterlind »

est31 wrote: post #36
threwawasy1228 wrote: post #6

Earlier quoted context omitted.

I think that NixOS could definitely become a foundational next-gen distribution if they fix the Channel system. One fix I'm particularly fond of is flakes. [0] https://github.com/NixOS/rfcs/pull/49

I too hope that NixOs becomes mainstream because I like the basic approach, but the same time there are some issues with it still. I'm not sure it will ever become mainstream. It might remain small forever, e.g. like the haskell/fp community.

I think it could get big if people start making Nix distributions. I've been meaning to make something like NixOS for Grandmas that hides the config and tools behind a shiny installer and settings page and uses Nix as a control plane.

The best part is, there wouldn't be fragmentation of package maintenance between distros.

Re: Operating Systems Without Systemd

#102

Post by zenlot »

pnako wrote: post #95
stouset wrote: post #81

Earlier quoted context omitted.

You know, I had to integrate with `journald` a bit ago and I was prepared for a nightmare after all the ruckus raised about systemd. And you know what? It’s fantastic . The API is generally well-designed (if not without a few sharp corners) and the whole thing is incredibly well thought out. Sure, plain text logs let you use standard UNIX tools. But doing so sucks . God help you if there’s a newline in your logs or i…

Next, have all the settings in some sort of central database. And in 20 years, Red Hat will have finally finished re-inventing Windows NT on top of the Linux kernel.

Have you ever worked with IBMs AIX? It has ODM and it’s amazing. Systemd is going to the right direction.

Re: Operating Systems Without Systemd

#103

Post by robocat »

nrclark wrote: post #47
wrycoder wrote: post #32

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.

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

Re: Operating Systems Without Systemd

#104

Post by marios »

nrclark wrote: post #47
wrycoder wrote: post #32

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.

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…

I have a problem with how service files are good, except when you don't get them right on the first try and it's difficult to debug (unless I've missed something obvious). More generally, I find that systemd is difficult to observe and thus debug. To debug an ancient init.d script, you'd just run it with "sh -x" rather that sh, and you would have a trace of what the script is doing.

If your service file is a tad more complicated, then you quickly discover that there's a scripting language masquerading behind key/value entries.

I have a hard time wrapping my head around dbus being the core component used for coordination among systemd components. dbus wasn't built for this use case, and having PID1 depend on a well behaved dbus for proper system operation sounds insane. systemd adds a lot of features, which means additional complexity. My understanding so far is that the tooling is not there yet to manage this complexity.

Another gripe I have with systemd is that it does parallel service start introduces non determinism at boot. Which means your setup could work very well most of time, but fail miserably 1 time out of 10. Not exactly what you'd want if you are rebooting a remote server for example. s6 [1] init doesn't appear to have this problem.

[1] https://skarnet.org/software/s6/

Re: Operating Systems Without Systemd

#105

Post by marios »

256 wrote: post #57
nrclark wrote: 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…

> 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 application. Certainly not at systemd level. Because in that case, you need to do some insane things (IMO), like link tmux with libsystemd [1].

[1] https://github.com/tmux/tmux/issues/428nk

Re: Operating Systems Without Systemd

#106

Post by f1refly »

the_why_of_y wrote: post #97
dogecoinbase wrote: post #41

Earlier quoted context omitted.

Modules which only work with their own other modules and fail to work with other people's modules aren't modules, they're a monolith.

Would you say Postfix is a monolith? Or qmail?

yes and yes. Fairly small ones, but monoliths nonetheless.

Re: Operating Systems Without Systemd

#107

Post by ori_b »

mappu wrote: post #92
ori_b wrote: post #79

Earlier quoted context omitted.

Wut. What has it de-cargo-culted? Most of the stuff that could use de-cargo-culting is still there under it.

Runlevels, for one.

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.

Re: Operating Systems Without Systemd

#108

Post by majewsky »

marios wrote: post #105
256 wrote: 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…

> 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 everything cleaned up after them unless they explicitly want something like screen or tmux to linger.

> you need to do some insane things (IMO), like link tmux with libsystemd

That would probably be the easiest choice for the tmux devs. If they don't want to link libsystemd, they could have accessed logind's DBus interface directly (either by calling dbus-send(1) or via libdbus). Contrary to wide-spread belief, systemd does, in fact, present well-defined and documented interfaces that other daemons can implement as well (and they do, see elogind). libsystemd is not magical.

Re: Operating Systems Without Systemd

#109

Post by majewsky »

ori_b wrote: post #79
wmf wrote: post #71

Earlier quoted context omitted.

Right, and systemd is pretty much the only successful attempt to de-cargo-cult Unix.

Wut. What has it de-cargo-culted? Most of the stuff that could use de-cargo-culting is still there under it.

Init scripts used to be mostly unportable since every distro shipped with their own support library. You could technically have a portable init script, but it would not behave like the rest of the distro's native init scripts in terms of status reporting etc. systemd units behave the same across all distributions.

Another smaller thing: /etc/os-release replacing the various /etc/*-release files.

Re: Operating Systems Without Systemd

#110

Post by majewsky »

isbjorn16 wrote: post #77
deadbunny wrote: post #59

Earlier quoted context omitted.

You can output journald to syslog with one config option[1]. 1. https://www.freedesktop.org/software/systemd/man/systemd-jou...

Then it should be on by default. Having to use journalctl instead of reading a plaintext file in /var/log should have resulted in a swift slap upside the noggin the moment it was first considered. I otherwise don't care about systemd, except for the more-than-one locations I might find an init script hiding on my system. It's fine. But don't make me use journalctl just to tail a god damned file like a normal person.…

> Having to use journalctl instead of reading a plaintext file in /var/log should have resulted in a swift slap upside the noggin the moment it was first considered.

I absolutely love the idea of journalctl (without commenting on the execution).

As an admin, there was always the chance that $DAEMON_OF_THE_DAY put their logfile in a particularly creative place, thus sending me on some wild goose hunt. Now it's just `journalctl -u $DAEMON` and that works immediately, every single time.

Also, as a user running journald on a notebook, I love that it's just one config switch to send all the logs from all the services to /run instead of /var, to reduce the write load on the SSD. Sure you could fiddle with a bind-mount but that would have to happen very early in the boot process so I don't think it would be as reliable.

As a daemon writer, it's one less option for me to care about. Especially when my daemon is just some bash script, logging to stdout is the easiest way.

And logging to stdout also meshes well with running the same daemon/script in container environments like Docker or Kubernetes where containers usually don't even have syslogd. (In fact, I have containerized a service that requires syslogd and that was kind of a pain. I ended up using a mini-syslogd implementation that just dumps all logs on stdout so Docker can pick it up.)

Post reply on HN