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.

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.

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.

IMO Nix code is the exact opposite of easy to read and usable. I used it on my headless box at home for a couple of years and really liked the concept, but the syntax is just way too hard to use IMO. I'd like to take a look at using guix as the lisp syntax I think is much easier to grok.

Yep, that's why I second to try GuixSD but for now GuixSD is really raw&limited compared to NixOS... And nix itself while in some case it's not much clear for most usage is clear enough...

You should look into Darch.

https://godarch.com/

"Think Dockerfiles, but for bootable, immutable, stateless, graphical (or not) environments for your everyday usage"

It supports Arch/Debian/Ubuntu/VoidLinux.

Almost any Linux distribution can do that. Why I should chose an obscure distribution instead of major one, like Fedora?

Tell me how... Saltstack/Ansible on top of traditional distro is a small car compared to a spaceship...

BTW NixOS, repology at hand, offer the most up to date and big package set, second only to Arch AUR... Fedora and Ubuntu are far behind. Not so "obscure" IMO...

Repology is slightly misleading here.

NixOS includes packages for multiple Python versions, as well as a large fraction of PyPi multiplied by the number of Python versions on which they run, and Repology counts all of them despite these being basically the same package.

It's still a large package set even accounting for that, but it's not that large.

That's true but also that's means that you can tweak your environment with nix, for instance if you develop in python, while on Ubuntu/Fedora you have to go by hand/pip etc. It's IMO a plus, even if it's "hard to say they are independent pkgs".

I can also add few Gnome Shell extensions, Emacs packages and Vim plugins etc. They may "count less" but when you build your system, for instance via homeManager they count.

Having switched off Ubuntu when Canonical decide to leave desktop (because yes abandon Unity7 means leave desktop, and adding 10+year support to latest LTS means the same) I found a far more up to date system with a bigger package selection than Ubuntu, plus all the advantage of a functional OS (replication, never-brake updates, major distro version included etc)...

I can't really measure accurately nor package coverage nor popularity but I found NixOS all but certainly not an obscure distro... For GuixSD I'm a bit less happy since while I like scheme vs nix, I like Emacs integration and Emacs related packages it really suffer from having too few devs. But not NixOS. NixOS IMO is production-ready and a good choice other RH/Ubuntu for server usage...

> 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.

I'm not a container historian, but I believe this came later: when Docker and the like entered the scene with their ideas of immutability, LXC on Linux was already several years old, and BSD Jails / Solaris Zones probably a decade older still; and they were all quite mutable.

When I first came across them, I viewed them as very lightweight VMs, with (as you say) rather insufficient security, but still useful for experiments or to segregate services for ease of management.

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.

You should look into Darch.

https://godarch.com/

"Think Dockerfiles, but for bootable, immutable, stateless, graphical (or not) environments for your everyday usage"

It supports Arch/Debian/Ubuntu/VoidLinux.

You are confusing packaging, orchestration and virtualization.

Take a look at NixOS then :-)

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.

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.

> many independent packagers of various distro check out that code and package it

This doesn't scale any more and hasn't scaled for a long time. Most of the time the software I need isn't in the distro or is too old.

I found everything I need in NixOS, Arch and in general community-based true distro (true means not a recompilation of another distro). While I often found old software in Ubuntu and Fedora, for instance.

This system scale far more than proprietary one, to the point that after decades proprietary OS choose "repo model" instead of single independent installer (because yes, Play store, Apple Store, Samsung Store, Windows store etc are a limited and limiting repo-model software distribution).

People that say it doesn't scale are IMO two kind: one that produce software no one is really interested to package or people who struggle to being part of a community or do not want being part at all because they want proprietary software...

Another important thing: having an integrated, well functional system is FAR more important than having the latest build from a CI. Software freshness is not a problem to a point that in operation we never trust an unpatched release on anything. Freshness is normally required by crapware devs who produce normally monsters that need a continuous stream of "fixes", like most commercial business softwares so they can't really keep up with a traditional model.

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.

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

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.

> 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.

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.

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.

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.

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

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.

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.