Live data from Hacker News

Docker fails to launch on Apple Silicon

github.com

231–240 of 281 posts

Re: Docker fails to launch on Apple Silicon

#231

This link is a little confusing because the top comment and much of the conversation is talking about the DTK which was based on the much older A12X CPU and not the M1. As far as I can tell, the M1 does have virtualization support, Docker just isn't ported yet. Update: Also, from Apple docs it seems like you won't be able to run emulation and virtualization in the same process. So you can run x86 Mac apps, but it's l…

Right, lots of confusion in this thread. A12Z/DTK: HW does not support virtualization at all. Apple M1 / New Apple Products: HW does support virtualization for ARM64 guests (both windows and linux demonstrated). What about x86 software in the guestOS? Not with Rosetta. Instead, the guest OS will have to provide its own translation (such as windows/arm's current x86->arm64 or upcoming x86_64->arm64 feature). I'm not f…

you should be able to run x86 vms through qemu. Just like running arm vms on x86 today

Re: Docker fails to launch on Apple Silicon

#232
thread goes from people being confused that the DTK isn't the same as the release hw, to someone complaining abut docker desktop spying on you, to arguing about whether or not you should test server software on your mac. I feel bad for people subscribed to that thread that care about the actual issue (wanting docker desktop to run on m1)

Re: Docker fails to launch on Apple Silicon

#233
post #148

Earlier quoted context omitted.

I switched off Mac years ago. My servers run Linux. Not bsd. Having to deal with this sort of stuff is just a waste of time. Mac's don't have a monopoly on quality, haven't for a long time. And since it's a usual response, anyone claiming Linux is too fiddly haven't used it in a long time. And while it can be if you want to roll your own DE its completely optional. Using something like fedora you can literally do alm…

Fedora is the new Ubuntu

I haven't touched fedora in a couple years. what's going on there?

Re: Docker fails to launch on Apple Silicon

#234

I've been holding off on upgrading my MBP13 for a few years now because Apple was painfully slow to refresh it. I was ready to order the model that came out in May (with 32GB RAM) but then the rumour about ARM hit the internets so I kept waiting. Now (I guess always?), it's clear that Apple Silicon is not going to be a comfortable dev environment, at lest not for some and not for a while. JDK macos/aarch64 port is st…

Up until this year, I had using BYOD MBP for both work and personal development, I'm on the late 2016MBP and it's been a great setup that allows me to both interact with corporate's exchange server, edit power point slides, WebEx screen share, and still develop for Linux servers.

End of last year, I switched jobs and have been forced onto a Windows laptop. I had been using VSCode, so after fighting with WSL1 and Docker on the work system for months, I installed a dedicated console only linux VM (under vmware workstation) within Windows and I use the VSCode's SSH remote option. It's pretty much seamless. The VM runs docker "natively" within it, the core part of vscode is running within the VM itself. There used to be a bit of confusion if you open a new vscode window, then you had to use that to open a second ssh-connected window. But last month, they changed that so you can connect the current window. When you open a folder or file, it's all like browsing the "remote" VM's filesystem. VSCode also now can auto-detect when you're starting a program on a localhost port and creates an ssh tunnel from your desktop to the remote system (you can also set these up manually if it fails to detect it). Sidebar: Now that WSL2 is available, I could see migrating from my Linux VM under VMWare to a WSL2 Linux VM under Hyper-V, but that's another level of effort for about the same end result.

Just prior to the pandemic, I had set myself up a linux desktop and made that my primary system (relegating my MBP to secondary/couch use). My work laptop was on a stand to the right and my MBP was on a stand to the left. I would use vscode to remote into either the VM on my work laptop or develop personal stuff locally. I also setup VSCode on the MBP to remote into the desktop. During the pandemic with kids home, I had to migrate from my detached garage/home office to inside the house. So I rarely touch my desktop directly and do my (personal) dev work remotely on it from the MBP.

In the future, should it come time to replace my MBP, I don't think I'll use another Apple. Since I can't BYOD it for my current job, and I don't need Outlook and PowerPoint for personal use, getting a hefty Linux laptop seems just fine for personal. If they would let BYOD MBP on the corp VPN, I'd consider it.

Re: Docker fails to launch on Apple Silicon

#235
post #233

Earlier quoted context omitted.

Fedora is the new Ubuntu

I haven't touched fedora in a couple years. what's going on there?

in my case, they ship a almost up to date kernel, they don't use snaps, vanilla gnome, the distro is very stable. The linux community I follow also likes where the distro is going and the overall "Fedora philosophy".

Re: Docker fails to launch on Apple Silicon

#236
post #189
post #153

Earlier quoted context omitted.

As someone who cross compiles C++ to arm (and others) as part of my $dayjob, I sincerely don't understand this comment. I would like to, as maybe there's something I misunderstand. Ninja edit: I guess you're suggesting that some parts are in hand rolled x86 assembly, not just pure C++ that would be output as the cross compiler target architecture?

There's usually a million assumptions that are technically undefined behaviour but work, and immediately break if you try to cross-compile by just changing the target system in CMake or w/e.

I could see that if it were being compiled against another libc as well. It's true my experience is with a codebase that has forever been cross compiled. Just altering the output architecture I guess I just haven't seen be an issue. Aarch64 hasn't ever given me an "immediately break" scenario. If it compiles, it works. Ymmv though. Computers are complex.

Re: Docker fails to launch on Apple Silicon

#237
post #155

Earlier quoted context omitted.

I guess the flip side is that, hopefully, the Docker ecosystem will start getting a lot better at multi-arch, at least for x86-64 and ARM. I just ordered an M1 MBP and I'll be quite happy to start thwacking bugs in images and upstreaming the fixes.

I naively assumed, until today, that the whole point of using linux in docker was that you get the multi-arch goodness of linux for free!

What multi-arch goodness of Linux? Linux can't magically run code from any architecture even without Docker in the mix, and unless someone is maintaining packages for your specific architecture, you're building them yourself.

Re: Docker fails to launch on Apple Silicon

#238
post #223

Earlier quoted context omitted.

That begs an even bigger why, given it's such an awful OS in many ways.

LOL. Because people value different things? I stay on MacOS because it works very, very, very well for what I want to do. There are a large number of affirmative reasons I prefer Macs. Hardware build quality has traditionally been stellar, on par with the golden age of Thinkpads (which is one reason the keyboard thing was so jarring). The OS is immensely, profoundly stable. The built-in tools for things like mail, co…

So much this, OSX remains a great tool for devs on X86. As much as I would love to move to Linux full time, I also don't want to think or deal with OS issues when I'm trying to write my code. OSX is far more polished than any other unix-based system out there, and there's a ton of support for any issues you might have.

I also love homebrew, it strikes a good balance between something like apt and windows-style installers. Toss all that together with the ecosystem that apple offers with it's other products (being able to send texts from my laptop via iMessage was a revelation) and you have one hell of a value proposition. There's a lot of valid criticism against apple but I can pretty much guarantee that 99% of the actual devs who rail against them use a MBP for work.

People have to understand that these are not your bargain-bin windows laptops, these are premium products. You wouldn't compare a Ferrari to a Toyota Camry, nor would you treat them the same or expect the same level of "performance" across all use cases.

Re: Docker fails to launch on Apple Silicon

#239

I've been holding off on upgrading my MBP13 for a few years now because Apple was painfully slow to refresh it. I was ready to order the model that came out in May (with 32GB RAM) but then the rumour about ARM hit the internets so I kept waiting. Now (I guess always?), it's clear that Apple Silicon is not going to be a comfortable dev environment, at lest not for some and not for a while. JDK macos/aarch64 port is st…

I've been using WSL2 for my personal projects on Win10 and it feels really good if you use VSCode. The "spaces" version of windows is better IMO which is a huge plus. It was very easy for me to go from my mac workflow to windows which I found surprising. Docker, Windows Terminal, VSCode, WSL2 all seem to work well for me. Windows 10 even has a spectacle equivalent-ish where you can drag and snap windows to create grids for your apps.

This allows me to go from development on personal projects to gaming and vice-versa which is very satisfying.

Re: Docker fails to launch on Apple Silicon

#240

Earlier quoted context omitted.

This will become less of a problem over time as more M1’s make it into the wild. What gives me pause moreso than this is the absence of the touchscreen and Face ID, which are very obviously coming in the next refresh (iPad app support without touch?). As impressive as the new MacBooks are, they’re very clearly a stopgap solution so as not to replace everything all at once.

> As impressive as the new MacBooks are, they’re very clearly a stopgap solution so as not to replace everything all at once. I agree, but at the same time, they pushed it pretty hard by not just doing an Air with the chip like I thought they would, but putting it in a Pro as well (with, according to the early benchmarks I've seen, barely any performance difference. I mean they could at least have put two of them in…

Re: the Pro and Air difference... expect the performance for anything long-running to be rather significantly different, I'd guess...
Post reply on HN