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.
Ordinarily I would agree, but systemd's "MCP-like" behaviour (TRON reference, I honestly believe that's a valid simile) means that uselessd has a chance of being a replacement for systemd packages of existing distributions. If I can put this in place of systemd on centos7 and have it boot in an unprivileged container (currnetly impossible with stock) then that's a win in my book.
You can't just switch systemd for openrc in an existing distribution without some major resistance. Believe me, I wish it could or I would just install openrc or upstart. That's the problem - systemd is claiming distributions and the list of alternatives is unnervingly small.
Phoronix take on this is hilarious. A "boycott of systemd" led to the development of uselessd? Rather it looks to me like the uselessd developers saw that systemd had some very good ideas, and they wanted to have that, minus some parts they didn't like, on systems that aren't glibc, and aren't linux. This is part evolution, part competition. Either way it enhances Lenardts' position all along, that traditional script-based system v init is horribly broken. For even uselessd now supports socket activation (systemd's main feature) and process supervision, the latter being sorely lacking from sys v init for many years.
In any event, this is all great news. If anything it paves the way to support modern operating system features on non-linux systems, and non-gnu systems. Part of what's required to finally port modern GUI systems like Gnome 3 to other platforms.
I think the name is probably going to help, not hurt.
It's in the long-standing tradition of weird/funny/pun names in *nix. Less is more, unix is kinda like multics, but with the gonads cut off", etc.
As long as nobody starts calling it "GNU/Useless" ... The whole "GNU/Linux" thing is so '90s, and it's just linux to the world.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Why do we need this? I've been in unix for over 20 years and never even heard of kill -1.
Not just that, but running a non-systemd system even if you use a distro that uses openrc by default is becoming more of a pain as more and more packages hook into it. As a Gentoo user who is trying to hold off for just a little while longer I've found myself doing a lot of package shuffling and using the package blacklist for the first time in the almost decade I've been a gentoo user.
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/).
I'm in the same boat. Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis? There seems to be so much whining about "systemd", you just can't work out how much is complete FUD and whats a genuine gripe. Most of the gripes seems to be neutered by the Myths page http://0pointer.de/blog/projec...
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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.
I agree and am happy to see this fork. As unpopular as it may make me, I actually like the initd functionality of systemd. I'm fine with using and writing the old init scripts, but systemd unit files are simple, concise, and powerful enough for my needs.
On the other hand, I find the kitchen-sink feature creep of systemd absolutely repulsive. Cramming all of that functionality into PID 1 as a unwieldy monolith seems like such a deeply flawed exercise. Uselessd seems like a perfect replacement for systemd: all of the benefits and none/less of the cruft.
If you want a vision of the future, imagine a youtube comments section scrolling - forever.
Most users could care less about running GNOME. We will see if Cinnamon, Mate and KDE make SystemD a hard requirement.
I know I do not have enough knowledge to critique SystemD, SysV or UselessD. That said, I want text logging to disk with no configuration. If I need to learn new commands to read the logs, I'm just not going to do it. At most I will have one Linux box running at home. Pushing 40 with a kid and another on the way configuring my computer has become a hassle and a headache that I don't need. Was there a time when I compiled kernels for fun? Yup, but that ship said over a decade ago. The few times I've needed the logs it is simple just to less or vi and just read the thing. Hopefully Mint will default to giving me my text files. I'm actually about to install Linux again after a multiyear break related entirely to desktop unusability.
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.
Which is why I don't see a systemd fork as a viable alternative. The whole idea is broken, as it breaks with the Unix toolbox approach, where tools work independently, and not as a clusterfuck of apps that engage in social networking under the dictatorship of an object-oriented leviathan.
I have turned down Red Hat EL 7 for my business systems, and install RHEL 6 with vaious 3rd party repos to get new packages, precisely because of systemd.
A leaner fork of systemd just won't do it.
Give me an init that only does init and does it well with a KISS philosophy. And give me hal back - systemd-udev cannot do what it does, which makes RHEL 7 unusable. I don't want a 90% system, when the 10% is used by my business to earn money.
Yet I love XFCE4 and although I run Gentoo as a software developer who needs to freeze various C/C++ libraries in certain versions without crippling my systems update capability, I actually love XCFE4 for it's simplicity and ability to be modified.
I'd rather run XFCE4 and add a bunch of various extra toolbar plugins for a lot of eye candy. Because XFCE4 is lighter weight I don't feel bad having cpu graphs, temp sensors, mem/net/disk indicators, weather, etc all flashing away because it's still less load average than sitting idle on a Gnome3 desktop which oddly needs 6 mouse clicks to get anything to happen.
Gentoo + XFCE4 + OpenRC is how things have been for me and how things will remain.
I have many GCC/GDB versions installed, valgrind, a specific /etc/portage/package.mask which freezes various libraries I code against, yet I can still update my system and stop any changes I do not like. Since the distro is source based it works around these changes unlike a binary distribution where someone else hardcodes their C++ libs into your packages and crosses their fingers you haven't mucked with it.
I clearly used to think Gentoo was a joke in the server world purely due to it's update cycle but honestly I don't think RedHat or anyone else for that matter is really doing it better. I'm starting to think Gentoo with a manual portage overlay on a bunch of servers is what I will switch to next. CentOS isn't cutting it these days and systemd isn't coming to my servers. Not as long as my $$$$ are behind that risk.
But the kernel is monolithic, [...]
Wrong. Linux kernel has modular architecture, but monolithic design. The precise opposite of the systemd.
I know that the uninitiated see the kernel as a big black box. But actually Linux very well structured and highly hierarchical.
systemd can monitor dæmons (only if they use the systemd watchdog facilities) and automatically restart them if they stop talking.
The question here is about the case when systemd itself "stops talking".
Some time ago that would have been theoretical question, but actually there were already such bugs in systemd where it was simply stuck because the daemons which compromise it couldn't understand with each other. This is precisely the consequence of monolithic architecture in combination with modular design: the singular logic is spread across many "modules" (the *-systemd binaries) and when the modules do not agree with each other, things go south pretty quickly.
All hope abandon ye who enter here.
you just can't work out how much is complete FUD and whats a genuine gripe
Once upon a time I used to carefully go over all aspects of my system, and compile custom kernels, fine-tune startup, etc. I haven't bothered in the last decade or so when things work out of the box and I want to concentrate on what I am using the computer for instead of polishing the backend. That said, I've been following some of the systemd news, and responses to it seem to be a real mess and a huge amount of complaints that end up just being strawmen (probably not intentionally). There are legit idealogical complaints I can appreciate, but the vast majority of specific, detailed complaints I come across I later find out are just false. Too many complaints saying "It can't use X" or "It forces you to use Y", when it turns out there is a simple option to change to use X or not use Y... or in many cases where it flat out doesn't do Y or already uses X by default. It makes it rather difficult to take complaints seriously, talking about the "*nix way," when I thought RTFM used to be part of the *nix way.
Systemd...its the Metro of Linux!
ACs don't waste your time replying, your posts are never seen by me.
it does trump most of the shit pumped out repeatedly - please explain what's irrelevant about his responses to the myths.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Unless someone is going to dispute his responses to the myths with good arguments and real life repeatable cases then his blog response is more valid than a bunch of whiners repeating shit without checking it out.
That's not a very good argument, I might as well say, "unless he's going to write code that's not crap, he's just a whiner." Woohoo, a point that makes no sense.
For specific, easy to see problems with the blog post, start by noticing that he actually agrees with many of the points that he calls myths. You don't even need to dig deep! The following are quotes from the actual post:
Myth: systemd is difficult.
This also is entire non-sense.......systemd certainly comes with a learning curve.
Myth: systemd is a freedesktop.org project.
yes, we host our stuff at [freedesktop.org]
Myth: systemd is not UNIX.
There's certainly some truth in that.
Myth: systemd is complex.
There's certainly some truth in that.
Myth: systemd is a feature creep.
Well, systemd certainly covers more ground that it used to......
"First they came for the slanderers and i said nothing."
"But then, they aren't you; so they are just stupid, right?" - unfortunately there seem to be a load of self-important old school admins who know it all who hate change and disparage other peoples efforts by making dubious "complaints"
Exactly.
OS X switched over to "launchd" (which is essentially "systemd") way back in 10.4 (Tiger) Days. I'm sure there was a bunch of whining within the Apple Developer Community from people who were crossover Linux and OS X Devs; but now, about 5 years on, it doesn't seem to have brought death and destruction to OS X. In fact, I recently played around with an SSD-equipped MacBook Air running OS X 10.9 (Mavericks), and it booted from a Cold Start in less than 10 seconds (and actually faster than a Restart!). Yes, the SSD is a part of that; but I gotta believe that launchd helps, too.
It's amazing to me how tech-savvy people can be such luddites; but there it is...
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.
I'm not talking about *init systems* - systemd was never "just an init system". Remember, it's absorbed stuff like network management and system authentication. That kind of feature often requries linking to (L)GPL code, and you can trigger the GPL's requirements depending on how you do that.
So Poettering wants to move all those function calls to (k)dbus. In his own words, "... the primary interfacing between the executed desktop apps and the rest of the system is via IPC (which is why we work on kdbus and teach it all kinds of sand-boxing features)".
Ce n'est pas une signature automatique.
I don't think there will *never* be the "Year of The Linux Desktop", but it won't be in the next 5 years.
GNU/Linux on the desktop is a novelty for nerds, tinkerers, and techies.
GNU/Linux on the server is the bread and butter of the internet itself. Most people who actually use and rely on linux for work, and their life do so without actually knowing it, or dirrectly interacting with the operating system.(ever use google search, you've used gnu/linux).
people who do, in fact install and maintain linux on computers, tend to be running servers, and need a stable platform, more than anything else.
All the people with loads of cash, and manhours of talented developer time, to spend on GNU/Linux and dirrectly related projects are spending their resources on making GNU/Linux servers(and even embedded), better, and more reliable.
a GNU/Linux desktop will happen when a company like Red Hat, google, intel, nVidia, or one of the other many other large corporations gets their dick stepped on for the last time, by microsoft, and they decide to hit them where it hurts, the desktop.
And its going to be a slow, painful, uphill battle full of headaches and tears. No, it *will* happen eventually, but its not on anyone's timeline.
Oh, and I'm sick of bellyaching about systemd. Its a great system, it runs well, reliable as fuck, and most of the compaints are fear mongering. People hate it because its new(GNU even, dum dum tiss), and doesn't conform to the mantra of an OS written over 40 years ago for a system with 64KB of memory.