Hacker News Reader

Hacker News

Comment by pantalaimon | Hacker News Reader

Parent Full thread

pantalaimon

> What packages which only support systemd are we actually talking about

Gnome, Wayland, KDE

> how much work would it be to untie them?

a lot

View on HN

I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal.

For example policykit was broken and things like mounting USB devices or managing VPN connections didn't work. That is finally fixed and with latest cgmanager from unstable, and policykit-1 from experimental those things work again.

The only noticable loss compared to systemd is the lack of 'Suspend/Hibernate' in the KDE menu, but you can still use 'pm-suspend' from the cmdline, or even with 'qdbus' and the systemd specific dbus API, so in the end this should be fixable too.

So I wouldn't put KDE into the same bucket as Gnome, its dependencies on systemd seem to be mostly indirect:

* policykit, which started to depend on systemd-logind instead of consolekit. Works with cgmanager+systemd-shim as replacement

* upowerd doesn't support suspend/hibernate anymore but apparently, so apparently systemd specific dbus methods have to be used now.

Also Gnome3 works under OpenBSD (with consolekit?), and there is definitely no systemd there, although it might not be the latest version: http://callfortesting.org/gnome3/

> I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal.

I'm having a similar experience with systemd. I had problems with USB storage (seems fixed now) and I'm still having problems with networking. DBus went haywire, not sure if it's in a sensible state yet or not. I haven't been using VPN connections or suspend.

This isn't exactly a nightmare scenario. Most of the evident problems with systemd seem to be fixable. I can't say I'm impressed. I'm also having a hard time remembering why it was so important to move away from sysv init in the first place.

There is an architectural failure if your desktop environment depends deeply and inseperably (product tying) on how you spawn processes at boot.

systemd may or may not suck and I'm not discussing that aspect in this post. What definitely horribly sucks is product tying a desktop environment (you know, cut and paste, drag and drop, background images, window animations) deeply in with the earliest intricacies of the boot process.

systemd provides a lot more than spawning processes at boot. It aims to provide all essential operating system deamons and a common userspace interface for them.

Is systemd eventually going to contain Wayland, then? SSHd? PAM? Samba? How far does this go? Is it going to end up that if I want configurable logins (a la PAM), or to access a SMB file server, I need to use systemd as my init system, log management system, and whatever else?

>Is systemd eventually going to contain Wayland, then? SSHd? PAM? Samba? How far does this go?

Farther than that, I bet. It's pretty safe to assume that all of those things are already written on a few informal systemd roadmaps.

I really hope that that's a joke that didn't translate well into text, as taking it literally, I would suggest seeing a doctor about that paranoia :S

If at some point that is considered as "essential" as in "I can't boot a system without", then maybe. However, there's a way to avoid that path: Write a better init system than systemd. Or contribute the extra effort to make sshd, pam, samba, wayland, gnome, kde work without systemd. All that systemd does is offer a service. It seems to pay off for gnome and kde to rely on that.

I can already boot a fully functioning system without half the stuff in systemd (and in fact, there's entire distros and the entire world of embedded devices which do so).

GNOME and KDE did work just fine without systemd until they didn't. udev did as well. Samba, PAM, OpenSSH, and most of the rest of the services on my system, work just fine without it. I rather doubt that'll be the case five years down the line.

Write a better init system than systemd.

Done many times.

...Oh, wait.

You mean to tell me that systemd isn't just an init system? And that it includes, but is not limited to, and I quote [1]:

"init system, journal logging, login management, device management, temporary and volatile file management, binary format registration, backlight save/restore, rfkill save/restore, bootchart, readahead, encrypted storage setup, EFI/GPT partition discovery, virtual machine/container registration, minimal container management, hostname management, locale management, time management, random seed management, sysctl variable management, console managment, . . ."

They are working on:

"network management, Local DNS cache, mDNS responder, LLMNR responder, DNSSEC verification, IPC in the kernel, time synchronisation with NTP, stateless systems, factory reset, OS/container/app image format, sandboxing of services and apps..."

[1] http://0pointer.de/public/gnomeasia2014.pdf

So what people really mean by "Write a better init system." is "Write a second, competing hulking mammoth like systemd."

One only need to re-implement the interfaces actually used by the DEs. IIRC GNOME had a page listing those interfaces on their wiki and systemd has remarkably good documentation about its public interfaces.

Also consider that until now many of the things you listed were done by shell scripts that every distro reimplemented differently, so if you're happy with such ugliness you can pick it up as-is. ;)

> However, there's a way to avoid that path: Write a better init system than systemd. Or contribute the extra effort to make sshd, pam, samba, wayland, gnome, kde work without systemd.

The latter is the easier approach. However, it's still hard. The major problem is logind, and no-one has yet tackled writing a logind that layers on top of Debian-without-systemd. See: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...

Which is oppositional to the unix philosophy. There will be only one permitted http server and one permitted database server, all that is not permitted will be forbidden and all that it not forbidden will be mandatory.

> systemd provides a lot more than spawning processes at boot.

And that is exactly what I think is the most irritating thing about it. I just want it to init my system. I'll do the rest, or decide which piece of software should. NOT the systemd developers.

The systemd developers don't decide that. They offer capabilities. Obviously the value proposition is attractive to other developers, thus they're using it. It's not like they're forcing others at gunpoint to adopt their tech. If you don't want to use it, don't. Pick software that doesn't rely on systemd capabilities. Or advocate that that software gets written and maintained. Or write it yourself. Or stop complaining. Just don't tell somebody to not offer a capability.

> If you don't want to use it, don't. Pick software that doesn't rely on systemd capabilities.

Doesn't this becomes more difficult though, when things people are used to like KDE/Gnome are depending on systemd?

What happens if more tools start depending on systemd? Will people just have to keep finding alternatives?

> What happens if more tools start depending on systemd? Will people just have to keep finding alternatives?

Linux becomes the new OSX (Slick, integrated, everything works great as long as you are doing the things that the system designers expect you to do); FreeBSD becomes the new Linux (Weird and confusing out of the box, but can be customised however you want it)

> It aims to provide all essential operating system deamons and a common userspace interface for them.

I think that is the reason so many people dislike it.

Replacing init - and nothing else - is something many of those people would be totally fine with. Starting services in parallel, and watching them when running, restarting them if they crash, that is something a lot of people would like very much, I am certain.

But the systemd developers did not stop there and are trying - it seems - to have systemd replace everything but the proverbial kitchen sink. I am not even saying that this is a bad (or a good idea). But doing so just rubs many people the wrong way, if only because it means the systemd people are attempting to change an important aspect of the architecture of the system without having a proper discussion about it first.

To be fair it mostly replace lots of stuff that every distribution had reimplemented in a incompatible way.

Desktop environments now have an actively-maintained cross-distro interface that they can target to simplify their life (from setting the hostname to secure multi-seat handling), so it's not a surprise that they make use of it.

That sounds like a pain for my desktop, but implies there's still hope to use a simpler init on my servers so long as the coupling doesn't increase.

My advice: consider a move to FreeBSD on servers. I know it might seem drastic, but if you're looking for a simpler init system, they've probably got a closer philosophy to you anyways.

That's what I've found at least, their rc system is dead simple, like Arch used to be before they started making changes to allow for systemd. I miss the day's of arch's rc.conf.

I clearly need to learn a lot more about FreeBSD (and it's cousins) but unfortunately we're committed to Docker for server deployments.

Debian's sysvinit script wrappers were not in any way simple.

But servers is precisely where systemd is particularly useful. Having tools to interact with the init system and proper logging are invaluable.

Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. Sure there is some additional information that systemd stores in logs that syslog wouldn't, but implementing that could've been done while keeping the main log text-only (eg: have an id for each logline in your human-readable text logs, and have the binary/index etc separate that refer to that id).

>Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging.

No need to be quite so weaselly: 'Many disagree...' is something I'm pretty sure you could provide references for if pressed.

Hi, I've run infrastructure and software projects involving thousands of machines for companies with over a trillion dollars in asset under management. Binary logs and putting coredumps in your journal are stupid and anyone who does that doesn't understand the first thing about running systems.

I'm not a professional sysadmin (at least not at your level) seriously curious why a binary log is so bad. I guess in big deployment logs are collected to a central location, so I don't understand the "corruption" issue many people usually raise.

Also, what's so bad about coredumps? You can disable storing them in the journal, discarding them or saving them in a separate location (which is the default). Where coredumps are rare (which I guess it's the case in most of the deployments) it seem nice having a clean, standardized way to manage them.

Structured data is very useful. Just because many unix folks have managed to extract some meaning out of random text for so long doesn't mean it's a good idea.

This is the same thing I see about HTTP/2. It's good to finally remove a huge number of parsing errors and inefficiencies!

I'd be less opposed to journald if it used SQLite instead of its own format, but I still think that logs don't belong in a binary file by default: https://news.ycombinator.com/item?id=7210570

The problem with sqlite for this is that as you write more and rows into a table then the writes get progressively slower -- it simply isn't able to do O(1) writes over a long period of time so you'd have to rotate the database files themselves.

I've been solving this problem by writing a non-pretty printed JSON blob to one line in a log file. Structured, but still text and very easy to stream. I build a separate binary index that gives more efficient time based lookups, but it isn't needed to understand and process the log file.

Did you release your code that does that?

No. It's in a monitoring system we've been working on, but the principle is pretty simple. We may well end up open sourcing quite the rest of it sometime in the future -- a lot of the code already is.

People already complain about systemd dependencies, I'm sure pulling in SQLite would have generated more complaints than a quite simple custom binary format. :)

And that's part of the problem. Some systemd parts makes sense for server, some make sense for desktop, but trying to select just those that fit scenario X is a pain in the behind.

It's really good on a desktop as well, particularly for laptops. Services come and go based on what's plugged in, etc.

systemd is the launchd for Linux I've been wanting for years.

Reply on news.ycombinator.com