I wonder what exactly these laws prohibit. Like, does it apply to a fully encrypted cold-copy on Amazon Glacier? If you don't store the encryption key outside of UAE, I'd say this isn't even the same data that gets transferred to the third party, it's just some random blob. But I have no idea if the authorities of that country would agree and if it's even actually enforced for that matter, or if it's one of those laws that actually cause problems only if you follow them.
That is actually surprising to me. Claims like that are pretty common, they make sense and they should be true, so even though I don't really know AWS (/Backblaze/Azure/whatever) redundancy planning in enough detail, I used to trust them. It's really worrying when they outright say it will be ok, and then a week later it turns out to be not ok.
The devil is always in the details. Somehow I feel that when we offload the responsibility to some one else we get this feeling that the other person/entity would be doing full diligence and whatever else is required to carry out the job perfectly. However in reality most of the times they just do the bare minimum to pass your evaluation criteria to get the job.
Especially with Amazon, who are well known for squeezing every last bit of profit from their employees, contractors etc., it doesn't really sound surprising. "Offsite backups?! Sure, you could have had that if you had found the right page in the AWS console and if you would have paid 50% extra!"
Oh sorry, you picked "AWS Backup" but you actually needed to use "Backup AWS" to solve that problem. Perhaps hop on a call with our sales engineering and cost magnification teams to guide you to a better, more solutioned, tomorrow?
Perhaps, cheapness is always an factor but I'm potentially reading it as the customers perhaps not wanting data to move outside of the country and with AWS only have one datacenter in said country produced this result.
This is almost always the case.
It's one of the frustrating things about the software industry; because everything is much more complicated than the customer is able to comprehend, a software company can promise anything and the customer can't actually verify.
So any software company/project which actually took the time and effort to fully handle the enormous complexity, they can't sell themselves based on that fact because every other company (who didn't invest the effort) is also claiming it and the customer has no mechanism to verify the claims until some major rare event occurs.
And most of the effort is required precisely to handle those 1% of rare situations.
That is why contracts are more than one page in length. The details matter. I can remember receiving a contract class in Afghanistan about something as simple as moving gravel. Yeah, use your imagination with that and whatever absurd cartoon like fantasy you could dream up regarding "moving gravel" is still probably less strange than the real events that occurred.
I don't write contracts for a living, at least yet, but my learning so far is:
* clear goals: where is the end point and what does the product look like once it gets there in all required details
* defined test criteria: this is where you get to sue when they fuck shit up
* measures: there must be predefined measures. These can be wildly unrealistic at the start and require changes as the work occurs, which is ok, but there must be defined performance criteria that all parties are held to before work completion. In other worlds this is rewarded with bonus targets and penalties
its not true. If everyone actually did the bare minimum, everything would screech to a halt immediately. In fact people doing that imo is part of what causes the decline of empires. You can, in fact, trust people further than you can throw them.
Its a cousin of the mindset that the reason people don't steal is because they think they will be caught and rationally weigh up based on the value they gain and the chance of loss that its not a worthwhile action.
No, most of the time people steal because they think its wrong, and they dont want to do it.
Public trust is a real thing and varies massively by country. America is notably extremly low on this metric
its also the fact that a lot of fundamental systems work in trade offs.
Do you want performance, or correctness.
Well, if you want performance you use write through caching and in the case of distributed storage: more nodes confirming the block before returning. Huge performance cost.
Outsourcing this just means someone else makes these tradeoffs, they will prioritise the general case- and they’re even more incentivised to move the needle towards things that are most visible to the end user.
In this case, performance.
You won’t notice that theres a third commit server off-site (unless that site is bombed), but you will notice slower writes- and the general case says that people will express comparative dissatisfaction with weaker performance and use it as a justification to use another provider.
if you want correctness* you use write through caching.
My mistake, if you want performance you choose write-back caching, and fewer nodes need to acknowledge the write. Sorry for clumsily typing the inverse when I was in a morning haze waking up :(
I would love if someone could tell me the name for this phenomena. FWIW, using an LLM incites this same undue assurance as well. No matter how much you know that an LLM might just be hallucinating, it still happens anyway. It's a hard instinct to fight.
This is so true. After 20 years in the tech business I have so rarely seen perfect execution. It's mostly scrambling and chaos and a miracle anything works in the first place.
It really is important to understand the failure modes that the durability model accounts for and what it doesn't. It only accounts for "normal" failures, like an HDD reaching end of life.
For example, you mention Backblaze. Backblaze has public posts about their durability model. They claim to use 17:20 Reed-Solomon erasure encoding. That means there are 20 shards of a blob, and you can lose 3 of them and still reconstruct the blob.
Think about that for a second. If they store 4 shards in a datacenter, that means that a loss of that one datacenter is sufficient to lose the blob, forever. That entails that blobs are sharded across a minimum of 7 data centers, or the loss of one data center might mean permanent data loss. Which one do you think is true? (In fact it's pretty clear from Backblaze's public posts that they don't shard across data centers at all, only across racks within a data center.)
Now, AWS's availability guarantee — not their durability guarantee — entails that they use a less cost-effective erasure coding ratio. S3 is designed so that your blob is available even if a whole AZ goes down, and it's well known that most AWS regions have only 3 AZs. Therefore, if you tolerate the same number of shards lost to HDD failure as Backblaze in your durability model (3), then you might need 17:30 erasure coding to get the same durability and the required availability. That means S3 is storing way more physical bytes than Backblaze — 1.76x the logical size of the blob, instead of Backblaze's 1.18x. That's more expensive, but it also gives you better availability.
Which is also why One Zone S3 is cheaper — if you don't care about the availability guarantee, S3 can do what Backblaze does and save 33% on physical bytes, and they pass on 40–50% of those savings to the customer (this is fairer than it sounds — there's more overhead than physical storage bytes).
But here's the thing. AWS has more redundancy built in than Backblaze because they make availability guarantees in addition to durability guarantees. BUT the durability model is the same, which is why Backblaze can claim equivalent durability to S3. S3 in fact has better durability — they can survive the permanent loss of an AZ without necessarily losing blobs stored there (with the exception of One Zone blobs), and Backblaze cannot. But that's not actually a factor of the durability model, which is just taking into account normal events like HDD failure. Instead, S3 has durability that's more resilient to AZ loss because of their availability model. It's a side effect that isn't actually part of the durability promise!
As far as I'm aware Backblaze stores data only within a single datacenter (for a given region). This likely made sense in their original business model of being "offsite" copy of data.
But it very much breaks down for B2 where they're now storing original data. I hope they rethink this model. You do get what you pay for. There's a reason they're cheap.
The caveat is always "if you're using the service correctly" which is not necessarily free. Meaning taking advantage of multiple geo zones, building in redundancy to your stack, etc. Like everything he said is possible if your technology stack living in AWS was designed to survive it. Everyone who has ever had the "we lost your data" email from AWS knows at the end of the day the cloud is just someone else's data center with neat provisioning tools and services.
The problem is that lots of people seem to be under the impression that they are doing it right because they are using AWS. They don't realize that AWS is a toolbox, not a 'ready made solution for redundancy against all catastrophes you are possibly exposed to'. They use that to their advantage by pricing such solutions at a level that people will either pay through the nose or will be left without recourse when AWS loses their data. It's stupid, but at the same time these beliefs are surprisingly wide spread.
Yep, a lot of non-technical leaders believe that 'cloud' is synonymous with 'DR strategy' or even 'backup'. "We won't have to worry about being offline if our server goes down if we move to the cloud!" Some of these people fundamentally don't understand what the cloud is, their assumption is cloud means easy button that solves all your infrastructure and uptime problems.
But alongside the marketing blitz they also offer certifications for people who are supposed to execute these projects. Even the most foundational certification exam -- which simply tests your recall on what AWS service is for compute versus networking -- teaches and tests you about "Shared Responsibility Model" that draws the line at what the customer is still responsible for when they use cloud bases IaaS / PaaS / SaaS services.
If businesses are going to cloud but without engaging / listening to competent people who know these basics -- then the blame needs to be somewhat pointed back at those very business leaders I feel.
This is not obscure magical knowledge either that is tightly controlled. Any cloud vendor will freely teach you that. Or even a google search would.
Who is a CEO going to believe? Amazon, Microsoft and the entire IT infra division or that lone SRE who disagrees with them?
I mean, every time cloud comes up on HN we see legions of techies posting strowman arguments about why you should offload everything onto AWS, GCP, Azure, etc.
Aws cto is basically opening every presentation with a everything breaks all the time slide, idk where you get that idea they oversell the cloud resilience
They could offer controlled "failure of service" service where they randomly take stuff offline and you have to pay to get it back if you don't have a backup/recovery strategy.
You just have to take a look at the Rube Goldberg-esque abomination that is the AWS web interface for a few minutes to realize that it's not that simple. Granted, most executives won't do that...
Or encounter their CLI and it's lovecraftian combination of positional arguments, named arguments, piping, json documents, etc, distributed largely by random lot, as far as I can tell.
And for a time, it even seems true as long as the natural disasters that impact various customer offices happen to not impact that one particular data center…
If I were a bit more bloody-minded I would launch a service for vibe-coded apps that, under the hood, did everything "the right way" and just charged a flat fee + percent on the underlying.
I feel like if this was done correctly it would eat a bunch of the market, but I question how many people are actually willing to pay for "the right way". The last time I had that experience it was with Heroku which was quite a leaky abstraction.
I think a lot of people have built those services. But doing it right is more expensive, and people end up choosing the $5-$10/mo option over your $30/mo+ that does it right. Multiply those numbers by whatever multiple you want for higher end stuff.
Well, one of the things I would be very, very focused on is LLM optimization, so that is something that could be mitigated, at least. Especially since I would be building with it, certainly, I would try to engineer it so that it was to Mr. Claude / Mr. Gippity's taste
1. There is no single "the right way", different app have different "right ways"
2. As for the flat fee, it only works initially when things are simple, as time goes on and your business and usecases you support grows, a flat fee won't work anymore.
I mean I would be limiting it to a very specific use case, and the flat fee would be "plus a percentage of the underlying", something like $50/mo + 20% of the AWS spend underlying.
And for that, with a simplified use case, well, they can scale up to $20k+ a month if they like, that would be ideal, and if they need a more complicated setup or enterpriseyness, migrate off with my blessing and available-not-required hands on support (again for a reasonable fee, maybe $10k if you want the white glove).
>Quite often a senior leadership issue because backing stuff up results in $$$ spent, which makes shareholders unhappy.
This is true. The latter half of your comment is not. At best they have a duty to shareholders. But your assertion would mean every time a company posted a loss and the price went down the execs would be in legal trouble, which is nonsense.
Shareholder nuisance lawsuits can happen basically any time the stock goes down... or doesn't go up enough, and often companies will settle instead of the expensive fighting...
There are grounds legally if shareholders can prove that the "long-term risk reduction" argument is a lie, they can sue under the Duty of Loyalty. In reality, yes, this amounts nuisance lawsuits, large settlements and disruption at the board level. In practice, this and the executive pay structures almost always incentivizes short-term decisions and these risks become problems “for the next person.”
This is Matt Levine's theory of "everything is securities fraud".
Something bad happens, stock goes down, angry shareholders sue because they should have been told the bad thing would happen and the stock would go down.
What?! Publicly traded companies are not “legally bound to return growth in share price or dividends.”
There are plenty of companies who pay no dividends and have not returned growth in share price. They’re still operating and no one’s coming to throw the execs in jail.
On the off chance that there is such a law, please cite it.
In a Gramscian understanding of the world it is, yes. Forget Gramsci, right now I'm finishing reading a book by Maurice Gauchet [1] (not a leftist by any means) whos's saying exactly that, i.e. that neo-liberalism is very much defined by its insistence on relying on " le juridique"
> Ce dérèglement se manifeste avant tout par la réduction de la démocratie à une logique juridique, le néolibéralisme ayant imposé une conception où le droit, érigé en garant exclusif de la liberté individuelle, relègue le politique à une fonction purement gestionnaire
automatically translated as
> This dysfunction manifests itself primarily through the reduction of democracy to a legalistic logic, as neoliberalism has imposed a conception in which the law—elevated to the status of exclusive guarantor of individual liberty—relegates the political realm to a purely managerial function.
Yeah, that sort of thing, where the law sort of dictates the current morality based on the "morality" the of above mentioned neo-liberal order/current state of things.
Of course that all this is kind of circular, meaning the (neo-liberal) morality imposing itself via law on the current (and by now surpassed) morality, but that's how things usually go when it comes to societal theory.
No, that quotation on the GP clearly states that AWS has enough redundancy within the same region that they will continue all services running on it if a datacenter is destroyed.
It's very clearly not about you being able to set-up redundancy for yourself.
That's actually true. AWS is designed to survive one datacenter being offline (which happened more than once, btw). When the first DC in ME was hit, AWS continued working normally, with only a few services experiencing issues.
But it's not designed to survive TWO datacenters going offline, and in a permanent fashion.
"S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive redundantly store objects on multiple devices across a minimum of three Availability Zones in an AWS Region. An Availability Zone is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region."
As far as I've heard before that's not with parity and three zones means three copies. But when I search now I see things about 5+4 parity, any insight here?
Yes, normal S3 is at least triply-redundant. But it's possible for S3 to lose some data if two DCs are down and a disk dies in the single remaining DC.
AWS doesn't use parity for S3, they actually mirror the data.
Not just in terms of service costs, but in time and complexity. In many cases building out that complexity is complicated and difficult. And sometimes the functionality you need isn't supported in the regions you use.
Pretty much this, it’s your responsibility to use their tools to make sure your data is managed in such a way that any data destroyed is already elsewhere before the event.
Well, listen, you do know that even when the largest most ambitious and most sophisticated things are shipped, each owner of each specific part (could be many many owners) basically , to the best of their ability, prayed that nothing particularly bad happens when it’s shipped off. Truly, that’s the best a mortal human can do, pray their part doesn’t break.
So then that big thing comes to you. It’s all kind of … held together by a prayer …
Trust me I’ve worked at these big places. You wouldn’t believe how much fucking luck and grace from God is allowing you to do anything with your digital life. It’s a mindfuck of a tangled mess out there, eternities worth of written code that only God ensures works together at this point, only to get more hidden with AI.
How much data is stored in the average aws data center? Assuming they do regularly back ups, it makes sense that recent data can’t be instantly backed up and so there will always be some data in transit or queued up no?
That's very unpleasant to hear. It's sad to be reminded that Rust compiler is not magic and cannot just... do these things somehow. Sure, all abstractions do have some cost, but, man, 17% performance gain by virtue of replacing enum with this monstrosity? That's very annoying.
Probably with an annotation around a NanBoxable(f64) type that tells it to do that.
That being said, the optimization is complex that may be insufficient:
> For my boxing scheme, I picked a bias value such that the lowest two bits end up being 10. That 1 in bit index 1 indicates that doubles can't be directly compared for equality. Amazingly, we only lose two bits of exponent, and we keep the full precision of the mantissa, meaning we lose no significant digits in the flonum representation.
This suggests the optimization needs more information about specifically how you want to box the float. There probably is some primitives worth considering standardizing to make this kind of optimization possible so that the tunable parameters are passed as const generic values.
Or actually doing what they did here where it changes it to a
enum Value {
SimpleFloat(64bit value),
ComplexNan(Heap pointer)
Ptr(*const T)
}
You lose out on performance if you use the bit patterns in the float that most people don't use very much, but you keep the correctness.
I'd be very unhappy if a compiler silently did this to me - it would make performance extremely hard to reason about. But it's not quite as bad as changing the semantics.
A 64-bit sum type can't magically combine an i64, f64, and several raw pointers, each of which carry a full 64 bits themselves. You have to change the semantics of the code. Some semantics could be expressed more easily with compiler improvements, allowing eg `Aligned<T>` like `NonNull<T>`, or `FiniteF64` like `NonZeroU64`, or even `#[range(0..1<<60)] u64`, but you still couldn't overlap two `Aligned`s in one enum, because only one can be stored unchanged, the others need masking off before usage. Even if the enum semantics allowed this, I'm not sure the compiler should do this kind of compute/memory tradeoff automagically. Which doesn't mean you can't write nice abstractions over it, there's a few tagged ptr crates which aim to do it for you
It's so funny to see a "compiler is magic" people encountering reality in the wild. No, an algorithm that must work for every single user of the language cannot possibly optimize for every individual's use case. It is trivial for hand-written code to outperform a compiler on bespoke use cases. That anyone perpetuated otherwise was a lie they told themselves to feel secure in their ignorance and incompetence, because it's more comfortable to excuse your lack of skill if you believe that no human could ever out-perform a compiler. The saddest part is the barrier isn't even that high. You, and the rest of the magical compiler religious believers, could learn to do this, if only you tried instead of believing in your fairy tale.
I shouldn't be surprised, given I saw plenty of nicely functioning legacy codebases, but still, somehow this isn't the news I was expecting to hear in 2026.
Obviously it's bad and we can all say "fuck Microsoft" once more, but "we" probably don't use Windows anyway, right? I have no idea, really, but if you willingly use closed-source spyware that is notorious (for AT LEAST 15 years) for all kinds of invasive telemetry it forces upon you, you probably wouldn't find this new piece of information concerning anyway.
And ironically, I think that this one is kinda fair. I mean, you specifically asked your software to generate whatever pseudo-random bytes it wishes to loosely based on some text prompt. It did that. Now, apparently, these pseudo-random bytes turn out to be personally identifiable. So what? I suppose they didn't claim their PRNG to be cryptography-grade. They could even make it seem like an accident, should they be bothered to. Make it way less obvious.
Now if it would insert watermarks on save (like printers do), that would be really outrageous. But when you trust software to produce "whatever", you probably shouldn't be really mad about it doing anything more than you asked to.
Of course the EU is not democratic. The sheep, the common people, are only allowed to vote on pre-defined options that are decided entirely in private by the new political nobility, the EU politicians.
Should they happen to vote incorrectly, like when the EU constitution was voted about in ireland and france ,they will just have to vote again and again until by exhaustion, the right result is guaranteed.
The EU has nothing to do with democracy. No, putting a paperslip in a box is not democracy.
I think perhaps switzerland is the country on the planet that is closest to democracy, and they also have the highest incomes ,highest living standards and lowest taxes in europe.
The EU has choose the path of soviet like socialism, and of course the economy will slowly decrease until it collapses, and then we'll get a Hitler 2.0 to "fix" the problems that were caused by the EU dictators.
The best thing you can do if you care about europe, is to move outside of the EU, avoid paying tax, do not feed the beast, and spread the truth, so that fewer and fewer people want to move there. Then it will hopefully collapse in time.
The elitism of direct democracy is a mystery to me, especially in the case of the US where it is not technically direct and the powers and role of the president are deeply modelled after those of the British crown of the times
Actually, they do, sort of. At least, if you use GLSL shaders. I remember some demo project using it in a way that made it appear that the website "sees" another window with the same website, which blew my mind when I saw it first. Cannot recall the name or anything else to locate it.
Screenshots would be helpful, because (you may be surprised to learn that) it is not entirely obvious which mode of behavior is supposed to be "wrong".
Anyway, I wouldn't say it currently behaves nicely (like something I would like to reuse anywhere whatsoever). Tested on Firefox opening Bookmarks on the left. First off, there is this ugly flicker, as browser first renders the "wrong" version, then your JS "fixes" it. Second, there is some concurrency problem, as by opening and closing Bookmarks repeatedly I somehow managed to render both versions: centered to viewport and covered by sidebar.
And, yeah, as others have said, I also think that allowing sidebar to cover your webpage content is absolutely bogus and don't foresee myself wanting this behavior, ever. But that's up to you.
I’ve added GIFs showing the intended behavior. The brief movement doesn’t bother me, opening or closing a sidebar already resizes the webview and causes pages to reflow in the browsers I use. Ending in the wrong state after repeatedly toggling it is a bug. And yeah, if you prefer viewport centering, there’s no reason you’d want to use the extension.
Not trying to argue you out of your preference, but trying to understand it: Why would you want to be able to accidentally hide parts of the page by having a sidebar open, or extended too far? I don't understand why the page should pretend to take up the whole window and ignore that it does truly live in just a viewport. I get why aesthetically it might be pleasing, but isn't that pretty short-lived when faced with serious practical drawbacks?
I don't understand what's the conclusion is. I was supposed to "disagree initially and be convinced by the end", but I ended up losing sight of what I was supposed to agree/disagree, and what should I've been convinced of.
It starts with the premise of "C/C++ have pretty fucked up type systems, and look how much nicer integer type names are in Rust" and also that we should use unsigned integers as the first approximation if we are trying to model ℕ. Was I supposed to disagree with that? It didn't seem like the author was arguing against them, and they seem like pretty trivial, obviously true statements.
Then it starts to talk about how we cannot properly use unsigned in C/C++, because it's fucked up, and it cannot be fixed properly because the proper handling of integers is too expensive. This all sounds sadly familiar and we are nodding and saying: "Well, such is life." But at least we still have Rust, that doesn't suffer from the same inherent UB curse, right? I mean, I'm not deep enough into the details of current compiler implementation, but I've got the impression that the described problems don't apply to Rust. All good then? (edit: obviously, except for the fact that we still allow wrapping in prod builds, because it's expensive not to. But we all knew this already.)
Then it follows up with some pretty contrived (IMO) example of how we cannot mindlessly swap int with uint (obviously? I mean, you basically explicitly check for `i == -1` in this example), framing is as "uint is unintuitve". Was it supposed to be a strawman? It surely is a strawman, but the author doesn't argue against it.
And then a couple more of statements to the support of Stroustrup's "just use signed" (in C/C++), which also don't seem to apply to (saner) Rusts choices.
And then it ends w/o a conclusion. So, what was the conclusion supposed to be, please? I really don't understand what the author tried to convey.
reply