from Jack_Burton@lemmy.ca to linux@lemmy.ml on 15 Sep 22:48
https://lemmy.ca/post/51677798
I have 3 machines I’ve switched to Linux: an old laptop with Mint, and my primary laptop and PC runing Ubuntu Studio. I use Protonvpn on all 3.
Today I had my app manager on Mint and Discover on Ubuntu showing new updates. I installed Mint’s first, via the manager and Proton was an update. It mentioned it would uninstall a few proton things so I figured it had to uninstall them in order to install the new update. Protonvpn stopped working after, it looked uninstalled but my killswitch was still active (so no internet at all and no access to open the vpn app). I had to find out how to kill the network processes via ncmli (good new info to learn!) and do a roundabout uninstall through a process I found in an old Proton post as just uninstalling it with normal commands didn’t work, restart the laptop then reinstall Protonvpn.
So on my laptop and PC, I updated via terminal instead, using sudo apt update/upgrade. All smooth and no issues.
Was my Mint problem a one-off glitch or is there a real difference when updating via update manager vs the terminal?
Edit: Thanks guys, seems the general consensus is yes, but some of ya’s say no haha. I knew going into the question that having Mint screw up with manager and Ubuntu Studio work with terminal opens a lot of os possibilities beyond simply manager vs terminal.
Next Proton update, I’m going to try the terminal on Mint instead of manager, and the manager on my Ubuntu Studio laptop instead of terminal and see if anything screws up.
threaded - newest
no, there is no difference. at least if ubuntu studio has hooked apt up to discover; it’s usually mainly used for flatpaks.
Yes. GUI stores tend to use something called PackageKit. It’s basically an abstraction layer, each package manager writes its own packagekit backend.
That way, GUI stores just have to support PackageKit rather than every single package manager. But there are bugs with PackageKit and the backends may have bugs too. Pacman’s is notoriously bad.
Hopefully I can piggyback with a similar question that came to me recently. Similar to how Ubuntu/Mint work, Fedora KDE can be updated through the Discover store or directly via the
dnfcommand. But after updating system packages via Discover, it prompts me to restart the PC to finish the update. What is it actually doing? Why does DNF not do that?the prompt to restart happens to me on debian when using the software manager too.
Some stuff needs a restart to use the new libraries and such when those things are already in use, since it doesn’t actually delete those until they stop being used. For example, if you get a new kernel, it won’t just delete your old one until you’re done using it. Terminal tools usually assume that you know this, so they won’t prompt you.
It’s safer, and uses a systemd mechanism to update with most programs not running.
That said, I’ve never had a problem updating without restarting…
You can change the behavior in System Settings -> Software Update -> Apply System Updates
Pick either immediately or after rebooting
Some things only get applied once you restart. Take the kernel for example. It will be used once restarted. It is safe to restart at a later time but you would still be running a older kernel at that point.
So technically the update is dine but not everything is using it yet. Dnf does tell you you should restart for some things to be applied. The choice is yours to do so.
On Ubuntu, I’m not sure about “Discover”, but I use the GUI called “Software Updater”. This is just a GUI on top of apt/apt-get which I can also use from the command line.
Not sure about Mint, but I would expect it to be very much similar.
on my manjaro machine updating via terminal doesn’t cover some updates. Opening the software manager reveals missed updates. stuff like gear level and freedesktop.org. couldn’t tell ya why.
on my fedora kde machine, it misses stuff from Discover. also not sure why.
on mint, terminal covers everything. same on debian.
The Linux Mint GUI updater is an interesting bit of code, or at least it was about 5 years ago. I looked at updating it a bit with a status bar for a stage I thought could use it.
I opened up the code…Python that just uses a shell call to apt. No muss, no library calls. Okay, that’ll do.
It was a functional wrapper on the command line calls, exactly as you’d hope for a tool.
What command are you using to update on the terminal? If its pacman then it will miss KDE store and flatpak updates. You can add a hook in I think.
ah this must be it, thanks
Are the missing updates from the AUR? Because if so, most terminal tools don’t check those.
there is. if the updater gui integrates with packagekit and systemd, it can start an offline update that reboots your system and installs the updates while nothing else is running.
kind of like on windows, except that this is one of the things where windows made the right call. complex software does not handle it well if its program libraries and assets are being replaced by newer ones that the running version cannot understand.
its still kind of a new thing, not all distros make use of it yet, but Fedora does, and it’s not a Fedora custom solution but something that most distros can have.
automatic filesystem snapshots and rollback can be integrated to this too, and then bye bye to updates breaking the whole system.
@SatyrSack@quokk.au
I gripe about having to restart my Fedora machine with updates, but you can’t knock the results. It’s as reliable as a swiss watch.
Most GUI package managers are just wrappers for the package manager CLI.
Yup. On slow systems when doing a very big update I suggest using a terminal over a GUI based app. Less risk of things getting stuck.
For Mint in particular, there is a difference. There are some ubuntu packages they don’t want applied, and the command line does apply them. While their packagekit gui app, doesn’t. They always suggest we use their app. Also, the app updates spices, and flatpaks.