Started using my other AI services for conversational work, I lean on my AI subscription with kagi.com a lot more now when it's not related (in whole, or in part) with my dev work.
I agree, and it can’t be right - is this based on “projected utilization” or something?
My thinking is there wouldn’t be downward pricing pressure on data center compute if utilization was actually this high - it would mean providers could jack up prices and walk with larger margins rather than burn money for acquisition, right?
Plus the market wouldn’t increase the price of borrowed money if utilization was that high; they’d see the same signal. But the cost to borrow money for datacenters has roughly doubled year on year (might just be for riskier ventures? Buildings? Is this aggregate?) - those two signals wouldn’t disagree, it’s nonsensical (I mean, right?)
Edit: it’s just “the buildings”, and it makes sense: maximal utility comes from installing compute in a building already setup to house compute (cooling, infra, power). I actually take this as a negative signal: we’re seeing downward pricing pressure already, AND new projects aren’t fully booked, AND money is now twice as expensive. Somebody’s going to lose their shirt unless OpenAI’s Omnissiah comes online and converts us all.
IMHO, the easiest way to perform a restore test is to use your production backups to refresh a lesser environment on a weekly cadence. Naturally this has to be appropriate to the type of data you're restoring, e.g., our E2E (end to end) testing environment has been built to the same risk tolerances of production so it's suitable for production data and the PII (Personally Identifiable Information) it hosts. If this isn't in your own risk tolerances, you can still perform the same test but ensure the data from prod is anonymised or alternatively destroyed, and perform a second restore after production restore with the dataset that preceeded it that has no PII data or similar.
With this the E2E tests confirm the backups are expected and you can tick a box that when shit does eventually hit the fan, data corruption isn't a problem. Normal caveats apply, you must make sure your backups are immutable so they cannot be modified or changed _after_ the tests have been ran.
I was using Restic + Backrest as well for my personal Windows machines and it was great. Then I found out that Backrest stores the vault password (among other things) in a simple plaintext file on your local hard drive. Not sure if this applies to all platforms but for Windows users that is a huge security hole in today's environment.
We actually do use some of our backups in anonymize -> test environment pipeline so it gets dual use on top of just testing restores.
We also use S3 versioning in case something gets the keys and just erases it. Then it's replicated to the cloud S3-compatible store to get the offsite location.
Only feature I really miss is "turn this restore into .tar", both for testing restores and for convenience when we get requests of "we need this directory from 4 weeks ago"
Unfortunately it's not the norm, and is instead a great, and positive example of an outlier.
Corpo speak globally is a lot closer to the opposite of what you quoted. The US, Australia (gas, mining and energy companies are core examples) and for the larger part Europe (e.g., Volkswagen) effortless say everything and nothing at the same time.
For anyone who hadn't heard this before, like me. <3
In computer architecture, Amdahl's law (or Amdahl's argument[1]) is a formula limiting the speedup of a task as resources are added to the system executing that task.
The law can be stated as[disputed – discuss]:
the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used.[2]
It is named after computer scientist Gene Amdahl, and was presented at the American Federation of Information Processing Societies (AFIPS) Spring Joint Computer Conference in 1967.
Amdahl's law is often used in parallel computing to predict the theoretical speedup when using multiple processors.
reply