I get that remote development is a thing some people prefer, and if you have an underpowered machine it can be great to just use it as a thin-client and get all the power and performance you need without running down your battery or spending a fortune on local hardware.

BUT... you're recommending this as a workaround for limitations in expensive "Pro" local development machines, as part of an encouragement to go ahead and buy them.

Why not follow your advice and buy an old refurbed Macbook. Or any 2nd-hand machine of any brand. Or a low-end Chromebook.

To clarify: I'm not saying remote dev is bad, or you shouldn't recommend it. It's just really really weird to do so in this specific context.

It shocks me that so many people want to run Docker on a platform it was never built for. The suggestion above is not bizzare, it's a normal use case: run Docker on Linux like it's meant to be run.

Docker for Mac has had performance issues for years, especially related to file I/O. The common suggestion is to use NFS to get around those, which is just ridiculous when you think about it. [0]

[0] https://vivait.co.uk/labs/docker-for-mac-performance-using-n...

surely you can imagine a situation in which a developer prefers to develop on a mac but wants to deploy to a linux server though? that's the use case here.

This is the exact workflow that VSCode w/ remote is supposed to enable: you just connect to the VM and everything works. VM could be somewhere else. Or it could be on the local machine. Doesn't matter.

I don't want to maintain my own special-snowflake VM just to run docker containers on it. I want a dumb cattle VM running Container OS or an equivalent, whose only job is to run containers, ephemerally, connected to my host. The less it can do other than that, the better. In fact, best if it gets blown away on every restart.

Any statefulness is to be avoided, because a stateful Docker host might mislead me that my images will work in prod, when they're really dependent on something in my dev VM. Caches, databases, message queues? In development, they're ephemeral. Blow those containers away, please. I don't want any persistent volumes, host mounts, any of that. This is development, not deployment. Any data is just there to verify that the code is doing the right thing. Why would any such data need to live longer than the containers producing+consuming it?

(In the rare case that I do want a persistent database, I run it on the host. It's already a special snowflake; may as well treat it like one. As a bonus, this forces me to ensure my applications can target external resources using connection-string env-vars — which is almost-always relevant in production, where the DBMS is going to be some cluster external to the compute environment.)

> VM could be somewhere else. Or it could be on the local machine. Doesn't matter.

I don't know about docker itself, but I'm using Docker on Mac for Kubernetes "application" development. Targeting my commands to my local Docker-on-Mac k8s cluster vs a remote one is just a `kubectl config set-context` away. (Or you can do the same from the Docker on Mac tray menu.)

Yet, it works, and well, your shock notwithstanding.

If your goal is a SINGLE portable, virtualized platform for your developers, which does not require a persistent internet/SSH connection, and which is "fast enough" for developers to be effective, Docker on Mac is a pretty swell solution.

You can dismiss this but if your dev shop is doing dev work that lands in a k8s cluster, it sure is nice to just have devs install docker desktop for Mac and they have a fully functioning k8s cluster that just works.

My whole company uses macs except me. I had to spend a bunch of time figuring out how to get a dev environment working on Linux. And it wasn’t easy as none of the out of the box k8s solutions support how we developed our build system. If I wasn’t a k8s admin from early versions of k8s I would have just given up.

No platform is perfect.

It sounds like your company built its dev tooling specifically around Docker for Mac. It's not surprising that it was a pain to replicate on Linux your company's work as a sole programmer.

But that doesn't mean that Linux doesn't support Kubernetes well. Linux is the primary target for k8s! It runs more efficiently and has better support than Kubernetes on Mac. Minikube has worked as a dev cluster on Linux long before Docker for Mac shipped a k8s dev cluster.

(I, too, have been involved with Kubernetes projects since the early days, and have built k8s tooling at fairly large companies.)

Go install docker desktop for Mac. Click a preference and you have kubernetes.

That is not the case in Linux. Can you install kind? Sure. Can you install minikube? Sure.

And define support? To give you a simple example, in minikube on Linux how do you make local images built by docker available in minikube?

https://hasura.io/blog/sharing-a-local-registry-for-minikube...

It involves using dockerhub (rate limited) or running another local registry that you retag and push.

How about docker for Mac? No changes required at all, if the image is in the docker registry, it works in kubernetes

This is the exact type of retagging non sense that I hate in a dev workflow and is completely hacky.

So I solved it myself using k3s but I don’t think I have seen anyone else tackle it on Linux. Especially not minikube or kind

This is nonsense. We invested multiple man month this year to create a local k8s dev environment for our company. Our devs use MacOS and Linux. Me and my colleague evaluated various solutions for running k8s locally, all of which worked fine on Linux out of the box, while the process of setting them up for MacOS was riddled with issues (mostly around performance).

Yeah, I came to say the same thing - if you are anyway going to do remote dev, why still bother buying a new Apple device?? Anything else will do fine too!

My desktop is an AMD Threadripper 299WX running FreeBSD. My laptop is a mid-2014 MBP. I can build a kernel about 8x faster on the AMD than in a VM on the mac. So when I'm away from my desk, I use the MBP to ssh to the AMD and do all my dev there.

My biggest problem with my current MBP is that the battery life is down to 1-2 hours. Less if I have a video call.

I could maybe just use a chromebook or windows laptop, but the Mac "just works" for all kinds of corporate stuff and is the path of least resistance.

That's why professional laptops lets you change the battery. As we're professionals, we use our laptops a lot, so the battery needs to be exchangeable without having to buy a new laptop, so you can restore the same battery life as you had to initially.

Now any professional laptop (except the "modern" Apple ones) let you change the battery, if you don't want to do 3rd party repairs yourself. But I highly recommend you either change your battery in a repair shop, or get a laptop meant for professionals, ThinkPads are pretty good in that area. And if you do a lot of remote dev, it doesn't really matter which one, as long as it has a good WiFi card so remote latency/jitter gets as low as possible.

For me it'd be because of the User Interface.

I'm not disagreeing with you per se. Simply pointing out there are other considerations when selecting hardward.

For example : https://www.ebay.com/itm/Lenovo-ThinkPad-X1-Carbon-6th-Gen-i...

I don't think my manager would take it well if I told him that my used eBay Thinkpad is broken and I need to find a replacement before I can work again.

It took Apple 32 days to get my MBP 16" repaired, returned under Crapplecare.

Better yet, get the office to pay for it, if they're going to be so demanding.

The interesting thing here is, is it really a game changer in practice for something like web development and every day computer usage?

I'm not here to start a mac vs windows war but I have a 6 year old i5 3.2ghz CPU (4 cores, no HT) with 16gb of memory and a first gen SSD.

I use this workstation for full time development / ops work on Windows with WSL 2 / Docker, etc..

Everything is still pretty damn fast and it feels no different than the day I put together the machine.

Opening Chrome from hotkey to being able to type takes a second. Opening a terminal feels instant. Working with Vim and 50+ plugins has no type delay. Disk I/O feels good. I can keep multiple VMs running, run multiple Dockerized large web apps in various web frameworks, open 20+ tabs in a browser and a bunch of other stuff and it doesn't break a sweat. Sometimes I forget that I have image editors and other stuff open in virtual workspaces too.

I also do a lot of screencast recording / editing. The only part of my workflow that feels sluggish at times is rendering videos but that ends up being a non-issue because if I need to export 75 videos for a course I queue them up before I goto sleep and it finishes before I wake up the next morning. For 10-20 minute videos here and there I just render them before doing something where I go AFK (showering, eating, going outside, etc.).

I guess what I'm getting at here is, I'm not sure how a faster CPU will really help that much in my day to day besides crushing benchmarks.

Are folks running non-M1 MBPs experiencing slow downs in their day to day where they feel compelled to get one with an M1? Where do you see and feel the performance wins in practice?

I assume a significant amount of long-term Mac fans give Apple shit not because they're comparing to other ecosystems, but to an ideal of Not Sucking.

I agree with that in principle, but in practice Docker development on Intel MacOS already performs so poorly that it’s effectively broken anyway. I’ve actually been looking forward to Apple Silicon in the hopes that Docker starts over again and gets things working without the constant CPU pegging and 5-10x performance penalty.

I don't use Docker on Mac, but I'm curious how much of the performance penalty is attributable to VirtualBox. I use a VirtualBox-based Vagrant environment, and the performance is awful. It mostly comes down to terrible disk performance due to how VBox shares directories from inside the VM to the host filesystem. Apparently it can be fixed entirely by switching to local NFS, but I haven't had any success getting that working.

So, if I like all those things, but I can’t build a docker image locally (for now), why not just do something that will potentially improve my development experience in addition to allowing me to use this machine?

I mean, folks should do what they want. But, I’d say calling this recommendation bizarre to be a bit over the top :)

I personally would wait until Docker works, if that was a problem for me.

I totally believe that, but the question is, how good of an option is it for a powerful, expensive laptop.

If I were in IT, I'd not be buying M1 laptops right now for the company. However, for a personal development workhorse, I'd jump on it. I wouldn't miss local docker.

One of the great things about docker is/was that one can develop locally and the same thing would run when deployed. Having to run it on a distant machine kind of ruins this.

That's great, if you're doing something that will fit in a laptop. But I think the OP's point was that people using large datasets, complex workflows, or multiple projects, his method makes sense and saves money on buying new hardware.

For example, the web site I'm going to putz with today is many GB larger than the unformatted capacity of my laptop's SSD.

One could argue that even the "cheapest M1 + paying your remote Docker/Compute friendly machine" is not really the cheapest option. At least do not convince yourself "the new M1 chip is faster and will improve my developer experience regarding compute"

You don't buy a Mac because it's the "cheapest option". You buy it because you value several extra conveniences (displays, trackpads, speakers, construction, weight, baterry life, even keyboard - before and after they've messed theirs up for 3 years). Sure, it's not better in all of those than a comparable in price PC laptop, but it's usually better in most, and unaproachable in others. The SSDs it comes with are speedy as hell also (compared to the options Dell or Lenovo has on comparably priced models).

The CPU/GPU you can find in PC a too. At least until the M1, which has the best performance/power ratio of any current PC CPU. Plus there's always macOS, which lets you have a no-fuss desktop OS than runs all your proprietary apps and a native UNIX (as opposed to WSL/WSL2). Plus an ecosystem, drivers for your external peripherals (as opposed to the hit-and-miss Linux experience).

But it's not about saving money, and "I could the same work while spending less".

Obviously there are arm servers but they're not in widespread use.

I couldn’t figure out how best to fit VSCode though. It works remote, and with docker, but it seems very tricky with both?

e.g running a ruby linter inside docker on a remote box and seeing lint errors on my local VSCode.

Any pointers or tips?

But you get the compatibility and still keep the Air’s absurd battery life, so it wouldn’t necessarily be a bad setup.

Especially if you buy M1 hardware to take advantage of the machine learning enhancements.

You could buy a chrome book for less than Apple silicon and do remote development.

To me it feels more like going back to the way things used to be. Reminds me of when I used to do my work by pushing buttons on a Wang terminal in one state, and the PR1MEOS machine that I was actually working on was several hundred miles away.

Maybe as our work becomes more complex, it makes sense to return to thin clients.

The kicker is who owns the super computer you're dialing into, and how much of it you actually own. "Back in the day" it probably made sense for a company to maintain their own servers.

But now it's too profitable to not use amazon in most cases. It's nice not needing a server room, but hat suffers is ownership issues with infra and data, accepting the outages, and rolling with the crazy decisions amazon might make in the future that will effect your systems.

It works extremely well.

I would rather use my workstation's CPU & memory resources to actually compile the code rather than masking the complexity of moving that compilation process onto hardware which I do not own.

On the other hand, I'm worried it's going to be used to (attempt to) "take away" our ability to compile locally rather than giving us an amazing, immutable, local dev environment.

It's how I work now, a lot of vs code remote and ci/cd anyway.

That being said I am ordering my M1 air .. for reasons, definitely just lusting for a new upgrade.

There was a recent discussion on Hacker News about the use of abbreviations and acronyms and how they drastically reduce the legibility of posts.

But yes 100% agreed, especially this one as it's really hard to google for..

- Is there a way to forward local ports to the remote docker instance? So I can access the app on "localhost:3000" as usual? (OAuth setups make the app URL a pain to change)

- Is there a way to "mount" local volumes on the docker instance? (Reaction Commerce mounts the code folder as a volume. Altough that project has other issues, that's the main thing that kept me from using it).

Mounts: it's equivalent to mounting a remote file system. Docker -> server -> local.

https://www.lenovo.com/us/en/desktops-and-all-in-ones/thinkc...

If anyone has some good tips for this, I would greatly appreciate it.

At least you'd be getting the impressive battery life from the power efficiency courtesy of RISC ... Still rather silly though.