Well, things like the fact that snap is supposed to be a distro-agnostic packaging method despite being only truly supported on Ubuntu is annoying. The fact that its locked to the Canonical store is annoying. The fact that it requires a system daemon to function is annoying.
My main gripes with it stem from my job though, since at the university where I work snap has been an absolute travesty;It overflows the mount table on multi-user systems.It slows down startup a ridiculous amount even if barely any snaps are installed.It can't run user applications if your home drive is mounted over NFS with safe mount options.It has no way to disable automatic updates during change critical times - like exams.
There's plenty more issues we've had with it, but those are the main ones that keep causing us issues.Notably Flatpak doesn't have any of the listed issues, and it also supports both shared installations as well as internal repos, where we can put licensed or bulky software for courses - something which snap can't support due to the centralized store design.
I'm currently sitting with an Aura 15 Gen 2, and I'm definitely happy with it.I do wish they'd get their firmware onto LVFS, but that's about my main complaint.
He won't be allowed to perform at Eurovision with the Windows 95 name/trademark/logo, so it would be hilarious if he switches to a name like Linuxman during it.
The built-in Firefox support is only activated for unstable builds, so you can't enable it on stable unless you manually enable it during compile-time.
You could also just run IMAP/JMAP/SMTP as separate components, I can't see any place in the Stalwart documentation - or in the Docker image itself - where monolith is the only option.
I haven't tested the setup myself yet, but me and another root are planning on testing a setup of Stalwart to replace a semi-broken IMAP/JMAP setup for a computer club, keeping the SMTP as is.
I personally use ~/.bin for my own symlinks, though I also use the user-specific installation instead of the system-wide one.I wouldn't guarantee that any automation handles ~/.local/bin or ~/.bin either, that would depend entirely on the distribution. In my case I've added both to PATH manually.
Flatpak already creates executable wrappers for all applications as part of regular installs, though they're by default named as the full package name.
For when inkscape has been installed into the system-wide Flatpak installation, you could simply symlink it like; ln -s /var/lib/flatpak/exports/bin/org.inkscape.Inkscape /usr/local/bin/inkscape
For the user-local installation, the exported runnable is in ~/.local/share/flatpak/exports/bin instead.
The official binhost project has been an experimental thing until now, I've personally been using it for the year on multiple machines, but it's not been something that you can just enable. And it's definitely not been something that's come pre-prepared in the stage 3.
Reading the Dockerfile in their repo, it's simply a clean debian:slim with four compiled rust binaries placed into it. There's no services, no supervisord, nothing except the mail server binaries themselves.
Flatpak uses OSTree - a git-like system for storing and transferring binary data (commonly referred to as 'blobs'), and that system works by addressing such blobs by hashes of their content, using Linux hardlinks (multiple inodes all referring to the same disk blocks) to refer to the same data everywhere it's used.
So basically, whenever Flatpak tells OSTree to download something, it will only ever store only copy of that same object (.so-file, binary, font, etc), regardless of how many times it's used by applications across the install.Note that this only happens internally in the OSTree repo - i.e. /var/lib/flatpak or ~/.local/share/flatpak, so if you have multiple separate Flatpak installations on your system then they can't automagically de-duplicate data between each other.
A lot of that data doesn't actually exist, ostree hardlinks data blobs internally, so the actual size on disk is much smaller than most disk usage tools will show.
People love to complain about CMake, often with valid complaints as well. But it - to this day - remains the only build system where I'll actually trust a project when they say they are cross-platform.
Being the Windows maintainer for OpenMW, it used to be absolute hell back a decade and half ago when an indirect dependency changed - and used something like SCons or Premake while claiming to be "cross-platform", used to be that I had to write my own build solutions for Windows since it was all hardcoded against Linux paths and libraries.
CMake might not be the coolest, most hip, build system, but it delivers on actually letting you build your software regardless of platform. So it remains my go-to for whenever I need to actually build something that's supposed to be used.For personal things I still often hack together a couple of Makefiles though, it's just a lot faster to do.
Well, things like the fact that snap is supposed to be a distro-agnostic packaging method despite being only truly supported on Ubuntu is annoying. The fact that its locked to the Canonical store is annoying. The fact that it requires a system daemon to function is annoying.
My main gripes with it stem from my job though, since at the university where I work snap has been an absolute travesty;It overflows the mount table on multi-user systems.It slows down startup a ridiculous amount even if barely any snaps are installed.It can't run user applications if your home drive is mounted over NFS with safe mount options.It has no way to disable automatic updates during change critical times - like exams.
There's plenty more issues we've had with it, but those are the main ones that keep causing us issues.Notably Flatpak doesn't have any of the listed issues, and it also supports both shared installations as well as internal repos, where we can put licensed or bulky software for courses - something which snap can't support due to the centralized store design.