This is a big deal for local development imho. With the raw single-thread performance of the M4/M5 chips, an openbsd guest is arguably the best environment for testing pf configurations or running isolated mail servers (for example). Being able to rely on viogpu without the black-screen-of-death means we can slowly move away from serial console-only installs for quick VMs.
Big kudos to Helg and Stefan!
A unikernel would probably be even better? (But then you need a mail server that's set up for running as a unikernel, without an underlying OS.)
No, thanks. My IaC doesn't want or need any interaction when spinning up a quick or slow VM.
It started in 7.3 with the frame buffer changes and the only workaround was to disable the kernel driver.
Maybe more people will get to try out OpenBSD successfully now.
The subject in the parent comment changed to OpenBSD when they mentioned it, and it appears you may have overlooked the subject change.
* hypervisor-framework handles the hypervisor bits, like creating virtual machines, virtualising hardware resources, basically a C API on top of Apple's hypervisor
* virtualization-framework is a higher-level API, meant to make it easy to run a full-blown VM with an OS and hardware integration, without having to reinvent the integration with lower-level primitives that hypervisor-framework provides
* containerization-framework uses virtualization-framework to run Linux containers on macOS in microVMs.
By analogy to not mix them up, it's a bit like KVM > QEMU > containerd.
Hope this helps!
The new Tahoe framework you're probably thinking of is Containerization, which is a WSL2-esque wrapper around Virtualization.framework allowing for easy installation of Linux containers.
So Linux is now a first class citizen on both Windows and Mac? I guess it really is true that 'if you can't beat em, join em.' Jobs must be rolling in his grave.
- Lima - wsl2-like access to a virtual machine https://github.com/lima-vm/lima/blob/master/README.md
- vfkit - CLI creation and management of applehv VMs https://github.com/crc-org/vfkit
- podman machine - easily run x86 containers in CoreOs, via the podman CLI https://docs.podman.io/en/latest/markdown/podman-machine.1.h...
Tested VMs on what? For VMs are used daily and there are, what, hundreds of millions of VMs running as we speak? Billions?
It looks roughly the same as when I took 15 years ago, except they switched to riscv from x86. Honestly, what you're describing sounds too difficult for a first assignment. Implementing irq handlers or syscalls on an existing codebase is far more realistic, plausible, and useful.
You can look up which top tier schools use it for OS classes.
connect -r
map -r
fs0:
bootaa64.efi
boot bin.rd
You can grab the files from: https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/
Actually installing the system is left as an exercise for the reader.
Traditionally BSD has booted very differently than Linux, because Linus adopted the same boot process as MINIX when he first developed it (since he was actually using the MINIX boot blocks at first).
BSD has historically used a bootstrap that understands V7FS/FFS and can load a kernel from a path on it. MINIX takes the actual kernel and RAM disk images as parameters so it doesn’t need to know about filesystems, and that tradition continued with Linux bootstraps once it was standalone.
https://marc.info/?l=openbsd-ports-cvs&m=121226747005033&w=2
I had discovered it searching on SourceForge originally, but the tmux creator Nicholas Marriott was already an OpenBSD user and he took MAINTAINER for the port.
A year later, tmux was imported by nicm@ to the OpenBSD base system, where it has remained upstream for last 16 years (GitHub sync's from OpenBSD).