I feel like anyone who genuinely has a strong opinion on this and isn’t actively developing something related has too much time on their hands ricing their desktop and needs to get a job
My full-time job literally involves dealing with systemd’s crap. There is a raspberry pi that controls all of our signage. Every time it is powered on, systemd gets stuck because it’s trying to mount two separate partitions to the same mount point, whereupon I have to take a keyboard and a ladder, climb up the ceiling, plug in the keyboard, and press Enter to get it to boot. I’ve tried fixing it, but all I did was break it more.
systemd gets stuck because it’s trying to mount two separate partitions to the same mount point
Uh… Sounds like it’s not really systemd’s fault, your setup is just terrible.
I’ve tried fixing it, but all I did was break it more.
If you’re unable to fix it, maybe get somebody else? Like, this doesn’t sound like it’s an unfixable issue…
Uh… Sounds like it’s not really system’s fault, your setup is just terrible.
I don’t know his specific issue, but the general behavior of systemd going completely nuts when something is a bit ‘off’ in some fashion that is supremely confusing. Sure, there’s a ‘mistake’, but good luck figuring out what that mistake is. It’s just systemd code tends to be awfully picky in obscure ways.
Then when someone comes along with a change to tolerate or at least provide a more informative error when some “mistake” has been made is frequently met with “no, there’s no sane world where a user should be in that position, so we aren’t going to help them out of that” or “that application does not comply with standard X”, where X is some standard the application developer would have no reason to know exists, and is just something the systemd guys latched onto.
See the magical privilege escalation where a user beginning with a number got auto-privileges, and Pottering fought fixing it because “usernames should never begin with a number anyway”.
Curious, how does changing one of them to a different mount point make things worse?
I’m gonna laugh if it’s something as simple as a botched fstab config.
In the past, it’s usually been the case that the more ignorant I am about the computer system, the stronger my opinions are.
When I first started trying out Linux, I was pissed at it and would regularly rant to anyone who would listen. All because my laptop wouldn’t properly sleep: it would turn off, then in a few minutes come back on; turns out the WiFi card had a power setting that was causing it to wake the computer up from sleep.
After a year of avoiding the laptop, a friend who was visiting from out of town and uses Arch btw took one look at it, diagnosed and fixed it in minutes. I felt like a jackass for blaming the linux world for intel’s non-free WiFi driver being shit. (in my defense, I had never needed to toggle this setting when the laptop was originally running Windows).
The worst part is that I’m a sysadmin, diagnosing and fixing computer problems should be my specialty. Instead I failed to put in the minimum amount of effort and just wrote the entire thing off as a lost cause. Easier then questioning my own infallibility, I suppose.
As someone who has strong opinions on this, and not only has a job but has a job related to exactly sort of thing… We use freebsd.
Specifically to avoid shit like systemd, and other questionable choices forced down people’s throats by idiots who can’t stop touching things that work well because they didn’t invent it.
What do you use freebsd for? Server or clients and what kind of workload?
As someone who’s not a developer at all and has been making a comic about systemd for a rather small audience, it’s worse than you think: We actually have stuff to do and procrastinate on them while spending time and thoughts in this, reading old blog posts and forum debates as if deciphering Sumerian epic poems. Many pages were made while I was supposed to be preparing for exams, which I barely passed. Others when I should’ve been cleaning up for moving. I think part of the reason why I haven’t made any in a while is that with a faithful audience being born and waiting for the next chapter, it’s started feeling like something I had to do, and therefore, the type of stuff I procrastinate on.
“I hate systemd, it’s bloated and overengineered” people stay, perched precariously on their huge tower of shell scripts and cron jobs.
“I hate systemd, it’s bloated and overengineered”
And built poorly by people who don’t work well with others and then payola’ed onto the world.
people stay, perched precariously on their huge tower of shell scripts and cron jobs.
Fucking UNIX is shell scripts and cron jobs, skippy. Add xinetd and you’re done.
yeah I just hate the move away from flat text files honestly. Its one thing I did not like about windows NT with the registry. databasing up the config.
Which part of systemd’s config is not text-based? The only “database” it uses for configuration is the filesystem
huge tower of shell scripts and cron jobs.
That’s bloat. I start all my services manually according to my needs. Why start cupsd BEFORE I need to print anything?
Wait until you learn about debhelper.
If you use a debian-based system, unless you have actively looked at the DH source, the one thing that built virtually every package on your system, you do not get to say anything about “bloat” or “KISS”.
DH is a monstrous pile of perl scripts, only partially documented, with a core design that revolves around a spaghetti of complex defaults, unique syntax, and enough surprising side effects and crazy heuristics to spook even the most grizzled greybeards. The number of times I’ve had to look at the DH perl source to understand a (badly/un)documented behavior while packaging something is not insignificant.
But when we replaced a bazillion bash scripts with a (admittedly opinionated but also stable and well documented) daemon suddenly the greybeards acted like Debian was going to collapse under the weight of its own complexity.
If systemd was only managing services there would be less opposition. People opposed don’t want a single thing doing services and boot and user login and network management and…
Are they also opposed to coreutils being a single project with dozens of executables doing different things?
The systemd debate is basically dead. There are very few against it, but many accept it by now. Just avoid phoronix forum and some other places.
“Just avoid places that sysadmins and security guys frequent and get your opinions on systemd from memes and people running arch on home machine”. Great plan.
Systemd is absolute and utter shit, especially from security perspective.
Noone was asking security guys but package maintainers.
My favorite systemd thing is booting up a box with 6 NICs where only 1 was configured during the initial setup. Second favorite is betting on whether it will hang on reboot/shutdown.
Great tool, 10/10.
I’ve gotten into quite a lot of systemd-related flame wars so far, and what strikes me is that I haven’t heard a single reason why systemd is good and should be used in favor of openrc/sysvinit/whatever. The only arguments I hear in favor of systemd, even from the its diehard defenders, are justifications why it’s not that bad. Not once have I heard someone advocate for systemd with reasoning that goes likes “Systemd is superior to legacy init systems because you can do X much easier” or “systemd is more secure because it’s resistant against Y attack vector”. It’s always “Linus says it’s allright” or “binary logfiles aren’t a problem, you can just get them from journald instead of reading the file”, or “everyone already uses it”.
When it comes to online discourse, systemd doesn’t have advocates, it has apologists.
Linus had an epic flame war with the systemd idiots for breaking Linux stupidly: https://igurublog.wordpress.com/2014/04/03/tso-and-linus-and-the-impotent-rage-against-systemd/
He didn’t do anything because he made it clear he owned the kernel and userspace was someone else’s problem, but also that the systemd guys were absolute morons who were a danger to themselves and everyone else.
Well, I’ll tell you that I prefer systemd because I can comprehend its declarative unit files and dependency-based system a lot better than the shell script DSLs and runlevels that I’ve had to mess with in other init systems. systemctl status has a quite nice output that can be really handy when debugging units. I like being able to pull up logs for just about any service on my system with a simple journalctl command instead of researching where the log file is.
I’ve gotten into quite a lot of systemd-related flame wars so far, and what strikes me is that I haven’t heard a single reason why systemd is good and should be used in favor of openrc/sysvinit/whatever.
“Hi I’m new to Linux, I switched from Windows to Alpine Linux and my laptop’s battery life has gone from 6 hours to 30 minutes before needing a charge.”
“Just avoid places that sysadmins and security guys frequent and get your opinions on systemd from memes and people running arch on home machine”. Great plan.
So salty. Also twisting the things I said. I for sure like to visit phoronix, but I avoid the phoronix forum and advice was to avoid the forum.
Noone was asking security guys but package maintainers.
citation needed.
Keep using Devuan if it makes you happy.
Not really interested in debating with average “I run arch btw” user. We are not in the same universe, things I have to audit and maintain are not in the same universe with things you do, so having such a smart advice coming from you is not a surprise at all. I could, after all, just roll out my own distro if I am not happy, amirite?
I run systemd machines because I don’t have a choice. It doesn’t make it any less of a shit. Simple as that.
But hey, tell me some more about systemd, I am really new to all this 🤔
My favorite was when the behavior of a USB drive in /etc/fstab went from “hmm it’s not plugged in at boot, I’ll let the user know” to “not plugged in? Abort! Abort! We can’t boot!”
This change over previous init behavior was especially fun on headless machines…
You could just use systemd mounts like a normal person. Fstab is for critical partitions
Anytime I see a Phoronix article (very loosely) about systemd or Wayland I fill my insults bingo card.
What’s wrong with Wayland? I get the hate for systemd, even though I love it dearly, but I get the hate. But what’s wrong with Wayland? It’s amazing as far as I have used it. I started using with when Fedora 40 shipped plasma 6.
Various mildly understandable to braindead reasons
- “it doesn’t work”
- “breaks my workflow”
- “Xorg is better”
- “Nvidia”
- “no reason to use it”
- “being pushed by IBM”
- “no SSH forwarding”
- “has taken too long to get to current state”
- “when I last tried it 5 years ago it didn’t work”
It’s missing a lot of features that Wayland “developers” (spec writers) don’t want to add because they personally don’t need them. For the few features they actually add, they leave it to WM developers to implement them, thus creating different incompatible implementations.
I’ll preface this by saying that I’m a Wayland user (Hyprland, then KDE Plasma, and I’ll be giving Cosmic a fair shot), and don’t see myself returning to X and having to choose between massive screen tearing and massive input lag.
Wayland is missing many features that are required for some people or some applications. There’s no way for a multi-window application to tell the compositor where to place the windows, for example to have one window snap to and follow the other. Color profiles were implemented very recently. Wayland’s isolation of applications, while a significant improvement to security, has made remote input software and xdotool-like programs highly dependent on third-party interoperability solutions (specifically dbus and XDG Desktop Portal). The same isolation broke most accessibility tools like screen readers. Dockable windows, like the toolbars in QT Creator or QOwnNotes, are often difficult or impossible to dock back into the main window.
Because Wayland compositors have to implement all protocols (as opposed to deferring to the X.Org server; which is why wlroots is such a big deal) or rely on XDG Desktop Portal (which has never worked right for me), feature parity between compositors is never guaranteed, and especially problematic with GNOME dragging its heels.
Wayland is nowhere near feature parity with X11 today, and that is a legitimate prohibitive issue for many people. Wayland will never reach total feature parity with X11 in some areas, and that will always be prohibitive for some people.
But the worst (in my opinion) is the development process of the Wayland protocols. The proposal discussion threads read like the best and/or worst sitcom you’ve ever seen. It took them several months of back-and-forth just short of ad hominem attacks to decide how a window should set its icon. Several months for a pissing WINDOW ICON!
I still have weird glitches where applications don’t seem to update on screen (chrome and firefox, both natively doing wayland).
Lack of any solution for programmatic geometry interaction. This one has been afflicted with ‘perfect is enemy of good’, as the X way of allowing manual coordinates be specified is seen as potentially too limiting (reconciling geometry with scaling, non-traditional displays), so they do nothing instead of proposing an alternative.
The different security choices also curtail functionality. Great, better security for input, uh oh, less flexibility in input solutions. The ‘share your screen’ was a mess for a long time (and might be for some others still). Good the share your screen has a better security model, but frustrating when it happened.
Inconsistent experience between Wayland implementations. Since Wayland is a reference rather than a singular server, Plasma, Gnome, and others can act a little different. Like one supporting server side decorations and another being so philosophically opposed to the concept that they refuse to cater to it. While a compositing window manager effectively owned much of the hard work even in X, the X behavior between compositors were fairly consistent.
I’ve been using Plasma as a Wayland compositor after many failed attempts, and it still has papercuts.
The systemd debate is basically dead.
But the Super Nintendo vs. Sega Genesis/Megadrive debate rages on.
Bullshit, there’s always reasons listed. Some more, some less opiniated, but there’s always lists.
For me personally:
- no portability
- not-invented-here syndrome
-
- manages stuff it shouldn’t, like DNS
-
- makes some configurations unneccessarily complicated
- more CVE than all other init together
-
- service manager that runs with PID 0
To the feature creep: that’s kind of the point. Why have a million little configs, when I could have one big one? Don’t answer that, it’s rhetorical. I get that there are use cases, but the average user doesn’t like having to tweak every component of the OS separately before getting to doom-scrolling.
And that feature creep and large-scale adoption inevitably has led to a wider attack surface with more targets, so ofc there will be more CVEs, which—by the way—is a terrible metric of relative security.
You know what has 0 CVEs? DVWA.
You know what has more CVEs and a higher level of privilege than systemd? The linux kernel.
And don’tme get started on how bughunters can abuse CVEs for a quick buck. Seriously: these people’s job is seeing how they can abuse systems to get unintended outcomes that benefit them, why would we expect CVEs to be special?
TL;DR: That point is akin to Trump’s argument that COVID testing was bad because it led to more active cases (implied: being discovered).
is it overengineering or just a push back against “make each program do one thing well,” and saying yeah but I have n things to do and I only need them done, well or not I just need them done and don’t want to dig through 20 files to do it…
[ *] (3 of 3) A stop job is running for User Manager for UID 1000... (1m12s / 3m)
# nano /etc/systemd/{system,user}.conf
----
DefaultTimeoutStopSec=10s
You’re welcome.
Systemd is trying to stop a service. To do an action to a service (or any unit), it runs a job. The job to stop a service is called a stop job. Once the stop job is taken off the job queue, the stop job is running.
The method of stopping a service is configurable, but the default is to send a kill signal to the MainPID, then wait for the process to exit. If it doesn’t, after a timeout, the kill is reattempted with a harsher signal.
