4 ms·
Once upon a time, we were obsessed with efficiency and speed of code. We created powerful, but simple systems like sysvinit, and we designed to optimize speed i
by exelius 11y ago
Once upon a time, we were obsessed with efficiency and speed of code. We created powerful, but simple systems like sysvinit, and we designed to optimize speed in 80% of use cases. The Linux you grew up with used to mostly run on x86 machines, except the majority of Linux devices now run on ARM with different power requirements, hardware, drivers, etc. than x86 ever had to deal with. The increasing complexity in the use cases of Linux is driving systemd, not some desire to stifle innovation (which IMO is exactly the opposite of what systemd is doing).
Our CPUs got fast enough and our use cases so diverse and network dependent (leading to lots of idle CPU time) that we stopped worrying about raw performance above all else. In nearly every case where you're not doing something glaringly stupid, performance is a function of the complexity of your problem set. Things like power consumption and safe asynchronous communication are more important than raw speed, and these things need to be coordinated through the same interfaces on every Linux machine (though not necessarily through the same methods).
Systemd doesn't so much fly in the face of "open architecture" as it does introduce architectural concepts that are sufficiently abstract that much of the community doesn't fully understand them. But this is complexity for the sake of flexibility -- which is far easier to deal with than complexity for the sake of performance. Best practices around specific use cases will eventually become common knowledge.
- vezzy-fnord 11y agoYour implication is that sysvinit was designed for speed. I can't seem to find much evidence for that. In fact, sysvinit's purely synchronous nature and its reliance on the patterns of symlink farms to represent system states in the form of "runlevels", along with the tendency to write bloated shell scripts for it because no one ever bothered to write a proper rc/service runtime framework until much later (in contrast to the BSDs), meant it was slow. IIRC, one of the motivations for some distros to symlink /bin/sh to dash was to reduce boot times. Then we got ugly hacks like startpar for asynchronous script executions, insserv for parsing dependency directives inside scripts, and Debian had all the cruft behind sysv-rc just to make managing the runlevels easier. The whole thing descended into an unmaintainable mess that performance improvements in systemd and other alternative systems were unsurprising.
- exelius 11y agoI think it was originally designed for speed (or at least for simplicity) because it only dealt with a handful of use cases that worked well. Granted, they were the more general use cases, but writing a dependency solver into the init system in 1980 would have negatively impacted speed to an unacceptable degree. Applications back then weren't modular enough for it to make a ton of sense anyway. So they traded flexibility for deterministic execution that was "fast enough". That's not a tradeoff you have to make anymore; CPUs are fast enough now that you can do all the thread syncing you need without worrying about the overhead too much. But flexibility and modularity is more important now than maintaining compatibility with decades old init scripts. Some of those modules may need low level system access for a variety of good reasons. The kneejerk reaction is to apply network server use cases to every Linux feature, but Linux is a whole lot more than a network server these days.