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
-
kochmarkus schrieb:
bladehunter schrieb:
kochmarkus schrieb:
Kantenglättung
Na toll. Jetzt habe ich noch ein Webcomic-Archiv, dass ich komplett durchlesen muss
Verdammte Webcomics...
Sind ja nicht sooo viele auf der Seite. Ich empfehle aber von Anfang an zu lesen, da die einzelnen Strips sehr zusammenhängen.
Natürlich lese ich die von Anfang an durch.
Das Comic gibt es "glücklicherweise" noch nicht so lange und deswegen habe ich es auch noch recht schnell geschafft, das Archiv durchzuarbeiten
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
MAC USER 4 EVER :D
Es soll ja bald eine neues Betriebsystem raus kommen hab ich gehört ? -
ja, schnee-leopard, oder? wirklich ein selsamer name.
-
ja das wird dann unter linux emuliert *lol*
-
nee, dann verdoppelt sich bestimmt die miese kantenglättung und alle buchstaben sind schwarze blöcke ...
-
verbrennt den ketzer !
-
Tut mir leid, dass ich diesen Thread ausgrabe, aber so viel Unsinn wie hier geschrieben wurde, kann ich einfach nicht so stehen lassen.
bladehunter, Windows-API und Linux-Kernel-API haben nichts miteinander gemeinsam, jeder Vergleich zwischen ihnen ist unsinnig. Für den Userspace-Programme hat Linux genauso wie Windows auch eine stabile API, aber Windows hat es eben auch für die Treiber.
Wer sagt, dass eine stabile Treiber-Kernel-API unwichtig ist, versteht nicht viel von der Materie. Eine solche ist ein absolutes MUSS, kein netter Zusatz, der mal 10 Jahre Zeit hat.
Als ich z. B. auf den 2.6.25 Kernel, so weit ich mich erinnere, updatete, streikte mein nVidia-Treiber wegen einer Kernel-API-Änderung, die Probleme haben mich so ein ganzes Wochenende Full-Time beschäftigt, bis ich das diagnostiziert und behoben hatte.
Dass Änderungen an der Kernel-API nur bei Updates, die die erste Zahl hinter dem Punkt betreffen, also z. B. von 2.4 auf 2.6, vorgenommen werden, ist völliger Unsinn, das habe ich beim 2.6.25er Kernel selbst anders erlebt. Verfolge doch einfach mal die Kernel-News eine Weile und dann wirst du schon selbst feststellen, dass zwischen 2.6.xx Kerneln massive Änderungen vorgenommen werden.
Es geht mir nicht darum, ob man von den Hardware-Herstellern verlangen darf, Open-Source-Treiber rauszubringen, sondern dass eine stabile Kernel-API unheimlich viel Aufwand einspart. Viele Treiber werden mit den Distributionen im Binärform mitgeliefert, überlege dir doch einmal, was für ein Aufwand auf allen Ebenen, d. h. Paketerstellung, Release-Manager usw. da unnötig erzeugt wird, denn bei jedem Kernel-Update muss das alles durchgecheckt werden! Oder allein in der Kernel-Entwicklung selbst, fünfmal im Jahr den USB-Stack komplett neuzuschreiben oder mal die ganze VM auszutauschen ist kein sehr effizientes Entwicklungsmodell, sondern eher eines, das auf schlechte Planung schließen lässt.
Beitrag zuletzt geändert: 1.5.2009 23:52:22 von steampunk -
steampunk schrieb:
Tut mir leid, dass ich diesen Thread ausgrabe, aber so viel Unsinn wie hier geschrieben wurde, kann ich einfach nicht so stehen lassen.
· muß dir doch nicht leid tun
· ist ja ein spam-forum ...
· tu dir keinen zwang an!
· tralala, ich muß auf den beitrag weiter nicht eingehen, weil ich von der materie eh keinen plan hab!
aber ich bin scheinbar der einzige mac-freund, der hier zusammengekommen ist
*eiskaffee ausgrab und schlürf* -
steampunk schrieb:
Tut mir leid, dass ich diesen Thread ausgrabe,
Aaaah was hast du getan?
aber so viel Unsinn wie hier geschrieben wurde, kann ich einfach nicht so stehen lassen.
Nun, ich lasse mich gerne eines besseren belehren.
bladehunter, Windows-API und Linux-Kernel-API haben nichts miteinander gemeinsam, jeder Vergleich zwischen ihnen ist unsinnig.
Ich habe den Thread gerade mal nach allen Vorkommnissen von "API" durchsucht und ich bin dort nirgendswo auf einen Vergleich gestoßen. Und als ich die WinApi erwähnt habe, bezog ich mich dabei auf die Probleme, die man als Programmierer auf anderen Plattformen hat.
Aber du hast natürlich Recht. Es wäre, wenn überhaupt, wahrscheinlich sinnvoller die Kernel API mit der nativen API von Windows zu vergleichen. Die interessanterweise nicht vollständig dokumentiert ist.
Für den Userspace-Programme hat Linux genauso wie Windows auch eine stabile API, aber Windows hat es eben auch für die Treiber.
Meinst du mit den beiden APIs folgendes? :
man(2) -> Kernel API
man(3) -> Gnu C library (glibc)
Wobei diese beiden APIs sich eher ergänzen, als dass die eine eine Alternative zu der anderen ist.
Wer sagt, dass eine stabile Treiber-Kernel-API unwichtig ist, versteht nicht viel von der Materie. Eine solche ist ein absolutes MUSS, kein netter Zusatz, der mal 10 Jahre Zeit hat.
Eine instabile API muss nicht heißen, dass ständig alles bestehende umgeworfen wird. Und ich wage zu behaupten, dass die Kernel-Entwickler dies nur aus guten Gründen tun.
Als ich z. B. auf den 2.6.25 Kernel, so weit ich mich erinnere, updatete, streikte mein nVidia-Treiber wegen einer Kernel-API-Änderung, die Probleme haben mich so ein ganzes Wochenende Full-Time beschäftigt, bis ich das diagnostiziert und behoben hatte.
Und wie hast du es behoben? Hast du deinen Treiber gepatcht, so dass er die API Aufrufe in der richtigen Form tätigt?
Dass Änderungen an der Kernel-API nur bei Updates, die die erste Zahl hinter dem Punkt betreffen, also z. B. von 2.4 auf 2.6, vorgenommen werden, ist völliger Unsinn, das habe ich beim 2.6.25er Kernel selbst anders erlebt. Verfolge doch einfach mal die Kernel-News eine Weile und dann wirst du schon selbst feststellen, dass zwischen 2.6.xx Kerneln massive Änderungen vorgenommen werden.
Ich habe recherchiert und muss dir Recht geben.
Es geht mir nicht darum, ob man von den Hardware-Herstellern verlangen darf, Open-Source-Treiber rauszubringen, sondern dass eine stabile Kernel-API unheimlich viel Aufwand einspart. Viele Treiber werden mit den Distributionen im Binärform mitgeliefert, überlege dir doch einmal, was für ein Aufwand auf allen Ebenen, d. h. Paketerstellung, Release-Manager usw. da unnötig erzeugt wird, denn bei jedem Kernel-Update muss das alles durchgecheckt werden!
Ich kann nicht abschätzen, wie viel Aufwand das wirklich ist. Wobei ich dir mit "auf allen Ebenen" nicht ganz zustimme. Die Programmierer einer Software müssen diese natürlich auf die neue Kernel API anpassen. Aber für die Packet-Maintainer in den Distros ist das ganze wie ein normales Packetupgrade. Natürlich macht sowas auch Arbeit, aber für einen Maintainer macht es keinen Unterschied, ob er jetzt ein Upgrade in die Repos einspielen muss, weil die Kernel API sich geändert hat, oder weil die neue Version Bugfixes beinhaltet.
Und auch wenn so aussieht, als wäre das alles furchbar viel Arbeit, so funktioniert dieses System trotzdem. Das heißt natürlich nicht, dass man diese Vorgehensweise nicht kritisieren darf.
Oder allein in der Kernel-Entwicklung selbst, fünfmal im Jahr den USB-Stack komplett neuzuschreiben oder mal die ganze VM auszutauschen ist kein sehr effizientes Entwicklungsmodell, sondern eher eines, das auf schlechte Planung schließen lässt.
Auch die Kernel-Entwickler sind keine Programmier-Götter. Und USB ist ein recht komplexer Standard, der meiner bescheidenen Einschätzung nach schwer zu implementieren ist. Und aus eigener Erfahrung weiß ich, dass es manchmal sinnvoll sein kann, den bestehenden Code wegzuwerfen und ihn neu zu schreiben, weil man sich verrannt hat. Es ist eine große Herausforderung ein großes Softwareprojekt richtig zu planen, denn man neigt dazu viele Details zu übersehen. Und diese Details können einem später richtig Probleme machen.
aber ich bin scheinbar der einzige mac-freund, der hier zusammengekommen ist
*eiskaffee ausgrab und schlürf*
*mitschlürf* Willste nen Schokokeks?
-
Kantenglättung!!!!11einseinself
Kernel-API!!!1111 *rumgröhl*
Ähh, ja... guten Morgen
*sich Kaffee nehm* -
tralala, hier die 15 zeichen
-
Meinst du mit den beiden APIs folgendes? :
Nein, die meine ich natürlich nicht. Wenn ich Kernel-API sage, dann meine ich ausschließlich die Kernel-API und nicht die API, die durch Bibliotheken bereitgestellt wird.
man(2) -> Kernel API
man(3) -> Gnu C library (glibc)
man(2) ist die Dokumentation der Kernel-API für die Userland-Programme. Diese API ist stabil, genauso wie die entsprechende API unter Windows. Die interne Kernel-API, die die Treiber benutzen, hat keine Dokumentation in den Manpages. Man kann sie sich nur über das Studieren des Kernel-Quellcodes vollständig erschließenEine instabile API muss nicht heißen, dass ständig alles bestehende umgeworfen wird. Und ich wage zu behaupten, dass die Kernel-Entwickler dies nur aus guten Gründen tun.
Es gibt zwei Extreme: erstens, dass die API überhaupt keine stabilen Phasen hat und sich jederzeit ändern kann, zweitens, dass die Stabilität der API die Weiterentwicklung bremst.
Es ist nicht schlimm, wenn in der Kernel-API ab und zu etwas revidiert wird, aber es muss stabile Phasen geben von, sagen wir mal, zwei Jahren. Dann sollten die Entwickler die User rechtzeitig auf bevorstehende API-Änderungen hinweisen und diese wenn möglich auch dokumentieren, am besten wäre natürlich eine "deprecated"-Schonfrist.Und wie hast du es behoben? Hast du deinen Treiber gepatcht, so dass er die API Aufrufe in der richtigen Form tätigt?
Nein, das wäre unmöglich gewesen, schließlich hatte ich ja den Quellcode nicht. Ich habe einen inoffiziellen Wrapper installiert.Ich kann nicht abschätzen, wie viel Aufwand das wirklich ist. Wobei ich dir mit "auf allen Ebenen" nicht ganz zustimme. Die Programmierer einer Software müssen diese natürlich auf die neue Kernel API anpassen. Aber für die Packet-Maintainer in den Distros ist das ganze wie ein normales Packetupgrade. Natürlich macht sowas auch Arbeit, aber für einen Maintainer macht es keinen Unterschied, ob er jetzt ein Upgrade in die Repos einspielen muss, weil die Kernel API sich geändert hat, oder weil die neue Version Bugfixes beinhaltet.
es ist sehr wohl ein Unterschied, weil es da viel schwerer für den Maintainer ist, die Abhängigkeiten zu erkennen.Auch die Kernel-Entwickler sind keine Programmier-Götter. Und USB ist ein recht komplexer Standard, der meiner bescheidenen Einschätzung nach schwer zu implementieren ist. Und aus eigener Erfahrung weiß ich, dass es manchmal sinnvoll sein kann, den bestehenden Code wegzuwerfen und ihn neu zu schreiben, weil man sich verrannt hat.
Du musst mir nicht erklären, dass Rewrites manchmal vernünftig sind. Aber doch bitte alles in Maßen, sonst zeigt man, dass man nicht planen kann und wie ein Cowboy coded
. Der FreeBSD-USB-Stack wurde ja auch nur einmal neugeschrieben, Windows, weiß ich nicht, ist Betriebsgeheimnis, aber ich denke auch nicht so oft.Es ist eine große Herausforderung ein großes Softwareprojekt richtig zu planen, denn man neigt dazu viele Details zu übersehen. Und diese Details können einem später richtig Probleme machen.
Weiß ich selber nur zu gut, nur wenn die Konkurrenz besser ist, sollte man die Fehler bei sich selbst suchen. Die BSDs und Windows haben eine stabile Treiber-Kernel-API und sind auch nicht völlig schlechte Betriebssysteme
-
Ich begreife den Zusammenhang zu dem Induktionsherde(n) nicht...
-
steampunk schrieb:
Meinst du mit den beiden APIs folgendes? :
man(2) -> Kernel API
man(3) -> Gnu C library (glibc)
Nein, die meine ich natürlich nicht. Wenn ich Kernel-API sage, dann meine ich ausschließlich die Kernel-API und nicht die API, die durch Bibliotheken bereitgestellt wird.
Ich habe mich in der Tat geirrt. Danke für den Hinweis.
man(2) -> Syscalls an den Kernel
man(2) ist die Dokumentation der Kernel-API für die Userland-Programme. Diese API ist stabil, genauso wie die entsprechende API unter Windows.
Da habe ich andere Informationen. Und diese Informationen waren auch dafür verantwortlich, dass ich gedacht habe, dass die Funktionen in man(2) der Kernel API entsprechen, weil beides nicht stabil ist.
In meinem Buch "Assembly Language Step by Step" steht auf Seite 453, letzter Absatz:
The INT 80H interface is what the C library uses to communicate with the kernel, and the authors if Linux make it clear that they reserve the right to change the parameters and semantics (that is, what the calls do) of kernel primitives as necessary without notice or apology
Bei meinen Recherchen bin ich zusätzlich auf folgendes gestoßen: http://lkml.indiana.edu/hypermail/linux/kernel/0308.0/1032.html
Auch hier gibt es Hinweise, dass die Syscall-API nicht stabil ist.
edit: Ich habe weitere Informationen, die deutlich offizieller sind und dir Recht geben:
Aus der Documentation/stable_api_nonsense.txt im Kernel-Packet
This is being written to try to explain why Linux does not have a binary
kernel interface, nor does it have a stable kernel interface. Please
realize that this article describes the _in kernel_ interfaces, not the
kernel to userspace interfaces. The kernel to userspace interface is
the one that application programs use, the syscall interface. That
interface is _very_ stable over time, and will not break. I have old
programs that were built on a pre 0.9something kernel that still work
just fine on the latest 2.6 kernel release. That interface is the one
that users and application programmers can count on being stable.
Ich gebe dir also doch Recht.
Die interne Kernel-API, die die Treiber benutzen, hat keine Dokumentation in den Manpages. Man kann sie sich nur über das Studieren des Kernel-Quellcodes vollständig erschließen
Ich habe zumindest folgendes gefunden: http://www.gnugeneration.com/books/linux/2.6.20/kernel-api/index.html Allerdings scheint sich diese Dokumentation auf den 2.6.20er Kernel zu beschränken.
Gibt es denn bestimmte Header-Dateien die als halbwegs übersichtliche Dokumentation dienen, oder muss man wirklich in den eigentlichen Code reinschauen?
Eine instabile API muss nicht heißen, dass ständig alles bestehende umgeworfen wird. Und ich wage zu behaupten, dass die Kernel-Entwickler dies nur aus guten Gründen tun.
Es gibt zwei Extreme: erstens, dass die API überhaupt keine stabilen Phasen hat und sich jederzeit ändern kann, zweitens, dass die Stabilität der API die Weiterentwicklung bremst.
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.
Es ist nicht schlimm, wenn in der Kernel-API ab und zu etwas revidiert wird, aber es muss stabile Phasen geben von, sagen wir mal, zwei Jahren. Dann sollten die Entwickler die User rechtzeitig auf bevorstehende API-Änderungen hinweisen und diese wenn möglich auch dokumentieren, am besten wäre natürlich eine "deprecated"-Schonfrist.
Eigentlich wird ein neuer Kernel erstmal ausgibig von Freiwilligen getestet, bevor er in die Repos kommt. Und die OpenSource Treiber werden von den Maintainern auch an die neue API angepasst. Wenn jetzt jemand verschläft, die Treiber anzupassen, dann ist das natürlich doof, aber ich habe auch meine Zweifel, dass eine 2-jährliche Ankündigungszeit da viel helfen würde. 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.
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 wie hast du es behoben? Hast du deinen Treiber gepatcht, so dass er die API Aufrufe in der richtigen Form tätigt?
Nein, das wäre unmöglich gewesen, schließlich hatte ich ja den Quellcode nicht. Ich habe einen inoffiziellen Wrapper installiert.
Es war also ein proprietärer Treiber?
Ich kann nicht abschätzen, wie viel Aufwand das wirklich ist. Wobei ich dir mit "auf allen Ebenen" nicht ganz zustimme. Die Programmierer einer Software müssen diese natürlich auf die neue Kernel API anpassen. Aber für die Packet-Maintainer in den Distros ist das ganze wie ein normales Packetupgrade. Natürlich macht sowas auch Arbeit, aber für einen Maintainer macht es keinen Unterschied, ob er jetzt ein Upgrade in die Repos einspielen muss, weil die Kernel API sich geändert hat, oder weil die neue Version Bugfixes beinhaltet.
es ist sehr wohl ein Unterschied, weil es da viel schwerer für den Maintainer ist, die Abhängigkeiten zu erkennen.
Das kann ich nicht ganz nachvollziehen. Die einzige Abhängigkeit für einen Treiber dürfte doch nur der Kernel selber in einer bestimmten Version sein? Und selbst wenn der Treiber weitere Abhängigkeiten hat, so dürften sich diese alleine aufgrund der Kernel-API Änderung nicht auch ändern, oder doch?
Auch die Kernel-Entwickler sind keine Programmier-Götter. Und USB ist ein recht komplexer Standard, der meiner bescheidenen Einschätzung nach schwer zu implementieren ist. Und aus eigener Erfahrung weiß ich, dass es manchmal sinnvoll sein kann, den bestehenden Code wegzuwerfen und ihn neu zu schreiben, weil man sich verrannt hat.
Du musst mir nicht erklären, dass Rewrites manchmal vernünftig sind. Aber doch bitte alles in Maßen, sonst zeigt man, dass man nicht planen kann und wie ein Cowboy coded. Der FreeBSD-USB-Stack wurde ja auch nur einmal neugeschrieben, Windows, weiß ich nicht, ist Betriebsgeheimnis, aber ich denke auch nicht so oft.
Ich weiß nicht, was jetzt genau die Gründe für die Rewrites waren. Und ich bin im Moment aus Zeitgründen auch nicht dazu in der Lage, zu recherchieren, in welchen Zeitabständen innerhalb eines Jahres diese Rewrites stattgefunden haben. Aber vielleicht war es einfach der Drang nach Perfektion, der sie dazu veranlasst hat, den USB Stack so oft neu zu schreiben. Und nach jeder Implementierung haben sie Erfahrung gesammelt, die sie dann in ihren Rewrite einfließen haben lassen. Das mag jetzt wie Cowboy-Coding aussehen und ich will die Entwickler jetzt auch nicht in Schutz nehmen, da ich nicht weiß, welche Gründe es für die Rewrites gab, aber ich halte das jetzt auch nicht für so schlimm, dass es so gelaufen ist. In einer Firma hätte man wahrscheinlich niemals einen solchen Rewrite vorgenommen, weil die Zeit und das Geld fehlt. Man hätte dem Kunden das Produkt in die Hand gedrückt und damit wäre die Sache gegessen gewesen. Es kann natürlich sein, dass dieses Firmen-Produkt funktioniert und der Anwender damit arbeiten kann. Aber gegen ein paar Verbesserungen gibt es doch nichts einzuwenden, oder?
Und es geht hier nicht um irgendein Kernel-Bestandteil, sondern um den USB-Stack. Und USB ist heutzutage nunmal der de-facto Anschluss für Peripherie und entsprechend ist es schon sinnvoll, dort eine möglichst optimale Implementierung zu haben.
Und in diesem Zusammenhang fällt mir auf folgender Link ein, den wir in diesem Thread bereits hatten:
http://www.kroah.com/log/linux/ols_2006_keynote.html
Die entsprechendne 2 Absätze zu USB:
Here's an example that shows how this all works. The Linux USB code has been rewritten at least three times. We've done this over time in order to handle things that we didn't originally need to handle, like high speed devices, and just because we learned the problems of our first design, and to fix bugs and security issues. Each time we made changes in our api, we updated all of the kernel drivers that used the apis, so nothing would break. And we deleted the old functions as they were no longer needed, and did things wrong. Because of this, Linux now has the fastest USB bus speeds when you test out all of the different operating systems. We max out the hardware as fast as it can go, and you can do this from simple userspace programs, no fancy kernel driver work is needed.
Now Windows has also rewritten their USB stack at least 3 times, with Vista, it might be 4 times, I haven't taken a look at it yet. But each time they did a rework, and added new functions and fixed up older ones, they had to keep the old api functions around, as they have taken the stance that they can not break backward compatibility due to their stable API viewpoint. They also don't have access to the code in all of the different drivers, so they can't fix them up. So now the Windows core has all 3 sets of API functions in it, as they can't delete things. That means they maintain the old functions, and have to keep them in memory all the time, and it takes up engineering time to handle all of this extra complexity. That's their business decision to do this, and that's fine, but with Linux, we didn't make that decision, and it helps us remain a lot smaller, more stable, and more secure.
Es ist eine große Herausforderung ein großes Softwareprojekt richtig zu planen, denn man neigt dazu viele Details zu übersehen. Und diese Details können einem später richtig Probleme machen.
Weiß ich selber nur zu gut, nur wenn die Konkurrenz besser ist, sollte man die Fehler bei sich selbst suchen. Die BSDs und Windows haben eine stabile Treiber-Kernel-API und sind auch nicht völlig schlechte Betriebssysteme
Nunja, die Frage ist bloß, ob man es jetzt als besser oder schlechter ansieht: Ich selber halte es für besser, wenn man nicht die erste Implementierung nimmt, sondern sich richtig Mühe gibt, und deswegen erst beim 5. Versuch zufrieden ist.
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.
Beitrag zuletzt geändert: 3.5.2009 15:31:50 von bladehunter -
test test test test
-
sonok schrieb:
Danke das du den Thread wieder ausgegraben hast.
test test test test
Hab ihn irgendwie schon vermisst
-
hey, der ist doch gerade mal 2 tage alt!
nönönö, ich buddel nur nach realen schätzen im wald
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
