MAC OS-X Freunde kommt zusammen ...
lima-city → Forum → Sonstiges → Spam und sonstiges Unvergütetes
betriebssystem
code
entwickler
fehler
frage
hardware
hilfe
http
jahr
machen
problem
programm
punkt
schrift
software
system
treiber
url
vergleich
windows
-
sonok schrieb:
hey, der ist doch gerade mal 2 tage alt!
ey, was soll das? Ich will schlafen... -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
na, dann klemm mal deinen sehnerv vom rechner ab
-
Was heißt hier Sehnerv? Du bist in den Bewegungsmelder des Threads gekommen und hast mich geweckt *gähn*
-
Nein, ich habe ein ausgeklügeltes Warnsystem, das anschlägt, wenn in fragwürdigen Threads wie diesen gepostet wird
-
hm, dann tut es mir natürlich sehr sehr leid, daß ich dich aus deinem dings geweckt hab
-
Gey schlüffen, blady!
-
sonok schrieb:
hey, der ist doch gerade mal 2 tage alt!
nönönö, ich buddel nur nach realen schätzen im wald
Jetzt bin ich ja wieder da, also Sonntag hatte ich keine Zeit, Montag + Dienstag, als ich Zeit hatte, ging lima-city.de nicht. Mittwoch war ich leider auch komplett ausgebucht.
Ich gebe dir also doch Recht.
Das ist schön. Gibt es denn bestimmte Header-Dateien die als halbwegs übersichtliche Dokumentation dienen, oder muss man wirklich in den eigentlichen Code reinschauen?
Die Comments sind ja so aufgebaut, dass sie von Doxygen interpretiert werden können, man kann sich also selbst so ein html-Dokument wie auf gnugeneration erzeugen. Allerdings besteht die Beschreibung so durchschnittlich aus drei Wörter pro Funktion/Datenstruktur...
Ich denk also schon, dass man sich den eigentlichen Sourcecode anschauen muss.Dann muss man sich fragen, ob die Kernel-Entwickler die goldene Mitte getroffen haben. Falls du einen guten Einblick in die Entwicklung des Kernels haben solltest, würde mich interessieren, wie du die Sache einschätzt.
Ich würde nicht von mir behaupten, dass ich einen wirklich guten Einblick habe. Sicher ist aber, dass Linux-Treiber-Entwicklung ohne Mithilfe der Kernel-Entwickler sehr schwer wird.Wenn jemand es verschläft gewisse Anpassungen vorzunehmen, weil er nicht wahrnimmt, dass die API-Änderungen auch den Treiber betreffen, dann wird auch mehr Zeit nicht viel nützen.
Es ist für ein kleines oder mittleres Unternehmen extrem schwer, den Treiber auf die Kernel-Änderungen anzupassen, die einzige Möglichkeit ist, dass es in den offiziellen Main-Kernel-Tree kommt, so dass die Kernel-Entwickler selber die Änderungen vornehmen können.
Und je nach Distribution kriegt man häufiger oder weniger häufig Updates. Bei Ubuntu (stable) kriegt man nur alle 6 Monate einen neuen Kernel und bei Debian (stable) noch seltener. Dem gegenüber stehen Distries mit einem Roling-Release-System, wo neue Versionen nach kurzer Testzeit in die Repos kommen und in der Regel gibt es keine Probleme damit.
Vielleicht sehe ich das auch falsch und und denke einfach anders darüber, weil ich bisher einfach Glück hatte, dass mir außer ein paar kleineren Xorg-Problemen(Rolling Release) nichts passiert ist. Aber auch sonst hört man wenig schlechtes über OpenSource Software-Updates.Und um nochmal auch die Kernel-API zurückzukommen: Beide Ansätze bringen potentiell Ärger. Du hast ja bereits die 2 Extrema genannt. Entsprechend ist es auch schwierig objektiv zu beurteilen, welcher Ansatz besser ist.
Es gibt kein Betriebssystem, was in dem Punkt so schlecht da steht wie Linux, natürlich macht das die Sache vielleicht effizient. Natürlich sind mir die Vorteile bewusst, ich weiß jetzt aber nicht, ob es nicht besser wäre mehr Treiber zu haben, als nen cutting-edge USB-Stack.
Es ist ja nicht damit getan, dass ein Hardwarehersteller seinen Treiber unter GPL stellt, er hat schon fast die Garantie dafür, dass fremde Entwickler Änderungen vornehmen werden. Proprietäre Treiber sind noch problematischer und das führt eben zu der Situation, die wir jetzt haben: die Hardwareunterstützung ist immer noch mangelhaft. Und wenn morgen sämtliche Hardwarehersteller Open-Source-Treiber rausbringen würden, bräuchte es auch noch mehr Kernel-Entwickler für die Wartung!
Der Sinn der letzten drei Posts war halt zu zeigen, dass man zugeben muss, dass die schlechte Situation bei den Treibern teilweise selbst verschuldet ist. Ja, Intel schafft es irgendwie, aber dafür ist die Hardware (Grafik) Müll
-
steampunk schrieb:
Ja, Intel schafft es irgendwie, aber dafür ist die Hardware (Grafik) Müll
Was spricht gegen Intel Grafikchips? (Ausseren deren 3D Leistung)
-
Müll sind die Intel-Chips natürlich nicht, aber sie sind definitiv nicht so leistungsfähig wie die entsprechenden Konkurrenzprodukte, auch bei 2D-Anwendungen. Mir ist das z. B. beim Abspielen von Blu-rays aufgefallen.
-
Aso, dafür brauche ich sie nicht. Ich benötige sie vorallem für Präsentationen und problemloses umherschalten zwischen verschiedenen Graphik-Modi und das schaffen die NVidia und ATI Chips in Notebooks nichtmal ansatzweise so gut, wie die von Intel. (Nach meinen bisherigen Erfahrungen mit zahlreichen Notebooks...)
Bei Intel Chips ist es mir noch nicht passiert, dass ein Video bei DuaView Clone-Output nur auf dem ersten, nicht aber auf dem Zweiten Monitor angezeigt wurde...
//EDIT:
Obgleich der Vergleich, fällt mir ein, vielleicht etwas hinkt, da es teilweise auch Schul-Notebooks waren, die in Sachen Software-Konfiguration ... darüber wollen wir gar nicht sprechen...
Beitrag zuletzt geändert: 7.5.2009 18:47:48 von erasmuz -
Ich werde mich in meiner Antwort hauptsächtlich auf http://www.kroah.com/log/linux/ols_2006_keynote.html beziehen, da ich von der Kernel-Entwicklung leider nicht viel Ahnung habe.
steampunk schrieb:
Dann muss man sich fragen, ob die Kernel-Entwickler die goldene Mitte getroffen haben. Falls du einen guten Einblick in die Entwicklung des Kernels haben solltest, würde mich interessieren, wie du die Sache einschätzt.
Ich würde nicht von mir behaupten, dass ich einen wirklich guten Einblick habe. Sicher ist aber, dass Linux-Treiber-Entwicklung ohne Mithilfe der Kernel-Entwickler sehr schwer wird.
Nunja, wie sieht es denn bei anderen Betriebssystemen aus? Gibt es da eine gute Doku, die einen einführt?
Auf dem verlinkten Vortrag wird zumindest für Linux erwähnt, dass es entsprechende Einsteiger-Wikis und Mailinglisten ect. gibt. Aber bezüglich der Doxygen Doku hast du wahrscheinlich Recht. Es wäre sinnvoller, da wesentlich mehr Informationen zur Verfügung zu stellen.
Es ist für ein kleines oder mittleres Unternehmen extrem schwer, den Treiber auf die Kernel-Änderungen anzupassen, die einzige Möglichkeit ist, dass es in den offiziellen Main-Kernel-Tree kommt, so dass die Kernel-Entwickler selber die Änderungen vornehmen können.
Wenn man der Website glauben darf, gibt es in Documentation/HOWTO eine gute Doku, wie man in den Kernel-Tree reinkommt. Ich kann natürlich nicht beurteilen, wie schwer es wirklich ist und man hat natürlich das Problem, dass man nicht "einfach" nen Treiber programmieren kann und ihn ausliefert, sondern dass die Kernel-Entwickler auch noch ihren Senf dazu geben.
Hatte Microsoft nicht auch mal irgendwas geplant/umgesetzt bezüglich überprüfter und signierter Vista-Treiber?
Und um nochmal auch die Kernel-API zurückzukommen: Beide Ansätze bringen potentiell Ärger. Du hast ja bereits die 2 Extrema genannt. Entsprechend ist es auch schwierig objektiv zu beurteilen, welcher Ansatz besser ist.
Es gibt kein Betriebssystem, was in dem Punkt so schlecht da steht wie Linux,
Und mit "schlecht dastehen" meinst du die Tatsache, dass "Niemand" Treiber entwickeln will, weil es keine stabile API gibt? Also an dieser Stelle denke ich eher, dass die Firmen nur Windows sehen, weil dieses Betriebssystem nunmal ein deutliches Monopol hat und es sich nach Rechnung einiger engsichtiger BWLer nicht lohnt Treiber für ein angebliches Nischenbetriebssystem zu entwickeln.
Und wenn der Manager dann erfährt, dass der Treiber OpenSource sein muss und von den Kernel-Entwicklern begutachtet wird, dann schreckt das natürlich den Linux-fremden Manager ab.
natürlich macht das die Sache vielleicht effizient. Natürlich sind mir die Vorteile bewusst, ich weiß jetzt aber nicht, ob es nicht besser wäre mehr Treiber zu haben, als nen cutting-edge USB-Stack.
Du meinst wohl eher "die richtigen Treiber haben", anstatt "mehr Treiber zu haben". Denn Linux unterstüzt nunmal eine sehr große Auswahl an Hardware. Außerdem wirfst du hier 2 Dinge durcheinander. Einen cutting-Edge USB Treiber zu schreiben ist Fleißarbeit (und natürlich die entsprechende Dosis Programmier-Kunst). Aber eine stabile API zu haben ist nichts, was man sich einfach so erarbeiten kann. Man kann natürlich einfach sagen "jetzt ist Stillstand", aber wäre das wirklich so sinnvoll? Und selbst wenn die aktuelle API ein guter Kompromiss wäre, ist es trotzdem denkbar, dass im Laufe der Jahre ein anderes API-Modell sinnvoller wäre.
Es ist ja nicht damit getan, dass ein Hardwarehersteller seinen Treiber unter GPL stellt, er hat schon fast die Garantie dafür, dass fremde Entwickler Änderungen vornehmen werden. Proprietäre Treiber sind noch problematischer und das führt eben zu der Situation, die wir jetzt haben: die Hardwareunterstützung ist immer noch mangelhaft. Und wenn morgen sämtliche Hardwarehersteller Open-Source-Treiber rausbringen würden, bräuchte es auch noch mehr Kernel-Entwickler für die Wartung!
Die verlinkte Website sagt hier:
We want more drivers, no matter how "obscure", because it allows us to see patterns in the code, and realize how we could do things better. If we see a few drivers doing the same thing, we usually take that common code and move it into a shared piece of code, making the individual drivers smaller, and usually fixing things up nicer. We also have merged entire drivers together because they do almost the same thing. An example of this is a USB data acquisition driver that we have in the kernel. There are loads of different USB data acquisition devices out in the world, and one German company send me a driver a while ago to support their devices. It turns out that I was working on a separate driver for a different company that did much the same thing. So, we worked together and merged the two together, and we now have a smaller kernel. That one driver turned out to work for a few other company's devices too, so they simply had to add their device id to the driver and never had to write any new code to get full Linux support. The original German company is happy as their devices are fully supported, which is what their customers wanted, and all of the other companies are very happy, as they really didn't have to do any extra work at all. Everyone wins.
Mehr Treiber bedeuten natürlich auch potentiell mehr Arbeit. Jedoch wird hier auch gemischt, was gemischt werden kann.
Der Sinn der letzten drei Posts war halt zu zeigen, dass man zugeben muss, dass die schlechte Situation bei den Treibern teilweise selbst verschuldet ist. Ja, Intel schafft es irgendwie, aber dafür ist die Hardware (Grafik) Müll
Ich kann durchaus nachvollziehen, dass die Bedingungen einigen Firmen nicht gefallen. Aber OpenSource ist nunmal ein Feature, das Benutzer auch als Vorteil ansehen kann und deswegen ist Linux bei vielen Leuten so beliebt.
Und das hat natürlich seine Konsequenzen, genauso wie es Konsequenzen hat, dass Microsoft ihr Betriebssystem alleine entwickelt und die Benutzer sich damit zufriedengeben müssen, was Redmond ihnen liefert. -
Ich werde mich in meiner Antwort hauptsächtlich auf http://www.kroah.com/log/linux/ols_2006_keynote.html beziehen, da ich von der Kernel-Entwicklung leider nicht viel Ahnung habe.
Ich kann Greg Kroah nicht so ernst nehmen, er schreibt in stable_api_nonsense.txt einiges an Unsinn (vorsätzlich, denn er muss es besser wissen), wie z. B. dass wir ja eh keinen stabile Kernel-API brauchen, da sich die ABI je nach Version von libc und C-Compiler ändert. Ja, das stimmt aber das Problem haben auch anderen Betriebssysteme und größere Softwareprojekte, und sie werden alle damit fertig. Es gibt einige Reihe von Techniken, die jeder gute Entwickler kennt, um die ABI-Kompatibilität zu wahren.
Die Windows Driver Foundation ist vollständig dokumentiert und enthält auch eine Einführungsdoku, FreeBSD weiß ich nicht, aber die Doxygen-Doku des Kernels ist zumindest sehr gut.
Nunja, wie sieht es denn bei anderen Betriebssystemen aus? Gibt es da eine gute Doku, die einen einführt?Wenn man der Website glauben darf, gibt es in Documentation/HOWTO eine gute Doku, wie man in den Kernel-Tree reinkommt. Ich kann natürlich nicht beurteilen, wie schwer es wirklich ist und man hat natürlich das Problem, dass man nicht "einfach" nen Treiber programmieren kann und ihn ausliefert, sondern dass die Kernel-Entwickler auch noch ihren Senf dazu geben.
Ja, das HOWTO (do Linux kernel development) ist schon sehr umfangreich, aber auch ziemlich durcheinander.
Hatte Microsoft nicht auch mal irgendwas geplant/umgesetzt bezüglich überprüfter und signierter Vista-Treiber?Und mit "schlecht dastehen" meinst du die Tatsache, dass "Niemand" Treiber entwickeln will, weil es keine stabile API gibt? Also an dieser Stelle denke ich eher, dass die Firmen nur Windows sehen, weil dieses Betriebssystem nunmal ein deutliches Monopol hat und es sich nach Rechnung einiger engsichtiger BWLer nicht lohnt Treiber für ein angebliches Nischenbetriebssystem zu entwickeln.
Ich denke, was ihn am meisten abschreckt, ist, dass er die Kontrolle über den ganzen Prozesse verliert. Bei Windows oder bei Macs (um mal ein Nieschenbetriebssystem zu nennen) kann der Hardwarehersteller einfach testen, ob seine Treiber funktionieren und dann auch die Garantie dafür geben.
Und wenn der Manager dann erfährt, dass der Treiber OpenSource sein muss und von den Kernel-Entwicklern begutachtet wird, dann schreckt das natürlich den Linux-fremden Manager ab.
Mal ehrlich, selbst wenn einiges von Linux unterstützt wird, es gibt nur ganz, ganz wenig Hardware, wo auf der Packung vorne steht "läuft auf Linux ab Kernel 2.6".
Es ist ein zu großes Risiko für den Hersteller, das zu garantieren und "läuft wahrscheinlich auf Linux" kann er ja wohl schlecht auf die Packung drucken.
Nochmal, stabile APIs für alle Ewigkeit gibt es nie, XP z. B. war glaube ich die letzte Windows-Version, die noch 16-Bit Programme ausführen konnte.
Du meinst wohl eher "die richtigen Treiber haben", anstatt "mehr Treiber zu haben". Denn Linux unterstüzt nunmal eine sehr große Auswahl an Hardware. Außerdem wirfst du hier 2 Dinge durcheinander. Einen cutting-Edge USB Treiber zu schreiben ist Fleißarbeit (und natürlich die entsprechende Dosis Programmier-Kunst). Aber eine stabile API zu haben ist nichts, was man sich einfach so erarbeiten kann. Man kann natürlich einfach sagen "jetzt ist Stillstand", aber wäre das wirklich so sinnvoll? Und selbst wenn die aktuelle API ein guter Kompromiss wäre, ist es trotzdem denkbar, dass im Laufe der Jahre ein anderes API-Modell sinnvoller wäre.
Eine über eine gewisse Zeit stabile API ist der Standard. Linux hat das nicht, und damit machen sie es anders als der Rest der Welt.
Und IMHO kann man sich sehr wohl eine stabile API vornehmen. Die erfahrensten Programmierer in einem Projekt sollten den Weitblick haben, dass sie nach einer Planungsphase sagen können "so und so werden wir es jetzt machen, und dabei bleiben wir auch die nächsten zwei Jahre erstmal".
Nach der Zeit hat man dann genug Erfahrung gesammelt, sodass wieder sinnvoll etwas an der API geändert werden kann.
Beitrag zuletzt geändert: 8.5.2009 16:09:45 von steampunk -
Ich gebe dir in allen Punkten Recht.
-
˙ɟdoʞ sǝllɐ ʇzʇǝɾ ʇɥǝʇs ɹıɯ ıǝq `ǝɟlıɥ
˙ʇlǝıdsǝƃɯnɹ ƃunʇʇälƃuǝʇuɐʞ ɹǝp uɐ lǝıʌ nz qɐɥ ɥɔı ǝqnɐlƃ ɥɔı
-
kochmarkus schrieb:
˙ɟdoʞ sǝllɐ ʇzʇǝɾ ʇɥǝʇs ɹıɯ ıǝq `ǝɟlıɥ
˙ʇlǝıdsǝƃɯnɹ ƃunʇʇälƃuǝʇuɐʞ ɹǝp uɐ lǝıʌ nz qɐɥ ɥɔı ǝqnɐlƃ ɥɔı
das ist genial.
total sinnlos aber genial. wie hast du das gemacht???
-
ǝlƃooƃ lɐɯ ɥɔɐɟuıǝ ɥɔop ʇɥnɯǝq: http://www.revfad.com/flip.html
Beitrag zuletzt geändert: 9.5.2009 20:29:24 von kochmarkus -
kochmarkus schrieb:
ǝlƃooƃ lɐɯ ɥɔɐɟuıǝ ɥɔop ʇɥnɯǝq: http://www.revfad.com/flip.html
˙dʎʇ uǝp ƃɐɯ ɥɔı
(-: ǝlıǝʍǝƃuɐl ɥɔılʇuǝpɹo puɐɯǝɾ ǝʇʇɐɥ ɐp
llǝɥ ǝɥʇ ʇɐɥʍ
irgendwie weist das script aber noch fehler auf
das l wird falsch dargestellt
Beitrag zuletzt geändert: 9.5.2009 20:35:27 von goldeneye -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
