:: Re: [DNG] Detailed technical treati…
Top Page
Delete this message
Reply to this message
Author: Steve Litt
Date:  
To: dng
Subject: Re: [DNG] Detailed technical treatise of systemd
On Thu, 05 Nov 2015 19:05:23 +0000
Rainer Weikusat <rainerweikusat@???> wrote:

> Worrying about 'starting servers in parallell' only makes sense if
> there's a real-world situation where this demonstrably makes a
> relevant difference. And I very much doubt that --- that's just
> another imaginary sugar-coating supposed to help selling systemd to
> people who are not expected to understand the issue. As someone
> recently wrote,


I'd like to discuss this. Now, after a year of thought, I still see no
benefit to "starting servers in parallel" except for boot time. There
are use cases where boot time is critical (99.9999% uptime, or a
television appliance), but for the vast majority of us the difference
between a 1 second boot and a 40 second boot is we get a chance to go
get a cup of coffee every day, week, month, year, whatever. And
frankly, it's been a long time since I've seen any system that takes
more than 30 seconds to boot.

If they were honest about it, they'd say "use systemd if boot speed is
a real priority for you, otherwise use whatever you want." But noooo,
they sell parallel instantiation as a feature the way the car industry
tempts us with keyless ignition and magnesium paddle shifters.

I'm a big fan of the Epoch init system, which is a guaranteed one
service at a time sequential init system. With Epoch, the system's going
to boot the same way every single time.

I'm also a fan of Runit, because it's very daemontools like. I don't
know whether Runit parallel instantiates, but I do know it starts
services indeterminately. In practice this hasn't been a problem ---
I've been using Runit for a month on three machines, some of which I
booted quite often (8 to 14 seconds grub prompt to Virtual Terminal,
with complete networking). With Runit or any other daemontools-inspired
init or process supervisor, if process dependencies become a problem, a
simple test script in the directory of the process needing the
dependency, to test that the dependency is *really* open for business
(and isn't just backgrounded) solves the problem.

Here's honest marketing for parallel instantiation: "Parallel
instantiation is great because it reduces boot time from 10 to 20
seconds to 1 to 4 seconds, assuming it's implemented right. If you
reboot every day, the time you save would give you 1/2 of one trip to
the drinking fountain."

>
>     Point remains: most of the "less-tech-savy" users will
> probably not even know what systemd is, or what the fuss is all
>     about. It's all been seamless, without hitch. The OS boots and
>     gives them a GUI, done.

>
> IOW, without the systemd marketing barrage, most people had never
> noticed it as there are no user-visible difference, IOW, it's not an
> improvement for them.


Yes it is. Now the most tech-challenged user can feel superior to
somebody (us). Now the dumbest droob can call us "neckbeard", "troll",
"scared of change", "1985", "demotivating", and "just don't
understand." Think how fun that is for the guy who's usually the
dumbest guy in the room.

And systemd did something for *us* too. It got those clowns out of our
hair. Systemd is a honeytrap. :-)

SteveT

Steve Litt 
November 2015 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques