Could systemd be an inconvenient on portability?

In case you do not look it up here are a few snippets:
(Alien Bob Slackware Contributor):
"Some things will probably be forced upon Slackware - PAM has been on the "carefully circumventing but you never know" list for a long time. PAM is not bad to have at all, but it is personal opinion of the Slackware boss which keeps it at bay. That is an architectural decision which we can live with as a team and as Slackware users.
But systemd is essentially evil. It is invasive, extremely hostile to other environments, threatening to kill non-Linux ecosystems which have hal, udev, dbus, consolekit, polkit, udisks, upower and friends as dependencies. And every iteration of the software written by the Redhat employees who are responsible for hal, udev, consiolekit, polkit and now systemd are incompatible with previous releases, re-implementing their bad ideas with new bad ideas... basically proving that these Redhat employees must be declared unfit to work on the core of a Linux distro.

However, the influence of their employer is so big that these products are forced upon the wider UNIX community and at some point it will be "assimilate or die". I hope we (Slackware) will find a way where we do not have to assimilate but still manage to keep the distro working. I have high hopes for KDE which has no Redhat ties and so far, manages to stay clear of this mess, sticking to widely accepted standards.

An example of impending doom: udev sources for recent releases are no longer in existence. They are now part of systemd source tarballs. And udisks? That has been deprecated in favour of the new "udisks2". Read http://igurublog.wordpress.com/2012/...loss-for-linux and weep.

Eric"

(H_TeXMeX_H)

"I think that systemd is only a problem that appears along with GNOME. As Slackware has never included GNOME, I think it is safe for now. The increasing number of applications that require it are likely GNOME-only apps, which I have seen many of, and avoid instantly. If you don't know why I avoid them, try to install one, the dependencies are endless and hard to build in order and if you forget to compile something into one of the dependencies you have to go back and do it again."

(ReaperX7)

"From that video he seems to be thinking his software can directly mimic the speed, user-friendliness, zero-administration, and core functionality of Windows upon the Linux kernel.

Sorry, but Linux and Windows are two different operating systems and systemd isn't about free choice and freedom of administration of the system. It's about controlled automation and a lack of core principles of system security.

I'm beginning to think we'd be better off gathering up some independent developers, or developers from other Linux systems, grabbing the hal, udisks, upower, and udev sources we still have and redeveloping a cross-platform INIT system that can be not only invisible to the system, but completely modular with full control of the system if so desired, works on BSD, Linux, and various other UNIX and UNIX-like operating system kernels and distributions, before Red Hat and Lennart completely destroy Linux and the various OS distributions that use it, and turn it into something it's not and set back Linux yet again as a viable OS alternative to Windows."

Pat in response to someone saying that systemd was fine because it made things simpler and easier:

"Not even close.

"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." -- Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition"

I could go on, but it makes for a great read to follow the above link...there are many other links if you are interested in seeing both sides of the discussion and not just the pro systemd side.

> Yes, in some cases it is better to not to have portability. When there is a piece of free software that has no proprietary counterpart, or is by far technically superior to that technical counterpart, then it is usually better that it runs only on a fully free operating system so that is not portable.

Oh, I see what you mean. I thought you meant that there was situations where it wasn't good to have portability between fully free systems.

Edit: oops, posted in wrong place, this was to marioxcc.

One more from Pat (Slackware founder)
volkerdi
Slackware Maintainer

"Well, the problem with using shell scripts in the boot process is that it goes through a lot of PIDs, and it would be "less ugly" to arrive at a usable machine state with a PID in the hundreds, or lower. If everything has to break in order to achieve that, it seems like a good trade. Eventually all the broken stuff will be fixed, right?

I think that's the basic rationale. And maybe shave a few more seconds off boot time, but who boots much (or cares)? My servers and desktops remain on, and my laptops are usually on, suspended, or hibernated. I would prefer a reliable and well-understood boot system like the one we have.

My primary concern is that the systemd cabal is going to be pushing it as a dependency wherever possible, but we'll deal with that if it happens. But if any major distributions do actually release using systemd, the world will be stuck with it forever. If that's the case, I hope it turns out to be a good idea..."

ok last one from this bunch for now (anyway), but I think this is all very educational for many:

(Alien Bob
Slackware Contributor)

"I would not consider systemd for this reason only: it is being written specifically to work only on the Linux platform.
I am very much an advocate of cross-platform development, UNIX is bigger than Linux alone. Systemd is expected to be used by "userland" programs like KDE and Gnome. However these are also used on BSD, Solaris, HP UNIX etcetera. It is as if Poettering expects that the userland programmers (KDE/Gnome and other desktop environments) and distributors of UNIXes should deal with the incompatibilities and patch their code to make it work on non-Linux OS-es where systemd will be unavailable.
Code that shows this amount of contempt for anything that is not Linux, should be buried without ceremony.

Poettering also said his code is "more efficient" because he does not stick to POSIX compliant programming. The programming shortcuts he takes are non-portable.
I think "more efficient" and "cross-platform" should not be mutually exclusive. Taking shortcuts to make your program do fancy stuff is an immature coding style and better suited for the demo scene. You can optimize code and still keep it cross-platform, there is a lot of software that proves this - look at the multimedia applications that use platform-specific assembler code to squeeze all the available performance out of a computer. Still those applications compile cleanly and can be used on Linux, UNIX, and on several hardware platforms. It takes effort to make software portable and you have to be willing to spend that time - you do it for the users of your software.
Poettering defends his systemd with vigor, but his comments reflect his contempt for any other way of thinking. One of his typical statements is that all his critics are "amazingly badly informed". You can not go into a dialogue with the guy, he just won't listen to your arguments.

So, what are the advantages of systemd? Using "error-prone shell code" instead of systemd is bullshit - it's not as if we have to write new init scripts every week. Replaces consolekit? Poettering and Zeuthen are two Redhat employees who infest computers with half-assed software that they deprecate faster than distros can adopt it. Does it make your computer boot faster? Well wow... how many seconds of productive time do you gain per day?.

It is not worth the hassle.

Eric"

For those that think systemd is just an elegant modern init system, consider this from Potterings own blog:
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html

"We want a unified solution that ultimately can cover updates for full systems, OS containers, end user apps, programming ABIs, and more. These updates shall be double-buffered, (at least). This is an absolute necessity if we want to prepare the ground for operating systems that manage themselves, that can update safely without administrator involvement."

Pottering wants systemd to even take care of updating your entire system, so you the end user or administrator never have to! Can you name one reason why an init system would do this, or even need to? "Prepare the ground for operating systems to manage themselves..." Really!

Interesting post from one of the top Linux kernel developers regarding Pottering and systemd. Comments are interesting as well.

https://plus.google.com/+StevenRostedt/posts/WtGhnM4jVoP

I've been doing some research on portability and systemd but couldn't find much.

> Is systemd going to be an obstacle when people want to port applications to GNU Hurd or other Unix-like systems?

Not sure. But this isn't the first time that happens[1]. People simply use compatibility layers (like Wine) to overcome the lack of portability of the subsequent programs. It works but sill not ideal as lack of portability is the sickness and compatibility layers just a placebo.

This is not related with systemd but with portability in general in the free world. Andy Tanenbaum said this at FOSDEM 2010[2]

It's just amazing how much free software is so crappy, it's not portable. You know, you run ./configure and it always fails, *ALWAYS*. You know, what happens? It was looking for, I don't know, Perl 5.2.3.26.9.4b and if that wasn't there it gives up. Even though the application you're trying to install doesn't use Perl at all.[2]

[1] https://teythoon.cryptobitch.de/posts/on-portability-of-init-systems/
[2] https://www.youtube.com/watch?v=bx3KuE7UjGA Minute 38:20

The following is not something I am saying, I am copy-pasting this from somewhere else, I just think it's insightful.

What is systemd? It's an init system. An init system is the first process started during the boot process, and it is then responsible for starting all of the other processes that need to be started. You control which processes run by default by configuring your init system, as well as things like which process should be restarted is they crash or are killed. It also provides commands for stopping and starting system services. Most init systems limit themselves to that, which adheres to the part of the Unix philosophy that says that programs should "do one thing and do it well". Systemd, however, takes it upon itself to also provide a myriad of other services, some of which are tangentially related to the job of an init system, and some of which are completely unrelated. These include, but are not limited to, a job scheduler, a logging daemon (and a bad one), a device manager, power management utilities, internet services daemon, an ACPI daemon, and a login manager. These services can be disabled, and systemd proponents seem to think that means that it's modular and unix-like. The problem, though, is that these services only work in the context of systemd, and systemd itself only works with the Linux kernel. The Unix philosophy says things like "programs should flexible and open", "programs should be portable", "programs should be good at communicating with other programs", "data should be stored in flat text files", and so on. If you follow these guidelines well and write something like an ACPI daemon, it will work on any operating system that has some basic set of features, totally regardless of what init system it's using and in many cases regardless of what kernel it uses. If you're a systemd developer, nothing should work unless systemd is there, and systemd doesn't work unless you are using the Linux kernel. This behavior is NOT Unix-like. The result on ignoring the Unix philosophy is basically this: if a systemd developer writes a session manager, and a popular desktop environment uses it, that desktop environment now only runs on a single init system and kernel, even though it doesn't depend on either one directly. Suddenly, you start to see user applications that come with these ridiculous dependency chains that go right down to the kernel, and anyone who wants to use that software no longer has any choice as to what operating system components they use. It basically turns Linux into Windows: Take all of it, or take none of it.

In return for all of this ridiculousness, you get literally nothing. It has zero advantages over its modern alternatives, all of which are actually unix-like and modular.

Apparently systemd is giving some problems to Arch users who don't use systemd. Just thought it's relevant.

https://lists.archlinux.org/pipermail/arch-general/2015-July/039425.html