6 ms·

It's not "scare quotes" - it's to convey sarcasm and justified scepticism. Sure, poorly coded third party kernel extensions can have security and / or stability

It's not "scare quotes" - it's to convey sarcasm and justified scepticism. Sure, poorly coded third party kernel extensions can have security and / or stability issue. That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. In fact, in the past most of the popular application firewalls (and VM softwares) on macOS came with their own kernel extensions and have worked fine without issues, and millions of users have used such applications without any issues. Now that Apple is forcing macOS developers to use their APIs, these software developers are at the mercy of Apple which is exactly what Apple wants - they will now be forced to negotiate with Apple for any changes or new features they want. Apple can now cripple a system developers ability to provide the kind of system software they want to offer to user. End result is that Mac users and developers both lose.

coldtea 4y ago
>It's not "scare quotes" - it's to convey sarcasm and justified scepticism. Sure, poorly coded third party kernel extensions can have security and / or stability issue. That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. They don't have to be "the only one who knows how to write such bug-free or secure system software". They just have to disallow a class of potentialy buggy and insecure software running with kernel level access, and that's enough to keep tons of additional attack vectors off the OS. I'd rather trust just Apple on kernel-space (which I have to anyway, as they make the kernel), than Apple + any random third party software that wants to run as a kernel extension.
- webmobdev 4y ago
  > I'd rather trust just Apple on kernel-space (which I have to anyway, as they make the kernel), than Apple + any random third party software that wants to run as a kernel extension. Which is all ok till you consider that experienced developers that make good system software can offer better software than Apple, which often may have no incentive to support softwares that isn't aligned with their business interest. Application firewalls is an example, because they can also prevent Apple software and services from data-mining a users personal data. (You may trust the Apple codebase on which all Application firewalls on macOS are forced to run, but what if I don't and want alternative? And if you say, "Then don't use macOS", note that's a very anti-consumer view and is toss to everyone's consumer rights). Virtualisation is another example where non-Apple options can be better than Apple's as Apple would prefer that you do everything on their OS than use alternate ones. Or when you don't want to use Apple software because of the terms you have to accept to use it.
  - coldtea 4y ago
    >and if you say, "Then don't use macOS", note that's a very anti-consumer view Not much more "anti-consumer" than "if you prefer formal attire, then just don't buy Levi's - as opposed to insist the make black suits and bow ties". Though I understand the convenience - I'd like to have the option myself in some cases. What I dont like is third party companies forcing you to install a kext if you want to use their product, for non essential reasons (that could be handled in userland). At least this forces them to work with userland APIs (looking at the "haxie" peddlers out there).
mbreese 4y ago
This isn’t the way Apple wanted it to work. In a perfect world vendors would write good kernel extensions that were stable and wouldn’t crash a system. Instead, in the real world we got vendors that wrote horrible and unstable code that was required by IT departments. For example, instead of implementing a firewall using Apple technologies, in a stable manner, we got an “enterprise” firewall kext that would crash whenever a USB network card was plugged in. And I mean crash the computer. My USB-C dock was absolutely worthless because of this exact issue. Vendors forced this on Apple. IT departments that were primarily Windows shops would just blame Apple instead of the vendor. Because their software worked for Windows, so why was it only a problem for Apple? I know the IT department at my $WORK had this mentality. Now at least I have a stable system and I don’t miss not being able to add my own kexts.
- webmobdev 4y ago
  There are also examples of popular applications with kernel extensions that have been used by thousands / millions of users without any issue for years now on various macOS versions. Why should such system developers be punished with an inferior alternative, especially when it also serves Apple's interest by being anti-competitive too!?
saagarjha 4y ago
> That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. In fact, in the past most of the popular application firewalls (and VM softwares) on macOS came with their own kernel extensions and have worked fine without issues, and millions of users have used such applications without any issues. Apple definitely cannot write bug-free code, but your claim that third-party software worked fine without issues is factually incorrect. Third party kernel extensions have historically been a major source of instability and crashes.
- webmobdev 4y ago
  > 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.

coldtea 4y ago

>It's not "scare quotes" - it's to convey sarcasm and justified scepticism. Sure, poorly coded third party kernel extensions can have security and / or stability issue. That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. They don't have to be "the only one who knows how to write such bug-free or secure system software". They just have to disallow a class of potentialy buggy and insecure software running with kernel level access, and that's enough to keep tons of additional attack vectors off the OS. I'd rather trust just Apple on kernel-space (which I have to anyway, as they make the kernel), than Apple + any random third party software that wants to run as a kernel extension.

webmobdev 4y ago
> I'd rather trust just Apple on kernel-space (which I have to anyway, as they make the kernel), than Apple + any random third party software that wants to run as a kernel extension. Which is all ok till you consider that experienced developers that make good system software can offer better software than Apple, which often may have no incentive to support softwares that isn't aligned with their business interest. Application firewalls is an example, because they can also prevent Apple software and services from data-mining a users personal data. (You may trust the Apple codebase on which all Application firewalls on macOS are forced to run, but what if I don't and want alternative? And if you say, "Then don't use macOS", note that's a very anti-consumer view and is toss to everyone's consumer rights). Virtualisation is another example where non-Apple options can be better than Apple's as Apple would prefer that you do everything on their OS than use alternate ones. Or when you don't want to use Apple software because of the terms you have to accept to use it.
- coldtea 4y ago
  >and if you say, "Then don't use macOS", note that's a very anti-consumer view Not much more "anti-consumer" than "if you prefer formal attire, then just don't buy Levi's - as opposed to insist the make black suits and bow ties". Though I understand the convenience - I'd like to have the option myself in some cases. What I dont like is third party companies forcing you to install a kext if you want to use their product, for non essential reasons (that could be handled in userland). At least this forces them to work with userland APIs (looking at the "haxie" peddlers out there).

mbreese 4y ago

This isn’t the way Apple wanted it to work. In a perfect world vendors would write good kernel extensions that were stable and wouldn’t crash a system. Instead, in the real world we got vendors that wrote horrible and unstable code that was required by IT departments. For example, instead of implementing a firewall using Apple technologies, in a stable manner, we got an “enterprise” firewall kext that would crash whenever a USB network card was plugged in. And I mean crash the computer. My USB-C dock was absolutely worthless because of this exact issue. Vendors forced this on Apple. IT departments that were primarily Windows shops would just blame Apple instead of the vendor. Because their software worked for Windows, so why was it only a problem for Apple? I know the IT department at my $WORK had this mentality. Now at least I have a stable system and I don’t miss not being able to add my own kexts.

webmobdev 4y ago
There are also examples of popular applications with kernel extensions that have been used by thousands / millions of users without any issue for years now on various macOS versions. Why should such system developers be punished with an inferior alternative, especially when it also serves Apple's interest by being anti-competitive too!?

saagarjha 4y ago

> That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. In fact, in the past most of the popular application firewalls (and VM softwares) on macOS came with their own kernel extensions and have worked fine without issues, and millions of users have used such applications without any issues. Apple definitely cannot write bug-free code, but your claim that third-party software worked fine without issues is factually incorrect. Third party kernel extensions have historically been a major source of instability and crashes.

webmobdev 4y ago
> 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.