I recently attempted to get on Azure because of their startup package, and I fail to understand how Microsoft holds anything together at all.
Docs are a mess with contradictory information, coordination between teams is a mess, azure UI is a mess. My support agent that was assisting on my PAID support went on vacation with no one to take over the case, and month after, after I asked for any sort of timeline (you have to actually nudge them, otherwise they won't ever communicate), I was told they couldn't fix the issue on their end and I have to create a new account, because my account was stuck in some sort of limbo where they can't see the state of it and their engineering couldn't figure it out.
The process I went through reminds me very much of Bill's internal thinking here.
> But no, let's in fact choose the stupidest possible way of doing it — by rendering everything as HTML commit by commit and then parsing it.
This drives me crazy with so-called SOTA LLMs that have "achieved AGI".
Fable, Sol, Astra, will start by trying to reverse engineer a binary to figure out how something works when software is open source and one search query away.
You let them know it's open source, and they will start using github API instead of just cloning and grepping.
Yes. See LongMemEval, LoCoMo. Tons of research here.
But precision/recall is relatively "solved". What nobody has gotten close to solving is maintenance and provenance - what goes into memory, what qualifies as truth, how stale memory gets invalidated/superseded.
We're now in the phase of re-discovering 30+ years of pain of knowledgebases.
I now have dozens of projects where I've embraced the yolo. I went through elaborate systems, workflows, review triages, architectural linters, specialist agents, yet, they all still suffered the same fate - slop which I don't understand and now LLMs don't understand either.
The only thing that worked was a standing instruction and periodic system reminder injected from the harness:
"If any assumption doesn't hold, if there's a fork in the road, any architectural decision needs be made, STOP and report back to the user. Do not try to push through the problem."
This has worked remarkably well for me. Now I have to think a whole lot more. It's much slower, yes, but I don't really see any other way that doesn't end up in garbage.
I don't know much about RCS other than that carriers need to be involved, but there's a way to not involve them, which Google did for a while using some kind of compat-service (jibe or something?), and then they stopped doing it.
Never seen RCS working on any carrier ever since. I don't understand why Google couldn't just continue doing what it was doing. Why require carriers?
The intended purpose of RCS was to be federated between carriers, just like SMS. If you centralise it then it's just a worse version of any of Google's abandoned chat apps. But there's a realpolitik reason to insist on centralised RCS: because it's already got the reputation of decentralisation, it makes it look like Google is better than it actually is.
Did SMS fail? Sort of, as it's rarely used, but also not, because it continues to work and it's still the only federated messaging system you can rely on being available on your phone (besides phone calls).
SMS was a huge success. For a standard that was defined in 1986 and first rolled out in 1992, it had good longevity and was extremely popular from its introduction until ~2010 [1]. Nearly 20 years is a good run for a technology in a rapidly evolving field. It was also designed in a completely different age when most phones did not have cellular internet and carrier support and federation were the only way to provide reliable person-to-person messaging. Even though the carriers probably dream of reviving SMS as RCS to be more than just pipes for the internet, those days are over.
Google-based RCS is Google coopting an existing standard to get the foot in the door for Apple Messages interoperability. By coopting a standard (rather than pushing yet another Google messenger), they could convince regulators to push Apple towards supporting it. Otherwise RCS is completely irrelevant and if it weren't for Google, it would've been mostly dead.
[1] Yeah, I realize that is was probably used in the US much longer, but that's when it started to dwindle in the rest of the world, where MMS also never really took off.
I do RE mostly, and they do lock up for me. But what works for me is: warm up context with non-RE things with American models > switch to GLM 5.3 with actual request, let it fill context with some RE work > switch to American > switch back to GLM 5.3 and keep switching back and forth if anything gets flagged.
Solves the guardrail problem - check
Feeds China data to US - check
Feeds US data to China - check
But I think OpenAI has caught up with this, and it's why they're pushing so many things server-side and encrypt it (subagent messages, compaction, new context history thing).
Docs are a mess with contradictory information, coordination between teams is a mess, azure UI is a mess. My support agent that was assisting on my PAID support went on vacation with no one to take over the case, and month after, after I asked for any sort of timeline (you have to actually nudge them, otherwise they won't ever communicate), I was told they couldn't fix the issue on their end and I have to create a new account, because my account was stuck in some sort of limbo where they can't see the state of it and their engineering couldn't figure it out.
The process I went through reminds me very much of Bill's internal thinking here.
reply