Kinda interesting, but disjoint from all the real underlying reasons why React and other frameworks are so sticky.
After a decade of React, I'm not going to go go learn htmx or any other marginally better same-shaped tool for a new project, especially when it'd degrade my ability to review and debug another actor's work product. The cost of switching frameworks is now dramatically higher and the payoffs way lower.
Fundamentally, framework perf is about not incurring too heavy a cost for the abstractions, and then to improve dev efficiency. This matters most in the "explore"/prototype phase, when poor perf would be a good problem to have to care about.
In my projects, the real question has kinda moved down to "should I yeet 1/2 the app to wasm yet?" and similar higher-order questions.
Glad you seem to have found a way to deal with it. Have been dealing with a handful of severe health issues myself the last few years and it does get nightmarish at times, especially as one scratches out candidate causes.
IMO accessibility is an under-discussed benefit of the recent AI improvements. I've recovered from my RSI (typing injury) enough to use a keyboard a moderate amount but doubt I could ever go back to shredding through a codebase like I used to. In an earlier era I might have left the field entirely.
But still, even if all one has to do is read diffs and mumble to Claude, there's no getting around fatigue and brain fog when it's severe enough.
If you haven't tried it yet: Those expensive but very ergonomic keyboards (glove80, kinesis, ...) with very light key switches did do the trick for me. Had severe RSI at some point from hacking away at a laptop and then at home at an ordinary keyboard, so that I went to doctors. But they didn't know about such keyboards, and I couldn't just stop doing my job that I loved. Anyway, now I very rarely have any issues at all. Worth trying if you have not yet.
Whether the ant post amounts to plagiarism, it is definitely somewhere between extremely lazy and intentionally misleading. No particular idea has its inspirations or origins traced or cited, there is no comparison to comparable tooling or discussion of prior work, and there is absolutely nothing to actually position or discuss the project in a manner that might lead to "Contributing to the wider ecosystem."
If only they had had a claude write the post, it'd be full of citations, inspiration credit etc.
Also WRT coordination: All an agent has to do is think "if another agent could write, then I could read their answers. What's the first site I can think of where that might be possible?" because they all have approximately the same conditioning, they'll converge on the same sites.
Generally, models of the same class should be able to coordinate quite well without communicating. But also, this could be being exploited to detect this kind of thing early
The key insight here is being the top used model on opencode while being fully served on Chinese chips. The free price itself might be just a flex or marketing budget.
it was not the first model served for free, i remember grok and others beeing free on openrouter but they never had this popularity because they where not good enough.
This comes almost exactly a week after the HF hack. Good strat, to drum up a bunch of press about how security-capable the model is right before releasing the product.
Or, it would be if it was intentional. It's a bit suspicious but it is probably incidental or opportunistic... though I do really struggle to see why this tool wasn't made better use of internally to actually harden their infra against the big scary AI they were testing.
With the scarcity of details in this and the OAI post, I feel there's no telling whether this was a particularly impressive series of exploits vs lackluster security. Similar w/ the similar Ant news WRT Mythos earlier.
Not saying the intro of agents capable enough to exploit the latter isn't meaningful, but we should not trust the use of technical terms to give us good heuristics of severity or import.
Ie, an agent "breaking out" of its local harness "sandbox" is trivial, and so is discovering a "zero-day" in a half-maintained internal piece of utility infra nobody put serious effort into securing.
Now, if I see something like a collaborative red-team effort where a frontier model gets into a replicated prod env setup by like, Big Four bank security+ops team, and manipulated balance numbers in a system of record, _that_ I'll freak out about.
Haven't we established defensive and offensive security usage are intractably entangled? I.e. "patch all [security] bugs, make no mistakes" gives one a list of potential exploits to hand off to less capable models.
Doesn't that undermine all good-faith discourse on cybersecurity safeguards, controlled usage etc? Or is that overstating the case (I'm not a security researcher myself so kinda parroting).
I got the Phomemo M02 Pro and have liked it alright for printing out playtest cards on-the-fly. Claude did manage to replicate an integration someone else did the hard work of working out w/ dithering etc, but the native app's fidelity & speed has been better for my use-case, at least
This is very cool - I try to have a container-centric setup but sometimes YOLOcal clauding is too tempting.
My biggest question skimming over the docs is what a workflow for reviewing and applying overlay changes to the out-of-cwd dirs would be.
Also, bit tangential but if anyone has slightly more in-depth resources for grasping the security trade-offs between these kind of Linux-leveraging sandboxes, containers, and remote VMs I'd appreciate it. The author here implies containers are still more secure in principle, and my intuition is that there's simply less unknowns from my perspective, but I don't have a firm understanding.
After a decade of React, I'm not going to go go learn htmx or any other marginally better same-shaped tool for a new project, especially when it'd degrade my ability to review and debug another actor's work product. The cost of switching frameworks is now dramatically higher and the payoffs way lower.
Fundamentally, framework perf is about not incurring too heavy a cost for the abstractions, and then to improve dev efficiency. This matters most in the "explore"/prototype phase, when poor perf would be a good problem to have to care about.
In my projects, the real question has kinda moved down to "should I yeet 1/2 the app to wasm yet?" and similar higher-order questions.
reply