Linux running natively on M1?

[bradl]

I'm not the target audience, but I understand why some want it. For most Linux enthusiasts, any proprietary UNIX is a non-starter - they want full source code for everything.

To a degree.. I had the unfortunate privilege of breaking a 2568-day uptime of a Sun Fire X2200 1U server that was running Solaris x86 2.8 because our client changed their requirements that they could go to using RHEL for their webserver. While it could easily have run Linux (it was AMD Athlon X4), having it run Solaris meant that a lot didn't have to be compiled or source code needed, which meant that less time was spent trying to build the software that was to be maintained. It effectively ran itself, so I only had to patch the zone that was running inside it (like a VM), so the main core OS never had to be shut down.

The same could have been achieved with OpenSolaris, but Linux has the better support.

Even for those with a less dogmatic point of view, there's a bunch of things about Apple's UNIX which would be annoying or showstoppers for long-term Linux users. Apple's take on a lot of things is just weird to anyone who grew up on Linux. Apple ships creaky, ancient versions of many open source UNIX programs because their legal department decreed that Apple employees Shall Not Touch anything with the GPLv3 license. Lots of the apps Linux enthusiasts want to run can be (and have been) ported, using layers like XQuartz, but they'll always be weird and poorly integrated with the native Cocoa UI. Which isn't nearly as customizable as they window managers they're used to.

XQuartz comes in handy for me, just mainly for running an xterm. From there, and thanks to XCode, GCC (llvm, CLANG, etc.) can be installed to where I can compile anything I may need, which isn't much. If I wanted to, I could compile GnuPG and Mutt and have a way to send/receive mail and encrypt/sign any file I choose with my PGP key. But with having Apple Mail, Postbox, and a native GnuPG client for the Mac, I really don't need to. But the option is there if I want, as it does provide an ANSI C environment.

Once you accept that people exist who really won't run any desktop OS other than Linux, it's easy to see why there's demand for M1 Linux. What can you buy in x86 land which matches up with the M1 MacBook Air?

That is a fair point. The interesting thing to think about is what support Linux will have for the hardware, especially since it is a completely different architecture compared to what Linux can support (x86, sparc, ia64, alpha, s390, etc.).

BL.

 

[Krevnik]

The interesting thing to think about is what support Linux will have for the hardware, especially since it is a completely different architecture compared to what Linux can support (x86, sparc, ia64, alpha, s390, etc.).

BL.

ARM is supported by Linux, and more distros are including ARM boot images. SBCs and ARM servers have been driving it, but it’s not that new.

 

[quarkysg]

ARM is supported by Linux, and more distros are including ARM boot images. SBCs and ARM servers have been driving it, but it’s not that new.

Main issues will be the drivers for the various blocks in the M1 SoC, e.g. GPU, SSD, PMU, NPU, ISP, media encoder/decoder, etc.

 

[leman]

To run apps that are not available on Mac like Kile and Ghostwriter (insert your own favourite app here...). Other complex systems like TeXLive run faster under Linux than on Mac.

I am curious about the last bit. Do you have a source? I don’t see a reason why the LaTeX suite should perform slower under macOS…

 

[bradl]

Main issues will be the drivers for the various blocks in the M1 SoC, e.g. GPU, SSD, PMU, NPU, ISP, media encoder/decoder, etc.

Exactly, and because of that, those developing drivers for Silicon are basically doing what those who developed drivers for nVidia cards had to do: reverse engineer the hardware to create the software, as nVidia's Linux driver was binary only, unsigned, and crashed frequently, making nVidia all but useless as a video driver. If Apple isn't willing to open up the hardware or post specs for it, they'll be stuck reverse engineering it, which will take longer to completely support.

BL.

 

[mr_roboto]

Exactly, and because of that, those developing drivers for Silicon are basically doing what those who developed drivers for nVidia cards had to do: reverse engineer the hardware to create the software, as nVidia's Linux driver was binary only, unsigned, and crashed frequently, making nVidia all but useless as a video driver. If Apple isn't willing to open up the hardware or post specs for it, they'll be stuck reverse engineering it, which will take longer to completely support.

Apple will never document any of it.

However, due to the interesting system design of Apple Silicon, in many cases what they're reverse engineering is message passing APIs. For many peripherals, all the low level hardware interaction is done by firmware running on its own private ASC coprocessor; the macOS driver sends it messages to request work, and the interface is a much higher level of abstraction than the low level hardware registers.

Apparently it's possible to drive these peripherals directly from an application processor (Firestorm or Icestorm) with a conventional driver, but Apple seems to really like offload in M1.

ASC firmware blobs are distributed by Apple with macOS, and loaded by Apple's bootloader chain before starting the Linux bootloader, so Asahi Linux won't have to distribute them, just use a script to download the version they need from Apple's servers during installation.

Taking advantage of the ASCs will cause heartburn among some open source purists, but it's not like there haven't been a million other peripherals with an embedded microcontroller which needs a firmware blob. Many of them are even conceptually very similar to the way Apple uses ASCs - for example, the LSI/Avago/Broadcom RAID controller chips have an embedded PowerPC which actually runs the show, and the Linux driver only sends and receives messages which ask that core to do things.

 

[DaveFromCampbelltown]

I am curious about the last bit. Do you have a source? I don’t see a reason why the LaTeX suite should perform slower under macOS…

The source is me and my iMac.

I test systems by compiling a long (150 page) LaTeX document, specifically lshort.tex.
I install TeXLive on Mac, Ubuntu Linux and Windows (10 and 11).
Compiling the document takes --

Operating System	Time (sec)
macOS	8
Ubuntu Mate	7
Windows 11	22
WSL (Ubuntu) on Win 11	7

This is all using the same hardware - iMac, OS installed on SSD, 8Gb RAM.

 

[Krevnik]

Main issues will be the drivers for the various blocks in the M1 SoC, e.g. GPU, SSD, PMU, NPU, ISP, media encoder/decoder, etc.

Of course. But that’s also exactly what these engineers are doing surprisingly successfully. You also don’t need the ISP, hardware codecs or NPU to be successful at bringing Linux to the bare metal. Especially without interest from common libraries to integrate support. However, the post I quoted was giving CPU architectures as examples.

 

[JMacHack]

In the 90s, people criticized Microsoft for stifling competition. MS could make a case for the benefits of having the same OS used on 90+% of the word's computers - and there's some truth in that. Upon reflection, Linux success in say, the server space, sure seems to have ushered in loads of innovation at a MUCH faster pace than MS ever could have.

Today, people criticize Apple for stifling competition (sherlocking, un-upgradeable devices, planned obsolescence, etc). Apple can make a case for security! and safety, and there's truth in that. In a few years, we'll look back and realize "Apple had our backs the whole time!" - or maybe - "These Linux devices are great! This kind of innovation would never have come about from a company like Apple".

Yes, Apple makes products that helps make lives better, but would more doors and a better future be opened another way?

The only issue with Linux is the fragmentation. Every Linux user has an opinion on which distro is best and how it should be structured. This often means some innovations go unused or ignored due to ego.

The unfortunate reality is that sometimes leadership is required to make a great product.

 

[wyrdness]

The source is me and my iMac.

I test systems by compiling a long (150 page) LaTeX document, specifically lshort.tex.
I install TeXLive on Mac, Ubuntu Linux and Windows (10 and 11).
Compiling the document takes --

Operating System	Time (sec)
macOS	8
Ubuntu Mate	7
Windows 11	22
WSL (Ubuntu) on Win 11	7

This is all using the same hardware - iMac, OS installed on SSD, 8Gb RAM.

So you're argument in favour of running apps natively on Linux, rather than OS X, is that some run faster on Linux. You gave TexLive as an example. When challenged, you've provided data to show that a task that takes 8 seconds on Mac, takes 7 seconds on Linux.
This is not the compelling argument for running native Linux on Mac that you seem to think it is.

 

[leman]

The source is me and my iMac.

I test systems by compiling a long (150 page) LaTeX document, specifically lshort.tex.
I install TeXLive on Mac, Ubuntu Linux and Windows (10 and 11).
Compiling the document takes --

Operating System	Time (sec)
macOS	8
Ubuntu Mate	7
Windows 11	22
WSL (Ubuntu) on Win 11	7

This is all using the same hardware - iMac, OS installed on SSD, 8Gb RAM.

Thanks! Looking at your results, there is a clear reason to abound Windows for LaTeX, Mac and Linux results are almost identical. Doesn’t seem to me to be worth the hassle to be honest?

Which driver (PDFlatex, Xelatex, LuaLatex) and which Linux filesystem were you using?

 

[DaveFromCampbelltown]

So you're argument in favour of running apps natively on Linux, rather than OS X, is that some run faster on Linux. You gave TexLive as an example. When challenged, you've provided data to show that a task that takes 8 seconds on Mac, takes 7 seconds on Linux.
This is not the compelling argument for running native Linux on Mac that you seem to think it is.

Not only faster, but some apps which are not available on Mac at all, such as Kile (the best LaTeX editor evah!) and Ghostwriter markdown editor.
Bootup is also faster in Ubuntu Linux (16 seconds compared to 30 seconds with macOS).

Perhaps the best reason for running any version of Linux on a Mac is that MS Word is not available...

 

[MBAir2010]

If  is so nice and open on what Operating systems we can run and lets us boot multiple macOS
and downgrade to last Californian Theme of the year,
why are we dependent on a DOSdude to run our great MacBooks made in the 2010's in 2020?

 

[leman]

Not only faster, but some apps which are not available on Mac at all, such as Kile (the best LaTeX editor evah!) and Ghostwriter markdown editor.
Bootup is also faster in Ubuntu Linux (16 seconds compared to 30 seconds with macOS).

Perhaps the best reason for running any version of Linux on a Mac is that MS Word is not available...

In the end, all of us have their own preferences, but your list hardly strikes me as objective. One could retort that Linux lacks Bibdesk and TextMate, which I personally consider the best LaTeX editing environment (but than again this would be silly since both Linux and Mac oder access many outstanding LaTeX editors). Booting times are inconsequential in this day and age since wake from sleep is instantaneous anyway and modern Macs have standby battery endurance traditional computers can only dream of. And of course, with all my dislike to office systems of any kind, MS office can unfortunately be inescapable in some work environments (I for example have to use excel to fill out student grades because that’s what my Uni requires).

Besides, the software you mentioned seems to be available for Mac just fine, even though it’s not optimal. And there are very good alternatives. For example, typhora.

 

[nigelbb]

To run apps that are not available on Mac like Kile and Ghostwriter (insert your own favourite app here...). Other complex systems like TeXLive run faster under Linux than on Mac.

Both Kile & Ghostwriter are available for MacOS as is every other OpenSource Linux application.

 

[DaveFromCampbelltown]

Both Kile & Ghostwriter are available for MacOS as is every other OpenSource Linux application.

I politely beg to disagree. Do you have links to installable versions of these apps? I would love to have them.

 

[Gnattu]

I politely beg to disagree. Do you have links to installable versions of these apps? I would love to have them.

They do but with few quirks. You have to compile them from source.

 

[nigelbb]

I politely beg to disagree. Do you have links to installable versions of these apps? I would love to have them.

Why move the goalposts & insist on "installable versions"? They are OpenSource you just need to compile from source just like every other OpenSource application.

 

[leman]

Why move the goalposts & insist on "installable versions"? They are OpenSource you just need to compile from source just like every other OpenSource application.

I just had a quick look and it seems like Kile is abandoned since 2019 and relies on KDE libraries (which would make it a mess to build on macOS). Ghostwriter is a Qt app and should be buildable on macOS, but the experience won't be native. So at this moment I would agree with @DaveFromCampbelltown that these applications are not really available on macOS. Of course, the likely reason for it is lack of community reasons because of excellent alternatives that exist on macOS. At any rate, it's a weak argument for in favour of using Linux anyway.

 

[januarydrive7]

Is compiling LaTeX docs to PDF really the benchmark that is swaying macOS users to move to Linux? How often are you generating PDFs and how large are these projects?

I frequently collaborate on LaTeX projects, oftentimes with some who prefer working in MS word for user-friendliness. For this reason, I've moved away from dedicated installable apps and now only use Overleaf, which IMHO offers the most user-friendly collaborative (La)TeX experience, and compile times aren't terrible. For comparison, I just compiled lshort.tex (english) on overleaf in ~13 seconds. Full disclose, I rarely work on projects longer than 30 pages (usually CS conference papers following ACM/IEEE standards), and I rarely see compile-times that take longer than a few seconds, unless I have some nasty errors or package conflicts.

 

[leman]

Is compiling LaTeX docs to PDF really the benchmark that is swaying macOS users to move to Linux? How often are you generating PDFs and how large are these projects?

Nobody is moving to Linux to get an alleged 1% improvement in their compilation speed. The very notion is silly.

 

[januarydrive7]

(I for example have to use excel to fill out student grades because that’s what my Uni requires).

Requires grades to be input via excel? I've taught as an associate in. at my uni a few times (summer positions while working towards my PhD), and I've often complained about some of the inefficient or downright ludicrous processes teachers need to adhere to, but excel as the required means for entering grades? That takes the cake.

 

[JMacHack]

Nobody is moving to Linux to get an alleged 1% improvement in their compilation speed. The very notion is silly.

I could imagine it being considerable if the “1%” of time saved amounted to hours.

 

[Xiao_Xi]

marcan has just published the latest progress report and has found some interesting differences between M1 and M1 Pro/Max.

Progress Report: October-November 2021 - Asahi Linux

asahilinux.org

 

[Xiao_Xi]

It seems Apple is secretly helping the Asahi project.

https://twitter.com/x/status/1471799568807636994