Guten Morgen liebe Pro-Linux Leser. Ich bin eigentlich ein überzeugter debian Benutzer (gewesen). Die letzte Zeit jedoch ärgern mich grundlegende entscheidungen des Projektes. Die restriktive (für mich nicht nachvollziehbare) Politik wg den binären firmwares geht mir ziemlich auf den Wecker. Die netinst mit wlan zu installieren geht bei vielen wlan treibern mit externer firmware nicht. Weiter liefert debian einen kastrierten radeon treiber ohne xv/3d beschleunigung. Das ist für mich nicht nachvollziehbar, da sie mit so einer übertriebenen Vorgehensweise die Freiheit eher einschränken als fördern. Netzwerkkarten mit eingebauten rom, wo die firmware auch nicht frei ist wäre für debiananwender die beste wahl. Wenn so gängige hardware wie e100 und radeon künstlich eingeschränkt werden, habe ich dafür echt kein verständnis.
Im Artikel steht, dass die offiziellen debianpatches nicht enthalten sind in dem Echtzeitkernel. Das ist für den Debiananwender vielleicht ein segen. Dadurch entfällt das nachträgliche Einbinden von non-free und die Installation von firmware-linux.
Wenn Dir die Debian-Politik nicht gefällt, nimm eine andere Distrie. Es soll noch ein oder zwei andere geben Oder forke Debian und kleb die ganzen non-free Sachen rein. Aber akzeptiere das die Leute von Debian sich so entschieden haben, und so auch auf einen massiven Miststand aufmerksam machen! Das Problem ist nämlich nicht das Debian sich so entschieden hat, sondern die Anderen die CS-Zeugs zu ihrer Hardware vertreiben, statt mal ein paar ordenliche Datenblätter zu liefern.
Und das mit den Debian-patches gibt mir etwas zu denken, normalerweise wird die Version des Kernels festgehalten und Bug/Sicherheitslücken rausgepatcht. Ich hoffe diese Patches sind damit nicht gemeint.
Mir bleibt keine andere wahl als das zu akzeptieren. Wie immer bei solchen Dingen ist die Extreme hier mein Problem. Was hab ich von einer vorzeige freiheitsdistribution wenn die hw unterstützung bescheiden ist? Es kam ja bei der installation noch nicht mal ein hinweis, das ein zusätzliches paket erforderlich ist um 3d/xv ... für den radeon treiber aktivieren zu können.
Mir ist es lieber zu wissen, dass man vorsichtig sein sollte. Mit Debian kenne ich das System am Ende besser, als eine andere Distribution. Im Zweifelsfall kann ich besser reagieren.
Du hast aber recht, dass man für die Einrichtung ein bisschen zu viel Zeit braucht, aber es sollte alles vorhanden sein.
Mir liegt Debian einfach am Herzen, trotz seinen Stolpersteinen.
"Mit Debian kenne ich das System am Ende besser, als eine andere Distribution."
Das geht mit Slackware noch ein Stückchen besser. Und vor allen Dingen ist Slackwares Software- und Treiberzusammenstellung frei von jedem ideologischen Ballast, da meist genau das angeboten wird, was man direkt beim jeweiligen Projekt als Source herunterladen kann.
Von Uwe Kleine-König am Mo, 28. September 2009 um 10:15 #
Hallo,
die Debian-Patche haben wir hauptsächlich deshalb raus gelassen um möglichst gute Bug-Reports upstream geben zu können. Die sind nämlich (verständlicherweise) recht unmotiviert modifizierte Kernel zu debuggen. Der Langzeit-Plan ist, auch eine RT-Variante nach Debian zu bringen.
Von kartoffel200 am Mo, 28. September 2009 um 09:41 #
Jo naja wenn du ewig Radeontreiber Updatest wie willst du sicherstellen das alles noch geht bei sooo vielen Aplikationen die davon betroffen sein können. Nutz doch was aktuelles und ärger dich über die instabilität
Und die ist nicht so schlecht wie du es darstellst. Es gibt schon einen Grund warum man es bei Debian so macht und nicht wie die meisten anderen. Das ist ja nicht gerade so, das die sich und den meisten anderen das Leben schwer machen wollen. Wenn irgendwas mit dem Installer jetzt noch nicht möglich ist, wird es bei bedarf ( und auch so ) nachgereicht und bei Squeeze eingebracht.
> Weiter liefert debian einen kastrierten radeon treiber ohne xv/3d beschleunigung. Das ist falsch.
> Die netinst mit wlan zu installieren geht bei vielen wlan treibern mit externer firmware nicht. Der Installer kann die Firmware nachladen, siehe: http://www.debian.org/releases/stable/i386/ch06s04.html.de
>> Weiter liefert debian einen kastrierten radeon treiber ohne xv/3d >> Beschleunigung > Das ist falsch.
Nein, ist es nicht. Schau doch einfach mal nach, was der Inhalt von firmware-linux unter squeeze sein wird!
Beüglich nachladen der Firmware im installer: von hinten durch die brust in die nase:-). kann auch gleich lfs oder gentoo nehmen. Es geht mir eher um die Auswirkung. Debian ist einer der besten Distributionen bite erstaunlich guter stabilität. (nein ich möchte nicht zu ubuntu wechseln). Die künstlichen Stolpersteine regen mich einfach auf. Klar kann ich die Firmware nachinstallieren (wenn ich das weis, das der radeon eine benötigt). Es hat mich einige zeit gekostet um den tollen debianweg zu verstehen. Das muß einfach nicht sein. Ohne firmware kein radeon mit beschleunigung. Dann kann ich auch gleich nvidia nehmen, wenn ich schon non-free anschalten muß um meine graka nutzen zu können. Auf debiansystemen ist dadurch der Vorteil des neuen radeon treibers dahin. Diese form von extrementscheidungen find ich einfach nur übertrieben und völlig daneben. Dies fördert in keinsterweise die Freiheit sondern nur frust. Debian wird nur anhänger an die anderen Distributionen abgeben nicht mehr.
"Ohne firmware kein radeon mit beschleunigung. Dann kann ich auch gleich nvidia nehmen, wenn ich schon non-free anschalten muß um meine graka nutzen zu können."
Was ATI/AMD wohl denken, wenn sie sehen, dass sie von einem einflußreichen Teil der Linux-Community trotz ihrer Bereitschaft, die Programmierung freier 2D- und 3D-ATI-Grafikkartentreiber unter Linux zu unterstützen, letztendlich mit NVidia, die im Gegensatz zu AMD/ATI keinerlei für die Programmierung freier Treiber notwendigen Hardwarespezifikationen (die Kenntnis der unfreien Firmware ist dazu nicht notwendig) zugänglich machen und lieber die nv- und nvidia-Treiber selbst maintainen, auf eine Stufe gestellt werden?
Die Gretchenfrage lautet doch: Ob ich nun die unfreie Firmware im Kernel benutze oder aber die unfreie Firmware von einem ROM-Chip geladen wird, wo ist da im Endergebnis der Unterschied? Na? Es gibt keinen. AMD/ATI sieht das ganz genauso, wie man an den folgenden Ausführungen eines AMD/ATI-Entwicklers ablesen kann:
"(...) I can't believe that the definition was written to deliberately penalize hardware vendors who load microcode in the driver rather than autoloading it from ROM or permanently storing the microcode on-chip, but that is what is happening right now. (...) Honestly I don't see why a microcode image loaded at power-up is any less free than the same microcode stored permanently in the chip. Neither one can be read or understood, neither one allows learning or changing or redistributing the changes, yet apparently one is Good and one is Evil. I can't believe that was Mr. Stallman's intention."
Und jetzt der Hammer: 3D funktioniert mit älteren Radeonkarten auch ohne die unfreie Firmware bis hoch zu den 5xx-Chips. Hierzu führt der Entwickler aus:
"AFAIK most of the older Radeon GPUs can use the 3D engine *without* the command processor, albeit more slowly, since there is a comman FIFO which can accept command packets without requiring that the microcode images be loaded."
Bislang hat diese Tatsache in Linux-Entwicklerkreisen aber niemanden interessiert:
"I have mentioned this to a couple of developers but so far there hasn't been much interest. Only the 6xx-and-up parts absolutely require the command processor microcde for 3D."
Interessant ist auch der Hinweis des Entwicklers, warum die Firmware nicht freigegeben werden kann:
"We are not documenting the internal functioning of the hardware, and the microcode images are part of that internal hardware function."
Kein GPU-Hersteller macht das.
Ein bisschen 2D ohne 3D wie bei NVidias nv, ist das wirklich das, was wir auch für die Linux-ATI-Treiber wollen? Nein danke.
Gnewsense und Debian sind IMHO in punkto unfreier Kernel-Firmware völlig auf dem Holzweg. Wenn man dieses Verbot unfreier Firmware in Software ("microcode") und in Hardware (ROM-Chips) konsequent umsetzen und beachten würde, dann müssten aber die Rechner, auf denen Debian oder Gnewsense laufen soll, erst noch gebaut werden. Ohne jegliche unfreie Firmware geht gar nichts, freie Hardware gibt es nun einmal so gut wie überhaupt nicht. Wenn ein freies Linux jetzt nur noch auf völlig freier Hardware laufen dürfte, dann wäre GNU/Linux am Ende seines Weges angelangt. Linux-Entwickler mögen ein freies Betriebssystem programmiert haben, die Hardware der jeweiligen Hersteller gehört ihnen aber nicht. Auch nicht die Firmware, egal, wo sie sich befindet.
Was ist eigentlich z.B. mit der unfreien Festplatten-Firmware? Hören die Protagonisten dieser "entfernt die unfreie Firmware aus dem Kernel"-Idee jetzt auf, ihre Festplatten zu verwenden? Es ist doch bestimmt ganz einfach, einfach nach non-free verschieben.
Von irgendwer am Di, 29. September 2009 um 09:17 #
Zwischen "die Hardware bringt ihre Firmware mit" und "der Softwaretreiber muss diese mitbringen" ist ja wohl ein gehöriger Unterschied. In ersterem Fall muss sich der Softwaretreiberentwickler nicht um die Lizenz der Firmware kümmern. Im letzteren Fall eben sehr wohl. Er muss das Recht haben, diesen Teil (ja meist hochgeheime Software) frei verteilen zu dürfen.
Und wie gefährlich möglicherweise illegales Kopieren von Software ist, wird uns doch von der Industrie derzeit überall gezeigt. Das kann schonmal etliche Tausend Dollars kosten.
Sicher, Firma-X sagt jetzt offen zu, dass man die Firmware mit verteilen darf. Generell ist das aber nicht so einfach. Ich schätze bei Debian hat schlicht keiner Lust darauf, dass man irgendwann Ärger bekommt, da man halt irgend eine Firmware "illegal kopiert" hat, weil irgend eine kleine Schmuddelfirma dann doch lieber noch ein paar Dollars abschöpfen lässt als dass ihre Hardware unter dem unbekannten Nischensystem Linux eben auch noch läuft.
Die unfreie Firmware ist nicht illegal in den Kernel gelangt.
Zudem ist diese Argumentation im konkreten Fall nicht wirklich stichhaltig, da Debian (wie Gnewsense) die Firmware nicht aus Angst vor juristischer Verfolgung wegen irgendwelcher hypothetischer Rechtverletzungen entfernt, sondern schlichtweg aus dem Grunde, dass die Firmware im Kernel unfrei ist.
Irgendein Unterschied zwischen unfreier ROM-Chip-Firmware und unfreier Microcode-Firmware im Kernel im Hinblick auf deren Nutzung zur Laufzeit besteht jedoch nicht. In beiden Fällen wird unfreie Firmware in gleicher Weise verwendet. Konsequent wäre daher nur die Nichtbenutzung jeglicher unfreier Firmware, unabhängig davon, ob sie nun als Kernel-Microcode oder aber "in Hardware eingegossen" angeboten wird. Auch die Hardware-ROM-Chips lassen sich ja entfernen, ein bisschen Handarbeit und Dein persönliches Linux ist wieder ein Stückchen freier.
Von Kevin Krammer am Mi, 30. September 2009 um 00:47 #
Irgendein Unterschied zwischen unfreier ROM-Chip-Firmware und unfreier Microcode-Firmware im Kernel im Hinblick auf deren Nutzung zur Laufzeit besteht jedoch nicht. In beiden Fällen wird unfreie Firmware in gleicher Weise verwendet.
Das ist der Punkt! Wenn du die unfreie Firmware auf irgendeine Weise zur Verfügung stellst, ist das kein Unterschied. Ob du sie im ROM der Hardware hast, oder aus einer anderen Quelle hast ist irrelevant. Für Debian ist lediglich wichtig, dass die von ihnen verteilte Software ihren Richtlinien genügt.
Orthogonale Konzepte die bei oberflächlicher Betrachtung gerne durcheinander gebracht werden.
So, ich habe Dir das einmal am Beispiel des e100-Netzwerkchips herausgesucht: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494308
Robert Millan schreibt hierzu glasklar: "Since the licensing terms allow redistribution, shipping them is not illegal but is a DFSG violation."
Es geht also in diesem Fall tatsächlich um "Freiheit", die Verteilung der unfreien e100-Firmware wäre legal.
Die jeweilige Firmware kommt meist mit einer eindeutigen Lizenz. Hier sind einige dieser Lizenzen mit aufgeführt: http://wiki.debian.org/KernelFirmwareLicensing
Wie Du siehst, gibt es auch einige zweifelhafte Fälle. Diese werden aber auch nicht in non-free landen, die betreffende Firmware fliegt dann komplett aus Debian heraus, was IMHO richtig ist.
Die eindeutigen Fälle (unfrei, aber laut Lizenz legal verteilbar) landen dann in non-free.
Von Kevin Krammer am Di, 29. September 2009 um 09:26 #
Ob ich nun die unfreie Firmware im Kernel benutze oder aber die unfreie Firmware von einem ROM-Chip geladen wird, wo ist da im Endergebnis der Unterschied?
Der Unterschied ist nicht in der Benutzung, sondern in der Art der Verteilung (Vertriebskanal).
Im Debian Modul "Main" ist nun mal nur Software, die den entsprechenden Richtlinien entspricht. Unfreie Firmware könnte man also maximal in "non-free" unterbringen, vorrausgesetzt der Hersteller der Firmware erlaubt eine solche Redistributions.
Wenn die Firmware als Teil der Hardware verbreitet wird, dann ist das ein weiterer Vertriebskanal, der natürlich nicht an Richtlinien andere Vertriebskanäle gebunden ist.
Im Falle des AMD/ATI Bespiels geht es also nicht darum welche Lizenz die Software hat, die der Radeon Chip ausführt, sondern ob die Lizenz den Richtlinien des Vertriebskanals genügt, über den sie verbreitet werden soll.
Diese "Ansicht" finde ich aber recht heikel. Würden sich z.B. die r128-, radeon-, mga- und e100-Firmware auf einem ROM-Chip befinden, dann wäre ja auch für Debian (und Gnewsense) alles in Ordnung. Und das, obwohl die Firmware ja zur Laufzeit genauso vom ROM-Chip geladen wird wie vom Kernel-Firmware-Microcode. Einen Unterschied im Endergebnis gibt es hier jedenfalls nicht. Wie sollte nun ein Hersteller im Sinne dieser "Ansicht" reagieren? Etwa mit dem zukünftigen Nichtanbieten solcher Firmware unter Linux? Das wäre neben dem einfachen Belassen wohl die einzig gangbare Möglichkeit. Würde man es sich mit der FSF nicht verscherzen wollen, so müßte jeder Hardwarehersteller seine unfreie Linux-Kernel-Firmware freiwillig entfernen. Vielleicht sollte man z.B. über Emails genau daraufhin einwirken. Dann bräuchten auch Debian und Gnewsense nichts mehr zu entfernen, was Einiges an unnötiger Arbeit ersparen würde.
Von Kevin Krammer am Mi, 30. September 2009 um 00:36 #
Das hat nicht mit der FSF oder GPL zu tun.
Es geht nicht um den Einsatz der Firmware, sondern um den Kanal der Verbreitung. Wenn sie als Teil der Hardware verbreitet wird, wird sich nicht als Teil von Debian verbreitete, also ist das Debian "egal". Wenn die Firmware als Teil einen "non-free" Pakets kommt, ist das auch OK (daher auch non-free). Nur als Teil von "main" nicht, weil das nur freie Software enthält.
Es geht nicht darum, wann etwas geladen wird, sondern woher dieses etwas kommt. Wenn ein Benutzer die proprietäre Firmware laden will, kann er/sie das tun.
Ich kann Deine Argumentation zwar nachvollziehen, aber ich verstehe nicht, warum Debian dann - wenn Deine Argumentation zutrifft - überhaupt noch non-free-Repos anbietet. Schließlich wird die unfreie Software dort letztlich auch vom Debian-Projekt vertrieben und nicht von einem unbekannten Dritten. Nur zu sagen, non-free ist ja nicht auf unseren Installations-CDs und deshalb haben wir mit dessen Vertrieb nichts zu tun, ist kein stichhaltiges Argument.
Das nachladen setzt aber vorraus das es irgendwo local vorhanden ist. Stell dir ma vor, jemand hat ein notebook, hat den zugang nur über wlan und keine gespeicherte firmware parat und benutzt eine NetInst. Da möchte ich ma sehen was da nachgeladen werden soll .
Genau. Du hattest die Freiheit dir einen kartenleser oder externes diskettenlaufwerk zu holen. Kein Mehrwert für die Benutzer aber die Freiheit wurde gewart.
Komm schon, das ist doch humbuck ... wenn du nur das notebook hast und die cd. Man muss doch in der lage sein wenigstens ein minimales system installieren zu können. Aber man kann sich lange darüber streiten, es ist die entscheidung von Debian es so zu fahren. Ich nutze übrigens ebenfalls debian , nutze aber bei der installation die DVD da kann ich wenigestens das system aufsetzen ohne auf internet zugriff nehmen zu müssen.
Von Flying Circus am Mo, 28. September 2009 um 12:54 #
Man muss doch in der lage sein wenigstens ein minimales system installieren zu können.
Wieso, genau das geht mit einer Netinstall-CD. Nur nachladen kannst Du natürlich nüscht, wenn der WLAN-Chip nicht direkt unterstützt wird.
Finde ich allerdings persönlich nicht sonderlich problematisch, ich war noch nicht in der Verlegenheit, abseits von verfügbaren Ethernet-Anschlüssen neu installieren zu müssen.
Auf offiziellen Debian-CDs und -DVDs wird keine Software aus non-free enthalten sein, nur main und contrib. Du brauchst also noch ein Linux, dass Dir mittels e100 den Zugriff aufs Internet ermöglicht, um die unfreie Kernel-Firmware aus non-free herunterzuladen. Das ist doppelt gemoppelt. Da nimmt man lieber gleich die Linux-Distro m i t der e100-Firmware auf ihren Installations-CDs bzw. -DVDs und spart sich Debian. In diesem Zusammenhang sollte man auch nicht vergessen, dass e100 als Netzwerkchip auf vielen Intel-Mainboards verbaut ist. Einen funktionierenden Netzwerkchip aus politisch-religiösen Gründen durch eine weitere Netzwerkkarte ersetzen zu wollen, macht schlicht keinen Sinn.
Von Flying Circus am Di, 29. September 2009 um 10:18 #
Auf offiziellen Debian-CDs und -DVDs wird keine Software aus non-free enthalten sein, nur main und contrib.
Keine Ahnung - ich nehme immer nur Netinstall oder die Mini-Images.
Du brauchst also noch ein Linux, dass Dir mittels e100 den Zugriff aufs Internet ermöglicht, um die unfreie Kernel-Firmware aus non-free herunterzuladen.
Wenn, wie ich oben ja schrieb, man nur WLAN zur Verfügung hat (iirc ging es zumindest dem Ausgangsposter ja um WLAN). Bei der Installation. Nun haben die gängigen WLAN-Router aber Ethernet und eine Installation führe zumindest ich idR nicht irgendwo am Strand durch. YMMV.
Das ist doppelt gemoppelt. Da nimmt man lieber gleich die Linux-Distro m i t der e100-Firmware auf ihren Installations-CDs bzw. -DVDs und spart sich Debian.
Oder man packt sich die Firmware auf $Speichermedium.
Einen funktionierenden Netzwerkchip aus politisch-religiösen Gründen durch eine weitere Netzwerkkarte ersetzen zu wollen, macht schlicht keinen Sinn.
Sinn machen gibt es im Deutschen nicht Für die Ideologie habe ich sogar Verständnis. Aber ich achte auch bei meiner Hardware sehr darauf, ob sie out-of-the-box unterstützt wird. Wenn die Netzwerkkarte (Ethernet) nicht unterstützt wird, hat man in der Tat ein ernsteres Problem. Ließe sich mit ner LiveCD, die mit der Karte umgehen kann, einem Speichermedium (zum Speichern der Firmware) und ca. 3 Minuten Zeit auch umgehen. Ob man das dann tun will, bleibt jedem selbst überlassen. Ich mag Debian. Ich nutze es gerne. Wer es nicht nutzen will, hat die breite Auswahl.
Aber sicher. Dieser angebliche Anglizismus wird mittlerweile so häufig benutzt, dass er sich sicher bald im Duden wiederfinden wird.
Vergleiche Sinn einfach mit dem Inhalt eines dreidimensionalen, fluktuierenden, fiktiven Gebildes, das sich stetig in seinen Ausmaßen verändert. Dadurch ändert sich auch der Sinn an sich, er kann erschaffen, "gemacht", verändert und letztlich auch vernichtet werden. Jedenfalls ist es möglich, etwas Sinnvolles zu kreieren und in diesem Fall etwas Sinnvolles zu "machen". Sinn kann man also verändern, durch eigene Handlungen.
Das Nachbeten vorgefasster und nicht allzu tief reflektierter Lehr-/Leer-Meinungen ist im Sinne der Aufklärung völlig abzulehnen.
Zu Debian: Ehrlicherweise muß ich sagen, dass ich in punkto Firmware doppelt betroffen bin: Mein Intel 845BG-Mainboard enthält einen nicht austauschbaren e100-Netzwerkchip und eine ATI Radeon 7500, die aber ausgetauscht werden kann. Als ich das Mainboard 2003 gekauft habe, war nirgendwo irgendetwas davon zu lesen, dass die e100-Firmware unfrei sei. Damals hat das anscheinend niemanden im Linuxlager gestört. Alternativ kann man ja auch die neuen Debian-Kernel wieder "zurückpatchen" und zum Download anbieten.
Ich hätte auch das Problem mit e100 und neueren Debian-Kerneln, wenn ich denn diese neuen Debian-Softwarezusammenstellungen (ab Squeeze) benutzen würde. Es ist tatsächlich unlogisch, die unfreie Firmware im Kernel zu verteufeln, aber weiterhin die unfreie Firmware in ROM-Chips weiter zu benutzen, nur weil sie in Hardware "eingegossen" ist. Es gibt hierbei im Endergebnis im Hinblick auf die Nutzung unfreier Firmware keinerlei Unterschied. Debian handelt demzufolge hier irrational. Ich könnte diese Vorgehensweise nur dann als logisch ansehen, wenn sie gar keine unfreie Firmware mehr benutzen würden, als weder die unfreie Firmware im Kernel noch die unfreie Firmware in ROM-Chips auf der jeweiligen Hardware. Das Gleiche gilt zudem genauso für die meisten BIOS-Chips. Auch ältere e100-Chips laufen mit neueren Kerneln nicht mehr, da der ältere, aber freie eepro-Treiber mittlerweile von kernel.org entfernt wurde.
Von DriverDevel am Mo, 28. September 2009 um 18:35 #
Auch ältere e100-Chips laufen mit neueren Kerneln nicht mehr, da der ältere, aber freie eepro-Treiber mittlerweile von kernel.org entfernt wurde.
Ähm, welche denn? Das sollte seit meinem Patch (non-MII) ein Stück besser sein (allerdings gibt es ein Non-Support-Window bei IIRC 2.6.28-2.6.29, erst 2.6.30 hatte den Patch dann drin, DA DIE LEUTE FAST EIN JAHR GEPENNT HABEN), aber ich hab auch schon Unkenrufe vernommen, dass es noch ganz andere Hardware gibt, die von e100 gar nicht unterstützt wird...
Das bestärkt mich in meiner Meinung, dass die Entfernung von eepro100 wohl eine Katastrophe war... (scheint doch einige Leute zu betreffen - hohe Dunkelziffer -, wenn man hin und wieder aktiv mitbekommt, dass es Probleme gab) Es gibt aber auch im SCSI-Controller-Bereich ähnliche Migrations-Katastrophen.
Von den e100-Chips sind nicht alle betroffen. Laut Sidux z.B. sind es folgende: 82559 D101M/ D101M, 82551-F, 82551-10. E100-Chips wie z.B. der recht haeufige Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller funktionieren ohne die e100-Firmware. Ich bin gerade damit - ohne e100-Firmware - im Internet.
Von zettberlin am Mo, 28. September 2009 um 17:10 #
... bietet schon seit Jahren RT-Kernel für Debian. Vielleicht habe ich einen Hinweis auf den Beitrag der Linux-Audio community auf die Schnelle nicht gefunden aber ich finde es schon seltsam, dass weder in der Meldung noch im RTWiki etwas dazu zu finden ist. Die immer gern belächelten Linux-Audio-Leute trommeln seit 10 Jahren für ein RT-fähiges Linux für alle und haben damit einiges erreicht.
Dass es jetzt im RTWiki so aussieht, als ginge es nur um Industrie-Maschinen wird wieder einmal das ganze Thema in eine Nische schieben. RT-Fähigkeit sollte für Linux so selbstverständlich sein, wie für MacOSX. Die richtige Hardware/Treiber vorausgesetzt, arbeitet man auch unter MSWindows schon lange mit Latenzen um die 10 Millisekunden.
Unter Linux geht in der Tat mehr als unter MacOSX oder Win - auch mit einfacher Hardware. Mit Einsteiger-Profigerät kann man auch mit weniger als 3 ms stabil arbeiten. Alles mit bekannten Lösungen, die bis jetzt allerdings von gängigen Distributoren bestenfalls mit mildem Interesse gewürdigt und nur bei wenigen in offiziellen Repos geduldet werden.
Von zettberlin am Di, 29. September 2009 um 00:27 #
>M-Audio Delta 1010LT :-)
Zusammen mit einem RT-Kern pustet das Ding einiges weg. Ich kann auf einem Rechner mit 1-Kernigem AMD-Prozessor, 2 GB RAM und einer vergleichbaren MAudio 1024 Ardour-Projekte mit mehr als 50 Spuren, 96KHz Samplerate und dutzenden LADSPA/LV2-Plugins problemlos mit 10 ms Latenz betreiben...
Von zettberlin am Di, 29. September 2009 um 01:50 #
> mit Industriemaschinen der Tausendfache Umsatz
Das ist sicher korrekt. Aber es kommen auch auf jedes Desktop-Linux na? 80, 100, 200? Server mit Linux, trotzdem sagt keiner, KDE oder GNOME wären für Linux nicht wichtig, weil Apache viel wichtiger ist.
Außerdem: Fakt ist, dass die Audio-Entwickler maßgeblichen Anteil an der Existenz von RT-Kerneln für Linux haben. Ohne die Unterstützung durch Paul Davis und andere Audioentwickler wäre Ingo Molnars Arbeit bestenfalls 5 Jahre später von den Hauptentwicklern von Linux als brauchbar und wichtig akzeptiert worden.
Die Fähigkeit, produktive Audiosoftware zu betreiben, ist für MacOSX eine Selbstverständlichkeit und auch unter Windows relativ leicht erreichbar. Solange Linux da nicht nachzieht, ist es kein vollwertiges, universelles Betriebssystem für alle Anwender.
Von Feuerfrei am Mi, 30. September 2009 um 22:23 #
Und wo siehst du die Probleme? Sicher nicht jede Distri bietet derzeit einen RT-Kernel, aber doch die weit verbreiteten. Dass ein Kernelpaket alle Anforderungen abdeckt, wird es bis auf weiteres nicht geben. Dafür sind die Anforderungen zwischen Servern, Desktops, Embedded und Audioworkstations zu verschieden. Ein 08/15 Fileserver kann sich z.B. gar nichts von der besseren Latenz kaufen, sondern produziert einfach nur mehr Wärme bzw. sorgt für eine höhere Stromrechnung. Deine Kritik geht also eher an die Distris, die keine RT-Kernel anbieten. Für den Anwender macht es einen Unterschied, er bekommt ohnehin höchst selten einen vanilla Kernel vorgesetzt.
>Die immer gern belächelten Linux-Audio-Leute trommeln seit 10 Jahren für ein RT-fähiges Linux für alle und haben damit einiges erreicht.
Warscheinlich wäre es sinnvoller diverse Atari Clone Projekte zu unterstützen? So richtiges Realtime, ich meine damit "wirklich richtiges", wird es untwer Linux wohl nie geben können!
Welche Vor- und Nachteile hat das Aktivieren von RT_PREEMPT denn überhaupt zur Folge?
Die Nutzung des Rechners als digitaler Mehrspurrekorder ohne wahrnehmbare (unter ~10ms?) Verzögerung zwischen abgespielten und dazu aufgenommenen Spuren wird möglich, siehe den vorherigen Diskussionszweig.
Für mich, dem einmal einfache Vierspurrekorder mit Audiokassetten ein zu teurer Traum waren, ist schon ein wie Programm audacity ein Hammer. Ohne RT-Kernel werden aber Verzögerungen zwischen alten und dazu neu aufgenommenen Spuren hörbar.
Von zettberlin am Mo, 28. September 2009 um 20:29 #
> Welche Vor- und Nachteile hat das Aktivieren von RT_PREEMPT
Pro: stream-orientierte Prozesse wie Musiksoftware und überhaupt alles, was in Echtzeit rendert, kann mit garantierten Verzögerungszeiten rechnen. Damit kann man einen kleinen Buffer für den output verwenden und ein kontinuierlicher Stream (Soundsynthese/Wiedergabe, Messwerte etc) läuft ohne Unterbrechung. Die Anwendung kann beispielsweise mit weniger als 10 Millisekunden Verzögerung ansprechen, wenn man eine Taste drückt, ohne die Gefahr, dass der Buffer leer/überläuft (xrun), weil ein anderer Prozess sich dazwischen schiebt. Das Ganze geht *ohne* Root-Privilegien via PAM(solange, bis die Hardware tatsächlich die Last nicht mehr bringen kann). Bei Musiksoftware erwartet jeder Anwender heutzutage genau dieses Verhalten. Mit einem Normalkernel kommt man bestenfalls auf 100 Millisekunden und selbst das ist nicht sicher.
Contra: RT-Kernel holen eben alles raus, was drin ist. Damit kann man das System leichter mit einem Normalnutzerprozess erwürgen und RT-Kernel haben eine Tendenz mehr Strom zu verbrauchen. Canonical hat die einfache PREEMPT-VOLUNTARY aus Dapper entfernt, weil einige berichtet hatten, dass ihr Akku mit dem damals neuen Kernel schneller leer ist. Allgemein ist Linux mit RT ein etwas bissigeres Biest als ohne. Für Webserver ist ein RT-Kernel zumindest auf dem heutigen Stand keine sehr gute Idee...
Von irgendwer am Di, 29. September 2009 um 09:43 #
Lassen sich die RT_PREEMT-Patche per Option an- und ausschalten? Ich meine, gibt es bei einem RT_PREEMT-gepatchten Kernel die Möglichkeit, diese Patche durch Kernel-Configure-Optionen abzuschalten und so quasi einen Vanilla Kernel zu generieren?
Dann spräche doch nichts dagegen, die Patche in den kernel.org-Kernel einfließen zu lassen und einfach alle RT_PREEMT-Otionen per Default zu deaktivieren.
Oder werden Dinge gepatcht, die nicht per Option veränderbar sind?
Von irgendwer am Di, 29. September 2009 um 09:46 #
Wieso ich auf diese Frage komme: für eines meiner nicht-PC-Systeme sind die bestfunktionierendsten Kernelquellen u.a. auch mit RT gepatcht. Ich brauche diese allerdings nicht bzw. sie sind sogar kontraproduktiv, weshalb ich die Optionen möglichst so setze, dass RT nicht zum Einsatz kommt.
Von zettberlin am Di, 29. September 2009 um 12:22 #
>Lassen sich die RT_PREEMT-Patche per Option an- und ausschalten?
Das schon...
> ...und so quasi einen Vanilla Kernel zu generieren?
Das eigentlich nicht - die RT-Patches ändern sehr viel im Kernel. Man kann zwar RT_PREEMPT abschalten und dann sollte sich so ein Kernel auch genauso wie ein Vanilla verhalten aber anders ist anders.
Machen könnte man das trotzdem - die Vanilla-Maintainer müssten bloß... ein paar 1000 RT-Code in Vanilla einpflegen };-)
Von zettberlin am Di, 29. September 2009 um 13:53 #
> Ganz so schlimm ist es nicht.
Stimmt, die Mainline-Entwickler haben schon einige Techniken aus dem RT-Zweig in Vanilla eingebaut. Man kann zum Beispiel einen Vanilla mit PREEMPT-VOLUNTARY übersetzen, dann bekommt man auch schon Alltagstaugliche Leistung für Jack und Co.
Von freiheitsliebender am Mo, 28. September 2009 um 23:13 #
Heißt das jetzt, dass man unter Debian keinen fglrx mehr installieren kann, weil die Symbole in kernel/rcupreempt.c mit EXPORT_SYMBOL_GPL exportiert werden statt mit EXPORT_SYMBOL? Sidux leistet da ja schon großartiges auf der Linux DRM Front.
Ich bin eigentlich ein überzeugter debian Benutzer (gewesen). Die letzte Zeit jedoch ärgern mich grundlegende entscheidungen des Projektes.
Die restriktive (für mich nicht nachvollziehbare) Politik wg den binären firmwares geht mir ziemlich auf den Wecker. Die netinst mit wlan zu installieren geht bei vielen wlan treibern mit externer firmware nicht.
Weiter liefert debian einen kastrierten radeon treiber ohne xv/3d beschleunigung. Das ist für mich nicht nachvollziehbar, da sie mit so einer übertriebenen Vorgehensweise die Freiheit eher einschränken als fördern.
Netzwerkkarten mit eingebauten rom, wo die firmware auch nicht frei ist wäre für debiananwender die beste wahl.
Wenn so gängige hardware wie e100 und radeon künstlich eingeschränkt werden, habe ich dafür echt kein verständnis.
Im Artikel steht, dass die offiziellen debianpatches nicht enthalten sind in dem Echtzeitkernel. Das ist für den Debiananwender vielleicht ein segen. Dadurch entfällt das nachträgliche Einbinden von non-free und die Installation von firmware-linux.
Oder forke Debian und kleb die ganzen non-free Sachen rein.
Aber akzeptiere das die Leute von Debian sich so entschieden haben, und so auch auf einen massiven Miststand aufmerksam machen!
Das Problem ist nämlich nicht das Debian sich so entschieden hat, sondern die Anderen die CS-Zeugs zu ihrer Hardware vertreiben, statt mal ein paar ordenliche Datenblätter zu liefern.
Und das mit den Debian-patches gibt mir etwas zu denken, normalerweise wird die Version des Kernels festgehalten und Bug/Sicherheitslücken rausgepatcht. Ich hoffe diese Patches sind damit nicht gemeint.
Gruß Micha
Wie immer bei solchen Dingen ist die Extreme hier mein Problem.
Was hab ich von einer vorzeige freiheitsdistribution wenn die hw unterstützung bescheiden ist?
Es kam ja bei der installation noch nicht mal ein hinweis, das ein zusätzliches paket erforderlich ist um 3d/xv ... für den radeon treiber aktivieren zu können.
Mit Debian kenne ich das System am Ende besser, als eine andere Distribution.
Im Zweifelsfall kann ich besser reagieren.
Du hast aber recht, dass man für die Einrichtung ein bisschen zu viel Zeit braucht, aber es sollte alles vorhanden sein.
Mir liegt Debian einfach am Herzen, trotz seinen Stolpersteinen.
Das geht mit Slackware noch ein Stückchen besser.
Und vor allen Dingen ist Slackwares Software- und Treiberzusammenstellung frei von jedem ideologischen Ballast, da meist genau das angeboten wird, was man direkt beim jeweiligen Projekt als Source herunterladen kann.
die Debian-Patche haben wir hauptsächlich deshalb raus gelassen um möglichst gute Bug-Reports upstream geben zu können. Die sind nämlich (verständlicherweise) recht unmotiviert modifizierte Kernel zu debuggen.
Der Langzeit-Plan ist, auch eine RT-Variante nach Debian zu bringen.
Grüßle
Uwe
Dankeschön, das klingt nach einem tollen Plan.
und eine paketquelle zu aktivieren ist jetzt find ich auch nicht so das problem. könntest ja auf eine ubuntu lts umsteigen
Das ist falsch.
> Die netinst mit wlan zu installieren geht bei vielen wlan treibern mit externer firmware nicht.
Der Installer kann die Firmware nachladen, siehe:
http://www.debian.org/releases/stable/i386/ch06s04.html.de
>> Beschleunigung
> Das ist falsch.
Nein, ist es nicht.
Schau doch einfach mal nach, was der Inhalt von firmware-linux unter squeeze sein wird!
Beüglich nachladen der Firmware im installer: von hinten durch die brust in die nase:-).
kann auch gleich lfs oder gentoo nehmen.
Es geht mir eher um die Auswirkung. Debian ist einer der besten Distributionen bite erstaunlich guter stabilität. (nein ich möchte nicht zu ubuntu wechseln). Die künstlichen Stolpersteine regen mich einfach auf. Klar kann ich die Firmware nachinstallieren (wenn ich das weis, das der radeon eine benötigt). Es hat mich einige zeit gekostet um den tollen debianweg zu verstehen. Das muß einfach nicht sein. Ohne firmware kein radeon mit beschleunigung. Dann kann ich auch gleich nvidia nehmen, wenn ich schon non-free anschalten muß um meine graka nutzen zu können.
Auf debiansystemen ist dadurch der Vorteil des neuen radeon treibers dahin.
Diese form von extrementscheidungen find ich einfach nur übertrieben und völlig daneben. Dies fördert in keinsterweise die Freiheit sondern nur frust. Debian wird nur anhänger an die anderen Distributionen abgeben nicht mehr.
Was ATI/AMD wohl denken, wenn sie sehen, dass sie von einem einflußreichen Teil der Linux-Community trotz ihrer Bereitschaft, die Programmierung freier 2D- und 3D-ATI-Grafikkartentreiber unter Linux zu unterstützen, letztendlich mit NVidia, die im Gegensatz zu AMD/ATI keinerlei für die Programmierung freier Treiber notwendigen Hardwarespezifikationen (die Kenntnis der unfreien Firmware ist dazu nicht notwendig) zugänglich machen und lieber die nv- und nvidia-Treiber selbst maintainen, auf eine Stufe gestellt werden?
Die Gretchenfrage lautet doch:
Ob ich nun die unfreie Firmware im Kernel benutze oder aber die unfreie Firmware von einem ROM-Chip geladen wird, wo ist da im Endergebnis der Unterschied?
Na?
Es gibt keinen.
AMD/ATI sieht das ganz genauso, wie man an den folgenden Ausführungen eines AMD/ATI-Entwicklers ablesen kann:
http://phoronix.com/forums/showthread.php?t=6585&page=63#628
"(...) I can't believe that the definition was written to deliberately penalize hardware vendors who load microcode in the driver rather than autoloading it from ROM or permanently storing the microcode on-chip, but that is what is happening right now.
(...)
Honestly I don't see why a microcode image loaded at power-up is any less free than the same microcode stored permanently in the chip. Neither one can be read or understood, neither one allows learning or changing or redistributing the changes, yet apparently one is Good and one is Evil. I can't believe that was Mr. Stallman's intention."
Und jetzt der Hammer:
3D funktioniert mit älteren Radeonkarten auch ohne die unfreie Firmware bis hoch zu den 5xx-Chips.
Hierzu führt der Entwickler aus:
"AFAIK most of the older Radeon GPUs can use the 3D engine *without* the command processor, albeit more slowly, since there is a comman FIFO which can accept command packets without requiring that the microcode images be loaded."
Bislang hat diese Tatsache in Linux-Entwicklerkreisen aber niemanden interessiert:
"I have mentioned this to a couple of developers but so far there hasn't been much interest. Only the 6xx-and-up parts absolutely require the command processor microcde for 3D."
Interessant ist auch der Hinweis des Entwicklers, warum die Firmware nicht freigegeben werden kann:
"We are not documenting the internal functioning of the hardware, and the microcode images are part of that internal hardware function."
Kein GPU-Hersteller macht das.
Ein bisschen 2D ohne 3D wie bei NVidias nv, ist das wirklich das, was wir auch für die Linux-ATI-Treiber wollen?
Nein danke.
Gnewsense und Debian sind IMHO in punkto unfreier Kernel-Firmware völlig auf dem Holzweg.
Wenn man dieses Verbot unfreier Firmware in Software ("microcode") und in Hardware (ROM-Chips) konsequent umsetzen und beachten würde, dann müssten aber die Rechner, auf denen Debian oder Gnewsense laufen soll, erst noch gebaut werden.
Ohne jegliche unfreie Firmware geht gar nichts, freie Hardware gibt es nun einmal so gut wie überhaupt nicht.
Wenn ein freies Linux jetzt nur noch auf völlig freier Hardware laufen dürfte, dann wäre GNU/Linux am Ende seines Weges angelangt.
Linux-Entwickler mögen ein freies Betriebssystem programmiert haben, die Hardware der jeweiligen Hersteller gehört ihnen aber nicht. Auch nicht die Firmware, egal, wo sie sich befindet.
Was ist eigentlich z.B. mit der unfreien Festplatten-Firmware?
Hören die Protagonisten dieser "entfernt die unfreie Firmware aus dem Kernel"-Idee jetzt auf, ihre Festplatten zu verwenden?
Es ist doch bestimmt ganz einfach, einfach nach non-free verschieben.
Und wie gefährlich möglicherweise illegales Kopieren von Software ist, wird uns doch von der Industrie derzeit überall gezeigt. Das kann schonmal etliche Tausend Dollars kosten.
Sicher, Firma-X sagt jetzt offen zu, dass man die Firmware mit verteilen darf. Generell ist das aber nicht so einfach. Ich schätze bei Debian hat schlicht keiner Lust darauf, dass man irgendwann Ärger bekommt, da man halt irgend eine Firmware "illegal kopiert" hat, weil irgend eine kleine Schmuddelfirma dann doch lieber noch ein paar Dollars abschöpfen lässt als dass ihre Hardware unter dem unbekannten Nischensystem Linux eben auch noch läuft.
Zudem ist diese Argumentation im konkreten Fall nicht wirklich stichhaltig, da Debian (wie Gnewsense) die Firmware nicht aus Angst vor juristischer Verfolgung wegen irgendwelcher hypothetischer Rechtverletzungen entfernt, sondern schlichtweg aus dem Grunde, dass die Firmware im Kernel unfrei ist.
Irgendein Unterschied zwischen unfreier ROM-Chip-Firmware und unfreier Microcode-Firmware im Kernel im Hinblick auf deren Nutzung zur Laufzeit besteht jedoch nicht. In beiden Fällen wird unfreie Firmware in gleicher Weise verwendet.
Konsequent wäre daher nur die Nichtbenutzung jeglicher unfreier Firmware, unabhängig davon, ob sie nun als Kernel-Microcode oder aber "in Hardware eingegossen" angeboten wird. Auch die Hardware-ROM-Chips lassen sich ja entfernen, ein bisschen Handarbeit und Dein persönliches Linux ist wieder ein Stückchen freier.
Das ist der Punkt!
Wenn du die unfreie Firmware auf irgendeine Weise zur Verfügung stellst, ist das kein Unterschied.
Ob du sie im ROM der Hardware hast, oder aus einer anderen Quelle hast ist irrelevant.
Für Debian ist lediglich wichtig, dass die von ihnen verteilte Software ihren Richtlinien genügt.
Orthogonale Konzepte die bei oberflächlicher Betrachtung gerne durcheinander gebracht werden.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494308
Robert Millan schreibt hierzu glasklar:
"Since the licensing terms allow redistribution, shipping them is not illegal
but is a DFSG violation."
Es geht also in diesem Fall tatsächlich um "Freiheit", die Verteilung der unfreien e100-Firmware wäre legal.
Die jeweilige Firmware kommt meist mit einer eindeutigen Lizenz.
Hier sind einige dieser Lizenzen mit aufgeführt:
http://wiki.debian.org/KernelFirmwareLicensing
Wie Du siehst, gibt es auch einige zweifelhafte Fälle. Diese werden aber auch nicht in non-free landen, die betreffende Firmware fliegt dann komplett aus Debian heraus, was IMHO richtig ist.
Die eindeutigen Fälle (unfrei, aber laut Lizenz legal verteilbar) landen dann in non-free.
Der Unterschied ist nicht in der Benutzung, sondern in der Art der Verteilung (Vertriebskanal).
Im Debian Modul "Main" ist nun mal nur Software, die den entsprechenden Richtlinien entspricht. Unfreie Firmware könnte man also maximal in "non-free" unterbringen, vorrausgesetzt der Hersteller der Firmware erlaubt eine solche Redistributions.
Wenn die Firmware als Teil der Hardware verbreitet wird, dann ist das ein weiterer Vertriebskanal, der natürlich nicht an Richtlinien andere Vertriebskanäle gebunden ist.
Im Falle des AMD/ATI Bespiels geht es also nicht darum welche Lizenz die Software hat, die der Radeon Chip ausführt, sondern ob die Lizenz den Richtlinien des Vertriebskanals genügt, über den sie verbreitet werden soll.
Würden sich z.B. die r128-, radeon-, mga- und e100-Firmware auf einem ROM-Chip befinden, dann wäre ja auch für Debian (und Gnewsense) alles in Ordnung.
Und das, obwohl die Firmware ja zur Laufzeit genauso vom ROM-Chip geladen wird wie vom Kernel-Firmware-Microcode.
Einen Unterschied im Endergebnis gibt es hier jedenfalls nicht.
Wie sollte nun ein Hersteller im Sinne dieser "Ansicht" reagieren?
Etwa mit dem zukünftigen Nichtanbieten solcher Firmware unter Linux?
Das wäre neben dem einfachen Belassen wohl die einzig gangbare Möglichkeit.
Würde man es sich mit der FSF nicht verscherzen wollen, so müßte jeder Hardwarehersteller seine unfreie Linux-Kernel-Firmware freiwillig entfernen.
Vielleicht sollte man z.B. über Emails genau daraufhin einwirken.
Dann bräuchten auch Debian und Gnewsense nichts mehr zu entfernen, was Einiges an unnötiger Arbeit ersparen würde.
Es geht nicht um den Einsatz der Firmware, sondern um den Kanal der Verbreitung.
Wenn sie als Teil der Hardware verbreitet wird, wird sich nicht als Teil von Debian verbreitete, also ist das Debian "egal".
Wenn die Firmware als Teil einen "non-free" Pakets kommt, ist das auch OK (daher auch non-free).
Nur als Teil von "main" nicht, weil das nur freie Software enthält.
Es geht nicht darum, wann etwas geladen wird, sondern woher dieses etwas kommt.
Wenn ein Benutzer die proprietäre Firmware laden will, kann er/sie das tun.
Schließlich wird die unfreie Software dort letztlich auch vom Debian-Projekt vertrieben und nicht von einem unbekannten Dritten.
Nur zu sagen, non-free ist ja nicht auf unseren Installations-CDs und deshalb haben wir mit dessen Vertrieb nichts zu tun, ist kein stichhaltiges Argument.
Kein Mehrwert für die Benutzer aber die Freiheit wurde gewart.
Aber man kann sich lange darüber streiten, es ist die entscheidung von Debian es so zu fahren. Ich nutze übrigens ebenfalls debian
Wieso, genau das geht mit einer Netinstall-CD. Nur nachladen kannst Du natürlich nüscht, wenn der WLAN-Chip nicht direkt unterstützt wird.
Finde ich allerdings persönlich nicht sonderlich problematisch, ich war noch nicht in der Verlegenheit, abseits von verfügbaren Ethernet-Anschlüssen neu installieren zu müssen.
Ansonsten gibts immer noch die DVDs.
Du brauchst also noch ein Linux, dass Dir mittels e100 den Zugriff aufs Internet ermöglicht, um die unfreie Kernel-Firmware aus non-free herunterzuladen.
Das ist doppelt gemoppelt.
Da nimmt man lieber gleich die Linux-Distro m i t der e100-Firmware auf ihren Installations-CDs bzw. -DVDs und spart sich Debian.
In diesem Zusammenhang sollte man auch nicht vergessen, dass e100 als Netzwerkchip auf vielen Intel-Mainboards verbaut ist. Einen funktionierenden Netzwerkchip aus politisch-religiösen Gründen durch eine weitere Netzwerkkarte ersetzen zu wollen, macht schlicht keinen Sinn.
Keine Ahnung - ich nehme immer nur Netinstall oder die Mini-Images.
Du brauchst also noch ein Linux, dass Dir mittels e100 den Zugriff aufs Internet ermöglicht, um die unfreie Kernel-Firmware aus non-free herunterzuladen.
Wenn, wie ich oben ja schrieb, man nur WLAN zur Verfügung hat (iirc ging es zumindest dem Ausgangsposter ja um WLAN). Bei der Installation. Nun haben die gängigen WLAN-Router aber Ethernet und eine Installation führe zumindest ich idR nicht irgendwo am Strand durch. YMMV.
Das ist doppelt gemoppelt.
Da nimmt man lieber gleich die Linux-Distro m i t der e100-Firmware auf ihren Installations-CDs bzw. -DVDs und spart sich Debian.
Oder man packt sich die Firmware auf $Speichermedium.
Einen funktionierenden Netzwerkchip aus politisch-religiösen Gründen durch eine weitere Netzwerkkarte ersetzen zu wollen, macht schlicht keinen Sinn.
Sinn machen gibt es im Deutschen nicht
Für die Ideologie habe ich sogar Verständnis. Aber ich achte auch bei meiner Hardware sehr darauf, ob sie out-of-the-box unterstützt wird.
Wenn die Netzwerkkarte (Ethernet) nicht unterstützt wird, hat man in der Tat ein ernsteres Problem. Ließe sich mit ner LiveCD, die mit der Karte umgehen kann, einem Speichermedium (zum Speichern der Firmware) und ca. 3 Minuten Zeit auch umgehen. Ob man das dann tun will, bleibt jedem selbst überlassen.
Ich mag Debian. Ich nutze es gerne. Wer es nicht nutzen will, hat die breite Auswahl.
Aber sicher.
Dieser angebliche Anglizismus wird mittlerweile so häufig benutzt, dass er sich sicher bald im Duden wiederfinden wird.
Vergleiche Sinn einfach mit dem Inhalt eines dreidimensionalen, fluktuierenden, fiktiven Gebildes, das sich stetig in seinen Ausmaßen verändert. Dadurch ändert sich auch der Sinn an sich, er kann erschaffen, "gemacht", verändert und letztlich auch vernichtet werden. Jedenfalls ist es möglich, etwas Sinnvolles zu kreieren und in diesem Fall etwas Sinnvolles zu "machen". Sinn kann man also verändern, durch eigene Handlungen.
Das Nachbeten vorgefasster und nicht allzu tief reflektierter Lehr-/Leer-Meinungen ist im Sinne der Aufklärung völlig abzulehnen.
Zu Debian:
Ehrlicherweise muß ich sagen, dass ich in punkto Firmware doppelt betroffen bin: Mein Intel 845BG-Mainboard enthält einen nicht austauschbaren e100-Netzwerkchip und eine ATI Radeon 7500, die aber ausgetauscht werden kann. Als ich das Mainboard 2003 gekauft habe, war nirgendwo irgendetwas davon zu lesen, dass die e100-Firmware unfrei sei. Damals hat das anscheinend niemanden im Linuxlager gestört.
Alternativ kann man ja auch die neuen Debian-Kernel wieder "zurückpatchen" und zum Download anbieten.
Es ist tatsächlich unlogisch, die unfreie Firmware im Kernel zu verteufeln, aber weiterhin die unfreie Firmware in ROM-Chips weiter zu benutzen, nur weil sie in Hardware "eingegossen" ist.
Es gibt hierbei im Endergebnis im Hinblick auf die Nutzung unfreier Firmware keinerlei Unterschied.
Debian handelt demzufolge hier irrational. Ich könnte diese Vorgehensweise nur dann als logisch ansehen, wenn sie gar keine unfreie Firmware mehr benutzen würden, als weder die unfreie Firmware im Kernel noch die unfreie Firmware in ROM-Chips auf der jeweiligen Hardware. Das Gleiche gilt zudem genauso für die meisten BIOS-Chips.
Auch ältere e100-Chips laufen mit neueren Kerneln nicht mehr, da der ältere, aber freie eepro-Treiber mittlerweile von kernel.org entfernt wurde.
Ähm, welche denn? Das sollte seit meinem Patch (non-MII) ein Stück besser sein (allerdings gibt es ein Non-Support-Window bei IIRC 2.6.28-2.6.29, erst 2.6.30 hatte den Patch dann drin, DA DIE LEUTE FAST EIN JAHR GEPENNT HABEN), aber ich hab auch schon Unkenrufe vernommen, dass es noch ganz andere Hardware gibt, die von e100 gar nicht unterstützt wird...
Das bestärkt mich in meiner Meinung, dass die Entfernung von eepro100 wohl eine Katastrophe war...
(scheint doch einige Leute zu betreffen - hohe Dunkelziffer -, wenn man hin und wieder aktiv mitbekommt, dass es Probleme gab)
Es gibt aber auch im SCSI-Controller-Bereich ähnliche Migrations-Katastrophen.
Daher eben die Frage: welche denn??
Laut Sidux z.B. sind es folgende: 82559 D101M/ D101M, 82551-F, 82551-10.
E100-Chips wie z.B. der recht haeufige Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller funktionieren ohne die e100-Firmware.
Ich bin gerade damit - ohne e100-Firmware - im Internet.
Dass es jetzt im RTWiki so aussieht, als ginge es nur um Industrie-Maschinen wird wieder einmal das ganze Thema in eine Nische schieben. RT-Fähigkeit sollte für Linux so selbstverständlich sein, wie für MacOSX. Die richtige Hardware/Treiber vorausgesetzt, arbeitet man auch unter MSWindows schon lange mit Latenzen um die 10 Millisekunden.
Unter Linux geht in der Tat mehr als unter MacOSX oder Win - auch mit einfacher Hardware. Mit Einsteiger-Profigerät kann man auch mit weniger als 3 ms stabil arbeiten. Alles mit bekannten Lösungen, die bis jetzt allerdings von gängigen Distributoren bestenfalls mit mildem Interesse gewürdigt und nur bei wenigen in offiziellen Repos geduldet werden.
:-)
Zusammen mit einem RT-Kern pustet das Ding einiges weg. Ich kann auf einem Rechner mit 1-Kernigem AMD-Prozessor, 2 GB RAM und einer vergleichbaren MAudio 1024 Ardour-Projekte mit mehr als 50 Spuren, 96KHz Samplerate und dutzenden LADSPA/LV2-Plugins problemlos mit 10 ms Latenz betreiben...
In der Welt wird mit Industriemaschinen der Tausendfache Umsatz gemacht wie mit Audio-Software...
Das ist sicher korrekt. Aber es kommen auch auf jedes Desktop-Linux na? 80, 100, 200? Server mit Linux, trotzdem sagt keiner, KDE oder GNOME wären für Linux nicht wichtig, weil Apache viel wichtiger ist.
Außerdem: Fakt ist, dass die Audio-Entwickler maßgeblichen Anteil an der Existenz von RT-Kerneln für Linux haben. Ohne die Unterstützung durch Paul Davis und andere Audioentwickler wäre Ingo Molnars Arbeit bestenfalls 5 Jahre später von den Hauptentwicklern von Linux als brauchbar und wichtig akzeptiert worden.
Die Fähigkeit, produktive Audiosoftware zu betreiben, ist für MacOSX eine Selbstverständlichkeit und auch unter Windows relativ leicht erreichbar. Solange Linux da nicht nachzieht, ist es kein vollwertiges, universelles Betriebssystem für alle Anwender.
Warscheinlich wäre es sinnvoller diverse Atari Clone Projekte zu unterstützen? So richtiges Realtime, ich meine damit "wirklich richtiges", wird es untwer Linux wohl nie geben können!
Unsinn ! RTAI erreicht hier bei mir 5µs, XENOMAI 10µs. RT-Preempt habe ich noch nicht ausprobiert.
Was verstehst Du denn unter "wirkliches richtiges" Realtime ?
PS: Welche Vor- und Nachteile hat das Aktivieren von RT_PREEMPT denn überhaupt zur Folge? Im Artikel wird das leider nicht so deutllich dargelegt.
Die Nutzung des Rechners als digitaler Mehrspurrekorder ohne wahrnehmbare (unter ~10ms?) Verzögerung zwischen abgespielten und dazu aufgenommenen Spuren wird möglich, siehe den vorherigen Diskussionszweig.
Für mich, dem einmal einfache Vierspurrekorder mit Audiokassetten ein zu teurer Traum waren, ist schon ein wie Programm audacity ein Hammer. Ohne RT-Kernel werden aber Verzögerungen zwischen alten und dazu neu aufgenommenen Spuren hörbar.
Pro:
stream-orientierte Prozesse wie Musiksoftware und überhaupt alles, was in Echtzeit rendert, kann mit garantierten Verzögerungszeiten rechnen. Damit kann man einen kleinen Buffer für den output verwenden und ein kontinuierlicher Stream (Soundsynthese/Wiedergabe, Messwerte etc) läuft ohne Unterbrechung. Die Anwendung kann beispielsweise mit weniger als 10 Millisekunden Verzögerung ansprechen, wenn man eine Taste drückt, ohne die Gefahr, dass der Buffer leer/überläuft (xrun), weil ein anderer Prozess sich dazwischen schiebt. Das Ganze geht *ohne* Root-Privilegien via PAM(solange, bis die Hardware tatsächlich die Last nicht mehr bringen kann).
Bei Musiksoftware erwartet jeder Anwender heutzutage genau dieses Verhalten. Mit einem Normalkernel kommt man bestenfalls auf 100 Millisekunden und selbst das ist nicht sicher.
Contra:
RT-Kernel holen eben alles raus, was drin ist. Damit kann man das System leichter mit einem Normalnutzerprozess erwürgen und RT-Kernel haben eine Tendenz mehr Strom zu verbrauchen. Canonical hat die einfache PREEMPT-VOLUNTARY aus Dapper entfernt, weil einige berichtet hatten, dass ihr Akku mit dem damals neuen Kernel schneller leer ist. Allgemein ist Linux mit RT ein etwas bissigeres Biest als ohne. Für Webserver ist ein RT-Kernel zumindest auf dem heutigen Stand keine sehr gute Idee...
Dann spräche doch nichts dagegen, die Patche in den kernel.org-Kernel einfließen zu lassen und einfach alle RT_PREEMT-Otionen per Default zu deaktivieren.
Oder werden Dinge gepatcht, die nicht per Option veränderbar sind?
Das schon...
> ...und so quasi einen Vanilla Kernel zu generieren?
Das eigentlich nicht - die RT-Patches ändern sehr viel im Kernel. Man kann zwar RT_PREEMPT abschalten und dann sollte sich so ein Kernel auch genauso wie ein Vanilla verhalten aber anders ist anders.
Machen könnte man das trotzdem - die Vanilla-Maintainer müssten bloß... ein paar 1000 RT-Code in Vanilla einpflegen };-)
IRQ Threads sind z.B. ab 2.6.30 im Linux Kernel drin: Realtime Linux Road Map
Stimmt, die Mainline-Entwickler haben schon einige Techniken aus dem RT-Zweig in Vanilla eingebaut. Man kann zum Beispiel einen Vanilla mit PREEMPT-VOLUNTARY übersetzen, dann bekommt man auch schon Alltagstaugliche Leistung für Jack und Co.
Macht aber kaum ein gängiger Distributor...