Hmm, I remember when Ars Technica macOS reviews were the gold standard. This one isn't bad, but I miss having more in-depth information about the improvements.
In my opinion, the details here complement the Ars Technica article nicely:
Agreed. While Andrew's done an okay job stepping into some big shoes, I too miss the reviews John Siracusa used to do for Ars. Same could be said for a lot of the old internet when you had people like Siracusa, Anand Lal Shimpi at AnandTech among others, providing very detailed deep dives on the latest technology.
On my short tests: This model is amazing and the speed makes it feel like another sort of AI.
But it's bad at code reviews (maybe it's the harness agy cli?). Could not get it to same quality level on reviews like Opus, GPT 5.6, Grok. Even tried special code review skills but no luck.
wait for it... I can see a future were every wallet, payment etc. app will block devices which are on custom ROMs and do not pass strong hardware integrity with blessing from Google.
I've read once that there are paid app testing labs which test if an app has root and custom ROM detection and when they don't have that it's a minus point on the report.
All the big boy AI stuff runs on servers, which certainly aren't going to be running on Windows or Mac anytime soon. Linux _is_ what all this NVIDIA hardware is going to run on until... what exactly? FreeBSD overtakes Linux in the server space?
> Who knows what i sthe next big thing after AI. Maybe something that doesn't need Linux?
And Nvidia hardware was running on Linux before AI as well...
> And I'm not so sure that Mac is out of the equation
Mac servers exist but anyone serious about running at scale isn't using them for a number of reasons, not least of which is that Apple simply doesn't make real servers anymore...
They have the money they have the capability design and engineering in house and they are vertical. The question is whether or not they have the will, one thing that might help them come to a decision is that they now have an engineer CEO from the Apple Silicon, part of the company and not a bean counter.
very rarely use more than 4–5 per project. Maybe I'm just avoiding wrapping my head around worktrees and actually trying them out.
Benefits: These clones act as semi-permanent directories:
- Helps with caching for heavy Docker usage (think of repeated parallel unit, e2e tests)
- I've color-coded my terminal tabs for each clone so I can instantly tell where I am at a glance (kinda like tab groups just with colors)
Maybe if for some reason I need double digits clones of a project I will be more forced to use git worktrees because then it will be annoying to remember in which directory a branch clone lives.
this is basically what worktrees do, though? except git 'knows' about all the associated branches, so you don't have to deal with pushing/pulling in order to merge xyz branch, etc.
The main issue with worktrees is that you can't have the same branch opened in multiple worktrees which makes many things harder than the ought to be. I don't really understand why we need that limitation, otherwise the tooling is good enough.
JJ workspaces don't have that limitation. They do limit you to not having the same working copy commit opened in more than one location, but that's not particularly restrictive with JJ since you're probably squashing changes from the working copy into a permanent commit anyway.
The article said that a "limitation" of worktrees is that a branch can only be checked out in one worktree at a time- however, this seems like a feature, because if you could have several worktrees each with their own overlapping sets of branches then surely that would be equivalent to many git clones?
But yes, personally, in my ignorance, I shamelessly git clone the same repo many times.
I'm also stubborn. I clone multiple copies of the repo. I'm currently at two at my job right now, because I was trying to vibe-code an E2E test suite.
I'm probably missing something that people see as a huge advantage of having multiple streams of work large enough to require a long-running branch. I just finish working on the current branch and then switching to another branch. If work can't be accomplished and merged into `main` within a small amount of time, I'm almost certainly doing something wrong.
I just wonder how they handle full Google's certification for hardware integrity + Google Play Store with GrapheneOS. They contradict on this part on the normal GrapheneOS mod and I don't see a way how they will not on Motorola phones.
Banking apps (e.g. Revolut) block GrapheneOS actively and many other apps too.
But it will be interesting times once they are out!
> Banking apps (e.g. Revolut) block GrapheneOS actively and many other apps too.
You've misunderstood something here. Revolut doesn't "block GrapheneOS actively". I'm running Revolut and most of my banking apps on GrapheneOS right now.
In my experience, there are two major categories of incompatibility:
- High levels of Google Play Integrity checks: app only works on releases of Android that have been allowlisted by Google. The only app that does this for me so far is McDonalds.
- Commercial root detection APIs: some of GrapheneOS' security features like "Secure App Spawning" trip root detection heuristics. This is the kind of incompatibility I usually run into for banking apps. You can disable individual features on a per-app basis these days to get around this.
reply