Kind of tangential, but is Bezos a programmer type? I thought he came from banking or the big 4. I’m curious if the “malloc for the internet” bit is verbatim.
He was at D.E. Shaw, a company not known for hiring dead wood.
Amazon S3 Path Deprecation Plan – The Rest of the Story
71–80 of 146 posts
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#72Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#73Earlier quoted context omitted.
How was the original plan “reasonable”? S3’s FAQ talks about durability in terms of tens of thousands of years https://aws.amazon.com/s3/faqs/ . To honor that claim, AWS has the burden to support v1 URLs until the end of the internet.
It's pedantic, but durability has little to do how the object is routed. The object is still there.
[deleted]
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#74Earlier quoted context omitted.
How was the original plan “reasonable”? S3’s FAQ talks about durability in terms of tens of thousands of years https://aws.amazon.com/s3/faqs/ . To honor that claim, AWS has the burden to support v1 URLs until the end of the internet.
Storage durability has nothing to do with this. Changing how you access data saved in storage is a reasonable change to keep up with the evolution of networking technologies. The change here was deprecating an access pattern, not destroying data or anything remotely similar.
Tell that to the author of “The Peace Corps and Latin America”, who used S3 v1 URLs dozens of times in the book, with the assumption that they’d be available forever: https://books.google.com/books?id=Q312DwAAQBAJ&pg=PA135&dq=h...
And thousands of other books like that.
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#75Earlier quoted context omitted.
How was the original plan “reasonable”? S3’s FAQ talks about durability in terms of tens of thousands of years https://aws.amazon.com/s3/faqs/ . To honor that claim, AWS has the burden to support v1 URLs until the end of the internet.
It's pedantic, but durability has little to do how the object is routed. The object is still there.
That's not being pedantic.
A move operation is representationally an atomic copy and delete.
The original object is clearly no longer there.
It's clear cut breaking backwards compat for no reason at all.
I don't even know why they aren't supporting both API versions indefinitely it doesn't really make any sense it's literally a url rewrite/301 for anything hitting the old domain. Want to avoid our bottleknecked legacy LBs for better performance? Hit the new LBs. Hell even the sdk doing this upfront will alleviate a crap tonne of legacy requests.
People need to stop allowing corps making breaking backwards compat so nonchalantly it's unprofessional. And on top of that, AWS has a really good track record of maintaining backwards compat, allowing them to get away with this is just asking for more down the line.
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#76Earlier quoted context omitted.
Storage durability has nothing to do with this. Changing how you access data saved in storage is a reasonable change to keep up with the evolution of networking technologies. The change here was deprecating an access pattern, not destroying data or anything remotely similar.
Tell that to the author of “The Peace Corps and Latin America”, who used S3 v1 URLs dozens of times in the book, with the assumption that they’d be available forever: https://books.google.com/books?id=Q312DwAAQBAJ&pg=PA135&dq=h... And thousands of other books like that.
Using URLs you don't control in a book is just a bad idea all around. If you're reading a book some years after its publication, a URL that still does work will be the exception.
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#77Earlier quoted context omitted.
Storage durability has nothing to do with this. Changing how you access data saved in storage is a reasonable change to keep up with the evolution of networking technologies. The change here was deprecating an access pattern, not destroying data or anything remotely similar.
Tell that to the author of “The Peace Corps and Latin America”, who used S3 v1 URLs dozens of times in the book, with the assumption that they’d be available forever: https://books.google.com/books?id=Q312DwAAQBAJ&pg=PA135&dq=h... And thousands of other books like that.
Did they discuss that with Amazon prior to publishing? That seems like a completely silly assumption to make for a product that’s been around for only 13 years.
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#78This is interesting for a few reasons. IMHO, the original deprecation plan was reasonable. Not generous, but reasonable. Especially compared to what other cloud providers (eg. Google Cloud) have done. It did seem like a diversion from their normal practice of obsessively supporting old stuff for as long as possible, but it really wasn't too bad. Responding to feedback, publicly, and explaining what they were trying t…
Could you please clarify what Google Cloud did in comparison? I'm not arguing, just want to know more about Google Cloud.
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#79Earlier quoted context omitted.
Tell that to the author of “The Peace Corps and Latin America”, who used S3 v1 URLs dozens of times in the book, with the assumption that they’d be available forever: https://books.google.com/books?id=Q312DwAAQBAJ&pg=PA135&dq=h... And thousands of other books like that.
Did they discuss that with Amazon prior to publishing? That seems like a completely silly assumption to make for a product that’s been around for only 13 years.
Also every AWS book out there that has instructions on how to install the AWS CLI uses the v1 URL! You know why? Because that’s the official URL! https://twitter.com/dvassallo/status/1125502432924975104?s=2...
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#80Still doesn't help with domain censorship. This was discussed in-depth in the other thread from yesterday, but TLDR, it's a lot harder to block https://s3.amazonaws.com/tiananmen-square-facts than https://tiananmen-square-facts.s3.amazonaws.com because DNS lookups are made before HTTPS kicks in.
And even if you use encrypted DNS, the domain is still in the clear via SNI. There's an RFC for encrypting SNI, but that's not here yet.
Encrypted SNI seems to be tailor made for this situation. The public portion of the request SNI would just be s3.amazonaws.com but the ESNI extension has the full subdomain name. That (+encrypted dns) solves the privacy issue, while still enabling all the new features and improvements they have planned.