Aber die Qualität wird dadurch auch nicht besser als bei den anderen Distributionen mit aktuellerer Software. Man denke nur an das OpenSSH-Debakel. Nur dass man halt Asbach-Versionen einsetzt statt von den Weiterentwicklungen zu profitieren, die oft stabiler sind als alte Versionen, weil mittlerweile Bugs behoben wurden. Mit Ubuntu hab ich alle Vorteile: das gute Debian-Paketmanagement plus Usability-Verbesserungen, aktuelle Versionen und einen festen und planbaren Release-Zyklus. Auch auf dem Server. Wikipedia ist ja auch schon auf Ubuntu-Server migriert.
Vielleicht ist diese Auffassung etwas Subjektiv. Ich finde ja schon, das debian eine deutlich stabilere distro abliefert wie ubuntu. Zudem beinhaltet die ubuntu distro oftmals keine aktuellen versionen von weniger verbreiteten Programmen. Sie aktualisieren die für den (normalen) User sichtbaren programme. Linphone oder twinkle sind beispiele für solche applications, die in einer älteren version ausgeliefert worden sind, obwohl die stabilen versionen zum release-Zeitpunkt verfügbar waren. Andererseits wird auch wenns erst am letzten Tag fertig wird immer der neuste kernel + neuste GNOME Version ausgeliefert.
Was mich an Debian deutlich mehr ankotzt ist die Firmwarepolitik. Ich werde es sicher nicht verstehen, das der radeon treiber, e100, und weitere ohne firmware aus nonfree nicht laufen werden. Dadurch entfällt die netinstalloption auf note/netbook für debian komplett.
Du hast wohl den DFSG nicht gelesen und/oder verstanden?
Den es ist sogar insgesamt betrachtet korrekt so. Den die unfreie Firmware, von der es keine Quellen für die Debian Entwickler gibt, darf dort nicht in main sein. Wenn es dir nicht passt, dann ist es dein Problem.
Laut den Richtlinien muss nämlich alles davon offen sein, damit es in main sein kann. Und wenn du so dringend die Daten brauchst dann installier dir die Firmware einfach nach...
Ich finde es schon fast kindisch, wenn man sich über sowas aufregt. Stell dir vor, Debian würde irgendwann contrib und non-free komplett abschaffen. Dann könntest du dich darüber beschweren. Solange man dir diesen Luxus aber bietet, solltest du dich auch nicht darüber beschweren...
Martin, du hast anscheinend die kritik dahinter nicht verstanden oder nicht weiter gedacht. Das bios deines rechners ist sicher auch unfrei, oder die firmware in deinem rom auf der Netzwerkkarte usw. Es kann doch nicht sein, das die flexiblere verwendung von firmware-images dem benutzer zum nachteil wird. Ich denke viele werden die mitgelieferte firmware auf dem rom der Netzwerkkarte nicht updaten. Aber es kann zum Vorteil sein diese flexibel austauschen zu können. Jahre lang haben wir uns über die radeon treiber aufgeregt, das sie nicht genug können usw. Jetzt könnten sie genug und debian findet wieder einen weg das zum Nachteil für den benutzer auszulegen. Das ist ein problem in deren Freiheit emfinden. Übertriebene Freiheit führt zur unfreiheit.
Da Debian das trotzdem so durchziehen wird, bleibt dem Nutzer nur die Möglichkeit, diese neue Firmwarepolitik zu akzeptieren oder weiter zu ziehen. Ich habe mich für Letzteres entschieden, da der eingebaute Netzwerkchip meines Rechners in Squeeze nicht mehr unterstützt wird (ebenfalls ein e100). Ein Debian während der Installation nicht mehr direkt mit dem Internet zum Zwecke des Updatens bzw. des Nachladens noch fehlender Pakete verbinden zu können, macht keinen Sinn mehr, zumal man gewöhnt ist, Debian mit nur einer CD komplett zu installieren. Dass meine alte Radeon mit Debian Squeeze Main seine 3D-Fähigkeit verlieren wird, das hätte ich noch verschmerzen können. Aber Netzwerk ist essentiell. Und nein, ich werde nicht in einem von Debian nicht unterstützten non-free-Repo herumsuchen.
http://www.debian.org/doc/developers-reference/resources.html The main section of the Debian archive is what makes up the official Debian GNU/Linux distribution. The main section is official because it fully complies with all our guidelines. The other two sections do not (Anm. des Autors: contrib + non-free), to different degrees; as such, they are not officially part of Debian GNU/Linux.
Von Kevin Krammer am Di, 20. Oktober 2009 um 13:36 #
Ich denke viele werden die mitgelieferte firmware auf dem rom der Netzwerkkarte nicht updaten. Aber es kann zum Vorteil sein diese flexibel austauschen zu können.
So weit ich das verstanden habe wird die Hochladefunktion ja eh nicht aus dem Treiber entfernt, sondern das aktuellste Firmware Update als extra Paket gehandhabt.
Wer also die Firmware im EEPROM/Flash der Karte updaten will, braucht nur dieses andere Paket zu installeren (bzw. unabhängig vom Kernel updaten) und der Treiber erledigt den Rest.
Natürlich wäre es fein, das zum Zeitpunkt der Veröffentlichung aktuellste Update mit auf die Installations-CDs zu packen, aber dort werden halt derzeit nur Pakete aus "main" verwendet. Eventuell kann ja jemand anderer alternative CDs zur Verfügung stellen, die eben auch ausgewählte Pakete aus non-free beinhalten.
Das Problem ist doch aber, das jemand Debian Squeeze installieren wird und über diese Firmwaregeschichte nicht Bescheid weiß. Wer rechnet schon damit, dass ein seit Ewigkeiten unterstützter Netzwerkchip wie e100 plötzlich nicht mehr funktioniert? Die Frage ist dann nur, um welche jemands es sich da handeln wird, wie groß ihre Zahl sein wird und wieviele dieser Personen in diesem Fall dann eine andere Distro benutzen werden. Auf die Auswirkungen dieser neuen Firmwarepolitik kann man schon gespannt sein. Wirklich "lustig" finde ich auch, dass Debian die unfreie Firmware aus dem Kernel entfernt, Ubuntu baut sie wieder ein und Gnewsense z.B. entfernt sie dann wieder. Irgendwie höchst effektiv.
Von Kevin Krammer am Di, 20. Oktober 2009 um 14:05 #
Wer rechnet schon damit, dass ein seit Ewigkeiten unterstützter Netzwerkchip wie e100 plötzlich nicht mehr funktioniert?
Das verstehe ich jetzt nicht ganz. Wieso hört der Netzwerkchip auf zu funktionieren wenn man kein Firmware-Update einspielt? Ist die zur Zeit eingespielte Firmware irgendwie zeitlich begrenzt?
Auf die Auswirkungen dieser neuen Firmwarepolitik kann man schon gespannt sein.
Ich scheine da nicht am Laufenden zu sein, denn ich dachte Code und Daten in "main" sind immer DFSG-free. Gab es da eine Ausnahme für Firmware?
Bisher war die unfreie e100-Firmware im Debian-Kernel enthalten, demnächst ist das nicht mehr so. Drei weit verbreitete Intel-e100-Netzwerkchips funktionieren dann nicht mehr mit Debian Main. Die unfreie Firmware fehlt dann ganz einfach (sie soll nach non-free verschoben werden, fehlt also auf den Installations-CDs).
Von Kevin Krammer am Di, 20. Oktober 2009 um 15:57 #
Nur damit ich das richtig verstehe: die Hardware ist als im Auslieferungszustand nicht funktionsfähig und muss durch ein zur Laufzeit (über den Treiber) durchgeführtes Update Instand gesetzt werden?
Genau. Die drei betroffenen e100-Chips funktionieren mit den Debian-Squeeze-Installations-CDs erst einmal nicht. Erst muß die unfreie e100-Firmware aus non-free eingespielt werden, die sich normalerweise im Kernel befinden würde, wenn man sie nicht bewusst entfernt hätte. Normalerweise würde man eine solche Firmware aus einem ROM-Chip laden, in diesem Fall lädt man halt den unfreien Firmware-Microcode aus dem e100-Kerneltreiber. Das Gleiche gilt im übrigen für die mga-, r128- und radeon-Firmware trotz gültiger Lizenzen, die ausdrücklich jedermann das Verteilen der Firmware erlauben (das gilt auch für die e100-Firmware). Nur hier sind die Auswirkungen nicht so schlimm, da meist nur die 3D-Beschleunigung und in einigen Fällen auch die 2D-Hardwarebeschleunigung verloren geht.
Von Kevin Krammer am Di, 20. Oktober 2009 um 18:15 #
Genau. Die drei betroffenen e100-Chips funktionieren mit den Debian-Squeeze-Installations-CDs erst einmal nicht.
Ziemlich bedauerlich, dass es mittlerweile schon so weit gekommen ist, dass Hardwarehersteller etwas liefern, was erstmal nicht funktioniert und erst mal durch Software gefixt werden muss.
Verbesserungen oder Zusatzfunktionalität, die zum Zeitpunkt der Hardwareproduktion noch nicht fertig war, lasse ich mir ja noch einreden, aber zumindest die Grundfunktionalität sollte schon im Auslieferungzustand funktionieren.
Ist schon interessant, welche Schweinereien manchmal aufgedeckt werden, wenn Firmen nicht mehr unter dem Schutzmantel de Versteckens und Verschweigens operieren können.
Hätte Intel die e100-Firmware auf einem ROM-Chip mit auf seinen Motherboards verbaut und würde unter Debian die e100-Firmware aus einem solchen ROM-Chip geladen werden und nicht aus dem Kernel-Microcode (der dann obsolet wäre), dann wäre für Debian alles in Ordnung.
Falls das jetzt nicht ironisch gemeint war: Eine Schweinerei ist das nicht, eher eine Unannehmlichkeit. Die Firmware-Geschichte ist direkt ein Ergebnis aus dem ernst genommenen Debian-Gesellschaftsvertrag, der im Hinblick auf die Frage der Verteilung ausschließlich freier Software durch Debian zu 100% absolut ist:
"1. Debian wird zu 100% frei bleiben
Wir geben die Richtlinien, die wir verwenden, um zu bestimmen ob eine Arbeit "frei" ist, in dem "Die Debian-Richtlinien für Freie Software" genannten Dokument an. Wir versprechen, dass das Debian-System und alle dessen Komponenten entsprechend diesen Richtlinien frei sein werden. Wir werden Personen unterstützen, die freie und unfreie Arbeiten zu Debian erzeugen oder verwenden. Wir werden niemals das System von nicht-freien Komponenten abhängig machen." http://www.debian.org/social_contract.de.html
Von daher gibt es für Debian keinerlei Spielraum. Selbst die Konstruktion mit non-free ist IMHO angesichts dieser "Vorschrift" eigentlich unzulässig. Jeder Nutzer muß selbst wissen, ob er das mittragen möchte oder nicht.
Von Kevin Krammer am Di, 20. Oktober 2009 um 20:25 #
Eine Schweinerei ist das nicht, eher eine Unannehmlichkeit.
Schweinerei war vielleicht ein bischen zu hart forumliert, weil der Hersteller zumindest in diesem Fall ja eine kostenlose Möglichkeit zur Problembehebung bereitstellt.
Es ist allerdings schon bedenklich, dass bewußt mit einem unvollständigen und funktionsuntüchtigen Gerät oder Bestandteil in Produktion und Handel gegangen wird, weil man schon darauf hin plant, die eigentliche beworbene Funktionalität erst nachträglich durch eine Art Update/Fix zu erreichen.
Selbst die Konstruktion mit non-free ist IMHO angesichts dieser "Vorschrift" eigentlich unzulässig.
Ich vermute, dass es dafür eine spezielle Ausnahmeregelung gibt, also für Code und Daten, die zwar verbreitet aber nicht (oder nur begrenzt) verändert werden dürfen. Ansich ein sehr praktikabler Ansatz, denn sowohl Verzicht als auch Verwendung derart behandelter Pakete ist gleichermaßen einfach (Entfernen, respektive Hinzufügen eines Repositories im Paketmanager).
In vorliegendem Fall, wo Hardware in einem funktionsuntüchtigen Zustand ausgeliefert wurde und ausgerechnet diese Hardware für den Zugriff aus dieses extra Repository nötig ist, hat man natürlich eine Art Deadlock.
Man kann nur hoffen, dass die dadurch entstehenden Unannähmlichkeiten zumindest bei einigen Betroffenen die Erkenntnis weckt, dass ein Mangel vom Hersteller geschickt kaschiert werden kann, solange niemand all zu genau hinsieht.
Ich selbst bin zwar nicht betroffen, aber ich denke ich werde in Zukunft verstärkt darauf achten, dass Hardware im Originalzustand zumindest die Grundfunktionalität ihrer Kategorie besitzt.
"Es ist allerdings schon bedenklich, dass bewußt mit einem unvollständigen und funktionsuntüchtigen Gerät oder Bestandteil in Produktion und Handel gegangen wird, weil man schon darauf hin plant, die eigentliche beworbene Funktionalität erst nachträglich durch eine Art Update/Fix zu erreichen."
Interessanter Punkt. Wenn man ein Stück Hardware kauft, dann sollte man also nach Deiner Meinung darauf zählen können, dass alles für die reine Hardwarefunktionalität Wichtige - wie etwa die Firmware - mit in die Hardware integriert ist. Die betreffenden e100-Chips funktionieren ohne die unfreie Firmware schließlich nicht richtig. Trotz gekauften Hardwareproduktes hängt es dann vom Gutdünken des Herstellers ab, ob ein funktionsfähiger Treiber - mit unfreier Firmware - unter einem bestimmten Betriebssystem vorhanden ist oder nicht, je nachdem, welche Lizenz der Hardwarehersteller hier gewählt hat.
So gesehen sollte ich den e100-Onboard-Chip vielleicht tatsächlich stillegen. Das muß ich mir aber noch genau überlegen.
Von Kevin Krammer am Mi, 21. Oktober 2009 um 13:11 #
Wenn man ein Stück Hardware kauft, dann sollte man also nach Deiner Meinung darauf zählen können, dass alles für die reine Hardwarefunktionalität Wichtige - wie etwa die Firmware - mit in die Hardware integriert ist.
Man sollte sich darauf verlassen können, dass zumindest die eigentliche Grundfunktionalität zur Verfügung steht. Im Falle eine Netzwerkchips zumindest eine der langsameren Varianten des entsprechenden Protokolls (sollte auch nicht so schwierig sein, Hersteller schaffen dass schon seit Jahrzehnten).
Wenn man dann für die volle Leistung ein Update braucht, ist das zwar immer noch Mist, aber wenigstens nicht nur Staubfänger.
Wobei es da juristisch interessant werden könnte, je nachdem wie das Produkt beworben wird. In anderen Branchen gibt es dafür ja entsprechende Formulierungen (z.B. bei Autos "..ab XYZ PS.."). Als Äquivalent könnte ich mir da bei Netzwerkhardware vorstellen, dass das dann in etwa so formuliert ist "Ethernet am 10MBit*" und irgendwo im üblichen Kleingedruckten "*die für 100MBit nötige Zusatzsoftware ist im Lieferumfang enthalten".
Bei Grafikkarten scheint das ja, abgesehen von der irreführenden bzw. ungenauen Werbung, schon zu funktionieren. Zumindest Darstellung nach VESA funktioniert immer, für die Ausnutzung von Zusatzfunktionen braucht man dann noch alles Mögliche. Von spezieller Firmware über spezielle Treiber bis zu herstellerspezifischen OpenGL Bibliotheken.
Aber der Punkt ist, so wie gekauft kann man sie, wenn auch mit Einschränkungen, immer in Betrieb nehmen.
So gesehen sollte ich den e100-Onboard-Chip vielleicht tatsächlich stillegen. Das muß ich mir aber noch genau überlegen.
Das ist vielleicht ein bischen übertrieben, du hast diese Hardware ja schon. Es scheint nur wieder mal nötig zu werden, beim Kauf genauer hinzusehen.
Am ehesten fällt mir dazu als Vergleich die Situation früher mit WinModems oder GDI-Druckern ein. Damals sind auch eine Reihe Hersteller auf Billigmassenprodukte umgestiegen und wer zuverlässig funktionierende Geräte wollte, musste das halt beim Kauf berücksichtigen.
Es gibt auch noch den freien Treiber eepro100, der wurde seinerzeit zugunsten e100 blacklisted und duerfte vermutlich wieder whitelisted werden wenn e100 rausfliegt.
eepro100 ist im neueren Kerneln nicht mehr enthalten. Den müßte Debian schon höchstselbst einfügen. Außerdem laufen einige ältere e100-Chips auch ohne die unfreie e100-Firmware, während wiederum nicht alle neueren e100-Chips mit dem freien eepro100 laufen. Siehe u.a.: http://packages.debian.org/de/squeeze/firmware-linux Letzendlich muß man "nur" wissen, dass man sich dieses knapp unter 600kb große Paket vor einer Installation bzw. vor einem Update auf Squeeze herunterlädt, wenn sich etwa die betroffenen e100-Onboard-Netzwerkchips auf dem Motherboard befinden. Wenn man das vergisst, kommt man halt erst einmal nicht ins Internet und muß sich kurzfristig andere Wege suchen, um dieses Paket herunterzuladen. Denn dieses kleine Paket wird sich auf keiner offiziellen Debian-Installations-CD befinden, da diese niemals non-free-Repo-Pakete enthält. Natürlich kann man sich dieses Paket auch über den Start irgendeiner Ubuntu-Live-CD herunterladen, aber gerade hier ist der Ubuntu-Installations-Button nicht sehr weit.
>Ich scheine da nicht am Laufenden zu sein, denn ich dachte Code und Daten in "main" sind immer DFSG-free. Gab es da eine Ausnahme für Firmware?
Firmware war bisher direkt in main bzw. in Linux enthalten. Eine Ausnahme gab es dafür aber nicht, der Bug war bekannt und wurde lediglich von Release zu Release auf "ignore" gesetzt bzw. nicht als releasekritisch angesehen. Mit Squeeze will man den Bug jetzt wohl endlich los werden und hat begonnen Firmware nach non-free zu verschieben.
Komisches freiheitsemfinden haben die Leute hinter dem Debianvertrag. Der Kommentar von weiter oben immer eine funktionierende hardware zum auslieferungszeitpunkt zu erwerben war echt lächerlich. Die meisten heute erhältlichen geräte werden mittels firmware beim treiberladen erst funktionstüchtig. Das gilt nicht nur für die netzwerk oder Grafik-karten. DVB, scanner, modems und und und. Daher wird debian nur eines erreichen: 1. Sie werden massiv an benutzern verlieren 2. Ihre ohnehin schon verbesserungswürdige Benutzerfreundlichkeit wird weiter absacken.
Für die fast 10 Jahre Debiannutzung hier ist es echt ein schlag eine solche Entwicklung zu sehen. Das Argument: es steht im vertrag so - reicht mir nicht. Dann sollte man das Werk überarbeiten, wenn das ziel die Einschränkung der Benutzerschaft mit sich bringt.
Die Geschichte mit der unfreien Firmware ist trotzdem eine Überlegung wert. Theoretisch könnte ein Hersteller seine Firmware von der Lizenz her z.B. nur für MacOSX oder Windows-Betriebssysteme zur Verfügung stellen. Außerdem halten die Lizenzen für die Firmware im Kernel beim Nachforschen meist keiner eingehenden Überprüfung stand. Es gibt meist keine belastbaren schriftlichen Nachweise, dass die "Nutzungslizenzen" für die Firmware tatsächlich so gewährt wurden. Auf Nachfrage können die Firmen kaum antworten, da die Vorgänge schon zu lange zurückliegen. Kommerzielle Linuxdistributoren wie RedHat setzen sich somit (z.B. in den USA) einem unnötigen juristischen Risiko aus.
Gut ok das sehe ich sogar ein, aber debian ist kein komerziell operierendes Unternehmen. Auch ubuntu hat bisher keinen aufriß um die Firmwarethematik veranstaltet. Sicher ist eines: eine große zahl von hw wird nicht mehr out-of-the-box mehr laufen. Erst nach dem einspielen der pakete nach der einrichtung des internets (fals möglich) bringt den gewohnten zustand. Solche hersteller die keine einschränkungen was die verbreitung der fw angeht sollten bevorzugt nicht aus dem kernel entfernt werden. Falls der linux kernel firmwares bmitliefert, deren verbreitung der Hersteller nicht wünscht, würde ich ihre entfernung auch befürworten.
Von Kevin Krammer am Mi, 21. Oktober 2009 um 15:16 #
Sicher ist eines: eine große zahl von hw wird nicht mehr out-of-the-box mehr laufen. Erst nach dem einspielen der pakete nach der einrichtung des internets (fals möglich) bringt den gewohnten zustand.
Sieht so aus :( Ich frage mich manchmal wirklich, warum der IT Industrie derartige Privilegien gewährt werden. So neu und klein ist sie wirklich nicht mehr dass man sie nicht nach den selben Richtlinien behandeln könnte, die bei anderen Industriezweigen die Kunderechte schützen.
Solche hersteller die keine einschränkungen was die verbreitung der fw angeht sollten bevorzugt nicht aus dem kernel entfernt werden.
Soweit ich das verstanden habe geht es zumindest in diesem Fall nicht darum, dass etwas aus dem Kernel entfernt werden soll, sondern lediglich darum, dass bestimmte unfrei lizenzierte Teile als entsprechende Extrapakete nach Debian/non-free wandern.
Oder hab ich das falsch verstanden und die unfreien Teile können nicht normal nachinstalliert werden?
IMHO soll die Möglichkeit geschaffen werden, Firmware von einem seperaten Medium während der Inst. nachzuladen/installieren: http://www.debian.org/releases/stable/i386/ch06s04.html.de
Das einzelne Chips nur die Möglichkeit haben die entsprechende Firmware nachzuladen, liegt einfach schlicht und ergreifend darin begründet das der Hersteller keine Chipfläche für EEPROM oder Flash Speicher benötigt, der ROM-Inhalt müsste in jedem Fall also ins interne RAM kopiert werden. Flash oder Eeprom ist für viele Anwendungen einfach zu langsam oder nicht geeignet um von dort direkt Programme auszuführen (Flash kann keine nicht einzelnen Bytes adressieren). Z.b. FPGAs enthalten kein Flash oder Eeprom Spreicher. Der RAM-Loader kann platzsparend als maskenprogrammiertes ROM auf dem Chip liegen und benötigt keine speziellen Prozessschritte bei der Herstellung des Chips.
Chipfläche und Prozessschritte sind u.a. wesentliche Kostenfaktoren bei der Chipherstellung.
Das OpenSSH Problem ist ein alter Hut. Dies noch als Argument zu verwenden zeigt nur, dass man nun einen kritischen Punkt hatte und Debian auch nicht perfekt sein kann.
Klar ist es schade, dass sowas passiert ist aber damit Ubuntu, was diesen Fehler auch hatte, nun als Lösung dafür anzubieten ist Schwachsinn.
Anbei verwendet Wikipedia auch nur die LTS Versionen von Ubuntu und kommt damit auch nur auf das was Debian stable ist. Also sehe ich hier keinen ernsthaften Grund für Ubuntu. Debian schreibt dann meist die Patches für ie anfällige Software und Ubuntu verteilt diese dann einfach per LTS an die Server.
Also warum Ubuntu nehmen wenn es bei Debian dann die Patches gibt :/?
> Also warum Ubuntu nehmen wenn es bei Debian dann die Patches gibt :/?
Weil man sich bei Ubuntu Support deriekt vom Vendor hinzukaufen kann. Bei Debian sucht man sich erstmal eine IT-Bude die das machen würde, was aufwändiger wäre.
Ja, sehr aufwendig "Linux Systemhaus" in $Suchmaschine einzutippen. Ist ja auch grauenvoll, diese Qual der Wahl der Systemhäuser! Da nehm ich lieber Canonical und nur Canonical denn Canonical ist Gott?
> Ja, sehr aufwendig "Linux Systemhaus" in $Suchmaschine einzutippen.
Wenn du Aufträge vergibst ohne unabhängige Referenzen einzuholen und zu vergleichen, kannst du das gerne auf das von dir genannte reduzieren. Mit der Realität hat das bei Leuten die nachhaltig planen wenig zu tun.
Es handelt sich um ein Openssl-Debakel, das natürlich auch Auswirkungen auf Openssh hatte. Die Ursache war aber das Löschen von zwei Zeilen im Openssl-Sourcecode. Eine Änderung war o.k., die andere leider nicht.
> Ich fände es aber nicht förderlich wenn Debian wegen Ubuntu seine Zeiten ändert.
Auf lange Sicht fände ich es nicht schlecht, wenn sich die Zeiten (und damit die Codebasis) von *buntu-LTS und Debian zeitlich nähern würden. Dann könnte es Pakete geben die darauf ausgelegt sind auf beiden zu laufen. Jetzt kannst du meist ein Ubuntu-Packet mit etwas Glück auf Debian laufen lassen wenn sie in ähnlichen Zeitraum veröffentlich wurden. Aber meist hat Ubuntu einfach mal wild Unstable abegeriffen und es hat dann nichts mit dem späteren Debian-Release zu tun. Wenn die jetzt koordiniert mit der LTS und der Freeze-Phase die unstabel abgreifen, ist es für (kommerzielle) Entwickler viel einfacher vorgefertigte Pakete zu erstellen, Weil Libraries und Programmversionen nahezu identisch sind.
Zur Zeit sieht es wohl noch so aus, dass Ubuntu 10.04 ein LTS-Release wird. Außerdem sollte man den folgenden Text in Debians Verlautbarung nicht überlesen: "As in our previous update, we want to stress that the state of unstable and testing is not very good. We still have a large number of Release Critical bugs and problems ensuring the smooth transition of packages to testing."
Nachfolger ist die im Kernel integrierte KVM: http://www.linux-kvm.org/page/Main_Page
Hab die KVM selber im Einsatz und muss sagen, dass man zwischen der Vollvirtualisierung mit CPU-Hilfe und der Paravirtualisierung fast keinen Unterschied bemerkt.
KVM benötigt halt die CPU-Unterstützung, womit sie für ältere Hardware nicht nutzbar ist. Gilt leider auch für billige Hardware der aktuellen Generation ...
Ja und Nein. Bisher hat eigentlich nur RedHat Xen Adieu gesagt. Nun folgen Debian und Derivate. Mal sehen wie lange Novell/Suse noch Xen supported. Und paravirt-ops Dom0 Unterstützung im Kernel scheint auch auf den St.Nimmerleinstag verschoben worden zu sein.
>KVM benötigt halt die CPU-Unterstützung, womit sie für ältere Hardware nicht nutzbar ist. >Gilt leider auch für billige Hardware der aktuellen Generation ...
Hab hier eine brandneue Quadcore-CPU von Intel (Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz). Zu meiner eigenen Überraschung hat diese keine VT-Unterstützung. Da lobe ich mir AMD, die haben in allen neueren Athlons und Phenoms AMD-V (Pacifica) drin.
> Hab hier eine brandneue Quadcore-CPU von Intel (Intel(R) Core(TM)2 Quad CPU > Q8200 @ 2.33GHz). Zu meiner eigenen Überraschung hat diese keine > VT-Unterstützung. Da lobe ich mir AMD, die haben in allen neueren Athlons und > Phenoms AMD-V (Pacifica) drin.
Hab nie verstanden, warum alle auf diese Intel-Teile (E7200, Q8200) abfahren und warum die überall empfohlen werden. Da werden sich noch einige wundern, wenn ihre tolle Intel-CPU unter Windows 7 mit dem XP Mode nix anfangen kann... Für mich ist das mit der undurchsichtigen VT-Unterstützung der Grund, kein Intel zu kaufen. Ich hab keine Lust, erst alle Datenblätter zu lesen, bevor ich was kaufe.
Von DerBeobachter am Di, 20. Oktober 2009 um 13:52 #
Also ich war lange Zeit Debian Nutzer und war damit auch zufrieden. Seit 1-2 Jahren verwende ich jetzt aber fest ArchLinux. Das hat zwar einige deutliche Unterschiede zu Debian und ich wüßte auch nicht, ob ich es auf einem (Produktiv)Server einsetzen würde, aber auf dem Desktop läuft es sehr stabil.
Von meinen Desktop Erfahrungen damit, kann ich nur sagen, dass ArchLinux Debian in Sachen Stabilität in NICHTS nachsteht. Und das Arch Team patcht so wenig an den Paketen rum wie möglich. Also das komplette Gegenteil zu Debian.
Da fragt man sich dann schon, ob das überhaupt noch Sinn macht. Und dazu kommt, dass Debian doch eine Sicherheitslücke z.B. im Apache wieder zurück an das Apache Projekt meldet und den Patch bereit stellt oder sehe ich das falsch? Wenn Arch dann also eine aktuellere Version von Apache verwendet, müsste diese Version doch schon gepatcht sein?!
Oder funktioniert das nur in der Theorie eines Nicht-Programmierers so?
Hast du dir schon mal den Inhalt von diversen *.src.deb Paketen angesehen? Debian kann gar nicht anders, als herumpatchen. Das Backporten von Sicherheitspatches dürfte mit die langwierigste Aufgabe der Debian-Maintainer sein. Und ob jeder Maintainer die notwendigen Skills hat den Sicherheitsfix von foo 2.2.x auch sauber in foo 2.0.x zu implementieren, dafür würde ich meine Hand nicht ins Feuer legen.
Ok, wir reden hier von Security-Patches. Sagt das doch ;) Hierbei handelt es sich meist um Patches, die direkt von Upstream zurück portiert werden, bzw. oft sogar von pstream selbst für die betroffenen Versionen freigegeben werden.
Die Maintainer sind dafür übrigens nicht direkt selbst zuständig, sondern in Stable wird das vorm, durchaus kompetenten, Security-Team übernommen.
Von DerBeobachter am Di, 20. Oktober 2009 um 14:52 #
Na das ist doch kein Geheimnis, dass Debian viel an den Paketen macht.
Ich versteh ja, wenn Debian sagt, wir warten lieber noch ein paar Monate, bis wir eine neu Major Release (KDE 4/Gnome3/...) pushen. Aber woran denkst Du liegt es, dass Lenny immer noch mit Gnome 2.20.x (Quelle: Distrowatch) läuft und nicht mit .24 oder .26 ? Da müssten sie jedesmal wieder und wieder durchgehen und Alles "nachpatchen".
Und da weiß ich als Nicht-Programmierer halt auch nicht, ob es nicht vielleicht besser wäre einfach direkt die .28 zu verwenden. Kann mir nicht vorstellen, dass die Gnome-ler kein Interesse an Bugfixes/Security-Fixes haben.
Das lag an einigen wenigen schweren Bugs in Gnome 2.22 (Nautilus, GDM, gvfs), die vor dem Freeze nicht beseitigt werden konnten. Außerdem hielt Debian gvfs generell für zu unausgereift. Das Resultat ist im übrigen ein Gnome 2.20/2.22-Mix, also eine Art Gnome 2.22 mit Kernkomponenten aus Gnome 2.20. Etwas Fatales wie das hier https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/216104 wurde damit von Debian bewusst vermieden.
ArchLinux, Klasse..........das habe ich gemerkt als ich letzte Woche nach einem pacman -Syu vor einem Rechner zusammengebrochen bin, der nicht mehr booten wollte. Und um dir den Wind aus den Segeln zu nehmen, es stand keine Ankündigung auf der Projektseite dass es Probleme geben könnte!
Zum Beweis: http://forum.archlinux.de/?id=20;page=Postings;thread=14118
<<<Von meinen Desktop Erfahrungen damit, kann ich nur sagen, dass ArchLinux Debian in Sachen Stabilität in NICHTS nachsteht.<<<
Lächerlich! Meine Erfahrungen sagen da was anderes. Nach einem Halben Jahr Archlinux und vielen grauen Haaren nieee wieder.
Von Sepps Rache am Di, 20. Oktober 2009 um 14:14 #
Vielleicht ist CentOS als Red-Hat-Nachbau für den einen oder anderen eine sinnvolle Alternative, was Releasezyklen und Unterstützung angeht. CentOS 5.4 sollte sehr bald veröffentlicht werden; auf den Spiegeln ist es schon vorhanden.
>Vielleicht ist CentOS als Red-Hat-Nachbau für den einen oder anderen eine sinnvolle Alternative
Nur bedingt. CentOS bringt nur eine Handvoll Pakete mit, teilweise fehlen essentielle Dinge sowohl für den Desktop als auch für den Serverbetrieb (beispielsweise Bacula oder syslog-ng). Und dann fängt man an Dritt-Repositories wie EPEL oder RPMForge zu benutzen. Wie es da mit Sicherheitsupdates aussieht kann kein Mensch sagen.
Ich bin mir nicht sicher ob ich das nächste Upgrade noch mitmachen soll. Hab in der Vergangenheit schlechte Erfahrungen mit Debian auf anderen Servern gehabt und bin dort bereits auf Ubuntu Server Edition gewechselt. Bin schon lange am überlegen das auch auf meinem eigenen Server zu machen. Aber wenn es läuft, dann läuft es und man ist natürlich froh da keine Arbeit zu haben und lässt es erstmal so. Debian 6 wäre vielleicht ein guter Zeitpunkt anstatt des Upgrades gleich den Server neu aufzusetzen mit Ubuntu Server.
Mir sind auch die Updates bei Debian etwas langsam. Wenn ich sehe was da an Updates auf den Ubuntu Maschinen aufläuft, bekomme ich kein gutes Gefühl bei Debian nicht doch irgendwelche Sicherheitskritischen Updates verpasst zu haben. Könnte mir vorstellen, nicht der einzige zu sein der so denkt?
Ubuntu liefert sehr viele "Updates" mit, die nichts mit Security-Updates zu tun haben, z.B.: http://packages.ubuntu.com/hardy-updates/ Z.B. im Hardy-Fall reichen "Hardy" und "Hardy-Security", "Hardy-Updates" braucht man nicht. Gnewsense macht das genau so. Auch dort ist die Anzahl der Aktualisierungen weitaus geringer. Bei Debian Stable sind solche Updates (die sog. "empfohlenen Aktualisierungen") wie bei Ubuntu so gut wie nicht verbreitet, da der fehlerbehaftete, zum Teil afunktionale Code schon während der langen Freeze-Phase aus Debian Stable eliminiert wurde.
Ne. Auch Debian Stable hat diverse Probleme in Software, die aber nicht gefixt wird, wenn sie nicht sicherheitskritisch ist. Sowohl der Ubuntuweg als auch der Debianweg macht Sinn. Wenn du ein Debianserver am laufen hast, dann sind dir die funktionellen Bugs schon egal und dann freust du dich wenn du nur sicherheitskritische Updates bekommst. Für den Desktop finde ich es dagegen netter, wenn diverse auch nicht sicherheitskritische Fehler rausgepatcht werden.
Der Ubuntuweg macht ja nur dann Sinn, wenn Ubuntu z.B. für "Hardy-Updates" ebenfalls Sicherheitsupdates bereit stellt. Geschieht das auch? Theoretisch könnte ja eine in Hardy-Updates aktualisierte Version eines Programms nach einiger Zeit eine Sicherheitslücke aufweisen, die in der ursprünglichen, nicht aktualisierten Hardy-Version gar nicht vorkommt, weshalb dann hierfür auch kein Sicherheitsupdate notwendig wäre.
Ich habe sowohl die Debian als auch die Ubuntu Security-Mailinglisten abonniert. Bei den meisten kritischen Lücken kamen die Benachrichtigungen und Patches bei Debian schneller als bei Ubuntu. Und auch auf der DFN-Cert-Liste werden häufig die Sicherheitsupdates von Debian früher als bei vielen anderen großen Distros gemeldet.
(Disclaimer ;-): Diese Aussagen sind gefühlt aus dem Gedächtnis; um diese zu verifizieren müsste ich mich langwierig durch meine Mailarchive wühlen)
Ich finde ja schon, das debian eine deutlich stabilere distro abliefert wie ubuntu.
Zudem beinhaltet die ubuntu distro oftmals keine aktuellen versionen von weniger verbreiteten Programmen.
Sie aktualisieren die für den (normalen) User sichtbaren programme.
Linphone oder twinkle sind beispiele für solche applications, die in einer älteren version ausgeliefert worden sind, obwohl die stabilen versionen zum release-Zeitpunkt verfügbar waren. Andererseits wird auch wenns erst am letzten Tag fertig wird immer der neuste kernel + neuste GNOME Version ausgeliefert.
Was mich an Debian deutlich mehr ankotzt ist die Firmwarepolitik. Ich werde es sicher nicht verstehen, das der radeon treiber, e100, und weitere ohne firmware aus nonfree nicht laufen werden. Dadurch entfällt die netinstalloption auf note/netbook für debian komplett.
Den es ist sogar insgesamt betrachtet korrekt so.
Den die unfreie Firmware, von der es keine Quellen für die Debian Entwickler gibt, darf dort nicht in main sein.
Wenn es dir nicht passt, dann ist es dein Problem.
Laut den Richtlinien muss nämlich alles davon offen sein, damit es in main sein kann.
Und wenn du so dringend die Daten brauchst dann installier dir die Firmware einfach nach...
Ich finde es schon fast kindisch, wenn man sich über sowas aufregt.
Stell dir vor, Debian würde irgendwann contrib und non-free komplett abschaffen.
Dann könntest du dich darüber beschweren.
Solange man dir diesen Luxus aber bietet, solltest du dich auch nicht darüber beschweren...
Martin
Das bios deines rechners ist sicher auch unfrei, oder die firmware in deinem rom auf der Netzwerkkarte usw.
Es kann doch nicht sein, das die flexiblere verwendung von firmware-images dem benutzer zum nachteil wird.
Ich denke viele werden die mitgelieferte firmware auf dem rom der Netzwerkkarte nicht updaten.
Aber es kann zum Vorteil sein diese flexibel austauschen zu können.
Jahre lang haben wir uns über die radeon treiber aufgeregt, das sie nicht genug können usw. Jetzt könnten sie genug und debian findet wieder einen weg das zum Nachteil für den benutzer auszulegen.
Das ist ein problem in deren Freiheit emfinden. Übertriebene Freiheit führt zur unfreiheit.
Ich habe mich für Letzteres entschieden, da der eingebaute Netzwerkchip meines Rechners in Squeeze nicht mehr unterstützt wird (ebenfalls ein e100). Ein Debian während der Installation nicht mehr direkt mit dem Internet zum Zwecke des Updatens bzw. des Nachladens noch fehlender Pakete verbinden zu können, macht keinen Sinn mehr, zumal man gewöhnt ist, Debian mit nur einer CD komplett zu installieren.
Dass meine alte Radeon mit Debian Squeeze Main seine 3D-Fähigkeit verlieren wird, das hätte ich noch verschmerzen können. Aber Netzwerk ist essentiell.
Und nein, ich werde nicht in einem von Debian nicht unterstützten non-free-Repo herumsuchen.
huch, non-free wird doch von Debian offiziell unterstützt...
genau das ist wohl auch der Grund, warum Debian nicht von der FSF empfohlen wird.
Viele Grüße,
Holger
The main section of the Debian archive is what makes up the official Debian GNU/Linux distribution. The main section is official because it fully complies with all our guidelines. The other two sections do not (Anm. des Autors: contrib + non-free), to different degrees; as such, they are not officially part of Debian GNU/Linux.
Aber es kann zum Vorteil sein diese flexibel austauschen zu können.
So weit ich das verstanden habe wird die Hochladefunktion ja eh nicht aus dem Treiber entfernt, sondern das aktuellste Firmware Update als extra Paket gehandhabt.
Wer also die Firmware im EEPROM/Flash der Karte updaten will, braucht nur dieses andere Paket zu installeren (bzw. unabhängig vom Kernel updaten) und der Treiber erledigt den Rest.
Natürlich wäre es fein, das zum Zeitpunkt der Veröffentlichung aktuellste Update mit auf die Installations-CDs zu packen, aber dort werden halt derzeit nur Pakete aus "main" verwendet.
Eventuell kann ja jemand anderer alternative CDs zur Verfügung stellen, die eben auch ausgewählte Pakete aus non-free beinhalten.
Die Frage ist dann nur, um welche jemands es sich da handeln wird, wie groß ihre Zahl sein wird und wieviele dieser Personen in diesem Fall dann eine andere Distro benutzen werden.
Auf die Auswirkungen dieser neuen Firmwarepolitik kann man schon gespannt sein.
Wirklich "lustig" finde ich auch, dass Debian die unfreie Firmware aus dem Kernel entfernt, Ubuntu baut sie wieder ein und Gnewsense z.B. entfernt sie dann wieder. Irgendwie höchst effektiv.
Das verstehe ich jetzt nicht ganz.
Wieso hört der Netzwerkchip auf zu funktionieren wenn man kein Firmware-Update einspielt?
Ist die zur Zeit eingespielte Firmware irgendwie zeitlich begrenzt?
Auf die Auswirkungen dieser neuen Firmwarepolitik kann man schon gespannt sein.
Ich scheine da nicht am Laufenden zu sein, denn ich dachte Code und Daten in "main" sind immer DFSG-free. Gab es da eine Ausnahme für Firmware?
Drei weit verbreitete Intel-e100-Netzwerkchips funktionieren dann nicht mehr mit Debian Main.
Die unfreie Firmware fehlt dann ganz einfach (sie soll nach non-free verschoben werden, fehlt also auf den Installations-CDs).
Die drei betroffenen e100-Chips funktionieren mit den Debian-Squeeze-Installations-CDs erst einmal nicht. Erst muß die unfreie e100-Firmware aus non-free eingespielt werden, die sich normalerweise im Kernel befinden würde, wenn man sie nicht bewusst entfernt hätte.
Normalerweise würde man eine solche Firmware aus einem ROM-Chip laden, in diesem Fall lädt man halt den unfreien Firmware-Microcode aus dem e100-Kerneltreiber.
Das Gleiche gilt im übrigen für die mga-, r128- und radeon-Firmware trotz gültiger Lizenzen, die ausdrücklich jedermann das Verteilen der Firmware erlauben (das gilt auch für die e100-Firmware). Nur hier sind die Auswirkungen nicht so schlimm, da meist nur die 3D-Beschleunigung und in einigen Fällen auch die 2D-Hardwarebeschleunigung verloren geht.
Die drei betroffenen e100-Chips funktionieren mit den Debian-Squeeze-Installations-CDs erst einmal nicht.
Ziemlich bedauerlich, dass es mittlerweile schon so weit gekommen ist, dass Hardwarehersteller etwas liefern, was erstmal nicht funktioniert und erst mal durch Software gefixt werden muss.
Verbesserungen oder Zusatzfunktionalität, die zum Zeitpunkt der Hardwareproduktion noch nicht fertig war, lasse ich mir ja noch einreden, aber zumindest die Grundfunktionalität sollte schon im Auslieferungzustand funktionieren.
Ist schon interessant, welche Schweinereien manchmal aufgedeckt werden, wenn Firmen nicht mehr unter dem Schutzmantel de Versteckens und Verschweigens operieren können.
Falls das jetzt nicht ironisch gemeint war:
Eine Schweinerei ist das nicht, eher eine Unannehmlichkeit. Die Firmware-Geschichte ist direkt ein Ergebnis aus dem ernst genommenen Debian-Gesellschaftsvertrag, der im Hinblick auf die Frage der Verteilung ausschließlich freier Software durch Debian zu 100% absolut ist:
"1. Debian wird zu 100% frei bleiben
Wir geben die Richtlinien, die wir verwenden, um zu bestimmen ob eine Arbeit "frei" ist, in dem "Die Debian-Richtlinien für Freie Software" genannten Dokument an. Wir versprechen, dass das Debian-System und alle dessen Komponenten entsprechend diesen Richtlinien frei sein werden. Wir werden Personen unterstützen, die freie und unfreie Arbeiten zu Debian erzeugen oder verwenden. Wir werden niemals das System von nicht-freien Komponenten abhängig machen."
http://www.debian.org/social_contract.de.html
Von daher gibt es für Debian keinerlei Spielraum. Selbst die Konstruktion mit non-free ist IMHO angesichts dieser "Vorschrift" eigentlich unzulässig.
Jeder Nutzer muß selbst wissen, ob er das mittragen möchte oder nicht.
Schweinerei war vielleicht ein bischen zu hart forumliert, weil der Hersteller zumindest in diesem Fall ja eine kostenlose Möglichkeit zur Problembehebung bereitstellt.
Es ist allerdings schon bedenklich, dass bewußt mit einem unvollständigen und funktionsuntüchtigen Gerät oder Bestandteil in Produktion und Handel gegangen wird, weil man schon darauf hin plant, die eigentliche beworbene Funktionalität erst nachträglich durch eine Art Update/Fix zu erreichen.
Selbst die Konstruktion mit non-free ist IMHO angesichts dieser "Vorschrift" eigentlich unzulässig.
Ich vermute, dass es dafür eine spezielle Ausnahmeregelung gibt, also für Code und Daten, die zwar verbreitet aber nicht (oder nur begrenzt) verändert werden dürfen.
Ansich ein sehr praktikabler Ansatz, denn sowohl Verzicht als auch Verwendung derart behandelter Pakete ist gleichermaßen einfach (Entfernen, respektive Hinzufügen eines Repositories im Paketmanager).
In vorliegendem Fall, wo Hardware in einem funktionsuntüchtigen Zustand ausgeliefert wurde und ausgerechnet diese Hardware für den Zugriff aus dieses extra Repository nötig ist, hat man natürlich eine Art Deadlock.
Man kann nur hoffen, dass die dadurch entstehenden Unannähmlichkeiten zumindest bei einigen Betroffenen die Erkenntnis weckt, dass ein Mangel vom Hersteller geschickt kaschiert werden kann, solange niemand all zu genau hinsieht.
Ich selbst bin zwar nicht betroffen, aber ich denke ich werde in Zukunft verstärkt darauf achten, dass Hardware im Originalzustand zumindest die Grundfunktionalität ihrer Kategorie besitzt.
Interessanter Punkt.
Wenn man ein Stück Hardware kauft, dann sollte man also nach Deiner Meinung darauf zählen können, dass alles für die reine Hardwarefunktionalität Wichtige - wie etwa die Firmware - mit in die Hardware integriert ist. Die betreffenden e100-Chips funktionieren ohne die unfreie Firmware schließlich nicht richtig. Trotz gekauften Hardwareproduktes hängt es dann vom Gutdünken des Herstellers ab, ob ein funktionsfähiger Treiber - mit unfreier Firmware - unter einem bestimmten Betriebssystem vorhanden ist oder nicht, je nachdem, welche Lizenz der Hardwarehersteller hier gewählt hat.
So gesehen sollte ich den e100-Onboard-Chip vielleicht tatsächlich stillegen. Das muß ich mir aber noch genau überlegen.
Man sollte sich darauf verlassen können, dass zumindest die eigentliche Grundfunktionalität zur Verfügung steht.
Im Falle eine Netzwerkchips zumindest eine der langsameren Varianten des entsprechenden Protokolls (sollte auch nicht so schwierig sein, Hersteller schaffen dass schon seit Jahrzehnten).
Wenn man dann für die volle Leistung ein Update braucht, ist das zwar immer noch Mist, aber wenigstens nicht nur Staubfänger.
Wobei es da juristisch interessant werden könnte, je nachdem wie das Produkt beworben wird. In anderen Branchen gibt es dafür ja entsprechende Formulierungen (z.B. bei Autos "..ab XYZ PS..").
Als Äquivalent könnte ich mir da bei Netzwerkhardware vorstellen, dass das dann in etwa so formuliert ist "Ethernet am 10MBit*" und irgendwo im üblichen Kleingedruckten "*die für 100MBit nötige Zusatzsoftware ist im Lieferumfang enthalten".
Bei Grafikkarten scheint das ja, abgesehen von der irreführenden bzw. ungenauen Werbung, schon zu funktionieren. Zumindest Darstellung nach VESA funktioniert immer, für die Ausnutzung von Zusatzfunktionen braucht man dann noch alles Mögliche. Von spezieller Firmware über spezielle Treiber bis zu herstellerspezifischen OpenGL Bibliotheken.
Aber der Punkt ist, so wie gekauft kann man sie, wenn auch mit Einschränkungen, immer in Betrieb nehmen.
So gesehen sollte ich den e100-Onboard-Chip vielleicht tatsächlich stillegen. Das muß ich mir aber noch genau überlegen.
Das ist vielleicht ein bischen übertrieben, du hast diese Hardware ja schon.
Es scheint nur wieder mal nötig zu werden, beim Kauf genauer hinzusehen.
Am ehesten fällt mir dazu als Vergleich die Situation früher mit WinModems oder GDI-Druckern ein. Damals sind auch eine Reihe Hersteller auf Billigmassenprodukte umgestiegen und wer zuverlässig funktionierende Geräte wollte, musste das halt beim Kauf berücksichtigen.
e100 blacklisted und duerfte vermutlich wieder whitelisted werden wenn e100
rausfliegt.
Den müßte Debian schon höchstselbst einfügen.
Außerdem laufen einige ältere e100-Chips auch ohne die unfreie e100-Firmware, während wiederum nicht alle neueren e100-Chips mit dem freien eepro100 laufen.
Siehe u.a.:
http://packages.debian.org/de/squeeze/firmware-linux
Letzendlich muß man "nur" wissen, dass man sich dieses knapp unter 600kb große Paket vor einer Installation bzw. vor einem Update auf Squeeze herunterlädt, wenn sich etwa die betroffenen e100-Onboard-Netzwerkchips auf dem Motherboard befinden. Wenn man das vergisst, kommt man halt erst einmal nicht ins Internet und muß sich kurzfristig andere Wege suchen, um dieses Paket herunterzuladen.
Denn dieses kleine Paket wird sich auf keiner offiziellen Debian-Installations-CD befinden, da diese niemals non-free-Repo-Pakete enthält. Natürlich kann man sich dieses Paket auch über den Start irgendeiner Ubuntu-Live-CD herunterladen, aber gerade hier ist der Ubuntu-Installations-Button nicht sehr weit.
Firmware war bisher direkt in main bzw. in Linux enthalten. Eine Ausnahme gab es dafür aber nicht, der Bug war bekannt und wurde lediglich von Release zu Release auf "ignore" gesetzt bzw. nicht als releasekritisch angesehen. Mit Squeeze will man den Bug jetzt wohl endlich los werden und hat begonnen Firmware nach non-free zu verschieben.
Es war also weniger eine offizielle Ausnahme, sondern mehr ein Nebeneffekt weil man ja schlecht den ganzen Kernel nach non-free schieben konnte.
Das gilt nicht nur für die netzwerk oder Grafik-karten. DVB, scanner, modems und und und.
Daher wird debian nur eines erreichen:
1. Sie werden massiv an benutzern verlieren
2. Ihre ohnehin schon verbesserungswürdige Benutzerfreundlichkeit wird weiter absacken.
Für die fast 10 Jahre Debiannutzung hier ist es echt ein schlag eine solche Entwicklung zu sehen.
Das Argument: es steht im vertrag so - reicht mir nicht. Dann sollte man das Werk überarbeiten, wenn das ziel die Einschränkung der Benutzerschaft mit sich bringt.
Außerdem halten die Lizenzen für die Firmware im Kernel beim Nachforschen meist keiner eingehenden Überprüfung stand. Es gibt meist keine belastbaren schriftlichen Nachweise, dass die "Nutzungslizenzen" für die Firmware tatsächlich so gewährt wurden. Auf Nachfrage können die Firmen kaum antworten, da die Vorgänge schon zu lange zurückliegen. Kommerzielle Linuxdistributoren wie RedHat setzen sich somit (z.B. in den USA) einem unnötigen juristischen Risiko aus.
Sicher ist eines: eine große zahl von hw wird nicht mehr out-of-the-box mehr laufen. Erst nach dem einspielen der pakete nach der einrichtung des internets (fals möglich) bringt den gewohnten zustand.
Solche hersteller die keine einschränkungen was die verbreitung der fw angeht sollten bevorzugt nicht aus dem kernel entfernt werden.
Falls der linux kernel firmwares bmitliefert, deren verbreitung der Hersteller nicht wünscht, würde ich ihre entfernung auch befürworten.
http://git.kernel.org/?p=linux/kernel/git/torvalds/
linux-2.6.git;a=blob_plain;f=firmware/WHENCE
"This file attempts to document the origin and licensing information,
if known, for each piece of firmware distributed for use with the Linux
kernel."
Zum Teil steht wirklich dabei: "Licence: Unknown".
Sieht so aus :(
Ich frage mich manchmal wirklich, warum der IT Industrie derartige Privilegien gewährt werden. So neu und klein ist sie wirklich nicht mehr dass man sie nicht nach den selben Richtlinien behandeln könnte, die bei anderen Industriezweigen die Kunderechte schützen.
Solche hersteller die keine einschränkungen was die verbreitung der fw angeht sollten bevorzugt nicht aus dem kernel entfernt werden.
Soweit ich das verstanden habe geht es zumindest in diesem Fall nicht darum, dass etwas aus dem Kernel entfernt werden soll, sondern lediglich darum, dass bestimmte unfrei lizenzierte Teile als entsprechende Extrapakete nach Debian/non-free wandern.
Oder hab ich das falsch verstanden und die unfreien Teile können nicht normal nachinstalliert werden?
Das einzelne Chips nur die Möglichkeit haben die entsprechende Firmware nachzuladen, liegt einfach schlicht und ergreifend darin begründet das der Hersteller keine Chipfläche für EEPROM oder Flash Speicher benötigt, der ROM-Inhalt müsste in jedem Fall also ins interne RAM kopiert werden.
Flash oder Eeprom ist für viele Anwendungen einfach zu langsam oder nicht geeignet um von dort direkt Programme auszuführen (Flash kann keine nicht einzelnen Bytes adressieren). Z.b. FPGAs enthalten kein Flash oder Eeprom Spreicher.
Der RAM-Loader kann platzsparend als maskenprogrammiertes ROM auf dem Chip liegen und benötigt keine speziellen Prozessschritte bei der Herstellung des Chips.
Chipfläche und Prozessschritte sind u.a. wesentliche Kostenfaktoren bei der Chipherstellung.
Diese Möglichkeit soll nicht erst geschaffen, sie existiert bereits! Wie du aus dem von dir verlinkten Dokument entnehmen kannst.
Dies noch als Argument zu verwenden zeigt nur, dass man nun einen kritischen Punkt hatte und Debian auch nicht perfekt sein kann.
Klar ist es schade, dass sowas passiert ist aber damit Ubuntu, was diesen Fehler auch hatte, nun als Lösung dafür anzubieten ist Schwachsinn.
Anbei verwendet Wikipedia auch nur die LTS Versionen von Ubuntu und kommt damit auch nur auf das was Debian stable ist.
Also sehe ich hier keinen ernsthaften Grund für Ubuntu.
Debian schreibt dann meist die Patches für ie anfällige Software und Ubuntu verteilt diese dann einfach per LTS an die Server.
Also warum Ubuntu nehmen wenn es bei Debian dann die Patches gibt :/?
Weil man sich bei Ubuntu Support deriekt vom Vendor hinzukaufen kann. Bei Debian sucht man sich erstmal eine IT-Bude die das machen würde, was aufwändiger wäre.
Wenn du Aufträge vergibst ohne unabhängige Referenzen einzuholen und zu vergleichen, kannst du das gerne auf das von dir genannte reduzieren. Mit der Realität hat das bei Leuten die nachhaltig planen wenig zu tun.
Es handelt sich um ein Openssl-Debakel, das natürlich auch Auswirkungen auf Openssh hatte. Die Ursache war aber das Löschen von zwei Zeilen im Openssl-Sourcecode. Eine Änderung war o.k., die andere leider nicht.
Eine sehr, sehr erfreuliche Nachricht!
Ich fände es aber nicht förderlich wenn Debian wegen Ubuntu seine Zeiten ändert.
Martin M.
Seh ich auch so. Nach meiner Schätzung verkürzt sich die Laufzeit von Lenny dann um ca. 6 Monate. Technische Gründe dafür sehe ich nicht.
Auf lange Sicht fände ich es nicht schlecht, wenn sich die Zeiten (und damit die Codebasis) von *buntu-LTS und Debian zeitlich nähern würden. Dann könnte es Pakete geben die darauf ausgelegt sind auf beiden zu laufen. Jetzt kannst du meist ein Ubuntu-Packet mit etwas Glück auf Debian laufen lassen wenn sie in ähnlichen Zeitraum veröffentlich wurden. Aber meist hat Ubuntu einfach mal wild Unstable abegeriffen und es hat dann nichts mit dem späteren Debian-Release zu tun. Wenn die jetzt koordiniert mit der LTS und der Freeze-Phase die unstabel abgreifen, ist es für (kommerzielle) Entwickler viel einfacher vorgefertigte Pakete zu erstellen, Weil Libraries und Programmversionen nahezu identisch sind.
Außerdem sollte man den folgenden Text in Debians Verlautbarung nicht überlesen:
"As in our previous update, we want to stress that the state
of unstable and testing is not very good. We still have a large number
of Release Critical bugs and problems ensuring the smooth
transition of packages to testing."
Sieht so aus, als ob Xen so langsam das zeitliche segnen würde...
Nachfolger ist die im Kernel integrierte KVM:
http://www.linux-kvm.org/page/Main_Page
Hab die KVM selber im Einsatz und muss sagen, dass man zwischen der Vollvirtualisierung mit CPU-Hilfe und der Paravirtualisierung fast keinen Unterschied bemerkt.
KVM benötigt halt die CPU-Unterstützung, womit sie für ältere Hardware nicht nutzbar ist.
Gilt leider auch für billige Hardware der aktuellen Generation ...
Ja und Nein. Bisher hat eigentlich nur RedHat Xen Adieu gesagt. Nun folgen Debian und Derivate. Mal sehen wie lange Novell/Suse noch Xen supported. Und paravirt-ops Dom0 Unterstützung im Kernel scheint auch auf den St.Nimmerleinstag verschoben worden zu sein.
>KVM benötigt halt die CPU-Unterstützung, womit sie für ältere Hardware nicht nutzbar ist.
>Gilt leider auch für billige Hardware der aktuellen Generation ...
Hab hier eine brandneue Quadcore-CPU von Intel (Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz). Zu meiner eigenen Überraschung hat diese keine VT-Unterstützung. Da lobe ich mir AMD, die haben in allen neueren Athlons und Phenoms AMD-V (Pacifica) drin.
> Q8200 @ 2.33GHz). Zu meiner eigenen Überraschung hat diese keine
> VT-Unterstützung. Da lobe ich mir AMD, die haben in allen neueren Athlons und
> Phenoms AMD-V (Pacifica) drin.
Hab nie verstanden, warum alle auf diese Intel-Teile (E7200, Q8200) abfahren und warum die überall empfohlen werden. Da werden sich noch einige wundern, wenn ihre tolle Intel-CPU unter Windows 7 mit dem XP Mode nix anfangen kann...
Für mich ist das mit der undurchsichtigen VT-Unterstützung der Grund, kein Intel zu kaufen. Ich hab keine Lust, erst alle Datenblätter zu lesen, bevor ich was kaufe.
Von meinen Desktop Erfahrungen damit, kann ich nur sagen, dass ArchLinux Debian in Sachen Stabilität in NICHTS nachsteht. Und das Arch Team patcht so wenig an den Paketen rum wie möglich. Also das komplette Gegenteil zu Debian.
Da fragt man sich dann schon, ob das überhaupt noch Sinn macht.
Und dazu kommt, dass Debian doch eine Sicherheitslücke z.B. im Apache wieder zurück an das Apache Projekt meldet und den Patch bereit stellt oder sehe ich das falsch? Wenn Arch dann also eine aktuellere Version von Apache verwendet, müsste diese Version doch schon gepatcht sein?!
Oder funktioniert das nur in der Theorie eines Nicht-Programmierers so?
Wie kommst du denn da jetzt drauf? Unter Debian ist das nicht anders. Und erzähl mit jetzt nichts von OpenSSH. Ausnahmen bestätigen die Regel...
Hierbei handelt es sich meist um Patches, die direkt von Upstream zurück portiert werden, bzw. oft sogar von pstream selbst für die betroffenen Versionen freigegeben werden.
Die Maintainer sind dafür übrigens nicht direkt selbst zuständig, sondern in Stable wird das vorm, durchaus kompetenten, Security-Team übernommen.
Ich versteh ja, wenn Debian sagt, wir warten lieber noch ein paar Monate, bis wir eine neu Major Release (KDE 4/Gnome3/...) pushen.
Aber woran denkst Du liegt es, dass Lenny immer noch mit Gnome 2.20.x (Quelle: Distrowatch) läuft und nicht mit .24 oder .26 ? Da müssten sie jedesmal wieder und wieder durchgehen und Alles "nachpatchen".
Und da weiß ich als Nicht-Programmierer halt auch nicht, ob es nicht vielleicht besser wäre einfach direkt die .28 zu verwenden. Kann mir nicht vorstellen, dass die Gnome-ler kein Interesse an Bugfixes/Security-Fixes haben.
Etwas Fatales wie das hier
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/216104
wurde damit von Debian bewusst vermieden.
Zum Beweis: http://forum.archlinux.de/?id=20;page=Postings;thread=14118
<<<Von meinen Desktop Erfahrungen damit, kann ich nur sagen, dass ArchLinux Debian in Sachen Stabilität in NICHTS nachsteht.<<<
Lächerlich! Meine Erfahrungen sagen da was anderes. Nach einem Halben Jahr Archlinux und vielen grauen Haaren nieee wieder.
Für Multimedia empfehlen die folgendes:
http://wiki.centos.org/TipsAndTricks/Mu
ltimediaOnCentOS?highlight=%28multimedia%29
Anfang nächten Jahr müsste RH 6 erscheinen und dann folglich auch Centos 6.
Nur bedingt. CentOS bringt nur eine Handvoll Pakete mit, teilweise fehlen essentielle Dinge sowohl für den Desktop als auch für den Serverbetrieb (beispielsweise Bacula oder syslog-ng). Und dann fängt man an Dritt-Repositories wie EPEL oder RPMForge zu benutzen. Wie es da mit Sicherheitsupdates aussieht kann kein Mensch sagen.
Mir sind auch die Updates bei Debian etwas langsam. Wenn ich sehe was da an Updates auf den Ubuntu Maschinen aufläuft, bekomme ich kein gutes Gefühl bei Debian nicht doch irgendwelche Sicherheitskritischen Updates verpasst zu haben. Könnte mir vorstellen, nicht der einzige zu sein der so denkt?
http://packages.ubuntu.com/hardy-updates/
Z.B. im Hardy-Fall reichen "Hardy" und "Hardy-Security", "Hardy-Updates" braucht man nicht. Gnewsense macht das genau so. Auch dort ist die Anzahl der Aktualisierungen weitaus geringer.
Bei Debian Stable sind solche Updates (die sog. "empfohlenen Aktualisierungen") wie bei Ubuntu so gut wie nicht verbreitet, da der fehlerbehaftete, zum Teil afunktionale Code schon während der langen Freeze-Phase aus Debian Stable eliminiert wurde.
Geschieht das auch?
Theoretisch könnte ja eine in Hardy-Updates aktualisierte Version eines Programms nach einiger Zeit eine Sicherheitslücke aufweisen, die in der ursprünglichen, nicht aktualisierten Hardy-Version gar nicht vorkommt, weshalb dann hierfür auch kein Sicherheitsupdate notwendig wäre.
Bei den meisten kritischen Lücken kamen die Benachrichtigungen und Patches bei Debian schneller als bei Ubuntu.
Und auch auf der DFN-Cert-Liste werden häufig die Sicherheitsupdates von Debian früher als bei vielen anderen großen Distros gemeldet.
(Disclaimer ;-): Diese Aussagen sind gefühlt aus dem Gedächtnis; um diese zu verifizieren müsste ich mich langwierig durch meine Mailarchive wühlen)