|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
Von Anonymer Feigling am Wednesday 19. January 2005, 22:59 MEW (#1)
|
|
|
|
|
Denn erst dann können sie auch gefixt werden.
Und es ist besser sie jetzt zu finden als später, wenn jeder 2. Linux nutzt (auch DAUs). Denn erst weit verbreitete Betriebssysteme lohnen sich für die meisten anzugreifen.
Ausserdem wird bei OSS wenigstens nichts totgeschwiegen. Und es tut sich was in Sachen Sicherheit.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich persönlich wäre für eine Mischung zwischen dem jetztigen Modell und dem alten: Neue Minor-Versionen ca. jedes Jahr oder sogar noch öfter, gerade == stable. Wenn dieser Prozess beschleunigt wird, fällt auch das Problem weg, dass neue Features, um "zu den Leuten" zu kommen, in den aktuellen Stable-Branch müssen. Oh, und ein konsistentes Treiber-interface (auch binär) wäre natürlich auch schön. Jedenfalls während der gleichen Major-Version. Nu ja, wünschen darf man ja.. aber haben's nicht andere OSS-Projekte (vor allem KDE, GNOME, ...) ähnlich?
tL
--
... I don't like it, but I guess things happen that way ... (J. Cash)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Oh, und ein konsistentes Treiber-interface (auch binär) wäre natürlich auch schön.
Sind die Probleme mit ATI und NVidia-Treibern nicht schon schlimm genug? Willst du das in Zukunft auch für andere Hardware? Ich kann darauf wirklich verzichten.
|
|
|
|
|
|
|
|
|
|
|
|
|
Und ich bleib dabei, mir isses egal ob binary-only oder open source (nach welcher definition auch immer). Hauptsache, es laeuft und laeuft gut. Kann mich auch weiterhin _nicht_ ueber nvidia treiber beschweren.
|
|
|
|
|
|
|
|
|
|
|
|
|
Es ist ja keiner gezwungen, diese Treiber zu nutzen. Aber ein bisschen nett dürfte man zu den Binary-Treiber-Herstellern doch schon sein. Lieber ein Binary-only-Treiber als gar keiner!
tL
--
... I don't like it, but I guess things happen that way ... (J. Cash)
|
|
|
|
|
|
|
|
|
|
|
|
|
Irrtum! Mit einem Interface für Binärtreiber animiert man gerade zu die Hersteller neue Produkte nur noch mit binärtreibern auszuliefern, oder wie war das damals als xfree ein solches Interface baute?
|
|
|
|
|
|
|
|
|
|
|
|
|
Gute Frage, wie war das damals? Ich bin wohl zu jung. Gabs dann plötzlich Treiber für XFree, die binary-only waren?
IMHO gibts bis jetzt immer noch sehr wenige Firmen, die Source- oder Halbsourcetreiber oder wenigstens Gerätespecs anbieten. Ich ändere deinen Satz mal ab:
"Ohne Interface für Binärtreiber animiert man geradezu die Hersteller, neue Produkte nur noch mit Treibern für eine Plattform mit einem solchen Interface auszuliefern."
Versteh mich nicht falsch - ich bin absolut für möglichst viel OSS - auch und vor allem bei Treibern. Für viele soll Linux aber wohl eine Plattform für OSS-Fanatiker bleiben - "CSS ist vom Teufel! Wir müssen alle, die unsere geheiligte Plattform nutzen wollen, dazu bringen, auch OSS zu produzieren." So nen Scheiss. Oder wieso wollte Stallman nicht, dass sich der GCC an die C++-Specs von LSB2.0 halten muss? Genau: Es könnte proprietärer Software ein Nutzen sein.
Aber ich komme vom Thema ab...
tL
--
... I don't like it, but I guess things happen that way ... (J. Cash)
|
|
|
|
|
|
|
|
|
|
|
|
|
>Oder wieso wollte Stallman nicht, dass sich der
>GCC an die C++-Specs von LSB2.0 halten muss?
Moooooooooooooooooooooooooooooooooooooooment!
LSB != GNU
GCC ist Teil des GNU-Projektes.
Weiterhin, ohne Kommentar: LSB ist doof,
http://thread.gmane.org/gmane.comp.gcc.devel/52007
http://article.gmane.org/gmane.comp.gcc.devel/52016
http://article.gmane.org/gmane.comp.gcc.devel/52088
Es gab noch andere Mails, wo der LSB spezifisch
abgeraten wurde, auf eine nichtexistente "v5" ABI
zu dependen, aber die sind expired.
Ich bin BSDler, ich darf das!
06.03.2005 00:24 UTC
#1 der Hall of Fame:
2⁷ Kommentare
|
|
|
|
|
|
|
|
|
|
|
|
|
Alle machen Fehler.. Ich weiss, dass GCC Teil von GNU ist, und GNU != Linux && GNU != LSB.
Grundsätzlich kann ich aber bei meiner Aussage bleiben: "Wir wollen GCC unabhängig von LSB weiterentwickeln, so dass wir Features reintun können, die zu LSB inkompatibel wären. Dies kommt dem Benutzer zugute". Stimmt ja eigentlich, aber eben: Es gibt auch Leute, die ihre SW nicht im Source vertreiben wollen. Wenn jetzt da die Schnittstelle ändert - bö, Pech gehabt!
Kann aber ehrlich gesagt auch sein, dass ich das ganze etwas falsch interpretiert hatte, da ich nicht wirklich die Zeit dazu fand, der kompletten Diskussion zu folgen.
tL
--
... I don't like it, but I guess things happen that way ... (J. Cash)
|
|
|
|
|
|
|
|
|
|
|
|
|
Nein, das war eher so:
LSB: "Hallo GCC, wir wollen demnächst LSB 2.0 mit
demunddem C++ herausbringen, was haltet ihr
davon?"
GCC: "Hey Leute, erstens gibts diese ABI gar nicht
und zweitens ist die fehlerhaft und in gcc
3.4 ff. gefixt"
RMS: "Ruhe da, ihr dürft kein offizielles Statement
abgeben!"
LSB: "Ok, wir machen das so, WEIL ja kein Vendor
bereit ist außer einem, gcc 3.4 zu shippen"
Cox: "Leute, warum macht ihr das? Unsinn."
GCC: "Wir dürfen euch ja offiziell nix sagen, aber
als Privatperson rate ich euch davon ab."
* LSB bringt LSB 2.0 raus, weil Deadline für
Submission zur ISO nah ist und die Vendors
nicht nachgeben
Ich bin BSDler, ich darf das!
06.03.2005 00:24 UTC
#1 der Hall of Fame:
2⁷ Kommentare
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich hingegen halte den Ansatz "release early,
release often" nur gut für ein pre-2.2 Linux,
als es noch eine Randerscheinung war und eine
rapide Entwicklung benötigte.
Ausgereifte Systeme wie das mehr als doppelt
so alte BSD hingegen schmeißen nicht alle 2
Tage eine neue Version hin (ok, ist auch mehr
Source als nur ein Kernel), bringen (außer
FreeBSD™ *g*) neue Features nur in -current
ein, während -stable nur bei Sicherheitspro-
blemen aktualisiert wird.
Weitere Projekte wie gcc entwickeln neue
Features erst in vendor branches (tree-ssa
zum Beispiel), die erst dann in HEAD inte-
griert werden, wenn sie halbwegs laufen, und
dort dann auch sehr lange getestet werden.
*UND* keine Regression verursachen.
(FreeBSD™ hat den neuen IDE-Treiber von 5.x
nach 4.x backportet, mit dem Ergebnis, daß
viele Server nicht mehr von 4.7 wegkommen.
In 5.x committen Leute nur neuen Müll wie
GEOM und so, um ihr Ego zu befriedigen. Die
Entwickler nennen es jetzt 5-STABLE in der
Hoffnung, daß es auf irgendeine magische Art
und Weise von alleine stabil wird. Kurzum,
DragonFly hat auf lange Sicht die Nase vorne;
ich vermisse sie aber auf Messen und so.)
Ich bin BSDler, ich darf das!
06.03.2005 00:24 UTC
#1 der Hall of Fame:
2⁷ Kommentare
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 20. January 2005, 12:42 MEW (#7)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Naja ... wenn es schon so genau sein soll, dann bitte irgendetwas wie:
"Es ist in der Praxis unmöglich, komplexe Programme, wie etwa einen Linux-Kernel, auf Korrektheit gegenüber einer Spezifikation zu überprüfen (Verifikation). Ausserdem ist es unmöglich festzustellen, ob eine Spezifikation vollständig ist (Validation)."
Wenn man beides zusammennimmt, dann ist der Satz "Per Definition gibt es ja keine fehlerfreie Software" eigentlich schon recht angemessen.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 21. January 2005, 02:52 MEW (#13)
|
|
|
|
|
"Es ist in der Praxis unmöglich, komplexe Programme, wie etwa einen Linux-Kernel, auf Korrektheit gegenüber einer Spezifikation zu überprüfen (Verifikation). Ausserdem ist es unmöglich festzustellen, ob eine Spezifikation vollständig ist (Validation)."
Du verwendest hier den Begriff Validation falsch (Validation bezieht sich auf die spezifizierten Anforderungen). Der Rest oben stimmt.
Software kann durchaus fehlerfrei sein, denn ein Defekt muss nicht zwingend zu einem Fehler führen und "Fehler" bezieht sich auf die spezifizierten Anforderungen (bekannt, da spezifiziert). Deshalb ist die Aussage "Per Definition gibt es ja keine fehlerfreie Software" falsch.
Die Terminologie ist allerdings entscheidend. Wenn man "Fehler" umgangssprachlich versteht (statt gemäss der Terminologie des Software-Qualitätsmanagements), sieht es anders aus. Das würde aber wieder schlecht zu "Per Definition" passen, welches eine klare Terminologie impliziert.
|
|
|
|
|
|
