Oh how things have progressed.

Consider a hyper-converged cluster with many nodes serving distributed block storage, say at N=3 replication. This can tolerate exactly one N=1 node of outage for the reboot. It would seem preferable to drain the nodes in a way that allows for more parallelism in the per-node kernel-reboot process, but draining is expensive and its cheaper to reboot and hope the data comes back to the pool within some period of time after the reboot. This gets worse linearly as the cluster grows.

A non-trivial size cluster facing this can have a reboot rollout easily stretch from hours into days and even weeks. It is further made slower when the roll-out itself is repeatedly paused when any other production issue is detected, or some other in-cluster event is happening and distributed storage health is degraded or unavailable. If a single (additional) node goes out during the reboot roll-out, data goes unavailable and storage must wait and heal. It also simply takes time for the cluster to reconcile when the storage eventually comes back from reboot to make sure it is all still there.

If your systems are large enough, things will go so slow that things fall into the trap where the target release changes mid-deployment: to benefit from everything learned in the last many days or weeks, security, performance, crashes, whatever! There is benefit because the fixes you cared about most got onto a portion of the cluster sooner than later. There is also penalty, as this resets the time it takes to deploy, elongating the perceived end-to-end deployment time. This negatively affects OKRs and similarly displaces the release of anything that was queued for upcoming releases.

So yeah, live patching is great to get priority fixes out in a matter of minutes or hours. I also think it is the best tool to get oneself out of this rollout-reset trap and onto the next release sooner. Faster than rollback or rollover.

I wonder how long these sorts of games will play before the law applies itself.

This decoupling of system libraries from the OS itself is necessary because it otherwise becomes unmanageable to ensure "google3 binaries" remain runnable on both workstations and production servers. Workstations and servers each have their own Linux distributions, and each also needs to change over time.

This is centralizing governance of forfeited assets from across the many agencies that are currently holding wallets with no direction, into a single place: the Treasury. This seems far favorable to letting various (430+) agencies manage these valuable assets on their own where they can easily be lost, stolen, etc.

Also, there is still plenty of hardware out there that only comes with BIOS-capable option roms. These still require CSM if you want them to be be visible at boot.

What is being managed here with Effingo is the relatively tiny links between sites, not the bandwidth on the fat local links. Bandwidth needs to be managed and prioritized across all the various copies that are happening across different services apps and teams simultaneously across the company, and across the systems themselves as aggregate for the links. Managing it gives you control on cost but also ensures optimal use within the constraints imposed and consistent and reliable handling of the copy use case.

I recall participating in an ESPP where each time it vested (each 6 months) ended up being in a trading black out window, where we had to wait until Earnings Release + 3 days before being able to dump the stock. Lost that 15% gain just about every time.

If you are addressing others, use better words to describe them. Calling people "folks" all the time is lazy and insulting.

Now not all speakers using it mean it that way, but it's a lazy word to use to group people, and the othering of people it implies seems to equally apply. The condescending tone really shines through.

If you intend on continuing to use this word to address people, know that at least some of us are making this conversion in our heads at all times.

CO2 is plant food, and is a red herring to the energy discussion.