It will depend how an app has been packaged, but when well done the sandboxing is invisible.
I think the only issue I ever had with them was the inability to inject files inside. Do you know if that's possible?
I was trying to use a browser, I think Vivaldi, that had instructions for enabling widevine by copying a file to a certain directory, but I couldn't find a clean way to do so.
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.
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.
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.
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.
Come to think of it I can probably prune one of the windows...
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.
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+...
It has access to X11 <https://github.com/flathub/com.spotify.Client/blob/0856c7641...>, so it could also be running a keylogger.
Sandboxing should be a separate tool independent of packaging systems and anything else .
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.
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 versions of openssl is a security problem that merely updating cannot solve.
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.
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...
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.
- Installation (no manually moving files from ~/Downloads)
- Launcher integration (no writing .desktop files by hand)
- Auto updating
As far as I saw, AppImage didn't have any of that. Though it was a while ago (and maybe some of this was my distro's fault). Has any of this improved lately?
How are people keeping their AppImages updated?
But Linux Desktop has a nasty habit of adopting over engineered solutions instead of simple ones, especially if any other desktop OS is doing it that way.
The only software I run as an AppImage is BitWarden (from the official GitHub repo[1]. It prompts to update itself when there's a new version which works very well.
ive been using flatpak more myself these days but i hope the appimage format sticks around because its handy being able to quickly try out some software and then delete it when you are done, or to try out a new version of something and have both running at the same time
Installation, launcher integration:
https://docs.appimage.org/user-guide/run-appimages.html#inte... https://docs.appimage.org/reference/desktop-integration.html
https://docs.appimage.org/user-guide/faq.html#question-how-c...
Updates:
https://docs.appimage.org/packaging-guide/optional/updates.h...
What was missing was convenient sandboxing. Firejail was recommended but with the responsibility entirely on the user to install and use it.
Flatpak doesn't limit access by default (or rather it does but apps can just ask more permissions at build time and it's not prevented by default IIRC) but offers the user some options for being more strict without needing extra tools.
Nor is their FAQ describing their sandboxing as a security feature, more like (limited) isolation technique.
But this isn't stopping flatpak zealots who just won't shut up about the "sandbox == secure" falsehood.
I don't know, I'd rather prefer a technology which is upfront about its lack of security than one which has glaring hole in what they call (a false sense of) "security". I treat flatpaks and appimages as mostly equal things and use them to keep and run proprietary stuff so that I know it won't be shitting its guts all over the host system.
In fact...I think I have all the software packages you have, except Obsidian, but also, Signal, Anki, and Element.
I did consider using it to deploy and update a CLI on (multiple) Linux(es), but found that the design of common shells make that kind of thing uncomfortable, as you need to teach them about autocompletion and the user also has to muck with getting the utility into $PATH. Normal-style packages simply have the privileges to muck with /etc and /usr/bin and that's the end of that, but it is somewhat unsatisfying that this is almost necessarily the case.
Commercial software would like a comprehensive and relatively stable API like what Windows famously provides. Flatpak's analog of the Windows API is the runtime. What level and duration of maintenance do Flatpak runtimes typically receive?
https://developers.redhat.com/blog/2020/08/12/introducing-th...
Well yes, these are all closed source binaries. In terms of usage it's not all that different to running them in a VM. In the bad old days we just did it in an XP windows VM instead.
They make so much sense and work so well. I feel like the people who dislike them either never actually used them, or they’re just the type of person who hates change and will never be happy with new things.
Last I checked Flathub shipped with VSCode and IntelliJ, despite both having major broken parts. The VSCode workaround back when I tried Silverblue was to run sshd inside toolbox and remote Flatpak VSCode into it. It was definitely not a frictionless experience. And IntelliJ having the terminal and debugging broken removes most of the useful parts of the IDE for me.
It is really strange that both this and "it's totally ok for packages to set their own security defaults" are true in Flatpak land.
Wireshark is a tool more in the realm of development/sysadminry, whereas flatpaks are designed for more traditional apps, like Discord or Firefox.
I wouldn't want my development tools to come from flatpaks even if they had full access to the system, because I wouldn't have control over dependencies. Traditional system package managers are a better fit for that, and on Silverblue you have Toolbox for that.
See, here's the problem with letting packages determine their own defaults. I want the ability to give a Flatpak those permissions, not that they be able to give them to themselves. As it is, Flatpaks can give themselves permission to $HOME without ever notifying me, which I think is just as silly.
In my opinion, Flatpak should support a user-definable default permissions template that says "always permit", "always deny", and "don't care" for any given permission.
> you have Toolbox for that
Actually I agree that when it comes to these collections of software to build an "environment" something like toolbox/distrobox is a better fit. I have my issues with both[0], but the base concept is sound.
[0] For instance: why is podman required? The container functionality required is built into the kernel and podman has a lot of features that are entirely unused. Even bubblewrap has all that's needed and it is included anyway because of Flatpak. I will probably end up writing my own replacement for these tools.
Using development tools as a flatpak is usually not a good idea for many reasons. That’s why Silverblue ships with Toolbox (https://docs.fedoraproject.org/en-US/fedora-silverblue/toolb...).
Flatpaks are kind of like Android APKs, except unlike Android, there’s actually an operating system worth interacting with. An IDE on Android usually needs to include all of the tools it needs. A flatpak is the same, except that’s hard to get right for every development setup, so a toolbox just lets you do whatever you want with it. They’re podman containers with extra features to integrate with the host.
I have all of my development tools installed in a single toolbox, and have .desktop files for the GUI ones so that I can launch them from the KDE app menu as if they were regular apps. With this setup I can use e.g. clangd with the LSP plugin in Sublime Text, execute CMake, use the embedded terminal (Terminus), or the debugger plugin with lldb.
Most of these are proprietary. I view these third-party stores mostly as a way to ship proprietary software. Not sure what else they add, and the downsides of having yet another package manager on top of your system's are obvious. I'm surprised KDE is behind this.
Some sort of packaging standard that works across distributions would be beneficial, but it'd have to be integrated with the system's package manager, not tacked on.
I am a Nix person who has been a bit obsessed with package management for a long time, and it's probably fair to call me a bit of a 'container skeptic'. I know many good reasons to prefer other means of installing packages, and I agree with most of them. I care about things like the extra storage overhead, the increased app startup time, the additional complexity associated with portals and sandboxing, the extent to which Flatpak applications do or don't support the available sandboxing features, and the orientation of Flatpak towards enabling a larger proprietary software ecosystem I'm not very interested in.
But despite all of that, and despite my interest in— and to some extent, commitment to— competing paradigms... I think Flatpak does what it tries to do pretty well. It seems to me that the engineers working on it have done a pretty good job of mitigating the downsides and risks, like library duplication and difficulty of shared updates, disk usage, etc. Considering what it aims to do, it feels pretty fast, reliable, and neat. And I trust it way more than an apt or dnf or pacman repo hosted by the likes of Zoom, Google, Discord, etc. It's a much better way to manage third-party software than anything else we've got.
I think it's clearly a good thing that the biggest and most popular desktop environments are coalescing around it. This is good news for desktop Linux users in general, and especially good news for those of us who don't run Ubuntu or derivatives. The more things are packaged for Flatpak, the lower the burden for practical usage of distros maintained by small or new communities.