Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Pyjong132628dIs this from a movie? It sounds like a movie.
Fast-Nop2661728dMicrosoft: hey Linux is pretty shitty actually, so we can make Windows 10 crappy and still be ahead.
Linux community: hey Windows 10 is pretty shitty so that we can get away with more crap than before.
ddephor491228dEverything is shitty if you don't know enough of it.
Here the one uses shitty, bloated scripts where you don't know what happens when and in which sequence, with different workarounds for different distros. The other one uses a shit ton of services and scripts hidden in gazillions of subdirectories where you don't know how to set up anything non-standard.
At the end you'll always end up googling shit, copy paste it hoping it works, and fucking it up by yourself because the googled stuff doesn't fit you needs.
But to be honest, you can learn anything, it's just software.
ddephor491228d@PublicByte I don't get the context, but yes, you're right, everything is shitty, it's just the level that changes.
Root6332228dThe only thing about systemd that relieves me is that someday, Lennart Poettering will die and stop making things worse.
RememberMe1305428dHonestly I wasn't all too fond of init scripts, they were a horror to maintain and debug. So...yeah. unless somebody comes up with a better system, I'll go with systemd.
stop576328d@RememberMe Systemd helped me to shift the blame to the guys that developed it. It was a Tomcat APP that communicated with 6 other programs. At first it was a pain to Debug it, since it was thrown into the background and Any output was discarded. After that i created 6 systemd-services and i was able to See that passwords were wrong, files were missplaced and other things. It helped with the monitoring too, so we could stop an rouge service after an update.
IntrusionCM177828dThe thing about SystemD is simply.
If it would follow "do one thing and do it well" I'd be happy with it.
But... You know these dinner parties where everyone does exactly one frigging dish he or she's good at... And then comes BLEEP who bring's two dozens of fuckup to the table cause "You know I couldn't decide what to make but you'll gonna love it cause it's BLEEP BLEEP BLEEP BLEEP". And you just think.... Damn... This is not death row. We'll have to throw all that shit away just because you thought you we're a special snowflake and failed hard.
Only systemd? Okay.
But... Networking? Home directory control? Container's? Locale settings? User Init? NTP / RTC settings? Logging? Audiring? Sending to remote location? Booting? Boot verification? Mother of DNS resolve? Security isolation? Limit CTL? Environment override? Mount handling?....
It's just too much. And every piece of it can fail hard... Leading to a completely borked system.
Not to mention that sometimes new defaults are added... Which can completely break you.
PrivateTmp eg. I thought I was going nuts till I realized that.
Parzi833528d@IntrusionCM so what you're saying is... the thing that handles kernel requests and loads things as needed... shouldn't do that? Additionally, systemd has been the most stable part of completely fucked distros and installs for me, so it works pretty well if I can rarely break it when *trying*.
IntrusionCM177828d@Parzi I'm not sure what you mean (the thing that handles kernel .... as needed).
I was saying two things:
1) SystemD isn't modular, so "every piece of it can fail hard... Leading to a completely borked system". And yes.... I would like the modular approach...
2) sometimes new defaults are added.
That is the part where it get's nasty. I've "supported" (as in maintenanced) SystemD units from the beginning.
As SystemD continuously adds new parts and settings, upgrades can really be painful.
As an example I mentioned PrivateTmp. Which isolates a System Temp Folder so it is only visible to the service process.
While it might be a nice idea... it's terrifying when you know that a service wrote to tmp and there is nothing there.
And that's a thing I really dislike about SystemD - it broke a lot of workflows and tried to make them better (Init Bash Scripts / OpenRC)
So far so good.
But as it adds more features and changed sometimes even the service definition meanings...
And that's for me a No-Go.
While it might not be visible as a end user on a fixes desktop, it's pretty visible from an admin perspective.
Needing to rewrite self made Service Units every OS release and having to add them to the packaging, provision ing and so on is... Narf.
Aldar64227d@IntrusionCM I cannot agree enough.
My biggest issue with SystemD is how it tries to be a jack of all trades and take over, an I am exaggerating here, every bleeping system service traditionally managed by an independent pluggable daemon.
The beauty of Unix and Linux was its modularity - Disliked how one service did things? Could replace it with a fork that did it different.
Sure, we don't *have* to use systemd's plentora of services and APIs but... All the other services we run that use push us to... And there's no way in hell we would modify or hack standard services to use a different API.
Aldar64227dOne example that made my blood boil is when PHP-FPM, our CGI of choice, introduced a dependency on one single stupid SystemD library, and suddenly, we were forced to install the whole of systemd on all of our up to date systems. Sure, it didn't force us to actually switch the active init daemon, but... Why...
One library. One stupid library and suddenly we had to deal with internal tools going haywire because they found, albeit nonfunctioning, systemctl on sysvinit systems!
Even major packages can run into issues then!
Most notably, Elasticsearch, had a bug where it checked for the init daemon in use just by if it found systemctl, and if it did, it tried to use it during uninstallation.
Guess what happens when systemctl failed to talk to the main systemd bus? Yep, prerm script fail, uninstall fail, dpkg error... That's just so stupid, the modularity is disappearing, and its making me mad.