[zer00eyz]

>>> To me, all that points at containers being in some way a solution to Dynamic linking. And maybe an over the top solution. ... Should we be doing more static linking? Not even depending on libc? What are the challenges with that?

>> but it's a ruby application and I need to install the whole stack of things, plus the gems. Instead I containerize it, and keep my system clean.

There was a bit of drama recently with the Bottles project and some Distro maintainers. With the Bottles devs saying "we only want the appimage as a distribution method".

I see containers as a means of distributing software. If that ruby app was a binary, then the container would become baggage.

[bayindirh]

> Bottles devs saying "we only want the appimage as a distribution method".

Good for them having wishes, yet free software doesn't work that way in most cases. :)

> I see containers as a means of distributing software

That's OK. Docker is a tool, and tools can be held and used in many ways.

[zer00eyz]

>>> Good for them having wishes, yet free software doesn't work that way in most cases. :)

Historically I would agree with you.

But bottles, and the attitude of some upstream projects is one of "modern", "faster", "support the latest version only" ... Software devs who live in user space want a more "App Store" like delivery mechanism where they have control. The kernel is inclined to never break backwards compatibility. Distros are sort of stuck in the middle...

>> I see containers ... > That's OK. Docker is a tool,

One of these is a subset of the other... (depending on your perspective). Dockerdesktop running a linux image on a windows box is most certainly a tool... that same container being ported to lcx in production makes it a package manager. Who is a subset of whom is something we could debate but these things can be both.

[prmoustache]

Honestly I don't understand that obsession of developers with building and distributing binaries themselves. That is the less fun part.

When I write something, I just release the source code and I let other do the non fun part for me. You just have to mention the dependencies and how to build and that's it.

[EraYaN]

Because it's easier to support, easier to answer bug reports and/or crash reports etc. And distros can now not mess up the build too much, which happens a lot with any sufficiently complicated piece of software. Besides your average user does not want to deal with building something like OBS or Ardour or any of these programs that have a ton of dependencies and no real unified package manager to install them.

[bayindirh]

> Software devs who live in user space want a more "App Store" like delivery mechanism where they have control.

They can have control. They can say that we have flatpaks and app images we publish and support, and they only support the latest version (or the same minor version, whatever), and can say that packages got from distros may not be the latest.

There's no need for a yelling match, IMHO.

Distros also can do whatever they want. Like rclone. You can get the packages from rclone.org or from your distros. There's no yelling match, but trade-offs.

> ...that same container being ported to lcx in production makes it a package manager.

I don't think so. I have containers which work like binaries (in the form of "./binary infile outfile" fashion) and exit after processing what I give them. For me that container is a utility program as a whole. Same for the imap-backup example.

When you think services which are always on, docker might be a package manager, but I pack my own containers for example, so it's more like compiling for me.

So, what docker or containers is depends on your perspective, or like a chameleon which changes its color according to the landscape it's in.

So, it's a tool in the end. Package managers are tools, too.

[sloowm]

I think it was Flatpak that Bottles prefers.

The thing with Bottles is that it also relies on a very specific setup of all underlying software. So in that case it's more about complexity that leads to the need of containerization than keeping systems clean or containerizing for sandboxing.