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.
Then you will be delighted to learn that, according to uselessd website, they dropped udev and systemd-udev and any dependency to it. They also dropped logind, journald (i.e. no idiotic binary logs), all of the fuckingd retardedd crapd.
Besides, they give clues (if not full explanation) about which existing third party programs you can use to achieve everything that systemd tried to replace.
In other words, they keep only what you asked for: the init part.
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."
You should do more, some even, investigation.
"20. Myth: systemd makes it impossible to run syslog.
Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service."
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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.
we actually have a mac server, launchd doesn't always launch the 3fd party stuff (like nagios client for example) for whatever reason. I'd take init for it any day of the week
I'm in the same boat. Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis?
Um, you "use" kill -1 *every* time you use "crontab -e", you also "use" it (the SIGHUP signal) for a lot of other things probably, like forcing apache httpd to re-read it's config file, or any number of other similar things where you can make an app/daemon re-read it's config. And if you drop your connection to your login shell without logging out first, it gets a SIGHUP as well.
It has nothing to do with linux/unix being 'unreliable'.