Since buying a new computer, my primary desktop is no longer Linux, and containers are no longer native. I decided that the path of least resistance would be to try Podman Desktop, but it leaves a lot to be desired.
First and foremost, it’s slow to boot. I wouldn’t care, except that while it is still booting, it lies. The Containers tab will incorrectly say “no container engine,” then wrongly claim “no containers,” before finally realizing that everything is all there. The first time I saw it, it made me really worried about my data.
The second most-annoying feature is the ad on the dashboard that cannot be dismissed. There is no way to express disinterest, nor non-consent. (This ad is also on their website, which is why their website is not linked.) Update 2025-02-24: Version 1.16 appears to have made this dismissable… too late to avoid criticism, though; this post was drafted prior to the change.
Those are the everyday annoyances. I had a few containers going, and then I needed to build a custom one. My GitHub User Pages are managed by Pelican, which runs in Python; and I also needed git installed, to be able to push the build results. Creating the container to make all this possible was unnecessarily difficult.
The build sequence is essentially an edit-build-(run-)debug loop, but the app UI has no affordance for this. Building an image is modal. Clicking most things closes the build page. When reopening it, nearly all inputs have been forgotten. The only one that is kept is the “last used directory” for the app as a whole, which means a cycle which included “run” makes the user flip between build directory and volume attachment.
When asking to create a container from the Containers tab, the app asks whether it’s from a Containerfile or an existing image. Once the question is answered, the user is unceremoniously dumped into the appropriate Images subscreen, without explanation. To create a container from an image, the user is expected to click on one of the Play buttons, and completely ignore the button on the Containers tab. Likewise, the Build button on the Images tab is for building an image from a Containerfile; the Containers tab is not particularly special.
When actually “building from a Containerfile,” the user is building an image, and Podman Desktop completely forgets that the user originally asked to create a container. When the image is done, nothing special happens; the user clicks Done and “returns” to the image list. There’s no tip to use the Play button on the newly created image. The user just has to know that already.
Building images spits the build log onto the screen, then hides it, without clearly indicating success or failure. The user has to scroll down to get the log back, to confirm it ends with “successfully tagged image,” or else the Images screen just… mysteriously lacks the image that should have been built. Leaving the build screen to see this, of course, throws away all the input that was on it, along with the log!
The images that are built are unexpectedly tagged under the namespace of a popular container registry, despite being a local image that is never pushed (I don’t have any credentials for the registry.) This is surprising, confusing, and wrong; and it is another case where non-consent should have been expressible.
It’s possible to forget to set up a volume when creating a container, in which case, the app creates space for it internally. The stated path does not appear in the host’s filesystem (possibly Mac-specific.) This defeats the point of using a volume for file-sharing between host and container. Interestingly, volumes created this way appear on the Volumes tab, unlike every other volume.
Users must always remember to set every option every time through the cycle, since the app insists on being so forgetful, and nothing can be modified later. If the user forgets to name the container and doesn’t like the auto generated name, there’s no recourse but to delete the container and try again. If the user forgets to link a volume to share files as desired, there’s no recouse but to delete the container and try again. From scratch, because once again, the previous inputs are gone.
That’s it for building, but there are a couple of issues remaining.
The image screen—the whole app—appears to lack a way to update an image. If the user pulled Alpine five months ago, the user will have that image forever, unless the user asks to pull it by its URL again. Once the image is pulled, the old one hangs around with the uninformative name of none.
Despite having all options and plugins deactivated for a popular container engine, the app still offers a “Compatibility” button in its status bar, suggesting that compatibility is active. In reality, it is the entry-point to a dialog that asks if the user would like to use admin rights to turn it on. Yet again, for the third time, there’s no “hide this” option. The effective choices are “Yes” and “Maybe later!”
Finally, the Podman Desktop Mac App doesn’t have a built-in option to uninstall itself cleanly. Naïvely removing the app will leave downloaded data all over, including container engines. Rating: ★☆☆☆☆, average corporate disdain for users mixed with average open source lack of polish. I would not use this app if I had a better alternative in mind.
No comments:
Post a Comment