7 ms·

> Requirements on the executing device: Docker is required.

by Epskampie 1y ago

alumic 1y ago
I was so blown away by the title and equally disappointed to discover this line. Pack it in, guys. No magic today.
- stingraycharles 1y ago
  Thank god there’s still this project that can build single executables that work on multiple OS’es, I’m still amazed by that level of magic.
  - cozyman 1y ago
    [flagged]
harha_ 1y ago
Yeah, it feels like nothing but a little trick. Why would anyone want to actually use this? The exe simply calls docker, it can embed an image into the exe but even then it first calls docker to load the embedded image.
- jve 1y ago
  I see a use case. The other day I wished that I could pack CLI commands as docker containers and execute them as CLI commands and get return codes. I haven't tried this stuff, but maybe this is something in that direction.
  - matsemann 1y ago
    I do that for a lot of stuff. Got a bit annoyed with internal tools that was so difficult to set up (needed this exact version of global python, expected this and that to be in the path, constantly needed to be updated and then stuff broke again). So I built a docker image instead where everything is managed, and when I need to update or change stuff I can do it from a clean slate without affecting anything else on my computer. To use it, it's basically just scripts loaded into my shell. So if I do "toolname command args" it will spin up the container, mount the current folder and some config folders some tools expect, forward some ports, then pass the command and args to the container which runs them. 99% of the time it works smooth. The annoying part is if some tool depends on some other tool on the host machine. Like for instance it wants to do some git stuff. I will then have to have git installed and my keys copied in as well for instance.
    - rzzzt 1y ago
      CoreOS had a toolbox container that worked similarly to the one you have (the Podman people took over its maintenance): https://github.com/containers/toolbox https://github.com/containers/toolbox
    - endofreach 1y ago
      > my keys copied in as well for instance. Tip: you could also forward your ssh agent. I remember it was a bit of a pain in the ass on macos and a windows WSL2 setup, but likely worth it for your setup.
  - lelanthran 1y ago
    > I see a use case. The other day I wished that I could pack CLI commands as docker containers and execute them as CLI commands and get return codes I don't understand this requirement/specification; presumably this use-case will not be satisfied by a shell script, but I don't see how. What are you wanting from this use-case that can't be done with a shell script?
    - lazide 1y ago
      Presumably, they don’t want to write/maintain a shell script wrapper for every time they want to do this, when they could use a tool which does it for them.
      - lelanthran 1y ago
        > Presumably, they don’t want to write/maintain a shell script wrapper for every time they want to do this, when they could use a tool which does it for them. How's "packing" cli commands into a shell script any different from "packing" CLI commands into a container?
        lazide 1y ago
        Calling a container on the CLI is a pain in the ass. People generally don’t put stuff that works in whatever environment you’re in on the CLI already into contains. Stuff that doesn’t, of course they do. Having a convenient shell script wrapper to make that not a pain in the ass, while letting all the environment management stuff still work correctly in a container is convenient. Writing said wrapper each time, however is a pain in the ass. Generating one, makes it not such a pain in the ass to use. So then you get convenient CLI usage of something that needs a container to not be a pain in the ass to install/use.
    - james_marks 1y ago
      An icon a non-technical user can click to run it.
      - 1y ago
- johncs 1y ago
  Basically the same as Python’s zipapps which have some niche use cases. Before zipapp came out I built superzippy to do it. Needed to distribute some python tooling to users in a university where everyone was running Linux in lab computers. Worked perfectly for it.
- j45 1y ago
  Could be ease of use for end users who don't docker.
  - worldsayshi 1y ago
    But now you have two problems.
    - throwanem 1y ago
      The first of which can be p90 solved by "Okay, type 'apt install dash capital why docker return,' tell me what happens...okay, and 'docker dash vee' says...great! Now..." Probably takes a couple minutes, maybe less if you've got a good fast distro mirror nearby. More if you're trying to explain it to a biologist - love those folks, they do great work, incredible parties, not always at home in the digital domain.
Hamuko 1y ago
I feel like it's much easier to send a docker run snippet than an executable binary to my Docker-using friends. I usually try to include an example `docker run` and/or Docker Compose snippet in my projects too.
deleted 1y ago
[deleted]
drawfloat 1y ago
Is there any alternative way of achieving a similar goal (shipping a container to non technical customers that they can run as if it were an application)?
- regularfry 1y ago
  It feels like there ought to be a way to wrap a UML kernel build with a container image. Never seen it done, but I can't think of an obvious reason why it wouldn't work.
- mrbluecoat 1y ago
  See the dockerc comment above
arjvik 1y ago
Good friend built dockerc[1] which doesn't have this limitation! [1]: https://github.com/NilsIrl/dockerc https://github.com/NilsIrl/dockerc
- hnuser123456 1y ago
  That screenshot in the readme is hilarious. Nice project.
- dheera 1y ago
  But will this run inside another docker container? I normally hate things shipped as containers because I often want to use it inside a docker container and docker-in-docker just seems like a messy waste of resources.
  - rcfox 1y ago
    Doesn't podman get around a lot of those issues?
    - dheera 1y ago
      Aw hell, more band-aids because people don't want to get software distribution done right. Can we please go back to the days of sudo dpkg -i foo.deb and then just /usr/bin/foo ?
      - johnisgood 1y ago
        I am still using "ar x" and "tar xvf" for .deb files on Void Linux, because some projects only release .deb files!
  - vinceguidry 1y ago
    Docker in Docker is not a waste of resources, they just make the same container runtime the container is running on available to it. Really a better solution than a control plane like Kubernetes.

> Requirements on the executing device: Docker is required.

alumic 1y ago

I was so blown away by the title and equally disappointed to discover this line. Pack it in, guys. No magic today.

stingraycharles 1y ago
Thank god there’s still this project that can build single executables that work on multiple OS’es, I’m still amazed by that level of magic.
- cozyman 1y ago
  [flagged]

harha_ 1y ago

Yeah, it feels like nothing but a little trick. Why would anyone want to actually use this? The exe simply calls docker, it can embed an image into the exe but even then it first calls docker to load the embedded image.

jve 1y ago
I see a use case. The other day I wished that I could pack CLI commands as docker containers and execute them as CLI commands and get return codes. I haven't tried this stuff, but maybe this is something in that direction.
- matsemann 1y ago
  I do that for a lot of stuff. Got a bit annoyed with internal tools that was so difficult to set up (needed this exact version of global python, expected this and that to be in the path, constantly needed to be updated and then stuff broke again). So I built a docker image instead where everything is managed, and when I need to update or change stuff I can do it from a clean slate without affecting anything else on my computer. To use it, it's basically just scripts loaded into my shell. So if I do "toolname command args" it will spin up the container, mount the current folder and some config folders some tools expect, forward some ports, then pass the command and args to the container which runs them. 99% of the time it works smooth. The annoying part is if some tool depends on some other tool on the host machine. Like for instance it wants to do some git stuff. I will then have to have git installed and my keys copied in as well for instance.
  - rzzzt 1y ago
    CoreOS had a toolbox container that worked similarly to the one you have (the Podman people took over its maintenance): https://github.com/containers/toolbox https://github.com/containers/toolbox
  - endofreach 1y ago
    > my keys copied in as well for instance. Tip: you could also forward your ssh agent. I remember it was a bit of a pain in the ass on macos and a windows WSL2 setup, but likely worth it for your setup.
- lelanthran 1y ago
  > I see a use case. The other day I wished that I could pack CLI commands as docker containers and execute them as CLI commands and get return codes I don't understand this requirement/specification; presumably this use-case will not be satisfied by a shell script, but I don't see how. What are you wanting from this use-case that can't be done with a shell script?
  - lazide 1y ago
    Presumably, they don’t want to write/maintain a shell script wrapper for every time they want to do this, when they could use a tool which does it for them.
    - lelanthran 1y ago
      > Presumably, they don’t want to write/maintain a shell script wrapper for every time they want to do this, when they could use a tool which does it for them. How's "packing" cli commands into a shell script any different from "packing" CLI commands into a container?
      - lazide 1y ago
        Calling a container on the CLI is a pain in the ass. People generally don’t put stuff that works in whatever environment you’re in on the CLI already into contains. Stuff that doesn’t, of course they do. Having a convenient shell script wrapper to make that not a pain in the ass, while letting all the environment management stuff still work correctly in a container is convenient. Writing said wrapper each time, however is a pain in the ass. Generating one, makes it not such a pain in the ass to use. So then you get convenient CLI usage of something that needs a container to not be a pain in the ass to install/use.
  - james_marks 1y ago
    An icon a non-technical user can click to run it.
    - 1y ago
johncs 1y ago
Basically the same as Python’s zipapps which have some niche use cases. Before zipapp came out I built superzippy to do it. Needed to distribute some python tooling to users in a university where everyone was running Linux in lab computers. Worked perfectly for it.
j45 1y ago
Could be ease of use for end users who don't docker.
- worldsayshi 1y ago
  But now you have two problems.
  - throwanem 1y ago
    The first of which can be p90 solved by "Okay, type 'apt install dash capital why docker return,' tell me what happens...okay, and 'docker dash vee' says...great! Now..." Probably takes a couple minutes, maybe less if you've got a good fast distro mirror nearby. More if you're trying to explain it to a biologist - love those folks, they do great work, incredible parties, not always at home in the digital domain.

Hamuko 1y ago

I feel like it's much easier to send a docker run snippet than an executable binary to my Docker-using friends. I usually try to include an example `docker run` and/or Docker Compose snippet in my projects too.

deleted 1y ago

[deleted]

drawfloat 1y ago

Is there any alternative way of achieving a similar goal (shipping a container to non technical customers that they can run as if it were an application)?

regularfry 1y ago
It feels like there ought to be a way to wrap a UML kernel build with a container image. Never seen it done, but I can't think of an obvious reason why it wouldn't work.
mrbluecoat 1y ago
See the dockerc comment above

arjvik 1y ago

Good friend built dockerc[1] which doesn't have this limitation! [1]: https://github.com/NilsIrl/dockerc https://github.com/NilsIrl/dockerc

hnuser123456 1y ago
That screenshot in the readme is hilarious. Nice project.
dheera 1y ago
But will this run inside another docker container? I normally hate things shipped as containers because I often want to use it inside a docker container and docker-in-docker just seems like a messy waste of resources.
- rcfox 1y ago
  Doesn't podman get around a lot of those issues?
  - dheera 1y ago
    Aw hell, more band-aids because people don't want to get software distribution done right. Can we please go back to the days of sudo dpkg -i foo.deb and then just /usr/bin/foo ?
    - johnisgood 1y ago
      I am still using "ar x" and "tar xvf" for .deb files on Void Linux, because some projects only release .deb files!
- vinceguidry 1y ago
  Docker in Docker is not a waste of resources, they just make the same container runtime the container is running on available to it. Really a better solution than a control plane like Kubernetes.