Just because we don't understand or know about compilers or able to read their output does not make them fungible.
In old days we chose between Turbo/Borland C, Quick C and GCC. We didn't think them same or trust blindly even if we didn't know how they worked.
The best developers hand optimized assembly for sub routines which they knew compilers were not good at, the rest of us sure didn't understand how any of it worked, but nonetheless felt the differences and chose with dollars and usage .
Part of what I’m getting at is exactly your point that we used to think about what compiler to use and didn’t always blindly trust them.
If you have enough tests at what point does AI rewriting software in a different language become close enough to ‘deterministic’? Maybe never, maybe not.
Microsoft. It more than compensated for Azure not being the best product . They are incredibly more responsive, you have multiple points of contacts and escalation chain of actual humans you can meet
they will even come to your customer call or connect with their rep already working with the mutual customer and so on.
AWS has the best tech and but not as good as Microsoft service wise, they certainly improved a lot last few years and it shows but because they don’t have any enterprise apps like MS their footprint is more limited.
Google keeps talking about GCP being important but doesn’t feel anything has changed on ground
My company also used all 3 (at a very large scale / spends). MS was nice, but useless / incompetent technically. Anything non-trivial took forever to get a straight answer or resolve. We rarely got to speak directly to anyone with real expertise.
AWS, we could speak directly to Sr engineers on the relevant team. Full transparency, highly responsive. They were clearly trying to understand our issues and suggest change for both us and themselves.
Google was mostly useless. There was one team I got to talk directly to, who were great. But that was the exception.
My experience with AWS hasn't been good when we had major problems in redshift becoming unresponsive. Since it was an intermitent issue and not a full blown blackout they just shrugged and we kept having problems for months.
I can confirm. Redshift support is mediocre even for a F100 firm with TAM support if the workload is large and complex and you have some needle in the haystack causing problems like you allude to.
Practically speaking keeping an eye on locks and transactions is a good idea, as is watching out for your statistics on key core columns going bad when they shouldn't. (analyze and vacuum sometimes don't actually do anything when you need them to...)
It is much worse than that. Even taking the node names at face value[1] that is just one dimension, there are two/three[2] dimensions to consider so it would be 100x different.
Nehalem(2008) was a 45nm node based chip and had ~3MTr/mm2 transistors in comparison today we have 3nm(N3E/P/X/C) nodes(2023-4) from TSMC area about 220MTr/mm2.
Of course that is just one metric- transistor count, there are many other improvements to consider over the last two decades.
They don't even notice it happening, it is not a conscious thought not to fix it.
Empathizing about problems you don't face is a hard product/ux and management skill. Facebook famously simulated 2G on Tuesdays 10 years ago[1] for example to get their employees to see the problems their users have.[2]
People don't to put effort in noticing(solving comes next) problems they don't face. It is why things like a11y and i18n need regulation like ADA etc.
lol wish Bloomberg was that cheap . Last time I renewed It was like 280/yr and retail is like $35/month.
Still probably worth it , financial news publishers generally have less bias[1]/sensationalism than general broadsheets. Bloomberg/FT have been by my go to for factual news without too much hyperbole , click bait.
[1] There will be pro-business bias of course which in US these days I think as outside the political spectrum , both parties have very bad polices for businesses or labour.
It was also a different market in 2024. Much more fluid private credit industry, deal volume was much higher[1] and under very different interest rate regime[2], also generated music was just getting somewhat decent and the risk probably wasn't being factored in to long term value yet.
[1] The Queen deal came at end of series of high profile catalog acquisitions all 500M+ buys - Springsteen, Jackson(half), Bob Dylan.
[2] Interest rate while high was trending down and widely expected to even reach to pre-pandemic levels in few quarters.
I don't think hot patching holds the same relevance it did in 2010.
Much of today's workloads are containerized and run on roughly ephemeral nodes that can be switched out easily- K8s version upgrades force this more or less. We tent to run more and more of-the shelf hardware and worry less about individual node failures now.
In-memory updates also not magic , and can be limited as they requires data structure semantics to not really change and can create its own class of issues/bugs including security ones.
While am sure there are still use cases which dictate this type of update, the need is lot less than 15 years ago that the patent expiry will do much to the ecosystem.
That’s still a minor part of the overall Internet. Small orgs are still using traditional hosting which who knows how often are updated. I’ve seen clients sites running on managed servers that are a few major versions behind.
The small orgs using traditional hosting are not the workloads which would consider in-memory update paths ?
Typically when shops like this do scheduled updates they will happily announce downtime, it just not business critical to have zero planned downtime and also lack the skill / budget to evaluate if a given patch can be applied in-memory or not.
The overlap between those using simper setups you say and those who need in-memory updates doesn't exist?
In old days we chose between Turbo/Borland C, Quick C and GCC. We didn't think them same or trust blindly even if we didn't know how they worked.
The best developers hand optimized assembly for sub routines which they knew compilers were not good at, the rest of us sure didn't understand how any of it worked, but nonetheless felt the differences and chose with dollars and usage .
reply