3 ms·
>You asked what they do. I asked for their ostensible justification. A valid answer should not involve making up a justification I never referred to, with the
by SilasX 5y ago
>You asked what they do.
I asked for their ostensible justification. A valid answer should not involve making up a justification I never referred to, with the implication I had done so, with you refuting said justification, even if other people proffer said justification.
And the reason that I asked, was because the first reply eye-rolled at the problem I ran into, and then (seriously, as best I can tell) suggested I should have solved it by nesting a VM within the existing VM to control the dependency chain that led to the problem — even though that was what the first VM exists to solve!
To clarify, here is that (dubious) reply again:
> That's not what containerization is about as can be easily demonstrated by simply running your container on a kernel that's built without some config option you rely on.
That is, surrounding the container by a controlled environment would avoid the problem… but I was already controlling the environment by a VM that exists to solve that problem! Hence, (sardonically) wondering what the first one is accomplishing.
> The most useful feature is they reduce the pain associated having negligently-large build and runtime dependency trees.
No, the most useful feature is locking down a machine spec that Just Works. When I have to go and debug things about that machine that suddenly fail, for reasons Docker (not the machine) introduced, I lost the most useful feature.
Sating my desire to have my app point at port 8000 and no other … is way, way down the list.
- seba_dos1 5y agoJustification? For what? Seems like you're the one who feels entitled for something, it's you who needs justification. > and then (seriously, as best I can tell) suggested I should have solved it by nesting a VM within the existing VM You were the first to suggest anything like that. My answer did not offer any suggestion for solution at all, read it again. > No, the most useful feature is locking down a machine spec that Just Works. That's not a feature Docker ever had or intended to have. Seems you have misunderstood something about what containers actually are. They're very explicitly not "virtual machines lite", and it sounds like you want an actual virtual machine instead.
- hedora 5y agoThere are things that containers acually do (I discussed those above, and won't repeat), and things they ostensibly do, but do not actually do, such as security sandboxing, or providing a fixed, "just works" environment for your binaries, like a VM would. As far as I know, the people making the incorrect claims/assumptions are distinct from the people that built commonly-used containerization software. If you want to understand what containers are, start with the mental model that it is a chroot with /dev, /sys and /proc mounted, and with processes running with uid=0. Their sandboxing isn't quite that bad, but they are closer to chroot environments (or bsd jails) than a VM. Next, package a few things by writing dockerfiles, then deploy them to a raspberry pi or something. If you still care, then follow up by reading the kubernetes tutorials. Edit: This message is directed to SilasX.