Slashdot Mirror
Fork of Systemd Leads To Lightweight Uselessd
An anonymous reader writes A boycott of systemd and other backlash around systemd's feature-creep has led to the creation of Uselessd, a new init daemon. Uselessd is a fork of systemd 208 that strips away functionality considered irrelevant to an init system like the systemd journal and udev. Uselessd also adds in functionality not accepted in upstream systemd like support for alternative C libraries (namely uClibc and musl) and it's even being ported to BSD.
Ok, so the ARM is about to be poised to take over lots of systems (cell phones, etc), and you rip out (to save space) a portable embedded tiny clibrary?
In fact the article says that uselessd adds support for compiling it under musl and uClibc
FUD again. The udev module of systemd does not run under PID=1! Please take a look at how systemd is organized before you post something like this.
systemd encompasses many things that used to be separate, but that doesn't mean they all run in the same process. Functionality is still kept modular, and you can update systemd without requiring a reboot most of the time. systemctl --daemon-reexec will reload the updated modules.
I'm not a fan of *ctl commands (hard to type, they don't roll off the fingers), but they are okay.
Meh. It's just a slightly-faster reboot that's only usable when you don't need to change the kernel.
If you rephrase that slightly, it makes a very different case:
It's just a slightly-faster reboot that's especially useful when you must ensure the kernel doesn't change (ex. unknown illo/grub state).
There are a handful of other times it's useful. My personal favorite is as a self destruct (secure delete almost all files and free space, then issue kill -1), though there are much better ways of doing that.
That particular blog has been fairly well deconstructed in this thread.
In short, just because the author calls something a myth, doesn't mean it's actually a myth.
"First they came for the slanderers and i said nothing."
Then consider yourself the recipient of valuable information. Signal #1 is SIGHUP ("hangup"). The naming is strictly historical at this point. It is probably easier to remember "kill -HUP <some-daemon's-pid>". Either way you issue it, the command restarts the daemon, or reloads the daemon's config. The precise behavior depends on the coding of the paricular daemon. There is no guarantee except what the man page for the daemon says. SIGHUP used on most non-daemon programs just terminates them. That is the default if a process is not coded to intercept and handle SIGHUP.
You're entirely right that you could go for an entire career without once using kill -1. Issuing "service <daemon> restart" strikes most people as much more natural. That will send the signal for you. Incidentally, it's high time somebody wrote "service" for systemd. A simple shell script will do it for some definition of "do it".
Is OS X open? no. Is it put together in many different ways from parts from many different developers? no. Do we care whether it becomes a tightly integrated ball of proprietary software? no. So do you understand the issue? no.