Container Linux on the Desktop [slides](docs.google.com)
docs.google.com
Container Linux on the Desktop [slides]
https://docs.google.com/presentation/d/17Hml1iFqdXElxOcrh9caQSC5px5mDgaS015Vhaz42ZY
58 comments
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.
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.
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.
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.
https://godarch.com/
"Think Dockerfiles, but for bootable, immutable, stateless, graphical (or not) environments for your everyday usage"
It supports Arch/Debian/Ubuntu/VoidLinux.
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...
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...
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.
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 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.
> 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.
https://godarch.com/
"Think Dockerfiles, but for bootable, immutable, stateless, graphical (or not) environments for your everyday usage"
It supports Arch/Debian/Ubuntu/VoidLinux.
Take a look at NixOS then :-)
You are confusing packaging, orchestration and virtualization.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Very interesting work.
I have seen OpenBSD's pledge, and unveil systemcalls that achieve this easily for applications running on OpenBSD. Elegant in the way it's done.
On the other hand, running container images for wmeverything including text editor seems like a NIMBYism in OS and packages. There is a reason why our OSes evolved with package managers. Sharing and reusing common libraries so that they can be updated once safely. Bug in libsodium? Update libsodium in your system, and all applications that use it automatically get new version.
With containers, you have to rely on each and every container to update libsodium...
Secondly, it takes away the sharing so you have several copies of libraries for each applications you use as containers.. What does it do to memory usage, and disk usage?
Very interesting either way, and got me thinking about using such for specific cases.
I have seen OpenBSD's pledge, and unveil systemcalls that achieve this easily for applications running on OpenBSD. Elegant in the way it's done.
On the other hand, running container images for wmeverything including text editor seems like a NIMBYism in OS and packages. There is a reason why our OSes evolved with package managers. Sharing and reusing common libraries so that they can be updated once safely. Bug in libsodium? Update libsodium in your system, and all applications that use it automatically get new version.
With containers, you have to rely on each and every container to update libsodium...
Secondly, it takes away the sharing so you have several copies of libraries for each applications you use as containers.. What does it do to memory usage, and disk usage?
Very interesting either way, and got me thinking about using such for specific cases.
It's worse on several levels. The first thing containers do is take away the tools needed (unshare, seccomp syscalls) for an application to secure itself or its children.
The pledge/unveil model is far more elegant.
> What does it do to memory usage, and disk usage?
You'd need a deduplicating filesystem, i.e. btrfs for the storage aspect. For memory consumption you either have to rely on KSM or hope that they will implement page cache sharing it for btrfs. Overlayfs has it but it's less space-efficient.
But I agree that this shouldn't be needed because containers shouldn't each ship with their own OS disk image. That's not orthogonal to the security aspect.
The pledge/unveil model is far more elegant.
> What does it do to memory usage, and disk usage?
You'd need a deduplicating filesystem, i.e. btrfs for the storage aspect. For memory consumption you either have to rely on KSM or hope that they will implement page cache sharing it for btrfs. Overlayfs has it but it's less space-efficient.
But I agree that this shouldn't be needed because containers shouldn't each ship with their own OS disk image. That's not orthogonal to the security aspect.
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).
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).
[deleted]
In practice containers are siblings with a lot of redundant data, not a layer cake.
> You'd need a deduplicating filesystem
Until all your packages decide to use different versions of their dependencies.
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.
see https://www.usenix.org/legacy/events/atc10/tech/full_papers/..., https://www.usenix.org/legacy/event/lisa11/tech/full_papers/..., and https://patents.google.com/patent/US8589947
I'd argue that docker copied this in a degenerate way, but that those papers implemented what you asked for.
I'd argue that docker copied this in a degenerate way, but that those papers implemented what you asked for.
I guess it's give and take - on one hand containers would isolate processes such that a security bug in an application shouldn't allow an attacker to propagate to the rest of the system. On the other, updates are not centralized anymore as you pointed out. Then again, the most commonly used distros have a slow update cycle anyways, so I don't think it would change that much if they rebuild container images rather than packages for each release. Plus, isolation would allow software to be tested independently from each other, so rolling distros could become easier to handle for the maintainers and more stable. IMO from a development perspective it makes sense as a step forward.
The corresponding talk is on Youtube, here: https://www.youtube.com/watch?v=gES4-X6y278
I must say I am tempted by Qubes OS as a way to get this level of isolation between apps. However I'd likely need a new laptop, as RAM requirements are much higher.
I've been considering QubesOS for my next laptop (won't do it on desktop yet; still like my gaming too much). My old netbook is dying, and I'm considering something more powerful to do coding on. However, given that the lead of Qubes just left, I'm wondering what the future of the project is going to look like.
8 GB is easily enough for most cases.
The main source of trouble is web browsers and IDEs having problems at low memory... (As if 2GB is not enough RAM for a web browser or a glorified text editor. Shame on them!) Those same applications cause trouble on 8GB system.
Of course you will need more if you want to play high end games in a VM. Or run many Windows instances as that hog eats 512 MB RAM when fully loaded in and doing nothing. (Unless it is ReactOS which is still frugal.)
16 GB RAM essentially guarantees high comfort in a such VM system as you can usually allocate extra GBs to offending special purpose VMs.
The main source of trouble is web browsers and IDEs having problems at low memory... (As if 2GB is not enough RAM for a web browser or a glorified text editor. Shame on them!) Those same applications cause trouble on 8GB system.
Of course you will need more if you want to play high end games in a VM. Or run many Windows instances as that hog eats 512 MB RAM when fully loaded in and doing nothing. (Unless it is ReactOS which is still frugal.)
16 GB RAM essentially guarantees high comfort in a such VM system as you can usually allocate extra GBs to offending special purpose VMs.
I can't trust anything which based on Xen and doesn't have a battalion of paid engineers for support.
Qubes OS has a significant limitation in that it isn't designed to allow anything to run in dom0, so nothing can use the GPU.
I got a new MacBook Pro from work a couple of months ago, and decided to try a scaled back version of this. You can’t reasonably run graphical apps in Docker on MacOS, but most of the CLI tools that I would install via HomeBrew can be run in Docker. I took the same approach that Jess did, and set up a a shell alias for these commands. That way I run the command the way I would normally run it from Terminal.app, but the app isn’t installed at all on my host.
To be clear: I have no real reason to do this, other than to just see how it works. It’s nice to know that if I got a new machine tomorrow, all of the CLI stuff I need is defined in some Dockerfiles and bash aliases, and could be reinstalled pretty quickly. There are other ways to do that, but it’s a fun experiment. In practice, there’s really very little noticeable overhead to running things this way on modern hardware, but I’m also not running things in tight loops where that overhead would matter.
If you’re curious at all about this, Jess has a couple of Github repos worth looking at:
https://github.com/jessfraz/dockerfiles/
https://github.com/jessfraz/dotfiles
Specifically, her aliases are set up here: https://github.com/jessfraz/dotfiles/blob/master/.dockerfunc
To be clear: I have no real reason to do this, other than to just see how it works. It’s nice to know that if I got a new machine tomorrow, all of the CLI stuff I need is defined in some Dockerfiles and bash aliases, and could be reinstalled pretty quickly. There are other ways to do that, but it’s a fun experiment. In practice, there’s really very little noticeable overhead to running things this way on modern hardware, but I’m also not running things in tight loops where that overhead would matter.
If you’re curious at all about this, Jess has a couple of Github repos worth looking at:
https://github.com/jessfraz/dockerfiles/
https://github.com/jessfraz/dotfiles
Specifically, her aliases are set up here: https://github.com/jessfraz/dotfiles/blob/master/.dockerfunc
I run as much python/node/ruby/whatever inside of containers as possible but packaging up something like vim would probably just make me angry with the little startup delays :)
I just want to be able to have multiple, suspendible desktop sessions with different apps running and/or installed and different files available. Ideally I should be able to kick up more than one at a time to let them exchange data. Preferably without having to run a full VM per session. Bonus points if I can ship them between physical machines, though I know that's a long shot.
That's more interesting to me than individually-containerized applications. I want to have per-project and/or per-task-group desktop sessions that are right where I left them when I spin them back up, within reason. That's the one big "killer feature" I feel lacking in every modern desktop OS I use.
That's more interesting to me than individually-containerized applications. I want to have per-project and/or per-task-group desktop sessions that are right where I left them when I spin them back up, within reason. That's the one big "killer feature" I feel lacking in every modern desktop OS I use.
You can stop and continue tasks easily (eg just SIGSTOP them), but if you want them to stop using memory and kernel resources while suspended, then it's equivalent to process checkpointing. Which has proven a hard problem on Linux so far.
This is the main reason I prefer CLI programs: I can have several sessions inside dvtm running in abduco and suspend/restore sessions at any time.
I'd love to see what you propose, but I don't think there is anything remotely similar.
I'd love to see what you propose, but I don't think there is anything remotely similar.
This is a really nice idea for anyone who wants to learn containers from scratch and get deeper into appsec.
But I can't think of a valid reason why anyone would want to use this in practice when there is QubesOS. If the reason is to increase my base-layer of security for OpSec, then this is a poor choice. Perhaps this is what she meant in the slides when she says don't try this at home ... maybe she explained it better in the talk (I haven't watched it). Seriously don't do this at home unless it's for educational purposes (in that case I agree it is awesome).
But I can't think of a valid reason why anyone would want to use this in practice when there is QubesOS. If the reason is to increase my base-layer of security for OpSec, then this is a poor choice. Perhaps this is what she meant in the slides when she says don't try this at home ... maybe she explained it better in the talk (I haven't watched it). Seriously don't do this at home unless it's for educational purposes (in that case I agree it is awesome).
You can get this running with LXD (system containers).
Some people managed to get a whole GUI running in a LXD container.
Running everything in a container is the definition of commitment! I am looking forward to the day when this is normal.
It of makes a lot of sense to do that. One thing I appreciate with running server side stuff in containers is just how easy it is. Instead of installing mysql, having to worry about setting that up, creating a mysql user, etc. I just run it with a one liner and it runs. And when I stop it, I can cleanup the containers and volumes and it is gone. No surprise that this has become the norm for server side deployments.
It seems that that could be a nice thing to have with basically any kind of software package on the desktop as well. In a way that is the attraction of having browser based software: you just go to a particular website to run a web app. No installation needed. No need to worry about updates. Just run it.
I actually get the architectural purity that drove this person to do this. Why settle for less? Why accept all the kludges, legacy cruft, stupid hacks, and ugliness that we accept as normal? As, she's demonstrated, there's no good reason.
It seems that that could be a nice thing to have with basically any kind of software package on the desktop as well. In a way that is the attraction of having browser based software: you just go to a particular website to run a web app. No installation needed. No need to worry about updates. Just run it.
I actually get the architectural purity that drove this person to do this. Why settle for less? Why accept all the kludges, legacy cruft, stupid hacks, and ugliness that we accept as normal? As, she's demonstrated, there's no good reason.
I've been running Silverblue (https://silverblue.fedoraproject.org/) for the past month or so and for the most part you can use it as a daily driver. The OS itself is an immutable image created and updated with OSTree, and you can layer RPMs on top if they don't fit a containerized workflow. For applications, you either run Flatpaks (for desktop) or Docker/OCI images through podman.
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.
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.
is there an actual talk we can listen/watch somewhere ?
Thanks
Thanks
Yes, already linked in a comment:
https://news.ycombinator.com/item?id=18500903
https://news.ycombinator.com/item?id=18500903
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"/*.