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

Asahi Linux 7.1 Progress Report

asahilinux.org

Post reply on HN
Print view View original

201–210 of 258 posts

Re: Asahi Linux 7.1 Progress Report

#201

Post by TazeTSchnitzel »

eqvinox wrote: post #46

> The defacto industry standard for audio ICs is I²S, an I²C-based bus optimised for audio data. Nit: I²S has nothing to do with I²C. (Most I²S chips also have an I²C interface since I²S only carries raw audio data, no sideband like volume control or clock configuration. But that's a separate interface and can also be SPI rather than I²C. In fact, SPI is more closely related to I²S than I²C is.)

I²S is a remarkably simple design. There's no protocol handshakes, it's just raw PCM. I like how it's designed so sender and receiver can use totally different sample bit-depths (in either direction) without any incompatibility.

https://web.archive.org/web/20070102004400/http://www.nxp.co...

Re: Asahi Linux 7.1 Progress Report

#202

Post by utlsao »

debugnik wrote: post #144
dandellion wrote: post #119

Earlier quoted context omitted.

You'll never be able to agree on where that line should go. First because there's a cultural component to it. I'm from Spain so I can only talk for myself, but while he uses rude language, nothing I've ever read from him ever seemed particularly offensive. And second because any activity involving a large group of people will need some amount of toxicity if only to prevent other toxic people from derailing it, and si…

> nothing I've ever read from him ever seemed particularly offensive You may have missed the "retroactively aborted" one. https://lkml.org/lkml/2012/7/6/495 To be fair, he's got much more self-control now.

That post is so exaggerated that it is funny.

That implementation is also hilariously bad:

> read things ONE F*CKING BYTE AT A TIME with system calls for each byte

Re: Asahi Linux 7.1 Progress Report

#203

Post by tcmart14 »

bsammon wrote: post #172
nosioptar wrote: post #82

Earlier quoted context omitted.

You should have high standards. Torvalds often crosses that line into outright toxicity. I've written a few kernel patches that I never tried to upstream for that reason.

I seem to remember reading somewhere that, even at his worst, Linus limited his toxicity to professional-programmer kernel contributors (i.e. people who were employed by linux distros or hardware companies to contribute to Linux). Can anyone else remember/confirm this? Regardless, to a newbie potential kernel contributor, that high level of toxicity can be intimidating, and the professional-programmers-only aspect is…

That is my understanding also. It was mostly for people who were around and should know better. He would never do this to a new contributor. Granted, he almost never sees code from new contributors in review. But what he will do is, if there is something egregious from a new contributor, he lights of the maintainer of the system.

example. I don't remember what all system Greg KH is responsible for, but for the sake of argument, lets say USB. You as a new contributor, try to contribute a patch to the USB subsystem. Turns out it is total garbage. For it to get Linus's attention, it has to have gone through review by Greg KH. Linus will light up Greg and only Greg because Greg has been doing this for 20+ years.

Now, do I feel he sometimes goes over board and unprofessional? Yes. But people keep contributing and the thing keeps chugging along.

Re: Asahi Linux 7.1 Progress Report

#204

Post by utlsao »

bsammon wrote: post #172
nosioptar wrote: post #82

Earlier quoted context omitted.

You should have high standards. Torvalds often crosses that line into outright toxicity. I've written a few kernel patches that I never tried to upstream for that reason.

I seem to remember reading somewhere that, even at his worst, Linus limited his toxicity to professional-programmer kernel contributors (i.e. people who were employed by linux distros or hardware companies to contribute to Linux). Can anyone else remember/confirm this? Regardless, to a newbie potential kernel contributor, that high level of toxicity can be intimidating, and the professional-programmers-only aspect is…

Or it may attract talented and responsible people, since it makes it more of an honor if a patch gets through the gauntlet. Especially since the gauntlet is fit for a system that literally affects billions of people in so many ways.

Re: Asahi Linux 7.1 Progress Report

#205

Post by simonh »

amelius wrote: post #193
simonh wrote: post #152

Earlier quoted context omitted.

It basically just has to look like macOS in some trivial sense, it doesn't have to be macOS, there are no obstacles. The system is designed specifically to enable booting custom compiled kernels and former members of the Apple team have said booting other OSes was intentionally left open. The company just doesn't make any guarantees about that.

Where is it stated in official Apple communications that Apple laptops will always support other OSes like Linux? There you have it. If they don't guarantee it, then better not depend on it. Or waste your time on it. This also holds for members of the Asahi team. Unless they don't mind that a decade or so of their working life goes down the drain in one decision from Apple management or Apple lawyers.

That is irrelevant for the laptops Asahi currently support or are working on supporting.

Re: Asahi Linux 7.1 Progress Report

#206

Post by zbentley »

> The firmware loaded by XNU is not verified by the CM3. It will begin executing from its reset vector when signalled, no matter what is actually there. What if we just… used our own firmware?

Without taking away from the unutterably awesome achievement of writing custom firmware against a proprietary moving target, I worry about this one specifically. While Apple will hopefully continue the practice of not going out of their way to break third-party OSes, it doesn’t seem unlikely that they will introduce hardware signing for firmware blobs or the data they supply at runtime when programming the hardware; that’s a reasonable security concern for Apple to address. I hope this gamble pays off though!

Re: Asahi Linux 7.1 Progress Report

#207

Post by zbentley »

jagged-chisel wrote: post #147
drbawb wrote: post #131

Earlier quoted context omitted.

The Apple Platform Security[1] white paper describes the secure boot process for Apple silicon. The Mac boot process is significantly more configurable than the iOS boot process, and it allows operating in reduced security modes. (Including running locally signed operating systems.) Apple knows how to build an iPhone: if they wanted to lock down a Mac they would have simply done that. There's something like nine page…

I guess I'm missing something then. The Asahi blog says "Apple’s boot tooling will only work with what it considers to be a “valid” macOS installation inside an APFS container." Sounds very adversarial to "the ability to boot an arbitrary OS."

It’s the difference between “there’s no published standards other than the reference implementation for some of the API” and “there’s no published standards and extremely monolithic reference implementation design coupled to proprietary blobs and considerable effort spent on signing/boot chain authentication to prevent third party implementations”. Apple is currently the former.

Re: Asahi Linux 7.1 Progress Report

#208

Post by xorcist »

nosioptar wrote: post #82
Grombobulous wrote: post #47

Earlier quoted context omitted.

I can’t see that being a bad thing considering that the kernel is mandatory software in the Linux world. You would want to have high standards for what gets added.

You should have high standards. Torvalds often crosses that line into outright toxicity. I've written a few kernel patches that I never tried to upstream for that reason.

Not very likely. It doesn't work that way. Linus usually don't respond to individual patches and hasn't for over 20 years.

A subsystem maintainer will pick up your patch if it is good, and they will deal with Linus for you. Most subsystems have their own mailing list because you need to visibility.

The process is described pretty well in Documentation/.

Re: Asahi Linux 7.1 Progress Report

#209

Post by LargoLasskhyfv »

throw0101d wrote: post #121
simonh wrote: post #88

Earlier quoted context omitted.

marcan addressed this early on in the project, arguing that Intel platforms including some of those advocated for by the FSF are less open and more at risk of upstream abuse in some very significant ways. https://news.ycombinator.com/item?id=29684585 For example intel systems (and Android) run resident supervisor code you can't get rid of, and that can do remotely initiated updates you have no control over. That's no…

> For example intel systems (and Android) run resident supervisor code you can't get rid of, and that can do remotely initiated updates you have no control over. That's not so on Apple silicon. The Oxide Computer folks wrote their own AMD boot loader and have an entire chain of trust and apparently (?) basically got rid of the supervisor code (Ring -2 and -3). They also have custom motherboards with third-party BMCs.…

> Could something similar be done on Intel?

Yes: https://duckduckgo.com/?q=%253Asite+phoronix.com+'Dasharo'

Re: Asahi Linux 7.1 Progress Report

#210

Post by GeekyBear »

zbentley wrote: post #206

> The firmware loaded by XNU is not verified by the CM3. It will begin executing from its reset vector when signalled, no matter what is actually there. What if we just… used our own firmware? Without taking away from the unutterably awesome achievement of writing custom firmware against a proprietary moving target, I worry about this one specifically. While Apple will hopefully continue the practice of not going out…

The firmware blobs (and the system files) for MacOS live on a read only partition that is digitally signed.
Post reply on HN