Live data from Hacker News

How fast is a macOS VM, and how small could it be?

eclecticlight.co

101–110 of 111 posts

Re: How fast is a macOS VM, and how small could it be?

#101
post #55
post #49

Earlier quoted context omitted.

Seeing there are thousands running those apps (incl. Freeform) without memory leaks, it could be something else at play here.

It's quite clearly a bug and likely not one easy to diagnose or reproduce given the length of time the bug has remained in macOS. Or a fix would be a drastic breaking change. Or Apple doesn't really care, though I doubt that's the case.

It seems rather easy to diagnose actually any of those users could use the heap profiling tools that ship with the OS

Re: How fast is a macOS VM, and how small could it be?

#102
post #6

Earlier quoted context omitted.

I don’t assume that macOS virtualization is advanced enough to support memory ballooning, or is that not what you’re referring to? Edit: I stand corrected!

I don't assume anything either, but a single Google search is enough to dispel that [1] [1] https://developer.apple.com/documentation/virtualization/vzv...

Not supported on macOS

Re: How fast is a macOS VM, and how small could it be?

#103
post #7

>Starting with 4 virtual cores and 8 GB vRAM, where the VM ran perfectly briskly with around 5 GB of memory used, I stepped down to 3 cores and 6 GB, to discover that memory usage fell to 3.9 GB and everything worked well. With just 2 cores and 4 GB of memory only 3.1 GB of that was used, and the VM continued to handle those lightweight tasks normally. Good reminder that there's a certain amount of memory tied up wit…

As a general rule, also the amount of physical memory installed in a computer should be proportional with the number of hardware threads provided by its CPU. Besides the fact that the operating system may allocate some memory for each thread, when you launch a multi-threaded application that is able to use all available threads, for instance the compilation of a big software project, it frequently will allocate some…

> when you have only 32 GB for a 16 core/32 thread CPU, you must reduce the number of concurrent compilations

Also, depending on the architecture, avoiding odd(or even) virtual cores might free more L2 or L3 for the worker threads and speed up the process.

Re: How fast is a macOS VM, and how small could it be?

#104
post #98
post #75

Earlier quoted context omitted.

I'm happy for your personal experience; it clearly doesn't jive with the numerous threads on the macos reddit forum for first and third party apps causing OOM issues (which macOS ungracefully handles, unlike NT). > Not sure what your intentions are. This is just a weird statement. > Yes, modern OS's might have issues in runtime /All/ modern general purpose OSes have issues at runtime. Every last one of them. macOS is…

Looking at your comment history - it does seem you have an agenda. I don't get it. Yet your references are mostly anecdotes from random forums that back your claim. You'll find that for any OS or any piece of software if you go looking.

> Looking at your comment history - it does seem you have an agenda.

This is just weird behavior for HN. I suggest you re-evaluate how you participate in conversations, here.

Re: How fast is a macOS VM, and how small could it be?

#105

Earlier quoted context omitted.

There is some overhead per-core, you're right, but imo this reduction in usage is likely from how the kernel allocates available memory, which is being reduced as well. The kernel will keep read caches around longer with more memory, it'll prefer to compress memory instead of swap to disk if it has more, it'll purge/cleanup reclaimable memory less often with more memory, etc. It even scales its internal buffer sizes…

Single inline backticks like `this` aren't recognized (although still useful in my opinion, they just don't change the rendering). Triple backticks also aren't recognized. However, if you indent by I believe 4 spaces, it formats it in a fixed width font presuming it's code. Let's try (4 spaces): func main() { fmt.Println("Hello, HN!") } None for comparison: func main() { fmt.Println("Hello, HN!") }

2 spaces triggers the formatting, the rest just get printed: https://news.ycombinator.com/formatdoc

  2 spaces Lorem ipsum dolor sit amet,
  consectetur adipiscing elit, sed do eiusmod
  tempor incididunt ut labore et dolore magna
  aliqua.
vs

    4 spaces Lorem ipsum dolor sit amet,
    consectetur adipiscing elit, sed do eiusmod
    tempor incididunt ut labore et dolore magna
    aliqua.

Re: How fast is a macOS VM, and how small could it be?

#106
post #7

>Starting with 4 virtual cores and 8 GB vRAM, where the VM ran perfectly briskly with around 5 GB of memory used, I stepped down to 3 cores and 6 GB, to discover that memory usage fell to 3.9 GB and everything worked well. With just 2 cores and 4 GB of memory only 3.1 GB of that was used, and the VM continued to handle those lightweight tasks normally. Good reminder that there's a certain amount of memory tied up wit…

[flagged]

Re: How fast is a macOS VM, and how small could it be?

#107

Earlier quoted context omitted.

Try Apple's container CLI. I moved a project of mine from colima+docker to it relatively easily, a couple of weekends ago. https://github.com/apple/container

Here's an example of how to build a simple Alpine Linux container using Apple's containerization CLI. It also demonstrates how to connect to the container through Tailscale SSH using a Tailscale auth key stored in Apple Keychain: https://github.com/highpost/tailscale-macos-container

Why would this be preferred over the Tailscale macOS app? What are the advantages of this method?

Thanks.

Re: How fast is a macOS VM, and how small could it be?

#109
post #91
post #72

Earlier quoted context omitted.

Does this project aim for docker cli and api compatibility? Searching for Docker on that page yields no results. Though in their example, they do show an example of a Dockerfile referencing docker.io without shame. Typical Apple behavior, I guess, but grating to see in a OSS tool.

This is a weird take, imho. Should they feel shame for using Dockerfiles in their OCI-standard-compliant tool? Would you be happier if they introduced subtly incompatible Applefiles? Why are they obliged to emulate the Docker CLI? This limits them to just shadowing someone else's product. Just use Docker if you want their CLI/API, it uses the same virtualization framework under the hood on Macs.

Isn’t Containerfile a bit more neutral ground?

Re: How fast is a macOS VM, and how small could it be?

#110
post #107

Earlier quoted context omitted.

Here's an example of how to build a simple Alpine Linux container using Apple's containerization CLI. It also demonstrates how to connect to the container through Tailscale SSH using a Tailscale auth key stored in Apple Keychain: https://github.com/highpost/tailscale-macos-container

Why would this be preferred over the Tailscale macOS app? What are the advantages of this method? Thanks.

The macOS app manages the host Tailscale service, while this example demonstrates how to connect with a *macOS container* using Tailscale SSH based on the Tailscale service under userspace networking mode. This gives the container its own dedicated Tailnet IP and identity without needing to port-forward through the host.

edit: For example, I can create a container on my MacBook to run an application. A colleague *in my Tailnet* can then connect to this container to interact with that application from a coffeeshop or airliner while not exposing the rest of my MacBook.

Post reply on HN