Asahi Linux alpha release
asahilinux.org
asahilinux.org
The processor is outstanding, so is battery life and the screen and touchpad are incredibly better than any Dell or Lenovo out there.
Give us the opportunity to get rid of the increasing number of "cruft" that is Photos, Messages, iCloud, and countless demons in macOS... are we are good to go!
What? The touchpad I agree, but screen? For the Macbook Air (not pro)? That is still good, but definitely not better than the UHD+ screens you for instance get from Dell. And that is not even considering oled options.
Dell frequently does discounts, but the base price for their UHD panel in the XPS13 is twice the price of a MacBook Air. I had both, and still prefer the Mac hardware by a considerable margin.
[1]: https://github.com/tpwrules/nixos-m1/blob/main/docs/uefi-sta...
The Mac Studio bring-up might be worth waiting for on this use case though, apart from more cores it crucially has more RAM options. While the SSD is comparatively fast to swap from what most are used to dealing with the 16 GB of RAM limit on the Mini can still be between a real downer to a non-starter for many server workloads.
I’m considering just getting a Mac Mini and using that as a home server with everything in it.
Let's be honest, Raspberry Pi is garbage. It's just insanely weak, I regret spending around €100 for mine (Raspberry Pi 4, with case). It's got 32-bit ARM chip, and USB 3 ports that you can't use (I plugged in 2 external HDDs into it, was running a SMB share for Time Machine and Media, they just kept dropping. Apparently something power delivery related, works with USB 2.0 speeds though.)
I am wondering why Apple doesn't support this more directly. That would be just a tiny drop out of the marketing budget. But at least there seems to be some good will in the relevant OS department with recent changes from which Asahi Linux benefited.
On a side note, as long as the graphics are CPU rendered, is this rendering multi-threaded and would benefit from the beefier M chips?
All that said, I would be delighted if Apple supported an M1 version of VirtualBox.
They almost do, Apple ships Hypervisor.framework with macOS. You still need an app to interface with it, but Apple’s framework does most of the work.
You might be interested in https://github.com/machyve/xhyve
Asahi Linux, of course, isn’t that. Asahi Linux runs on bare metal.
If everything works reliably well, this could be a game changer for Linux.
One big issue with Linux is driver maintenance. If a distro can focus on just one set of hardware (e.g. M1 Macs), it allows the developers to optimize the distro massively. It also makes everything more predictable, and saves a lot of time.
Not to mention that the M1 macbooks have outstanding displays, speakers, mics, etc. Imagine a world where the distro has perfect drivers out of the box, and we don't need to use some subpar nouveau driver (when I say subpar, I'm speaking relative to the official drivers).
Not to mention that most people run Linux on crappy $1000 laptops. An M1 air is around that price range, and destroys anything in that particular market space.
This could be massive for Linux desktops. I feel like the one thing that has been holding it back has been this very issue. It even opens up the door to reverse engineering the Apple hardware and perhaps creating a complete open source integrated system in the future.
It matters, and it could be the thing that rocket blasts Linux into more normies homes.
Allow me to explain how you're wrong. How often have you heard a normie Average Joe that's tech illiterate and just buys Macs or Walmart PCs and doesn't even know that their machine runs MacOS or Windows or that their iPhone runs iOS or that their Samsung phone runs Android (basically your average boomer dad), say "Gee wizz, I would totally wish I could run Linux on some decent HW, if only Linux driver support for Macs were better". lol
You're delusional if you think Linux market share on laptops/desktops will explode when the driver situation improves. 99,99% of people who will buy Macs will keep using MacOS. Most people buy into the Apple ecosystem for the ecosystem, and apart from some geeks/tech workers, they're not gonna start installing Linux on them.
My point is, you're massively overestimating how many Mac users (outside of geek tech bubbles) would actually daily drive Linux on them.
And even in the geek/tech bubbles, most will probably play with Linux on their M1 Macs for a day, and once they see that the trackpad movement is worse than MacOS and there's some screen taring due to some driver/wayland issue, they'll reboot and revert back to daily driving MacOS. Rinse and repeat in an year when it will finally be "year of the Linux".
The "year of Linux" on the desktop/laptop hasn't yet happened not because people couldn't run Linux on their Macs but because of countless of other factors, the biggest of which being that the average consumer doesn't know, want or care to install another OS than the one that came with their machine out of the factory.
Is it a significant share of the MacOS market making this switch, or is it basically just a rounding error in the grand scheme of things?
And to correct you, Linux GOT installed on Macs when they had standard PC HW so Linux kernels had native support for them, but in the current state of Linux on the M1, there's so many things not working[1] due to Apple not using PC HW anymore, that I doubt Linux will be suitable for daily driving on M1/ARM Macs anywhere near it was on X86 Macs anytime soon. And I doubt Mac users will put up with Linux on their M1 machines if a lot of peripherals that worked on MacOS, don't work well on Linux.
[1]What doesn’t work
DisplayPort
Thunderbolt
HDMI on the MacBooks
Bluetooth
GPU acceleration
Video codec acceleration
Neural Engine
CPU deep idle
Sleep mode
Camera
Touch Bar
I mean ok some people will do that but at that point the machine starts to either obsolete or there is something wrong with it already. Why not just run a macOS that is couple of versions older, than install some Linux that probably can't even sleep properly..
Don't get me wrong, it will be nice to have another manufacturer to choose from with excellent Linux support, but as it sounds, they aren't there yet with this new distro. So... I'll keep using ThinkPads for now.
Also I despise glossy screens. So I'll probably never want a macbook anyway.
If you are moving from a PC laptop to a Mac you will more likely switch to MacOS than to Linux, and if you were already on Linux before, it doesn't matter for its success that you changed machine.
Linux on an M1 Mac - https://news.ycombinator.com/item?id=30717758 - March 2022 (136 comments)
AsahiLinux's Introduction to Apple Silicon - https://news.ycombinator.com/item?id=30699794 - March 2022 (5 comments)
Asahi Linux Add Support for the Broadcom FullMAC WiFi Chips Used on Apple T2/M1 - https://news.ycombinator.com/item?id=29694497 - Dec 2021 (9 comments)
Apple Helps Asahi Linux - https://news.ycombinator.com/item?id=29591578 - Dec 2021 (174 comments)
Asahi Linux for M1 Macs Progress October-November 2021 - https://news.ycombinator.com/item?id=29564384 - Dec 2021 (211 comments)
Asahi Linux for M1 Macs: progress report for September 2021 - https://news.ycombinator.com/item?id=28762744 - Oct 2021 (186 comments)
Asahi Linux for Apple M1 progress report, August 2021 - https://news.ycombinator.com/item?id=28180135 - Aug 2021 (183 comments)
Asahi Linux Progress Report: January/February 2021 - https://news.ycombinator.com/item?id=26421963 - March 2021 (65 comments)
Asahi Linux: Linux on Apple Silicon project - https://news.ycombinator.com/item?id=25649719 - Jan 2021 (405 comments)
Super slick. No issues.
You can find some other options in https://github.com/torvalds/linux/blob/c5d9ae265b105d9a67575... as well
I haven’t been at apple for over a year but there was a strong population using apples own arch Linux distro. It’s not like people there don’t use Linux.
It’s kind of like Correlium’s M1 port over a year ago. It got Linux on the M1 within weeks of launch but the code was unusably atrocious.
Edit: Adding to that, Linux does not have a stable driver interface, and regularly changes between releases. That means that messy sloppy code that is unupstreamable will quickly be unable to move forward to future Linux versions without increasingly herculean efforts. You'll be trapped on an old kernel indefinitely if you follow that path - just like the Android situation.
Edit 2: And I'm not exaggerating that Correlium's code was sloppy. Almost none of it ended up in the Asahi Linux project. Also Corellium basically dumped that code for fun and then quickly gave up trying to keep it up to date.
That's unfortunate, but it seems to be a bit of a common theme in open-source to say "you have the source, we don't care if we broke your code, fix it yourself". I suppose that might've been an attempt to discourage closed-source drivers, but...
You'll be trapped on an old kernel indefinitely if you follow that path - just like the Android situation.
...that didn't have the desired effect either.
It’s only a burden if your own fork, or want closed source bits. Neither of these are important goals for upstream.
see here:
[1]: https://github.com/AsahiLinux/m1n1/commit/0d4fb00ceb8a14f083...
The raw image mode was added for us. Apple has absolutely zero use for such an option.
Obviously what I say isn't proof though
Darwin already works on arm, as the iOS is darwin
Because all large scale, big name, commercial HW, CAD and EDA tools are either Windows and/or Linux exclusive.
EDA vendors don't even bother with the tiny (non existent?) market share of MacOS in this space when their entire customer base has been exclusively *nix and Windows for several decades now.
Wowsa. I know disk space is abundant but that is still shocking. I've never used MacOS, but why does it need at least 38 GB free for MacOS update?
> You need 15GB for Asahi Linux Desktop
Wowsa number 2. I'm used light installs using lightweight windows managers or desktops so that number was a bit shocking. Anyone else prefer a small base onto which you can add software rather than getting everything and having to uninstall a bunch of software?
As for the 15GB, 2.5GB must be used for the mandatory Recovery partition as well as leaving room for the recovery partition to have extra room if necessary, because it can’t be easily expanded later.
That leaves 12.5GB for your desktop Linux and any free space for your apps or files. You can use Expert Mode to go smaller with either macOS or Asahi but I’d say they are reasonable guidelines.
Very surprised by this, but to be fair this is an alpha. So I expect them to drive that down drastically when it is stable anyway.
It may not be the friendliest of installers, but hey that Linux. Or perhaps someone can do a user-friendly AsahiInstaller.app as well?
You still can if you really, really want to, it has just become excessively annoying. (I don’t blame you at all for switching OS’s)
macOS is unlikely to run inside a VM on Linux any time soon, because the desktop environment requires a paravirtualized Metal graphics device, which means writing an entire Metal implementation for Linux. You can run the XNU kernel in text mode though, even on non-M1 systems.
https://asahilinux.org/2021/03/progress-report-january-febru...
Userspace breaks on 16K pages when it tries to do things like call mmap() with virtual addresses that aren't aligned to 16K. Usually it's allocators doing this when they think the entire world is 4K.
Don't 16K pages "exist alongside" 4k pages too, just not within the same virtual address space or (in Linux) VMA? How else are Rosetta apps supposed to work in Mac OS?
Rosetta runs the userspace half in 4K mode, and XNU had to be reworked a lot to support this. Linux could of course be reworked to do something similar on paper, but it's a hugely intrusive change and it'd actually be easier to just make the kernel support 4K/16K pages in a single build first.
Hugepages aren't like that, they actually coexist with normal pages. In general, hugepages are just a pile of contiguous/aligned small pages that the kernel manages as a unit, and it flags them to tell the MMU "I promise these are all one big contiguous chunk so you can optimize it to one larger TLB entry". Depending on the page table structure they might be coalesced to a higher-level page table entry, skipping a page table walk level.
This looks like the real issue, so adding support for both "4k" and "16K" address spaces would involve support for multiple page table structures within a single kernel? Still seems very much worth doing since it can likely be extended to support e.g. 64K. And maybe other architectures could reuse that support depending on how their hardware support for multiple page sizes works, e.g. https://en.wikipedia.org/wiki/Page_(computer_memory)#Multipl...
Lots of things in the kernel count sizes in pages. If your page size can vary, suddenly a lot of kernel constants become boot-time variables. And if it can vary from process to process, suddenly lots of things are per-process. Say you run a 4K process. It wants to map some data from a file. That data is in the page cache in 16K chunks. Now you have one page cache page mapped to anywhere from 1 to 4 4K pages. How do you keep track of that? That wasn't necessary before.
What happens if a 16K process shares memory with a 4K process? If the 4K process sends the 16K process a 4K page, that page can't be mapped at all.
See how this is makes everything much more complicated?
Has this stuff been discussed elsewhere so far, e.g. on some linux kernel dev list? I think you've made a good case for not trying to support per-process page size right away, but many of these issues are not entirely new; they came up in some form as part of the transparent-huge-pages feature. It turns out that some hardware support already requires the kernel to understand "higher-order" mappings of contiguous physical pages, and "transparent huge pages" could leverage that support.
In an earlier post they said this about progress on the iommu hw limitation leading to start out with 16k page size: "Sven took on the challenge and now has a patch series that makes Linux’s IOMMU support layer play nicely with hardware that has an IOMMU page size larger than the kernel page size" (https://asahilinux.org/2021/10/progress-report-september-202...)
(Also apps can always opt-in to bigger pages using the existing mechanisms)
Of course it's also true that 4k is a ridiculously small page size, we've been using the same size for 30-40 years while memory sizes have grown 5-6 decimal orders of magnitude. But from that POV we should now do a bigger bump than 4k->16k - I think the next bigger commonly used page size on ARM Linux has been 64k.
https://en.wikipedia.org/wiki/Tadpole_Computer
It was the sparc flavor... but they had an Alpha too.
> According to Allen Baum, the StrongARM traces its history to attempts to make a low-power version of the DEC Alpha, which DEC's engineers quickly concluded was not possible. They then became interested in designs dedicated to low-power applications which led them to the ARM family. One of the only major users of the ARM for performance-related products at that time was Apple, whose Newton device was based on the ARM platform. DEC approached Apple wondering if they might be interested in a high-performance ARM, to which the Apple engineers replied "Phhht, yeah. You can't do it, but, yeah, if you could we'd use it." -https://en.wikipedia.org/wiki/StrongARM
And while the IP didn't directly influence Apple Silicon, the experience did:
> P. A. Semi (originally Palo Alto Semiconductor[1]) was an American fabless semiconductor company founded in Santa Clara, California in 2003 by Daniel W. Dobberpuhl,[2][3] who was previously the lead designer for the DEC Alpha 21064 and StrongARM processors. The company employed a 150-person engineering team which included people who had previously worked on processors like Itanium, Opteron and UltraSPARC. Apple Inc acquired P.A. Semi for $278 million in April 2008. - https://en.wikipedia.org/wiki/P.A._Semi
And then there is the DEC PDP, which enabled some of the former Multics developers (Ken Thompson & co) to take what they had learned building Multics and apply it to the affordable PDP hardware to build Unix, which then inspired Linux.
DEC may no longer exist, but their shadow reaches a long way into the future.
[1] https://arstechnica.com/uncategorized/2005/10/5486-2/ (product annoncement before getting Apple-acquired)
“Ready to give it a shot? Make sure to update your macOS to version 12.3 or later, then just pull up a Terminal in macOS and paste in this command:”
Other than that, fantastic work and I look forward to eventually having an M1 to run Asahi on
Edit: I just wish the wording would encourage you to verify the file. I don’t think there’s something inherently wrong with using shell scripts from the internet. But massive companies let domains expire, why won’t marcan?
I guess it’s not, but it feels like it is.
This is incorrect. For hardened installations, it is an absolute must.
That being said, I don't see that as being reasonable to expect for this alpha distro.
At the very least, instead of the one liner give me a two liner: one to download to a file, then a second line to execute it.
Prepare to be impressed, the bootloader this installs to be able to boot Linux was first made for the capability of transparently running macOS under its hypervisor intercepting every hardware call transparently and streaming it to remote PCs to enable reverse engineering.
If you're intentionally verifying what's on the site via a completely separate independent method (which is what you need to do to actually verify what's on the site is what should) then it doesn't really matter what the instructions on the site say in the first place as you just decided you're not relying on them for the verification.
What is still needed but not implemented yet is hashes inside the served script for content it pulls from the 3rd party CDN. That said there is a reason it's alpha.
For anyone who would be running curl, you can easily not pipe to shell and inspect the script yourself.
As with any software release: you have the list of things planned for the next release, even if they are not available yet and you have a list of things which definitely won't be in the next release.
So they "work" already, just not in the kernel packages I'm building :-)
There's _a lot_ of work still. It's not clear that Bluetooth should be the highest priority of what's left. And this whole undertaking is a monumental task which it's amazing that volunteers are even attempting. Saying "I want bluetooth, please focus on that guys" here seems a bit tone-deaf.
Yes, and every other mainstream OS is: "No, this is not supported.". I don't see how Linux is seen as worse then that answer. If anything this post proves how rapidly the Linux community moves. Within a year there is working Linux on FULLY proprietary hardware. And not just a funny PoC. No, you can daily drive this thing. Let's see how long it takes for Windows to run on the M1...
Meanwhile my Sennhesier headphones work sometimes with my POS mac to the point where I have to tell people If i don't immediately pick up it's because I'm wasting 15 minutes trying to get my headphones to pair with my Mac.
EDIT: To everyone downvoting this: nobody cares, nobody is listening to you.
I love honestly love a lot of Chromebook hardware. It's honestly exactly what I want in a laptop - long battery life, efficient, lightweight, decent enough keyboard.
But it's impossible to get without giving Google money, and without dealing with a massive warning every time you boot - if you're model even lets you install something other than Chrome OS.
I should really grab a Pinebook Pro I guess.
And that's without getting into all the privacy issues of students being forced to use Google software/hardware, or the schools spying on students through the Chromebooks.
Somehow I got downvoted for it.
That's not even the most painful part. Full data wipe when switching between security modes is outright user-hostile, and would be widely considered as unacceptable if Microsoft or Apple did that on their general-purpose computing platforms.
I don't think it's user hostile to prevent all security models from being dragged to the lowest common denominator. If they didn't do that, an attacker could just switch to a more insecure mode and go after your data.
It's rather the reverse. How macOS handles it is by asking for user credentials on a security policy downgrade, and enforcing that by the Secure Enclave.
(and if you have user creds, you _have access to user data anyway_)
On other platforms, that tying... just doesn't exist.
You can get rid of the warning by physically removing a write-protect screw and replacing the firmware. It's still a very user-hostile feature because it's not just a 'warning' either, but actively prompts you to wipe your existing installation. That sort of thing is very much what you'd expect in a toy, not a machine for serious use.
Wiping the installation is very much expected. The security model includes protecting data, of course data has to be wiped when removing security. Data on disk is encrypted with a key stored in the security chip, which destroys the key when security settings are changed.
Android does the same for fastboot unlock.
What's the big deal? If you want to flash UEFI and use a custom OS, why would you want to preserve the ChromeOS partition?
Yes, however now is a bad time. They are out of stock and struggling to source parts last I checked. I think screens are the main issue.
Check out this FAQ that's scoped around a custom Arch Linux ARM but gives you an idea of the pain: https://github.com/SvenKiljan/archlinuxarm-pbp/blob/main/FAQ...
For thoughts on why Pine64 seems to be stuck in this state of never fully working hardware I can recommend Drew DeVault's blogpost: https://drewdevault.com/2022/01/18/Pine64s-weird-priorities....
The postmarketOS folks have significant experience with mainlining kernel support for hardware that's only supported in downstream/vendor kernels. Please reach out to them and make sure they know about the issues; this work should be plenty relevant to them because Pine64 is also doing mobile HW.
"Against will" probably only applies to the families with people technical enough to understand what having an enterprise managed Chromebook that their child has to be on for 8 hours a day means.
It was a very low grade HP chromebook that was shamed by the performance of a raspberry pi 3b. I have been thinking of gutting it and installing a pi inside to make a pibook.
Your comment indicates that you are expecting the community to serve your feature requests, while not even pointing out to the "beneath you" opportunity to contribute yourself. If not willing to put the effort into desktop configuration or "rolling your own" features, why are you bothering with Linux? You can be better served by Windows or MacOS. But you might find your feature requests to fall on deaf ears there.
In my experience, a Linux desktop is unparalleled in flexibility, productivity and stability, if given some time/effort to configure and adapt to your workflows - it's been years and years "of Linux desktop" already for people who care.
Sadly there haven't been many AAA games with Linux compatibility (that I wanted to play) since then. Valve is still pushing it though.
So yeah, I have no idea how Proton works.
>There is a category of software that will likely never support 16K page sizes: certain emulators and compatibility layers, including FEX.
Well, too bad...
On the desktop side: I always assumed x11/xorg derived GUIs were purely software rendered? Has Wayland finally landed? Sorry I'm lagging behind >10 years of Linux on desktop.
The whole thing with Wayland is just a new generation of coders saying "hey all this pile of new apis on top of old apis on top of older apis spanning back 40 years designed for hardware that no longer exists is insane. We need to start over." They aren't wrong, but they also haven't reached feature parity with the old stuff yet, because doing hardware accelerated 3D graphics over a pipe to a remote host was a pretty amazing feat of technology.
Edit: to be a little more specific, Silicon Graphics company's whole business was accelerated graphics, and they were in business since 1982, and invented most of X11, or at least its extensions.
In regards to Wayland landing or not it has become the default for Ubuntu, Debian, SUSE, RHEL, and many others but a lot of apps still rely on the XWayland compatibility layer to run. The Asahi Desktop install option currently defaults to an X11 Plasma session, I assume for simplicity at this stage, but Wayland works fine as well. Even if you try a desktop environment that requires accelerated rendering and has no native software fallback it'll work via a software rasterizer like LLVMpipe until real GPU acceleration arrives.