9 ms·

First off, what a level-headed friendly response from a developer who is clearly frustrated by Apple's bugs and policies. As someone who has had to support comm

by wscott 6y ago

First off, what a level-headed friendly response from a developer who is clearly frustrated by Apple's bugs and policies. As someone who has had to support commercial software this is not easy to do consistently. Second, this has significantly tempered my lusting over the new M1 macs. I think I can be content with my ThinkPad's running Linux.

rwmj 6y ago
This worries me for a similar reason - I get requests to port some software I wrote over to the Mac from time to time, and the new M1 Mac Mini is cheap enough that I might have bought one to do this development. But I'm not keen to spend any money or time on an ecosystem which might be closed down in the future.
- marcus_holmes 6y ago
  Aeah, how much more proprietary and strange are the Apple API's going to get? They'll have control over the entire vertical, and can put all kinds of undocumented crap right in the silicon.
  - wscott 6y ago
    even to the syscall level, like the MAP_JIT flag to mmap() https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-jit https://developer.apple.com/documentation/bundleresources/en... not optional and requires special app entitlements to enable. So you are not going to write portable code that has a JIT without apple-special code.
    - TwoBit 6y ago
      A JIT is a major potential source of malware enablement and thus a security consideration.
      - andrekandre 6y ago
        applogies if its an ignorant question but, if the os had proper access protections, even with a buffer overflow or other exploits to an app itself, how can that enable malware just by having a JIT?
        saagarjha 6y ago
        It cannot; Apple's security policy towards third-party JITs is misguided. Such a feature is useful if you are interested in providing defense-in-depth for a JIT that you have taken effort to secure and would like stronger, hardware-backed mitigations for. The API should really be opt-in for the apps that want it–the real consumers of it are going to Chrome and Firefox.
        lmm 6y ago
        JIT requires bypassing exploit mitigations e.g. W^X. JIT doesn't make an app that's already been subverted any more dangerous than it would otherwise be, but it makes it easier to exploit the app in the first place.
    - saagarjha 6y ago
      And that JIT has additional considerations on Apple silicon, where there is specific hardware that needs to be taken into account: https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon https://developer.apple.com/documentation/apple_silicon/port...
      - Klonoar 6y ago
        I ran into another quirk with MAP_JIT recently, but going the other direction in time. If you supported an older platform (High Sierra, which up until recently was... valid...), you would need to explicitly _not_ pass MAP_JIT into mmap there. It makes total sense once you find the bug, but it was also an easy one to overlook. Tracking that down was kind of annoying.
- sdflhasjd 6y ago
  I fell into the same trap a while back. Bought a mac, fixed some OSS I maintained (and I do note the documentation was quite crap "Well, Apple. I made it... despite your directions"), the next OS X update killed it again, gave up, sold the mac. Felt like an enourmous waste of money and time.
  - enriquto 6y ago
    > Felt like an enourmous waste of money and time. And it certainly was. But sometimes you have well-appreciated macOS users that you have not yet managed to convert out of it. In that case, instead of throwing away your money you can easily [0] install a Catalina vm inside linux or windows. With a quite small effort, you can readily check that your program compiles and runs on that shitty system. [0] https://github.com/myspaghetti/macos-virtualbox https://github.com/myspaghetti/macos-virtualbox
    - The_Colonel 6y ago
      Is it legal? I thought you can run MacOS only on Mac hardware.
      - enriquto 6y ago
        I don't see how such a thing might be illegal, but the current century never ceases to amaze me. In any case, it is just a (very popular) shell script that downloads a few publicly available files and runs them in a controlled environment. It does not harm anybody.
        m-p-3 6y ago
        It's technologically doable, but running MacOS on non-Apple hardware is against the ToS.
        enriquto 6y ago
        Is it? Anyhow, it does not mean that it is illegal, which was the original question. I guess most ToS are not enforceable in practice. The worst that may happen is that you "lose the warranty" of your macOS install and you cannot ask Apple for support. No big deal.
Ensorceled 6y ago
Yeah, I'm wondering if my next work computer will be something different after almost 20 years of working on NeXT/Mac OS X/MacOS because I'm not sure general development will continue to be viable on the M1s. Spent another weekend moving my wife over to a new Windows machine ... not interested in that environment.
- yourapostasy 6y ago
  I'm in the very fortunate position of being able to afford the luxury of running multiple laptops at the same time, and being relatively price-insensitive. I've supported and recommended Apple as long as I can, but they're repeating their core strategic mistakes when they were riding high in the Apple // era, and I've been to that rodeo before. This time, I'm getting off the bull before it gores me. Last time, I clung on like a limpet long past the time it made sense, and I'll pass that mantle to the younger generations who have the time and energy budgets to do so. Apple's core strategic weakness is being the dominant market participant for too long. It is as if hardwired into their corporate cultural DNA is the absolute need to be the underdog. Once they dominate for awhile, they start seeking out easy answers, and it takes strong leadership that demands finesse, class and taste in solutions to steer them past the answers within their immediate grasp, and uncomfortably reach for the ones that pleasingly engage customers. This starts with their relationships with partners, then developers, then customers, then it corrupts their products, in roughly that order within their overall ecosystem. We have another decade or two to go before it gets that bad, if it gets that bad (I really hope I'm wrong, their corporate culture otherwise from a customer perspective is highly desirable). I'm getting out while the getting is still good and migration paths are not quite so painful. Part of this is because the raw hardware capabilities of my dual-track alternative (Dell Precision 5500 fully tricked-out) are a quantum leap over Apple's offerings. I have simultaneously put up with non-Apple trackpads, keyboards and OS's on Wintel laptops I simultaneously carry (hazard of consulting) while my main daily driver is an Apple, so those don't faze me. There was a brief, glorious period in the 00's when Apple locked in users by being a superlative superset of delighting capabilities above Wintel gear that compelled users like me to share with those who asked me about my quirky non-enterprise choice in the enterprise consulting space, "I use a Mac because it is a very good mobile Unix slab", and they came away impressed and agreeing with the choice, "if only we had the money". As a consultant, I got a pass for having the money to make that choice. Mac laptops for a brief 2-3 years had the densest memory, mass storage and top-of-the-line mobile chipsets, making many light "server-like" tasks upon it feasible. I heavily leveraged those capabilities to run rings around other consultants, able to deliver results in a fraction of the time because while they were requisitioning servers, I was already coding, debugging and running tests. Haven't had that experience since. I'm hoping I can catch some of that fire again with a Lintel setup. The general lack of developer infrastructure discipline I see across the board is leading many corporate cloud environments to enshroud themselves with all sorts of cost containment approval procedures, and most of my clients have already lost the agility cloud promised. Better security postures within my clients' sites also makes it increasingly difficult to access my own cloud accounts. So my own development deck once again makes sense for my own specific use case.
macspoofing 6y ago
>from a developer who is clearly frustrated by Apple's bugs and policies. Are there any developers who aren't? >this has significantly tempered my lusting over the new M1 macs. What sad is that when it comes to locking down computing devices Apple really is the vanguard of where things are going.

by wscott 6y ago

rwmj 6y ago

This worries me for a similar reason - I get requests to port some software I wrote over to the Mac from time to time, and the new M1 Mac Mini is cheap enough that I might have bought one to do this development. But I'm not keen to spend any money or time on an ecosystem which might be closed down in the future.

marcus_holmes 6y ago
Aeah, how much more proprietary and strange are the Apple API's going to get? They'll have control over the entire vertical, and can put all kinds of undocumented crap right in the silicon.
- wscott 6y ago
  even to the syscall level, like the MAP_JIT flag to mmap() https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-jit https://developer.apple.com/documentation/bundleresources/en... not optional and requires special app entitlements to enable. So you are not going to write portable code that has a JIT without apple-special code.
  - TwoBit 6y ago
    A JIT is a major potential source of malware enablement and thus a security consideration.
    - andrekandre 6y ago
      applogies if its an ignorant question but, if the os had proper access protections, even with a buffer overflow or other exploits to an app itself, how can that enable malware just by having a JIT?
      - saagarjha 6y ago
        It cannot; Apple's security policy towards third-party JITs is misguided. Such a feature is useful if you are interested in providing defense-in-depth for a JIT that you have taken effort to secure and would like stronger, hardware-backed mitigations for. The API should really be opt-in for the apps that want it–the real consumers of it are going to Chrome and Firefox.
      - lmm 6y ago
        JIT requires bypassing exploit mitigations e.g. W^X. JIT doesn't make an app that's already been subverted any more dangerous than it would otherwise be, but it makes it easier to exploit the app in the first place.
  - saagarjha 6y ago
    And that JIT has additional considerations on Apple silicon, where there is specific hardware that needs to be taken into account: https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon https://developer.apple.com/documentation/apple_silicon/port...
    - Klonoar 6y ago
      I ran into another quirk with MAP_JIT recently, but going the other direction in time. If you supported an older platform (High Sierra, which up until recently was... valid...), you would need to explicitly _not_ pass MAP_JIT into mmap there. It makes total sense once you find the bug, but it was also an easy one to overlook. Tracking that down was kind of annoying.
sdflhasjd 6y ago
I fell into the same trap a while back. Bought a mac, fixed some OSS I maintained (and I do note the documentation was quite crap "Well, Apple. I made it... despite your directions"), the next OS X update killed it again, gave up, sold the mac. Felt like an enourmous waste of money and time.
- enriquto 6y ago
  > Felt like an enourmous waste of money and time. And it certainly was. But sometimes you have well-appreciated macOS users that you have not yet managed to convert out of it. In that case, instead of throwing away your money you can easily [0] install a Catalina vm inside linux or windows. With a quite small effort, you can readily check that your program compiles and runs on that shitty system. [0] https://github.com/myspaghetti/macos-virtualbox https://github.com/myspaghetti/macos-virtualbox
  - The_Colonel 6y ago
    Is it legal? I thought you can run MacOS only on Mac hardware.
    - enriquto 6y ago
      I don't see how such a thing might be illegal, but the current century never ceases to amaze me. In any case, it is just a (very popular) shell script that downloads a few publicly available files and runs them in a controlled environment. It does not harm anybody.
      - m-p-3 6y ago
        It's technologically doable, but running MacOS on non-Apple hardware is against the ToS.
        enriquto 6y ago
        Is it? Anyhow, it does not mean that it is illegal, which was the original question. I guess most ToS are not enforceable in practice. The worst that may happen is that you "lose the warranty" of your macOS install and you cannot ask Apple for support. No big deal.

Ensorceled 6y ago

Yeah, I'm wondering if my next work computer will be something different after almost 20 years of working on NeXT/Mac OS X/MacOS because I'm not sure general development will continue to be viable on the M1s. Spent another weekend moving my wife over to a new Windows machine ... not interested in that environment.

yourapostasy 6y ago
I'm in the very fortunate position of being able to afford the luxury of running multiple laptops at the same time, and being relatively price-insensitive. I've supported and recommended Apple as long as I can, but they're repeating their core strategic mistakes when they were riding high in the Apple // era, and I've been to that rodeo before. This time, I'm getting off the bull before it gores me. Last time, I clung on like a limpet long past the time it made sense, and I'll pass that mantle to the younger generations who have the time and energy budgets to do so. Apple's core strategic weakness is being the dominant market participant for too long. It is as if hardwired into their corporate cultural DNA is the absolute need to be the underdog. Once they dominate for awhile, they start seeking out easy answers, and it takes strong leadership that demands finesse, class and taste in solutions to steer them past the answers within their immediate grasp, and uncomfortably reach for the ones that pleasingly engage customers. This starts with their relationships with partners, then developers, then customers, then it corrupts their products, in roughly that order within their overall ecosystem. We have another decade or two to go before it gets that bad, if it gets that bad (I really hope I'm wrong, their corporate culture otherwise from a customer perspective is highly desirable). I'm getting out while the getting is still good and migration paths are not quite so painful. Part of this is because the raw hardware capabilities of my dual-track alternative (Dell Precision 5500 fully tricked-out) are a quantum leap over Apple's offerings. I have simultaneously put up with non-Apple trackpads, keyboards and OS's on Wintel laptops I simultaneously carry (hazard of consulting) while my main daily driver is an Apple, so those don't faze me. There was a brief, glorious period in the 00's when Apple locked in users by being a superlative superset of delighting capabilities above Wintel gear that compelled users like me to share with those who asked me about my quirky non-enterprise choice in the enterprise consulting space, "I use a Mac because it is a very good mobile Unix slab", and they came away impressed and agreeing with the choice, "if only we had the money". As a consultant, I got a pass for having the money to make that choice. Mac laptops for a brief 2-3 years had the densest memory, mass storage and top-of-the-line mobile chipsets, making many light "server-like" tasks upon it feasible. I heavily leveraged those capabilities to run rings around other consultants, able to deliver results in a fraction of the time because while they were requisitioning servers, I was already coding, debugging and running tests. Haven't had that experience since. I'm hoping I can catch some of that fire again with a Lintel setup. The general lack of developer infrastructure discipline I see across the board is leading many corporate cloud environments to enshroud themselves with all sorts of cost containment approval procedures, and most of my clients have already lost the agility cloud promised. Better security postures within my clients' sites also makes it increasingly difficult to access my own cloud accounts. So my own development deck once again makes sense for my own specific use case.

macspoofing 6y ago

>from a developer who is clearly frustrated by Apple's bugs and policies. Are there any developers who aren't? >this has significantly tempered my lusting over the new M1 macs. What sad is that when it comes to locking down computing devices Apple really is the vanguard of where things are going.