aq9

AWS support (even Enterprise support) was always hit and miss.

At least with Enterprise support you can yell at your TAM, which sometimes is less effective than you would think, considering the price.

Interesting yes, but surely not "Disastrous", all the men from the Endurance survived. Now, Scott's expedition was a disaster.

This is silly though. For an IT company, what should the #2 cost be? Legal? It is an IT company....

The "old" british standard is even cooler: https://www.plugsocketmuseum.nl/OldBritish1.html

As a South African (living abroad for many years, but still with the bulk of my extended family there), this seems overly alarmist. If you review https://en.wikipedia.org/wiki/South_African_energy_crisis , very few consumers experienced anything like 50% of total hours without electricity even in the darkest days of the load-shedding in 2023. And 2024 was, comparatively, a good year, probably the best since 2020/1.

RE the police force and private security, that has been a fact of life in South Africa for decades, not a new development. Anyone with the means employs private security, in the same way that anyone with means utilizes private health care, not public health care. Here South Africa is not that much different from other high-crime and high-inequality countries like Brazil and Mexico.

As long as the amounts are small, and from a variety of cards, no normal (real) card processor is going to notice/care. Cannot speak for Stripe.

More recent analog: https://simpleflying.com/tupolev-tu-22-booze-carrier-why/

84 hours/week is for amateurs. Call back when you hit 100 per week consistently.

I have used one of the original 4k TVs-as-a-monitor ( https://www.avsforum.com/threads/review-of-the-seiki-39-4k-d... ) as my central monitor (plus one on each side) for 10+ years now. Not feeling any need to upgrade (don't do graphics/games, just lots and lots of text terminals and browser windows)

All of them?

What do you mean? Prices are going up. Costs have been falling since AWS was introduced faster than they have reduced prices. I am willing to bet that their gross margin is higher today than it was last year, 5 years ago or 10 years ago.

Interesting question. Here is my take (I have both a consulting and infra/data background):

* Yes, many companies need the help.

* However, they typically (not necessarily unfairly) have a dim view of consulting/consultants.

* They can't (or won't) prioritize stopping or slowing down feature development to make the infrastructure changes that will lead to significant improvement. Often the potential solutions are actually either known or obvious already.

* In systems of appreciable complexity, it can take a significant amount of time for a consultant to examine all the moving parts to come up with a good/reasonable set of recommendations.

* So, as a result, consultants are often only brought in when things have deteriorated to an extent where it really hard to help. One other case is upon change of control (company is sold or acquired); this might be a better point to implement change.

* Lastly, knowing what needs to be done is one thing; actually implementing the necessary changes "on the fly" is actually the hard(er) thing. Often the company's team just don't have the skills to do that. Accordingly the best results are often when you can bring in a team to both consult and help the team through the implementation/changes.

A Mac plus docker would have been fine a few years ago, but now with Mac arm64, things are getting complicated again. Stick with a decent Intel laptop + linux for now, unless you really just mostly use "user-side" stuff (i.e. not containers, linux, etc.)

Let's be honest: if no-one (higher up) went to jail after 2008, it is not likely to happen this time.

"Tim Cook... hasn't had layoffs". Yet...

See the original at: https://archive.org/details/Esquire-Magazine-1983-12/page/n1...

There are recruiting companies that have been using AI bots for (at least) 3 years. I am not going to name names, but I have used one as a hiring manager in the past to fill openings.

Close, I think.

Context: I looked into uptime monitors quite deeply about 10 years ago when I thought about doing a SaaS.

Implementing a good uptime monitoring system is actually more complex than you would think from a technical perspective (dealing with network splits which could be the result of your network or the target endpoint's network, so you need to triangulate continuously between multiple network sensors).

Actually, something like pagerduty is even simpler from a technical perspective; but as a business, is probably a different story.

As someone who has been in both tech IC (individual contributor) and higher management levels, this is often a relatively simple result of impedance mismatch (excluding bad faith individuals for now):

ICs and lower level managers are all about inputs and outputs, blocking and tackling, getting shit done.

At the higher management levels it is all about setting direction, setting the "tone", "getting the culture right".

There is just so little concerns that intersect between these groups, that communication becomes a challenge.

I think this is the wrong way to think about it.

For the type of organizations that run workloads on IBM mainframes, there are three drivers: * Legacy: The application was written for the mainframe, cannot run on anything else, too expensive in terms of dev and test time to re-platform * Business value: This is the big one; these workloads make their companies 100s of millions to billions of dollars per year. The price premium for running this on a mainframe is a rounding error. * Reliability: With the cloud, I hold the opinion that the average x86 application is less available/reliable than a well-run pre-cloud application (which already included HA, etc.). Mainframe apps and hardware blow all this out of the water.

FWIW: I programmed mainframes briefly early in my career, I am quite familiar with the ecosystem.

Shaka, when the walls fell.

You need to qualify massive scale, it can be on multiple dimensions: * "Large" data (these days, 10s of TB of data, maybe with multi-TB individual tables, billions of rows in the large tables) * "High" QPS - reads * "High" QPS - writes

High QPS is in the eye of the beholder, but let's say something like a few hundred thousand QPS and up.

If you have scale in just one of these 3 dimensions, the solutions are relatively easy (except maybe for high write QPS, depends on the nature of the writes). If you are at scale on all three dimensions, solutions get harder (sharding, non-innodb storage engines).

Of course, there is also the wildcard: the nature of your queries/transactions. Large transactions along with scale will make your life a living hell.

Not always, and not if they are competently planned and executed. I will grant you that, in the current climate, that they are probably not competently planned nor executed.

https://layoffs.fyi/ is the more up-to-date spot for this info.

It's a shame fuckedcompany.com is not around anymore. We miss you, Pud.

To be fair in the comparison; you can also query (via curl) icanhazip.com via HTTP instead of HTTPS, and it is only 5 packets and 385 bytes.

Dover is a YC company; this is a YC company jobs ad. Don't think there is anything new here.

So, a lot would depend on what you plan on passing the protobufs over. Plain TCP? gRPC? gRPC kinda sucks for this, the serialization/deserialization can be moderately expensive (CPU); and gRPC's multiplexing of multiple flows onto the same connection can be hard to reason about (i.e. debug); and the performance characteristics are not great either.