Live data from Hacker News

No Systemd

nosystemd.org

11–20 of 20 posts

Re: No Systemd

#11

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.

Re: No Systemd

#13
post #8

systemd will never be done, it’s a scam designed to make Linux UN maintainable and incompatible and force businesses to buy service contracts from IBM.

Okay grandpa, let's get you back to bed

Re: No Systemd

#14

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.

> 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.

Re: No Systemd

#15
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.

Re: No Systemd

#16

Earlier quoted context omitted.

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.

> 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.

This is about as correct as saying http is bloated because there are printer protocols using REST.

Re: No Systemd

#17
post #9

I swear, the more time goes on, the more I disrespect the "no to systemd crowd", not because they don't have valid arguments, but because in recent years it attracted a very *specific* kind of audience, and now it smells bad. 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 an…

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.

Re: No Systemd

#18
post #17
post #9

I swear, the more time goes on, the more I disrespect the "no to systemd crowd", not because they don't have valid arguments, but because in recent years it attracted a very *specific* kind of audience, and now it smells bad. 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 an…

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 sysadm…

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...….

Re: No Systemd

#19
post #15

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…

https://kainctl.github.io/isd/ in the context of https://blog.tjll.net/you-dont-love-systemd-timers-enough/ or similar.

Re: No Systemd

#20
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.

Post reply on HN