Finch: An open-source client for container development(aws.amazon.com)
aws.amazon.com
Finch: An open-source client for container development
https://aws.amazon.com/blogs/opensource/introducing-finch-an-open-source-client-for-container-development/
5 comments
Great, then can you speak to whether rancher-desktop supports the "--platform" argument to "run" the same way that finch does?
I wouldn't mind answering it myself, but it looks like rancher-desktop is an electron something or other: https://github.com/rancher-sandbox/rancher-desktop/blob/v1.6... and even downloading the 500MB release zip shows that there's `Rancher Desktop.app/Contents/Resources/resources/darwin/lima/bin/limactl` hidden in it, but I'm a distrustful sort and I don't want to crawl through unlimited lines of typescript to find out what this is going to do to my system
Maybe it's just that I'm not the right audience for this, since I am the polar opposite of "some gui fanciness," as I came up through the docker-machine universe, and now colima, and thus have a lot more comfort debugging CLI tooling when something inevitably goes toes up
I wouldn't mind answering it myself, but it looks like rancher-desktop is an electron something or other: https://github.com/rancher-sandbox/rancher-desktop/blob/v1.6... and even downloading the 500MB release zip shows that there's `Rancher Desktop.app/Contents/Resources/resources/darwin/lima/bin/limactl` hidden in it, but I'm a distrustful sort and I don't want to crawl through unlimited lines of typescript to find out what this is going to do to my system
Maybe it's just that I'm not the right audience for this, since I am the polar opposite of "some gui fanciness," as I came up through the docker-machine universe, and now colima, and thus have a lot more comfort debugging CLI tooling when something inevitably goes toes up
Podman Desktop has a gui and runs on Windows/macOS/Linux for those that weren't aware. It also doesn't require a commercial license, unlike Docker desktop for enterprises.
https://podman-desktop.io
https://podman-desktop.io
A really great container solution is Podman and Linux. If macOS wanted to provide namespaces they could have done so, but to get the native container experience and a truly open source operating system just use Linux.
> If macOS wanted to provide namespaces they could have done so, to get the native container experience and a truly open source operating system just use Linux.
I am not too sure why this needed to turn into a dig on MacOS. I think a tool like Finch, Lima, Docker, etc. that further helps Linux be highly portable as a container environment highlights the strength of Linux as a portable runtime on every platform.
To flip it around, one could lament how Linux lacks a unified desktop experience compared to MacOS, which makes it even more difficult to use desktop Linux in the enterprise in contrast to Windows and MacOS.
Why not celebrate that containerized Linux will be even more accessible to another platform instead of turning this into a dig at another -- more widely used -- desktop OS in the enterprise? Some people/environments just can't or have not yet made the investment into desktop Linux.
(I'm a daily desktop NixOS and Arch user)
I am not too sure why this needed to turn into a dig on MacOS. I think a tool like Finch, Lima, Docker, etc. that further helps Linux be highly portable as a container environment highlights the strength of Linux as a portable runtime on every platform.
To flip it around, one could lament how Linux lacks a unified desktop experience compared to MacOS, which makes it even more difficult to use desktop Linux in the enterprise in contrast to Windows and MacOS.
Why not celebrate that containerized Linux will be even more accessible to another platform instead of turning this into a dig at another -- more widely used -- desktop OS in the enterprise? Some people/environments just can't or have not yet made the investment into desktop Linux.
(I'm a daily desktop NixOS and Arch user)
Wouldn't having multiple competing open source window managers be considered a good thing? I'm not sure what you mean by unified desktop experience as well, can you clarify specifically what that means to you? Do you mean like why don't all Linux desktop apps use GTK3 or Qt? Or why don't all Linux desktops use Gnome or KDE?
I do celebrate that Docker, Podman, Colima advance container solutions and increase exposure to Linux for server apps. My point being though is that if the point of Finch or Colima is to get a slight increase in performance in an already non-native VM experience then IMO the time would be better utilized either forcing Mac to implement native namespace and kernel-level support for containers or to adopt a native backed for containers. I can't tell you how many times I've seen developers implement poor practices coming from non-native development workstations because to them what does it matter if your container is a bit slower if they already are used to subpar performance and functionality.
I do celebrate that Docker, Podman, Colima advance container solutions and increase exposure to Linux for server apps. My point being though is that if the point of Finch or Colima is to get a slight increase in performance in an already non-native VM experience then IMO the time would be better utilized either forcing Mac to implement native namespace and kernel-level support for containers or to adopt a native backed for containers. I can't tell you how many times I've seen developers implement poor practices coming from non-native development workstations because to them what does it matter if your container is a bit slower if they already are used to subpar performance and functionality.
> Wouldn't having multiple competing open source window managers be considered a good thing?
I absolutely love this about Linux. However, I think this freedom of choice leads to difficulty of use in the enterprise.
> I'm not sure what you mean by unified desktop experience as well, can you clarify specifically what that means to you?
So one example that comes to mind for me as I am a security engineer is desktop-specific security software (and let me again emphasize I am talking about desktop). For example, on MacOS you have a myriad of effective desktop security tools that predictably work on the platform once it is released. Patrick Wardle's open source Objective See tooling[1] is the best example I can think of, Little Snitch[2] is another one that comes to mind.
As a thought exercise imagine you were to implement a Linux alternative to KnockKnock[3], which enumerates what applications will run at startup to help identify persistently installed malware. How would you do this on Linux? Monitor ~/.config/autostart, crontab, systemd? What if they have a non-systemd system, what if they are using i3 and starting applications in their i3 config, if you want notifications what notification daemon/client do you implement? The list goes on and on as there are a million different variables.
Another example I don't think can exist on Linux is an alternative to one of my favorite MacOS apps named Secretive[4], which allows you to store secure non-retrievable SSH keys in the Mac's secure enclave. Apple has a bit of an unfair advantage as they control the hardware and software that allows users to access the secure enclave -- but on Linux we don't really even have a uniform way to store credentials on the software side that a security vendor could reliably count on: we can use gnome-keyring, KDE's competitor, pass, gnupg, etc.
I am not saying these problems are insurmountable, but I think that if a security vendor were to target desktop Linux in addition to Windows and MacOS they would almost HAVE TO limit the scope to something like a default Ubuntu desktop LTS running GNOME as the DE (or something similar) so they could reliably reproduce results.
And I am not saying that this means desktop Linux shouldn't be used for work -- I exclusively work from my NixOS machine for my day job. But I have compassion for the IT org or product vendor who can't support desktop Linux in the enterprise -- Linux is kind of the wild, wild west on the desktop.
I hope one day we see a large-scale standard adopted by enterprise (i.e. Ubuntu LTS as the distro, GNOME as the DE, etc.) for desktop Linux just so it was more reasonable of an option in the enterprise. And to be clear, I don't mean that I hope choices for Linux go away, I love the amount of choice you have on Linux. But it can be a great weakness if you want standardized desktop builds.
[1] https://objective-see.org/tools.html
[2] https://www.obdev.at/products/littlesnitch/index.html
[3] https://objective-see.org/products/knockknock.html
[4] https://github.com/maxgoedjen/secretive
I absolutely love this about Linux. However, I think this freedom of choice leads to difficulty of use in the enterprise.
> I'm not sure what you mean by unified desktop experience as well, can you clarify specifically what that means to you?
So one example that comes to mind for me as I am a security engineer is desktop-specific security software (and let me again emphasize I am talking about desktop). For example, on MacOS you have a myriad of effective desktop security tools that predictably work on the platform once it is released. Patrick Wardle's open source Objective See tooling[1] is the best example I can think of, Little Snitch[2] is another one that comes to mind.
As a thought exercise imagine you were to implement a Linux alternative to KnockKnock[3], which enumerates what applications will run at startup to help identify persistently installed malware. How would you do this on Linux? Monitor ~/.config/autostart, crontab, systemd? What if they have a non-systemd system, what if they are using i3 and starting applications in their i3 config, if you want notifications what notification daemon/client do you implement? The list goes on and on as there are a million different variables.
Another example I don't think can exist on Linux is an alternative to one of my favorite MacOS apps named Secretive[4], which allows you to store secure non-retrievable SSH keys in the Mac's secure enclave. Apple has a bit of an unfair advantage as they control the hardware and software that allows users to access the secure enclave -- but on Linux we don't really even have a uniform way to store credentials on the software side that a security vendor could reliably count on: we can use gnome-keyring, KDE's competitor, pass, gnupg, etc.
I am not saying these problems are insurmountable, but I think that if a security vendor were to target desktop Linux in addition to Windows and MacOS they would almost HAVE TO limit the scope to something like a default Ubuntu desktop LTS running GNOME as the DE (or something similar) so they could reliably reproduce results.
And I am not saying that this means desktop Linux shouldn't be used for work -- I exclusively work from my NixOS machine for my day job. But I have compassion for the IT org or product vendor who can't support desktop Linux in the enterprise -- Linux is kind of the wild, wild west on the desktop.
I hope one day we see a large-scale standard adopted by enterprise (i.e. Ubuntu LTS as the distro, GNOME as the DE, etc.) for desktop Linux just so it was more reasonable of an option in the enterprise. And to be clear, I don't mean that I hope choices for Linux go away, I love the amount of choice you have on Linux. But it can be a great weakness if you want standardized desktop builds.
[1] https://objective-see.org/tools.html
[2] https://www.obdev.at/products/littlesnitch/index.html
[3] https://objective-see.org/products/knockknock.html
[4] https://github.com/maxgoedjen/secretive
(I'm a daily Fedora+nixpkgs user, and MacOS for work)
Apple has not provided the requisite plumbing to allow Lima to match the experience that Linux offers. I was the guy who had to write the scripts so that the rest of the folks could get up and running (at the time Lima was the only realistic container solution on aarch64). Pitfall after pitfall. There are still things that I can't do. I'm still telling people to `script.sh runtime recreate` at least weekly.
Don't get me wrong, the [Co]Lima folks have done heroic work. It's MacOS that is dog shit for this kind of stuff. We shouldn't brush that under the rug because doing so gives Apple no incentive to fix their shit.
Apple has not provided the requisite plumbing to allow Lima to match the experience that Linux offers. I was the guy who had to write the scripts so that the rest of the folks could get up and running (at the time Lima was the only realistic container solution on aarch64). Pitfall after pitfall. There are still things that I can't do. I'm still telling people to `script.sh runtime recreate` at least weekly.
Don't get me wrong, the [Co]Lima folks have done heroic work. It's MacOS that is dog shit for this kind of stuff. We shouldn't brush that under the rug because doing so gives Apple no incentive to fix their shit.
> We shouldn't brush [MacOS being dog shit for this kind of stuff] under the rug because doing so gives Apple no incentive to fix their shit.
I can totally agree with you on that. MacOS completely sucks (for me) without open source tooling such as Brew and Lima.
I was more responding to the vibe of "you should be on Linux if you actually want real containers" which bugs me because many orgs and product vendors have a tough time targeting desktop Linux due to the lack of standardization on the desktop.
I can totally agree with you on that. MacOS completely sucks (for me) without open source tooling such as Brew and Lima.
I was more responding to the vibe of "you should be on Linux if you actually want real containers" which bugs me because many orgs and product vendors have a tough time targeting desktop Linux due to the lack of standardization on the desktop.
Well, technically he is correct since containers on osx actually run inside a Linux VM, adding some overhead.
Obviously use whatever works for you, but containers on Linux is a different beast and besides better performance offer some other things that some people may find useful (e.g. zfs containers).
Also, the number of moving parts is much fewer. You can run containers right on top of systemd if you want.
Obviously use whatever works for you, but containers on Linux is a different beast and besides better performance offer some other things that some people may find useful (e.g. zfs containers).
Also, the number of moving parts is much fewer. You can run containers right on top of systemd if you want.
How's the Podman networking story? I appreciate the rootless nature of it but I ran into fringe issues when trying to replicate an aged Docker (Swarm) setup on it.
I think my biggest issue with Podman on Mac was the time shift over a few days, no matter which solution I tried.
Lima just works.
Lima just works.
I spent some time last week to get Colima to work on my Macbook but eventually gave up after Homebrew tried to pull in some Docker.dmg and a lot of other problems. Maybe I did something wrong.
Anybody know what the difference is between this and Lima? It already offers a Docker VM template that with nerdctl is a drop-in replacement for Docker Desktop. There's also Colima which again seems to be the same as Lima which it's based on.
The cynical response would be that they all contribute to a different person's promotion document (promodoc in Amazon parlance)
It's an abstraction layer above Lima. Looks like they're especially working on ease of use on macOS as the only supported platform for now.
> Finch is our response to the complexity of curating and assembling an open source container development tool for macOS initially, followed by Windows and Linux in the future.
> We are curating the components, depending directly on Lima and nerdctl, and packaging them together with their dependencies into a simple installer for macOS. Finch, via its macOS-native client, acts as a passthrough to nerdctl which is running in a Lima-managed virtual machine.
> All of the moving parts are abstracted away behind the simple and easy-to-use Finch client. Finch manages and installs all required open source components and their dependencies, removing any need for you to manage dependency updates and fixes.
> Finch is our response to the complexity of curating and assembling an open source container development tool for macOS initially, followed by Windows and Linux in the future.
> We are curating the components, depending directly on Lima and nerdctl, and packaging them together with their dependencies into a simple installer for macOS. Finch, via its macOS-native client, acts as a passthrough to nerdctl which is running in a Lima-managed virtual machine.
> All of the moving parts are abstracted away behind the simple and easy-to-use Finch client. Finch manages and installs all required open source components and their dependencies, removing any need for you to manage dependency updates and fixes.
Offhand, the biggest difference I'm aware of is the "--platform" argument to "finch run"; with colima (and presumably lima under it) one must specify that at vm creation time not per container
$ ./_output/bin/finch run --platform amd64 --entrypoint=/usr/bin/env redis:7-alpine uname -m
x86_64
$ ./_output/bin/finch run --platform arm64 --entrypoint=/usr/bin/env redis:7-alpine uname -m
aarch64
$ uname -m
x86_64
$ ./_output/bin/finch images
REPOSITORY TAG IMAGE ID CREATED PLATFORM SIZE BLOB SIZE
redis 7-alpine 2700d5097763 31 seconds ago linux/amd64 30.8 MiB 11.3 MiB
redis 7-alpine 2700d5097763 31 seconds ago linux/arm64/v8 30.5 MiB 11.3 MiBMultiarch works fine for me with colima and Docker CLI:
$ limactl shell colima uname -a
Linux colima 5.15.68-0-virt #1-Alpine SMP Fri, 16 Sep 2022 06:29:31 +0000 aarch64 Linux
$ docker run --rm --platform=linux/arm64 busybox uname -a
Linux d9daf296b930 5.15.68-0-virt #1-Alpine SMP Fri, 16 Sep 2022 06:29:31 +0000 aarch64 GNU/Linux
$ docker run --rm --platform=linux/amd64 busybox uname -a
Linux 34805057ef02 5.15.68-0-virt #1-Alpine SMP Fri, 16 Sep 2022 06:29:31 +0000 x86_64 GNU/Linux
Looks like this is for a consistent workflow for developers where managing a VM or learning nerdctl is too much. I say this as truthful and neither sarcastically or maliciously.
The article notes that Finch is simply curating and/or wrapping Lima etc...
This makes some sense to me. I can see this being a loose part of the CDK since there are quite a few constructs that require local Docker builds before being deployed. That's not just containers either, python lambda code is packages using a Docker container and the result spat out as a zip file for instance.
Disclaimer, I started Rancher Desktop so I have a little bit of a bias.
[1] https://rancherdesktop.io