Breaking: The openSUSE Board discusses SUSE's request to stop using its brand, highlighting the need for cooperation and goodwill.

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
    3·
    4 months ago

    Thanks!

    Well I think that the atomic distros, especially desktops, have a big future, I hope openSUSE gets to keep working on those.

    I might try Kalpa actually. Seems like the openSUSE version of Fedora Kinoite?

    • bsergay@discuss.online
      3·
      4 months ago

      Thanks!

      It has been my pleasure.

      Well I think that the atomic distros, especially desktops, have a big future

      So do I. Though, I think they’ll have a big future across the board.

      I hope openSUSE gets to keep working on those.

      Yup, me too. I trust that at least openSUSE Aeon will thrive (through Richard Brown). And hopefully that will eventually result into a healthy ecosystem in which more ‘immutable’/atomic spins (with other desktop environments) will follow.

      I might try Kalpa actually. Seems like the openSUSE version of Fedora Kinoite?

      Technically, it’s indeed openSUSE’s take on an ‘immutable’/atomic distro with KDE Plasma. However, there’s a big difference in how much development it enjoins.

      • For Fedora Atomic, all the spins are equal~ish in regards to their development. Like, it’s not possible to point to a difference that goes beyond polish.
      • On the other hand, openSUSE Aeon is in RC3 while openSUSE Kalpa hasn’t left Alpha. This is not surprising when considering that multiple people work on openSUSE Aeon and only a single developer works on openSUSE Kalpa.

      There’s also a difference in how ‘immutability’/atomicity works on Fedora Atomic vs openSUSE MicroOS. Without even going over the implications thereof. But that’s out of scope for what’s intended for this comment.

      • PotatoesFall
        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
          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.