Announcement

Collapse
No announcement yet.

Fedora Atomic Desktops Born Out Of Fedora Silverblue Success

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

  • #21
    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.

    Comment


    • #22
      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.

      Comment


      • #23
        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.

        Comment


        • #24
          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.

          Comment


          • #25
            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.

            Comment


            • #26
              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.

              Comment


              • #27
                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.

                Comment


                • #28
                  Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post
                  It's weird to standardize the naming for some of the desktops but not others. I realize Silverblue and Kinoite are the big two, but they should have taken the opportunity to rename them to Fedora Workstation Atomic and Fedora KDE Atomic.
                  Theyve built up significant brand recognition already for both of those. You wouldnt just rename EndevourOS as ArchLinux Complete DE Edition or something, so renaming Silverblue at this is counter productive

                  Comment


                  • #29
                    Originally posted by user1 View Post

                    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.
                    Random power outages can mess up anything so that's not really a good excuse to not use something. Enterprise users will have UPS and battery backups. Home users can do that, too. It's not my fault they, and me, don't want to spend $100 for peace of mind. It's not like they, the Fedora devs, haven't tried to make updating as safe as possible. At some point it is on the end user to provide a stable operating environment during critical moments.

                    It doesn't take much to make GRUB have issues due to how it implements its own file system drivers. That's especially true with Arch since it can use any number of file systems with any number of configurations. While I don't remember why the last Arch/GRUB issue happened, I just know that disk format issues tend to happen more often with DIY distributions. For that matter, boot loader issues in general happen more often with DIY distributions. That's not really that surprising. When you're on the front lines you're more likely to be shot.

                    Comment


                    • #30
                      Originally posted by SpyroRyder View Post

                      Theyve built up significant brand recognition already for both of those. You wouldnt just rename EndevourOS as ArchLinux Complete DE Edition or something, so renaming Silverblue at this is counter productive
                      EndevourOS isn't made by Arch Linux so they wouldn't and legally couldn't do that name change. Silverblue is from Fedora. Kinoite started as unofficial and now is from Fedora. Both should undergo the name change else they'll just look silly. EndevourOS isn't a good one to pick. They only have the one installer that lets the user pick the desktop environment they'd like to use which is ideally what Fedora would do with their atomic installer.

                      It's like this Focus Group for a Ford Focus:

                      We have the Ford Focus SW, the Ford Focus DE, the Ford Silverblue, the Ford Focus GT, and the Ford Kinoite.

                      Why do the Silverblue and Kinoite's look like Focus variants?

                      That's because they are. They're all different versions of the Focus

                      Why do those two in particular have different names?

                      We decided to let them keep their prototype names since 168 people are familiar with that branding.

                      Oh, you're actually serious. Let me laugh harder at that.

                      Comment

                      Working...
                      X