

I figured I’d recommend the OG since it’s easily available from flathub, and even in maintainence mode, was likely feature complete for most needs. But cheers for mentioning TriliumNext as well, which hopefully will come to flathub as well soon!
A frog who wants the objective truth about anything and everything.
Admin of SLRPNK.net
XMPP: prodigalfrog@slrpnk.net
Matrix: @prodigalfrog:matrix.org
I figured I’d recommend the OG since it’s easily available from flathub, and even in maintainence mode, was likely feature complete for most needs. But cheers for mentioning TriliumNext as well, which hopefully will come to flathub as well soon!
Lubuntu now ships with LXQt.
Lubuntu would be fine, though personally I’d suggest the lightweight Linux Mint versions, such as Linux Mint XFCE.
Flatpak shares libraries, so there are no duplicates of the same version, though there may be duplicates of other versions, as that would ensure compatibility with the specific app.
App image does not share libraries between apps, so it would potentially have more duplicates.
Even if everyone agreed on Apt as the standard package format, wouldn’t you still need to create multiple packages for the various different versions of libraries each distro will still have depending on their release cycle? As far as I know, it can be done theoretically, but since libraries can often break ABI, it’s safer to bundle all dependencies, but then you’re not far off from an appimage in practice.
Also, what are your thoughts on Richard Brown’s (of opensuse) talk on Flatpak, who was a prominent hater of containerized apps.
Bananas Screen Sharing may one day be able to replicate that functionality, though at the moment it does not pass-through application audio (The dev mentioned they hadn’t implementet that because it’s difficult to do on Mac OS, but seems to be viable for Windows/Linux), but it does pass through the microphone.
Mint is absolutely slamming it for new users, but as a KDE user, I’m happy to have the diversity :)
In my experience, there is no noticeable dip in performance.
I’ve tried it a number of times, but never could stick with it due to how buggy it was, though the last time I tried it was about 3 or 4 years ago, so it might be in a better state today.
As someone who uses it; it really is an exceptional video editor, and IMHO is worth the hassle (which is much less of a hassle now due to DavinciBox, which the video author sadly was not aware of).
I’d heard of pixelorama a few years ago when it was released, but looking at it now, it looks like it’s come a long way, very impressive.
I think you might be confusing it with something else. Pixelorama is quite a recent app developed entirely with the Godot engine.
From a pure usability and features standpoint, if you are capable of compiling it, there is no reason to use Libresprite over aseprite.
LibreSprite’s only advantage is the GPL license and the ease of installation compared to compiling aseprite (if one does not pay)
The forks are based off an older version, and received less development compared to the OG after stopped being FOSS. A serious artist or gamedev would likely appreciate the additional features of the OG, but the forks are free, and still retain much of what made aseprite so good, making them more than adequate to learn with or any pixel art amateur.
Email and calendar: Tuta, Posteo, Mailbox.org, Disroot
Passwords: Bitwarden, KeepassXC
Drive: Filen.io
James Lee was right.
Another reason to add to the pile in favor of citizen controlled media like the fediverse.
I was actually able to find ultra high res scans of the other two! (use the arrows to hop between the three). I think these might be even higher res than the other one I posted, as all together they come to 2.5gb, where as the other scan was only 32mb.
As someone who also bounced off Manuskript for similar reasons, I think this will be right up your alley. :)
It’s main purpose is to demonstrate how Linux could function with a less unix-like file structure, in an effort to make it more intuitive to use, and to make it possible to have multiple versions of a library/package without conflict.
I personally really love what they attempted, but it’s unfortunately not been adopted anywhere else, making it unpractical to use as a daily driver.
But it serves as a very successful experiment that hopefully someday inspires change or a new way of thinking about the Linux file structure for other distros.