The carrier has been letting them down every single step of the way (and to add insult to injury, I have to use that damn "Shop" app to track the delivery.) From a pick up on the 1st of October, they've supposedly had the package go back and forth between Los Angeles and here a couple of times.

Not sure what the price difference is for them to have used this carrier, but it can't be worth it compared to the fuss both of us are having trying to get the carrier to actually deliver the shipped product. The vendor is going to send a second one if the delivery doesn't happen to day like the carrier pinky promises it will (they've promised for 3 days straight it was going to be delivered that day, so I'm not holding my breath)

Nearly 20 years ago I had such a wonderful debugging experience when the power grid where I lived sent a "switch to backup" message and then milliseconds later a cancellation. The colo's power system got jammed between generator and mains electricity and everything rapidly ran out of UPS backup power and died. I found so many dependency loops between servers that day, took me hours to get things back up and running.

I've found type hints to be remarkably useful and catch significantly more bugs than I ever would have thought, and have quickly picked up the practice of using them wherever I code. My general finding is that if I have to struggle to put useful type hints in place, I probably need to rethink my code.

I even type hint my unit tests because I've learned that sometimes type incorrectness means my tests haven't been testing what I thought they were testing.

Frameworks like pydantic[0] can help you turn those type hints into something runtime enforcing too.

[0] https://pydantic.dev/docs/validation/latest/get-started/

I've waded through unfamiliar code at 3am trying to figure out just why the hell things broke this time more times than I can care to remember, particularly trying to tease apart the ways that code has organically grown compared to the original intent. If I'm subjected to one more piece of "spooky at a distance" injected behaviour code I'll probably scream loud enough to be heard half way across the country.

It's still just leaps and bounds more readable than what people are slopping together (I do have some co-workers that have been extremely tightly focused on avoiding "slop" with their AI and doing a lot of tuning, and it's certainly preferable to the ones that haven't)

Your code used to be a masterpiece, so well crafted it's easy for AI to tweak and modify because you've got everything so logically organised and scoped... and now this is what you're producing? Hard to debug monstrosities that only an LLM can realistically bolt new features or tweaks onto, because it can do the kinds of refactoring necessary each time.

We use to talk about the fact that code should be readable because you spend more time reading it than writing it, but I think that misses the key part that readable code is also typically easier to debug. If you can read and understand the code, you can follow the logic when things are wrong in production, and you can more easily reason about the emergent properties of interactions between the complex systems that are involved.

It's down at the moment (Not sure if it'll return?) but Chat Jimmy[0] produced by Taalas[1] was powered by an ASIC running Llama 3.1 8B, and hitting 17,000 tokens/sec. It was amazing to use, you'd no sooner have hit enter than you had a full response back. I actually found its speed to be a problem for interactive stuff, as every answer got several paragraphs I'd then wade through, vs a model populating text closer to my reading speed.

I appreciate, there are differences between an 8 billion parameter model and something GPT-4-ish, but we're currently in the middle of a race between a half dozen or so companies to produce the next best frontier model, which requires their infrastructure to be dynamic.

We really don't always need newer better faster stronger models, there's quite a lot of room for "good enough" where getting 17kt/s at significantly lower power would be amazing.

[0] https://chatjimmy.ai/ [1] https://taalas.com/

At least in the later stages of life Sun sales folks were literally selling the company into bankruptcy. They'd find out what competitors were offering, undercut it to the degree they'd make a loss, just to get the contract and their sweet commission.

To not realise you've got this going on really speaks to how little they were interested in the actual running of the business.

2013-2014 would be about right, they were still in SEA when I joined in 2013 but were actively working on decommissioning it.

The amount of data S3 stores "automatically replicating" to other geographical locations would make things prohibitively expensive, especially when you consider the daily delta, and how much of that is ephemeral or frequently mutated data that is stored. The bandwidth costs alone would be eye-watering, let alone the storage costs.

S3 cannot make any automated decision about whether data is, or isn't important, and if they did they'd only open themselves up to lawsuits if they guessed wrong. That's why it's made an option for the end user to enable replication if they want to, or choose to replicate their own data.

They have a well deserved reputation for the quality and accuracy of their incident reports, and they don't pull their punches.

It'll be interesting to see the outcome of the NTSB investigation, they're usually quite thorough.

A remarkable own goal given that if they'd literally held their tongue, I'd be at worst indifferent.

I flat out guarantee they'll come away with a wildly different perspective of the things that need done, and the ways their service operates.

Ideally I'd want them to do a rotation in customer support so they get the small customer perspective too, and at least learn what kind of paper cuts they're inflicting on customers.