Indy500 hat geschrieben:Langsam wird's echt lächerlich. Ohne Firmware funktionieren nunmal die Geräte die diese benötigen nicht und freie Firmware wird es auf absehbre Zeit auch nicht geben, PUNKT.
Es ist ja schön wenn man Ideale hat und diese auch verteidigt aber manchmal sollte man sich auch einfach mal den Realitäten stellen. Eine Firmware ist nunmal Bestandteil der Hardware und somit kann diese auch Lizenztechnisch ruhig in der Distri belassen. Schließlich habe ich ja als Verbraucher mit dem Kauf der Hardware das Recht zur Nutzung erworben.
Indy, Du hast zwar recht, daß Du mit dem Erwerb der Hardware gewisse Rechte daran erwirbst, aber es handelt sich um ein Stück Software, daß vom Treiber zur Laufzeit auf die Hardware geladen werden muß. Und daher muß dieses Stück Software den DFSG entsprechen. Sinnvoller wäre es entsprechend, wenn die Firmware direkt auf der Hardware beheimatet wäre, dann könnte man sich die Diskussion sparen. Sprich, ein kleines Hardware speziefisches Bios, was beim Booten direkt von der Hardware aus einem EPROM geladen wird und die (Grund-)Funktionalität bereitstellt. Das sind allerdings Kosten, die sich die Hardwarehersteller mitlerweile ersparen wollen.
Wir hatten gerade neulich eine Diskussion u.a. auch zu diesem Thema. Das Problem besteht ja schon länger, wurde jedoch noch nie richtig angegangen. Sicherlich ist es im Moment für Debian nicht gerade fördernd, Sarge, auf das viele schon lange warten, gerade wegen dieser Problematik nicht zu releasen, sondern erst von sämtlichen proprietärem Code zu befreien. Aber gemacht werden muß es! Zumindest, um sich als Freie Software Distribution nicht bei z.B. den Fensterbauern lächerlich zu machen. Zudem muß Druck auf die Pinguin-Coder ausgeübt werden, da diese Sinn und Zweck der GPL und Freier Software nicht wirklich verstanden haben und durch die proprietäre Firmware im Kernel auch ganz klar gegen die GPL verstoßen.
Der Sache ist es äußerst dienlich, Sarge nicht zu releasen, bis Sarge sauber ist. Debian jedoch tut es nicht so gut. Es gilt an dieser Stelle abzuwägen, was wichtiger ist. Sarge schnell rauszuhauen und die Probleme vor sich her zu schieben, bis das Flaggschiff der Freien Software, nämlich der Kernel, selbst zu proprietärer Software verkommen ist oder eben Sarge zu releasen, um die Anwender "zufriedenzustellen". Das Problem hätte alleine dadurch entschärft werden können, wäre man das Release etwas früher angegangen. So hätte man letzten Sommer oder Herbst Sarge releasen können und sich jetzt in aller Ruhe dieser Problematik stellen können und das nächste Release erst nach Beseitigung aller Probleme anstreben können.
Noch zum abschluß ein kleiner Hinweis: bevor Ihr jetzt den Debian-Entwicklern die Tür einrennt und Euch bei denen beschwert, daß Sarge so schnell nicht kommen wird, tragt Euch in der Linux-Kernel-ML ein und haut dauernd Beschwerdemails raus, daß die proprietäre Software im Kernel nicht tragbar ist. Man hätte vor Jahren schon beginnen sollen, die Firmware durch Reverse-Engineering selbst zu Coden, Stück für Stück, wenn gerade mal wieder was gebraucht wird. So sitzt man jetzt vor einem riesen Berg, der schier unbewältigbar wirkt.
Alternativ könnt auch Ihr Euch mit Reverse-Engineering befassen. Somit helft Ihr den Kernel-Hackern den Kernel zu säubern, eure Hardware wird weiterhin unterstützt und Sarge wird früher released.
____________
@mohamet: rc2 bedeutet soviel wie Release Candidate(?). Andere Software würde das eher als 3.0.2 benennen.
Letzlich bedeutet das soviel: Debian released woody als 3.0, genauer 3.0.0 oder 3.0rc0. Haben sich eine Reihe Bugfixes und Securityfixes angesammelt, werden diese in die "offizielle Release" eingebaut und die rc-Nummer inkrementiert, also aus 3.0rc0 wird 3.0rc1, anders ausgedrückt 3.0.1
in diesem Sinne
[/quote]
. Ich muss ganz ehrlich sagen das ich mich von dem Verhalten so kurz vor Schluss noch mal alles zu aendern vor den Kopf gestossen fuehle und ein recht grosser Schaden fuer das Debian Projekt entsteht.
