Those are entirely different operational models.

While people do often use pis to do things you could do with an esp32, an ESP32 cannot do the majority of things a Pi can do.

Over time the Raspberry Pi use case shifted more and more away from GPIO. They all still have it but probably most of them are used as a Linux computer without ever touching the GPIO now. The people who do use GPIO on a Raspberry Pi are often better off using an ESP32 because they have better control of GPIO, consume far less power, and are actually cheap.

Personally I use ESP32s for GPIO to control things around the house and have one Raspberry Pi acting as a hub.

I've been doing home electronics projects since around 2013, I used to use Raspberry Pi's for everything from lighting control to robots, camera projects and lots in between (I even had a mechanical keyboard with a Pi inside) and a massive collection of hats and addons. These days, I can do 99% of what I need with tiny little ESP32 variant boards for a fraction of the cost and significantly less complexity. Hell, you can even get esp32's with really nice touch screens attached for dashboards / animations. I built a whole cyberdeck using an ESP32 and no computer in-sight.

their RP1 IO chip is such a disappointment for high performance GPIO use cases as well, literally can’t trust any IO decision they make after having hacked on that chip

The full size Pi has less and less of a niche. GPIO / low power edge? ESP32s are great. Signage? The pi isn’t really all that great, and is expensive, get a cheap N100/150. Hacking on Linux? Literally anything else.

In many cases that’s an advantage. Tiny (or no) attack surface, less power, etc

The attack surface maybe smaller but less eyes on the firmware images for sure.

At least most my ESP32s are off any net, and pretty low stakes applications.

There is some overlap, see FUZIX for the RP2040 for example.

Most of the time it's some UART or BT proxy for me, maybe toggle a light, etc. Sometimes it's all of that in one. Plenty of power for it lol.

> Those are entirely different operational models.

In some of the tinkering applications, RPis are shoehorned into the very operarional model that is followed by ESP32s.

ESP32s may be harder to debug but they allow us to remove a big chunk of the complexity that lies between our code and what we want the device to do.

I think your criticism is more in line with "they are not exactly the same as RPis". And that is fine.

> I think your criticism is more in line with "they are not exactly the same as RPis". And that is fine.

I chose my wording very intentionally. My criticism is exactly what I said.

It’s like comparing a bicycle to a light duty farm truck.

A security researcher colleague of mine was/is exploring an unauthenticated avenue along this line. I don’t have any update, she told me she didn’t feel comfortable exposing information to anyone other than Tailscale staff until she’s confident in what she found or didn’t.

we'd love to hear about it at security@tailscale.com, we're happy to work from & with and credit early ideas as well.

I will send her your message!

Bleeping Computer also reported that PHP 6 was among the vulnerable versions. I’m not exactly sold on their verification standards.

Buying a stock that holds its price is equivalent to putting your money in a savings account with no interest.

I presume you mean a stock that holds its price with no dividend?

stock will likely hold inflation adjusted price unlike saving account.

Given gov currently spends 1T annually on servicing debt, I expect US is forced to print money and increase inflation for a long time.

I'm not sure if you're being self depreciating or genuinely desire that, but this isn't an outcome that leads to good software engineering.

You should own and be the expert on the architecture and design of what you're building regardless of whether yourself, an LLM or another person is writing the code.

The LLM isn't "smarter" than you, it's more resourceful. It can (to varying degrees of success) translate your design into code. If you aren't still taking ownership and driving the design of that logic, the LLM isn't going to bring you success with anything other than single-use or hobby applications.

The thing is, if you’re good at designing and breaking down problems and coming up with a good system, code is not likely an hindrance.

You can take any idea and try to flesh it out with pseudo code. Once that’s done, try to convert it to real code and you’ll see that process is fairly mechanical. This is why people says that coding wasn’t an issue for ages. Coming up with the algorithm is the hard part.

People that have an issue with coding either are not familiar with the language/platform or is trying to think with real code instead of pseudocode or diagrams.

ADDENDUM

There are techniques to think with real code, moslty the Edit-Compile-Run workflow coupled with a good editor, or the REPL workflow (also helped by a good editor). Then add a good integration with a documentation system (manual pages?) and you’re golden.

But I’ve been on projects where a dev cycle relies on a 20 minutes local rebuild or one hour CI run. So it can be very hard to try to apply those workflows to legacy projects.

I find this to be intrinsically true in my experience. I was put into senior-level engineering positions very early in my career because I'm a strong problem solver and mentor. I've taken on several positions as a programmer working with a language stack I had little to no experience in without much issue.

Of course there are problems where knowing the code deeply is essential to solve the problem, but those really aren't the majority, if even less than 1% of business problems.

When it comes to what the average developer needs to understand, having a strong grasp on one functional and one procedural language can enable you to solve almost every problem in any language ecosystem, provided the correct resources. If you can do this, you can utilize an LLM for programming assistance well. If you can't, you probably should not heavily rely on one at all yet.

I somewhat doubt the "fairly mechanical" claim. I think when you actually turn it into real programming language code, that's when lots of the edge cases become apparent and then you will face a lot of new questions, that the natural language or the pseudo code didn't cover.

I think those are mostly technical issues (accidental complexity) and those are either documented or there should be someone experienced with the technology on your team (even if that experience came from trying it out).

Critical thinking is essential for nailing down your essential complexity (the core solution of the problem). You can try to define invalid and edge cases alongside the happy path in the pseudo code diagrams version, even if it's a TODO comment.

Sorry, I get where your emotions are coming from with this, but it is just technically wrong on every level.

The vast majority of tech support scams come through apps on the Play Store. Not only that, but malicious apps get approved on the Play Store constantly.

There is no reason to take any claim that this change is meant to mitigate scams seriously, because there's no evidence to support that it makes a noticeable dent in such activity.

What this change does noticeably and impactfully do, is prevent, via chilling effects, users from being able to use their phones in ways that could lose Google and its partner vendors post-sales revenue.

As you said, serving people should be the end in itself, and this change doesn't do that - it hurts people.

And most people running containers are running a default docker/containerd setup, which does not actually isolate you from anything at all in the first place anyways.

For real.

My agentic workloads happen on two physical machines dedicated only to agentic workloads that share a VLAN with only eachother, with single token access to the specific repositories they are meant to push to and limited scope, hard limited credentials pulled from the hardware store on hardware token/fingerprint request only.

I view the safety around unmonitored agentic work in a similar way to how I view working with viruses or bacteria in a disease lab.

This stuff isn’t magic, it isn’t intelligent, but it is dangerous and needs to be handled with careful intent.

To be four, you could open it to the world.