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.
https://news.ycombinator.com/item?id=26209345
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.