I don't understand the details, but it looks like you use the uefi-only option in the installer to install the UEFI 'firmware', which then lets you boot the openbsd installer.
Yes, there's an "UEFI environment only" option that only installs m1n1+u-boot (not Linux), OpenBSD/arm64 uses the EFI implementation provided by u-boot.
Mark Kettenis' from the OpenBSD project is responsible for upstreaming Apple M1 support for u-boot, and has been collaborating with the Asahi Linux team.
Damn, that’s awesome. If I wasn’t using my M1 air as a daily driver at the moment, I’d already be attempting an install.
I guess I’ll keep an eye out for a second hand M1 mini, or wait for a refurbished mini to show up on the Apple online store (in Ireland). Would love to add another RISC system to my home fleet of machines running OpenBSD (and a couple of FreeBSD).
Honestly, the biggest advantage OpenBSD has always had for me was its internal consistency and excellent documentation. If you’re a heavy command line user, you can usually figure out either what command you need to run or what you need to look up in the man pages. It’s also great for C development, as it has far better docs for libc than glibc does.
If you have supported hardware (and that’s a bit if and caveat; smaller than it used to be, but still quite large), then everything just works. Even little things like the built-in screen brightness buttons, just work regardless of if you’re in x11 or a terminal (same with volume buttons), because it’s designed as a complete system rather than a distribution of otherwise unrelated open source projects.
Scrivener is a gem for sure, but I'm always curious if anyone actively using it has tried Highland? I guess I'm biased as it feels extremely "at home" on macOS.
It looks nice, I'll be sure to try it out! Upfront, I don't think it'll cover all my scrivener uses (it seems to be missing a lot of the outlining and research features—please correct me if I'm wrong), but I'm curious enough to try it for a short story or two.
I think it already runs on FreeBSD. It's in the handbook somewhere:
- "Linux® Binary Compatibility"
- "Describes the Linux® compatibility features of FreeBSD. Also provides detailed installation instructions for many popular Linux® applications such as Oracle® and Mathematica®."
I wasn't able to find that exact reference in the docs of the current release (using a mobile device at the moment). However, there is a very useful forum thread for anyone interested. It's not a straightforward install, but it's definitely possible to install/use Mathematica on FreeBSD.
Ya, same for FreeBSD. You can literally operate a system with nothing but the handbook in most cases - the documentation is much more systematic and developed than Linux. What you get isn't just a "how to use a GUI" tutorial or manpages, it's a comprehensive look at how you do routine sysadmin tasks. The kind of thing that Linux pushes off to web tutorials or stackoverflow.
It of course helps that nothing ever changes in BSD-land. After 50 years of development, they are largely feature-complete and are not going to be doing massive changes just for the sake of massive changes. As such they get much lower levels of "documentation rot", things rust a lot slower when nothing ever changes and as such it's a lot easier (and more productive) to build comprehensive documentation.
But the amount of churn in linux is insane, Ubuntu has used three completely different init systems in the 15 years since I started using Linux seriously. For java development, I routinely see and use StackOverflow answers from like 2009 that are completely valid still, and yet answers from that era are completely useless for Linux, which has invalidated that acquired-knowledge twice since then. You can pretty much sysadmin FreeBSD out of the handbook, and if you need to search then an answer from 2009 is usually still valid.
It's absolutely a cathedral-vs-bazaar situation. Cathedral is presented as a negative in that metaphor, but the cathedral ensures enough stability that you can start Having Nice Things instead of just constantly scrambling to rewrite everything every time a vendor thinks they've built a better mousetrap.
There are some cases of real churn in Linux but they're rare. The new init systems and such come with plenty of useful features that simplify many administration tasks: the reason for people being so unsatisfied with them is that they bring lots of what's effectively cowboy-coded hacks and prototype-quality code in order to enable these features. But rewriting all of this stuff from the ground up with a clean, Unix-like design (or rather, Plan9-, Limbo- or Amoeba-like, given that Linux now supports the needed foundational features for these) while preserving its feature set would involve more rather than less churn.
> or rather, Plan9-, Limbo- or Amoeba-like [design], given that Linux now supports the needed foundational features for these
I‘d be curious to hear more about what you're referring to, if you were willing to expand. What foundational features are new to Linux that would be really useful for cleaner init system (etc.) designs?
Yeah, it's great! Even if you don't get deeply into it, the ability to take and send snapshots, the intelligent caching layer, and the data integrity stuff is all super useful. It's the same stuff that BTRFS sells but it actually, you know, works without constant intervention and data loss. And Zed is great, it ties the whole snapshot thing into the software update process and so on.
It's definitely a bit heavier than other filesystems but it's one of those things where I can't imagine setting up a Linux/Unix system without it anymore.
I wouldn't exactly classify ZFS as a "new" feature though. ZFS dates to 2004, OpenZFS dates to 2006, and OpenSolaris dates to 2010. 20 years is pretty well into "mature technology" by most standards, even 16 years is very mature by software standards.
How does it compare to some of the better run wikis like the Arch wiki? I think I'll take a look around, never thought about checking there freebsd for info on general command line stuff.
I think “comfortable” sums it up better than anything else. When I run OpenBSD, I know what’s running on my system (up until the firmware at least), but more importantly I understand it. Even the kernel is easy to dive into.
It's great, if you don't need something like zoom, or to interact with those weird 'usb button' projectors or whatever.
Or video accelerated YouTube.. Or Microsoft office..
Really, I love OpenBSD, but I only really use it for (internet) networking these days, FreeBSD looks after my storage, and it's all proxmox with ubuntu 20.04 vms running k8s for apps.
Someday I'll switch back, but working as a freelancer with a lot of different customers bsds are just too painful to run bare metal (def works with ssh/mosh/tmux though!)
Most people do most things in a web browser these days. Can't Microsoft Office be used as a hosted app in a browser, at least the bulk of common functionality?
You can get GPU accelerated YouTube videos in OpenBSD, provided you have a supported GPU in the first place. You have to use Firefox and enable gfx.webrender.all and layers.acceleration.force-enabled in about:config. I've been able to get up to 2Kp60 smooth as butter on Intel HD 530 graphics in OpenBSD 7.0. 4Kp60 plays and drops a few frames, but my monitor is 2K so I have no need for 4K playback anyway.
Zoom actually works fine under chromium on OpenBSD, with full microphone/webcam support. It just requires some configuration to enable a few things which are disabled by default for security reasons.
Benefits? If you are not developing _for_ the platform or don’t have specific use cases (e.g. package creation) literally none. It will be an uphill battle where you will spent man-hours trying to find workarounds to things elsewhere are trivial. Or have another system laying around which IMO beats the purpose.
If you are an OS & BSD aficionado, you like to spent time working with OpenBSD because <reasons> ok, but otherwise I would advise against it.
I’d see it as stability, in the “won’t need upgrades” outside of security ones.
A bunch of us have a trail of old macs that are weird to use because of the whole system is stuck on the last supported OS, which happens to be the most bloated for that hardware, and doesn’t receive updates anymore. Moving to another simpler system altogether makes it a better proposition. As a matter of choice, BSD is more familiar than linux in many ways.
M1 laptops are not in that position yet, but in 2 years I’d totally imagine getting rid of macos on sub machines.
this is a troll, right? MacOS is much better for most users than Windows or Linux, and I say this as someone who used desktop Linux for 10+yrs before throwing the towel in.
Commercial/Proprietary software support, mainly. Certain companies or institutions may require Windows or MacOS only. I prefer MacOS ecosystem (*nix-like) to Windows.
Key part is without any energy saving features. Once those are implemented it will improve. I am pretty sure MacOS has a number of energy saving features implemented.
Whatever happened to NetBSD being the version that ran on everything? I discovered the other day that it took them years to even run properly on the Raspberry Pi.
Are they short of money or developers, or is the famed portability of it just not as true as it used to be?
A lot of the hardware on the board has vendor support in Linux and only Linux. Vendors will write drivers and upstream them to Linux and then just call it a day. You can't get the manuals for those components except under NDA, which makes open source development for non-Linux operating systems a huge pain in the ass.
Yeah they're even borderline hostile to non raspbian systems. When a new Pi comes out it usually only works for raspbian for quite some time until others put in the work of getting the right stuff together for other distros.
I love raspberry pi but they are definitely not as "open" and drop-in compatible as most people think.
That seems to be a problem with most ARM devices, so may not be specific or the fault of the Pi people.
Yes but Raspbian is also 'a weird variant of Debian' by that line right? I think you're in agreement with GP; I find a similar thing coming up with Arch & Manjaro (an Arch derivative) - for almost any purpose when someone says 'Arch' it applied to Manjaro too (just less often vice versa).
So, yes, 'non-Debian' which (Debian) includes Raspbian, not 'non-Raspbian' which (Raspbian) precludes Debian.
Yeah I agree, I consider Raspbian "a weird variant of Debian." They add a bunch of packages (some that override upstream debian) and they have some custom software, plus a lot of other customization.
Raspbian is probably closer to Debian than Ubuntu is, but it's still quite clear that you're not on Debian.
How soon after a new Pi model comes out do you try? If you wait 6 months then yes, Ubuntu tends to work fine (although you do still need a specific build. You can't just download a generic one).
I used to use Ubuntu MATE on pi, but when the Pi4 came out it took a long time before it was supported.
I tried within a week or two of the cm4 releasing. This may be unfair due to the similarities of the pi4 and the cm4. I’ll know better when pi5 releases. I heavily utilize these in my work, and have great incentive to have new pi’s supported on Ubuntu immediately:)
I mean do they have the manpower to keep up with 12 different distros? Don't they opensource everything they do so other distro users can figure it out?
I assume parent isn't talking about creating SD card images for 12 different distros, but rather working with upstream developers so more stuff is mainlined earlier thus being useful to everybody.
OpenBSD is known for its high quality standards, quality software is resource-intensive to develop, and they are a relatively small team.
As a practical / project management matter, how do they manage to support a diversity of hardware? What proportion of their resources is spent just keeping up with hardware?
Maybe don't boot your Macs into third-party operating systems (high potential for thermal damage or even misconfiguring mainboard components such that it might cause data loss even when rebooted back into macOS ..if the BSP devs at Apple were sloppy in their initialization code or an "unknown state" is created). Linux on Mac, A/UX, etc. was a Thing back in the day when clock rates were lower and component densities were lower and the machines came chalk full of holes to let the heat out, so running the system "out of spec" had less potential for permanent damage.
Apple-sanctioned alternative operating systems such as VMware ESXi have also caused problems in the past and should not be used at all anymore because Apple does not seem to play well with others on that level (by releasing uncoordinated firmware updates).
> running the system "out of spec" had less potential for permanent damage
You may have a point, unless this insinuated physical damage from altOS on Apple Silicon never appears.
> Apple-sanctioned alternative operating systems such as VMware ESXi have also caused problems in the past and should not be used at all anymore
VMWare currently supports running their bare metal hypervisor on (at least) Intel Mac hardware (except for Mac Pro due to COVID straining VMWare development, and not because ESXi causes Mac Pros to detonate), but does not consider any Mac with VMWare an enterprise-grade setup.
> because Apple does not seem to play well with others on that level (by releasing uncoordinated firmware updates).
Please accept some humble advice: since there are three and only three reasons to update anything: bugfixes, pressing security issues and the last a need for new features, generally, one should never update firmware, and this is especially true the moment the update appears. In the first case, unless the bug prevents booting, it couldn't be less important, secondly, worrying about firmware security issues is silly, because if you can't physically prevent access to the computer, it's pwned anyway no matter how secure the firmware is. And in the last case, if you have a functioning system in production, then it doesn't need new features, get out of here with needing new features on production. The notion is absurd on it's face.
> secondly, worrying about firmware security issues is silly, because if you can't physically prevent access to the computer, it's pwned anyway no matter how secure the firmware is.
Not true. Apple hired some of the best security experts in the world to build a system that was resistant to pwnage even if the attacker has physical access to the machine:
I just want to point out that this tweet is wrong when it claims that Secure Boot does not protect against physical presence attacks. This misunderstands the point of Secure Boot.
Secure Boot can indeed be disabled, but that will change the TPM PCR values, so assuming a standard BitLocker configuration, the TPM will fail to unlock the BitLocker key. So if you try to disable Secure Boot on such a machine, you will be unable to boot unless you have the BitLocker recovery key.
>secondly, worrying about firmware security issues is silly, because if you can't physically prevent access to the computer, it's pwned anyway no matter how secure the firmware is
This is just completely wrong. You're peddling bad 20-year-old advice that hasn't ever been completely true, and especially not anymore.
First, firmware updates often patch vulnerabilities that would allow attacks without physical access. Most obviously, vulnerabilities in the networking hardware can allow attackers to take control a machine by sending crafted packets. But other hardware issues can also, e.g., make it possible for untrusted code to perform a privilege escalation of some kind. You want firmware updates to protect yourself.
Second, Macs/iOS devices and PCs—through the Secure Enclave and TPM, respectively—offer really good protection against physical access attacks. They verify the integrity of boot components and are only able to decrypt the system volume if they detect an untampered boot chain. Further, they can lock down direct memory access to protect powered-on systems from bypasses to user authentication. This is why nowadays, if a thief steals your laptop and you had the hard drive encryption with hardware security features on (on Windows, if you set up with a Microsoft Account, this is enabled without any further action by the user), you can feel fairly secure that even a technically savvy thief cannot access your data. Firmware updates can fix vulnerabilities in these security systems.
Nice straw man, because you didn't disagree with me, you disagreed with someone else's argument. Actually, in the old days, every update was applied as soon as humanly possible. It is only in the last 25 years that admins have been required to carefully examine updates and weigh the risks of production possibly going down or getting funked against I suppose apparently the incessant barrage of novel network firmware attacks.
Above, you said, "worrying about firmware security issues is silly, because if you can't physically prevent access to the computer". That's not someone else's claim, it's yours. If you didn't intend it to be your claim, you erred in expressing it, since that's what it conveys. That's the claim the other poster refuted. I simply don't understand you when you say they "disagreed with someone else's argument"? I control F'd the parent posts and found no such claim made by anyone, except you.
Your (apparent) claim is obviously wrong for the reasons already pointed out by the other poster, including that there are firmware-level attacks that do not require physical access. Some of these vulnerabilities can be fixed by firmware updates. So, if possible, it makes sense to promptly apply each patch that will fix such a vulnerability.
Blah blah blah, you’re talking out your ass, VMware ESXi can and will fry trashmac when run with incompatible firmware that can sneak in while booted into macOS releases that came after the ESXi release..and neither Apple nor VMware may warn you before the glue comes off.
lol now that's the spirit of adventure I expect! You're not going to burn up a chip as long as it has a heatsink on it. All modern cpus have thermal trips to reset when it gets too hot. You might scramble your hard drive of course butnothing you can't recover from
Intel processor yes, Apple processor unknown and what about GPUs and nVME, dried up caps, melted ribbon connectors on the board interconnects causing short circuits…all well known issues that come from the fragile thermal dynamic designs on past Macs and all issues that are pushed to extreme by not knowing when or how to interact with the proprietary firmware from within alternate kernel modules.
Component failure due to thermal issues (in this case, not knowing the protocols or facilities for controlling the custom cooling features) don’t typically manifest overnight. My point is “novices beware” —but writing that would challenge some students into this fool’s errand that ends with the demise of their Mac.
>don't boot your Macs into third-party operating systems (high potential for thermal damage or even misconfiguring mainboard components such that it might cause data loss even when rebooted back into macOS
I see this fantastical claim thrown around on all kinds of forums, of course never with sources cited.
There shouldn't be any potential for thermal damage from software. There should be very simple low level circuitry on the board that cuts power after a critical temperature is exceeded, regardless of how the OS or firmware are set up. Many consumer devices have something like this so that they don't melt down and hurt people. Are you trying to say that Apple isn't including basic safety features anymore?
Thanks for helping me get downvoted. I am a source, of course, for these claims and the Internet is littered with relevant testimonials. Expect the hysteresis shutdown to allow for UL-like protection of the consumer, not say, the D500 GPUs in the trashmacs.
You are most welcome. I just so happen to be a hobbyist who has had my hands on almost every generation of Mac from the later 68k models to the Intel platforms up to around 2012. And I have booted NetBSD or some kind of Linux on almost all of them. They did not overheat or suffer any damage.
In fact, my hottest running Macs in my collection, the G4 PowerBooks, run cooler under Linux than OS X 10.5
I still think you're grossly overstating the risks of modes of failure that just don't happen that often.
Unfortunately, the most exotic alternative OS that Macs support is BootCamp and that’s not yet for ARM so hack away while booted into Darwin (macOS) using a VM. I recommend Zephyr for big time hacking fun! :)
You could probably ask their support, they are very good at responding.
That being said, they use coreboot and hardware with open/well known drivers. I actually bought a Librem 14 and installed Windows on it for my spouse, and surprisingly, everything on it worked out of the box.
I'd be really interested to hear if any arm64 or other RISC architecture laptops are useable! M1 is a step in that direction, it would be really surprising to me if it worked well beyond basic support yet however. Asahi linux took like over a year to get to that point but it sounds from reading that link that they're pretty gung ho on getting it working for 7.1 which is amazing to hear. It sounds like other hardware support in those laptops is the big thing.
Fun miscellaneous stuff: SMP on intel architecture is disabled on openbsd for security reasons, so looking at alternatives to make things go fast with guarantees for that is big right now.
To add to that, if you need the (max ~30%) performance boost (less on OpenBSD as a some parts of the kernel are still poorly performant in SMP scenarios, it's improving but still noticeable), it's possible to enable hyperthreading temporarily via
doas sysctl hw.smt=1
I do this occasionally when running larger compilations (LLVM or similar). If you want it enabled permanently you can add
SMP is specifically multi-cpu, not multi-core. Normally the distinction doesn’t matter, but when you are talking about kernel support they are entirely different.
Kernel devs typically do use SMP to refer to multicore. Even Wikipedia says: "In the case of multi-core processors, the SMP architecture applies to the cores, treating them as separate processors."
Because arm64 is an architecture, not a definition of an entire SoC. When you want to run on a SoC with all sorts of connected peripherals you must support those in your OS in order to use them. Some peripherals are required to run at all. To run on any SoC you'll have to implement software to work on it.
^This. We've been so spoiled by several decades of relatively compatibility between x86(_64) PC-based systems, that it's easy to forget that that's not the norm for most architectures.
Plus *BSD isn't a single OS. The main ones are OpenBSD, FreeBSD, NetBSD and DragonflyBSD. All with their own divergent philosophies and incompatibilities.
Happy to see this! I run OpenBSD/arm64 on a Pi 4 and am posting this from OpenBSD on an old ThinkPad. Great OS all around, and it's always nice to see the current version running on both old stuff (this laptop from 2012) and cutting-edge stuff simultaneously :)
At this point it seems M1 Macs have better Linux/other unixes support than Intel Macs with a T2 chip. At least from my experience and what I’m seeing with Asahi Linux.
The forthcoming GPU and sound support are all I'm waiting for to move my daily OpenBSD workstation to my M1 mini. I tested Asahi Linux on it earlier this morning and it was mind-bogglingly fast. My fastest AMD64 based system is a Ryzen 5 3600 with a NVMe main storage drive, and Linux on the M1 makes it feel like a 10 year old i3 with a spinning drive in comparison. Everything is just instant, file transfers are faster than they are on macOS on the same machine, and even without GPU acceleration, KDE Plasma is quick and fluid. I ran out of time to try OpenBSD today but I'll jump on that this week and see if the performance carries over to it.
Hope to see a write up on it somewhere! I bought my M1 air specifically to run a powerful arm computer with Linux/BSD once it is decent enough! I am in my last semester and don't want to tamper with my machine until that is over, so once I graduate in a month, I have plans to look into doing this. If OpenBSD is in a usable state, that'll be what gets loaded on sometime in may.
Definitely! I don't have much of an online presence beyond here, OSNews, Ars Technica, and Reddit, but I have been wanting to start a blog about my tech hobbies (OpenBSD primarily) and this would be a good start for it. I'll be sure to add it to my profile here once I've started it.
reply