New to Obsidian. I have installed it on my Ubuntu laptop using snap and it ran first time from the menu. I created a couple of pages with links and then stopped Obsidian. I decided to go back into it and it now does not start (I even waited 5 minutes).
I tried it from the command line, no errors or messages to indicate a problem. I removed it using snap and reinstalled and it started again and I could load my files. Stopped it and again and it won’t start.
Any ideas?
uname -a output: Linux nero 6.8.0-51-generic #52-Ubuntu SMP PREEMPT_DYNAMIC Thu Dec 5 13:09:44 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Why want snap if there are deb package and even appimage versions.
I never understood why to install snap and flatpak if there are perfectly available normal install possibilities.
Then if you can write on the command line, you cannot search the forum?
I can try and install via an image but why so hostile to snap install?
Also I did search the forum and didn’t find any similar issues which i why I post my issue.
So I’ve installed flatpak via the Software app (do a lot of command line so never thought of searching here). Seems to start properly every time so not sure what was wrong with the snap install.
I can think of a few reasons someone would want to install the snap/flatpak version of Obsidian even if a “native” .deb package exists:
A) The Snapcraft version can be automatically updated to use a newer Electron launcher in the event that OTA updates aren’t sufficient
B) The snap/flatpak version can be safely installed/removed without affecting system files in /usr, and they run with some level of application sandboxing. The .deb package (and .deb packages in general) doesn’t have these protections built-in.
C) AppImages have relatively poor system integration since they’re designed to function like self-contained bundles as opposed to installable packages. There are helper tools that exist to help with this use case, but they’re not well supported.
D) The flatpak has aarch64 support, while the .deb doesn’t.
I know about Arch Linux not running on debian.
As for sandboxing, it seems to me that it is the exact reason why problems in the past happened for users, not just with plugins but the software itself.
aarch64 refers to the CPU architecture (in this case, 64-bit ARM), not a distribution like Arch Linux.
If you’re using Debian on ARM for something like a Raspberry Pi or an ARM laptop, then your options within the Obsidian releases page are going to be limited to files ending in -arm64.AppImage or -arm64.tar.gz:
Alternatively, the flatpak can be installed through one command regardless of CPU architecture since it has multi-arch build support.
As for sandboxing, it seems to me that it is the exact reason why problems in the past happened for users, not just with plugins but the software itself.
There are a multitude of technical issues that Obsidian users have had to deal with.
Several distributions like Ubuntu have broken FUSE support several times, impacting AppImage users. Many users have also encountered problems with outdated GPUCache files lingering after a launcher update, causing graphical bugs.
Obsidian being an app with an extensive plugin ecosystem also has to deal with any number of support files that have to exist on the host system to work correctly, such as the Git plugin needing a git binary.
It is true that the sandbox can exacerbate plugin-related issues since the sandbox often prevents arbitrary system file access, but conversely that doesn’t mean that these support files can’t be built to run within the sandbox. The flatpak for example builds various support files to ensure common plugins can work:
It even includes some fixes to work around bugs that affect Obsidian in general, like cleaning up GPUCache files:
The Flathub site says that its flatpak version is verified by obsidian.md. I’m assuming this means it’s supported by Obsidian proper. Am I missing something? I am new to using flatpaks.
It is true my recollection with flatpak issues might not have been updated, but all I’ve seen from WhiteNoise in the Bug Report section in the past that Obsidian didn’t take bug reports for flatpak. For example:
It’s certainly good if FlatHub ironed out the kinks in the meantime.
Having said that and considering what came above, I don’t see how I’d take on a liability with a minimal setup for Linux, especially if one of the most popular plugins (starred 7.2k times), to do with sync doesn’t seem to work with it:
Even though the flatpak isn’t officially supported by the Obsidian developers, it’s still a community-maintained package that has their approval for fulfilling the app verification process:
The Obsidian developers reserve the right to not investigate downstream packaging bugs. That’s why the flatpak issue tracker mentions triaging bugs first to determine whether a bug is downstream-related or affects Obsidian in general:
If a plugin developer or a plugin user encounters a plugin issue with the Obsidian flatpak, then I strongly urge them to file an issue. Once an issue is fixed within the flatpak, it makes the Obsidian experience better for users regardless of the distribution. In the git plugin’s case, I’ve fixed multiple issues over the years to make the plugin work better OOTB so that system file access isn’t necessary in most cases:
So basically, as with all things, the less capable user is at the mercy of the more capable (who will go and file the issue).
Which leads me to ask: is the less capable user advised to install via these package managers, take on all the hassle of what comes with using these package managers, while they can download the .deb package (and I suspect most Linux users are not on Arch but on a flavour of Ubuntu) and even install with Synaptic, if they don’t want to learn any terminal?
I am only the one loving me some deb?
I admit that if the auto-update comes electron updates as well, that’s a plus.
And I am pretty sure many users don’t even know what Electron is exactly (present writer – me – included), so that’s a weight off their shoulders, granted.
What the majority also doesn’t know what the aforementioned git is. They think it’s for “sync”. I think about 90-95 percent of the 7.2k likers of Git is actually handy with git, the rest is just getting their toes wet and I think that at least another 10k (50k?) users are using it without liking it or having a GH account.
So basically, as with all things, the less capable user is at the mercy of the more capable (who will go and file the issue).
Most forms of community feedback have a barrier of entry, and filing an issue in the right place admittedly requires some technical skill. At least there’s a forum and a Discord support channel to make this process more accessible.
My goal as a maintainer is to make apps like Obsidian work well across various distributions to such a degree that key details like what Electron version is used and what support libraries are available become practically invisible to the user. There will likely never be a point where the work is truly finished, but I’m content with being part of the journey.
So far the flatpak with the years of accumulated enhancements seems to be robust enough to such a degree that it usually doesn’t get more than a one or two issues filed per month. I think that’s an acceptable rate for an application that’s had 1.1 million unique installs since November 2020 at the time of this writing:
Which leads me to ask: is the less capable user advised to install via these package managers, take on all the hassle of what comes with using these package managers, while they can download the .deb package (and I suspect most Linux users are not on Arch but on a flavour of Ubuntu) and even install with Synaptic, if they don’t want to learn any terminal?
I am only the one loving me some deb?
I think this goes back to the earlier point about user preference. Sometimes users might prefer the added QoL fixes that aren’t present in other packages, or they may want some additional features like a configurable sandbox. Also, some Ubuntu derivatives like Linux Mint even enable (verified) Flatpaks OOTB so they can install Obsidian directly from the software store, making it easier to discover than the .deb version:
Flatpak is great because it runs in a sandbox, also their libs can differ from system installed libs. In other words, you avoid messing around with the stability and security of your system.
The only disadvantage of Flatpak is they don’t integrate with the gpu. High performance tasks like 3d rendering or high def raw photo development is not possible with a flatpak app.
Flatpak is a great standard, IMO the best on Linux. Once you’ve required runtime components, flatpak apps shrink to reasonable download sizes.
Go with flatpak!
The only disadvantage of Flatpak is they don’t integrate with the gpu. High performance tasks like 3d rendering or high def raw photo development is not possible with a flatpak app.
This is sorta correct, but needs context. Flatpak has a lot of plumbing in place to make sure GPU-intensive workloads are possible. The Freedesktop runtime includes Mesa drivers needed for using OpenGL/Vulkan/EGL on Intel/AMD/Nvidia GPUs
If a proprietary Nvidia kernel driver is detected on the host, then it’ll try to install a matching version of the userspace libraries to ensure that driver can be leveraged:
These are all prerequisites for getting modern apps like Obsidian to run with hardware acceleration within the flatpak environment, not to mention run entire games through the Steam flatpak.
Even hardware decoding within flatpak works fairly well these days, enabling web browsers and video players to efficiently play video using APIs like vaapi.
One anecdote in particular – I’ve been using the Blender flatpak so I can broaden my creative skills. It works about as well as you’d expect for a 3D modeling app on a laptop having Intel graphics.
It is true that leveraging GPUs for compute is still tricky business. GPU compute within flatpak isn’t impossible, but right now it only works within a few circumstances. Supporting it comprehensively across the various GPU vendors within the runtime and through the sandbox requires a lot of work, and is an evolving story:
Jstone,
Thanks for expanding and adding context on how flatpaks integrate with drivers.
From my previous experience, some flatpak were not optimized for high-demanding GPU operations. The reasons are to search in my case, in Amd drivers and on the ability of the developer/ package team to know literally everything about GPU integration, usually such in-depth knowledge isn’t needed for apps rendering “common” graphical elements, like displaying an app GUI and some more features, I guess, like the graph view in case of Obsidian.
Flatpaks need to download the right driver automatically to integrate well with the GPU and usually they do, because looking for the right drivers online can be misleading and time consuming, especially for newcomers, by all kinds of varied opinions and gpu specific tutorials online.
What I found at the time, 2 years ago, was some few tutorials with layman instructions how to download drivers from Amd itself and install older versions of blender. Red flag for me, bc I didn’t want to experiment around with software in the hope, everything would fit automagically, not to talk about side effects.
I didn’t follow this path and finally decided to install the deb version; without further ado I was able to installed the latest versions of blender plus some driver components already available from my official download repo.
A similar case was Darktable. I had to ask for help to get the right package, as newcomer, but for the drivers I had to find the components myself, again, luckily the right components were available from my official download repo.
One exception is Lutris, the only flatpak app, which integrated perfectly with the GPU, from the very beginning. A seamless integration between apps and GPU drivers is for sure a very hard task for developers.
Since blender etc works for me, I didn’t follow anymore latest developments of Flatpak, but I’m very confident flatpaks will tackle this issue sooner or later as well.
To all the developers involved in this task, they’ve my respect, to do this incredible work and I mean it literally! A very big thanks to all this people!
What I found at the time, 2 years ago, was some few tutorials with layman instructions how to download drivers from Amd itself and install older versions of blender. Red flag for me, bc I didn’t want to experiment around with software in the hope, everything would fit automagically, not to talk about side effects.
This is consistent with my experience with AMD GPUs as well. I have found AMD’s ROCm stack to have poor compatibility outside of LTS distributions:
Since running OpenCL workloads with the open source driver stack is still poorly supported, AMD developers themselves recommend using their proprietary AMDGPU-Pro driver:
- customers using slower moving enterprise/LTS distros which do not automatically pick up the latest graphics drivers - we offer them both open source and proprietary/workstation options
- customers using workstation apps who need the extra performance/certification from a workstation-oriented driver (although Marek has done a lot of great work over the last year to improve Mesa performance on workstation apps)
In general there is a big overlap between those groups.
The third target audience is customers looking for ready-to-go OpenCL, either for use with the packaged open/closed drivers or with the upstream-based stack in a recent distro.
It’s not necessarily flatpak’s fault that a GPU vendor has very specific requirements to get their GPGPU stack to work correctly, but it still presents a technical challenge that inevitably leads to frustration for media production users who want to fully leverage the capabilities of their GPU without being required to limit themselves to a handful of LTS distributions.
To this day, getting a popular VFX app like DaVinci Resolve installed with GPU acceleration working correctly is still a big hurdle on Linux. I’m hoping that flatpak will eventually make it just work:
