I'm running OpenBSD on it with an amdgpu WX2100 card, works nicely.
HN user
Bluerise
[ my public key: https://keybase.io/bluerise; my proof: https://keybase.io/bluerise/sigs/_XKHalQi6Ef9petT3xbSQoVvDFDPpKN98vKYXbOldvo ]
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.
No, it‘s a completely new implementation. The whole backend and frontend is written from the ground up.
Which patches from Bitrig are you exactly talking about?
Bitrig does not have support for ZFS. Must be something different from Bitrig the poster is talking about.
The difference is that the rPi blobs actually run on the GPU, the CPU is unharmed.
Still, both have access to the same memory. But that's a similar issue on the PC.
I'm sorry, but that is wrong.
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.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/Makefil...
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.
Bitrig developer here, feel free to shoot questions!
They wrote their own. A completely new implementation.
OpenBSD did not want to be on the list of distros to be notified[0].
It's no conspiracy due to LibreSSL, but maybe rather Theo's ignorance.
Bitrig is working on support though. The devs have a few Exynos based devices, including that particular one.
Have a look at i.MX6 based machines. Namely CuBox-i, HummingBoard, SABRE Lite and Wandboard. The Utilite is fine, too.
They don't care about that. Their main interest is to have a library conforming to OpenBSD standards.
A9 core rather than the virtualization-ready A15? (I'd rather have a 64-bit ARM but those are still a ways out)
There aren't really many choices. Samsung has A15 cores, but it's probably hard to get and there's _no_ documentation. The same for Nvidia Tegra. Not sure how easy it's to get OMAP5, and how expensive.
The i.MX6 SoC is probably the developer friendliest one, has very good documentation, and it has support for lots of stuff.
100 Mbit Ethernet in the Year Of Our Lord Two Thousand Fourteen?
Read carefully. One of those ports is 1Gbit (due to SoC limitations only 480Mbps though). The other one seems to be connected via USB 2.0. One could have put an Intel PCIe Gigabit Ethernet chip on the board, but the PCIe slot is probably better used for WiFi.
It's pricy, but I don't think they are able to produce them for fewer money, like HP/Samsung with their $400 Chromebooks.
I have been waiting for some time for the crowdfunding campaign.
The FreeScale i.MX6 platform is very versatile. Up to quad core 1.2GHz, SATA, PCIe, Gigabit Ethernet (limited to 480Mbps) and lots of good documentation and driver support.
The only issue is the graphics blob and... in this case the price tag. I hoped I could afford it, but it looks like I can't.
Still, there are lots of other community boards based on the i.MX6 SoC. If you don't need the laptop version or an FPGA, there are much cheaper boards out there.
The Novena Open Laptop really is good work. I hope it'll get funded!
Agreed, this is really well designed and beautiful. I would love to use that for my personal timekeeping.
What about Bitrig?
You should print it or write it down and store it in a secure place.
Cyphertite[1] works very will for encrypted backups.
It splits your data in chunks, encrypts them on the fly while sending them to the cloud. It doesn't use much space, apart from a little metadata, and you don't have to worry about the NSA, as the encryption keys are only on your local machine.
OpenBSD people? OpenSSH people!