openSUSE Logo

Neues von openSUSE

In den vergangenen Tagen gab es einige neue Nachrichten von openSUSE und Tumbleweed. Auf der News-Seite von openSUSE verkündet das Projekt einen großen Fortschritt in deren Unterfangen für Reproducible Builds (RBOS).

Bereits seit vielen Jahren arbeiten verschiedene Distributionen an Projekten mit dem Ziel Reproducible Builds. Der Gedanke dahinter: Wird ein Paket aus dem gleichen Quellcode mit den gleichen Werkzeugen gebaut, so sollen die daraus resultierenden Pakete immer bitgenau gleich sein. Hört sich einfach an, ist es aber nicht. Das liegt unter anderem daran, dass viele Build-Werkzeuge Daten wie Uhrzeit und Datum des Builds in nicht deterministischer Form aufzeichnen. Um solche Abweichungen zu erkennen, wurden unter anderem Tools wie diffoscope entwickelt.

Bei den Distributionen nimmt Debian seit 2015 unter der Federführung von Holger Levsen eine Vorreiterrolle im Hinblick auf überprüfbare Pakete ein. Die dabei geschaffene Infrastruktur in Jenkins greifen mittlerweile andere Distributionen ebenso auf wie die Werkzeuge zum Lösen von Problemen und Überprüfen der Ergebnisse. So können etwa Fedora, OpenSuse oder Arch Linux die Ergebnisse von Debian verifizieren und umgekehrt.

Bernhard Wiedemann, der seit fast zehn Jahren an Reproducible Builds im Projekt RBOS bei openSUSE arbeitet, erhielt für vier Monate finanzielle Unterstützung der NLnet-Stiftung, um in Vollzeit den jetzt vermeldeten Meilenstein zu erreichen.

Wiedemann erstellte in der Zeit einen Fork von openSUSE mit zu 100 % reproduzierbaren Paketen. Dazu wurden 3.300 Pakete getestet und gepatched. Das Ergebnis soll mit der Zeit in das openSUSE Factory-Repository einfließen. Wer den Fork testen möchte, lädt sich das 175 MByte große Image mit

wget https://rb.zq1.de/RBOS/ring1/_build.standard.x86_64/altimagebuild/altimagebuild-1-1.1.x86_64.rpm

herunter und startet es nach dieser Anleitung in einer VM.

Tumbleweed wechselt zu SELinux

Bereits seit dem Sommer des vergangenen Jahres geplant und nun mit Snapshot 20250211 umgesetzt wurde der Umstieg von openSUSE Tumbleweed von AppArmor auf SELinux. Beides sind sogenannte MACs, was für Mandatory Access Control, also Zugriffskontrolle, steht. Das bei der NSA und bei Red Hat entwickelte SELinux besteht aus einem Kernel-Patch und vielen Erweiterungen für Systemprogramme. Es soll die Sicherheit gegenüber AppArmor erhöhen, da mehr Dienste standardmäßig eingeschränkt werden. Zudem nutzen SUSE und openSUSE dann künftig die gleiche MAC.

Nähere Informationen über die Implementierung bei MicroOS und jetzt auch bei Tumbleweed sind im Portal:SELinux nachzulesen. Bestehende Installationen sind von der Änderung nicht betroffen, neue Installationen können zu AppArmor zurückkehren. openSUSE Leap 15.x ist von der Änderung nicht betroffen, Neuinstallationen des im Jahresverlauf erwarteten Leap 16 allerdings schon.

Legacy BIOS soll in Rente gehen

openSUSE Leap Release Manager Luboš Kocman hat auf einer Mailingliste eine Vorankündigung gemacht, die darauf abzielt, mit SLES 16 und Leap 16 nur noch UEFI als Bootoption anzubieten und den Legacy-BIOS-Support fallen zu lassen. Da beide infrage kommenden Veröffentlichungen eine x86_64-v2 CPU voraussetzen, rechnet Kocman damit, dass alle unterstützten Geräte UEFI nutzen. Die Resonanz in den Kommentaren ist zunächst überwiegend ablehnend.

Teilt den Beitrag, falls ihr mögt

21 Kommentare

  1. Phu – Ich habe mal wieder das Gefühl, dass viele Benutzer OpenSource als ganzes und Suse im Speziellen nicht verstanden haben.
    Wenn ICH ein Tool zu meinem eigenen Vergnügen erstelle, oder weil ich ein Bedürfnis habe und das dann Open Source stelle, dann ist das in erster Line einfach nett von mir. Wenn DU dann DEIN Bedürfnis mit MEINEM Tool nicht befriedigen kannst, dann darfst du:

    • Einen Commit machen, um Code zu meinem Projekt hinzuzufügen, der das ergänzt
    • Meinen Code Forken (ist ja open source) und Dein eigenes Projekt basteln, das dieses Bedürfnis erfüllt
    • In einem Kommentar schreiben, welche unglaubliche Frechheit es von MIR ist, dass ich DEIN Bedürfnis nicht umsonst befriedigt habe.

    Merkst Du selber, oder?

    Wenn SUSE – welche in erster Linie SLE entwickelt – keinen Geschäftspartner mehr hat, der für Legacy BISO zahlt – dann darf das die Community über OpenSuse weiter pflegen. Wenn die keinen Maintainer finden, der das umsonst gratis franko macht, dann ist es raus. So einfach funktioniert das. Ihr könnt euch jetzt als Maintainer bei OpenSuse melden und LegacyBios übernehmen, oder Suse froken, oder mal schauen was GekoLinux macht (das ist schon ein Fork von SuSE, eventuell mache pflegen sie das weiter).
    Nein du als User wirst zu gar nichts gezwungen. Du hast die absolute Freiheit, das selbst weiter zu pflegen und es der Community zur Verfügung zu stellen – das ist die Grundfreiheit, die aus OpenSource entsteht. Niemand hat gesagt, dass Du alles für gratis bekommst.

    16
    1. Das hat jetzt nix mit suse zu tun!

      Danke Dir genau das ist eben Linux und Linux ist eben ueberwiegend keine Firma, sondern reine Community und genau das macht Linux aus. Jeder kann und soll alles und wer rummeckert, der kann es sich ja selbst bauen.

      0
  2. Da beide infrage kommenden Veröffentlichungen eine x86_64-v2 CPU voraussetzen, rechnet Kocman damit, dass alle unterstützten Geräte UEFI nutzen.

    Da irrt Kocman.
    Es gibt noch genügend viele Geräte mit einer x86_64 CPU, die ausschließlich mit Legacy-BIOS zu betreiben sind. Ich allein nutze aktiv 4 davon.

    5
    1. Das ist anektdotische Evidenz. Die Vernunft sagt doch, dass es viel weniger nicht-EFI kompatible Geräte gibt, und die auf Grund des Alters jeden Tag weniger werden und nicht nachproduziert werden. Theoretisch hätte ich auch noch ein Gerät, aber das ist +10 Jahre alt

      4
  3. Den Legacy-BIOS-Support fallen zu lassen und somit dem user wieder vorzuschreiben was er zu machen hat, das ist wieder typisch suse. Aber die haben immer mal solche Anwandlungen und sind jedes mal damit aufs maul gefallen.

    Naja wems gefaellt.

    8
    1. Es gibt nicht unendlich Ressourcen und Legacy BIOS ist irrelevant. Ich bin mir ziemlich sicher, das das nicht aus einer Laune heraus beendet wird, sondern das schlicht keine Maintainer sich die Arbeit machen wollen und sich von den betroffenen keiner als Ersatz gemeldet hat. Ergo wird es im Projekt nicht gebraucht.

      5
        1. suse ist nicht egal, die sind z.T. efolgreicher als Ubuntu im Unternehmenssektor.

          SLE ist downstream von openSUSE Tumbleweed. Wenn die unten in SLE BIOS EFI canceln, dann gab es oben in Tumbleweed keine Community, die das pflegt. Weil wenn da jemand wäre, der das gut und zuverlässig pflegen würde, würde es doch keinen Sinn ergeben, das raus zu werfen. Und von Unternehmensseite ergibt die Pflege auch keinen Sinn, weil niemand bei klarem Verstand solche Dinge auf derart veralteten und unsicherer Hardware laufen lassen würde. Weil das Zeug ist ja dann so alt, das könnte jeden Tag kaputt gehen und der Hardwaresupport (wenn verfügbar) wäre astronomisch teuer.

          6
            1. Das kommt dann auch darauf an, wie man das messen will. Deine Zahlen kann ich jetzt nicht kommentieren, da ich nicht weiß, worauf die sich beziehen. Es wird sicherlich mehr Ubuntu-Installationen geben als solche mit SUSE, allerdings hat SUSE vor allem in Europa wohl ein paar große Kunden, die da z.B. ihr SAP-Gedöns drauf laufen haben.

              2
      1. Legacy BIOS ist noch lange nicht irrelevant und du verstehst auch nichts von Ressourcen.
        Das Maintainment von Legacy BIOS macht keine Arbeit, weil sich dort seit 15 Jahren nichts mehr ändert. Es rauszuschmeißen hingegen heißt aber die User zu verprellen, die zum Teil durchaus auch noch ältere Hardware am Laufen haben.

        Für mich wird damit Suse irrelevant und das tatsächlich wg. meiner Ressourcen.

        7
        1. Du stellst jetzt die Hypothesen auf, dass
          a) Legacy BIOS in einem relevanten Umfeld in Unternehmens- und Privatumfeld genutzt wird.
          b) man 15 Jahre alten Code einfach unverändert behalten kann, wenn sich alles andere darum ändert.
          c) es Nutzer von Legacy BIOS Hardware gab, die bereit waren, den Aufwand für die Pflege zu leisten, und dass das vom openSUSE Projekt abgelehnt worden ist.
          d) Legacy BIOS hardware User überhaupt zur Zielgruppe von SLE oder openSUSE sind.
          e) es irgendwo sonst angemessen ist, für ein Stück Hardware mehr als 10 Jahre support anzubieten. (Denk anders herum, welches andere Mainstream OS bietet so was an? Windows? *lach*. Dass du so alte Hardware bis jetzt überhaupt mit Sicherheitspatches betreiben konntest, ist schon ein Wunder)

          Alles ohne Begründung.

          Eine ähnliche Diskussion gabs doch auch schon bei Debian und der geplanten Einstellung von 32 bit. Genau das gleiche. Nicht genug Leute, die das brauchen und gleichzeitig bereit sind, sich bei der Entwicklung zu beteiligen.

          5
          1. Zu
            a) Relevantes Umfeld, das musst du erst mal definieren, was du damit meinst.
            Jedenfalls kann man da recht unterschiedlicher Meinung sein.
            b) syslinux ist schon bestimmt 15 Jahre völlig unverändert aber ausgereift und stabil und wird heute noch auf jedem archlinux.iso dazu eingesetzt um entsprechender Hardware zu booten.
            c) Also horsch einmal zu. Wir beide tauschen hier Argumente miteinander aus. Ich muss dir gar keine Nachweise über andere Leute in anderen Distributionen erbringen, nur damit du ein rationales Argument nachvollziehen kannst.
            d) Spätestens wenn sie es rausschmeißen, gehöre ich nicht mehr zur Zielgruppe. Ansonsten hätte ich mich schon dazu gerechnet.
            Dein Argument dreht die Sachlage auf den Kopf. Zielgruppen-Hygiene ist Politik.
            Ich bin User und sage lediglich, dass ich das weiterhin brauche.
            e) Suse bietet keinen Gerätesupport an. Suse ist eine Software-Distribution.
            Die Entscheidung über den Zeitpunkt, wann ich meine Hardware wegschmeißen möchte, sollte doch bitteschön mir überlassen werden.
            Und wo du Windows ansprichst, dass ist ein Grund dafür, dass ich Windows nicht mehr einsetze. Bei Windows darf ich sogar noch funktionierende Drucker und Scanner wegschmeißen wenn es denen so gefällt.
            f) Ein durchgängiger 32 bit Support ist eine ganz andere Dimension der Aufwendung für eine Distribution, als ein bootloader, der nicht anderes macht als die Maschine zu booten. So etwas kann man nicht miteinander vergleichen.
            Und trotzdem gab es bei 32bit ein paar Freiwillige die den Support in einem eigenen Projekt weiterbetrieben haben.

            6

Kommentar hinterlassen