Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Asahi Linux Progress Report: January/February 2021

asahilinux.org

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Asahi Linux Progress Report: January/February 2021

#61

Post by lovelyviking »

marcan_42 wrote: post #4
rvz wrote: post #2

> Welcome to the first Asahi Linux Progress Report! In this series we’ll be taking a page from the Dolphin playbook and giving you monthly updates on the progress of the project. Nice work! let's see the progress... ~60,000+ words later... > We could keep talking in depth for another 10000 words, but alas, this post is already too long. Please no. A TL;DR is just enough for the busy. The Dolphin report even shows mor…

Well, Dolphin is an emulator, so screenshots and videos are quite an obvious tool to demonstrate game emulation issues... and it's also easier to boil down most changes to "fixes X issue on Y game" for a mature project; that model doesn't map quite as well to the early stages of an OS port project, especially since most of the stuff in this first report is literally required to get anything to work at all. The one sc…

I liked the long form too because there is a lot to learn there. I really appreciate what you do. Actually one of the decisive factors for buying M1 was the fact that you work on making it gnu/linux friendly. Perhaps some shorter form in the beginning could also help for better understanding before one can comprehend all the details but if we ask for that it's better be done in a respectful way. Thank you for your hard work.

Re: Asahi Linux Progress Report: January/February 2021

#62

Post by floatboth »

marcan_42 wrote: post #8
als0 wrote: post #6

> On the other hand, the rest of the 64-bit ARM world has largely converged on two competing standards: UEFI + ACPI (largely used by servers running Windows or Linux), It's not supposed to be just for servers, the Arm Base Boot Requirements (BBR) require it for any non-embedded use https://developer.arm.com/documentation/den0044/latest The new ARM64 laptops follow BBR so they have UEFI+ACPI, which means they can run…

It's not really a question of firmware support; the standards need amending to support all of this, and then OSes need to implement core support. Basically, there will never be a way to run Windows natively on Apple Silicon without someone pushing to have a pile of new Apple-specific stuff added to ACPI, and then getting Microsoft to implement support for it. The only way to run Windows on Apple Silicon without all o…

If Broadcom of all companies switched to the GIC, I wonder if there's any chance Apple would do the same in a later chip – in a less rushed dev cycle that's not just "quickly desktopify the iDevice SoC". (Also SMMU along with the GIC…)

Of course the unfortunate reality is that there is just no motivation for them to do this. Goddamn vertical integration! But.. maybe Boot Camp could motivate this? Though so far it seems they're just pushing virtualization instead.

Re: Asahi Linux Progress Report: January/February 2021

#63

Post by als0 »

blackrock wrote: post #60
als0 wrote: post #56

Earlier quoted context omitted.

Most of the modularity and security advantages still apply today. Performance is also good, unlike early implementations. Google is developing a microkernel operating system called Fuchsia, possibly to replace Android https://en.wikipedia.org/wiki/Google_Fuchsia

Is it because of runtime speeds (the slowness) that prevents microkernel operating systems from being more prevalent? Or is it just because Linux is good enough, and it became popular and free?

There is a speed impact but it's mostly negligible, especially on modern hardware. The main reason is that building an entire operating system requires enormous investment beyond what most companies are willing to spend. But Google seems to be willing. And even if you succeed, people will inevitably chase you on Linux app compatibility.

Some well known open-source examples are seL4 and RedoxOS.

Re: Asahi Linux Progress Report: January/February 2021

#64

Post by someperson »

chaorace wrote: post #37

I remember getting to the midpoint and thinking "Man, all of these PowerPC-isms really takes me back to the Wii modding days!". Imagine my face when I read this line: "m1n1 traces its past to mini, which is a minimal environment that I wrote for the Nintendo Wii’s security CPU". As if there was any doubt: Hardware reverse engineers are a very special breed of dedicated people. There aren't many of them, but those tha…

Yeah marcan helped hack the Nintendo Wii. See his original talk at 25C3 here [1].

The other guy in the talk [1] is the late Ben 'bushing' Byer. I only knew him from his online work, but it's still very sad that he passed away in 2016 [2]. I'm sure if he was still alive, he'd also continue to be doing great reverse engineering work!

[1] https://www.youtube.com/watch?v=lyVuY_S5VcI

[2] https://fail0verflow.com/ben

Re: Asahi Linux Progress Report: January/February 2021

#65

Post by saagarjha »

als0 wrote: post #63
blackrock wrote: post #60

Earlier quoted context omitted.

Is it because of runtime speeds (the slowness) that prevents microkernel operating systems from being more prevalent? Or is it just because Linux is good enough, and it became popular and free?

There is a speed impact but it's mostly negligible, especially on modern hardware. The main reason is that building an entire operating system requires enormous investment beyond what most companies are willing to spend. But Google seems to be willing. And even if you succeed, people will inevitably chase you on Linux app compatibility. Some well known open-source examples are seL4 and RedoxOS.

The speed is not really “mostly negligible”, it’s just something that you accept when you design a microkernel.

Re: Asahi Linux Progress Report: January/February 2021

#66

Post by marcan_42 »

pronoiac wrote: post #57

Ah, the author is here, and leaving feedback here seems easiest - > Our current Linux bring-up series is in its third version There's a #fragment in the link, and it goes to a less interesting part of the page. I only circled back after looking at the first and second versions.

The links should go to the same style page now, thanks!

Re: Asahi Linux Progress Report: January/February 2021

#67

Post by kevincox »

marcan_42 wrote: post #40
marcan_42 wrote: post #20

Earlier quoted context omitted.

I'll add a link later; this was on my TODO list but I didn't get a chance to do it yet.

Link (and header s) added!

I now see it on the blog root but it would be great if the actual article was also marked up with the RSS feed. This is pretty standard and I only bothered looking at the blog homepage because the writing was really good :)

Re: Asahi Linux Progress Report: January/February 2021

#68

Post by als0 »

saagarjha wrote: post #65
als0 wrote: post #63

Earlier quoted context omitted.

There is a speed impact but it's mostly negligible, especially on modern hardware. The main reason is that building an entire operating system requires enormous investment beyond what most companies are willing to spend. But Google seems to be willing. And even if you succeed, people will inevitably chase you on Linux app compatibility. Some well known open-source examples are seL4 and RedoxOS.

The speed is not really “mostly negligible”, it’s just something that you accept when you design a microkernel.

Agreed. More services does mean more context switching. The most pure microkernels will have many, and the more practical ones may consolidate some services to reduce context switches. Also, some types of IPC can have a very lightweight context switch; they typically transfer only a few words of data, but this is usually mitigated by shared memory.

Re: Asahi Linux Progress Report: January/February 2021

#69

Post by pronoiac »

marcan_42 wrote: post #66
pronoiac wrote: post #57

Ah, the author is here, and leaving feedback here seems easiest - > Our current Linux bring-up series is in its third version There's a #fragment in the link, and it goes to a less interesting part of the page. I only circled back after looking at the first and second versions.

The links should go to the same style page now, thanks!

Confirmed!
Post reply on HN