I've now played with a Raspberry Pi 400 for a week and here are my conclusions | Hacker News Reader

I've now played with a Raspberry Pi 400 for a week and here are my conclusions

316 pointsMarkusWandel219 comments

My brother gave me a Raspberry 400 (starter kit) because he knew I'd geek out on it and really evaluate it.

If you give it fast enough "disk" storage it really moves. I plugged in a Kingston brand 120GB SSD on a USB3 adapter. hdparm -t gave 292MB/s read speed and the default LXDE environment was really crisply responsive, with even a first launch of Chromium taking less than two seconds. With such good storage, the only real limitation is that heavy Javascript stuff is too slow - 5+ seconds to switch between folders in Chrome, or for the thumbnail gallery to appear in Youtube. Also, video calling is marginal. Aside from that the CPU is fast enough.

Then I accidentally yanked a cable. And the SSD was bricked. I was able to unbrick it again with the long-powerup-without-data-cable trick, but plainly this setup is too fragile.

USB boot is a game changer. A junk drawer 8GB USB stick works just fine, aside from the fact that it takes many minutes to copy the OS image onto it in the first place.

An old 60GB SATA laptop hard disk in the same USB3 case that I tried the SSD in is pretty good. About like a decent SD card, but without the scary wear/corruption issues. I can post the brand (Can$14 on Amazon) and the workaround needed for its broken (or at least Linux incompatible) UAS.

Bluetooth Audio actually works. In the typical use case, with this thing plugged via HDMI/DVI adapter into an old junk monitor, you can use additional clutter, like a $3 USB headset adapter and computer speakers to get sound or at least plug in a headphone. But if you have a bluetooth headphone or speaker, you don't need cables at all. I can post the recipe that worked for me for this.

View on HN

I understand why the Raspberry Pi uses SD cards (cost, simplicity, ease of use) but the entire line would be so much more useful with onboard eMMC storage.

SD cards are great for keeping cost down and getting started quickly by flashing OS images from a PC. However, enthusiasts spend so much time fiddling with external storage options and cobbling together messes of powered USB hubs, cables, external enclosures, and fiddling with kernel issues (USB attached SCSI) that a Raspberry Pi with built-in eMMC would be a breath of fresh air.

They could even keep costs down by adding a connector for an eMMC submodule, similar to what ODROID has done with their boards.

I browsed the datasheet [1] for the BCM2711 processor and did not see an eMMC controller on this part. Assuming the SD card is connected by SPI which would explain why it's so slow. Also rules out eMMC.

[1] https://datasheets.raspberrypi.org/bcm2711/bcm2711-periphera...

The physical layer for eMMC is SDIO- the same is used for SD cards, at least if you want more than ~ a megabyte/s of interface bandwidth.

IIRC the layers above SDIO are slightly different for eMMC and SD(HC), but generally SoCs that have SDIO interface support both types of memory.

The Raspberry Pi Compute Module 4 has eMMC.

Jeff Geerling benchmarked it and found it faster than his fastest SD card: https://www.jeffgeerling.com/blog/2020/raspberry-pi-compute-...

It's definitely not NVMe fast, but it's perfect for average workloads.

Weird. So the processor has an eMMC controller but they left that out on the datasheet.

The publicly-available datasheets for the SoC in the Pi are incredibly, and as far as I can tell intentionally, incomplete. The SD card controller is just one of the things lacking public documentaiton.

For those who don't know eMMC is basically an SD card that is soldered to the board

Why is that more useful than a removable SD card?

I think the comment was a bit tongue-in-cheek. The underlying storage tech between is the same, but eMMCs have a controller that handles the actual layout of the data. In a removable SD card setup, this is handled by the CPU, which of course has many other things to worry about. Having its own controller makes eMMCs more reliable.

"eMMCs have a controller that handles the actual layout of the data"

Maybe there is some part that eMMCs have that SD cards don't, but SD cards absolutely do have a controller that does layout (wear levelling). It doesn't do the filesystem layer, but IIRC eMMC's don't either.

AFAIK the only reason SDs are less reliable, is because they're cheap and the socket can be loose, causing corruption during a write (or wear level). It would be interesting if you know of something logically different that also makes them less reliable.

SD cards used to be optimized for usage patterns typical in a video or foto camera (big files, written at once). eMMCs are better adapted to serve as a traditional filesystems for e.g. phones.

Don't find source now though, so maybe I'm completely wrong.

That's true, I remember reading that somewhere too.

The main advantage of eMMCs in reliability is that you can't buy a RPi with a eMMC for camera use soldered on. You can have this same advantage by buying the right kind of SD cards (embdedded/industrial ones, or on a budget, overkill capacity "surveillance" camera cards that advertise wear leveling).

Then do we have "eMMC" equivalent quality SD cards that lasts just as long?

Yes, they're marketed as "industrial grade MicroSD cards" and are available via electronics component distributors like Digi-Key.

e.g. https://www.digikey.com/en/products/detail/swissbit/SFSD032G...

That costs more than the rpi itself!

is there anything marketed as "industrial grade X" that costs less than a rpi?

Drop the e and you have an MMC card.

eMMC has several advantages over microSD cards.

For example, the microSD slot only has 4 data lines. eMMC isn't constrained to the microSD slot, so they can have 8 data lines.

The Raspberry Pi 4 Compute Module has onboard eMMC. Jeff Geerling tests a lot of SD cards on the Raspberry Pi, but he found the CM4's eMMC is faster than any SD card he's ever tested: https://www.jeffgeerling.com/blog/2020/raspberry-pi-compute-...

I agree. I have run quite a few Raspberry Pi over the years and so many of them died because of SD card corruption. Eventually I got a NanoPC T4 with built in eMMC and it’s been tugging along for a good 2 years with zero issues.

I've never experienced this SD card corruption, even when power goes down to the Pi. I believe it happens, but I wonder what my unique circumstances are. Is it that I always use Samsung or SanDisk SD cards with the Pi?

Those will still eventually die due to log being written to the card using all available read/write cycles.

That's a problem that will eventually affect any flash solution -- SD card, SSD, or USB flash.

They usually just stop accepting writes (silently). It's a bit of a head scratcher at first. But at least it doesn't lead to a complete data loss.

You mean /var/log or filesystem log? What about using non-journaling filesystems or keeping /var/log on a ramdisk?

> Is it that I always use Samsung or SanDisk SD cards with the Pi?

Quite possibly! Flash memory is absolutely not all the same. I wish someone would do for SD cards what Backblaze does for hard drives.

> Is it that I always use Samsung or SanDisk SD cards with the Pi?

Oddly enough, Samsung, SanDisk, and Sony are the three brands I've had die on me. I had a GoPro eat two Sony cards in less than a year, I switched to SanDisk Endurance and it's been plugging along for about 2 years now. I've had one Samsung and a couple SanDisk SD cards die in Raspberry Pi's. I'm currently using MicroCenter, AData and one other lower tier brand that have held up much better than the name brands.

I've had a raspberry with SD card for more than 3 years now, still working fine. YMMV obviously

Had similar and switched to a cheap used desktop. I was running Home Assistant [1] and my guess is the constant writing of state history into the database slowly killed the card.

[1]: https://www.home-assistant.io/

> I have run quite a few Raspberry Pi over the years and so many of them died because of SD card corruption

The Pi themselves don't die because of a SD corruption. Only the SD cards do (and they can be recovered).

The Raspberry Pi 4 Compute Module has eMMC

The eMMC submodule works just as well as a SD card when writing it on another system, the submodule plugs into a small PCB with SD card traces on one end, you then plug the whole lot into a SD card slot.

It would be better if it had a built in fast flash of about 8GB. That’s enough to run the OS and do basics and if you want more, add it via one of the external ports.

3B+ forward has support for USB boot, as of I think July this year it was built into the firmware for the 4b. I have a Zw with SD card as it requires more or less but everything lese is USB based with drives I swap around for raspbian, ubuntu, retropi/etc. But setting that up does require an SD card with respbian unless the pi shipped with the newest firmware.

I'm not against on board storage but I understand the tradeoff to allow user expandability and reduce production costs. I think they'd get heat on the eMMC size unless it was like 32gb and I don't think that cost increase would make it very far. But maybe with the push to the 400 they will start to go that route to create a self contained but expandable system that is plug and play raspbian by default.

Personally I wish they'd add an m2 slot and scrap the SD card. It really is the bottleneck of the whole system.

But they walk a fine balance with PCB space, backward compatibility, performance, cost and user-friendliness.

m.2 slot is definitely the best long term issue for keeping costs down but providing a way for high speed. Now that they’ve switched to USB, I don’t see power draw as an issue any longer.

It depends what you want to do with it. If you want to use it for a mobile robot, run the Raspberry Pi off a battery, then yes, power does matter.

I suspect the power draw of a mobile robot would be dominated by the motors, would it not?

The motors aren't necessarily constantly on, and you don't need very big motors for a small robot.

The speed would be much better than an SD card, but nowhere near the peak M.2 performance we've come to love. The SoC they use only has a single lane of PCIe Gen 2. So 500 MB/s peak (MB, not MiB) with large transfers.

Throw in a PCIe switch or something so you can still attach a USB 3 controller and now you've doubled the price and power consumption.

If they add a m.2 slot now, at least it's already there for the next revision which they could improve the PCIe lane.

And hopefully that would ensure the new form factor to be somewhat stable for a while after that.

They could add a SATA M.2 slot, then it's equivalent to using a 2.5" SATA SSD but in a neater form factor.

500MBPS is already 1.5x SSD speed, so... I'd take it over SD any day of the week! Especially since at those speeds, you can buy just any random cheap m.2 and come out well on top.

What's really hindering responsiveness and day-to-day performance isn't going to be sequential read and write speeds but rather 4K random IOPS.

SD cards are not all designed or optimized around small, random reads and writes - the typical workload of a boot drive - and latencies can be staggering. Similar for USB sticks. On the other hand, these days the overwhelming majority of M.2 SSDs are at least somewhat optimized for 4K IOPS. The latest Sabrent Rocket M2 SSDs get some 650,000 4K IOPS vs eMMC at ~13000 (the Rocket is 50X faster) an SD card around ~2000 (the Rocket is 325X faster).

Frankly if you stuck a Sabrent Rocket on a PCIe 1.0 x1 connector the performance would absolute savage an SD or eMMC solution on this workload. Even if they somehow also had identical sequential I/O specs.

500 MB/s is more than enough for most applications.

Ack, why do away with SD slot? Sure add an nvme port that would be awesome but don't take away stuff, that's why we lost aux out on phones!

USB SD card readers are cheap, if you need one. Many hubs have one built in anyway.

SD card reading on the chip is also cheap, and doesn't require removing if you add an m.2 connector. No need to get rid of SD.

It might require removing to save on the physical space - an m2 connector requires a large amount of physical space compared to the SD card (for the retention screw). It might not have room for both.

So... that's fine, then? Telling people "you get an SD card connector and an m.2, you can't use both at the same time" seems perfectly reasonable to me. Have them overlap, done. Now people who want to use a $5 SD card with the slow speeds that come with that can do so, and people who want high speed but with the higher cost of a reliable m.2 drive instead can do so, too. No one loses.

yes but an sd card can be bought for less than 10 $/€, whereas an nvme disk would cost about the same price of the whole rpi.

you have to keep in mind the original goal of the raspberry pi project.

if you want nice performance and low power consumption, you're better off considering a cheap intel nuc.

Last time I checked, a NUC was considerably more expensive..

SSD: $20 for 128GB on Amazon

SD card: $15.20 for 128GB on Amazon

The price difference is minimal.

But the SSD is much much faster in that price range.

You're missing one of the very important aspects of a RPI is that it's cheap and accessible. Many countries around the world, particularly the poorer ones, don't have Amazon or ready cheap access to SSDs. What they do have access to is phone micro SD cards in adaptors. An 8 or 16GB card is plenty for a computer lab and is affordable and accessible.

Which country doesn't have access to SSDs?

They are saying that having an SD port allows people to spend less by using 8-16gb storage cards that are much cheaper than a 128gb M2 SSD. In many countries the RPi is already a big expense on itself and import taxes and low demand often inflate its price even higher. Same happens to other electronics, combined with the reduce buying power, it all adds up really quick.

SD cards are getting nvme in the future with 7.0 specification. I wonder how that will affect performance.

https://www.slrlounge.com/sd-express-memory-cards-pcle-nvme/

They could implement UFS 2 if they wanted higher speed.

The default intent, and thus the default configuration, is to have a device that a kid can accidentally nuke without any lasting consequences. That's the whole founding principle of the thing. Lose that and you've lost the Raspberry Pi as a concept.

eMMC isn't mutually exclusive with having an SD card slot.

Even if they removed the SD slot, you would still reflash the board over USB. That's how it's done with the Raspberry Pi Compute Module. With some software development it could be even easier than fiddling with SD cards.

In education environments, microSD cards tend to disappear a lot. Having one less moving piece to lose would be a win.

And having flashed cards ready to hand over is a win. "Factory reset" in the time it takes to swap a card. Your point? The Pi (apart from the CM) is for kids. It happens to be useful to other people as well, but that is not, was not, and never will be the aim of the Foundation.

Misplaced cards happen, but it does allow easier sharing of the boards.

It is when they have to build the thing for <$25 though.

> is to have a device that a kid can accidentally nuke

To be honest the large majority of RPi users I have ever met are only adults. Are there a lot of kids who are using it out there?

We would like the RPi more for education, but the cost is still a factor. Due to cost, the school need to buy these, as by itself the RPi is useless; It needed a keyboard, mouse, screen, etc.

Students bring their own SD card, since else they are easily misplaced (stolen). This also means boards can be used by any student.

A lot of effort and cost, so we went with the microbit. The kids can easily own them, use a tablet to program them, and for the kids that are older, they can go for the rPi to expand this setup and learn more advanced stuff. By we do not use this as an entry. Kids that do robotics have a better time with them.

So yes, maybe mostly used by adults. The idea of SD cards was a good one. But several flaws held it back; like the non-5v tolerant GPIO. Lost several boards due to misuse... And they ain't cheap if they need to be replaced often.

Do adults meet a lot of kids without adults present though? This seems like a bit of observer bias.

Yep. Kids don't tend to blog. Maybe brag, but still in a different scenario ;-)

Actually, yes. They're even good in a classroom because even if a kid screws one up, it's not hard to teach a public school teacher how to re-image an SD card.

You dont hear about it as often because for reasons, the kids aren't exactly encouraged to reach out to adults on the internet. Dogs on the internet and all that.

You sir, must have never played the IT guy to this teacher you speak of in our public school system. I challenge the “easy” assertion with great confidence.

/meant humorously but also seriously serious.

I think the key advantage of SD cards is they're easy to understand and use (once flashed). Conceptually it's simple to explain that the software lives on that little card. Want to change the OS? Swap the card. Plus it makes it easy for people who aren't comfortable flashing to buy a card with their OS of choice installed and ready to go.

PinePhone even has a great solution for the eMMC ease of use problem. The bootloader loads from eMMC by default (and I believe comes preloaded with a distro based on what version you bought) unless there is a bootable (micro)SD card inserted. There's a popular bootable SD card image for the PinePhone that exposes the eMMC over USB allowing flashing using `dd` or similar, which makes the whole process rather painless compared to the mess that is raspberry pi.

But cost is supreme in the case of the pi.

It's sort of like Elon Musk saying on Electric Vehicles: "We could make the car infinitely desirable, but if someone does not have the money, they won't buy it"

Just pull up https://www.raspberrypi.org and you'll immediately see "someone" is kids.

So I think the fiddling is a given, maybe part of the experience, and usually there's a payoff.

that said I'm not immune to wishful thinking. I think an expensive $150 Pi Pro that makes a profit would be cool. Think mini-itx, pcie, m.2 and memory slots PLUS gpios.

> and fiddling with kernel issues (USB attached SCSI)

That's actually a good thing, the raspberry pi community uncovered a ton of issues over the years related to storage drives over USB, which has been or can now be patched in the kernel to make such things more reliable.

Yes, I gave up on my rasp pi because of the instability of sd cards. It could barely run a few weeks without manual intervention. Honestly I have no clue how anyone does anything useful with them. Tried using usb attached ssd for a while, but never got it so stable that a remote reboot (or power loss) had acceptable risk.

I hear that many people are plagued with SD card issues. But I’m running probably ten raspberry pi’s right now and while I’ve had a couple SD card issues over the years, that has seemed to be the exception rather than the rule.

Yeah, well when running remotely it must come back by itself every single time, and I was unable to get reliable results over 6 months of testing. It might 3 months until I can travel and replace a nonbooting instance, and I will not even know what is wrong!

I disagree. When your eMMC degrades, your Pi turns into e-waste. With SD cards you get to enjoy the progress. In both speed and price per GB.

Why would you want eMMC? I'd rather not have to deal with broken eMMC. And non-upgradeable storage.

I got a pi 400 to replace a 2009 mac mini that was serving as the kids' computer but was struggling to play the online games they wanted (including scratch) because of missing webgl support in recent chrome updates.

Performance is roughly on par with the core 2 duo in the mini, but the graphics is more powerful and fully supported by webgl, so in practice it struggles less with the scratch environment and online games than the mini did. I would however not consider it snappy, it is quite sluggish to use chromium on it. I got both netflix and disney plus to work with minimal effort but disney plus is very slow to load, it takes almost a minute to fully pop up. It does play fine when streaming video.

The kids so far are quite happy and have been using it a lot more than they used the mac mini. It does everything they want (online educational games, some digital homework, and scratch), and they're not bothered by the sluggish loading of some sites. I think they also like the way it looks, it is a very fun looking little computer.

But why are you using Chrome in the first place - it's a known memory and CPU hog! Doesn't Firefox or other Webkit based browsers support webGL fully?

I don't understand what "memory and CPU hog" is supposed to mean here. Chrome runs faster than Firefox on every single ARM device I've ever used, and since the parent comment is explicitly about running a web app I would guess that nobody really cares if it takes slightly more resources to deliver good performance.

But the point is that the user isn't getting the expected performance and mentions Chrome specifically. So in this case using more resources on a constrained system is the main issue.

FF uses more memory on my system than Chrome now..

You can use cgroups to limit memory available to Firefox, and systemd-run gives you an easy path to do this.

How did you get Netflix to work with minimal effort? The 400 is still an ARM chipset, right? I know the "rip-arm-widevine-out-of-chrome-os" trick will work, though afaik the only automated way to accomplish this is via Kodi + the Kodi app at https://github.com/CastagnaIT/plugin.video.netflix

But I'd hardly consider that "minimal effort" in the general case. Did you find a better way?

Edit: also, Chrome itself. How did you manage that?

It’s chromium, not chrome, sorry for the confusion. I followed these instructions: https://blog.vpetkov.net/2020/03/30/raspberry-pi-netflix-one...

Cool, thank you!

I did some quick testing of IO games on mine and was quite disappointed, when even Slither.io cannot be played smoothly in a browser (a relatively simple 2D game) then the experience is quite underwhelming for a machine that has had this many iterations.

Anything web browser based is a disappointment on the rpi, and that's just it I think. Native apps work fine, emulated old games work fine etc.

I learnt to program on the ZXSpectrum with "Write Your Own Adventure Programs for Your Microcomputer" [0]

The RPi400 with Pico-8 seems to tick the same boxes, so I got one for my 10yr old. He's loving it. Perfect use case.

[0] https://colorcomputerarchive.com/repo/Documents/Books/Write%...

I wish there was a bare metal option that boots RPI 400 into a BASIC or Python interpreter the way the 8 bit machines used to

What do you mean by bare metal? Booting into python (or basic) would probably take less than 1h for someone who knows what they are doing.

There's a python/pygame/pygame_gui OS that does exactly this called snakeware. https://github.com/joshiemoore/snakeware Grab the rpi4 image and go.

Pick up a pocket chip for $40 on eBay- you have to click a single button after boot and then can start coding a game with pico-8 in lua.

Check out this thread:

https://news.ycombinator.com/item?id=18228740

RISC OS for RPi can do this. Not sure if RPi400 is supported just yet.

RISC OS Pico boots straight into BBC Basic:

https://web.archive.org/web/20181109020203/https://www.risco...

(IA link as it's been removed from the site, but the installer is still available via IA).

This is the correct answer. I've copied BBC BASIC games directly to a Pi running RISC OS Pico:

https://www.bencollier.info/projects/electronics/emulation/f...

To reiterate, the Pi can be made directly backwards-compatible with 8-bit games from 40 years ago. It's wonderful.

The Pi OS comes with Python installed, the pygame libraries, a bunch of games written in Python and of course the source code so you can modify them and create your own.

https://www.raspberrypi.org/documentation/usage/python/READM...

https://www.raspberrypi.org/documentation/usage/python-games...

It's not bare metal, but Python on Pi400 is great for kids.

Especially with side-by-side with a Minecraft window and the Minecraft Pi Edition python integration.

Also, there's a whole lot of little boards that support Micropython, and boot straight to it, including ESP32 etc. I use them in the classes I teach.

Wasn’t Minecraft Pi Edition discontinued years ago? Minetest on the other hand might be a great intro to programming with its Lua script mods, and also has always been designed for modest hardware.

https://www.minecraft.net/en-us/edition/pi

Appears to still be available

But not updated in ~7 years since v0.1.1

https://minecraft.gamepedia.com/Pi_Edition

Yah, it's discontinued, but it works fine and is still distributed. It's a fine path to write some code and interact with a working game world.

Yah, it’s technically functional, but there’s an actively maintained alternative that can support such advanced features as spawning mobs (like, say, the mascot in Minecraft’s logo).

These Usborne (and other) books were fantastic!

one of my colleagues uses that as an assignment for his students, they have to port one of the listings to c++

I got my start with a Spectrum and that book too. Far less luck interesting my kids in computers though.

Sounds like a neat bit of kit. For anyone unfamiliar, it's essentially an ARM-powered PC, in the form factor of a keyboard. [0]

> I was able to unbrick it

I know it's a nitpick, but if it can be repaired, it's not bricked.

[0] https://www.raspberrypi.org/products/raspberry-pi-400-unit/

From recent usage of the term 'bricked' here on HN I think those of us who consider bricking to at least require use of JTAG to alleviate to have lost the battle.

I suspect few people on HN have truly experienced a "bricked" device in their lifetime.

To you and me:

Static electricity from the carpet discharging into the joystick port of a Commodore 64? Bricked.

Yanked a cable from my Raspberry Pi and had to reboot in an unconventional manner? Not bricked.

I thought the same thing about an earlier post when someone said their MacBook Pro with a T2 chip was bricked. Something messed up and they had to use a special boot procedure while they were connected to another Mac to reflash the T2.

People were up arms but I call not bricked!

"Static electricity from the carpet discharging into the joystick port of a Commodore 64" Changing the CIA chip will fix the machine.

In my head at least, that’s a pretty good determinate of “Bricked”

Does it require a soldering iron to fix it?

No. Not “bricked”

Yes. “bricked”

(But I also totally accept that technical people are going to lose the language war here, same as when I used to rant about rc quadcopters not being “drones” since they’re not autonomous.)

To some people, soldering isn't a big deal.

To others, having to do a full drive reformat may be as intimidating as using a soldering iron.

Contrast to the second point, where non-autonomous quadrocopters are emphatically not "drones". Unless you consider the IMU and feedback loops that keep it level "autonomous", since it is technically some degree of autonomy...

Anyway, I'd be a little more specific and say something is "bricked" when it cannot be repaired with the speaker's skill level or equipment.

Ultimate bricking would be frying an IC with e.g. heat or ESD. Good luck removing those few hundred atoms shorting something inside.

Do we really have to have the “bricked is relative” argument again?

Edit: To be more constructive, how about a definition for “bricked” as “unable to be recovered by the intended users of the device through reasonably expected efforts.”

Seems to me the word has a clear sense of permanence built into it.

The term arose because a brick cannot be transformed into functioning electronic equipment. A device is said to be bricked when it is no more useful than a brick. If you drop your smartphone into water, and it shows no signs of life even after a couple of weeks of drying, you've bricked it.

The average user is not competent at repair, as that's a specialized skill. They might not know what to do with a laptop if you blanked its SSD, but we wouldn't call that laptop bricked.

> The term arose because a brick cannot be transformed into functioning electronic equipment.

This makes term "bricked" somewhat theoretical, as in practice almost any state of electronics can be turned back to functioning. In extreme cases you'll have to replace vital parts (if imagination forbids actually fixing broken microchips with a lab equipment), but in many cases it's still possible.

You're essentially using a sorites paradox/Ship of Theseus argument to attack the idea that a piece of electronics can ever, even in principle, be said to be 'permanently broken'.

In common usage, we consider 'permanently broken' to be meaningful, we draw the line somewhere reasonable, and don't worry too much about giving a legalistic precise definition. I think my earlier examples stand up ok here. The phone is bricked, and the laptop is not. There may be edge cases where it might not be clear whether we can say whether a device is 'bricked' or not. That's not a problem. There might be an edge case in furniture where it's not clear if it's a chair or a table, but the categories of chair and table are still worth keeping.

...anyway it looks like a promising ARM-based computer ;-P

I think we'd agree that term "bricked" is somewhat relative. Different people can define it - slightly or not - differently, which of course makes communications more difficult, yet for now that's where we are. The point was that the original nitpick can be questioned.

> You're essentially using a sorites paradox/Ship of Theseus argument to attack the idea that a piece of electronics can ever, even in principle, be said to be 'permanently broken'.

Dude, setting aside the argument itself, I never expected to see the Ship of Theseus busted out to win an internet debate... well done!

In the proud tradition of people lacking a formal education in philosophy, I think I got it slightly wrong - the continuum fallacy is the better fit.

Surely a typical brick contains a significant amount of silicon and sufficient trace amounts of germanium/boron/phosphorus to dope it into useable semiconductors...

(That’d make for an awesome YouTube channel project. How I melted down and refined a brick into pure enough elements to make semiconductors and working electronics, in my backyard... I’d totally subscribe to that Patreon.)

Working title: Bricks into bits, or Bits of bricks.

> The term arose because a brick cannot be transformed into functioning electronic equipment.

I've got a dictionary full of terms for you that arose from one concept to mean something else. Literally. Also figuratively.

Just because people can, or have, redefined things illogically doesn't mean they should.

I fully support efforts to gently nudge deviations of the vernacular toward reason and rationality, especially before it it crystallizes into some abomination like "literally" has become. That way lies muddy thinking, and madness.

The price of language-reality congruence is eternal vigilance and kindhearted pedantry.

Yah, but let's leave some room for some meaning to evolve and not be some kind of robots based on historic meaning and roots.

E.g. It's OK for "decimated" to mean "destroyed/removed a sizable part of" and not "killed precisely 10% of".

It's also OK for us to disagree on when the exact place an object becomes no more useful than a brick and to think that this could be a gray area. To me, something is slightly/soft bricked when it requires specialized, non-garden path recovery procedures to fix (e.g. a firmware flashing tool). It is hard bricked when it requires tools and processes only usually found in depot maintenance or manufacturer facilities, even if my home workshop happens to be capable of these things.

Of course, this means some things that are hard bricked could become soft bricked or even not bricked at all, if the manufacturer releases a tool or updates the normal software to deal with a situation.

So if Ring fucks up my doorbell's firmware, in a way that I can't fix it...

But they have tooling on one test bench somewhere that could load new firmware and bring it back to life...

Is it bricked?

Is it bricked if they release those tools, but they require specialized repair skills?

Is it bricked if they release those tools and it's easy?

The existence of tricky edge-cases does not show that the categories are meaningless. Please see my response to avmich's comment.

I'd seen your response before. I didn't find it informative.

To me, bricked means "requires exotic recovery procedure (or more) to repair." Existence of tooling in one manufacturer lab doesn't make something not "bricked". Releasing that stuff to the public makes it "soft bricked". Making it so that an ordinary user can do it makes it "not bricked anymore". When we say something is "bricked", the permanence is unknown.

Sitting with the drive powered for an hour without a data connection to let its firmware do internal housekeeping and maybe have the drive come (partially?) back, in an undocumented recovery procedure, is definitely somewhere murky on this spectrum.

> Existence of tooling in one manufacturer lab doesn't make something not "bricked".

I didn't say otherwise. Again you're attacking the idea that 'permanently broken' is meaningful.

You've shifted from attacking the term 'permanently broken' as unworkably imprecise, to attacking it as unknowable. Neither holds water. In real-word use, we just make do. It's not practical to give perfectly precise legalistic definitions.

We'd all agree that a severely water-damaged smartphone counts as permanently broken, and as bricked, regardless of whether it would be possible in principle for the device to be repaired at great expense.

> Releasing that stuff to the public makes it "soft bricked".

I agree that the availability of tooling can impact whether we consider something permanently broken. A failed hard-disk in an old games console might be enough to write off the whole machine, if the machine is hostile to replacement hard-disks and official repair services are no longer available (and their special tooling/software not made public). A failed hard-disk in a desktop computer, though, can easily be replaced.

> definitely somewhere murky on this spectrum

Again, of course there are edge cases. This is true of just about any categorisation we use, outside of mathematics. To refer back to my earlier example, it's not possible to give perfectly precise definitions of chair and table, but this doesn't much matter, the terms are still useful.

I think most agree anything not readily fixed by normal, known procedures is "bricked". But most things we call this are not really permanently broken (and we might be surprised to find some of them to be trivially recovered).

I don't really hear "bricked" in use for things damaged mechanically or by water. It's usually in conjunction with a failed upgrade, etc. Almost none of these things are really permanently broken, though some of them for practical purposes may be.

Well if bricking is permanent, then it's only bricked if it falls into a black hole; and in that case I vote that we change the term to "holed", because at least that is a term that's worth being misused, unlike "bricked".

You're attacking the idea that 'permanently broken' is meaningful.

avmich already did this, and it doesn't hold water. Please see my response to avmich's comment.

Maybe extend your definition to include "... with the tools available to them", something may be recoverable with a JTAG programmer.

In my opinion if the fix is not know at the time it could be considered bricked, at least temporarily until the fix is discovered.

How would you called a device that meets a fate like that? Stuck? Blocked? Unaccessible?

I agree; I think bricked is a fine word for this, even if it's reversible. Once you give up it's permanently bricked.

Whether you agree or not, it's incorrect. Common usage of "bricked" has been one thing and not the other for many years.

If you claimed to have bricked something a hundred years ago everyone would expect a wall. Meanings change.

You're illustrating a chance in context, not a change in meaning.

Does this not assume that ‘bricked’ means walled out and entry is blocked?

The word appears to originate from the idea that a device has been turned into a brick. This seems a new meaning to me, as ‘bricked’ isn’t a word that previously meant ‘to turn the thing into a brick’.

https://english.stackexchange.com/questions/488450/etymology...

https://en.m.wikipedia.org/wiki/Brick_(electronics)

From wikipedia brick(electronics) is quite relevant that bricking is not necessarily permanent.

Some devices that become "bricked" because the contents of their nonvolatile memory are incorrect can be "unbricked" using separate hardware (a debug board) that accesses this memory directly.[5] This is similar to the procedure for loading firmware into a new device when the memory is still empty. This kind of "bricking" and "unbricking" occasionally happens during firmware testing and development. In other cases software and hardware procedures, often complex, have been developed that have a good chance of unbricking the device. There is no general method; each device is different. There are also user-created modifier programs to use on bricked or partially bricked devices to make them functional. Examples include the Wiibrew program BootMii used to fix semi-bricked Nintendo Wiis, the Odin program used to flash firmware on Samsung Android devices,[6] or the fastboot Android protocol which is capable of reflashing a device with no software installed.[6]

"bricked" is a spectrum, and not something with a clear line meaning only some things.

With enough resources, one could fix almost anything. So what's enough to be bricked?

* Configured badly in a way that could be fixed in just software, but in a very unintuitive and undocumented way?

* Firmware overwritten with broken firmware, requiring special software and images to fix/update?

* Firmware overwritten with broken firmware, requiring you to open the case and attach a serial cable to a hidden connector fix it?

* Firmware overwritten with broken firmware, requiring you to attach thin test wires to a flash chip and bit-bang flash programming sequences?

* Firmware overwritten, requiring you to lift and replace the flash chip.

* Broken hardware components requiring extensive rework?

Whether something is irrevocably bricked or not depends upon what tooling, documentation, and skills you have. Someone releasing a new tool that makes it easier to recover/unbrick doesn't make it not have been bricked in the first place...

Like most things, it’s even worse than some people realise.

I know people who refer to their phone as “bricked” when the battery is flat.

"I thought I had bricked it, but..."

Soft bricked vs hard bricked. There are recovery procedures (possibly intrusive or troublesome) for soft bricked.

As an example, if I have a network device so screwed up that I have to do a little power and connection dance to get it to reload via tftp, I'd call that a soft brick. If I have to solder in jtag pins, that's pretty firm. If the magic smoke has come out, that's definitely hard.

Skype is not possible at this time. I tried 32 and 64 bit OS images, Chromium and Firefox. All are browser not supported, or it works but then doesn't make any attempt to use the webcam or a microphone (even the setup menu entry for this is missing). This being a web app, it could of course change any time. The other stuff that I tried - Zoom and Google Hangouts - worked, just not fast enough for good frame rate.

A modern computer should have suspend/resume. This doesn't, but all kitted out with accessories - 7 port USB hub, USB headset, spinning laptop hard disk - it idles at 6-7 watts, plus it boots fast and shuts down almost instantly, so that's not a big issue.

Now for a list of things that I think this is good for:

1. As an accessory to the family TV - for online video that the "smart TV" is too dumb for, for games and such.

2. As a classroom computer, with a few sample setups.

2a. Overlay mode (i.e. immutable SD card image and no wear) and everyone uses the same generic userID but then logs into their own google account.

2b. Overlay mode, immutable SD card image and everyone brings a USB stick to store their data on.

2c. Completely diskless mode, everyone has a USB stick they boot from (this works very well even with a typical slow USB stick).

2d. Completely diskless mode, PXE boot from a server (needs gigabit wired ethernet for adequate performance)

2e. Like 2c but with NFS home directories. This needs some sort of centralized account management.

Practical as that is, probably Chromebooks are too well established for this to get any traction.

3. As the standard experimenter's Raspi. Costs about the same as a Raspi4 with a good aluminum fanless case, so you get the keyboard for free.

4. As a small NAS/DVR/whatever server node. Same as 3. You get Raspi4 performance and passive cooling for about the same price but a free keyboard.

5. As an extra homework/Youtube/whatever screen in a screen-constrained budget conscious family. Get a $10 monitor from Craigslist/Kijiji, a $2 HDMI/DVI adapter for it and you're off. Except for the sound thing; suggest Bluetooth for minimum clutter for that.

Really a practical little machine, comparable to a decent 10-12 year old laptop with an SSD upgrade.

That's a great review, keep'em coming, people!

1080p video playback is pretty decent. Youtube in Chromium or Firefox is mostly perfect but plainly with some frame drops. A h.264 encoded .mp4 file at that resolution, played with mplayer, is rock solid. VLC too, except mysteriously, it currently gives a black screen when set to fullscreen.

> This explains the cost, but why are they supposed to be more buggy? Should you have time to test those individually if there's just a small number of them?

I had to set my user agent to Windows/Edge to make it work in Firefox. However, I can't remember if the audio/video worked.

> I plugged in a Kingston brand 120GB SSD on a USB3 adapter.

> Then I accidentally yanked a cable. And the SSD was bricked.

People who are going to use this as as their setup ought to buy a real, fast USB SSD, instead of relying on SSD drives plugged into adapters. They're engineered to deal with stuff like this and they're fast. (the Samsung T5 and T7 both benchmark even faster than what you saw, well above 300MB/s)

I think the limitation is the raspberry Pi which has no sata or m.2 interfaces. That's why they used a drive with an adapter.

OP mentioned USB SSDs, not SATA/M.2 SSDs.

Would be nice for the next Pi to have an M.2 slot tho...

Accidentally unplugging an SATA or m2 drive will have similarly awful results.

> And the SSD was bricked. I was able to unbrick it again with the long-powerup-without-data-cable trick...

What's the long-powerup-without-data-cable trick, if that's not a stupid question? Sounds like a useful thing to know!

I was wondering the same as I have an SSD I used as an external usb drive that has stopped working. I've never heard of a drive getting bricked much less there being a way to resolve it. I was assuming a permanent hardware failure of some kind.

Check this out, I hadn't heard about it either but am testing it on a ssd now.

https://dfarq.homeip.net/fix-dead-ssd/

Great article, thanks!

I have been playing with a Raspberry 400 for couple of days now. I thought of recommend it for my nephew, but couldn't do it because of the following drawbacks.

1. Lack of 3.5mm audio jack or built-in microphone/speakers 2. Unable to run Zoom reliably

Given that schools are closed (at least in India) and classes are happening over zoom, these two drawbacks makes it a no-go for my use case.

Good point. Audio from a 3.5mm jack would add little to the cost, and also keep down headphone cost. Also, most monitors have really shitty audio. Boo.

"Getting audio out of the Pi 400 was a bit of a challenge; it defaulted to attempting to deliver audio over HDMI, and Raspberry Pi OS' audio control dialog isn't the best. Even after changing the output device to USB Audio (my gaming headset), YouTube wasn't producing audio—and there's no "test" button I could find in Pi OS, like the one in Ubuntu's audio-control dialog. Closing and reopening the browser entirely after changing the output device resolved the issue, and audio played from the headset fine afterward." https://arstechnica.com/gadgets/2020/11/raspberry-pi-400-the...

My experience has been fine. Whether with the default audio device picker (which doesn't work correctly once you've installed PulseAudio) or PA's own "pavucontrol" selecting output device is snap. Sometimes you have to restart the audio-producing program to use the new selection, which is a feature, not a bug - you could have different programs use different audio devices at the same time.

So to get the usual 3.5mm jacks, just buy a cheap USB/analog headset adapter; about $3 from Ali Express. Select as input and output, and done. Microphone is usually not an issue if you're using a webcam since most have an adequate one built in.

Would you be able to output audio or have a audio/headphone/headset jack via a monitor over HDMI? Bluetooth is also an option but would require a headset and setup to work well I think.

One thing I discovered using the Raspberry Pi is that Linux is constantly writing to the SD card, and it's very hard to stop this behavior, even if you turn off file system timestamps, disable logging, etc.. Cutting the power or resetting the Pi seems to result in relatively frequent data corruption, and I've also ended up with several unusable SD cards.

However, switching to a read-only SD card and a RAM file system seemed to eliminate the file system corruption and SD card damage I'd been seeing in my Raspberry Pi-based design. No problem with power cycling the thing.

This is going to sound like a meme, but seriously: install gentoo.

“Linux” doesn’t write anything to the filesystem, but various helper utilities do, and this has become more true with systemd-journald.

I have been debating a Pi400 vs a Pinebook Pro as an Xmas gift for a 10-year-old. The Pi400 looks great except that it doesn't support a webcam+microphone(+audio out?) out of the box and attempts to find an HDMI monitor with these things built in and supported by the Pi have thus far been unsuccessful. Is it odd to be considering a Lunux laptop for a 10-year old? The open source ethos of both machines, seems ideal for this use case.

I don't think a Pinebook Pro has a 40 pin GPIO header, so the possibilities for interacting with the outside world are limited and thus fun is severely reduced.

The Pinebook Pro is pretty temperamental when it comes to things like battery management & performance.

The Pi has more memory, more computing power, and is more reliable.

Get him a Pi, and if he needs a laptop, pick up a used Thinkpad to go with the Pi.

Source: I own both a Pi 4 & a PBP.

I don't think the Pinebook Pro will be in stock until early next year.

I also got one. Really like the physical form factor and the keyboard.

I don't think something like this is ideal for running a full-blown Linux/Chromium/Firefox desktop environment though - it's just too slow for the bloated web sites of today. And using a mouse isn't exactly "sit-in-front-of-the-tv" friendly.

I like the idea of running something like BMC64 ("a bare metal C64 emulator for the Raspberry Pi with true 50hz/60hz smooth scrolling and low latency between input & video/audio") but unfortunately it doesn't work on the Raspberry Pi 400 yet.

You can get relatively inexpensive wireless keyboard/trackpad combos. Generally they come with a receiver piece that ties up a USB port.

I've been looking at either the pi 400 or or one of the pi 4 starter kits. For around the same price as the 400, I can get the 8GB pi and a full kit of accessories.

But, I really like the idea of having everything just built into the keyboard.

In your experience was the 4GB of RAM on the 400 reasonable?

Ever since the 400 popped up on here i've been looking into both of them. I just worry the 400 lacks more long term versatility than a straight pi 4 with a kit.

Any thoughts on this?

1. The 400 is faster than the 4 OOTB, and can be overclocked easily. 2. The 400 runs much cooler. 3. 4GB is plenty ;)

There's a dead comments that's saying exactly what I'll say: The 400 uses a slightly different chip that can be overclocked to 2.2 GHz while the regular Pi 4 can't really go above 1.8 if I recall.

More info here: https://www.jeffgeerling.com/blog/2020/raspberry-pi-400-tear...

EDIT: The comment I was referring to has been restored!

Hmmm that doesn't seem true

https://www.seeedstudio.com/blog/2020/02/12/how-to-safely-ov...

Is 4GB of RAM reasonable? Of course not. We all need to have six hundred browser tabs open and the browser weighing in at 20GB+. Just kidding. For the sort of browsing you'll do on a Raspi 400, 4GB is plenty at least in my experience.

Fair enough...I suppose, does it make a noticable difference would have been better wording.

You mentioned an external SSD and a microSD, but there's a nice inbetween option of using a thumb drive, like Samsung's FIT drives[1] where it's just a nub sticking out of the USB port. You get better performance than an SD card, something that can arguably get "SSD-like" performance in short bursts, and you don't have to jury-rig an external SSD to the Pi. Doesn't offer the same durability as a full-size SSD but might be good enough (and cheap enough to try IMO).

There's also endurance microSDs made for constant writing -- and I bought one for my current Pi 4 -- but I don't have enough experience with those to say whether it solves the Pi corruption issues.

[1] https://www.samsung.com/us/computing/memory-storage/usb-flas...

> Then I accidentally yanked a cable

USB-C is so outrageously bad in this regard. I have a smartphone on my desk, connected via USB3 for debugging. At some point it started reconnecting if I just slightly touch the phone or cable, which is extra fun if it happens mid-deployment.

Check for pocket lint or other debris in the socket. This exact thing was happening to me, a minute with a toothpick fixed it.

Will check, but it's unlikely since both the phone and cable only ever sit on this desk. It's a pure debugging device.

Hot glue it in place? It's going to provide enough strength to keep the things attached, but still will be easy to remove if needed.

I think USB-C is designed to have the connector on the cable fail first, so maybe you can try to replace the cable?

My testing phones (that sit on the table like the OPs) eat cables like popcorn. I never buy less than 3 cables at a time.

Maybe it's the too-stiff cables. As devices have become smaller, lower mass, our cable rigidity, thinness has not scaled proportionally.

I'm burning through something like 10-20 usbc cords a year. It's outrageous. I'm buying Ankers and "good" brands too. My car has ubsc to usbc and android auto and it used to be a pain (usba to usbc slowed it down) so I'm diligent about fast/good cables.

I have no working usbc-usbc cables right now. It's wild how quickly mine go bad and most of the time they're just plugged into a phone once a day (driving), if that.

I just have a drawer full of dead cables with some sort of usbc end..

You may be able to get the Anker cables replaced for free, some have a lifetime guarantee.

I have one sitting here in a box that I'm planning to set up my 2 year old toddler with. He loves using my computer, so I'm hoping to put on some typing and other simple games for him to use. Goal is to connect it to an older monitor so he can "work like Diddy" and get him into real computers vs. the iPad.

He's already able to type letters & numbers on the keyboard since he can read them, so it should just amplify his learning.

And yes, he gets plenty of regular playtime outside and inside. He spends hours outdoors. It's mostly going to just "be there" to use as he pleases, especially with the upcoming cold weather and lockdown.

I just spent a few hours fiddling with my new pi4 yesterday. Is it possible to get them to boot from USB without first setting it up to boot from SD and then cloning the disk? I'm guessing not since I think it has to flash some settings to the EEPROM, not just make changes to /boot.

I was following this guide and couldn't even get these steps to work: https://www.tomshardware.com/how-to/boot-raspberry-pi-4-usb

It seems they recently changed[1] the default boot order to SD Card followed by USB Mass Storage, from just SD Card.

Of course if you get an Raspberry Pi made before this became the default then you're SOL.

[1]: https://www.raspberrypi.org/documentation/hardware/raspberry...

Are those settings in hardware, or the EEPROM?

This is the EEPROM settings.

But once I figure out how to properly flash it, I should be able to boot from a freshly created USB drive, without having to clone from SD?

Yes exactly, the EEPROM stores the settings rather than the config.txt file on the SD Card as with earlier Pi's.

I think all I had to do to get it working, now that the USB boot feature is out of beta, was to boot Raspberry Pi OS from an SD card and do a normal "apt upgrade". This automatically downloads and updates the firmware[1].

After that (and possibly rebooting?) I could run raspi-config and enable USB boot[2] there.

[1] https://www.raspberrypi.org/documentation/hardware/raspberry...

[2] https://www.raspberrypi.org/documentation/configuration/rasp...

But that still requires an SD card to bootstrap the process...

Yes, once, during setup. But you need to run raspi-config anyway to change the settings, so you need to boot into Raspberry Pi OS somehow even if you're going to be installing something else on the USB drive.

I'm fine running rpi OS, but it would be nice to be able to boot straight into USB without having to do SD first.

The Pi 400 is new enough to have USB boot already in it. At least mine did; the boot loader version was considerably newer than what is needed. Just dump the OS image onto a USB stick or an external hard disk, it'll boot.

Awesome, confirmed! I've had mine for a week and didn't think to try this.

"Back in the day" I managed a fleet of X terminals. Some were purpose built X terminals and some were old repurposed Sun 3/50 or 3/60 pizza boxes.

I also ran a bunch of servers where they booted off of a small internal disk and otherwise lived entirely off of NFS.

It all ran "just fine" on 10bt.

Get off my lawn...

One of these things seems ideal for "diskless" operation, especially if used in a lab setting.

Thanks for the review. I’m considering buying one for a set top box. Would it be powerful enough for that? Can it pull 4K video?

>USB boot is a game changer. A junk drawer 8GB USB stick works just fine

As an aside, why isn't there a market for a say 10gig usb medium that isn't flakey AF like microsd etc that die if you squint at it a little too hard

USB enclosure and an actually SSD seems like the cheapest option. There has got to be a middle ground here...

USB3 to M.2 adapter?

Also high endurance SD cards are an option.

> Then I accidentally yanked a cable. And the SSD was bricked. I was able to unbrick it again with the long-powerup-without-data-cable trick, but plainly this setup is too fragile.

What's the nature of this phenomenon? Why does it happen to Raspberry Pi but doesn't happen to classic x86 systems?

Definitely an upgrade from your MP3 player! http://wandel.ca/homepage/jukebox.html

Always have been a fan of your site.

I have one as well, and my experience with BT speakers is odd: It works fine in VLC, but not in Chromium or any of the pre-installed games.

I used PulseAudio and removed "bluealsa". So far it's worked fine with everything. Unfortunately the standard LXDE volume/device selector icon doesn't play nice with PulseAudio so I have to use pavucontrol for that. The standard audio icon does pairing very well; by comparison "blueman" isn't as good.

Can the 400 receive a bluetooth signal and act like a remote speaker? Specifically is the bluetooth hardware capable of that?

The ordinary raspberry pi can, so I would be very surprised if the 400 couldn't.

I challenge anyone to run SolveSpace CAD software on one of these. It should be quite fun.

Being a small and light application I thought the new Occulus Quest would be a great platform for SolveSpace.

Interesting. I assume that would mean interacting with the 3D model in some way. That could be fun - grab a vertex and move it around. It would require some changes to copy the model (and sketch entities) into the VR world since it can't maintain that kind of framerate while the geometry is changing. A voice interface for simple commands like adding dimensions would make it rather like the holodeck.

I would love to see them drop all connectors except for USB-C and an M.2

ahhh I'm eagerly awaiting this to come out!

Adafruit and PiShop don't have it yet :/

I ordered one from SparkFun. They are out of stock now but they did ship mine and I will get it next week.

I bought mine from https://www.canakit.com/raspberry-pi-400.html right after release and it showed up quickly (IIRC shipping was from Vancouver).

Ordered from SparkFun a few weeks back when they were announced — mine showed up a week ago.

Reply on news.ycombinator.com