Thing is that these "vendors" don't have the same level of hardware bias that Android has. Unlike "something Nexus something", people can't (usually?) run a vanilla Android.
PS: if you pine for those days of manually fixing things, there's always LFS that has all the knobs and switches. I guess it's even more hardc0re than an old RH9.
It looks like "security in deployment" (aka sane defaults) is a concept difficult to grasp for the CouchDB devs. I wouldn't expect this from a project that claims it is passed over version 0.x.
> This creates bad habits, such as relying on auto-complete. Instead of being a direct actor, we become some sort of operator of a big machine that does the work for us.
That's the point of having machines in the first place. Do you work for the machine or the machine works for you?
You still need to provide an access key id and secret access key with that session token as returned by Security Token Service. And properly sign every request with those credentials. With a proper session token, but invalid credentials, the request fails with HTTP 400: "__type: com.amazon.coral.service#InvalidSignatureException, message: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.". Amazon still checks the signature. The same logic that could be used for IAM credentials that don't expire, without the need to check for a valid session token. If it is an Amazon screw up, that static credentials take more time to evaluate vs temporary credentials - that's not out fault. It is a pure Amazon screw up. The signing logic is still there for every API call. So (apparently?) we're back to square one: extra requests and wrapper logic for zero benefits, and worse overall experience. The session credentials aren't stateful. I specifically checked for this behavior. Therefore what you say, doesn't seem to happen in reality.
And for the love of God, don't blindly trust the documentation / what the AWS folks say. As an AWS library author myself, I had a lot of fun debugging failed requests because the smarty who wrote the signing procedure docs forgot to mention some HTTP headers that are mandatory to sign. I had to reverse engineer an official SDK in order to patch my own code. While being implemented as the docs say, the signing method failed at every request, although I had a valid session token. Trial and error is always a broken way of developing things due to broken docs. If you're an AWS employee, please send my regards to the documentation folks.
The API doesn't bother me as much as the temporary authentication via STS. Temporary credentials for database access? Seriously? I am the only one who sees how ridiculous this is?
While we're at it, can the Adobe folks explain to the rest of the world when Flash is going to suck less? I mean really. Don't care about the on paper gibberish.
This is exactly what they said on their blog post:
Long term archival data is different than everyday data. It's created in bulk, generally ignored for weeks or months with only small additions and accesses, and restored in bulk (and then often in a hurried panic!)
This access pattern means that a storage system for backup data ought to be designed differently than a storage system for general data. Designed for this purpose, reliable long term archival storage can be delivered at dramatically lower prices.
PS: if you pine for those days of manually fixing things, there's always LFS that has all the knobs and switches. I guess it's even more hardc0re than an old RH9.