upvote
Decent support is not good enough. The Rasppi support is kind of an unsurmontable advantage.
reply
Seems like a good use for AI. If people can use it to port video games from one system to another or jailbreak consoles, surely "get this library/program compiling on this device, then get all the tests passing, here's root ssh and an internet connection" could work pretty well in most cases. I wouldn't have bothered wasting my time in the past, but now, sure why not? It's not my time anymore and AI can turn the crank until it works.
reply
Largely agreed but very different problems between "works for me" and "ready for upstream/mainline".

I myself am guilty as hell of this, of carrying my own remixed software, juggling patches atop upstream, and feeling like getting it upstream would be far more work and labor (and ultimately like I don't really have the confidence to assert to upstream). Meanwhile upstream is screaming their heads off everywhere that they can't take it anymore, that they are not ok. It sucks that we have such amazing power, such competency, but our scaling & social functions aren't scaling into the godlike powers that are now on tap! Alas.

reply
Yeah, agreed. I do the same. I only contribute smaller patches that definitely fix bugs, and not big vibe coded sprawls of code that happen to work for me but who knows what it breaks. For example I started using opengym which is definitely someone’s vibe code project and then grafted SSO on top for my own needs, but there’s no way I’d submit that upstream. That’s fine. I got what I wanted out of it. Things will adjust but for now just enjoy the ride :)
reply
Rpi is not always such a gold standard either.. is their boot chain still a mess? That was one of the problems with zero 2w
reply
TBF, booting any Arm board is a mess. Rpi gets my kudos for frequently updating kernel sources, unlike any other SBC I have tracked. I know which gauntlet I'd rather run to enable secure boot on an Arm SBC., despite the weird architecture.
reply
All of the boot chain is a mess because the Pi 1 used a bucket load of unused Broadcom set-top-box SoCs which were GPUs with a tiny ARM core along for the ride. Every Pi boots off the GPU first.
reply
Yeah, it's not talked about too often but RPi 1 was basically Broadcom's "useless SoC recycling program".

If not for the success of Raspberry Pi, Broadcom would have zero SBC presence today. Like many companies chasing the high volumes and high margins, they don't see the market value in a segment like this. Thus things like poor docs and weird blobs. Raspberry Pi is open to the degree it is despite Broadcom, not because of it.

Ironically, that Broadcom tie could have caused RPi to eventually lose ground to other SBCs - because the likes of Rockchip just deliver more bang for buck in SoC dept. Broadcom doesn't seem to be investing in staying competitive in the segment. So RPi's edge is just the ecosystem being more important than raw price/performance.

For now though, that's pretty much on hold, because SBC price tags are increasingly DRAM dominated instead.

reply
Rockchip has stellar mainline kernel support for most of their SOCs.
reply
how close is the OS distribution for that to actual stock debian?
reply
Stock enough that if I don't pay attention to which shell I'm looking at I can get confused.
reply
Yeah, I have a bunch of Radxa zero 3W, with their Rockchip rk3566. 4x A55 is just barely better than the A53 era still plaguing us 15 flipping years latter! Unbelievable. Alas just a hair before modern era of Rockchip, so it's support is much less consistent! But still pretty competent all in all!

Pine's Quartz64 has different peripherals attached but still afaik one of the best ways to track upstream support. It hasn't changed much since Linux 6.1 and I don't know if that's because there's nothing new or the page is just out of date. https://pine64.org/documentation/Quartz64/Development/

reply
I tested te Pine64 SQQuartz CM4 compatible SoM, but it uses the same Cypress CYW43455 WiFi as the CM4/Pi4, which crashes on me under load (not the kernel, the chip itself). There is no fix or easy mitigation, other than lowering the load which only reduces occurence. I't odd that not many are talking about this.
reply