• 1 Post
  • 15 Comments
Joined 1 year ago
cake
Cake day: June 18th, 2023

help-circle







  • I used tmsu (“tag my shit up”) for a while, but it required too much discipline and then I dropped it.

    In addition, tools like fzf for fuzzy file-search (comes with shell integration to e.g. replace the default history search in bash) and ripgrep-all made this kind of organization unnecessary for me. It now suffices to have a vague idea where a thing is located and I can do a brute-force search in a few seconds.

    The next-level filesystem argument is brought forward every few months, but I’m not buying it.



  • Just so that you have an additional data point, here’s how I do it.

    I run a backup first, using borg-backup. I used rsync in the past, then rsnapshot and now borg since it allows for compressed incremental backups, diffing on the “chunk” level, meaning I won’t backup the entirety of a modified file again and safe a lot of space.

    I used yay before, but like you I didn’t want to go into it blindly and do some modicum of sanity-checking the PKGBUILD for changes beforehand. Since it wasn’t obvious on what would be the best way of using yay for doing this, I asked around on the ArchLinux Forum, and ultimately decided to try one of the simpler tools suggested in the Arch Wiki, aurutils.

    After setting it up (the author helped me migrate), I now use it as follows:

    • aur repo --upgrades: Searches for new versions of aur packages and displays them
    • aur sync --upgrades --no-build: Performs a git-pull under ~/.cache/aurutils/sync and opens vifm so that I can look at a diff of the PKGBUILD and all the other changes in the affected directory.
    • aur sync --upgrades --no-view: Builds the package. It is now available as part of the custom (local) repository used only for aur packages, but hasn’t been upgraded yet. That is, a package.tar.gz or whatever has been created and put into ~/.cache/aurutils/sync/, where the PKGBUILD resides as well
    • sudo pacman -Syu: Upgrades all packages from all repositories, including the ones from the custom repository

    I won’t argue pro or against one aur helper or the other, but I feel like I have a little more insight about what happens under the hood since I made the switch. That being said, in the very beginning, I managed aur packages manually. This works also, but at some point became too tedious for my taste. I am happy with the semi-automatic approach I am using now.



  • Although the relevant links have already been provided, the gist is

    • Acme stands for some “generic” editor here, where you have to use the mouse a lot, which is perceived as slow
    • Emacs is known to be very powerful (to the extend of being called an “OS with a bad editor”), but using unergonomic keyboard shortcuts
    • Vim is an editor that has been designed for keyboard power users in mind, but which has the reputation of being difficult to learn


  • mbw@feddit.detoMemes@lemmy.mlI miss forums
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    11 months ago

    It was 2006 or 2007 when I sent a girl from my class a funny pdf.exe on ICQ, which simply restarted her computer when she started it. I didn’t know that she would lose a whole day’s work that way, but eh what are you gonna do if programs don’t have autosafe.

    Also, anyone remember “dialers”? Fun times.




  • Then again, I’m not sure if for servers, Debian is still as important as it used to be. I’m probably overly generalizing, but often all you need is a few daemons installed natively (SSH, Docker, firewall), and your reverse proxy and any services are then managed e.g. via docker compose.

    There are variations on this, but with the fraction of packages installed via the distro’s package manager having become smaller like that, what distro you use for a server should not impact your QoL as severely as it used to I think.

    Your point about desktop usage still holds of course.