I still haven't fully grasped the Systemd drama, or systemd for that matter, but boy do I love it. I enjoy how Linux has those turf wars nobody outside of it knows about.
SystemD is great when it works, which is most of the time. But when it breaks or you have to do something that SystemD doesn't support it becomes an enormous pain in the ass. It's like being back in Windows land again.
Some DBus message is not appearing and it stalls out your boot process, finding where it was supposed to come from and why it didn't appear is a nightmare. If you want to use a different daemon than the one SystemD provides for some service it will fight you every step of the way, sometimes even undoing whatever you had to do to make the process work in a random update. As someone who experiments with weird networking stuff from time to time I've been kicked in the nuts by NetworkManager on several occasions.
I know this is a completely unimportant tangent. But I'm always amused that systemd skeptics insist on the "SystemD" spelling. Where does that come from? I never see anybody talk about NtpD, InetD or VsftpD. But somehow systemd needs to be SystemD. As I said, amusing.
I'm pretty sure it's just ingroup signaling: it's not the only example of "spelling something wrong because you really hate it". For years I've seen people on forums who want to show their dislike say "MAC" instead of "Mac", "MicroSoft" and so on.
> As someone who experiments with weird networking stuff from time to time I've been kicked in the nuts by NetworkManager on several occasions.
nit: NetworkManager is not the one provided by systemd in the first place - that's systemd-networkd.
That aside I do wierd networking stuff for a living and here's how I see the available tooling:
* NetworkManager - great for a laptop where you're moving between networks and don't need anything too fancy.
* systemd-networkd - great for servers and other mostly static networking setups, even weird ones.
* If you're doing anything weird dynamically (e.g. experimenting) - disable the above or move the interfaces you are experimenting on to a fresh netns and do everything by hand with the ip command (and maybe udchpc or dhclient if you need a dhcp client, but be aware of how to write your own callback scripts for how to handle various associated events).
Now for the weird part: Redhat wrote both NM and sd-nd, and decided what servers really need is NM by default, and getting a server to actually use sd-nd is like pulling teeth on RHEL. Completely baffling.
NetworkManager can read old style sysconfig network configuration, which is still used to this very day even if Red Hat wishes you wouldn't, and you really shouldn't.
I don't know why Redhat would do that, but I've never used RHEL - I quit the redhat and derivatives in the 90's due to rpm hell, and never looked back.
A new job forced me to get intimately familiar with how fractally dysfunctional RHEL and derivatives still are, and the only thing more baffling than Redhat's self-sabotaging decision making process is why anyone would voluntarily use it.
Yes, but then NetworkManger will override Netplan sometimes but not others. There is a setting in one of the buried config files to configure this behavior, but it doesn't always work depending on how NetworkManager is feeling that day.
I'm not keen on the network config being scattered across a dozen tiny files. It makes it hard to see what's going on, or to spot a configuration error.
Here's one for you: I can't remember the exact details, but I was trying to get do something with a samba share folder via systemd unit file and the way systemd handles the escape characters used by the samba client was not compatible for windows network shares that used spaces in the name.
Because it completely violates the UNIX philosophy and mission creeps into taking over essentially every part of the system. It was shoved down the throats of every user because the major distros kowtowed to a FOSS diva with a spotty track record, creating a monoculture built on awfulness and bloat.
I appreciated it. I fucking hated all these init scripts and find it muuuuuch easier to get services running under systemd. I don't care about philosophy when it gets in my way of managing systems.
> Had it not been for the philosophy, Linux would not have been a thing
I'm not entirely sure what you mean by this, but linux (the kernel) is very much not a "do one thing and do it well" kind of program. You'd need a microkernel for that.
Hot take: the 'UNIX philosophy' is stuck in the 1970s. It was the only practical compromise when computers were constrained to kilobytes of memory (at best) and a megabyte of storage (at best).
No, the UNIX philosophy persisted since the 70s because it is great default philosophy for building software. Not all kinds of software but most, I'd say. Doing one thing well plus all the other stuff (like preferring plain text output) means that users can easily assemble whatever they need. When applications are doing only one thing, you can thoroughly test them as well and enjoy a level of security that monolithic programs have to add via sketchy hacks. And when a monolithic system is compromised, it is a bigger threat than one with smaller scope.
With modern software it's a pain in the butt. Remember CD burning software? That at least used to invoke cdrecord underneath, and whenever that went wrong it was awful, because text is an awful interface for a complex system.
Today you'll find many things that actually "de-UNIX-philosophy" stuff, by making a library that wraps around an invocation to a complex tool and presents what 99% of users actually want -- a library style interface.
A GUI program invoking a program not designed to be a GUI in the laziest fashion is fringe example. Such a GUI would have been a herculean feat to implement if the authors could not piggyback off of an existing, simple tool. If the GUI authors really wanted, they could have tried to parse the output of cdrecord and/or contribute to making the output of cdrecord suitable for easy processing.
>Today you'll find many things that actually "de-UNIX-philosophy" stuff, by making a library that wraps around an invocation to a complex tool and presents what 99% of users actually want -- a library style interface.
There are tradeoffs to this simplicity. Your "library" is most likely a pain in the ass to use even for people using the same language, much less other languages. The output and invocation of a simple program is less likely to add a breaking change than its code. Do you think libraries were just invented, or what?
I like the idea of making the library first and then using that to build a tool. But that may not make sense in all cases, and it's extra work as well. For people using other languages, or trying to write simple shell scripts, a library alone is not going to work.
