Hacker News new | past | comments | ask | show | jobs | submit login

Being mean here:

Why use either? Aren't they both just "opinionated" wrappers around this basically:

    qemu-system-aarch64 \
      -M virt,accel=hvf \
      -cpu host \
      -smp cpus=8 \  
      -m 8192 \
      -boot d \
      -drive if=pflash,format=raw,file=/opt/homebrew/Cellar/qemu/9.0.0/share/qemu/edk2-aarch64-code.fd \
      -drive if=virtio,format=qcow2,file=debian-12-nocloud-arm64.qcow2 \
      -net nic \
      -net user,hostfwd=tcp::2222-:22,hostfwd=tcp::6443-:6443 \
      -device virtio-gpu-pci \
      -device nec-usb-xhci \
      -device usb-kbd \
      -device usb-tablet \
      -nographic



followed by "the rest of the owl," since I doubt very seriously that debian-12-nocloud-arm64 boots up docker or containerd and your cited command does not mount $HOME in qemu such that $(docker run -v $HOME/work:/work debian:12) would do something reasonable from within the VM

If you were interested, Brew also offers "opt" links to avoid hard-coding version numbers into paths:

      -drive if=pflash,format=raw,file=/opt/homebrew/opt/qemu/share/qemu/edk2-aarch64-code.fd \
and if one happens to be already running with $(brew shellenv) then

      -drive if=pflash,format=raw,file=${HOMEBREW_PREFIX}/opt/qemu/share/qemu/edk2-aarch64-code.fd \
will allow the script to work on both arm and x86_64 setups




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: