No Systemd(nosystemd.org)
nosystemd.org
No Systemd
https://nosystemd.org/
19 comments
The anti-systemd crowd just seems uneducated to be honest. They still say that systemd is bloated, because they don’t seem to understand systemd is a catalogue of software, not literally everything happening in PID 1.
Moreover none of them really seem to have operated servers at scale to understand why systemd is useful. Your init system is 1000 lines of C? Cool story bro that does literally none of the things sysadmins need to run a server fleet, enjoy gluing everything together with brittle bash scripts.
Moreover none of them really seem to have operated servers at scale to understand why systemd is useful. Your init system is 1000 lines of C? Cool story bro that does literally none of the things sysadmins need to run a server fleet, enjoy gluing everything together with brittle bash scripts.
Pfft. Ever heard of runit or s6(6)?
( https://smarden.org/runit/ https://www.skarnet.org/software/s6/ )
While systemd may be convenient, and more than a simple init & supervision,
it's still slow compared to runit/s6(6).
Let's say I have a larger process-tree.
Let's say I give it's top, or any thread sighup, lazily out of htop.
Systemd? Takes seconds to tear it down, and restart.
Runit? In an instant. s6(6)? Same.
Just a flicker in the corner of my eye.
There is nothing brittle about https://github.com/skarnet/execline which is a dependency of s6.
Tested initially on almost obsolete systems.
First noticed with large firefoxen, with many windows and tabs.
But it isn't limited to that, just any larger process-tree suffices for comparison.
Does still apply to current versions and is reproducible on contemporary systems.
Runit and before it DJB's daemon-tools (and derivatives) have been around for a long time.
S6 came later. All rather good stuff, if one knows them, that they exist at all,
and is able to handle them, which isn't really complicated,
because they never had the history of glued together brittle bash-scripts.
Just saying...….
( https://smarden.org/runit/ https://www.skarnet.org/software/s6/ )
While systemd may be convenient, and more than a simple init & supervision,
it's still slow compared to runit/s6(6).
Let's say I have a larger process-tree.
Let's say I give it's top, or any thread sighup, lazily out of htop.
Systemd? Takes seconds to tear it down, and restart.
Runit? In an instant. s6(6)? Same.
Just a flicker in the corner of my eye.
There is nothing brittle about https://github.com/skarnet/execline which is a dependency of s6.
Tested initially on almost obsolete systems.
First noticed with large firefoxen, with many windows and tabs.
But it isn't limited to that, just any larger process-tree suffices for comparison.
Does still apply to current versions and is reproducible on contemporary systems.
Runit and before it DJB's daemon-tools (and derivatives) have been around for a long time.
S6 came later. All rather good stuff, if one knows them, that they exist at all,
and is able to handle them, which isn't really complicated,
because they never had the history of glued together brittle bash-scripts.
Just saying...….
The effort of dealing with the increasing amount of software that expects systemd to run underneath makes all these initiatives not very worth it unless you buy heavily in the political, rather than technicals reasons, of avoiding systemd.
I don’t care. I have run Linux machines since 2001 and systemd is one of the least offensive reinvention of the wheel I have had to deal with. All software is shit one way or another, all that matters is how much effort do I have to spend to find myself dealing with another, unsupported pile of shit.
I don’t care. I have run Linux machines since 2001 and systemd is one of the least offensive reinvention of the wheel I have had to deal with. All software is shit one way or another, all that matters is how much effort do I have to spend to find myself dealing with another, unsupported pile of shit.
Every time I see no systemd - I remind myself of this post: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...
> What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically.
> What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically.
There was probably a case to be made for this stance when systemd was very new and getting shoehorned everywhere but increasingly I don't see the point
I think the issue people took with it was less on technical merit and more about the principle of resisting a change which was occurring too quickly for comfort
it was kneejerk reactionary to begin with and hasn't made any more sense as systemd has improved and received better integration with other software
I do mourn the loss of Upstart though, I thought that was one of Canonical's cooler projects
I also use Void/runit primarily and enjoy it because of its simplicity, it's a nice _exercise_ to run systemd-free but I don't pretend it comes anywhere near the level of capability that systemd provides
I think the issue people took with it was less on technical merit and more about the principle of resisting a change which was occurring too quickly for comfort
it was kneejerk reactionary to begin with and hasn't made any more sense as systemd has improved and received better integration with other software
I do mourn the loss of Upstart though, I thought that was one of Canonical's cooler projects
I also use Void/runit primarily and enjoy it because of its simplicity, it's a nice _exercise_ to run systemd-free but I don't pretend it comes anywhere near the level of capability that systemd provides
showing a list of bugs and vulnerabilities is not a compelling case against systemd, or it is a compelling case agains every single piece of software.... providing an argument *why* systemd is bad is what I expect
Agreed. As a previous systemd hater I went there looking for an abstract, high-level argument. I got drivel instead.
One compelling argument I’ve seen is that it tries to be too much which violates the Unix philosophy of small tools doing a single thing well.
After years of using it I have to conclude that it’s here to stay and while not perfect it’s good enough I’m not going through the hell of tearing it out.
One compelling argument I’ve seen is that it tries to be too much which violates the Unix philosophy of small tools doing a single thing well.
After years of using it I have to conclude that it’s here to stay and while not perfect it’s good enough I’m not going through the hell of tearing it out.
> I’ve seen is that it tries to be too much which violates the Unix philosophy of small tools doing a single thing well
Usually the same crowd that makes this complaint about systemd also have a strong affinity to Xorg and dislike to Wayland.
Xorg has a print server among many other things. Adhering to the UNIX philosophy is certainly something it does not.
Usually the same crowd that makes this complaint about systemd also have a strong affinity to Xorg and dislike to Wayland.
Xorg has a print server among many other things. Adhering to the UNIX philosophy is certainly something it does not.
This is about as correct as saying http is bloated because there are printer protocols using REST.
I'm curious - has anyone found / created easy-to-use Systemd GUI interface?
A bit of context: My specific case is creating timers (similar to crontab). I'm shuffle-playing music playlists at certain times of day. I'm comfortable with terminal/command-line, however the computers I'm building out are used in maker-spaces, where many people are not super technical. This has got me into the habit of thinking "what's the 'easy mode' for a lot of tools. For example, GitHub Desktop is a great way to slow-roll people into using `git` if they have never used it before. I like tools like that. Let me know what you suggest.
A bit of context: My specific case is creating timers (similar to crontab). I'm shuffle-playing music playlists at certain times of day. I'm comfortable with terminal/command-line, however the computers I'm building out are used in maker-spaces, where many people are not super technical. This has got me into the habit of thinking "what's the 'easy mode' for a lot of tools. For example, GitHub Desktop is a great way to slow-roll people into using `git` if they have never used it before. I like tools like that. Let me know what you suggest.
https://kainctl.github.io/isd/ in the context of https://blog.tjll.net/you-dont-love-systemd-timers-enough/ or similar.
Disclaimer: original RedHat investor here.
My home lab requires:
* Option 42 (custom NTP configuration)
* Option 66/67 (TFTP/PXE boot)
* Option 119 (Domain Search List)
* Vendor-specific options (43)
* Option 121 (Classless Static Routes)
* Custom enterprise options
+ DNS name Regex replacement (iPod/WII/Lucent DSLAM)
In RedHat dominated network, NetworkManager remains the dominant choice for:
* Enterprise desktops
* Laptops
* Many enterprise servers
* Complex managed networking in the Red Hat ecosystem
RedHat is still struggling to replace my network-manager's ultimate stackable network interfaces (VxLAN-VLAN-Bond-GRE-IPSec).
Furthermore, it isn't about hate. It is about KISS: it is about keeping PID 1 as simple as possible, something that all embedded systems and secured system should still aspire to do.
PId 1 should be pro forma and semantically secured as possible with minimal dependencies.
And process certainly should not be default all-privilege.
Simplicity of integration over complexity.
My home lab requires:
* Option 42 (custom NTP configuration)
* Option 66/67 (TFTP/PXE boot)
* Option 119 (Domain Search List)
* Vendor-specific options (43)
* Option 121 (Classless Static Routes)
* Custom enterprise options
+ DNS name Regex replacement (iPod/WII/Lucent DSLAM)
In RedHat dominated network, NetworkManager remains the dominant choice for:
* Enterprise desktops
* Laptops
* Many enterprise servers
* Complex managed networking in the Red Hat ecosystem
RedHat is still struggling to replace my network-manager's ultimate stackable network interfaces (VxLAN-VLAN-Bond-GRE-IPSec).
Furthermore, it isn't about hate. It is about KISS: it is about keeping PID 1 as simple as possible, something that all embedded systems and secured system should still aspire to do.
PId 1 should be pro forma and semantically secured as possible with minimal dependencies.
And process certainly should not be default all-privilege.
Simplicity of integration over complexity.
- every software has bugs, even curl does, does that mean you ll start a new website called nocurl.org?
That's a shockingly light list of bugs.
Guaranteed that the replacements would have a combined list at least as bad.
Guaranteed that the replacements would have a combined list at least as bad.
"Bait used to be believable."
I've used Linux for over 20 years at this point, my first Linux computer was a PS2 console and my second one was a PS3 console. I remember the rc scripts and upstart, and I hated dealing with any of it, systemd, its timers and the user units were the most convinient change in decades. I hear so many anecdotal accounts of "sytemd destroying someone's system", yet personally it was nothing but a pleasant experience.
I think there's always needs to be an alternative, and I welcome anyone who's actually building alternative code paths and doing the work to create the alternative tools, but every time some tool gains a dependency on systemd to improve the functionality and the mob comes in complaining I can't help but get angry. It's open source. You can patch it. You can switch to something else, but instead you hurl insults at people volunteering their time to make software you run better.