4 ms·

> but your claim that third-party software worked fine without issues is factually incorrect. That's a misunderstanding of what I was trying to convey. To clar

> but your claim that third-party software worked fine without issues is factually incorrect. That's a misunderstanding of what I was trying to convey. To clarify - I was specifically talking about existing application firewalls and VM applications for macOS that use / used kernel extensions and already have a large userbase on macOS. Their popularity, and relative stability of the kernel extensions these applications used, is proof that Apple's black and white approach of "all non-Apple kernel extensions are bad" is rubbish. Especially when we consider how such a move is also anti-competitive and anti-consumer, and thus helps Apple's business. Forcing developers to make an expensive migration from their own tried-and-tested and stable codebase over which they have full control, to use Apple's OS API's is a developer hostile move. Even more so when you consider that a developer will now have to rely on Apple to fix bugs or add new features - which Apple may have no inclination to do so so if it feels it isn't aligned to their own business interest (thus anti-competitive). I personally have been using some of these applications that install custom kernel extension, and my macOS (3 versions of macOS over a period of a few years) has never crashed or become unstable because of them, so far. If an application that used a kernel extension made my system unstable or crashed it, I obviously wouldn't use it and will uninstall it. But completely taking away my choice as user to customise my OS with kernel extensions, and reducing my choices (as a customer) by taking away the ability of developers to offer a non-Apple custom software solution that is better is also obviously anti-consumer.

dwaite 4y ago
> Their popularity, and relative stability of the kernel extensions these applications used, is proof that Apple's black and white approach of "all non-Apple kernel extensions are bad" is rubbish. Thats not what they are saying though. They are saying, when we have official userspace API, we will remove access to the old kernelspace API. Thats not to say the kext is bad or evil. It is to say you won't be able to accomplish it in a kext using public api anymore. Were there badly written kexts before? Were there kexts with interactions? Were there kernel API and whole subsystems kept in for years because some popular enterprise product refused to update? Absolutely. I'll refrain from mentioning the one I had in mind which hit all three checkboxes.

dwaite 4y ago

> Their popularity, and relative stability of the kernel extensions these applications used, is proof that Apple's black and white approach of "all non-Apple kernel extensions are bad" is rubbish. Thats not what they are saying though. They are saying, when we have official userspace API, we will remove access to the old kernelspace API. Thats not to say the kext is bad or evil. It is to say you won't be able to accomplish it in a kext using public api anymore. Were there badly written kexts before? Were there kexts with interactions? Were there kernel API and whole subsystems kept in for years because some popular enterprise product refused to update? Absolutely. I'll refrain from mentioning the one I had in mind which hit all three checkboxes.