I have been using Slackware-64-current as my daily driver for a few years and it serves me very well.

I use a mix of the bundled software that is part of Slackware and various tools that I add to it. These range from modules that drive devices to complex software. I use a lot of SlackBuilds but some things like VLC and LibreOffice and Inkscape require too much for me to bear so I use the packages graciously provided by yeomen like AlienBob, Ponce, and others. I have some converted .rpm and .deb also. Some of those work better than others. Now I find myself increasingly making use of AppImages and binaries rather than the "non-portable" installed packages and SlackBuilds. Probably some of the need for that is that I am running -current which sometimes breaks the slightly older (but stable!) versions found in the packages and SlackBuilds. but I find that I am often getting by better with the AppImages and binaries than with installed packages. The upside of portable versions is that I am up and going quickly.

I am wondering what is the downside of using portable versions of tools rather than installed versions?

I am a little curious to hear which AppImages you use? I use one for QBittorrent which has never given me trouble and I would certainly be ready to use more...

The normal downsides I guess. The portable stuff comes with its own libs. Which mostly means extra diskspace is being used, and those libs can be outdated. Also mixing packages (portable,slackbuilds,repo) means extra maintenance. Other that that, not much. That's a bit of the downside of Slackware, the repo with binaries isn't huge. In that aspect Debian comes with a bigger repo, but obviously with its downsides as well.

Being pragmatic is the most sensible thing to do. A home PC is there to use as a tool, and if portable applications expand your toolset then make use of that. I like Appimages a lot for software that cannot be easily installed/compiled otherwise.

Size and efficiency. But it doesn't really matter any more does it? I've got an accounting package in an AppImage, which is 91Mb. The same thing compiled dynamically would probably come in at less than 5% of the size... but who cares? When you're talking in tens of megabytes, I think portability is more important. Drop it in and it works. No mess, no fuss and no headaches.
This.

1 members found this post helpful.

I use Flatpaks and honestly it's changed the game. There are a few slackbuilds that either have sprawling dependencies, long builds, or are simply not available, and it's just an easy solution. It allows me to use Slackware more than I would otherwise.

I haven't encountered any serious drawbacks.

A minor hiccup came using a plugin with LibreOffice (since the default plugins folder is in a different place), but the solution was easily found on StackExchange. That was about it.

2 members found this post helpful.

I use unprivileged containers. My host user uid is not mapped inside the container so my uid 1000 on the host is the same inside the container and has access to my X socket. I also add acls for the devices in /dev/{snd,drm} to allow the container uid 1000 to use them. That way the container apps run "natively" without the need of huge faltpak runtimes.

Right now my home desktop is a minimal CRUX install with sway window manager, ubuntu and alpine containers and win10 qemu vm.



Cheers

1 members found this post helpful.

KISS really does work. In the long run you have all the control.

1 members found this post helpful.

@andrew.46 - I have only kdenlive as a AppImage presently. obs-studio, seaview (nucleic acid sequence analysis), blender, inkscape, and zoom are there as binaries. Seaview can be installed easily enough but the boxed whole package saves much time. I had R-studio as a binary at one point. I think I have some others but those are the main ones now. Some of the SlackBuilds just repackage the binaries, so I wonder what is the point.

LibreOffice keeps developing little glitches particularly in Impress
(my main reason for using LO)
I have tried the AppImage for LibreOffice and it adds new problems.
I have not tried the flatpak.

@lovemeslk
I am not sure which method is being defended as KISS.
I am always happy when stuff works.
Simple is simple if you know where the key is kept.
It seems like it must be some sort of magic until
someone shows you the little chromium switch.

My home life and my work life have never been actually separate.
I have heard of people who would choose to divide them but
I never grasped the concept actually, so I don't understand
the "home PC" argument or what diff it should make.

I try AppImages than I read something on web. His power: all needed files are included.
My test on AppImage (Pencyl2D & SynfigStudio): the first not works fine...window program go out the screen; second work nice, but when I'll find a good option I'll remove it.
So I prefer bin file because I think is optimized and fast than AppImage.
Read this article

https://www.techrepublic.com/article...ages-on-linux/

I've used AppImages and they seem pretty fine; they're also easy to break out into a more permanent install via the --appimage-extract option and convert it into a Slackware package if necessary, for example my client for Outline VPN.

I've also used binary releases from Rust and Go CLI utilities like docker-ce, kubectl or direnv; they're easy enough to drop in {~,/usr/local}/bin in a hurry and git-r-done. There are also heavier omnibus packages like chef-workstation/chefdk (which comes with their own full tree installed in /opt) that are also easy enough to just repack into a Slackware package (either normally or with slacktrack.)

I think the general belief among a lot of SBo maintainers is that compiled is better. There are some obvious benefits to compiling like ensuring all optional features are enabled if desired and linking to system libraries (saving overall space, even if minimal). And I'd say the vast majority of SlackBuilds are indeed compiling. But sometimes a project only provides binaries (like closed source projects) or the compile can be extremely difficult (like libreoffice) that offering a repackaging is nice.

There is no set standard from SBo admins on which method a maintainer should use, so it comes down to the preference of the maintainer.

I think that is different for each person. For some, KISS means running Ubuntu, Debian, RedHat, etc. For others, it means compiling everything to ensure it is compiled against system libraries. Others might go for binary packages because they don't want to deal with the dependencies when compiling the packages on their own.

You should do whatever you feel is best for you and your system. That's one of the beauties of Slackware. It gives you a good base for you to start with and then you tailor the system to what you want it to be. If you like AppImages, stick with them and don't let anybody tell you you're wrong.

1 members found this post helpful.