Author note - Most of you guys here are power users, for whom UI is a visual poem that you need or not. This is not a commercial project, it is not following any business goals. But this does not mean concessions to quality, it does try to offer minimal resource usage everywhere, easy experience, good UI/UX.
It explains all it does behind the scenes if you enable the developer console. It can help one learn so at a certain moment one understands and automates with scripts and specs.
But everyone these days is either seen as too smart or too dumb, I don't consider users like this. I know everyone started somewhere and a gradual learning experience is the best.
I broke so many radios and toys when I was a kid and I learned so much, by looking at what was is inside.
It is a project done by one dude, after work and when it rains outside (In Belgium it rains a lot).
Consider the case of a team of people collaborating on a software stack - the prototypical use case includes Docker Compose at the simplest and a full K8s stack at the extreme. There is quite often a minimum of 3 containers here; frontend, API/Backend and a database server. If you start to add observability tools, async/batch/event execution, caching, automated integration testing, etc, the number of "layers" in the stack grows quickly. In addition, each component may have unique per-environment or even per-user customizations.
Often one ore two people will manage the stack itself and provide instructions on how to get the whole thing working for others using a specific defined selection of easy to use tools that essentially offer minimal prerequisite knowledge to use
"Install X, run Y, get to work."
It saves a lot of time for the intern on the UI team who just wants to add a component to one page and test it locally and not also have to learn how to deploy the entire stack from scratch.
Vert succinct and poetic way to describe so much these days in this space.
As for systemd, podman is amazing https://docs.redhat.com/en/documentation/red_hat_enterprise_...
Do you mean the Podman "Kubernetes like" functionality (e.g. podman play kube..) or Kubernetes itself?
You don't really learn about sysadmin through it, or even about docker that much, but you get an idea of how you might easily run a few different things on a server while only needing to know YAML, and not some custom DSL like chef or puppet.
YAML may be a known syntax, but the use of it still requires domain specific knowledge, and is still a domain specific language expressing those domain specific concepts, as to what the expected keys and values are allowed to be and how they are interpreted.
Also, nice work on Container Desktop!
An excellent way to learn indeed! Good luck with your project.
It’s really no different than how I taught myself to fix a chain or replace a spoke. Or know to use WD-40 to clean, but then apply an oil to keep stuff lubricated and protected.
With the internet, it’s a lot easier. I can look up spec sheets just googling component markings and see the sample circuits.
I’ve stared at the Linux kernel a ton. I messed with some stuff. I couldn’t write a kernel myself, but I program better from doing it and I can troubleshoot things easier knowing the components and topology.
Off the top of my head, I can fumble around and make a crappy amplifier from parts in my closet, or write a crappy FAT-like file system. I’d probably struggle a bit with a nice new bike. I think gear shifters and stuff are a lot fancier than an old 10 speed.
With that said, I have recently tried OrbStack, and it is able to start up near instantly, while Kubernetes spends at most 2 seconds to start up. The UI is minimal, but it offers just enough to inspect containers, pods, services, logs, etc. It also is very lightweight on memory usage and battery. I personally cannot return to either Docker or Rancher Desktop after having tried OrbStack.
OrbStack also allows using Kubernetes service domains directly on the host. So no need to use kubectl port-forward, and applications running on the host can use identical configuration to what's inside the Kubernetes cluster.
The battery savings, dynamic memory usage, fast startup time, and QOL of OrbStack is pretty much my standard for a Docker Desktop alternative. I am not sure if container-desktop satisfies all of these requirements. (Rancher Desktop certainly doesn't)
Any suggestions or personal experience?
It has some kinks to work out but I got it working with IDEs too (e.g. the Intellij IDEA Docker Compose integration to work with it).
What I also like is that existing scripts and etc that use the docker-compose cli work with Rancher Desktop too, as it uses nerdctl https://github.com/containerd/nerdctl
(I’m not affiliated with Orbstack)
The debug shell feature alone makes it better than any alternative, and hopefully that subscription money is put towards more unique features.
also no affiliation and have not tried orbstack
The flexibility of container runtimes and host architecture (via QEMU) has proven useful.
I've also used Colima, and if Orbstack wasn't an option, I'd be happy to keep using it.
Be aware that you need a license if you use it at work.
Thankfully, lima has landed a new port forwarder with UDP support! [0]. I'm hoping to be able to use it soon once it makes into a release.
[0]: https://github.com/lima-vm/lima/commit/13e9cbcabc6a0a05ec389...
it also has support for Linux VMs and kubernetes (although i haven't tried that yet)
Replace docker-compose with podman-compose -- somewhat limited capabilities, but works in a lot of cases.
Use docker-compose against podman w/ podman's system service, which provides a docker compatible API endpoint (https://docs.podman.io/en/v5.2.1/markdown/podman-system-serv...). This basically has full docker-compose capabilities, but, you do need run the socket service as a specific user account which end up running all the pods.
We needed to use Docker for M1 support (probably should've tried Colima, etc).
Is there something in these desktop UIs that colima is completely missing?
[0] `colima start --vm-type=vz --vz-rosetta`
I'm not completely sure about licensing for Container Desktop but the footer suggests MIT license.
Unfortunately I got this error upon opening the Mac app:
Uncaught Exception:
TypeError: Cannot read properties of null (reading 'setImage')
at NativeTheme.<anonymous> (file:///Applications/Container%20Desktop.app/ Contents/Resources/app.asar/build/main-5.2.3.mjs:22:537771)
at NativeTheme.emit (node:events:519:28)
Also, it's not obvious from the site that Container Desktop does bundle Podman along wit it, unlike Docker Desktop. The analogy with the latter and the subtitle "Podman Desktop Companion" on the site made me think it might include a bundled Podman installation.
That said I do like the idea, and I'm definitely looking forward to trying it. For context, I'm not a Kubernetes user, mostly just Compose and plain `docker run` for ad-hoc things.
I am documenting myself as much as I can to be able to publish to flatpak hub, but there is a lot to get to do it properly.
$ colima start
$ docker context use colima
And that's it.
And Kubernestes? No thank you, life is already hard as is.
- Buggy as heck with bad error messages.
- Bad UX with inadequate help.
- Requires extra tweaking and installing more stuff to get going, which defeats its entire purpose.
- Confusing.
- Can't browse or choose tags of images.
It's not a viable alternative yet, but maybe it will improve sometime in the future.
A TUI alternative.
When Docker was only a few years old, I did keep running into lots of small things which implied that the people developing docker in fact did NOT have a Unix (or even Linux) background. Things like source code files having the wrong type of newlines (or a mix of types), and forgetting to add a newline to the last line in a file. (A correct Unix text file has a newline at the end of _every_ line, even the last one.) There were of course more giveaways than this, I just remember the newline stuff irritating me the most.
I remember not having a newline breaks some tools... but why? It can't be because of unix philosophy!?
(I get your point, but docker has made distribution way easier in a lot of ways, and you accept sole tradeoffs for that convenience)
It's so sad that running software on Linux is so wildly complicated and unreliable than things like Docker had to be invented. :(
So, from a consumer's point of view, if you want to use their software, then docker is the lesser evil compared to all the others. Notably, it's much better than binaries with dynamic libraries that don't come included in the bundle itself.
Binaries should always include the dynamic libraries they require. Docker is one way to include them. But you can also just include them the vanilla way. Works great! Very easy and reliable.
Perhaps you misunderstand. This issue is fully solved by including dependencies and not relying on anything in the system path. Programs should not touch the system path. If a program requires library A.Y then it should include and use A.Y. But it should not touch the system path and thus should not impact any other program. Nor will it be impacted by other programs wanting A.Z.