4 ms·

>That one is 90% gone Citation needed...? Everything you've listed still works and works very well on macOS.

imachine1980_ 5y ago
apple revenue 2009 $42.7 billion mac revenue 2009 $13.6 billion(30%) apple ""2014 $182.6 billion service""2014 $17.8 billion(%9.8) mac "" 2014 $23.9 billion(13%) apple "" 2020 $274.3 billion service "" 2020 $53.6 billion (19%) mac "" 2020 $28.4 billion(10%) edit"Spanish" from key product to small fish, now sell service to your mac is mor key than selling the mac itself and ipad pro whit magic keyboard is mor expensive than the mac air.
AnthonyMouse 5y ago
Twenty years ago, the Mac version of Photoshop was just better than the Windows version. That hasn't been true in a while. And then you don't have to choose between a Mini which doesn't have enough cores, an iMac which tops out at a 27" monitor when you can get a PC with a 32" monitor (or a 40" or 80" or 17" or whatever you want), or a Mac Pro which starts at $6000. Developers used to prefer Mac because it was Unix when the UI on every other Unix-like was bad. Now the UI on Linux is better than it used to be, and Windows has WSL et al, and Mac is full of "pay for a license annually and deal with code signing nonsense" that developers hate.
- Klonoar 5y ago
  >Twenty years ago, the Mac version of Photoshop was just better than the Windows version. That hasn't been true in a while. I've used both (PS on macOS/Windows) recently and find them to be more or less equivalent. Given the choice of using macOS or Windows, I'd still take macOS. Not sure what the point of your line re: hardware is when a standard M1 Mini runs very well for this use case. If you want a bigger monitor... just buy the bigger monitor with a Mini. >Now the UI on Linux is better than it used to be I ran Desktop Linux for years before going macOS, and I check in periodically. I remain unimpressed, it's still a jumbled mess of an ecosystem. UI is also not the stumbling block to Linux adoption - hardware support alone, while better, still isn't up to what you get with the big two. >and Windows has WSL et al This is a fair point, and was an incredibly smart thing for MSFT to do. >and Mac is full of "pay for a license annually and deal with code signing nonsense" that developers hate. Have you ever code signed anything elsewhere, where you buy certs and such? It costs money. Apple's setup is a flat $100/year and "just works". This is also only if you're shipping software, you can run homebrew/etc just fine if you're doing dev work - there's tons of developers working on macOS who never pay Apple the $100/year for membership. Can you actually refute what I'm saying, which is that macOS is still very usable by developers? The OP I responded to originally is claiming that the macOS devs loved is "90% gone", but outside of HN/Reddit echo chambers I don't see people switching en-masse.
  - wahern 5y ago
    Apple's codesigning "just works" as long as you stick to XCode. Outside XCode it's extremely esoteric and opaque. But to Apple's credit, it can be done, and done using the native toolset. It took me awhile, but my relatively simple Makefile is building fat binaries (x86_64 + arm64), building and signing the application package, submitting the package for signing, and stapling certificates. Not monolithically--it's not a giant shell script posing as a Makefile. I have proper, correctly defined build dependencies for every real target up to `make submit`. So `make submit` will effectively build and submit a package both from a fresh checkout, as well as incrementally from an existing tree where only a few object files need rebuilding. But `make submit` and `make staple` themselves are .PHONY targets; they're not idempotent, but invoking them multiple times is still benign.
    - Klonoar 5y ago
      I implemented the codesigning and notarization process for Slippi, which is a Dolphin Emulator fork... based on CMake. I would not call it esoteric and/or opaque. It's one or two shell scripts and an API key through App Connect for the notarization pass.
      - wahern 5y ago
        It's certainly esoteric if you're trying to diagnose entitlement issues. It's all poorly documented. Some of the documentation on the Apple website is flat out wrong, for example recommendations on signing multiple separate binaries, each requiring an entitlement (spoiler: there's exactly one app id per package (EDIT: per bundle), and exactly one executable that can use that app id for entitlements, so the documentation was recommending a method of accomplishing something that is simply impossible, which explains why it never worked). Once you figure things out, it's not nearly as bad. The tools can work well. And that's hugely valuable. But documentation and consistency are significantly worse than common open source projects. And at least with open source you can also resort to looking at the code to figure things out. I find myself constantly doing that for Keychain, actually. Fortunately older versions of Apple's Security.framework are open source, which helps me diagnose and analyze API usage problems. Want to figure out how to retrieve the usage constraints (i.e. SecAccessControlCreateFlags) used to generate a T2 Secure Enclave private key? Or even simpler, want to figure out if its even possible to derive those constraints? Only the code is going to tell you.
- jacobolus 5y ago
  Twenty years ago was 2001: the days of Photoshop versions 6.5–7. The Mac (OS 9) and Windows (2000) versions were all but indistinguishable, and Apple had just released OS X which was still a slow and buggy mess, not yet used by creative professionals. If you said Photoshop 3.0 was clearly better on Mac System 7 than Windows 3.1 in 1994, you might have a point (that was before my time using Photoshop or Windows, so I can’t comment).

imachine1980_ 5y ago

apple revenue 2009 $42.7 billion mac revenue 2009 $13.6 billion(30%) apple ""2014 $182.6 billion service""2014 $17.8 billion(%9.8) mac "" 2014 $23.9 billion(13%) apple "" 2020 $274.3 billion service "" 2020 $53.6 billion (19%) mac "" 2020 $28.4 billion(10%) edit"Spanish" from key product to small fish, now sell service to your mac is mor key than selling the mac itself and ipad pro whit magic keyboard is mor expensive than the mac air.

AnthonyMouse 5y ago

Twenty years ago, the Mac version of Photoshop was just better than the Windows version. That hasn't been true in a while. And then you don't have to choose between a Mini which doesn't have enough cores, an iMac which tops out at a 27" monitor when you can get a PC with a 32" monitor (or a 40" or 80" or 17" or whatever you want), or a Mac Pro which starts at $6000. Developers used to prefer Mac because it was Unix when the UI on every other Unix-like was bad. Now the UI on Linux is better than it used to be, and Windows has WSL et al, and Mac is full of "pay for a license annually and deal with code signing nonsense" that developers hate.

Klonoar 5y ago
>Twenty years ago, the Mac version of Photoshop was just better than the Windows version. That hasn't been true in a while. I've used both (PS on macOS/Windows) recently and find them to be more or less equivalent. Given the choice of using macOS or Windows, I'd still take macOS. Not sure what the point of your line re: hardware is when a standard M1 Mini runs very well for this use case. If you want a bigger monitor... just buy the bigger monitor with a Mini. >Now the UI on Linux is better than it used to be I ran Desktop Linux for years before going macOS, and I check in periodically. I remain unimpressed, it's still a jumbled mess of an ecosystem. UI is also not the stumbling block to Linux adoption - hardware support alone, while better, still isn't up to what you get with the big two. >and Windows has WSL et al This is a fair point, and was an incredibly smart thing for MSFT to do. >and Mac is full of "pay for a license annually and deal with code signing nonsense" that developers hate. Have you ever code signed anything elsewhere, where you buy certs and such? It costs money. Apple's setup is a flat $100/year and "just works". This is also only if you're shipping software, you can run homebrew/etc just fine if you're doing dev work - there's tons of developers working on macOS who never pay Apple the $100/year for membership. Can you actually refute what I'm saying, which is that macOS is still very usable by developers? The OP I responded to originally is claiming that the macOS devs loved is "90% gone", but outside of HN/Reddit echo chambers I don't see people switching en-masse.
- wahern 5y ago
  Apple's codesigning "just works" as long as you stick to XCode. Outside XCode it's extremely esoteric and opaque. But to Apple's credit, it can be done, and done using the native toolset. It took me awhile, but my relatively simple Makefile is building fat binaries (x86_64 + arm64), building and signing the application package, submitting the package for signing, and stapling certificates. Not monolithically--it's not a giant shell script posing as a Makefile. I have proper, correctly defined build dependencies for every real target up to `make submit`. So `make submit` will effectively build and submit a package both from a fresh checkout, as well as incrementally from an existing tree where only a few object files need rebuilding. But `make submit` and `make staple` themselves are .PHONY targets; they're not idempotent, but invoking them multiple times is still benign.
  - Klonoar 5y ago
    I implemented the codesigning and notarization process for Slippi, which is a Dolphin Emulator fork... based on CMake. I would not call it esoteric and/or opaque. It's one or two shell scripts and an API key through App Connect for the notarization pass.
    - wahern 5y ago
      It's certainly esoteric if you're trying to diagnose entitlement issues. It's all poorly documented. Some of the documentation on the Apple website is flat out wrong, for example recommendations on signing multiple separate binaries, each requiring an entitlement (spoiler: there's exactly one app id per package (EDIT: per bundle), and exactly one executable that can use that app id for entitlements, so the documentation was recommending a method of accomplishing something that is simply impossible, which explains why it never worked). Once you figure things out, it's not nearly as bad. The tools can work well. And that's hugely valuable. But documentation and consistency are significantly worse than common open source projects. And at least with open source you can also resort to looking at the code to figure things out. I find myself constantly doing that for Keychain, actually. Fortunately older versions of Apple's Security.framework are open source, which helps me diagnose and analyze API usage problems. Want to figure out how to retrieve the usage constraints (i.e. SecAccessControlCreateFlags) used to generate a T2 Secure Enclave private key? Or even simpler, want to figure out if its even possible to derive those constraints? Only the code is going to tell you.
jacobolus 5y ago
Twenty years ago was 2001: the days of Photoshop versions 6.5–7. The Mac (OS 9) and Windows (2000) versions were all but indistinguishable, and Apple had just released OS X which was still a slow and buggy mess, not yet used by creative professionals. If you said Photoshop 3.0 was clearly better on Mac System 7 than Windows 3.1 in 1994, you might have a point (that was before my time using Photoshop or Windows, so I can’t comment).