Lightweight Alpine VMs on macOS(beringresearch.github.io)
beringresearch.github.io
Lightweight Alpine VMs on macOS
https://beringresearch.github.io/macpine/
97 comments
The container landscape is getting crowded. As a person who just wants to get things done with containers it’s not immediately obvious where I should be focusing my efforts due to the proliferation of “container solutions”. It seems especially bad on the mac right now.
Colima is all you need now, it's basically a drop in replacement for docker desktop. There are actually very few container runtime engines (containerd and runc are the big ones) and all the tools you read about just wrap that lower level container runtime. They're all the same when you get down to it and just have different opinions about config, networking and storage.
Every tool says its the same but they aren't. You'll eventually run into some issue that wouldn't have happened on Docker, and as soon as a dev spends two hours on it you've paid more than you would have paid for a Docker Desktop license for that dev for the year.
To be fair, you'll run into issues with Docker Desktop too though. I've found Rancher Desktop to be as reliable or better than Docker for my needs.
Why not using Nix? No container needed, so it's much simpler, and the software selection for aarch64 (i.e. M1) is enormous.
Doesn't NixOS require reboot after each software install? I don't remember the last time I restarted my Mac or even PC.
I believe NixOS does not (there's a "nixos-rebuild switch" command that sounds vaguely like it requires a reboot, and NixOS does aim for declarative confgs, but it knows how to restart services etc. without rebooting your whole machine - see chapter 3 of the NixOS manual: https://nixos.org/manual/nixos/stable/index.html#sec-changin...)
But the proposal here isn't about running NixOS as your OS, since we're talking about macOS. It's about using Nix as an additional package/environment manager on top of another OS/kernel, in this case macOS, though of course Linux is well-supported too.
Each file in Nix is stored in a path that's computed based on the hash of the relevant source code, and depends on other files (e.g., libraries) via their hash-based paths, too. So you can straightforwardly have multiple execution environments with their own dependencies that don't interfere. It's an alternative solution to the dependency problem: containers leave paths alone, but create a new root filesystem for each container. Nix programs all share one root filesystem, but modify the paths so nothing uses e.g. /usr/bin or /usr/lib.
Precisely because Nix binaries isolate themselves from /usr and carry their own dependencies, the Nix packaging repo "nixpkgs" can be used on any Linux machine, not just NixOS ones. And the Nix folks also build nixpkgs for macOS, so most software in nixpkgs can be installed on a macOS machine too. This gets you a solution to the dependency problem on macOS itself (because there are no Linux-style containers on macOS). If you want, it also gets you a relatively consistent dev environment for applications that will be eventually deployed on Linux: although the kernel is different and of course the binaries are compiled for different kernels, the entire userspace can be the same on macOS and Linux.
But the proposal here isn't about running NixOS as your OS, since we're talking about macOS. It's about using Nix as an additional package/environment manager on top of another OS/kernel, in this case macOS, though of course Linux is well-supported too.
Each file in Nix is stored in a path that's computed based on the hash of the relevant source code, and depends on other files (e.g., libraries) via their hash-based paths, too. So you can straightforwardly have multiple execution environments with their own dependencies that don't interfere. It's an alternative solution to the dependency problem: containers leave paths alone, but create a new root filesystem for each container. Nix programs all share one root filesystem, but modify the paths so nothing uses e.g. /usr/bin or /usr/lib.
Precisely because Nix binaries isolate themselves from /usr and carry their own dependencies, the Nix packaging repo "nixpkgs" can be used on any Linux machine, not just NixOS ones. And the Nix folks also build nixpkgs for macOS, so most software in nixpkgs can be installed on a macOS machine too. This gets you a solution to the dependency problem on macOS itself (because there are no Linux-style containers on macOS). If you want, it also gets you a relatively consistent dev environment for applications that will be eventually deployed on Linux: although the kernel is different and of course the binaries are compiled for different kernels, the entire userspace can be the same on macOS and Linux.
nixos-rebuild switch does not require a reboot. In fact, you'd typically use nixos-rebuild boot if you don't want immediate changes.
For very complicated reconfigurations, it might be advisable to reboot if that involves changes to services that are only started during boot time. But that's the case for nearly any OS...
For very complicated reconfigurations, it might be advisable to reboot if that involves changes to services that are only started during boot time. But that's the case for nearly any OS...
I mean Nix on a Mac, as a package manager, not full NixOS. Linux is still not totally ready on M1 machines.
And of course it does not require a reboot.
And of course it does not require a reboot.
No
`containerd` invokes `runc` (and `docker` can also invoke `containerd` via its API, which then invokes `runc`). The "lower level container runtime" is cgroups and various kernel namespaces (primarily process and network, but some others are included). There's no magic there.
They are not all the same when you get down to it, though. The "different opinions" about how to plumb traffic back out from a container (DNAT/SNAT via a bridge, macvlan, whether using a CNI directly is supported), whether a service/daemon should be the primary entrypoint (docker, containerd) or whether it's optional (podman), whether they speak to runc at all (containerd/docker yes, podman defaults to crun, kata is also an option, and others), what kind of storage overlays and plugins are allowed, etc are more than "opinions".
The devil is in the details. Colima is "basically a drop in replacement for docket desktop" under the assumption that you aren't doing anything very complex with Docker. In particular, complex networking is likely to fail/explode.
They are not all the same when you get down to it, though. The "different opinions" about how to plumb traffic back out from a container (DNAT/SNAT via a bridge, macvlan, whether using a CNI directly is supported), whether a service/daemon should be the primary entrypoint (docker, containerd) or whether it's optional (podman), whether they speak to runc at all (containerd/docker yes, podman defaults to crun, kata is also an option, and others), what kind of storage overlays and plugins are allowed, etc are more than "opinions".
The devil is in the details. Colima is "basically a drop in replacement for docket desktop" under the assumption that you aren't doing anything very complex with Docker. In particular, complex networking is likely to fail/explode.
I recently switched from Docker Desktop to Rancher and it seems to not slow down my Mac so much.
Does Colima work with Docker Compose?
Does Colima work with Docker Compose?
Compose is a layer on top of the Docker client/API, so the container runtime provider shouldn't matter, I guess as long as there's a real dockerd under the hood, and modulo any bugs.
Rancher lets you choose between dockerd and moby. Does that mean Colima also uses dockerd?
I think you'd need a particular reason to not use Docker.
Last time I tried using Docker Desktop on my MBP (x86), the reason to not use Docker was that it was excruciatingly slow for the test suite I had to run in it, compared with Docker on Linux.
I abandoned Docker on the Mac because of that, and haven't touched it since. That was early 2021; maybe it's faster now.
I abandoned Docker on the Mac because of that, and haven't touched it since. That was early 2021; maybe it's faster now.
It’s the cross-OS filesystem stuff that always killed it on Docker for Mac (and to a lesser extent Docker for Windows).
I believe improvements have been made, but a lot of people these days check out their code directly in the container rather than using bind mounts, leveraging the fact that a lot of editors/IDEs now will interface directly with the containers.
I believe improvements have been made, but a lot of people these days check out their code directly in the container rather than using bind mounts, leveraging the fact that a lot of editors/IDEs now will interface directly with the containers.
That’s been massively improved with VirtioFS. I work with mounted code and I agree it wouldn’t be possible without it.
Docker Mac m1 is my daily driver. Painless performance.
But... watch out for software compatibility: m1/m2 requires recompiling from source which is painless... when it works. I recently needed syslinux and had to move to x86 cloud instance. Fortunately, docker made that easy.
But... watch out for software compatibility: m1/m2 requires recompiling from source which is painless... when it works. I recently needed syslinux and had to move to x86 cloud instance. Fortunately, docker made that easy.
It takes more time and effort than just running the damn script! Is that not good enough?
I mean I want to use containers but on top of setting up the host, they require composing containers (even when ready made for customizations), networking, logging and fight for more memory when using memory hungry stuff in conjunction (like elastic or other db).
If my main job was devops, I suppose I would make myself more valuable by doing everything in containers but when I deploy an app it is because I have to on top of many other duties so being able to not only setup but troubleshoot and fix outages quickly is most important (and I hope a full time devops person, if I ever get one) will help me migrate all that some day so it looks nice and neat.
I mean I want to use containers but on top of setting up the host, they require composing containers (even when ready made for customizations), networking, logging and fight for more memory when using memory hungry stuff in conjunction (like elastic or other db).
If my main job was devops, I suppose I would make myself more valuable by doing everything in containers but when I deploy an app it is because I have to on top of many other duties so being able to not only setup but troubleshoot and fix outages quickly is most important (and I hope a full time devops person, if I ever get one) will help me migrate all that some day so it looks nice and neat.
If you don't want to use containers at all then that's a different question than the one I I was responding to.
Fair enough.
Docker Desktop is:
- spyware (transmits private data off your machine without consent when it crashes, which it does a lot)
- nonfree software
- has a git repo so you don't notice it's nonfree software
- spyware (transmits private data off your machine without consent when it crashes, which it does a lot)
- nonfree software
- has a git repo so you don't notice it's nonfree software
Does docker support true x86_64 emulation on arm64 hosts?
No, and that’s a pretty good reason to not use it if you really need that.
What can you use to do that?
What can you use to do that?
Currently using straight up lima and software emulation. It’s slow but it just about works.
I think there’s stuff that uses it under the hood like colima and rancher.
Basically the issue is that quite a lot of software is amd64 only and they haven’t cross complied binary layers for arm64.
So for local development you have to emulate.
It’s a shame there’s not a way to leverage rosetta2 really.
I think there’s stuff that uses it under the hood like colima and rancher.
Basically the issue is that quite a lot of software is amd64 only and they haven’t cross complied binary layers for arm64.
So for local development you have to emulate.
It’s a shame there’s not a way to leverage rosetta2 really.
There is, it works wonderfully well but you have to do a lot of things manually for now.
I thought that was a limitation that Apple put in place.
You can either run an alternative architecture or an alternative OS. Running MacOS software for x86 is running through an interpreter.
If you want to run x86 Linux software, then MacOS on Arm is just one too many steps away.
You can either run an alternative architecture or an alternative OS. Running MacOS software for x86 is running through an interpreter.
If you want to run x86 Linux software, then MacOS on Arm is just one too many steps away.
I do have a particular reason - memory use. I am running postgres and redis locally for dev work, but I would love to use Docker so that I can standardize it for my team, but it just takes up to much ram on m1.
I don't mean to sound flippant, but that sounds like you're using a computer for business that can't handle the work you are trying to do. If 32/64GB isn't enough memory then yeah, I guess you need something else, but if your machine has less than that then it sounds like you need to buy the right computer for the job.
Also, are you using AMD or ARM images for those?
Also, are you using AMD or ARM images for those?
I dunno about the m1 aspect of this but postgres and redis for typical dev work shouldn't require more than a gigabyte or two of RAM when running together. 32-64GB is more like heavy traffic enterprise DB territory...
guess the parent is annoyed at spending 2-3GiB of ram on the VM itself.
even if the containers themselves only use 128MiB total: the VM will cordon off everything it's told to; which most people are unlikely to change until there's an issue, and is configurable down to 1GiB as a minimum.
FWIW Docker Desktop on my machine (M2 Macbook Air; 24GiB Ram) defaulted to using 8GiB of RAM.
even if the containers themselves only use 128MiB total: the VM will cordon off everything it's told to; which most people are unlikely to change until there's an issue, and is configurable down to 1GiB as a minimum.
FWIW Docker Desktop on my machine (M2 Macbook Air; 24GiB Ram) defaulted to using 8GiB of RAM.
They're also trivial to install without virtualization. Postgres has been one of the first things I install on a new laptop for over a decade now.
Also, stop using a Mac if they aren't suitable for your usecase. There are just so many layers of emulation for this, it's an absolute waste of resources.
This is the right answer.
Scratching my head as to why devs are buying up these new macs knowing up front that they will not work well for the job they were bought for.
Why not make it easier for yourself and have your dev machine match up with prod?
Scratching my head as to why devs are buying up these new macs knowing up front that they will not work well for the job they were bought for.
Why not make it easier for yourself and have your dev machine match up with prod?
You can setup how much ram is allowed in docker. Generally software will use as much as you allow (especially DB)
Your team might want to use asdf https://github.com/asdf-vm/asdf to run multiple native versions of PostgreSQL and Redis in parallel. Even with one project you might have multiple versions of those tools in different releases of the project. You standardize by using a .tool-versions file. I've been using that for a team targeting Linux and developing on Ubuntu, Mac and WSL (or was that an Ubuntu VM in Windows?)
Many companies run dev work in a dedicated cloud VM.. incl well known companies like Google or Amazon.
You can run a constant VM with 2/4/8/128gb of ram or whatever you need. I use one at work for years and I think mine is 16gb of ram and it’s way over provisioned most of the time. Unlike how you might expect, treat the cloud vm like a work laptop not a production service. Let people write scripts that stay there, let people keep it on 24/7, available on demand, etc. It’s a cloud laptop not a production VM.
You can run a constant VM with 2/4/8/128gb of ram or whatever you need. I use one at work for years and I think mine is 16gb of ram and it’s way over provisioned most of the time. Unlike how you might expect, treat the cloud vm like a work laptop not a production service. Let people write scripts that stay there, let people keep it on 24/7, available on demand, etc. It’s a cloud laptop not a production VM.
Depending on your workloads that sounds like a very expensive way to do development compared to just having a dedicated but efficiently set up work laptop.
Even giving people a headless Intel NUC to connect their laptops too would be way, way cheaper (assuming you're just doing development).
Even giving people a headless Intel NUC to connect their laptops too would be way, way cheaper (assuming you're just doing development).
Where I work, they used to give you desktop computers (pre Covid) for the workstation purpose, but post-covid they just provision a VM for you. Honestly, its probably cheaper in short-term and only mildly more expensive long term. No real IT work needed (since <cloud provider> handles the hardware), and automatic upgrades if more ram/GPU/etc is needed. Even a really big VM ($80/m) wouldn’t be crazy compared to the logistics of managing/storing/powering/networking a bunch of desktops across an office.
This is what I wonder. A powerful local laptop is so useful - instant feedback; works on the train or any other offline/low-connectivity setting; the only engineer you need looking after it really is the one who has it.
Having said that, cloud development means you don't need big capex orders for laptops all the time, and it's probably easier to secure.
Having said that, cloud development means you don't need big capex orders for laptops all the time, and it's probably easier to secure.
I use a 16gb m1 air. I'm running docker desktop with mysql, redis, 2 containers doing python, a node container and an nginx container. I'm not noticing any impact on performance. MS Teams hurts more to run. Though I have adjusted the resources docker uses.
I never understand the "docker takes up too much space/ram" objection. Isn't that configurable/manageable even from the GUI?
Colima or Rancher Desktop seem to be what most developers at my place of work have coalesced around these days.
Colima is a little but lower level but works very well. Rancher Desktop had some struggles a while back but most of the developers who are new to the company seem to be using it for local kubernetes.
Colima is a little but lower level but works very well. Rancher Desktop had some struggles a while back but most of the developers who are new to the company seem to be using it for local kubernetes.
Just use docker. It always works well enough and there is tons of support available online for any conceivable situation you might find yourself in.
Title says "on macOS".
That's the key part: Your positive experience is with PCs running linux I guess.
That's the key part: Your positive experience is with PCs running linux I guess.
I know this is a stupid argument from my part, but I see this enormous effort to use tools that work really really well on Linux, but on a Mac. Why not just use Linux and save yourself the effort, performance overheads and whatnot? 99% of the time the loads are being deployed on Linux servers, why not use it in the workstation as well? Is it worth JUST for the hardware?
Replying here also for the other comments.
Imho Mac hardware, especially with M1/M2 is the best value for money one can buy right now. Performance is outstanding, coupled with all day battery life. Build is also super premium including the keyboard now. I tried Lenovo X1, Dell XPS 13 which are supposedly the best PC laptops and found them way inferior... and more expensive!
Regarding macOS, I completely understand that some people like it, some don't. But we all want good tools on that hardware :)
Imho Mac hardware, especially with M1/M2 is the best value for money one can buy right now. Performance is outstanding, coupled with all day battery life. Build is also super premium including the keyboard now. I tried Lenovo X1, Dell XPS 13 which are supposedly the best PC laptops and found them way inferior... and more expensive!
Regarding macOS, I completely understand that some people like it, some don't. But we all want good tools on that hardware :)
Mac seems to offer a more similar experience to Windows when it comes to corporate remote administration.
So Macs are what corporate provides to developers.
So Macs are what corporate provides to developers.
The hardware is great, but it’s not just the hardware.
There are also some pretty good apps for macOS that just aren’t available on Linux.
And then some of us really enjoy the desktop experience of macOS.
When I need Linux tools they are easy to access via Lima. (One could also use Parallels or VirtualBox, but IMHO Lima is far more ergonomic.)
There are also some pretty good apps for macOS that just aren’t available on Linux.
And then some of us really enjoy the desktop experience of macOS.
When I need Linux tools they are easy to access via Lima. (One could also use Parallels or VirtualBox, but IMHO Lima is far more ergonomic.)
It works well on a mac. Only arm64 is a challenge.
But do any of these alternatives perform better on macOS? Under the hood they end up using the same underlying technologies, so there shouldn't be much performance difference between them.
Dockerfile + Docker compose is the way to go. With Portainer, you'll be up and running in less than 30 min.
I'm really not a fan of that docs website/static page generator - or maybe it's the way the content has been laid out - it shouldn't take so many clicks and full screen refreshes to get basic information that could each be a heading on a single page so you can grep for words, use the mouse less etc....
I think they have split it into far too many small pages, the whole CLI section should be one page, if not the whole lot.
Slight aside though, they have used the Material theme for MKDocs, which is much more than a theme, it's a whole extension package of bells a whistles for MKDocs. I'm not actually too keen on "Material for MKDocs" [0], I like all the clever plugins, but the theme itself I find distracting and too "loud". The theme jumps out more than the content itself.
In the Python ecosystem Material for MKDocs seems to be the leading default at the moment, however I much prefer Furo for Sphinx, it's much cleaner, it's about putting the content front and centre. It does also have a similar set of plugins for Sphinx adding those bells and whistles.
0: https://squidfunk.github.io/mkdocs-material/
1: https://pradyunsg.me/furo/
Slight aside though, they have used the Material theme for MKDocs, which is much more than a theme, it's a whole extension package of bells a whistles for MKDocs. I'm not actually too keen on "Material for MKDocs" [0], I like all the clever plugins, but the theme itself I find distracting and too "loud". The theme jumps out more than the content itself.
In the Python ecosystem Material for MKDocs seems to be the leading default at the moment, however I much prefer Furo for Sphinx, it's much cleaner, it's about putting the content front and centre. It does also have a similar set of plugins for Sphinx adding those bells and whistles.
0: https://squidfunk.github.io/mkdocs-material/
1: https://pradyunsg.me/furo/
Author of Material for MkDocs here. I totally understand that some people don't like Material Design, as it's just everywhere nowadays and can be considered a bit overused. However, with little effort, you can adjust the style of Material for MkDocs with a few lines of additional CSS [0] and fit it to your taste. For example, several days ago I did this [1] in 20min. Nevertheless, Furo is an awesome theme if you like to use Sphinx over MkDocs!
[0]: https://squidfunk.github.io/mkdocs-material/customization/#a...
[1]: https://twitter.com/squidfunk/status/1598341366869856257/pho...
[0]: https://squidfunk.github.io/mkdocs-material/customization/#a...
[1]: https://twitter.com/squidfunk/status/1598341366869856257/pho...
I don't see the point of a dedicated tool for this when it is easy enough just to start a Alpine docker container with a couple commands. As this project is just a wrapper for docker and LXD[1] and those tools are already easy enough for the average SWE to interact with, the project seems to just over-complicate an already existing workflow.
[1] https://github.com/beringresearch/macpine#motivation
[1] https://github.com/beringresearch/macpine#motivation
There's related discussion from earlier today at https://news.ycombinator.com/item?id=33762657 for LXD
This is like the 5th or 6th frontpage macOS container strategy this week. Wouldn't it be better to have native containers by just using Linux? What advantage do people get hy using macOS?
Great laptops and hardware; low hassle setup. There is some initial linux support for the M1 hardware but using mac os is a bit easier. The instructions for getting docker going on a mac are a lot shorter than getting linux going on an M1. So, if you have one, figuring out how you are going to run docker is something to do. And there are many options now.
I actually have a Manjaro laptop that I used for work for almost a year and it was great. Except for the hardware (generic cheapo wintel garbage). I'm back on a Mac now. Nice M1 laptop. Fast, silent, good keyboard and screen. Wonderful to use. Mostly my biggest headache is muscle memory for different key bindings and keyboard layout because I still use the linux laptop once in a while. But otherwise all my stuff (including docker) just works on both sides.
Docker for mac is nice but the licensing can be a bit of a show stopper. I've yet to try some of the alternatives mentioned here. I did use qemu on my old intel mac for a while with some simple environment variables to make the homebrew version of docker use ssh to my vm. It works but it can be a bit wonky with things like port forwarding and volumes. You can make all that work but it is a bit fiddly. Most of the proper alternatives make this a bit more seamless. But I'd recommend trying it just to de-mystify the whole process.
There is a docker desktop for linux even; which just goes to show that it does do a few things that are worthwhile having for some people. Even on Linux. I'm mostly a cli guy so I don't care about the UI/UX that it provides. But some people seem to like that.
I actually have a Manjaro laptop that I used for work for almost a year and it was great. Except for the hardware (generic cheapo wintel garbage). I'm back on a Mac now. Nice M1 laptop. Fast, silent, good keyboard and screen. Wonderful to use. Mostly my biggest headache is muscle memory for different key bindings and keyboard layout because I still use the linux laptop once in a while. But otherwise all my stuff (including docker) just works on both sides.
Docker for mac is nice but the licensing can be a bit of a show stopper. I've yet to try some of the alternatives mentioned here. I did use qemu on my old intel mac for a while with some simple environment variables to make the homebrew version of docker use ssh to my vm. It works but it can be a bit wonky with things like port forwarding and volumes. You can make all that work but it is a bit fiddly. Most of the proper alternatives make this a bit more seamless. But I'd recommend trying it just to de-mystify the whole process.
There is a docker desktop for linux even; which just goes to show that it does do a few things that are worthwhile having for some people. Even on Linux. I'm mostly a cli guy so I don't care about the UI/UX that it provides. But some people seem to like that.
MacOS contains tons of nice usability as a working environment, and even has great rolling package management with Homebrew, but the lack of native containers is the single biggest downside, basically preventing us from using containers more extensively at my work. The blocker for us is data work that needs a lot of memory locally, meaning it wouldn't work for us to allocate it to a VM for containers.
> What advantage do people get hy using macOS?
The question applies both ways: what advantage (other than native container support) do I get by running Linux?
Personally I would love to see OCI containers supported natively on other operating systems. Currently you get the same VM crapshow on e.g. OpenBSD, except the community is several orders of magnitude smaller, so you don't even get prepackaged solutions.
The question applies both ways: what advantage (other than native container support) do I get by running Linux?
Personally I would love to see OCI containers supported natively on other operating systems. Currently you get the same VM crapshow on e.g. OpenBSD, except the community is several orders of magnitude smaller, so you don't even get prepackaged solutions.
I get the advantage of transparent source code, a vibrant community supporting amazing projects, first-class support for new concepts and features.
> Personally I would love to see OCI containers supported natively on other operating systems. Currently you get the same VM crapshow on e.g. OpenBSD, except the community is several orders of magnitude smaller, so you don't even get prepackaged solutions.
Talk to your OS vendor. They are the ones who are preventing this from working.
> Personally I would love to see OCI containers supported natively on other operating systems. Currently you get the same VM crapshow on e.g. OpenBSD, except the community is several orders of magnitude smaller, so you don't even get prepackaged solutions.
Talk to your OS vendor. They are the ones who are preventing this from working.
I find it odd that you used both "it's a community project" and "talk to your vendor" in the same reply to address the same concern.
Why? Linux is a community project that is open source, and containers are based on Linux. If you want native support for your proprietary OS then talk to your proprietary OS vendor since they are the one who should be supporting it.
OpenBSD is proprietary?...
OpenBSD already has containerd support. macOS is not based on upstream OpenBSD though.
> macOS is not based on upstream OpenBSD though.
I've never suggested this at any point.
> OpenBSD already has containerd support.
So what are the leftover steps we'd need to take, from "has containerd support" until "pkg_add docker && rcctl start dockerd && docker run -ti --rm hello-world"?
I've never suggested this at any point.
> OpenBSD already has containerd support.
So what are the leftover steps we'd need to take, from "has containerd support" until "pkg_add docker && rcctl start dockerd && docker run -ti --rm hello-world"?
desktop Linux is bad
For who? People that don't want to learn a different operating system? I use it and it works great. Just got done playing some Steam games on Linux. Steam decided to choose Linux for their Deck cause it is pretty amazing.
Desktop linux is fine. Laptop linux is bad and every company gives employees laptops.
So the automatic port forwarding/FS sharing/networking is nice if you want that.
But I often don’t. When I’m using Docker on my Mac it’s usually because I’m trying to use Docker. I need to use an existing Docker container or build a new one to fit some purpose with a Dockerfile.
I guess it’s nice that there would be a simpler way to launch one-off containers or containers for myself that aren’t expected to work like every other Docker container.
Is this a common need? Is there something that makes this more than I’ve noticed? The fact I work in a “Docker for containers” place may be preventing me from seeing what would make this shine.
But I often don’t. When I’m using Docker on my Mac it’s usually because I’m trying to use Docker. I need to use an existing Docker container or build a new one to fit some purpose with a Dockerfile.
I guess it’s nice that there would be a simpler way to launch one-off containers or containers for myself that aren’t expected to work like every other Docker container.
Is this a common need? Is there something that makes this more than I’ve noticed? The fact I work in a “Docker for containers” place may be preventing me from seeing what would make this shine.
Love Alpine Linux. Only thing stopping me from running it on my main workstation is that my Sublime Text is my main editor and they have no musl version.
I like the concept of having a musl-based distro, but the utility of Alpine is frankly limited at the moment.
Sublime is just one case. We had a Python service running in an Alpine container because it was thought as "mean and lean" by someone. Sound choice, right?
Guess what: we used a handful of (popular) Python modules that are backed by native libraries and PyPi didn't have musl-linked versions for them. The "mean and lean" Alpine-based image ended up weighing more than a debian-slim-based image.
Sublime is just one case. We had a Python service running in an Alpine container because it was thought as "mean and lean" by someone. Sound choice, right?
Guess what: we used a handful of (popular) Python modules that are backed by native libraries and PyPi didn't have musl-linked versions for them. The "mean and lean" Alpine-based image ended up weighing more than a debian-slim-based image.
I had Alpine running on WSL as my main dev environment for a long time. I've heard the python issues before, but I can confirm node.js stuff all worked flawlessly.
IIRC npm will compile native extensions, sounds like PyPi (is that a package manager?) distributes binaries.
IIRC npm will compile native extensions, sounds like PyPi (is that a package manager?) distributes binaries.
I'm using Alpine as my main workstation, and for those situation (like for Slack) I use flatpak.
Guess I'm already using flatpak for a few packages on my current glibc distro. Not that elegant but better than nothing.
You can install glibc+support libs on Alpine to run third-party software, but YMMV - I've had very mixed results.
Have you tried these options for running glibc software on Alpine?
https://wiki.alpinelinux.org/wiki/Running_glibc_programs
https://wiki.alpinelinux.org/wiki/Running_glibc_programs
it's a thin wrapper around qemu, for those interested
I have a Macbook Air M1 but I have given up on running x86 containers. Too much hassle, to much diskspace consumed and too slow. I can run various web projects natively but when I need x86 containers I use a x86 notebook with Linux.
If they can get VSCode to work on musl that'd be greaaaat.
VSCode (and Electron) has been working for a while on Alpine Linux.
https://pkgs.alpinelinux.org/package/edge/testing/x86_64/cod...
https://pkgs.alpinelinux.org/package/edge/testing/x86_64/cod...
I forgot to mention arm
Edit: which... Might also be available?
Edit: which... Might also be available?
Also available, at least if your hardware is aarch64. We've had some issues getting Chromium working on some of the other arm versions Alpine supports.
https://pkgs.alpinelinux.org/package/edge/testing/aarch64/co...
https://pkgs.alpinelinux.org/package/edge/testing/aarch64/co...
Oh man that's great, that was my only gripe at the time. Thanks for the links.
Nice wrapper around qemu for those wondering.
As someone with MacAlpine heritage I have never been more disappointed in two letters, though.
As someone with MacAlpine heritage I have never been more disappointed in two letters, though.
This is your typical MacOS frenzy over solutions in search of a problem space that didn't need solving.