3 ms·

No problems here with Docker and macOS. Docker and Windows works too. We have a ratio of about 97% developers on macOS, 2% on windows and 1% on 'else' which is

No problems here with Docker and macOS. Docker and Windows works too. We have a ratio of about 97% developers on macOS, 2% on windows and 1% on 'else' which is mostly Linux and a single BSD user. This includes multiple editors and IDEs used, multiple languages and multiple frameworks, also multiple types of development (from common devops facilities development to front-end simulation, on-prem and cloud, C#, Python, Java, Go, Rust, Swift, Objective-C, C++, TypeScript, Scala, T-SQL, PL/SQL (yep, RDBMS with on-DB applications), some on plain docker, some on Podman some on local Kubernetes clusters, all using wired and wireless connections (or both), one or more VPN connections), and nobody is having any issues with macOS and Docker on Intel or ARM. The only non-ARM OS we have around is Windows because we can't legally get it. Everything else is multi-arch, except for some legacy Oracle and IBM applications that are being phased out and have been handed off to a third party to maintain while we rip them out. We have the luxury of not really doing and foreign architecture compilation because you can develop locally and CI will do matrix builds so we can run on a mixed spot fleet on AWS. We used to build for POWER8 too (before we handed off the IBM nonsense). Some people do it anyway, especially those who want to test binary protocols (a very small percentage) when they write applications that do IT<-->OT communication and want to make sure that the architecture on the IT side doesn't mess up binary payloads that the OT side won't know what to do with. This is usually done with k3s and skaffold where we attach and 2nd node to a Rancher Desktop instance that runs pure x86 instead of x86-in-ARM via Rosetta. We also have 1 Linux user who does this, but she's just using plain qemu emulation for ARM-on-x86 (instead of the other way around on M1/M2 Macs). So all in all, I think the problem is still valid, but your experience is not really representative it seems. Keep in mind that happy people tend to not go on the internet and tell everyone about all the problems they don't have ;-) So most reports we'll see will be from people having issues with something. The biggest issue we used to have was the AUFS support, but even that was mostly a painpoint for those who could not auto build from the ide or didn't have things like Jib. That has been resolved for over 5 years tho.

kitsunesoba 4y ago
> a single BSD user. This is surprising. I run FreeBSD on a home server but I would imagine that it'd be rather unproductive to run as a web dev workstation OS, since it shares friction points with macOS (mainly, it's not Linux) but doesn't have even a fraction as many users which means you're basically on your own for fixing any issues that crop up. More power to this individual if they're making it work though. It's great to see diversity in the desktop/workstation OS usage… in my view, desktop monoculture will only come back to bite us in the ass.
- oneplane 4y ago
  Yeah, it's a bit of a choice, but a happy user that takes care of the friction is a win for me. From an MDM perspective all we require is that your work machine can run osquery. We host the rules in an internal repo so if someone wants to use something we don't support they have to write the compliance checks themselves ahead of time (and get them approved, we do help with that). I also think that monoculture isn't really the best way, but neither is an abundance of variations causing uncertainty. We need to be able to plan ahead and look ahead, and have enough of a standard to operate. Luckily, convincing stakeholders that "but we imaged this workstation last year" isn't a valid argument in any scenario (security, productivity, DLP) wasn't all that hard, and the jump from there to "images and MDM are all fun, but near realtime posture verification is the only way" was made with relative ease. Most people still stick to the "supported and automated" provisioned workstations, but those who want something else can have it, if they deliver on their compliance, non-friction and actual work. Best of all worlds.

kitsunesoba 4y ago

> a single BSD user. This is surprising. I run FreeBSD on a home server but I would imagine that it'd be rather unproductive to run as a web dev workstation OS, since it shares friction points with macOS (mainly, it's not Linux) but doesn't have even a fraction as many users which means you're basically on your own for fixing any issues that crop up. More power to this individual if they're making it work though. It's great to see diversity in the desktop/workstation OS usage… in my view, desktop monoculture will only come back to bite us in the ass.

oneplane 4y ago
Yeah, it's a bit of a choice, but a happy user that takes care of the friction is a win for me. From an MDM perspective all we require is that your work machine can run osquery. We host the rules in an internal repo so if someone wants to use something we don't support they have to write the compliance checks themselves ahead of time (and get them approved, we do help with that). I also think that monoculture isn't really the best way, but neither is an abundance of variations causing uncertainty. We need to be able to plan ahead and look ahead, and have enough of a standard to operate. Luckily, convincing stakeholders that "but we imaged this workstation last year" isn't a valid argument in any scenario (security, productivity, DLP) wasn't all that hard, and the jump from there to "images and MDM are all fun, but near realtime posture verification is the only way" was made with relative ease. Most people still stick to the "supported and automated" provisioned workstations, but those who want something else can have it, if they deliver on their compliance, non-friction and actual work. Best of all worlds.