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

181–190 of 222 posts

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

#181

Post by bigiain »

sbassi wrote: post #152
reaperducer wrote: post #60

Earlier quoted context omitted.

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.

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

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

#182

Post by bigiain »

avmich wrote: post #47
MaxBarraclough wrote: post #39

Earlier quoted context omitted.

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…

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

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

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

#183

Post by bigiain »

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.

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.

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

#184

Post by gbraad »

lsiebert wrote: post #165
ekianjo wrote: post #146

Earlier quoted context omitted.

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

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

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

#185

Post by tachyonbeam »

ed25519FUUU wrote: post #110
m-p-3 wrote: post #79

Earlier quoted context omitted.

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.

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

#186

Post by arcticbull »

Teknoman117 wrote: post #116
m-p-3 wrote: post #79

Earlier quoted context omitted.

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.

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.

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.

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

#187

Post by arcticbull »

tachyonbeam wrote: post #185
ed25519FUUU wrote: post #110

Earlier quoted context omitted.

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?

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

#188

Post by m463 »

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…

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.

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

#189

Post by webmobdev »

stonogo wrote: post #48
webmobdev wrote: post #45

Earlier quoted context omitted.

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.

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

#190

Post by craftinator »

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…

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