7 ms·

“Container builds simply automate the process of installing and configuring an application in a container that you would do manually. It is a set of instruction

“Container builds simply automate the process of installing and configuring an application in a container that you would do manually. It is a set of instructions to install and configure the application.“ I’m constantly amazed by the lenghts people will go to in order to avoid mastering OS packaging. Coming up with these elaborate schemes, that makes no sense to me.

jitl 8y ago
Containers have much greater flexibility than OS packaging: use different libc library easily, install the same versions of the same package in the official sources without needing to re-package, use a different distro’s packages for a single use-case, isolate permissions and users along with the software, ... Containers are much easier to use than OS packaging: Docker documentation is easily readable online, there are tons of Stack Overflow answers, it makes complex processes like multi-stage chroot builds trivial, it works the same on every OS (including Windows and macOS), running a custom package repo is a single command. ... With a tool that’s so powerful yet easily to use, it’s no wonder that users avoid single-OS skills like Debian or RPM packaging skills.
- Annatar 8y ago
  "Containers have much greater flexibility than OS packaging: use different libc library easily," If you have to use a different libc, that's a kernel engineering problem. On a real UNIX, libc is an integral part of the entire system, is not required to come from another party and is carefully engineered as part of a whole. A good libc requires no alternatives. Case in point: BSD or illumos based operating systems. "Containers are much easier to use than OS packaging:" They might be, but that does not make them better, nor does it make them a correct solution, especially if one is running on an illumos based operating system which actually has true containers in form of Solaris zones. Docker is a solution to a non-existent problem, a problem which wouldn't be there if one of illumos-based operating systems is used as a substrate (refer to vmadm(1M) and imgadm(1M) manual pages for a detailed explanation on why that is so[1][2]). "there are tons of Stack Overflow answers," That is symptomatic of poor or lacking manual pages in the system, which in turn is symptomatic of poor or non-existent system engineering practices. Either way, it's an indicator of insufficiently documented as well as insufficiently integrated software: any time one mentions "Stack Overflow", one has lost, because "Stack Oveflow" is full of answers which work, but aren't correct on a system engineering or architectural level, and most who use it to solve their problems don't have the wherewithal to judge that, or they wouldn't be there in the first place. It's a very vicious cycle and a serious, systemic problem with long term consequences detrimental to the IT industry. [1] https://smartos.org/man/1m/vmadm https://smartos.org/man/1m/vmadm [2] https://smartos.org/man/1m/imgadm https://smartos.org/man/1m/imgadm
AnIdiotOnTheNet 8y ago
OS packaging itself is an overcomplicated scheme for installing applications, which is why people keep trying to fix it with stuff like this or inventing yet another package manager.
- geggam 8y ago
  Yet it is the one solution proven scalable with every distro release that uses it.
- Annatar 8y ago
  OS packaging is the simplest of them all and ideal for large scale configuration management. As another person mentioned, that is the proven technology that has consistently provided the best results over the last 40 years. That’s why I’m completely baffled by these irrational, massive, complex efforts to avoid mastering OS packaging. It’s a joy to build one’s own packages and for the OS to recognize them!
  - AnIdiotOnTheNet 8y ago
    You know what's even simpler? Just put your application in a folder and distribute it.
    - ofrzeta 8y ago
      There have been several approaches to distributing applications with their dependencies such as AppImage or most recently Snap (or Application Bundles on the Mac). For some reason none of them really took of. Ironically the official way of installing LXC and LXD is now through Snap packages.
      - AnIdiotOnTheNet 8y ago
        Indeed there have, and they haven't taken off... in Linux. Which is one of the reasons I think the Linux Desktop is unsalvagable. If the community would rather keep recreating the package manager and never fixing any of its problems as a distribution mechanism than go with the obvious and simple solution, then it is no surprise they have such a small share of the Desktop. Just use folders guys. Mac classic used to essentially do that (it was technically a single file with a resource fork), DOS did that, RiscOS did that, NeXTStep did that and modern MacOS inherited from it and still does that, A lot of Windows applications still work like that even if they don't advertise it, and I'm sure there's a bunch I'm forgetting. Linux Desktop seems like the outlier here, insisting on spreading everything over the file hierarchy and interlocking it all like it's still a server from the 70s.
solipsism 8y ago
I'm at least as amazed that you can't fathom why people would see benefits in applications being self contained. For all of time, anyone installing anything has appreciated applications that have very few dependencies. At scale, much of the Ops complexity of many organizations comes from matching the production environment with the development environment. That goes away when applications are self contained. I don't mean to argue that one way is better than another. Of course there are down sides to things being self contained. Just that if you can't understand the benefits of things being self contained, you might not be thinking hard enough.
- Annatar 8y ago
  I don’t need to break my head with such things because I’ve mastered OS packaging on several operating systems.

jitl 8y ago

Containers have much greater flexibility than OS packaging: use different libc library easily, install the same versions of the same package in the official sources without needing to re-package, use a different distro’s packages for a single use-case, isolate permissions and users along with the software, ... Containers are much easier to use than OS packaging: Docker documentation is easily readable online, there are tons of Stack Overflow answers, it makes complex processes like multi-stage chroot builds trivial, it works the same on every OS (including Windows and macOS), running a custom package repo is a single command. ... With a tool that’s so powerful yet easily to use, it’s no wonder that users avoid single-OS skills like Debian or RPM packaging skills.

Annatar 8y ago
"Containers have much greater flexibility than OS packaging: use different libc library easily," If you have to use a different libc, that's a kernel engineering problem. On a real UNIX, libc is an integral part of the entire system, is not required to come from another party and is carefully engineered as part of a whole. A good libc requires no alternatives. Case in point: BSD or illumos based operating systems. "Containers are much easier to use than OS packaging:" They might be, but that does not make them better, nor does it make them a correct solution, especially if one is running on an illumos based operating system which actually has true containers in form of Solaris zones. Docker is a solution to a non-existent problem, a problem which wouldn't be there if one of illumos-based operating systems is used as a substrate (refer to vmadm(1M) and imgadm(1M) manual pages for a detailed explanation on why that is so[1][2]). "there are tons of Stack Overflow answers," That is symptomatic of poor or lacking manual pages in the system, which in turn is symptomatic of poor or non-existent system engineering practices. Either way, it's an indicator of insufficiently documented as well as insufficiently integrated software: any time one mentions "Stack Overflow", one has lost, because "Stack Oveflow" is full of answers which work, but aren't correct on a system engineering or architectural level, and most who use it to solve their problems don't have the wherewithal to judge that, or they wouldn't be there in the first place. It's a very vicious cycle and a serious, systemic problem with long term consequences detrimental to the IT industry. [1] https://smartos.org/man/1m/vmadm https://smartos.org/man/1m/vmadm [2] https://smartos.org/man/1m/imgadm https://smartos.org/man/1m/imgadm

AnIdiotOnTheNet 8y ago

OS packaging itself is an overcomplicated scheme for installing applications, which is why people keep trying to fix it with stuff like this or inventing yet another package manager.

geggam 8y ago
Yet it is the one solution proven scalable with every distro release that uses it.
Annatar 8y ago
OS packaging is the simplest of them all and ideal for large scale configuration management. As another person mentioned, that is the proven technology that has consistently provided the best results over the last 40 years. That’s why I’m completely baffled by these irrational, massive, complex efforts to avoid mastering OS packaging. It’s a joy to build one’s own packages and for the OS to recognize them!
- AnIdiotOnTheNet 8y ago
  You know what's even simpler? Just put your application in a folder and distribute it.
  - ofrzeta 8y ago
    There have been several approaches to distributing applications with their dependencies such as AppImage or most recently Snap (or Application Bundles on the Mac). For some reason none of them really took of. Ironically the official way of installing LXC and LXD is now through Snap packages.
    - AnIdiotOnTheNet 8y ago
      Indeed there have, and they haven't taken off... in Linux. Which is one of the reasons I think the Linux Desktop is unsalvagable. If the community would rather keep recreating the package manager and never fixing any of its problems as a distribution mechanism than go with the obvious and simple solution, then it is no surprise they have such a small share of the Desktop. Just use folders guys. Mac classic used to essentially do that (it was technically a single file with a resource fork), DOS did that, RiscOS did that, NeXTStep did that and modern MacOS inherited from it and still does that, A lot of Windows applications still work like that even if they don't advertise it, and I'm sure there's a bunch I'm forgetting. Linux Desktop seems like the outlier here, insisting on spreading everything over the file hierarchy and interlocking it all like it's still a server from the 70s.

solipsism 8y ago

I'm at least as amazed that you can't fathom why people would see benefits in applications being self contained. For all of time, anyone installing anything has appreciated applications that have very few dependencies. At scale, much of the Ops complexity of many organizations comes from matching the production environment with the development environment. That goes away when applications are self contained. I don't mean to argue that one way is better than another. Of course there are down sides to things being self contained. Just that if you can't understand the benefits of things being self contained, you might not be thinking hard enough.

Annatar 8y ago
I don’t need to break my head with such things because I’ve mastered OS packaging on several operating systems.