I've used Seafile for years just for this. I haven't ran that on pi, but on virtual machine it runs pretty smoothly and android client is pretty hassle free.

I want to prevent myself from reinstalling my system.

Any even remotely normal file on disk doesn't stop that, regardless of encryption, privileges, attributes or anything your running OS could do to the drive. If you erase partition table it'll lose your 'safety' file too without any questions asked as on that point the installer doesn't care (nor see/manage) on individual files on the medium. And this is exactly what 'use this drive automatically for installation' -option does on pretty much all of the installers I've seen.

Protecting myself from myself.

That's what backups are for. If you want to block any random usb-stick installer from running you could set up a boot options on bios to exclude those and set up a bios password, but that only limits on if you can 'accidently' reinstall system from external media.

And neither of those has anything to do on read/copy protection for the files. If they contain sensitive enough data they should be encrypted (and backed up), but that's a whole another problem than protecting the drive from accidental wipe. Any software based limitation concerning your files falls apart immediately (excluding reading the data if it's encrypted) when you boot another system from external media or other hard drive as whatever solution you're using to protect them is no longer running.

Unless you give up the system management to someone else (root passwords, bios password and settings...) who can keep you from shooting yourself on the foot, there's nothing that could get you what you want. Maybe some cloud-based filesystem from Amazon with immutable copies could achieve that, but it's not really practical on any level, financial very much included. And even with that (if it's even possible in the first place, I'm not sure) if you're the one holding all the keys and passwords, the whole system is on your mercy anyways.

So the real solution is to back up your files, verify regularly that backups work and learn not to break your things.

Mullvad (apparenlty, first time I've heard from the service) uses DNS over TLS and I don't think that the current GUI version has the option to enable it. Here's a quickly googled howto from Fedora on how to enable it on your system. If that doesn't help search for 'NetworkManager DOT' or 'DNS over TLS'.

Dd. It writes on disk at a block level and doesn't care if there's any kind of filesystem or raid configuration in place, it just writes zeroes (or whatever you ask it to write) to drive and that's it. Depending on how tight your tin foil hat is, you might want to write couple of runs from /dev/zero and from /dev/urandom to the disk before handing them over, but in general a single full run from /dev/zero to the device makes it pretty much impossible for any Joe Average to get anything out of it.

And if you're concerned that some three-letter agency is interested of your data you can use DBAN which does pretty much the same than dd, but automates the process and (afaik) does some extra magic to completely erase all the data, but in general if you're worried enough about that scenario then I'd suggest using an arc furnace and literally melting the drives into a exciting new alloy.

Bare feet are a bit clickbaity on the headline. That alone doesn't mean much, but when it happens on a area where you should have full protective gear at the (supposed to be) sterile part of the manufacturing it's of course a big deal. But it would be equally big deal if you just stroll there in your jeans and t-shirt with boots you stepped on a dog shit on your way to work. And even then it's not even close of being the biggest issue on manufacturing where they constantly ignored all of the safety protocols, including ignoring test results which told them that the product is faulty.

I'd say that single core performance and amount of RAM you have are the biggest issues with running anything on old hardware. Apparently, in theory, you could run even modern kernel with just 4MB of RAM (or even less, good luck finding an 32bit system with less than 4MB). I don't think you could fit any kind of graphical environment on top of that, but for an SSH terminal or something else lightweight it would be enough.

However a modern browser will easily consume couple gigabytes of RAM and even a 'lightweight' desktop environment like XFCE will consume couple hundred MB's without much going on. So it depends heavily on what you consider to be 'old'.

The computer at garage (which I'm writing this with) is Thinkstation S20 I got for free from the office years ago is from 2011. 12GB of RAM, 4 core Xeon CPU and aftermarket SSD on SATA-bus and this thing can easily do everything I need for it in this use case. Browsing the web on how to fix whatever I'm working with at the garage, listen music from spotify, occasional youtube-video, signal and things lke that. Granted this was on a higher end when it was new, but maybe it gives some perspective on things.

Is there way to use a usb wifi card(tp-link) as the reciever and make it work?

No. The mouse is not a wifi device, and as it's a old one I doubt it'll support bluetooth either. So you really need the original dongle.

I don't know what to pick, but something else than PDF for the task of transferring documents between multiple systems. And yes, I know, PDF has it's strengths and there's a reason why it's so widely used, but it doesn't mean I have to like it.

Additionally all proprietary formats, specially ones who have gained enough users so that they're treated like a standard or requirement if you want to work with X.

I ran one for a while. In Finland legislation is a bit different, so I wasn't worried about breaking the law or getting sued, but my ISP got in touch pretty quickly. They were professionals and understood the situation when I explained why my traffic might look "a bit" suspicious and I attempted to clean up bad actors from the traffic with filtering and whatnot, but eventually ISP got enough complaints and they were pretty much forced to tell me that either I shut the exit node down or they'll cut my line.

As I said, they were very professional about it, and managed the whole experiment as good as I ever could have hoped, but my agreement with them has an option that if I'm letting malware and bad actors leave the network even after warnings they can shut the connection down. And that's understandable, I suppose they have similar agreements with other providers and they received all the abuse mail my exit node was causing, so I'm still a happy customer with them even if they eventually took the hard way.

I'm still pretty sure it would be possible to run filtered exit node, but it would require far more time and other resources that I'm willing to spend on a project like that and I'm not sure if a single person is enough for it anyways.

So, yes, do your homework and be careful. Legislation plays a significant part (depending on where you live), but your ISP most likely won't like it either.

And as they'll use mobile app, potentially a metric shit ton of more. Location, contacts, usage patterns, make/model of phone, other connected devices on your wifi and the list goes on and on. I'm not sure if they actually get everything they can like tiktok, but atleat theoretical possibility exists.

DNS is a quite well matured technology and it's just as complex as it needs to be and not a bit more. It's a very robust system which has been a big part of the backbone of the internet as we know it today for decades and it's responsible for quite a large chunk of stuff working as intended globally for millions and billions of people all day every day.

It's not hard to learn per se (it's something you can explain on a basic level to every layman in 15 minutes or so), it's just a complex system and understanding complex systems isn't always easy nor fast. Running your own DNS-server/forwarder for a /24 private subnet is rather trivial thing to do, but doing it well requires that you understand at least some of the underlying tehcnology.

You really need to learn how to walk at first and build on that to run. It's just a fundamental piece of technology and there's no shortcuts with it due to nature of DNS services. You can throw whatever running on a container by following step-by-step instructinos and call it a day, but that alone doesn't give you the knowledge to understand what's going on under the hood. That's just how the things are and should I have my way with things, that same principle should apply to everything, specially if it's going to face the public internet.