Should we plan on systemd ?

[AK-47]

I just don't want systemd to squeeze other inits out. Because if they do and we are left with only systemd, who knows what else will be made a hard dependency/requirement of systemd. Will we have to use their homed /home directory? their systemd bootloader?. Right now these are only optional functionality parts of systemd.

In this case it's not so much whether or not a distro adopts it that's the problem, but what applications will be available that don't rely on it. As a dev I can appreciate why an application developer would go, screw this systemd is the popular one we'll only bother with this. There is more than enough fragmentation (under the guise of choice) for the fundamentals as is which is why it's difficult for applications to support Linux, and now they have to worry about the myriad number of ways in which to do basic things which should have a set standard, such as service management and, well, starting the bloody operating system.

So this isn't really as much as a debian thing as it is a matter of application compatibility, it's a shame the winner is a pile of scope-creep galore, but it goes to show that luck, support, marketing and working with others beats mere technical superiority. I have heard (but have not confirmed) that Debian may be working on a scheme to support multiple inits. In essence, while distros started it, the consensus of the loudest and most prominent of the Linux software ecosystem have forged this path.

Just how safe is systemd to attacks when it is such a big program, and it wants to take over more and more tasks?

There's enough stuffed into the kernel (for instance, kSMBd) that should make any security conscious person quit their job in a heartbeat and turn into a monk. I think systemd will either turn out to be the least of one's problems, or it will be equally as bad as the kernel's problems.

[Freja]

We're fans of solid simple MX.
MX way is not same as Ubuntu way... At the very least, I think SysVinit default is a must.
(above saying as a MX User)

[oops]

Right Freja ... The Unix/Linux philosophy is documented by Doug McIlroy in the Bell System Technical Journal from 1978: Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". Expect the output of every program to become the input to another, as yet unknown, program.

[DukeComposed]

Right Freja ... The Unix/Linux philosophy is documented by Doug McIlroy in the Bell System Technical Journal from 1978: Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". Expect the output of every program to become the input to another, as yet unknown, program.

Lest we forget, Doug McIlroy is the UNIX co-founder no one remembers, and the one who encouraged Ritchie, Thompson, and Kernighan to implement pipes.

In 1986 Jon Bentley asked Don Knuth -- yes, that Don Knuth -- to solve a problem about taking arbitrary text input and output a word frequency count. Knuth wrote a custom program in a custom programming system he called WEB, using a custom data structure. Doug McIlroy complimented the sophistication of his approach, pointed out its flaws, and then solved the same problem in a short and sweet UNIX one-liner. Keep in mind that the only reason McIlroy's solution calls "sed" is because the "head" utility hadn't been written yet.

EDIT: typo

[Artim]

I'm curious about how antiX is able to be completely free of systemd (without any need for "shim"). Adding a desktop environment adds elogind, which I think is a component of systemd, but on my SalixOS machine (Slackware-based) I can use Xfce without any of the shims, elogind, or other work-arounds.

I'm not knowledgeable enough about any of this to know how or why one distro compared to another is able to get around the systemd issue completely or partially. But I trust the developers to know what's important and how to implement it.

The only way I know to completely avoid systemd - I think - is to get away from the Debian base and use one that doesn't "compromise" by adding bits and pieces of systemd to accomplish the goal of a fantastic OS like MX. Could it be that the future of systemd-free OSes is a Slackware base or a Devuan base? Does PCLinuxOS have these "bits and pieces" of systemd as well?

[anticapitalista]

Both Slackware and Devuan use elogind, while PCLOS uses consolekit.
elogind is systemd without systemd being the init system.

It's not just about systemd or even elogind.
Debian's version of udev is packaged to include dependency on components of either systemd or elogind (ie libsystemd0 or libelogind0) so it is impossible to be systemd/elogind-free using pure Debian.

As for MX, the devs have said that in the worse case scenario, they will build separate isos - one with systemd and the other with sysVinit.
From what I understand, MX devs are not interested in supporting other init systems.

[AVLinux]

As a dev I can appreciate why an application developer would go, screw this systemd is the popular one we'll only bother with this. There is more than enough fragmentation (under the guise of choice) for the fundamentals as is which is why it's difficult for applications to support Linux, and now they have to worry about the myriad number of ways in which to do basic things which should have a set standard, such as service management and, well, starting the bloody operating system.

This is an extremely good point and the core of a lot of issues in Linux, an inconvenient truth for sure...

[anticapitalista]

As a dev I can appreciate why an application developer would go, screw this systemd is the popular one we'll only bother with this. There is more than enough fragmentation (under the guise of choice) for the fundamentals as is which is why it's difficult for applications to support Linux, and now they have to worry about the myriad number of ways in which to do basic things which should have a set standard, such as service management and, well, starting the bloody operating system.

This is an extremely good point and the core of a lot of issues in Linux, an inconvenient truth for sure...

I disagree with this point.
The vast majority of software is init agnostic - it simply does not care what init is running.
The problem is that Debian packagers add systemd/libsystemd0 as a hard dependency even if the app does not require it at all

[asinoro]

I disagree with this point.
The vast majority of software is init agnostic - it simply does not care what init is running.
The problem is that Debian packagers add systemd/libsystemd0 as a hard dependency even if the app does not require it at all

Since you are one of last Mohicans that fight the beast, what other alternatives are away of Debian which could be user-friendly?

[Charlie Brown]

... Debian packagers add systemd/libsystemd0 as a hard dependency even if the app does not require it at all