> Containers are not security isolation, I'm not sure why this has to be repeated so often because it's very obviously not the problem containers try to solve.

> Containers are not security isolation, I'm not sure why this has to be repeated so often because it's very obviously not the problem containers try to solve. They aren't a perfect security solution, that doesn't mean they are useless for it. If I were really worried about an application being nefarious I either wouldn't run it or I'd run it in a VM on a dedicated device or something. You have to trust someone, and I choose to trust fewer people (the developer) rather than more (developer plus packagers). > I can very much think of ways they can still conflict; one would be port bindings for example. But I agree with the sentiment, you're basically arguing in favour of static binaries being shipped... except instead of static binaries it's... a tarball you run in a chroot... which has some kind of value I suppose. There are good reasons very few piece of software, let alone desktop software, are distributed as static binaries. And no, it isn't because of dependency size. There are things you just can't do without dynamic linking in Linux, and glibc is especially tricky to deal with as I understand it. > My major point is: centralising trust to a few maintainers who you can hold accountable for your entire OS experience has value, and you can still opt out. But making flatpaks mandatory decentralises that trust back to application developers, who might not be trustable. FlatPak still allows you to have your own repo run by the distro. In fact, Silverblue only pre-installs Fedora's own FlatPak repo, not Flathub. But regardless, I do not see a reason that FlatPaks need be mandatory, any FOSS software can just be packaged up by a distro without FlatPak. And if it isn't FOSS software than none of the advantages you speak of apply anyway. FlatPak just makes my, and a lot of other people's, lives a lot easier and fits how we use a computer better than the traditional package manager/repo model, so we'd appreciate if people would try to understand why. > and for an apt repository it would be much less dangerous (and very noticable) Would it? Heartbleed went unnoticed for years. The debian random number bug went unnoticed for years. An actor could slip in such a bug intentionally at any time and it would likely be not only overlooked, but simply considered a mistake rather than malicious when caught. I'm not convinced of the supposed security benefits of package maintainers.