OpenBSD obviously doesn't have NVIDIA support, but amdgpu(4) works pretty well. I'd also prefer to use AMD's own GPU, not only because I can't use NVIDIA, but also because I don't support NVIDIA's business practice.
First of all the feature wasn't available in the initial Big Sur release and it only got available during the Betas for the first minor patch. Second of all, some Apple developer stated on Twitter that (during M1 unveil) he's finally able to show all the boot policy work they worked on the past year(s) to allow users to boot foreign OSes and without opening up holes for attackers.
Basically it boils down to: they could have just used iBoot without changing it at all to keep it as a brick like the iPhone/iPad/Watch, but instead they invested plenty of resources to allow it.
With all that work done to allow it, I'm sure there'll be plenty of people inside of Apple who'd protest if someone changes their mind and decides all this has to go away.
The main blobs are being run on the GPU, as bootloaders, even before the actual operating system is loaded. OpenBSD does not need to run _any_ blob itself.
There used to be a 3d graphics driver blob, but afaik that got open sourced. Also, if you don't do 3d, you wouldn't even need it.
I did read them. Now and a few months back. Janne raises concerns about running a blob on the CPU (which does not happen), while Stuart explains the boot stages correctly in detail and compares it to very similar issues on newer x86 technology.
OpenBSD does not run on the rPi because there are only a handful developers taking care of the arm subtree, and none of them have time for it or are simply not interested. Heck, their whole arm subtree has been rotting and needs some major overhaul.
The main components of the new rPi are rather simple to get to work, so it's not a technical issue. The only real crapware inside is the usb controller.
I bet if someone supplied a diff they'd gladly take it. Also, I wonder why this rather old post is up here.
That is true. OpenBSD/Theo refuses to take part in embargos, which means they don't get a heads up. Don't have a citation right now, but Theo said that publicly when Hardbleed or so happened.
The funny thing is that even though they have OpenCVS in their source tree, they do not use it. It never took off and probably had too many bugs and issues.
Instead they are and have been using GNU CVS instead.
OpenCVS was linked to the normal build for a while but has been removed from it four years ago.
For me personally, better armv7 support. Even though many things stem from our hands, NetBSD and FreeBSD are a great resource. I have already started working on SMP support, based on their example.
Otherwise I do not have any NetBSD stuff in mind. Can't speak for our other developers though. ;)
I would love to have FreeBSD's bhyve on Bitrig. I will dedicate some time in January for that goal. DragonflyBSD is an inspiration for us, too. We have an experimental branch (smpns) for revamping the kernel for decent SMP support.