Live data from Hacker News

macOS extensions are moving away from the kernel

eclecticlight.co

121–130 of 149 posts

Re: macOS extensions are moving away from the kernel

#121

I've love to hear what this means for realtime multi-channel audio applications. Would someone close to this give us a summary, or recommend some resources for the only-barely-knowledgeable?

Regarding audio, I currently use some tools from Rogue Amoeba called SoundSource, Loopback, and Audio Hijack that allow users to redirect, record, and add effects to virtual audio devices and applications on the system. Currently, it's installed as a kernel extension, but I'm not sure if it will be possible for it to move to the new framework.

Looks like for at least one of their apps, other than jumping through some extra hoops they work on the M1 today: https://sixcolors.com/link/2020/11/rogue-amoebas-apps-update...

I know they are having a dialog with Apple about what's still lacking for them to do it the new "right way" but I think for now you sill have to basically do what Jason outlines.

Re: macOS extensions are moving away from the kernel

#122

To me, this sounds kinda like the following: - XNU was born from a fork of the Mach microkernel - When the microkernel hype simmered down due to them being way too slow for '90s machines, NeXT bolted on lots of chunks taken from BSD to speed up XNU - After 20+ years, computers are fast enough to run true microkernels, so Apple is bringing them back again So it's finally time for microkernels to shine again?

BSD was actually grafted into Mach early on, it wasn't something NeXT did.

Re: macOS extensions are moving away from the kernel

#123
post #119

Earlier quoted context omitted.

Apples been doing that for yeaaars, especially with mobile devices (not that that's news to you) Anecdote: I had an iPad pro I put in a drawer for a while. I had it synced to an apple account from my old job (used my corporate email for it). When I took it out after I moved jobs, it became permanently locked with no recourse because I didn't have access to the email anymore. And there was no way to factrory reset it,…

Device lock is hardly something unique to Apple devices. It's unfortunate you forgot to unlock it before you lost access to that email account, but all may not be lost - have you tried account recovery? https://support.apple.com/en-us/HT204921 For anyone else reading this - take heed. It's better to ensure you can recover before you need to. Apple provides multiple ways to ensure you have access to an important Apple…

This was around 2014, I wasn't aware of any of these recovery methods above. Even brought it to a genius bar and they said "tough luck". Trashed it shortly after because it was useless.

I'm just very used to holding a paper clip in a hole for a minute and getting to use a device fresh, I guess!

Re: macOS extensions are moving away from the kernel

#124
post #73

Earlier quoted context omitted.

You can definitely make snapshots on APFS. It also use checksums for filesystem integrity.

> You can definitely make snapshots on APFS. Apple can. I can’t. Making APFS snapshots requires special entitlements, which they’re not going to give me. > It also use checksums for filesystem integrity. It doesn’t check integrity of the actual data though. But I care about my data.

> Apple can. I can’t. Making APFS snapshots requires special entitlements, which they’re not going to give me.

What makes you think that? Carbon Copy Cloner does this, and is made by a small independent developer.

https://bombich.com/kb/ccc6/leveraging-snapshots-on-apfs-vol...

Re: macOS extensions are moving away from the kernel

#126

This article does a good job of explaining how kernel extensions worked under Intel and how they will work under M1, and the blessed replacement for kernel extensions by Apple under M1. What it's missing, and what I assume everyone's questions is: Are the capabilities of Apple's user-level APIs sufficient to replace most legitimate uses of kernel extensions?

> Are the capabilities of Apple's user-level APIs sufficient to replace most legitimate uses of kernel extensions? I would have trusted literally anyone else to do a good job at this. Apple's in the business of brokering power though, I see no reason why they'd be motivated to make those APIs as rich as kexts.

The whole reason for this change is to limit the damage drivers can do.

Because of that, nobody would be stupid enough to make those APIs (in the wide sense, as in “what kexts can do, not what they are supposed to do) as rich as kexts.

Re: macOS extensions are moving away from the kernel

#127

Earlier quoted context omitted.

> You can definitely make snapshots on APFS. Apple can. I can’t. Making APFS snapshots requires special entitlements, which they’re not going to give me. > It also use checksums for filesystem integrity. It doesn’t check integrity of the actual data though. But I care about my data.

> Apple can. I can’t. Making APFS snapshots requires special entitlements, which they’re not going to give me. What makes you think that? Carbon Copy Cloner does this, and is made by a small independent developer. https://bombich.com/kb/ccc6/leveraging-snapshots-on-apfs-vol...

They have managed to obtain the special entitlement.

Source: https://bombich.com/blog/2018/03/30/building-better-backups-...

They’re one of two apps in the world who have been granted the entitlement as far as I know. The other one is Time Machine.

Re: macOS extensions are moving away from the kernel

#128

Earlier quoted context omitted.

Upgrades suck, but at least MacOS leaves you alone if you choose not to update your OS. Windows shoves it down your throat... Do you have a blog or anything with write ups about your equipment? Would be very interested in hearing about your silicon upgrades once you get there.

>Do you have a blog or anything with write ups about your equipment? Would be very interested in hearing about your silicon upgrades once you get there. No blog. We don't even have a website as work has only ever arrived by word of mouth. I am not enamoured by studio blogs, generally. There's too much noise out there without my clumsy typehand adding to it. I keep abreast of technology and audio by furiously skimming…

I'm more interested in your tech upgrades and what snags you hit, I suppose on an IT level.

Re: macOS extensions are moving away from the kernel

#129

This article does a good job of explaining how kernel extensions worked under Intel and how they will work under M1, and the blessed replacement for kernel extensions by Apple under M1. What it's missing, and what I assume everyone's questions is: Are the capabilities of Apple's user-level APIs sufficient to replace most legitimate uses of kernel extensions?

"blessed" replacement Why did you use the word Blessed? I'm curious what made your brain choose that word instead of something neutral. Reminds me of "Walled garden" marketing speak instead of "Walled Prison". Edit- is there some sensitive nerve I hit?

>Why did you use the word Blessed?

It's a fairly common idiom when talking about platform APIs. Some APIs are "blessed" in that they are the APIs that they platform owners would like you to use and others they would like you to avoid. "Blessed" isn't wholly positive as it implies the platform plays favorites, and frequently the new blessed apis don't support all the old functionality.

Here is patio11 using the idiom 7 years ago:

https://news.ycombinator.com/item?id=7658396

It's not as nefarious as you are implying - I don't have an agenda, I've just been on HN for too long.

Re: macOS extensions are moving away from the kernel

#130
post #91

Earlier quoted context omitted.

I am quite sure that we have been other this several times in HN. The fact that they're no longer going to allow loading of 3rd party kernel modules (a pure political decision) does not a make a microkernel (which is an architectural style). The kernel is still going to be big and monolithic (it contains the entire BSD kernel in the same address space!), and they're still going to be loading Apple-authorized kernel m…

How is removing 3rd party kernel modules a “pure political decision”. Do you really believe there are no technical/security factors behind this choice?

What I mean is that it involves a policy setting, but little to no technical change. You cannot create a microkernel just because you declare 3rd party extensions to be banned. In order to classify yourself as a certain architecture you actually need that architecture first.
Post reply on HN