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.
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.
Being on a less used architecture, in the PC context, has its downsides though.
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.
Do you have benchmarks of Intel 11 gen beating Zen 3 ?
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.
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."
The same human-hours could have produced so much more on actually open platforms with actual documentation and respect like RISC-V ?