News Debian 12: „Bookworm“ mit proprietärer Firmware erschienen

[beercarrier]

Der Grund warum ich Debian nie in Betracht gezogen habe.
Freie Software war Ihnen immer wichtiger als Benutzbarkeit und das konnte ich meinen Bekannten nicht andrehen.

Mal schauen vielleicht probier ich es mal aus.
Wenn Ubuntu mit 24.04 "scheiße" baut, werde ich mir wohl aber zuerst Linux Mint anschauen...

allerdings konnte man schon immer non free Pakete nachinstallieren. Und ehrlich gesagt kann ich die Entscheidung nachvollziehen, glücklich bin ich aber nicht damit. Der Deal war mal eine Community erstellt frei verfügbar ein Betriebsystem und um es zu nutzen gibt du den Teil der fehlt dazu - auch frei verfügbar. Es war ein win-win. Mit den non free packages pinkeln die CEO´s der Konzerne doch denen ins Gesicht die die Infrastruktur geschaffen haben. Wenn Nvidia kein guten oss firmware bereitstellen wollen - gut. Dann können sie ihre AI Supercomputer gerne mit Windows Server verkaufen. Und Enduser die Linux nur nehmen um sich 9,99€ für geklaute Windows Lizenz zu sparen sind auch die Supporter die man unbedingt erreichen muss.

 

[andy_m4]

Wie soll das gehen, ohne Ende Hard- und Software selber zu schreiben?

Du scheinst so ein 100%-Typ zu sein. Ich weiß ja nicht, wie alt Du bist. Aber evtl. ist es Dir ja schon mal aufgefallen, das man in der Praxis nur ganz ganz selten irgendwo 100%-Lösungen hat.
Niemand würde auf die Idee kommen die Polizei abzuschaffen, nur weil sie nicht 100% aller Straftaten verhindert und aufklärt. Selbst Du wirst in Deiner Wohnungstür ein Schloss haben, welches Du abschließt. Und das, obwohl es nicht zu 100% einen Einbruch verhindert.

Uns selbst Open source heißt ja auch nur, dass jemand reinschauen kann, nicht dass es jemals wer getan hat.

Es mag seltener vorkommen als man gemeinhin denkt, aber es kommt natürlich vor. Es gibt sogar Prozesse, wo sogar regelmäßig (zumindest abschnittsweise) Code begutachtet wird. Viele Open-Source-Projekte sind so organisiert, das da jeweils für neu eingecheckten Quellcode ein Review stattfindet.
Oder auch wenn Distributions-Package-Maintainer Patches in die von ihnen betreuten Pakete einbauen, kommen sie zwangsläufig mit dem Quelltext in Kontakt.

Es geht bei solchen Sachen auch nicht immer um bewusst eingebaute Lücken. Schlechter (und damit buganfälliger) Code ist in der Praxis das weitaus größere Problem. Als Open-Source-Programmierer hat man die Tendenz, guten Code zu schreiben. Weil man ggf. einen Ruf zu verlieren hat. Aber auch, weil Open-Source i.d.R. als Mitmachprojekt angelegt ist und kaum jemand mitmachen wird, wenn das ein unwartbarer Codehaufen ist.

Bei Treiberkomponenten wie Firmware? Wie soll das gehen?

Ich erklärs Dir NOCHMAL:
Debian nimmt in main nur freie Software auf. Damit hast Du quasi die Garantie, das wenn Du daraus was nimmst, nur freie Software hast. Freie Software gewährt Dir bestimmte Rechte. Das Du die Sachen weiter geben darfst. Das Du Einblick hast. Das Du das Programm modifizieren darfst.

Wird Firmware dem gerecht? Nein. Das Du es weiter geben darfst, wird bei Firmware eher kein Problem sein. Der Hersteller will ja, das sein Gerät verwendet werden kann. Das sowas wie Firmware weiter gegeben wird, dürfte sogar in seinem Interesse liegen.
Beim modifizieren siehts schon anders aus. Wie, meinst Du, würde es der Hersteller finden wenn jemand die Firmware so modifiziert, das auf der Hardware Features freigeschaltet sind, die der Hersteller für teurere Varianten vorgesehen hat?

 

[drake23]

Generell: Da ich das Konzept der shared libraries unter Linux als DEN Teil des OS sehe, der die Sicherheit der Software-Pakete (und damit des Gesamtsystems) so unendlich einfach macht, werde ich auf absehbare Zeit jedenfalls kein Fan von Flatpak/snap und Konsorten. Software-Entwickler haben leider keine Ahnung von Sicherheit. Insbesondere, wenn sie Software Dritter einbeziehen. Eine Lib ist schon älter? Ist doch Wurscht! Hauptsache läuft! Das wird dann paketiert und man verlässt sich drauf, dass die Pseudo-Sandbox-Konzepte von Flatpak oder Snap das schon ausbügeln werden. Ein Shared Library-System hat da einen anderen Ansatz. Die Software-Entwickler entwickeln ihre Software in ihrem kleinen Kämmerlein, geben das an die Paketierer und die bilden das auf die aktuell verfügbaren 3rd party libs ab. Sollte sich irgendwann herausstellen, dass eine dieser Libs ein Sicherheitsproblem hat, wird EXAKT diese eine Lib systemweit (!) repariert. Die Paketmaintainer oder Entwickler der regulären Apps merken davon nix.

Passt mal auf... irgendwann kommt jemand auf die Idee und baut eine Distro, die definitiv zusammenpassende Flatpaks als Gesamtpaket anbietet, weil da die jeweiligen Libs definitiv mit dem Rest zusammenarbeiten... (Den Kram gibts ja auch heute schon nicht nur aus einer einzigen Quelle.)

Das spricht mir aus der Seele

Irgendwann werden sie hoffentlich erkennen, dass Sandboxing nichts hilft, wenn man einem MITM Angriff zum Opfer gefallen ist, weil im Flatpak die SSL Library veraltet war :/

Ein Vorteil, den ich allerdings sehe: Wenn irgendwann alle Distros den Flathub Firefox nutzen, muss der nicht mehr X mal selbst paketiert werden; evtl. ist dann auch ein großer Fokus auf dem Flatpak und sicherheitskritische Libs im Pak rücken in den Fokus...

 

[andy_m4]

muss der nicht mehr X mal selbst paketiert werden

Ja. Wobei es auch einen Vorteil hat, wenn der Firefox in jeder Distribution ein wenig anders "aussieht". Das erschwert nämlich auch Angriffe. Gerade bei Software mit einer hochgezüchteten Sicherheitsarchitektur wie Browser, kommt es häufig bei dem Ausnutzen von Sicherheitslücken drauf an, das Speicher-Adressen und andere Details passen, damit der Angriff erfolgreich ist.

evtl. ist dann auch ein großer Fokus auf dem Flatpak und sicherheitskritische Libs im Pak rücken in den Fokus...

Nur haben wir letztlich ne ähnliche gleiche Situation.
Sonst hatte man für jede Distribution ne quasi eigene "Variante" des Programms haben wir in dem Szenario für jedes Programm ne eigene "Variante" der benötigten Lib.

 

[free-sky]

GG Debian Team!

QLX/Spice ist ja aus rhel rausgeflogen, ich hoffe Debian 12/Proxmox 8 lassen das noch lange drin.

 

[Bigfoot29]

Na mal mindestens bis 2028. Debian 11 hat auch - als eine von wenigen populären Distris - noch vollen 32-Bit-OS-Support. Debian 11 auf nem Pentium M? Lüppt! (12 noch nicht geprüft)

@free-sky : Für mich stellt sich die Frage, WAS sie killen. QXL oder Spice. QXL ist mit guter CPU echt performant. Sogar bei großen Auflösungen. VirtIO kommt zwar GANZ langsam in funktionale Gebiete, "scheint" aber auch erst, wenn man tatsächlich 3D-Kram nutzt. Und was bleibt sonst noch? Bochs? RamFB? VGA? Und ganz ohne Spice wird es mit KVM aktuell komplett düster. VNC ist ein performance-technischer Witz. Aber hier kommt wieder Red Hat ins Spiel: Sie wollen halt ihren eigenen Hypervisor pushen. Denn DER wird Spice und Co definitiv weiter können.

Immerhin: Xen (als Hypervisor-Urgestein) ist gerade dabei, den ganzen Spice-Kram notfalls nachzuimplementieren. Wer das nutzt, hat dann ggf. auch dort eine vollwertige Alternative.

Regards, Bigfoot29

 

[Kaito Kariheddo]

kennst du solche Fälle?

Bestes Beispiel sind Exportbeschränkungen. Da dürfte die Firmware und auch entsprechende Datenträger welche diese beinhalten, nicht in sanktionierte Länder ausgeführt werden.

 

[polyphase]

@polyphase @Tanzmusikus
Oder einfach OMV mit nachinstalliertem Docker und KVM.

Das ist ein Debian, allerdings auf NAS gemacht. Mit hübscher Oberfläche.
Läuft bei mir mit 5 Docker Containern und bis zu 6 KVMs, unter anderen Homeassiant.

Wie sehen folgende Punkte bei OMV aus?

• ZFS Snapshots und Snapshot Replication
• Encrypted Datasets
• Docker Container auf Encrypted Datasets
• USV Geräte

Geht das alles über GUI oder ist das mehr oder weniger gebastel?

 

[xammu]

Wie sehen folgende Punkte bei OMV aus

USV ja, aber Rest dürfte Handarbeit sein

 

[Salamimander]

TrueNAS und OMV sind NAS Systeme und keine Hypervisoren, auch wenn sie es können…

Die Anforderungen (ZFS) erfüllt Proxmox im übrigen alle…

 

[Bigfoot29]

Ohne @polyphase seine Wünsche absprechen zu wollen, dürfte die Zielgruppe für derartige Configs auch eine ziemliche Minderheit sein. OSS-Setups decken das eher nicht ab, solange es nicht jemand selber beisteuert. Das sind eher konstenpflichtige Angebote, die sowas inklusive haben dürften. Die MÜSSEN solche Spezialfälle abdecken, um sich gegen die deutlich günstigere "Konkurrenz" absetzen zu können.

@Salamimander : Naja... jein. Problematisch ist bei OMV (da weiß ich es) höchstens, dass die Haupt-Dienste eben auch aus der privilegierten Domain heraus laufen und man Docker/KVM und Co eben nur "zusätzlich" dazubasteln kann. Aber es spricht am Ende nix dagegen, OMV lediglich als KVM-/Docker-Host zu fahren. Das dürfte dann technisch auch nicht anders laufen als z.B. Proxmox?

Regards, Bigfoot29

 

[polyphase]

Ohne @polyphase seine Wünsche absprechen zu wollen, dürfte die Zielgruppe für derartige Configs auch eine ziemliche Minderheit sein. OSS-Setups decken das eher nicht ab, solange es nicht jemand selber beisteuert. Das sind eher konstenpflichtige Angebote, die sowas inklusive haben dürften. Die MÜSSEN solche Spezialfälle abdecken, um sich gegen die deutlich günstigere "Konkurrenz" absetzen zu können.

Das ist keine Minderheit, das ist ein ganz normales Setup.

TrueNAS Scale erfüllt alle dieser Anforderungen.

Da ja OMV so gelobt wurde, wollte ich eben wissen ob es diese Funktionen auch kann.

 

[Bigfoot29]

Nö.

 

[ReactivateMe347]

Bestes Beispiel sind Exportbeschränkungen. Da dürfte die Firmware und auch entsprechende Datenträger welche diese beinhalten, nicht in sanktionierte Länder ausgeführt werden.

Dann dürfte die Hardware da auch gar nicht erst sein - und ohne Hardware ist die Firmware wertlos.

Ergänzung (13. Juni 2023)

Beim modifizieren siehts schon anders aus. Wie, meinst Du, würde es der Hersteller finden wenn jemand die Firmware so modifiziert, das auf der Hardware Features freigeschaltet sind, die der Hersteller für teurere Varianten vorgesehen hat?

Solange die modifizierte Variante nicht im Debian Repo für andere zur Verfügung gestellt wird: Was soll's?
Wie viele Nutzer haben überhaupt die Fähigkeit, Firmware funktionstüchtig zu modifizieren? Das so eine kleine Nische von Nutzern und so ein Aufwand, dass die "Recherche" der Lizenz im Vergleich lächerlich trivial ist.

 

[Serana]

Es geht hier auch um Wahlfreiheit.

Es gibt Menschen die aus politischen Gründen möglichst keine unfreie Software benutzen wollen, auch wenn das mit Einbußen beim Komfort einhergeht. Diese Menschen können sicher sein, daß sie bei Debian "main" ausschließlich freie Software bekommen.

Dann gibt es Menschen für die unfreie Firmware noch "in Ordnung" geht, aber sie wollen ansonsten keine unfreie Software auf ihrem Rechner. Genau für diese gibt es jetzt "non-free-firmware".

Bei Debian geht es eben auch darum, daß der Benutzer die Entscheidung trifft was auf dem Rechner installiert wird und was nicht.

 

[Buschpilot]

Debian 12 läuft ohne Probleme als VM auf meinen Proxmox, sind allerdings auch nur ein paar Docker container deployed, daher insgesamt nichts wildes.
Mit Debian allgemein bin ich sehr zufrieden, als ServerOS perfekt.

 

[andy_m4]

Solange die modifizierte Variante nicht im Debian Repo für andere zur Verfügung gestellt wird: Was soll's?

Ja. Was Du im privaten Rahmen machst ist tatsächlich nicht von Belang.
Wie bereits gesagt: Es werden die genannten Rechte garantiert. Und wichtig hierbei ist, das sie vollumfänglich sind. Sowas wie "kopieren nur zu dem und dem Zweck oder wenn nicht modifiziert" etc. wäre da eine Einschränkungen.

Wie viele Nutzer haben überhaupt die Fähigkeit, Firmware funktionstüchtig zu modifizieren?

Ja und was ist jetzt daran das Argument?
Das man alles, was ohnehin nur für "nicht-die-Mehrheit" relevant ist einfach nicht mehr zu machen?
"Die Mehrheit der Menschen braucht keine Traktoren. Wer hat schon ein Feld was es zu bestellen gilt? Also lass uns keine Traktoren mehr bauen."

Das so eine kleine Nische von Nutzern und so ein Aufwand, dass die "Recherche" der Lizenz im Vergleich lächerlich trivial ist.

Ok. Nehmen wir mal an, Dir ist es - aus welchen Gründen auch immer - wichtig freie Software zu benutzen.
Selbst bei einer nicht ausladenden, umfangreichen Debian-Installation, kommst Du schnell mal auf mehrere hundert bis tausend Pakete. Gut. Nicht jedes Paket ist ein eigenes Programm. Aber selbst wenn Du da zusammenfassen, bleibt noch sehr viel übrig. Und das willst Du dann ggf. alles per Hand checken?
Vor allem, da sich mit einem Update ja jederzeit etwas ändern könnte.

 

[dennisis]

Vor einem Jahr habe ich meinem Vater Debain 11 auf einem alten Laptop (Panasonic Toughbook von 2001) installiert. Es ist Debian geworden, weil es erstaunlich wenig Distros gibt, die noch x86 (32bit Intel Core2Duo) CPUs unterstützen und nicht 5 Jahre veraltet sind.
Für die Installation habe ich einen ganzen Tag gebraucht und es funktionierte nicht alles am Abend. Mit Debian 12 sollte das jetzt besser aussehen.

 

[Garmor]

32bit Intel Core2Duo

Aber die können doch auch alle 64-bit

 

[andy_m4]

Aber selbst dann stellt sich die Frage, ob es sinnvoll ist die mit 64-Bit zu betreiben.
Bei Geräten mit älteren CPUs dürfte auch der RAM-Ausbau nicht allzu üppig sein (und im Falle von Laptops ist auch i.d.R. das nchrüsten schwierig). 64-Bit-Programme haben einen signifikant höheren Speicherplatzverbrauch (was auch logisch ist; jeder Integer und Pointer etc. ist doppelt so groß wie bei 32-Bit).

Insofern kann es auch - jenseits der Frage der 64-Bit-Fähigkeit - sinnvoll sein, die mit 32-Bit zu betreiben.