boycott systemd

News, happenings
Post Reply
Message
Author
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.

anikin
Posts: 994
Joined: Thu 10 May 2012, 06:16

#21 Post by anikin »

The devil isn't as black as painted. Before subscribing to the boycott, it won't hurt to have a look at the other side's views.
Lennart Poettering wrote:But first, let's clear a few things up: is this kind of logic new? No, it certainly is not. The most prominent system that works like this is Apple's launchd system: on MacOS the listening of the sockets is pulled out of all daemons and done by launchd. The services themselves hence can all start up in parallel and dependencies need not to be configured for them. And that is actually a really ingenious design, and the primary reason why MacOS manages to provide the fantastic boot-up times it provides. I can highly recommend this video https://www.youtube.com/watch?v=SjrtySM9Dns where the launchd folks explain what they are doing. Unfortunately this idea never really took on outside of the Apple camp
https://freedesktop.org/www/Software/systemd/
http://0pointer.de/blog/projects/why.html
http://0pointer.de/blog/projects/systemd.html
http://0pointer.de/blog/projects/the-biggest-myths.html

To my layman's reason, the logic behind the boycott is akin to saying "boycott fuel injection, becuase it threatens our carburetors." The only impact I can think of is that we noobs - brave mouse-pushers, like myself and gcmartin, will have to do a lot of reading. Not only to understand what systemd is, bot what it's designed to replace in the first place.

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

#22 Post by bark_bark_bark »

let's not forget why systemd is bad here. systemd is a tool for RHEL developers to establish a monopoly.
....

gcmartin

#23 Post by gcmartin »

I not convinced that the industry is RedHat. It appears that Microsoft and Apple and Intel and AMD and ... have contributed.

Why is the Unix/Linux industry, now, RedHat?

I just recently booted an Alpha7 in a KVM guest that has, to my surprise, systemd built in. I am NOT suggesting anyone, here, do anything beyond what they feel is right. But, seems some distro developers in the Linux industry are moving. I wonder if their decision was to some benefit they perceived or for a greater understanding for what they envision for their future?

Personally, again, I have NO concern as either way, for me, my needs are at the subsystem-application levels. So, I am only trying to offer some ideas, just as others are presenting for a rational approach that will benefit Puppy distro developers as we march into its future. Same as was done with WOOF-CE as it presents a platform for good solid future life in Puppyland.

This will be my last post, here, because I am not a device developer or a system developer (was long ago). Systems developer ease and certainly simple easy to understand and use future needs would be a good review. Or create a brand-new model and present to Linux industry while we maintain and use such in Puppyland as a working model for industry review. Otherwise, we can weigh its beneficial side and use what would help Puppy slide into the future...just as we do when we use EFI, debian, slackware, Citrix, RHEL, and the many other ideas and products found in Open Source Community and certainly in Linux and used to make good/better Pups.

Here to help

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

#24 Post by greengeek »

I'm not technically able to contribute any info about the merits of systemd but from what I read it continues a trend of taking control away from the end user (which can be both good or bad depending on your preferences).

What I mean is - as the kernel has developed and expanded it now contains functions that used to reside outside of it (mouse / video functions etc that used to be standalone). The development of systemd sounds like a continuation of a trend that puts code 'beyond the reach' of people like me - I really enjoy being able to get 'under the hood' and strip / modify code just for the heck of it. I'm not good at it, but I like the feeling of having that control.

Does the development of systemd contribute towards the creation of a "black box" approach - where functionality is modular and the user is locked out from having total control? It seems to me that systemd has the same ugly odour as UEFI - an unnecessary level of isolation that prevents me doing what I want.

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

#25 Post by technosaurus »

greengeek wrote:... the same ugly odour as UEFI - an unnecessary level of isolation that prevents me doing what I want.
fwiw uefi isn't bad. The partition info is all at 1 location with distinct magic for each filesystem and that also allows it to be specified on the bootloader command line (PARTUUID=...). The existing infrastructure had magic values and UUIDs scattered all over the partitions which increased complexity (see guess_fstype) and reduced reliability (a usb drive may be sdb, sdc, ...) the tools just need(ed) updated.

systemd is no different than any other tool like it aside from the fact that it has the benefit of 20/20 hindsight of the past mistakes of others, it could just as easily use busybox ash with builtins like readahead (to preload files), wait $PID (to handle parallel processes) and inotifywatch on a tmpfs (for message transfer) along with judicious use of nofork/noexec applets and shell builtins. As it is, instead of parsing shell scripts, they have to parse config files and then separately load and run many external programs (this load/run takes much longer than even the forking-type busybox applets) ... but then again RedHat doesn't have me bigbass or amigo to audit their scripts, but do have a lot of experienced C programmers that would otherwise be F-ing up GTK+. I say support them on the projects we don't really care about (like systemd) so they spend less time with their fingers in the pie that we eat (gtk)
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].

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

#26 Post by mavrothal »

bark_bark_bark wrote:let's not forget why systemd is bad here. systemd is a tool for RHEL developers to establish a monopoly.
I'm not sure that monopolizing is the intention here. Using the words of Lennart Poettering, one of the 2 systemd credited developers (now removed from his wikipedia page!)
Linux is still too fragmented, and a developer targeting Linux will have to choose from a variety of APIs, a bazaar of somewhat matching but mostly just chaotic choices that will work on some systems but not on others. I think it would be in our greatest interest to streamline the platform top to bottom, and thus have a clear message what the Linux OS is. And of course, I believe my work in cleaning up the lower levels of our userspace stack is helping to work in that direction
.
The only thing is that in order to achieve that he wants to brake away from the so far APIs and code...
Not having to care about portability has two big advantages: we can make maximum use of what the modern Linux kernel offers these days without headaches -- Linux is one of the most powerful kernels in existence, but many of its features have not been used by the previous solutions. And secondly, it greatly simplifies our code and makes it shorter: since we never need to abstract OS interfaces the amount of glue code is minimal, and hence what we gain is a smaller chance to create bugs, a smaller chance of confusing the reader of the code (hence better maintainability) and a smaller footprint.
== [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] ==

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

#27 Post by bark_bark_bark »

mavrothal wrote:
bark_bark_bark wrote:let's not forget why systemd is bad here. systemd is a tool for RHEL developers to establish a monopoly.
I'm not sure that monopolizing is the intention here.
I disagree, but I would think the only one in their way is Mr Shuttleworth. Mr Shuttleworth is more likely to get total control of linux because he is trying to make people think that Ubuntu and Linux are the exact same thing.
Linux is still too fragmented
IMO, linux is not fragmented. It needs more variety. Too many distros are becoming too similar to each other. and it is only getting worse. If linux doesn't get more fragmented, real innovation will halt and we would basically have a "new windows".
Last edited by bark_bark_bark on Fri 16 May 2014, 12:58, edited 2 times in total.
....

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

#28 Post by jamesbond »

mavrothal wrote:Isn't it time for a BSD puppy? :lol:
Did they ever fix the FAT32 bug?
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

#29 Post by bark_bark_bark »

systemd will probably end BSD's existence.
....

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

#30 Post by technosaurus »

bark_bark_bark wrote:systemd will probably end BSD's existence.
if anything system will reinvigorate the BSDs. I for 1 have plans to puppify a BSD.
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].

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

#31 Post by bark_bark_bark »

BSD survival relies on software natively available on linux. If all these linux programs require systemd, then BSD is screwed.
....

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

#32 Post by Iguleder »

Here's a good example. They lost GNOME 3 to systemd, but they were lucky enough to have MATE (and it's a question of time until it's Linux-only, too).
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#33 Post by mcewanw »

Red Hat certification academies have become pretty much as huge as Cisco certification programs in colleges and polytechnics worldwide. If RedHat say systemd, then systemd is what will be taught to these probably millions of aspiring Linux professional engineers/system admins.

http://www.redhat.com/training/red-hat-academy.html
github mcewanw

User avatar
matiasbatero
Posts: 60
Joined: Fri 12 Oct 2012, 01:27
Location: Mar del Plata, Argentina

#34 Post by matiasbatero »

Its funny to see Puppy on BSD, but.. it is inviable!

Now, a linux system without systemd will be still alive if developers, uses systemd as optional dependency.. if not, is a serious trouble. I think that it is very difficult to maintain a Linux system in this direction. But, "maybe" the union with BSD at least, can share the pain.

BSD migration is not free. Go for BSD implies:
1) A reduction of 60% of current packages that are available on Linux.
2) We need to assume that we losses all systemd dependent software.
3) The current packages that work, maybe 10/15% will be old in the future. Because, some updates can incorporate systemd inside.
4) We assume that BSD port needs work, to make usable as common Linux.
5) And, the worst part.. is that we don't have possitive items to contrarrest 1,2,3,4 points. O no?
Last edited by matiasbatero on Sat 24 May 2014, 06:25, edited 1 time in total.

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#35 Post by saintless »

Boycott linux distro because it uses systemd - free linux software - just because it is not suitable for everyone?
The real problem is not systemd but any linux that can not provide optional systemd boot for the user.
Debian for example does the change from sysvinit to systemd by adding init=/bin/systemd to the boot code. Simple and elegant solution suitable for all needs. Maybe impossible to be included in similar way for Puppy but is this systemd fault?
Otherwise anyone who prefer to use systemd should boycott any linux that does not use it.
Boycotting any form of linux just doesn't feel right to me.

Post Reply