edg5000

I would not think in terms of "how much" context, but really just how the harness manages it. I've been fiddling around with harnesses earlier this year and the rabbit hole goes very deep. I eventually had to drop it because it consumed me, and I can only do one thing well. But what I learned is that there is a lot on the table at the harness level.

The elephant in the room and the constant tension is that the models do get "used" to a certain harness (trained for it by the model labs), but they also generalize well. So one really advanced mechanism could fall short because the model could fail to generalize, whereas in other cases the model might handle large deviations from how a conventional harness works better than expected. This is where the gains are.

I wonder how feasible decompilation is. The firmware is used in many boards. An open, cleanroom reimplementation (derriving hardware details from the firmware, then reimplementing cleanly in embedded C++ or rust) could fix the issues, that would be very interesting.

That's true. It's a two way street. I feel I gain more from what the model offers me, than what I provide back. Of course, local would be a thousand times better. One day I'll have 20k to spare and get the hardware.

Yes, so different SoC, same WiFi, same issues, isolating the issues to the WiFi chip (common denominator). Carrier was also ruled out since I tried a custom and Raspberry offical one.

I tested te Pine64 SQQuartz CM4 compatible SoM, but it uses the same Cypress CYW43455 WiFi as the CM4/Pi4, which crashes on me under load (not the kernel, the chip itself). There is no fix or easy mitigation, other than lowering the load which only reduces occurence. I't odd that not many are talking about this.

The CM4 and Pi 4 use the Cypress CYW43455 for Wi-FI, which I found to be unreliable. Under load, it crashes, and it can't be fixed in the kernel.

Frustratingly, many other SoMs and SBCs use this chip. I don't understand why there is no recall on this - in my opinion - trash product. It's an odd feeling to be the only one experiencing this. I am 100% confident this is a design flaw in the CYW43455. I've seen this also on a Pine64 CM4 compatible SoM, which has a completely different SoC. This is on both the official and custom carrier. Cypress, fix your shit!

I used to care about this initially, but now I don't. How can them having my data, mostly engineering work on niche (small market) products hurt me? An they need to know what's going on, how else would they ever improve the product? Benchmarks?

What could happen, even in countries with strong socialist worker protections (western europe) or high cost of living (US, europe, many others), is that labour will become cheaper again. We'll be "poorer", less able to import, but on the other hand may be able to do more locally. We may also see larger economic class differences, as you essentially said youself.

In a way this could be a downgrade, we'll be less incentivived to optimized or automate, and will be able to just throw bodies at problems.

From reading xpct's comment in this thread it seems like they use effectively a very deep and wide pipeline by tiling the cores without central clocking or dispatch. In theory if a GPU is centrally organized it could simulate this behaviour, but I imagine that creates transfer overhead. Just speculating though.

They're very afraid of the competition, this really fits their modus operandi. They don't want to reveal inner workings any more than needed for the product to be usable. Thankfully anybody can spin up a VM and vibe up something similar. It's not like the Windows moat or anything, it's not sticky.

Not using assistants, but I had it do quarterly reporting. Gave it the password to my webbased accounting software which does not have an API. Told it to write a CLI for itself to access the administration. I only did the bank exports to CSV. Told it to look in my Thunderbird mailbox to find invoices and let it do the quarterly reporting. Main issue: Many foreign vendors don't use invoices, which means my Dutch, invoice-centric accounting software kinda sucks for international import-heavy operations.

I have it use `playwright-cli` which runs a headless Chrome session, with relatively structural representations of websites without the HTML bloat, plus image viewing options. The builin web fetch tool indeed seems blocked. Headless Chrome is just Chrome, you can't block it. I think even the "Are you human" checkboxes are okay, since LLMs are good at coordinate guessing and initiating clicks.

I leave my address, name and an email address. What damage could be done with that? The only risk is password reuse with important services.

I've been doing PCB layout with Opus 5.5. Maybe this was possible easlier and with Chinese models, but I feel this really pushes the model. These are 10hr jobs, so also requires good stability over time. I suppose this could be tested. As the models get better, I also get better at using them. So I'd say yes, we do more advanced things with the models every year.