Vasil

It is about both, and the distinction is the key to the whole area.

That product is a virtualiser, not an emulator. Virtualisation means the guest's instructions run directly on the host processor, with the hypervisor managing isolation and hardware access. That is why it is fast, and it requires the guest and host to share an instruction set.

An Apple Silicon Mac has an ARM processor. An x86 guest does not share an instruction set with it, so there is nothing to virtualise — the instructions would have to be translated, which is emulation and a fundamentally different and much slower proposition.

So the requirement means: x86 host, x86 guest. The project's own maintainers have stated they do not intend to port it, for the same reason it does not exist on other ARM platforms.

What you can do instead splits along exactly this line.

Small note if the goal is specifically a dark room: the keyboard backlight and the display's automatic brightness are separate systems with separate settings.

Turning off keyboard backlight ambient adjustment does not affect the display, and vice versa. People often turn one off, find the room still lights up, and conclude the setting did not work.

Stepping back: for the workflow you describe — a file you actively edit on two machines in quick succession — a document sync service is the wrong tool, and the delays are not really the problem.

The real risk is that both machines edit the same file and you get a conflict, which cloud document sync resolves by keeping both versions and letting you sort it out. For code in particular that is a bad experience.

Use version control. A repository, even a local one pushed to a private remote, gives you explicit commits, explicit pulls, real conflict resolution and history. For a file you edit in a code editor across two machines this is the correct tool and it removes the entire category of problem.

It also happens to be much faster, because you decide when the transfer happens.

For utilities you genuinely need but rarely click, check whether they can be driven another way — a keyboard shortcut, a command line interface, or a shortcut automation.

Several of the popular menu bar tools have all three, and moving one or two off the bar entirely and onto a hotkey is often better than managing them. It also survives you buying a different machine with a different bar.

A broader suggestion for development databases on a laptop: run them in containers rather than as system services.

Each project gets its own container with a pinned version and its own data volume. Upgrading one project does not affect another, versions never collide, and removing everything is one command. The whole class of problem in this thread disappears.

The package manager route is simpler for a single database you always want running, and it becomes fragile as soon as two projects want different versions.