5 ms·

This bit about Multi-platform development is most interesting to me. > Many developers are going to experience multi-platform development for the first time wi

This bit about Multi-platform development is most interesting to me. > Many developers are going to experience multi-platform development for the first time with the M1 Macs. This is one of the key areas where Docker shines. Docker has had support for multi-platform images for a long time, meaning that you can build and run both x86 and ARM images on Desktop today. If multi platform images work, a lot of the concerns people have about x86 versus ARM should go away. Of course, once you can do everything on ARM as well as you can on x86. Perhaps changing more of your infrastructure to ARM might make more sense.

MangoCoffee 6y ago
>Of course, once you can do everything on ARM as well as you can on x86. i have high hope for AMD/TSMC to push x86. Intel seem to be...stuck for now.
- cogman10 6y ago
  I mean, if the apple approach really works well then I could see AMD or even Intel following suit in the future. If the industry starts to shift and push towards ARM due to cost, AMD and Intel would be fools to just leave that on the table.
  - ogre_codes 6y ago
    Intel's fat margins are largely based on their duopoly on x86. With ARM, it's far more competitive and margins are far lower. With Nvidia owning ARM, it seems likely we'll see more ARM CPUs from them. Samsung, Qualcomm, and Mediatech also have ARM CPUs all the way down to a few dollars per CPU. Intel isn't going to be able to come in and charge $50-500+ unit the way they do with their x86 chips. Unless Intel can reboot Moore's Law on Intel, they are going to get hit hard over the next few years. Even if Intel makes the move to ARM, their profitability will take a huge hit from the ARM migration.
    - cogman10 6y ago
      I don't disagree. In fact, I'm assuming that's a major reason they've not done this sooner. Intel tried to setup a different more efficient architecture with IA64, but they failed there. That being said, with major players like Amazon and Google tinkering with ARM in the cloud and Apple getting ARM into the hands of a lot of developers, we could be on the eve of seeing ARM make a big entrance into the server realm. IMO, a big reason ARM hasn't taken off there in the first place is because most devs aren't using ARM machines for development.
      - ogre_codes 6y ago
        I agree. > IMO, a big reason ARM hasn't taken off there in the first place is because most devs aren't using ARM machines for development. Also suspect this is largely true. Most developers have local environments and until Apple, having a local environment with ARM has been awkward. Docker multi-platform images is supposed to mitigate this, but they are still fairly new and I suspect many developers don't trust them yet. It would be interesting to see Apple launch am M series server. After looking at the M1 Mac mini logic board, it seems like a blade server with stacks of Mac mini boards would be fairly easy to engineer. Apple would just need to build the chassis. (Not holding my breath waiting for this)
      - pjmlp 6y ago
        That reason doesn't make any sense to me. I have been coding since the mid-80's, not having the same local UNIX machine for doing development than what the server was running was quite common in the world of commercial UNIXes. Then I moved into managed languages, where the actual CPU and even underlying OS, only matter to low level coding, again not using the same local OS/CPU combo as the server. Finally, cross compilation for ARM exists since years. ARM hasn't taken off, because most of time it doesn't matter enough to displace the existing stacks.
        cogman10 6y ago
        > I have been coding since the mid-80's, not having the same local UNIX machine for doing development than what the server was running was quite common in the world of commercial UNIXes. Things change. Why is x86 the primary server platform? It isn't a great micro architecture. The fact that ARM and others (Like power pc) have been eating their lunch in terms of price, performance, and power consumption is proof enough of that. So how do you explain the rise of x86 and the fall of pretty much every other platform on servers? To me, it's simple. x86 got fast enough on consumer hardware to be able to run the same software that would run on servers. Developers like to test their software locally. Emulators for anything to x86 have been terribly slow. That's why since about the late 90's pretty much everyone has been running x86 servers. That you can cross compile isn't really the issue. Even running managed languages isn't the issue. The issue is that there are always differences that are hard to compare when switching platforms if the one you are developing on isn't the same as the one you are targeting. That's like 90% the reason why most consoles have switched over to x86. Mobile devices would have gone to x86 were it not for the fact that licensing costs were too high and the performance/watt ratio too low.
YetAnotherNick 6y ago
> If multi platform images work, a lot of the concerns people have about x86 versus ARM should go away. Not really. Just because you have ARM and AMD debian, you wouldn't have same behaviour in both. You wouldn't have same list of packages that can be installed.
- acdha 6y ago
  You'll have extremely close to the same behaviour in both since Debian ships exactly the same versions. It's always possible that there's a compiler bug which only affects one platform but that's relatively uncommon. At one point I was supporting Debian on x86, x86_64, MIPS, and PowerPC. The major portability concern was drivers, which is irrelevant for Docker, and sometimes you'd find performance issues with e.g. OpenSSL having a hand-tuned x86 ASM implementation but relying on the C compiler for another platform but it was rather uncommon. I am skeptical that anyone will notice a problem unless their workflow is to build a container on their laptop and push it straight to production without testing.
- ogre_codes 6y ago
  That is fundamentally what I mean when I say "If they work". If the two platforms behave differently, then multi-platform images are pointless. If 1 in 20 multi-platform images has some kind of oddball cross platform behavior, developers won't be able to rely on them at all. I think we can get far better than that, but we'll see.
ducktective 6y ago
Yeah, until the developers decide to release only for Arm targets and when you search issues for x86 build, the maintainer says "just compile it yourself"... And you look into the dockerfile manifest and see that it wants to pull the whole stack of history of computing...Then you figure maybe you don't need that shiny utility in the first place and move on... It's "64 vs 32-bit" or "Ubuntu vs Arch vs Fedora binary" all over again...
- ogre_codes 6y ago
  > Yeah, until the developers decide to release only for Arm targets and when you search issues for x86 build, the maintainer says "just compile it yourself"... Until we start seeing reasonably priced, performant ARM desktops and laptops, there is little worry of that. Right now outside Apple, performance on ARM isn't good enough for any kind of great developer experience (or any kind of pro experience). Unless that changes significantly, x86 is going to be dominant on non-Macs for some time.
  - pjmlp 6y ago
    On desktops yes, ARM rules on mobile devices and plenty of us code for them, and on Android unless you are doing CRUD like apps, most likely there is some C or C++ code as well.
- totalZero 6y ago
  Apple is 15% of the personal computer market, if I'm not mistaken. Their intention to abandon x86 isn't a clarion call for the obsolescence of x86. Personal computers generally go where Windows goes. Heck, that's arguably part of why Apple left PowerPC for Intel in the first place. Apple has tremendous impact on design, form factor, and other visionary steps that the market takes. I do not deny that. Still, in terms of hardware and the development ecosystem, Microsoft simply has a lot more market inertia than does Apple. This is nothing like 64bit vs 32bit. That was a difficult (MacOS didn't drop 32bit app support until Catalina) but obvious (unless you hate RAM) leap forward. In contrast, Apple Silicon is a leap sideways whose opportunity arose because Intel's flagship process node has had a rough few years. There may be inherent advantages to Apple Silicon as a technology, but nobody should make the unproven assumption that Apple Silicon is universally superior to any and every possible TSMC 5nm x86 chip.
jillesvangurp 6y ago
X86 support is a big one for me. I deal with a lot of customer projects; typically with some kind of dockerized stuff as part of their tool chain. So, being able to run those things as is, is important for me. And I don't see those build systems being updated any time soon to be able to accommodate some Apple only hardware.
- Wowfunhappy 6y ago
  Note, Docker will run x86 containers via qemu, so you can still use them. They'll just be slower.
  - ogre_codes 6y ago
    This whole territory is pretty much unknown right now. Whether we can have reasonably performant x86 containers is up in the air.
    - Wowfunhappy 6y ago
      I'd expect it to be exactly as performant as qemu's x86 emulation always is. The M1 is new, but qemu is not.
      - fomine3 6y ago
        So it means plain old binary translation without hardware assist. I wonder that whether QEMU's binary translation is not optimized well nowadays because no one uses it for production (we use with VT-x/EPT or AMD equivalent).
        ogre_codes 6y ago
        I think QEMU is hardware emulation, not translation.
        fomine3 6y ago

MangoCoffee 6y ago

>Of course, once you can do everything on ARM as well as you can on x86. i have high hope for AMD/TSMC to push x86. Intel seem to be...stuck for now.

cogman10 6y ago
I mean, if the apple approach really works well then I could see AMD or even Intel following suit in the future. If the industry starts to shift and push towards ARM due to cost, AMD and Intel would be fools to just leave that on the table.
- ogre_codes 6y ago
  Intel's fat margins are largely based on their duopoly on x86. With ARM, it's far more competitive and margins are far lower. With Nvidia owning ARM, it seems likely we'll see more ARM CPUs from them. Samsung, Qualcomm, and Mediatech also have ARM CPUs all the way down to a few dollars per CPU. Intel isn't going to be able to come in and charge $50-500+ unit the way they do with their x86 chips. Unless Intel can reboot Moore's Law on Intel, they are going to get hit hard over the next few years. Even if Intel makes the move to ARM, their profitability will take a huge hit from the ARM migration.
  - cogman10 6y ago
    I don't disagree. In fact, I'm assuming that's a major reason they've not done this sooner. Intel tried to setup a different more efficient architecture with IA64, but they failed there. That being said, with major players like Amazon and Google tinkering with ARM in the cloud and Apple getting ARM into the hands of a lot of developers, we could be on the eve of seeing ARM make a big entrance into the server realm. IMO, a big reason ARM hasn't taken off there in the first place is because most devs aren't using ARM machines for development.
    - ogre_codes 6y ago
      I agree. > IMO, a big reason ARM hasn't taken off there in the first place is because most devs aren't using ARM machines for development. Also suspect this is largely true. Most developers have local environments and until Apple, having a local environment with ARM has been awkward. Docker multi-platform images is supposed to mitigate this, but they are still fairly new and I suspect many developers don't trust them yet. It would be interesting to see Apple launch am M series server. After looking at the M1 Mac mini logic board, it seems like a blade server with stacks of Mac mini boards would be fairly easy to engineer. Apple would just need to build the chassis. (Not holding my breath waiting for this)
    - pjmlp 6y ago
      That reason doesn't make any sense to me. I have been coding since the mid-80's, not having the same local UNIX machine for doing development than what the server was running was quite common in the world of commercial UNIXes. Then I moved into managed languages, where the actual CPU and even underlying OS, only matter to low level coding, again not using the same local OS/CPU combo as the server. Finally, cross compilation for ARM exists since years. ARM hasn't taken off, because most of time it doesn't matter enough to displace the existing stacks.
      - cogman10 6y ago
        > I have been coding since the mid-80's, not having the same local UNIX machine for doing development than what the server was running was quite common in the world of commercial UNIXes. Things change. Why is x86 the primary server platform? It isn't a great micro architecture. The fact that ARM and others (Like power pc) have been eating their lunch in terms of price, performance, and power consumption is proof enough of that. So how do you explain the rise of x86 and the fall of pretty much every other platform on servers? To me, it's simple. x86 got fast enough on consumer hardware to be able to run the same software that would run on servers. Developers like to test their software locally. Emulators for anything to x86 have been terribly slow. That's why since about the late 90's pretty much everyone has been running x86 servers. That you can cross compile isn't really the issue. Even running managed languages isn't the issue. The issue is that there are always differences that are hard to compare when switching platforms if the one you are developing on isn't the same as the one you are targeting. That's like 90% the reason why most consoles have switched over to x86. Mobile devices would have gone to x86 were it not for the fact that licensing costs were too high and the performance/watt ratio too low.

YetAnotherNick 6y ago

> If multi platform images work, a lot of the concerns people have about x86 versus ARM should go away. Not really. Just because you have ARM and AMD debian, you wouldn't have same behaviour in both. You wouldn't have same list of packages that can be installed.

acdha 6y ago
You'll have extremely close to the same behaviour in both since Debian ships exactly the same versions. It's always possible that there's a compiler bug which only affects one platform but that's relatively uncommon. At one point I was supporting Debian on x86, x86_64, MIPS, and PowerPC. The major portability concern was drivers, which is irrelevant for Docker, and sometimes you'd find performance issues with e.g. OpenSSL having a hand-tuned x86 ASM implementation but relying on the C compiler for another platform but it was rather uncommon. I am skeptical that anyone will notice a problem unless their workflow is to build a container on their laptop and push it straight to production without testing.
ogre_codes 6y ago
That is fundamentally what I mean when I say "If they work". If the two platforms behave differently, then multi-platform images are pointless. If 1 in 20 multi-platform images has some kind of oddball cross platform behavior, developers won't be able to rely on them at all. I think we can get far better than that, but we'll see.

ducktective 6y ago

Yeah, until the developers decide to release only for Arm targets and when you search issues for x86 build, the maintainer says "just compile it yourself"... And you look into the dockerfile manifest and see that it wants to pull the whole stack of history of computing...Then you figure maybe you don't need that shiny utility in the first place and move on... It's "64 vs 32-bit" or "Ubuntu vs Arch vs Fedora binary" all over again...

ogre_codes 6y ago
> Yeah, until the developers decide to release only for Arm targets and when you search issues for x86 build, the maintainer says "just compile it yourself"... Until we start seeing reasonably priced, performant ARM desktops and laptops, there is little worry of that. Right now outside Apple, performance on ARM isn't good enough for any kind of great developer experience (or any kind of pro experience). Unless that changes significantly, x86 is going to be dominant on non-Macs for some time.
- pjmlp 6y ago
  On desktops yes, ARM rules on mobile devices and plenty of us code for them, and on Android unless you are doing CRUD like apps, most likely there is some C or C++ code as well.
totalZero 6y ago
Apple is 15% of the personal computer market, if I'm not mistaken. Their intention to abandon x86 isn't a clarion call for the obsolescence of x86. Personal computers generally go where Windows goes. Heck, that's arguably part of why Apple left PowerPC for Intel in the first place. Apple has tremendous impact on design, form factor, and other visionary steps that the market takes. I do not deny that. Still, in terms of hardware and the development ecosystem, Microsoft simply has a lot more market inertia than does Apple. This is nothing like 64bit vs 32bit. That was a difficult (MacOS didn't drop 32bit app support until Catalina) but obvious (unless you hate RAM) leap forward. In contrast, Apple Silicon is a leap sideways whose opportunity arose because Intel's flagship process node has had a rough few years. There may be inherent advantages to Apple Silicon as a technology, but nobody should make the unproven assumption that Apple Silicon is universally superior to any and every possible TSMC 5nm x86 chip.

jillesvangurp 6y ago

X86 support is a big one for me. I deal with a lot of customer projects; typically with some kind of dockerized stuff as part of their tool chain. So, being able to run those things as is, is important for me. And I don't see those build systems being updated any time soon to be able to accommodate some Apple only hardware.

Wowfunhappy 6y ago
Note, Docker will run x86 containers via qemu, so you can still use them. They'll just be slower.
- ogre_codes 6y ago
  This whole territory is pretty much unknown right now. Whether we can have reasonably performant x86 containers is up in the air.
  - Wowfunhappy 6y ago
    I'd expect it to be exactly as performant as qemu's x86 emulation always is. The M1 is new, but qemu is not.
    - fomine3 6y ago
      So it means plain old binary translation without hardware assist. I wonder that whether QEMU's binary translation is not optimized well nowadays because no one uses it for production (we use with VT-x/EPT or AMD equivalent).
      - ogre_codes 6y ago
        I think QEMU is hardware emulation, not translation.
        fomine3 6y ago