7 ms·

In my own personal opinion container idea is "meh" and today's usage trends are AWFUL. They serve a sole real purpose, open door to proprietary software on GNU/

by xte 8y ago

In my own personal opinion container idea is "meh" and today's usage trends are AWFUL. They serve a sole real purpose, open door to proprietary software on GNU/Linux destroying it's community model. You can't run unsafe software in safety, it's a myth. Or worse is giving trust to a specific tech and so ignore both it's potential mistrust and other software security implications. The future for me is Nix{,OS}/Guix{,SD} certainly not "chroots"/"jails"/"zones"/"lpar"/*.

trulyrandom 8y ago
> They serve a sole real purpose, open door to proprietary software on GNU/Linux destroying it's community model. I agree. Especially Flatpak and AppImage facilitate this goal. I do run some software that communicates with the internet in a bubblewrap sandbox, like Chromium and Transmission, but other than that I shouldn't have to run every piece of software in a container to be safe.
- xte 8y ago
  Not only that: take a look at Emacs: essentially no one Emacs is equal to another. It's so flexible that any users bend it (easily) to their needs and desire. Sharing their configs is a mean for any users to evolve, acquire knowledge easily; you have a problem or need something? Ok go look for others chances that they already see and solved that problem are really high. With "black boxes" you can only customize what black box dev's have leaved to their users, real changes are hard, you have to checkout code, study it, modify it, rebuilt, ... in the end you're became as "standard" as possible without freedom and personal experimentation even if you have the open code. That's easy for companies since they deal with "standard" "Ford model like" people, but that's a killer for evolution especially evolution driven by people/users, not upstream/companies. If you can tailor software to fit your needs as you like you get a friendly personal environment and you have "a bit of power" on society, you still need upstream work but you are also a bit independent, and the same is for upstream to have help from the community they need to comply with an heterogeneous community with users, not consumers. We are in the end interdependent so forced to cooperate in a relative peace. On the over side we totally depend on upstream being effectively powerless. Oh yeah, you can choose different software, at least for now, but that need to exists, that's no more a community. A simple example a proprietary software, Master pdf editor, gain a bit of success in GNU/Linux world and decide to insert watermark on modify pdfs by free version. If it's distributed by single distro, single distros can keep old version for long time. Leaving all needed time to their user to switch. If you relay direct on upstream you discover the new "feature" a day perhaps without warning because it's auto-updated for instance, and you may have no time, no choice. This also happen recently with the "tweaked" Android settings by Google and I think many many other cases. Freedom it's not only "being free of doing something" it's also can do something easily, have a system that let you be as free as you like.
  - nameless912 8y ago
    I'm confused. What about containers makes them inherently less free than other tech? Ultimately, they're "just" a layered filesystem with some OS-level isolation magic sprinkled on top, they're not really revolutionary in any meaningful way other than that they unified two pre-existing technologies. LXC/OCI are great specifically because they give you a reasonable scaffolding upon which to build your containers, but you get to define every last thing that goes into them. Example: I used to work at a place that, for a variety of reasons, needed to use custom builds of upstream Debian packages. So, we created our own Debian container base and rebuilt all the major Docker container "base" images (e.g. `openjdk`, `python`, `node`, `nginx`) with our own image as base. We had custom control all the way down to the OS level, and our orchestration solution (Kubernetes in our case, but a pile of shell scripts calling LXC directly works too). I totally get being skeptical of {Docker|Kubernetes|Mesos|GKE|EKS|AKS}, but there's nothing inherently "un-free" about containers. They're a nice packaging primitive that happen to have some (useful, but not mission-critical) security features bundled in. So, your whole point kinda confuses me. That containers are standardized by OCI/LXC just makes them easier on your poor sysadmins to administer than 100 engineers' pet servers each running a different version of Emacs.
    - xte 8y ago
      Not unfree by itself but as a model: free software are born to be as integrated, flexible, easy to evolve as possible, isolation means or that you can't properly integrate your software or you can't trust it. Think about the level of integration of Emacs and it's flexibility vs Eclipse/VSc/... the former is completely integrated and you can essentially modify any aspect at runtime with a simple sexp/config change. While the letter require to write and maintain plugins. The burden between programming and using in Emacs is substantially nonexistent, while you feel it on any modern software. I do not know if it's clear seeing my bad English but I hope so. Think another example, Xerox model Alto&other Smalltalk machines, freedom it's not only the code but the way you use and customize your system, it's simplicity and flexibility. In FOSS we are all a bit devs, a bit admin, a bit users, a bit ..., while in proprietary world anything is rigid compartmentalized and "switch" between compartments it's not easy. The very same concept apply to containerization of software.
ngcazz 8y ago
Do you have any data to back up your assertion? Not being facetious here, really would like to understand these downsides. To be honest I think it unfair to ignore the fact that you can build your own containers to leverage dependency isolation, or to deploy through an orchestration engine ie. Kubernetes.
- xte 8y ago
  I can cite number of vulnerabilities found in snap, flatpack, appimage and see it per unit of time since they exists compared to number of vulnerabilities in classic packages found per unit of time. But that's an pointless exercise. Today's mania of "data", most of the time meaningless (they "prove" different and often opposite things depending on how you arrange them) it's a way to silence discussion or prove true false things. Consider a simple thing: traditional FOSS model consists of: - upstream devs that release their code - many independent packagers of various distro check out that code and package it - users get packaged code by their distro This means that many eyes see the code at minimum enough to compile and figure out why it doesn't work properly in their distro. They often patch and suggest improvements. Users get different binaries on different distros. Due to actual package model proprietary software can't be easily distributed as first class citizen by the vendor to the users simply because package an apps for any distro is unfeasible. Proprietary vendor have two options: allow redistribution so distro packagers (many different subjects) control distribution of their binaries or support only few distro leaving the over aside. So in synthesis in this model proprietary software is not first class nor welcomed and many different subjects with many different idea, environments etc pass the code around make it more portable (or it's a pain to be ported), up to date (or it's a pain to compile on different distro since [br]deps aren't under upstream control and no unique binary is around to be tried to exploit thanks to various bugs. In "container model" especially snap&c upstream package the final binary with all dependency. No more single independent distro packagers have to exists. No more need to be up to date for the upstream due to [br]deps updates on various distro. No more packagers check and improvement suggestions/patches from packager to the upstream. Only a straight line from "producer" to "consumers". Ideal situation for proprietary software since it can be now first class. Distro reduced to be a platform like a cargo ship instead of a compilation of various software, i.e. having different distros became meaningless since they are only a base for application. That's is. On FOSS/traditional model collaboration of different subjects with different interests, idea, competence, scattered around the world is NEEDED by design. On container model no communication is need and there are "compartments" between "producer" and "consumers" instead of an heterogeneous blends between them. Any time you reduce diversity, you compartmentalize, you empower people letting them operate "alone" you get bed results. That's the best "data" to back up such assertion. Is freedom and collaboration vs isolation in a rigid, compartmentalized system. To have a big "security proof" take a look at how many vulnerabilities and how serious they are in proprietary products vs FOSS software.
rkeene2 8y ago
LPARs are closer to VMs than containers. WPARs (workload partitions) may be what you are thinking of.
- xte 8y ago
  Yep, thanks for correction :-) Anyway for me OS partition or real virtualization are similar beast, while on power they have no overhead they are still a sign of bad development model. A way of avoid solving a problem proposing "intermediate" solutions.
zerogvt 8y ago
I agree but in containers' defense they weren't supposed to be about security in the first place. In my understanding the main incentive for the huge push behind them was immutability and them being microservices-friendly technology.
- blitmap 8y ago
  I wholeheartedly agree with this endeavor. Traditional packaging is so messy with a unified tree. We have claimed a lot of ground toward immutable systems. I totally love how easy it has become to scale horizontally in hardware and add virtual nodes to extend containers into.
  - xte 8y ago
    Take a look at NixOS then :-)
  - eeZah7Ux 8y ago
    You are confusing packaging, orchestration and virtualization.
  - pknopf 8y ago
    You should look into Darch. https://godarch.com/ https://godarch.com/ "Think Dockerfiles, but for bootable, immutable, stateless, graphical (or not) environments for your everyday usage" It supports Arch/Debian/Ubuntu/VoidLinux.
- michaelcampbell 8y ago
  Containers made a huge impact on my workflow, and I consider them just a way to ease packaging. Nothing else; all the other considerations of software must still be considered.
- xte 8y ago
  With NixOS and GuixSD you have easy to deploy, easy to update immutable systems with IaC built-in and no containers at all... They can be used also for development create isolated FHS environments with a simple text file describe the environment, again without containers. That's one of the reason I consider them the future, you have: - built-in infrastructure as code - built-in immutable servers - built-in orchestration/provisioning All with human-readable, easy to manage, text files.
juskrey 8y ago
In NixOS containers are just systemd containers with all of the default root breach problems, no?
- wmf 8y ago
  The author seems to be talking about NixOS without containers. If you have an all-powerful package manager you can solve dependency problems "properly" (i.e. with parallel installs of multiple versions of packages) instead of shoving everything into containers.
- Filligree 8y ago
  NixOS containers, or systemd services or whatever, are not intended as a security mechanism. Neither are Docker containers, they've just gotten shoehorned into the role. For security you'll need some other mechanism, but it does solve the immutability / replication problem.
eeZah7Ux 8y ago
People constantly confuse the security benefits of sandboxing and isolating applications (seccomp etc) with "containers". Most container implementations were not born with security in mind. Also, overlay filesystem are not required for improving application isolation. There's a zoo of unmaintained docker images, snap and appimage packages & same Linux distributions that are full of vulnerabilities. Nobody care or has the time to backport security fixes to whole zoo, unlike traditional distributions where maintainers are responsible for doing that. Statically compiled languages are only making things worse. This is going to come back and hurt all of us in few years.

by xte 8y ago

trulyrandom 8y ago

> They serve a sole real purpose, open door to proprietary software on GNU/Linux destroying it's community model. I agree. Especially Flatpak and AppImage facilitate this goal. I do run some software that communicates with the internet in a bubblewrap sandbox, like Chromium and Transmission, but other than that I shouldn't have to run every piece of software in a container to be safe.

xte 8y ago
Not only that: take a look at Emacs: essentially no one Emacs is equal to another. It's so flexible that any users bend it (easily) to their needs and desire. Sharing their configs is a mean for any users to evolve, acquire knowledge easily; you have a problem or need something? Ok go look for others chances that they already see and solved that problem are really high. With "black boxes" you can only customize what black box dev's have leaved to their users, real changes are hard, you have to checkout code, study it, modify it, rebuilt, ... in the end you're became as "standard" as possible without freedom and personal experimentation even if you have the open code. That's easy for companies since they deal with "standard" "Ford model like" people, but that's a killer for evolution especially evolution driven by people/users, not upstream/companies. If you can tailor software to fit your needs as you like you get a friendly personal environment and you have "a bit of power" on society, you still need upstream work but you are also a bit independent, and the same is for upstream to have help from the community they need to comply with an heterogeneous community with users, not consumers. We are in the end interdependent so forced to cooperate in a relative peace. On the over side we totally depend on upstream being effectively powerless. Oh yeah, you can choose different software, at least for now, but that need to exists, that's no more a community. A simple example a proprietary software, Master pdf editor, gain a bit of success in GNU/Linux world and decide to insert watermark on modify pdfs by free version. If it's distributed by single distro, single distros can keep old version for long time. Leaving all needed time to their user to switch. If you relay direct on upstream you discover the new "feature" a day perhaps without warning because it's auto-updated for instance, and you may have no time, no choice. This also happen recently with the "tweaked" Android settings by Google and I think many many other cases. Freedom it's not only "being free of doing something" it's also can do something easily, have a system that let you be as free as you like.
- nameless912 8y ago
  I'm confused. What about containers makes them inherently less free than other tech? Ultimately, they're "just" a layered filesystem with some OS-level isolation magic sprinkled on top, they're not really revolutionary in any meaningful way other than that they unified two pre-existing technologies. LXC/OCI are great specifically because they give you a reasonable scaffolding upon which to build your containers, but you get to define every last thing that goes into them. Example: I used to work at a place that, for a variety of reasons, needed to use custom builds of upstream Debian packages. So, we created our own Debian container base and rebuilt all the major Docker container "base" images (e.g. `openjdk`, `python`, `node`, `nginx`) with our own image as base. We had custom control all the way down to the OS level, and our orchestration solution (Kubernetes in our case, but a pile of shell scripts calling LXC directly works too). I totally get being skeptical of {Docker|Kubernetes|Mesos|GKE|EKS|AKS}, but there's nothing inherently "un-free" about containers. They're a nice packaging primitive that happen to have some (useful, but not mission-critical) security features bundled in. So, your whole point kinda confuses me. That containers are standardized by OCI/LXC just makes them easier on your poor sysadmins to administer than 100 engineers' pet servers each running a different version of Emacs.
  - xte 8y ago
    Not unfree by itself but as a model: free software are born to be as integrated, flexible, easy to evolve as possible, isolation means or that you can't properly integrate your software or you can't trust it. Think about the level of integration of Emacs and it's flexibility vs Eclipse/VSc/... the former is completely integrated and you can essentially modify any aspect at runtime with a simple sexp/config change. While the letter require to write and maintain plugins. The burden between programming and using in Emacs is substantially nonexistent, while you feel it on any modern software. I do not know if it's clear seeing my bad English but I hope so. Think another example, Xerox model Alto&other Smalltalk machines, freedom it's not only the code but the way you use and customize your system, it's simplicity and flexibility. In FOSS we are all a bit devs, a bit admin, a bit users, a bit ..., while in proprietary world anything is rigid compartmentalized and "switch" between compartments it's not easy. The very same concept apply to containerization of software.

ngcazz 8y ago

Do you have any data to back up your assertion? Not being facetious here, really would like to understand these downsides. To be honest I think it unfair to ignore the fact that you can build your own containers to leverage dependency isolation, or to deploy through an orchestration engine ie. Kubernetes.

xte 8y ago
I can cite number of vulnerabilities found in snap, flatpack, appimage and see it per unit of time since they exists compared to number of vulnerabilities in classic packages found per unit of time. But that's an pointless exercise. Today's mania of "data", most of the time meaningless (they "prove" different and often opposite things depending on how you arrange them) it's a way to silence discussion or prove true false things. Consider a simple thing: traditional FOSS model consists of: - upstream devs that release their code - many independent packagers of various distro check out that code and package it - users get packaged code by their distro This means that many eyes see the code at minimum enough to compile and figure out why it doesn't work properly in their distro. They often patch and suggest improvements. Users get different binaries on different distros. Due to actual package model proprietary software can't be easily distributed as first class citizen by the vendor to the users simply because package an apps for any distro is unfeasible. Proprietary vendor have two options: allow redistribution so distro packagers (many different subjects) control distribution of their binaries or support only few distro leaving the over aside. So in synthesis in this model proprietary software is not first class nor welcomed and many different subjects with many different idea, environments etc pass the code around make it more portable (or it's a pain to be ported), up to date (or it's a pain to compile on different distro since [br]deps aren't under upstream control and no unique binary is around to be tried to exploit thanks to various bugs. In "container model" especially snap&c upstream package the final binary with all dependency. No more single independent distro packagers have to exists. No more need to be up to date for the upstream due to [br]deps updates on various distro. No more packagers check and improvement suggestions/patches from packager to the upstream. Only a straight line from "producer" to "consumers". Ideal situation for proprietary software since it can be now first class. Distro reduced to be a platform like a cargo ship instead of a compilation of various software, i.e. having different distros became meaningless since they are only a base for application. That's is. On FOSS/traditional model collaboration of different subjects with different interests, idea, competence, scattered around the world is NEEDED by design. On container model no communication is need and there are "compartments" between "producer" and "consumers" instead of an heterogeneous blends between them. Any time you reduce diversity, you compartmentalize, you empower people letting them operate "alone" you get bed results. That's the best "data" to back up such assertion. Is freedom and collaboration vs isolation in a rigid, compartmentalized system. To have a big "security proof" take a look at how many vulnerabilities and how serious they are in proprietary products vs FOSS software.

rkeene2 8y ago

LPARs are closer to VMs than containers. WPARs (workload partitions) may be what you are thinking of.

xte 8y ago
Yep, thanks for correction :-) Anyway for me OS partition or real virtualization are similar beast, while on power they have no overhead they are still a sign of bad development model. A way of avoid solving a problem proposing "intermediate" solutions.

zerogvt 8y ago

I agree but in containers' defense they weren't supposed to be about security in the first place. In my understanding the main incentive for the huge push behind them was immutability and them being microservices-friendly technology.

blitmap 8y ago
I wholeheartedly agree with this endeavor. Traditional packaging is so messy with a unified tree. We have claimed a lot of ground toward immutable systems. I totally love how easy it has become to scale horizontally in hardware and add virtual nodes to extend containers into.
- xte 8y ago
  Take a look at NixOS then :-)
- eeZah7Ux 8y ago
  You are confusing packaging, orchestration and virtualization.
- pknopf 8y ago
  You should look into Darch. https://godarch.com/ https://godarch.com/ "Think Dockerfiles, but for bootable, immutable, stateless, graphical (or not) environments for your everyday usage" It supports Arch/Debian/Ubuntu/VoidLinux.
michaelcampbell 8y ago
Containers made a huge impact on my workflow, and I consider them just a way to ease packaging. Nothing else; all the other considerations of software must still be considered.
xte 8y ago
With NixOS and GuixSD you have easy to deploy, easy to update immutable systems with IaC built-in and no containers at all... They can be used also for development create isolated FHS environments with a simple text file describe the environment, again without containers. That's one of the reason I consider them the future, you have: - built-in infrastructure as code - built-in immutable servers - built-in orchestration/provisioning All with human-readable, easy to manage, text files.

juskrey 8y ago

In NixOS containers are just systemd containers with all of the default root breach problems, no?

wmf 8y ago
The author seems to be talking about NixOS without containers. If you have an all-powerful package manager you can solve dependency problems "properly" (i.e. with parallel installs of multiple versions of packages) instead of shoving everything into containers.
Filligree 8y ago
NixOS containers, or systemd services or whatever, are not intended as a security mechanism. Neither are Docker containers, they've just gotten shoehorned into the role. For security you'll need some other mechanism, but it does solve the immutability / replication problem.

eeZah7Ux 8y ago

People constantly confuse the security benefits of sandboxing and isolating applications (seccomp etc) with "containers". Most container implementations were not born with security in mind. Also, overlay filesystem are not required for improving application isolation. There's a zoo of unmaintained docker images, snap and appimage packages & same Linux distributions that are full of vulnerabilities. Nobody care or has the time to backport security fixes to whole zoo, unlike traditional distributions where maintainers are responsible for doing that. Statically compiled languages are only making things worse. This is going to come back and hurt all of us in few years.