- Installation (no manually moving files from ~/Downloads)
- Launcher integration (no writing .desktop files by hand)
- Auto updating
As far as I saw, AppImage didn't have any of that. Though it was a while ago (and maybe some of this was my distro's fault). Has any of this improved lately?
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.
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.
Commercial software would like a comprehensive and relatively stable API like what Windows famously provides. Flatpak's analog of the Windows API is the runtime. What level and duration of maintenance do Flatpak runtimes typically receive?
https://developers.redhat.com/blog/2020/08/12/introducing-th...
Well yes, these are all closed source binaries. In terms of usage it's not all that different to running them in a VM. In the bad old days we just did it in an XP windows VM instead.
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.
It will depend how an app has been packaged, but when well done the sandboxing is invisible.
I think the only issue I ever had with them was the inability to inject files inside. Do you know if that's possible?
I was trying to use a browser, I think Vivaldi, that had instructions for enabling widevine by copying a file to a certain directory, but I couldn't find a clean way to do so.
They make so much sense and work so well. I feel like the people who dislike them either never actually used them, or they’re just the type of person who hates change and will never be happy with new things.
Last I checked Flathub shipped with VSCode and IntelliJ, despite both having major broken parts. The VSCode workaround back when I tried Silverblue was to run sshd inside toolbox and remote Flatpak VSCode into it. It was definitely not a frictionless experience. And IntelliJ having the terminal and debugging broken removes most of the useful parts of the IDE for me.
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.
I'm using a very minimal system without a lot of the easy to implement features on purpose, but absolutely can not live without some of the more difficult ones. So for me the adherence would be cherry-picked parts from 3, 4 and 5 and impossible to place on a chart. I don't think it would be a good fit for the modular unix philosophy.
[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
[2] https://specifications.freedesktop.org/basedir-spec/basedir-...
I used to be on this hill. All this leads to is inoperable software where each integration point is liable to break. I want to get away from the spyware that is Windows, the walled garden that is MacOS. If a uni-desktop is the price we pay, so be it.
And it's gotten better too - did you know KDE3 had it's own sound mixer daemon? It was called ArtsD. Now we have pulseaudio, or whatever, which is great and cross desktop
DBUS made it everywhere as well - I believe initially KDE3 as well did not have DBUS but had something called, DCOP. so - yeah things have improved a lot and many things - even command line tools 'playerctl' interop well based on this.
More fun is also like libreoffice is compiled with many different file pickers, so on KDE you can use the native Qt extended KDE file picker, and on Gnome you get the GTK one.
What's the difference? If everything works perfectly with everything else, and the standards adherence is so high that you can't tell the difference which apps are from which organization, then how is that not a "unified DE"?
No thanks. GNOME dev hubris is the reason I use KDE
Personal example from trying GNOME out recently: I have an external webcam, which means I need to move the GNOME panel clock since it's in the top middle of the screen (and thus blocked by the base of the webcam). You would _think_ that would be easy, but you have to get an extension just to move the clock! Apparently each panel "widget" (this may or may not be the official term) defines its own position on the panel. So, to move something, you need to either find an extension that does it (Frippery Move Clock[0] in this case) or edit the widget code yourself.
Maybe someone can chime in with a technical explanation, but my cynical take is that the GNOME devs don't even trust users to be smart enough to customize their own panel without breaking things.
</vent>
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.
The problem with this is that Mac, unlike Gnome, actually works. Gnome just has weird holes where old functionality was removed (like application menus!) and never replaced.
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.
IIRC KDE committed to never break users again like they did with the first releases of KDE 4. It's expect the first releases of Plasma 6 that the distros will actually ship to be stable, and to be mostly a Qt5 → Qt 6 upgrade. You should be able to run a stable version of Plasma (5 or 6) in any case during this period. KDE 3 to 4 was a disaster; last versions of KDE 4 were rock solid. First versions of Plasma 5 were a bit lacking but rapidly became very stable and usable, and you could actually keep using KDE 4 in the meantime. I expect the Plasma 6 transition to be even smoother. I hope I'm not wrong.
But otherwise I agree, Cinnamon seems very good and I tend to recommend it and pick it for people who I install Linux for.
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.
By now, Snap is such a fundamental part of Ubuntu that it begs the question whether Ubuntu is right for you if you want to avoid it. Why not use a derivative or upstream that makes different choices?
Seriously though, just install Debian. It's not hard, the netinstaller may be text-mode but it walks you through the simple steps one by one just like Ubuntu's GUI installer. Anybody who's comfortable using Ubuntu in the first place should be able to get through the Debian installer just fine.
Ubuntu also as better hardware integration ( drivers ) and more modern kernels. AS a matter of fact it has many kernel for deferent usage.
People use Ubuntu because it works just fine out of the box, you don't need to install a third party non free drivers to get your wifi card to work. I still have nightmare with debian because they used to not ship proprietary drivers so you would have to cary a USB stick in the datacenter with drivers on it to make network cards working.
Unless I have another reason to reinstall Linux, it’s far easier to uninstall Firefox and the other handful of Snap apps and just use Flathub/flatpak exclusively. I just need to be careful I don’t pick the default store app when searching for software.
Removing Snap is not that hard, the "hardest" part is making sure that Firefox is installed from the Mozilla PPA and even that takes just a moment once you have the script saved somewhere.
By the way I had a look at some Ubuntu derivatives like PopOS or Mint and I might take the plunge at some point.
In my case, it's because my options are pretty much Ubuntu or Windows for this machine, and there's no contest there.
As for Flathub itself, it's like the Snap Store... but you aren't locked in, and the backend is open-source, and it's not directly owned by a distribution maker (even though it is definitely closer-in-kindred with the Fedora Project), which makes it far more palatable to people with even a modicum of understanding of the Linux and FOSS philosophy.
I harassed them nearly 6 years ago about this. https://forum.snapcraft.io/t/external-repositories/1760
cat << EOF > /etc/apt/preferences.d/nosnap.pref Package: snapd Pin: release a=* Pin-Priority: -10 EOF
One thing I don't do is use Flatpack, AppImage or any substitute for snap. If I wanted that functionality, I'd use snap.
I don't like apps installed via snaps (etc.) changing themselves almost seemingly stealthily.
...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.)
Although it provides its own solution to the Linux packaging problem, it's a single solution that comes with a whole load of baggage with it. It is not the panacea its proponents wants us to believe it is.
The fundamental idea is this: Every package is built in a "hermetic" environment that guarantees that the only inputs are the ones you have explicitly specified. Those inputs include tools, source files, compilers, build instructions etc., all specified by a hash. Those inputs themselves can then be packages build in this way, such that everything in your system forms a big Merkle tree.
This approach enables a number of excellent things - you get excellent build reproducibility, you can cache any step you want etc. A lot of the concerns you get with a more conventional system just go away.
People have objections to Nix(OS) - the language, the sporadic documentation, some of the design decisions made, the learning curve etc. But I think those (very reasonable) objections obscure the more interesting debate about the underlying approach and value.
All kidding aside, I installed NixOS (it installs like any other distro, it's just that after that you are completely lost), but it's a real paradigm shift.
I'm just hoping for Ubuntu Declarative Donkey at this point and hope someone addresses the learning curve and the specialist language and tools used. I'd hate to invest all this time and then all other distros finally respond and it was not really worth it after all. I mean it looks to me like one can just put a Yaml file at the heart of Ubuntu and make that work. At least as step 1. Why is there no response from the classic Linux vendors? There are atomic distro's yes (ie Fedora Silverblue), but no real NixOS-like product. I want my personal system to live in Git.
Maybe I should just use NixOS.
I think NixOS tends to be mentioned more often than others because it provides a lot of clean solutions to common problems. Especially when some people claim these common problems are unsolvable, but NixOS does offer some sort of solution (that of course comes with it's own set of tradeoffs, every solution does).
If someone says "It's impossible to run a popular website with client-side analytics" and you frequently hang out on popular websites without client-side analytics, wouldn't you share those examples to show that the person might not know about those and could further their understanding?
Package managers before nix simply didn’t solve the problem properly - they left behind garbage, couldn’t properly deal with multiple versions of the same package, etc. Easy way to check whether the package manager you have in mind is “sufficient” is to install the gnome group and the plasma group and remove them. How many orphan packages will you have as a result?
It is not a cult, people just like proper solutions to problems, and nix is unique in this regard.
* Works on all (most) distros * Builds the packages from sources, binaries are only a cache to speed things up. * Bonus: already has a lot of software packaged
And proprietary works in the system too, the build step can just download the binary from internet. It's not a preferred way to do it, but you don't have to build a broken system just because of few packages without source access
More seriously, people who run NixOS are, generally and historically, people who have a lot of experience with package management and people who choose their Linux distro based on the tooling rather than based on defaults.
The Nix approach is conservative in some wonderful ways that are likely to appeal to longtime Linux users who appreciate the strengths of old-school system package managers as well as the defect of those systems, which makes Nix people want to cry out in response to container-based package management:
> You don't have to go that far! You can have all these benefits but keep fine-grained library sharing! The choice between static and dynamic linking is a false dichotomy!
because if you love what's great about traditional package management, that's really exciting.
Rather than being a cult in itself, there's a crowd of very vocal fanboys similar to the RIIR stike force. Pestering people with "why don't you use $thing" is not good advocacy.
"the nix ecosystem is like a cult. Not because it tries to be, but because the ideas are so good you cannot deny them."
I think it kinda is, but in a good way.
It's the church of reproducible builds, which is a good cause.
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.
Also as far as I remember flatpack is something more complex than a simple package format, it has a runtime where each application runs in an isolated container where it can access only some of the resources (e.g. the filesystem). This adds to me useless complications to a system.
I think that the best approach to the integration of third party software is the one followed by ArchLinux, that is the AUR: a series of build instructions, maintained by the community, that allow you to package practically any piece of software that exists.
I guess it's mostly the kernel and my DE these days.
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.
https://www.notebooksbilliger.de/
https://www.lenovo.com/pt/pt/d/portateis-linux
https://www.skroutz.gr/c/25/laptop/f/526320/Linux.html
The problem isn't the hardware per se, rather lack of focus on a single desktop experience like the competition.
For non-technical users and app developers.
And how did you come to the conclusion that "missing high quality linux desktops" are the thing "holding back" Linux?
Is this based on some statistical work you did?
If we talk about feelings - did you ever have the feeling that corruption, lobbying and blackmailing could play a role?
BTW - why do you think Linux is missing high quality desktops? I am working with very high quality Linux desktops since many years and I wonder why people are using such low quality desktop OS that are sold commercially.
> If we talk about feelings - did you ever have the feeling that corruption, lobbying and blackmailing could play a role?
If you want to make the argument make it, I will listen.
I working with Linux desktop for decades and like it. My point is that the hardware is the bigger issue.
First, Windows caught up, Linux used to have things that windows didnt in the late 90s and early 2000s, not most linux only app have windows ports, you can run any linux app on windows WSL , and now windows also have powershell
Second, apple made a comeback, now many people who dont want windows use apple and get a unix experience if they wanted one
Third, end users shifted to tablets and mobile phone
The combination of all 3, leave little room for linux, no matter how good linux does , linux on the desktop only make sense for people who develop for linux on the server and want a similar environment on their laptop
1. https://sneak.berlin/20230115/macos-scans-your-local-files-n...
I’d be happy to pay for Linux software but there is no way I’d want to be tied to a particular distro/repo/storefront.
Smells like that old MS attitude to me.
The Azure dev tools on Linux i have tried are all Snap only, or a tar file and maybe an rpm/deb. At the moment they seem to avoid Flatpak like the plague.
As far as I'm aware, Ubuntu is still the biggest player in the consumer Linux market not counting Android. Given the need to balance upkeep costs with range of support, I can see why Microsoft chose just Ubuntu and threw the rest to the wind.
[1] https://support.endlessos.org/en/apps/flatpak [2] https://fosdem.org/2023/schedule/event/containerised_apps/ [3] https://www.codethink.co.uk/articles/2022/flathub-codethink-... [4] https://www.collabora.com/news-and-blog/blog/2017/08/17/debc... [5] https://github.com/Igalia/webkit-flatpak-sdk
You can fork the base repository and just add the packages you want to have installed on your host system. Everything else is handled with flatpaks or with distrobox containers, or you could technically install whatever else package management system you wanted to.
I think part of the problem with a lot of "selling stuff on Linux" has been mucking around with different dependencies for the thousand different versions of Linux.
Historically, this has led to a couple solutions: either a) Just officially support one distro (usually Ubuntu), or b) just don't release a Linux version.
Flatpak has actually succeeded in making a system that kind of works everywhere, and I think it actually has a shot of being an equivalent to the Mac App Store.
I do hope the command-line UX around flatpaks (installing, updating, etc) improves a lot though as currently it leaves much to be desired.
In his most recent talk he basically said, he was wrong, the Flatpak people did address most of the issue he had and AppImage was no viable.
There's far fewer applications because there's a very tiny market share compared to these two OSes. Not because of the lack of payment systems.
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.
This is kind of how immutable systems like fedora's silverblue, and suse's microos are setup.
The base systems are still built with rpm, but for user packages you either use flatpak or stuff in containers via toolbox or distrobox.
It's still possible to layer stuff on to the base image if necessary though.
It totally is! Why does a distro maintainer need to pack every known application into the OS and make sure it works? This kind of work does not scale.
Sandboxing and distro-agnostic packaging are definitely the way to go. They have some pain points but it's better to fix those than to go back to the older way of doing things.
https://ftp.fau.de/fosdem/2023/UA2.114%20(Baudoux)/container...
Erm...
> we also reduce the ability for users to scrutinise the source in the Flathub build system that was used to build their application
I don't think so
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?
AppImage solves the packaging problem in a bad way (ugh, loopback mounts), but does not solve the dependency problem, try run AppImages compiled for Ubuntu on Fedora..
AppImage is just the least bad solution - if nothing else it doesn't need some weird infrastructure to run. As a developer you just upload the binary to your site and as a user you just download the binary and run it.
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.
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.
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 hope, if this succeeds, it turns out to be a good thing.
What if I need older version of some software? Or what if I need multiple versions of the same software at once?
... Neither MacOS nor Windows do this; what are you targeting now?
The sandboxing features are documented: https://docs.flatpak.org/en/latest/sandbox-permissions.html
i like it because it actually solves problem (getting proprietary software like slack) instead of creating ones and/or getting in the way (i'm looking at you snap).
Flatpak enables people to publish a single package that just works on all distos and doesn't break every 6 months. It's removing the maintenance gatekeeping.
I think it will be interesting to see if tech like WASM results in packages which work across CPU architectures as well as Linux on ARM is very painful currently, let alone more obscure ones like RISC-V.
Anyone have the connections to make this happen?
Valve actually uses bubble wrap on the Steam deck for proton.
Off topic: An idea that came to my mind a few days ago is that would have been great to add support for desktop apps to Podman by adding some extension or plugin capabilities to it instead of creating a new whole technology. Probably a silly idea though.
Wow.
- 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.
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.
Some convergence of desktop and mobile is plausible over the midterm so it might be worthwhile to think how that could be orchestrated
We don't need yet another store. What we need is a simple registry of applications that are installed with the scripts to uninstall. We already have this, it's a package manager.
For soft that doesn't need a package manager, we have .appimage.
Instead of making it more difficult to package apps for Linux, focus on having few methods that are robustly supported.
How can application whitelisting be achieved?
Does Flathub come with any features that help with that?
If you need to tweak them, Flatseal is a great tool.
Personally, I still prefer my repos with shared libraries when possible. I'm also able to keep a mirror of the packages to cut down on bandwidth.
I haven't figured out how to mirror the flatpaks yet, mostly due to lack of effort.
I'm excited, it will be good to have a cross-distro app store.
I'd gladly donate or even keep a subscription to keep Flathub running.
as in Ray Dalio?
