Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Development on Apple Silicon with UTM

rkiselenko.dev

Post reply on HN
Print view View original

11–20 of 76 posts

Re: Development on Apple Silicon with UTM

#11

Post by thinker5555 »

Maybe I'm just really out of my depth on this, but it feels like there's not a lot of information about _why_ these particular steps and tools are used. Why are 4 different Linux images needed? Why are there all of these steps to create a one-time use "init.iso"? Is it just so the cloud-init script can run? I see the call to mkisofs is referencing "cidata", but it's the only place in the whole page that "cidata" shows up. Does that mean mkisofs is cloud-init aware? And why use emulation instead of virtualization?

I guess part of why I'm asking is because I've set up virtual machines in UTM on Apple Silicon before, and I never had to go through all of this just to get Linux installed and configured. The post makes me wonder if there's something I'm maybe missing, but it doesn't give any explanation for me to be able to figure out if that's the case. Maybe the post is meant more just as a checklist for the person that wrote it, for their own reference? But the way the post reads doesn't quite sound that way.

Hmm... that's all coming out sounding more critical than I mean to. I just want more info and I am curious about the approach.

Re: Development on Apple Silicon with UTM

#12

Post by worldsavior »

pmarreck wrote: post #7
robin_reala wrote: post #2

Not sure why this recommends emulation instead of installing the native ARM images referenced near the top of the page?

A lot of dev tooling still expects x86_64. Example off the top of my head, Cosmopolitan will not build ARM binaries and will not compile on ARM. (But it WILL build x86_64 universal binaries that will run on Apple Silicon and macOS via Rosetta.) There is also the issue of wanting to have your dev environment be as close to your prod environment as possible, and the vast majority of cloud-based hosting is still x86_64.

Building on a virtual x86_64 barely achieves the performance when building on host, if there was an applicable way.

Re: Development on Apple Silicon with UTM

#14

Post by vbezhenar »

The most severe limitation that I've found is inability to work both with x86 (Rosetta) and USB passsthrough. qemu does not support Rosetta and Virtualization.Framework does not support USB passthrough. In the end, I abandoned Macbook and moved to Thinkpad because of that.

Re: Development on Apple Silicon with UTM

#15

Post by larusso »

thinker5555 wrote: post #11

Maybe I'm just really out of my depth on this, but it feels like there's not a lot of information about _why_ these particular steps and tools are used. Why are 4 different Linux images needed? Why are there all of these steps to create a one-time use "init.iso"? Is it just so the cloud-init script can run? I see the call to mkisofs is referencing "cidata", but it's the only place in the whole page that "cidata" show…

My thought was why use UTM? Most of this can be achieved with qemu alone :). But it showed me something new. The cloud init tool was new to me. From my toolbox I would have used ansible or something. But I think it very interesting that this runs all automatically during first boot. But I agree one needs to read between the lines to understand what the purpose of this post is. As you said it reads like a overcomplicated install setup.

Re: Development on Apple Silicon with UTM

#16

Post by Zanfa »

thinker5555 wrote: post #11

Maybe I'm just really out of my depth on this, but it feels like there's not a lot of information about _why_ these particular steps and tools are used. Why are 4 different Linux images needed? Why are there all of these steps to create a one-time use "init.iso"? Is it just so the cloud-init script can run? I see the call to mkisofs is referencing "cidata", but it's the only place in the whole page that "cidata" show…

If you just need a single Linux VM, you don't need to fiddle with cloud-init. If you want repeatability or automation, that's when you'd reach for it, whether for setting up per-project VMs, shareable VM configs between developers etc.

Also, you don't need all 4 Linux images, just the one you want to run as your guest OS. Emulation / virtualization depends on the guest OS CPU architecture.

Re: Development on Apple Silicon with UTM

#17

Post by jbverschoor »

Although I would'e loved to use UTM, it's still a resource hog. OrbStack (machines) does such a great job at being lightweight.

Is it already possible to connect an external screen to UTM and use that as the main screen? (Multi-port Adapter or iOS, or a displaylink usb dongle on Macbook).

That would enable some great stuff. Until then, I don't think the overhead is worth it for me

Re: Development on Apple Silicon with UTM

#19

Post by nottorp »

Hmm I haven't tried x86 linux on utm on an arm mac (i have an x86 linux box i can ssh in), but i tried x86 windows. It was so slow as to be unusable.

Edit: would command line linux be usable, considering it doesn't have to emulate all those pixels?

Re: Development on Apple Silicon with UTM

#20

Post by znpy »

larusso wrote: post #15
thinker5555 wrote: post #11

Maybe I'm just really out of my depth on this, but it feels like there's not a lot of information about _why_ these particular steps and tools are used. Why are 4 different Linux images needed? Why are there all of these steps to create a one-time use "init.iso"? Is it just so the cloud-init script can run? I see the call to mkisofs is referencing "cidata", but it's the only place in the whole page that "cidata" show…

My thought was why use UTM? Most of this can be achieved with qemu alone :). But it showed me something new. The cloud init tool was new to me. From my toolbox I would have used ansible or something. But I think it very interesting that this runs all automatically during first boot. But I agree one needs to read between the lines to understand what the purpose of this post is. As you said it reads like a overcomplica…

> My thought was why use UTM? Most of this can be achieved with qemu alone :)

qemu needs to be studied a bit, UTM is fairly intuitive.

I recently decided to learn how to create VMs with bare qemu (using the command-line).

As I have an arm macbook for work, UTM helped me a ton with aarch64 virtual machines because I could enable debug log and see what qemu options/flags/switches would UTM use.

Unrelated: I have some ideas about writing a tool that aims at being a "spiritual successor" to vagrant (from hashicorp), but focused on targeting qemu rather than virtual box.

Anyone interested? Please let me know (upvote or comment)

Post reply on HN