Derzeit ist neu der Code nicht größer als der alte, Ich glaube hier ist der "Beweis" dafür das der Text im wesentlichen von einem Übersetzungsprogramm stammt, liest sich zumindest alles sehr holprig.
Und was bedeutet im Unterschied dazu im Deutschen das Wort "Implementation"?
Falls es nichts anderes bedeutet, könnte man mit "Implementation" eins dieser blöden "ung"-Worte vermeiden, wie z.B. Kompression statt (würg) Komprimierung.
Falls es doch was anderes bedeutet, wäre eins von beiden eine ungeschickte Wortwahl...
Du meinst, die Bedeutung hinter dem englischen Wort "implementation" deckt sich größtenteils mit dem, was im Deutschen bislang "Implementierung" geheissen wurde, richtig? Sobald es aber auch das deutsche Wort ""Implementation" gibt (durch Gebrauch) und von einer nicht unbedeutenden Anzahl Personen als Verweis auf den gleichen Begriff verwendet wird, trifft Deine Behauptung nicht mehr zu. Tut mir leid. Alles fließt.
Der deutsche Begriff "Implementation" (du kannst ja im Duden nachschlagen) ist insbesondere im technischen Bereich zu verwenden. Dein Einwand ist also ungerechtfertigt.
Es gibt im Deutschen Implementierung und Implementation: Zunächst hat man einen Algorithmus, der implementiert wird (= ausprogrammiert). Diese *Tätigkeit* ist die Implementierung. Die Implementation ist dann das fertige Teil, also das Programm.
Aber ich glaube, wenn Gewicht auf den Vorgang der Entwicklung gelegt wird, ist es auch in Ordnung, "Implementierung" für das Endprodukt zu verwenden. "Implementation" klingt statisch, abgeschlossen.
Da steht explizit "Implementation entwickelt" - das hat auch mein Sprachverständnis irritiert. Es hört sich nicht ganz "richtig" an, auch wenn es wohl in Ordnung ist. Da explizit von Entwicklung (also dem Prozess) die Rede ist, kann man wohl auch "Implementierung entwickelt" sagen.
Mal nebenbei ist das vielleicht einfach ganz generell etwas redundant und schlechtes Deutsch von "entwickelten Implementationen" zu reden, weil der Begriff der Implementation schon voraussetzt, dass etwas entwickelt wurde.
Der Schluß liegt nahe, dass der Verfasser des Artikels keine Preise für eloquentes Deutsch gewinnen wollte, sondern sich auf den Inhalt selbst konzentriert hat.
..anhand der bisherigen Kommentare, kann man doch sicher drauf schliessen, daß hier zu 99% (oder gar 999Promille) nur Linuxuser und keine Linuxhacker vorbeischauen :)) !!11ölf
au contraire, es bedeutet nur, dass sich bislang nur LinuxUser dazu bereitgefunden haben, einen Kommentar zu schreiben.
Und hier kommt er schon: Obgleich ich diese Entwicklung begrüße, mache ich mir natürlich Sorgen, welche Auswirkung die Veränderte Schnittstelle auf die Stabilität des Dateisystems haben wird... glücklicherweise hat man bei Linux immer die Wahl, welche Version man verwenden will.
Da würd ich mir keine Sorgen machen, bis so etwas nicht 100%ig stabil und zuverlässig funktioniert wird Linus es sicher nicht in den Kernel einfließen lassen. Zum Testen gibts dann ja -ac & Co.
> Da würd ich mir keine Sorgen machen, bis so etwas nicht 100%ig stabil und zuverlässig funktioniert wird > Linus es sicher nicht in den Kernel einfließen lassen.
Da wäre ich mir nicht so sicher http://kerneltrap.org/node/8414
Von Anonymous Coward am Mo, 25. Juni 2007 um 16:36 #
Was heiÃt hier Halbwahrheit? Fehler passieren. Der einzige Weg, wie man das verhindern könnte, wÀre, die Korrektheit zu beweisen, aber das ist bei einem Kernel wie Linux (monolithisch, in C geschrieben, welches fÃŒr formale Beweise ungeeignet ist) unrealistisch.
Von Benjamin Kießling am Mo, 25. Juni 2007 um 16:49 #
Juhu holt das Popcorn raus, das C-Bashing beginnt wieder! ;) C ist halt nunmal die beste Sprache für relativ hardwarenahes Programmieren daran änderst auch du nichts. Mysteriöserweise hat noch niemand ein größeres OS in irgendeiner "sicheren" Sprache geschrieben, das auch im weiteren Gebrauch ist.
Es hat auch noch niemand hier gefordert, ein OS in einer High-Level-Sprache zu schreiben, der OP einzig allein ausgesagt, das Korrektheitsbeweise fuer den Linuxkernel nicht machbar sind (und deshalb Fehler passieren). Aber wenn du schon das C-Bashing beginnen moechtest: Die Anfuehrungszeichen kannst Du dir sparen, in fast jeder Sprache entwickelt es sich sicherer als in C.
Z.B. die enorm kurze Testphase, bevor man das nächste Release dem Nutzer zum Fraß vorwirft. Es wäre schön, wenn Linux 2.6 gepflegt würde und neue Features/partielle Rewrites in 2.7 einflössen. Daß das ein bißchen mehr Arbeitsaufwand für die Entwickler bedeutet, steht natürlich außer Frage.
Nicht so relevant, aber da du es erwähntest: Ein freier Mikrokernel mit der Verbreitung von Linux und vergleichbarer Anzahl unterstützter Hardwarekopmponenten, wäre selbstverständlich noch viel besser.
Linus hat sehr deutlich erklärt, wieso er sich gegen einen stable und einen development tree entschieden hat. Mit dem alten Modell wurde mehrere Jahre am neuen Kernel gebaut, der Code an sehr vielen Stellen komplett geändert. Das betraf dann nicht nur ein Subsystem, sondern den gesamten Kernel. Da das ganze ein Entwickler-Kernel war, wurde der auch nur von sehr wenigen Leuten getestet. Am Ende, wenn man dann beschloss, dass die Arbeit fertig ist, und der Kernel als stable released wurde, traten dann die Fehler auf. Logisch, wenn der Code nur unzureichend getestet wurde. Mit dem neuen Modell, werden Änderungen wesentlich partieller vorgenommen. Man tauscht nicht mehr bei einem Release den halben Kernel aus. Das führt insgesamt zu einem deutlich umfangreicheren Testszenario bei weniger Veränderungen. Es bringt nichts, wenn hunderte von 2.7er Kerneln veröffentlicht werden, aber die nicht den notwendigen Tests unterzogen werden.
Nur weil er das so sieht, muß ich noch lange nicht mit ihm übereinstimmen. Die Anzahl der Regressionen, mit denen Distributoren wg. diese ach so tollen Modells beschäftigen müssen, nimmt nicht ab; Ganz im Gegenteil.
ja, klar. Mit 2.4 und dem 2.5 Entwicklerzweig war es ja sooo viel besser.
Dauernd mußten die Distributoren Treiber und anderes backporten, was einen enormen Aufwand bedeutet hat. Die Regressionen, die dabei entstanden könnten Bücher füllen. Und war 2.4 etwa stabiler?
Nein. Es gab ja mehr als einmal 'donotuse' releases von 2.4
Ich glaube hier ist der "Beweis" dafür das der Text im wesentlichen von einem Übersetzungsprogramm stammt, liest sich zumindest alles sehr holprig.
Falls es nichts anderes bedeutet, könnte man mit "Implementation" eins dieser blöden "ung"-Worte vermeiden, wie z.B. Kompression statt (würg) Komprimierung.
Falls es doch was anderes bedeutet, wäre eins von beiden eine ungeschickte Wortwahl...
Sobald es aber auch das deutsche Wort ""Implementation" gibt (durch Gebrauch) und von einer nicht unbedeutenden Anzahl Personen als Verweis auf den gleichen Begriff verwendet wird, trifft Deine Behauptung nicht mehr zu. Tut mir leid. Alles fließt.
Zunächst hat man einen Algorithmus, der implementiert wird (= ausprogrammiert). Diese *Tätigkeit* ist die Implementierung.
Die Implementation ist dann das fertige Teil, also das Programm.
"Implementation" klingt statisch, abgeschlossen.
Da steht explizit "Implementation entwickelt" - das hat auch mein Sprachverständnis irritiert. Es hört sich nicht ganz "richtig" an, auch wenn es wohl in Ordnung ist.
Da explizit von Entwicklung (also dem Prozess) die Rede ist, kann man wohl auch "Implementierung entwickelt" sagen.
Mal nebenbei ist das vielleicht einfach ganz generell etwas redundant und schlechtes Deutsch von "entwickelten Implementationen" zu reden, weil der Begriff der Implementation schon voraussetzt, dass etwas entwickelt wurde.
Der Schluß liegt nahe, dass der Verfasser des Artikels keine Preise für eloquentes Deutsch gewinnen wollte, sondern sich auf den Inhalt selbst konzentriert hat.
Und hier kommt er schon: Obgleich ich diese Entwicklung begrüße, mache ich mir natürlich Sorgen, welche Auswirkung die Veränderte Schnittstelle auf die Stabilität des Dateisystems haben wird... glücklicherweise hat man bei Linux immer die Wahl, welche Version man verwenden will.
Gruß, LX
> Linus es sicher nicht in den Kernel einfließen lassen.
Da wäre ich mir nicht so sicher
http://kerneltrap.org/node/8414
MfG Peschmä
Da kann ich nur beipflichten. Wenn's dann passiert ist, wird mit der Halbwahrheit "Fehler passieren halt.", abgewiegelt.
C ist halt nunmal die beste Sprache für relativ hardwarenahes Programmieren daran
änderst auch du nichts. Mysteriöserweise hat noch niemand ein größeres OS in irgendeiner "sicheren" Sprache geschrieben, das auch
im weiteren Gebrauch ist.
mfg Benjamin
Aber wenn du schon das C-Bashing beginnen moechtest: Die Anfuehrungszeichen kannst Du dir sparen, in fast jeder Sprache entwickelt es sich sicherer als in C.
änderst auch du nichts.
Aber auch C wird sehr wahrscheinlich irgendwann mal überholt sein.
Z.B. die enorm kurze Testphase, bevor man das nächste Release dem Nutzer zum Fraß vorwirft. Es wäre schön, wenn Linux 2.6 gepflegt würde und neue Features/partielle Rewrites in 2.7 einflössen. Daß das ein bißchen mehr Arbeitsaufwand für die Entwickler bedeutet, steht natürlich außer Frage.
Nicht so relevant, aber da du es erwähntest: Ein freier Mikrokernel mit der Verbreitung von Linux und vergleichbarer Anzahl unterstützter Hardwarekopmponenten, wäre selbstverständlich noch viel besser.
Mach einen Fork und bilde eine stabile Kernel Linie ;-)
Gruß
M.S.
Dauernd mußten die Distributoren Treiber und anderes backporten, was einen enormen Aufwand bedeutet hat. Die Regressionen, die dabei entstanden könnten Bücher füllen.
Und war 2.4 etwa stabiler?
Nein. Es gab ja mehr als einmal 'donotuse' releases von 2.4
Also bleibt mal alle schön auf dem Teppich, ok?