Just 2 days ago, I was also discussing about flatpak in discord.
@ htuy nice explanation.
Hope it comes soon.
1 Like
I get that we Linux users tend to be opinionated, but please try to keep the discussion focused on the feature request.
1 Like
I apologize, I’ll disengage from this conversation above and stay on-topic.
I hope all the flagged posts stay.
From my uninvolved point of view, as a low commitment Linux user since the 90s (mostly in Windows atm), they encapsulate much about current circumstances across the communities.
Informative to outsiders. Nothing wrong with disagreement reasonably expressed.
1 Like
I would love to see a flatpack release, but understand why the initial setup required to provide it might make it a longer-term thing.
Hey everyone, creator of the experimental Obsidian Flatpak manifest here. I’d be quite happy if the Obsidian developers decided to release Flatpak builds!
One of the things I personally like about Flatpak is that there’s a lot of flexibility in how you can configure a build. It could be submitted to a centralized, community-maintained repository like Flathub which improves discoverability and ensures updates are handled in one place. This is a model which should be familiar to Linux users who’re used to the package management model seen in most distributions.
Flatpak builds could also be distributed as standalone packages if desired, similar to AppImage. For example, the Basemark GPU team has taken the liberty of self-hosting builds for their benchmarking tool as well as submitting it to Flathub:
Speaking as a developer, I really appreciate the design around containers since dependencies are handled in a truly cross-distro way. By building and running applications in a containerized fashion, the host operating system is no longer a factor. This containerized approach can work in harmony with many CI systems, not dissimilar to Docker/podman. This is in contrast with AppImage where developers have to make assumptions about libraries that would be installed on most distributions.
Getting AppImage to run at all on niche distros like Alpine Linux is still an ongoing task, and there are some fundamental limitations with the current AppImage implementation where the AppImage runtime needs to be dynamically-linked to glibc and FUSE. This really hinders AppImage’s potential as a cross-distro format, and might not be fixed so long as there’s a hard dependency on FUSE. Flatpak on the other hand doesn’t have this limitation – by running everything inside a container, developers no longer have to worry about whether the host is glibc-based or musl-based, has FUSE support, or has libraries designed with static-linking in mind (among other edge cases).
It’s a breath of fresh air that developers can say that they support Desktop Linux instead of having to specifically say Ubuntu, Fedora, openSUSE, Arch, etc. Upstream developers no longer have to maintain packages for specific distribution releases, so download pages can look like this:
https://www.flathub.org/apps/details/org.clementine_player.Clementine
Instead of this:
https://www.clementine-player.org/downloads
I think something that cannot be understated is the amount of inertia Flatpak has gained already. Gnome and KDE – two of the most prolific desktop environments – have integrated Flatpak support for some time now, and many popular desktop distributions including Fedora, Mint Linux, Pop!_OS, elementary OS, and OpenSUSE have enabled support. A lot of work has been done in the past few years to provide seamless integration of desktop shortcuts, mimetype associations, updates, etc, so it can complement distribution package managers without actually being tied to a specific distribution.
Here is an example comparing the UX for AppImage and Flatpak install methods in Gnome Shell:
While troubleshooting the issue in the first screenshot is trivial for experienced users, I think it’s fair to say that it’s not a great first impression for anyone just testing an application on Linux in 2020.
One might be asking – can’t Linux users put in the work to manage applications their own way like they’ve been doing since the 90s? My answer – We don’t have to anymore! We have the technology to bring application management to the same level of convenience that Windows and macOS users have been benefitting from for a long time!
A lot of progress has happened in the past several decades for advancing the state-of-the-art in application deployment on the Linux desktop – in the beginning binaries were distributed as tarballs, then came along .sh/.run/.bin self-extracting files, after that came AppImage, and now it seems like the community is putting work into supporting Flatpak as the latest standard in desktop application management so upstream developers can deploy applications directly to users with as little effort as possible.
If any of the developers have any interest in learning more about Flatpak, then feel free to reach out to me!
6 Likes
First visit to the community here. And first thing I’m looking for is Flatpak support. Thanks for the feature request. Hope this comes soon.
1 Like
Hey again everyone! I’ve went ahead with creating a pull request on Flathub:
Anyone curious to try testing this build shouldn’t need to run more than:
git clone --branch=md.obsidian.Obsidian https://github.com/joshua-stone/flathub
cd flathub
flatpak-builder --install --user --install-deps-from=flathub --force-clean _build md.obsidian.Obsidian.yml
flatpak run md.obsidian.Obsidian
@Licat @argentum As mentioned in this document, app submissions generally should involve reaching out to upstream developers:
Please let me know if you’d be interested in maintaining an Obsidian build on Flathub, or if there are any questions you may have.
4 Likes
The pull request has been merged and Obsidian is now available on flathub.
Thanks to @jstone for doing the heavy-lifting and @Licat for actively participating in this discussion.
Amazing! it was perfect on my system (I use Pop! _OS 20.04).
In the Snap version, nautilus’ GTK theme was bugged when it was necessary to create or open a Vault, the launch took longer and had to run a command on the terminal to install.
In the AppImage version, the application launch was fast, however, the obsidian icon did not appear in the gnome menu and needed the AppImageLauncher to integrate Obsidian into the system.
With this flatpak version I don’t have these problems, it made it a lot easier.
1 Like
Thank you, thank you, thank you! This makes thinks so much easier.
I thought I’d let the Flatpak prove me wrong and installed it.
On the 0.9.4 flatpak build, I can’t delete folders. Anybody else seeing this problem?
1 Like
@justdanyul There are some potential causes of this behavior. Electron apparently has some questionable ways of handling trash across different desktops. I don’t believe it’s a flatpak issue per se, more like the concept of “system trash” isn’t well-defined on Linux and projects like Electron have to hack their own implementations around it, which then might not even behave as expected when run in an environment that has strict permissions checks like in the case of flatpak.
This particular bug can at least be worked around – set Deleted files to Move to Obsidian trash (.trash folder) like so:
The Obsidian devs may eventually add a global option for default trash behavior, but in the meantime I’ve written a workaround that runs every time Obsidian launches.
All you need to do to update and restart Obsidian:
$ flatpak update md.obsidian.Obsidian --assumeyes
$ flatpak run md.obsidian.Obsidian
I hope that helps!
2 Likes
I’ll start an informal bug tracker here just to keep notes on fixed and current flatpak-specific bugs. The bugs are listed in chronological order. If you see frequent updates to this flatpak, this is why. Flatpak uses delta updates so only a tiny bit of data is downloaded on these bugfix updates.
Current:
Fixed:
-
Audio recorder plugin reports “No microphone is connected” commit
- PulseAudio access is now allowed by default
-
Cannot access files on removable drives commit
- The sandbox is now configured to allow access to
/mnt,/mediaand/run/mediaby default.
- The sandbox is now configured to allow access to
-
Trash doesn’t work commit
- Workaround has been added to automatically set trash behavior to use the local .trash folder instead of system trash. Obsidian doesn’t have a global trash preference so we check each vault on startup and set the trash behavior to local. If you have created a new vault, please either go to Settings -> File -> Deleted files and set this to “Move to Obsidian trash”, or simply restart Obsidian.
-
“Open in default app” and “Show in folder” options in the context menu doesn’t work commit
- Electron relies on
xdg-openfor these operations, thexdg-utilsin the current freedesktop runtime is way too old and doesn’t contain necessary bugfixes required to make this work. The latest version offlatpak-xdg-utilsis now bundled as a workaround.
- Electron relies on
2 Likes
Can anyone help? I have no idea what I am doing but as you can see from the screenshot I am trying to get this going. I have a 32bit Chromebook ACER (new)
I have followed the instructions from flatpak but doesn’t seem to work.
Many thanks
Chris
@Chris789 You have to make sure flatpak is installed and Flathub is configured for your system before you can install Obsidian. The official ChromeOS instructions are found here:
Or more concisely,
$ sudo apt install flatpak
$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
$ flatpak install md.obsidian.Obsidian
Let me know if you need any more help!
@htuy @jstone Does it make sense to keep the full thread here? Or should we split the “bug tracker” onto a separate topic?
@argentum I think it’d be sensible to put the bug tracker into its own thread when the original request – “Linux packaging: ship as flatpak on flathub” – has been fulfilled, and more bugs will inevitably be reported.
1 Like
Thank you for this, I never liked appimages. 