A few years ago we were able to upgrade everything (OS and Apps) using a single command. I remember this was something we boasted about when talking to Windows and Mac fans. It was such an amazing feature. Something that users of proprietary systems hadn't even heard about. We had this on desktops before things like Apple's App Store and Play Store were a thing.
We can no longer do that thanks to Flatpaks and Snaps as well as AppImages.
Recently i upgraded my Fedora system. I few days later i found out i was runnig some older apps since they were Flatpaks (i had completely forgotten how I installed bitwarden for instance.)
Do you miss the old system too?
Is it possible to bring back that experience? A unified, reliable CLI solution to make sure EVERYTHING is up to date?
Alias update="sudo apt full-upgrade && flatpak update"
Fixed it for you
Appimages for in-dev programs usually have an auto-updater that runs when you run the program, too, which is accetapble by my factual and perfect standards. It would be nice if someone put together an appimage store to manage these, I guess.
There has always been the option of installing software from source. The package manager won't update anything installed from source.
You don't have to use Flatpak, Snap or AppImage if you don't want to. If you use the package manager to install everything, it will update everything.
If I use ubuntu I'm somehow forced to use them.
Even on Fedora the average user is presented with many flatpak results when they use the GUI software manager. Not everyone is technically adept enough to check the origin of the app. So it's kind of being forced on users.
If I use ubuntu I’m somehow forced to use them.
Yes, that's why I stopped using it years ago (among other reasons).
Users are not out of options, they don't need to check the origin of the apps themselves, it's enough to ask other users what distros don't do the things they don't like and use those.
IMHO the killer feature of linux is that you aren't getting shit straight into your mouth every day by some corporation that decices to squeeze more cash money out of you.
And as others have pointed out most gui applications update all sources automatically.
#! /bin/sh #update_everything_in_one_command.sh set -e apt update apt upgrade -y flatpak update -y$ sudo update_everything_in_one_command
Tada!
You're using Linux. It took me about an hour to create a script that will upgrade all packages, Snaps, and flatpaks, complete with flavor text. The fact that I could do that, with total control over how and when to run those updates, is still a killer feature to me.
Silverblue here with automatic updates enabled, I do not care anymore, it just works.
Use a distribution with a large package library that is kept up to date and there is noting to miss.
Ubuntu is starting to push Snaps. So, that is becoming an unavoidable reality for Ubuntu users. For the most part though, Flatpaks remain optional for most distros.
The problem that Flatpaks solve is that the distro provided packages are out-of-date. If they are not, there is no real reason to prefer Flatpak.
IDK I thought sandboxing is also something that comes with Flatpak, so security concernes could be a reason to use Flatpak as well.
I do hear that. Flatpaks do not seem to be very good sandboxes though.
A few years ago we were able to upgrade everything (OS and Apps) using a single command. I remember this was something we boasted about when talking to Windows and Mac fans. It was such an amazing feature. Something that users of proprietary systems hadn’t even heard about. We had this on desktops before things like Apple’s App Store and Play Store were a thing.
If this actually were Linux's killer feature, then Linux would have had a much higher market share by now.
Make no mistake, this is my favourite feature of Linux as well, and I have never used a snap/flatpack/appimage in my entire life. But it doesn't have the kind of broader public appeal that you seem to be suggesting.
I don't use flatpak. But if your distro does, I imagine it should be pretty easy for them to provide a higher level program that updates both types of packages at once. I think this isn't a big problem.
What I think the biggest problem with the traditional package managers is that (1) they don't isolate packages from each other (when you install a program files are placed in many random places, like /usr/bin, /usr/lib etc) and (2) you can't have multiple versions of the same package installed at the same time.
This creates a lot of work for package maintainers who need to constantly keep packages up to date as dependencies are updated.
Also, because of this, every distro is essentially an insane dependency tree where changing even one small core package could break everything.
Because of this, backwards compatibility on Linux is terrible. If you need to run an older application which depends on older packages, your only choice is to download an older distro.
This is what snap and flatpak try to solve. I think they are not great solutions, because they ended up being an extra package manager next to the traditional package managers. Until we see a distro that uses flatpak or something similar exclusively, the problem is not solved.
What I think the biggest problem with the traditional package managers is that (1) they don’t isolate packages from each other (when you install a program files are placed in many random places, like /usr/bin, /usr/lib etc) and (2) you can’t have multiple versions of the same package installed at the same time.
Would you like to know about our Lord And Savior NixOS?
Wow, that's exactly what I have been missing in my life. Amen, brother!
Never used Flatpak or Snap in nearly 30 years of using Linux. I might one day but not yet.
I don't use Fedora these days but your package manager will probably have some hooks. Add one to update your Flatpaks when it has finished its main job.
I've seen the term "hooks" used all the time and have always wondered what the need for them is. I was a Windows user my entire life since childhood and recently rectified that a couple months ago.
Unlearning the Windows paradigm of operating systems has been annoying. So many functional aspects of my machine abstracted away made me have to create an entirely new scaffold for learning technology...
A hook is a mechanism for adding functionality at a certain point in a program's normal flow. As a simple example, imagine a program that works by doing three things in order. It could have hooks that allow the user to add actions before or after any individual steps. Each possible point in the flow is a separate hook. One way to implement it is with a directory for each hook in the program's configuration directory, where executables can be placed; the hook runs each executable in sorted order.
I didn't look up any of this, so it may not be the best explanation, but I hope it is helpful.
Thanks for the explanation! I always wondered why would describe hooks so trivially. I'm still bleaching my brain of the Windows habits I developed from lifs-long usage.
I looked a little more into hooks, and am curious if a patch can kind of be like a hook? Where you create a config file that has symlinks to all the executables like you mentioned? Still a noob when it comes to software creation :D
[Can] a patch can kind of be like a hook?
In the free software world, a patch usually describes a file that lists lines to be added to or removed from another file (or multiple files). The most common use for this is probably with actual source code.
Binary (non-text) patches are also possible, and in Windows a software bug-fix "patch" would likely be mostly binary. In the free software world, it's uncommon to use binary patches for updates; instead the source is patched (either in the main upstream project or by a distribution) and a new binary package is built and published.
Where you create a config file that has symlinks to all the executables like you mentioned?
I don't really understand how those two questions relate, so I may not be able to give you a good answer. Often a configuration file has a
variable=valuestructure, but it would certainly possible to have a list of file paths in a configuration. However, this might instead be implemented as an actual directory (like~/.config/app/pre-hook.d/) where each executable file in that directory is executed by the "pre" hook in the app. (Configuration directories often work very similarly also.)Whether the paths are symlinks is likely to be irrelevant, as this is more a filesystem level feature that would often be ignored entirely by the application.
I hope this is helpful.
I'm still updating the whole system with one command. Just avoid flatpaks. Repackage for your distro if you need to.
