boycott systemd

News, happenings
Post Reply
Message
Author
User avatar
James C
Posts: 6618
Joined: Thu 26 Mar 2009, 05:12
Location: Kentucky

boycott systemd

#1 Post by James C »

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.
http://boycottsystemd.org/

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#2 Post by Flash »

Okay, do the Puppy developers know about this? What are we supposed to do about it?

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#3 Post by jamesbond »

I dislike systemd like anybody else, but the site doesn't give a convincing reasons for boycotting it. This is probably a better link: http://www.phoronix.com/scan.php?page=n ... px=MTY1MzA (make sure you follow the LKML links in that article too).

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 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#4 Post by technosaurus »

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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#5 Post by amigo »

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.

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#6 Post by Iguleder »

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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#7 Post by jamesbond »

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 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#8 Post by Iguleder »

It's my favorite "system daemon" :lol:
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#9 Post by jamesbond »

Iguleder wrote:It's my favorite "system daemon" :lol:
You mean a "daemon" that will take over the "system" ... :lol:
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

bark_bark_bark
Posts: 1885
Joined: Tue 05 Jun 2012, 12:17
Location: Wisconsin USA

#10 Post by bark_bark_bark »

It's too bad the DistroWatch people don't hate systemd.
....

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#11 Post by mavrothal »

jamesbond wrote: 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.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#12 Post by Iguleder »

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).
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#13 Post by greengeek »

technosaurus wrote: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...)

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#14 Post by technosaurus »

greengeek wrote:
technosaurus wrote: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 posted a version here:
http://murga-linux.com/puppy/viewtopic. ... 997#743997
have a look through this thread:
http://www.murga-linux.com/puppy/viewtopic.php?t=70238
and you will understand why the old hotplug scripts and many puppy commands are so slow (hint, excessive use of external commands when equivalent shell functions are available)

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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#15 Post by jamesbond »

Iguleder wrote: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 :shock:
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#16 Post by Karl Godt »

Have nothing brings nothing .

Money is generated if you can tell the bank about something new .
systemd is something new .

Let's face it : Manpower is recruited with money from a bank .
Someone must take a step forward and make Puppy commercial with an openPUPPY branch .

That needs focusing on few hardware setups or machines and kernels that are optimized for these hardwares and they likely would not have the drivers for other setups .

And it needs a headquarter where the developers open a door each day and not some windows .
Since the few developers are scattered all over the world this is currently difficult to enable or not possible .

I for myself only own a crappy eeepc to introduce at a bank .
No laptops in sight .

Main suggestion would be to rewrite *dialog* applications in GTK, since
*dialog* apps are for short dialogs and not for sophisticated GUIs .
Main problem I have with gtkdialog is that the GUI needs to be rebuild completely if variables change .

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#17 Post by mavrothal »

jamesbond wrote:perhaps the kernel will be merged to become part of systemd, too :shock:
Isn't it time for a BSD puppy? :lol:
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#18 Post by Iguleder »

Here's my init:

Code: Select all

#include <stdlib.h>
#include <string.h>
#include <stdbool.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <sys/reboot.h>

/* the init script path */
#define INIT_SCRIPT_PATH CONF_DIR"/rc.d/rc.sysinit"

/* the shutdown script path */
#define SHUTDOWN_SCRIPT_PATH CONF_DIR"/rc.d/rc.shutdown"

#define PRINT(x) (void) write(STDOUT_FILENO, x, sizeof(x))

void _signal_handler(int type, siginfo_t *info, void *context) {
	(void) waitpid(info->si_pid, NULL, WNOHANG);
}

bool _run_script(const char *path, pid_t *pid) {
	/* the return value */
	bool is_success = false;

	/* the process ID */
	pid_t parent_pid;

	/* the process signal mask */
	sigset_t signal_mask;

	/* get the process ID */
	parent_pid = getpid();

	/* empty the signal mask */
	if (-1 == sigemptyset(&signal_mask))
		goto end;

	/* create a child process */
	*pid = fork();
	switch (*pid) {
		case (-1):
			goto end;

		case (0):
			/* reset the child process signal mask */
			if (-1 == sigprocmask(SIG_SETMASK, &signal_mask, NULL))
				goto end;

			/* in the child process, run the init script */
			(void) execl(path, path, (char *) NULL);

			/* upon failure, send a signal to the parent process */
			(void) kill(parent_pid, SIGTERM);

			break;

		default:
			is_success = true;
			break;
	}

end:
	return is_success;
}

int main() {
	/* the process exit code */
	int exit_code = EXIT_FAILURE;

	/* a signal action */
	struct sigaction signal_action;

	/* a signal mask used for waiting */
	sigset_t signal_mask;

	/* the init script PID */
	pid_t script_pid;

	/* the signal received */
	siginfo_t received_signal;

	/* the command passed to reboot() */
	int reboot_command;

	/* assign a signal handler for SIGCHLD, which destroys zombie processes */
	signal_action.sa_flags = SA_SIGINFO;
	signal_action.sa_sigaction = _signal_handler;
	if (-1 == sigemptyset(&signal_action.sa_mask))
		goto end;
	if (-1 == sigaction(SIGCHLD, &signal_action, NULL))
		goto end;

	/* block SIGUSR1 and SIGUSR2 signals */
	(void) memcpy(&signal_mask, &signal_action.sa_mask, sizeof(signal_mask));
	if (-1 == sigaddset(&signal_mask, SIGUSR1))
		goto end;
	if (-1 == sigaddset(&signal_mask, SIGUSR2))
		goto end;
	if (-1 == sigprocmask(SIG_SETMASK, &signal_mask, NULL))
		goto end;

	/* run the init script */
	if (false == _run_script(INIT_SCRIPT_PATH, &script_pid))
		goto end;

	/* wait until either SIGUSR1 or SIGUSR2 is received */
	if (0 == sigwaitinfo(&signal_mask, &received_signal)) {
		if (script_pid != received_signal.si_pid)
			exit_code = EXIT_SUCCESS;
	}

	/* ask all processes to terminate */
	PRINT("Terminating all processes\n");
	if (0 == kill(-1, SIGTERM)) {

		/* upon success, give them 2 seconds and kill them brutally */
		(void) sleep(2);
		(void) kill(-1, SIGKILL);
	}

	/* disable the SIGCHLD signal handler, to make it possible to wait for the
	 * shutdown script to terminate */
	if (-1 == sigemptyset(&signal_action.sa_mask))
		goto flush;
	signal_action.sa_flags = 0;
	signal_action.sa_handler = SIG_IGN;
	if (-1 == sigaction(SIGCHLD, &signal_action, NULL))
		goto flush;

	/* run the shutdown script */
	PRINT("Running the shutdown script\n");
	if (true == _run_script(SHUTDOWN_SCRIPT_PATH, &script_pid)) {

		/* wait for the shutdown script to terminate */
		(void) waitpid(script_pid, NULL, 0);
	}

flush:
	/* flush all file systems */
	PRINT("Flushing file system buffers\n");
	sync();

	/* reboot or shut down the system */
	switch (received_signal.si_signo) {
		case SIGUSR1:
			PRINT("Shutting down\n");
			reboot_command = RB_POWER_OFF;
			break;

		case SIGUSR2:
			PRINT("Rebooting\n");
			reboot_command = RB_AUTOBOOT;
			break;

		default:
			goto end;
	}
	(void) reboot(reboot_command);

end:
	return exit_code;
}
Believe it or not, Puppy works just fine with this one, with a minor modification - initNEW should run 'cttyhack init' instead of just 'init'.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

bark_bark_bark
Posts: 1885
Joined: Tue 05 Jun 2012, 12:17
Location: Wisconsin USA

#19 Post by bark_bark_bark »

I think linus has no intentions of allowing systemd to take over the kernel.

EDIT: Edited because the (relevent) above post was removed.
Last edited by bark_bark_bark on Sat 17 May 2014, 00:39, edited 1 time in total.
....

gcmartin

#20 Post by gcmartin »

Not to be taken wrongly as I have NO particular position. I remain a "simple" user. But the Linux "boards" are a bastion of world Linux experts, hardware manufactures, OS development corps and users. It takes a long time before ANYTHING in Linux gets done. Then it takes years of nail-biting to get the Linux world to come around because of all the differing personalities that stake a position. Yes, its normal, I know and it has both positives and negatives in doing so.

But, we are Puppy LInux with some very smart talents.

Here's a view. Is there a way for some of the distro developers to begin approaching this such that anyone, a builder, can select which they will use in system starts and operation?

We have seen the same thing occur in discussion of EFI, yet the world of manufacturers and vendors have continued that trek.

We will have little influence in changing the world trek, unless we join the boards where we make acceptable contributions in the discussion of the pros/cons in the directions they take.

But, in this domain, we can observe and take advantage of whatever offerings they make available such that we BENEFIT from those offerings without shooting ourselves in continual future tweaks.

If we boycott, is it because we hate change, or has the world produced a new approach planning a follow-on that we should wait for? And what do we gain or lose from a boycott? Gentoo, has a radically different mindset that they approach Linux from. Its a good one, but its different. While most other distros have some commonality.

Gotta love the Linux OS. But, like any OS, it changes causes major upheavals. This has been seen over the history of time with Apple, Microsoft, IBM, Canonical, Intel, AMD, etc. It will continue at the developer user levels, but it wont stop the marches just as it did not stop the march to 64bit. or to WYSIWYG (as in Windows/Apple/X desktops) or touch (as you see in every handheld) or ....

@JamesBond and others are correct in contemplating the development impacts that they show.

If there's a better way, or a replacement that can be developed in Puppyland, then let's do it and "offer it to the wider Linux community, as well as the IT Unix community" for scutiny and guidance.

Post Reply