the most common complaint i see people have with Docker is the quip "it works on my machine => i'll ship my machine" but this is literally the _least_ of the issues with Docker

every new thing i learn about Docker and container infrastructure as a whole is somehow more upsetting than the previous one. the entire thing is bad. OCI is bad. none of it is well-designed, most of it makes barely any sense at all, hardly any can be reasonably run at scale

why is `buildah rm` and `buildah remove` two completely unrelated commands. does nobody involved give a shit about UI design

quick! tell me which of `docker export` and `docker save` operates on images and which on containers

why is everything like this!!

@whitequark docker export operates on containers and docker save on images. I think.

@freya correct

you get a gold star: ⭐

@whitequark yaaay I got that right despite fucking hating docker

@whitequark containers in my world look like this

pfexec zonecfg -z testzone
create -b
set zonepath=/zones/testzone
set autoboot=true
set brand=lx
add net
set address=192.168.50.221/24
set defrouter=192.168.50.1
set physical=e1000g0
end
verify
commit
exit
pfexec zoneadm -z testzone install -i <linuxrootfstarfile>
pfexec zoneadm -z testzone boot
pfexec zlogin -C testzone

@freya @whitequark lol brand=lx absolutely batshit insane.

*massive bong rip* hey this Linux thing is getting popular, how about we let folks run a Linux userland inside a zone on a Solaris x86 host?

@jpm @whitequark it's actually quite nice and I've used it a lot
@freya @whitequark oh I didn’t say it was bad, it’s a hell of an achievement developing a compatibility layer to allow another operating system’s binaries to run unmodified on a completely different kernel
@jpm @whitequark oh it absolutely is. Hell, I do it on FreeBSD a lot too
@whitequark docker save makes Docker dive towards the ball to try and stop it from going in the goal, I think.

@whitequark
EXEC? RUN? No, CMD! Wait, ENTRYPOINT?

raaaaggh

@whitequark at least it doesn’t have both --dryrun and --dry-run that turn off different parts of actually doing the thing
@rfc6919 i'm sorry what

@whitequark

semgrep

--dry-run
When set, will not start a scan on semgrep.dev and will not report
findings. Instead will print out json objects it would have sent.

--dryrun
If --dryrun, does not write autofixes to a file. This will print
the changes to the console. This lets you see the changes before
you commit to them. Only works with the --autofix flag. Otherwise
does nothing.

@rfc6919 How do you un-read a Mastodon post? This needs a CW for cognitohazard
@krans largely how i felt when i worked out why my dry run wasn’t doing what i expected

@whitequark I've worked with docker CLI and API enough as well as living with similar problems in self created problems to wager this:

It was created fast when it got traction but wasn't fully redesigned to provide a proper user architecture when it was stable enough.

That would mean a change for a couple of hundred thousands users in stead of *checks notes* millions of users over years 😭

@whitequark I like `rm` and `rmi`, which I guess are sort of clear (in the style of unix commands, anyway) if you know about both of them (`rmi` is "remove image", which means by elimination `rm` is "remove container"), but you do have to know about both of them or what you're trying to do won't work for no apparent reason.
@whitequark I didn't even know docker export existed because why would you need that?

@whitequark This makes me feel a bit vindicated that I opted to go the proxmox vms route for the friends & damily server @.@

(Even though proxmox is its own royal pain in the ass)

@whitequark Even though that project also hit a hard blocker that I couldn't work past until now that I've moved:

Proxmox has literally zero documentation about how to set it up to function over a wifi connection and is built to assume you have it wired, and multiple user requests/complaints to that effect have been met with complete silence from the project. 🙃

@whitequark I'm in a new place now where I can actually use a wired connection as the Proxmox Gods intend, but in my old place I literally had only a wifi connection and I was not the only person in this world with the same problem.

I think Docker/Podman are the same. They assume you can wire up a link.

@dragonarchitect i think assuming you have basic linux administration skills is basically reasonable tho?
@whitequark some days i fantasize about a world where kubernetes was built on a saner basis than _literally_ using docker and friends, and then i remember it's practically add-only engineering and sigh
@whitequark sure you can, just add another layer of insane complexity on top of it (kubernetes).
@whitequark I personally tend to go as far away from docker as a model as possible. I know this may sound completely insane, but I feel like with containers, Kubernetes is the sane choice compared to docker/podman.
@ignaloidas @whitequark You mean to run stuff (=not develop)? Because k8s uses the same containers? As someone who runs containers and doesn't build them, I can't say I like the docker format and where everything is going. But I still vastly prefer it to some other stuff simply because it works almost always. No more annoying issues when you see a cool project, the installation says "pip - r requirements.txt" or whatever and it JUST DOESN'T WORK in a fresh ubuntu LTS vm.
@chke @whitequark I feel like for developing as well, somewhat? E.g. I was looking into utilizing buildkitd for building images for some IaC shenanigans I was doing, and it seemed to be significantly nicer and more isolated than using docker build - though I didn't end up pursuing that till the end.

And also, I feel like containers have very little benefit if you're running just one or two of them, and for anything more, kubernetes is just way, way, way better. I worked on a project that essentially acted as a platform integrating a bunch of other projects, and Kubernetes was genuinely the best way for both local and production deployments. Yes, it's annoying to get a local kubernetes working decently on non-linux systems, but it was still better than the pain you would've had getting dependencies and other stuff set up for 8 different projects, a bunch of which were written in different languages.
@whitequark and yet: containerization is the model people are using for large scale. funny ol world
@whitequark thank you for helping me feel better about not "getting" docker in spite of taking many kicks at that can
@whitequark I believe the secret reason why Docker got so popular is privilege escalation.

@whitequark I predicted containers before they were cool. Doesn't mean I think they're a good idea though.

We all should have gone with Plan 9, at least as soon as it went FOSS, 25 years ago. Everything is in an isolated virtual environment all the time and there's no "real" privileged level underneath.