Shebanator

Model sizes aren't directly comparable, and they aren't even that relevant. I care about result quality, cost, and speed, not size. I switched to deepseek because it was giving me better coding results than GLM, and for far less cost. GLM is still better at planning.

Couldn't agree more. Using a screen reader is an incredible learning experience, and it really teaches you just how extraordinary people can be: its incredibly difficult to get anything done. And then there are the people with motor disabilities, the deaf, and on and on.

I got interested in accessibility some 30 years ago, when I got to visit the lab at University of Washington. Its unbelievable the progress that has been made. And AI is having a huge positive impact as well.

I'll also say that if you can get a chance to go to a place like a google accessibility lab for a demo or even better watch a live usability test with disabled users, do it!

NixOS is not a read only OS. There is an impermanence addon that can do this, though, for many partitions.

This problem has been around for a long time. Not only that but it would say this even when the problems were directly caused by their code.

I put a line in my CLAUDE.md that says "If a test doesn't pass, fix it regardless of whether it was pre-existing or in a different part of the code."

Exactly: it depends on what you mean by "better". OS/2 had a much more modern basis, but:

* it was painful to program compared to Windows

* it required a lot more hardware (and thus money) to achieve the same level of performance.

* the UI was terrible

not mini PCs, no, but there are laptops that do

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.

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.

You assume the marketing folks actually talk with the hardware folks. More likely its a big game of telephone....

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.

Its shift-tab in Claude Code, fyi

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.