Why does an init system do DNS lookup?
And in such a breaking way?
And in such a breaking way?
For caching and DNSSEC validation at the system level instead of needing to be handled ad hoc by each individual framework or application.
> And in such a breaking way?
See https://github.com/systemd/systemd/issues/5755#issuecomment-...
Systemd designers optimized their new resolver's behavior for one common use case, but apparently never considered that it breaks another (undocumented) use case. That seems like an example of a lack of real user testing for an important feature before cutting a new release.
Given the hostility and generally crappy attitude of the systemd's maintainers, this reads to me as "Reinventing the wheel and throwing out decades of knowledge because shiny is better".
Systemd as a project run by people abuses this confusion. In the minds of most normal people, when you prefix a name with another name, you're implying a deep association. Apple Watch, Apple iPhone. Systemd Journal, Systemd resolver.
When people criticize Systemd's continued absorption of Linux system services, they point at it being "modular" (despite it being a rapidly moving target with no real alternative replacements - i.e. modular in the purely theoretical sense of the word), and then take criticisms of the individual parts as criticisms of the whole in an attempt to shout the detractors down strawman-style.
Most of the problems with systemd can be chalked up to its leadership and utterly toxic cultural impact, rather than its technical merits (or lack thereof).
Most people with a problem with systemd don't have a problem with systemd as code - they have a problem with systemd as this creeping monstrosity that keeps eating services that have worked fine for decades in the name of objectively worse replacements. Did name resolution, NTP, and so forth really gain anything tangibly meaningful from their assimilation, other than integration with systemd? Did those services gain more than they lost in annoyances by system admins troubleshooting the changes?
We arguably needed a new init system (and I'll just gloss over things like Upstart and OpenRC). We did not need yet another new NTP, DNS, cron, logger, auditd, and fucking QR code library tied into the system internals!
Political capture. Now we're saddled with this dysfunctional product because only a couple of niche distros are taking the effort to still give their users a choice.
>If you disagree, use a Linux distro that doesn't, or make your own.
Rather, I'll do what I continue to do, and point out the ways in which it sucks and is a net negative on Linux.
https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
And in my personal experience, using systemd has been much less of a nightmare than the old ways. Especially when it comes to cross-distro compatibilites.
edit: here is some even more justification for debian, https://wiki.debian.org/Debate/initsystem/systemd
I think it's rude to assume that people who run these distros didn't think about the technical aspects.
The confusion is your own. You somehow came to believe that systemd is a project that only builds an init system.
You could have come to the same confusion with apple, to use your example; you could have thought "Apple only makes ipods.. wait, they're making phones? Apple's abusing confusion by doing more things".
The systemd project is fairly similar. All those things are closely related; they're made by the same people and work well together. They are not all related to init, just like everything apple makes isn't related to the ipod or the apple II or whatever the first product of theirs you heard of is.
> they point at it being "modular" (despite it being a rapidly moving target with no real alternative replacements - i.e. modular in the purely theoretical sense of the word), and then take criticisms of the individual parts as criticisms of the whole in an attempt to shout the detractors down strawman-style.
That does happen some, but I think that's largely because the detractors of systemd constantly turn criticism of any small component to criticism of the whole thing. It's the same fallacy in reverse.
Also, systemd is not modular in the sense that components are perfectly interchangeable; rather the majority of systemd components are optional and you can keep using whatever you were before (e.g. journald has a configuration to forward to rsyslog or whatever your old syslog daemon was and to not save on disk, thus being as before, resolved is optional, timesyncd is optional, networkd is optional, etc etc).
All of that optionalness is not theoretical. There are distros that take advantage of it, including to the extreme of running full linux systems with no systemd at all.
> Most of the problems with systemd can be chalked up to its leadership and utterly toxic cultural impact, rather than its technical merits (or lack thereof).
I think the toxic cultural impact is a huge problem with systemd, but that impact came not from systemd, but from trolls around it, from people spreading FUD, etc. I don't actually think the systemd leadership or project has actively worked to create such an environment, but rather all of systemd's detractors have intentionally made it a polarizing and political subject which resulted in a toxic environment.
Proving this in either direction is near impossible unfortunately, so we could each see different reasons for the same environment.
> creeping monstrosity that keeps eating services that have worked fine for decades in the name of objectively worse replacements
If it's objectively worse distros wouldn't be adopting it. Have you ever read syslog-ng's code? bind's? glibc's? Have you ever configured your network with rc scripts and hacks? Have you then tried to do the same network configuration on a different distro and found it to be different?
It's clearly better in some metrics in that distros have switched to it. Because of the cultish political toxicity around the project, all of systemd's issues get amplified a hundredfold and make a perception of it being worse, but people only rarely see the convenience and benefits it brings.
> Did name resolution, NTP, and so forth really gain anything tangibly meaningful from their assimilation
Networking gained consistent configuration formats which don't vary by distro. ntp didn't really change meaningfully (though I like that it's an ntp client, not a client and server bundled into one for no discernible reason).. it did gain better man pages and a better CLI, but that's only a small detail. Name resolution gained a number of security features that typically weren't available, Networking in general gained ordering with services, which was nearly impossible before and was typically powered by luck and spit.
> We did not need yet another new NTP, DNS, cron, logger, auditd, and fucking QR code library tied into the system internals!
Maybe, maybe not. It turns out that once you're starting, restarting, and managing FDs for processes, it's really convenient to also integrate with a logging system, and syslog was utter garbage for that sort of integration.
Once you've got the facilities an init has for starting and stopping processes, it's also pretty natural to do a cron-like thing; that's just starting and starting processes too (and timers are much more featureful than cron, including things like '4 hours after the last time this exited', random skew, and much more readable formats).
Once you're managing processes, it also kinda makes sense to manage containers; afterall containers need something to start/stop/manage them too... and once you're managing containers, networking tools, logging,and so on make even more sense.
Almost like systemd was pitched to solve the init problem, and then all this other crap winds up coming along for the ride? Naming a thing systemd-something does not remove that perfectly reasonable logical assumption that the thing that handles init is now handling something else.
Then again, I'm not the one that chose to start with an init system and then suffix all the other stuff I'm assimilating with the same name.
>That does happen some, but I think that's largely because the detractors of systemd constantly turn criticism of any small component to criticism of the whole thing.
Is nobody allowed to be concerned about the creeping monoculture?
>..rather the majority of systemd components are optional
"Optional" in the sense of if you want to compile your own system and run your own homegrown flavor of Linux, sure. Meanwhile, most people are going to be stuck with the defaults and the feature creep - and those defaults are what will matter when you go looking for help.
>I think the toxic cultural impact is a huge problem with systemd, but that impact came not from systemd, but from trolls around it, from people spreading FUD, etc.
First, you just did that thing we were talking about. It is possible to dislike systemd and its implications without being "a troll". Second, it's not the detractors that are responsible for Poettering et. al. 's general poor attitude towards everyone else's place in the ecosystem. That attitude was exemplified with the kernel message overflowing problem. It's exemplified when systemd maintainers open PRs to something like Tmux to put in systemd-specific code. It's exemplified when the maintainers pressure downstream distros to pressure the kernel devs. It's exemplified when they lie about compatibility promises. On and on and on. There's a wiki somewhere that I lost the link to that includes pages of this kind of crap happening again and again.
It's the attitude that turns people off, myself included. Systemd (the project) is not a good citizen, it is the thing that you should make allowances for and get out of the way of. I am not a fan of this style of political wheeling and dealing.
>Have you ever read syslog-ng's code? bind's? glibc's? Have you ever configured your network with rc scripts and hacks?
You mean the exhaustively documented "rc scripts and hacks" that existed on every distro pre-systemd and worked perfectly well on those distros? /etc/network/interfaces for Debianlikes, /etc/sysconfig/network-scripts/(interface-name).conf for Rhellikes. That's 90% of the server/desktop land covered.
The thing that is coming in to change everything is what needs to justify itself, not the other way around. Normally I'd be all for the technical merit by itself, but time spent learning/unlearning/troubleshooting/etc is a thing too. I work in a mixed Ubuntu environment since around 8.04ish, and lemme tell ya, unlearning ~10 years of muscle memory every time I want to tweak services on a 16.04 machine is a pain in the ass that causes curses on systemd's name regularly from a not insignificant amount of people.
The typical response to this is to insult people who dare bring up this concern as "backwards" or "old fashioned" (read: appeal to novelty). And I could put up with that change no problem if there was something objectively better about the replacement.
Yet, there is not. What I have works fine right now, and I gain no new benefits from all of this wheel-reinventing. Point to a tangible benefit. No, "universal network config" is not a tangible benefit in my book, because I don't see a Linux-wide monoculture as a positive.
>It's clearly better in some metrics in that distros have switched to it.
Argumentum ad populum. Once RHEL (which was a given since they're basically the corporate backer) and Debian bought in, the discussion was effectively over.
As to the rest of your post, yes, once you're in a position of power and can basically dictate standards that everyone else is pressured to follow (going as far as the Linux kernel wrt. kdbus), it makes sense to absorb as much as you can.
I'm not accusing Systemd (the people) of mendacity or evil. I'm accusing them of having a shitty, hostile attitude that I don't have a (meaningful) choice in avoiding unless I want to spend all my days reconfiguring stuff that wasn't broken in the first place. Most of the benefits systemd brings to the table just from an everyday server standpoint really aren't that huge at the end of the day, at least not anywhere near huge enough to justify the headache caused by its adoption.
no, just no. Nobody get confused by GNU emacs being prefixed with the same brand than GNU tar or GNU make.
> Did name resolution, NTP, and so forth really gain anything tangibly meaningful from their assimilation, other than integration with systemd? Did those services gain more than they lost in annoyances by system admins troubleshooting the changes?
As an user, I certainly gained much from only having to learn a single, predictable config format that GUI tools can parse easily, vs 1 different config format for each and every service under the sun. The only things it misses in my opinion is power management (eg upsd / nutd).
Emacs is just Emacs to most, not GNU Emacs.
>I certainly gained much from only having to learn a single, predictable config format that GUI tools can parse easily
Linux's primary use is on servers where there usually isn't a GUI, which already had conventions for config formats, usually delineated by debianlike or RHELlike. For people that run servers (read: most Linux users by far), these changes are obnoxious.
Is it ? nowadays 3% of internet traffic comes from Linux computers. Doesn't sound like much, but it makes for more than 115 million users.
https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...
Desktop is 90% windows, mobile is 70% linux (by way of Android), server space is 60% linux. Any way you slice it, Linux is responsible for a lot more traffic.