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

My only complaint about arch/i3 so far is that updating Firefox forces a restart of Firefox, and I've got FF windows scattered over a few workspaces so I need to sift them back to their places.

Come to think of it I can probably prune one of the windows...

I'm almost sure this is an excerpt straight from https://youtu.be/7Nj9ZjwOdFQ

I'm flattered you think I achieve perfect window placement.

Would it be possible to create a script to save the desktop and screen position for each firefox window on close and restore them to the recorded desktops and positions on open? I haven't used i3 much (or arch at all), but I'm fairly certain I did something similar using Xubuntu some years back.

I did that on xubuntu too. Used xdotool, wmctrl and something else I can't recall.

I'm vaguely aware of tools that'll do it for i3 but thus far I've just avoided restarting as much as I can. The call-out to James Mickens is not altogether inaccurate (:

Keep in mind that you can downgrade firefox back after the update with pacman -U /var/lib/something, then just refresh/keep using the open windows with no issue.

Aren't downgrades heavily discouraged in Arch?

Been running this same setup for eight or nine years now, extremely pleased with it

My impression is that Arch is not technically unusual among distributions, but is simply well-polished, documented, and very active (and has an easy way to install unvetted community packages). If this impression is correct, you still run the risk of unnoticed outdated software if the amount of volunteers drop, or a particularly critical one no longer has the time.

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?

>Which part of Arch's design prevents the issue described in the grandparent post?

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.

The impact of having frictionless package building cannot be understated. I'm publishing Arch Linux packages for all my applications because it takes just a few minutes to write up a PKGBUILD. Then one time, I tried providing a Debian package as well, but I gave up after several hours of trying to get through all the bureaucracy of the tooling.

The difference is that arch doesn't have downstream forks of repositories. They just package the upstream versions which means the dev cycle is much tighter which in turn means they can update more frequently which means they just switch to the next major version and don't worry about breaking their special sauce forks. The downside is that there are people using old distros and stuck with old major versions who use eg. Python 2 by default.

Regardless of the explanations, as an Arch user, I think you have to at least acknowledge that Arch does not have this problem in practice. I am sure there are counter-examples but in almost all cases Arch packages are extremely up to date. If they are not, it is probably a package you are not even going to find on another distro.

Lagging isn't always a bad thing. Users of Debian Stable missed Heartbleed entirely.

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.

While I generally agree with you with respect to the mindset, it is actually possible to downgrade a flatpak [1]. It is rather involved, but possible. I have done it to downgrade cheese (the webcam app) since newer versions don't have the filters that older ones did, at least not for me.

[1]: https://itsfoss.com/downgrade-flatpak-packages/

> it is actually possible to downgrade a flatpak

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

It is! I have to do it with Mixxx because of some weird GL bugs they're having in 2.3.3. But it's a privileged operation compared to upgrading, which is crazy.

> But flatpak has it sandboxed so the worst you could do is maybe steal my Spotify session token.

It has access to X11 <https://github.com/flathub/com.spotify.Client/blob/0856c7641...>, so it could also be running a keylogger.

Which is an issue of the X architecture less of flatpack. Wayland is there for a reason

> But flatpak has it sandboxed so

Sandboxing should be a separate tool independent of packaging systems and anything else .

> But flatpak has it sandboxed

With an open sandbox by default for many apps…

You are thinking of Snap probably. Some flatpaks have $HOME wide-open, but Flatpak itself has no mechanism to completely bypass the sandboxing, as evidenced by things like Wireshark being unable to actually capture packets and many IDEs being unable to actually call build tools.

> Some flatpaks have $HOME wide-open, but Flatpak itself has no mechanism to completely bypass the sandboxing

The first one is the second one.

We're obviously using extremely different definitions of the word "completely". Flatpak sandboxes more than just file system access.

And write access to $HOME lets a process climb out of the sandbox.

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.

I totally agree about letting applications determine their own defaults being a bad idea.

We are in a transition period. Starting with getting apps packaged in flatpak even if it doesn’t improve security, and then once that’s all done we can start tightening the restrictions.

We shall see. "And then, we add security" has so far never won.

In that case can you please at least stop advertising flatpak for its security until it happen to be secure eventually…

If every application is properly sandboxed, and the sandbox has zero holes, then it's fine. I don't believe either.

> But flatpak has it sandboxed so the worst you could do is maybe steal my Spotify session token

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.