5 ms·

Making architectural changes to create a patch implies that they only prefer to work on the latest codebase. What you are describing is a lack of commitment to

Making architectural changes to create a patch implies that they only prefer to work on the latest codebase. What you are describing is a lack of commitment to long-term-support for older OS (in effect, planned obsolescence); so the head line is indeed accurate. Apple providing only partial support for older OSes can be quite meaningless depending on the security hole they decide to not fix "because it is too much work".

dagmx 4y ago
Your comment belies that you have never worked on kernel and system level infrastructure with mass deployment. You can't just patch an old kernel for all security flaws because you may break other things like how third party drivers interact with the kernel. That interaction itself may be the cause of a security flaw (and in fact is, which is why they're moving to user space kernels with DriverKit) How would you posit that you patch an architectural security hole that would break users setups if you were to backport it?
- webmobdev 4y ago
  You don't backport - you create a separate hacky patch for the older codebase that temporarily fixes the issue. (In fact, that's exactly what everyone does when a serious bug is found in a current version software that they know requires an architectural change for a long term fix). Ensuring compatibility without breaking stuffs (like Windows was once famous for) or long-term support for softwares is not a new concept. What you pointed out in your comments is how Apple prioritises its resource - it's perfectly reasonable to focus only on the latest version of codebase as that is obviously easier, and Apple's business model is built on that. That's the mindset / policy that certainly gives you the luxury to think in terms of changing the architecture to fix a bug the "right" way but at the expense of ignoring older codebases.
  - dagmx 4y ago
    You completely ignored my very salient and real example of where “separate hacky patches” can’t work.

dagmx 4y ago

Your comment belies that you have never worked on kernel and system level infrastructure with mass deployment. You can't just patch an old kernel for all security flaws because you may break other things like how third party drivers interact with the kernel. That interaction itself may be the cause of a security flaw (and in fact is, which is why they're moving to user space kernels with DriverKit) How would you posit that you patch an architectural security hole that would break users setups if you were to backport it?

webmobdev 4y ago
You don't backport - you create a separate hacky patch for the older codebase that temporarily fixes the issue. (In fact, that's exactly what everyone does when a serious bug is found in a current version software that they know requires an architectural change for a long term fix). Ensuring compatibility without breaking stuffs (like Windows was once famous for) or long-term support for softwares is not a new concept. What you pointed out in your comments is how Apple prioritises its resource - it's perfectly reasonable to focus only on the latest version of codebase as that is obviously easier, and Apple's business model is built on that. That's the mindset / policy that certainly gives you the luxury to think in terms of changing the architecture to fix a bug the "right" way but at the expense of ignoring older codebases.
- dagmx 4y ago
  You completely ignored my very salient and real example of where “separate hacky patches” can’t work.