Trade war isn't real until shelves are empty and black market is blooming, like a regular war.

Serving from space CDN means at least 2x better ping than Starlink (for content directly served by CDN). Then you upgrade to space Cloud and provide even more content with fewer hops.

Being an ISP, CDN, Cloud Provider and Content Provider gives serious advantages. That's a great way to out competitors and get hefty fines at some point.

My first job was exactly that, selling windows app in Delphi. I joined the new team working on .net windows apps and we had an army of people clicking on UI all day long. They maintained their "test plan" on a custom software where they could report failures.

TBH, that was well done for what it was but really called for automation and lacked unit-testing.

I am forced to use a custom kv store for my current t project. That pos has a custom dsl, which can only be imported through a swing ui, by clicking five buttons. Also, the ui is for 1024 screens, they are tiny in my 4k monitor

I remember a test plan in a spreadsheet where no test had an ID.

I wish I could teach everything I learned the hard way at that job

That was every installer looking unique now it's every app wanting to look unique.

You now have to build and self-shot a complete CA/PKI.

Or request a certificate over the public internet, for an internal service. Your hostname must be exposed to the web and will be publicly visible in transparency reports.

Companies have software to manage this for you. We utilize https://www.cyberark.com/products/machine-identity-security/

You could always ask for wildcard for internal subdomain and use that instead so you will leak your internal FQDN but not individual hosts.

I'm pretty sure every bank will auto fail wildcard certs these days, at least the ones I've worked with.

Key loss on one of those is like a takeover of an entire chunk of hostnames. Really opens you up.

Let's Encrypt dropped support for OCSP. CRL doesn't scale well. Short lived certificate probably are a way to avoid certificate revocation quirks.

It's a real shame. OCSP with Must-Staple seemed like the perfect solution to this, it just never got widespread support.

I suppose technically you can get approximately the same thing with 24-hour certificate expiry times. Maybe that's where this is ultimately heading. But there are issues with that design too. For example, it seems a little at odds with the idea of Certificate Transparency logs having a 24-hour merge delay.

Also certificate transparency is moving to a new standard (sunlight CT) that has immediate merges. Google requires maximum merge delay to be 1 minute or less, but they've said on google groups that they expect merges to be way faster.

The log is not really for real time use. It’s to catch CA non-compliance.

Interesting and definitely something platforms must take into consideration.

Now back to the post, implementing custom cache is not something Netlify is strongly complaining about. They are mostly asking for some documentation with rather stable APIs. Other Frameworks seems to provide that.

This adds costly pollution tests to the equation, if you want to eat eggs safely. Backyard chickens doesn't sound like a great solution.

I think in practice in their randomized tests, almost all samples were above the recommended threshold, so you can save the test money and assume it's not going to be good.

Probably covered here:

> In the old days you had to run a script or install a package to hook into their monitoring....but with IPMI et al being standard they don't need anything from you to do their job

How can IPMI detect the cause (kernel panic vs user command) for restart?