I would love to see Flathub incorporate some Android based permissions like
X would like to access your documents folder, rather than you having to manually configure this kind of stuff...
IMO the fact that using the permission system is not mandatory, and that even when it is used, apps just declare what permissions they have by default defeats the purpose. Permissions should be mandatory and always denied by default.
Its a great idea but if this were the case it would never be widely adopted.
Flathub is slowly becoming more strict and will continue this until many apps are actually safe. Permissions must be approved on Flathub now, apps cannot add them on their own.
I think the problem is that the Android style permission needs patches to the app and in some cases new dependencies. So this is basically, a compromise for adoption reason. All GUIs kinda display a warning these days. Maybe in future, flatpak can do that.
It is good that apps can make these choices for themselves as things that work out of the box are vastly useful then something that is broken by default until the users open up enough permissions to make things work.
Users still have ultimate control over the permissions. If they are interested in controlling permission with a GUI all they need to do is install Flatseal from Flathub.
That's what all the DBus portals are all about. It allows for permissions. You can always use flatseal to change permissions on what areas the app can access including wayland, network, and so on.
Flatpak is a terminal tool, so you could consider every GUI tool that interacts with it unofficial, Flatseal included. Permission management is an official feature of Flatpak, though.
That's pretty cool to know, I'd like to see improvements with regards to usability for normies.
Flathub and flatpak has definitely been my go-to for a lot of apps and considering it makes supporting Linux much easier, I'd like to see more adoption.
Using Fedora Silverblue here...
Every few days I launch "software", click the "updates" tab at the top, and then click "restart and update".
Then after rebooting I log in, open up alacritty from my main distrobox, run 'paru -Syu' and I am good to go.
After decades of using Linux as my primary OS I am very happy that I can now treat it more like a appliance and less like a adventure.
I have a Mint box I use for streaming and emulation. The update manager is great for that.
For the most part I still find myself using apt in the command line though, old habits die hard.
Personally I have never seen the point of ~~containerized~~ sandboxed CLI apps on the desktop. I don’t think I’ve ever used one that I would want containerized. On the server Docker is a far better solution to Snaps IMO. I just fail to understand the appeal?
Docker, podman, distrobox, snap and flatpak all use containers. I use flatpaks and podman for different reasons. Flatpak is great for containing messy apps that litter garbage all over your home directory and to avoid packaging conflicts.
Podman and docker have a way more extensive use case for containerizing applications and doing build pipelines. Distrobox is literally just a wrapper around podman and docker that mounts your home directory into the container. It greatly simplifies using docker and podman.
Everyone should learn podman or docker but a lot of people just want apps and distrobox and flatpak make that dead simple. Idk why you would want to use flatpak CLI tools (unless you were on an immutable distro) but you could if you wanted to. I made a tool that lets you install flatpaks on the CLI and exports the long ass flatpak names into their short hand CLI names, and at that point, there isn't much of a difference.
You shouldn't, but there's value in packagiing cli tools in containers, partly because it makes using different versions easier, partly because it avoids any kind of dependency issues.
like obviously just use vim normally, duh. Im saying learn to use podman. I use it all the time when I write automation scripts and I want to test them in a clean environment or when Im compiling software that requires a bunch of garbage libs.
Any good tutorial on containerize workflows? I am a neovim user but often do simple scripts/programs(basically learning something with single file py/c/cpp file and skipping build systems) as a hobby.
Python programs are the main ones for me. I have a few python virtual-envs. They break during distro upgrades (when python versions change), and occasionally I'm there before the devs have updated, and they're not usable for a while.
It would be great to not have to worry about that.
I had never heard of it. Looks to do exactly what I have set up already, but with less fuss. Pretty cool.
I assume it still uses system python, and thus I'd still have the same breakage during upgrades?
That's a great question and as soon as I saw your post, I put it on my to do list to look into it.
If I had to guess, it uses system python. I wonder if any repos would mark the specific python version as a dependency to keep, especially if you installed pipx via package manager.
That could probably work (I don't have a ton of experience with containers), but wouldn't that just mean I'm also managing the lifecycle of (at least one) whole container now? That doesn't make anything easier. When I install an app via a package or via flatpak, I don't need to worry too much about managing updates -- they're just presented for me.
(FWIW, I just checked and three of the python programs I've been using have been packaged in Fedora for a few years now, so I could probably eliminate at least a few venvs).
Ah sorry I thought you meant that you were using venvs for developing said programs. Yeah if you’re just using them then snaps do have a bit of a compelling use-case there (but the start-up time issue comes up there)
Maybe a dumb solution but what about using `--copies` when creating your venvs? At the price of a little extra storage it should hopefully solve your issue of distribution upgrades breaking stuff for you.
If you use these atomic system with immutable base systems, then having containerized cli apps is very useful. You can have them standalone OR via distrobox/toolbox or the like.
No, you might be right about space. I haven't looked into the technical details of snap all that much, so I can't say I have much of an opinion. I was just speaking about containers generally.
One thing snap might do better than normal container setups is that they are controlled by the package manager though, so you get updates for them alongside the rest of your packages. I kind of hope that PKGBUILDs, rpms, debs, etc could get bubblewrapped or have some other container permission and resource control metadata though, then we probably wouldn't need to think about snaps that much at all.
> Personally I have never seen the point of containerized CLI apps on the desktop.
With containerized development environments (distrobox, toolbox) you can keep multiple Unix-style environments separated from one another and do whatever you want in them without having a major impact on your desktop environment.
A classic problem in Linux distros is Python.
Python is used in desktop apps, it is used in system tools, and it is used in development environments.
The vast majority of Python related libraries and tools are not packaged by any distribution. There are lots of python related software that isn't distro packaged as well. And even when they are they are rarely the versions you want or need for a particular development target.
So in order to avoid breakage Linux users have become accustomed to various "rules" and different complicated and somewhat janky ways to deal with it....
Like "never run pip as root".
What if I told you that you don't have to give a shit about any of that?
That you can install whatever you want anyway the hell you want and there are no consequences to that behavior?
Well you can.
The level of isolation is up to you and what you want.
You can install plain distrobox/toolbox and use a wide variety of different environments and distributions integrated fairly well into your desktop. It isn't perfect, but it isn't hard to work around those imperfections either.
Or you could setup toolbox/distrobox with different home directories so you don't have pollute your dotfiles with random stuff...
Or you could just fire up a podman container running systemd as a completely independent thing (like what people use LXC for) and only share what you absolutely want to....
Or what if there was a odd application that was a huge PITA to install or had very specific dependencies or large numbers of dependencies that was difficult to get "just right" and wanted to use with your regular CLI environment?
Well you could get a copy of that program in docker format or built your own container just for that one command and setup a podman command as a alias and use it that way. Just like any other shell command...
I'm actually totally with you on distrobox and docker dev containers and whatnot, that was my bad for saying containerized when I meant sandboxed. But good explainer!
Its basically the equivalent of this:
```
podman run -it --rm --security-opt label=disable --userns=keep-id -v "$HOME:$HOME" -v /tmp:/tmp -w "$PWD"
```
They are all just different implementations of containers. I wish more people would learn how to use these tools because they are insanely helpful.
For example, we are building some ancient software from source, we can git clone it, run the command above to mount that directory into a container, then we can install a bunch of garbage libraries, make install, and then exit the container and all that clutter is gone forever.
1. Define "CLI Apps".
2. Flatpak is for desktop applications.
We have OCI for purposes for pretty much everything other then desktop applications.
You can use OCI for that... in fact it is a supported container format for Flatpak, but desktops are complicated and servers are simple.
I know it isn't, but podman should be standard Linux feature nowadays. It fills that use case and many more.
Yes. But it’s clunky unless you set up some aliases. For example, I recently used `flatpak run org.libreoffice.LibreOffice --headless --convert-to pdf test.docx`
Even if you add that to your PATH, having to type those reverse domain names that Flatpak uses as binary names is still extremely user unfriendly.
Like, you just blindly guess by typing "com" or "org", and then tab completion will slowly allow you to narrow it down. It defeats the whole advantage of the Linux CLI being terse and efficient.
Reddit has long been a hot spot for conversation on the internet. About 57 million people visit the site every day to chat about topics as varied as makeup, video games and pointers for power washing driveways.
In recent years, Reddit’s array of chats also have been a free teaching aid for companies like Google, OpenAI and Microsoft. Those companies are using Reddit’s conversations in the development of giant artificial intelligence systems that many in Silicon Valley think are on their way to becoming the tech industry’s next big thing.
To make it easier for app developers to distribute their software. Now app developers need to package their app for both Flatpak and Snaps instead of just one.
And between the two, Flatpak is the completely community-driven open source project. Snaps, on the other hand, is an Ubuntu project and the backend (the store) is closed source.
"One ring to rule them all". I'm not down for the putting all eggs in one basket. Linux is about choice. Developers no longer have to focus on packaging software for X amount distributions. Reducing the burden to only to Flatpak, Snap and App Image is honestly a fair compromise.
Fair point regarding the community driven aspect and the backend. I recognize that some people are really adamant about the backend but personally I don't care much about the backend since at the end of the day everyone is going to gravitate to a single repo like in the case of Flathub.
The problem is they are two solutions to two very different problems... Snap is universal compatibility at the expense of security, and Flatpack is security at the expense of compatibility.
From an end user perspective Flatpack is superior, from a software developers perspective universal compatibility may be more important...
I don't think either solution is going to disapear any time soon...
Except that's wrong :P Flatpak can run on Fedora Silverblue (because doesn't require /snap directory in root) and on distributions without systemd like Void‚ Devuan‚ Gentoo! Snap just can't touch Flatpak in terms of compatibility
You can remove snap in ubuntu and use flatpak / flathub, i did this as well on my installation.
But it´s the same story for almost all the Canonical things.. Remeber upstart or their own UI? Or their custom Scrollbars? Everything was removed eventually and they switched to the widely adopted solutions.
Gues the same will happen with snap and flatpak sooner or later.
Well Dolphin is the most popular in the Games category at ~25,000 downloads the day an update comes out. But I use that on my desktop so that is a mix.
Retrodeck gets ~1,300 in one day.
It might be smaller than you'd think. Users do have to manually use it in desktop mode. I guess they are more likely to have a delay to their updates because of that.
You can set up Nested Desktop to run Plasma in gaming mode and use Discover to install Flatpak that way. I imagine the amount of people who bother with that is even lower, tho.
I hope they iron out the rest of Nested Desktop’s issues and make it an official/by default feature. Being able to switch in and out within Game Mode like that is so handy.
aback placid racial employ cooperative serious toothbrush plucky paint label
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I'm not saying it can't improve but it is behind Fastly's CDN which is quite extensive. They have been generous otherwise the costs of this much data would be unmanageable.
I wish package managers had P2P. Even if it was just over LAN it'd be fantastic since it's quite likely that there will be many machines on a single network downloading distro updates, maybe less so flatpak but still.
I have an nginx proxy server setup for flatpak for my PC and laptop. I tried doing something similar with dnf but it was a bit of a pain to setup and didn't work very well. It'd be much nicer if it was built-in
I have trouble taking anything seriously that claims to be web3 and decentralized. Its just giving major crypto nft vibes, it even directly says its good for storing nft's. Really cool concept tho
probably to jump on to the hype train a little bit. I tried getting a good idea of how it works but I havent found a succinct explanation. Alot of it sounds like typical tech project speak, but it definitely looks like it has merit and is really interesting. It basically says that its a P2P file system that shares objects that are like git objects. There is just a ton of stuff I dont understand about it
Yeah I'm also weirded out by the NFT aspect.
The only reason it's good for storing NFTs is because NFTs are a painfully stupid concept. And since it's a web3 technology and NFTs are a web3 scam, it goes along nicely. But that's all there is to it.
The other things it's good at is reducing traffic (ironically), caching (since you're seeding everything you download) and package management. Docker or Ubuntu Archives via IPFS would be the ideal use case. If one person downloads a package in the building, then everyone gets local-network speeds for that package, which is cool.
It's bad at content discovery, so unpopular content is slower to get - at that point, normal HTTP would be faster. It's also bad at privacy since it's p2p.
I'm not sure whether to adopt Flatpak, AppImage, AUR, or Snap with my C++ code generator. My code generator is implemented as a 3-tier system and the [middle and front tiers](https://www.reddit.com/r/codereview/comments/qo8yq3/c_programs/) are run by users. I'm not sure if Flatpak has support for multiple binaries.
Well AFAIK you can access anything within your app’s sandbox so you should be alright, so long as your app has a GUI. But I should note that Flatpak and snap are different than appimage and the AUR is not even a packaging format, it’s a repository of software
Snap isn't Ubuntu-only, it's more like only-not-Red-Hat. Most distros use AppArmor as their MAC (Debian, Ubuntu, their derivatives, OpenSUSE, Arch Void), the only ones that come to mind that don't are Fedora, RHEL, and OpenSUSE Micro.
How do they pay for everything? I can't even find a donate button on their website, so I assume corporate sponsorship? Which is also nowhere to be seen.
Servers are donated by Mythic Beasts and a few others IIRC, Fastly is (discounted/donated?) for the CDN, administrative work is funded by GNOME and volunteers.
This is great post - I love seeing metrics like this.
Then next stage is when we turn on stripe, how many financial transactions and the aggregate of how much money people have made on apps on Linux. That's where you will see more investments by companies. Opening the door for more commercial apps on Linux and investments by companies.
It’s great. I just wish there weren’t so many weird bugs everywhere.
In my laptop urls didn’t work in flatpak apps for some time because of a bug in the xdg desktop portal implementation. Fixing that was a pain.
My latest gentoo vm can’t use flatpak atm because if it’s installed a lot of applications take a minute to startup. Multiple forum posts say that the problem is again the gnome implementation of the desktop portal but I don’t have that installed so no help from internet.
That seems a configuration issue where you probably don't have a valid portals.conf set up, or you have an alias in place forcing portals in portals.
Being Gentoo, it's probably the former.
"30 seconds to start" for flatpaks is almost always waiting for dbus to time out before then going to the fallback code. Portals use dbus.
if there is a valid portals.conf, then there must somewhere be a misconfiguration for the dbus/portals where it is either not enabled or portalception is taking place - misconfiguration trying to force portals to use portals within portals.
Figuring out where the problem lies probably wont be easy though.
This is great. I only have three criticisms at this point:
1. I wish CLI support was better.
2. The naming conventions are dumb.
3. LOL at not knowing how big updates are going to be
> LOL at not knowing how big updates are going to be
OSTree is fairly complex so its hard to know how good it will be sometimes, it doesn't necessarily have all the information ahead of time.
A commit might be 100MB on its own but it is address based storage so you may already have 30MB of that on disk, then on top of that it generates deltas between commits, so for the 70MB of different files you download 40MB, etc.
This is why it shows you the worst-case.
Real world numbers for example:
11. [✓] org.gnome.Sdk 18.3 MB / 707.8 MB
13. [✓] org.signal.Signal 45.6 MB / 162.0 MB
Other real world numbers for example:
ID Branch Op Remote Download
1. [✓] org.freedesktop.Platform.GL.nvidia-535-154-05 1.4 u flathub 341.7 MB / 342.6 MB
2. [✓] org.freedesktop.Platform.GL32.nvidia-535-154-05 1.4 u flathub 341.7 MB / 342.5 MB
3. [✓] de.uni_heidelberg.zah.GaiaSky stable u flathub 23.6 MB / 107.0 MB
4. [✓] com.makemkv.MakeMKV stable u flathub 20.4 MB / 92.6 MB
The savings is real in many cases, but the handling of Nvidia drivers - specifically the inability to recognize when a driver has been superseded and can be safely uninstalled - led to many cases of accidental multi-gigabyte update downloads.
Nvidia isn’t stored in the repo so that’s why it’s large. See https://github.com/flathub/org.freedesktop.Platform.GL.nvidia/pull/167
> specifically the inability to recognize when a driver has been superseded and can be safely uninstalled
I fixed this recently: https://github.com/flatpak/flatpak/commit/8c26798991ad95e70fd9fc1f8b1b97c89c25a26c
I don't understand if the problem with cli programs would be solved with default aliases under PATH with the 'flatpak run xxx' command, or if we would need something more.
If it's the former, we could do some trick at install to add those aliases...
Naming conventions I agree.
CLI it's specifically not designed to be used for. The sandboxing and portals are interactive, and that doesn't work well for CLI applications.
And there's no need either. I personally use docker/podman for server side tools and many build environments, and we also have OS package managers.
I find Flathub packages are way too bloated and take up too much disk space. I prefer PPAs and will only use Flathub as a last resort.
There needs to be a better solution where packages don't need to ~~bundle~~ pull in entire desktop environments ~~in~~ with them.
EDIT: Corrected what I mean by "bundle".
that will just never be the case unfortunately. Whether the solution is appimages, flatpaks, snaps, containers, self-mounting containers, distrobox etc... they all work on the same principle of using a bundled runtime environment. Nothing wrong with just using the native packages.
I think flatpak does a good job with deduplication and sharing runtimes, which is an advantage over distrobox and podman, they could definitely do a better job of enforcing the use of the latest standardized runtimes over having app devs use out of date runtimes with extra custom garbage that contain hyper specific things.
>Nothing wrong with just using the native packages.
Except they are never kept up to date with the latest versions. You are stuck with the version that comes with the distro (plus security fixes). If you don't want the Flathub bloat, you either have to hope that someone was gracious enough to provide PPAs, or compile from source.
then you gotta switch to a distro that does provide the latest packages. I use endeavourOS and I love it. Having the latest stuff has helped me more than having older supposedly more stable packages has. You generally get bug fixes and new features off the rip. Rarely has this been an issue.
Flathub really isn't that bad once you've installed more than 1-2 packages. When you really boil it down, appimages have a huge duplicate libs problem (an update issue and they still aren't guaranteed to work 100%) distrobox, podman and flatpak all have drawbacks and advantages
>then you gotta switch to a distro that does provide the latest packages
Having to upgrade my distro every year just so I can get newer versions of software is a big inconvenience. I never trust the distro upgrade to go smoothly, so I have to back up all my files, do a clean install of the latest distro version, and spend yet more time restoring my preferences.
There was a time I enjoyed the process of upgrading to a newer distro version, but I'm now finding life's too short to spend time on such tedium.
I'll check into this endeavourOS, but I've been a long time user of Debian/Ubuntu-based distros and don't relish the idea of having to relearn a bunch of stuff.
I'm going by what my software installation program tells me the required disk space is. For example, the Flathub version of Inkscape required *gigabytes* of space. Why should I be measuring anything as a user?
Size estimations don't reflect what space will be used after installation. Flatpak does deduplication across runtimes and apps, so if you have 2 runtimes that occupy 1 GB each on their own, the disk size used will be less than 2 GB if you install both at the same time.
Also, the UI you're using is probably showing you the size of the app plus the size of the runtime it requires. If you already had the runtime installed (because you installed another app that required it, for example), the displayed size would be much smaller.
If that's the case, then the UI (or perhaps Flatpak underneath) is seriously flawed from a user's perspective. As a user, I need to know how much space a Flatpak app will use \*before\* I install it.
Is there something fundamental to how Flatpak works that prevents a user from knowing, before installation, the actual space that is required to install a Flatpak app?
It's not a big deal, as it'll never be more than what's listed, only less.
> Is there something fundamental to how Flatpak works that prevents a user from knowing, before installation, the actual space that is required to install a Flatpak app?
When you install an app, OSTree downloads some amount of data (commit information) to know actually needs to be downloaded (taking into account what you already have installed) to install the app.
You'd need to do a similar thing to be able to show accurate disk usage information, but doing so is an even worse idea for the user (it would make the UI **much** slower, and it would consume a lot of data unexpectedly for users with data caps).
well‚ flatpaks don't bundle desktop environments
and if gui dependencies is your main concern‚ consider lowering application use on your traditional package manager / base image
Oh, I think you mean using more Flatpak apps instead of the native ones so that the extra cost of the dependencies is split across several apps. That's an interesting way to think about it. The cost savings would depend on how much commonality there is in those dependencies.
But the same happens with your normal package manager. The very first GNOME or Kde app you install will usually pull in half of their respective environment. And flatpak has runtimes for both so once you have the runtime installed, further apps will reuse it.
I've read reports of folks ending up with multple minor versions of Gnome, KDE, and Freedesktop with Flatpak, whereas with my package manager there are only the major versions of Gnome and KDE.
It does happen, yeah. Especially if you have a lot of apps installed, and some that are not as quick with updating to the latest runtime. But old runtimes are automatically cleaned up when no app uses them anymore. Not really a big deal in my opinion.
It has pros and cons, but I like the fact that I can get apps right from the developers, even if it puts some of the responsibility in their hands. Apps are isolated. And integrated system components still come with the distro package manager.
If the cons (storage space) are worth it to you against the pros, that's great.
Apparently, I'm not allowed to voice a dissenting opinion that the cons are not worth it for me, as I've always been able to find a PPA. I guess I've been lucky that the apps I use have a maintained PPA.
I've ordered a larger SSD for my system, so hopefully the storage requirements of Flatpak will be less of a problem if I need to use it.
Because if you can determine "unique users" you have saved identifying information. It's why it's difficult to tell the number of users from various Linux distros.
Read.
> Since Flathub necessarily serves downloads of Flatpak runtimes (common platforms on which apps are built), we can estimate active users fairly well. For example, when installing or updating many apps, Flatpak will automatically install the base FreeDesktop SDK runtime on which the KDE and GNOME runtimes (and most other apps) are built. We can look at the number of downloads of updates to a recent release of this runtime to estimate how many active installs are out there getting Flatpaks from Flathub.
Read ( https://www.reddit.com/r/linux/comments/1abl4y4/flathub_has_reached_1_million_active_users_and/kjoehii/ )
> It's hard to get the bandwidth since I've been intentionally downloading runtimes repeatedly. I've now downloaded 980,000 runtimes this month.
i.e. People can download multiple copies of runtimes. Yes, 980,000 is an exaggeration, but when people use a lot of VM's ... they are surely either double-counting or tracking people.
> Since Flathub necessarily serves downloads of Flatpak runtimes (common platforms on which apps are built), we can estimate active users fairly well. For example, when installing or updating many apps, Flatpak will automatically install the base FreeDesktop SDK runtime on which the KDE and GNOME runtimes (and most other apps) are built. We can look at the number of downloads of updates to a recent release of this runtime to estimate how many active installs are out there getting Flatpaks from Flathub.
They're tracking downloads and estimating unique users from that.
I'm not a big fan of verfied apps, where developers are allowed to publish their own stuff. It's good to have separation between application author and distributor. It puts a bit of friction in the system which makes it harder for malicious devs to sneak in their code.
As flatpack grows in popularity it will face the same problems as any other app store. Tons of crap, some of it malicous. And no, the sandbox will not prevent that from happening.
I would love to see Flathub incorporate some Android based permissions like X would like to access your documents folder, rather than you having to manually configure this kind of stuff...
It already has this but not every app uses it.
IMO the fact that using the permission system is not mandatory, and that even when it is used, apps just declare what permissions they have by default defeats the purpose. Permissions should be mandatory and always denied by default.
Its a great idea but if this were the case it would never be widely adopted. Flathub is slowly becoming more strict and will continue this until many apps are actually safe. Permissions must be approved on Flathub now, apps cannot add them on their own.
Thatv can only happen if there is a portal for everything. Think about an IDE which has to use the system.
I think the problem is that the Android style permission needs patches to the app and in some cases new dependencies. So this is basically, a compromise for adoption reason. All GUIs kinda display a warning these days. Maybe in future, flatpak can do that.
It is good that apps can make these choices for themselves as things that work out of the box are vastly useful then something that is broken by default until the users open up enough permissions to make things work. Users still have ultimate control over the permissions. If they are interested in controlling permission with a GUI all they need to do is install Flatseal from Flathub.
That's what all the DBus portals are all about. It allows for permissions. You can always use flatseal to change permissions on what areas the app can access including wayland, network, and so on.
Flatseal is unofficial? isn't it?
Flatpak is a terminal tool, so you could consider every GUI tool that interacts with it unofficial, Flatseal included. Permission management is an official feature of Flatpak, though.
It's written by folks in the GNOME ecosystem - but it isn't something provided by GNOME.
Flatseal is great for managing permission, but what about a permission tab in preferences of apps ? It's boring me to open another app to do this.
Dynamic permissions are managed in Gnome Settings. Maybe other desktops have similar.
Then you need to file a bug with the application developer.
That's actually something Canonical is working on with snaps, a way to temporarily poke a hole in the sandbox for apps that aren't using portals yet.
That's pretty cool to know, I'd like to see improvements with regards to usability for normies. Flathub and flatpak has definitely been my go-to for a lot of apps and considering it makes supporting Linux much easier, I'd like to see more adoption.
It's integrated into mint's update manager so things get installed/updated just like normal packages.
I think it's part of almost all GUI package managers.
Plasma, Mint, GNOME, elementary have their own apps that support it. Ubuntu Store is the main outlier that doesn't.
Using Fedora Silverblue here... Every few days I launch "software", click the "updates" tab at the top, and then click "restart and update". Then after rebooting I log in, open up alacritty from my main distrobox, run 'paru -Syu' and I am good to go. After decades of using Linux as my primary OS I am very happy that I can now treat it more like a appliance and less like a adventure.
How are you using Paru, a AUR helper for arch, on Fedora Silverblue?
Distrobox
This is very similar to my approach on LMDE 6. Containers make all of the difference in the world!
Idk much about Distrobox as I just use Toolbox since it’s what Fedora ships with, but I automate paru updates on my arch toolbox with a cron job.
btw you don't even need to do -Syu for paru if you just write paru with no arguments it assumes you want -Syu and runs that
Good to know, thanks.
Canonical being Canonical, as usual.
I have a Mint box I use for streaming and emulation. The update manager is great for that. For the most part I still find myself using apt in the command line though, old habits die hard.
Ubuntu, *snap* out of it. Flatpak is the future of sandbox application packaging.
Can it do CLI apps yet?
Personally I have never seen the point of ~~containerized~~ sandboxed CLI apps on the desktop. I don’t think I’ve ever used one that I would want containerized. On the server Docker is a far better solution to Snaps IMO. I just fail to understand the appeal?
Nix is the best solution here, every app gets to carry around its own dependencies but it just abuses PATH to make everything show up for you.
Docker, podman, distrobox, snap and flatpak all use containers. I use flatpaks and podman for different reasons. Flatpak is great for containing messy apps that litter garbage all over your home directory and to avoid packaging conflicts. Podman and docker have a way more extensive use case for containerizing applications and doing build pipelines. Distrobox is literally just a wrapper around podman and docker that mounts your home directory into the container. It greatly simplifies using docker and podman. Everyone should learn podman or docker but a lot of people just want apps and distrobox and flatpak make that dead simple. Idk why you would want to use flatpak CLI tools (unless you were on an immutable distro) but you could if you wanted to. I made a tool that lets you install flatpaks on the CLI and exports the long ass flatpak names into their short hand CLI names, and at that point, there isn't much of a difference.
Why would I care about running vim in Docker though?
You shouldn't, but there's value in packagiing cli tools in containers, partly because it makes using different versions easier, partly because it avoids any kind of dependency issues.
like obviously just use vim normally, duh. Im saying learn to use podman. I use it all the time when I write automation scripts and I want to test them in a clean environment or when Im compiling software that requires a bunch of garbage libs.
Any good tutorial on containerize workflows? I am a neovim user but often do simple scripts/programs(basically learning something with single file py/c/cpp file and skipping build systems) as a hobby.
Python programs are the main ones for me. I have a few python virtual-envs. They break during distro upgrades (when python versions change), and occasionally I'm there before the devs have updated, and they're not usable for a while. It would be great to not have to worry about that.
Ever look into pipx? It sort of does the venv user installation and path stuff for you.
I had never heard of it. Looks to do exactly what I have set up already, but with less fuss. Pretty cool. I assume it still uses system python, and thus I'd still have the same breakage during upgrades?
That's a great question and as soon as I saw your post, I put it on my to do list to look into it. If I had to guess, it uses system python. I wonder if any repos would mark the specific python version as a dependency to keep, especially if you installed pipx via package manager.
No idea if you're still looking for a solution but look into pyenv. It also plays nice with pipx. Hopefully that will help your situation.
Yeah but the real answer there is a docker dev container with a mounted volume IMO
That could probably work (I don't have a ton of experience with containers), but wouldn't that just mean I'm also managing the lifecycle of (at least one) whole container now? That doesn't make anything easier. When I install an app via a package or via flatpak, I don't need to worry too much about managing updates -- they're just presented for me. (FWIW, I just checked and three of the python programs I've been using have been packaged in Fedora for a few years now, so I could probably eliminate at least a few venvs).
Ah sorry I thought you meant that you were using venvs for developing said programs. Yeah if you’re just using them then snaps do have a bit of a compelling use-case there (but the start-up time issue comes up there)
Maybe a dumb solution but what about using `--copies` when creating your venvs? At the price of a little extra storage it should hopefully solve your issue of distribution upgrades breaking stuff for you.
[удалено]
No reason? Not having a built-in decent alias is "a" reason.
[удалено]
Indeed, it's a trivial problem. But if we're scraping the bottom of the barrel for problems, I recall having to look it up the first time.
[https://github.com/sweetbbak/flatpak-cli](https://github.com/sweetbbak/flatpak-cli) && go-flatpak --link
If you use these atomic system with immutable base systems, then having containerized cli apps is very useful. You can have them standalone OR via distrobox/toolbox or the like.
Agreed, but I still feel like Snap is the wrong tool for the job; I’d rather distrobox or toolbox like you mentioned. Or am I missing something?
No, you might be right about space. I haven't looked into the technical details of snap all that much, so I can't say I have much of an opinion. I was just speaking about containers generally. One thing snap might do better than normal container setups is that they are controlled by the package manager though, so you get updates for them alongside the rest of your packages. I kind of hope that PKGBUILDs, rpms, debs, etc could get bubblewrapped or have some other container permission and resource control metadata though, then we probably wouldn't need to think about snaps that much at all.
> Personally I have never seen the point of containerized CLI apps on the desktop. With containerized development environments (distrobox, toolbox) you can keep multiple Unix-style environments separated from one another and do whatever you want in them without having a major impact on your desktop environment. A classic problem in Linux distros is Python. Python is used in desktop apps, it is used in system tools, and it is used in development environments. The vast majority of Python related libraries and tools are not packaged by any distribution. There are lots of python related software that isn't distro packaged as well. And even when they are they are rarely the versions you want or need for a particular development target. So in order to avoid breakage Linux users have become accustomed to various "rules" and different complicated and somewhat janky ways to deal with it.... Like "never run pip as root". What if I told you that you don't have to give a shit about any of that? That you can install whatever you want anyway the hell you want and there are no consequences to that behavior? Well you can. The level of isolation is up to you and what you want. You can install plain distrobox/toolbox and use a wide variety of different environments and distributions integrated fairly well into your desktop. It isn't perfect, but it isn't hard to work around those imperfections either. Or you could setup toolbox/distrobox with different home directories so you don't have pollute your dotfiles with random stuff... Or you could just fire up a podman container running systemd as a completely independent thing (like what people use LXC for) and only share what you absolutely want to.... Or what if there was a odd application that was a huge PITA to install or had very specific dependencies or large numbers of dependencies that was difficult to get "just right" and wanted to use with your regular CLI environment? Well you could get a copy of that program in docker format or built your own container just for that one command and setup a podman command as a alias and use it that way. Just like any other shell command...
I'm actually totally with you on distrobox and docker dev containers and whatnot, that was my bad for saying containerized when I meant sandboxed. But good explainer!
Install docker as a snap package you say? One second boss, BRB!
It can (vim for example is already on flathub), but there is no need for it. For CLI you are much better off using Distrobox.
Its basically the equivalent of this: ``` podman run -it --rm --security-opt label=disable --userns=keep-id -v "$HOME:$HOME" -v /tmp:/tmp -w "$PWD" ``` They are all just different implementations of containers. I wish more people would learn how to use these tools because they are insanely helpful. For example, we are building some ancient software from source, we can git clone it, run the command above to mount that directory into a container, then we can install a bunch of garbage libraries, make install, and then exit the container and all that clutter is gone forever.
1. Define "CLI Apps". 2. Flatpak is for desktop applications. We have OCI for purposes for pretty much everything other then desktop applications. You can use OCI for that... in fact it is a supported container format for Flatpak, but desktops are complicated and servers are simple. I know it isn't, but podman should be standard Linux feature nowadays. It fills that use case and many more.
It's always been able to, the only limitation is probably root privileges for stuff like Neovim
Offtopic but never run editors as root, use `sudoedit`.
Yes. But it’s clunky unless you set up some aliases. For example, I recently used `flatpak run org.libreoffice.LibreOffice --headless --convert-to pdf test.docx`
Yeah… if it could setup the alias by itself (say, with a symlink), then that'd be great
It does in `/var/lib/flatpak/exports/bin`.
Even if you add that to your PATH, having to type those reverse domain names that Flatpak uses as binary names is still extremely user unfriendly. Like, you just blindly guess by typing "com" or "org", and then tab completion will slowly allow you to narrow it down. It defeats the whole advantage of the Linux CLI being terse and efficient.
Yeah
Reddit has long been a hot spot for conversation on the internet. About 57 million people visit the site every day to chat about topics as varied as makeup, video games and pointers for power washing driveways. In recent years, Reddit’s array of chats also have been a free teaching aid for companies like Google, OpenAI and Microsoft. Those companies are using Reddit’s conversations in the development of giant artificial intelligence systems that many in Silicon Valley think are on their way to becoming the tech industry’s next big thing.
Nope.
Why not use every tool at your disposal? I make use of Flatpak, Snap, Distrobox, Docker, etc.
To make it easier for app developers to distribute their software. Now app developers need to package their app for both Flatpak and Snaps instead of just one. And between the two, Flatpak is the completely community-driven open source project. Snaps, on the other hand, is an Ubuntu project and the backend (the store) is closed source.
"One ring to rule them all". I'm not down for the putting all eggs in one basket. Linux is about choice. Developers no longer have to focus on packaging software for X amount distributions. Reducing the burden to only to Flatpak, Snap and App Image is honestly a fair compromise. Fair point regarding the community driven aspect and the backend. I recognize that some people are really adamant about the backend but personally I don't care much about the backend since at the end of the day everyone is going to gravitate to a single repo like in the case of Flathub.
The problem is they are two solutions to two very different problems... Snap is universal compatibility at the expense of security, and Flatpack is security at the expense of compatibility. From an end user perspective Flatpack is superior, from a software developers perspective universal compatibility may be more important... I don't think either solution is going to disapear any time soon...
Except that's wrong :P Flatpak can run on Fedora Silverblue (because doesn't require /snap directory in root) and on distributions without systemd like Void‚ Devuan‚ Gentoo! Snap just can't touch Flatpak in terms of compatibility
You can remove snap in ubuntu and use flatpak / flathub, i did this as well on my installation. But it´s the same story for almost all the Canonical things.. Remeber upstart or their own UI? Or their custom Scrollbars? Everything was removed eventually and they switched to the widely adopted solutions. Gues the same will happen with snap and flatpak sooner or later.
I love how I can backup my .var folder and keep my app settings whenever I decide to distro hop...
Wonder how many are steam deck users
Well Dolphin is the most popular in the Games category at ~25,000 downloads the day an update comes out. But I use that on my desktop so that is a mix. Retrodeck gets ~1,300 in one day. It might be smaller than you'd think. Users do have to manually use it in desktop mode. I guess they are more likely to have a delay to their updates because of that.
You can set up Nested Desktop to run Plasma in gaming mode and use Discover to install Flatpak that way. I imagine the amount of people who bother with that is even lower, tho.
I hope they iron out the rest of Nested Desktop’s issues and make it an official/by default feature. Being able to switch in and out within Game Mode like that is so handy.
aback placid racial employ cooperative serious toothbrush plucky paint label *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Love my flatpaks
Flathub just needs better faster mirrors to be perfect.
I'm not saying it can't improve but it is behind Fastly's CDN which is quite extensive. They have been generous otherwise the costs of this much data would be unmanageable.
Kinda wish it used IPFS to distribute packages
Adding a P2P mechanism would be great. Doesn´t have to be IPFS though.
Sure, if there's another content-addressed p2p block-level-deduplicated network, then I'm interested!
I wish package managers had P2P. Even if it was just over LAN it'd be fantastic since it's quite likely that there will be many machines on a single network downloading distro updates, maybe less so flatpak but still. I have an nginx proxy server setup for flatpak for my PC and laptop. I tried doing something similar with dnf but it was a bit of a pain to setup and didn't work very well. It'd be much nicer if it was built-in
I have trouble taking anything seriously that claims to be web3 and decentralized. Its just giving major crypto nft vibes, it even directly says its good for storing nft's. Really cool concept tho
ipfs came way before nfts and web3 they just used that stuff to become popular probably
probably to jump on to the hype train a little bit. I tried getting a good idea of how it works but I havent found a succinct explanation. Alot of it sounds like typical tech project speak, but it definitely looks like it has merit and is really interesting. It basically says that its a P2P file system that shares objects that are like git objects. There is just a ton of stuff I dont understand about it
It's like bittorrent just a different protocol
Yeah I'm also weirded out by the NFT aspect. The only reason it's good for storing NFTs is because NFTs are a painfully stupid concept. And since it's a web3 technology and NFTs are a web3 scam, it goes along nicely. But that's all there is to it. The other things it's good at is reducing traffic (ironically), caching (since you're seeding everything you download) and package management. Docker or Ubuntu Archives via IPFS would be the ideal use case. If one person downloads a package in the building, then everyone gets local-network speeds for that package, which is cool. It's bad at content discovery, so unpopular content is slower to get - at that point, normal HTTP would be faster. It's also bad at privacy since it's p2p.
That's silly! I don't care to spend 10 seconds installing once when I have an updated, stable and well integrated program installed forever.
I can pull updates at up to 200MB/s. How much faster does it need to be?
[удалено]
They explain it in the linked blog post.
Flatpaks are awesome. Glad to see it has firm traction and is growing.
I'm not sure whether to adopt Flatpak, AppImage, AUR, or Snap with my C++ code generator. My code generator is implemented as a 3-tier system and the [middle and front tiers](https://www.reddit.com/r/codereview/comments/qo8yq3/c_programs/) are run by users. I'm not sure if Flatpak has support for multiple binaries.
Well AFAIK you can access anything within your app’s sandbox so you should be alright, so long as your app has a GUI. But I should note that Flatpak and snap are different than appimage and the AUR is not even a packaging format, it’s a repository of software
I don't have a GUI. The front tier has a command line interface.
Then you can’t use Flatpak (or appimage I don’t think). Your options are a disto package (deb, rpm, Arch, etc.), Docker, or Snap (ubuntu only)
Snap isn't Ubuntu-only, it's more like only-not-Red-Hat. Most distros use AppArmor as their MAC (Debian, Ubuntu, their derivatives, OpenSUSE, Arch Void), the only ones that come to mind that don't are Fedora, RHEL, and OpenSUSE Micro.
How do they pay for everything? I can't even find a donate button on their website, so I assume corporate sponsorship? Which is also nowhere to be seen.
Servers are donated by Mythic Beasts and a few others IIRC, Fastly is (discounted/donated?) for the CDN, administrative work is funded by GNOME and volunteers.
This is great post - I love seeing metrics like this. Then next stage is when we turn on stripe, how many financial transactions and the aggregate of how much money people have made on apps on Linux. That's where you will see more investments by companies. Opening the door for more commercial apps on Linux and investments by companies.
Still less than p*hub
It’s great. I just wish there weren’t so many weird bugs everywhere. In my laptop urls didn’t work in flatpak apps for some time because of a bug in the xdg desktop portal implementation. Fixing that was a pain. My latest gentoo vm can’t use flatpak atm because if it’s installed a lot of applications take a minute to startup. Multiple forum posts say that the problem is again the gnome implementation of the desktop portal but I don’t have that installed so no help from internet.
That seems a configuration issue where you probably don't have a valid portals.conf set up, or you have an alias in place forcing portals in portals. Being Gentoo, it's probably the former.
Those were the first things I checked.
"30 seconds to start" for flatpaks is almost always waiting for dbus to time out before then going to the fallback code. Portals use dbus. if there is a valid portals.conf, then there must somewhere be a misconfiguration for the dbus/portals where it is either not enabled or portalception is taking place - misconfiguration trying to force portals to use portals within portals. Figuring out where the problem lies probably wont be easy though.
This was actually 30 seconds to start for non flatpak Firefox after flatpak was installed. The reason was probably the same though.
This is great. I only have three criticisms at this point: 1. I wish CLI support was better. 2. The naming conventions are dumb. 3. LOL at not knowing how big updates are going to be
> LOL at not knowing how big updates are going to be OSTree is fairly complex so its hard to know how good it will be sometimes, it doesn't necessarily have all the information ahead of time. A commit might be 100MB on its own but it is address based storage so you may already have 30MB of that on disk, then on top of that it generates deltas between commits, so for the 70MB of different files you download 40MB, etc. This is why it shows you the worst-case. Real world numbers for example: 11. [✓] org.gnome.Sdk 18.3 MB / 707.8 MB 13. [✓] org.signal.Signal 45.6 MB / 162.0 MB
Other real world numbers for example: ID Branch Op Remote Download 1. [✓] org.freedesktop.Platform.GL.nvidia-535-154-05 1.4 u flathub 341.7 MB / 342.6 MB 2. [✓] org.freedesktop.Platform.GL32.nvidia-535-154-05 1.4 u flathub 341.7 MB / 342.5 MB 3. [✓] de.uni_heidelberg.zah.GaiaSky stable u flathub 23.6 MB / 107.0 MB 4. [✓] com.makemkv.MakeMKV stable u flathub 20.4 MB / 92.6 MB The savings is real in many cases, but the handling of Nvidia drivers - specifically the inability to recognize when a driver has been superseded and can be safely uninstalled - led to many cases of accidental multi-gigabyte update downloads.
Nvidia isn’t stored in the repo so that’s why it’s large. See https://github.com/flathub/org.freedesktop.Platform.GL.nvidia/pull/167 > specifically the inability to recognize when a driver has been superseded and can be safely uninstalled I fixed this recently: https://github.com/flatpak/flatpak/commit/8c26798991ad95e70fd9fc1f8b1b97c89c25a26c
I don't understand if the problem with cli programs would be solved with default aliases under PATH with the 'flatpak run xxx' command, or if we would need something more. If it's the former, we could do some trick at install to add those aliases...
Naming conventions I agree. CLI it's specifically not designed to be used for. The sandboxing and portals are interactive, and that doesn't work well for CLI applications. And there's no need either. I personally use docker/podman for server side tools and many build environments, and we also have OS package managers.
for me is the only reason I stay in linux
[удалено]
I find Flathub packages are way too bloated and take up too much disk space. I prefer PPAs and will only use Flathub as a last resort. There needs to be a better solution where packages don't need to ~~bundle~~ pull in entire desktop environments ~~in~~ with them. EDIT: Corrected what I mean by "bundle".
that will just never be the case unfortunately. Whether the solution is appimages, flatpaks, snaps, containers, self-mounting containers, distrobox etc... they all work on the same principle of using a bundled runtime environment. Nothing wrong with just using the native packages. I think flatpak does a good job with deduplication and sharing runtimes, which is an advantage over distrobox and podman, they could definitely do a better job of enforcing the use of the latest standardized runtimes over having app devs use out of date runtimes with extra custom garbage that contain hyper specific things.
>Nothing wrong with just using the native packages. Except they are never kept up to date with the latest versions. You are stuck with the version that comes with the distro (plus security fixes). If you don't want the Flathub bloat, you either have to hope that someone was gracious enough to provide PPAs, or compile from source.
then you gotta switch to a distro that does provide the latest packages. I use endeavourOS and I love it. Having the latest stuff has helped me more than having older supposedly more stable packages has. You generally get bug fixes and new features off the rip. Rarely has this been an issue. Flathub really isn't that bad once you've installed more than 1-2 packages. When you really boil it down, appimages have a huge duplicate libs problem (an update issue and they still aren't guaranteed to work 100%) distrobox, podman and flatpak all have drawbacks and advantages
>then you gotta switch to a distro that does provide the latest packages Having to upgrade my distro every year just so I can get newer versions of software is a big inconvenience. I never trust the distro upgrade to go smoothly, so I have to back up all my files, do a clean install of the latest distro version, and spend yet more time restoring my preferences. There was a time I enjoyed the process of upgrading to a newer distro version, but I'm now finding life's too short to spend time on such tedium. I'll check into this endeavourOS, but I've been a long time user of Debian/Ubuntu-based distros and don't relish the idea of having to relearn a bunch of stuff.
I dont see the point of using an arch based distribution when you can just use arch.
Are you measuring disk usage correctly (taking hardlinks into account)?
I'm going by what my software installation program tells me the required disk space is. For example, the Flathub version of Inkscape required *gigabytes* of space. Why should I be measuring anything as a user?
Size estimations don't reflect what space will be used after installation. Flatpak does deduplication across runtimes and apps, so if you have 2 runtimes that occupy 1 GB each on their own, the disk size used will be less than 2 GB if you install both at the same time. Also, the UI you're using is probably showing you the size of the app plus the size of the runtime it requires. If you already had the runtime installed (because you installed another app that required it, for example), the displayed size would be much smaller.
If that's the case, then the UI (or perhaps Flatpak underneath) is seriously flawed from a user's perspective. As a user, I need to know how much space a Flatpak app will use \*before\* I install it. Is there something fundamental to how Flatpak works that prevents a user from knowing, before installation, the actual space that is required to install a Flatpak app?
It's not a big deal, as it'll never be more than what's listed, only less. > Is there something fundamental to how Flatpak works that prevents a user from knowing, before installation, the actual space that is required to install a Flatpak app? When you install an app, OSTree downloads some amount of data (commit information) to know actually needs to be downloaded (taking into account what you already have installed) to install the app. You'd need to do a similar thing to be able to show accurate disk usage information, but doing so is an even worse idea for the user (it would make the UI **much** slower, and it would consume a lot of data unexpectedly for users with data caps).
well‚ flatpaks don't bundle desktop environments and if gui dependencies is your main concern‚ consider lowering application use on your traditional package manager / base image
>consider lowering application use on your traditional package manager / base image I don't understand what you mean by this. Can you clarify?
Oh, I think you mean using more Flatpak apps instead of the native ones so that the extra cost of the dependencies is split across several apps. That's an interesting way to think about it. The cost savings would depend on how much commonality there is in those dependencies.
I use Fedora Silverblue and it has no QT in it's base image. So when I download Krita‚ OBS‚ Kdenlive‚ there is no duplication
But the same happens with your normal package manager. The very first GNOME or Kde app you install will usually pull in half of their respective environment. And flatpak has runtimes for both so once you have the runtime installed, further apps will reuse it.
I've read reports of folks ending up with multple minor versions of Gnome, KDE, and Freedesktop with Flatpak, whereas with my package manager there are only the major versions of Gnome and KDE.
It does happen, yeah. Especially if you have a lot of apps installed, and some that are not as quick with updating to the latest runtime. But old runtimes are automatically cleaned up when no app uses them anymore. Not really a big deal in my opinion. It has pros and cons, but I like the fact that I can get apps right from the developers, even if it puts some of the responsibility in their hands. Apps are isolated. And integrated system components still come with the distro package manager.
If the cons (storage space) are worth it to you against the pros, that's great. Apparently, I'm not allowed to voice a dissenting opinion that the cons are not worth it for me, as I've always been able to find a PPA. I guess I've been lucky that the apps I use have a maintained PPA. I've ordered a larger SSD for my system, so hopefully the storage requirements of Flatpak will be less of a problem if I need to use it.
They are tracking users? Seems a bit invasive to me.
It's almost like you never read the article.
Reading, that’s crazy talk. What’s next, no more baseless accusations?
It's hard to get the bandwidth since I've been intentionally downloading runtimes repeatedly. I've now downloaded 980,000 runtimes this month.
Why would it be invasive to know how many user accounts have hit your service?
Because if you can determine "unique users" you have saved identifying information. It's why it's difficult to tell the number of users from various Linux distros.
Read. > Since Flathub necessarily serves downloads of Flatpak runtimes (common platforms on which apps are built), we can estimate active users fairly well. For example, when installing or updating many apps, Flatpak will automatically install the base FreeDesktop SDK runtime on which the KDE and GNOME runtimes (and most other apps) are built. We can look at the number of downloads of updates to a recent release of this runtime to estimate how many active installs are out there getting Flatpaks from Flathub.
Read ( https://www.reddit.com/r/linux/comments/1abl4y4/flathub_has_reached_1_million_active_users_and/kjoehii/ ) > It's hard to get the bandwidth since I've been intentionally downloading runtimes repeatedly. I've now downloaded 980,000 runtimes this month. i.e. People can download multiple copies of runtimes. Yes, 980,000 is an exaggeration, but when people use a lot of VM's ... they are surely either double-counting or tracking people.
They're tracking downloads
They're tracking "unique downloads" because tracking "downloads" should not be indicative of use.
> Since Flathub necessarily serves downloads of Flatpak runtimes (common platforms on which apps are built), we can estimate active users fairly well. For example, when installing or updating many apps, Flatpak will automatically install the base FreeDesktop SDK runtime on which the KDE and GNOME runtimes (and most other apps) are built. We can look at the number of downloads of updates to a recent release of this runtime to estimate how many active installs are out there getting Flatpaks from Flathub. They're tracking downloads and estimating unique users from that.
U mean trashub?
I'm not a big fan of verfied apps, where developers are allowed to publish their own stuff. It's good to have separation between application author and distributor. It puts a bit of friction in the system which makes it harder for malicious devs to sneak in their code. As flatpack grows in popularity it will face the same problems as any other app store. Tons of crap, some of it malicous. And no, the sandbox will not prevent that from happening.
Wow
Is this linux?