RHEL does not include qemu-user-static, consider alternatives.
- In WSL2 run:
sudo apt update
sudo apt install qemu qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils cpu-checker \
network-manager iptables-persistent linux-headers-generic \
qemu uml-utilities virt-manager git \
wget libguestfs-tools p7zip-full make dmg2img tesseract-ocr \
tesseract-ocr-eng genisoimage vim net-tools screen firewalld libncurses-dev -y
sudo apt install virt-manager
sudo addgroup kvm
#include <stdio.h> | |
#include <string.h> | |
#include <sys/types.h> | |
#include <unistd.h> | |
#include <Security/Security.h> | |
// Compile with: | |
// gcc -o ourpath -framework CoreFoundation -framework Security main.c |
Guide updated to use the official installation .iso from Microsoft, which finally became available in Dec. 2024! For the VHDX disk image based guide check an earlier version of this gist.
When following this guide on a host not capable of aarch64 virtualization, replace -cpu host -accel kvm
with -cpu max
.
- Download the installation .iso from https://www.microsoft.com/en-us/software-download/windows11arm64. Win11_24H2_EnglishInternational_Arm64.iso is known to work.
- Download the the latest virtio-win.iso from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/.
- Create a disk image for the Windows installation:
qemu-img create -f qcow2 win11.qcow2 25G
- Start the installation with generic (ramfb for display, usb-storage for .isos) as well as virtio (virtio-gpu-pci, virtio-block) devices: `qemu-system-aarch64 -M virt -cpu host -accel kvm -m 4G -smp 4 -device ramfb -device virtio-gpu-pci -bios /usr/share/qemu/qemu-uefi-aarch64.bin -device qemu-xhci -device usb-kbd -dev
#!/usr/bin/env bash | |
# virtualapple-utm-link | |
# Karen/あけみ (akemin_dayo) | |
# https://gist.github.com/akemin-dayo/8337d8274deddfefae5d1543420ca0b1.git | |
# This is a cleaned up version of an internal script that I've been using while working on TotalFinder to create VirtualApple virtual machine instances that are hardlinked to a UTM virtual machine instance. | |
# It's particularly useful for entering One True recoveryOS (1TR) as well as using the other features found only in VirtualApple. | |
# UTM does not support entering 1TR for macOS 12 hosts (yet?), though it is now possible on macOS 13 hosts (utmapp/UTM/issues/3526). |
If you want to change things on the root drive of a Mac you will need to take some steps to disable the built in security of the system. Most of these steps are the same regardless if you are on Intel or Apple Silicon. If there is a difference it is noted.
Note that all of these things put a Mac into an unsupported and less secure state.
Make sure you either perform these steps in a VM or that you reset the protections after you are done poking around
(This list is not exahustive on the details of each. Check the links at the end for more info.)
On systems with UEFI Secure Boot enabled, recent Linux kernels will only load signed modules, so it's about time DKMS grew the capability to sign modules it's building.
These scripts are extended and scriptified variants of https://computerlinguist.org/make-dkms-sign-kernel-modules-for-secure-boot-on-ubuntu-1604.html and https://askubuntu.com/questions/760671/could-not-load-vboxdrv-after-upgrade-to-ubuntu-16-04-and-i-want-to-keep-secur/768310#768310 and add some error checking, a passphrase around your signing key, and support for compressed modules.
dkms-sign-module
is a wrapper for the more generic sign-modules
which can also be used outside of DKMS.
- Create a directory under
/root
, say/root/module-signing
, put the three scripts below in there and make them executable:chmod u+x one-time-setup sign-modules dkms-sign-module
As of macOS 12 (Monterey), Apple's Virtualization framework has nice support for macOS guest virtual machines, but with severe limitations: For example you can't install a macOS guest on Intel Macs, install guests with newer versions of macOS than the host, copy and paste between the host and the guest, or install third party kernel extensions in the guest. As usual for Apple, the functionality they do support is nicely implemented, but they've left out so much that the result is only marginally useful -- at least compared to
The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).
My take-aways are:
-
You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.
-
Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse