Will FEX ever leverage the hardware that Apple design for Rosetta 2 trickery? It seems like a heavy lift for a general purpose emulator, but at the same time there's probably a bunch of performance wins to be had.
From when I last checked, it still requires a custom 4K kernel as Asahi only ships with a 16K kernel, and FEX won’t work with those.
So you need to compile a custom kernel for FEX to run and Steam to work.
Still, great work from Lina and the Asahi team, very excited about getting full FEX support on stock kernels (I have a backlog of Humble Bundle games to try with this).
<script>document.referrer.startsWith("https://news.ycombinator.com")&&(console.log("Hacker News is becoming worse than 4chan. Do better."),document.location="https://google.com")</script>
Anyone have an option for Chrome they trust? Not only for this, but to fix the stupid Twitter behavior of hiding complete threads and showing "related tweets" if you are linked.
It’s a shame because most of the top 10 top level comments ended up being just pure praise and admiration, and all the negative ones were downvoted or debunked. I think the main disagreement was the people speculating on the identity of Lina.
This is hilarious, you're actually speculating about "the real reason" after getting linked to the literal statement of why it was done with example comments given, most of which are doing exactly what you're doing here: irrelevant speculation and going of on tangents
If there is a basic archetype of a HN comment, yours is a perfect example of it
I follow Hector on Mastodon and he's posted a few times in the past about how he dislikes the HN comments and often finds them toxic. He didn't implement any anti-HN measures in his sites before though, so there was clearly something different this time. What I think elevated this from "ignore" to "block" were a few creepy subthreads relating to him and the identity of Lina that I am not going to repeat. Additionally I thought this was a shame because those nasty ones ended up being flagged and downvoted by the community, and drowned out by a boatload of comments saying how much people admired the work Hector, Lina, Alyssa and the Asahi crew are doing. So he's under the impression that most HNers are dumb idiots who dislike him and and are comofortable doxxing people, which I don't think is the case.
However if you're looking for the basic archetype of a bad HN comment I think yours is actually much more appropriate. Very poor form :-/
Hector had no problem spreading salacious rumours about Richard Stallman a couple of years back.
He loudly supported a hateful and slanderous campaign that resulted in RMS having to step down from the FSF.
Now he comes along and for whatever reason he's decided to adopt this weird hentai alter ego, which is very obviously him... but for some reason we're not allowed to mention it - because? ...actually I have no idea why.
But he certainly doesn't mind dealing in rumours when it's against people he decides deserve it.
I actually kind of know marcan, but sorry, this is just too much of a low hanging fruit to let it just pass by.
*Ahem*
Complaining about people not reading the article and then denying those people the ability to read the article is 300% concentrated irony. Holy shit.
(I'm assuming the motivations behind the redirect are what marcan is complaining about. marcan's complaint by itself is valid, of course. People only reading headlines is nothing new.)
I don't get the reason behind his complaints about not 100% of all the comments being focused on the one topic. It's a discussion forum for humans, not a bureaucratic committee. Comment folding exists for a reason.
And while it sure can be frustrating when completely avoidable questions are asked, I don't get why that's so bad that one has to block the website. Especially considering 95% of comments to marcan's post linked above could be summarized as "haha orange site bad" - a lack of substance doesn't seem to be the issue.
I'm sure this frustration has a cause, but I struggle to see what that is.
I have talked to creators before about their projects ending up here. When you are doing a project or have an interest in something you haven't thought of everything. But you have probably thought of most things that spontaneously comes to mind. It isn't even just shitting on things that is the problem. Effectively shitting on something takes some interest, making claims or potentially having a point. It is the random bullshit that gets to you. The ignorance and the arrogance and even more so in combination because there is little you can do about it. It is many times as burdensome to read inaccurate things when you know better and even more so trying to correct them. So it quickly becomes Wargames. If you don't engage the bullshit spreads, if you do engage you waste all your time and it probably don't get much better anyway. So the only way to win is not to play at all.
I went back and read some of the discussion in the other thread. I didn't read everything because of time. What strikes me isn't the bad faith or poor form trying to expose someone or arguing a tangent on an interesting subject. It is how embarrassing it is. And how embarrassing it that they don't know how embarrassing it is. If I managed to even slightly get my point across you will understand why I can't explain why it is embarrassing. What I can say is that it isn't about just about being wrong or being rude. It about not knowing what they are talking about while being convinced that they have a point.
And no I don't think it is ironic. If you consider Hacker News a net negative blocking your blog from being published here is consistent with that view. More would if "all publicity is good publicity" wasn't such a strong idea in money making ventures.
I'm gonna take this moment to thank Asahi Lina and the other developers for their work and inspiration. Thank you. I wish I had even a small percentage of the reverse engineering skill you guys have.
I feel like there is some additional context missing. It's not like HN readers were spamming him, or flooding his platform. It's just, from what I gathered from this mastodon thread, that the people didn't read the article, resulting in comments on HN not being interesting enough for him.
But blocking people just because they are reading HN and learning about Asahi through it seems kinda extreme and uncalled for.
Wow, I haven't seen that since https://jwz.org used to redirect HN referrers to a certain old school NSFW internet meme. Plus, I don't think even he still pulls that kind of redirect BS these days.
Oops, sorry about that. I must have had something cached from when I verified that I had the correct tld, though in the end, jwz.com, jwz.net, and jwz.org all lead to the same place.
Wow. That's infuriating. I had no idea until I saw these comments. Apparently these people are insanely petty and gifted developers.
Here the relevant text about 16k page size kernels:
> IOMMU 4K patches (in review): The M1 is peculiar in that, although it supports OSes that use either 16K or 4K pages, it really is designed for 16K systems. Its DART IOMMU hardware only supports 16K pages. These chips have 4K support chiefly to make Rosetta work on macOS, but macOS itself always runs with 16K pages – only Rosetta apps end up in 4K mode. Linux can’t really mix page sizes like that and likely never will be able to, so we’re left with a conundrum: running a 16K kernel makes compatibility with older userspace difficult (chiefly Android and x86 emulation), plus distros don’t usually ship 16K kernels; while running a 4K kernel runs into a major mismatch with the DART. This initially seemed like a problem too intractable to solve, but 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! It’s not perfect, as it can’t support a select few corner case drivers (that do things that are fundamentally impossible to support in this situation), but it works well and will support everything we need to make 4K kernels viable.
I disagree. I don't mean that Ryzen 5800U lied about its stats or something, but the totality of the systems based on Ryzen 5800U is at best competitve with Intel systems and at worst Intel would look better. Unfortunately, the tuning that Apple have done is significant (more power-efficient screen, speakers and other assorted hardware that you would usually ignore).
Also, even ignoring all of that, Apple M series are basically the only option for a resonably functional ARM device. I acknowledge Chromebook can be effectively transformed into Linux, but their focus on price shows.
Intel is rapidly losing the server market to Arm. So, if you are targeting phones or the cloud, having an Arm laptop is an advantage. (MacOS includes a hypervisor that runs Arm Linux better than any native Arm Linux device I can purchase for myself.)
My point was that the intersection between the low level programming where you do care about which architecture you are running on and phones is very very slim.
Not saying that shouldn't be the case, but that is unfortunately where we are.
That's normal thing. Emulated hardware is normally chosen so that is simplest to implement and the drivers are most common. (Before you go up to the specialised solutions) Hypervisor runs X better than native is true for almost any X for non-critical solutions.
ARM (64-bit) is a much more secure architecture than Intel; it would be simply because it doesn't have variable-length instructions, but it also has PAC/BTI and more coming in ARMv9.
No, in the web browser case this is literally the most important thing. Second most important would be hardware image/video codecs but that's an optional power optimization. Third would be setting up IOMMUs so the wifi chip can't read all your memory.
Writing hardware drivers through reverse engineering is actually fairly common, not too difficult, and the people doing it for Asahi aren't running into problems - it's more like everyone else just assumes they will.
> I would have thought the browser was the most important thing. Do you have any examples to share?
No, you're right. The architectural differences like pointer signing sometimes need the code to adopt them but mostly you get them for free after the compiler adopts them.
A browser is special though because it runs JavaScript so it's got a compiler (JIT) in it. So exploiting the JIT lets you attack the rest of the system after you find something like a use-after-free or type confusion bug. The ARM security techniques MTE and PAC protect against this.
> Particularly and genuinely curious about how variable length instructions have affected browser security.
Basically the issue is that you can jump into the middle of an instruction and it can be another valid instruction. This lets you find something called a "ROP gadget" and construct a new evil program out of little bits of browser code. Harder but not impossible with fixed length instructions. BTI is meant to protect against this too.
It also makes it easier to hide evil code inside an innocent looking binary, but that's more of a problem for like an antivirus and there's other ways to do it anyway.
> "aren't running into problems". How would we know? (obviously talking about security problems here)
We wouldn't, that is possible. I just meant that they're making good progress getting everything to run at all, and most of the image of it being super hard is coming from commenters. (Of course it is pretty hard.)
Performance and power is pretty easy to observe just by watching your battery life though.
This is the difference right there. My daily driver is an 6800U (a slightly more efficient 5800U), the whole system idles on Linux at around 6W which is way too much to target whole day battery life. The performance is amazing though.
Yes. "TDP" from Intel and AMD have completely different definitions and are only loosely correlated with actual power consumption (especially for mobile parts); they're pretty much made up by the marketing departments for the purpose of product segmentation. The "TDP" they list for Apple is made up by PassMark; Apple doesn't publish a TDP number.
No mention of methodology there. In the review of the M1, it looks like they reported some numbers from software estimates (never particularly accurate, especially for cross-platform comparisons), and some measurements of wall power (ignoring the battery, which actually matters for peak power consumption). The one AMD 5800U review I checked seemed to be mostly using wall power measurements. Their methodology article does not really provide any further detail ( https://www.notebookcheck.net/Our-Test-Criteria.15394.0.html ). Every plausible way of producing the numbers in the comparison chart from the data they collect and present in their individual laptop reviews leaves them at risk of systematic errors on the order of several Watts.
That page has the 5800U at 18735 / 25w, around 750/w.
M2 8-core is 15356, and the tdp figure isn’t listed because it’s got the ram on the same package, but IIRC the entire package has a 15w tdp. If that recollection is correct, that’s over 1000/w; add 6w power use for ram to the ryzen and it’s really no contest.
Looking at the Cinebench R15 results it seems like the M1 x86 actually had better perf/Watt than the 5800U despite the oversite the M1 is running this 2013 benchmark via emulation.
Note: If you hit the expandos you'll see nearly every 5800U result is coming from a 30W/25W TDP 5800U. Even if you take the most favorable R15 test (multicore), the 25W value for the 5800U, and a 15W value for the M1 (despite the page saying 10W) that still comes out with perf/watt in favor of the M1 emulating the benchmark. If you look at the first native release of Cinebench (R23 in 2020) you'll see the reality that the M1 runs at about the exact same speed (slightly ahead in single core, slightly behind in multicore) at 1/2 the Wattage.
Interesting thank you! Also the primary/secondary core of the M1 is pretty clever. Intel 13th gen uses a similar strategy now, but not AMD yet, which is surprising considering their chiplet approach.
Not exactly. One chiplet has more L3 cache, but the other one can run at higher clock speeds, so which one to prefer depends on the application. Which makes it a horrible mess from a software/OS perspective.
Never underestimate doing something you feel passionate about. I understand the sentiment, but it's worse to work on something you don't really care about. You can put in 3x as many "human-hours" and you still still go nowhere.
I understand the early hacker mindset came from an era where we wanted to unlock hardware. But in 2023, good unlocked hardware exists and needs more love
What good unlocked hardware exists that is comparable to current apple silicon laptops? (In price, performance, heat, keyboard, trackpad, display quality, battery life, etc.)
The Lenovo Yogas and LG Grams are my favorite in the MacBook class. But if you want more upgradability I recommend the classical Framework 13 and HP elitebooks
tell me you've only used Linux since the mid 2010s without telling me you've only used Linux since the mid 2010s
This is very very very recent trend. This wasn't even the case when I was in school. You used to have to use the NDIS wrapper (Windows network driver support in the Linux kernel) for lots and lots of wifi chipsets to get any kind of wifi working.
The point being that it was vital for the success of Linux that there were hackeres willing to reverse engineer closed hardware to make it run. That there are now official and open source drivers for a lot of hardware is a directly consequence of it.
For GPUs AMD yes, but for example when the Asahi project started there was no open source driver from NVIDIA. These trends are very recent, and they do not guarantee anything more anyway (like who knows if they will continue contributing in the next generation).
Anecdotally, none. 2021/2022 I received five different Dell and Lenovo notebooks (Lattitude, Precision, ThinkPad, not consumer models) for customer projects to work on and every single one had battery or memory problems OOTB. Battery running times were a joke compared to a MBP, and so were the monitors. Mac notebook monitors aren't matte though, and I find the 14" Alu MBP a bit heavy and bulky. Mind, I was a big fan of my old 2016 XPS but even that had a swollen battery which needed replacement out of warranty.
Of those five notebooks I only kept a Thinkpad x13 gen 2 Ryzen (the last one/only one that wasn't broken) but it's not great either with dysfunctional power management/BIOS under Ubuntu 22.04, something I never had problems with so far on Thinkpads.
Intel/AMD based laptops are no more "unlocked" than apple's (and they are much worse in performance). Documentation is a different thing than "locking/unlocking".
the eternal ideology vs pragmatism debate. this project will get people a good linux machine that actually exists and you can buy in stores. besides, why not both. linux has been all about making it run on hardware without the manufacturers support or consent from the beginning.
Yeah, well, Intel laptops are trash subjectively speaking. I'd much rather have an M1 MacBook Air than any current Intel machine. In the past, ThinkPads were my favorite, but they got rid of many ergonomic features and now I can't even use tpmiddle to make the middle trackpoint button function as middle click without using scrolling features. Also, the BIOS on my Ryzen 5000 ThinkPad is always max brightness, regardless of what I had last set it to, so it's extremely uncomfortable to turn on at night or just after waking up, which is basically the only two times I want to use my laptop. Previous ThinkPads lacked all these issues, so they were my favorite overall laptops, but it increasingly seems like Lenovo staff probably don't even use them; I bet they use MacBooks, lol.
There is no reason MacBooks have to be the best modern laptops, and yet they are. That's why I think it's a good idea for this much effort to be put into making Linux/Free Desktop useful on them.
Genuine question, why do you think Apple doesn't publish docs about the M1 architecture?
They know the Asahi team will crack it anyway, but what's preventing them from opening the platform to make it even more popular?
It's just guess, but it very much possible Apple simply can't publish any documentation because even they use a lot of 3rd-party IP under NDA. Also publishing documentation officially make patents attack easier.
I not into defending Apple, but there are plenty of reasons why they're okay with Asahi team reverse engineering their hardware, but won't invest any money into making it more open. After all they earn a lot from subscription services and Linux users wont pay for them.
1. Documentation implies a commitment to the decisions made thus far. Apple has no compunctions about changing things behind the scenes and concealing the impact from users as much as possible.
2. Apple’s bread and butter are always going to be macOS users, Linux will be a rounding error.
Thought it was only me getting irritated by permanently missing plain touchpad left-click on a x13 3nd gen, clumsily middle clicking instead. That together with loss of kinetic scroll alone is such a regression. Actually, I'm looking at that notebook in anticipation of pain, and grabbing the MacBook next to it instead (running Mac OS but looking forward to run Linux on it as well).
There’s a level of zen above this where you simply do not care about the concept of what the company cares about or who you’re benefitting. Not everything has to be a move in the game.
Even if Apple makes it impossible for asahi to work at all the Linux kernel would have benefited from bug fixes and graphics devs writing shaders for apple devices would have better insight into the perf of what they are writing due to a reverse engineered disassembler.
Because then Linux wouldn't run on anything. Same deal for 99% of laptop manufacturers. Most of it is closed and reverse engineered, including ThinkPads.
So what? Did Broadcom or Nvidia contribute to the open source drivers you probably use on Linux? How many contributions did Intel make to the Linux kernel from 1991 to 2000 during which the kernel was in the infancy of running on Intel silicon?
Do Intel's micro-arch manuals tell the whole story or do people go to Anger Fog website frequently (https://www.agner.org/optimize/)?
Even then a lot of it was, is or still would be broken if not for those willing to contribute their own time instead of waiting for the vendors' effort.
They contribute some drivers, but not all. There are still some ThinkPads without full functionality on Linux due to closed hardware. Until just a few years ago it was 100% reverse engineered.
If anything this weakens Apple's grip. For example, I would consider dual booting, or even erasing my mac partition depending on how things go with Asahi. I just like the Macbook hardware. The software I'd rather use linux most of the time, especially if everything is working
No, I don't think so. There are about 100 million Mac users. The vast majority of them don't even know what Linux is. No way Apple's "grip" is impacted.
I don't think it harms them financially though. You still have to buy the macbook and I don't think they earn any significant amount of money from you running macOS on it after that, I've bought like one $6 app on the mac app store. Being able to run linux makes me more likely to buy more macbooks in the future and if I can run windows games I'll get the highest-specced one available.
You are what folks would call a Linux consumer. Fact is that
1) if everyone (especially kernel devs) all had your attitude linux wouldn't run on a darn thing
2) Apple's made no indication that they would stop alternative operating systems from working with their boot loader. in fact their own engineer(s) have tweeted that their boot loader has that in mind and theyre going to do nothing to stop it
3) it happens to be the most cost effective high performance arm hardware that anyone can get their hands on. Even if you take the top end ampere the single threaded perf is half (although the 80 core+ versions make up for it in multithread). It would be absolutely foolish to not use this hardware target for Linux.
4) the M1 architecture (the entire SoC) breaks a lot of assumptions that other hardware has made, and this is a great way to fix bugs in Linux as well a lot of the software on top of the kernel as well.
Finally I think the work folks have done on asahi is probably really useful for anyone trying to optimize graphics shaders on Apple devices at the per instruction level (which they have consistently obfuscated with pretty charts in their performance tooling in Xcode).
Do you care that Nvidia isn't open with their Linux driver or that Broadcom didn't to my knowledge ship an open source driver for many of their wifi cards? It is really common for GPU vendors to keep their hardware details proprietary because they're all trying to one up each other on benchmarks and games every year. Just because Intel and AMD do open source drivers doesn't mean that what Apple is doing is unique.
majority of linux users buy AMD because of drivers alone. avoid broadcom like the plage etc.
asahi linux is weird. theres no good reason to explain its existence other than there are too many people willing to give money to apple for no good reason.
"no good reason", except the performance, battery life & build quality?
Different people have different needs, preferences & ideological beliefs to you. If you measure the actions of others, based on your viewpoint alone, you will never understand the rest of humanity.
The biggest lesson that owning a Macbook has taught me is that my world view as a power user is a minority and worthless one that should be relegated to /dev/null under most circumstances.
Fucking nobody cares about the gripes I would have with it, and I've even come around to appreciate the fact that Apple sells goods engineered to the desires of people who aren't me (read: the majority): I can't deny the speakers on my Macbook are fucking amazing, and most people would care about that rather than whether something is FOSS.
Ok, but apart from the performance, the novel hardware architecture, the battery life, the build quality, the recyclability, and the documentation and tooling for developing custom kernels, what has Apple ever done for us?
What do you mean, it is pretty obvious that having more low level control would allow developers improve aspects of their software in certain cases. I am using software for some very time sensitive applications, and in this case linux > windows > macos just because apple's documentation and implementation is not dev friendly while linux with open source amd drivers have the best performance of all. Being closed and not dev-friendly has its costs, too.
Well, actually some people do care, for different reasons. If apple was more open then it would appeal much more to these people.
Sometimes it is even just a practical issue: having as low level control as possible can increase performance in certain aspects, for example in latency related tasks, that can be important in certain applications. This does not make everything else useless, but there are definitely tasks for which I choose an AMD gpu over an NVIDIA gpu (or apple silicon) just because of the open source drivers in linux.
A lot of this control and insight into the µarch is gleaned by the public not from the hardware company's released drivers or docs but through exactly this sort of reversing. See Ager's website as an example.
You could also take this to the extreme, as Stallman used to do with his OLPC where he deleted the wifi blob to only use lan because it wasn't free enough. If you have to wait for hardware company's to build free and open drivers and open hardware docs and open firmwares to use linux well im afraid your options are basically some X220 with a Open rom bios reimage.
For now, Apple's arm64 silicon is the most compelling option for anyone that wants to develop on the architecture locally. It's the same way as how i386 was the most compelling option for anyone that wanted to run a free unix at home in 1991. It just does not matter that Apple hasn't done a dump of all their drivers and hardware docs because it is all we have and the hardware is damn good at that too.
My personal answer: It's good hardware. I like good hardware, so I'm pro-competition. Doing the work makes the hardware documented, for anyone to understand (mainly developers, but also Apple's competitors). Having more developers on ARM also makes ARM more competitive, and helps to break the x86 duopoly on single-core performance.
It's a gift to users and developers, not Apple. I like arm64 a lot more than RISC-V, and find their documentation better. And there aren't yet RISC-V CPUs that have competitive single-core performance.
Thanks! It's a tiny contribution compared to Alyssa and Lina's development and reverse engineering work, but it's been very educational and rewarding work so far :)
And it’s an extra special gift to people who will be buying or inheriting secondhand Apple Silicon hardware in four, five, six years from now. Projects like Asahi Linux will literally divert some obsolete hardware from landfill.
A lot of people agree with you, like me. There is huge amount of talent wasted on things like this. Obviously it has an audience, but that doesn’t mean it is meaningful.
Who are you to tell what kind of activities are wasteful and which aren't? Though you are free to pay talented people to spend their time in ways you find more productive or "meaningful".
When somebody builds a RISC-V laptop people will start working on software for it. In any case, the GPU getting built into RISC-V SoCs is a PowerVR one, there is supposed to be an open-source driver being written for it but right now the situation is no better than for the Apple M1.
> But why work on hardware from a company that is so closed-source and user/hacker hostile? Why gift your talent to a company that doesn't respect you ?
I'm glad Asahi exists, and I hope that it will become as successful as it can possibly be, but I remember being surprised about it because the founder of Asahi Linux used to viciously complain about the closed parts of the Raspberry Pi hardware on twitter, at the most heated moments comparing them with Apple. I first became aware of him when he shared the barely-obfuscated hardware keys needed to clone the RPi v2 camera hardware (or something). I remember him ranting about how the Raspberry Pi foundation had gone "full Apple" and how we ought to call the Raspberry Pi "the Raspberry iPi."
I don’t know the specifics, but there is a difference between a supposedly open hardware and one that was made for proprietary usage. Apple won’t go out of their way to make drivers for a different OS, but they don’t hinder it at all. Our expectations should be in the context of a given product.
I used to use it on my M1 MBP. For M2 MBP only the 13" is supported, 14" and 16" still need some "minor" work to let the components know how to initialize in those models. Since I switched to M2 MBP I haven't been able to use it lately and miss it :).
For day to day the biggest pain points for me were the lack of speaker, microphone, and webcam support. Bluetooth and 3.5mm audio worked fine though. GPU support was useable for browsing and whatnot before so with the recent massive speedup and continued OpenGL support improvements I can only imagine it's even better now. Wi-Fi, touchpad, keyboard, screen brightness, and USB all seemed to work fine for me. I think HDMI out, DP alt mode from the type c, and thunderbolt were all unsupported as was touch-id. Battery life was worse than macOS but still better than a normal laptop (for my usage pattern at least). Software side it's ALARM (Arch Linux ARM) based and "I use Arch btw" so I had no complaints. Users who prefer other distros may not like that and while it's possible to get certain other distros running the experience isn't as good and seems complicated. Wayland is the officially recommended display server option and XWayland works fine in it for running X11 only apps. Early on the 16k pages created a lot of headache but that seemed out of the way towards the end of me having the M1. Some Electron apps were slow to upgrade to a Chromium base which included the 16k page support. I never really messed with FEX or anything about running x86 and/or Windows stuff on it, just native packages. The installer was pretty straightforward to use.
(CtrlFn⊞AltSpaceAlt⊞), except for the double-swapped right-option which acts as Win instead of the expected Ctrl.
There is a `rightalt_as_rightctrl` patch[2 which doesn't work with Asahi yet, but there's plans to upstream it. However, marcan was planning to make some massive changes in the apple-hid driver, so it might take a while.
I have the M1 MBP. I use it as a daily driver for my personal computing (I have another company-owned laptop). Currently, I'm doing a little programming in rust and some photo work in Darktable. Of course many others things work too.
I also compiled and ran some 7+ years old C++ projects successfully.
Only thing I'm missing is standby. It sounds a little ridiculous that I have an expensive laptop at home and I need to boot it every time.
Using it on M2 Air, but only as my driver while travelling. What I wrote elsewhere:
> Asahi works great on Apple Silicon. There’s a small collection of software (like Widevine/Zig) that isn’t available on Asahi/ARM64, and some important features that are still in progress (Speakers/Webcam/Mic/External Monitors). GPU and Sleep support is still experimental, but the device is usable enough for me (No critical showstoppers so far).
Widevine has since been solved in a great hack[0].
According to https://github.com/AsahiLinux/docs/wiki/Feature-Support there's at least partial audio support for every machine except the models introduced so far this year, using the 3.5mm output. The built-in speakers are still disabled by default while they work on the software required to drive them at reasonable loudness without burning them out. It's not clear to me whether audio over HDMI works for the models where they already have HDMI support.
Not much different from Proton, they're both based on Wine. They're probably the most similar stack layer. Everything else (x86 emulator, graphics driver, OS) is completely different.
Linux has come a long way in terms of gaming. Literarily all my steam games run on Linux without issue, rig being a 3090 amd ryzen. I am surprised at how stable everything is and how well the ui works (kde, xfce, and openbox - the latter for focused work).
157 comments
[ 3.0 ms ] story [ 216 ms ] threade: i checked linas mastodon and apparently it's using FEX
https://fex-emu.com/
So you need to compile a custom kernel for FEX to run and Steam to work.
Still, great work from Lina and the Asahi team, very excited about getting full FEX support on stock kernels (I have a backlog of Humble Bundle games to try with this).
https://support.mozilla.org/en-US/questions/1130505
Here's a list of them maintained by the extension mentioned above: https://gitlab.com/smart-referrer/smart-referer/-/blob/gh-pa...
If there is a basic archetype of a HN comment, yours is a perfect example of it
However if you're looking for the basic archetype of a bad HN comment I think yours is actually much more appropriate. Very poor form :-/
He loudly supported a hateful and slanderous campaign that resulted in RMS having to step down from the FSF.
Now he comes along and for whatever reason he's decided to adopt this weird hentai alter ego, which is very obviously him... but for some reason we're not allowed to mention it - because? ...actually I have no idea why.
But he certainly doesn't mind dealing in rumours when it's against people he decides deserve it.
*Ahem*
Complaining about people not reading the article and then denying those people the ability to read the article is 300% concentrated irony. Holy shit.
(I'm assuming the motivations behind the redirect are what marcan is complaining about. marcan's complaint by itself is valid, of course. People only reading headlines is nothing new.)
And while it sure can be frustrating when completely avoidable questions are asked, I don't get why that's so bad that one has to block the website. Especially considering 95% of comments to marcan's post linked above could be summarized as "haha orange site bad" - a lack of substance doesn't seem to be the issue.
I'm sure this frustration has a cause, but I struggle to see what that is.
I went back and read some of the discussion in the other thread. I didn't read everything because of time. What strikes me isn't the bad faith or poor form trying to expose someone or arguing a tangent on an interesting subject. It is how embarrassing it is. And how embarrassing it that they don't know how embarrassing it is. If I managed to even slightly get my point across you will understand why I can't explain why it is embarrassing. What I can say is that it isn't about just about being wrong or being rude. It about not knowing what they are talking about while being convinced that they have a point.
And no I don't think it is ironic. If you consider Hacker News a net negative blocking your blog from being published here is consistent with that view. More would if "all publicity is good publicity" wasn't such a strong idea in money making ventures.
But blocking people just because they are reading HN and learning about Asahi through it seems kinda extreme and uncalled for.
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
Here the relevant text about 16k page size kernels:
> IOMMU 4K patches (in review): The M1 is peculiar in that, although it supports OSes that use either 16K or 4K pages, it really is designed for 16K systems. Its DART IOMMU hardware only supports 16K pages. These chips have 4K support chiefly to make Rosetta work on macOS, but macOS itself always runs with 16K pages – only Rosetta apps end up in 4K mode. Linux can’t really mix page sizes like that and likely never will be able to, so we’re left with a conundrum: running a 16K kernel makes compatibility with older userspace difficult (chiefly Android and x86 emulation), plus distros don’t usually ship 16K kernels; while running a 4K kernel runs into a major mismatch with the DART. This initially seemed like a problem too intractable to solve, but 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! It’s not perfect, as it can’t support a select few corner case drivers (that do things that are fundamentally impossible to support in this situation), but it works well and will support everything we need to make 4K kernels viable.
For anybody who wants to read the whole thing: https://archive.is/Wc0XN
Making foss for the hardware that best suits you is good, actually.
Also, even ignoring all of that, Apple M series are basically the only option for a resonably functional ARM device. I acknowledge Chromebook can be effectively transformed into Linux, but their focus on price shows.
Do you have benchmarks of Intel 11 gen beating Zen 3 ?
Being on a less used architecture, in the PC context, has its downsides.
Iphones do, but the biggest advantage of an M1 in that case the advantage by far ought to be "runs macos" and not, "is arm".
x86 rapidly losing in serverspace? No. If you work on servers you are still mostly working on x86. And in most cases it wouldn't matter anyway.
Lot of hypotheticals to try and justify it.
Since when? If you mean Android’s Java, it is mostly AOT compiled/cached machine code.
My point was that the intersection between the low level programming where you do care about which architecture you are running on and phones is very very slim.
Not saying that shouldn't be the case, but that is unfortunately where we are.
And you think it is relevant for a laptop?
Really.
> And you think it is relevant for a laptop?
Yes, it's got your personal info and you run a web browser on it.
When we get to those kind of details, maybe you shouldn't rely on drivers that were written without proper information about the hardware?
Writing hardware drivers through reverse engineering is actually fairly common, not too difficult, and the people doing it for Asahi aren't running into problems - it's more like everyone else just assumes they will.
Particularly and genuinely curious about how variable length instructions have affected browser security.
"not too difficult", I guess everything is relative. But I'd have to disagree and say that the work they do is quite difficult.
"aren't running into problems". How would we know? (obviously talking about security problems here)
No, you're right. The architectural differences like pointer signing sometimes need the code to adopt them but mostly you get them for free after the compiler adopts them.
A browser is special though because it runs JavaScript so it's got a compiler (JIT) in it. So exploiting the JIT lets you attack the rest of the system after you find something like a use-after-free or type confusion bug. The ARM security techniques MTE and PAC protect against this.
> Particularly and genuinely curious about how variable length instructions have affected browser security.
Basically the issue is that you can jump into the middle of an instruction and it can be another valid instruction. This lets you find something called a "ROP gadget" and construct a new evil program out of little bits of browser code. Harder but not impossible with fixed length instructions. BTI is meant to protect against this too.
It also makes it easier to hide evil code inside an innocent looking binary, but that's more of a problem for like an antivirus and there's other ways to do it anyway.
> "aren't running into problems". How would we know? (obviously talking about security problems here)
We wouldn't, that is possible. I just meant that they're making good progress getting everything to run at all, and most of the image of it being super hard is coming from commenters. (Of course it is pretty hard.)
Performance and power is pretty easy to observe just by watching your battery life though.
M2 8-core is 15356, and the tdp figure isn’t listed because it’s got the ram on the same package, but IIRC the entire package has a 15w tdp. If that recollection is correct, that’s over 1000/w; add 6w power use for ram to the ryzen and it’s really no contest.
Check the Cinebench R15 multicore here, Zen3 wins on perf/watt again
https://www.notebookcheck.net/M1-vs-R7-5800U_12937_12976.247...
Note: If you hit the expandos you'll see nearly every 5800U result is coming from a 30W/25W TDP 5800U. Even if you take the most favorable R15 test (multicore), the 25W value for the 5800U, and a 15W value for the M1 (despite the page saying 10W) that still comes out with perf/watt in favor of the M1 emulating the benchmark. If you look at the first native release of Cinebench (R23 in 2020) you'll see the reality that the M1 runs at about the exact same speed (slightly ahead in single core, slightly behind in multicore) at 1/2 the Wattage.
For comparison an entire Mac Mini system pulls 30W from the wall when running a compute benchmark workload https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste... including conversion loss, peripherals, memory, and anything else.
This is very very very recent trend. This wasn't even the case when I was in school. You used to have to use the NDIS wrapper (Windows network driver support in the Linux kernel) for lots and lots of wifi chipsets to get any kind of wifi working.
The Dell XPS and Razer models are much more similar in build quality, hardware capabilities and price range to the MBPs.
Of those five notebooks I only kept a Thinkpad x13 gen 2 Ryzen (the last one/only one that wasn't broken) but it's not great either with dysfunctional power management/BIOS under Ubuntu 22.04, something I never had problems with so far on Thinkpads.
There is no reason MacBooks have to be the best modern laptops, and yet they are. That's why I think it's a good idea for this much effort to be put into making Linux/Free Desktop useful on them.
I not into defending Apple, but there are plenty of reasons why they're okay with Asahi team reverse engineering their hardware, but won't invest any money into making it more open. After all they earn a lot from subscription services and Linux users wont pay for them.
1. Documentation implies a commitment to the decisions made thus far. Apple has no compunctions about changing things behind the scenes and concealing the impact from users as much as possible.
2. Apple’s bread and butter are always going to be macOS users, Linux will be a rounding error.
Do Intel's micro-arch manuals tell the whole story or do people go to Anger Fog website frequently (https://www.agner.org/optimize/)?
It doesn't matter.
> this weakens Apple's grip.
Because I don't think Asahi harms them.
1) if everyone (especially kernel devs) all had your attitude linux wouldn't run on a darn thing
2) Apple's made no indication that they would stop alternative operating systems from working with their boot loader. in fact their own engineer(s) have tweeted that their boot loader has that in mind and theyre going to do nothing to stop it
3) it happens to be the most cost effective high performance arm hardware that anyone can get their hands on. Even if you take the top end ampere the single threaded perf is half (although the 80 core+ versions make up for it in multithread). It would be absolutely foolish to not use this hardware target for Linux.
4) the M1 architecture (the entire SoC) breaks a lot of assumptions that other hardware has made, and this is a great way to fix bugs in Linux as well a lot of the software on top of the kernel as well.
Finally I think the work folks have done on asahi is probably really useful for anyone trying to optimize graphics shaders on Apple devices at the per instruction level (which they have consistently obfuscated with pretty charts in their performance tooling in Xcode).
majority of linux users buy AMD because of drivers alone. avoid broadcom like the plage etc.
asahi linux is weird. theres no good reason to explain its existence other than there are too many people willing to give money to apple for no good reason.
Different people have different needs, preferences & ideological beliefs to you. If you measure the actions of others, based on your viewpoint alone, you will never understand the rest of humanity.
Fucking nobody cares about the gripes I would have with it, and I've even come around to appreciate the fact that Apple sells goods engineered to the desires of people who aren't me (read: the majority): I can't deny the speakers on my Macbook are fucking amazing, and most people would care about that rather than whether something is FOSS.
Sometimes it is even just a practical issue: having as low level control as possible can increase performance in certain aspects, for example in latency related tasks, that can be important in certain applications. This does not make everything else useless, but there are definitely tasks for which I choose an AMD gpu over an NVIDIA gpu (or apple silicon) just because of the open source drivers in linux.
You could also take this to the extreme, as Stallman used to do with his OLPC where he deleted the wifi blob to only use lan because it wasn't free enough. If you have to wait for hardware company's to build free and open drivers and open hardware docs and open firmwares to use linux well im afraid your options are basically some X220 with a Open rom bios reimage.
For now, Apple's arm64 silicon is the most compelling option for anyone that wants to develop on the architecture locally. It's the same way as how i386 was the most compelling option for anyone that wanted to run a free unix at home in 1991. It just does not matter that Apple hasn't done a dump of all their drivers and hardware docs because it is all we have and the hardware is damn good at that too.
i.e making the linux port possible even if not supporting it publicly.
It's a gift to users and developers, not Apple. I like arm64 a lot more than RISC-V, and find their documentation better. And there aren't yet RISC-V CPUs that have competitive single-core performance.
I hope I don’t have to detail why is it fallacious thinking.
When somebody builds a RISC-V laptop people will start working on software for it. In any case, the GPU getting built into RISC-V SoCs is a PowerVR one, there is supposed to be an open-source driver being written for it but right now the situation is no better than for the Apple M1.
I'm glad Asahi exists, and I hope that it will become as successful as it can possibly be, but I remember being surprised about it because the founder of Asahi Linux used to viciously complain about the closed parts of the Raspberry Pi hardware on twitter, at the most heated moments comparing them with Apple. I first became aware of him when he shared the barely-obfuscated hardware keys needed to clone the RPi v2 camera hardware (or something). I remember him ranting about how the Raspberry Pi foundation had gone "full Apple" and how we ought to call the Raspberry Pi "the Raspberry iPi."
For day to day the biggest pain points for me were the lack of speaker, microphone, and webcam support. Bluetooth and 3.5mm audio worked fine though. GPU support was useable for browsing and whatnot before so with the recent massive speedup and continued OpenGL support improvements I can only imagine it's even better now. Wi-Fi, touchpad, keyboard, screen brightness, and USB all seemed to work fine for me. I think HDMI out, DP alt mode from the type c, and thunderbolt were all unsupported as was touch-id. Battery life was worse than macOS but still better than a normal laptop (for my usage pattern at least). Software side it's ALARM (Arch Linux ARM) based and "I use Arch btw" so I had no complaints. Users who prefer other distros may not like that and while it's possible to get certain other distros running the experience isn't as good and seems complicated. Wayland is the officially recommended display server option and XWayland works fine in it for running X11 only apps. Early on the 16k pages created a lot of headache but that seemed out of the way towards the end of me having the M1. Some Electron apps were slow to upgrade to a Chromium base which included the 16k page support. I never really messed with FEX or anything about running x86 and/or Windows stuff on it, just native packages. The installer was pretty straightforward to use.
For detailed feature support tables this page has the info https://github.com/AsahiLinux/docs/wiki/Feature-Support
Oh and you can swap the command/option keys around to the non-Apple way if you want:
There is a `rightalt_as_rightctrl` patch[2 which doesn't work with Asahi yet, but there's plans to upstream it. However, marcan was planning to make some massive changes in the apple-hid driver, so it might take a while.
[2]: https://github.com/free5lot/hid-apple-patched/issues/1
Only thing I'm missing is standby. It sounds a little ridiculous that I have an expensive laptop at home and I need to boot it every time.
> Asahi works great on Apple Silicon. There’s a small collection of software (like Widevine/Zig) that isn’t available on Asahi/ARM64, and some important features that are still in progress (Speakers/Webcam/Mic/External Monitors). GPU and Sleep support is still experimental, but the device is usable enough for me (No critical showstoppers so far).
Widevine has since been solved in a great hack[0].
[0]: https://gist.github.com/DavidBuchanan314/c6b97add51b97e4c3ee...
I like running macOS and it's a pain to have to reboot or run Windows in a VM just to play a game.