Stop panicking about Apple's rumored switch from Intel to its own chips in the Mac

17891113

Comments

  • Reply 201 of 245
    melgrossmelgross Posts: 33,510member

    Soli said:
    melgross said:

    Soli said:
    melgross said:
    Soli said:
    melgross said:

    iqatedo said:
    Soli said:
    nunzy said:
    Will this be a step towards uniting iOS and OSX?
    That would be like uniting watchOS, tvOS, and iOS simply because they're all AArch64. Hell, even iOS for the iPhone and iPad are distinct UIs with different downloads despite  the I/O being almost identical. I don't see any future where iOS and macOS will be "united" into a single crappy OS. They will, however, continue to share code, which they've been doing since iOS was created despite the discrete architectures in play.
    Thank you Soli. 
    Aaand...I disagree. There is absolutely no reason to believe that it would result in a “crappy” OS.
    You honestly don't think unifying watchOS, tvOS, iOS for iPhone, iOS for iPad, podOS, macOS and every other OS X-based OS into a single, unfed download would not make for a crappy OS? What reason for the Apple Watch need to be weighted down with any code it doesn't need.

    I don't see that ever happening. We don't even have iOS for iPhone and iOS for iPad being unfied OS and those use nearly the same HW and code base. All of these OS X-based OSes will continue to share code as it suits each product but they will never be unified.
    Having all the same code isn’t what I’m saying. It’s just the opposite of what I’m saying. Right now, all of Apple’s OSs are based on the same Unix. Apple, as we know, strips out everything that isn’t needed for a particular device family. That eliminates a huge chunk of code, while allowing the base to remain the same. The biggest differences are the UI requirements, and the external interfaces. No massive printer or monitor databases inside an iPhone, iPad or Apple Watch. That’s hundreds of megabytes right there, even a gigabyte. 

    But the base code is the same, or similar enough. As far as I know, because I haven’t done this for some time, the main differentiation remains the UI differences. Resolve that, and you’re pretty much there. For the iPad, that would just require either a mouse interface, or the on screen trackpad I discussed earlier. Mostly, that would do it.

    but you’re assuming, I’m assuming (;~)) that this would all be a mess everywhere. It wouldn’t. I’m not suggesting a tiny keyboard on the Apple Watch.

    and I specifically stated that it would NOT be a unified download. Right now, Apple downloads what it needs for a specific device. Apple knows exactly what you’ve got in hardware, and which version of the OS you’re running. So if you buy an app for your iPhone, very often, if a developer has an iPad version, you get that one on your iPad. There is no unified code of both in one being imported to both devices. We know how this works, because Apple spelled it out a good two years ago. Apple has the capability to look at what you’ve got, and send only that code to you. Since they can do that already, I see no reason why that couldn’t also be done for a unified OS.

    and certainly, when it comes to Apple, don’t say never. Apple does change its mind. Remember what Jobs said that nobody wanted to watch video on a small iPod or phone, and then just a few months later, Apple was doing it? Also, he said that OS X was their next OS for “15 years”. Well, it’s past 15 years now. We don’t know what they’re doing other than not sitting on their hands. He also said, right before he came back to Apple, when asked, in an interview, what he would do with Apple if he was running it again, and he responded - “I’d milk the Mac for all it was worth, and then I’d go on the the next big thing.” That’s not the exact words, I don’t think, but you get the gist.
    That's not a unified OS. That's some basic sharing of code. If you want to talk about Darwin, then, yeah, that OS is pretty unified between all the Apple devices under  the OS X umbrella.
    Yes it is. If your concept that even the watch should run a full sized Photoshop for it to be a unified OS, then I think that you should think it out some more. Even for the Mac, there are some apps that simply won’t run on a Macbook that will run on higher end machines.
    I made no mention of apps. I'm strictly speaking about the OS. There's no reason I should be able to download a massive "Apple OS" and have it install on everything Apple makes and have it include only the frameworks, drivers, and UIs for that particular device. That's insane! If they haven't done it for watchOS, tvOS, and iOS then there's absolutely no reason for you to think that they'd do it for macOS simply because it now offers AArch64 support in a fat binary.
    I don't think you are reading @melgross' comments correctly.  As I understand it, he means that:

    1. Apple will package its diverse OSes (UIs,frameworks, etc.) into a single Package
    2. Instead having a mostly duplicate custom UIs,frameworks, etc. for each OS
    3. the UIs,frameworks, etc. are customizable to the devices and UOS version

    At development time the developer will select:

    1. the UOS version level he wants to support
    2. the devices he wants to support
    3. the app. features he wants to support
    4. the UIs,frameworks, etc. customize themselves (adding or removing code/capabilities) based on the UOS Version and Devices

    After testing, the Xcode IDE will build a single UDP (Universal Distribution Package) based upon the developer selections.  This will be uploaded to the Single App Store.

    At user download time, the UDP will customize what is downloaded based on the device and UOS version.


    This is a win-win:  The customer gets fast, efficient, potentially lower-cost and more sophisticated apps, smaller-size, more-reliable apps (and updates) -- the developer gets all the advantages of working/collaborating with a single code base.

    Finally, all this is already being done to some extent, e.g.:

    • Universal iOS Apps for iPhone and iPad
    • Applications with multiple targets for iOS and macOS
    • Apps with multiple schemas, e.g. watch and iPhone
    • Storyboards for multiple device UIs
    • Conditional statements within source code to add or remove code -- based on device, OS version, developer choices, etc.
    That’s exactly what I’m saying. But I don’t think he agrees anyway.
  • Reply 202 of 245
    dick applebaumdick applebaum Posts: 12,527member
    melgross said:

    Soli said:
    melgross said:

    Soli said:
    melgross said:
    Soli said:
    melgross said:

    iqatedo said:
    Soli said:
    nunzy said:
    Will this be a step towards uniting iOS and OSX?
    That would be like uniting watchOS, tvOS, and iOS simply because they're all AArch64. Hell, even iOS for the iPhone and iPad are distinct UIs with different downloads despite  the I/O being almost identical. I don't see any future where iOS and macOS will be "united" into a single crappy OS. They will, however, continue to share code, which they've been doing since iOS was created despite the discrete architectures in play.
    Thank you Soli. 
    Aaand...I disagree. There is absolutely no reason to believe that it would result in a “crappy” OS.
    You honestly don't think unifying watchOS, tvOS, iOS for iPhone, iOS for iPad, podOS, macOS and every other OS X-based OS into a single, unfed download would not make for a crappy OS? What reason for the Apple Watch need to be weighted down with any code it doesn't need.

    I don't see that ever happening. We don't even have iOS for iPhone and iOS for iPad being unfied OS and those use nearly the same HW and code base. All of these OS X-based OSes will continue to share code as it suits each product but they will never be unified.
    Having all the same code isn’t what I’m saying. It’s just the opposite of what I’m saying. Right now, all of Apple’s OSs are based on the same Unix. Apple, as we know, strips out everything that isn’t needed for a particular device family. That eliminates a huge chunk of code, while allowing the base to remain the same. The biggest differences are the UI requirements, and the external interfaces. No massive printer or monitor databases inside an iPhone, iPad or Apple Watch. That’s hundreds of megabytes right there, even a gigabyte. 

    But the base code is the same, or similar enough. As far as I know, because I haven’t done this for some time, the main differentiation remains the UI differences. Resolve that, and you’re pretty much there. For the iPad, that would just require either a mouse interface, or the on screen trackpad I discussed earlier. Mostly, that would do it.

    but you’re assuming, I’m assuming (;~)) that this would all be a mess everywhere. It wouldn’t. I’m not suggesting a tiny keyboard on the Apple Watch.

    and I specifically stated that it would NOT be a unified download. Right now, Apple downloads what it needs for a specific device. Apple knows exactly what you’ve got in hardware, and which version of the OS you’re running. So if you buy an app for your iPhone, very often, if a developer has an iPad version, you get that one on your iPad. There is no unified code of both in one being imported to both devices. We know how this works, because Apple spelled it out a good two years ago. Apple has the capability to look at what you’ve got, and send only that code to you. Since they can do that already, I see no reason why that couldn’t also be done for a unified OS.

    and certainly, when it comes to Apple, don’t say never. Apple does change its mind. Remember what Jobs said that nobody wanted to watch video on a small iPod or phone, and then just a few months later, Apple was doing it? Also, he said that OS X was their next OS for “15 years”. Well, it’s past 15 years now. We don’t know what they’re doing other than not sitting on their hands. He also said, right before he came back to Apple, when asked, in an interview, what he would do with Apple if he was running it again, and he responded - “I’d milk the Mac for all it was worth, and then I’d go on the the next big thing.” That’s not the exact words, I don’t think, but you get the gist.
    That's not a unified OS. That's some basic sharing of code. If you want to talk about Darwin, then, yeah, that OS is pretty unified between all the Apple devices under  the OS X umbrella.
    Yes it is. If your concept that even the watch should run a full sized Photoshop for it to be a unified OS, then I think that you should think it out some more. Even for the Mac, there are some apps that simply won’t run on a Macbook that will run on higher end machines.
    I made no mention of apps. I'm strictly speaking about the OS. There's no reason I should be able to download a massive "Apple OS" and have it install on everything Apple makes and have it include only the frameworks, drivers, and UIs for that particular device. That's insane! If they haven't done it for watchOS, tvOS, and iOS then there's absolutely no reason for you to think that they'd do it for macOS simply because it now offers AArch64 support in a fat binary.
    I don't think you are reading @melgross' comments correctly.  As I understand it, he means that:

    1. Apple will package its diverse OSes (UIs,frameworks, etc.) into a single Package
    2. Instead having a mostly duplicate custom UIs,frameworks, etc. for each OS
    3. the UIs,frameworks, etc. are customizable to the devices and UOS version

    At development time the developer will select:

    1. the UOS version level he wants to support
    2. the devices he wants to support
    3. the app. features he wants to support
    4. the UIs,frameworks, etc. customize themselves (adding or removing code/capabilities) based on the UOS Version and Devices

    After testing, the Xcode IDE will build a single UDP (Universal Distribution Package) based upon the developer selections.  This will be uploaded to the Single App Store.

    At user download time, the UDP will customize what is downloaded based on the device and UOS version.


    This is a win-win:  The customer gets fast, efficient, potentially lower-cost and more sophisticated apps, smaller-size, more-reliable apps (and updates) -- the developer gets all the advantages of working/collaborating with a single code base.

    Finally, all this is already being done to some extent, e.g.:

    • Universal iOS Apps for iPhone and iPad
    • Applications with multiple targets for iOS and macOS
    • Apps with multiple schemas, e.g. watch and iPhone
    • Storyboards for multiple device UIs
    • Conditional statements within source code to add or remove code -- based on device, OS version, developer choices, etc.
    That’s exactly what I’m saying. But I don’t think he agrees anyway.
    Ha!  I've had like disagreements with both you and @Soli in the past...  Let's all 3 just agree that 2 out of we 3 are hardheads... You pickem'
    edited April 2018
  • Reply 203 of 245
    dick applebaumdick applebaum Posts: 12,527member
    melgross said:

    That’s exactly what I’m saying. But I don’t think he agrees anyway.

    Reading back over your posts to this thread, I think you went even farther, by suggesting ways to customize the underlying Unix OS to gain additional advantages.
  • Reply 204 of 245
    SoliSoli Posts: 10,035member
    melgross said:
    There you go again, you’re not thinking about what I’m saying. Apple isn’t going to do that. Developers would have code that’s more modular. Apple would spell out what they expect them to do. Only that code required for a specific device would be downloaded. I’m saying that the UI is very I’m;oetant here, and so it is. But that means more than what you’re thinking. 

    Nobody would expect to do full full editing within Photoshop on their phone. Adobe could write this so that only those modules expected to be useful for that would be downloaded. That could be half the app, maybe more, or less. We already have games for out phones with core apps of over 150MB, with graphics adding almost another 1.5GB. So it’s not out of line to think that Photoshop for the phone could run between 100-200MB. Heck, Apple’s own software runs in the hundreds of megabytes now, on the iPad and iPhone. An example; Pages takes 462.4MB besides its data. Keynote takes 643.5MB besides its data. Even my Walgreens store app takes 156.1MB space.

    so what does the OS take in comparison and why should that change now? I don’t think it matters. Don’t say what Apple will do, people get in a lot of trouble doing that. I’m just suggesting what I think Apple would do if they do use a variation of their chips.
    If you're bringing up apps like photoshop then you're no longer taking about the OS. This is not a discussion about apps. Think only about the OS. Can you really ever imagine that the download for watchOS will be the same one as for macOS with the iPhone or Watch stripping out all the unneeded frameworks, UIs, drivers, and other code before the installation? Not in a million years do I see that ever being unified into that single piece of crap. Again, we will continue to have more shared code, just as we've had since the iPhone launched which was macOS stripped down and then built up for the HW and I/O and then more efficient frameworks and core services were then ported to macOS for a more efficient macOS. Even now, none of the OS X variants that have supported ARM from day one are unified, and they're a lot closer to each other than the Mac.

    edited April 2018
  • Reply 205 of 245
    melgrossmelgross Posts: 33,510member

    asdasd said:
    melgross said:

    Soli said:
    knowitall said:
    I keep wondering if it would make sense for a Mac (and macOS) to support configurations with:
    1. an ARM CPU and an Intel CPU
    2. multiple ARM CPUs
    3. multiple ARM CPUs and an Intel CPU
    Maybe it need not be all or nothing?
    I think it does. Including an Intel CPU defeats the purpose (getting rid of Intel).
    Why assume that Apple would be getting rid of Intel because they wanted to use an ARM-based Mac for, say, a new MacBook Air that was basically the 12" MacBook but running an Apple-designed chip? Do you really think there's an ARM-equivlenet that will work for the Mac Pro? I don't see the Pro-line being affected by this until such time as most people are instead bitching that Apple isn't moving fast enough to switch their high-end machines to to ARM.
    Prescient!
    Sure. If Apple can get the ARM chips to run x86 software natively, as I’m proposing, there is no way they could consider it for a high end machine. While some say that Apple could force its users and developers down that road again, I’m not so sure.

    whike users don’t care what in the machine, as long as it works, developers do. There are all too many ignorant people out there who believe the solution is to “just have it go through a recompile!” Sure, if you have a flashlight app, that will work. But no decently complex software will ever work properly, if at all, with “just” a recompile. It’s months of major work, at least, and mammoth amounts of money. Developers have to be taken off other projects, etc.

    having said that, desktop chips don’t have the power constraints mobile chips do. Even the Macbook Pro uses chips up to a 35 watt power draw. Compare that to the 6 watt draw of the A series for the iPad, or the M series of Intel chips for the Macbook. There’s plenty Apple could do just by going to 12 Watts. But at some point there’s a limit. As you go up the power scale, you actually have less options, because when you hit these power levels, you find that you’re competing with really high end chips. Right now, the A series can compete with the M series easily, and some other ultralow power Intel chips for mobile. But Desktop chips are different. Apple may still have an advantage, but by how much?
    It’s will be a recompile for pretty much everything that uses objective c, swift, even c or c++ code that compiles already in Xcode. What compiles for ARM or x86 now for iOS can work for the Mac in future. 
    It might, it might not, depending on how Apple handles it. Some code may not be doing things correctly, such as using pointers and memory locations they know Apple has told them not to. All that will change.
    edited April 2018
  • Reply 206 of 245
    melgrossmelgross Posts: 33,510member
    melgross said:

    That’s exactly what I’m saying. But I don’t think he agrees anyway.

    Reading back over your posts to this thread, I think you went even farther, by suggesting ways to customize the underlying Unix OS to gain additional advantages.
    Yes. Look, Apple is using a certified Unix in macOS. How much of it is in the other devices in iOS, I don’t know. But as Apple has control of both the hardware and the OS, they can work out problems that others can’t. Unifying doesn’t have to mean - Exactly the same. As all devices would be running on that OS, Apple could differentiate by device. Adding or subtracting for device capabilities doesn’t mean that the OS isn’t unified. An OS is the same whether it’s working on a machine with one core and no GPU, or a machine with 24 cores and multiple high end GPUs. Same thing with the amount of RAM and storage space. Not all software will work on all machines. Remember when Apple came out with Aperture? It wouldn’t even install on at least one of Apple’s laptops because it didn’t have enough RAM or processing power.

    so eliminating some code that controls third party GPUs, or monitors, or specific keyboards, or whatever, isn’t going to eliminate the unification. And unifications doesn’t mean, again I’ll say it, exactly the same. But the same enough to run the software in whatever means required for a specific class of device. So developers don’t have to rewrite the entire piece of software for every device.
    edited April 2018
  • Reply 207 of 245
    SoliSoli Posts: 10,035member
    Personally, I'm just glad that a lot more people are onboard this concept than there have been in the past when my what-if proposition of Apple introducing ARM-based Macs in the future was getting nearly 100% backlash from this forum.
  • Reply 208 of 245
    SoliSoli Posts: 10,035member
    melgross said:
    Adding or subtracting for device capabilities doesn’t mean that the OS isn’t unified
    That literally means it's not unified. watchOS and iOS are not unified and I see no avenue that will make them unified despite both running on ARM and having very similar touchscreen tech as their primary I/O which just a couple physical buttons.

    shared ≠ unified.

    unify | ˈyo͞onəˌfī |
    verb (unifies, unifying, unified)
    make or become united, uniform, or whole
    edited April 2018
  • Reply 209 of 245
    melgrossmelgross Posts: 33,510member

    Soli said:
    melgross said:
    There you go again, you’re not thinking about what I’m saying. Apple isn’t going to do that. Developers would have code that’s more modular. Apple would spell out what they expect them to do. Only that code required for a specific device would be downloaded. I’m saying that the UI is very I’m;oetant here, and so it is. But that means more than what you’re thinking. 

    Nobody would expect to do full full editing within Photoshop on their phone. Adobe could write this so that only those modules expected to be useful for that would be downloaded. That could be half the app, maybe more, or less. We already have games for out phones with core apps of over 150MB, with graphics adding almost another 1.5GB. So it’s not out of line to think that Photoshop for the phone could run between 100-200MB. Heck, Apple’s own software runs in the hundreds of megabytes now, on the iPad and iPhone. An example; Pages takes 462.4MB besides its data. Keynote takes 643.5MB besides its data. Even my Walgreens store app takes 156.1MB space.

    so what does the OS take in comparison and why should that change now? I don’t think it matters. Don’t say what Apple will do, people get in a lot of trouble doing that. I’m just suggesting what I think Apple would do if they do use a variation of their chips.
    If you're bringing up apps like photoshop then you're no longer taking about the OS. This is not a discussion about apps. Think only about the OS. Can you really ever imagine that the download for watchOS will be the same one as for macOS with the iPhone or Watch stripping out all the unneeded frameworks, UIs, drivers, and other code before the installation? Not in a million years do I see that ever being unified into that single piece of crap. Again, we will continue to have more shared code, just as we've had since the iPhone launched which was macOS stripped down and then built up for the HW and I/O and then more efficient frameworks and core services were then ported to macOS for a more efficient macOS. Even now, none of the OS X variants that have supported ARM from day one are unified, and they're a lot closer to each other than the Mac.

    You can’t only think about the OS, because the OS and what runs on it, and how, are intregal to each other.
  • Reply 210 of 245
    thttht Posts: 5,437member
    tipoo said:
    Panicking...I'm all in, baby! Their ARM custom cores are very good, and by 2020 there will be a convergence on Intels usual fabrication process lead so even that will be gone. I'm salivating at what Apple could design in high wattage, actively cooled, larger chips, with Intel-parity fabrication plants in 2020. 

    I wonder about the GPU part for dedicated GPU models, will Apple only cover the integrated GPU, or will they build dedicated ones too?
    I’m all in too. While it is really cool to have performance competitive ARM hardware to Intel or x86 hardware from 15 to 150 Watts, Apple going custom ARM will enable them to use form factors and have capability that they can’t with Intel. Like the aforementioned 0.5” thick iMac or a 0.5” clamshell dual display laptop while offering the same performance as Intel at half the power consumption, have integrated cellular modems, storage controllers right in the SoC.

    Not sure they want to play in the high performance computing game. Their ARM core can probably hit 6000 single threaded GB4 points if they have 50 W to play with. The recent reversal with eGPU support, a new Mac Pro and a new external display is showing they at least want to stay in the game for another shot, but there is no guarantee of long term support.

    I would really like to know what their thought process was for letting the 2013 Mac Pro stagnate, not building a 4K monitor in 2013, not revving the Time Capsule to 4/8 TB, not revving the Mac mini. In the 2015 timeframe, they had a murderer’s row image of their product lineup (look up grand unified theory of Apple product design), and the products in the image where Watch, iPhone, iPad, MBP and iMac. Hrrmph.

    Today, that chart would have to include displayless devices like AirPods, HomePods, and the rumored tin can headphones; and, the Apple TV at least. The Apple TV should be folded into Music or the inevitable future content services page, and audio products take its place on Apple’s website.
  • Reply 211 of 245
    SoliSoli Posts: 10,035member
    melgross said:

    Soli said:
    melgross said:
    There you go again, you’re not thinking about what I’m saying. Apple isn’t going to do that. Developers would have code that’s more modular. Apple would spell out what they expect them to do. Only that code required for a specific device would be downloaded. I’m saying that the UI is very I’m;oetant here, and so it is. But that means more than what you’re thinking. 

    Nobody would expect to do full full editing within Photoshop on their phone. Adobe could write this so that only those modules expected to be useful for that would be downloaded. That could be half the app, maybe more, or less. We already have games for out phones with core apps of over 150MB, with graphics adding almost another 1.5GB. So it’s not out of line to think that Photoshop for the phone could run between 100-200MB. Heck, Apple’s own software runs in the hundreds of megabytes now, on the iPad and iPhone. An example; Pages takes 462.4MB besides its data. Keynote takes 643.5MB besides its data. Even my Walgreens store app takes 156.1MB space.

    so what does the OS take in comparison and why should that change now? I don’t think it matters. Don’t say what Apple will do, people get in a lot of trouble doing that. I’m just suggesting what I think Apple would do if they do use a variation of their chips.
    If you're bringing up apps like photoshop then you're no longer taking about the OS. This is not a discussion about apps. Think only about the OS. Can you really ever imagine that the download for watchOS will be the same one as for macOS with the iPhone or Watch stripping out all the unneeded frameworks, UIs, drivers, and other code before the installation? Not in a million years do I see that ever being unified into that single piece of crap. Again, we will continue to have more shared code, just as we've had since the iPhone launched which was macOS stripped down and then built up for the HW and I/O and then more efficient frameworks and core services were then ported to macOS for a more efficient macOS. Even now, none of the OS X variants that have supported ARM from day one are unified, and they're a lot closer to each other than the Mac.

    You can’t only think about the OS, because the OS and what runs on it, and how, are intregal to each other.
    This is solely discussion about the OS, not about, say, how Safari for Mac will work on the HomePod.
  • Reply 212 of 245
    dick applebaumdick applebaum Posts: 12,527member
    Soli said:
    melgross said:
    There you go again, you’re not thinking about what I’m saying. Apple isn’t going to do that. Developers would have code that’s more modular. Apple would spell out what they expect them to do. Only that code required for a specific device would be downloaded. I’m saying that the UI is very I’m;oetant here, and so it is. But that means more than what you’re thinking. 

    Nobody would expect to do full full editing within Photoshop on their phone. Adobe could write this so that only those modules expected to be useful for that would be downloaded. That could be half the app, maybe more, or less. We already have games for out phones with core apps of over 150MB, with graphics adding almost another 1.5GB. So it’s not out of line to think that Photoshop for the phone could run between 100-200MB. Heck, Apple’s own software runs in the hundreds of megabytes now, on the iPad and iPhone. An example; Pages takes 462.4MB besides its data. Keynote takes 643.5MB besides its data. Even my Walgreens store app takes 156.1MB space.

    so what does the OS take in comparison and why should that change now? I don’t think it matters. Don’t say what Apple will do, people get in a lot of trouble doing that. I’m just suggesting what I think Apple would do if they do use a variation of their chips.
    If you're bringing up apps like photoshop then you're no longer taking about the OS. This is not a discussion about apps. Think only about the OS. Can you really ever imagine that the download for watchOS will be the same one as for macOS with the iPhone or Watch stripping out all the unneeded frameworks, UIs, drivers, and other code before the installation? Not in a million years do I see that ever being unified into that single piece of crap. Again, we will continue to have more shared code, just as we've had since the iPhone launched which was macOS stripped down and then built up for the HW and I/O and then more efficient frameworks and core services were then ported to macOS for a more efficient macOS. Even now, none of the OS X variants that have supported ARM from day one are unified, and they're a lot closer to each other than the Mac.


    Way back in post 47 to this thread, @knowitall linked to an Apple Developer page:

    knowitall said:
    rcfa said:
    There’s no merit in having an Intel CPU per se.

    The issue is software: Audio plug-ins discontinued, Aperture, VirtualBox, Adobe Software predating the subscription jail, etc.

    If Apple had retained Rosetta indefinitely, we’d all be calm. But what we’re looking at, is yet another orphaning of critical software.

    It would be high time Apple would switch to something like LLVM intermediate code as compilation target, such that any software would retain essentially indefinite compatibility with any past, present, and future CPU for which LLVM or something corresponding exists.
    Intermediate code would be one architecture of a universal binary, the actual target architecture only being generated during install or first execution.
    Apple already does this: https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f


    Here's a bit from the linked to page:


    Admittedly, it's currently limited to iOS, tvOS and watchOS -- but if Apple releases macOS on ARM, I suspect they would follow a similar approach.

  • Reply 213 of 245
    SoliSoli Posts: 10,035member
    Soli said:
    melgross said:
    There you go again, you’re not thinking about what I’m saying. Apple isn’t going to do that. Developers would have code that’s more modular. Apple would spell out what they expect them to do. Only that code required for a specific device would be downloaded. I’m saying that the UI is very I’m;oetant here, and so it is. But that means more than what you’re thinking. 

    Nobody would expect to do full full editing within Photoshop on their phone. Adobe could write this so that only those modules expected to be useful for that would be downloaded. That could be half the app, maybe more, or less. We already have games for out phones with core apps of over 150MB, with graphics adding almost another 1.5GB. So it’s not out of line to think that Photoshop for the phone could run between 100-200MB. Heck, Apple’s own software runs in the hundreds of megabytes now, on the iPad and iPhone. An example; Pages takes 462.4MB besides its data. Keynote takes 643.5MB besides its data. Even my Walgreens store app takes 156.1MB space.

    so what does the OS take in comparison and why should that change now? I don’t think it matters. Don’t say what Apple will do, people get in a lot of trouble doing that. I’m just suggesting what I think Apple would do if they do use a variation of their chips.
    If you're bringing up apps like photoshop then you're no longer taking about the OS. This is not a discussion about apps. Think only about the OS. Can you really ever imagine that the download for watchOS will be the same one as for macOS with the iPhone or Watch stripping out all the unneeded frameworks, UIs, drivers, and other code before the installation? Not in a million years do I see that ever being unified into that single piece of crap. Again, we will continue to have more shared code, just as we've had since the iPhone launched which was macOS stripped down and then built up for the HW and I/O and then more efficient frameworks and core services were then ported to macOS for a more efficient macOS. Even now, none of the OS X variants that have supported ARM from day one are unified, and they're a lot closer to each other than the Mac.


    Way back in post 47 to this thread, @knowitall linked to an Apple Developer page:

    knowitall said:
    rcfa said:
    There’s no merit in having an Intel CPU per se.

    The issue is software: Audio plug-ins discontinued, Aperture, VirtualBox, Adobe Software predating the subscription jail, etc.

    If Apple had retained Rosetta indefinitely, we’d all be calm. But what we’re looking at, is yet another orphaning of critical software.

    It would be high time Apple would switch to something like LLVM intermediate code as compilation target, such that any software would retain essentially indefinite compatibility with any past, present, and future CPU for which LLVM or something corresponding exists.
    Intermediate code would be one architecture of a universal binary, the actual target architecture only being generated during install or first execution.
    Apple already does this: https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f


    Here's a bit from the linked to page:


    Admittedly, it's currently limited to iOS, tvOS and watchOS -- but if Apple releases macOS on ARM, I suspect they would follow a similar approach.

    Again, not that's unifying everything into a whole. That's sharing so that specific devices can get the code they need. For the final time, AArch64, bitcode and slicing will never allow for unifying the OS X umbrella into a single, unified OS where the download for watchOS is the same for macOS. This is done to make it easier for developers. That's the drive, not some bizarre desire for some facile notion of minimalism that doesn't do anything but make everything worse.
    edited April 2018
  • Reply 214 of 245
    dick applebaumdick applebaum Posts: 12,527member
    Soli said:
    Admittedly, it's currently limited to iOS, tvOS and watchOS -- but if Apple releases macOS on ARM, I suspect they would follow a similar approach.
    Again, not that's unifying everything into a whole. That's sharing so that specific devices can get the code they need. For the final time, AArch64, bitcode and slicing will never allow for unifying the OS X umbrella into a single, unified OS where the download for watchOS is the same for macOS.
    Who would want that?  You are the only one, here that is suggesting the existence of an all-encompassing, monolithic OS that needs to be downloaded to every device.

    Even macOS, Unix, Linux, Windows are modular installs!
  • Reply 215 of 245
    SoliSoli Posts: 10,035member
    Soli said:
    Admittedly, it's currently limited to iOS, tvOS and watchOS -- but if Apple releases macOS on ARM, I suspect they would follow a similar approach.
    Again, not that's unifying everything into a whole. That's sharing so that specific devices can get the code they need. For the final time, AArch64, bitcode and slicing will never allow for unifying the OS X umbrella into a single, unified OS where the download for watchOS is the same for macOS.
    Who would want that?  You are the only one, here that is suggesting the existence of an all-encompassing, monolithic OS that needs to be downloaded to every device.

    Even macOS, Unix, Linux, Windows are modular installs!
    AND THEY WILL ALWAYS BE MODULAR SO STOP SAYING IT WILL ALL BE UNIFIED ONCE AArch64 IS ON macOS!
    edited April 2018
  • Reply 216 of 245
    dick applebaumdick applebaum Posts: 12,527member
    Soli said:
    melgross said:

    Soli said:
    melgross said:
    There you go again, you’re not thinking about what I’m saying. Apple isn’t going to do that. Developers would have code that’s more modular. Apple would spell out what they expect them to do. Only that code required for a specific device would be downloaded. I’m saying that the UI is very I’m;oetant here, and so it is. But that means more than what you’re thinking. 

    Nobody would expect to do full full editing within Photoshop on their phone. Adobe could write this so that only those modules expected to be useful for that would be downloaded. That could be half the app, maybe more, or less. We already have games for out phones with core apps of over 150MB, with graphics adding almost another 1.5GB. So it’s not out of line to think that Photoshop for the phone could run between 100-200MB. Heck, Apple’s own software runs in the hundreds of megabytes now, on the iPad and iPhone. An example; Pages takes 462.4MB besides its data. Keynote takes 643.5MB besides its data. Even my Walgreens store app takes 156.1MB space.

    so what does the OS take in comparison and why should that change now? I don’t think it matters. Don’t say what Apple will do, people get in a lot of trouble doing that. I’m just suggesting what I think Apple would do if they do use a variation of their chips.
    If you're bringing up apps like photoshop then you're no longer taking about the OS. This is not a discussion about apps. Think only about the OS. Can you really ever imagine that the download for watchOS will be the same one as for macOS with the iPhone or Watch stripping out all the unneeded frameworks, UIs, drivers, and other code before the installation? Not in a million years do I see that ever being unified into that single piece of crap. Again, we will continue to have more shared code, just as we've had since the iPhone launched which was macOS stripped down and then built up for the HW and I/O and then more efficient frameworks and core services were then ported to macOS for a more efficient macOS. Even now, none of the OS X variants that have supported ARM from day one are unified, and they're a lot closer to each other than the Mac.

    You can’t only think about the OS, because the OS and what runs on it, and how, are intregal to each other.
    This is solely discussion about the OS, not about, say, how Safari for Mac will work on the HomePod.
    No it's not -- the title of the article is:  

    Stop panicking about Apple's rumored switch from Intel to its own chips in the Mac


    From the end of the article, emphasis mine: 

    More complaints are swirling about Apple's software. While it is true that Apple could use a little help with quality assurance, users who think that the last version of any Apple software was the best ever have a short memory. 

    In every operating system Apple has ever shipped, there have been show-stopping bugs. We just have more users beating on Apple's offerings than ever before, so any problems will be found sooner, much like the theoretical infinite monkeys working on typewriters, with one generating the works of Shakespeare given enough time.

    What we'd get with a new Apple-build ARM processor is a new processor architecture not bogged down with literally three decades of legacy routines. We'd get new architecture, with an architecture that can handle LPDD4 RAM, allowing for up to 64 gigabytes of RAM and four times the bandwidth that LPDDR3 and conventional DDR4 can handle.

    Yes, we'd lose some devout, like we always have at every shift. But, what the remainders would get is a superior architecture for the future, not beholden to Intel's continued tock, with no signs of a tick that would be beneficial to Mac users coming in a timely fashion.

    We've done this as users before. When the dust settles, there will be Intel-devout, when it was talked about as akin to the end of days, the same as the shift to the Mac, and the shift to PowerPC. Plus, your old hardware won't spontaneously combust when the shift is announced, and you can in all likelihood wait until your favorite software is ARM-native to buy new gear.

    So, don't fear the shift. There's no need to panic.

  • Reply 217 of 245
    SoliSoli Posts: 10,035member
    Soli said:
    melgross said:

    Soli said:
    melgross said:
    There you go again, you’re not thinking about what I’m saying. Apple isn’t going to do that. Developers would have code that’s more modular. Apple would spell out what they expect them to do. Only that code required for a specific device would be downloaded. I’m saying that the UI is very I’m;oetant here, and so it is. But that means more than what you’re thinking. 

    Nobody would expect to do full full editing within Photoshop on their phone. Adobe could write this so that only those modules expected to be useful for that would be downloaded. That could be half the app, maybe more, or less. We already have games for out phones with core apps of over 150MB, with graphics adding almost another 1.5GB. So it’s not out of line to think that Photoshop for the phone could run between 100-200MB. Heck, Apple’s own software runs in the hundreds of megabytes now, on the iPad and iPhone. An example; Pages takes 462.4MB besides its data. Keynote takes 643.5MB besides its data. Even my Walgreens store app takes 156.1MB space.

    so what does the OS take in comparison and why should that change now? I don’t think it matters. Don’t say what Apple will do, people get in a lot of trouble doing that. I’m just suggesting what I think Apple would do if they do use a variation of their chips.
    If you're bringing up apps like photoshop then you're no longer taking about the OS. This is not a discussion about apps. Think only about the OS. Can you really ever imagine that the download for watchOS will be the same one as for macOS with the iPhone or Watch stripping out all the unneeded frameworks, UIs, drivers, and other code before the installation? Not in a million years do I see that ever being unified into that single piece of crap. Again, we will continue to have more shared code, just as we've had since the iPhone launched which was macOS stripped down and then built up for the HW and I/O and then more efficient frameworks and core services were then ported to macOS for a more efficient macOS. Even now, none of the OS X variants that have supported ARM from day one are unified, and they're a lot closer to each other than the Mac.

    You can’t only think about the OS, because the OS and what runs on it, and how, are intregal to each other.
    This is solely discussion about the OS, not about, say, how Safari for Mac will work on the HomePod.
    No it's not -- the title of the article is:  

    Stop panicking about Apple's rumored switch from Intel to its own chips in the Mac


    From the end of the article, emphasis mine: 

    More complaints are swirling about Apple's software. While it is true that Apple could use a little help with quality assurance, users who think that the last version of any Apple software was the best ever have a short memory. 

    In every operating system Apple has ever shipped, there have been show-stopping bugs. We just have more users beating on Apple's offerings than ever before, so any problems will be found sooner, much like the theoretical infinite monkeys working on typewriters, with one generating the works of Shakespeare given enough time.

    What we'd get with a new Apple-build ARM processor is a new processor architecture not bogged down with literally three decades of legacy routines. We'd get new architecture, with an architecture that can handle LPDD4 RAM, allowing for up to 64 gigabytes of RAM and four times the bandwidth that LPDDR3 and conventional DDR4 can handle.

    Yes, we'd lose some devout, like we always have at every shift. But, what the remainders would get is a superior architecture for the future, not beholden to Intel's continued tock, with no signs of a tick that would be beneficial to Mac users coming in a timely fashion.

    We've done this as users before. When the dust settles, there will be Intel-devout, when it was talked about as akin to the end of days, the same as the shift to the Mac, and the shift to PowerPC. Plus, your old hardware won't spontaneously combust when the shift is announced, and you can in all likelihood wait until your favorite software is ARM-native to buy new gear.

    So, don't fear the shift. There's no need to panic.

    That’s what AI posted, and then someone made a silly comment about unifying all their OSes. You know forum threads work, Richard. 
  • Reply 218 of 245
    dick applebaumdick applebaum Posts: 12,527member
    Soli said:
    Soli said:
    Admittedly, it's currently limited to iOS, tvOS and watchOS -- but if Apple releases macOS on ARM, I suspect they would follow a similar approach.
    Again, not that's unifying everything into a whole. That's sharing so that specific devices can get the code they need. For the final time, AArch64, bitcode and slicing will never allow for unifying the OS X umbrella into a single, unified OS where the download for watchOS is the same for macOS.
    Who would want that?  You are the only one, here that is suggesting the existence of an all-encompassing, monolithic OS that needs to be downloaded to every device.

    Even macOS, Unix, Linux, Windows are modular installs!
    AND THEY WILL ALWAYS BE MODULAR SO STOP SAYING IT WILL ALL BE UNIFIED ONCE AArch64 IS ON macOS!

    I never said they would be unified -- just shared, customizable components (modules, if you will) of a whole Package -- e.g. a unified code base that can be tailored by developers and computer processes to build apps.  By their nature these apps will packaged to download, install, run and update efficiently on the targeted devices and OS versions.
  • Reply 219 of 245
    dick applebaumdick applebaum Posts: 12,527member
    Soli said:

    That’s what AI posted, and then someone made a silly comment about unifying all their OSes. You know forum threads work, Richard. 

    Yeah, I have a jar for you to wash...
  • Reply 220 of 245
    crowleycrowley Posts: 10,453member
    You have a different understanding of what unified means in the context of a codebase, we get it.  Since you seem to agree on the actual practical implications, can you just agree to disagree about the precise meaning of the word "unified" and get over it?

    So tedious.
    edited April 2018
Sign In or Register to comment.