Comment by ratorx
3 months ago
I think a lot of the arguments I’ve seen stem from “Unix philosophy” style arguments. Also, historically the systemd project has been quite hostile to user requests in some cases, which broke existing workflows for people.
I personally think the basic “service manager” functionality works pretty well and I like systemd overall.
However, the same is not true for a bunch of the more peripheral services (e.g. resolved, networkd, timesyncd). What’s particularly annoying is that there exist mature open source projects that can provide better functionality in a lot of cases which could be used, rather than bundling a half-assed attempt with systemd (eg. unbound, chrony).
> resolved, networkd, timesyncd
None of these are mandatory though. It's up to the distros whether to use them. For example at this point resolved is pretty commonly enabled by default, networkd not at all, and timesyncd is perhaps 50-50 with chrony.
Yes, but not using those seems to defeat the point of using systemd.
The most convincing advocacy I have seen for systemd (by a BSD developer, its fairly well known) is that it provides an extra layer of the OS (on top of the kernel) to standardise things.
> Yes, but not using those seems to defeat the point of using systemd.
I don't see how it defeats the point - it still nice init / services manager, it still provide features say sysvinit couldn't do at all for my _services_ and management/lifecycle of services.
How often I tackle with resolved or networkd or timesyncd - not even sure, may be once a 2-3 months, while systemd-as-service-manager I do almost every day.
Mind providing some example on your setup/cases?
If you don't use them, you still have a standardized way of managing system services, including scheduled batch jobs. The other services are a convenient and integrated way of getting a basic version of that functionality, but they are by no means the entire point of systemd.
7 replies →
So, systemd is like "doing Linux services the Microsoft way"
Your remark may suggest that everything MS does is “wrong”. This is of course an extreme overstatement and all of their approaches should be evaluated on their own.
So far the argument for systemd seems to be "well it works so why are you complaining"
8 replies →
It comes down to a philosophy you choose.
I personally think that most of the OS decisions done by Microsoft are wrong and should be killed with fire but also I'm far from thinking bad about the people who made these decisions. Perhaps these decisions make sense from their standpoint given the information they had a time.
On the other hand on Linux I'd really wish for a centralized settings repository like Registry. But not from the systemd crowd, of course.
3 replies →
It's more like doing Linux services the UNIX(TM) way since it's more similar to other UNIX service managers like SMF from Solaris or SRC from AIX in the integration -- NT's service manager requires an active event loop which responds to messages.
As an aside, the reason I don't like systemd is because it's inferior to its UNIX counterparts -- especially SMF -- for system management.
Maybe someone should port smf or launchd to Linux?
Given that it was based off of the design of OS X's launchd, I think it's probably more accurate to say it's "doing Linux services the Apple way".
Isn't MacOS a UNIX?
resolved and timesyncd are intended to be removed by the end user of the operating system. Sort of like a transparent peel is intended to be removed by the buyer of a new shiny device.
I haven't seen anything worse than those two from systemd crowd.
Resolved is useful if you frequently change networks (e.g. a laptop), particularly if you’re also using an overlay such as Tailscale. Unfortunately, like anything related to systemd it is flakey and buggy and the solution to most things is to restart it.
I started using Linux because I liked stability. Systemd makes a Linux system as dynamic as a Windows one (which is nice) at the price of making it as stable as a Windows one (which is not).
I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. Writing it in Lisp would have been smart. Writing it in Go nowadays would probably be okay. But C is just an unmitigated disaster.
Also, bringing INI to Linux is unforgivable.
> I started using Linux because I liked stability.
> I believe that part of the problem is that it is written in C,
You know the Linux kernel, and probably most of your userspace, are also written in C? Why do you say systemd is a disaster solely based on its use of the C language but seem to be believe the rest of "Linux" is stable despite also using C?
I mean, there could be some argument here about everything systemd does actually being harder than a kernel's job... but you didn't say that.
I'm on the C-hate bandwagon as much as anyone else, but it doesn't make sense. I have mixed feelings about systemd though.
1 reply →
> Unfortunately, like anything related to systemd it is flakey and buggy and the solution to most things is to restart it.
For what it's worth, I have never found this to be the case. systemd's functionality has been far more reliable to me than the old methods of using `ifupdown` and dhcpd.
> I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in.
I'd love to know what you've seen from systemd that indicates that this is the case.
> Writing it in Lisp would have been smart.
Hard disagree here. You need a language that more people know if you want contributors, and you need to be able to interact as well with other libraries/languages in ways that are understandable to the typical user. Lisp is, at best, an obscure edge case in the context of mainstream programming, and would severely hamper its adoption as an open-source project.
> Writing it in Go nowadays would probably be okay.
Ehh, I agree with this only because you're so noncommital about it. I agree that it would probably be okay. Rust would be far better, in my opinion, if we're looking for a modern language with far more memory safety guarantees (which IMHO is very important for low-level system services).
> Also, bringing INI to Linux is unforgivable.
I'd love to know what you'd recommend that would meet the criteria that INI provides:
1. Simple to read, simple to write (for users)
2. Simple to parse, simple to generate (for software)
3. Uncomplicated syntax that isn't prone to errors when being written or generated (e.g. wrong indentation in YAML, missing brackets in JSON)
I can't think of any options off the top of my head that don't end up introducing additional complexity with little to no benefit, but I'd be happy to be wrong.
> Resolved is useful if you frequently change networks (e.g. a laptop)
I can see the case. I use it myself on a laptop. And by "use" I mean that I just gave up looking into Linux desktop networking like a decade ago. It works, fine.
> I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. Writing it in Lisp would have been smart. Writing it in Go nowadays would probably be okay. But C is just an unmitigated disaster.
... this is ... incredibly wrong. Hardest disagree on all points here.