Amusing seeing people reacting here on HN to the Apple M1 SoC Linux kernel upstreaming, meanwhile in OpenBSD.. FreeBSD hasn't made any public progress yet on M1 support.
I also wouldn’t fault HN for being more interested in the port for an OS they actually use to a platform they’re intrigued by. Not to say there’s anything wrong with OpenBSD, but I am not interested in switching to it.
Sure that's fair, just thought it was interesting to point out the progress they've been making, especially with their 50th release around the corner (6.9 is due May 1st), and M1 SoC support in pretty good shape OOTB. USB works, Wireless, Ethernet on the M1 Mini, etc. It is lacking SMP and a bunch of other stuff, but still.. ton of impressive work.
Not trying to convince anyone to look at OpenBSD who has no inclination toward *BSD, but out of curiosity, what's missing for you?
Last I checked OpenBSD lacked any support for Wayland (I tend to use SwayWM; it is supported on FreeBSD I believe, though realistically Linux is going to have the best story here for now.) I also don’t believe Docker runs natively, which is a pain for some stuff. I don’t expect most commercial software (REAPER, IDA/Binja, etc.) to really support BSDs either.
I run multiple machines so it’s not a huge issue if one OS doesn’t do everything I need, but I expect roughly all of the things I want to do to require some kind of VM or emulation under BSD, if it’s even possible at all. So for me, the value proposition is limited. It just seems like more stuff to learn, and I’m not entirely sure what to do with it.
I am unaware of any reasons why Wayland won’t come to OpenBSD. Last I checked, progress towards the possibility of running Wayland compositors on OpenBSD had been progressing slowly. OpenBSD seems to support KMS these days, as well as DRM. I don’t know if OpenBSD will adopt evdev, but I don’t think it would be a giant logical leap unless the maintainers are diametrically opposed.
If OpenBSD is unable to transition to Wayland, that does call into question what it will do in the future. My understanding is that Xorg maintenance basically only extends to Xwayland use cases, so it seems like a fork of Xorg or an alternative would be needed to keep things going in the longer term.
X.org maintenance consists of merging drivers written by GPU companies. The software itself has been totally finished for many years. Im sure when IBM et al decide to formally relinquish control of X.org instead of pussyfooting around with this "maintenance mode" act, we'll see more progress though. Promising technologies such as Xgl were left by the wayside because X.org is supposed to be depreciated.
The difference is that binary packages for Tier-2 and lower are on a best-effort basis, and might be more or less out of date depending on the available package build hardware. For arm64 we now have multiple high-end arm64 servers and can guarantee packages will be built in a timely fashion for all supported branches.
Fantastic, congratulations and big thanks to all that made this happen.
I was outspokenly grumpy when the news came out that this wasn’t happening, now I’m so pleased it is.
Wait, so does this mean FreeBSD will work better on a raspberry pi without having to hack on your config files just to get it to recognize all available RAM? I’ve got FreeBSD running on a rpi4—took some doing. It would be nice to just slap an image on it and have it work.
This is pretty unlikely, unfortunately. We're generally looking out for a Pi maintainer because it doesn't really have one -- it's not the most desirable platform to hack on, from a developer POV.
Speaking from personal experience, it's an absolute pain -- they're already an odd duck (w.r.t. booting, for instance), add on that the documentation is incredibly lacking compared to competitors and you've got a platform that's not too appetizing.
I’m curious about what documentation is lacking? I’ve been collecting technical documentation on the RPI4 because I’m trying to understand the platform well, and maybe I’ve come across something that can help?
Pretty much anything that would need to come from Broadcom, really
The docs that most recently bit us are pcie/ethernet on the RPi4; I got in touch with Broadcom, who is now in a multi-year effort to figure out how to disperse usable docs (under NDA?) to the broader community. I lost faith after 9ish months of poking and getting back "oh, you know how it is" in response.
I speak as a FreeBSD developer who has dabbled with RPi, having tested and shuffled in a lot of the initial RPi4 patches and did some not-insignificant hacking to get a single RPi image to actually support RPi3 + RPi4.
I’m glad to see this b/c I had a good experience with the RPI3 on FreeBSD but a terrible experience trying to get the RPI4 running on FreeBSD. I think I will still have to use a dongle to run the RPIs on FreeBSD which isn’t great but hopefully the overall setup will be easier
semi-kinda blob and blob-like exterality depending on rpi4, black magic to make things work with 8gb, nothing insurmountable but I kind of wish in the future some rpi8 doesn't inherit this risk. Absolutely awesome news and welcome news.
https://www.openbsd.org/arm64.html
Amusing seeing people reacting here on HN to the Apple M1 SoC Linux kernel upstreaming, meanwhile in OpenBSD.. FreeBSD hasn't made any public progress yet on M1 support.
https://marc.info/?l=openbsd-arm&m=161386122115249&w=2
https://github.com/openbsd/src/search?q=m1&type=commits