But to your earlier one, I can get the VPN client working outside of a container. There’s even an RPM file from the vendor, so installing it is just as easy as installing any other package.
Aight. You know what you ought to do then 😉.
I appreciate the input!
It has been my pleasure!
But I’m fully aware that my frustrations are atomic problems
Are these frustrations solved by layering with rpm-ostree? If so, just go with it. I've always layered over a dozen or so packages and it has worked out fine; it's defaulted to automatic upgrades in the background, so you don't feel much of it anyways.
I just recently learned that openSUSE users also have a lot of stability due to btrfs snapshots, so maybe that’s really the feature I’m looking for. I don’t know much about it, honestly.
I love openSUSE and what they do with Btrfs snapshots and Snapper.
However, in terms of 'robustness' and 'stability', I don't think anything currently out there can hold up to Fedora Atomic, Guix System and NixOS. This is just by design; the leap from traditional to atomic, then reproducible and finally declarative ensures that issues related to hidden/unknown state, accumulation of cruft, bitrot, configuration drift are left behind in the past. If Btrfs snapshots + Snapper would have been sufficient, then openSUSE themselves would never have desired the creation of openSUSE MicroOS (i.e. their attempt at an 'immutable' distro) in the first place.
Consider reporting back on how it goes 😉.
Fair.
Btw, was I correct on the following?
I assume this is based on an experience with Kinoite? Am I right?
Thank you for mentioning that! Did the slower distros you tested come with older kernels?
So..., you don't think it will make a difference. However, you do affirm that whatever CachyOS does is noticably better than the rest.
Perhaps more importantly, have you actually measured 1% lows or 0.1% lows on games. And did you compare how different distros fared in this regard?
Ok, I’m still not clear on exactly what you’re trying to achieve as I can’t quite see the connection between somehow preventing certain files being duplicated when cloning the disk and preventing yourself from reinstalling the system.
Premises:
Therefore, I would lose those very important files if I were to attempt a wipe. If said files are important enough for me to reconsider wiping, then the act of protecting them from copy/mv/clone has fulfilled its job of preventing me from reinstalling the OS.
Bear in mind that reinstalling the system would replace all of the OS, so there’s no way to leave counter-measures there, and the disk itself can’t do anything to your data, even if it could detect a clone operation.
I understand.
If what you’re trying to protect against is someone who knows everything you do accessing your data, you could look to use TPM to store the encryption key for your FDE. That way you don’t know the password, it’s stored encrypted with a secret key that is, in turn, stored and protected by your CPU. That way a disk clone couldn’t be used on any hardware except your specific machine.
Very interesting. A couple of questions:
Very informative post. Thank you!
It has been my pleasure!
and joined their discord in preparation.
That will definitely help out a lot. Well thought!
Welcome on board 😉.
First of all, if you'll be using Bazzite, then become familiar with its documentation. Other sources may not necessarily translate that well to Bazzite due to Fedora, Atomic, OCI and SELinux (to name a few). Though, some other sources may benefit you as long as it doesn't contradict with Bazzite's own documentation.
so, what are your tips and tricks for a new linux user?
Bazzite is on Fedora Atomic's model, hence you should become familiar with the built-in rollback mechanism. Furthermore, it's possible to keep deployments around. Therefore, if anything, consider utilizing this on your first deployment; just in case.
Pinning said deployment is possible with the sudo ostree admin pin <insert number> command after installation. The number can be deduced through the rpm-ostree status command. The first deployment's corresponding number is 0 and for each deployment found below you just have to increase the number by one to find its corresponding number. So, the 4th deployment corresponds to the number 3. Btw, you can pin multiple deployments. So there's no opportunity cost involved. Finally, you can unpin a deployment with -u. So sudo ostree admin pin -u <insert number>
as a final question, what got you into using linux over windows or mac?
I was never a mac user in the first place. As for Windows, a hardware failure was causing more issue on it than on Linux. So that was the direct cause. But the reason I got interested into Linux initially and what has kept my interest are privacy and freedom respectively.
Interesting!
So, I guess that at least one of the following 'transitions' is 'blameworthy':
I guess I'll pass out on it for now. Thank you though!
We'd rather like to see that anyways 😜.