The linux release should be a deb+rpm, snap, appimage, or flatpak for proper installation and integration.
I disagree. I like it this way. I hate having to have overlying software. I really like how they prepackage everything in a 7z so I can keep it modular.
I am not sure, if this is supposed be here. But I downloaded trilium-linux-x64-0.27.3.7z for my Ubuntu18.04 device. But don't know how to start the application after unzipping the 7z file. Also, is there a specific folder where I should be unzipping the files?
You can unzip wherever you want. Archiv contains trilium-linux-x64 directory which contains "trilium" executable, so just run that. I should add some more details on this, I agree.
It would be better if standard Linux compression was used. While I appreciate the few bytes saved, a non-standard file format hurts adoption.
0.28 actually started using .tar.xz for linux builds which should be standard enough ...

Seems to have trouble installing the tarball. Any tips? The trilium file within the tarball isn't executable, not even after chmod +x.
But it's just a tarball, there's no installation. You should use standard tar xf instead of pacman.
The trilium file within the tarball isn't executable, not even after chmod +x.
What does it say?
After I unpack with tar on my system, then trilium file is executable - no chmod necessary.
Providing an AppImage would have, among others, these advantages:
appimaged--appimage-extract parameterHere is an overview of projects that are already distributing upstream-provided, official AppImages.
If you have questions, AppImage developers are on #AppImage on irc.freenode.net.
Im new to linux, i downloaded the trilium and extract to home, when i open trilium isnt executable, what to do, when i ckick properties it says is a "application/x-sharedlib"... how do i run this?
Im using Linux Mint 19
@pitxica you can do chmod 777 trilium to make it executable. I'll have to research why it sometimes doesn't show up as executable after unpacking ...
Please DO NOT put an AppImage into another archive like a .zip or .tar.gz. While it may be tempting to avoid users having to set permission, this breaks desktop integration with the optional appimaged daemon, among other things. Besides, the beauty of the AppImage format is that you never need to unpack anything. Furthermore, packing an AppImage into some form of archive prevents the AppImage from being added to the central catalog of available AppImages at https://github.com/AppImage/AppImageHub.
Reference:
https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages#common-mistake
@probonopd there's no AppImage. This is about binaries packed into .tar.xz
It might be better to move any further conversation about AppImage into specific issue ...
@zadam this command didnt change anything, whe i click the program ask me to choose a program to open the archive, what should i choose?
snap package would be appreciated for sure
Closing as this is too all-encompassing, better to handle this in individual issues. Currently linux packages are available as .tar.xz or .deb
Most helpful comment
Providing an AppImage would have, among others, these advantages:
appimaged--appimage-extractparameterHere is an overview of projects that are already distributing upstream-provided, official AppImages.
If you have questions, AppImage developers are on #AppImage on irc.freenode.net.