I used to think Flatpaks were a huge pain the butt, but over the last few years, I moved to using them for all third party software that I run on my Fedora Linux workstation.
Zoom, Slack, Spotify, Steam, Discord, Obsidian all run without issues and they get consistent updates. I am convinced now that they are one of the best ways to ship commercial software on to Linux desktop. Flatpak has been a key part of me becoming 100% Windows free for my PC gaming. Not having to run a desktop KVM to switch between my work workstation and my Gaming PC has been super great.
Last I tried all three of the semi-popular formats like this, AppImage was the only one that didn't feel fundamentally wrong (though what I gather was the closest thing to an official repository for them looked sketchy as hell—somehow they copied the exact CSS vibe as a content-scraped StackOverflow spam site). But that was a couple years ago. I know Snaps still suck, but haven't messed with Flatpacks since then, so maybe they're better now.
> I used to think Flatpaks were a huge pain the butt, but over the last few years, I moved to using them for all third party software
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.
I use Fedora and this is how I use Flatpak as well. Some software does have some problems when used through Flatpak. I vaguely recall Blender's Flatpak version having some issues. I would also like to see more transparency with who is publishing the Flatpak on Flathub. Maybe I'm just dumb but it is not immediately obvious to me who the publisher is and whether or not this is an officially supported Flatpak application.
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 convinced now that they are one of the best ways to ship commercial software on to Linux desktop.
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?
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.
I also use it like this. I got into it for the sandboxing, although I know there are a "few" lurking issues on this point. But, some of the sandboxing definitely works, and were I a flatpak engineer I'd want to see some indication of traction to justify working towards goals of completion, and no other project with any packaging base I can think of is anywhere close, so, I use it.
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.
I had issues with certain games crashing when run from Steam installed via Flatpak. It's not permission issues, but seems to be due to the Flatpak version bundled different system libraries. Have you encounter such issue on your end?
One big tricky thing is plugins, such as for OBS. ABI incompatibility and sandboxing can make it tricky and confusing for end users. Flatpak itself could theoretically provide answers here.
So these integrate well now?
I normally just use AUR for everything now, and remember having issues with a flatpak for rpcs3 a few years ago, ended up compiling from src
Obsidian without git plugin is pretty much a non-starter for me. What's the point in a folder full of markdown files that can't be checked into git? Only works out of the box for the AppImage, for now. I can't remember why. I suppose I am missing out on 0-click updates of some kind.
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.
I switched to Fedora Kinoite (KDE spin of Silverblue) to force me to go all in on Flatpaks, and now I love them.
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.
> As we also open the ability for applications to be uploaded in binary form, which is essential for low-friction compatibility with popular language-specific build systems such as Electron/Node, Rust, Go, etc - we also reduce the ability for users to scrutinise the source in the Flathub build system that was used to build their application.
...and their solution is running an antivirus scanner rather than stepping back and realizing that they're shooting their own feet clean off. And it's based on an absurd premise! Seriously:
> binary form, which is essential for low-friction compatibility with popular language-specific build systems
What? No it's not! Worst case, build in a container with the official tools. Best case, package the build tools like every other distro and enforce source availability and build reproducibility. I mean, NixOS is a bunch of volunteers doing (a better version of) what you're claiming is impossible!
(Granted, I assume the claimed reason is a lie and the real reason is to support proprietary software, which is... maybe reasonable, but pretending otherwise isn't.)
Opinions on Flatpaks/snaps notwithstanding, it's encouraging to see KDE and GNOME collaborating on projects like this. IMO desktop GNU/Linux has benefited greatly from moving away from offering LXDE/LXQT/Mate/Enlightenment/Cinammon flavors and towards a more digestible subset (GNOME only, GNOME/KDE/XFCE, etc) of polished desktop environments. Pipe dream, but it would be incredible to see all of the passionate, talented folks working together on one definitive GNU/Linux DE.
I'd prefer to see more easily-communicated DE standards and published levels of adherence, rather than moving to the uni-desktop.
Like if you want to select a desktop and are kind of new to desktop environments, maybe aim for the (imaginary example here) DE-5 level of standards-adherence. DE-4 and lower might suck in various ways even though they could have cool new features.
There are way too many benefits from the huge variety of DE approaches, including the benefit that Linux-critics often hide behind critique of a single desktop experience, which is lazy and attempts to steal focus from exactly this open, creative, diverse approach that is the jewel in the Linux ecosystem's metaphorical crown.
It's definitely great to see the groups working together on these projects that benefit everybody.
> but it would be incredible to see all of the passionate, talented folks working together on one definitive GNU/Linux DE.
This would be terrible. Gnome and KDE have pretty conflicting ideologies. Gnome is super opinionated and Mac-like minimalist. KDE is all about user choice.
If they'd collaborate it would end up something in the middle which would suit nobody.
Of these, I would say that Cinnamon is one that could be comparable to XFCE or even GNOME and KDE. Seriously, it's good. The system settings menu has all of the options one could need and the look and feel of the dektop is very customizable.
I'm a KDE user, but if it ever stopped working/disappeared I would use Cinnamon. In fact I plan to use it whenever KDE Plasma 6 releases to wait out until the it becomes more stable.
As a long time Linux user I have mixed feelings about that.
I'm not really against it, but I don't use KDE or Gnome (or any of the others in your list) and it concerns me that people might start thinking of those as "being Linux". I'd hate to see a future where "We support Linux" means KDE or Gnome.
On the other hand, I have to admit I'm not really sure what that would mean. I guess only having "Flatpak" as an option would be a bummer, but I don't see that happening with the distros I use.
There's nothing wrong with Mate, Cinnamon or even LXDE. Especially since desktop environments these days are mostly different frontends built on a fairly unified infrastructure, largely provided by freedesktop.org. We still see divergence between Qt-based and GTK+ based desktops, and other minor differences exist, but the "one definitive" user environment is basically here.
All my dealing with GNOME have made me dread the day that happens. We need a polyculture because we will never beat $mega_corp on a polished monoculture.
I'm an Ubuntu user and the first thing I always do in a new system is removing the Ubuntu Store, completely removing snapd, and installing the Flathub Store.
I'm very in favour of improving the state of application distribution on Linux. Targeting an abstraction like Flatpack seems like a no-brainer if there are no regressions in experience to the end user.
I am not sure if this is the case, but in theory I love the idea that the app sandboxing can allow the Flatpak engine to be a source that can prompt users for permissions access (e.g. "app would like to access your location").
Last time I tried Flatpack I experienced a lot of integration issues, from GTK theming issues to applications missing features due to sandboxing.
Would love to see a high level medium-dive explainer on how Flatpack works to alleviate some of my concerns; predominantly around the limitations of sandboxing.
e.g.
Can OBS have unimpeded screen recording access? How does OBS compare in Flatpak compared to natively installed.
Can VSCode access any part of the FS without any performance overhead, what about language servers and that sort of thing?
Can applications like Discord that feature a voice-activated mic work? Can Discord access what game you're currently playing on Steam and set that as its status?
Originally, I thought Flatpack was much like old win32 applications where if you put a dll dependency next to the executable, it will use that rather than the system one. I got really scared of Linux app sandboxing engines when I tried Snapd and it started making virtual network devices and my system theme wasn't applied to the application - seemed very convoluted.
Flatpak used to have a lot of issues with sandboxing, but in recent years the situation has gotten better because of two things:
1. A strong push to help package maintainers fix sandboxing mistakes, expose the APIs that need to be exposed and lock down the APIs that are not needed. It used to be pretty bad but it's pretty rare to see sandboxing problems nowadays.
2. You can now use a tool called Flatseal, or in KDE a new builtin settings interface in Plasma 5.27, to modify sandboxing settings for applications in an intuitive way. If you're trying to use an IDE and just want to expose every permission to it, you can easily do that now.
3. Unrelated to Flatpak, Wayland is now getting a lot of the video capture and screen recording APIs that are needed.
> Can OBS have unimpeded screen recording access? How does OBS compare in Flatpak compared to natively installed.
I'm livestreaming on a regular basis, and moved from OBS as compiled by Arch Linux to OBS Flatpak. Everything just works (esp. the browser source that uses an embedded Chromium, which I never got to work with the Arch packages). Most likely that particular Flatpak is very liberal in its sandboxing, because it was even able to write into $HOME/obs-recordings/ without any permission prompt. I don't care about the sandboxing part of Flatpak too much in this particular case, so I didn't dig further.
I haven't been the biggest fan of flatpak and generally wish software would either be packaged as an rpm or an AppImage, but the OP makes a pretty strong case for why it's a good idea (because existing options are too niche, and have no ability to incentivize developers who need to get paid for their work. This leads to Linux desktop having far fewer applications available to them compared to windows and mac.)
I do hope the command-line UX around flatpaks (installing, updating, etc) improves a lot though as currently it leaves much to be desired.
Flathub could become the killer "app" for the Linux desktop. No need to juggle dependencies and third party repos. The software you need in an instant.
It's the closest thing to APKs for Linux. We need an Android for desktop: a signed base image with silo'd applications, application data, and granular permissions.
I feel like one thing that is still holding Linux Desktop and any initiative like this back is that we don't have really high quality linux laptops on the market.
We have some people like System76 doing great things, but not in Europe and for all their great work its not the highest quality stuff from China with some serious limitations.
For all the things the European Union funds, from chip manufacture, HPC and many other project from large to medium to small. Why have we not seen a made in Europe Laptop/Desktop/Phone for the bureaucrats and engineers who do things like running states and building weapons and so on.
A fair amount of EU money goes into a lot of these distributed system and internet projects. And I'm not complaining, but we are spending a lot of time trying to make our system secure from everything other then direct attack. The fireware in the new notebook doesn't seem better then in the one before, in fact worse in some way.
We have most of the software, we have most of the things needed to do these things. An Open-Source computer for Europe (and anybody) would be a real counter-point to most of the other models out there.
In such an environment a real AppStore for Open Linux desktop could actually be a really good thing.
The system package manager is useful for updating the underlying system, not necessarily the user's environment. Think of it as a in the classic root/user divide. The system package manager is there for updating the core system and things like flatpaks/toolboxes are there for the users. They don't follow the same updating patterns so it makes sense to keep them separate.
Richard Brown, who's been working on this problem for 10 years at Suse, says he was wrong in 2017. Flatpak is now the clear way to go, if you care about security, app updates, licensing, and multi-distro support (runtime dependencies).
maybe it's indeed time to let the system package management(apt,rpm,etc) just manage a solid BASE system, and let Flatpak etc to manage their own application sandboxes on top, kind of like dockers.
Appimage is macos flavor, it never needs your sudo to install the package, which is nice.
Flatpak is a redhat flavor(kind of), it needs sudo sometimes, but OK.
Snap is a ubuntu flavor(kind of), it is like systemd that can overtake the whole system, it can install package and even the whole system I was told, too much as a package manager for me.
I don't use Snap. Appimage is not as widely adopted as the rest two? I think Flatpak is a great middle ground.
It will be really cool if KDE and Gnome work together to build this.
I had to use flatpack to install Bottles, I'm on Porteus because it's the only distrib I found that would fit on a 15 year old 512MB USB stick and then in the RAM directly... Let just say it wasn't a seamless experience but I'm glad I managed to run Cinema4D R20 or MPC Software with Bottles without too many bugs. Anyway Bottles is just fantastic, I tried Wine before but it never worked properly, but having to install a package manager (flatpack) on top of another one (slackpkg) just felt absurd...
What about appimage instead, like Krita? To me it's sounds like the best way to distribute a linux app in 202X...
Managing to make things run on Linux gives a sense of accomplissement, at the same time, I can understand why most people won't move to Linux anytime soon given all the complexity involved... or it's just me and there was an easier way to install flatpack at first place?
Interesting that this announcement comes concurrently with the news that Ubuntu now expects all official derivatives to drop Flatpak support [0]. Looking forward, can someone tell me how these two policies will play nice together?
Unlike google play, apple's appstore and canonical's Snap, flatpak isn't limited to a single repo, apps from other repos will show up in the store ui just like any other app.
Flatpak is a solution to package management as Docker is to servers. What's the predominant reason people use Docker? Because it's impossible to get a Python/NodeJS monstrosity working properly without it. On rolling release distributions, you don't ever need Flatpak. Its predominance is found in stable release distributions like Ubuntu and Fedora. Because they stall packages and their dependencies, it'll always be an issue to install new software. If anything, I prefer AppImage a lot more.
I'm not sure if PopOs uses flathub by default for its PopShop, but I've always had some issues with it and they prevented me from using it and directly using flatpak CLI.
- I don't know how to see running logs by default (if it's possible even) and it's a must when you have slow internet
- sometimes it just hangs and I need to kill (probably leaving residue along the way)
hopefully my issues are my own OR it will get resolved as well.
I think flatpaks are awesome. Especially for commercial software. I do think they are missing an important feature that snap has what snap referes to as classic confinement. For example vscode as a flatpak can't really interact with your normal system libraries/exectuables/etc. That being said I do hope that Flatpaks succeed and becomes the easy go-to option for commercial software to support linux distributions.
>As we also open the ability for applications to be uploaded in binary form, which is essential for low-friction compatibility with popular language-specific build systems such as Electron/Node, Rust, Go, etc - we also reduce the ability for users to scrutinise the source in the Flathub build system that was used to build their application.
This is unacceptable. Open-source apps should always be built from source on a trusted infrastructure and ideally the builds should be reproducible. Otherwise, one of the main benefits of open-source software -- ability to verify its security -- is completely lost.
Fortunately, Flatpak != Flathub. There is also Fedora's flatpak repository and that's what I'm using. It doesn't have as many apps as Flathub, but their number is growing.
I prefer flatpaks to RPMs because of the sandboxing feature. While it's not perfect yet, I like that I can forbid most of my apps to access the network and to limit access to the filesystem and other system parts for apps that require network as much as possible. As a result, the trusted base of my system can be reduced significantly (and the base system can then use other method to confine its processes which on Fedora is SELinux).
Another benefit of Flatpak over traditional packaging systems is that it's a cross-distro package manager and the apps can be installed on any Linux distribution. Even if we end up with multiple Flatpak repositories like Flathub and Fedora Flatpaks with different approaches and philosophies, users of any Linux-based OS can then install apps from any repository they like, and OS developers can focus on the base system.
So in general I like Flatpak and I think it's a step in the right direction, but I can't say the same about Flathub. For me it's unacceptable to install anything from Flathub unless they fix their supply chain security flaws.
[+] [-] jdoss|3 years ago|reply
[+] [-] yamtaddle|3 years ago|reply
[+] [-] pxc|3 years ago|reply
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.
[+] [-] Entinel|3 years ago|reply
[+] [-] yazzku|3 years ago|reply
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.
[+] [-] curt15|3 years ago|reply
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?
[+] [-] uonpopular_th|3 years ago|reply
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.
[+] [-] fdr|3 years ago|reply
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.
[+] [-] neurostimulant|3 years ago|reply
[+] [-] jchw|3 years ago|reply
[+] [-] idonotknowwhy|3 years ago|reply
[+] [-] gavmor|3 years ago|reply
[+] [-] silisili|3 years ago|reply
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.
[+] [-] bogwog|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] yjftsjthsd-h|3 years ago|reply
...and their solution is running an antivirus scanner rather than stepping back and realizing that they're shooting their own feet clean off. And it's based on an absurd premise! Seriously:
> binary form, which is essential for low-friction compatibility with popular language-specific build systems
What? No it's not! Worst case, build in a container with the official tools. Best case, package the build tools like every other distro and enforce source availability and build reproducibility. I mean, NixOS is a bunch of volunteers doing (a better version of) what you're claiming is impossible!
(Granted, I assume the claimed reason is a lie and the real reason is to support proprietary software, which is... maybe reasonable, but pretending otherwise isn't.)
[+] [-] Liquix|3 years ago|reply
[+] [-] themodelplumber|3 years ago|reply
Like if you want to select a desktop and are kind of new to desktop environments, maybe aim for the (imaginary example here) DE-5 level of standards-adherence. DE-4 and lower might suck in various ways even though they could have cool new features.
There are way too many benefits from the huge variety of DE approaches, including the benefit that Linux-critics often hide behind critique of a single desktop experience, which is lazy and attempts to steal focus from exactly this open, creative, diverse approach that is the jewel in the Linux ecosystem's metaphorical crown.
It's definitely great to see the groups working together on these projects that benefit everybody.
[+] [-] 24t|3 years ago|reply
No thanks. GNOME dev hubris is the reason I use KDE
[+] [-] wkat4242|3 years ago|reply
This would be terrible. Gnome and KDE have pretty conflicting ideologies. Gnome is super opinionated and Mac-like minimalist. KDE is all about user choice.
If they'd collaborate it would end up something in the middle which would suit nobody.
[+] [-] sureste|3 years ago|reply
Of these, I would say that Cinnamon is one that could be comparable to XFCE or even GNOME and KDE. Seriously, it's good. The system settings menu has all of the options one could need and the look and feel of the dektop is very customizable.
I'm a KDE user, but if it ever stopped working/disappeared I would use Cinnamon. In fact I plan to use it whenever KDE Plasma 6 releases to wait out until the it becomes more stable.
[+] [-] jlarocco|3 years ago|reply
I'm not really against it, but I don't use KDE or Gnome (or any of the others in your list) and it concerns me that people might start thinking of those as "being Linux". I'd hate to see a future where "We support Linux" means KDE or Gnome.
On the other hand, I have to admit I'm not really sure what that would mean. I guess only having "Flatpak" as an option would be a bummer, but I don't see that happening with the distros I use.
[+] [-] zozbot234|3 years ago|reply
[+] [-] uonpopular_th|3 years ago|reply
[+] [-] mastazi|3 years ago|reply
[+] [-] apatheticonion|3 years ago|reply
I am not sure if this is the case, but in theory I love the idea that the app sandboxing can allow the Flatpak engine to be a source that can prompt users for permissions access (e.g. "app would like to access your location").
Last time I tried Flatpack I experienced a lot of integration issues, from GTK theming issues to applications missing features due to sandboxing.
Would love to see a high level medium-dive explainer on how Flatpack works to alleviate some of my concerns; predominantly around the limitations of sandboxing.
e.g.
Can OBS have unimpeded screen recording access? How does OBS compare in Flatpak compared to natively installed.
Can VSCode access any part of the FS without any performance overhead, what about language servers and that sort of thing?
Can applications like Discord that feature a voice-activated mic work? Can Discord access what game you're currently playing on Steam and set that as its status?
Originally, I thought Flatpack was much like old win32 applications where if you put a dll dependency next to the executable, it will use that rather than the system one. I got really scared of Linux app sandboxing engines when I tried Snapd and it started making virtual network devices and my system theme wasn't applied to the application - seemed very convoluted.
[+] [-] creatonez|3 years ago|reply
1. A strong push to help package maintainers fix sandboxing mistakes, expose the APIs that need to be exposed and lock down the APIs that are not needed. It used to be pretty bad but it's pretty rare to see sandboxing problems nowadays.
2. You can now use a tool called Flatseal, or in KDE a new builtin settings interface in Plasma 5.27, to modify sandboxing settings for applications in an intuitive way. If you're trying to use an IDE and just want to expose every permission to it, you can easily do that now.
3. Unrelated to Flatpak, Wayland is now getting a lot of the video capture and screen recording APIs that are needed.
[+] [-] majewsky|3 years ago|reply
I'm livestreaming on a regular basis, and moved from OBS as compiled by Arch Linux to OBS Flatpak. Everything just works (esp. the browser source that uses an embedded Chromium, which I never got to work with the Arch packages). Most likely that particular Flatpak is very liberal in its sandboxing, because it was even able to write into $HOME/obs-recordings/ without any permission prompt. I don't care about the sandboxing part of Flatpak too much in this particular case, so I didn't dig further.
[+] [-] freedomben|3 years ago|reply
I do hope the command-line UX around flatpaks (installing, updating, etc) improves a lot though as currently it leaves much to be desired.
[+] [-] sys42590|3 years ago|reply
[+] [-] flangola7|3 years ago|reply
[+] [-] heywhatupboys|3 years ago|reply
[+] [-] panick21_|3 years ago|reply
We have some people like System76 doing great things, but not in Europe and for all their great work its not the highest quality stuff from China with some serious limitations.
For all the things the European Union funds, from chip manufacture, HPC and many other project from large to medium to small. Why have we not seen a made in Europe Laptop/Desktop/Phone for the bureaucrats and engineers who do things like running states and building weapons and so on.
A fair amount of EU money goes into a lot of these distributed system and internet projects. And I'm not complaining, but we are spending a lot of time trying to make our system secure from everything other then direct attack. The fireware in the new notebook doesn't seem better then in the one before, in fact worse in some way.
We have most of the software, we have most of the things needed to do these things. An Open-Source computer for Europe (and anybody) would be a real counter-point to most of the other models out there.
In such an environment a real AppStore for Open Linux desktop could actually be a really good thing.
[+] [-] xen2xen1|3 years ago|reply
[+] [-] Gigachad|3 years ago|reply
If you use the gnome Software app, it merges flatpak, dnf, and the firmware updater in one “updates” page with a single button to update it all.
[+] [-] jug|3 years ago|reply
[+] [-] eikenberry|3 years ago|reply
[+] [-] canadaduane|3 years ago|reply
https://ftp.fau.de/fosdem/2023/UA2.114%20(Baudoux)/container...
[+] [-] synergy20|3 years ago|reply
Appimage is macos flavor, it never needs your sudo to install the package, which is nice.
Flatpak is a redhat flavor(kind of), it needs sudo sometimes, but OK.
Snap is a ubuntu flavor(kind of), it is like systemd that can overtake the whole system, it can install package and even the whole system I was told, too much as a package manager for me.
I don't use Snap. Appimage is not as widely adopted as the rest two? I think Flatpak is a great middle ground.
It will be really cool if KDE and Gnome work together to build this.
[+] [-] throw_m239339|3 years ago|reply
What about appimage instead, like Krita? To me it's sounds like the best way to distribute a linux app in 202X...
Managing to make things run on Linux gives a sense of accomplissement, at the same time, I can understand why most people won't move to Linux anytime soon given all the complexity involved... or it's just me and there was an easier way to install flatpack at first place?
[+] [-] ekianjo|3 years ago|reply
Wow.
[+] [-] voakbasda|3 years ago|reply
https://news.ycombinator.com/item?id=34912760
[+] [-] gtirloni|3 years ago|reply
[+] [-] JohnFen|3 years ago|reply
I hope, if this succeeds, it turns out to be a good thing.
[+] [-] jacooper|3 years ago|reply
[+] [-] Darmody|3 years ago|reply
Smells like that old MS attitude to me.
[+] [-] coldblues|3 years ago|reply
[+] [-] dimaor|3 years ago|reply
- I don't know how to see running logs by default (if it's possible even) and it's a must when you have slow internet - sometimes it just hangs and I need to kill (probably leaving residue along the way)
hopefully my issues are my own OR it will get resolved as well.
other than that flatpak is amazing.
[+] [-] tkuraku|3 years ago|reply
[+] [-] iavaijreigje89h|3 years ago|reply
This is unacceptable. Open-source apps should always be built from source on a trusted infrastructure and ideally the builds should be reproducible. Otherwise, one of the main benefits of open-source software -- ability to verify its security -- is completely lost.
Fortunately, Flatpak != Flathub. There is also Fedora's flatpak repository and that's what I'm using. It doesn't have as many apps as Flathub, but their number is growing.
I prefer flatpaks to RPMs because of the sandboxing feature. While it's not perfect yet, I like that I can forbid most of my apps to access the network and to limit access to the filesystem and other system parts for apps that require network as much as possible. As a result, the trusted base of my system can be reduced significantly (and the base system can then use other method to confine its processes which on Fedora is SELinux).
Another benefit of Flatpak over traditional packaging systems is that it's a cross-distro package manager and the apps can be installed on any Linux distribution. Even if we end up with multiple Flatpak repositories like Flathub and Fedora Flatpaks with different approaches and philosophies, users of any Linux-based OS can then install apps from any repository they like, and OS developers can focus on the base system.
So in general I like Flatpak and I think it's a step in the right direction, but I can't say the same about Flathub. For me it's unacceptable to install anything from Flathub unless they fix their supply chain security flaws.