Not a surprise for those with containerised workloads. Mac is a nightmare for that. Every single dev team with mac that I’ve been on has struggled with it. Heard all these things and more:
We can’t use Docker Desktop due to licensing!
podman doesn’t work, but colima does
npm install takes forever!
Why can’t it find the docker socket?
This only works on x86
The port-forwarding didn’t work
XYZ works in the dev-container but not when deployed
Recreating a problem you encountered with your container in a x86 linux VM in the cloud on a mac with apple silicon is no fun either.
And good luck with custom hardware on a mac. Working from home with stuff that was plug and play on linux simply refused to work on mac. Ergonomic mice, keyboards, USB-C docks, high-quality webcams, USB headsets… Either you’re in the Apple ecosystem or you’re gonna have a bad time.
If an employer doesn’t allow me to install linux on my dev machine, then I move on.
That’s kinda weird, I develop on a M2 Mac and use docker all day, I haven’t tried podman on my m2 but I used it on my previous i7 MBP without any issue for a project I was on.
I use my own mouse and keyboard and the same monitor setup I use for my personal computer.
Agreed. The bit about peripherals, in particular, seems strange. I’ve never had a problem with a fucking keyboard or mouse. None of the rest, either, but seriously, keyboard or mouse? Suggesting that they don’t work makes the whole post sound like an exaggeration.
I’m not a Mac guy so I can’t comment on the hardware side of things but I can comment on the Docker side of things.
Docker runs in a VM on Mac, and in a VM or WSL on Windows. On Windows the experience is awful, doesn’t matter if its WSL or VM. On Mac the experience is okish but there are enough differences that it makes Docker less effective as a platform.
The whole selling point of Docker is reproducibility, on Mac and Windows there are issues that do not occur on the platform that all the servers we deploy to run. I constantly have to help my coworkers with issues on Mac and Windows that simply do not exist on native Docker on Linux. It has gotten so bad that I simply refuse any help for anyone running Docker on Windows. I try my best on Mac but if I can’t solve it quickly or reproduce it on a Linux machine I dismiss it.
The devil is in the detail, minor differences are enough to throw off a system that is made to be run in a container and expects identical environments between instances.
There are 200 open issues for docker compose, nearly 600 for docker cli.
The number of open issues means nothing without context.
Again, I’d love to hear about actual peculiarities you run into because as of yet in the last 5 years I’ve developed on a MBP (work provided, I previously “hated” Apple) I haven’t had these issues you’re claiming are all over.
The number of open issues means nothing without context.
The context is that the issues for docker compose and docker CLI are almost identical across Linux hosts and can be worked around, there are 426 additional issues just for Mac one has to watch out for.
Our main issues on Mac (that I can remember):
Severe slowdowns causing healthchecks to fail (Mostly caused by slow network requests and writing/reading thousands of smaller files)
Environment variables not being applied correctly to build containers
docker-compose file differences, e.g. newer versions not available or older versions deprecated earlier
Under high load the VM chokes even though there are plenty of resources available
I never was able to set permanent sysctl configs needed for some of our applications.
On ARM: Building some of our x86 containers is seriously slow and eats a lot of RAM
On ARM: Running x86 containers is much slower, sometimes hangs and sometimes even crashes the VM
I have been a Linux admin for the better part of two decades now. I’m not saying that Mac is better, I’m just saying that in the real world I don’t run into any of those issues.
I didn’t purchase my Mac, it is work provided. My infrastructure is a mixture of x86 and arm but it’s all Linux.
I’ve ran into exactly 0 issues using the work issued Mac to interact with my infrastructure or develop containers or any of the supporting software for our operations.
I’ve used an intel MBP and an apple silicon MBP as well as developing on a handful of other platforms running other Linux platforms per contract requirements. There are peculiarities between any operating system but what they’re saying straight up isn’t true.
Issue numbers out of context is a stupid metric, their explanation for that metric is even dumber.
They legitimately said “peripheral issues” then when pressed backed off because “they’re not a Mac user”.
Then saying x86 containers run slower when on a different instruction set than native is somehow another indicator …
When I realized I wasn’t talking with someone who actually had real information I said what I said.
My bias is simply that repeating a narrative you’re not actually aware of is stupid. All of the things that person said aren’t actually the problem they say they are.
I agree with everything but the “This only works on x86”. I’m not saying that everything runs smoothly on arm, but I think it really is the future. Either that, or risc-v. I doubt riscv will garner a mainstream adoption anytime soon though, but one could only dream.
Not a surprise for those with containerised workloads. Mac is a nightmare for that. Every single dev team with mac that I’ve been on has struggled with it. Heard all these things and more:
npm installtakes forever!Recreating a problem you encountered with your container in a x86 linux VM in the cloud on a mac with apple silicon is no fun either.
And good luck with custom hardware on a mac. Working from home with stuff that was plug and play on linux simply refused to work on mac. Ergonomic mice, keyboards, USB-C docks, high-quality webcams, USB headsets… Either you’re in the Apple ecosystem or you’re gonna have a bad time.
If an employer doesn’t allow me to install linux on my dev machine, then I move on.
That’s kinda weird, I develop on a M2 Mac and use docker all day, I haven’t tried podman on my m2 but I used it on my previous i7 MBP without any issue for a project I was on.
I use my own mouse and keyboard and the same monitor setup I use for my personal computer.
This just doesn’t track at all.
mind you I literally have tux tattooed on my body
Agreed. The bit about peripherals, in particular, seems strange. I’ve never had a problem with a fucking keyboard or mouse. None of the rest, either, but seriously, keyboard or mouse? Suggesting that they don’t work makes the whole post sound like an exaggeration.
Do you use a mouse with more than 3 buttons? Do you use a split keyboard?
I’m not a Mac guy so I can’t comment on the hardware side of things but I can comment on the Docker side of things.
Docker runs in a VM on Mac, and in a VM or WSL on Windows. On Windows the experience is awful, doesn’t matter if its WSL or VM. On Mac the experience is okish but there are enough differences that it makes Docker less effective as a platform.
The whole selling point of Docker is reproducibility, on Mac and Windows there are issues that do not occur on the platform that all the servers we deploy to run. I constantly have to help my coworkers with issues on Mac and Windows that simply do not exist on native Docker on Linux. It has gotten so bad that I simply refuse any help for anyone running Docker on Windows. I try my best on Mac but if I can’t solve it quickly or reproduce it on a Linux machine I dismiss it.
The devil is in the detail, minor differences are enough to throw off a system that is made to be run in a container and expects identical environments between instances.
There’s enough issues with Docker for Mac that they have separate tabs on the Docker known issues page: https://docs.docker.com/desktop/troubleshoot/known-issues/
There’s also 426 open issues just for the Mac port of Docker: https://github.com/docker/for-mac/issues
Huh, I mean you’re saying a lot but still.
There are 200 open issues for docker compose, nearly 600 for docker cli.
The number of open issues means nothing without context.
Again, I’d love to hear about actual peculiarities you run into because as of yet in the last 5 years I’ve developed on a MBP (work provided, I previously “hated” Apple) I haven’t had these issues you’re claiming are all over.
The context is that the issues for docker compose and docker CLI are almost identical across Linux hosts and can be worked around, there are 426 additional issues just for Mac one has to watch out for.
Our main issues on Mac (that I can remember):
You’ve said enough at this point for me to recognize it’s your bias speaking.
Lol, as if yours isn’t.
I have been a Linux admin for the better part of two decades now. I’m not saying that Mac is better, I’m just saying that in the real world I don’t run into any of those issues.
I didn’t purchase my Mac, it is work provided. My infrastructure is a mixture of x86 and arm but it’s all Linux.
I’ve ran into exactly 0 issues using the work issued Mac to interact with my infrastructure or develop containers or any of the supporting software for our operations.
I’ve used an intel MBP and an apple silicon MBP as well as developing on a handful of other platforms running other Linux platforms per contract requirements. There are peculiarities between any operating system but what they’re saying straight up isn’t true.
Issue numbers out of context is a stupid metric, their explanation for that metric is even dumber.
They legitimately said “peripheral issues” then when pressed backed off because “they’re not a Mac user”.
Then saying x86 containers run slower when on a different instruction set than native is somehow another indicator …
When I realized I wasn’t talking with someone who actually had real information I said what I said.
My bias is simply that repeating a narrative you’re not actually aware of is stupid. All of the things that person said aren’t actually the problem they say they are.
I agree with everything but the “This only works on x86”. I’m not saying that everything runs smoothly on arm, but I think it really is the future. Either that, or risc-v. I doubt riscv will garner a mainstream adoption anytime soon though, but one could only dream.
well yeah arm is definitely the future, but edge cases and undefined behavior make parity between the instruction sets a major pain