[ale] [systemd] Boot speed
Jerald Sheets
questy at gmail.com
Mon Feb 19 10:19:42 EST 2018
So let me interject into this conversational process a “norm” that’s evolving out in silicon valley.
We don’t reboot. When a machine is sufficiently “Sick” that something as “profound” as a reboot is expected to be needed, the instance is terminated and a new node stands up in its place. There’s no such thing as persistent nodes any more in large scale work. YES, there’s a lot of architecture around that, and YES there’s a lot of clustering and session maintenance voodoo around that on the application side. However, not having to keep up with instances any more and/or terminate/replace instead of reboot is every bit as fast as some of these boot times we’re discussing here.
It is my opinion (and prediction) that this will be something of a non-issue over the next several years.
I cannot tell you the number of systems that are either running in a containerized fashion with CoreOS, stripped down operating systems you create yourself with not much more than a boot loader and a single boot environment on the OS to run a single app with a single set of boot scripts for that single app or even micro containers over docker that run nothing but OS libraries and language dependencies required to run the app itself…nothing more…(i.e., no SystemD OR SysV Init at all)
Our long-standing way of doing things is on the move again, folks. This particular conversation would now be classified as a “legacy” conversation. Look to container and lambda-style infrastructure to start taking big chunks of workload “out there”.
While you may be skeptical because of your current environment you care for and feed, one day you may have to leave it and go somewhere else, and what you find at your new role may look nothing like what you’re dealing with today.
My last 3 years (23rd, 24th, and 25th year in the business)has been more education than I encountered the first 3 years of my career.
—j
> On Feb 18, 2018, at 9:57 PM, Solomon Peachy via Ale <ale at ale.org> wrote:
>
> On Sun, Feb 18, 2018 at 03:41:23PM -0500, Steve Litt via Ale wrote:
>> 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.
>
> So... if the parent restarts, who is going to restart the dependents?
>
>> 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.
>
> I'd rather _not_ fix things up manually, by the time I've finished
> everyhing it would have been faster (and less disruptive) to just reboot
> the system.
>
> Annoyingly there's a big gotcha that I missed -- Google apparently
> requires matching IPv6 RDNS entries. I'd set up the HE tunnel
> so long ago I forgot that they automatically created those
> entries. Meanwhile, 2 days in, and Comcast hasn't fulfiled my ticket.
>
> (DNS had already switched over by the time I'd discovered this, so I
> couldn't just revert back. Joy...)
>
>> 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.
>
> You and I draw the "DIY" line at different places.
>
> (I don't administer my own systems for the joy of it; they have specific
> jobs to fulfil and I'm too much of a paranoid git to trust my data on
> anyone else's systems..)
>
>> 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.
>
> Emacs's viper-mode is arguably a better vi than vim. :P
>
>> The last piece of software to generate this level of antipathy and
>> resistance was Windows.
>
> ...Yet for all that antipathy and resistance, windows still easily rules
> the [PC] world.
>
> - Solomon
> --
> Solomon Peachy pizza at shaftnet dot org
> Coconut Creek, FL ^^ (email/xmpp) ^^
> Quidquid latine dictum sit, altum videtur.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20180219/8fe0cdb1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.ale.org/pipermail/ale/attachments/20180219/8fe0cdb1/attachment.sig>
More information about the Ale
mailing list