Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"

[starshipeleven]

You do realize that sysadmins and developers make up a pretty significant chunk of the Linux userbase?

They also usually like systemd very much.

You know, the ability to actually write configuration and not fucking code to manage services is so amazing.

[Delgarde]

I seem to recall BSD doing a similar thing as well - mapping up the systemd APIs, as all the modern DEs nowadays use said APIs to handle such things, to distance themselves from the underlying system design while still allowing for usable configuration mechanisms and the like.

I know they tried... I don't know how successfully. It's long been a problem for the BSDs that while they're willing to do this kind of work — providing native implementations of APIs initially developed on Linux — they've always struggled to deliver on manpower.

It's been that way since the early days of Gnome, KDE, etc... as soon as they started trying to offer better hardware integration for users, it tied them more to a specific OS. And even though everyone wanted to do abstraction layers to preserve cross-OS compatibility, the problem kept coming down to this — all the work was being done by the much larger number of Linux developers, and BSD just didn't have the people to make things work for them.

[aht0]

This simple fact actually caused GNOME support to suddenly take a massive leap on Solaris, when they were able to just implement all the systemd API's for things like session-, locale-, console-, time management, etc.
Since systemd had taken the time to actually create a set of well-documented and supported API for doing these system-facing actions, GNOME of course switched their GUI implementation to using them, so that they wouldn't have to deal any more with the minutia of how to - for example - interface with the NTP service on all possible init systems and configuration designs. And at that point, all that the GNOME-on-Solaris devs had to do was write stub services that mapped the Solaris configuration APIs onto the systemd endpoints, and suddenly they were able to switch to basically running unmodified upstream code - improving system stability, security, and the update tempo.

I seem to recall BSD doing a similar thing as well - mapping up the systemd APIs, as all the modern DEs nowadays use said APIs to handle such things, to distance themselves from the underlying system design while still allowing for usable configuration mechanisms and the like.

FreeBSD Gnome3 version is nearly 2y old. Portability problems.

[sabian2008]

This simple fact actually caused GNOME support to suddenly take a massive leap on Solaris ....

Nice burn!

The stagnation of this discussion for the last 5 years really shows almost everything that is wrong with (a small, but very loud and arrogant, subset of) the Linux community.

Developers like it, they don't work for you, don't tell them how to spend their time.

Of course, it doesn't fill every use case, not a single piece of software has ever done that. But if you need (not prefer) a tailored init system, you aren't chasing the mainstream desktop/server experience. In that case, what is the damn problem with using a non-mainstream distribution that has the init system you need?

[starshipeleven]

Modern Software Development is Cancer

"...PulseAudio? Is my sound any better? No. Shit. Wayland? Are my graphics any better? No. Shit. Systemd? Is my system more stable and/or boots faster? No. Shit. And the list goes on and on and on and on...
"...Windows 10. Half-baked releases. I didn't pay money for a half-baked crap you will complete in 2 years. I don't need a system settings menu that will be equivalent to the Control Panel in 6 months when I had the perfectly sane and functional Control Panel in Windows 7/8 years ago...

"...When I go to a restaurant, I don't want to know what the staff is doing with my food. I'm paying for the service and ignorance. And I expect the same from software. I'm paying, I'm the boss. It's time the software industry started serving its boss, the user..."

https://www.dedoimedo.com/computers/...nt-cancer.html

that whole article is bullshit

[BwackNinja]

Ok at the risk of feeding the trolls... what's with this fetish of what they call "init" systems? No-one seems to whine for "choice" between 10 incompatible and broken system call ABIs, why should the event, configuration and services manager be any different? Besides, Linux has IMHO a very pressing and urgent need for de-unixifcation and systemd is probably a very good place to start.

At the risk of giving you much more information than you are actually looking for, people want a lot of choice, everywhere. If you've ever built a kernel, you can appreciate how many options there are and the big difference between trying to maximize compatibility versus trying to make something small and specific to a certain set of hardware. System calls are actually an area that people talk about, mostly whether to use operating system-specific extensions or only POSIX-compatible ones, and the calling conventions are different between Linux and FreeBSD for example, though that's normally handled by the C library rather than directly in your own code.

On to init systems and friends, it's all more of an philosophical exploration of what it means for something to be a 'service' at all, and what the intended lifecycle is. Is a group of commands a service if it runs at startup and exits when complete? Who is responsible for managing a service's dependencies -- the application or the service manager? How do you determine whether a service is up? Should a service stop when a service it depends on stops?

My take on that is the whole idea of a service should mean that it provides a resource to be used either locally by other services or applications, or remotely by users on another machine. A job is different, because it may use services and executes a certain action, but it doesn't also provide any resource. The big problems I still see with service managers and the surrounding landscape is that these resources are often dynamic and configurable in the service's configuration files, so you have to re-encode that information in your service manager's configuration in order for other services to properly depend on it. Services that expose their resources over DBus are easy to deal with because it's clear what resources they expose -- their bus path. For other services, like mysql or apache, you can be listening on a configurable socket and/or port, particularly useful as an option if you're running multiple instances. This could be solved by services telling their service manager "hi, I want to expose my service on port 3306 and /run/mysql/mysql.sock", which would clearly indicate conflicts with other services and create a transient resource that other services could depend on, rather than depending the other service explicitly. Auditd can listen to syscalls that would indicate those situations[1] so if that was implemented in a service manager, applications wouldn't have to be modified to give that information. But then you still have the potential issue of dynamic dependencies and the need to encode those somewhere, or have the application take care of those itself. I don't know of a service manager that does this, and haven't even heard people talking much about doing something like that, so I don't think the init system discussion is anywhere near over and there is no ONE TRUE WAY. I don't think even Poettering himself would say that systemd is definitely right, only the current best solution.

UNIX and Linux have gotten as far as they have because of their flexibility. You can look at these problems, think about solutions to them, and implement them to see how well they work in practice. That's why daemontools, s6, runit, and co exist. That's why upstart got to be a major player. That's how systemd got to where it is. You may find talking about low level system components to be uninteresting, only looking forward to what new fancy applications will run on top of them, but there's definitely a lot to still discuss -- this is barely scratching the surface.

[1] https://serverfault.com/questions/71...tart-listening

[spstarr]

Honestly, you don't know about Fedora nor Red Hat Enterprise. Fedora needed a better system management because Upstart couldn't fill the needs thanks to the CLA imposed by Canonical (which was the reason systemd was born) and sysinit was completely a roadblock.
Systemd developers despite obstacle and opposition within Red Hat development (the team is very diversified as some of employees have Debian, Ubuntu and Arch backgrounds) had to convince the very conservative Red Hat department the new system manangement at the time was a better solution.

Please don't assume you know me. I know more about both given I've been there from the very beginning of Fedora .... anyhow. I know about that history... it doesn't change the fact a lot of people I know personally in Red Hat or who were in Red Hat HATED systemd and refused to even use Fedora for their development... kernel development....

[L_A_G]

They also usually like systemd very much.

You know, the ability to actually write configuration and not fucking code to manage services is so amazing.

Nice try at a straw man, but you're talking about features and I've been very clear that my complaints, like most who voice concerns over SystemD, are about the way it's been implemented and the project managed.

What you tried there is like trying to counter complaints about a restaurant where the whole place, kitchen included, is absolutely filthy and the staff is incredibly rude by pointing out that they've got some popular items on the menu.

[Ananace]

I know they tried... I don't know how successfully. It's long been a problem for the BSDs that while they're willing to do this kind of work — providing native implementations of APIs initially developed on Linux — they've always struggled to deliver on manpower.

It's been that way since the early days of Gnome, KDE, etc... as soon as they started trying to offer better hardware integration for users, it tied them more to a specific OS. And even though everyone wanted to do abstraction layers to preserve cross-OS compatibility, the problem kept coming down to this — all the work was being done by the much larger number of Linux developers, and BSD just didn't have the people to make things work for them.

I must imagine that having a well-defined API to implement would be a lot simpler than having to patch - and manage the patches for - all the upstream projects, in order to replace all their system-facing code.
With well-defined API endpoints in place, BSD wouldn't have to try and emulate Linux layouts or commands in order to fool the DE to think things are being done correctly, they'd just have to implement the APIs in a BSD-sane way while maybe massaging their return values to map to what the API spec defines that they should be.

[starshipeleven]

Nice try at a straw man, but you're talking about features and I've been very clear that my complaints, like most who voice concerns over SystemD, are about the way it's been implemented and the project managed.

It's not a straw man. I just pointed out that most sysadmins don't care about how many people Pottering *allegedly* killed in dark alleys on a full moon.

The software provided works better than its predecessor, therefore they are happy about it.

What you tried there is like trying to counter complaints about a restaurant where the whole place, kitchen included, is absolutely filthy and the staff is incredibly rude by pointing out that they've got some popular items on the menu.

No what I've tried is to say that what they do works better than the predecessor, and that's the only thing that matters for actual users of the software.

I'll also weight in with my own experience on systemd issue tracker and I'll tell you that I'm not seeing anything strange. We actually get quick answers (for opensource project standards) and direct intervention of project leaders and lead developers.