“We’re not direct booting an alternate operating system,” says Craig Federighi, Apple’s senior vice president of software engineering. “Purely virtualization is the route. [...]”
https://www.theverge.com/2020/6/24/21302213/apple-silicon-ma...
To be clear, I'm not saying that there couldn't possibly be any good reason for wanting to run Linux on a Mac desktop. But desktops are already a niche product for Apple, and people who want to run Linux on Mac desktops are arguably a tiny niche within a niche.
In fact macOS itself is more restrictive nowdays than it used to be.
Is the worry that Apple and its practices will dominate the industry to the point that you literally will not be able to turn on your current machine and use it?
I know you're joking, but I actually kind of am...
Apple has a tremendous amount of industry influence, just see removal of the headphone jack.
When macOS deprecates support for these ARM Macs in 5-7 years, Linux isn't an option for them unless Apple puts in a lot of work to support a mainline Linux kernel on their hardware. Apple has said they won't support running other operating systems on these ARM Macs unless they're virtualized.
Why would Apple need to "put a lot of work in"? Apple doesn't support Linux on 86 either. Third parties did the Mac Linux ports for 86, and will do them for the ARM Macs.
The only thing Apple needs to do is to not lock the ARM Macs from booting another OS, which is very easy to do -- Apple doesn't need to invest lots of work to run Linux on ARM Macs, just needs not to prevent it.
Because ARM SoCs are fundamentally different than 32-bit and 64-bit x86 machines. The prime difference is the lack of an enumerable bus that even some ARM servers have, but are missing in ARM SoCs.
I bought an x86 Mac when they were first released and I was able to boot an Ubuntu live CD when I got it. No work was needed to get a mainline kernel running on a x86 Mac, but work was needed to support things like Apple's SMC and cameras etc.
> The only thing Apple needs to do is to not lock the ARM Macs from booting another OS, which is very easy to do -- Apple doesn't need to invest lots of work to run Linux on ARM Macs, just needs not to prevent it.
This is not true. Given the lack of an enumerable bus, someone will need to either fork the kernel and hardcode addresses for hardware, or someone will need documents to build out the DeviceTree. If hardware doesn't conform to existing standards, which nearly every ARM SoC follows their own, someone will need to do further work port the kernel to the machine. All the special deviations from standards that Apple baked into their hardware either needs to be documented accurately, or Apple needs to put the work in to get mainline Linux running on their SoCs.
This is a general problem in the ARM SoC and Linux space, and is not unique to Apple's SoCs. There are millions of ARM SoCs that are either stuck on old kernel forks because vendors never put the work in to get mainline Linux to support their SoCs, or they will never run Linux at all, ever. I don't even think all of the Raspberry Pi models have mainline support yet, and those that do only have it because of the work put in by the RPi Foundation, which has access to some vendor documentation, but I don't believe all.
To get an idea of the scope of the problem concerning Linux support on ARM SoCs, check out this presentation[1].
'Purchasing' a Kindle book or video on Amazon is also renting for example and yet it does not mean you have to continue paying and yet you don't own the copy as Amazon's going to decide how you're allowed to consume it and if they're going to let you keep it[1][2].
1 - https://en.wikipedia.org/wiki/Amazon_Kindle#Criticism
2 - https://www.hollywoodreporter.com/thr-esq/amazon-argues-user...
In particular, this is the first 5nm chip to be widely available, and by most accounts on performance it competes with top of the line hardware at a small fraction of the power use. Most existing ARM chips are designed for the very-low-power market, e.g. in phones, not to be used in a high performance laptop.
If there's a Dell or Thinkpad laptop with an ARM chip that's comparable, by all means, let me know.
That's part of the value proposition (leave it or take it).
There is a massive marketplace for tinkering on computers, from Arduinos to multi-GPU ML rigs. Trying to optimize for both classes of things seems like a foolish endeavor, especially when Linux users represent such a small fraction of the desktop market.
It's not clear to me that the new Macs won't allow booting Linux if the Linux community can figure out how to do it. The number of folks booting Linux on Mac via Boot Camp has to be really tiny.
For comparison you can check the progress of Linux on iPhones (which is actually a thing!)
https://forums.macrumors.com/threads/running-linux-on-apple-...
Mainline Linux support requires a lot of work from vendors. Check out the ARM SoC Linux market for an abundance of examples of this problem. Many of the devices will be forever stuck an old kernel fork and will never run a mainline kernel.
https://support.apple.com/guide/mac-help/macos-recovery-a-ma...
When it comes to ARM SoCs, Linux requires vendor support to get it running. If you want mainline kernel support, that requires even more work that many vendors just aren't providing.
A locked bootloader is just one issue to overcome for Linux support. A lot of the real issues come down to the lack of an enumerable bus on ARM SoCs, along with a lack of drivers.
Without vendor support from Apple to support Linux, these devices will be like the millions of iPhones and iPads that don't run Linux and will never run Linux.
Most ARM SoCs that are sold explicitly as mini Linux computers also have this problem. Many of them are stuck on old kernel forks, because vendors didn't give the proper support their SoCs needed to run a mainline Linux kernel.
tl;dr: For Linux to be a viable option on Apple's SoCs, Apple needs to put in a lot of work to explicitly support Linux. Without that vendor support, you will never be able to download a Linux ISO and install it like you can on an x86 Mac.
Even if Apple does nothing to stop you running whatever software you like on the device, you’re still likely to be out of luck. I wouldn’t be surprised if some enterprising folks have a good run at it, but it’s likely to be a massive undertaking.
But if you want full control over your hardware... Apple isn't the way to go. I'm not even sure what the "OS of our choice" means when we're talking about a custom-designed SoC. The amount of reverse-engineering required to get any other OS to work would be staggering, no?
If you want to run a custom OS natively, you need to buy a laptop with a commodity chip, not a custom one. Fortunately, there are tons of them.
If Apple had decided to support it, that is.
Apple's hypervisor technology runs natively on the M1; Linux running on that will be faster than Linux running on anything else you can buy for the same amount of money.
They showed Debian running on Apple Silicon during the WWDC keynote nearly 6 months ago.
I expect a future “M2” to maybe take the performance crown, but AMD isn’t standing still. Cezanne has Zen 3 cores, which should boost IPC by about 20%, and Rembrandt should get to 5nm and have RDNA2 graphics.
1. You're not going to get 20 hours of battery life.
2. Don't forget it's not just the M1—it's the unified memory, the 8 GPU cores and the 16-core Neural Engine. Most CPU and GPU-intensive apps are going to run faster on the M1 than on your machine. Even x86-64 apps using Rosetta 2 on an M1 Mac may run faster, since those apps are translated to native code on the M1.
3. Mac's SSD is probably faster; it's essentially a 256GB cache for the processor.
4. The Mac can run iOS/iPadOS apps too.
5. If done right, Linux compiled for the M1 will likely run faster on an M1 Mac than it does on a machine like yours, especially if Apple provides a way to access certain hardware features.
We’ll have to see what happens but expect these machines to be pretty popular with users, even those who need to run Linux when that the distros are updated.
We shouldn't forget that the underpinnings to all of this is Darwin, the BSD-derived Unix layer which is already running natively on M1, including the compiler and the rest of the toolchain.
Sorry to burst your bubble, but you're not going to get 20 hours of battery life in real world usage on the M1 either. The early tests show about 10-12h, which is the same as my (and many other) laptops under regular usage.
> 2. Don't forget it's not just the M1—it's the unified memory, the 8 GPU cores and the 16-core Neural Engine. Most CPU and GPU-intensive apps are going to run faster on the M1 than on your machine. Even x86-64 apps using Rosetta 2 on an M1 Mac may run faster, since those apps are translated to native code on the M1.
Now it feels like you're just regurgitating marketing talking points. Can you tell me what "unified memory" even is exactly? Is it zero-copy support, because AMD has had that on its APUs since... 2013 or thereabouts. Is it LPDDR4 on a pop package, because all that means to me as an end user is I can never upgrade my memory and that I'm limited 16GB of memory (which I regularly go over - I am using 19GB of RAM right now just with browser tabs open). As for performance, we already know from the early testing that the M1 under-performs 8C Zen2 for heavy MT workloads like compiles and renders, so ... what are you saying exactly, somehow running software via emulation/translation will magically make that faster?
> 3. Mac's SSD is probably faster; it's essentially a 256GB cache for the processor.
Again would you simply assume that a Mac's SSD is "probably faster"? It in fact is not. The 256GB SSD on the M1 MBA was tested at 2676MB/s reads, my value NVMe SSD, a $200 2TB ADATA SX8200PNP does 2917 MB/s on my laptop. As for SSD as cache - what are you talking about? L2/L3 latency is typically about 10ns latency. NVMe latency is typically on the order of hundreds of microseconds, roughly 10,000X slower.
> 4. The Mac can run iOS/iPadOS apps too.
Poorly, but I mean, but surely this irrelevant to Linux performance?
> 5. If done right, Linux compiled for the M1 will likely run faster on an M1 Mac than it does on a machine like yours, especially if Apple provides a way to access certain hardware features.
Which hardware features? This is rhetorical. I know this is just hand-waving.
> We’ll have to see what happens but expect these machines to be pretty popular with users, even those who need to run Linux when that the distros are updated.
We'll see what happens. You can track the state of Docker here, for example: https://news.ycombinator.com/item?id=25119396
> We shouldn't forget that the underpinnings to all of this is Darwin, the BSD-derived Unix layer which is already running natively on M1, including the compiler and the rest of the toolchain.
Darwin/macOS may be POSIX compatible, but it is not production compatible with Linux. Like lots of other devs, I've used Macs in the past (for many years) and you always run into compatibility issues small and not so small until you're either running either a completely parallel devchain via Homebrew or MacPorts, or in a VM. Honestly, WSL these days is a more Linux-friendly dev environment than macOS. But then again, it's even easier/better to run Linux and Docker these days.
Yeah, laptops that look like bricks.
> Can you tell me what "unified memory" even is exactly?
GPU shares memory with the AP
> Is it LPDDR4 on a pop package
On SoC, no PoP
> I'm limited 16GB of memory
Wait for new hardware
> which I regularly go over - I am using 19GB of RAM right now just with browser tabs open
This isn’t how memory works :/
Eh, the laptop I'm using at the moment has a 15.6" display and 91Wh battery and is less than 100g heavier and about 1mm thicker than the 13" MBP. It's also 500g lighter than the 16" MBP. Lots of other properly tuned modern x86 laptops can perform similarly. For example the 14" 1.48kg 18mm 56Wh battery HP EliteBook 845 G7 manages >12h on NBC's wifi websurfing test: https://www.notebookcheck.net/HP-EliteBook-845-G7-review-AMD...
> This isn’t how memory works :/
Fair point that free might not be the best way to measure things, I have more tabs open now but still not doing work (obviously), so let's compare:
total used free shared buff/cache available
Mem: 65328424 26679236 31393956 1165140 7255232 36284812
Swap: 67108860 3197072 63911788
With totaling per-process shared/private memory (I uses memstat.sh for this). And the total I get is: 18.37 GiB - lower, but actually not so far off.This is only with a two browsers (a few hundred tabs) and some resident electron apps open, mind you. Before upgrading (w/ 16GB memory) I was often hitting swap, and now I'm not. But if you don't ever need >16GB of RAM, lucky for you I guess.
Here's an early test that’s quite different from what you described. I’d bet dollars to doughnuts your laptop can't play fullscreen, 4k/60fps video for 20 hours using only the battery:
In fullscreen 4k/60 video playback, the M1 fares even better, clocking an easy 20 hours with fixed 50% brightness. On an earlier test, I left the auto-adjust on and it crossed the 24 hour mark easily. Yeah, a full day. That’s an iOS-like milestone.
Another one: Just 17% of the battery to output an 81GB 8k render.
These are just a couple of highlights from the article "Yeah, Apple’s M1 MacBook Pro is powerful, but it’s the battery life that will blow you away": https://techcrunch.com/2020/11/17/yeah-apples-m1-macbook-pro...
You have to look at the totality of the what's going on.
In short, the M1 Macs are right up there with the fastest machines available at reasonable prices and at a fraction of the power consumption.
The machines set a new level of performance per watt and there's no disputing that. That's pretty good for their first attempt at Apple Silicon Macs.
Although hardware specific software from Apple is probably a big part of that draw too. I don't think we're ever going to see Linux prioritize a certain hardware and put in the effort to make it integrate as well as macs does.
Perhaps I'm a bit jaded after running into too much bullshit trying to get Linux running well on laptops in the 90s and 00s. Since I made the move I never wax nostalgic for the "Good Ole Days" of fighting for hours to get Wifi working properly.
Even assuming Apple released the specs so you could port Linux to M1, on top of the usual laptop driver issues around the trackpad, wifi drivers, and video drivers, you also have to deal with the Secure Enclave. Without that, you are stuck with either a non-encrypted drive or running drive encryption on the CPU which is likely going to kill many of the performance gains from using the Mac hardware. Likewise, without the Secure Enclave, you lose fingerprint auth.
Not anti-Linux by any means, but dropping Linux on the M1 isn't going to get you the same performance or battery life by any means. You are far better just going with a laptop which was designed to be Linux friendly to start with.
I'm literally trying to figure out how to install Python 3.6 alongside 3.9 in MacOSX .... right now, and it's not a one line command.
So... No. It has massive issues with developer friendliness. New OSX stalls with bluetooth mice and randomly locks my keyboard(MBP 2020). The only thing I can commend OSX on - battery life on a MacBook and nothing else
To be fair, that's not easy on any OS (well, maybe Windows). Certainly on CentOS it is a chore to get two versions of Python installed simultaneously.
Unsupported versions - harder, but still a few commands...
Supported versions? sudo apt install python-3.6 and done.
conda create -n myenv python=3.6
Having multiple versions of system Pythons can be complicated. I've learned not to touch the system Python.Here’s a script (that no longer works apparently due to a new system signing restriction) that disabled some of those, to give an example of the amount of crap running by default: https://gist.github.com/pwnsdx/1217727ca57de2dd2a372afdd7a0f...
The way that for Windows people Unix was "other" and bad and scary. Now we have legions of programmers who were brought up on Linux, and now think of Unix as "other."
And admining them was definitely very different aside from the basic shell commands.
I can assure you that you didn't have to do that for quite some time and it's not that which people are looking for.
- Am looking for a system that lets me run any damn thing I want without pipups, blocks, firewalls, warnings, requiring signed binaries etc.
I am looking to run and develop for the same environment I end up deploying on.
- I want a system that has native docker support, systemd and makes updating the whole system or installing pretty much anything as easy as one terminal command.
- It's important for me to trust my system; where I know no single entity has more power over the machine than myself and no secret upgrades I didn't desire are going to be pushed my way.
- There's no telemetry in my ideal system, certainly not at the system level and patched out at the app level where possible.
- I want a system that is open, configurable, respects the four freedoms and is community ran.
macOS cannot give me this, no matter how "fundamentally BSD" it is. I value the freedom that free software gives that no closed-source BSD ever could.
This is the reason I initially started using macOS more than a decade ago.
However, I've been told that I'm the wrong kind of user by Apple fans whenever I criticize Apple for transforming macOS from a pretty Unix into a locked-down App Store appliance.
The BSD parts of macOS are getting old and crufty, and are being locked out and overridden by Apple's proprietary and significantly-undocumented layer. For an example of this, check out how networking is done on modern macOS versus how networking is done on a BSD or Linux.
> Perhaps I'm a bit jaded after running into too much bullshit trying to get Linux running well on laptops in the 90s and 00s
Linux has gotten much better, and the problems of the 90s and 00s have vanished for my use case.
These days, at least to me, Linux is the pretty Unix that just works that macOS used to be.
Sure, it has a 'nice/well integrated GUI', but I'm not allowed to choose a different one. Good luck configuring the one they give you for different machines without lots of pointing and clicking. (Yes I know about `defaults write`, I tried to maintain a script to configure everything that way and similar for several years, things change every version, and it's a mess even when it works. It's not how they want you to do it, and it shows.)
Comment I replied to was 'I wouldn't pay for Apple hardware if I didn't want the software' implying that would be a stupid thing to do.
I prefer its hardware to anything else; I prefer Linux to macOS. So that's exactly what I'd want to pay for.
It's not just about individual drivers though, it's about the surrounding kernel infrastructure and the whole desktop experience. For example, getting instant suspend/resume working on Linux is not (I'm fairly sure) just a matter of writing a driver for a particular bit of hardware.
There are people who have clean room implemented entire nvidia drivers. Without doc. We can manage fine with whatever incomplete doc Apple allready has.