I have all of my sessions set to handle resizes the old way (which is fine).
Guacamole has changed the way I use my computer. My main monitor is a 24"
1920x1200 (16:10) screen. It now has a browser maximized on it all day long.
I used to have to switch back and forth between the browser window and my
terminal window. Now I've got HTML, SSH, RDP, and VNC in one contiguous set
of tabs. And since I'm at 1920x1200, I can view a remote 1920x1080 screen
without scaling it down, in those cases where the server won't size to the
client's screen dimensions.

Text windows are 190x56, which is a *little* excessive, but not so much that
I want to shrink them. Nobody writes code in 80 columns anymore, except maybe
COBOL programmers.

Obviously this isn't going to transform everyone's workflow, but it's working
great for me. Nearly everything I do is on a remote computer somewhere.

Whenever someone else thinks, "None of these really start my services how
I'd like them started... I think I'll make another one," an angel has its
wings ripped uncermoniously out of their torso in agony.

"Note that when openrc-init is used, it must be paired with openrc-shutdown,
and *not* the shutdown or reboot commands from other packages, otherwise you
will encounter errors."

So not only have you introduced yet another monstrosity for people maintaining
setups to ensure, but you're imposing on system administrators who have developed
muscle memory for shutdown/reboot a need to remember the oh-so-much-shorter
command "openrc-shutdown" because your system is that much better.

OpenRC is probably the dependency-based system I had in mind that predated
systemd. I remember trying gentoo years before 2007, and some of this rings
a bell from back then. It might be a new name, but the framework guts must
have existed back then.

It seems as if there was a largely held consensus that sysvinit was aging and had become a liability, since so many different parties have built replacements for it. I guess I'm one of those heretic type people, because I actually like systemd. So I simply hope that eventually we reach a point where systemd becomes the category-killer sysvinit replacement and we can count on it being there. For all practical purposes, ISV's who actually produce software instead of rolling craft beer distributions of Linux in their spare time, only care about Fedora (CentOS, Red Hat) and Debian (Ubuntu). Since both of those lines have already moved to systemd, the debate is essentially over.

While installing the OS, I was reminded how much I liked netbooks so much
more than tablets. And when I booted up the 2009-era Linux that was previously
installed on it, I was reminded how much better the GUI's were before *everyone*
collectively decided to make everything ugly and unusable.

The netbook was a good choice because it has a low-power processor (an Atom),
and I already had it so the cost was $0. Previously I was using a Raspberry
Pi, but it kept crashing for some reason. I'm still not sure why.

Recent moves by Amazon suggest that they are preparing to ditch the Xen hypervisor
and move to KVM.

The new hypervisor was mentioned in the release notes for a new "C5" instance
type which is powered by Intel "Skylake" processors. (Read notes here: [
http://tinyurl.com/die-bezos-die ]). They go on to mention that "going forward,
web'll use this hypervisor to power other instance types."

Although Amazon is bad, Amazon using KVM is good. The KVM hypervisor is
really, really good. It's less cumbersome than Xen, makes more sense in the
way it allocates resources using existing Linux facilities, and still manages
to be a Type 1 hypervisor even though it shares memory management and other
functions with the host OS's userland.

Perhaps. pv-ops was designed to be hypervisor agnostic (even VMware supports
it!) so they could port things over if they really wanted to. More likely
they will just deprecate the old instance types though.

I don't think we're talking about the same thing. Amazon is committed to
supporting what they call PVM-based AMIs, which as I understand it are Xen-based
paravirt kernels that predate pv-ops and don't have the ability to boot as
HVM, bare-metal, dom0 etc (all of which are supported by recent pv-ops) or
else there would be no point to any distinction between PVM and HVM AMIs

Yes, that is a bit different. I still think they could shim it out and make it run under KVM if they really wanted to, but it's probably easier for them to just cap those instance types and let them age out. In the hosting business we generally don't upgrade customers who have already paid unless they are ready to pay us again.