No need for something new here, Claude Code (Auto + default settings) has a tendency of running "find"/"ls" on your home folder when it struggles with solving a problem. I wish I was joking.
Now of course people trust these AI companies not to do bad things(tm), but all it takes is replacing the model endpoint URL -or any kind of harness compromise- and nothing will seem amiss
> has a tendency of running "find"/"ls" on your home folder
I've seen this first-hand. I was doing some work in a repository, Claude concluded it needs to investigate, how some AWS resources are created, and it literally started scanning ~/* for Terraform code. Which it found and started browsing through.
Or, when I asked Claude to debug some Spring issue, corporate firewall blocked Maven Central, so it literally started scavenging ~/.m2 caches to find the jar it desperately needed. Then it could not find it, so it started to clone Spring sources from GitHub to build the missing jar. I stopped the clone mid-way. I wish I was joking, I only stepped away from the keyboard for one minute.
It accidentally made a compiler because of an ambiguous prompt. And yes it will find "helpful" code on other parts of the system. Which means claude most likely has a `find ~` of millions of developers home folders
Is it not because they have been enshittifying Search for over a decade, then recently lost their de-facto monopoly on Search due to LLMs, with no good new product to show for it?
LLM use != vibe coding (latter should be reserved to "cattle" projects)
One can use LLMs to find vulns and/or review hand-written code, for example. But to answer your question, one doesn't understand code they didn't design nor write themselves.
Outside their most successful products (YouTube, Android, GMail, Chrome, Search), their products are usually worse than their competitors (e.g. GMeet vs Zoom)
> the brand recognition
Of not maintaining/outright abandoning their products, and making Search worse over the years?
> most importantly a billion normies
ChatGPT has 1.2B weekly active users, all the normies know what ChatGPT is but don't know about Gemini (outside the "AI Mode" stuff)
I dunno if that's a great example - I'm sure Zoom has more awareness in the zeitgeist, but from my standpoint it's an app most well-known for security problems and abusing OS conventions, while Google Meet just quietly and simply works whenever I want to call my mom.
Google meet screen sharing is a horrendous UX, reactions are clunkier than zoom, the tiling options are worse than zoom, and I have yet to see a conference room setup that actually works with HDMI inputs.
You're not alone. Though, I wonder if this means better coating, the coating on the existing MacBooks (but not the M1's) get damaged far too easily when in a bag.
Not sure when it started (at least the M4 is affected by this) but all the macbooks I had (personal+work) since the M4 have display dimples after being put in a stuffed backpack.
Meanwhile the M1 Air I had for more than 3 years never saw the issue.
Yeah and some of the article wasn't proofread (by himself or a clanker) and the project is missing some of the due dilligence.
One striking example is "No debugger, no stdout" which is baffling considering I implemented a GDB stub in the very first version of Rosalina which I released like... 10 years ago?
Stdout redirection is supported by both 3dslink and GDB stuff on 3ds, too.
I don't mean to be a party pooper - and the projects fullfills its role as a showcase of how far pure vibecoding can take someone - but it's this can of thing that gives the "absolutely no AI" crowd grounds to stand on.
> Good instinct, the bottleneck is on the CPU side though.
Have you, or rather your agents, tried to identify which CPU functions were the bottlenecks (e.g. in citro3d, perhaps)?
I find it surprising that your stuff is CPU bound. Are you doing one command-list submission for _both_ eyes (with one drawcall for each)? This should be relatively simple, only require viewproj matrix changes and avoid CPU<>GPU roundtrips.
If not, you are going to hit IRQ dispatching costs as well as shardmem dispatching costs as well as other costs.
Bypassing Citro3D for raw PICA200 commands cut our per-draw CPU cost by 15x (11 µs to 0.7 µs). After that, there's no single hot function left.
The remaining bottleneck is the o3DS instruction cache. Our code is bigger than the 16KB L1, so the CPU spends a big chunk each frame waiting on instruction fetches.
We build the list for left eye, submit, and then re-submit the list offset for the right. Hadn't tried chaining both into one submission, it improved performance. Thanks so much for the suggestion!
Thanks for taking a look and the great questions. I really appreciate your contributions to the scene.
GitHub offers noreply email addresses
reply