Yes — make a shell function/alias so you never retype it:

# in ~/.bashrc (or ~/.zshrc)
runbg() { "$@" >/dev/null 2>&1 & disown; }
alias tb='runbg thunar'

Then tb ./hello.txt launches Thunar in the background with all output silenced.

What's happening:

• >/dev/null throws away stdout
• 2>&1 redirects stderr to the same place
• & backgrounds it
• disown removes it from the job table, so it survives closing the terminal (with plain &, closing the terminal can kill the app via SIGHUP)

Tip: if you only want to see errors but not chatter, use >/dev/null without the 2>&1 part. And for apps that print to the journal instead, journalctl --user -f shows their logs after the fact.

Well I could. But copying several thousand small files back and forth just takes ages. So I was hoping there was some smart way to just repair some underlaying error.

But novice or not, it would be the most straight forward way to fix it. So thank you for your suggestion! If nothing else works I will have to anyway haha.

I’m just an old seasoned Linux user, which has tainted me with an attitude of never taking the easy solution :p

I am a real Linux novice, so this might not be the best advice, but why not just remove the partition and repartition it?

That's perfect, thanks.

their wiki has a page on switching gpu vendor
https://wiki.cachyos.org/features/chwd/gpu_migration/

With Linux you'll run into more of "the drivers for this old hardware are shit" moreso than it won't work. But what you have isn't even remotely old. You'll be fine. CachyOS should work just fine.

And yea, I already installed it in a VM and it worked well as soon as I gave it more than the default 2GB RAM. I know that should really have answered my question, but like I said.. cold feet.

OK, I got the idea Catchy was unfriendly to older tech from this article.

Maybe I misunderstood or the info is out of date. I got cold feet when the provided terminal command returned "Not Supported" for my CPU . Perhaps I didn't run that correctly.

grep -o 'x86-64-v3' /proc/cpuinfo && echo "Supported" || echo "Not Supported"

anything core 2 duo/quad or newer will work fine, you only need newer processors if you'd like to make use of the optimized packages..

No lol wtf

I once tried running Cachy on a first-gen i7 from 2009. It seemed to run fine, though obviously couldn't take advantage of the newer instruction sets.

Best bet is to try running from a live USB. If it boots, you'll be able to check its compatibility with all your components.

If it's running as a snap, you might be able to configure snap to allow access; I'm not sure how to do that though -- I moved to Mint because I didn't want to deal with snap crap...

Doing some searching, I found this reddit thread which suggests that some of the distro shipped qbtorrent versions aren't very good; people there suggest using the developer's PPA on Ubuntu instead. The developer's site includes instructions for alternate ways to install on various Linux distros.

You could try uninstalling the version you have and then running:

sudo add-apt-repository ppa:qbittorrent-team/qbittorrent-stable
sudo apt-get update && sudo apt-get install qbittorrent

if you're comfortable with the security implications of using their PPA.

What’s you network topology? Wired or WLAN? Switches, hubs, routers, repeaters, encryption, APs, nominal speed? If WLAN, how’s the signal, how many other devices, etc. Networking is complex…

I think this is circling the issue.

For what it's worth, the problem in the linked thread was Flatpak/snap apps that are sandboxed so that they can only access files and folders in your home directory.

Are you running the downloader as a sandboxed/containerized app? (Flatpak, snap, etc.)? Those can have weird issues with accessing the file system due to the isolation they implement to try to make things more secure.

This is the closest I've come to what might be the issue, but it doesn't necessarily bring me close to solving it. I installed using sudo apt-get install qbtorrent. I'm on ubuntu at the moment, but I don't stick with any distro for long. I've used pop-os, fedora, ubuntu, mint, kde.

I needed ubuntu on this machine because I needed specific versions of ROCm and other packages which would support the 395+ chip/ chipset.

Are you running the downloader as a sandboxed/containerized app? (Flatpak, snap, etc.)? Those can have weird issues with accessing the file system due to the isolation they implement to try to make things more secure.

Depending on which distro you're running, you might also check to see if there's something going on with SELinux or AppArmor; sometimes those security features, though well-intentioned, can cause cryptic problems. I think you should see an error in dmesg if something like that is going on.

Another thought is that maybe you can try mounting the NAS yourself via command line with the mount command to a simpler path (e.g. to /mnt/nas) rather than using GVFS via the GUI (with it's complicated auto-generated path) in case the download software is doing something dumb with path handling?

I guess I could try another machine on the network? Thats pretty much exactly what I do. I have it mounted as 'network-share'.

It just does not work.

Another example of someone having this issue: https://github.com/arvidn/libtorrent/issues/7763

I mount my nas to /media and then can choose that as a destination with qbitorrent. Was zero issue so it sounds for sure like a quirk of your system.

Yeah I only use them sparingly, and usually I'm just downloading to my local client.

This is basically the issue from 2 years ago on lvl1tech forums:

https://forum.level1techs.com/t/its-2024-why-cant-i-easily-save-torrents-to-a-share-drive/206022

There’s plenty of ways to make it happen. Odd that you’re having an issue at all - does your torrent client just not like network mounts?

You can always use a symlink/hard link to the network device, then your client will only see a local path.

This is exactly how I would have expected it to work. I've tried every client I could (qbTorrent, deluge, transmission, might have been a few more). I tried hard links, smb, yep. All of it. And the deeper I went the more of an issue it seemed to be. I genuinely can-not comprehend how a torrent client wouldn't just work with a network drive. I stopped trying to fix the issue because I'm now downloading the torrent using my NAS client (again, NOT my preferred approach. I don't want my NAS doing anything other than being a NAS).

I haven't used torrents in a very, very long time, but that seems rather odd to me considering everything else I can do with network mounts... How are you mounting the NAS, and what sort of problem/errors are you encountering?

There's plenty of ways to make it happen. Odd that you're having an issue at all - does your torrent client just not like network mounts?

You can always use a symlink/hard link to the network device, then your client will only see a local path.

I've done this in Windows forever because unlike Linux, Windows apps have historically been picky about network shares (not all, but many, especially in the 90's). Linux stuff usually is a lot more flexible with paths, which is why I'm perplexed you're seeing this issue today.

What's your setup? Do you have a NAS? What network access does it use/are you using? Samba? NFS?

Some details about the setup will help us see where it's potentially going sideways

My hypothesis:

• Someone in Epstein's circle had to be the IT guy.
• That IT guy wanted to have the Bash documentation locally (which is sensible, I do too).
• A discovery subpoena might request "all documents referencing (something)", which boils down to an extremely loose string search, and the documents' relevance to the case are determined later.
• The Bash documentation was caught by the algorithm because it contained some word they were searching for.

For all we know, the lawyers might've been looking for the word "child" and the algorithm found "child processes".

Yes, I've finally found that exact copy/paste workaround.

Still, who guesses that tapping on a link might not work? 🤔

Nah, I've got no issue accessing the pdf. I'm using the piefed web frontend on desktop.

It seems like the issue is that link shouldn't be parsed as a pdf file, but rather as an html document, so that it can do age verification, after that, it should redirect you to the PDF.

You might be able to open it on mobile by copy pasting the link to your mobile browser, so you can get past the age verification