[HN Gopher] Running GUI Linux in a virtual machine on a Mac
___________________________________________________________________
Running GUI Linux in a virtual machine on a Mac
Author : pram
Score : 199 points
Date : 2022-10-09 17:04 UTC (5 hours ago)
(HTM) web link (developer.apple.com)
(TXT) w3m dump (developer.apple.com)
| qwerty456127 wrote:
| Does this have to be this complex? Can't I just fire up a
| VirualBox as I do on Linux and Windows and go ahead?
| CharlesW wrote:
| You sure can. This is developer sample code, rather than
| something a typical user would use.
| mmis1000 wrote:
| I think this code is for who make VirualBox or similiar
| management software instead of end user. It basically
| demonstrate how to use macos's api to launch a virtual machine.
| olliej wrote:
| This documentation is more for the people who make virtualbox,
| rather than end users. All this is stuff that VirtualBox, etc
| already do on intel, you just don't see it because you're the
| end user.
| philipkglass wrote:
| You can, but running Linux with a graphical desktop on
| VirtualBox under MacOS has become extremely sluggish in my
| experience. I don't know whether newer releases of MacOS or
| VirtualBox itself are to blame. It was much snappier 8 years
| ago even though I had a significantly slower laptop then.
| coldtea wrote:
| > _You can, but running Linux with a graphical desktop on
| VirtualBox under MacOS has become extremely sluggish in my
| experience._
|
| Huh? It's actually faster than ever, and near native
| experience.
|
| And the post is not about "how to run" a virtual machine as
| an end user or dev (for that the way the parent describes is
| still the suggested way).
|
| It's about how to program running it under the hood if you're
| a developer who wants to develop something like a program
| that manages virtual machines or that hosts and runs one.
| philipkglass wrote:
| I'm only referring to the VirtualBox experience asked about
| by qwerty456127. Running e.g. Debian with Gnome under MacOS
| became extremely sluggish for me. The screen re-renders
| slowly, like running a remote desktop over a slow network
| link. I did a lot of searching and setting-tweaking when I
| encountered the problem earlier this year. I never found a
| satisfactory resolution. I tried this fix:
|
| https://mkyong.com/mac/virtualbox-running-slow-and-lag-on-
| ma...
|
| as well as others suggested on the VirtualBox forums, but
| couldn't get it running smoothly. I didn't have any trouble
| with a similar setup several years ago.
| 0x0 wrote:
| Not on Apple Silicon arm64 macs
| [deleted]
| naikrovek wrote:
| github.com/cirruslabs/tart is what I use, because it is a
| command-line tool. also, death to oracle.
| als0 wrote:
| Fails to build for me on macOS Monterey. It seems like you have
| to wait until macOS Ventura.
| 0x0 wrote:
| With UTM, I can already run GUI Linux arm64 on an M1 mac - on
| macOS 12.x. Works fine at least for 2d desktop stuff.
|
| I think UTM's arm64-macos guest support on arm64-macos12 hosts
| already use the macOS virtualization framework? Or is it
| hypervisor framework? Either way performance is very good.
| abinaya_rl wrote:
| Nice, There is official Apple documentation on running Linux GUI
| in VMs on Mac. So that means it's going to be Aashi linux
| competitor?
| benrow wrote:
| As I understand it, Asahi can run on bare metal of an Mx
| machine, including custom hardware/firmware due to their
| reverse engineering efforts. Running aarch64 Linux within a VM
| only needs to work with the simplified virtual hardware exposed
| by the VM.
| lobota wrote:
| What's so different compared to VMware on Mac?
| als0 wrote:
| I'm interested to see if this includes an example of harnessing
| Rosetta-based x86 translation from within the Linux VM. Here's
| the full documentation
| https://developer.apple.com/documentation/virtualization/run...
| forgotmypw17 wrote:
| This is how I do most of my work.
|
| Mac and Windows frequently perform non-consensual changes to my
| workstation. On the other hand, GNU/Linux is challenging for me
| to get working 100% on bare metal.
|
| This setup is reasonably fast for my work, which is mostly text
| editing.
| modeless wrote:
| Wow, you can use Rosetta to run x86 Linux binaries inside the VM
| on ARM? That seems pretty awesome.
| https://developer.apple.com/documentation/virtualization/run...
| watermelon0 wrote:
| I've tried using this a while back, soon after Apple released
| Ventura beta to developers.
|
| I can say that documentation (and examples) are quite nice and
| easy to follow, I managed to start Linux VM with Rosetta
| support, and SSH, in 1-2 hours.
|
| Geekbench numbers were quite close when running in VM (via
| Rosetta) and natively, they were only a few percentages slower
| in VM, so it stands to reason that computation heavy workload
| would run great.
|
| However, using development tools regularly resulted in
| segmentation fault or crashing for other reasons (e.g. when
| doing `npm install`). I didn't dig deeper to figure out what
| are the reasons for this.
|
| Additionally, real-world (from developer's point-of-view)
| workloads such as running web servers, building software, or
| running tests, were quite slow compared to running in an ARM
| VM.
| sascha_sl wrote:
| Only on Ventura, which isn't out yet (and quite frankly, the
| pre-release version is still a huge mess)
| zakjan wrote:
| Maybe I'm missing something, what are the actual commands for
| running a Linux x64 binary on macOS ARM?
| wtallis wrote:
| You don't run the Linux x64 binary on macOS ARM. You run the
| Linux x64 binary on Linux ARM inside a VM on macOS ARM.
| zakjan wrote:
| It seems overly complicated. Is there any benefit over
| using Docker?
| wtallis wrote:
| I'm not sure what you think Docker on a Mac does. Docker
| is a Linux-specific piece of software, and the only way
| to use it within macOS is to run a Linux virtual machine,
| with Docker running inside the Linux VM.
|
| If the containers you want to run with Docker are x86
| software, that Linux VM either needs to be an x86 Linux
| distro running in qemu emulation of a full x86 machine,
| or an ARM Linux distro using the new (not yet released in
| stable macOS) Rosetta for Linux translation.
| zakjan wrote:
| Sure, there is a VM in Docker as well. I'm sorry if it
| wasn't clear, I'm looking for the most straightforward
| way. With Docker it's a single command, it helps with
| documenting the steps for other coworkers. It feels slow
| though. I'm wondering if the new way with Rosetta is
| going to be better in performance.
| wmf wrote:
| Docker is equally complicated under the hood.
| zakjan wrote:
| Yes, but it's a single command to run, without the need
| to learn the internals, if the use case is just to run
| the binary.
| sascha_sl wrote:
| You just run them after you/your distro registers a handler
| for them. It uses binfmt behind the scenes.
|
| https://en.wikipedia.org/wiki/Binfmt_misc
|
| (To be clear, this is for running Linux x86 inside Linux
| arm64 VMs on an Apple Silicon host)
| aliqot wrote:
| You can do this in UTM, it's a GUI that wraps QEMU.
| mattl wrote:
| Has anyone seen a guide to installing OpenBSD on M1 Mac
| using UTM?
| aliqot wrote:
| No, but given that UTM is a graphical wrapper around QEMU
| would this be a worthy substitute?
| https://codeofconnor.com/running-an-arm64-openbsd-
| virtual-ma...
| mattl wrote:
| Thanks. I'll give it a go.
| oneplane wrote:
| UTM can use both native Apple Virtualisation and QEMU
| virtualisaion+emulation. The QEMU one can't make use of the
| M1/M2 Intel memory translation acceleration the same way
| native virtualisation can, but it can make use of
| acceleration on ARM64 workloads.
| MuffinFlavored wrote:
| I can't help but feel UTM pushed Apple to deliver this polished
| of a solution? Pulling this 100% out of thin air though.
| webmobdev wrote:
| With Apple, it is all about exerting control and crippling
| softwares that don't align with their goals. Don't be surprised
| if Apple suddenly forces developers to only use their
| virtualisation API on macOS, just like they did for application
| firewalls (that are no longer allowed to have their own custom
| kernel extensions for "security" and "stability"). They are
| slowly squeezing macOS to make it more and more like ios.
| coldtea wrote:
| > _are no longer allowed to have their own custom kernel
| extensions for "security" and "stability"_
|
| Why the "scare quotes"? Sounds totally justifiable. Third
| party kernel extensions have always have had issues with both
| security and stability.
| numbsafari wrote:
| They've been providing these APIs for a while for existing VM
| solutions in order to get rid of the kernel extensions
| previously needed. They keep evolving to support that use case.
|
| I've long thought it would be interesting to release Linux
| native apps in this sort of wrapper to the App Store.
| nottorp wrote:
| Isn't UTM a frontend for these APIs?
| renaudg wrote:
| Yes, these and QEMU
| hoistbypetard wrote:
| No. It uses qemu.
| nottorp wrote:
| Pretty sure I downloaded it and it let me set up a machine
| with or without qemu. Asked if i want virtualization or
| emulation.
| tambourine_man wrote:
| This link is also interesting:
|
| Running Intel Binaries in Linux VMs with Rosetta
|
| https://developer.apple.com/documentation/virtualization/run...
| punnerud wrote:
| Would not be surprised if they use the open source GPU driver for
| running Linux: https://news.ycombinator.com/item?id=33019316
|
| Or if this was a push to release the Linux support.
| oneplane wrote:
| It seems there is some confusion of what this page is about or
| why it might be relevant. This is not about an end-user product
| to run desktop virtualisation, but it is a page for developers in
| the Apple ecosystem to programmatically make use of OS-native
| virtualisation to create virtual machines with graphics output.
|
| The value in this is not as much that "it is possible" because
| there are plenty of implementations of this possibility, but it's
| more about the vendor-native support, vendor-native documentation
| and examples and the signal it gives about the current state of
| support.
|
| In the wild, an end-user (that includes developers, it's not a
| derogatory term, it simply mens the person the product is
| intended to be used by) might see applications like UTM, Veertu,
| Q and others use this under the hood.
|
| VirtualBox doesn't work on ARM by the way, they only release for
| x86(_64). So it can only virtualise, and only on x86 hosts for
| x86 guests.
| Maursault wrote:
| > VirtualBox doesn't work on ARM by the way, they only release
| for x86(_64).
|
| Because VirtualBox is not a CPU emulator, unlike QEMU,
| MAME/MESS, and other emulators. Virtualization software such as
| Fusion and Parallels run VMs of operating systems that match
| the architecture of the host OS. Intel VMs like those in
| VirtualBox will not run on Apple Silicon, and Apple Silicon VMs
| won't run on Intel. The CPU instruction sets are not
| compatible, nor can Rosetta 2 solve this.
|
| But an OS is arguably a tool used to run architecture
| compatible software, and much software will compile on
| different architecture platforms, so while it may not be
| possible to run VirtualBox on Apple Silicon, it may be possible
| to recompile whatever software is running on the virtual OS to
| native Apple Silicon. This is true for 10s of thousands of
| ports managed by MacPorts and much of the code available on
| GitHub, but it probably isn't true for proprietary software
| where the source code is unavailable.
| slickrick216 wrote:
| https://download.virtualbox.org/virtualbox/7.0.0_BETA3/Virtu.
| ..
|
| ;)
| Sirened wrote:
| For those not in tune with virtualbox, this beta lets you
| run 32-bit x86 guests on aarch64 macOS
| wila wrote:
| Sadly it does not appear to work that well..
|
| Quote:
|
| There has been no port to M1/M2. All there has been is
| early work that does nothing useful but somehow escaped
| the stables. You can safely forget all about it for now.
|
| [0]
| https://forums.virtualbox.org/viewtopic.php?f=15&t=106919
| oneplane wrote:
| I added some clarification. There is no VirtualBox on ARM
| platform. So you can't virtualise ARM on ARM with VirtualBox,
| because they don't make ARM compatible releases.
|
| But both VMWare and Parallels for example have made ARM on
| ARM virtualisation releases of their existing x86 on x86
| products.
|
| So if you need something like a sandbox or IR workstation,
| you can have plenty of virtual environments, just not with
| VirtualBox as supporting software and type 2 hypervisor.
| Maursault wrote:
| > But both VMWare and Parallels for example have made ARM
| on ARM virtualisation releases of their existing x86 on x86
| products.
|
| Right, but the VMs themselves are not cross platform. ARM
| Linux won't work in Intel VMWare, and x86 Linux won't work
| in ARM VMWare. I am sure you knew, or course, but as you
| pointed out there is confusion below about VirtualBox
| working on Apple Silicon.
| chrisseaton wrote:
| > ARM Linux won't work in Intel VMWare
|
| Newsflash: program for one processor's instruction set
| won't work on another processor.
| coldtea wrote:
| If only it was that clear cut.
|
| As you well know, with Rosetta and other technologies
| (heck, also Wine) that's just not true. With Rosetta you
| can take any (or most) Mac programs compiled for x86 and
| just run them on M1 ARM. Support gets even deeper, as
| with the Rosetta update you will be able to even run x86
| binaries inside a hosted ARM virtual machine (!).
|
| So it makes sense for people to be confused as to what's
| actually supported, and to add the clarification when
| this is not the case, because some might also expect this
| could be the case with say Virtualbox.
| chrisseaton wrote:
| > Well, with Rossetta and other technologies (heck, also
| Wine) that's just not true.
|
| Rosetta takes an instruction stream from another
| processor and translates it to an instruction stream for
| another processor - that's exactly what I mean - it needs
| translation.
| oneplane wrote:
| That is correct. But lets leave the VMs for now. The
| hypervisors is where the problem is at, if a hypervisor
| has no release for a specific platform, you cannot use
| it, period. That is the problem with VirtualBox. There is
| no VirtualBox for ARM. Only VirtualBox for x86. If you
| have an ARM host, and you wish you run an ARM guest, you
| cannot do that with VirtualBox. Because there is no
| VirtualBox for ARM.
| chrisseaton wrote:
| Doesn't AArch64 support the same virtualisation primitives
| that VirtualBox uses on AMD64?
| oneplane wrote:
| Yes and no. Similar in functionality, different in
| implementation. So you do get things like IOMMU etc. but
| you need a different software implementation to make use
| of it, even if only to use the different ISA and setup
| procedures.
|
| Imagine it like this:
| +-------------------------------------+ |higher-
| level software to abstract it |
| +----------------------------^--------+
| +---V---------------------------------+ |low-
| level software to make use of it |
| +----------------------------^--------+
| +---V---------------------------------+ |hardware
| with virtualisation support |
| +-------------------------------------+
|
| Even within the same architecture you might need
| different low-level interfacing software to make use of
| it. Even a type-1 hypervisor like Xen would need to know
| a bit about the specifics of the hardware to know what
| features exist and how to use them. Then you get some
| higher level abstractions that allow you to use a
| virtualisation interface to make use of the system
| without having to re-invent that interface every time
| some new hardware gets released.
|
| So if you have libvirt, you have a high-level abstraction
| for multiple hypervisors (like KVM and Xen) which in turn
| know how to interact with various hardware
| implementations to actually have it act the way we want
| it.
|
| On macOS there were essentially two low-level
| implementations, one for ARM and one for Intel, and a
| higher-level abstraction, Hypervisor.framework, that lets
| you simply "create" virtual machine instances, which then
| make use of the various virtualisation features depending
| on the underlying hardware.
|
| In the early days, the implementations between AMD and
| Intel were so different that you often needed specific
| builds for one or the other implementations, and you
| couldn't have both loaded at the same time (even if just
| 1 active and every other implementation inactive).
| Teknoman117 wrote:
| Just want to point out that QEMU can use your CPU's hardware
| virtualization extensions for VMs of the same architecture as
| your host, it's not exclusively an emulator.
| 999900000999 wrote:
| This looks absolutely fantastic, does this run at native speed
| though.
| elnatro wrote:
| I would prefer to run Linux GUI applications inside docker
| containers but, that's something.
| paulgb wrote:
| It takes some work, but you can pass in an XQuartz display to a
| Docker container and have it render to that.
| leoh wrote:
| Link?
| paulgb wrote:
| The closest thing I've seen to a comprehensive write-up is
| this: https://medium.com/@mreichelt/how-to-
| show-x11-windows-within... (medium, unfortunately)
|
| We've been using it experimentally to run an ephemeral
| instance of Firefox that we can programmatically inject DNS
| and CA certs into, for localhost HTTPS development. It's
| not documented yet, but the config is here:
| https://github.com/drifting-in-space/plane/pull/201
| amelius wrote:
| Does it expose the GPU?
| pram wrote:
| Yes, through virtio-gpu.
| jamesfmilne wrote:
| When you virtualise macOS it does expose the GPU, but only
| Metal is supported. However perhaps Mesa will be able to
| support OpenGL via paravirtualised Metal, for Linux and perhaps
| macOS and Windows.
| UniverseHacker wrote:
| Anyone think this might work with openbsd?
| pjmlp wrote:
| The year of desktop Linux has arrived, where all major desktop
| platforms run Linux distributions inside virtual machines.
| fbn79 wrote:
| I'm running Windows and MacOS virtualized in my Arch Desktop
| Linux from years
| [deleted]
| amelius wrote:
| The only problem: becoming root doesn't mean you now control
| the device (you paid for).
| pjmlp wrote:
| Basically just like container based distributions and cloud
| infrastructure. :)
| spijdar wrote:
| We've sort of been at this point for a long time, though, the
| abstraction bar is just being shifted up.
|
| Previously, the bar was at the firmware level, where you will
| never fully control the black boxes governing the security
| chips, DRM implementations and real time OSes running on the
| microcontrollers inside the CPU.
|
| Now the OS (especially on Apple devices) is almost becoming
| like the firmware layer itself, so deeply integrated and
| locked to the machine, but with the freedom to run other
| OSes/environments on top.
|
| At least you can (usually) still unlock the OS level...
| amelius wrote:
| I was sort of OK with the firmware being inaccessible when
| it couldn't talk to the internet. But times changed.
| ribit wrote:
| I feel like I pretty much have full control over my Mac
| laptop. Why would you expect to fully control a machine from
| inside a VM anyway? Sounds like a massive security risk too.
| amelius wrote:
| Security is entirely orthogonal here. It's like saying
| you're ok with not being able to enter your own house
| because of security.
| ribit wrote:
| If I lose the key, sure, getting inside the house will be
| more difficult, isn't that the entire point? Still, I
| don't understand the relevance of the analogy. I have
| access to the entire system and can pretty much tweak
| things as I want. I also happen to prefer the default
| macOS security model with the sealed system volume. Where
| exactly is control taken away from me?
| fsflover wrote:
| > I feel like I pretty much have full control over my Mac
| laptop.
|
| https://news.ycombinator.com/item?id=25074959
| ribit wrote:
| Oh please. You are quoting an issue that happened two
| years ago and Apple has already acknowledged that their
| algorithms were crappy and promised to reengineer this
| stuff. This is like claiming that Linux does not allow
| you to install software because a repository happens to
| be down.
| webmobdev wrote:
| The fact that Apple is working on virtualisation shows that there
| is a user demand for running alternative OSes on a Mac desktop.
| And yet, instead of opening up their hardware just a bit (by
| making available some hardware literature on their ARM SoC) to
| system developers, they'd rather offer a more convoluted way of
| running other OSes only on their terms and control. It's all
| about having control over your personal data folks - with Apple
| ARM chips, Apple can now ensure and push that the "best" way to
| run alternative OSes on Apple Silicon Mac hardware is only on top
| of macOS with virtualisation. This way, even if you use another
| OS (through virtualisation), macOS can still continue to datamine
| your personal data.
| Maursault wrote:
| > And yet, instead of opening up their hardware just a bit (by
| making available some hardware literature on their ARM SoC) to
| system developers, they'd rather offer a more convoluted way of
| running other OSes only on their terms and control. It's all
| about having control over your personal data folks
|
| I think the better argument is that it is what Apple says it's
| about, security. For the same reasons, we don't see Windows
| source code, nor are internally discovered Linux kernel
| security bugs advertised until they're fixed.
|
| _I personally consider security bugs to be just "normal bugs".
| I don't cover them up, but I also don't have any reason what-
| so-ever to think it's a good idea to track them and announce
| them as something special...one reason I refuse to bother with
| the whole security circus is that I think it glorifies--and
| thus encourages--the wrong behavior. It makes "heroes" out of
| security people, as if the people who don't just fix normal
| bugs aren't as important. In fact, all the boring normal bugs
| are way more important, just because there's[sic] a lot more of
| them. I don't think some spectacular security hole should be
| glorified or cared about as being any more "special" than a
| random spectacular crash due to bad locking._ -Linus Torvalds,
| 2008
|
| Instead of rolling over and vulnerably showing soft underbelly,
| armadillos fold in half, tuck in their legs and head, curling
| their tail beside the head and pull in tight, so that only
| their leathery armor shell is exposed. If they did what you
| wanted them to do, their species wouldn't exist for very long.
| derefnull wrote:
| There is already much user demand & vendor support for running
| virtual machines (including for Windows) on Apple hardware,
| through Parallels, VMWare and Qemu.
|
| Like there are options for containers, it is great to have
| another option for virtual machines.
| webmobdev wrote:
| Options are good. But the way Apple operates to exert control
| and cripples softwares that don't align with their goals,
| don't be surprised if Apple suddenly forces developers to
| only use their virtualisation API on macOS, just like they
| did for application firewalls (that are no longer allowed to
| have their own custom kernel extensions for "security" and
| "stability"). They are slowly squeezing macOS to make it more
| and more like ios.
| kitsunesoba wrote:
| They had the opportunity to do this when introducing the
| M-series Macs, because under the hood those work very
| similarly to iPhones and iPads. They could've done a direct
| copy-paste from the iDevice boot process and called it a
| day, but they didn't... they went out of their way to
| develop support for booting third-party operating systems,
| complete with a path for painless long term support with
| the flexibility of allowing the OS to choose which version
| of firmware to run on the hardware (so Apple can deploy
| compatibility breaking firmware updates for use with macOS
| without stepping on the toes of e.g. Asahi Linux).
|
| In macOS itself the main goal is to get third parties out
| of the kernel to the greatest extent possible, which makes
| perfect sense. Third parties, ideally, should be operating
| solely in userland, because otherwise you get pointlessly
| insecure nonsense like cloud file storage apps installing
| kernel extensions (like Dropbox used to on macOS).
| kitsunesoba wrote:
| I believe the bulk of the demand is coming primarily from a
| need to run Linux containers (e.g. docker images) than out of a
| desire to boot Linux directly.
|
| While there is demand for the latter (as demonstrated by the
| herculean efforts going into Asahi Linux), most people buying
| Macs are probably there at least partially for macOS and the
| ecosystem it fits into, as well as for the ability to run
| commercial software packages without a compatibility layer like
| WINE. All things considered it's probably generally easier to
| make headless Linux containers run acceptably on non-Linux
| hosts than it is to get complex UI software running acceptably
| under WINE or a Windows VM.
| jokethrowaway wrote:
| I would say people don't care too much and take the path of
| least resistance. If it was an out of the box option they
| would definitely love a system with good hardware and a
| configurable os.
|
| When I spent some time and installed Linux on my MacBook Pro
| 2015 some people came asking for instructions (and were
| mostly deterred by the compiling needed to build a driver for
| the webcam).
|
| Macbooks are unrivaled for their hardware (pretty much any
| other laptop sucks), the software is meh and keeps getting
| worse.
| alwillis wrote:
| Apple isn't "starting to work on virtualization"; it's been
| around for several years.
|
| You can also run FreeBSD:
| https://dan.langille.org/2018/10/02/running-freebsd-on-osx-u...
| lxe wrote:
| So we can finally have docker for Mac that doesn't run
| egregiously slow?
| jokethrowaway wrote:
| Lima is not too bad (but I'd use Linux if he support was there)
| psygn89 wrote:
| VirtioFS made it usable for me. Before that, I used Mutagen.
| indymike wrote:
| Our solution was to run Linux native on all dev machines.
| Docker really is a Linux tool and it works much better under
| Linux. We were running JetBrains IDEs and doing mostly Go,
| Python and JS development, so the switch was pretty easy and
| painless.
|
| The switch also dramatically reduced developer time spent
| solving Mac/Linux incompatibilities in tooling, and let us
| focus more on our product. Overall we accelerated development
| by about one day, per developer, per week. I was kind of
| surprised it was that much time, but looking back, there really
| are quite a few differences between the GNU userspace and
| MacOS.
| isoprophlex wrote:
| I swear I'm not trying to be facetious, not trying to stir
| the same old tired "hurrr year of the linux desktop" shit...
|
| I have to ask: you accelerate development by 1 day/week, but
| do your devs lose any time with the accumulation of tiny
| annoyance such as sorting out
| bluetooth/audio/hibernation/battery drain?
| kitsunesoba wrote:
| Yeah I could see maybe going full Linux if everybody were
| working on custom built towers where maximum compatibility
| for each component can be assured and sleep won't be a
| problem, but I wouldn't want to be stuck with supporting a
| fleet of laptops running Linux. My Tiger Lake ThinkPad
| which is a couple generations old (no longer cutting edge)
| and about as standardized/boring as it gets (Intel for most
| components, no fussy discrete GPU) runs Linux ok but has
| sleep issues that hamper its usefulness as a laptop.
| indymike wrote:
| > I have to ask: you accelerate development by 1 day/week,
| but do your devs lose any time with the accumulation of
| tiny annoyance such as sorting out
| bluetooth/audio/hibernation/battery drain?
|
| No. All of the above have been fine - save hibernate.
| Standard kit is a multidevice logitech bluetooth keyboard
| and mouse... no issues. A couple of the devs on my team use
| bluetooth headsets, and that too is no problem. The LG Gram
| gets about 16-19 hours on a battery, so we've not had drain
| issues. Audio hasn't been a problem. We did have issues
| with hibernation when we switched, and solved it by
| disabling hibernate, and setting the machine to sleep when
| the lid shuts. I've left my laptop in the bag, sleeping all
| weekend and had 70% battery on Monday morning.
| Incidentally, the battery is really not critical... 65W
| USB3 chargers are cheap so we mostly run plugged in.
|
| Your mileage may vary. Incidentally, LG is making a great
| machine right now. Huge 17" display, metal case, keyboard
| has a numeric keypad, great battery life, and it weighs 1
| oz more than a 13" Macbook Pro. Oh, and lots of ports.
| fsflover wrote:
| The things you mentioned can be problematic, unless you buy
| hardware specifically designed for Linux - then they should
| work flawlessly (they do for me).
| howinteresting wrote:
| Plenty of tiny (and big) annoyances on any platform. For me
| personally Linux has by far the least.
| switchbak wrote:
| I'm seeing many more folks with Docker centric workflows take
| the same approach.
|
| It's been mostly painless for me, minus the usual
| audio/Bluetooth snafu. Even those don't happen enough for me
| to be too concerned.
| Maursault wrote:
| > there really are quite a few differences between the GNU
| userspace and MacOS.
|
| This is why GNU/XNU OS distros should be a thing. I think
| this would satisfy most that want a fully functional "Linux"
| on Apple Silicon, being in its entirety OSS plus the ability
| to gain a fully compliant UNIX specification in stride, at
| least in practice if not actually registered.
| webmobdev wrote:
| GNU Coreutils - https://ports.macports.org/port/coreutils/
| - partly helps with this on macOS, but yes, custom distros
| are much better solutions.
| Maursault wrote:
| GNU coreutils are essential on macOS, and Apple should
| just include it by default. \o/
| alwillis wrote:
| Um... GNU's license is incompatible with Apple; that's
| why Bash 3.2 is the current version for macOS.
| gunapologist99 wrote:
| Not incompatible, except with Apple's business model;
| Apple has been removing GNU software for more than a
| decade:
|
| https://news.ycombinator.com/item?id=3559990
| selimnairb wrote:
| What hardware and distro+kernel version are you using? I am
| trying to do this on a 12th gen. Intel Dell XPS, and to be
| honest the hardware support isn't great. I had to install an
| upstream 5.19 kernel (rather than 5.15 that ships on Ubuntu
| 22.04). Sill, at least 2-3 times per week the machine fails
| to wake from sleep and has to be hard rebooted. Meanwhile my
| M1 Pro Mac 14" MBP routinely goes 3-4 weeks uptime, with
| reboots only for OS update. What am I missing?
| indymike wrote:
| I just switched from an XPS 15 to an LG Gram. In both
| cases, I thought I had problems, until I bit the bullet and
| set up Ubuntu (well, in my case, Kubuntu) to do secure
| boot. Then everything just worked, except for the
| fingerprint reader.
| viraptor wrote:
| Anything in the logs? It just works for me on xps (fedora
| since 28 till latest). Fwiw, my mac has issues with sleep,
| so there seems to be some luck involved either way.
| selimnairb wrote:
| My last Intel MBP had sleep issues (2019 i9), but this M1
| Pro has been bulletproof.
|
| I will look in the logs. I am also planning to "upgrade"
| to Ubuntu 22.10 when it comes out since it will ship with
| an Ubuntu-patched 5.19 kernel. Failing that, if I don't
| find anything in the logs or don't have time to find a
| root cause (more likely), I may have to give up and
| switch to Windows 11 (sigh).
| hhh wrote:
| You can do this now. I use Multipass to get rapid linux VMs
| with access to my files.
|
| For Kubernetes, I use Rancher Desktop (which can also do some
| docker magic)
| Sirened wrote:
| Are there any good, free desktop hypervisor apps for ARM macOS at
| this point? I always used VirtualBox on Intel but they don't
| support ARM guests on ARM hosts so I've been stuck using qemu,
| which is not so great performance-wise. I know I can use the APIs
| linked here but I would rather not build my own hypervisor client
| if at all possible haha
| renaudg wrote:
| UTM. It's a GUI for both QEMU and the native macOS hypervisor
| framework
| derefnull wrote:
| Also, the main page
| https://developer.apple.com/documentation/virtualization shows
| support for running virtualized macOS.
|
| This is pretty exciting, and appears to be a macOS answer to
| libvirt
| mistrial9 wrote:
| compiling curl today on linux, I see Apple has an internal
| SSL/TLS curl-7.81.0$ ./configure --help | grep
| -i apple --with-secure-transport enable Apple OS native
| SSL/TLS
|
| MSFT is adding new signing keys to build and boot Ubuntu. Perhaps
| Apple wants to play, too and add their own signing keys to build
| and boot linux, openssl and libssh.
|
| Let no crucial technology fall into the hands of the un-
| corporate?
| oneplane wrote:
| The Microsoft equivalent of this is SecureChanel and none of
| this has to do with signing keys or booting.
| comex wrote:
| SecureTransport is a system library on Apple operating systems
| that implements TLS. It doesn't exist on Linux. The configure
| help output is showing it on Linux because it doesn't filter
| the list of options based on the OS you're running on. (Nor
| should it, since you might hypothetically want to cross-compile
| a binary for a different operating system than the one you're
| running on.)
| riffic wrote:
| are darwin-native containers on Apple's road map at all?
|
| previously: https://news.ycombinator.com/item?id=28430196
| nynx wrote:
| I so, so want to be able to spin up linux VMs on iOS devices.
| capableweb wrote:
| The opposite would be much more interesting and finally make
| cross-platform CI bearable without relying on closed source
| third-parties.
| nynx wrote:
| I guess that's be cool. I just want to take advantage of this
| phone that I carry around in my pocket that's more powerful
| than my laptop.
| jayd16 wrote:
| You'd still need a Mac with xcode for the build, no?
| capableweb wrote:
| Not really, I'm already doing Rust builds with macOS SDK on
| Linux for M1/M2 which works... Fine I guess, but it's hacky
| as hell.
|
| It's testing that's the problem really, where you really
| need the hardware.
| amelius wrote:
| I'm still waiting for a Wine-equivalent where iOS takes the
| place of Windows.
| yndoendo wrote:
| Not IOS yet but macOs middle-ware like WINE.
| https://www.darlinghq.org/
| newaccount74 wrote:
| There is iSH -- it's just a single VM, but it's pretty sweet
| nonetheless.
| fragmede wrote:
| https://ish.app/
| Sirened wrote:
| The most recent hardware actually do support ARM hypervisor
| extensions so you can actually run raw linux on iOS hosts :)
|
| https://worthdoingbadly.com/hv/
| Aissen wrote:
| It's 2022 and we are still running installers in VMs ? Give me a
| pre-installed VM with cloud-init, it'll be fine, thank you.
| aliqot wrote:
| UTM works great. Emulate X86, AMD64, or run on Apple Silicon.
| It's essentially a GUI on top of QEMU.
|
| https://mac.getutm.app/
| protomyth wrote:
| The only problem seems to be that it won't allow you to run an
| earlier OS X that can still run 32-bit programs.
| oneplane wrote:
| Those earlier macOS versions don't have the frameworks to run
| virtualisation with. There are some hacks (mackintosh-ish)
| that allow you to run very old Intel releases on non-ARM
| releases, those virtualise the CPU but emulate nearly
| everything else.
| sdevonoes wrote:
| Another problem is that it's not programmatic (e.g., like
| Vagrant), so it's tiresome to spin up/down a bunch of VMs.
| wmf wrote:
| There are several tools to create VMs from the CLI or
| scripts like QEMU, docker machine, and podman machine.
| miles wrote:
| The comment you replied to was about UTM, which does allow
| running earlier versions of macOS/OS X on Apple silicon
| hosts:
|
| Virtualizing OpenCore and x86 macOS on Apple Silicon (and
| even iOS!) https://khronokernel.github.io/apple/silicon/2021/
| 01/17/QEMU...
|
| Run Tiger, Leopard, or any Mac OS X PowerPC version on M1
| https://tinyapps.org/docs/tiger-on-m1.html
| protomyth wrote:
| Their website says differently _Note that macOS VM support
| is limited to ARM based Macs running macOS Monterey or
| higher._ https://mac.getutm.app/
| rafram wrote:
| That means that the _host_ has to be on Monterey or
| higher. The guest can be any macOS version.
| miles wrote:
| > Their website says differently _Note that macOS VM
| support is limited to ARM based Macs running macOS
| Monterey or higher._
|
| While ARM virtual machines are limited to Monterey and
| higher on Apple silicon[0], emulation works just fine for
| x86, PowerPC, etc.
|
| Here's a video I cobbled together of UTM running Tiger on
| an Apple silicon Big Sur host:
| https://tinyapps.org/screenshots/tiger-on-m1.mp4
|
| and another of the same host running Windows XP:
| https://tinyapps.org/screenshots/20210522-utm-xp.mp4
|
| [0] https://kb.parallels.com/125561 "To run a macOS
| Monterey VM on Mac computers with Apple M1 chips,
| Parallels Desktop 17 uses new technology introduced in
| macOS Monterey, that's why it is not possible to run
| earlier versions of macOS on a Mac with Apple M1 chips."
| Maursault wrote:
| I really like UTM's business model: identical free software if
| you want it, or 10 bucks if you want automatic updates and to
| fund UTM development.
___________________________________________________________________
(page generated 2022-10-09 23:00 UTC)