brickfrog

On Debian the older Nvidia GPU would still work fine with the default Nouveau driver (open source non-Nvidia), I think(?) it'd be the same on Kubuntu/Ubuntu. Since it was an upgrade maybe you just need to re-enable Nouveau on your system? It's not something I've ever done but doing a quick online search came up with some instructions here https://gist.github.com/vredchenko/42381e9cff3f1e162cb47cfd6479c459 , it looks more or less correct I'd just double-check before rebooting that Nouveau is not being blacklisted in /etc/modprobe.d

You could try that & see how it goes before doing anything more drastic. You're not going to do any heavy gaming with Nouveau but it should handle day-to-day tasks fine.

Like the other comment mentioned I'd try https://www.cgsecurity.org/wiki/PhotoRec first.

Just a heads up with proper data recovery it's usually a good idea to dump an image of the media card to your drive and do any data recovery attempts against that image, not the media card itself. I would usually use ddrescue for that but you'll probably be okay with standard dd too if the card itself is fine (as you said the deleted files were user error, not a failing card).

PS - You should definitely not use the media card in the camera until you're done with recovery attempts, the more you use it the less likely you'll recover anything off it.

At the very bottom is a menu with an entry called “Instances”. Click that to see lists of linked and blocked instances.

Just FYI that does not tell .world members about which communities lemmy.world admins block. Whether on purpose or accidental lemmy.world admins are a bit secretive about which communities they block, there is no published list anywhere I could find. If you find one let me know but AFAIK it does not exist.

So per your example .world members can see that instances are linked and federated (including dbzero) but there's no indication about any blocked communities on those linked instances.

You would need to view the instance directly, not through lemmy.world due to the lemmy.world admins blocking it. I'm not sure if lemmy.world admins block links to it too but if you need a link look up all the Lemmy instances at https://lemmyverse.net/?order=active

Divisions by zero is currently the 7th most active Lemmy instance.

From there you'd just have to decide if you want to create an account at that instance itself, or just create an account at a different Lemmy instance that isn't blocking piracy communities. I think lemmy.world admins may be the only ones actively blocking piracy communities.. I haven't heard of other admins at other instances doing that.

I'm on Debian but have been using GNOME with its built-in RDP server since it's Wayland compatible.. But before I did that I had also set up XRDP so here's a few ideas :)

I just installed Debian with XFCE. I installed XRDP but for the life of me I cannot get it working.

Are you using XFCE with Wayland or X11? XRDP currently only works with X11. Make sure the user you are using to RDP with is able to log in normally with XFCE + X11 before attempting RDP.

Also RDP logins only work with Linux users that are not currently logged in at the desktop so make sure you're logged out before testing.

Also double-check that the xrdp.ini file looks right, particularly the incoming port it is configured to use. (on Debian it is in /etc/xrdp/xrdp.ini). When I initially configured XRDP the port setting was strangely configured, it was set with port=vsock if I remember correctly and that wasn't working.. I had to change it to a regular port number. Also consider changing the port number if necessary, I had to change mine but only because Gnome's own RDP server was already using the default port 3389. (if you change xrdp.ini settings make sure to restart the xrdp service)

Also double-check that the XRDP service is active and running (sudo systemctl status xrdp) - on my end the service would stop running when the port number config was wrong which meant it was no longer listening to incoming connections.

You don't need to but #1 could be a bit easier if you prefer multiple torrent clients/instances for organization. qBittorrent / Deluge can run multiple instances so you could have like qBittorrent "A" instance pointing to your internal SSD and qBittorrent "B" instance pointing to your external HDD. That's just a quick example but I'm sure Transmission and other torrent clients can do the same.

The only tricky bit with multiple torrent clients is that they'd each need their own incoming connection port if you intend to be fully connectable (port forwarded). That may not be feasible if you're using a VPN that only gives you 1 port forward but otherwise it's doable, depends on your setup.

In qBittorrent what is the Status of DHT, PeX, LSD when you click on the torrent and click its Trackers tab?

I’m on CGNAT

Your own torrent peer is not and cannot be connectable (port forwarded), unfortunately.

Not sure if you'll be able to get much improvement, it'll always be slow or impossible depending on the amount of connectable peers in the torrent swarm. But you should be seeing okay-ish speeds if the torrent you're trying to download has tons of connectable peers. Does the torrent you're downloading have a lot of seeds/leeches on it?

PS - If you're saying everything usually works fine then something changed, could try restarting your internet router just to rule that out.

Most AppImage files are full compiled applications on their own, no need to "install" anything. Just run them directly to start the application.

You may need to expand in your post what it is you're doing exactly? Or maybe you downloaded the one Appimage that is an installer for something and it is designed to remove itself after installation? Doubt that is what is happening but can't entirely rule it out.

CPU: socket LGA1200 era Intel Celeron

DRIVES: 4 SATA, 1 PATA, 2 NVME

Just wanted to mention that PATA hard drive may need to sit this one out, depends on whether you want to buy more stuff beyond a motherboard. LGA1200 means you're using motherboards built from roughly 2020+, it would be highly unusual to find a motherboard with a PATA port in this decade or even last decade. So to use that drive inside the server you're looking at buying some type of adapter (I've seen PATA-to-SATA adapters but can't vouch for any in particular) or a PCIe card with PATA ports if those exist. Or to use it externally you'd have to hunt around for an old IDE-to-USB enclosure or some other type of USB adapter to have the drive sit outside the server.

I have a few old PATA drives myself but actively using them seems like more trouble than it's worth

The link is from February 1st, about a blog post in January. I clicked here thinking Bitwarden just raised their subscription price again haha.

The last ancient USB to PATA only adapter I once had did actually support SMART stats, but apparently the adapter’s firmware didn’t support drives over 128GB

So close, you almost had it!

Same, been thinking of just keeping an eye out at thrift stores and such for an antique USB drive enclosure.. one that isn't a Maxtor OneTouch, heh. Or maybe my idea of a janky PATA-to-SATA connected to SATA-to-USB will actually work for SMART info by some miracle.

If I had more space for storing old tech I'd maybe just adopt or buy an ancient desktop that actually has PATA ports in it. I've actually seen them come up on Craigslist, like ancient Compaq desktops from back in the day before SATA existed.

Your post title and post body are asking for two different things :P Tons of SATA to USB adapters and drive enclosures work well on Linux, that part isn't too difficult.

But what you probably want is one that has both UASP support and TRIM support for best SSD support. Here's the tricky part, even if the adapter or drive enclosure has TRIM support that doesn't mean it was auto enabled in the Linux system it was plugged into. Often times Linux can't tell if an adapter or drive enclosure has TRIM support so the safe thing to do is to not enable it by default. That means you can see the drive supports TRIM, hdparm says the drive supports TRIM, yet when you run fstrim it still complains that TRIM isn't supported.

Take a look at

https://wiki.archlinux.org/title/Solid_state_drive#External_SSD_with_TRIM_support

and https://glump.net/howto/desktop/enable-trim-on-an-external-ssd-on-linux

If you already have an external adapter or enclosure that claims TRIM support but it isn't working in Linux maybe try to enable TRIM and see how it goes?

For what it's worth I do have a drive enclosure, with ASMedia ASM1351 chipset, that claims TRIM and UASP support but by default fstrim still won't run TRIM on any drives inside it. If I get some free time maybe I'll see if I can get Debian to enable TRIM on the device just for testing but it could be a bit.

EDIT: Confirmed the instructions in archlinux seem to work and I was able to temporarily enable TRIM on my external drive enclosure to successfully run fstrim on an SSD inside it. I only did a quick test, setting provisioning_mode to "unmap" so it'll lose TRIM configuration once I disconnect the drive or restart the system. You'll probably want to go the extra step and set up udev rules to keep it enabled.

Tested on Debian with a Startech S251BMU313 (USB 3.1 enclosure for 2.5" SATA drives with ASMedia ASM1351 chipset). In theory the archlinux instructions should work with any external USB adapter or enclosure with TRIM support.

Also note the instructions are a bit confusing, I did notice that running sg_readcap immediately resets the configuration in provisioning_mode so in my case I had to avoid re-running sg_readcap after enabling "unmap".

EDIT2: Forgot one important tidbit :P for whatever reason the actual echo "unmap" command in archlinux would not work for me, I think you may need to have root permissions to actually do that? Instead I ran this with my non-root admin user:

echo unmap | sudo tee /sys/block/sdX/device/scsi_disk/*/provisioning_mode

Replace sdX with the drive device you're working with. I'm not entirely sure why the above command works for me in Debian, and not the archlinux version, but figured I'd document it here just in case.