Das einzig Konstante bei openSUSE in den vergangenen Jahren ist der Wandel. Die Zukunft von openSUSE Leap hängt in der Schwebe, seit SUSE im Frühjahr 2022 für seine Enterprise-Edition SLE eine Architekturänderung hin zur unveränderlichen Adaptable Linux Platform (ALP) bekannt gab. Eine Bestandsaufnahme, wie es angesichts dieser Änderungen um openSUSE Leap steht, haben wir im Juni geschrieben.
Community zu klein
Der Kern des Problems liegt in der Community. Wenn SUSE auf ALP umgestellt wird, verliert openSUSE Leap in seiner jetzigen Form die Basis. SUSE wird seine Community-Edition danach nur marginal unterstützen. Die relativ kleine Community von openSUSE wird es ohne die Basis von SLE schwer haben, einen Nachfolger von Leap, möglicherweise mit verschiedenen Desktop-Umgebungen zu erstellen, zu betreuen und zu supporten.
Davor warnte Richard Brown, SUSE-Entwickler aus dem Future Technology Team bereits. Der einzige Lichtblick damals war die Nachricht, dass mit der Fristverlängerung durch das Einschieben von Leap 15.6 mehr Zeit für die Community bleibt, sich neu aufzustellen und zu orientieren.
Slowroll oder Linarite?
An einer kürzlichen Befragung der Community nahmen 251 Personen teil, von denen sich 101 als Beitragende bezeichneten. Es galt zu entscheiden, welche von drei vorformulierten Optionen der Vorzug zu geben sei und welche Option die meisten Beitragenden erwarten könnte:
- Linarite – Leap mit reduziertem Paketumfang, vermutlich basierend auf dem SUSE-ALP-Projekt Granite
- Slowroll – ein Derivat von Tumbleweed mit kuratiertem Rolling (ähnlich wie Arch → Manjaro)
- Leap fortsetzen – Versuch, Leap im jetzigen Umfang fortzuführen
Sowohl Slowroll als auch Linarite existieren bereits, Letzteres lief bisher unter dem Namen Grassy Knoll. Beides sind zurzeit Ein-Mann-Projekte.
Beitragende und User uneins
Fast die Hälfte der Teilnehmer erklärte, dass ihre Mitarbeit nur für Leap zur Verfügung steht und nicht für eine der beiden anderen Optionen. Auch wenn die Antworten sehr divers sind, stellte Richard Brown fest, dass es »Vorschläge gibt, zwei sehr unterschiedliche Distributionen zu bauen, um Leap zu ersetzen«, sieht aber eine Bevorzugung von Slowroll. Insgesamt zeigt das Ergebnis der Befragung deutlich die Tendenz, dass die Leute glauben, openSUSE solle Dinge tun, zu denen sie selbst nicht bereit sind, beizutragen.
Mitarbeit dringend gesucht
Während Leap noch 61 Beitragende verzeichnet hat, halbiert sich diese Zahl nun, sofern etwas anderes als Leap favorisiert wird. Hinzu kommt, dass Slowroll oder Linarite viel mehr Paketierungs- und Wartungsaufwand erfordern werden. Brown stellt abschließend fest:
Damit ein Ersatz für Leap realisierbar ist und sowohl hergestellt als auch über Jahre hinweg unterstützt werden kann, bin ich davon überzeugt, dass wir deutlich mehr Leute benötigen, die ihre Ärmel hochkrempeln und daran arbeiten.
Richard Brown
Mir erscheint die Zukunft von openSUSE derzeit äußerst ungewiss, egal in welcher Form. Wird eine der ältesten Distributionen vom Markt verschwinden? Wird openSUSE neben Tumbleweed noch gebraucht? Was denkt ihr?
Für mich haben unveränderbare Distributionen eine klare Zielgruppe: jene Leute, die einen Computer nur NUTZEN, aber nicht warten können/wollen. Jene Leute, die sich auf den Standpunkt stellen: “Es muss einfach funktionieren” und daher aktuell Windows oder Apple nutzen. Sie können von Kalpa und Co profitieren:
Wir sollten uns eines bewusst sein: 95% aller Nutzer gehören in diese Zielgruppe. Die WOLLEN ihr Betriebssystem nicht konfigurieren, und daher stört es sie auch nicht, dass es gar nicht erst möglich ist. Aber die kommentieren hier halt nicht.
Ich selbst werde auch keine unveränderlichen einsetzten, aber ich sehe ein riesiges Potenzial in einem unveränderlichen Desktop als Alternative zu Windows und Apple.
Ist halt das Prinzip der Android images, portiert auf den PC.
Finde ich dort schon besch…eiden, dass Änderungen am rootfs volatil sind.
Naja, Android verfolgt – soweit ich weiß – das A/B Prinzip. ALP arbeitet mit ro snapshots, das ist was anderes. Und durch einen Reboot in den neuen Snapshot erhält man ja die Änderungen.
Aber klar, vom Nutzer her gedacht finde ich Fedoras Ansatz mit Silverblue besser (auch wenn mich die Variante von ALP mit btrfs technisch mehr überzeugt)
Das A/B-Prinzip wird von Vanilla OS genutzt.
Ich hab mir neulich ein Video vom Herrn Brown auf Youtube angeschaut, das war sehr aufschlussreich:
Aus meiner Sicht also alles halb so wild… Klassisches SLES/D wird es eben nicht mehr geben, das kann SUSE ja entscheiden wie sie wollen. Für Tumbleweed Nutzer ändert sich nichts.
Die Community kann weiterhin ein “LTS” von SUSE erhalten, das basiert dann nur eben auf ALP.
Der Support von SLES ist zu aufwändig für SUSE
Genau. Kosten sparen, Personal einsparen, Verantwortung abgeben.
Hmm… ist halt eine Firma, die am Markt überleben muss. Ob die Entscheidungen das bewerkstelligen, wird man sehen. Vielleicht gibt es irgendwann nur noch ALP/SLED for SAP oder so 😉
Ich betreue seit vielen Jahren ca. 250 Server mit SLES und openSUSE Leap (je nach Anforderung der darauf laufenden Anwendungen). Obwohl ich ALP prinzipiell befürworte, sehe ich keinen so schnellen Wechsel. Ich wünsche mir daher, dass openSUSE Leap 15.x ebenso lang betreut wird, wie SLES 15 SPx.
Es ist vollkommen unbegreiflich, dass SUSE mit OpenELA jetzt sogar eine freie Red Hat kompatible Distribution unterstützen, dagegen ihr eigenes openSUSE Leap (dafür?) aufgeben will.
Für mich (und viele andere) wird sich daher, wenn es SLES oder Leap nicht mehr gibt, die Frage stellen: ALP oder Red Hat? Momentan würde ich entscheiden: Red Hat.
Ich kann mir nicht vorstellen, dass SUSE diese Problematik nicht auf dem Schirm hat und daher SLES (und somit Leap) weiterbetrieben wird, solange ein nennenswerter Teil der zahlenden Kunden das noch haben will.
Ich stimme dir eigentlich vollkommen zu.
Aber ob das wirklich alle auf dem Schirm haben?
Ich glaub nicht. So oft wie SUSE nun weiter gereicht wurde. Und wenn man die letzten Personalabwanderungen beobachtet. Der letzte glaub war der Finanzvorstand…
Die technischen Susemitarbeiter haben das wie wo anders auch auf dem Schirm. Aber die BWL-Leute schauen auf andere Dinge.
Und wie gesagt. Ich vermute, was ich ja auch schrieb, wird primär RedHat vorgeschrieben.
Und bevor ich ALP nehemen würde, kommen andere Systeme zum Einsatz.
Ich finde es ganz schön erschreckend, wie kurzsichtig und emotional hier kommentiert wird.
Flatpak ist per Definition dezentral. Du kannst es in deinem Intranet selbst hosten – siehe hier: https://github.com/flatpak/flat-manager.
Gleiches Vorgehen gilt im Übrigen in Unternehmen auch für Container-Registries (z.B. DockerHub) oder klassische Software-Repositories (RPM, DEB). Da können die Server i.d.R. auch nicht ins Internet und man will hier auch Bandbreite sparen. Daher spiegelt man sich die entsprechenden Repositories. Wäre ja nicht gerade sinnvoll, wenn jeder Server die Container und Patches neu herunterlädt. Ich kann hier keinen “Bullshit” erkennen.
SUSE mag für viele im privaten Kontext wenig interessant erscheinen, aber im Mittelstand- und Enterprise-Umfeld setzen nach wie vor die meisten SAP-Kund:innen darauf. Irrelevant sieht anders aus.
Naja Suse hat nach all den Jahren immer noch nicht die Stellung im Linuxbereich, die sie gern haetten. Die Eigner interessiert das nicht, die interessieren nur Zahlen.
Allerdings ist Suse auch im Enterprise Bereich absolut weit weg von Debian und RedHat.
Daran sind sie allerdings selbst schuld, in den 90ern haben sie den FHS verlassen und das hat sie damals schon weit zurueckgeworfen, dann sind sie teilweise zurueck zum FHS aber sie haben nichts draus gelernt.
Gut RedHat wird weitestgehen in den close Bereich gehen aber das wird nichts an Suse aendern.
Ich denke es ist nur eine Frage der Zeit.
SUSE behauptet ja immer, das ALP aufgrund von Kundenwünschen entwickelt wurde. Das kann
ich als privater Hobbyuser nicht beurteilen. Ich weiß nur das ich ALP nicht will! Ich kann mir auch nicht vorstellen, dass die meisten Unternehmenskunden begeistert sind, dass SUSE Linux neu erfinden will. Ich denke für eine Unternehmens-IT ist der Wechsel von SLE auf ALP ein riesen Aufwand.
Was SUSE auf jeden Fall mit der Ankündigung von ALP geschafft hat ist Verunsicherung unter den
Usern zu erzeugen!
Für mich war openSUSE Leap in den letzten 10 Jahren das ideale Betriebssystem. Tumbleweed war mir mit den täglichen Snapshots zu nervig.
openSUSE Leap war ja wohl schon in den letzten Jahren personell unterbesetzt und hat nur überlebt, weil das komplette Basissystem von SLE übernommen wurde.
Ich denke das openSUSE Leap oder ein entsprechender Nachfolger keine Zukunft mehr hat und finde das extrem schade.
Nachdem sich openSUSE Leap 15.5 auf dem neuen 08/15 Intel Mini-PC meiner Frau nicht installieren ließ (blieb schon beim Laden des Installationsprogramms hängen) habe ich dort kurzerhand Linux Mint ohne jegliche Probleme installiert.
Auf meinem Haupt-Arbeits-PC habe ich Anfang August GhostBSD installiert und bin damit bisher
sehr zufrieden. Ob das langfristig eine Alternative ist, wird sich zeigen. Auf dem neuen MiniPC meiner Frau lief GhostBSD übrigens ohne Probleme … aber sie möchte weiterhin Linux nutzen …
Same here. Leap dagegen war mir zu “alt”, vor allem Kernel und Mesa.
Wollte neulich Slowroll nach Ankündigung auf phoronix ausprobieren, hab dann jedoch relativ schnell aufgegeben, da es bislang nicht einmal ein spezifisches Live oder Installationsimage gibt.
Werde es mir definitiv anschauen, wenn’s verfügbar ist. Die Idee ist super (für’n Desktop).
Die meisten Pakete bei ALP soll man als flatpack beziehen.
Dazu muss ich Zugriff auf flathub haben.
Das haben aber die Rechner in einer Firma nicht.
Und wenn sie es haben, dann darf man nicht so einfach etwas installieren. Ist also gesperrt.
Wie will man also ein Paket auf mehreren Rechnern installieren, wenn der Rechner keine Internetverbindung hat, der Nutzer keine Rechte und es dass Paket in den Repos nicht mehr gibt?
Das ist einfach Bullshit. Sorry.
Habe ich nicht verstanden. Wenn ich ein klassisches Suse im DC ohne Internetanbindung betreibe, brauche ich einen Mirror der RPM Repos.
Für ALP brauche ich das dann halt entsprechend für die flatpaks, die ich haben möchte. Sehe ich jetzt nicht als Problem.
Korrekt.
Dann soll ich also noch den Flathup spiegeln?
Das wird niemals in einem Unternehmen frei gegeben.
Somit keine Chance das zu nuzen.
Du sollst das nicht. Das überlässt Du schön Deinen Admins.
Und die stimmen das genauso mit Vorgesetzten und Security ab, wie sie es vorher auch mit den RPM- Repos gemacht haben.
Sorry. Die Antwort ist nun ein wenig unpassend.
Ich war ein Synonym für irgend jemanden.
Und ich unterstelle dir mal, dass du scheinbar nicht wirklich praktische Erfahrung hast. Schon gar nicht in größeren Unternehmen.
Vorgesetzte haben in größeren Unternehmen damit gar nichts zu tun. Und bei RPM muss man nichts abstimmen. Da gibt meist als Vorgabe RedHat und zumindes die Hauptrepos sind gespiegelt. Und wenn man was anderes als RedHat möchte muss man ganz viel Idealismus und Liebe für Suse mitbringen. Und einen ganz, ganz langen Atem haben. Sonst wird das nichts.
Das Kompliment mit der praktischen Erfahrung gebe ich gern zurück.
Ich arbeite nun seit 15 Jahen un der Unternehmens IT und weiß grob, wie der Hase läuft. Du scheinbar nicht.
Davon ab hast Du einen Logikfehler: Wenn man bei RPMs nichts abstimmen müsste, müsstest Du bei Suse ja nicht betteln. Das ist ja derzeit RPM.
Woher hast du das? Flatpak ist für Desktop-Apps, ALP ist für Server. Das sind zwei völlig verschiedene Schuhe.
Wer schreibt vor, dass flatpacks nur für Desktop ist? Wer schreibt das vor, dass ein Server keine GUI haben darf?
Zukünftig wird das mehr mehr werden.
Zum Beispiel bekomme ich den Firefox nur über Flatpack. War zumindest so und denke das ist immer noch so.
ALP ist nicht nur für Server. Das ganze Zeugs, egal wie es nun heißt basiert auf ALP und somit auf den Containerdingen.
Also nix mit unterschiedlichen Dingen.
Du hattest die These in den Raum gestellt: “Die meisten Pakete bei ALP soll man als flatpack beziehen”.
Kannst Du das irgendwie belegen?
Laut der offiziellen Flatpak-FAQ (auf Deutsch übersetzt): “Kann Flatpak auch auf Servern verwendet werden?
Flatpak ist für die Ausführung innerhalb einer Desktop-Sitzung konzipiert und basiert auf bestimmten Sitzungsdiensten, beispielsweise einem D-Bus-Sitzungsbus und optional einer systemd –user-Instanz. Daher eignet sich Flatpak nicht gut für einen Server.
Allerdings laufen die Build-Funktionen von Flatpak auch außerhalb einer Sitzung einwandfrei, sodass Sie Dinge auf einem Server erstellen können.” Nur Mal hier zur Klarstellung, damit nicht andere noch irgendwelche Forenkommentare glauben.
Was willst du nun damit sagen?
Für was sich Flatpack eignet steht auf einem anderen Blatt.
Ich meine zum Beispiel für gar nichts.
Und wenn ich ein Programm aus Flatpack benötige ist mir erstmal wurscht was im Hintergrund passiert. Kann mir hier auch nicht vorstellen, dass die erstmal lokal gebaut werden. Ist für das Thema aber auch nicht relevant.
Wenn ich ALP nutze, sind viele Programme nur container dienste zu installieren/betreiben. Lese doch die Vorgaben dazu. Ich meine die Vorgabe ist: 1. Flatpack, 2. distrobox, 3. transactional.
Und nochmal. Wer schreibt vor ob eine GUI gebraucht wird oder nicht? Und somit auch GUI Anwendungen. Du und ich sicher nicht. Das muss jeder selbst wissen.
Die Leute von Suse und hier insbsonders der Herr Brown sollte mal etwas weiter denken.
Ihr ALP Zeugs brauch niemand. Und ich mag mal behaupten auch nicht im Unternehmensumfeld.
Dieses ALP Zeugs dient nur dazu bei Suse Personal abzubauen, Kosten zu sparen und Verantwortung abzugeben. Dieses ALP flatpackzeug funktioniert im Unternhmen sowieso nicht. Denn die Server / Rechner kommen gar nicht raus ins Internet.
Was aber viel wichtiger für Suse ist, ist dass meiner Meinung und Kenntnis nach, im Unternehemensumfeld überwiegend RedHat gesetzt ist. Evtl. noch Ubuntu im Desktopbereich.
Möchte nun jemand Suse (egal wie man das schreibt), dann muss er darum kämpfen.
Und das ist in größeren Unternehmen sehr schwierig. Man muss also schon sehr von Suse überzeugt sein um sich das anzutun.
Fällt nun Leap weg, schwenken die User um und suchen sich eine andere Distro.
– Debian ist im übrigen mittlerweile aktueller als Leap. –
Und somit fallen auch die Leapuser welches sich im Unternehmensumfeld für Suse einsetzten weg.
Und somit früher oder später fällt Suse komplett weg.
Fällt also Leap weg, fällt früher oder später auch Suse weg.
Und somit auch der Arbeitsplatz von Herrn Brown.
Du wirfst hier einiges durcheinander. SUSE hat mit Flatpak nichts zu tun. Flatpak ist für Desktop-Apps und wird auf Servern nicht verwendet, spielt daher für SUSE und ALP auch keine Rolle. SUSE hat wesentlich höhere Gewinne als Canonical, eben allein dank der Server. Du brauchst dir also keine Sorgen um SUSE zu machen. Der Linux-Desktop spielt im Unternehmensbereich kaum eine Rolle. Der Leap-Desktop hat schon lange keine Rolle mehr gespielt. Ein Nachfolger rentiert sich eben auch nicht mehr, da SUSE nichts mehr darin investiert. Mit Slowroll und Aeon / Kalpa gibt es aber würdige technologisch modernere Nachfolger für Leap.
Sorry, aber ich glaub eher du bringst hier einiges durcheinander und meinst deine Ansicht gilt für alle.
Wer schreibt vor das man auf Servern keine Gui-Anwendungen benutzen darf? Das wird eher zunehmen. Somit wird auch flatpack benötigt.
Achso und die Anwendungen sollen über Docker kommen. Dazu brauch ich also einen Internetzugang.
Zu Canonical schrieb ich im Desktopbereich. Also nix mit Server.
Und wer sagt das der Desktop keine Rolle spielt?
Er spiel eine Rolle. Eine sehr große sogar.
Bei dir vielleicht nicht, aber woanders schon.
Und was Leap mit den Servern zu tun hat, hatte ich auch beschrieben. Und was das mit dem Niedergang zu tun haben wird. Darauf gehst du aber nicht ein.
Was Aeon/Kalpa, Slowroll betrifft.
Ist alles noch nicht wirklich fertig.
Kalpa ist noch Alpha und es arbeitet glaub nur eine einzige Person daran.
Slowroll ist noch “weniger” als Alpha. Auch hier arbeite nur eine einzige Person dran.
Und was an den Conaintersachen morderner sein soll erschließt sich mir nicht.
Und Gnome ist auch keine alternative.
Wenn ich lese, um Gnome wirklich nutzen zu können, benötigt man einige Extensions, die laufend nicht funktionieren. Und wenn ich Leute zu Linux bringen möchte, dann liegt KDE eben näher.
Und ich schreibe hier nicht über irgendwelche Dinge, worüber ich glaub wie sie sein könnten. Ich schreibe nur über Dinge, die ich auch beweisen könnte.
Natürlich kann man bei Servern eine GUI benutzen, das sind aber im Grunde verschwendete Ressourcen.
Im Business Bereich spielt der Linux Desktop leider kaum eine Rolle. Bin damit auch nicht glücklich, aber ist nun mal so.
ALP ist das gleiche was Canonical und Redhat auch vorhaben. Fedora Silverblue wird vermutlich mit Version 40 der Standard. Und somit früher oder später auch das neue RHEL.
Ubuntu wird die nächste LTS Version auch als Immutable Desktop rausbringen.
Gnome ist seit Ewigkeiten der Standard Desktop von allen Business Linux Distros.
Ist übrigens durchaus sehr gut ohne Extensions nutzbar.
Und tatsächlich hat sich jeder ehemalige Windows Nutzer denn ich zu Linux gebracht habe sich für Gnome oder Cinnamon statt KDE entschieden.
Es war abzusehen, dass mit der (fragwürdigen) Entscheidung von SUSE, die herkömmliche Distribution einzustampfen auch die Community-Varianten verschwinden werden. Auch die Zukunft von Tumbleweed sehe ich nicht gesichert.
Ich sehe nur die Möglichkeit, sich komplett von SUSE zu lösen, ähnlich wie Mageia sich von Mandriva getrennt hat. Am Ende wird es eine Frage des Engangements und der Zahl der Beitragenden sein. Da sieht es aber nicht all zu gut aus.
PS: Nichts gegen unveränderliche Distributionen wie ALP, aber diese sprechen halt auch nur eine einzige Zielgruppe an – nämlich User, die mit den Vorgaben zufrieden sind und nichts am System ändern wollen. Das ist vor allem im Unternehmens-Umfeld interessant. Aber Privatuser und andere, die gerne Customizing betreiben, können damit wenig anfangen.
Ich glaube, TW wird bleiben; weil die Entwicklung in Factory stattfindet, und TW ja “nur” Factory + OpenQA ist. Factory/TW ist auch der Upstream von ALP wie ich es verstehe