Show HN: Container Desktop – Podman Desktop Companion(container-desktop.com) |
Show HN: Container Desktop – Podman Desktop Companion(container-desktop.com) |
(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.
It should never be more complicated than "run the binary". Running programs shouldn't require infrastructure or VMs or Docker images. Deploying a program should be, and can be, as simple as sharing a zip file, extracting, and running.
It's not that hard!
https://www.phoronix.com/review/windows11-wsl2-zen4
wsl2 runs under the windows hypervisor as a vm, but so does windows since windows 11. So there should not be much performance issues from running stuff in windows vs wsl2. The major bottleneck is if you need to move files from and to the windows vm to the Linux vm
Why people constantly insist on adding unnecessary layers of abstraction is beyond me.
As for why to do it, if you develop on server apps Linux is the standard (as an example redis does not have a windows native version), and I say this as a developer of Windows based microsevices on the cloud, my company is actively looking to migrate to Linux due to lack of tooling in the windows space (and also licence cost of windows server), like it or not that is the way it goes. If you don't need it great for you, but for other of us those layers are life saver
I tend to ship code that needs to run on Linux + macOS + Windows + Android. So Docker is a total non-option. And it's totally fine! Very easy in fact.
It's literally impossible to _not_ depend on the system path.
The "Linux Way" is to depend on a bunch of random garbage pooped by lord knows bullshit script into one of several global search paths. This is bad, stupid, and wrong. Programs should include as many of their dependencies as is possible.
The number of dependencies that a program can not deploy and must assume are provided by the system are extremely minimal and special case. It's a short and static list.
In general no script or program should add libraries into the global search paths. On Windows user programs do not add random crap to System32. On Linux the existence of /usr/lib is an abomination that should not exist.
Is that better? I'm fairly certain you understand what I'm trying to say.
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.
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!?
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.
For Kubernetes, it’s CRDs that are written in YAML and they conform to a specification.
Both podman-compose (the Python project) and docker-compose-v1 have significant gaps in the compose spec.
Be sure to increase RAM over the default 2GB as well, that SQL Server container is hungry and will crash without enough resources dedicated to it.
> Debug Shell works by injecting a debugging environment using: > NixOS for a large package collection, and flexibility with filesystem paths
Debugging slim or distroless images is quite the pain, so a tool like this is worth it if you're frequently working on such images.
I mostly wanted to provide a software/hardware playground for my advisors who were working on their own thesis about algorithms for energy-aware IoT edge deployments.
The TLDR is that you can write algorithms to minimize various parameters within a Kubernetes cluster, like energy consumption.
POSIX defines it more succinctly than I do: A text file contains one or more "lines" and every "line" is terminated by a "newline."
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
Unix has ALWAYS defined a line of text as being terminated by a newline. The last line in the file is not an exception.
not a personal attack on you, but it blows my mind how clueless the current generation of developers become after the docker phase.
There's always been a mythos of a true developer. Here's a rant from 1983 about how real programmers don't use Pascal. https://www.pbm.com/~lindahl/real.programmers.html
Kids these days...
Containers will only ever be on a linux kernel or VM? Never natively on ANY other OS? Only Linux containers exist?
Developers were more clueful about containers before Docker made them wildly popular?
In practice, yes.
Linux is not the only OS that has container like things. FreeBSD had jails years earlier, Solaris had something else which I don't remember any more, and for all I know macOS may have their own native equivalent as well.
Bear in mind that Apple introduced an official hypervisor framework a few releases ago, so they could be doing something similar for containers. It wouldn't be a bad idea. :)
“Performance is crap when running BlahBlah Management Suite.”
And so on. You don’t necessarily call support when one dev has an issue, you call when they all do.
https://docs.orbstack.dev/architecture
> OrbStack uses a lightweight Linux virtual machine with a shared kernel to minimize overhead and save resources, similar to WSL 2 (Windows Subsystem for Linux).
https://github.com/orbstack/orbstack/issues/461#issuecomment...
I think you forgot how this thread got started:
> If you’re on macOS, then Orbstack is a nice alternative to Docker Desktop
We’re talking about running OCI (“Docker compatible”) images. The page you just linked to makes it apparent that you are talking about something orthogonal: OrbStack’s “machines” feature (https://docs.orbstack.dev/machines/).
The original topic is that OrbStack’s support for Docker containers is fast (implied: faster than Docker for Desktop), which cannot be explained by the lack of a VM, as both use a Linux VM to run one or more Docker containers.
https://arstechnica.com/gadgets/2024/02/asahi-linux-projects...
1. keep log, docs, records of whatever you are doing. most commands are repetitive.
2. copilot or chatgpt, they help a lot with command lines and simple utilities
3. amazon Q sucks in comparison.
4. it used to be google, but now LLMs do it better. less scrolling and ads/spam.
but my post was about doing complex tasks in general. try to offload. another advise for developers is to write comments, even in your small hobby projects. this way you don't have to memorize it all. this was learned hard way. i usually also have a separate documentation with plans, ideas, algorithms, useful info. remind: this is for hobby projects.
and important thing: touch typing is must have. this makes it all much easier
If you also need docker emulation with podman too
Step 3. Install Podman Step 4. Install Podman Desktop.
Now a. Either work with Rancher Desktop (open it) and Docker is available also in cmd line (docker, docker ccompose , etc) b. Or Start Podman Desktop to configure Podman (or just use comandline to configure)
Now in cmd you not only have docker and friends but also podman and friends
Bonus, you have Kubernetes tools too and you are FOSS.
Happy composing :-)
PS: I think you cannot start both. I have both installed and never looked back. Windows 10 x64 PRO
FFMpeg is a good example though of one I'm happy to just have my notes on, but since I do literally only ever use it for one or two types of tasks, I'm happy to have that sit behind the scenes. Others might use it in many versatile ways, for which I'd be grateful to have those options readily available in my terminal.
The root of the problem was we had third party tools which were windows only.