The scope seems to be pretty similar to: https://nixos.org/
What is Silverblue?
51–60 of 140 posts
Re: What is Silverblue?
#52Earlier quoted context omitted.
That's a good idea to measure the sharing! Fortunately even if every app gets containerised, not all of those libraries will be duplicated. Specifically each app which forks on its own will still preserve sharing. For example 11 firefox processes I'm running now would share the libraries, whether it's running directly or from docker.
On linux, none of these libraries are duplicated, they are loaded once, and shared across all processes that need them.
Only if they're the same version (which using the older built-in package system all packages are likely built against the same version)...
If the containerised versions of apps all have different versions of dependencies (quite likely IMO as they'll have the freedom to), there won't be any sharing.
Re: What is Silverblue?
#53I 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.
Re: What is Silverblue?
#54The 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.
Re: What is Silverblue?
#55Earlier 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.
Would you rather each update of said binary be dependent on the author or some volunteer? That's how you get Debian stable.. No thanks.
I love Debian stable for this. And then we get MX, Deepin, Ubuntu and Mint..
Re: What is Silverblue?
#56Earlier quoted context omitted.
On linux, none of these libraries are duplicated, they are loaded once, and shared across all processes that need them.
Only if they're the same version (which using the older built-in package system all packages are likely built against the same version)... If the containerised versions of apps all have different versions of dependencies (quite likely IMO as they'll have the freedom to), there won't be any sharing.
Or even different locations. (unless they're hardlinks, or COW files probably) If it's not the same block on the disk, it's going to be duplicated in cache - whether it's the same contents or not.
Re: What is Silverblue?
#57It's worth a moment to give credit to the long defunct Stateless Linux project: https://fedoraproject.org/wiki/StatelessLinux This was imagined a decade ago, but the technology and the market weren't ready then. I am really excited to see it as an actual product.
I'm guessing there are embedded Linux deployments that went this direction even earlier. Read-only rootfs is generally a good idea if you can swing it. You gain the ability to sign the rootfs which is good for security.
Having worked on embedded systems with (nearly) read-only root filesystems:
An even bigger motivator is that flash memory lifetime is more determined by number of writes per block rather than time or reads per block. So to keep your storage both cheap and reliable, it's best to flash it with a single full (compressed) image every time you run a firmware upgrade, and otherwise mount it read-only.
Re: What is Silverblue?
#58Earlier quoted context omitted.
What do you mean by 'maintained' automatically? Many flatpaks use their own custom compiled dependencies that are outdated. I took a frequently-used dependency used to decode untrusted data (ffmpeg). Many Flatpaks on Flathub use outdated ffmpeg versions. Some examples: - VLC ships with a slightly older version of ffmpeg (4.1.3) with two known CVEs: https://github.com/flathub/org.videolan.VLC/blob/f1b27c13b13... - Mak…
Aren't flatpaks sandboxed? Does that help mitigate the risk somewhat?
Theoretically yes (minus you are only one kernel vulnerability away from elevated access). However, a lot of Flatpaks take blanket access to the home directory or host filesystem:
https://github.com/search?q=org%3Aflathub+%22--filesystem%3D... https://github.com/search?q=org%3Aflathub+%22--filesystem%3D...
So, many applications use it as a distribution mechanism and not so much for sandboxing. Of course, this is bound to get better over time when applications are modified to support sandboxing better and can use portals.
IMO you need both: isolation through e.g. sandboxing and timely security updates of applications and all their dependencies. Flatpak currently provides the former for some applications and the latter is completely dependent on the maintainer of the Flatpak.
Re: What is Silverblue?
#59Earlier quoted context omitted.
Only if they're the same version (which using the older built-in package system all packages are likely built against the same version)... If the containerised versions of apps all have different versions of dependencies (quite likely IMO as they'll have the freedom to), there won't be any sharing.
Or even different locations. (unless they're hardlinks, or COW files probably) If it's not the same block on the disk, it's going to be duplicated in cache - whether it's the same contents or not.
If the soname is the same between the duplicate copies, and another copy is in $LD_LIBRARY_PATH it shouldn't matter about location.
Re: What is Silverblue?
#60Earlier quoted context omitted.
That's a meme propagated by the news, but I'm pretty sure the desktop is still a thing.
...where? No joke. I seriously don't see desktops running rich applications around anywhere, except the mini-computer / workstation use case. Generally people are running a glorified thin terminal with a browser or putty connection to a dosbox app. People who actually do things on their own computers generally run laptops now. The exceptions are people who do demanding work loads, and they run workstations that can h…
Laptops run desktop operating systems, and that's what pcr910303 was talking about.
Plus "putty connection to a dosbox app"? I have never heard of anyone doing that, and don't understand why they would. Or maybe you don't mean "dosbox" [1], but "console"/"terminal"?