• 0 Posts
  • 89 Comments
Joined 2 years ago
cake
Cake day: October 28th, 2024

help-circle
  • very rare for exploits that can breach a VM. Like once-every-10-years kind of rare.

    One important thing to be aware of. By default your VM will have access to the same network resources as the host. So, say, if you use tailscale or some other secure VPN to protect your NAS, but you give your host access, the VM will be able to access it too! You can use firewall rules or bridge networking to fix this, but tbh it isn’t trivial.





  • With power comes responsibility. Flexibility is power, and the easier it is to modify core system components, the easier it is for you to mess them up as well.

    I am not a Fedora Atomic maintainer or lead, so this is just my perspective from the outside, but the core ideology behind it is to have a tailored opinionated experience for user. I remember Bluefin’s lead dev saying something like “I want that ‘defaults’ lifestyle”. It’s the experience of having everything just work out of the box, and be maintained for you.

    With Fedora Atomic, the user chooses less responsibility, and thus has less power.

    On the flip side you have NixOS and Arch. Maximum power and maximum responsibility. If the world starts moving towards a new window compositor (think X11 -> Wayland), you now have to figure out how to do that migration yourself. If there are customizations that you added that aren’t Wayland compatible, you have to figure out how to work them out. It’s a ton of little decisions. Whereas for an opinionated distro, you just trust that the maintainers handled it and just update your system. Which is exactly what happened for me, as a Fedora user. One day I was using X11, and then the next I was using Wayland, no manual configuration on my part.

    This is why I recommend atomic distros to beginners. Beginners don’t have the knowledge to handle the responsibility of maintaining a distro. They don’t know why X11 is insecure, what systemd is, how linux permissions work. They need these guard rails. Once they get more familiar with the ecosystem they can choose to install a more customizeable distro.


  • Can’t speak much about OP’s distro or CachyOS, but I can talk about how Fedora Atomic differs from simply doing btrfs backups before every update.

    First, updates are not the only thing that can modify the base system. Installing packages, installing plugins or extensions, manual user modifications, etc, can all end up bricking the system. Fedora Atomic makes the base system immutable so that the only way of making modifications is via rpm-ostree, which ensures that you always have a way to rollback.

    Second, one of the issues with traditional update mechanisms is that over time, updates might not do proper clean-up and leave artifacts. This is a harder problem than people realize, because users can have all sorts of permutations of packages and versions installed, and the update mechanism has to account for all of them. Over time, and many updates, a system can accumulate tons of small update errors and finally fall over. I’ve had this issue myself and heard of this issue from multiple sources. Fedora Atomic solves this by ensuring that every update is like a complete re-install.

    Third, since every Fedora Atomic user uses the same base system as their distro maintainers, they can be sure that their base system is well tested. Bugs are more reproducible, and thus can be fixed faster. None of those “works on my system, you’re on your own” issues.

    Fourth, this one isn’t a benefit to the user but the community. Fedora Atomic (and universal blue) distros are easy to fork. This is why there are so many flavors now. Bluefin, Aurora, Bazzite, Secureblue, Wayblue, etc. Instead of one generic distro with a huge community relying on a few maintainers, like Fedora used to have, now you have smaller specialized communities with their own leaders, and users can choose which community they align with more. And you can even switch communities, since rpm-ostree allows you to “rebase” to a different distro (eg Aurora -> Bazzite).










  • I bet another reason is security. You might not trust the NUT software. It might be proprietary, and even if its open source, it might not be scrutinized enough to be safe.

    Using separate hardware, lets you take in the power loss signal from the NUT and then convert it to a channel you might trust more, like an http request over wireguard. Alternatively you could use a VM with usb passthrough on the main PC…though usb passthrough still has risks.