_16k4

I've always thought of Apollo environments as containers before kernel features for containers existed. With enough environment variables and wrapper scripts taking the name of real binaries to populate stuff like LD_LIBRARY_PATH, Apollo makes a private environment that is only _slightly_ contaminated by the host.

I was able to load up yocto's standard VMDKs into HyperV on my windows desktop, but AWS's import tool barfed on it. I build an embedded linux and wanted to use AWS as a hypervisor for larger scaled testing. (It was fairly easy to setup a custom machine config in yocto. (Require tune-core2.inc and you're off to the races.) I use the variable overrides system to tweak build build arguments on some packages to have them stub out hardware in the virtual images.

I've found though that making your own image classes to be the most direct way of formatting your image if you need something exotic. The image classes system is kind of fun - you can keep stacking on more reusable classes that act as a kind of pipeline.

To get it working on AWS I ended up doing what I needed to do by spawning a VM with an off the shelf AMI, attaching a second disk, dd-ing my image on, and then capturing that as an AMI. (I'm kind of annoyed that I couldn't find a proper API for this, but maybe I'm not looking in the right place. Their import tools all want to understand things about your image and mess with it, and I just wanted to send them a flat disk image.) This process was an annoying enough slow down for testing that I ended up making an image that would boot up just enough to get networking up, then fetch the real image from S3 based on directions in user-data, over-write itself, and reboot. If going with newer AWS instance types, don't forget to include their kernel modules, and have fun debugging when it doesn't boot :)

Is the intent to get class E routed on the public internet, or just make it available in private networks?

I've seen docker configs squatting on chunks of class E space for the local bridge interface, presumably because Linux takes it, and it doesn't usually clash with the landmines in rfc 1918 space.

I know of at least one company using class E as the new 8/8 ;)

I've heard a fun story from the old timers in my org about a fiber outage in Brazil. A routine fiber cut occurred. They figure out how far from one end the cut is (there is gear that measures the time to see a light pulse reflect off of the cut end.) Then they pull out a map of where the fiber was laid, count out the distance, and send a technician out to have a look at where they expect the cut to be. All standard practice up until this point.

The technician updates the ticket after a while with "cannot find road." The folks back in the office try to send them directions, but then the technician clarifies, "road is gone." Our fiber, and the road it was buried under was totally demolished in the few hours it took to get someone out there. The developing world can develop at alarming rates.

Other tales from the middle of nowhere: People shoot at arial fiber with guns. Or dig it up and cut it for fun. One time out technician was carjacked on the way to doing a repair.

I just put 1 TB in AWS/Azure/GCP's cost calculators.

AWS (US East 1, no free tier) - $92.07

Azure (East US) - $88.65

GCP (Americals) - $122.88

I'm quite surprised by GCP being the highest cost here, and by such a wide margin.

I assure you there is nothing sinister about the price asymmetry. Fiber and routers have as much bandwidth coming as going. The inbound traffic is mostly composed of little http(s) requests. The outbound is full of images and mountains of JavaScript. Cloud providers don't charge for ingress because they got it for free when they grew their egress capability to meet demand.