uselessd - a project which aims to reduce systemd to a base initd process

For those that may be interested…

http://uselessd.darknedgy.net/

The “init war” was a farce and never properly fought to begin with, mostly just presented as a false trichotomy between systemd, sysvinit and Upstart. Previous attempts to solve the problem (such as Richard Lightman’s now historical depinit(8))) were neglected, and it wasn’t until systemd arrived and began consolidating functionality and leeching itself into other applications was it either quietly adopted, or in Debian’s case, a rather entertaining debate ensued. The fact that systemd offloaded a lot of work for distro maintainers was probably the main motivation for its adoption. Distro maintainers are lazy.
Nonetheless, the common belief that shell script-based boot is inherently prone to buggy and ugly boilerplate code is a false one. It is true in the case of sysvinit, but not in BSD init, where most common functions are abstracted away in a file named /etc/rc.subr, which is then imported as a module. Initscripts often tend to be up to 3-4 lines of code, even shorter than systemd services. There is also no restrictive concept of runlevels, nor a cryptic inittab syntax.
Most core Linux applications and even the kernel are developed by a handful of companies, largely by Red Hat (who inherited much of the work on GNU after acquiring Cygnus Solutions, thus also leading GNOME and various other projects), who also support the opaque Freedesktop.org standards.

rotfl!, -not a native English speaker I first comment the “wicked” name used on networksetup/factory 13.2 in Pre-Release/Beta earlier today. Now “uselessd”(is it a joke or for real?). I can read it as “use less” d (systemd) or useless (systemd). How should i read it?

Ps. I do not hate systemd, I just don’t like it because the complex connections and the lack of tools to control it. Ds.

regards

Systemd being replaced already? That was fast rotfl!.

A good read, though I’m not quite sure what to make of it.

The idea of “systemd” as a modernized “sysvinit” seemed reasonable. But “systemd” has become much more more than that, and it makes me nervous.

Under “sysvinit”, I could start “sshd” and it would run. If I changed the configuration, I sent a HUP signal to the running daemon to reinitialize. I cannot do that any more. Instead, I must use “systemctl restart sshd.service”.

Much the same is true of “sendmail”.

Both “sshd” and “sendmail” were designed to be autonomous. You used “sysvinit” to start them, but thereafter they looked after themselves. We now see that “systemd” in insisting on being a full time baby-sitter and nanny for those services. I preferred it when those services were self-contained and autonomous, with a central role only in starting them but not in continuously monitoring them.

I mentioned “sshd” and “sendmail”. But those are just two examples of many. Perhaps some services do need constant baby-sitting. But I think self-contained autonomous services are generally a better idea.

On 2014-09-20 16:06, nrickert wrote:

> Under “sysvinit”, I could start “sshd” and it would run. If I changed
> the configuration, I sent a HUP signal to the running daemon to
> reinitialize. I cannot do that any more. Instead, I must use
> “systemctl restart sshd.service”.

Try “reload” instead, it should do the trick.

If not, try this:

kill NAME…

Send a signal to one or more processes of the unit. Use
–kill-who= to select which process to kill. Use --kill-mode=
to select the kill mode and --signal= to select the signal to
send.

It is in “man systemctl”.

It often is a matter of finding out how to do it now :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)