Hacker Newsnew | past | comments | ask | show | jobs | submit | WinstonSmith84's commentslogin

Well, regardless of the drama, the interesting part on Anthropic vs OpenAI is:

- One of the two main persons work at Anthropic and "almost" or "partially" solved the issue, but eventually didn't succeed

- An external person with just an excerpt of the chat and certainly less versed in Mathematics (than these 2) tackled the problem.

There is little doubt that OpenAI is so much ahead and maybe the gap is even larger than what we see on Astra vs Fable.


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.

https://www.dxomark.com/smartphones/

We aren't sure when the first Motorola folding devices we can support will be released, but that will happen.


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.


Fable does far better at considering the whole picture, weighing options, and making suggestions during architecture or refactoring discussions.

It’s more reliable and makes less dumb errors than Opus.

It still messes up, of course. But for my working style, I definitely prefer it.


Exactly. Use Fable to draft the plan and make decisions. Less capable models to implement the plan.

That said, Opus 5 is broken. Use 4.8 or another vendor for the build agent.


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...

By the way: https://x.com/alexcdot/status/2087078010524406137


What am I missing in Zed is actually a "File History" - like in VS Code, which keeps a history of every time a file was saved to the disk, and it's very easy to review that history.

Now this DeltaDB goes way beyond that


it depends on how you see things. By default OMP with all its options turned off is very much like Pi, just with a better UX/UI - and - a faster start, somehow. And you can turn things on when needed. I see people like Pi because it's super skinny and they can tweak it with extensions A, B or C. I like OMP because I don't have to spend time figuring out the next best thing while there is a guy out there who knows (more than me) what he is doing and packaging all the good stuff into his app. Yes it's opinionated, but I use regularly half of the installed extensions - and occasionally play with other features too.

But I can agree on a thing: the best for OMP would be to have a clear "list of extensions" that can be activated or deactivated (to unclutter the menus)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: