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 ?
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.