The place I've probably wanted it the most though is in CI/CD systems: it's always been annoying to build and test system images in EC2 in a generic way.

It also allows for running other third party appliances unmodified in EC2.

But also, almost every other execution environment offers this: GCP, VMWare, KVM, etc, so it's frustrating that EC2 has only offered it on their bare metal instance types. When ec2 was using xen 10+ years ago, it made sense, but they've been on kvm since the inception of nitro.

On fs.com you can order fiber in custom lengths. An armored pre-terminated 350ft OS2 duplex cable costs $128: https://www.fs.com/products/20720.html Non-armored would be as cheap as $40: https://www.fs.com/products/50147.html?attribute=58053&id=17...

If you don't have a conduit, you can buy direct-burial cable. Two strands at 350 feet would be $590: https://www.lanshack.com/2-Strand-CustomLine-Corning-ALTOS-O... 6 strands at 350 feet would be $687: https://www.lanshack.com/6-Strand-CustomLine-Corning-ALTOS-O...

If you have some extra length, just coil it somewhere in the wall and don't bother splicing or re-terminating it. You can also use keystone jacks or couplers at both ends too so you have flexibility later without re-running it through the conduit.

If you have a static IP, it should be fine, but this became an annoyance the couple of times the IP changed when I was living there.

GCP looks like it does UEFI too. And Azure Gen2 instances use UEFI too.

It's truly great for situations where APIs refuse to take anything other than files and you don't worry about cleanup. Ex: loading certs from memory into a python openssl context.

Really that just means a registry that sends back a header indicating it supports signatures and serves up the right signature endpoints. It's shocking this isn't more common.

But if you just want to check signatures at the cluster's point of entry, you can use an admission controller to block the pods from being created with unsigned images.

https://www.livingabroadincanada.com/2009/05/13/why-does-ket...

AWS does continue to support older instance types, however, but only legacy workloads are using them. They actually now even run the XEN based legacy instance types on nitro. https://perspectives.mvdirona.com/2021/11/xen-on-nitro-aws-n...

That said, from further reading of the GCP docs, it does sound like if they detect a disk failure they will reboot the VM as part of the not-so-live migration.

You can read more about GCP live migrations here: https://cloud.google.com/compute/docs/instances/live-migrati...

So while I can get behind this sentiment philosophically, until something changes upstream in kubernetes, this makes it really difficult to use crossplane in a cluster used for anything else and it probably makes sense to offer a workaround until then. Also, in practice, any security conscious users running crossplane in production are probably going to give it AWS credentials scoped to only the resources they want to allow it to manage, so even if you do install all of the CRDs in the cluster, 90% of them won't work due to their AWS credentials anyway.

Many devices also operate less efficiently in high heat. If the AC unit is on a circuit with other devices, it is possible that the influx current when starting the AC unit trips the breaker. One might even be able to get away with 2 AC units on a 15A breaker as long as both compressors never start at the exact same time, but cause a trip when then kick in together.

When hardware fails, the instance is migrated to another machine and behaves like the power cord was ripped out. It's possible they go down this path for failed disks too, but it's feasible that it is implemented as the disk magically starting to work again but being empty.

You can read more about GCP live migrations here: https://cloud.google.com/compute/docs/instances/live-migrati...