3 ms·

> to a lesser extent Apples xenophobic posturing toward 3rd party developer control. Classic MacOS didn't even have a first-party IDE. Everything was third-par

by jen20 2y ago

> to a lesser extent Apples xenophobic posturing toward 3rd party developer control. Classic MacOS didn't even have a first-party IDE. Everything was third-party. > but you can guarantee it is an uphill battle to get anything deployed outside the Apple App store ecosystem build tree. It's hard to even parse this sentence, to be frank, but any possible reading of it is nuts. It's trivial to install Nix on macOS and have basically every package available to you. Same with Brew, though it's less nice that way.

Joel_Mckay 2y ago
It is OK, people wouldn't know what is missing if they never saw the alternative. "It's hard to even parse this sentence" Try to cross-compile something on modern MacOS, and handle the DRM signing on another platform. For example, you are still going to need an active Apple Developer account to run https://quasar.dev https://quasar.dev for MacOS/iOS targets, or users are going to incur a bit of hassle running your code. It is ok, most people have trouble understanding each other at first. =3
- samatman 2y ago
  > DRM signing In what world is code attestation Digital Rights Management? Is there even meaningful overlap between these two things?
  - Joel_Mckay 2y ago
    Indeed, App stores must sign the software on their platform to deploy, and offline binaries now require a valid registered Developer Account signed code in order to easily run. A bodged on ecosystem like Brew doesn't practically count here, as a signed-check block is functionally also preventing most users running unapproved code. It is marketed as a security feature, which is why it sounds odd to people inside the ecosystem. "Is there even meaningful overlap between these two things?" If one wants to target every platform, than people are ultimately forced to use a Mac with a Developer Account subscription. Accordingly, there is no practical guarantee your project will reach market (app store rejections are common)... or worse... some dimwit chooses a platform ecosystem specific language to really double-down on a bad investment. Hence, my opinion on the answer to the threads question: "Why did Borland ignore the Macintosh market?" Have a nice day =3
    - samatman 2y ago
      > App stores must sign the software on their platform to deploy This is true, or rather "developers must sign software in order to sell it on the App Store" is true, and I believe this is what you meant. That's attestation. It isn't DRM. > offline binaries now require a valid registered Developer Account signed code in order to easily run "Easily" here means one click. "Not easily", then, is three clicks. The dialog boxes tell you exactly what to do. This is needed the first time you open a program, after which it just opens. > A bodged on ecosystem like Brew doesn't practically count here Why don't Homebrew, Mac Ports, and Nix, count here? Practically, I mean. > as a signed-check block is functionally also preventing most users running unapproved code This just isn't true though, it isn't even in the same neighborhood as the truth. Most users are, in fact, able to: read a dialog which says "go to Privacy and Security", go to Privacy and Security, and click the button which lets them run unsigned code. > forced to use a Mac with a Developer Account subscription Yes, it's true, you do need to have a Mac (or borrow one, cloud code signing does exist) and pay $99 a month, to sign code. Or you can just release it. Weren't we talking about Digital Rights Management? I thought you were going to explain how code attestation is DRM. I haven't seen you do that yet, did you want to? > there is no practical guarantee your project will reach market (app store rejections are common) You can just sell software for the Mac. The App Store is completely optional. The checks involved in the attestation process are quite minimal and focus on whether your program is malware. Failing that, you can sell your mal^H^H^H software directly, and users will have to endure three clicks, instead of one, to open it for the first time.
      - Joel_Mckay 2y ago
        >That's attestation. It isn't DRM. True, but only if the validation code is vulnerable to an unpatchable vulnerability discovered in Apple M1, M2 and M3 chips. Otherwise your hardware, drivers, and or software likely still needs approved by Apple. "> Why don't Homebrew, Mac Ports, and Nix, count here? Practically, I mean." Generally, most users will never touch CLI, and the ones that do often know how to deal with nag-ware in the OS. "This just isn't true though, " Right, you try to publish some kernel level driver that touches the hardware signatures. These modern machines will usually brick into a lock-screen on most platforms now. Thus, no one will be developing 3rd party hardware/drivers/Software/Firmware inside that box. You must pay Apple to play... even to replace many broken components. "> The checks involved in the attestation process are quite minimal and focus on whether your program is malware" Or running something Apple doesn't want, like another store ecosystem ( https://en.wikipedia.org/wiki/Epic_Games_v._Apple https://en.wikipedia.org/wiki/Epic_Games_v._Apple ). Arguably, modern Win11 and MacOS are already technically Malware collecting user telemetry, content, and metadata... in my opinion they arrive broken out of the box. Perhaps you are arguing some corporation is ethically superior to regular thieves. =3
pjmlp 2y ago
Object Pascal and MPW had something, but Metrowerks was clearly much better.
- Joel_Mckay 2y ago
  CodeWarrior was mainly popular for PalmOS, but had numerous targets. It was a standard prior to the gcc getting mainstream recognition. =3
  - pjmlp 2y ago
    Not much of a standard on PC, other than being the way to produce Palm, Epoch and Symbian apps, until Nokia replaced it with Eclipse based tooling, Carbide.
    - Joel_Mckay 2y ago
      Metrowerks stuck around a long time in the embedded space. Eclipse was more of a phenomena in the Java/OO paradigm, but was often slow on older platforms. Still, many folks embraced the open ecosystem when it became popular. Symbian was 10 years ahead of their time, and brought a lot of new paradigms to mobile. Leaving the master signing key on a reset device was a teachable moment for most folks. =3

by jen20 2y ago

Joel_Mckay 2y ago

It is OK, people wouldn't know what is missing if they never saw the alternative. "It's hard to even parse this sentence" Try to cross-compile something on modern MacOS, and handle the DRM signing on another platform. For example, you are still going to need an active Apple Developer account to run https://quasar.dev https://quasar.dev for MacOS/iOS targets, or users are going to incur a bit of hassle running your code. It is ok, most people have trouble understanding each other at first. =3

samatman 2y ago
> DRM signing In what world is code attestation Digital Rights Management? Is there even meaningful overlap between these two things?
- Joel_Mckay 2y ago
  Indeed, App stores must sign the software on their platform to deploy, and offline binaries now require a valid registered Developer Account signed code in order to easily run. A bodged on ecosystem like Brew doesn't practically count here, as a signed-check block is functionally also preventing most users running unapproved code. It is marketed as a security feature, which is why it sounds odd to people inside the ecosystem. "Is there even meaningful overlap between these two things?" If one wants to target every platform, than people are ultimately forced to use a Mac with a Developer Account subscription. Accordingly, there is no practical guarantee your project will reach market (app store rejections are common)... or worse... some dimwit chooses a platform ecosystem specific language to really double-down on a bad investment. Hence, my opinion on the answer to the threads question: "Why did Borland ignore the Macintosh market?" Have a nice day =3
  - samatman 2y ago
    > App stores must sign the software on their platform to deploy This is true, or rather "developers must sign software in order to sell it on the App Store" is true, and I believe this is what you meant. That's attestation. It isn't DRM. > offline binaries now require a valid registered Developer Account signed code in order to easily run "Easily" here means one click. "Not easily", then, is three clicks. The dialog boxes tell you exactly what to do. This is needed the first time you open a program, after which it just opens. > A bodged on ecosystem like Brew doesn't practically count here Why don't Homebrew, Mac Ports, and Nix, count here? Practically, I mean. > as a signed-check block is functionally also preventing most users running unapproved code This just isn't true though, it isn't even in the same neighborhood as the truth. Most users are, in fact, able to: read a dialog which says "go to Privacy and Security", go to Privacy and Security, and click the button which lets them run unsigned code. > forced to use a Mac with a Developer Account subscription Yes, it's true, you do need to have a Mac (or borrow one, cloud code signing does exist) and pay $99 a month, to sign code. Or you can just release it. Weren't we talking about Digital Rights Management? I thought you were going to explain how code attestation is DRM. I haven't seen you do that yet, did you want to? > there is no practical guarantee your project will reach market (app store rejections are common) You can just sell software for the Mac. The App Store is completely optional. The checks involved in the attestation process are quite minimal and focus on whether your program is malware. Failing that, you can sell your mal^H^H^H software directly, and users will have to endure three clicks, instead of one, to open it for the first time.
    - Joel_Mckay 2y ago
      >That's attestation. It isn't DRM. True, but only if the validation code is vulnerable to an unpatchable vulnerability discovered in Apple M1, M2 and M3 chips. Otherwise your hardware, drivers, and or software likely still needs approved by Apple. "> Why don't Homebrew, Mac Ports, and Nix, count here? Practically, I mean." Generally, most users will never touch CLI, and the ones that do often know how to deal with nag-ware in the OS. "This just isn't true though, " Right, you try to publish some kernel level driver that touches the hardware signatures. These modern machines will usually brick into a lock-screen on most platforms now. Thus, no one will be developing 3rd party hardware/drivers/Software/Firmware inside that box. You must pay Apple to play... even to replace many broken components. "> The checks involved in the attestation process are quite minimal and focus on whether your program is malware" Or running something Apple doesn't want, like another store ecosystem ( https://en.wikipedia.org/wiki/Epic_Games_v._Apple https://en.wikipedia.org/wiki/Epic_Games_v._Apple ). Arguably, modern Win11 and MacOS are already technically Malware collecting user telemetry, content, and metadata... in my opinion they arrive broken out of the box. Perhaps you are arguing some corporation is ethically superior to regular thieves. =3

pjmlp 2y ago

Object Pascal and MPW had something, but Metrowerks was clearly much better.

Joel_Mckay 2y ago
CodeWarrior was mainly popular for PalmOS, but had numerous targets. It was a standard prior to the gcc getting mainstream recognition. =3
- pjmlp 2y ago
  Not much of a standard on PC, other than being the way to produce Palm, Epoch and Symbian apps, until Nokia replaced it with Eclipse based tooling, Carbide.
  - Joel_Mckay 2y ago
    Metrowerks stuck around a long time in the embedded space. Eclipse was more of a phenomena in the Java/OO paradigm, but was often slow on older platforms. Still, many folks embraced the open ecosystem when it became popular. Symbian was 10 years ahead of their time, and brought a lot of new paradigms to mobile. Leaving the master signing key on a reset device was a teachable moment for most folks. =3