Container Linux on the Desktop [slides]

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

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.

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.

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.

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

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.

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.

> You'd need a deduplicating filesystem

Until all your packages decide to use different versions of their dependencies.

I found this thread which has some stats on the memory savings achieved through KSM, but the results weren't very impressive.

you don't need deduplicating file system or ksm. regular file systems and regular shared read only code pages work fine.

see the links I posted above, if every package (or a subset of packages based on the underlying source package) in a traditional linux distribution is treated as an independent layer that can be composed together on demand (i.e. what happens when you install a package, except much slower) using a traditional union file system you get deduplication (as every image using that package will be sharing the same exact portion of the file systme) and you get memory sharing for free (for exact same reason, as its fundamentally no different than multiple processes on a single host dynamically linking the same binaries).

I am new to Silverblue, but also using it daily for the past month.

An important aspect of it, I think, is "rootless" podman -- I can create and manage containers without elevated privileges. Any required root escalation is done in the containers.

Still, it is weird. GUI apps do work, but hmm.

Solaris Zones are better-integrated than this newfangled podman stuff that you kids are using these days.