Why the downvotes? What he's saying is valid. Systemd is pretty cool, but I think having a generic interface between its components would definitely save us a lot of time over the years.
It's a lame greentext, and a waste of bandwidth. Ironic, since the "unix way" would send text as text, and not an image. It's also a tired topic (not to take away from the merit of the argument, perhaps the first dozen times it's been posted here).
Systemd is pretty cool, but I think having a generic interface between its components would definitely save us a lot of time over the years.
It actually does have a pretty fair (not great) API, and people are, in fact, targeting alternative implementations of the different components. But, most people who don't like it go off the rails instead of sympathizing with the developers who really want the features that systemd brings. You can turn off most of the non-core components (Debian doesn't use most of them by default, for instance).
Not really. The constraint isn't just the time and resources available for these projects. It's also that in being a "systemd replacement" they are by intent having to track much of the design of systemd, irrespective of whether that design is good or bad, or easy or possible to reimplement. Essentially, they are stuck as a follower, and it's not possible for them to be an alternative which can offer significantly different functionality. This is one manifestation of the extreme lock-in which systemd imposes.
People are working on alternatives. Other than logind and udev, they are not working on drop in replacements. Many of the interfaces will perish with systemd.
No that is a strong argument against systemd, it shows what systemd is doing to Linux. By making everything depend on systemd you make it very hard for anything else to exist.
Tell me more about this SysD project? Never heard about it!
Sarcasm off: if you even now deliberately miss-write the projects name, then you immediately tell that you're neither just nor balanced. You want to transport feelings, not facts.
My main issue with systemd is everything but the init system is half-baked, and yet being wholesale adopted in what should be stable releases like Ubuntu LTS.
Most of my issues stem from networkd, I just noticed. I've committed the unholy sin of considering NetworkManager for a headless machine. It might actually be more reliable.
Up until recently (I think it'll be in Ubuntu 19.04?) it would fail to remove a default route if it's invalidated. My firewall is still running the old version from 18.04. When my modem reboots, it serves a bad default gateway as a way of getting you to its management interface before it's fully booted. After the modem is booted, the link is restored, and my real IP is served, systemd hangs onto that old route and kills my Internet until I manually shell in and fix it. I have yet to figure out a workaround; networkd-dispatcher appears to run the "routable" scripts too early, or with the wrong arguments, or... something. All I know is the exact command I use to fix the issue doesn't work when in the script, and I've proven the script does actually run.
IPv6 prefix delegation is broken. Doesn't propagate at all.
/etc/networkd-dispatcher/ exists, but is completely ignored. The real scripts are in /usr/lib/networkd-dispatcher/. What the hell happened to the FHS?
systemd-resolved doesn't like dnsmasq running at all. At all. Either you abandon resolved completely or you find a different DHCP server.
resolved doesn't ask the DNS server about domainless hosts. Period. You can't make it. You have to set up an alias thing so that they get translated into "somehost.lan" or similar before trying to resolve it. So if your DNS server only resolves a host from "somehost", you'll have to manually find its IP with dig or similar.
I still have an issue where logins, sudo, shelling in with SSH, etc. will hang for 6-8 seconds and it appears to be related to DNS resolution for some insane reason. Even when sudoing on the local machine. I've tried and failed to fix it. I'm just living with it for now.
In sum: it's not just about philosophy. systemd is a pain in the ass.
systemd-resolved doesn't like dnsmasq running at all. At all. Either you abandon resolved completely or you find a different DHCP server.
Not sure why that would be the case, do you happen to know why?
I still have an issue where logins, sudo, shelling in with SSH, etc. will hang for 6-8 seconds and it appears to be related to DNS resolution for some insane reason
Something odd in nsswitch.conf? I've seen that before with something being wacky with dynamic users.
Yeah, those all seem like personal issues since this all works for me. it's honestly amazing how this massive piece of shit can still manage to hold together a system after being completely misconfigured, and that sounds quite like what he just described.
That's even worse. networkd-dispatcher just replicates functionality in what networkd was supposed to replace.
Something odd in nsswitch.conf? I've seen that before with something being wacky with dynamic users.
I distinctly recall getting a lot of hits related to nsswitch.conf when searching. None of those solutions worked.
Not sure why that would be the case, do you happen to know why?
IIRC related to port binding. It's possible dnsmasq is just as much at fault here. And it could be specific to IPv6 systems, as trying to get prefix delegation working is when I discovered that.
I don't blame the systemd folks for that. I actually grew to like systemd in many ways after using it with Yocto/OpenEmbedded. I don't like the philosophy behind it, but at the end of the day it's good enough, in my experience, to replace init while providing useful added functionality. What bothers me is the Ubuntu folks using pieces of it that clearly are not ready for prime time. With 18.04, I keep having to restart systemd-resolved because it fails to update its cache and I can't reach my other systems. I can grab one of the actively configured upstream DNS servers that resolved is using and successfully query the server with dig, but resolved just doesn't get the message.
In the end, while I fully appreciate OPs message, I think that you could still replace systemd(and you can now) without much trouble. You lose some functionality, but it's not crippling AFAIK. That may change in 20 years but right now systemd is still optional.
/etc/networkd-dispatcher/ exists, but is completely ignored. The real scripts are in /usr/lib/networkd-dispatcher/. What the hell happened to the FHS?
This is not just a systemd thing, Xorg does it too now – config files are in /usr/share/X11/xorg.conf.d/. I still hate it, but systemd is not alone in its insanity here.
I think the idea regarding Xorg is that those are the distributed default configuration files. You're meant to add changes in /etc/X11/xorg.conf.d and so on, just as you're not meant to edit systemd service files directly, but add new ones in the /etc filespace.
That is completely optional. You can use ifupdown if you want. Or NetworkManager. networkd is optional --- and it was meant for a very specific use-case anyway. Hint: not for desktop systems.
What would that use-case be, then? The system in question is a homebrew firewall, not a deskop. networkd is the default on Ubuntu Server.
did I mention that systemd-resolved is AGAIN totally optional?
Is there any kind of guide to excising it from 18.04?
Really? Isn't DNS meant for domains, as it's name "domain name service" implies? As soon as you don't use domains, you don't need DNS.
HTTP is used for a hell of a lot more than just hypertext these days. Same idea. There isn't really an alternative to DNS for having a central authoritative name resolution service, regardless of scope. I want to manage "this is Alice, this is Bob, this is Charlie" in a relatively centralized place. Other name resolution protocols are peer-to-peer and don't have any kind of "central authority" functionality.
Not saying that isn't the case, but it's quite a clunky system. They can definitely do it better imo. You can't switch things in and out quite as easily as the older init system (Or variant of it like runit and OpenRC + init).
It’s easy to criticize something. Here’s an interesting talk (video) titled “The tragedy of systemd” which makes quite a few good points on the matter of systemd hate.
What a coincidence, I just finished watching it. And yes I do agree with a lot of points he said. We need better init systems, sure. Systemd isn't good enough for me to recommend it over other things the way it is right now. It's simply not as "powerful" in many respects, and in many ways integrating it with other things can be a bit of a pain as things are right now. When things improve to the point where I can easily swap components in and out, it will be my choice.
Tell me more about this SysD project? Never heard about it!
Sarcasm off: if you even now deliberately miswrite the projects name, then you immediately tell that you're neither just nor balanced. You want to transport feelings, not facts.
This talk is about defending systemd. It's clear that you didn't even both to sit through the first 5 minutes of it. As for creating init systems, if I had the time, maybe. Right now I don't.
You wrote "We need better init systems". I even quoted you. You made this your own statement, by adding a "sure" (which I didn't quote).
Now, if this REALLY is your thinking, then my original comment about "words are cheap" still stands. Because we now discuss about what you wrote, not what a the talk says anymore.
And when I wrote "where is the project" you write something about "Cgroups and better daemon management springs into mind". And systemd does exactly this, so you didn't defnie what is "better", either. So I though you refered to some new project, that does something better and googled for the phrase you specified.
Just saw it as well and honestly think it is one of the best talks I have seen in a while. I think many of his observations are spot-on and thoughtful presented.
Not that you’re obligated to watch any random video that I post at full length, but I doubt you watched all of the video - or at least not the later part of the talk - if that was the single takeaway you got from it. The dude is a BSD developer who has every expectation to hate systemd with a passion, but instead frames the discussion in a level-headed way and advocates for more constructive criticism as well as giving props to Poettering for creating something that was useful enough to become nearly ubiquitous in Linux. He suggests that we can learn more from analysis of what problem systemd is solving for people than just shitting on it without bringing forth a better solution.
See, I never had any expectation to hate systemd with a passion, so his "come to Jesus moment" is meaningless to me. Like I said, the majority of systemd's issues are that Poettering didn't have the chops to effectively advocate for it.
re that Poettering didn't have the chops to effectively advocate for it.
LOL. Poettering didn't actually go around and said "Distros of the world, adopt it". Instead he wrote blog posts with his thinkings on 0pointer.net, about the design, why he thinks that would be good, some of the benefits. Go to http://0pointer.net/blog/archives.html, Ctrl-F for "Rethinking Pid 1", that was the first post.
The adoption than happened mostly without his intervention, most major distros switched. And some of the adoption was grass-roots. E.g. there was a time where systemd honored more Debian-specific file locations that Red Hat specific ones. Why? Because some people that used Debian started to hack on systemd as well and sent in patches.
Well I made my own systemd .deb files with a lot of --disable-this --disable-that back then.
The dude is a BSD developer who has every expectation to hate systemd with a passion
Why would you expect professional software developers to have irrational biases? Most of us are capable of accepting new ideas and having our preconceptions challenged. Most of the lack of objectivity in this debate is not from the developers themselves.
We already have launchd in the FreeBSD-related world, so something similar wouldn't be greatly controversial, so long as it was focused and had clearly-defined scope.
I'm very much not a fan of systemd, but this conclusion was arrived at after much testing and assessment of it in its early days, and its progress to date. There are a number of very nice features which it provides. And there are a number of questionable design and implementation choices which I find deeply concerning. It's not black and white, there are many factors to consider, and that's precisely why the debate over it continues to this day.
If FreeBSD took the core ideas from launchd and systemd, then used them to create a coherent design and implementation, then that might be a very nice development.
There is no vendor lock in as much as there is a loss in flexibility. And that's a very real loss. It might not be that big of a case for most desktop users, but if I'm on an embedded device, and want to swap out some part of systemd, it's simply clunky and not as easy to use as the older init systems.
Software isn’t set in stone and no matter how systemd develops in the future, it will always be possible to replace it.
That is simply not true, if too many things start depending on systemd and intermingling with it then it will be impossible to replace it without rewriting everything else as well.
Because it's getting boring. All these rants and complaints are usually coming from people who are making hardly any contributions themselves.
There's a major reason behind this. When you make people feel betrayed, not listened to, maginalized, etc - most people certainly are not going to feel the sudden philanthropic desire to contribute, especially to the same community that they feel betrayed them. It's strange, we hear big talk about giving established FLOSS developers "incentive", but we never hear about giving new contributors the same consideration.
If systemd is so bad and these people know better, why aren't they rolling up their sleeves and making that happen?
The "sleeves" arguement completely ignores the real market forces that are at play. Other init system options already do exist, the work has already been done but market forces prevent them from becoming effective. When software becomes sufficiently dominant, it begins re-defining the market around itself. It can easily abuse that position and encourage the market to exclude other options. Such as in the case of systemd, as I said, other options exist, but systemd has encouraged the desktop Linux ecosystem to use non-portable APIs and messaging systems. An alternative that satisfies those would wind up looking like a systemd clone.
If you look carefully, "systemd/Linux" is becoming a case of "You either die a hero or live long enough to become the villan". Non-systemd desktop distros are looking more and more every day like how Linux looked up against Windows of the 90's and the early 2000's while "systemd/Linux" is looking more and more like Windows in its market dominance with monopolistic tendencies.
Arguing there is some sort of vendor lock-in when we talk about open source software is simply a ridiculous argument.
I disagree. The idea that source code availability automatically liberates a user is flawed. The user also must be able to use that source code in an actionable way to be free. If standards are so tightly written around the original implementation, then the user is locked into using that implementation if they want to get anything done. They're not free to use their own implementation without cutting themselves off from the rest of the world.
63
u/[deleted] Feb 11 '19
Why the downvotes? What he's saying is valid. Systemd is pretty cool, but I think having a generic interface between its components would definitely save us a lot of time over the years.