Hacker News Reader

Comment by silisili | Hacker News Reader

As a Linux user from the 90s, I welcome this change. RPM Hell and its Debian equivalent are real and painful things. When disk space was a premium, system dynamic linking made sense. Today, it absolutely does not. rpm-ostree is a bit ugly. Snap has the right idea of doing both system services and apps. Fedora should do the same.

View on HN

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

On the author of the single vulnerable library instead of the hundreds of authors of projects making use of it, yes please.

The fact that things like flatpak, snap, nix all explicitly try to address this problem with platforms/base layers/grafting etc. is very telling. They are all a trade off of your security vs. the dev's convenience, which might be necessary to succeed.

I love Debian stable for this. And then we get MX, Deepin, Ubuntu and Mint..

I prefer the quality control that something like Debian stable provides, developers aren't always interested in packaging their application the right way or are just ignorant of how to package their application for one of many distros all with their own package format and tools.

The brave new OSTree/Flatpak world needs build systems that know how to do security updates. There's a lot of work in this area in the Dockerverse; maybe it will cross over.

What happens is that half of your security updates never happen because it depends on individual app providers who have no skin in the game to do so this is unfixable unless apps that are insecure aren't installable.

Before Silverblue, Red Hat and Fedora maintain a list of custom build scripts for all packages that apply patches and security updates.

After Silverblue, when they run in Flatpaks, they can still maintain build scripts that achieve the same thing.

The distribution itself can even maintain a common base image for all flatpaks in the official repos, retaining all of the code sharing of existing systems, but with the benefit of a more robust and modular solution when they need to make exceptions. End users will also be able to more reliably use applications that are not supported by the distribution proper.

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.

Sounds a bit inconvenient if something low level gets changed, no? If libc changes you’re in for a day of builds…

Who says you need to compile anything? Nix allows you to download the binaries from their "build cache" if you so choose to, the same is true for guix.

But then, you’re downloading GB of stuff, just like windows update.

FreeBSD’s pkg does that, but they’re recompiled in the package server and you just download the updated binaries built against those releases. It is very fast.

While I can appreciate the security advantages of snap packages, I can't help but resent the fact that the output of the mount command is now polluted with dozens of lines unrelated to mounted disks.

Agreed on that front. That's really my biggest issue with snaps.

Thank you, it's nice to know that I'm not the only one who thinks this. You could use an alias to hide this:

alias df='df -x squashfs'

Given that squashfs is a read-only filesystem, I don't know why this isn't done by default. No one needs to worry about how much free space is left on an ro volume.

I also go a few steps further and disable udev (-x devtmpfs) and tmpfs (-x tmpfs) as well.

Try findmnt(8) like:

    findmnt --df --types

Reply on news.ycombinator.com