You're oversimplifying. Even if all a system is serving is static HTML, it's still potentially vulnerable to things like buffer overflow attacks and almost certainly vulnerable to DDOS. I agree that many industries cut corners on information security, but I don't think it's realistic to advocate certain stripped down technologies as "unhackable". Even in those older simpler systems, there were layers of abstraction that not one person understood entirely.

How is it without comments? It's the easiest thing to populate a nearby cell with some freeform text giving more context. How is it full of go-tos? It's pretty close to pure functional programming.

From the summary, the old trucks get 8.2 mpg. So the new trucks are not worse. The quoted statement from USPS also said the new trucks carry more load, so fuel spent per package or pound of cargo should be better still.

You shouldn't send a hash of the password. If passwords are used, then send the password for verification, but on the auth server it will be used to create a one way hash, which gets compared with a stored value. The password gets sent over an encrypted channel like SSL. This reduces the chance of credentials being exposed from server-side hacks or data breaches. If you don't use passwords, you can use one-way encryption to sign communication and verify those signatures without a shared secret.

A lot of comments are critical of overuse of the clouds or AWS specifically. But for me it boils down to a couple of more specific issues that can be improved upon.

The first thing is within the customers' grasp: let's think critically about our system design in terms of third parties. The more consolidation there is in the SaaS industry, the more we'll see business' interdependence. In other words, if there is a really compelling offering for managed services that run outside your immediate control, there will be a ratcheting of probability that on any given day something in your product is broken. I know there's an age old truism about build vs buy: only build things that comprise your business' core competency and buy the rest. Authentication is a classic example. Use a third party IDP or SSO service and focus more on your own business logic. It generally makes business sense, but I think there needs to be a bit of thought given to the resiliency within our own products around these third party integrations -- can we handle this third party's outage, can we fail over or allow for a degraded experience for our end users without totally falling down ourselves? I think for Engineering departments, there's a job to do here to advocate design and advocate for a middle ground between total reliance on an integration and super expensive full redundancy or bringing all these features in-house unnecessarily.

The other issue is lurking within AWS: global services' dependence on specific regions. It looks like with at least one of the outages, we saw an outsized impact to AWS from some core functionality within AWS being wholly dependent on us-east-1 in particular. That feels counter to what AWS architects preach themselves. I recently talked with our CTO about this and he speculated that Amazon's culture of lots of small self-sufficient teams may be partly to blame. When you strongly incentivize individuals and small teams to perform at their best and forget some non-functional requirements, you may end up with this kind of tech debt build-up that bites you unexpectedly. Could there have been a reason for AWS web console to stay up despite us-east-1 having problems if it was designed better or if they put a bit more investment into its redundancy?

Instilling values is one thing,shutting down others' lawful commercial activity that doesn't comport with your values is something else entirely.

I work at an online marketing platform. We abide by the laws and keep an eye on industry trends and practices. Believe it or not, an opted out user is of very little interest to these people. Some spam houses may want big volume of any real deliverable emails they can get, but most real businesses want real customers or prospects, who show engagement. They don't want to send you emails you don't care for any more than you want to receive them.

Unless you're paying Facebook for the service, you're not a customer.

They do use XML: https://kb.ddex.net/

I haven't read every comment, but it looks like yet another rehashing of the same back and forth as in previous threads and it seems to be exclusively men sharing their thoughts. Do we not have any women on this forum? For the men participating in this, let's pipe down for a sec and hear from women, as the posting suggests.

Reality check: you're commenting about a specific real person you don't know anything about.

Intentionally blocking the way is obstructing traffic. Going slowly on a local road in the rightmost lane is not. Farming equipment is allowed on any such road and that stuff usually travels at roughly similar speeds as bicycles. There are not so many roads with actual minimum speed limit posted and only highways specifically restrict bicycles and farming equipment from them.

Google and XMPP are finished. I run a few apps on their cloud infrastructure and received notices from them warning of XMPP deprecation and all services that run on it. They're pushing some alternative technologies, but as far as their cloud services, 2017-11-01 is when they sunset XMPP. I assume their consumer services are already off it.

I suggest you track down source material and not constrain yourself to the news summary. The article links to the original BuzzAngle Music report for 2016, which mentions this:

If I remember this right, Oracle's grievance was that some of the Android source was shown to have come from non-GPL Java libraries. It's not just about the API, but the implementations as well. In light of this, it looks as though Google made a mistake. I doubt that it can be demonstrated that Google's actions caused $8B of damages to Oracle in missed business opportunities in the mobile market, which is what I think their case alleges. We'll see.