justi wrote: > > This is only for ARM, right? I haven't looked but I guess the ARM deb > isn't including all the CPAN versions that the x86 one does, it is 47Mb > compared to 139Mb.
Yes, I should probably have been clearer. The specific architecture .debs are all under 50Mb, though; it's only the multi-arch that gets up to nearly 140Mb. I don't have any experience building for other architectures, but given that the LMS packages are similar in size and the base Debian package (debian-slim) is also around 20Mb in each case, perhaps the other architectures wouldn't be much bigger than my 283Mb final image, if built with the arch-specific .debs. Also, aren't Dockerhub images compressed? The download size for the stretch-slim image listed on Dockerhub is 18.4Mb, but the image on my Pi is 41.5Mb. I'm not sure the image download would necessarily be quite the size you're imagining. > To avoid confusion for others in what you and epoch1970 have said, > images *are always* immutable, they are used to create containers. > Containers have a rw top layer filesystem, and would rarely if ever work > if they were not allowed to write to the filesystem. > > So your concern is over how much writing containers are allowed to do, > and whether patching parts of the software installed in the container is > too much or objectionable for philosophical (not techincal) reasons. > I'm suggesting this is a perfectly reasonable thing to do for > minor/patch updates. But I'm not trying to force it on anyone -- you > don't have to download server updates in LMS and you can remove and > recreate the container if you want to start from a clean slate, no > problem. And I would still suggest that major/stable releases have > their own images built. > Yes, you're right, it is a philosophical point rather than technical and I have also been guilty of confusing -image -and -container -in my text. I meant to say that (philosophically!) *containers* should be immutable. This is a point of view, admittedly, but I would humbly submit 'this blog post' (https://www.docker.com/blog/containers-are-not-vms/) on the official Docker blog as both an explanation of the "official" wisdom (for what it's worth) and a reason why several (even prominent) images may not fully embrace that philosophy (spoiler: it's because people erroneously - according to the blog author - see containers as lightweight VMs). As you've said, of course containers aren't actually immutable or the software running within them would usually not work. A question: is it likely to cause a problem if a patched container is replaced for whatever reason by a new container made from the less up-to-date original image, but keeps the updated prefs / cache folders which are stored in docker volumes outside the container? If so, this may not be a purely philosophical discussion as that is bound to happen at some point. I very much agree with you that the aim should be a reliable image that users can just pull and use without any messing around with Dockerfiles etc. Done right, this should make installing LMS easier than it is at present, particularly for those who already have Docker up and running. ------------------------------------------------------------------------ BobSammers's Profile: http://forums.slimdevices.com/member.php?userid=66026 View this thread: http://forums.slimdevices.com/showthread.php?t=111828 _______________________________________________ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
