BTRFS can work across multiple disks much like ZFS. It supports RAID 0/1/10 but I can’t tell you about performance relative to ZFS.

Just be sure you do NOT use BTRFS’s RAID5/6. It’s notoriously buggy and even the official docs warn that it is only for testing/development purposes. See https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices

Edit: Another interesting thing to note between the two file systems is deduplication. ZFS supports automatic deduplication (although it requires a lot of memory). BTRFS supports deduplication but does not have built-in automatic dedup. You can use external tools to perform either file-level or block-level deduplication on BTRFS volumes: https://btrfs.readthedocs.io/en/latest/Deduplication.html

Good advice!

This is also available with BTRFS. Personally I am leveraging this feature via Snapper, simply because it was the default on OpenSuse and was good enough that I never bothered looking into alternatives. I’ve heard good things about Timeshift, too.

This has saved my butt a couple times. I’ll never go back to a filesystem that doesn’t support snapshots.

I really liked ZFS when I used it many years ago, but eventually I decided to move to BTRFS since it has built-in kernel support. I miss RAIDZ, though. :(

If you got a problem, reinstall and do the same stuff again, you’ll almost certainly get the same problem again

Sure, but nobody’s likely to do that. If I wiped my system now, I doubt I could get it back to exactly the same state if I tried. There are way too many moving parts. There are changes I’ve forgotten I ever applied, or only applied accidentally. And there are things I’d do differently if I had the chance to start over (like installing something via a different one of the half-dozen-or-so methods of installing packages on my distro).

For example, I have Docker installed because I once thought a problem I had might have been Podman-specific. Turned out it was not. But I never did the surgery necessary to fully excise Docker. I probably won’t bother unless and until there is a practical reason to.

They have a big IRL ad campaign in major US cities. See https://mullvad.net/en/blog/advertising-that-targets-everyone

These ads certainly aren’t the worst, but they’re still a bit misleading. Using a VPN is not going to prevent tracking in general. Your phone apps will still send GPS data to all the same places. Web sites will still use all the same cookies. Facebook is still gonna be Facebook. 🤷

That said, Mullvad does include domain-based ad and tracker blocking with their DNS server (which is free and available to the public, btw), and that’s also optional on the VPN, so it does help to a point.

(Pinging @countrypunk@slrpnk.net to avoid double-replying. )

Sure. I’m referring to the ones that run big ad campaigns, like Nord and Mullvad. They tend to overstate how a VPN can protect you, sometimes in ways that barely make sense. There is no epidemic of criminals stealing personal credit card information over insecure wi-fi, for example. The ads play into ignorance and fear.

That said, yeah, I’d rather be on a VPN when on a public wi-fi network. But I’m not really worried about someone sniffing my encrypted HTTPS traffic (which is pretty much everything nowadays; Firefox by default won’t even load unencrypted web sites).

Some VPNs allow multi-hopping, similar to Tor. I couldn’t give you an exhaustive list but most popular ones support this. Mullvad and Proton do, for example. There are also strategies to add noise into VPN traffic.

This is not a silver bullet, of course. Tor has similar problems as you describe if an adversary has visibility into enough nodes. As always, this comes down to your threat model.

On the one hand, I find the advertising of VPNs outright dishonest. On the other hand, I would trust any reputable VPN provider much more than I trust my ISP or cell carrier.

Great points, thanks.

Can you clarify what you mean by “local decryption”? I thought Proton and Tuta work pretty much the same way, but perhaps there’s a distinction I’m missing.

One thing I like about Tuta is that it has the option to cache your messages in localstorage in your browser so you can do full-text search. FWIW, I think Proton added a similar feature recently, though I have not tried it. I imagine neither would work very well with large mailboxes; probably better to configure a real email client.

Do they offer cloud storage now? From what I can see on their web site, it’s 500GB…just for email. I mean sure, that’s cool, but it would take me several lifetimes to accumulate 500GB of email so it’s not much of a selling point to me.

It’s a good email service, anyway. I’ve been using the free tier for a few years. Similar to Proton, and in theory Tuta is more private because they encrypt the headers as well as the message body.

btrfs’s RAID features are not production-ready, and at this point I doubt they ever will be. See:

https://en.wikipedia.org/wiki/Btrfs#Implemented_but_not_recommended_for_production_use

https://wiki.archlinux.org/title/Btrfs

https://www.phoronix.com/news/Btrfs-Warning-RAID5-RAID6

ZFS is definitely more robust.

This is called a “15-minute city”.

Something like for-jay-yo.

From https://forgejo.org/faq/ :

Forgejo (pronounced /forˈd͡ʒe.jo/) is inspired by forĝejo, the Esperanto word for forge.

I recently upgraded to a 7900 XTX on Debian stable, as well. I’m running the newest kernel from Debian’s backports repo (6.6, I think), and I didn’t have that same problem.

I did have other problems with OpenCL, though. I made a thread about this and solved it with some trouble. Check my post history if you’re interested. I hope it helps. I can take a closer look at my now-working system for comparison if you have further issues.

IT WORKS NOW! I will need time to run additional tests, but the gist of my solution was:

1. Backport llvm-18 from sid following the guide you linked at https://wiki.debian.org/SimpleBackportCreation

2. After compiling and installing all those deb files, I then installed the “jammy” version of amdgpu-install_6.0.60002-1.deb from https://www.amd.com/en/support/linux-drivers

3. Downloaded the latest kernel sources from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git, and simply copied all the files from its lib/firmware/amdgpu folder into my system’s /lib/firmware/amdgpu. Got that idea from https://discussion.fedoraproject.org/t/amdgpu-doesnt-seem-to-function-with-navi-31-rx-7900-xtx/72647

4. sudo update-initramfs -u && sudo reboot

I’m not totally sure it step 3 was sane or necessary. Perhaps the missing piece before that was that I needed to manually update my initramfs? I’ve tried like a million things at this point and my system is dirty, so I will probably roll back to my snapshot from before all of this and attempt to re-do it with the minimal steps, when I have time.

Anyway, I was able to run a real-world OpenCL benchmark, and it’s crazy-fast compared to my old GTX 1080. Actually a bigger difference than I expected. Like 6x.

THANKS FOR THE HELP!

Thanks for the links! I’ve never attempted making my own backport before. I’ll give it a shot. I might also try re-upgrading to sid to see if I can wrangle it a little differently. Maybe I don’t actually need mesa-opencl-ics if I’m installing AMD’s installer afterwards anyway. At least, I found something to that effect in a different but similar discussion.

Update: I upgraded to Sid. Unfortunately, mesa-opencl-icd depends on libclc-17, which uninstalls -18. So I can’t get OpenCL working while the correct libclc is installed.

No idea where to go from here. I’ll probably restore my Bookworm snapshot, since I don’t want to be on Sid if it doesn’t solve this problem.

Update: Running amdgpu-install did not provide those files. There were a few errors regarding vulkan packages when I attempted, I guess because it’s assuming Ubuntu repos. Trying with just opencl and not vulkan succeded, but still clinfo reported the missing files.

I don’t think I can get this working without a whole newer llvm.

Ah, somehow I didn’t see 18 there and only looked at 17. Thanks!

I tried pulling just the one package from the sid repo, but that created a cascade of dependencies, including all of llvm. I was able to get those files installed but not able to get clinfo to succeed. I also tried installing llvm-19 from the repo at https://apt.llvm.org/, with similar results. clinfo didn’t throw the fatal errors anymore, but it didn’t work, either. It still reported Number of devices 0 and OpenCL-based tools crashed anyway. Not with the same error, but with something generic about not finding a device or possibly having corrupt drivers.

Should I bite the bullet and do a full ugprade to sid, or is there some way to this more precisely that won’t muck up Bookworm?

Can you explain more about your workflow? Do the Nix packages have their own isolated dependency resolution? How does it work when Debian packages depend on a library you get from Nix, or vice-versa?

Thanks, that’s good advice. There are lower-numbered gfx* files in there. 900, 902, 904, 906. No 1030 or 1100. Same after reinstalling.

Looks like these files are actually provided by the libclc-15 package. libclc-16 has the same set of files. Even libclc-17 from sid has the same files. So I guess upgrading to testing/unstable wouldn’t help.

apt-file search gfx1100-amdgcn-mesa-mesa3d.bc yields no results, so I guess I need to go outside of the Debian repos. I’ll try the AMD package tonight.

Thanks! I didn’t see that. Relevant bit for convenience:

we call model providers on your behalf so your personal information (for example, IP address) is not exposed to them. In addition, we have agreements in place with all model providers that further limit how they can use data from these anonymous requests that includes not using Prompts and Outputs to develop or improve their models as well as deleting all information received within 30 days.

Pretty standard stuff for such services in my experience.