Installing software on Linux, I would always prefer installing from a software manager as it will then keep the software updated automatically, it would also share libraries, making downloads quicker.
Consequently a .deb file would be my preference.
LogSeq isn’t available in a .deb package.
I have found, in the absence of a .deb file .AppImage files are far more reliable than snaps or flatpaks.
But the last X2 iterations of LogSeq .AppImages simply don’t run. At all. And I’m not alone with this fault.
So I’m asking, how long will it be before the package is fixed?
AppImage is a security nightmare, it shouldn’t be used in production i.e. just to quickly try development builds.
.deb format is for Debian system packages, it’s not intended for distribution of third party software and it’s up to Debian project to eventually package Logseq as .deb and maintain it in its repositories.
The Freedesktop (the set of standards of GNU/Linux systems) app platform is Flatpak. Being an app platform means it’s intended for third parties to distribute their software and indeed it has a permission system called Portals and this is the minimum for security.
Snap is a format by Canonical that targets servers mainly, it’s not a community project, it uses Flatpak’s Portals too but has many downsides compared to Flatpak. For example Flatpak is designed to work with many repositories and everyone can host one, while Snap promotes Canonical’s app store.
Logseq is available on the main Flatpak repository, FlatHub, I installed it from there and I have no issues, it updates right after a new release is available.
I think you should report the issues with Flatpak because it is the right way to run third party apps on a GNU/Linux system and so we should make it works instead of switching to insecure alternatives.
1 Like
I doubt the devs want to spend a lot of time on packaging for all the different package managers Linux has. It really is up to the community or the distro to package things up in their specific flavor.
Until this is sorted out maybe this script can help: logseq nightly It’s what I used when I was on Linux, it will need some editing, but it is the most convenient way to easily upgrade Logseq.
The script is only half-done. The desktop file part was never written, sorry.
alex0 thank you so much.
No-one has been able to describe the differences to me with such clarity.
Just one question occurs to me, I’m willing to accept AppImage is a security nightmare if you say so, but how and what makes it so?
1 Like
You are welcome!
In general there are two approaches to software distribution: bundling together libraries and whatever is needed to run the software (like on Windows or MacOS) or define a tree of dependencies and use a “package manager” to make sure an application has the needed libraries provided by other packages.
The two approches have pro and con:
The former is better for compatibility because the libraries are available for sure and at the right version, tested by the developers of the application. But since vulnerabilities are often found in libraries and fixed in future versions, the con of this approach is that the app developer has to monitor new libraries’ versions, test them with their app, distribute a new version of the bundle and makes sure the user gets it.
The latter is better for security because the maintainer of the repository has to update the libraries only once for every application relying on them. Indeed this is the approach used on servers and the reason GNU/Linux distributions are so successful there. The con is compatibility, two different applications may need two different version of the same library or other conflicts like that.
AppImage uses the bundle approach and to mitigate security issues the AppImage promoters propose automated infastructures that re-build AppImage bundles when a library update is detected. But not every AppImage around is made this way and this ambiguity is an issue per se.
And even if every AppImage had automated build, there isn’t a way to ensure the user actually updates it, there may be outdated AppImages somewhere on users’ hard drives. Indeed many people use to “backup” their AppImages on various hard drives.
This means that a fix to a vulnerability in some library doesn’t propagate properly with AppImage.
Flatpak has a middleground approach, its packages are bigger than .deb but it makes sure they are updated like package managers do. And has two features to mitigate the bundles issues:
-
There are two kind of Flatpak packages, the Apps and the Platfoms. Basically instead of a big tree of dependencies there are only two levels i.e. Apps can depend on specific Platforms. Platforms have most of the libraries so that app developers target a platform and don’t have to update every library they use. Some Platforms are Freedesktop, GNOME and the KDE ones.
-
To solve the issue of compatibility, Flatpak uses a technology called OSTree that is something like a file system but that can store multiple versions of files without increasing to much the storage needed. It basically store each file and the differences to provide different versions of that file if needed.
Using OSTree means that even if two Platforms, or a Platform and a App, or two Apps, ship two different versions of a library, those files are not duplicated but stored just once plus the differences. This means a lot of saved storage compared to AppImages and simple bundles in general, while ensuring compatibility: indeed if an application needs a specific version of a library it just have to bundle it and there won’t be any conflict with the version in the target Platform.
The other important difference between AppImage and Flatpak is being sandboxed by default or not.
AppImages by default can access everying, every file in your Home folder, the Internet, the microphone, the camera and so on.
Flatpak has a system of permissions to “exit” the sandbox and access specific resources. Even with files, passing a file to a Flatpak app through a Portals means the app has access only to that file, like the file was thrown inside the sandbox through a hole called Portal.
AppImage promoters argue that Firejail can be used to sandbox AppImages but this mean the user need to know it and relying on end users for security is a defeat on the first place, since human factor is the bigger issue in security in general, so being secure today means taking into account the UX and AppImage+Firejail does not.
Some people argue that some Flatpak apps have to disable the sandbox to work. This is a temporary situation and those apps need to be updated to use Portals instead. In the meanwhile some repositories like FlatHub decided to allow apps with sandbox disabled but at least it’s made clear to the user through software centers’ UI.
So Flatpak is not just another package format, it is a third innovative way to distribute software that is different both from Windows, Mac OS, Android, iOS approach and the traditional GNU/Linux one. No other platform has something like this!
Edit: and a way to make an app accesses just one file will be available on Android 13, while we had it for years as a Flatpak Portal!
2 Likes
alex0 thank you, that’s everything I need to know++
I had had problems with Flatpaks some years ago, and so lost faith with them.
I have followed some very good and clear advise about setting up for using Flatpaks, (which I doubt I did previously 
) downloaded LogSeq flatpak and it is the newest version, and working perfectly (I had to reboot after downloading and installing, I guess that’s normal?) The first time it ran load time was quite slow, but way quicker all the subsequent times, quicker than the AppImage too.
I’ll be swapping out some other AppImage installs for Flatpaks, thanks again Alex.
1 Like
You are welcome!
I use KDE Plasma so I just needed to open Discover (the software center), search for Logseq and click “install”.
In case Flatpak or FlatHub are not available by default, Discover has a couple of handy buttons to install/enable them. Once both Flatpak and FlatHub are available, Logseq appears when searching.
I suppose it’s almost the same with GNOME Software.
2 Likes