OpenBSD 7.1 has been released. The biggest improvement in this point release is support for Apple Silicon, which is now ready for general use. Of course, there’s a lot more in this new release, so head on over to the changelog to get all the details.
I’ve been playing around with the 7.1 snapshot on a Skylake mini-pc and my Mac mini, and the performance increase is substantial. OpenBSD on the desktop is fast enough on recent hardware for daily use, and on my M1 Mac it’s usable but I wouldn’t say ready for “general use” just yet. It’s definitely mind-bogglingly fast on the M1 just as Linux is, even without GPU acceleration. When that lands, along with USB3 and Thunderbolt support, I can’t imagine a better platform for a Linux or BSD daily driver.
Good to know! I’ve been looking for ARM desktops lately.
How are the WiFi, card reader, and NIC chips doing?
I have a late-2012 MacMini which is getting turned into a server because the NIC is stable while the other two are not.
I don’t use WiFi on my desktops including the Mac mini, so I can’t say for sure, but it looks like WiFi would work as it’s based on the bwfm(4) driver. There is no card reader on the M1 mini and I don’t know if the one on the Macbook Pro would work or not under OpenBSD. The NIC on the M1 mini works fine and appears to support full 1Gbps on my home network under both Asahi Linux and OpenBSD arm64.
The new Mac Studio with the M1 Max/Pro/Ultra chips does have a card reader, and I believe that device will soon be supported under Asahi Linux with OpenBSD support likely soon afterwards.
The M1 seems compelling for efficiency. The main detractor for me is that I’m not keen about “voting with your wallet” to buy closed hardware. I appreciate the work being done to reverse engineer the hardware, it’s thanks to people who dedicate their skills to do this work that we get to run open operating systems on ARM and other architectures. But at the same time reverse engineering should only be a last resort. As a norm though this ongoing long term dependency of FOSS users relying on proprietary hardware vendors is not good and causes systemic problems for all FOSS platforms. I often ask myself whether things have to be this way or if somehow there’s a path to a solution where the money could reward the manufactures that actively support FOSS rather than those that are hostile to FOSS.
This is why I moved away from anything Nvidia a few years ago (right down to getting rid of my Shield TV) and focused on AMD for desktop computing. Their overt hostility towards FOSS was just insane. Apple is far friendlier to the world of FOSS than Nvidia, though maybe “friendly” isn’t the right word for it; “less hostile” might be more accurate.
Honestly though, BSD on an Apple device just feels right given macOS’s history and the BSD licenses being more permissive. I’d love it if Apple would fully open up the specs on their hardware to avoid having to reverse engineer, but at least they aren’t blocking anyone from hacking on their new machines, and in fact seem to be helping along here and there according to Marcan.
Morgan,
Haha, yeah I understand.
I think it’s currently a case of apple recognizing that alt-os users are technically good for sales and perhaps much more importantly blocking them would incur tons of negative press for no tangible benefit to apple sales. That said I think apple would have no reservations about being hostile to alt-OS if being hostile were to be commercially beneficial to apple. It’s just that they consider hostile action to be a means to an end rather than a goal in and of itself. I don’t know how much comfort this is, but at least it’s something.
Apple could block alt-OS on new firmware if they actually wanted to, but the expectation is that they won’t want to. I can think of a few contrived cases where they might want to in the future, but hopefully it remains merely proprietary rather than proprietary AND locked down.
Obviously it would be great if they would explicitly open up their hardware. It could set a great precedent for the whole industry, but honestly this doesn’t seem in line with apple’s values at the moment.
“It could set a great precedent for the whole industry, but honestly this doesn’t seem in line with apple’s values at the moment.”
It doesn’t seem in line with the industry as a whole really.
Maybe I’m wrong, but moving to UEFI, etc. scares me a bit. Signed by Microsoft keys only on PC. Smartphones, tablets pretty locked down hardware, etc.
People running their stuff in the cloud instead of servers they can touch (rented or not).
Data stuck behind proprietary APIs so it’s harder to make backups (Atlassian outage for 2 weeks for a subset of it’s customers).
Smartphones and tablets having interfaces which give you basically no access to the file system for a while. Which opened up again later, but feels like it could be undone at the next update.
Funny thing is for those making the hardware something like RISC-V will make it more open for them. But seems to me the end user/software developer. does not get the advantages of something like that.
I also worry about the digital dark ages we are creating.
The dark ages is a time when things were written on a type of material that didn’t last.
Now we are putting our stuff on flash storage which I would think won’t last. And doing full disk encryption.
Lennie,
Yes, I am aware. It’s just with so many companies copying aspects of apple (good and bad) apple are in a strong position to set good precedents if they wanted to. Unfortunately they haven’t been great role models, opting to use their power to block competition, impose planned obsolescence, and fighting the right to repair, etc. Better leadership could turn apple into a good role model, but then that’s obviously not what wall street is about.
IMHO UEFI, as a standard, is better for alt-OS than having each device using proprietary boot methods. The PC bios was never a great standard, but the mere existence of that standard really helped build a viable alt-os scene. In modern years the lack of standards on commodity ARM devices has caused decades of struggle for users and developers. So for this reason I think widely adopted standard are desperately needed.
Of course you are right that lock downs are extremely harmful too, such as microsoft’s insistence that secure boot keys be locked to MS keys on ARM devices, but I don’t believe their policy would be any different if they weren’t using UEFI. UEFI isn’t the enemy so much as owner restricting policies are. Such policies are a major problem for alt-os regardless of the underlying boot methods.
Yea, I find the hope for RISC-V is somewhat similar to the hope I had for ARM long ago. RISC-V as an open architecture could be truly great if it’s implementation were actually open and accessible. But if the manufacturers do like nvidia does using RISC-V cores in their products: gating them up and denying end users all the benefits of openness, then it’s one step forward, two steps backwards. 🙁
Sometimes the barriers are natural/incidental, but problems are exacerbated when companies deliberately spend resources to make things break in the field. I’m pretty sure the technology of the 80s-90s will more accessible to retro-enthusiasts in the future than the hardware and software companies are putting out today due to artificial hardware and software restrictions.
https://www.defectivebydesign.org/the-worst-thing-about-drm
https://9to5mac.com/2020/10/30/iphone-12-camera-repair/
Corporations driven by profits are decidedly bad stewards for openness. Companies need to be made to feel some pressure against doing these things, otherwise I fear such owner restrictions could be permanent.
I was definitely not hating on UEFI as an idea for creating a standard. UEFI does seem pretty big, etc. And lots of dodgy implementations, etc. instead of better security it sometimes seems because of the features/size to introduce more security problems.
These days the security researchers are worried we can’t detect when malware was installed in firmware and how can we be sure it’s gone again. Security features backfire.
“, but problems are exacerbated when companies deliberately spend resources to make things break in the field. I’m pretty sure the technology of the 80s-90s will more accessible to retro-enthusiasts in the future than the hardware and software companies are putting out today due to artificial hardware and software restrictions.”
I’m certain planned obsolescence will take care of that. Nothing much will remain working.
At least the DRM can be broken over time. So far every DRM scheme has been broken over time. But we are tying it more and more to hardware over time. So when the hardware breaks and we didn’t get the keys out of one of them…. the more obscure media might be lost.
Lennie,
Even in the worst case though UEFI isn’t less secure than a simple PC bios, which offered little to no security on its own. The PC bios (and other “simple” firmwares) readily allow malicious code to be installed and run. We need to keep in mind that any security measures in UEFI are in addition to those of the operating system.
For instance, even if we assume secure boot is broken out of the gate, an adversary still generally needs physical access to a system and/or a privilege escalation within the OS to actually write the boot media and exploit it.
Well, it’s impossible for any firmware (including UEFI) to confidently detect it’s own corruption. Obviously one can try and obfuscate the firmware, but the premise is flawed because anyone who can replace the firmware can also replace the checks too. Some devices may have a way to verify their firmware using additional attestation, but this has to be implemented using trusted silicone outside the firmware, otherwise it too is vulnerable.
Software DRM can be broken using software attacks, but the same is not necessarily true with hardware DRM. Hardware DRM didn’t become mainstream in the past because hardware features supporting it generally fell out of scope for consumer machines. However going forward with the new TPM requirements for windows, it could finally make hardware enforcement of owner restrictions much more effective across general purpose consumer computers. Part of me suspects this is part of microsoft’s goal in requiring it.