Use AppImages To De-Bloat Your System DistroTube
video description
Date: 2022-03-30
Related videos
Comments and reviews: 10
Juzu
I use Gentoo, and while I would certainly want faster CPU for compiling, I compile everything from source. I also have the highest optimization level + graphene and LTO, so compiling really takes forever. But I let it compile in the background or when I'm not using my computer. I'm getting my sources instantly after those are released, so waiting for overnight in the worst possible case like with QtWebKit and Firefox is not that big of a deal. While I'm not checking out the source codes, I still really love the feeling that I get for having 100% source based system. Though with couple of required firmware blobs. Hopefully those could be avoided with some future hardware.
reply
I use Gentoo, and while I would certainly want faster CPU for compiling, I compile everything from source. I also have the highest optimization level + graphene and LTO, so compiling really takes forever. But I let it compile in the background or when I'm not using my computer. I'm getting my sources instantly after those are released, so waiting for overnight in the worst possible case like with QtWebKit and Firefox is not that big of a deal. While I'm not checking out the source codes, I still really love the feeling that I get for having 100% source based system. Though with couple of required firmware blobs. Hopefully those could be avoided with some future hardware.
reply
ubiquity
I like where your head is at, but I wouldn't exactly call your approach, -de-bloat-.
Frankly speaking, AppImages can actually reduce bloat only if we become smarter about updating them.
An AppImage is really just a bunch of files running in a squashfs. If we wanted to use them to reduce bloat, we need an appImage manager that sifts through an updated AppImage and only downloads the parts of it that were -updated- instead of everything, then it will -patch- your currently installed AppImage with just the updated parts.
Until this happens, we can't make a strong enough argument for why someone should switch to AppImages entirely. They are just too big.
reply
I like where your head is at, but I wouldn't exactly call your approach, -de-bloat-.
Frankly speaking, AppImages can actually reduce bloat only if we become smarter about updating them.
An AppImage is really just a bunch of files running in a squashfs. If we wanted to use them to reduce bloat, we need an appImage manager that sifts through an updated AppImage and only downloads the parts of it that were -updated- instead of everything, then it will -patch- your currently installed AppImage with just the updated parts.
Until this happens, we can't make a strong enough argument for why someone should switch to AppImages entirely. They are just too big.
reply
AlexXx
Instead of inventing self-contained packages, why not make/use a package manager that can track dependency versioning information and keep different versions installed for compatibility. Package manager job is then to link apps with the dependency versions they are compatible with, and only update this linkage to different versions when app update specifically says so. No dependency breaks after updates. Profit.
I think the idea like that was used on Windows to fight DLL hell. Now there is the SxS folder which keeps and manages dll version dependencies for the apps.
reply
Instead of inventing self-contained packages, why not make/use a package manager that can track dependency versioning information and keep different versions installed for compatibility. Package manager job is then to link apps with the dependency versions they are compatible with, and only update this linkage to different versions when app update specifically says so. No dependency breaks after updates. Profit.
I think the idea like that was used on Windows to fight DLL hell. Now there is the SxS folder which keeps and manages dll version dependencies for the apps.
reply
Milo
I would love to see a Linux distro that only has the core base OS installed, and then everything else for user space is installed via appimages. AppImages are superior to snaps and flatpacks to me because they have all dependencies included and are more universal. They come closer to the old MACOS idea of the entire app is just a folder and you can just drag and drop the entire app to install it. While, something like snaps that require a bunch of daemons to run, and a bunch of other packages to be installed seems like a wrong way to go.
reply
I would love to see a Linux distro that only has the core base OS installed, and then everything else for user space is installed via appimages. AppImages are superior to snaps and flatpacks to me because they have all dependencies included and are more universal. They come closer to the old MACOS idea of the entire app is just a folder and you can just drag and drop the entire app to install it. While, something like snaps that require a bunch of daemons to run, and a bunch of other packages to be installed seems like a wrong way to go.
reply
UnReaLgeek
It-s interesting seeing the two different view points on what debloat means - on one hand, we have the time based view point, which takes bloat as downtime from updates and number of packages, while the storage based view point takes bloat as the storage space used.
Hilariously, it-s two different eras - one where storage is cheaper than cycles and thus reducing downtime is preferred (new tech); and the other era is cycles are cheaper than storage and thus space per program must be optimized (old tech).
reply
It-s interesting seeing the two different view points on what debloat means - on one hand, we have the time based view point, which takes bloat as downtime from updates and number of packages, while the storage based view point takes bloat as the storage space used.
Hilariously, it-s two different eras - one where storage is cheaper than cycles and thus reducing downtime is preferred (new tech); and the other era is cycles are cheaper than storage and thus space per program must be optimized (old tech).
reply
TDplay
Package number is meaningless, you're actually adding MORE bloat.
AppImages bundle all their dependencies and therefore lead to duplicate libraries, use the packages from your distribution whenever possible. They are for upstream packaging, if you want an unbloated system then using libraries as separate packages is less bloated.
If you want to debloat your system, just tell your package manager to remove things you don't use. When you have window managers you don't use, -pacman -Rs- is your friend.
reply
Package number is meaningless, you're actually adding MORE bloat.
AppImages bundle all their dependencies and therefore lead to duplicate libraries, use the packages from your distribution whenever possible. They are for upstream packaging, if you want an unbloated system then using libraries as separate packages is less bloated.
If you want to debloat your system, just tell your package manager to remove things you don't use. When you have window managers you don't use, -pacman -Rs- is your friend.
reply
Pinaki
AppImages are the way to go if I don't want to mess up the base installation for trivial things. AppImages are the future of software packaging for the commercial software vendors to avoid complications while making the package available for various Linux distributions. I use those single file binary packed all together with all the required dependencies to keep my base installation clean and lean. It's my work machine, so bread and butter matter more than experimenting with the repo-based installation.
reply
AppImages are the way to go if I don't want to mess up the base installation for trivial things. AppImages are the future of software packaging for the commercial software vendors to avoid complications while making the package available for various Linux distributions. I use those single file binary packed all together with all the required dependencies to keep my base installation clean and lean. It's my work machine, so bread and butter matter more than experimenting with the repo-based installation.
reply
Erik
I don't think that anything configured with a text file or were you want the configuration synced with git would work with any of the 3 main universal package systems.
Meaning that you would basically have to use vanilla Emacs if you found an actual appimage of it as I'm not sure it is allowed to read/write to/from -/doom.d/ or -/emacs.d/
I remember the alt package for steam not being able to read/write to My games harddrive but I'm not sure that was appimage and not snap or flat
reply
I don't think that anything configured with a text file or were you want the configuration synced with git would work with any of the 3 main universal package systems.
Meaning that you would basically have to use vanilla Emacs if you found an actual appimage of it as I'm not sure it is allowed to read/write to/from -/doom.d/ or -/emacs.d/
I remember the alt package for steam not being able to read/write to My games harddrive but I'm not sure that was appimage and not snap or flat
reply
ubiquity
I encourage any of you wanting to de-bloat your arch install, to try making a backup of your system. I guarantee you, you will start questioning why you need -vi- when -vim- is also installed.
Better yet, try using aconfmgr which is a configuration manager for arch. After it runs for 3+ hours, you will be forced to know what needs to go and what should stay. When was the last time you cleaned your .pacnew files?
reply
I encourage any of you wanting to de-bloat your arch install, to try making a backup of your system. I guarantee you, you will start questioning why you need -vi- when -vim- is also installed.
Better yet, try using aconfmgr which is a configuration manager for arch. After it runs for 3+ hours, you will be forced to know what needs to go and what should stay. When was the last time you cleaned your .pacnew files?
reply
Alby
If long updates or software breaking a lot is a problem, then why not add programs to the IgnorePkg array in your pacman config and update applications at your own convenience? Also, for certain proprietary software this might make sense, but you generally prefer to use open source software a lot, and the fine people who package software for Arch Linux generally rebuild software as libraries are updated.
reply
If long updates or software breaking a lot is a problem, then why not add programs to the IgnorePkg array in your pacman config and update applications at your own convenience? Also, for certain proprietary software this might make sense, but you generally prefer to use open source software a lot, and the fine people who package software for Arch Linux generally rebuild software as libraries are updated.
reply
Add a review, comment
Other channel videos
