Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

141–150 of 222 posts

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

#141

Post by musicale »

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.

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

#142

Post by cptskippy »

bitwize wrote: post #105
iddqd wrote: post #34

Earlier quoted context omitted.

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?

> 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.

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

#143

Post by makomk »

castratikron wrote: post #109
PragmaticPulp wrote: post #78

Earlier quoted context omitted.

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.

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

#144

Post by puzzlingcaptcha »

shiftpgdn wrote: post #107
bitwize wrote: post #105

Earlier quoted context omitted.

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.

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

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

#145

Post by mlyle »

abraxas wrote: post #27
jops wrote: post #15

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

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.

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

#146

Post by ekianjo »

stan_rogers wrote: post #89
PragmaticPulp wrote: post #24

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…

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.

> 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?

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

#147

Post by ekianjo »

iddqd wrote: post #34
PragmaticPulp wrote: post #24

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…

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 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).

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

#148

Post by mlyle »

johnklos wrote: post #20
zbrozek wrote: post #16

Earlier quoted context omitted.

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.

"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...

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

#149

Post by HorizonXP »

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.

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

#150

Post by mlyle »

MaxBarraclough wrote: post #39
taneq wrote: post #12

Earlier quoted context omitted.

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 spe…

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?

Post reply on HN