drrotmos

Of course, the natural question is "Can you put a Canvas in the DOM in the Canvas in the DOM?"

Here's hoping for it being DOM-in-Canvas all they way down.

Are they though?

  $ docker pull php:8.4.27
  8.4.27: Pulling from library/php
  no matching manifest for linux/arm64/v8 in the manifest list entries
  
  $ docker pull --platform linux/amd64 php:8.4.27
  8.4.27: Pulling from library/php
  no matching manifest for linux/amd64 in the manifest list entries

More than likely the instruction was "Fetch this information from the website", and when the agent didn't find that information, it decided that the best way to get it was to hack the site.

If so, it illustrates quite well the lack of common sense in LLMs. A person, especially one with sufficient skill to actually hack a website, would presumably think twice about doing it (considering that it is illegal) for a simple information gathering request.

I wonder if there is any other ways to solve this long-term than to introduce strict liability for model providers...

Edit: An obvious other choice would be strict liability for the operator, but considering how much weird shit LLMs get up to without being asked to, that would get out of hand quickly.

I really like working using Claude Code, but Anthropic has a really bad tendency to push out new "features" like this as default-on, through auto-update. That, and their models trying to do everything through bash (including editing files) is enough that I'm seriously looking in to switching harness to pi.

It is and it isn't. If you ask a human how many calories (or carbs) are in that sandwich, they can give you a qualified guess based on how a sandwich like that is typically constructed. They may not know the calories for a slice of bread or a slice of cheese by heart, but if you give them a food database, they can look it up.

They absolutely won't be 100% correct (bread sizes e.g. are going to be an estimate), but unless it's a trick sandwich drenched in olive oil or with hollow cheese, they're probably going to be in the right ballpark.

I don't think it's outside the realm of possibility for an LLM to be in the right ballpark as well, but that doesn't seem to be where we're at now.

Plastic isn't a single material. Some plastic materials (e.g PE, polyethylene or PVC, polyvinyl chlorine, but also others that use ethylene derivatives as intermediates) require ethylene, but there certainly are plastic materials which are produced without any involvement of ethylene or other petrolium derivatives.

But according to the README, it is production grade! Presumably "production" in this case is an isolated proof of concept?

True. I do however like the process of working with an AI more in a language like Rust. It's a lot less prone to use ugly hacks to make something that compiles but fail spectacularly at runtime - usually because it can't get the ugly hacks to compile :D

Makes it easier to intercede to steer the AI in the right direction.

In my experience AI and Rust is a mixed bag. The strong compile-time checks mean an agent can verify its work to a much larger extent than many other languages, but the understanding of lifetimes is somewhat weak (although better in Opus 4.5 than earlier models!), and the ecosystem moves fast and fairly often makes breaking changes, meaning that a lot of the training data is obsolete.

We have multiple apps across both Common Runtime (EU) and Private Spaces (eu-west-1). It's a mixed bag. Some are up, some are down.

We're seeing mixed results with our apps, both in the Common Runtime (EU) and Private Spaces. A few apps are up, most are down.

The ESP32-S3 has 512 KB of SRAM, and the RP2350 has 520 KB of SRAM. The ESP32-S3-WROOM does indeed come in configurations with additional PSRAM, but that would be comparing apples and pears. The WROOM is an entire module complete with program flash, PSRAM, crystal oscillator etc. It comes in a much larger footprint than the actual ESP32-S3, and it is entirely conceivable that one could create a similar module with the same amount of PSRAM using the RP2350.

Furthermore, the added RAM in both cases is indeed PSRAM. That being said, the ESP32-S3 supports octal PSRAM, not just quad PSRAM, which does make a difference for the throughput.

I'm very much looking forward to giving Embassy on the RP2350 a go. I've been using it for a while with the RP2040, and it's a joy to use.

Note that this was written 2024-08-08. While I haven't kept up to date with exactly what's been happening in rp-rs, I do know that probe-rs has since been updated with support for the RP2350. Other things may be outdated as well.