Meanwhile we have distros lagging behind for years to provide a new package because they can't break all the things depending on the old version.
I'm glad I left this category of problems behind me 5 years ago when I switched both, my personal and my work laptop to arch-linux/i3wm. These two machines have been running for 5 years, almost daily, with almost no issues, with the latest software packages. If the hardware lasts, I will go on like this for another 3 to 5 years and then upgrade hardware and (maybe) switch to wayland. I don't see anything on the horizon which would make me switch away from this setup.
Which part of Arch's design prevents the issue described in the grandparent post? The issue is "distros lagging behind for years to provide a new package because they can't break all the things depending on the old version", which is solvable either with enough manpower or by sandboxing a la NixOS, where you can keep old versions around indefinitely for the things that need them. Does Arch use such sandboxing now?
As a former long-time Arch user, you're correct. It's "just" a distro not unlike the biggest one. The reason Arch repos are fairly well updated and big is the relatively easy to understand PKGBUILD format and the tooling around it, which lessens friction on package management.
Come to think of it I can probably prune one of the windows...
ETA: and maybe one of the workspaces...
It has access to X11 <https://github.com/flathub/com.spotify.Client/blob/0856c7641...>, so it could also be running a keylogger.
But this gets to the mindset that bugs me about Flatpak, the magical thinking that regressions don't happen. It's why Alice can't downgrade a system flatpak because it might introduce a vulnerability she uses to attack Bob, but it's absolutely fine if she upgrades to introduce that vulnerability.
Only when the version you want to downgrade to happens to be within the last 10 versions! Why 10? Beats me!
Case in point: the flatpak package for the Element messaging client seems to be the preferred installation method for non-debian distros. But for many users, encrypted message search is broken! [1] [2] Some users claim that downgrading can fix the issue, but the flatpak has been updated too many times now for any user to downgrade to an old enough version - tough luck!
[1] https://github.com/vector-im/element-web/issues?q=is%3Aissue... [2] https://github.com/flathub/im.riot.Riot/issues?q=is%3Aissue+...
You are cherry-picking the spotify session token while many other applications have valuable personal data.
Also sandboxing is also implemented by the OS. It is not an advantage of flatpak.
With an open sandbox by default for many apps…
The first one is the second one.
Trying to make sense of Flatpak's threat model is just near-impossible. It might protect you from something, if the specific app's configuration told it to do so. Starting a random Flatpak app, you have no guarantees, and the UX doesn't communicate anything about this.
Sandboxing should be a separate tool independent of packaging systems and anything else .
Besides, sufficiently quality minded projects always wind up vendoring all of their dependencies anyway. There's a reason Chrome has their own fork of everything down to the compiler.
It's not about quality. It's about reproducibility of the exact versions of all dependencies. It's about communications with repos not being subverted to load malicious packages. It's build security not app quality, though app quality is a part.
Plenty to criticise about it from a product perspective but from an engineering one it is kind of a marvel.
On my GFs computer Chrome starts in about 7 minutes after fresh boot, no other programs running, yet. From a fricking Samsung SSD, 8GiB RAM. All it has to do is show some fake tabs and render a single page content.
Tell about its quality to my GF. She's used to it, but some of these days, I'll check the DNS logs, to see if it's really loading all the 1000 tabs (she keeps open at once), for 0 reason whatsoever, or if it's just that slow to start one page.
There is something wrong with your GF’s computer. I have no idea what but a seven minute start time is absolutely atypical.
I actually know of quite a few people who use browsers this way, so it may not be a terrible idea to have something like this.
Also the same chrome profile starts very fast when she uses the "private browsing mode" which doesn't restore any tabs. So it really just seems like chrome having perf issues with tab restore with many tabs.
But anyway the point still stands: an outlier user with 1000 tabs open had a slow startup time doesn’t mean Chrome is horribly engineered. If it isn’t an extensions issue then it’s a minor bug.
but that's a problem, too.
i'd rather all things on a system be bottleneck-forced into using the latest version of security libraries that my system is actively updating; yes, this causes issues, but not issues like "There was a huge vulnerability found in X version Y, does it affect me?".
in other words, i'd rather have system breakage than insecurity. That's a personal taste, I admit.
that said, the sandboxing aspect behind 'the new ways' is fantastic.
Which is to say most people use a computer to run software, so if the software doesn't run the security is pointless anyway.
Sure, if only some software breaks and you can wait for fixes that's a tradeoff, but given that in package maintainer land those fixes could be months or years away...
Multiple versions of openssl is a security problem that merely updating cannot solve.
And how many of them are critically out of date because the software maintainer didn't update? Who can say? That's the beauty of flatpack (not).
With flatpack you have all the downside of static linking with none of its advantages, how exciting. (and there's nothing as cool as having 7 full linux distros installed on your computer at once, just because software can't agree on which base image to use)
...until attackers find a vulnerability in some library, then you are really in trouble.
Just like docker, the bundling of tons of software into opaque blobs is terrible for security.
Now, maybe the Linux approach is so good and useful in other ways that it's worth putting up with that, but it is a big problem and people are going to solve it, one way or another. If the model can't be changed, then the only solutions available may be bad, but they'll be used, and widely.
No, it is not. If you want security you need dependency management and software lifecycle management on all OSes and platforms.