Comment by eadmund
3 months ago
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.
> You know the Linux kernel, and probably most of your userspace, are also written in C?
I’m aware. It would be nice were that not the case. One of my favourite userspace programs uses C, but just to build a Lisp runtime!
> Why do you say systemd is a disaster solely based on its use of the C language
I wrote ‘part of the problem.’ Systemd is a disaster in part due to its use of C. Its bugs are in part because C is not a language which is really suitable for abstraction and reasoning over abstractions.
I do think that what systemd does is more complex than the parts of a kernel which require assembler or C. I wasn’t constructing a full argument, just opining. I think that the sheer weight of C required to do anything complex makes it very difficult to reason about what that code is doing. Languages higher on the abstraction curve make it easier to reason about abstractions. Reasoning about abstractions helps prevent design bugs. And also languages with good abstraction capabilities tend to help avoid implementation bugs.
> 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.