61–70 of 140 posts
I agree that on servers the container runtime makes a lot of sense but not on Desktops where changes happen every day.
Earlier quoted context omitted.
Walk into any random company, there will be many desktops. Sure, some applications are web applications, but they will typically also use Microsoft Office and a smattering of more niche applications. We happen to live across an office tower. People sit and work behind desktops.
Interesting. The offices in the part of the world where I live generally consist of flat surfaces where employees place their company-provided laptops. The exception is things like receptionists, or other areas where multiple employees share a common terminal. But as mentioned before, those computers are basically used as stationary, large-screen browsers or thin clients for cloud applications. Email? Excel? It's bee…
Earlier quoted context omitted.
On linux, none of these libraries are duplicated, they are loaded once, and shared across all processes that need them.
Even when the processes are loading the libraries from different paths, in different filesystems, in different containers? How does it page in data on demand if the first container that loaded the library is killed and its filesystem unloaded? It's not easy to share libraries across containers, unless they can be built to share a base layer in a stacked union filesystem approach.
I have been working on a similar idea (well ok the concept of an immutable desktop - the tech is completely different) - https://github.com/mikadosoftware/workstation/tree/master/bi... The article is completely right about this being the future of user OS's - even my half-broke me-ware above has changed how I think about using my laptop - just knowing exactly what is under me is exactly what I have set is ... reassur…
Thanks for summarizing the crucial piece, that this is about an Immutable OS. You have to scroll 2 full pages before the Silverblue news release actually gets to that.
Basically : the OS is itself a layered read-only "container", on top of which flatpak is the recommended way to install applications. I wish someone built an OS based on k8s as a service and application orchestrator. We wouldn't have to reinvent all the config files, the command line tools and we could reuse knowledge between cluster and single-machine administration. Plus k8s already voluntary abstracted the underly…
Earlier quoted context omitted.
On linux, none of these libraries are duplicated, they are loaded once, and shared across all processes that need them.
Even when the processes are loading the libraries from different paths, in different filesystems, in different containers? How does it page in data on demand if the first container that loaded the library is killed and its filesystem unloaded? It's not easy to share libraries across containers, unless they can be built to share a base layer in a stacked union filesystem approach.
Earlier quoted context omitted.
>system dynamic linking made sense I too look forwards to having to manually updated all security patches for each binary in the system.
This is what Nix gets right. Even if static linking is used, if some dependency is updated, all packages that have that dependency in its transitive closure get recompiled.
> What are the benefits of an immutable OS?
> One of the main benefits is security. The base operating system is mounted as read-only, and thus cannot be modified by malicious software. The only way to alter the system is through the rpm-ostree utility.
How is this different from the current experience? "Operating system" files already aren't writable by the user. The only way to alter the system is through the "sudo" utility.
> Another benefit is robustness. It’s nearly impossible for a regular user to get the OS to the state when it doesn’t boot or doesn’t work properly after accidentally or unintentionally removing some system library. Try to think about these kind of experiences from your past, and imagine how Silverblue could help you there.
How often does this happen? I've worked with complete Linux noobies who were "forced" to use Linux in a VM daily and I've never seen this happen.
The scope seems to be pretty similar to: https://nixos.org/
But there are also large differences. Silverblue still uses a single namespace for all libraries (unless you count Flatpaks, which can bring their own dependencies), whereas on NixOS you can have many different versions of the same library in parallel. In NixOS, the whole system is defined declaratively, including the system configuration, whereas Silverblue uses a mutable /etc.