cross-posted from: https://lemm.ee/post/37281970

Believe it or not, an unexpected conflict has arisen in the openSUSE community with its long-time supporter and namesake, the SUSE company.

At the heart of this tension lies a quiet request that has stirred not-so-quiet ripples across the open source landscape: SUSE has formally asked openSUSE to discontinue using its brand name.

Richard Brown, a key figure within the openSUSE project, shared insights into the discussions that have unfolded behind closed doors.

Despite SUSE’s request’s calm and respectful tone, the implications of not meeting it could be far-reaching, threatening the symbiotic relationship that has benefited both entities over the years.

  • PotatoesFall
    link
    fedilink
    arrow-up
    2
    ·
    4 months ago

    awesome you seem knowledgable :P Can I bother you to share any resources on the differences between the atomicity between fedora and open suse? Search engines suck these days

    • bsergay@discuss.online
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      4 months ago

      Can I bother you to share any resources on the differences between the atomicity between fedora and open suse?

      It’s genuinely hard to point towards an exhaustive source on the matter. Perhaps related to the fact that there are continuous advancements and developments going on that make it hard for something to not feel outdated very quickly. But, basically, Fedora Atomic heavily relies on OSTree/libostree for accomplishing its ‘immutability’/atomicity. While, on the other hand, openSUSE MicroOS utilizes Btrfs snapshots (primarily) instead. Some implications are:

      • Fedora Atomic is able to track changes. openSUSE MicroOS currently does not. Though, this feature is planned.
      • Fedora Atomic is (pretty) reproducible; even if after dozens of transactions one returns back to an earlier state without tracing back. This is possible through the use of layers instead of directly changing the base system. This is something Btrfs snapshots can’t do currently. Therefore, there’s nothing that indicates that openSUSE MicroOS is able to do the same. Though it can be reproducible in its own way.
      • Git-like features of OSTree/libostree allows branching (and other git-like features) when managing deployments. Concept of branching is alien for Btrfs Snapshots.
      • Fedora Atomic basically offers built-in factory reset. For openSUSE MictroOS, this is planned.
      • Like git, Fedora Atomic can rebase. In practice, this allows it to change drastically through a single reboot without actually reinstalling. This is used to rebase to a new major version (from Fedora 39 to Fedora 40), but even more impressive is to change from Silverblue (GNOME) to Kinoite (KDE Plasma) to Sway to Budgie etc. And all of this, without (most of) the cruft associated with these changes. Heck, you could even rebase to uBlue images or any others you fancy. This concept of rebasing is not found on openSUSE MicroOS.
      • In theory, Btrfs snapshots should be more flexible in regards to applying changes we may find on traditional distros. But, unfortunately, because Fedora Atomic is further along its development, we don’t actually notice this. (The upcoming update related to bootable containers for Fedora Atomic doesn’t make it any easier for openSUSE MicrOS to be more flexible anyways.)
      • The upcoming update related to bootable containers also allows Fedora Atomic to be (relatively) declarative and hence; less state. This concept is also currently absent on openSUSE MicroOS.

      Ongoing developments may alter the above list significantly. It’s even entirely possible that all features mentioned above will be found on both distros in the upcoming years. However, vision and scope are perhaps decisive when it comes to making any predictions regarding the future. We haven’t gone over those yet… Going over those is out of scope for what this comment intends :P .

      Search engines suck these days

      Can’t agree more.