Yes, it's exactly how docker works if you use it for where it matters for a hobbyist - which is where you are installing random third-party apps/containers that you want to run on your SBC locally.

I don't know why people instantly forget the context of the discussion, when their favorite way of doing things gets threatened. :)

Context is hobbyists and SBC market (mostly various ARM boards). Maybe I'm weird, but I really don't care about minor differences between my arch linux workstation, and my arch linux arm SBCs, because 1) they're completely different architectures, so I can't avoid the differences anyway 2) it's a hobby, I have one instance at most of any service. 3) most hobbyist run services will not work with a shitton of data or have to handle 1000s of parallel clients

> Yes, it's exactly how docker works if you use it for where it matters for a hobbyist

What you described is exactly the opposite of how it works. There is no reasonable scenario in how that is how it works. In fact, what you're saying is opposite of the whole point of containers versus using a VM.

> when their favorite way of doing things gets threatened

No, it's when someone (like you) thinks they have an absolute answer without knowing the context.

And by the way, in my scenario, container overhead is in the range of under a hundred MiB total . The thing I'm working on HAPPENS to require a fair amount of RAM.

But you confidently asserted that "1GiB machine can run a lot of server software". And that's true for many people (like you), but not true for a lot of other people (like me).

> most hobbyist run services will not work with a shitton of data or have to handle 1000s of parallel clients

neither of these are true for me but you need to take a step back and maybe stop making absolute statements about what people are doing or working on :)

> where it matters for a hobbyist

you dont get to define "where it matters" for a hobbyist

> which is where you are installing random third-party apps/containers that you want to run on your SBC locally

this is such a consoomer take. for those of us who actually build software, we have actual valid reasons for using it during development

> they're completely different architectures, so I can't avoid the differences anyway

ironically this is a side benefit modern containers are useful

i think you have a fundamental misunderstanding of how containers work and why theyre useful for software development. based on your other posts in this thread only makes me more sure of that. im not saying containers/etc are a perfect solution or always the right solution, but your misconceptions are separate from that

No I don't have a fundamental misunderstanding. In the entire thread I'm talking about docker, not "containers" in general. You seem to have a misunderstanding apparently.

I've been working with "containers" since before docker existed, and I also wrote several applications that use basic technologies so called "docker containers" are based on in Linux. You can use these technologies (various namespaces, etc.) in a way that does not waste RAM. That will not happen for common docker use, where you don't control the apps and base OS completely. You can if you try hard make it efficient, but you have to have a lot of control. The moment you start pulling random dockerfiles from random sources, you'll be wasting colossal amounts of resources compared to just installing packages on your host OS, to share maximum amount of resources.

And for all these "let's have just a big static binary and put it into a container" containers, that don't really have/or need a real full OS userspace under them, there's barely any difference deployment wise from just running them without docker. In fact docker is just a very complicated additional duplicated layer in this case for what systemd does, that most people already have on their OS. So that's another RAM waste and additional overhead from what is now reduced to a service manager in this use case scenario.

> No I don't have a fundamental misunderstanding. In the entire thread I'm talking about docker, not "containers" in general. You seem to have a misunderstanding apparently.

i said modern containers. and you do have a FUNDAMENTAL MISUNDERSTANDING. you are repeating falsehoods throughout this entire thread.

> That will not happen for common docker use

again you are asserting a "common" use of software, when the people youre replying to are clearly using it for development

> where you don't control the apps and base OS completely

stopping saying "you" to me. id tell you to speak for yourself but you seem incapable of doing that

> And for all these "let's have just a big static binary and put it into a container" containers, that don't really have/or need a real full OS userspace under them, there's barely any difference deployment wise from just running them without docker.

ironically enough it does have differences, glaring big differences. like ironically the deployment differences are about the only reason to use docker in this situation

another stark example of you popping off with incorrect assertions. and yes there are reasons not to do use docker for this as well but it depends on multiple factors

> In fact docker is just a very complicated additional duplicated layer in this case for what systemd does, that most people already have on their OS. So that's another RAM waste and additional overhead from what is now reduced to a service manager in this use case scenario.

there are so many misconceptions in there asserted as if theyre the entire truth. yes people can use docker containers poorly but its not everyone.

> The moment you start pulling random dockerfiles from random sources, you'll be wasting colossal amounts of resources compared to just installing packages on your host OS, to share maximum amount of resources.

its a good thing that I'm not doing that! ive already stated that im using them to build software, not just "pulling random dockerfiles from random sources"

you are digging your heels in and you are now trying to assert a set of conditions and situation in which youre correct, even though youre dead wrong for the use cases that the people youre replying to are describing

you have repeated falsehoods as fact repeatedly and seem unable to adjust to people telling you "im not doing that thing youre complaining about"

frankly, i think youre out of your depth on this subject and youre trying to do anything you can justify your original claim that 1GiB is enough, or whatever

TLDR

feel free to have the last word, im sure youll have lots of them. maybe youll get lucky and a few will be correct. im exiting this conversation

there are no real deployment differences, eg. systemd has portable services, full containers via nspawn, etc. and there are many other ways to realize what docker does with or without containers (eg. what yandex does internally by just packaging their internal software and parts of configuration into debian packages, and manage reproducibility that way)

and you don't provide any other technical arguments

what remains is you strongly telling me something I already acknowledged in the previous post (that you can perhaps make efficient use of docker, but it's hard to make it not waste resources in general use case)