This works well for problems that are purely algorithmic in nature. But problems often have solutions that don't fall into those categories, especially in UI/UX. When people tell me that LLMs can solve anything with a sufficiently details spec, I ask them to produce such a spec for Adobe Photoshop.
The quality x price curve is not linear. Expensive materials and engineering often produce only incremental quality improvements, if any. Sometimes the improvements are only cosmetic. So Apple's headphones would need to be a lot closer to the best of the best than 80-90% in order to justify their price.
The feature that applies a hearing test as an equalizer setting make the APM sound pretty damn good, so much so it ended my 20 year long headphone-collecting hobby.
Before hearing-tuned EQ became a thing, trying headphones was like trying food. No matter what someone else said it was no guarantee you'd like the sound. Conversely, you might find a cheap pair that sounded spectacular to you. The APM will sound very good to just about anyone, with the hearing test EQ applied.
I think every headphone maker (or better yet, DAC maker) should have this feature. Audiophiles are often old, a hearing test EQ can make them hear music like they're 20 again, and they'll pay for it.
I think Apple is more responsible. One of Flash's chief benefits to the customers who paid the big bucks was that it 'just worked' everywhere. Once Apple stopped supporting Flash on the iPhone, that story was a lot less attractive.
The bugs were definitely Adobe's fault: as with most tech companies, they were far more interested in expanding the feature set than they were on fixing the bugs and stabilizing the platform.
The first iPhone had 128Mb of RAM and a 400Mhz processor and could barely run Safari. If you scrolled to fast you would get a checkerbox while Safari was trying to catch up.
If it couldn’t run Safari with decent performance, how was it going to run Safari + Flash?
In fact when Flash finally did come to Android in 2010, it required a 1Ghz processor and 1GB of RAM and it barely ran then and killed the battery. An iPhone with those specs didn’t come out until 2011.
Another anecdote is that the Motorola Xoom was supposed to to be the “iPad killer” because it could show you the “real web” with Flash.
But it came out without Flash because Adobe was late. You couldn’t even see the Xoom home page on the Xoom when it was first introduced because it required Flash.
there's an apocryphal story that when one of Apple's chips was nearing 10B transistors, marketing asked the chip folks if they could round it up to 10B for their copy. The chip folks were confounded, and said no they didn't have any uncounted transistors to round it up, and they didn't approve of claiming 10B transistors when it wasn't.
(This was a while ago. I see the M4 is at 28 B)
Which is why I'm all the more surprised that Apple would claim 2x more ANE TOPS than it can really does.
Does anyone know if the company is still active. Haven't seen any updates for a while now. I like the product a lot, but products like this need security updates at the very least.
Last release was November 2025 which isn't that terribly long ago. https://docs.orbstack.dev/release-notes. They do look to have stopped blogging on orbstack.dev for more than a year now. They have a discord channel, but I'm not up for dealing with discord to check on it.
I discussed approaches in my earlier reply. But what you are saying now makes me think you are having problems with too much context. Pare down your CLAUDE.md massively and never let you context usage get over 60-65%. And tell CLAUDE not to commit anything without explicit instructions from you (unless you are working in a branch/worktree and are willing to throw it all away).
Those kinds of errors were super common 4-6 months ago, but LLM quality moves fast. Nowadays I don't see these very often at all. Two things that make a huge difference: work on writing a spec first. github.speckit, GSD, BMAD, whatever tool you like can help with this. Do several passes on the spec to refine it and focus on the key ideas.
Now that you have a spec, task it out, but tell the LLM to write the tests first (like Test-Driven Development, but without all the formalisms). This forces the LLM to focus on the desired behavior instead of the algorithms. Be sure to focus on tests that focus on real behavior: client apis doing the right error handling when you get bad input, handling tricky cases, etc. Tell the system not to write 'struct' tests - checking that getters/setters work isn't interesting or useful.
Then you implement 1-3 tasks at a time, getting the tests to pass. The rules prevent disabling tests, commenting out tests, and, most importantly, changing the behavior of the tests. Doesn't use a lot of context, little to no hallucinating, and easily measurable progress.
Wrong. If you know nix then you know "leverages the unique way that Flox environments are rendered without performing a nix evaluation" is a very significant statement.
Yeah, it's essentially cached eval, the key being where/how that eval is stored.
When you create a Flox environment, we evaluate the Nix expressions once and store the concrete result (ie exact store paths) in FloxHub. The k8s node just fetches that pre-rendered manifest and bind-mounts the packages with no evaluation step at pod startup.
It's like the difference between giving the node a recipe to interpret vs. giving it a shopping list of exact items. Faster, safer, and the node doesn't need to know how to cook (evaluate Nix). I don't know, there's a metaphor here somewhere, I'll find it.
Only so much room for magic, for sure, but tons of room for efficiency and optimization.
Correction: we don't eval when you create environments.
Our catalog continuously pre-evaluates nixpkgs in the background. 'flox install' just selects from pre-evaluated packages -- no eval needed, ever. The k8s node fetches the manifest and mounts the packages.
Eval is done once, centrally, continuously. So... even more pre-val'd, so to speak.
reply