Happy to help!

Awesome! Glad it worked. I’m no expert regarding the battery, but it should be okay. Lots of people use laptops as servers with them plugged in all the time. Just keep an eye on it and if you see any signs of swelling or excessive heat, pull and/or replace the battery.

Goid luck!!

That’s the process I’ve used when switching machines for seeding, and it works great, just takes time for it to recheck all the files.

On the Mac, open qbittorrent, select all torrents in the client, and export them as torrent files or magnets, whichever you prefer.

Copy all the torrent/magnet files to a thumb drive or something and copy them to the elementary laptop.

On the elementary laptop, start without an internet connection. Connect the external drive with all the downloaded files, mount it if elementary doesn’t auto mount it, and note the path.

Open qbittorrent.

Set the default save path in qbittorrent to the path of the mounted drive with all of your downloaded files.

If you want to do it in bulk, now add all the torrent files to QBittorrent. You may have to verify the file location for the torrents to make sure it sees the files on the drive.

Once you’re certain all the loaded torrents are pointing to the save path for the files, you can close qbittorrent, connect the laptop to the internet, and relaunch qbittorrent.

It should verify all the files it finds for the torrents, which can take some time if you have a lot of torrents, and once verified it’ll automatically start seeding

For me it’s Perl’s rename, which of course cones in a variety of package names depending on the distro you use. In trying to find a link, I landed on this stack exchange answer that gives a great overview of how the tool works and the different packages available on different distros.

I have to bulk rename files every day, and using regex and the other features of Perl’s rename makes it so much easier to do.

WHY THE FUCK DIDN’T YOU ADD .ENV TO .GITIGNORE YOU FUCKING DONKEY!?!?!

I was wondering the same

Ytdlp works with Spotify too iirc, and there are Spotify downloaders out there too.

That hardy heron wallpaper went hard. Takes me back too. Damn.

Git

I’d encourage learning. The more you understand the better you can control your data and maintain your services. You don’t need to be an expert but I’d encourage working towards relying less on gpt.

wg-easy is what you want

DOWN:

I’m currently fighting with my OliveTin config file. I added a simple new config for a button action and ylthe whole thing just shit the bed. Now OliveTin won’t load at all. Even after removing the new config. Stupid yaml.

UP:

After reading the Jellyfin docs and their Hardware Encoder Quality section which states

Apple ≥ Intel ≥ Nvidia >>> AMD*

I decided to spin up a test server on the m1 mini that’s been sitting unused in my basement for a couple of months now to see if I can get better performance out of jellyfin on the m1 vs where it’s running currently, which is on an i7 Intel that’s going on 10ish years old now.

I also spun up baserow and directus containers to see which one I want to use for my database needs.

Audiobookshelf for sure. It handles audiobooks fabulously, and it also does handle ebooks.

I use it to manage my eBook library, but not as the reader. You can set up a “send to ereader” option to email the ebooks to your reader of choice. So I just shoot them off to my pocketbook ereader when I want to read one.

Another for radicale. Been using it for years now. Its great.

Same here. luks encrypted drive in my work locker.

Right now I sneaker net it. I stash a luks encrypted drive in my locker at work and bring it home once a week or so to update the backup.

At some point I’m going to set up a RPI at a friend’s house, but that’s down the road a bit.

You could. I didn’t even think about it. I’m used to using dd, but clonezilla is a totally viable option here.

No worries! Happy to help, and the instructions will work with the HDD, just use the HDD/boot as the in. I shouldn’t have assumed the existing boot was an ssd. Good luck!!!

If you want to clone the existing system onto the new ssd, here’s the broad strokes of what you can do.

1. Get a usb stick and write your linux distro of choice to it. Doesn’t really matter which one, we’re just using this to clone the system drive to the new drive. You want the system drive to be totally inactive during the clone which is why you’ll do it from a live usb rather than with the system itself booted.
2. shut down the system
3. Install the new ssd. DO NOT REMOVE THE CURRENT SYSTEM/BOOT SSD. You should now have two ssds installed.
4. If you can’t install the second ssd, plug it in to usb via an enclosure
5. Boot from the live usb
6. open the terminal
7. run lsblk and note the /dev/sdX path of the system drive. Write it down.
8. From the same output, note the /dev/sdX path of the new ssd. Write it down.
9. Use the dd command to clone the system drive to the new ssd. The command will look like this:

`dd if=/dev/existingBootDrive of=/dev/newSSDDrive bs=8M status=progress oflag=direct’

This command will clone the exact data of the system drive to the new ssd. the if portion of the command stands for in file, as in the source of the data you want to clone. Make sure that is your existing boot drive. of is the out file, the destination of the clone. Make sure that is your new ssd.

When you do this, the new drive will appear to be the same size as the old drive. This is due to the cloning, but is easily resolved by resizing the partition(s). How you do this depends on the filesystem, so refer to this guide for resizing

10. Once you’ve resized the partition/disk, double check the partition UUIDs on the new ssd against what’s in /etc/fstab on the new disk. To do this, run blkid to get a list of all the partitions and their UUIDs. Note the UUIDs of the partitions on the new ssd.
11. To check /etc/fstab, you’ll have to mount the root (/) partition of the new drive somewhere in the live system. In the terminal you should already be in the home folder of the live system user. Make a new directory with mkdir. Call it whatever you want. So something like: mkdir newboot
12. run lsblk and make note of the root partition on the new ssd, then mount that to newboot (or whatever you called it) with sudo mount /dev/sdX newboot (where X is the actual device label for the root parition of the new drive`
13. open /etc/fstab with your terminal text editor of choice. Compare the UUIDs to the ones you noted. If they are the same, you’re golden (they should be the same, but I’ve also had them change on me. ymmv). If they are different, delete the old UUID and replace it with the new UUID for each respective partiiton
14. Shut down the system
15. Remove the old boot drive, and install the new boot drive in it’s place
16. Boot the system. If all goes well, you’ll boot right into tumbleweed as if nothing has changed except you’re running from your shiny new ssd
17. If it doesn’t boot, boot again from the live usb, and again check the UUIDs to make sure there were no mistakes
18. Keep the old SSD unmodified in case you need to revert back to it.