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-Servern đŸ”„ Kaufen Sie zuverlĂ€ssiges Hosting fĂŒr Websites mit DDoS-Schutz, VPS VDS-Servern | ProHoster