Schlagwort: openSUSE

  • openSUSE will unabhängiger werden

    openSUSE Leap 15
    Lizenz: GFDL

    Auf der openSUSE-Mailingliste findet derzeit eine Diskussion über eine mögliche Umbenennung der Distribution statt. Hintergrund ist der wiederholte Wunsch des Projekts, durch Gründung einer Stiftung oder dem Beitritt zu einer Schirmorganisation mehr Unabhängigkeit von der Konzernmutter SUSE zu erlangen.

    Seit 2011 immer wieder ein Thema

    Die Idee einer unabhängigen Organisationsform taucht regelmäßig auf, wenn die SUSE Linux GmbH wieder einmal den Besitzer gewechselt hat. Die weiteren Gründe, die für eine Stiftung sprechen, wurden in einer Vorstanddssitzung während der kürzlich abgehaltenen openSUSE Conference erläutert, die als YouTube vorliegt.

    Nomen est Omen?

    OpenSUSE steht zu SUSE wie Fedora zu Red Hat, mit dem Unterschied, dass Fedora keinen Namensteil von Red Hat im Namen hat, sondern lediglich im Logo eine Verbindung erkennen lässt. Einerseits mag es naheliegend klingen, durch den Zusatz »open« die Ausrichtung klarzustellen.

    Juristische Implikationen

    Jedoch hat dies juristische Auswirkungen etwa beim Markenrecht. So muss die Konzernmutter SUSE derzeit alle Domains von openSUSE weltweit innehaben, da das Unternehmen ansonsten seine eigene Marke nicht effektiv schützen könnte. Zudem könnte openSUSE mit einer Stiftung im Hintergrund selbst Spenden einnehmen, Spendenquittungen ausstellen und auch selbst an andere Projekte spenden.

    Häufige Besitzerwechsel

    openSUSE hat zwar auch nach dem kürzlichen erneuten Besitzerwechsel bei SUSE alle bisherigen Freiheiten behalten, das kann aber nicht in alle Zukunft vorausgesetzt wrrden. Somit ist es verständlich, dass durch die Gründung einer Stiftung mehr Unabhängigkeit und der Status einer eigenständigen juristischen Person erreicht werden soll. SUSE wird dem Projekt hier auch keine Steine in den Weg legen.

    Würde man allerdings eine openSUSE-Stiftung ins Leben rufen, so wäre hier bei einer Markenanmeldung seitens der Stiftung der Markenstreit schon vorgezeichnet, denn SUSE würde durch eine Duldung seine eigene Marke schwächen. Also diskutiert das Projekt über eine Umbenennung. Eine Alternative wäre, der Stiftung einen abweichenden Namen vom Projekt selbst zu geben, was aber zu Problemen mit Zuordnung und Wiedererkennbarkeit führen könnte.

    Sachlich bis nostalgisch

    Die Diskussion teilt sich in sachliche Erwägungen und eher nostalgisch geprägte Aussagen, wobei die Meinungen in beiden Kategorien stark divergieren. Auch im Vorstand herrscht keine Einigkeit über den einzuschlagenden Weg. Während Richard Brown hauptsächlich aus juristischen Gesichtspunkten für eine Umbenennung stimmt, ist Simon Lees dafür, den Namen so lange wie möglich beizubehalten.

    Andere Teilnehmer sehen einen möglichen Schaden für das Renommee beider Projekte bei einer Umbenennung, da Außenstehende diese für ein Anzeichen von Problemen sehen würden, egal wie man die Umbenennung marketingtechnisch verkauft.

    Community soll entscheiden

    Die Diskussion ist offen, im Endeffekt soll die Community entscheiden. Einhergehend mit der Namensänderung wird auch eine Änderung oder Abwandlung des Logos in Erwägung gezogen.

    Einen Vorteil hätte die Namensänderung auf jeden Fall: openSUSE wäre nicht mehr die ständig falsch geschriebene Distribution. Obwohl die deutsche Rechtschreibung die offizielle Schreibweise zulässt, wird sie sowohl von Anwendungen wie LibreOffice als auch von Redakteuren in Blogs und Zeitschriften ständig zu OpenSUSE, OpenSuse oder Opensuse abgewandelt.

  • OpenSUSE Leap 15 steht vor der Tür

     

    openSUSE Leap 15
    Logo: openSUSE | Lizenz: GFDL 1.2

    Am 25. Mai soll openSUSE Leap 15 offiziell freigegeben werden. Die Distribution steht im bereits seit einem Vierteljahrhundert rotierenden SUSE-Produktuniversum in der Mitte zwischen  dem Rolling-Release Tumbleweed und der kommerziellen Ausgabe SUSE Linux Enterprise Server (SLES) und speist sich aus beiden. Im Februar hatte ich bereits auf einen Blick auf einen Snapshot im Betas-Status geworfen. Heute geht es eher um ein herausragendes Merkmal des neuen openSUSE Leap – die transaktionalen Updates.

    Neue Herausforderungen

    In den letzten Jahren trugen die Weiterentwicklung des Linux-Kernels und die Entstehung neuer Paketformate und Container dazu bei, dass sich vielerorts die Art und Weise, wie Software und deren Konglomerierung zu Distributionen aktualisiert wird, veränderte. Im Internet der Dinge (IoT), wo Linux auf eingebetteten Geräten läuft, sind Updates einerseits enorm wichtig, andererseits aber sehr schwierig. Sie müssen zentralisiert und automatisiert durchgeführt und kontrolliert werden. Geht dabei etwas schief, wäre bei herkömmlichen Methoden der Aktualisierung guter Rat teuer.

    Deswegen kommen dort und anderswo sogenannte atomare Updates, auch als transaktionale Updates bezeichnet, zum Einsatz. Dabei wird ein Update gebündelt, nicht ungleich einem Image vollzogen. Geht dabei etwas schief, wird das gesamte Update zurückgerollt und der Zustand vor dem Update wieder hergestellt. So aktualisiert etwa Canonical seine Snaps, die bereits in vielen Geräten des IoT werkeln.

    OSTree

    Auch die Container-Variante von Fedora, Atomic-Workstation, trägt diese Art der Aktualisierung bereits im Namen. Gerade arbeiten die Fedora-Entwickler daran, die Workstation-Ausgabe der Distribution im Rahmen des Projekts Silverblue transaktional zu gestalten. Den Update-Mechanismen liegt die Bibliothek libostree zugrunde, die zusammen mit einigen Kommandozeilentools als OSTree bezeichnet wird. Das Paketformat Flatpak bedient sich dieses Modells ebenso wie die gerade in Version 3.4 erschienene Endless OS. Dazu wurde bei Endless eigens ein  Updater geschrieben.

    Btrfs + Snapper + Zypper

    OpenSuse verfügt durch die Verwendung von Btrfs als Dateisystem und per Snapper kontrollierte Snapshots des Systems bereits seit längerem über ein ähnliches System, allerdings entkoppelt vom Aktualisierungsmechanismus der Distribution. Zu festgelegten Zeiten oder vor einem umfangreichen Update wird mit Snapper ein Snapshot erstellt, der eingespielt wird, falls das Update schiefgeht. Mit openSUSE Leap 15 wird dieses System nun direkt mit den Aktualisierungen verknüpft. Aus dem auf Tumbleweed basierenden Projekt Kubic, das der Entwicklung von Container-Technologien dient, stammt die Entwicklung, die künftig den Anwendern von openSUSE Leap alternativ transaktionale Updates bescheren wird.

    Dabei werden Aktualisierungen entweder in einer einzigen Transaktion oder gar nicht auf das System angewendet. Dies geschieht ohne Beeinflussung des laufenden Systems. Wenn ein Update fehlschlägt oder wenn das erfolgreiche Update als inkompatibel oder anderweitig fehlerhaft angesehen wird, kann es verworfen werden, um das System sofort wieder in seinen vorherigen Betriebszustand zu versetzen.

    Unberührt

    Transaktions-Updates berühren nie direkt das laufende System. Anstatt das aktuelle System zu patchen, erstellt das Transaktions-Update-Tool einen neuen Snapshot. Alle für das Update erforderlichen Operationen werden vorerst nur in diesem Snapshot ausgeführt. Am Ende des Updates wird bei erfolgreicher Aktualisierung ein abgeschlossener Snapshot als neuer Standard markiert. Diese Updates werden dann beim Neustart des Systems wirksam. Wenn die Aktualisierung nicht erfolgreich war, wird der Snapshot verworfen und keine Änderung am System vorgenommen.

    Wer die neue Technik bereits jetzt testen möchte, wählt bei der Installation von openSUSE Leap 15 im Tab »User Interface« die Option »Transactional Server«. Das Image der Beta-Version ist rund 3.6 GByte groß. Viel Spaß beim Testen.

  • openSUSE Leap 15 bietet Snapshots mit Beta-Status

    openSUSE Leap 15 bietet Snapshots mit Beta-Status

    openSUSE bietet erste Snapshots der kommenden Veröffentlichung Leap 15 in Beta-Qualität. Die stabile Veröffentlichung ist für das Frühjahr 2018 vorgesehen. Bis zur Veröffentlichung rollt Leap ohne feste Beta-Veröffentlichungen. Jetzt wird sich mancher Leser fragen, wieso 15 wenn doch das letzte Release die Versionsnummer 42 trug. Auch wenn Leap mit Sprung zu übersetzen ist, geht es hier ja hier immerhin rückwärts.

    Wie Entwickler Richard Brown auf der Mailingliste erklärt, war die letzte Opensuse-Version vor Leap die 13.2, während die Version von Suse Linux Enterprise  (SLES) damals bei 12 stand. Da Leap im Kern jetzt auf SLES basiert, sollte das neue Versionsschema das reflektieren. Da man aber SLES bereits voraus war, ging das nicht sofort. So entstand die Idee, die SLES-Version als Vorlage zu nehmen und 30 zu addieren, womit die erste Leap-Version 42 war. Das wurde jetzt über den Haufen geworfen und nun werden die Versionsnummern beginnend mit der 15 für Leap und SLES synchronisiert. Bei SLES fallen 13 und 14 aus.

    Nun aber zum eigentlichen Thema, der Vorschau auf openSUSE Leap 15 mit der derzeitigen Buildnummer 115.1 vom 30.1. 2018. Eine Beta-Version zu SLES 15 war bereits im November 2017 erschienen. Die Beta-Leap-Builds verfügen über ein überarbeitetes Aussehen sowie den Linux Kernel 4.12. Benutzer können zudem KDEs nächste LTS-Version Plasma 5.12 testen, deren Veröffentlichung am 2. Februar in stabiler Version erwartet wird. Bis zur stabilen Version von Leap 15 wird noch die neue Version 4.14 des Pakets rpm in das Image aufgenommen.

    Den Namen und das Konzept »openSUSE Leap« gibt es seit 2015, als das Projekt eine Neuorientierung einleitete. Mit Leap besteht openSUSE aus einem Grundstock von Paketen aus der kommerziellen Mutter-Distribution SLES, auf der aktuelle Kernel, Pakete und Entwicklungen aufsetzen. Der aktuelle Snapshot von openSUSE Leap 15 mit einer Größe von vier GByte kann von der Projektseite heruntergeladen werden. Ein Net-Install steht ebenfalls bereit. Ein Ausprobieren ist hier vorab nicht möglich, es handelt sich nicht um ein Live-Image. Ein wenig Geschichte zur 25-jährigen Geschichte von SUSE vermittelt eine News zum Geburtstag.