Die Integration von proprietären Firmware-Versionen in die Debian-Auslieferung wurde vorangetrieben.

Steve McIntyre, der mehrere Jahre als Projektleiter für Debian tätig war, hat eine Initiative ins Leben gerufen, um die Haltung von Debian gegenüber der Bereitstellung proprietärer Firmware zu überdenken. Diese Firmware wird derzeit nicht in die offiziellen Installationsabbilder aufgenommen und steht in einem separaten Non-Free-Repository zur Verfügung. Nach Meinung von Steve führt der Versuch, ausschließlich freie Software bereitzustellen, zu unnötigen Schwierigkeiten für die Benutzer, die in vielen Fällen proprietäre Firmware installieren müssen, um die volle Funktionalität ihrer Hardware zu erreichen.

Proprietäre Firmware wird in einem separaten Non-Free-Repository abgelegt, zusammen mit anderen Paketen, die nicht unter freien und offenen Lizenzen vertrieben werden. Das Non-Free-Repository gehört offiziell nicht zum Debian-Projekt, und Pakete daraus dürfen nicht in offizielle Installations- und Live-Bauten aufgenommen werden. Daher werden Installationsabbilder mit proprietärer Firmware separat erstellt und gelten als inoffiziell, obwohl ihre Entwicklung und Wartung formal vom Debian-Projekt durchgeführt werden.

In der Community hat sich ein gewisser Status quo etabliert, der den Wunsch, nur Open-Source-Software im Distribution bereitzustellen, mit den Bedürfnissen der Benutzer nach Treibern kombiniert. Es gibt eine kleine Auswahl an freien Treibern, die in die offiziellen Builds und das Haupt-Repository aufgenommen wurden, aber diese Treiber sind sehr begrenzt und in den meisten Fällen nicht ausreichend.

Der in Debian verfolgte Ansatz führt zu vielen Problemen, darunter Unannehmlichkeiten für die Benutzer und Ressourcenverschwendung für die Erstellung, das Testen und die Bereitstellung inoffizieller Builds mit proprietären Treibern. Das Projekt präsentiert die offiziellen Abbildungen als die Hauptempfehlungen, was die Benutzer jedoch mehr verwirrt, da sie beim Installationsprozess auf Unterstützungsschwierigkeiten stoßen. Die Verwendung inoffizieller Builds trägt ungewollt zur Popularität proprietärer Software bei, da der Benutzer zusammen mit den Treibern auch das verbundene non-free-Repository mit anderer proprietärer Software erhält. Wären die Treiber separat angeboten worden, hätte man auf die Einbeziehung des non-free-Repositories verzichten können.

In letzter Zeit setzen Hersteller zunehmend auf externe Firmware, die vom Betriebssystem geladen wird, anstatt Firmware direkt im dauerhaften Speicher der Geräte bereitzustellen. Solche externen Firmware-Lösungen sind für viele moderne Grafik-, Audio- und Netzwerkadapter erforderlich. Es bleibt jedoch unklar, inwieweit Firmware den Anforderungen an die Bereitstellung von nur freier Software zugeordnet werden kann, da diese grundsätzlich auf Hardware-Geräten und nicht im System ausgeführt werden und somit zur Hardware gehören. Ebenso werden auf modernen Computern, die sogar mit vollständig freien Distributionen ausgestattet sind, Firmware verwendet, die im Gerät integriert ist. Der einzige Unterschied besteht darin, dass einige Firmwares vom Betriebssystem geladen werden, während andere bereits im ROM oder Flash-Speicher implementiert sind.

Steve hat fünf Hauptoptionen zur Diskussion gestellt, wie Firmware in Debian bereitgestellt werden soll, die zur allgemeinen Abstimmung unter den Entwicklern stehen werden:

  • Alles beim Alten lassen und geschlossene Firmware nur in einzelnen inoffiziellen Builds bereitstellen.
  • Die Bereitstellung von inoffiziellen Builds mit nicht freien Firmware-Versionen einzustellen und die Distribution in Übereinstimmung mit der Ideologie des Projekts zu bringen, das ausschließlich freie Software liefert.
  • Inoffizielle Builds mit Firmware in den Rang offizieller Builds zu überführen und diese parallel und an einem Ort zusammen mit Builds zu liefern, die nur freie Software beinhalten, um den Benutzern die Suche nach der benötigten Firmware zu erleichtern.
  • Proprietäre Firmware in die offiziellen Standard-Builds aufzunehmen und die Bereitstellung separater inoffizieller Builds aufzugeben. Ein Nachteil dieses Ansatzes ist die standardmäßige Einbeziehung des non-free-Repositories.
  • Proprietäre Firmware aus dem non-free-Repository in eine separate Komponente non-free-firmware auszulagern und diese in einem anderen Repository bereitzustellen, das keine Aktivierung des non-free-Repositories erfordert. In die Projektregeln eine Ausnahme hinzuzufügen, die die Aufnahme der Komponente non-free-firmware in die standardmäßigen Installations-Builds erlaubt. So besteht die Möglichkeit, auf die Bildung separater inoffizieller Builds zu verzichten, Firmware in die Standard-Builds aufzunehmen und das non-free-Repository bei den Benutzern nicht zu aktivieren.

    Steve plädiert für die Annahme des fünften Punktes, der es dem Projekt ermöglichen soll, sich nicht zu weit von der Förderung von Open-Source-Software zu entfernen, während gleichzeitig das Produkt benutzerfreundlich und nützlich bleibt. Im Installer wird vorgeschlagen, freie und nicht-freie Firmware deutlich zu trennen, um dem Benutzer die Möglichkeit zu geben, eine informierte Entscheidung zu treffen und ihn darüber zu informieren, ob die verfügbaren freien Firmware-Versionen die aktuelle Hardware unterstützen und ob es Projekte zur Erstellung freier Firmware für vorhandene Geräte gibt. Zudem ist geplant, beim Booten eine Option hinzuzufügen, um das Paket mit nicht-freier Firmware zu deaktivieren.

    Quelle: opennet.ru

  • Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server 🔥 Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server | ProHoster