3 ms·
As much as I dislike the idea of systemd, I'm starting to think it's pointless to fight it. There's still a large chunk of people that think the desktop is impo
by CrLf 12y ago
As much as I dislike the idea of systemd, I'm starting to think it's pointless to fight it. There's still a large chunk of people that think the desktop is important for Linux's future and will keep pushing for turning it into a brittle mess of opaque components, unaware of what's really important to maintain and troubleshoot servers on a daily basis, and unaware of what has made Linux so successful in this area.
It may happen that systemd ends up being a good thing, or it may happen that something else takes the place that Debian and Red Hat currently occupy in the server space. That thing may very well be something other than Linux, and I don't care if it is anymore.
- XorNot 12y agoSince when have init.d scripts been anything but brittle?
- nmcfarl 12y agoForever, till this very day and presumably forever more. If there’s anything this debate shows me, it’s that people have VERY different experiences with SysV init.
- CrLf 12y agoSysV init is brittle only for desktop scenarios, where many things can change between reboots. On servers I've always found it to be very predictable. Once you fix an issue, it usually stays fixed. I haven't ran into many startup race conditions in servers. SysV init has many problems and can be improved upon, but solutions that increase complexity exponentially and are impossible to reason about when problems arise aren't the solution. It worries me to see people justifying increased complexity pretenfing it matters for servers. Two examples: 1. I don't care how long my servers take to boot, that doesn't happen very often and when it does, who cares about cutting 30 seconds on the operating system side when the POST itself takes twice as long? 2. I don't care about too much hardware detection magic. Once a server is installed, at most it will get a memory upgrade sometime along the way, and replacement disks coming in and out of it will be transparently handled by the RAID controller. Most often it will just get scrapped in the exact same configuration it had on day one. The systemd approach is not unlike the Windows approach. I've managed Windows servers for may years and I've also had to deal with at least an order of magnitude more boot issues that with SysV-like init systems.
- digi_owl 12y agoHow many things can really change between reboots on desktop? That i yank one GPU and install another? VGA is still VGA as a fallback, no? Frankly the only bus i can see being much of a issue on desktop is USB. And that is mostly if you are relying on a ethernet dongle or similar that ended up moving from port 1 to port 2 between boots. Yes, this means your desktop may not get connection until you sort out the new name of the port. But that is a niggle, not a world ending scenario that require the full replacement of everything between the kernel and the desktop environment. All in all, systemd looks like a solution in search of a problem. And if it has remained Poettering's personal project and distro variant i don't think many would have raised a stink (and those that found it interesting would have adopted it on their own time).
- XorNot 12y agoAt which point why bother with desktop computing or user customizability or ease of use at all! I mean, who really needed Plug and Play? Or even multi-user desktops. Or removable storage. In Linux, everything got a lot better when we added udev - which gave us event driven mounts. And then we wrote a bunch of hacks to make sysV init minimally event driven enough to properly wait for it to finish it's work. systemd simply dispenses with the fiction that SysV init is in anyway actually suitable for bringing up a modern computer, and replaces it with centralization of what we now know are the actual, useful services pretty much all modern computers need to provide. Even embedded systems are likely to be using network mounted and accessible storage.