Docker Desktop for Mac (Apple Silicon)
docker.com
docker.com
That moment is now here. Sure, it's only a subset of the market, but Mac devices are a significant percentage of developer computers (28%), way higher than in the general population (17%).
https://insights.stackoverflow.com/survey/2020#technology-de...
https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...
Likewise, with the return of timesharing, anyone can log into their assigned server slot and work just like I was doing 30 years ago.
https://medium.com/incerto/the-most-intolerant-wins-the-dict...
They will either be using Windows in some form (even if pirated), now with Linux VMs as standard feature, or some Linux variant.
(a) It's not those countries that drive trends (if they were we wouldn't have heavy frameworks and a 10MB SPA bloat as the norm in web development),
(b) ARM was already trending for use in servers (heck, even supercomputers),
(c) and Apple's transition means tons of devs in the West (and elsewhere, e.g. I've worked outside of Europe and US and everybody had a Mac in several different companies) will end up with an ARM chip and start influencing server trends
(d) At first many of those devs will go to ARM for personal server needs, like people use Digital Ocean and Linode and VPS providers for tons of personal/small business products today
(e) As for Windows, it wont stay out of the ARM game long (it already has a leg in). And even your developing world devs will easily find cheapo ARM computers for Linux/Windows.
I happen to care for fellow developers, and outside our Fortune 500 customers orgs, I haven't seen anyone being so lucky, and even then, Apple hardware tends to stay at MBA levels, unless they are doing iOS development.
I have seen devs teams where iMacs are timeshared across teams.
So most companies, if they have a mac, it is one on the side, so they can avoid 2).
(How do I know? I'm the only guy using mac in our org).
The costs are in setting up the whole infrastructure for managing and supporting a new class of devices.
Yes, but unless you are a new or very small company, they were already paid.
> The costs are in setting up the whole infrastructure for managing and supporting a new class of devices.
Exactly.
In my opinion that's pretty competitive.
Are we talking about enterprises here, with say, millions in revenue and a few millions in profit, or small shops that can't afford webservers and maybe use some shared hosting?
>I happen to care for fellow developers, and outside our Fortune 500 customers orgs, I haven't seen anyone being so lucky
Well, outside of the virtue signalling (and/or implying that I don't care for fellow developers), this is neither here, nor there.
It's not developing world SMEs that set industry trends, or have historically done so.
And we were talking about whether there will be a trend towards ARM in datacenters (helped because of the fact devs will now get more familiar with ARM, with M1 and similar ARM moves from MS).
It's not about whether Macs (or ARM) will be the architecture of choice for cash strapped companies in Freedonia.
(Plus, IT demand and ability to work / compete across the world, makes devs an exception related to their countries average wages. A local dev wage might be 1/2 or 1/5th of what a dev gets in Silicon Valley, but it's not 1/10 or 1/20 - as their national average across professions can often be. And such salaries still have them afford nice tools, Macs or high end PCs or similar).
(Also, Fortune 500? Never worked in one such company, and the ones I did are more like Fortune 1,000,000 but still Macs are extremely popular with devs).
As for the rest I won't bother to reply.
And I think his assertion is on point, in the sense that the widespread availability of desktop ARMs on developers hands will help drive ARM adoption to the datacenter (and that's just with the M1/M... line, not to mention further ARM adoption by MS that's also possible).
For what is worth, Linus Torvalds made a similar point regarding the influence of developer architecture options to server architecture choices (and especially regarding ARM).
I think that the objection "but developing world / poorer companies don't use Macs/M1" is valid, but not really relevant, kinda moving the goalposts. It's not those that set industry trends (and surely not in the US).
>As for the rest I won't bother to reply.
Well, I've replied to the arguments, with what I think is the case (and what I've seen).
Not sure if you were bothered that I took offense to the "I happen to care for fellow developers" line. But it sounded like an insult that wasn't called for, and was not relevant to the discussion.
In that case, I apologize!
Therefore all change is dependent upon the unreasonable person.
The world does not change for reasonable people.
But things are a bit different now, it’s much more convenient to work on a laptop, so most people do that. Maybe the pendulum will swing the other way and we’ll start timesharing again, with laptops as terminals instead of standalone machines, but even if that’s possible in theory, there are few providers of ARM in the cloud at the moment. It’s a chicken and egg problem and I think Linus is right, it’s going to take pressure from devs, most of whom IMO don’t care enough to make a difference.
The tipping point will be when deploying to x86 becomes annoying (for some measure of annoying). Right now, even though I’d personally like to deploy to ARM (or at least give it a red hot go), my cloud provider (Vultr) doesn’t support it yet, and I don’t personally plan to go ARM on my desktop until next year. But I’m a CPU enthusiast. Most people wouldn’t bother to go the the extra effort.
We used IBM X Windows terminals, and green phosphor text ones to connect to them.
By the time I graduated, they had been replaced by Red-Hat Linux.
88K DG/UX didn't last very long before they switched to x86, which we also had. Under my desk I had Motorola's 88110 system (a stackable with a SCSI floppy disk!) The thing that stood out most about DG was just how nice all their staff were. I mean really nice.
Even in those days it became very apparent that whatever workstations developers worked on were what was then best supported in the products even for non-GUI software. Slowly but surely the workstation vendors dropped support to server only, meanwhile Windows spread from workstations to servers even though it was considered inferior. Linux also spread for the same reasons.
The DG gear was awesome, the OS was great and even the support was terrific. Such a shame they died.
I never considered the rise of Windows as a development platform as being the driver for that failure but it makes sense. I used to work on X terminals and then Linux workstations, and with DG being strongly into GNU tools I didn’t see the Windows side of things at all until much later in my career.
But this really supports up the idea that if devs move to ARM, so will the cloud.
That may have contributed to their demise.
It's shocking that the Mac UX is so good that 75% of the developers out there would rather not use one... Meanwhile developers are the group that uses them more than the general population so both groups obviously disagree that Macs have a good UX at all lul.
As for the WM differences, its just a different way of thinking about it, or a preference. None of them really bother me, personally.
Having to remove some dangerously old GNU utils and constantly having to contend with Apple over your rights puts macOS squarely behind Linux and only just ahead of Windows (for work) in my book. If you haven't used Linux in years, try a rolling Arch based distro like Manjaro and you'll experience how little setup you actually need to get your job done. Heck, you don't even have to use the CLI to install every single piece of software you'll ever need. It literally takes minutes to setup. Windows and Mac simply can't compete in this area.
WM differences don't necessarily annoy me, but I don't tolerate people saying shit like "Mac UX is better than anything, period" because that is demonstrably not true for many, many, many values of "better". I have all three at home and at work and I use each one for what it's best at. Windows for gaming and entertainment. Linux for any sort of development. Macs for Apple/Mac/iOS stuff. They each have some obvious strengths, but anyone arguing that Macs are uniformly better for developers are clearly inexperienced IMO.
It was a bit of a process but once we got it working, developing on the M1 has been great. Captured notes on the process here in case it's helpful for anyone later: https://authzed.com/blog/onboarding-with-an-m1/
More than anything; starting on a new team, sorting out the provisioning process, meaningfully contributing to the team and doing a write up for their blog. I’d wager whoever hired you is very pleased.
I like the native posix terminal. Much of my work that I used WSL for works natively on Mac anyway.
The battery life is amazing, because I like to work away from an outlet occasionally when my mind needs it. This is the first laptop where I’ve felt comfortable leaving the house (for a full day of work) without a charger.
No fan noise, no heat, no throttling under typical workloads, and no worrying about blocking the intake vents like I did on my thinkpad.
I was concerned about the architecture support at first, but Rosetta 2 has been 100% seamless with the exception of some steam games I tested out, which I don’t care about anyway since this is 100% a development machine.
I don’t do super intensive workloads, but the m1 has been way faster for some of the nodejs work I’ve been doing. Some of my nodejs workloads are seeing a 10x performance increase over my i5 thinkpad.
And of course, you have to love the apple trackpad. I tried a few different Bluetooth mice, but I ended up just using the trackpad instead because the precision feels better than even an Mx master.
Now, cross compiling does suck. I have a few raspberry pis in a kubernetes cluster at home and am looking forward to the native compilation that this new release provides.
Idem if I run ARM locally, I'll deploy on ARM.
Of course this does not apply to interpreted languages or any of the modern languages (Go, Rust, Zig) that make cross compiling _somewhat_ easier.
But if desktop ARM becomes commonplace, it's a good indicator that ARM is finally competitive for "serious" workloads, and people might invest in it more.
As thing stands right now and IMO, it's getting there but Apple having M1 is not enough for me, as CTO, to look into ARM servers, if not as a curiosity.
I’d wager that right now the M1s are about the most bang for buck you can get on desktop machines.
So it matters in that not everyone currently has tooling working for ARM, but Apple silicon is going to push that along real fast.
https://www.anandtech.com/show/16610/nvidia-unveils-grace-a-...
Running docker containers on it was OK, and cross-compiling my golang monitoring stuff was easy enough.
But over time I just wanted to use my existing pipelines and deploy x86 stuff. So in the end it was a novelty, and while cheaper than an amd64 host it was eventually replaced so that I had a consistent set of deployment targets.
There's just one final remaining vendor dependency that we're running via qemu on x86 that's holding me back at this stage.
We are looking to switch over to Graviton ASAP. The cost/performance ratio is just too appealing to ignore now.
But I only did a x86 Linux container as a test, and it wasn't a great experience. Seemed visibly slower and crashed once.
So whether or not this suits your needs, I feel, depends on to what degree you need the "contract" that your local environment is the same as prod, because you're probably using x86 Linux/BSD boxes.
If Amazon and Nvidia's ARM server chips really pick up steam, then the M1 Macbooks would be the premiere local device.
I seriously doubt this is true if you include desktop computers in the comparison.
I didn’t realize this for a while myself, as the docker CLI tools are all free software. The “Desktop” variants are not, and embed spyware.
The other advantage of docker machine is that you can also ask for a cloud instance to run dockerd, and that's actually how gitlab-runner does it
Replacing Docker for Mac's kubernetes support is done with either kind or minikube depending on ones desire to have on a modern version versus "yeah, yeah, just run the VM and make kubectl work"
None of those setups have any provided gui/menubar widget support, or similar hand holding, which is why I started this the way I did
Do you have any more information about this? I tried to google it but couldn't find anything. Not that I doubt that this is happening...
First link is https://docs.docker.com/ee/telemetry/
Clicking it it redirects me to https://docs.mirantis.com/containers/v3.0/dockeree-products/...
> A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.
Just changing the kernel under which the container runs can break havoc on the "reproducible" build.
(although yes, the base filesystem might be different)
http://www.jakubkonka.com/2021/01/21/llvm-tls-apple-silicon....
I don’t think Apple would allow it, but it seems like an interesting antitrust wedge if they blocked it.
By native I mean:
FROM macos:10.13.2
RUN xcode-build <...>
(I mean the "you're not the target market" understand)
I feel like the real solution I should be going with is Parallels or qemu. Just wanted to know if there was something I'm missing.
I went and checked the issue when i saw they've made a formal release but it doesn't appear to be resolved. So maybe keep it in mind if anyone has issues trying to use docker now :)
Edit: I see Docker has closed the issue and encouraged people to simply use ARM containers instead. Unfortunately that's not an option for cross-compilation when you're using x86 servers. Something for people to keep in mind when deciding what laptop to buy next, i guess.
You don't actually need to run the same architecture you compile for, you just need a toolchain and environment that matches your target and a compiler for your machine's architecture that knows how to write to your target architecture.
It sounds more complicated than it is, really. How you go about doing this might vary by language, but as Docker for M1 takes off, you'll see more and more guides for doing "hard" things like compiling to x86.
Also, if you find that you're building Docker images on x86 machines and want to build Docker images for Arm as well, have a look at https://docs.docker.com/buildx/working-with-buildx/#build-mu... for example.
I recently had to wipe my machine to remove Rosetta (there's no "uninstall"), and saw quite a significant boost in performance across the board.