<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">So let me interject into this conversational process a “norm” that’s evolving out in silicon valley.</div><div class=""><br class=""></div><div class="">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 <i class="">no such thing </i>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.</div><div class=""><br class=""></div><div class="">It is my opinion (and prediction) that this will be something of a non-issue over the next several years. </div><div class=""><br class=""></div><div class="">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)</div><div class=""><br class=""></div><div class="">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”.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">—j</div><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 18, 2018, at 9:57 PM, Solomon Peachy via Ale <<a href="mailto:ale@ale.org" class="">ale@ale.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Sun, Feb 18, 2018 at 03:41:23PM -0500, Steve Litt via Ale wrote:<br class=""><blockquote type="cite" class="">It also isn't all that necessary. Most run scripts, as they come from<br class="">the factory (at least with Void Linux) have no process dependency<br class="">checking, and in practice things seem to work just fine. But if one<br class="">wants process dependency checking, it simply requires a simple "if"<br class="">statement within the dependent process' run script.<br class=""></blockquote><br class="">So... if the parent restarts, who is going to restart the dependents?<br class=""><br class=""><blockquote type="cite" class="">Runit can do that. I'm not sure it's a good idea: I'd rather ip link<br class="">set dev eth0 down;ip link set dev eth0 up, and same with wlo1. With<br class="">such a change, I'd rather fix it up manually. For situations where the<br class="">network goes down and back up again, all I can say is my computer<br class="">brings back its network connection without the need of having the<br class="">network be a service.<br class=""></blockquote><br class="">I'd rather _not_ fix things up manually, by the time I've finished <br class="">everyhing it would have been faster (and less disruptive) to just reboot <br class="">the system.<br class=""><br class="">Annoyingly there's a big gotcha that I missed -- Google apparently <br class="">requires matching IPv6 RDNS entries. I'd set up the HE tunnel <br class="">so long ago I forgot that they automatically created those <br class="">entries. Meanwhile, 2 days in, and Comcast hasn't fulfiled my ticket.<br class=""><br class="">(DNS had already switched over by the time I'd discovered this, so I <br class=""> couldn't just revert back. Joy...)<br class=""><br class=""><blockquote type="cite" class="">Problem is, with systemd's welded together entanglement of large<br class="">sections of software with applications and the underlying OS, systemd<br class="">completely changes the way you adjust your software, and IMHO not for<br class="">the better if you're at all DIY.<br class=""></blockquote><br class="">You and I draw the "DIY" line at different places. <br class=""><br class="">(I don't administer my own systems for the joy of it; they have specific<br class=""> jobs to fulfil and I'm too much of a paranoid git to trust my data on <br class=""> anyone else's systems..)<br class=""><br class=""><blockquote type="cite" class="">You never saw this kind of thing with Vim vs Emacs: Neither tried to<br class="">weld itself into irreplacibility. You don't see this thing with KDE vs<br class="">Gnome: Neither was successful enough in welding itself into<br class="">irreplacibility. <br class=""></blockquote><br class="">Emacs's viper-mode is arguably a better vi than vim. :P<br class=""><br class=""><blockquote type="cite" class="">The last piece of software to generate this level of antipathy and <br class="">resistance was Windows.<br class=""></blockquote><br class="">...Yet for all that antipathy and resistance, windows still easily rules <br class="">the [PC] world.<br class=""><br class=""> - Solomon<br class="">-- <br class="">Solomon Peachy<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span> pizza at shaftnet dot org<br class="">Coconut Creek, FL ^^ (email/xmpp) ^^<br class="">Quidquid latine dictum sit, altum videtur.<br class="">_______________________________________________<br class="">Ale mailing list<br class=""><a href="mailto:Ale@ale.org" class="">Ale@ale.org</a><br class="">http://mail.ale.org/mailman/listinfo/ale<br class="">See JOBS, ANNOUNCE and SCHOOLS lists at<br class="">http://mail.ale.org/mailman/listinfo<br class=""></div></div></blockquote></div><br class=""></body></html>