Hacker News new | ask | show | jobs
by samtho 1047 days ago
This would be hilariously satirical if it were not true and it highlights much of what is wrong with tech.

A benture capital subsidized micro mobility startup pulls out of a major city ostensibly because threshold for potential profit has been crossed and they’ve determined they cannot adjust their pricing to get the right numbers on their spreadsheet (note: this likely part of the reason why so many of these companies have trouble converting people to yearly plans, why bother if your market can be dropped with such swift indifference?). After pulling out of the market they leave their trash, that were assets a few days previous, scattered amongst the city as technological blight strewn across the landscape, left to rust. When opportunists go to crack them open, they find a raspberry pi, an SBC created for educational and hobby purposes but has been infamously out of stock because larger companies want to vacuum them all up to use in their own products. Then you wonder where all the engineering cost for these scooters went. After the presumably thousands of hours of labor that went into designing this, they went with a consumer grade, off the shelf product for an application that would have required a fraction of the power it was capable of? Not to mention that Spin can be identified as one of offenders of why the raspberry pi is so goddamn hard to find.

This all makes me irrationally irritated.

16 comments

> When opportunists go to crack them open, they find a raspberry pi, an SBC created for educational and hobby purposes but has been infamously out of stock because larger companies want to vacuum them all up to use in their own products.

What a strange complaint. RPIs are out of stock because they're useful - this company found a use for them. Really the issue isn't one of who's buying, but rather an issue of the Foundation not making enough of their wildly successful product. Seems like a high-quality problem.

I can't imagine the Foundation being up in arms over someone finding a use for their product. The more users, the better the economy of scale, the cheaper the product is for everyone.

> Then you wonder where all the engineering cost for these scooters went.

Well, into the backend, the integration, the mechanical engineering - the myriad other things that mark the difference between a fun thing you made at home and a product you sell to the public.

> After the presumably thousands of hours of labor that went into designing this, they went with a consumer grade, off the shelf product for an application that would have required a fraction of the power it was capable of?

Again, economics of scale. One product that's more capable than any one person needs - but has a bigger audience - is likely cheaper than a niche one that's 'right-sized.'

Your remote control doesn't need a Cortex M0 but they're cheaper than an 8051 now.

> Not to mention that Spin can be identified as one of offenders of why the raspberry pi is so goddamn hard to find.

So can anyone who hit 'add to cart.' Especially since they only have like 500-1000 scooters per city in which they operate. That's not exactly Apple-scale orders.

The issue is supply, not demand.

>RPIs are out of stock because they're useful - this company found a use for them.

While I sympathize with this sentiment, it should be noted that their use case could have been most likely accomplished with something like an ESP32, which is only slightly more difficult to work with but boasts a bulk price of $1-3 a pop.

Using a Raspberry Pi 4 for this is a bit like flying a private jet to get to the grocery store.

developing for esp32 is way more difficult than developing for raspi. raspi lets you basically treat it like a normal computer, you can use standard python and sqlite and install whatever nonsense you want from pip and basically assume it will run whatever your laptop can. it means you can hire kids straight out of school, or outsource to india, and whoever you get can work on it without really any concern - it'll run whatever crap you give it.

esp32 is embedded enough that you have to develop for it like you develop embedded software - you need to do things like think about how much ram you're using that you just don't have to on raspi.

Problem: We need to outsource the software to India.

Solution: Put a way overpowered computer in the product so they can program it.

Ridiculous problem with a ridiculous solution. Are they allergic to any level of correctness? Sometimes I'm ashamed to be in this industry.

I've struggled with this question myself so I'll just put it out: what makes using something that's more powerful than you need - and less expensive - wrong or shameful?

The only product that matters to a customer is one that exists, and if this approach saves you money, lets you prove product market fit, or allows the product to keep existing longer - isn't that more important than the fact the Pi has more parts than you need?

What if the jet ride cost 25% less than the drive? What if they're only using the jet to prove demand exists on the route? Optimization only makes sense in the face of scale, but you need to get to the scale first.

My lament is more about the unrelenting desire to degrade software from being robust, well designed, and fit for the task, to fungible slop pouring out of a pipe from whoever is cheapest. In no other profession (architecture, construction, teaching, anything) would that mentality be tolerated.

The unnecessarily wasteful hardware is just one of the (ultimately more benign) side effects of that.

The phrase that I've cautioned other engineers with over the years is "you don't get extra points for making it harder."

You really don't. And in most cases, making it harder means that you're probably making it buggier.

Why outsource to India?

Pick any random set of Software Engineers from any country. I guarantee you that you are more likely to find people who can develop fast on an RPi than on an ESP32.

Now if you're a startup needing to build very fast and iterate quickly, it's obvious you're going to use the RPi4. Then, once you've grown, you can make the system more efficient, port it, etc. It'll be a growing pain, but a sustained one. And without being completely immersed in ridiculous amounts of VC-funding (hopefully)

I'm the CTO of a company who helps startups go from the idea to the scale-up phase. We helped build a tiny startup to one of the most promising startups in europe using this idea. We're very proud of what we've achieved. Could we have built something with an ESP32? Sure, and we might have even made it in the same timeframe given the amazing team we have, but it was less risky to bet on the RPi than the ESP32.

In fact, the first iteration had an ESP32 and we were brought in because they needed to move faster and it was becoming hard to develop for and iterate at their pace. Again: perhaps we could have built the same with the ESP32, but it's a matter of risk analysis!

Sometimes I feel like people talk about these things in a kind of vacuum of perfection and utopia, outside of the real world. In the real world things get messy and move very fast. Supply-chain issues arise, hardware has to be swapped, people move cities and quit their jobs. Where we have excelled as a partner is in dealing with very very very fast change and using an ESP32 for that would have made things harder. Now instead of a dead product there's thousands of the thing we helped build out there, and growing. And we're finally moving away from the RPi4.

Technology is actually a very small part of what we do. Most of it is creating the logistic and the "system" around the technology to get everything to work. Sometimes, as engineers, we forget that.

you can outsource esp32 developement to india just fine. the fact that someone decides to use overpowered hardware so he can develop crapware is independent of where the crapware is developed
An ESP is a chip, not an SBC. So then you have to pick an off the shelf SBC from a different supplier which is either (a) hobby grade, see OP or (b) much more expensive or (c): you have to do your own electrical engineering, component selection, BOM, PCB layout, PCB manufacture, assembly, deal with a contract manufacturer - do EVT, DVT and PVT - ramp production, test/validate, package, stock and distribute the units. (c) is going to delay you 6-12 months.

We also don't know anything about the quality of the software running on those devices. I've seen some awful crimes against computers committed in embedded software - and I've seen some pretty well written software on more capable machines. And v.v. of course.

Take the money from the raspis and put it in a decent developer, then fire him once you unleash the scooters and break even after a couple months? The issue here is the months long wait I assume
I understand your point—the barrier to entry for development is somewhat higher for the ESP32 than for the Raspberry Pi.

Then again, I wouldn't say that it is way more difficult, and I would wager that most of those who have the skills to build the brain of an electric scooter with a Pi 4 could learn how to port their application over to the ESP32 platform within at most a week. Even if you went with a more pessimistic estimate than that, the enormous price difference between the two boards will always make up for the cost of engineering at scale.

Consider a few other advantages of using the ESP32 here: faster replacement times of faulty hardware, and a way smaller attack surface. How much do you want to bet that those Pi 4s have "root" set as their username and password?

Right, but depending on your industry, you may not be able to make up the development speed advantage of the RPi at any cost.
You would like Python and SQLite on ESP32? Looks like a solved problem.

https://github.com/spatialdude/usqlite/wiki/esp32

Micropython isn't actually Python.
The only time I think I'll ever see a pi compared to a jet, hah!
> After the presumably thousands of hours of labor that went into designing this, they went with a consumer grade, off the shelf product for an application that would have required a fraction of the power it was capable of?

Driving the 3-phase motor yes, that can (and is usually) done with a dedicated real-time MCU/ASIC. But the interface with the backend, the actual brains? You need to deal with GPS, authentication (unlock via app/bluetooth/...), ride logging, debug data. And at that point an ESP32 or heaven forbid an Arduino won't cut it either, and you don't want to spend hundreds of hours on wrangling with some custom higher-power embedded board because that is real nasty to get right. So you use an RPi because the extremely broad user base has already solved every issue you might have run into.

Besides, the innards of e-scooters can be had as whitelabel solutions, no one engineers these themselves. All people do is design the outer shell based on a design kit, do whatever needs to be done to pass legal certifications, and integrate some sort of brains if it's for a fleet.

> GPS, authentication (unlock via app/bluetooth/...), ride logging, debug data. And at that point an ESP32 or heaven forbid an Arduino won't cut it either

Why? ATMega board is surely a questionable fit, but ESP32, or nRF52, or some STM32 board with Bluetooth all should be fully capable of doing the basics. I can't imagine those scooters do some fancy signal processing on-board or handle some particularly heavy traffic. ESP32 is capable of wrapping and transmitting a decent video stream (and even do some basic detection while it's at it) - surely it's much more data than some route information and various on-board telemetry. GPS and cellular are just talking over some bus to a module (pretty much the same as with rPI4), Bluetooth is available and not resource-expensive at all. So is talking to whatever relays run or block the motors - I imagine that's probably just a bunch of GPIOs. All that remains is need for some RAM to store/buffer the traces (ESP32, or one can throw in some external storage) and a basic TLS and MQTT implementation (or whatever tech would make most sense there) for the command and status message queue.

And most importantly, average ESP32 energy consumption is way smaller than rPI4's (it's pretty hot even when it idles). While I understand that scooters have large batteries, it still matters.

The ESP32 can certainly do any of those things, but where it starts to become a problem is when you want to do all of those things. You start to run into limitations on application size, IRAM, GPIO's, etc.

I've shipped ESP32-based boards and written firmware for it that really tries to cram in as many features as possible, but you do hit limits. While I almost certainly wouldn't make the choice of shipping a high-volume product with an actual Raspberry Pi in it, I do see why trying to cram all of this into an MCU is tough — especially if you're trying to get to market quickly.

Perhaps this would have been a good place to use the RPi CM4 though?

For the record, I don’t care what tech they decided to use, but I don’t see why the features you listed couldn’t be implemented with ESP32. Sounds like a fun project actually.
BLDC drivers are readily available for a variety of applications and current levels. You need only a 3.3 or 5v signals to get them to run.

The RaspberryPi is not a real time computer, it uses a conventional OS that is inherently not real time. Regardless, you don’t need anything RealTime(tm) because the throttle produces a signal to the BLDC controller, and the MCU only turns on/enables its use.

The benefits from certification are minimal of using an off the shelf product, as you are still required to have the custom stuff l certified, too. They are likely using a cellular module that carry’s its own cert which is the biggest hurdle anyway.

My point is that using a hobby-grade Linux system designed for a much different use-case shows clear deficiency in the skillset of the team, management, or hiring, this is very obviously not the right tool for the job. What makes this upsetting is the fact that the market this was made for (and still is exerting demand pressure) cannot get their hands on it because of the pressures in the industry that values something that just works over correctness. If they would have used the Rpi compute modules, it would have given them a lot of flexibility in what they chose to include while reducing costs all around. This whole thing is a masterclass in gross incompetence characterized by waste and poor engineering.

Even then a RPi Zero should have been more than enough to handle the things you listed I'd think? An RPi 4 seems like not just overkill but ridiculous overkill.
Sounds like a good way to make your hardware easy to steal.
It's a 20 kg scooter, of course it's easy to steal.
A halfway-competent operation management team would see that as a reason to make the hardware harder to repurpose, not easier. Big organized operations can figure shit out, but put some barriers in front of the script-kiddie/homeless-dude contingent.

A me-too copycat startup like Spin who got kicked out of Seattle a year ago ( https://www.seattlebikeblog.com/2022/05/13/city-announces-ne... ) doing it this way doesn't seem like a great endorsement to me.

You have to spend $$$ up front on thousands of vehicles that cost hundreds of dollars each, and your marginal revenue per ride ain't great. Putting a dent in your vehicle theft rate becomes a big deal fast.

A halfway-competent operation management team would run the numbers to see if there are enough people stealing scooters and stripping them for parts to justify developing proprietary hardware. They probably did and the answer was probably "no."
I'm doubtful that a copycat operation like Spin really ran the numbers as much as a much-higher-scale operation like Lime who clearly came to the "yes, we need custom shit" conclusion: https://flutterawesome.com/custom-iot-for-lime-gen-3-e-scoot...
> A halfway-competent operation management team would see that as a reason to make the hardware harder to repurpose, not easier.

Given that it's a routine sport in many cities, particularly those with bodies of water, to damage or destroy the scooters, it's imperative to make them as cheap as possible and as easy to repair as possible. Both conflict with stuff like custom boards or barriers to opening them up.

Are you getting this info from financial reports or such? Cause it directly contradicts all the first- or third-party reporting I've seen from the big players in the industry. As well as the hacker discussions around trying to repurpose newer Limes and such (another link in addition to the one I put in the other subthread: https://scootertalk.org/forum/viewtopic.php?t=30090&start=10 )

The biggest theft use I see locally these days of the modern Limes and Birds is using the batteries for charging shit at homeless encampments.

But there were a million copycat companies like Spin who launched with off the shelf stuff after Bird and Lime who seemed to copy the "light money on fire theft-wise" problems of off the shelf stuff.

It already has GPS and an internet connection. Easy to steal, yes, but also trivial to find.
I suspect both of those are external module/boards plugged to the rPI. It doesn't require a degree in electronics or software engineering to unplug all connectors from the board and move the scooter away from its last location. Or, you know, just disconnect the battery.

I've no idea about those scooters, but I won't be surprised if it's all behind some plastic panel held by few screws.

Damn I wonder if this problem could have been solved by making a dedicated board.
e-scooters are usually classified as vehicles. Stealing them in an organized fashion to part them out can net you a GTA charge.

Besides, why would you want to steal them? You can grab new ones for a couple hundred dollars. Not worth the risk.

https://scootertalk.org/forum/viewtopic.php?t=962&start=40

This was already all over the internet 4 years ago when Lime/Bird got started and were using off the shelf vehicles.

AFAIK, somehow going after scooter thefts in cities that often already had a grumpy relationship with them for GTA never really happened. And come on, there's a LOT of people for whom "a couple hundred dollars" is a plenty big enough score. Why would anyone steal a bike in that case either?

eBikes certainly aren't classed as vehicles in the US, and no one cares when they are stolen.

Given how little prosecution there is around bike theft, I doubt any police department or prosecutor is interested in spending the resources to prosecute the theft of an even cheaper mobility device.

They're classified as vehicles. Bikes themselves are also classified as vehicles and belong on the road
Depends on your locality, biking on sidewalks and trails is perfectly legal here: https://www.seattle.gov/transportation/projects-and-programs...
I dunno. I think you have to build a lot of units before the NRE cost increase beats the BOM cost decrease. Anyone that knows Python can write software that runs on a Raspberry Pi. Getting someone who knows embedded systems is going to cost you a lot more than that. Let's say you pay your Python engineer $200k a year and your embedded systems expert $350k a year. By hiring the Python engineer instead of the embedded systems engineer, you now have $150k to spend on parts. A Raspberry Pi 4 is $35, and a RP2040 (probably waaaaaay more compute power than these things need) is $1. So you save $34 per scooter, maximum. $150k/$34 = 4411 scooters before you break even by optimizing BOM costs. Do they have that many V1 scooters? Probably not.

Another angle is paying contractors. I doubt that you need a person-year to make an electric scooter, so that pushes the break-even point down a few units. But, your Python engineer can also make the backend when you're done with the hardware. It really depends on how expensive your recuriting/hiring/onboarding pipeline is. I am sure many people you run into will say that they know how to design e-scooter control systems, but you have to find the ones who are not lying. That's a cost.

So all in all, it seems like they spent their investors money wisely. You do the cost reduction when you want to expand, not for the "yeah, this business can't work" test phase. It seems like that's what they did; the business doesn't work in Seattle at any scooter BOM cost, so it's not a business.

The dumb part is not paying someone to round up the scooters and eBay the electronics and batteries, though. They could easily make a lot of their money back, probably even selling the used Pis for more than they paid!

Where do you live that embedded systems folks cost more than a generic Python dev? Everywhere I've ever heard of, ES is on the low end of the pay scale for software. Python is usually in the middle somewhere. That's definitely true in Seattle as well.
Yeah, I don't know where they pulled the 350k figure from? And from the picture, they aren't using 2040s. They are using full on PI 4s
+1 unless you work for google or maybe nvidia embedded get paid less than fronted devs straight outta bootcamp. at least that was the case last time i looked at those roles a few years back.
350k is so out of touch. maybe in a decade when there are no embedded devs left. everyone I work with is 55+
It's certainly attainable in ES, but you have to be fairly far out on the bell curve even with a decent amount of seniority in a HCOL area. It's nowhere near an average salary even in silicon valley.
There’s nothing wrong with this, RPi is a great platform for hardware startups because it’s one of the very few platforms with a good, well-documented Linux distro, a million HATs for easy prototyping, and a community to help you out.

It was never meant just for education and hobbyists, Raspberry Pi Foundation absolutely supports the commercial use case, and their newer products like CM4 even more so.

I’d wager you never tried to launch an embedded Linux-powered product, because if you did you’d quickly realize that building custom images from obscure Linux and U-Boot forks is just not fun. Raspberry Pi solved that for everybody, this is why it’s popular among startups even though it’s not the best hardware around spec- and cost-wise.

> I’d wager you never tried to launch an embedded Linux-powered product

I'd wager most people go with a RTOS

Outside a few open source options like zephyr (and FreeRTOS to a lesser extent), RTOSes typically have a worse developer experience than even the shittiest vendor kernel trees. At least Linux doesn't dictate your choice of dev tools like most of the commercial RTOSes do and the libc usually works.
I quite like Zephyr? Are you saying it's somehow worse than Linux? I agree there's plenty of garbage though.
The opposite. Zephyr is one of the more ergonomic RTOSes. Compare that experience to what's offered by VxWorks or Green Hills, which feel like taking a time machine back to the early 2000s in terms of productivity and features.
Thank god I've been privileged to not be forced into using commercial RTOSes
You’d only do that if you absolutely have to, eg when you’re very constrained by battery or you do actually need real time guarantees. Getting a device with Wi-Fi, BLE, GPS, logging, camera, etc working on a RTOS is just unreasonably complicated when you have a huge battery and 2W power consumption of the SBC is dwarfed by a kilowatt motor.
Perhaps they just used the Pi to reduce the time to market. I don't see what's wrong with that.
Because it's not AT ALL the right tool for the job. And it shows that they don't even have one remotely competent hardware person on the team. Yes, it can work, but even at retail it's too expensive, requires too much power, and has a vastly higher rate of problems than many other off the shelf, far cheaper and much more widely available products.
> ... Yes, it can work, but even at retail it's too expensive ...

Is it? $35 seems pretty cheap for an SBC that does what you need it to, with you having to do zero of the engineering work yourself. I think most industrial SBCs cost way more than $35.

> ... requires too much power ...

Pi 4 consumes 2-6W. [1] Scooter batteries are 400-600Wh based on a cursory glance, so we're talking up to two weeks of idle time. The scooter only goes 12-15 miles, and at 10mph, that's going to be a significantly bigger issue.

> ... and has a vastly higher rate of problems than many other off the shelf, far cheaper and much more widely available products.

Which products would you recommend, and also, do you have any data on the failure rates of the Pi? I'm curious.

Is it prefect? No, probably not. But if you only need a few thousand units, and you're trying to prove out the product market fit, why isn't this a great solution? Think of all the millions in capital they didn't waste building a custom solution. Personally, I respect the hustle.

[1] https://www.pidramble.com/wiki/benchmarks/power-consumption

With respect, your assumption here reads like a line from arrested development: “how much can a banana cost, $10?”

I really don’t think you have any idea of not the costs of these things, every penny counts with hardware products because any amount increases the marginal cost by at least 1.5x, vs software where it is so low it is effectively zero. I can get a very beefy STM32 for sub $10 at low quantities (sub $5 at > 1000) and toss all the passives and connectors needed for an extra $2-$4 the PCB may cost $1-$5, and you might be at $10-$15 depending on volume. You also can pre buy components that are known run out or design the board to accept different MCUs incase of shortages. With the RPi, you are totally SOL if you cannot find them, with your company being at the tail end of a, now, know volatile supply chain with a company you cannot get guaranteed fulfillment contracts with.

Your assumption about power is also very divorced from the reality of the situation, battery performance is not so easily calculated when your battery is not in clean room conditions, these scooters are subjected to extreme conditions and abuse, all of which can affect the battery. Additionally, It is disingenuous to consider only the operating parameters because it does run a full Linux system and software you load into it creates non-deterministic (at least with current models) situations where new software can skyrocket the power consumption. They also ideally have a separate battery from the drive motors so it can call for help and a tech can collect the scooter for maintenance.

The thing about the Pi is, since it runs an actual Linux os, you can take garden variety web devs and have them write code for it. You don’t need any esoteric hardware devs to fiddle all day with bits and writing drivers before they even start on the actual use case. That alone makes the Pi super attractive for startups.
Yes, that's the problem. I don't want a vehicle I'm relying on for my safety to be programmed by web developers and running an non-RT OS. Even if it's just doing remote management stuff.
Bad engineering (way overpowered board for the job), bad research (plenty of cheaper similar boards that do the same thing), bad economics as they chose the only supplier that doesn't sell bare chips, so that developing a cheaper personalized board is not doable. It was the wrong tool for the job since the beginning, and now it's also the overpriced nearly unobtanium link that inflates their production costs and can could bringthe product to an end..
if the RPi foundation didn't want commercial customers they wouldn't have them, it's not like these are being stolen from the hands of starving children

using a very cheap off the shelf linux board with great software support is a completely reasonable choice for corporations, too

Every company I’ve worked for used these types of boards to some extent, for R&D.
This isn't the fault of RPi as such. It's the fault of the whole embedded industrial SBC industry whose boards are expensive, long lead time, have awful software and are poorly documented.
Is there so much of a shortage of hardware engineering talent that these startups really need to be using hobby hardware?

I am not formally trained in electronics, but I managed to learn enough in the last year to design and manufacture my own PCBs for respiratory breath analysis with Atmel microprocessors. Essentially, they're like Arduinos but I also attached an off-the-shelf SD card reader and a bluetooth module. After that experience, I learned enough that I can simply build virtually everything into the board itself if I were to try again (which I'm still sort of in the process of doing).

Point is, the fact they're just using Raspberry Pis tells me that they barely know what they're doing. No reason why they can't design their own hardware to do the same thing but consume way less energy. What else do they truly need other than a basic microcontroller and a GSM module? GPS maybe?

I design my own boards too, but throwing a SOM into my layout is way too attractive to pass up, especially when schedule matters more than COGS.

Make-versus-buy decisions abound in product development. If you aren't a full stack electronics and firmware designer, then you have to manage the design project with its uncertainties, including schedule. A buy-in gets you moving right away, to address other project issues that require a prototype. You can always design it out later.

Dealing with complex chips often involves discovering bugs in the docs, and a second board spin to fix them. Then you'd better have a good scope and some real knowledge.

Despite its hobby orientation, the RPi is legit.

Sure but the added cost is not a big factor when you're making a handful of them.. If you're making tens of thousands though? Then it begins to add up.
10,000 @ $35 is $350,000 - that's really not that much money. That's like 1 to very generously 3 engineers for a year. Can you really design, build, validate, ramp, stock, fulfill and deploy your own hardware for less than that? I strongly suspect they ran the numbers and the answer was a hard no.

Not to mention the time penalty - as a rule of thumb it takes about minimum 6m average 12m to go from concept to physical units in people's hands at scale. These Pi's are shipping today. As a startup, that's hard to pass on.

And then the designer up and quits, leaving you with a sketchy and gratuitously complex design that nobody can fathom.

A volume like 10k puts you in a dreaded "in between" zone. You're not making a one-off widget that a customer is willing to pay an unlimited amount for because it solves a unique problem. And it's not enough volume to make something that just rolls off an assembly line. All of the simplistic mental models for how to proceed, don't work.

I work in such an industry, making specialized equipment. Every component is an expensive buy-in. It's ridiculously hard to find cost savings every component is up against the same math. Then again the competition faces the same problem.

> I am not formally trained in electronics, but I managed to learn enough in the last year to design and manufacture my own PCBs

How did you learn? I'm not formally trained in electronics either and would like to be able to do this.

I picked a somewhat easy project and paid an engineer I found online $20.00/hr over asking to do the design with me one on one over screen sharing in 2-3 hour increments. 2 weeks later a board was born.
What makes the RPi "hobby hardware"?
I'm referring to the OP's terminology, but it's also not entirely untrue. The intent of the Raspberry Pi was/is not to be a shortcut for tech startups who can't C++ their way out of a paper bag. It's also not like the Rpi has enough power to be of practical use to the average person, or even most atypical folks, hence it's more of a hobby or educational tool.
Interesting, but this has a hint of gatekeeping I would say. If someone makes a product and it's somewhat successful, who cares what it's built on!? The actual intent according to their website is

> Computing for everybody

> From industries large and small, to the kitchen table tinkerer, to the classroom coder, we make computing accessible and affordable for everybody.

https://www.raspberrypi.com/

I would say that's exactly what we're seeing here.

IMO every company, employee, or hobbyist should be able to buy the same number of Pis. Fulfilling orders of thousands for corporations while leaving individuals to fight over out-of-stock listings is not computing for everybody.
It's not that it's their business model to suffer from supply chain issues.
The second line of the raspberrypi.org website says "From industries large and small .. we make computing accessible and affordable for everybody."

If I wasn't personally involved in building something I'd generally assume the engineers were reasonable people making reasonable decisions.

> After pulling out of the market they leave their trash, that were assets a few days previous, scattered amongst the city as technological blight strewn across the landscape, left to rust.

Nothing in the source suggests these are “strewn across the landscape”. Your comment is basically made up outrage bait. I live in Seattle and walk a few miles a day and haven’t seen any abandoned Spin scooters.

You know, if I try to get into exactly what is wrong, the problem is way more about the entire world relying on a single proprietary design than anything else.

The availability of something everybody uses is entirely up to Broadcom right now. The pi foundation fixed the problem on the 2040, and maybe they will fix on the mainline some day, but the situation isn't optimal right now.

Raspberry Pis are commercial products made by a commercial company. They were out of stock, I believe, because of suppliers issues.

Now, I would agree that a Rpi 4 in an e-scooter seems overkill but if they are small and cheap enough, and easy to work with then why would you go to the trouble of finding a less powerful solution?

> they find a raspberry pi, an SBC created for educational and hobby purposes but has been infamously out of stock because

Because making a lot of money is more satisfying than supporting education and hobbyists. —- ftfy

That was my first reaction.. if that's true, what a waste..
Seems like your irritation is actually pretty rational.
> the city as technological blight strewn across the landscape, left to rust

You should get a job at the New York Times

> This all makes me irrationally...

I can tell