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

101–110 of 222 posts

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

#101

Post by magicalhippo »

anderspitman wrote: post #95

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

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

#102

Post by 8bitsrule »

anandology wrote: post #75

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

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

#103

Post by CarelessExpert »

MaxBarraclough wrote: post #54
avmich wrote: post #47

Earlier quoted context omitted.

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

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

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

#104

Post by anderspitman »

magicalhippo wrote: post #101
anderspitman wrote: post #95

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?

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

#105

Post by bitwize »

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

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

#106

Post by Joeri »

chias wrote: post #98
Joeri wrote: post #28

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

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

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

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

#107

Post by shiftpgdn »

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?

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

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

#108

Post by CharlesW »

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?

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

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

#109

Post by castratikron »

PragmaticPulp wrote: post #78
castratikron wrote: post #30

Earlier quoted context omitted.

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

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

#110

Post by ed25519FUUU »

m-p-3 wrote: post #79
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…

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.
Post reply on HN