The Pi5 is quite reasonable, and the Pi 500 by extension, but I just have two things that I wish they’d fix:
I wish the NVMe port was populated. The Pi 5’s desktop performance feels massively better with a cheap NVMe drive compared to a microSD card.
It would also be much better if it worked with full functionality with an actually standard USB-PD power adapter instead of requiring a custom 5V 5A adapter. The whole point of USB-C and USB-PD is reusability. Instead, for the Pi5/500 I have to buy a dedicated USB power adapter rather than using the existing 45W/65W/100W ones I already own.
I believe there would be a market for themed keyboards designed after vintage computers with RPi module carrier boards. This is kind of the heir of the BBC micro and if love one with a black top, white bottom, and red function keys.
Clockwork Pi has one modeled after a TRS-80 Model 100, but it's a bit too small. A full sized Model 100-like would be super cool.
Can it play youtube videos without saturating the resources yet?
This was a major problem with Pi 4/400, I had to resort to quite an extreme overclock and some hacky custom browser builds to improve this. Bought it for a family member new to computing. I was put off so much of the 'pi as a basic desktop computer' that I wouldn't buy another for this usecase. Never did make sense to me why it struggled so much with a quad core SoC that should have been able to handle it.
First thing I do on an SBC now is to see what resources are consumed playing back a 1080p youtube video.
There's a bunch of different codecs in use with YouTube videos. Some of them are more intense than others to decode.
It'd be nice if it was a user preference on YouTube, wherein: A user could say "VP9? Lol, no -- there's no way that's gonna work. How about h.264? I know I can play that."
But it's really not that way even though it should be. Instead, we get a vaguely-meaningless way to coarsely change resolutions and codecs are selected by the man behind the curtain.
This problem is something that can be an issue even on x86 systems that otherwise performs very well for other every-day tasks.
>It'd be nice if it was a user preference on YouTube, wherein: A user could say "VP9? Lol, no -- there's no way that's gonna work. How about h.264? I know I can play that."
No need for a user preference. There's an api that allows the site to query how well a given codec would work.
The trouble, then, would be that YouTube's implementation is either broken or nonexistent. (We can tell this because if it did exist and did work well, then there would not be complaints.)
Of course not; how could we ever be sure? We're dumb users; inspection of details of interactions between our browser and a website is a black art.
"Youtube doesn't work" is the default apparent failure mode here; and this failure mode does not provide even a PC LOAD LETTER way of going further.
(It'd be nice if it were transparent or always worked, but again: It is simply not this way. And again: We can tell this because of the complaints, and of the storied workarounds.)
Some error handling, data logging, tied to user reporting could do a long way here. I've never looked under the hood of YT, so I have no idea of the user journey in these cases. The full picture would be only visible from the Google side anyway and it'd be up to them to figure out what combinations of capabilities are causing trouble.
I've not seen 1080p playback issues even on 3rd gen Intel machines, to be honest. All I could think is that it was a driver issue with PiOS, as the SoC [0] should have good support for decoding these codecs. When I was in the rabbit hole trying to solve the issue I read many reports from others with the same problems.
I have issues with Chrome on Linux when playing 1080p videos on my 1080p monitor, ever since I disabled the h264ify plugin that (according to some here) I should have never, ever needed to have had installed to begin with.
On an i7-6700K. With an RTX 2080 Super. This is not the fastest rig, but it's plenty capable of playing a fucking 1080p Youtube video (maybe even with software decoding) as long as it isn't fucking sabotaged, like I used to do with much-lesser computers from the beginning of YouTube's 1080p streams.
(Do I have some software issues to sort out? You betcha! But the automagic shit on Youtube fails to produce usable video today, for me, just the fucking same -- without explicit help. This means that the automatic shit does not fucking work, for me -- today. And I am not alone -- see the other random complaint, above.)
(And this begs the question of: Why does this h264ify plugin, and its friends, even exist if it was never needed to begin with? For the lulz? Was it created as merely an educational experiment?)
[And as a point of comparison: 1080p Pornhub video works fine on this system. Every time. It's just smooth video without problems or aberrations. I do not know what codecs Pornhub uses, mostly because Pornhhub has never given me any reason to care about the codecs they use.
My YouTube-viewing experiences are not that way at all. By default, they fuck up. And they fuck up often. This makes me research reasons to explain, and correct for, YouTube fucking-up. Meanwhile, Pornhub works fine; it has thus not needed any corrective measures or inspection at all.]
And yes: It will always be totally cromulent for end-users like myself to bitch about the experiences they have that do not fucking work, even if (or especially if) they have some measure of technical chutzpah.
(I bitched about a thing in concert with another user who was bitching about a very similar thing. You did not provide a solution, or even a viable path towards finding a solution.)
The same question applies to most GNU/Linux distributions for laptops.
The last time I was able to use hardware video decoding for YouTube on my Asus 1215B netbook, was with Flash plugin for Firefox.
After the plugin was dropped, never again, regardless of how many incantations of VAAPI, AMD and Intel drivers.
That netbook died last year.
It is due to stuff like this that I have settled on Apple, Microsoft and Google offerings (ChromeOS and Android use only the Linux kernel, with managed userspace).
my main problem with the raspberry pi 4 8GB as a desktop PC is that first, the 8GB model is not exactly "cheap", and by the time you add all the extra stuff needed to make it usable (power supply, case, heatsink, fan, good sized of quality microsd card, etc) it costs well above a hundred bucks...
And for $100 I can go to ebay and get a used dell small form factor desktop with a core i5-something quad core cpu, 16GB RAM, 160GB Intel SSD which will run circles around it in performance as a real linux desktop.
The only thing the rpi has going for it is tiny size and its I/O pins which aren't so relevant if your application is "i want a desktop that can capably play youtube videos"
Thanks. I went to look at bcm2712-rpi-5-b.dts and bcm2712.dtsi in 6.12.x, as it's been a while since I last checked, but it looks like even 14 months after the RPi5, they've still got no further with upstreaming than serial support. No USB, no graphics... possibly SD card working?
They used to be alright (if not stellar) at Linux support so the story with RPi5 has been really disappointing. Hard to choose CM5 for a product when it's stuck in a downstream quagmire.
Both of those are things you could rig up yourself, which is the point of RPi. If you're interested in finding suitable touch pads, have a look at the ergonomic keyboard community as they do a lot of fabrication and integration.
I wish the NVMe port was populated. The Pi 5’s desktop performance feels massively better with a cheap NVMe drive compared to a microSD card.
It would also be much better if it worked with full functionality with an actually standard USB-PD power adapter instead of requiring a custom 5V 5A adapter. The whole point of USB-C and USB-PD is reusability. Instead, for the Pi5/500 I have to buy a dedicated USB power adapter rather than using the existing 45W/65W/100W ones I already own.
reply