systemd0 is a replacement for the sysvinit daemon used in GNU/Linux and Unix systems, originally authored by Lennart Poettering of Red Hat. It represents a monumental increase in complexity, an abhorrent and violent slap in the face to the Unix philosophy, and its inherent domineering and viral nature turns it into something akin to a "second kernel" that is spreading all across the Linux ecosystem.

This site aims to serve as a rundown and a wake-up call to take a stand against the widespread proliferation of systemd, to detail why it is harmful, and to persuade users to reject its use.

Seriously, anyone tries to discredit systemd needs to state very clearly:
a) technical reasons why systemd design is bad (e.g there is no design at all, etc)
b) technical reasons why systemd implementation is bad (why running everything from PID 1 is bad, etc)
c) non-technical reasons why systemd is bad (e.g. the guys behind it are a**s, etc)
d) non-technical reasons why systemd is bad *for the normal user*
e) and if we do avoid systemd, what would be the implications (e.g. no GNOME 3.8 for you, etc)

systemd is meant to be "system daemon", that is, the daemon that runs "the system" (ie your computer) for you. If you read my linked article, you will get the impression that its authors thinks that systemd is much more important than the kernel itself (despite the fact that systemd will only run on Linux kernel and not everywhere else) --- but this is not a valid reason why we should not use systemd.

If we can't articulate these points then it's just "my words against their words" kind of thing and things will not get better._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

I would prefer an event handler that simply runs an appropriate command or built-in function. Systemd comes close but overcomplicats it. I wrote a simple hotplug handler in shell that outperforms udev and mdev ... the only reason the old hotplug scripts were so slow was the code quality; specifically insufficient use of built-in functions._________________Web Programming - Pet Packaging 100 & 101

As I mentioned before, it is quite unlikely that Puppy would ever use systemd -since puppy already eschews the normal init process in favor of its own init. However, the use of systemd elsewhere has an impact on Puppy -since Puppy uses binaries snatched from other distros, these binaries come with their own requirements. Specifically, anyone trying to use gnome or gnome-related desktops will already have to deal with systemd requirements -and KDE will probably also follow this trail.

I think it is possible to use systemd in Puppy, because eventually, initNEW runs /sbin/init.

However, I do not like systemd because it includes many components - some aren't useful for everyone and cannot be replaced with alternatives.

Also, it's heavier than BusyBox' init, but doesn't offer any additional useful functionality. The current init solution Puppy uses is sufficient, as long as we don't use GNOME.

Moreover, systemd is younger and less polished than other solutions, so it's less stable. It's risky to have a PID 1 process that does more than signal handling.

EDIT: finally, I'm worried about the path FOSS is going. I do not want Red Hat to control Puppy. It's systemd, PulseAudio and D-Bus. So far we're fine, but I'm afraid this won't last forever - I think Wayland's mainstream status will be a disaster for FOSS. Just take a look at the list of people who worked on Wayland support in GNOME._________________My homepageMy GitHub profile

iguleder, google for ignorantguru and read his blog. you will find that he comes to the same conclusion. note that puppy and Gentoo are perhaps the last bastions holding out against systemd - even lfs now builds with systemd (thankfully, they still have a version without systemd - but I worry how long this will last).

the problem with systemd can be summarised as follows: can anybody tell me, in a short simple sentence, of what systemd actually is? (not what it does, but what it is. )_________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

can anybody tell me, in a short simple sentence, of what systemd actually is? (not what it does, but what it is. )

Is RHEL attempt to unify (ie control) GNU/Linux
RHEL is the single biggest contributor to the Kernel and GNOME projects.
Systemd "controls" userspace.
GNOME is a UI.
Now GNOME "needs" systemd.
Pretty soon systemd will "require" GNOME.
End of the story._________________Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too

In other words, Red Hat tries to keep Linux a kernel, but make RHEL the only distro you can actually build on top of it.

But this won't happen. No matter which major component of Puppy gains a hard dependency on systemd, we can kick it out. We've got home-grown replacements for udev (I'm aware of at least three of them), D-Bus can be easily replaced with stubs and there are many syslogd implementations out there (even I wrote one)._________________My homepageMy GitHub profile

I would prefer an event handler that simply runs an appropriate command or built-in function. Systemd comes close but overcomplicats it. I wrote a simple hotplug handler in shell that outperforms udev and mdev ... the only reason the old hotplug scripts were so slow was the code quality; specifically insufficient use of built-in functions.

Is there any implementation of your handler within any existing puppy as far as you know? What would it take for someone like me to try this out? (bearing in mind I'm too dumb to know how to build it into a pup myself...)

I would prefer an event handler that simply runs an appropriate command or built-in function. Systemd comes close but overcomplicats it. I wrote a simple hotplug handler in shell that outperforms udev and mdev ... the only reason the old hotplug scripts were so slow was the code quality; specifically insufficient use of built-in functions.

Is there any implementation of your handler within any existing puppy as far as you know? What would it take for someone like me to try this out? (bearing in mind I'm too dumb to know how to build it into a pup myself...)

I tested it out using a modified aboriginal linux and pupngo, but I ran into a bug with musl libc's mknod (since fixed) and lost traction/interest before Rich patched it. Unfortunately I don't have any devices that require firmware anymore, so I can't thoroughly test that part._________________Web Programming - Pet Packaging 100 & 101

But this won't happen. No matter which major component of Puppy gains a hard dependency on systemd, we can kick it out. We've got home-grown replacements for udev (I'm aware of at least three of them), D-Bus can be easily replaced with stubs and there are many syslogd implementations out there (even I wrote one).

We can still do that now. Apps from parent distro that depends on systemd can simply be re-compiled without systemd dependency. But when apps starts to have systemd as a "hard dependency" at the source level (i.e. it won't compile unless systemd libraries are in place), then we have problem. One apps, fine, we can patch it. Two apps, fine, we can patch it too. If there are many of them, we'll be in trouble. It's not a technical problem to patch them, it's the manpower problem.

Stubs is the way to shortcut it, but then as systemd complexity arises we may need more and more complex stubs (the dbus stubs - can't recall who did it, was it your or technosaurus - doesn't always work; the app decides to crash instead).

And yet there are places where even stubs won't work - I give you one example: udev and Xorg.

I have seen technosaurus' hotplug implementation and it is indeed excellent. One can easily throw out udev (and busybox mdev, even) and use it instead. There is only one little problem: Xorg auto-configuration requires libudev. That is, if you want to have hotplugged device to work with Xorg (without having to restart it), you need to compile Xorg with libudev; and udevd has to be running. Stubs won't work, and the excellent script from technosaurus won't work here either --- unless one wants to patch Xorg to get the information from the script instead of libudev.

My hope is that people who write system applications don't ever fall into the trap of making systemd as a hard dependency, but I don't know whether this is just wishful thinking when so many of them are already in RedHat's purse. RedHat has already subsumed udev and bind it to systemd (making the excuse that udev and systemd are maintained by the same people). It caused uproar, but in the end only gentoo made the right move (fork udev to eudev). As noted, version 3.8 of GNOME now has systemd as a hard-dependency (no systemd, no desktop for you). If this trend continues, pretty much everything will depend on systemd ...

---

A part from other technical concerns, my biggest concern about systemd is that there is no scope to it, there is nothing too big to be left outside systemd. Systemd isn't just an init replacement, it's not only a syslogd replacement, it's not only a service management supervisor, it's not only your privilege escalation management, (together with udev) it's not only your hardware management supervisor, it's not only your network management supervisor ... it is bigger than that, and it's getting bigger as time goes on ... to the point that some jokes that perhaps the kernel will be merged to become part of systemd, too _________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum