5 ms·

The processor doesn't matter to Apple because they don't mind fucking over their customers and their third party developers.

justinjlynn 9y ago
I doubt that story has changed much.
gaius 9y ago
It’s true that Apple fumbled 68k —> PPC as far as MPW went but it’s also true that creating fat binaries was a total non-issue with CodeWarrior. Apple had learnt from that mistake for PPC —> x86
- ghazak 9y ago
  The difference is that the x86 chips were so much faster than what they had for PPC, that they could still emulate it without customers feeling like they were going backwards.
macintux 9y ago
Apple spent a lot of effort with each transition trying to make it as smooth for customers as possible while still pushing forward with the new system. I have no doubt some customers were caused pain by the transitions, and some left the Apple world entirely, but characterizing them as being "fucked over" seems a bit over the top.
- macintux 9y ago
  (gaius is right, however: CodeWarrior saved Apple once, but they've clearly learned a lot with successive transitions.)
mankash666 9y ago
How does this fuck over customers or third party devs in anyways?
- MereInterest 9y ago
  If you are changing CPU architecture, you have three options with respect to backwards compatibility. 1) Old programs don't work, because it is a different CPU architecture. 2) Old programs work, but in a VM, so it can't take full advantage of the hardware. 3) Old programs must be recompiled to work on new architecture. The last one is the preferred option, but is only possible for open source software. If options 1 or 3 are taken for proprietary software, the customer needs to buy a new version of the software.
  - mankash666 9y ago
    You go through some mental gymnastics to make it seem like #3 is only possible for open source. Look - Apple or any other vendor isn't beholden to one CPU architecture. Such expectations breed monopolies - like Intel in PC CPUs. None of your arguments prove that Apple is fucking over customers or developers. If anything, this opens up the market for newer, more nimble companies that'll fill the gaps left by slow moving, irrelevant apps/software. Cheers
    - MereInterest 9y ago
      I'm looking at it from the point of view of the customer. If I don't have the source code, I cannot recompile the code, end of story. The company that sold the binary executable might recompile it for the new architecture, but they're probably not going to give the recompiled binary away for free. That is why I say that #3 is, for the user, only possible for open source. I agree that vendors are not beholden to a CPU architecture, but let's not pretend that switching is immediately beneficial to the user. What you call "opening up the market", I call adding unnecessary obsolescence to programs that chose not to add planned obsolescence in the first place. If anything, I would take this as further evidence that software should be sold as source code, because the utility of mere build artifacts can be taken away.
      - mankash666 9y ago
        You can conjure up fictitious reasons, but the manufacturer never guaranteed the buyer that future hardware versions would use the same CPU. Then there's your contrived reason to obtain source code - another bogus, non-sensical reason that'll never fly with devs. You always have the choice of staying with an older model, or better, using Linux on your custom hardware. Don't push your socialism/communism on one of the most capitalistic companies on Earth (Apple)
Moto7451 9y ago
That’s a popular line around here but it doesn’t line up with the reality. When they’ve done architecture changes in the past they’ve reached out to large developers for feedback before committing to the changes being made. The original very OpenStep like OS X did not ship en mass because it lacked a bridge library to support developers and Adobe and others cried foul. That’s how Carbon came about. When 64bit Carbon was shelved some 10 years ago, the “sky is falling” was proclaimed but Adobe came along for the ride and everything was fine. Are Technica did a great write up summarizing both the genesis and end of Carbon development [0] The PPC transition and Intel Transition both had emulators, fat binary support, and for the Intel transition, early access to developer hardware [1]. I’m not sure how much more you can ask of Apple. The current iOS simulator compiles to native Intel code and then builds for deployment use the appropriate CPU target. The tooling is mature and the execution know. Apple can certainly do better in a lot of areas, i.e. Swift examples that are either missing or are too old to compile. This is something they’re competent at. [0] https://arstechnica.com/staff/2008/04/rhapsody-and-blues/ https://arstechnica.com/staff/2008/04/rhapsody-and-blues/ [1] http://vintagemacmuseum.com/the-apple-developer-transition-system-a-trojan-horse-powermac/ http://vintagemacmuseum.com/the-apple-developer-transition-s...

justinjlynn 9y ago

I doubt that story has changed much.

gaius 9y ago

It’s true that Apple fumbled 68k —> PPC as far as MPW went but it’s also true that creating fat binaries was a total non-issue with CodeWarrior. Apple had learnt from that mistake for PPC —> x86

ghazak 9y ago
The difference is that the x86 chips were so much faster than what they had for PPC, that they could still emulate it without customers feeling like they were going backwards.

macintux 9y ago

Apple spent a lot of effort with each transition trying to make it as smooth for customers as possible while still pushing forward with the new system. I have no doubt some customers were caused pain by the transitions, and some left the Apple world entirely, but characterizing them as being "fucked over" seems a bit over the top.

macintux 9y ago
(gaius is right, however: CodeWarrior saved Apple once, but they've clearly learned a lot with successive transitions.)

mankash666 9y ago

How does this fuck over customers or third party devs in anyways?

MereInterest 9y ago
If you are changing CPU architecture, you have three options with respect to backwards compatibility. 1) Old programs don't work, because it is a different CPU architecture. 2) Old programs work, but in a VM, so it can't take full advantage of the hardware. 3) Old programs must be recompiled to work on new architecture. The last one is the preferred option, but is only possible for open source software. If options 1 or 3 are taken for proprietary software, the customer needs to buy a new version of the software.
- mankash666 9y ago
  You go through some mental gymnastics to make it seem like #3 is only possible for open source. Look - Apple or any other vendor isn't beholden to one CPU architecture. Such expectations breed monopolies - like Intel in PC CPUs. None of your arguments prove that Apple is fucking over customers or developers. If anything, this opens up the market for newer, more nimble companies that'll fill the gaps left by slow moving, irrelevant apps/software. Cheers
  - MereInterest 9y ago
    I'm looking at it from the point of view of the customer. If I don't have the source code, I cannot recompile the code, end of story. The company that sold the binary executable might recompile it for the new architecture, but they're probably not going to give the recompiled binary away for free. That is why I say that #3 is, for the user, only possible for open source. I agree that vendors are not beholden to a CPU architecture, but let's not pretend that switching is immediately beneficial to the user. What you call "opening up the market", I call adding unnecessary obsolescence to programs that chose not to add planned obsolescence in the first place. If anything, I would take this as further evidence that software should be sold as source code, because the utility of mere build artifacts can be taken away.
    - mankash666 9y ago
      You can conjure up fictitious reasons, but the manufacturer never guaranteed the buyer that future hardware versions would use the same CPU. Then there's your contrived reason to obtain source code - another bogus, non-sensical reason that'll never fly with devs. You always have the choice of staying with an older model, or better, using Linux on your custom hardware. Don't push your socialism/communism on one of the most capitalistic companies on Earth (Apple)

Moto7451 9y ago

That’s a popular line around here but it doesn’t line up with the reality. When they’ve done architecture changes in the past they’ve reached out to large developers for feedback before committing to the changes being made. The original very OpenStep like OS X did not ship en mass because it lacked a bridge library to support developers and Adobe and others cried foul. That’s how Carbon came about. When 64bit Carbon was shelved some 10 years ago, the “sky is falling” was proclaimed but Adobe came along for the ride and everything was fine. Are Technica did a great write up summarizing both the genesis and end of Carbon development [0] The PPC transition and Intel Transition both had emulators, fat binary support, and for the Intel transition, early access to developer hardware [1]. I’m not sure how much more you can ask of Apple. The current iOS simulator compiles to native Intel code and then builds for deployment use the appropriate CPU target. The tooling is mature and the execution know. Apple can certainly do better in a lot of areas, i.e. Swift examples that are either missing or are too old to compile. This is something they’re competent at. [0] https://arstechnica.com/staff/2008/04/rhapsody-and-blues/ https://arstechnica.com/staff/2008/04/rhapsody-and-blues/ [1] http://vintagemacmuseum.com/the-apple-developer-transition-system-a-trojan-horse-powermac/ http://vintagemacmuseum.com/the-apple-developer-transition-s...