(Edit: I always forget that Beehaw will convert every ampersand character in code segments to &. Have this in mind when reading the code below. Do you have these problems too with your instance?)
If you update your system from terminal, do you have a shortcut that bundles bunch of commands? I’m on EndevourOS/Arch using Flatpak. Rustup is installed and managed by itself. The empty command is a function to display and delete files in the trash using the program trash-cli. In my .bashrc:
alias update='eos-update --yay \
; flatpak uninstall --unused \
; flatpak update \
; rustup update \
; empty'
empty() {
trash-empty -f --dry-run |
awk '{print $3}' |
grep -vF '/info/'
trash-empty -f
}
I just need to type update. Also there are following two aliases, which are used very rarely, at least months apart and are not part of the main update routine:
alias mirrors='sudo reflector \
--protocol https \
--verbose \
--latest 25 \
--sort rate \
--save /etc/pacman.d/mirrorlist \
&& eos-rankmirrors --verbose \
&& yay -Syyu'
alias clean='paccache -rk3 \
&& paccache -ruk1 \
&& journalctl --vacuum-time=4weeks \
&& balooctl6 disable \
&& balooctl6 purge \
&& balooctl6 enable \
&& trash-empty -f'
This question is probably asked a million times, but the replies are always fun and sometimes reveals improvements from others to adapt.
You must log in or register to comment.
i just run
yaywithout args.Paru > yay
May I ask why? I’m a recent Arch user, and yay seems just fine for me so far. Haven’t looked into paru much yet. Is it because it’s made on Rust, or are there more/better features?
No alias, just topgrade
nix flake update && sudo nixod-rebuild switch
You should at least consider
nixos-rebuild --use-remote-sudo switchover raw-doggingsudo.What does remote sudo actually do I thought it was meant to be for doing remote builds over ssh
It’ll call sudo at the point it needs to at the end regardless of remote or not. There have been a couple of bugs in the past trying to run the whole process under sudo &
--use-remote-sudowas always recommended as a fix.Have tried using it this way though the glaring issue for me is that I have to type the password at the end rather than start, meaning I’ll start a rebuild, go for something else then it’ll time out on the sudo password
That is a different story & a usability pain I can share 😅 …but assuming there wasn’t a GC, the build is cached, just needs another switch—& I am willing to take that as opposed to having the whole process running as root.
I suppose I could write a custom script that runs sudo echo or something so it’s cached
On Arch I don’t need any, I just run
paruwithout any options, which by default invokes a full Pacman update, as well as updating all AUR packages. But I have a system maintenance script, that, besides doing some other stuff that’s specific to my system, runsparu -Sc --noconfirmto clean the Pacman package cache, and delete unneeded cloned AUR Git repos and build artifacts.Honestly, no. I just use direct apt commands on my Debian installs for native stuff, assuming I even use the shell for that; sometimes, if it’s not a complex update that’s going to hold back 1.0*106 packages, I just use Synaptic or Package Updater, frankly, as one of those is what I have my XFCE Package Update Indicator set to use on any machine I use frequently and it’s convenient sometimes.
As for Flatpaks, I just run the flatpak update command whenever I feel bored. I wish Warehouse GUI supported updating, just because I find it really weird that’s excluded from an otherwise pretty slick application that gets rid of me having to muck through the Flathub.
I don’t write Rust code at the moment, and as for Python, I’m either using the Debian version of Python packages or scattered venvs that follow a de facto standard for Python developers: “What’s an update?”
Using Bluefin (a Fedora atomic distro) and all of that gets done automatically behind the scenes. Flatpaks, distrobox containers, Brew, vocoder extensions, etc…
All done using topgrade: https://github.com/topgrade-rs/topgrade
#!/usr/bin/env bash systemctl --failed -q yay -Pw sudo reflector --save /etc/pacman.d/mirrorlist -c de -p "https" --ipv6 --completion-percent 100 -l 10 --sort age yay -Syu pacman -Qqnte > ~/.local/share/applications/pkglist.txt pacman -Qqdtt > ~/.local/share/applications/optdeplist.txt pacman -Qqem > ~/.local/share/applications/foreignpkglist.txt yay -Sc > /dev/null pacman -Qtd pacman -Qm sudo find /etc -name *.pac*Thanks for posting. But isn’t this a bit too much for every time you update your system? Like rebuilding the mirrolist each time?
I update about once every 2 months.
So I basically put everything related to updates from https://wiki.archlinux.org/title/System_maintenance into my script.Wow that is probably the longest update cycle I ever heard of any Arch user. :D Nothing wrong with it, its just unusual.
Arch is the most stable OS (as in, doesn’t break) in my experience, as long as you maintain it.
The Mint upgrade tool got flatpak support so I don’t even use the terminal to update anymore.
Topgrade handles most distros package managers, things like npm, brew and cargo, can pull git repositories and cleanup cache as well
That’s my system, I just have
topgradealiased toupdatelol
I actually just run the update commands individually when I feel like.
su -l 'pacman -Syu' # All regular packages pakku -Syu # All AUR packages (I know this updates regular packages, too.) flatpak-update # Update Flatpak packages with a function I wroteSince I do not trust Flatpak (especially when it comes to driver updates and properly removing unused crap) I once created this monstrosity.
flatpak-update () { LATEST_NVIDIA=$(flatpak list | grep "GL.nvidia" | cut -f2 | cut -d '.' -f5) flatpak update flatpak remove --unused --delete-data flatpak list | grep org.freedesktop.Platform.GL32.nvidia- | cut -f2 | grep -v "$LATEST_NVIDIA" | xargs -o flatpak uninstall flatpak repair flatpak update }The initial problem with Flatpak thinking it would be a good idea to add dozens of Nvidia drivers and re-download and update all of them on every update (causing a few gigabytes of downloaded files on every run of a normal
flatpak updateeven if nothing needed to be updated) is reportedly fixed, but I just got used to my command.The initial problem with Flatpak thinking it would be a good idea to add dozens of Nvidia drivers and re-download and update all of them on every update (causing a few gigabytes of downloaded files on every run of a normal flatpak update even if nothing needed to be updated)
100% agree! Up until last year I was also using Nvidia and the Flatpak drivers for Nvidia got out of hand. I was using just a handful of applications in Flatpak, yet I had 6 different versions of the driver, each 350 MB and every of them was downloaded fully and updated every time. And that is besides other updates and other stuff. I would have needed your function so badly back then. :D
Yeah mine is less beautiful but
alias off='shutdown -h now' alias update='flatpak update -y ; flatpak remove --unused --delete-data -y ; distrobox upgrade --all ; rpm-ostree update' alias upfin='update ; off'My firmware is write-protected so fwupd is not in there.
doas apk -iU upgradeAn Alpine user, cool! What is it like to use it as your primary desktop OS? I have only played around with it on servers or in VMs and containers.
still in the setup phase and running LabWC rather than a full desktop – but actually rather enjoying it and have been stumbling across a lot of cases finding out that even with a GUI installed, terminal programs do just as good a job if not better than their graphical counterparts (ex. I don’t think I’ll ever be a full vim/emacs convert, but for basic text editing, nano does just as well as mousepad/leafpad/featherpad/xed/gedit)
You could give helix a try, feature/functionality wise it’s almost vim, but with 0 config needed and all commands easily discoverable which is closer to nano.
As someone who really tried to get into modal editors, both emacs and vim, for years, it was the first one where i was reasonably fast after a short time and it was easy to discover the keybindings.
I don’t use an alias, as the command to update is pretty small to begin with.
I don’t, because stuff like that is a little too touchy to wrap in a cute shell alias. If I’m going to update a box, I’m going to update a box. If I’m going to reboot a machine, I want to be reminded that I’m going to reboot a machine (which in turn is a reminder that there are other people using stuff there and not to fuck their days up without at least a little warning).
It’s just bunch of commands run with a single call, an automation. As long as I know exactly what each command is doing and if I wrote the alias myself, then I think its not a problem. What problem do you see with an update-alias such as I did there? The update-command does exactly that, it updates the box with all relevant package managers.
However if other people are also using the box, then its obviously a different situation. I wouldn’t want to be reckless in the operation either; respect other users, even if you can do whatever you want.
It’s not that. It’s not getting complacent by eliding the semantics of what you’re doing. It’s being consciously aware that you’re doing something that could possibly fuck stuff up.
In fact typing these commands by hand all the time won’t save you from a fuck stuff up anyway. The update-alias is the exact same command I would have typed. In fact, as an alias its less likely to make a typo and fuck stuff up. I’m doing this since 2008, when I started with Linux, and named it always “update”.
Using the update command I’m always aware it changes the system. Not at least because I also often expand the alias to its full command with a shortcut (update will be replaced in the terminal with the actual commands), I also see what the output of the commands. And without my password it wouldn’t do any system changes anyway.
So typing these commands everything out won’t be safer, as you suggest.
#!/usr/bin/env dash set -e cd $HOME/nixcfg # flake inputs to update for input in nixpkgs nixos-hardware home-manager hosts; do nix --extra-experimental-features flakes --no-warn-dirty flake update $input done # rebuild NixOS nixos-rebuild --use-remote-sudo switch --keep-going --fallback --flake $HOME/nixcfg#$(hostname) # check for firmware upgrades fwupdmgr get-updates # print hard drive status info sudo smartctl -H /dev/nvme0n1 sudo zpool status -v -x
