5 ms·

I actually think the opposite is true. Typically customers choose MacOS over Windows (when price is no object). The features in the Darwin/XNU systems are certa

I actually think the opposite is true. Typically customers choose MacOS over Windows (when price is no object). The features in the Darwin/XNU systems are certainly very customer focused. Having said that anecdotally I think that while it could be said that developers enjoy having new capabilities rather it is more often the case than not that when old APIs are deprecated and new APIs are used to replace them (forcibly) developers end up upset (see: Metal replacing OpenGL on MacOS / 32-bit application deprecation on MacOS).

CharlesColeman 7y ago
> Typically customers choose MacOS over Windows (when price is no object). But when they do so, I think they do it in spite of the lax attitude towards compatibility, due to other factors. Chief among them is the higher prestige Apple products have, the fact that many basic users only use very few programs that are all under heavy development (e.g. browsers) that lessens the sting, and many regular users have become resigned to being abused by their technology providers. If you narrow the question down to one factor, we're going to break your stuff vs. we're going to do everything we can to keep your stuff working, I think most people would choose the latter
- ArcVRArthur 7y ago
  I think backward compatibility is a feature, and the lack of it can be considered an anti-feature as I mentioned in the article: > As nice as backward compatibility is from a user convenience perspective when this feature comes as a result of a static kernel Application Binary Interface this trade-off is essentially indistinguishable from increasing time-preference (or in other words declining concern for the future in comparison to the present). I would argue that users are not using the system due to the lack of backward compatibility, rather my contention would be that this feature comes at a cost that outweighs the benefit (also from the article): > This can be seen with a continuous layering of hacky fixes, sloppily 'bolted on' feature additions (built in such a way that new additions don't conflict with existing APIs), and unremovable remnants of abandoned code segments left in place purely to ensure that applications continue to run. These issues not only cause their own problems but, in aggregate, cause a huge creep in the number of lines of code in privileged memory. This does not grow the exploitability of a system linearly but rather it causes exploitability to grow exponentially due to the fact that by there being more code to exploit, malicious functionalities can be chained together and made more harmful.
gdxhyrd 7y ago
I am not upset because Metal replaced OpenGL. I actually like Metal's design. What I am upset about is the removal of a standard that worked well. Just don't allow OpenGL apps in the Store and that would be enough. Even worse, removal of 32-bit support in macOS. Now that's a extraordinarily bad move that confirms Apple does not care about enterprise nor gaming.
- NobodyNada 7y ago
  AFAIK OpenGL hasn't been removed, and isn't planned to be in the near future; it's just been deprecated. Apple isn't adopting new versions of OpenGL or Vulkan, but OpenGL code that used to run on macOS still runs on macOS.
  - gdxhyrd 7y ago
    OpenGL support has been abandoned by Apple years ago, not to mention being broken. The fact that it is now officially deprecated is just a warning from Apple to remove it soon without bad PR.
    - xenadu02 7y ago
      You are moving the goalposts. You stated: > What I am upset about is the removal of a standard that worked well That is not correct on either count: 1) OpenGL is a terrible fit for modern GPUs so I don't agree that it "worked well" 2) OpenGL was not removed anyway > OpenGL support has been abandoned That is not correct. Code continues to be written and maintained to keep OpenGL working on newer GPUs, both OpenGL ES on iOS GPUs, as well as OpenGL on mac GPUs. > The fact that it is now officially deprecated is just a warning from Apple to remove it soon without bad PR. macOS/iOS continue to support /many/ deprecated APIs, some of which have been deprecated for over a decade. Contrary to popular opinion, things are not removed just for fun. Things are removed when there is a sound security/technical reason, or when there is a high ongoing cost either to end users or the development process. The alternative is to be MS and never remove anything, and where any changes to observable behavior of the system (or even moving internal struct values around!) can cause breakage and so is not done or requires inserting hacks to preserve behavior. If you think that doesn't impact individual engineer's decision making process ... well I don't know what to tell you. It must be soul-crushing to know if you change an internal data structure from uint16_t to uint32_t some crappy app that depends on being able to poke around will break. Surely such policies encourage some developers to do even more such hacky things, knowing MS will take the blame and end up making sure you can keep getting away with it.
asveikau 7y ago
There is a lot of weird stuff in Darwin that makes me wonder... Why do they deprecate useful things at other layers and keep this clunky Mach thing? They could switch to FreeBSD or Linux and probably perform better. It is hard to take them seriously when they say they don't like to maintain creaky stuff when there is Mach...
- eschaton 7y ago
  Sounds like you don’t understand what Mach actually offers. Check out Amit Singh’s book.
  - asveikau 7y ago
    You might think I don't understand, but I do know about kernel development and yes, the IPC is pretty unique for instance. But it can be recreated with Unix domain sockets and what have you, in exchange for a kernel with more active work going on, not just by a single entity, more wood and arrows behind it so to speak. And mach is dated, from the microkernel experimentation era of the 80s and 90s, with a lot of overhead of its own. The fact remains that Linux outperforms macOS on the same hardware. Yes I have run comparisons.
    - yjftsjthsd-h 7y ago
      > But it can be recreated with Unix domain sockets and what have you Or, heck, they could port the IPC and anything else worth keeping. Even just building a private fork of FreeBSD with the Darwin personality grafted on top would be viable.
      - trasz 7y ago
        FWIW, the NextBSD folks did exactly that - they ported Mach IPC into the FreeBSD kernel.
    - CoolGuySteve 7y ago
      I think as core counts increase, in 5-10 years we’ll see operating systems that run solely on a dedicated low power core while the other processes run in tickless mode with a more topology aware scheduler and almost no context switching or core migration. This is already how game consoles and low latency systems work for the most part. At that point microservices might become more palatable since the context switching won’t damage the rest of the processes performance as much. And Linux’s performance advantage might dissipate as scheduling and cache pressure become less relevant.
eru 7y ago
Customers also choose Ferrari over Volkswagen, when price is no object.
pjmlp 7y ago
Only FOSS developers are upset with Metal, everyone else appreciates not having a clunky 3D API still based on C, and is already taking advantage of it on their 3D engine. Plus, regarding the theme being discussed here, the use of Metal is transparent when using SceneKit, SpriteKit, Core Graphics,....
- pcwalton 7y ago
  It is very much not the case that only open source developers prefer cross-platform standards to Metal and all the other vendor-specific APIs. I have to say that I don't know why you dismiss open source graphics stacks. Anyone who has worked with the open source Mesa knows it is a breath of fresh air compared to the proprietary Qualcomm drivers, Mali drivers, Apple OpenGL drivers, or (horrors) fglrx.
  - pjmlp 7y ago
    Then you don't go much to game developer conferences, watch GDC talks, or read game development related publications like EDGE or Develop.
    - pcwalton 7y ago
      It doesn't take much searching to find game developers saying the exact same things I'm saying: https://appleinsider.com/articles/18/06/05/some-game-developers-hint-at-abandoning-the-mac-if-apple-phases-out-opengl https://appleinsider.com/articles/18/06/05/some-game-develop... And I've spoken with the Unity engine developers, who say they still consider OpenGL ES 2 support essential. Sure, Unity uses Metal (and I use Metal) because Apple forces us to to get maximum performance, but does anyone really want to write both Vulkan and Metal? Valve wouldn't have acquired MoltenVK if they were really itching to write Metal!
      - pjmlp 7y ago
        A couple of indie developers it seems, not the group I was talking about. Valve is on the driving seat with Khronos regarding Vulkan.
littlestymaar 7y ago
> Typically customers choose MacOS over Windows Well, unless they want to play games or run any non-mac software … I don't know where you get your idea that customers prefer MacOS, but apart from some niche communities (designers, some subgroups of developers) this simply doesn't hold.

CharlesColeman 7y ago

> Typically customers choose MacOS over Windows (when price is no object). But when they do so, I think they do it in spite of the lax attitude towards compatibility, due to other factors. Chief among them is the higher prestige Apple products have, the fact that many basic users only use very few programs that are all under heavy development (e.g. browsers) that lessens the sting, and many regular users have become resigned to being abused by their technology providers. If you narrow the question down to one factor, we're going to break your stuff vs. we're going to do everything we can to keep your stuff working, I think most people would choose the latter

ArcVRArthur 7y ago
I think backward compatibility is a feature, and the lack of it can be considered an anti-feature as I mentioned in the article: > As nice as backward compatibility is from a user convenience perspective when this feature comes as a result of a static kernel Application Binary Interface this trade-off is essentially indistinguishable from increasing time-preference (or in other words declining concern for the future in comparison to the present). I would argue that users are not using the system due to the lack of backward compatibility, rather my contention would be that this feature comes at a cost that outweighs the benefit (also from the article): > This can be seen with a continuous layering of hacky fixes, sloppily 'bolted on' feature additions (built in such a way that new additions don't conflict with existing APIs), and unremovable remnants of abandoned code segments left in place purely to ensure that applications continue to run. These issues not only cause their own problems but, in aggregate, cause a huge creep in the number of lines of code in privileged memory. This does not grow the exploitability of a system linearly but rather it causes exploitability to grow exponentially due to the fact that by there being more code to exploit, malicious functionalities can be chained together and made more harmful.

gdxhyrd 7y ago

I am not upset because Metal replaced OpenGL. I actually like Metal's design. What I am upset about is the removal of a standard that worked well. Just don't allow OpenGL apps in the Store and that would be enough. Even worse, removal of 32-bit support in macOS. Now that's a extraordinarily bad move that confirms Apple does not care about enterprise nor gaming.

NobodyNada 7y ago
AFAIK OpenGL hasn't been removed, and isn't planned to be in the near future; it's just been deprecated. Apple isn't adopting new versions of OpenGL or Vulkan, but OpenGL code that used to run on macOS still runs on macOS.
- gdxhyrd 7y ago
  OpenGL support has been abandoned by Apple years ago, not to mention being broken. The fact that it is now officially deprecated is just a warning from Apple to remove it soon without bad PR.
  - xenadu02 7y ago
    You are moving the goalposts. You stated: > What I am upset about is the removal of a standard that worked well That is not correct on either count: 1) OpenGL is a terrible fit for modern GPUs so I don't agree that it "worked well" 2) OpenGL was not removed anyway > OpenGL support has been abandoned That is not correct. Code continues to be written and maintained to keep OpenGL working on newer GPUs, both OpenGL ES on iOS GPUs, as well as OpenGL on mac GPUs. > The fact that it is now officially deprecated is just a warning from Apple to remove it soon without bad PR. macOS/iOS continue to support /many/ deprecated APIs, some of which have been deprecated for over a decade. Contrary to popular opinion, things are not removed just for fun. Things are removed when there is a sound security/technical reason, or when there is a high ongoing cost either to end users or the development process. The alternative is to be MS and never remove anything, and where any changes to observable behavior of the system (or even moving internal struct values around!) can cause breakage and so is not done or requires inserting hacks to preserve behavior. If you think that doesn't impact individual engineer's decision making process ... well I don't know what to tell you. It must be soul-crushing to know if you change an internal data structure from uint16_t to uint32_t some crappy app that depends on being able to poke around will break. Surely such policies encourage some developers to do even more such hacky things, knowing MS will take the blame and end up making sure you can keep getting away with it.

asveikau 7y ago

There is a lot of weird stuff in Darwin that makes me wonder... Why do they deprecate useful things at other layers and keep this clunky Mach thing? They could switch to FreeBSD or Linux and probably perform better. It is hard to take them seriously when they say they don't like to maintain creaky stuff when there is Mach...

eschaton 7y ago
Sounds like you don’t understand what Mach actually offers. Check out Amit Singh’s book.
- asveikau 7y ago
  You might think I don't understand, but I do know about kernel development and yes, the IPC is pretty unique for instance. But it can be recreated with Unix domain sockets and what have you, in exchange for a kernel with more active work going on, not just by a single entity, more wood and arrows behind it so to speak. And mach is dated, from the microkernel experimentation era of the 80s and 90s, with a lot of overhead of its own. The fact remains that Linux outperforms macOS on the same hardware. Yes I have run comparisons.
  - yjftsjthsd-h 7y ago
    > But it can be recreated with Unix domain sockets and what have you Or, heck, they could port the IPC and anything else worth keeping. Even just building a private fork of FreeBSD with the Darwin personality grafted on top would be viable.
    - trasz 7y ago
      FWIW, the NextBSD folks did exactly that - they ported Mach IPC into the FreeBSD kernel.
  - CoolGuySteve 7y ago
    I think as core counts increase, in 5-10 years we’ll see operating systems that run solely on a dedicated low power core while the other processes run in tickless mode with a more topology aware scheduler and almost no context switching or core migration. This is already how game consoles and low latency systems work for the most part. At that point microservices might become more palatable since the context switching won’t damage the rest of the processes performance as much. And Linux’s performance advantage might dissipate as scheduling and cache pressure become less relevant.

eru 7y ago

Customers also choose Ferrari over Volkswagen, when price is no object.

pjmlp 7y ago

Only FOSS developers are upset with Metal, everyone else appreciates not having a clunky 3D API still based on C, and is already taking advantage of it on their 3D engine. Plus, regarding the theme being discussed here, the use of Metal is transparent when using SceneKit, SpriteKit, Core Graphics,....

pcwalton 7y ago
It is very much not the case that only open source developers prefer cross-platform standards to Metal and all the other vendor-specific APIs. I have to say that I don't know why you dismiss open source graphics stacks. Anyone who has worked with the open source Mesa knows it is a breath of fresh air compared to the proprietary Qualcomm drivers, Mali drivers, Apple OpenGL drivers, or (horrors) fglrx.
- pjmlp 7y ago
  Then you don't go much to game developer conferences, watch GDC talks, or read game development related publications like EDGE or Develop.
  - pcwalton 7y ago
    It doesn't take much searching to find game developers saying the exact same things I'm saying: https://appleinsider.com/articles/18/06/05/some-game-developers-hint-at-abandoning-the-mac-if-apple-phases-out-opengl https://appleinsider.com/articles/18/06/05/some-game-develop... And I've spoken with the Unity engine developers, who say they still consider OpenGL ES 2 support essential. Sure, Unity uses Metal (and I use Metal) because Apple forces us to to get maximum performance, but does anyone really want to write both Vulkan and Metal? Valve wouldn't have acquired MoltenVK if they were really itching to write Metal!
    - pjmlp 7y ago
      A couple of indie developers it seems, not the group I was talking about. Valve is on the driving seat with Khronos regarding Vulkan.

littlestymaar 7y ago

> Typically customers choose MacOS over Windows Well, unless they want to play games or run any non-mac software … I don't know where you get your idea that customers prefer MacOS, but apart from some niche communities (designers, some subgroups of developers) this simply doesn't hold.