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.
If it still doesn't adequately support the "kill -1" functionality of initd (which kills and resets all processes init manages, especially the getty processes on the terminals), I still don't want it.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
That's how the free open source community works. If you don't like something, it's pointless to just spend a lot of time bitching about it (like many linux users have done about systemd). Just go out and make your own version. Everyone who's been complaining about systemd better contribute to this thing.
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.
I thought it would be serious until I visited uselessd' site (http://uselessd.darknedgy.net) and saw such gem: "This has meant eradicating plenty of GNUisms" and GNUisms being a link to... USA's Communist Party (no, seriously: http://www.cpusa.org/).
systemd does have some very good ideas when it comes to the init system. Socket-based activation and process supervision are Very Good Things.
But when the systemd developers started trying to embrace, extend and extinguish other things like syslog, core dumps, etc. then systemd jumped the shark.
Yes. No. Wait - yes. No... no. Uh....
The systemd has modular design.
But monolithic architecture.
Literally everything inside systemd is intertwined using the D-Bus.
So yes, a crash of one of the systemd daemons might cause deadlock/hang or even crash of the rest of the systemd, and consequently affect the processes running under it.
The systemd's design is pretty bad. This is not an exaggeration, when people call it Windows-like: MSWindows OS has very very similar atructure as the systemd. Windows "Event Log" is really cherry topping.
On-topic: uselessd doesn't fix this problem. It lessens it, but doesn't fix it.
All hope abandon ye who enter here.
systemd is designed to use specific features of the linux kernel. That's why kernel developers as a group aren't up and arms about it. Sure you might get some occasional people like Ted Tso upset, but in general systemd exposes kernel features that a lot of people have worked hard on. Things like cgroups are using copiously in systemd.
That's the whole point of all of this mess: {,k}dbus
Neither an init system nor vertical integration are the goal. The one consistent thing in all of the "systemd mess" is to leave the actual implementation officially a moving target where the trditional .so based library APIs are either hidden and undocumented or they are left out entirely. This forces you to use an IPC mechanism (dbus/kdbus) instead of simply linking to the functions you need and calling them directly. Forcing data to be serialized/unserialized so it can be sent over IPC is not nearly as efficient as calling a dynamically loaded local function. The systemd people love fast thing ("boot time!", etc), so why would they require this slow IPC everywhere?
*** if you never need to link to a library to use it, you can "link" to and distribute GPL code without being bound by the GPL. Poettering's cabal and systemd is an attempt to enable a new form of "tivoization" ***
If you are technically only "using" a library (no linking, no modifications to the library), you have not "infected" your proprietary code with the GPL. It's slower, but computers got fast enough that it doesn't really matter.
The nasty part is that by forcing arbitrary incompatable interface with systemd, to run stuff like GNOME you have to provide the key dbus features even if you don't use systemd. The end-run around the GPL still works with uselessd or any other "systemd replacement".
Unfortunatley, Lennart's cabal has everybody discussing technical features so this obvious goal isn't even addressed.
Ce n'est pas une signature automatique.
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."
"Systemd is what happens when inexperienced people with high IQ fly off on a tagent without engineering ability."
Exactly. There is no doubt that he's a very smart person who can code, but his ideas suck. Dependencies, political pressure, and inexperienced young windows refugees are why we are where we are now...
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
This is just more anti-systemd FUD very light on actual facts.
First you assert that it's somehow a bad thing that systemd uses a standard, established IPC mechanism (D-Bus). Would it have been better if it had invented its own?
Then you claim that a crash of one systemd daemon "might" cause deadlocks/hangs/crashes, but you don't give any example. What daemons are intertwined in such a way that a failure of one would bring down the system? As far as I know, you can kill any systemd daemon (other than PID 1, obviously), and systemd will notice and restart it. Daemons like systemd-journald even use systemd's watchdog mechanism to ensure that they get restarted in case of a hang. In other words, systemd provides a much stronger basis for a reliable system than SysV init.
Fun fact: I just did a "kill -9 -1" to kill every process in a NixOS VM except PID 1. Systemd restarted every system service perfectly. Try that on SysV init.