It's true that RPi owners don't know about a lot of that other stuff, but there are reasons they don't know about them.
What's the best right now in terms of openness and support for someone working at the driver level?
I don't work as much with TI but I've used Panda in the past for OMAP4 and some personal work with Beagle/AM335x and it's solid stuff. I'd like to think Beagle's community is as good as RPi's, just a little more low-key (and the chipmaker participates as well)
With RaspPi you can download an SD card image fully set up with a simple "wpa_supplicant.conf" for WiFi and a Bounjour discovery service to register a hostname like 'pi.local'. Takes like an hour with a crappy connection and then another hour at most for apt-get update. Need to hook a security camera? Download a prebuilkt MotionEyeOS image. Need to control a CNC with GCode and a .Net core API? Grab the Duet 3 and a raspberry pi.
I have some good memories of using TI embedded hardware (MSP430) and the documentation being pretty good. That's a different paradigm than a whole Unix system, though, even if it's a system that's going to be used for embedded stuff. It's nice to hear the Beagle situation is good. I remember those boards getting a hearty endorsement from Andrew Tanenbaum but otherwise I don't know too much about them.
The iMX6 used to be single, dual, (solo/duallite), quad. Done. Now there's what - 5 other variants? 7?
And then when I knew more I found aliexpress and the Orange Pi Zero LTS.
> It's true that RPi owners don't know about a lot of that other stuff, but there are reasons they don't know about them.
You're just trying to explain away ignorance, and prejudice really.
The other nice thing is the massive community means that software gets tailored to the Pi’s capabilities - things like octoPi have been invaluable to me. Sure, I could assemble the same thing myself, but having somebody else do the heavy lifting is really nice.
The final nice thing is that rPis are easy to buy. With other boards I have to pay for shipping from the states or wait for shipping from China. With the rPi, I have one distributor that’s local to me, and a second where shipping is pretty cheap.
If I wanted to configure display, read thermals, cpufreq I had to use some rpi specific tools in /opt, intstead of using standard kernel interfaces.
Trying to add a TFT display to RPi involved googling and finding a bunch of outdated/contradictory advice and then still having to figure it out myself with experimentation.
Locally bought Rpi2 at the time was also 3x the price of the better specced Orange Pi PC. And if I wanted to use video decoding I had to pay even more.
I mean, it's great it works for you. My interest was in learning, and it felt like the things I would learn about Rpi would not help me that much with any other boards, due to quirkiness of Rpi's SoC design, and nonstandard OS interfaces. So I bailed early, and focused on something else. I also found the SoC to be rather closed.
I run NetBSD, and the same exact software that runs on a Pi will also run on a RockPro64, just like the drivers for a zillion PCIe devices which work on other platforms will also work on a RockPro64.
GNU/Linux really should share more between distros instead of always needing distros to be able to differentiate themselves from each other.
Drivers are open source and part of the kernel. In that case, if a distro hasn't enabled support in their kernel build, you can build your own. Or compile it in with dkms if it's out of tree.
Or it's a proprietary driver, and then it might only work with certain distros, but in this case I seriously doubt the HW would work with NetBSD either.