Announcement

Collapse
No announcement yet.

Fedora Atomic Desktops Born Out Of Fedora Silverblue Success

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • user1
    replied
    Originally posted by elatllat View Post

    There are non-immutable ways of doing that, like modem/router/android A/B updates, cow fs snapshots.
    At least on Linux, the only way that I know of with which you can do atomic updates on a non immutable distro is to install transactional-update on a non immutable OpenSUSE variant and do all the updates via transactional-update instead of via Zypper.

    Leave a comment:


  • elatllat
    replied
    Originally posted by user1 View Post
    ... imo the strongest part of immutable distros is atomic updates (testing)...
    There are non-immutable ways of doing that, like modem/router/android A/B updates, cow fs snapshots.

    Leave a comment:


  • elatllat
    replied
    Originally posted by skeevy420 View Post
    ...rolling back...
    like lvm,zfs,btrfs.

    Originally posted by skeevy420 View Post
    ...
    security protections...

    like rkhunter, aid.

    Originally posted by skeevy420 View Post
    ...
    if you never have to install a single native package...
    I don't think that problem can be properly solved, it's a mutually exclusive goal.

    Leave a comment:


  • user1
    replied
    Originally posted by Snaipersky View Post

    Not really. If you just hold one or two snapshots, they aren't a full secondary copy, the storage used is just the difference between the two states. A 486 mb update to an 8gb / doesn't take 8gb, it takes about 486mb (generally less, as certain things stay the same). So compared to Windows shadow copy, or Avamar backups, it's faster, more robust, and smaller.
    I know it's just the difference between the two states, but I've used OpenSUSE Aeon for some time last year, updated it once a week and remembered how with each update my disk space usage increased by about 500mb. Imo it's still too much. The problem is also how old snapshots don't get automatically removed even if you already have dozens of snapshots at a time. Someone said to me that they should get removed automatically, but it hasn't happened in my case. I've also heard you need to be very careful if you want to manually remove old snapshots.

    That's why I think that now the rpm-ostree system that Fedora Silverblue uses is superior, because like btrfs snapshots the new rpm-ostree image is just the difference between the previous state and the new state, but it doesn't keep more than 2 images at a time. Plus, I also like how Fedora enables btrfs compression by default unlike OpenSUSE.
    Last edited by user1; 09 February 2024, 04:31 PM.

    Leave a comment:


  • Snaipersky
    replied
    Originally posted by user1 View Post

    If you talk about btrfs snapshots as the rollback system compared to something like Timeshift or whatever Windows has, then yes, they're miles ahead. However, they have a major drawback, and it's the absurd amount of disk space they take.
    Not really. If you just hold one or two snapshots, they aren't a full secondary copy, the storage used is just the difference between the two states. A 486 mb update to an 8gb / doesn't take 8gb, it takes about 486mb (generally less, as certain things stay the same). So compared to Windows shadow copy, or Avamar backups, it's faster, more robust, and smaller.

    Leave a comment:


  • user1
    replied
    Originally posted by skeevy420 View Post

    The argument is sound -- having a system in place that allows rolling back with added security protections totally makes sense from both a user and corporate perspective. As long as an update doesn't FUBAR the boot loader all anyone has to do is boot up the last known working environment and go on about their business should as update introduce a nasty bug.
    These are good points, but imo the strongest part of immutable distros is atomic updates. Imagine a power cut strikes during an update. It will most likely render a non immutable OS unbootable. Regarding the boot loader, I remember 1.5 years ago there was some buggy GRUB update which rendered Arch systems unbootable. In Fedora Silverblue the buggy GRUB update only caused the atomic update to fail.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by elatllat View Post
    The argument for immutable seems flawed to me.
    The argument is sound -- having a system in place that allows rolling back with added security protections totally makes sense from both a user and corporate perspective. As long as an update doesn't FUBAR the boot loader all anyone has to do is boot up the last known working environment and go on about their business should as update introduce a nasty bug.

    The implementation is what's flawed, IMHO. Take the Fedora way. It's just fine if you never have to install a single native package, but when you do install those packages they're installed as layers and those layers have to be removed and recreated every update. It gets old, fast, They want people to use Toolbox, Docker, and such tools instead of adding a native package, but sometimes you need native packages. If they could solve that problem, the layer problem, by, what I'd do, installing packages to /usr/local (/var/usrlocal in their speak), snapshotting that, too, before updates, and then creating a boot environment out of the current host OS and the current usrlocal data, that'd go a long way in making immutable distributions more user friendly. A separate kernel layer would be nice, too. There's also overlays, etc.

    Whatever the solution they come up with, their current non-immutable system package management strategy kind of sucks and fixing that would go a long way in making immutable systems funner to use.

    Leave a comment:


  • elatllat
    replied
    The argument for immutable seems flawed to me.

    Leave a comment:


  • user1
    replied
    Originally posted by Snaipersky View Post

    It is utterly baffling that SuSE's update system isn't the default for basically everything everywhere. No in-flight packages, no lengthy rollbacks if something broke, it's always in a known good state, or a quick reboot away. I hate having a windows work laptop that has to rollback updates every month for 1-2 hours, and having infrastructure for restoring server system images that one has to submit requests to and wait for hours. Make a subvolume, commit changes, reboot. If something went bad, you're out a minute of your time.​
    If you talk about btrfs snapshots as the rollback system compared to something like Timeshift or whatever Windows has, then yes, they're miles ahead. However, they have a major drawback, and it's the absurd amount of disk space they take.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post

    Have you thought about Tumbleweed or Slowroll from OpenSUSE? You get all the new stuff + easy rollbacks out of the box.
    The last time I considered changing distros, I was on a CPU from 2011 where all I could focus on was that people always wound up retreating to "it's fast enough" stances when I started asking about whether RPM-related tooling was as snappy on slow hardware as APT tools were.

    I have mixed feelings about OpenSUSE, since they're better than Red Hat about providing good-quality equivalents for things like packages.debian.org, but I'm still not sure I want to learn a whole new UI and workflow.

    I suppose, now that I have a brand new PC while my old 2011-CPU'd machine is still fully intact, I could ease myself into being comfortable with OpenSUSE without either fiddling around with a VM or switching over my daily driver cold-turkey.
    Last edited by ssokolow; 09 February 2024, 02:38 PM.

    Leave a comment:

Working...
X