Peak Tech Salesforce was 2010 +/- 2 years - i.e. after Visualforce and before Aura era. It used to be a developer oriented platform and it became shiny/flashy garbage eventually. But all these shiny things allowed them to get a large market cap with very brilliant sales people, it's hard to deny.
Aura existed simply because Salesforce thought to be smarter than open source, well. Can't deny it though: Salesforce engineers were great on the backend, but frontend dev has never been their thing. Back then there was Angular 1 which was miles ahead. React was released shortly after Aura itself, so to say. LWC is what Aura shall have been 10+ years ago. And that ties back to what OP wrote: awful UX extremely slow bloated with JS.
Now, don't talk me about VSCode Extensions. This is the perfect example of an awful dev experience. apex-jorje-lsp.jar with a JVM to parse Apex taking GB of memories, extensions taking dozens of seconds to load (when they load) ... In fact, the only decent LSP is aer, a simple decently working Go binary rather than the monster Salesforce shipped. The one good tooling Salesforce built in the last 15 years is, to some extent, the SF CLI - which came after the `force` CLI from the same guys who built `aer`, anyway. And nowadays, people can use that with their preferred editor from Zed to Vim with shortcuts from built upon the SF CLI.
So no, Salesforce didn't do great with tooling, they just did the bare minimum waiting on the (small) community to give them the right ideas.
To be fair, they came in with some requirements that I don't think anyone else had at the time, and even today aren't in any mainstream ones afaik.
I think the biggest difference was around providing security and stability barriers between front-end components on the same page, with the intent of allowing you to compose a page that contains your own components and those of other third party applications you've installed with guarantees about how they can (and can't) interact. Not sure they couldn't have tacked that onto another framework, but it comes with enough trade-offs and compromises that I'm not sure anyone else would have wanted to upstream it, so they would have been forking something anyway.
Aura wasn't much fun to work with, was never really feature complete, and not advocating for it... but it actually kind of made sense if you thought about front end with the context of how salesforce did security and multitenancy in mind.
I think around 2012 there was not a lot of options for an enterprise rally around. Aura was designed and built in the same timeframe as react/angular/ember/etc iirc.
The US-Iran war is very unpopular and it's not even that the US is winning it.
Going against Canada would mean .. what? Having tanks roll in Toronto downtown? Assuming it would be a military success, which isn't guaranteed after what happens in Iran,that would be unpopular beyond anything we've seen.
Tough words, that's the worse we may expect from the US gov realistically.
It's a two way street; sanction on big tech is also the big weapon the EU has against the US if need be and that we kept threatening but never activating.
Which doesn't mean it's easy or won't hurt like hell, but this is a continent that just cut most of the gas cord lines in record times despite massive pain and cost, if it came down to it we would simply because if it comes down to this and we don't then we're done.
Short time it would damage us pretty hard, but long term it would be another net loss for the US.
From what I read about what they wanted Canada to sign (the "new deal" Canada walked out of), they want to give them strict conditions and no abilities to make new deals with someone else to make them fully dependant. So the goal was not really military conquest but economic stranglehold. All the while apparently asking to tone down their minorities including the french one.
There is an alternate timeline where Canada signed that, and it looks much bleaker for them down the road.
I recommend that you read the linked PDF before drawing any conclusions.
This is sort of a weird interpretation:
> One of the two main persons work at Anthropic and "almost" or "partially" solved the issue, but eventually didn't succeed
- It wasn't an Anthropic endorsed effort.
- Solving this class of problem means a march of progress A -> B -> C -> D. If a student turns in a test that jumps from A -> D without showing any work they're either brilliant or cheating (probably cheating). Further, each step of progress isn't the same proportion of effort. What if moving from C -> D was actually the smallest contribution and just required a novel perspective to make the breakthrough.
This part is wrong:
> An external person with just an excerpt of the chat and certainly less versed in Mathematics (than these 2) tackled the problem.
- it was a whole team at OpenAI working on the problem
- it wasn't a chat excerpt, it was more like their entire git repo and project progress reports
Often with a hint on how to solve something, solving it is much much easier. It seems like that's what happened here.
Very weird behaviour from OpenAI, offering partial credit to on person, but not the other person involved. Trying to bully the mathematicians involved (see threats quoted upthread).
I suppose it's the sort of amoral behaviour we've come to expect from them.
Motorola doesn't have a great track records for flagships smartphones. I will keep finger crossed that we won't have to choose again between security and features but either way it's a great news, and I truly hope that GrapheneOS will be adopted by more manufacturers in the future
Motorola Signature (2026) was well received. They committed to 7 years of updates and provided top tier smartphones cameras which were previous limitations. Razr Fold (2026) has the top rated camera for a folding device on DXOMARK, unlike the huge camera downgrade for folding Pixels.
One detail that remains to be seen is whether you'll cater to the EU market, and how the impact of the memory crisis will impact the possible consumer-base. It's a weak market and sales are likely to be only the 'hardcore' users who demand/require security. I sincerely hope there are no numbers you need to hit to keep the partnership going. Sales are not likely to be at first significant, people are extremely price sensitive and I'm not sure GrapheneOS support will draw people in enough to justify the obviously now inflated costs to cover component price increases (and tariffs).
Pixels offer affordable options which is why unless you can cater to that market, a Motorola-only GrapheneOS future will only gain traction if you're able to get a cheaper low/mid-range option out there, akin to the Pixel A-series.
Much of that is out of their hands unfortunately. Motorola don't use the latest Snapdragon SoCs in most of their more affordable models, and Qualcomm are the only ones so far (outside Samsung/Google) who seem willing to support what is needed (MTE, Android SE imp etc.)
I don't understand much from MTE/Android or MIE/iOS but the explanation is also confusing when:
- They claim Apple did a great job integrating MIE in iOS
- iOS doesn't encourage to opt into MTE ... Apple's docs warn developers of performance and stability issues
So it seems like even for iOS, this special security feature is only available for Apple own iOS app (at most?).
Then also:
> Even Signal doesn't opt-in. Our approach enables forcing using MTE in the standard allocators regardless.
So does that mean that Signal and any other apps are enrolled in MTE on Graphene?
iOS uses MTE for nearly all of the important parts of the OS. It uses MTE within the kernel and for a substantial portion of the base OS processes. They focused on deploying it to the most security relevant processes first but it's deployed for a large portion of the OS beyond those. Apple has done a very good job protecting the OS with it. They've done a very poor job getting the app ecosystem to adopt it.
Android has more app ecosystem adoption than iOS due to having a better open source app ecosystem where GrapheneOS users have asked apps to enable it by default. Many GrapheneOS users are also force enabling MTE for user installed apps via our recommended toggle for it. Those users are reporting invalid memory access to developers via our dedicated notification system for invalid memory accesses it catches. For Android app developers, not opting into MTE doesn't mean their app won't be used with MTE due to GrapheneOS.
GrapheneOS uses MTE for the kernel and nearly every userspace process including all the base OS apps. We've had to fix many upstream Linux kernel and Pixel kernel driver bugs found by MTE. However, we aren't trying to fix the Pixel userspace drivers code ourselves so we have a few userspace processes excluded from MTE caused by userspace driver library/service bugs.
We recommend users enable our toggle for enabling MTE by default for every user installed app not explicitly marked as incompatible in our compatibility database. GrapheneOS has user-facing notifications for invalid memory accesses caught by MTE providing a traceback to share with the app developers. Users can use the per-app toggle to work around it if it makes an app unusable. We take the same approach for other aggressive exploit protections provided by GrapheneOS. Exploit protections with only rare compatibility issues are enabled by default for apps with a per-app toggle to opt-out and no toggle for the global default.
I see a significant difference between making a security feature available but opt-in during a teething phase, and removing the feature altogether. Am I missing something?
Agree, but the point is not because Fable is better than Sol, it's because it's .. different .. it just looks at the problem through a different angle.
I wish Fable were as good as you make it sound. A plan created by Fable is good, but in my case, it always contain issues caught only when it's reviewed again (whether by itself, Opus, Sol etc.). That's (almost) not different from plans created by Sol, GLM 5.3 etc. The one thing where it's genuinely better is the front-end, but then again it's far from perfect, it just needs less iterations.
>> but in my case, it always contain issues caught only when it's reviewed again
Yes but those issues will be much less severe with Fable-written plans than those written by lesser models. I know this because my workflows at both my regular job and my startup involve multi-step agent reviews via codified adversarial review skills. Fable as a reviewer will frequently find blocker-level issues with plans written by GPT 5.6 Sol, and sometimes with Opus 5. The opposite almost never happens. In fact I cannot remember the last time it happened.
Because that would reveal their edge to investors, or the lack thereof.
If Fable turns out to be a 10T or 20T model, there is little to boast vs Kimi at 3T. But the opposite is true: if Fable were to be e.g. a 500B model, that would show how far ahead they are from the open models. This isn't likely to be the case ...
I guess there's also the economic aspect. It would make it much easier for competitors to figure out your costs and margins if they know the model parameter sizes you operate.
Yes. And Opus goes a very long way compared to Fable, Anthropic isn't doing any favour, it's clearly just 2 models with a very different amount of parameters.
it's going to be easy to defeat either way, like SynthID is. From apps built to remove the watermark, to simply rephrase the work with an Open Model...
reply