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.

Which may or may not be fine in a Go binary that runs on a modern desktop CPU, but what if your code is supposed to run on say an ESP32-C3 with a whopping 160 MHz RISC-V core, 400 KB of RAM and maybe 2 MB of XIP flash storage?

You could of course argue that that's why no-std exists in Rust, or that your compiler might optimize out the animated GIF routines, but personally, I'd argue that in this context, it is bloat, that - while it could occasionally be useful - it could just as easily be a third party library.

The Pico 1 (i.e. the RP2040) doesn't. The Pico 2 (RP2350) does, albeit a fair bit slower (since it's QSPI PSRAM) than the internal SRAM.

The SNES and the Gamecube did have the Super Game Boy and Game Boy Player respectively though, but I'd probably count that as sideward compatibility rather than backward compatibility.

> You're assuming the odds that there was even the structure in place, that natural selection can work its magic.

I'm not assuming anything, I'm merely claiming that the situations aren't analogous.

> All of those single celled organisms didn't come from nowhere, overnight. There was, at least at some point, the first single celled organism. Not only the first one, but the first one that was able to reproduce. There could have been millions, billions of single celled organisms incapable of reproduction that died. The odds of just getting one single celled organism, by itself, without the ability to reproduce, is already ludicrous.

The general thinking among researchers is that single-celled organisms were preceded by self-replicating and self-catalyzing molecules, like RNA. Abiogenesis is a fascinating area of research.

> Now weigh the odds that, if the entire world population of monkeys hitting random letters can't even make Shakespeare within the amount of time from the Big Bang until the Heat Death, that we reached the level of human intelligence. Until such questions are answered, a God is still quite reasonable.

That's only an apt analogy if genetic mutations didn't include any kind of feedback mechanism. Natural selection makes them very different scenarios.

> Exactly. And this market has a really unfulfilled niche: cameras with a decent optical system and changeable lenses. I have a Sony Alpha camera and it's plenty enough for me in image quality, but I now leave it home most of the time because I just don't want to fiddle with it.

When I leave my MILC at home, it's because the optics are large and heavy, not because the body is. When I do take my camera, I usually opt for the Sony Zeiss 35 mm Sonnar T*, because it's so small. From an optical point of view, it's a good lens, but it's not the best 35 mm lens I have.

For capturing memories, the best camera really is the one you have with you at all times. For creating photographs, the bulk of the camera body really doesn't matter that much.

My go-to recommendation for single boiler vibratory pump machines has been Gaggiuino. I’m not sure I can still recommend it after their latest source-closing move, but it is absolutely still the best bang-for-the-buck upgrade for single boiler vibratory pump machines.

It is, and you’re welcome.

I’m actually taking a very componentized approach with my new Rust based firmware. Wherever it makes sense, I’m spinning things off into separate crates and will be publishing them (e.g. crates for the ADS124S08 and FDC1004 used in the All-Purpose Espresso Controller.

Also, everything is permissively licensed, so feel free to use whatever you want.

Gicar. If you're looking at home machines from manufacturers that also do commercial (e.g. Profitec, ECM, Lelit, Rancilio, La Marzocco etc), they almost exclusively use Gicar electronics.

Oh, don't get me started on what the problem is :D

* Espresso machine electronics are very proprietary. There's basically one manufacturer, no published schematics and very closed firmwares.

* That one manufacturer's hardware occasionally breaks and needs replacement, and they charge up the wazoo for it.

* Firmware updates is not a thing. Buying a new controller with the new firmware is your only option.

* Espresso machine electronics hardware is pretty firmly stuck in the past. If you're lucky you have a 128x64 px OLED, but more likely you have LED indicators, 7 segment displays, or graphical LCDs.

There are absolutely exceptions to this, but for 95% of the espresso machines out there, you're definitely not getting the full potential of the hardware.

The more I think about the more I feel that this is the wrong solution to the problem. Disclaimer: I'm doing a small open source espresso controller project, check it out if you're interested, but it's not ready for prime time yet: https://github.com/variegated-coffee.

My thinking is that this machine appeals mostly to people who already has an espresso machine. It's not particularly technologically advanced. It's a single boiler, an E61 group and a vibratory pump. If you're buying this machine, you're probably replacing a machine at a similar technology level, and that's not really a sustainable choice.

A well maintained espresso machine has a lifespan in the range of decades. Many recent innovations in espresso machines is mostly controllers, sensors and actuators. Also better pumps. These are all things that can easily be retrofitted to an older espresso machine.

There has been innovation in other areas not easily retrofittable (saturated groups, dual boilers instead of heat-exchangers, to name a few), but this machine doesn't really feature any of those.

I strongly believe that in this particular demographic, it's a much better (more sustainable, cheaper and all around more fun) idea to retrofit new and advanced parts to the espresso machine they presumably already have, than to buy a whole new machine. We don't need old espresso machines on landfills.

On the off chance that a prospective buyer doesn't already have a similar espresso machine, this isn't too bad of a choice, and the price is decent, but on the other hand, there are a lot of used machines on the market that are looking for a new owner and can be upgraded.

Personally, I've begun switching over my RP2040 projects to Rust using Embassy. Rust did take some getting used to, but I quite like it. Not an RTOS, but it satisfies a lot of the same requirements that'd lead you to an RTOS.

A debug probe is nice (quite possibly a must) if you're actively developing, but for deploying in a hobbyist environment, USB is hard to beat.

I make open source espresso machine hardware (github.com/variegated-coffee), and it's nice to be able to give users a wired way to update firmwares that doesn't require extra hardware.

> If you allow a person to buy a $800 sofa which looks great on the outside and is made in China albeit with extremely low quality materials vs. a sofa which looks almost exactly the same but is priced at $1500 but is of much higher quality - most consumers will obviously choose the $800 dollar sofa vs the $1500 since that's how the free-market functions. Is this rational though?

This is rarely the choice though. In my experience, the choices tend to be the $800 low quality sofa, the $3000 low quality but with a name brand sofa, and the $6000 low quality but with an even fancier name brand sofa.

Presumably there are some manufacturers that still produce furniture that's actually made of massive wood rather than cardboard and veneer, but it's becoming increasingly rare.