Recent submissions

Comment · 2 years ago
This presumes that it will be real humans that have to “take care” of the code later.

A lot of the people that are hawking AI, especially in management, are chasing a future where there are no humans, because AI writes the code and maintains the code, no pesky expensive humans needed. And AI won’t object to things like bad code style or low quality code.

Comment · 2 years ago
Electricity and water are things that we don’t mind (or even want) people using less of. The same can’t really be said for Spotify etc.
Comment · 2 years ago
Airbus A350s had the same issue: https://www.theregister.com/2019/07/25/a350_power_cycle_soft...

We’re just going to see more and more issues like this as more and more software is used in applications like this. I would be willing to bet that a Tesla would also spontaneously crash if left on for hundreds of hours, but they just rarely if ever are left on that long.

Comment · 2 years ago
There never will be an adequate industry-wide certification. There is no universal “good enough” or “when to stop” for security. What constitutes “good enough” is entirely dependent on what you are protecting and who you are protecting it from, which changes from system to system and changes from day to day.

The budget that it takes to protect against a script kiddy is a tiny fraction of the budget it takes to protect from a professional hacker group, which is a fraction of what it takes to protect from nation state-funded trolls. You can correctly decide that your security is “good enough” one day, but all it takes is a single random news story or internet comment to put a target on your back from someone more powerful, and suddenly that “good enough” isn’t good enough anymore.

The Internet Archive might have been making the correct decision all this time to invest in things that further its mission rather than burning extra money on security, and it seems their security for a long time was “good enough”… until it wasn’t.

Comment · 2 years ago
None of what you just said about US law is relevant here. Yes, Cloudflare has to abide by international law where it operates. This is established and every company across the globe is subject to it.

Cloudflare operates in and has a physical data center presence in Moldova, serves content owned by Moldovan citizens, and serves content to Moldovan citizens. Thus, they are subject to Moldova law. If they don’t want to be subject to it, they can remove their operations from the country and remove any interactions with Moldovans.

Comment · 2 years ago
If us-east-1 ever suffered a “FULL” data loss, it would be a company-ending event for so many companies that it would practically end society as we know it.

OVH’s failure was a single building. That’s the problem with a lot of server hosters - even Google has their availability zones all co-located in the same building, so a physical event like a fire could take down an entire region. AWS has AZs in physically separate locations, each with 1+ separate DCs.

Comment · 2 years ago
> AWS ProServe never had a RTO mandate

Before Covid, no team had an RTO mandate, so ProServe wasn’t really special here. In ProServe you were still expected to be in an office regularly, but it was just understood that you wouldn’t be in an Amazon office all the time because you’re likely at a client’s office instead.

Post-covid, it’s mostly the same, although now even many clients aren’t requiring consultants to come in. But when they do, you’re expected to be there.

Comment · 2 years ago
This undersells the fact that there’s a lot more to infrastructure management than “janitoring”. You and many others may want to just say “here’s my code, ship it”, but there’s also a massive market of people that _need_ the customization and deep control over things like load balancers, because they’re pumping petabytes of data through it and using a cloud-managed LB is leaving money and performance on the table. Or there are companies that _need_ the strong isolation between regions for legal and security reasons, even if it comes with added complexity.

A lot of developers get frustrated at AWS or Azure because they want to deploy their hobby app on it and realize it’s too difficult dealing with stuff like IAM - it’s like trying to dig a small hole in your garden and someone suggests you go buy a Caterpillar Excavator, when all you needed was a hand trowel. The reason this persists is because AWS doesn’t target the hobby developer - it targets the massive enterprise that does need the customization and power it provides, despite the complexity. There are, thankfully, other companies that have come in to serve up cloud hand trowels.

There is no “one size fits all” cloud. There probably never will be. They’re all going to coexist for the foreseeable future.

Comment · 2 years ago
You’re completely off the mark here. I’ve worked at a Big4 company before on reports like this. These reports aren’t paid for by other companies at all. They’re internally funded and done by the internal research teams. The motivations behind them are numerous: marketing, having artifacts to help rank at the top of stuff like Gartner reports, and even because believe it or not the people that work there sometimes genuinely enjoy researching and publishing reports. Reports like this are the consulting company equivalent of a tech company’s engineering blog bragging about their new scalable infrastructure or whatever.

If you see a report published by a company that says “PwC did research for us”, then yes, it has likely been influenced by that company. But a report like this that is entirely PwC branded is not that.

Comment · 2 years ago
Can we not do this? Everyone knows that “serverless” doesn’t actually mean there are no servers. It’s not productive to do this “haha gotcha!” trope every time someone uses the serverless term.

Serverless refers to the fact that you can launch individual workloads on the platform while abstracting away the underlying infrastructure. Yes, to set up dokku you still need to provision a server. But to deploy an application onto dokku after it’s been set up, you do that without worrying about provisioning new infra for your app. That’s what is “serverless” about it, and it’s a perfectly acceptable use of the term.

Comment · 2 years ago
> whether I'm managing 100 of the same thing or 1,000 - if I've built proper automation my only additional overhead is replacing failed hardware

Hahahah surely this is a joke, right?

If it’s so easy and you already had solved all these problems, why didn’t someone already build it? Why didn’t you build EBS, since you apparently have all the answers?

Comment · 2 years ago
Ah, yes, my original comment was a little unclear. I actually wasn’t logging in on new device vs existing device, it was that I had logged in to one device before 9:30est (presumably before the surge began) and just had an existing already-logged-in-session.
Comment · 2 years ago
It’s the largest trading volume day in years and everyone that isn’t living under a rock is trying to log into their banks to check their portfolio. The banks can’t handle the surge logging in.

It’s not that suspicious. Not everything is a conspiracy.

Comment · 2 years ago
I’ve been a Schwab user for years, and was a TDA user as well before the merger. TDA had just as many issues like this. Don’t let your recency bias fool you.

Schwab is overall a great bank and brokerage. Fidelity’s user experience quite frankly is much worse, as is E-Trade’s. Vanguard is even worse than those. IBKR looks nice, but the hassle hasn’t been worth it to me. Schwab has been great for me so far.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton