Flatpak has a concept of shared base layers, so if you update frequently you might notice 'org.gnome.Sdk' or whatever getting updated. This is a way to handle lots of the most popular shared dependencies.

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.

i gotta say, if chrome stands out to you as a shining beacon of quality, i'd hate to hear about what software you consider bad

I know “Chrome bad” is a meme-level comment at this point but it’s a hugely impressive piece of software, basically an operating system unto itself at this point. Not to mention the V8 engine etc.

Plenty to criticise about it from a product perspective but from an engineering one it is kind of a marvel.

I think there's a strong argument to be made that modern web browsers are a good deal more complex than operating systems -- or at least most kernels.

It all depends on how you draw your Venn diagrams, I suppose. Is Chrome a massively complex browser, or is it some window dressing and bookmark syncing sitting on top of Chromium, that itself is really just a simple UI around the Blink rendering engine. GNU/Chrome, anybody?

Tbh I kind of see the whole chrome/chromium/blink stack as a single team at Google.

ChromeOS makes those delineations pretty clear.

Maybe engineers might be enamoured by it. Whatever.

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.

> On my GFs computer Chrome starts in about 7 minutes after fresh boot, no other programs running, yet.

There is something wrong with your GF’s computer. I have no idea what but a seven minute start time is absolutely atypical.

They mentioned 1000 tabs which may go some way towards explaining it. If that's not how you're supposed to use Chrome (I'd understand if it wasn't) then I'd imagine some kind of notification to the user would be helpful. Something like: "Chrome may be a little slow, you have 1000 tabs open" including perhaps a table suggesting tabs that could be closed (i.e. if she's opened https://bbc.co.uk/news in 20 different tabs that were last accessed a month ago) and an easy mechanism to quickly do so.

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.

The computer is fine, judging by Firefox starting resonably fast with very many tabs to restore for her on that computer.

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.

Maybe it’s extensions.

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.

Chrome wasn't built for 1000 tabs. You need firefox for that.

Chrome doesn’t have to be a beacon of quality for Firefox to look bad in comparison.

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

The SDK is different from the platform itself, but more or less. So I have three versions of Gnome, two of KDE, and three of Freedesktop.org, just based on the apps I run on Silverblue and what version they're at in Flathub. Since I asked specifically about SSL, that's shipped with FDO, meaning I potentially have three versions running right now. Also I have this annoying situation where an app a client uses is using a deprecated FDo runtime and nobody wants to pay to rebuild it.

Why would I care? Ok Spotify has an old package with some vulnerabilities in it. But flatpak has it sandboxed so the worst you could do is maybe steal my Spotify session token. That's more a problem for Spotify than it is for me. They will go and fix their package and I will reset my sessions.

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.

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

Multiple copies of openssl is an problem that updates will hopefully solve.

Multiple versions of openssl is a security problem that merely updating cannot solve.

Until openssl has another vulnerability.

It's a problem of the many-distros model for Linux—or, if you prefer, it's a problem of Linux just being a kernel. You can't just target "Desktop Linux 15" and expect to have all the stuff that Desktop Linux 15 has, including a robust set of basic libraries and a unified GUI stack and standard same-on-every-copy-of-Linux-15 multimedia libraries and services and all that good stuff, and let the OS worry about keeping that secure without breaking your program. Programs end up having to be a lot more fiddly about their dependencies, and it causes problems.

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.

Freedom bad.

> It's a problem of the many-distros model for Linux

No, it is not. If you want security you need dependency management and software lifecycle management on all OSes and platforms.

>How many different versions of OpenSSL are running on my laptop right now? Who can say?

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.

Why don't you just turny our computer off then? It can't be exploited if it isn't actually running.

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

I do love the sandboxing, granted. But "let's just hope the app maintainers keep up with our rolling platform deprecations" is a horrible idea.

That’s what the whole container revolution was about: “fuck it, we’ll just tar up entire Linux file system images to distribute stuff.”

> How many different versions of OpenSSL are running on my laptop right now? Who can say? That's the beauty of flatpak

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)

I suppose it shouldn't surprise me that the sarcasm of my comment wasn't apparent to everyone.

Poe's law strikes again.

> if you sweep the problems of software management under a big enough rug, they go away and never bother you again.

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

Yeah I didn't realize people would take the joke there seriously. It's basically looking at package management and saying "this is hard so we won't try".

FWIW personally I detected your sarcasm but I replied knowing that the security risk would fly over people's heads here.