[ale] [systemd] Boot speed

[Steve Litt]

On Sat, 17 Feb 2018 09:33:31 -0500
Solomon Peachy via Ale <ale at ale.org> wrote:

> On Sat, Feb 17, 2018 at 08:58:22AM -0500, leam hall via Ale wrote:
> > I don't see boot speed as a game changer for systemd, even if it is
> > a lot faster. If you're booting your desktop then you're probably
> > already used to "push the power button, hit the head, grab some
> > coffee" routine. If you system isn't up by then maybe there's an
> > issue.  
> 
> Faster boot times aren't the primary benefit.
> 
> The main point is to have a set of fully dependency-resolved set of 
> services/actions.  

Daemontools, daemontools-encore, runit and s6 all have the ability to
define a dependency-resolved set of services/actions. You define them
with "if" statements in the run script instead of services, but the
result is the same. Plus,  with the daemontools-inspired inits, you can
decide your own definition of a dependency process being "up", so if
you don't like the daemon author's definition of its being "up", you
can make up your own. It's pretty cool.

It also isn't all that necessary. Most run scripts, as they come from
the factory (at least with Void Linux) have no process dependency
checking, and in practice things seem to work just fine. But if one
wants process dependency checking, it simply requires a simple "if"
statement within the dependent process' run script.

> A side benefit of this is parallelism, which in
> turn leads to better boot times.
> 
> For example, the night before last I switched my home IPv6 provider 
> from a Hurricane Electric tunnel to Comcast's native static service.  
> When I restarted the network interface, systemd automatically
> restarted all dependent services, without my needing to do anything
> else.

Runit can do that. I'm not sure it's a good idea: I'd rather ip link
set dev eth0 down;ip link set dev eth0 up, and same with wlo1. With
such a change, I'd rather fix it up manually. For situations where the
network goes down and back up again, all I can say is my computer
brings back its network connection without the need of having the
network be a service.

> 
> > For servers, if you really want uptime, why aren't you redundant?
> > Reboot time is again not an issue if the service stays up.  
> 
> Think of cloud instances that come and go based on realtime demand.
> The faster things start up, the faster they can start serving.
> 
> I'm not saying that use case necessarily matters to anyone here, but 
> I'll take improved boot times all the same.

I'm sure nobody here begrudges the ability to bring up and down
containers on demand, and have them boot in a couple seconds. I
certainly don't. My use case isn't universal.

Problem is, with systemd's welded together entanglement of large
sections of software with applications and the underlying OS, systemd
completely changes the way you adjust your software, and IMHO not for
the better if you're at all DIY. And systemd is so entangled, you can't
just yank it out and substitute another init. Systemd is the only init
system the preceding sentence is true for. The systemd cabal is saying
that their use case IS universal, and my use case doesn't count.
Because of systemd's entanglement, replacing it is extremely
difficult, leaving people with my use case in a much more difficult
situation. This is why, years after the Debian decision, systemd is so
reviled and fought against.

You never saw this kind of thing with Vim vs Emacs: Neither tried to
weld itself into irreplacibility. You don't see this thing with KDE vs
Gnome: Neither was successful enough in welding itself into
irreplacibility. The last piece of software to generate this level of
antipathy and resistance was Windows.

SteveT

Steve Litt
January 2018 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb