Daemonless operation sounds very compelling. It is often slow or complicated to deploy a docker installation just to be able to run a container when all I really want is a process. Conceptually (and I really mean conceptually, not technically) I don’t need a Python daemon to run a Python tool so why do I need a Docker daemon to run a containerized Python tool?
LXC did this nicely, imho, by storing the state and configuration of each container as files in a directory. It doesn’t seem like LXC/LXD has really taken off (see also: bzr) — bad luck Canonical, but thank you for trying.
Relating to both LXC vs Docker, and Docker vs Podman: oftentimes, the presence of competition is what drives the winner to victory. It might seem like wasted effort to have two competing solutions for a while but the final outcome of a winner that’s better than it would
have been is of benefit to everyone. If I had a dollar for every project I started at work just to stone-soup one of my peers into action I would have more than… $20? $50?
Postscript, written after reading the comments below (thanks!): when you need to get a project going in a creative field like software engineering, a useful technique is to start with something — anything at all — announce it, and invite meaningful contributions to take that thing from trivial starting point to a rich and useful product. The analogy is “stone soup”: a villager wants to put together a feast but doesn’t have the means to do it themselves. What they can do is get a fire going, get a pot of water simmering over the fire, and put a single rock in it. They then suggest to another villager “hey I’ve got this soup going but it would be even better with one of your onions: how about we work together?”. To another they say the same thing but for potatoes, to another a ham hock, ad finitum until the pot contains a rich and tasty broth. By kicking off the project, albeit with something that was just a framework, they were able to engage others interest and take the project to completion as a team.
The more scurrilous version of this is shit soup. One villager sets up the pot / asks a question on stackoverflow. Predictably, no one engages. Another villager — secretly conspiring with the first — shows up and announces the correct ingredient to be added next is goat turd / replies to the stackoverflow question with a deliberately incorrect answer. Lo and behold all the other villagers now show up to explain why that answer is dumb, and in fact we should be adding onions, potatoes, and ham / insert correct technical answer to SO question here.
Many of us will have come across this in The Pragmatic Programmer under “Stone Soup and Boiled Frogs”.
I know the interpretation 'stone soup' you use, however there are other parts of the world that know it in a different story, i'll tell it here.
When the english first attempted to colonize australia to Australia, an englishman noticed a native 'bush turkey' was not regularly eaten by the local native aboriginals. The englishman had tried to cook and eat them, but it ended up anything but tastey.
He asked one of the tribal elders the secret to eating them, the elder responded.
"You put a stone into the pot, you bring it to boil When its boiling you throw in the plucked bush turkey, you eat it when the stone is soft."
The lesson I take from this is "sometimes things are just going to be bad, you just gotta accept that and move on".
I’m not sure I understand your anecdote. I had actually never heard of “stone soup” by grandparent but I found it in Wikipedia as this story: https://en.m.wikipedia.org/wiki/Stone_Soup
My interpretation of grandparent as applied onto that story was that some of their colleagues had some local solutions that were part of the puzzle and OP purposefully created some ancillary solution (the “stone soup”) to get them to contribute to the bigger picture. But perhaps I’m seeing this entirely wrong?
> It doesn’t seem like LXC/LXD has really taken off
Maybe for you but LXC is very useful for deploying development environment isolated for each developers. systemd-nspawn is quite simple but LXC provides tooling that makes operations easier.
Docker and LXD serve different purposes. Docker is meant for an app to be run isolated but LXD can run a whole OS.
LXC did this nicely, imho, by storing the state and configuration of each container as files in a directory. It doesn’t seem like LXC/LXD has really taken off (see also: bzr) — bad luck Canonical, but thank you for trying.
Relating to both LXC vs Docker, and Docker vs Podman: oftentimes, the presence of competition is what drives the winner to victory. It might seem like wasted effort to have two competing solutions for a while but the final outcome of a winner that’s better than it would have been is of benefit to everyone. If I had a dollar for every project I started at work just to stone-soup one of my peers into action I would have more than… $20? $50?
Postscript, written after reading the comments below (thanks!): when you need to get a project going in a creative field like software engineering, a useful technique is to start with something — anything at all — announce it, and invite meaningful contributions to take that thing from trivial starting point to a rich and useful product. The analogy is “stone soup”: a villager wants to put together a feast but doesn’t have the means to do it themselves. What they can do is get a fire going, get a pot of water simmering over the fire, and put a single rock in it. They then suggest to another villager “hey I’ve got this soup going but it would be even better with one of your onions: how about we work together?”. To another they say the same thing but for potatoes, to another a ham hock, ad finitum until the pot contains a rich and tasty broth. By kicking off the project, albeit with something that was just a framework, they were able to engage others interest and take the project to completion as a team.
The more scurrilous version of this is shit soup. One villager sets up the pot / asks a question on stackoverflow. Predictably, no one engages. Another villager — secretly conspiring with the first — shows up and announces the correct ingredient to be added next is goat turd / replies to the stackoverflow question with a deliberately incorrect answer. Lo and behold all the other villagers now show up to explain why that answer is dumb, and in fact we should be adding onions, potatoes, and ham / insert correct technical answer to SO question here.
Many of us will have come across this in The Pragmatic Programmer under “Stone Soup and Boiled Frogs”.