Linux Software Managers

Topic

New Reply

With the recent paradigm shift of linux mint from ubuntu with snap packages and not being available by default in 20.04,
this got me wondering..
Currently there are three types of software package managers available in mainstream linux distros (and non-mainstream)

Appimage
Flatpack
Snap

A description of each is given in the following article with a concise summary table and explanations:
https://linuxhint.com/snap_vs_flatpak_vs_appimage/

I’ve never really taken to snap or flatpack and wondered what the concensus was for their preferred software package manager and why?

My reasoning is:
appimage is smaller in footprint and has been the longest serving software package manager
that suits my minimalist ethos on linux distro’s.

Windows - commercial by definition and now function...

1 user thanked author for this post.

DrBonzo

Reply | Quote

Replies

Those are not really package managers. Package managers are things like apt, apt-get, Synaptic, Muon, and the inferior graphical one I am stuck with in Fedora, dnfdragora. Those things you mention are alternative (cross platform) packaging formats.

I’ve never used any of them, I like the idea of being able to do away with the Linux fragmentation, and if it also has the result of mitigating the rate that some ABIs become obsolete as Linux advances, all the better. Still, several things about the whole thing bug me, although (again) I am far from knowledgeable about these.

A couple of things strike me as important in that list of relative features.

Sandboxing Mandatory: Sandboxing limits the things a program within can do (by design). If the intended tasks of the program don’t fall outside of those limits, then that’s great, but some programs need to go outside of the sandbox to work. These programs, it would appear, won’t work with Snap or Flatpak. Appimage, according to the chart, allows but does not mandate sandboxing. Advantage: Appimage.

Fully Contained Single Executable Support: Only Appimage has it, and this is a big one for me. I don’t like having to run the application itself as a parameter. Advantage: Appimage.

Automatic Updates: Need more info. One of the complaints Mint had about the Snap version of Chromium was that it updates automatically. For some of us, that is not a feature, but a flaw (not a bug, though, as it is intended). People move to Linux for a lot of reasons, but not having control over updates is not among them.

I like the way that native distro package managers handle updates… I get a notification that updates are available, I click the icon and it shows me a list of the packages that are available for update, and I can pick and choose which ones I want. Nearly always, I take them all, but not until I have read through the list and made sure that is what I want.

If that is not the experience I have by default with any of these alternative package setups, that’s an annoying problem. If I am unable to set it once and have that experience from then on with all packages of the given format, that is a bigger problem. If I can’t get that experience at all, that’s a rule-out.

The bit about Appimages being the smallest is a nice bonus too.

Based on what I see here, Appimage looks like the winner.

I’ve never had the opportunity/need to resort to this, though. All of the programs I have sought in Linux have either had a distro-native package (which is my preference if available) or if not, they were not offered in one of the alternative package setups.

One that I would have liked to see in such a format would be LinSSID, a Linux clone of the popular InSSIDer program for Windows. Its developers offer it in a .deb, which is great if you are using one of the Debian derivatives (including Ubuntu and Mint), but there are a lot more distros than that, including my new main (at least for now) distro, Fedora.

LinSSID is open source, so the source code is freely available, but the build instructions are not offered on the project site/repo. I found the instructions inside the downloadable source archive, but even then it was Ubuntu specific, listing the packages that Ubuntu derivatives would need, but not others. Fortunately, it was not that hard to try to build it, see what the errors it provided were, then find those packages using dnf (Fedora’s version of apt). I got it built in about 20-30 minutes, which IMO isn’t bad for someone fumbling around in an unfamiliar distro and who is not an old hat (har har) at building from source.

This is one example of a program that I do not know would work in a given format. It requires root access to be able to communicate directly with the wireless driver. Is that possible in the mandatory sandbox of Snap or Flatpak? I don’t know.

I don’t think you need to pick one and stick with it, though. It should be possible to have the frameworks for all three installed, if that is your wish.

 

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

Reply | Quote

I use both snap and flatpak and both work okay. The one snap game I have is now available as a flatpak so i may switch and remove snapd. Spapd seems to get into everything.

Here is a recent boot log:

—

systemd-analyze critical-chain
The time when unit became active or started is printed after the “@” character.
The time the unit took to start is printed after the “+” character.

graphical.target @40.865s
└─multi-user.target @40.865s
└─snapd.seeded.service @40.833s +31ms
└─snapd.service @29.831s +11.000s
└─basic.target @28.824s
└─sockets.target @28.824s
└─snapd.socket @28.824s +694us
└─sysinit.target @28.745s
└─snapd.apparmor.service @28.177s +567ms
└─apparmor.service @25.534s +2.641s
└─local-fs.target @25.533s
└─boot-efi.mount @25.380s +152ms
└─systemd-fsck@dev-disk-by\x2duuid-72A9\x2dB004.service @25.091s +277ms
└─dev-disk-by\x2duuid-72A9\x2dB004.device @25.090s

Reply | Quote

? says:

i use synaptic package manager, took out software center and snap.d,

https://www.kevin-custer.com/blog/disabling-snaps-in-ubuntu-20-04/

and boot time is 5 seconds and change…

Reply | Quote

I’ve used all three and added various repository permissions for programs such as emby.  Doesn’t matter to me where software comes from or how its delivered since I’m not a compulsive clicker and do some research before installing anything.

We have a Linux laptop and a home server, both running Ubuntu.  I experimented with a number of distros from the three main branches before settling on Ububtu minimal installs which are relatively small.  From there both installs have had a few mods; Ububtu with a particular Gnome extension is the only distro that gives my old laptop a smooth touchpad.

Not really sure from where the Mint team is coming with their move away from Canonical since Mint is two layers away from Debian and they can’t really do their own thing unless they somehow start over independently, a huge undertaking.

Linux is as minimal as a user’s talent for making it minimal while still meeting their needs.  Command Line stuff doesn’t bother me, it seemed stupid and basackward when I started trying distros earlier this year; a GUI is definitely easier for Windows migrators.  Little things matter; my laptop worked fine with any distro I have tried but good touchpad performance was the kicker.

“Purity” with Linux is a strange beast with many somewhat arbitrary variations.  Pure Admins never use a server GUI, Mint has their take, Kubuntu won’t allow file manager root access, etc.  Good thing is there are so many choices most users can find a distro they like.

Reply | Quote

anonymous wrote:

“Purity” with Linux is a strange beast with many somewhat arbitrary variations. Pure Admins never use a server GUI, Mint has their take, Kubuntu won’t allow file manager root access, etc. Good thing is there are so many choices most users can find a distro they like.

Well duh, proper ideological purists probably run Gentoo or some such, do a full toolchain rebuild on each fresh install and never use binary-distributed packages.

Or possibly NetBSD (with pkgsrc) and same.

Reply | Quote

anonymous wrote:

Little things matter; my laptop worked fine with any distro I have tried but good touchpad performance was the kicker.

All Linuxes use the same drivers (though not always in the same versions) for X, Wayland, Mesa, and all that sort of thing. If one distro works better with the touchpad than others, you could get that in any other distro too if you copied over the configuration that works well with the touchpad.

If a given distro uses Wayland, you’d be stuck using libinput, and it’s pretty awful, five years after it was supposedly ready for prime time. I tried to use and get used to it, but it’s just unusable to me, on all of the touchpads I tried it on as well as my actual mouse.

The devs of libinput think there’s such a thing as a “correct” configuration for a touchpad (or mouse), so they refuse to provide options to allow a person to tune the device to his or her own preferences, insisting instead that anyone who finds their device is not working “correctly” should instead file a bug and let the libinput devs make the libinput behavior “correct” for that device (only it will be their idea if correct, not yours).

If that sounds bonkers, I would say you are right. Most people are not going to file a bug, but they very well might move sliders around in the mouse settings until it feels the way they want (which takes a lot less time than filing a bug, let alone waiting for someone to fix it). The idea that there is a single “correct” feel that works for all people is bad enough, but trying to force those people to help you develop the driver to accomplish that (rather than letting them twiddle the knobs themselves) is just Microsoft-level arrogance, and then some.

If you use X11, you also have the option of using the much superior synaptics touchpad driver (which, despite its name, is not just for Synaptics touchpads), and in my experience, synaptics is necessary to get good touchpad feel.

I don’t use Gnome, though, so maybe there is some other solution with the extension you mention. I had heard that some GNOME distros use Wayland by default, so a switch to X11 may be in order for those if you wanted to use Synaptics. Wayland is supposed to replace the aging but venerable X11, just as libinput is meant to replace all other input drivers, but these kinds of unilateral, “our way or the highway” decisions and the continuous growing pains are why so many of us simply are not interested in Wayland in anything like its current form.

Pure Admins never use a server GUI, Mint has their take, Kubuntu won’t allow file manager root access, etc.

That’s a KDE decision, another example of “our way or the highway,” and one that was so unpopular that OpenSUSE (one of the big heroes in this sort of thing… if anyone is going to fix mistakes like this, it’s probably OpenSUSE) promptly patched that “feature” back out of Dolphin (file manager) and Kate/Kwrite (text editors).

As soon as I discovered this wonderful new “feature,” I just used the OpenSUSE patched binaries, and before long, KDE relented, partly. If you launch Dolphin with a few environment variables, it will successfully launch as root. A lot of people still think it doesn’t work, and it seems that’s by design (or KDE would have simply backed out the patch completely). It’s another example of not just accepting what the distro hands you, ’cause if you aren’t using OpenSUSE, KDE is much harder to use without knowing the secret handshake to get it to work like every other desktop. At least they did provide a fix that only needs to be done once and then keeps working, even if it is hidden. Many other open source devs are too arrogant for that.

GNOME, FWIW, is one of the worst offenders for this. As just one example, their load file dialogs don’t even have a text input field unless you know the secret key combo to make it appear, and that’s not an oversight, but a design decision. People have begged the GNOME devs for a button to make it appear or some other kind of visual reminder that the text input field even exists, but the GNOME devs say it’s not an actual feature as much as an “Easter egg” for those who know about it.

That would be like having windshield wipers on a car completely hidden and not mentioned in the manual, and having the control to turn them on require knowledge from some external source. They’re not an actual feature of the car, you see, but an Easter egg, a special treat for the select few. The rest of you, good luck if it rains!

GNOME 2 had a sensible file load dialog, but they got rid of that. Nautilus used to be a powerful, full-featured file manager (much as its fork Nemo now is), but it wasn’t simple enough for complete computer newbies (getting hard to find those these days), so it started having features hacked off, a process that has gone on for years, and one could easily conclude that it inspired Mozilla to take a machete to Firefox’s features in the same way.

The same thing happens in proprietary software too, of course, but there’s much less recourse if they lose their minds and decide to destroy the very thing that made you use their software in the first place, which seems to eventually happen to all software if you use it long enough.

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

1 user thanked author for this post.

Cybertooth

Reply | Quote