I’ve been at this since the late 90’s, I’ve recently went “all Lubuntu” and plan to keep i like that. Ever since Ubuntu started pushing Snap, It’s come with unneeded problems, usually due to it’s “sand-boxing” feature. But after reading this (a quote from the Linux mint site. Snap Store — Linux Mint User Guide documentation)
Centralized control
Anyone can create APT repositories and distribute software freely. Users can point to multiple repositories and define priorities. Thanks to the way APT works, if a bug isn’t fixed upstream, Debian can fix it with a patch. If Debian doesn’t, Ubuntu can. If Ubuntu doesn’t Linux Mint can. If Linux Mint doesn’t, anyone can, and not only can they fix it, they can distribute it with a PPA.
Flatpak isn’t as flexible. Still, anyone can distribute their own Flatpaks. If Flathub decides they don’t want to do this or that, anyone else can create another Flatpak repository. Flatpak itself can point to multiple sources and doesn’t depend on Flathub.
Although it is open-source, Snap on the other hand, only works with the Ubuntu Store. Nobody knows how to make a Snap Store and nobody can. The Snap client is designed to work with only one source, following a protocol which isn’t open, and using only one authentication system. Snapd is nothing on its own, it can only work with the Ubuntu Store.
This is a store we can’t audit, which contains software nobody can patch. If we can’t fix or modify software, open-source or not, it provides the same limitations as proprietary software.
Makes me wonder why anybody would want Snap in their distros?
This excerpt pretty much sums up my personal qualm about Snaps. I don’t like the idea or how it’s implemented because it has underlying implications that counter the spirit of open source. While I don’t deny the benefits that come with Snaps and Flatpaks (most are valid)—there are ways of doing it. I tend to side with Linux Mint and their favorability of Flatpaks simply for the better approach but I personally still find them both redundant to AppImages, which were supposed to be the one thing that was used as opposed to different packaging formats and whatnot… but I digress.
That being said, I don’t think it’s an easy task to do what Linux Mint has prescribed for themselves. They are a different project with different goals and resources. Lubuntu itself is a flavor of Ubuntu and still relies heavily on their base.
As much as I dislike snaps, I do still use them out of convenience because I recognize their security benefits. Also, I’m very paranoid.
Luckily for us, because Linux is pretty flexible with things, we can customize this kind of support and just remove snaps in favor of Flatpaks or just remove both.
The solution to your “problem” is to switch to Linux Mint. I mean, according to this quote, Linux Mint is the most secure distribution because it contains all the fixes from upstream, Debian, Ubuntu, and Linux Mint. And Debian seems to be a risky choice because of all the unpatched bugs.
Or you stay with Lubuntu and remove snapd. And for all the software which is originally provided as a snap, you can create your own PPA. Problems solved.
Or you create an account and start creating snaps yourself. Then you can fix, modify and patch the software to your liking. You can create your own Firefox snap and fix all the bugs, that Mozilla does not fix. If you include the patches from Mozilla, Debian, Ubuntu, Linux Mint, and your own patches, nearly nothing can go wrong. And the application is sandboxed.
And everyone else can use your Firefox snap too from the store. Nobody is forced to use the official Firefox snap from the verified Mozilla account.
It’s not surprising for Canonical to go with snap.
They have a vision for an integrated future.
And they can off-load the man hours required for testing, packaging and distribution to the snap maker. Also, snap just updated your app while you were making tea.
Personally, I’m not bothered with the security nor politics.
I just dislike snaps for it’s design, mainly the way it entrenches and interwines into your system and sits inside, continually upgrading itself and your packages, keeping several redundant copies.
I prefer to do all that stuff myself. At least I can see what I’m doing.
Can Lubuntu get away with not pre-installing Snap?
The requirement is that packages be made ‘available’.
The conundrum is if snap is not installed by default, then does this make firefox-snap ‘unavailable’ ? If so, would it break the rules of ‘Official Flavour’?
If all the other flavours are including snap, would you go ahead and not include it ? It’s a tough question.
While I love Lubuntu very much, I don’t see any drastic changes like moving Snap to an option instead of what it is now.
I’m also one that likes to do things myself, I don’t really need Snap, but I guess it’s a good idea that will attract more “Windows-like” users.
I was able to customize and remove most of Snap with 22.04, but noticed Snap is more ingrained in 22.10 and harder to deal with. I was having snap-security problems with a boot thumb drive I had made, to a point where I gave it up and went back to what I have now.
So, I guess I need to try Linux Mint again to avoid the further snap upgrades in newer distros.
22.04 is good for five years, so I got five years to think about it.
Thanks for the info, I took for granted they were all in tune with Ubuntu when it came to LTS.
I checked Mint and appears it does provide the same 5 year LTS support
Moreover, the support is only for security updates, right?
Other OS components and packages are not updated, AFAIK. So let’s say you install Dosbox or Lutris or VLC through APT, you will stay for years in that same version except for security updates, which you’ll still receive.
I’m thinking, although Lubuntu stops support, it’s still Ubuntu 22.04, so we will get the regular security updates from Ubuntu repo (might have to switch some repos), in my case, I’m hooked up to repos like WineHQ, Lutris, kisak-mesa, etc. So I would imagine support from those repos will also continue for the life of 22.04
No, this is not entirely correct. It is also possible to fix normal bugs. The details can be found at StableReleaseUpdates - Ubuntu Wiki
In the case of LXQt, this is a bit difficult, as upstream does not provide long term support for specific versions (they have only the latest version and the not-yet-released version). So the packagers have to backport fixes into the released version.
For PCs with not-new hardware, I don’t think that’d be too much of an issue. Let’s say PCs from 2013 or something like that.
Not that I have any particular interest in LTs versions, I always run the interim ones.
Yes and no. The reason for LTS versions is to have a stable version for a long time (and 3 or 5 years are a long time).
If you install 20.04 LTS you want to have a stable system not only in the year 2020 but also this year until next year. The kernel in 20.04 is not outdated, it is actively maintained by the kernel team. Sometimes the kernel receives support for new hardware and sometimes not. But you can be relatively sure, that the 20.04 kernel today behaves like it behaved two years ago.
Ubuntu has also the concept of hardware stacks. The point releases introduce newer kernel versions. You can use 20.04 with the linux-generic (5.4) or with linux-generic-hwe (5.15). Both versions are widely used in the Ubuntu community and are therefore well supported.
If you need third-party software or you need “newer” software, than maybe you should update every 6 months to the next Ubuntu release or you choose a rolling release distribution.
If you add third-party repos to your LTS system, then the question is, how stable is it? If you add Wine, then probably the community is big enough to detect and react to bugs. But if you add a PPA which is maintained by one person and tested on one device?
But this is a personal decision and I share only my point of view. It is absolutely fine, if you have a different point of view.
I would add that its more low RAM now instead of a low spec computer. Snaps have progressed where I don’t see a difference anymore if you have the memory.
