After having tried most (major) distros available over and over again, I decided about 2 years ago that I will just stick with Ubuntu in the future. Why is that?
- Stuff just works (better). No matter which hardware I used, Ubuntu was always the best out of the box configuration. I am getting to old to spend 2 days on setting up an obscure printer driver on arch e.g. These days I just want to be able to print as soon as I boot the first time and use my time for better things.
- It's polished. It just has the best desktop experience of all distros. The fonts look good. The theme does not look like a mess of things jumbled together.
- Most software is available in the repos or you can download a .deb package or use PPAs. The rest I can as usual just build myself.
The only "downside" for me is that it is not a rolling release.
I removed snap after a very short time because I hate it's while also. It's easy to get around the requirement for snap by repackaging them in .deb packages. Just install the snap a vm, find apt packages that provide the deps you need (examine the snap, use ldd/strace). Once they're added to the DEBIAN/control, build. If specific versions are required and aren't available in apt, bundle them and set an LD_LIBRARY_PATH. Use strace if shit still doesn't work). I'm probably not gonna bother updating those apps very often.
Fedora is pretty solid but also very much on the experimental side, like shipping Wayland as a default versions ago when half of the applications didn't work right.
I've defaulted to Ubuntu because it 'just works', every other distro I just have to spend time to do what Ubuntu does anyway.
I've read again and again (on here, of all places) that snap packages are _great_ for server administration, but I feel like production machines are a place where you wouldn't want a random assortment of packages updating. I can hear the sysadmins scream already, from here.
With the fact that Snap (and Flatpak) package releases are often delayed due to whatever vetting needs to take place (plus packaging or rollout delays?), combined with the fact that it can and will auto-update without your approval, even if you've told it otherwise, it sounds like the worst of both worlds.
For what its worth, Pop!_OS also doesn't use snap... and of all things, the reason why I switched from Ubuntu 20.04 to Pop!_OS was because the calculator took five seconds to load (of course, being a snap package) on Ubuntu, and milliseconds, on Pop, as it should.
This behavior is easy to rationalize if you think of it as a business decision. Canonical is happy to sell you an "enterprise edition" app store (a so-called "brand store") that restores full control of app updates. See https://core.docs.ubuntu.com/en/guides/go-to-production/adva....
The best practices I’m familiar generally have immutable things (images, containers), with new versions deployed continuously (with a build & validation pipeline). In-place upgrade just adds new failure dimensions, let alone automatic in-place upgrade.
As soon as possible I moved away from lxd which is a shame. It met my needs better and was easier to manage than k3s which replaced it. Unfortunately as long as it is only available as a snap it is a non-starter for my lab. I don't see how it could possibly be considered for a real deployment.
You used to get LXD over APT but they changed it and now you can't.
Well there's an APT package, but it simply tells Snap to install using Snap. You can do the latter yourself and get the same result either way.
Most of my servers use LXD for containers, and started doing so when it was over APT like any other package.
Then it was like a much improved LXC, and pretty nice. Things "just worked".
It's just as well it's like an improved LXC, because the commands are both "lxc" -- to maximise confusion! I need both old-style LXC and new-style LXD-pretending-to-be-LXC installed at the same time, because some LXC container images fail to run under LXD.
The change to forcing Snap is literally the only use of Snap on my host servers now. It's annoying and disconcerting. I'm still not sure if it will auto-update or not, and I daren't find out by switching to the current version of LXD. I'm sticking with an old version, which seems safer!
I could study Snap and get to know it, but that seems silly given I don't use it for anything else.
It's also annoying because of the mount points and data isolation inside Snaps, which I've basically had to workaround. I appreciate the benefits of container isolation, of course, but it did require some bind-mounting to accomodate my existing images and configurations.
In due course I expect I will switch out LXD for Kubernetes. That will be a pain, because K8s/Docker are not optimised for running distro images, but I don't think the pain will be any worse than trying to obtain certainty about LXD+Snap's evolving behaviour, and daily familiarity with K8s has far higher market value.
Which is a shame, because LXC and LXD are great technologies, and the various packaging and relevance issues have made even old-style LXC something to move away from.
But after upgrading to 20.04, and fighting with Snap slowdowns, and yet another change in desktop direction, the weird data sharing of searches with Amazon, and weird power management problems on hardware that had previously "Just Worked", I just had had enough. I switched to Mint a month ago, and haven't look back.
I love how Ubuntu has brought Linux into the (somewhat) mainstream, but I'm just over how much it keeps changing direction, and releasing things before they're ready.
That's simply not true. It was there until earlier this year[0].
Regardless, even if it had been removed years ago. It wouldn't have made any difference to my remarks or decision. It's just one more straw on the proverbial camel's back.
[0] https://www.omgubuntu.co.uk/2020/01/ubuntu-removes-the-amazo...
Snap versions also can be reverted.... it is annoying, but the article is a bit overdramatic, since it's not a secret..
RocketChat has this issue to. They work around that by delaying the snap release for weeks. And they also provide different update channels.
... and what if you revert a package, and a new version gets published, will it pull the rug out from under you and update again?
It's not snap that broke the IDE/Workflow. The author decided to use an install method that auto updates and the authors of the plugins didn't checked compatibility with the latest version.
This is more of a lesson of "don't auto update important tools" than "snap bad".
sudo snap revert hugo
will revert the hugo snap to the last version.
He is right that you have (almost) no control over snap updates. The snap will be refreshed if a new version after the latest is published according to the docs.
https://snapcraft.io/docs/getting-started#heading--revert
I am a little disappointed in this. I expected to be able to pin a software version or at least be able to access a lot more than the very last version of a snap. A lot of software publishers (both proprietary and open source) like to break compatibility with plugins that would break your workflow. You may be waiting a while for your plugins to update (or you give up on your plugins once other plugins show up or the new version has matured enough for you to move over).
A quick search of Flatpak shows that you can revert an older version and have more options to choose from.
https://unix.stackexchange.com/questions/552688/is-it-possib...
Also, Flatpak's 'mask' command may allow you to pin a version?
https://github.com/flatpak/flatpak/issues/3078
Perhaps someone familiar with Flatpak can chime on it. Last I used it Atom was still popular.
Manjaro is the only distro that was stable enough to keep running without fail. Been running it for 2 years now. One of the best things it has over Ubuntu is the ease of installing software. No more hunting down keys or PPAs.
