Siduction Forum
Siduction Forum => Free Speech => Topic started by: bluelupo on 2011/03/16, 12:15:12
-
@all: Warum entfernt slh aus seinen Kerneln das/die BKL, wenn die Mehrheit der Leute mit NVIDIA Karten damit nicht mehr arbeiten kann???
-
Hat es nicht kürzlich eine Umfrage gegeben, in der sich die Mehrheit für die Benutzung des proprietären Nvidia-Treiber ausgesprochen hat?
Also kaufe ich mir einen 12 Zylinder und mein freundlicher Tankstellenpächter entfernt daraus 8 Zündkerzen, weil er meint, das Auto sei so gut genug?
Soll ich meine Hardware nicht so betreiben wie es der Hersteller gedacht hat?
-
Hallo Leute
bitte macht einen neuen Thread auf um pro/contra nvidia ... bkl zu diskutieren!
-
@seagull: hab den Thread ab meinen Post geteilt
-
BKL kommt eh raus, und nvidia muss reagieren. es ist auch nicht so, dass die das nicht wüssten.
greetz
devil
-
devil, was heißt das? Kommt der BKL generell aus allen aktuellen Kernel raus?
-
Ich bin davon leider auch betroffen, den Treiber hab ich schon seit dem letzten Kernel vom Frickel, und jetzt bleib ich halt solange nvidia nicht reagiert beim .37 und fertig. Ich bin im Grunde auch nur *Nutzer* hab aber auch kein Problem damit mal was *rumzubasteln oder probieren* (wie es Manche nennen), und so wie devil schon gesagt hat wird nvidia reagieren müssen, denn schliesslich ist diese weit verbreitet.
Ich sehs locker :-) ... haja c'est la vie.
Gruss Tine
-
Recht so Spinne , der 38er Kernel ist nach meiner Erfahrung mit früheren Kernelreleases sowieso noch buggy. Meist erst mit dem sub .3 Release ist ein Kernel gesettled.
Wers nicht glaubt, schaue mal in die .1 .2 .3 Patches früherer Kernel, wieviele Schreibfehler, Verwechslungen ("<" statt ">"), etc dort ausgebügelt werden müssen.
Um den Kernel zu halten auch beim dist-upgrade, reicht es übrigens das Kernel Metapaket, was neue Kernelversionen reinzieht, zu deinstallieren.
-
Das Problem ist hier etwas anders.
Richtig ist, BKL ist Geschichte. NVIDIA benötigt BKL an sich auch nicht.
Geplant war, BKL aus Kernel 2.6.39 komplett zu entfernen, ob es dabei bleibt werden wir erst sehen, wenn das Mergewindow geschlossen wurde.
Richtig ist weiterhin, das Nvidia reagieren muß und sicherlich auch wird.
Wir reden hier aber über eine Änderung am Kernel, die es upstream noch gar nicht gibt, sondern egoman in den aptosid Kernel aufgenommen wurde.
Nvidia kann also gar nicht reagieren, solange diese Änderung nicht upstream erfolgt.
-
[...]
Wir reden hier aber über eine Änderung am Kernel, die es upstream noch gar nicht gibt, sondern egoman in den aptosid Kernel aufgenommen wurde.
Nvidia kann also gar nicht reagieren, solange diese Änderung nicht upstream erfolgt.
...genau das ist es was mich ärgert, warum wird diese Änderung im slh-Kernel so einfach mir-nichts-dir-nichts vorgezogen wenn's doch erst im 39er geplant war und somit die Zeit bis NVIDIA reagiert einfach nicht so lange ist. Dafür fehlt mir wirklich jedes Verständnis.
Ich habe nichts gegen "bahnbrechende" Änderungen im Kernel, aber dann in einer vernünftigen Art und Weise, so das man als Anwender die Möglichkeit sich darauf einzustellen.
-
Die fehlende Ankündigung ist auch für mich das wirklich ärgerliche und weckt den Verdacht nur als Manövriermasse oder Bauernopfer für dumm verkauft zu werden.
Ich habe kein Problem technische oder politsche Zusammmenhänge nachzuvollziehen, die Einschränkungen oder Kompromisse zur Folge haben aber ich möchte nicht ohne Ankündigung ins kalte Wasser gestoßen werden.
-
ich habe slh gestern abend mitgeteilt, dass das modul nun nicht mehr baut. er wusste es bis dahin nicht. von daher war eine ankündigung des teams nicht möglich. der einzige der es wusste, war towo, da er sowohl kernel als auch nvidia verfolgt.
greetz
devil
-
ich habe slh gestern abend mitgeteilt, dass das modul nun nicht mehr baut. er wusste es bis dahin nicht
So was kommt vor. Und nun? Wird 2.6.38.slh geändert?
-
Hi devil,
eigentlich sollte ein Kernelbauer solche wichtigen Dinge schon testen bevor sowas in die aktuelle Kernelversion einbaut wird. Das sind wirklich grundlegende Funktionalitäten die man einfach nicht so über den Haufen wirft. Ich finde es gut das du und towo auch Rückmeldungen ans offizielle aptosid-Team weitergebt und damit auch eine Weiterentwicklung möglich ist.
Trotzdem kann man so nicht die Nutzer einer Linuxdistribution vor vollendete Tatsachen stellen. Ein wenig mehr konservative Kernel-Entwicklung würde hier sicherlich der bessere und "schmerzfreiere" Weg sein.
-
bluelupo,
slh hat seit anbeginn von sidux nie einen hehl daraus gemacht, dass proprietäre treiber ihn nicht interessieren. er würde niemals selbst einen solchen bei sich installieren. wenn ihr euch erinnert: fglrx ging jahrelang nicht bei sidux.
greetz
devil
-
Hi
Ich denke nvidia wird schnell reagieren wenn der Patch upstream drin ist. Da sind die ja immer sehr schnell (in bereich von tagen/woche)
Mich würde intressieren wie ihr das bei ATI einschätzt. Die "updaten" (obwohl nicht alle bugs beseitigt werden/neuen hinzu kommen) den fglrx ja auch monatlich.
Meint ihr die werden wenigstens nach 1 monat reagieren und die header weg lassen ?
Und wie lange dauert es dann bis der neue fglrx als deb im debin sid ist?
Danke
-
Guten Abend in die Runde,
nette Diskussion hier...? Ich bitte, meine Anmerkungen als freie Meinungsäußerung zu verstehen. Alternativ möglich wäre ja noch, daß man weggebissen wird, wie es nach mir schon jemand anderem geschah. Ich bitte ausdrücklich diejenigen um Entschuldigung, die bisher nicht bissig und überheblich reagiert haben.
"@all: Warum entfernt slh aus seinen Kerneln das/die BKL, wenn die Mehrheit der Leute mit NVIDIA Karten damit nicht mehr arbeiten kann???
Soll ich meine Hardware nicht so betreiben wie es der Hersteller gedacht hat?"
Wie weiter unten zu lesen ist, kümmert ihn der Anwender herzlich wenig. "Wir machen das freieste System der Welt"- ganz egal, ob das noch für was Vernünftiges nutzbar wird oder nicht. Beispielweise arbeiten weder meine Grafikkarte noch mein Multifunktionsgerät mit irgendwelchem "freien" Treiberzeugs- und das trotz dutzendfacher Versuche- nein, auch nicht unter Mandriva oder openSUSE.
"BKL kommt eh raus, und nvidia muss reagieren. es ist auch nicht so, dass die das nicht wüssten."
Ob die reagieren "müssen", sei dahingestellt. Frag mal Redmond, ob die das ODF- Format statt ihrem Zeugs nutzen müssen.
"Um den Kernel zu halten auch beim dist-upgrade, reicht es übrigens das Kernel Metapaket, was neue Kernelversionen reinzieht, zu deinstallieren."
Klar, aber angeblich reagieren neue Kernel auch auf Sicherheitsmängel. Es gibt ja mittlerweile Alternativen zum aptosid- Standardkernel, aber...
"Wir reden hier aber über eine Änderung am Kernel, die es upstream noch gar nicht gibt, sondern egoman in den aptosid Kernel aufgenommen wurde.
Nvidia kann also gar nicht reagieren, solange diese Änderung nicht upstream erfolgt."
"...genau das ist es was mich ärgert, warum wird diese Änderung im slh-Kernel so einfach mir-nichts-dir-nichts vorgezogen wenn's doch erst im 39er geplant war und somit die Zeit bis NVIDIA reagiert einfach nicht so lange ist. Dafür fehlt mir wirklich jedes Verständnis."
"Ich habe nichts gegen "bahnbrechende" Änderungen im Kernel, aber dann in einer vernünftigen Art und Weise, so das man als Anwender die Möglichkeit sich darauf einzustellen."
"Trotzdem kann man so nicht die Nutzer einer Linuxdistribution vor vollendete Tatsachen stellen. Ein wenig mehr konservative Kernel-Entwicklung würde hier sicherlich der bessere und "schmerzfreiere" Weg sein."
Was interessiert gewisse absolute Sach- und Fachkenner schon der einfache Anwender? Wie es aussieht, ist aptosid auf dem besten Wege, sowas ähnliches wie Gentoo zu werden. 100 Mann wenden's an, 10.000 grausen sich davor...
"slh hat seit anbeginn von sidux nie einen hehl daraus gemacht, dass proprietäre treiber ihn nicht interessieren. er würde niemals selbst einen solchen bei sich installieren. wenn ihr euch erinnert: fglrx ging jahrelang nicht bei sidux."
Wenn dann z.B. sowas wie nouveau auch nach jahrelanger Entwicklungsarbeit nicht in der Lage ist, eine vernünftige Grafikauflösung mit einer nicht mehr topaktuellen Nvidiakarte nach Installation zu erzeugen- was tue ich damit? Freie Treiber sind eine gute Idee- aber funktionieren müssen sie schon.
Ich bin froh, daß ich vor weiterer Aktualsierung meines neuen aptosid (...!...) noch rechtzeitig bemerkt habe, daß schon wieder Mist beim DU passiert wäre. Das unangekündigte Zerschießen des nv hat ja schon gereicht.
Übrigens: "aptosid ist nichts für Dich" bzw. "Du taugst nicht für aptosid" hatten wir schonmal.
Gruß
Phoenix
-
Der technischen Seite kann ich nicht folgen, BKL und so...keine Ahnung.
Ich habe auch NVidia und bin froh, wenn ein Hardwarehersteller auch mal Linux unterstützt.
Klar, die Macher von aptosid geben den Ton an. Aber etwas mehr Nachsicht mit der Community, auch zu Lasten der Aktualität der Distribution, wäre schön. Finde ich.
-
Ich finde das ist ein NoGo. Das absichtliche Abschießen des NVIDIA-Treibers geht gar nicht. Eine Frage an die verantworlichen Aptosid-Entwickler: würdet ihr eine neue Aptosid-Version rausbringen mit einem Kernel, der ohne Not keinen NVIDIA-Treiber zulässt?
Niemanden würde es schaden, wenn dieser Patch erst mit dem nächsten oder übernächsten Kernel käme, wenn NVIDIA auch entsprechend reagiert hätte. Ohne Not einen Großteil der User abzuschießen kann ich nicht nachvollziehen.
-
Naja, towo und/oder andere Benutzer stellen ja einen Kernel ohne jene oder solche Patches zur Verfügung - in diesem Sinne also im Zweifelsfall einfach wo anders Tanken (um im Bilde zu bleiben). Und, der alte Kernel wird ja nicht entfernt - also wenn der neue nicht will dann eben erstmal weiter mit dem alten…
Es ist übrigens so, dass das Entfernen des BKL keine Erfindung der Neuzeit ist und unerwartet über NVIDIA hereingebrochen ist. Das ist schon lange bekannt und viel gewünscht.
Es hat desweiteren durchaus Nachteile diese Patches jetzt nicht zu aktivieren. Da sind zum einen die vielen vielen Nutzer die keine Nvidiakarte einsetzen. Warum sollten die auf den Fortschritt verzichten. Mich hat ja damals auch niemand gefragt als ein Rießenumbau bei Intel wechselnde Qualität hatte.
Wenn man von diesem Hickhack mal absieht, so ist das benutzen von zukünftigen Patches sehr wichtig für Upstream, da der frühzeitig darüber informiert werden kann wenn was nicht geht. Wenn jeder Warten würde bis nix es sich nicht mehr verhindern lässt, dann sind am Ende die Bugs denen wir jetzt in Vorabversionen begegnen in den als stabil gekennzeichneten Versionen. Das kann keiner wollen…
-
Ich werde vermutlich morgen mal 270.30 paketieren und selbigen so patchen, daß er gegen aptosid-kernel baut. Allerdings werde ich mich vorher mal in #nvidia mal rückversichern, ob es da unerwartete Nebenwirkungen geben könnte.
-
Ich finde das ist ein NoGo. Das absichtliche Abschießen des NVIDIA-Treibers geht gar nicht.
ich hab es jetzt schon ein paar mal gesagt, und sagr es nochmals: hier war nichts 'absichtlich', es war nicht mal bekannt und auch nicht unbedingt zu erwarten. es ist von anfang an (seit sidux start) so, dass weret darauf gelegt wird X/KDE nicht kaputtzumachen und freie treiber zu bevorzugen. hier jetzt absicht zu unterstellen ist schlicht nicht richtig. wir sollten aus einem proprietären treiber jetzt wirklich keine staatsaffäre machen. in japan schmelzen derweil die meiler.
greetz
devil
-
@towo, 270.30-beta ist dem xorg-server-1.9.x ohne Probleme laufbar unter Gentoo~unstable und openSUSE-11.4 nach eigener Erfahrung auf 64bit.
... es ging der 270.30-beta ja auch schon eine Nvidia-270.26-beta und eine 270.29-beta voraus...
-
Ich finde das ist ein NoGo. Das absichtliche Abschießen des NVIDIA-Treibers geht gar nicht. Eine Frage an die verantworlichen Aptosid-Entwickler: würdet ihr eine neue Aptosid-Version rausbringen mit einem Kernel, der ohne Not keinen NVIDIA-Treiber zulässt?
Niemanden würde es schaden, wenn dieser Patch erst mit dem nächsten oder übernächsten Kernel käme, wenn NVIDIA auch entsprechend reagiert hätte. Ohne Not einen Großteil der User abzuschießen kann ich nicht nachvollziehen.
Ich teile Gerds Ansicht bis auf das "absichtlich" auch einfach "nachlässig" "fehlerhaft" oder "ignorant" sein könnte.
Probleme mit der Graphikhardware erzeugen eh ein Grundrauschen im Forum und da erwarte ich etwas mehr Sensibilität und zuletzt auch Pragmatismus von der Verantwortlichen.
Das Hinterherflicken von towo (vor dem ich allen Respekt habe und der keine Scheu vor der Vokabel "egoman" hatte) ist für mich keine Option.
Vor einer Weile hab ich mich noch gewundert, das aptosid auf Distrowatch nicht mehr Resonanz findet im Vergleich z.b. zu archlinux. Jetzt verstehe ich es.
-
Ich verstehe die Aufregung nicht - das Thema war doch schon einmal auf dem Tisch mit fglrx. Ich glaube, ich hatte damals die WzT-Frage hier reingeworfen. Die Antworten der nichtbetroffenen nvidia-Benutzer klingen heute noch nach: Benutz freie Treiber!
Ich sehe es ein, dass es scheisse ist, wenn man von solchen Problemen auf einmal selbst betroffen ist, aber ein Grund zum Weinen ist das doch nicht wirklich. Wem der Kernel nicht passt, der nimmt halt den von towo. Meiner sollte auch mit nvidia laufen, da ich aber keine solche Hardware besitzt, kann ich das nicht testen.
Ich sehe auch kein allzugroßes Problem mit "egoman", was für fglrx recht ist, ist für nVidia billig. Prinzipiell ändert sich nichts, Alternativen sind verfügbar. Anders als der Rest der Pakete, die strikt debian folgen, ist der Kernel halt wirklich bleeding edge.
Ich hatte vor einiger Zeit die Frage gestellt, ob es nicht sinnvoll wäre, eine etwas hardwarefreundlichere Variante des Kernels in den Repositories zu haben - das wurde begründet durch die "Personalsituation" bei aptosid abschlägig beantwortet. Das ist verständlich. Die jetztige Situation ist doch aber genau das, was Linux auszeichnet: Die Quellen sind frei, und wenn ein Problem jemanden mit dem Wissen und dem Wollen so ankotzt, dass er es löst, ist allen geholfen.
Das sehe ich bei Towo mit nVidia genau so wie bei mir mit fglrx. Ich wäre froh, mich nicht darum kümmern zu müssen, funktioniert das mit den offiziellen Sachen, stirbt mein Zweig und ich bin noch glücklicher. Je mehr Input aber bei den Entwicklern ankommt, desto schneller werden diese Problemchen eventuell für die Allgemeinheit gelöst.
EDIT:
@seagull: Vor einer Weile hab ich mich noch gewundert, das aptosid auf Distrowatch nicht mehr Resonanz findet im Vergleich z.b. zu archlinux. Jetzt verstehe ich es.
Du solltest Arch in keiner Weise mit Aptosid vergleichen, die Ansätze sind zu verschieden. Im Prinzip würden die selben Disskussionen ablaufen wie hier, die aber eine radikal andere Wendung im spätestens 2. Posting hätten - Da würde dann so ungefähr steheh: Wir nehmen vanilla, soweit es irgend möglich ist, wenn es Euch nicht passt, dann ist das auch kein Problem, schraubt Euch das so hin, wie ihr es haben wollt.
Diese Diskussion wird es aber so nicht geben, da kein Mensch sich die Mühe macht, mehr als unbedingt notwendig an vanilla zu ändern. Wenn das minimalst gebrandet ohne Probleme durchs testing kommt, dann landet das Zeug halt im stabilen Zweig. Für irgendwelche privaten Befindlichkeiten ist dann das AUR da - ich weiss wirklich nicht, ob die Mehrheit hier sich mit dieser Philosophie anfreunden könnte.
-
@towo, 270.30-beta ist dem xorg-server-1.9.x ohne Probleme laufbar unter Gentoo~unstable und openSUSE-11.4 nach eigener Erfahrung auf 64bit.
... es ging der 270.30-beta ja auch schon eine Nvidia-270.26-beta und eine 270.29-beta voraus...
Ähm, ja und?
Was willst Du mir damit sagen?
Mal davon ab, 270.30 läuft auch mit Xserver 1.10 aber darum gehts gar nicht.
Ich will sehen, ob ein Entfernen von
#include linux/smp_lock.h aus nv-linux.h folgenlos bleibt. Da ich aber kein Programmierer bin, muß ich eben erstmal Jemanden fragen, des sowas weiss.
-
Das Hinterherflicken von towo (vor dem ich allen Respekt habe und der keine Scheu vor der Vokabel "egoman" hatte) ist für mich keine Option.
Meine Respekt hat towo auch, aber es kann nicht seine Aufgabe sein die offiziellen Kernel wieder gerade zu biegen.
-
Deshalb patche ich jetzt auch lieber die nvidia-kernel-source ;)
Allerdings habe ich mich entschieden, nicht den Beta Treiber zu nehmen, sondern 260.19.44, da selbiger heute nach sid kommt.
-
Ich verstehe die Aufregung nicht - das Thema war doch schon einmal auf dem Tisch mit fglrx. Ich glaube, ich hatte damals die WzT-Frage hier reingeworfen. Die Antworten der nichtbetroffenen nvidia-Benutzer klingen heute noch nach: Benutz freie Treiber!
[...]
Hi agaida,
Im Prinzip hast du Recht freie Treiber zu benutzen, wenn denn die Leistungsfähigkeit in etwa der propietären Treiber entsprechen würde. Das ist aber leider bei NVIDIA bei weitem nicht der Fall, also nicht wirklich eine Alternative. Das ganze Hick-Hack könnte man sich ersparen, wenn die Änderungen im Kernel (BKL) erst dann aktiviert werden wenn NVIDIA seine Treiber angepasst hat. Ich wehre mich dagegen, auch wenn ich Debian SID nutze, Versuchkaninchen zu sein wenn's nicht unbedingt nötig ist.
-
@devil: Hast recht mit dem absichtlich. Ich nehme es wieder zurück. Allerdings kommt Absicht ins Spiel, wenn dieser Patch mit den nächsten Kerneln nicht wieder rückgängig gemacht wird. Aber das ist im Moment Spekulation.
Auch finde ich es etwas komisch, dass hier immer auf andere Kernel von Towo u.a. verwiesen wird, denn es wird gleichzeitig betont, dass das dann nicht mehr Aptosid ist, es dafür also keinen offiziellen Support mehr gibt. Ist für den Nutzer nett, aber für das offizielle Aptosid kann das nicht gewollt sein.
@agaida Ich weiß nicht mehr wie das damals mit fglrx war, aber ich bin mir recht sicher, dass der Vergleich hinkt. Der BKL-Patch ist ja nicht dringend und bietet mW auch keine Vorteile, die die Nachteile aufwiegen.
-
Ohne jetzt zu sehr in dieser Wunde bohren zu wollen - meine erste Reaktion auf das Thema war ein belustigtes Lächeln, die zweite ein schallendes Lachen. Ohne die Kernelpolitk von aptosid währe ich nicht innerhalb der kurzen Zeit, die ich aptosid verwende, gezwungen gewesen, Kernelbauen á la aptisid zu lernen.
Jetzt triffts mal nVidia - nicht schön, aber es gibt Alternativen. Vielleicht ist das Problem jetzt spürbarer, da in jedweder Community immer auf ati rumgehauen wurde, aber sauber auf den proprietären Treiber von nVidia gesetzt wurde. Wenn das dazu führt, dass jetzt mal das dämliche ati-bashing aufhört, ist diese Aktion von slh doch mal was wert gewesen. ;)
Ich war damals angepisst wegen BKL, dass meine Hardware nicht mehr sauber unterstützt wurde, war mir eigentlich egal. Dass ich mir die Zeit nehmen musste, das für mich zu lösen, das hat weh getan, da war ich nicht glücklich drüber. Im Endeffekt, ich hab mir halt die 2 Tage Zeit genommen und mir gedacht: Es ist debian, verhalte ich mich auch so - it's done when it's done.
Das die Sache jetzt an towo hängt und er, um die Kernel-Frickelei zu vermeiden, versucht dem Treiber, besser gesagt, den Programmen rund um den Treiber Benehmen beizubringen, wird ihn auch nicht glücklicher machen. Es ist halt ein recht großer, meines Erachtens unnötiger Aufwand, der hauptsächlich politisch determiniert ist. Einen Sachzwang für den Mist gab es nicht.
Wenn das aber die Entwicklung insgesamt voranbringt, haben im Endeffekt alle gewonnen. Ganz ketzerisch würde ich mal folgendes vorschlagen: Um eine 2. Alternative zu haben, könnte ja mal jemand so frei sein, meinen Kernel gegen nVidia laufen zu lassen. Auch den Patch für Powertop könnte ich noch schmerzfrei in meinen Zweig integrieren, ein Patch mehr oder weniger interessiert mich da nicht wirklich doll. Da ich den Kernel so oder so mindesten wöchentlich baue, wäre das kein Mehraufwand.
Ist halt nur so eine Idee.
@Gerd: Ist noch nicht so lange her, da fand slh die Idee # config_bkl is not set statt config_bkl=y zu setzen, toll. Das war mit der Einführung des 2.6.37 - und die Geburtsstunde des linux-gcom-2.6. Einzige Änderung sind der Name und halt config_bkl=y. Was solls also, es war damals kein Problem, den proprietären ATI ohne Vorwarnung abzuklemmen, jetzt ist halt nVidia dran. Was solls und was kümmerts mich - ich bin Selbstversorger. Ich habe meine Probleme allein gelöst und werde sie auch weiterhin allein lösen. Das kostet weniger Kraft als der Kampf gegen Windmühlen. Auch wenn das jetzt sarkastisch ist - genau dass ist FOSS. Ich kann keinen davon abhalten, sein Ding zu machen, es kann keiner mich davon abhalten, mein Ding zu machen. Dass mit dem 2.6.38 noch der Aufwand dazugekommen ist, ausser einer Zeile Kernelkonfiguration noch einmal das Wort patch mit ein paar Optionen einzutippen, ist mir an der Stelle recht schnurz.
-
ist das nun das hohe Lied, dass sich jeder seinen Kernel gefälligst selbst bauen soll, damit er auch weiterhin seine Hardware so betreiben kann wie er es gewohnt war?
Konsequent ist es dann, dass aptosid keinen Kernel mehr bereitstellt und die User aufgefordert werden, sich selbst um ihre Belange zu kümmern. Das lässt sich am Ende sehr weit treiben.
Aptosid war für mich immer eine 'state of the art' Distribution. Ich fände es gut, wenn es so bliebe. Und vielleicht ist es gar nicht schädlich, wenn die User dazu auch noch zufrieden und sogar begeistert sind.
Wieviele Zeilen Text sind inzwischen wegen dieser Nvidia-Geschichte geschrieben worden. In dieser Zeit einen entsprechenden Kernel zu veröffentlichen, wäre nicht nur der Weg gewesen, hätte die Nutzer zufrieden gestellt und hätte gezeigt wie flexibel man sein kann.
Ich freue mich, dass towo die Initiative ergriffen hat.
-
So, ich habe nun Nvidia 260.19.44, welcher heute nach sid kommt, in einer gepatchten Version auf Frickel geladen.
Diese Version baut auch gegen den aktuellen aptosid-Kernel.
-
Offene Treiber verbessern sich nicht dadurch, dass sie nicht genutzt werden. Wenn keiner sie benutzt fehlt oft die Motivation seitens der Entwickler sie weiter als nötig auszubauen.
Es ist nunmal so, dass man als OpenSource Entwickler erstmal in seine eigene Kerbe schlägt. Was man selbst nicht braucht wird auch nicht zwangsweise gemacht. Sicherlich kann sich ein Anwender was wünschen und wenn der Entwickler dann Zeit hat und Nutzen darin sieht (meistens auch für sich), dann macht er das auch (Motivation und so).
Argumente wie "Vollkommen ohne Not", "Was du da machst ist Sche***", "Ich würde das so machen (hab aber keinen Bock)" und "Das sorgt nicht für einen Nutzeranstieg!" ziehen da einfach nicht, den man ist als Entwickler erstmal selbst der einzigste wichtige Anwender und wenn der dann Argumente (selbst wenn sie euch nicht gefallen) dagegen hat, dann macht er dass was für ihn am besten ist. Es mag seltsam sein, aber in der OpenSource Community ist der Kunde in den allerseltensten Fällen der König - den hier wird nicht produziert was man unbedingt verkaufen muss um zu überleben. Vielmehr macht man halt hobbymäßig ein bisschen was was man selber braucht. Wenns am Ende noch jemand anders nutzt, schön, toll, ja, sogar ein bisschen Stolz kann man dann sein, aber wenns kein anderer nutzt ists trotzdem gut, den einen Anwender hat man immer: sich selbst
(Dieser Anwender ist übrigens meist der schlimmste von allen ;) )
Wenn ich auf die Straße gehe und jedem den ich sehe 5€ in die Hand drücke, dann könnte mir jeder mit "ich will aber 10€"-Aussage den Buckel runterrutschen. Wer die 5€ nicht will muss sie ja nicht annehmen (Na, wenn das kein echtes 5 Sesterzenargument ist…). Verabschiedet euch also schnellstmöglich vom "ich will aber" denken, den meiner einer, wenn zu viele rummerken, würde irgendwann aufhören 5€ zu verteilen…
P.S.: "state of the art" ist also immer hinter dem aller Neusten hinterherzuhinken weil ein paar das Neuste nicht gefällt? Meine Definition war da irgendwie anders…
-
Allerdings kommt Absicht ins Spiel, wenn dieser Patch mit den nächsten Kerneln nicht wieder rückgängig gemacht wird. Aber das ist im Moment Spekulation.
der wird 100%ig nicht zurückgenommen.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4ba8216cd90560bc402f52076f64d8546e8aefcb
greetz
devil
-
Hi DonKult,
Offene Treiber verbessern sich nicht dadurch, dass sie nicht genutzt werden. Wenn keiner sie benutzt fehlt oft die Motivation seitens der Entwickler sie weiter als nötig auszubauen.
...da gebe ich dir Recht, aber wenn die Opensource-Treiber wie in diesem Fall mit NVIDIA einfach sehr weit dem propietären hinterher hinkt, wie soll ich das "normalen" Anwender klarmachen etwas einzusetzen das schlechter ist. Und diesen Zustand bei NVIDIA haben erst nicht seit gestern sondern eigentlich schon immer.
EDIT: Ich bin es Leid immer wieder auf die gleichen Probleme bei den Grafikkartenteibern zu stoßen. Letztes Jahr massive Probleme mit INTEL, heuer ATI und jetzt NVIDIA :-(
-
@agaida
Ein patch für powertop wär toll :-D
@all
Was mich an der Geschichte etwas stört ist, das ich darauf angewiesen bin das andere aptosid nutzer(towo,agaida) die politische Entscheidung eines einzelnen für viele anwender wieder rückgangig machen müssen damit sie ihre Hardware nutzen können wie das gedacht ist. Dies ist jetzt nicht vollständig gegen slh gerichtet, der mann kann machen was er für toll hällt. Was mich stört ist das ich jetzt von agaida abhängig bin. Wenn er von nem Bus überfahren wird (was hier nur hypothetische gemeint ist) gibts keinen Kernel mehr der für mich zu benutzen ist....
Also meine Lösung als Linuxnutzer (die eig für ihre neugier auf neues bekannt sind) Ich will selbst lernen das zu tun was agaida grade macht.
(siehe dazu meinen langen Thread im Experimentelles (kommt noch,grad nicht viel Zeit))
Wie wärs wenn sich die anwender die sich auf towo und agaida verlassen mal wieder was neues lernen um es irgendwann mal selbst in die hand zu nehmen wenn slh mal wider gegen die nutzer und nur für sich entscheidet?
Ich bin mir sicher das ich sehr viel Unterstützung bei meinem Vorhaben bekommen werde, also fühlt euch so frei und klinkt euch dann ein....
-
Hm...ich trau mich als (derzeit) nicht betroffener Intel-Nutzer ja kaum, hier was zu schreiben...zumal die Stimmung schon recht aufgeheizt zu sein scheint. Mich stört allerdings, dass die Diskussion hier etwas zu persönlich wird, sprich gegen slh gerichtet ist. Klar, ich kann verstehen, dass ihr verärgert seid, wenn die Nvidias nicht mehr richtig unterstützt werden. Ich kenne slh nicht, aber ich glaube auch kaum, dass er diese Änderungen in seinen Kernels in böser Absicht durchzieht. Letztendlich ist das, was er macht, nur konsequent. Es wird aber auch niemand gezwungen, diesem Weg zu folgen...es gibt doch Alternativen. Und wenn die halt voraussetzen, dass man selbst Hand anlegt, dann muss man das tun. Oder sich ein anderes System aussuchen...auch da gibts genug Auswahl. Ich kann mich daher der Meinung von DonKult nur anschließen...die Entwickler suchen sich ihren Weg, die Nutzer entscheiden, ob sie dem folgen wollen/können. Die offenbar schon recht hohe Erwartungshaltung gegenüber dem Team hinter der Distri finde ich in dieser Form nicht angebracht. Man vergisst glaube ich schnell, dass das alles auf freiwilliger Basis geschieht.
Wie gesagt, ich kann euren Ärger verstehen...aber ich würde es begrüßen, wenn das alles hier sachlich bleibt und sich nicht gegen eine einzelne Person richtet.
-
Nur als Klarstellung meinerseits: Der aptosid-kernel ist wunderbar aktuell und bisher das Beste, was ich in der Hand halten durfte. Dass ich einige Entscheidungen nicht unbedingt toll finde, ist mein Ding - ohne die Vorarbeit von slh hätten wir nicht den (meine Meinung) am besten gepflegten Kernel, den ich kenne. (Und auch nicht den Spass, darüber zu diskutieren, ob so aktuell wirklich sein muss).
Ich für meinen Teil nehme lieber den Kernel von slh und wenn ich es für mich als notwendig erachte, ändere ich minimale Kleinigkeiten, mit denen ich nicht wirklich einverstanden bin. Bei dem .38er Kernel aus sid hätte ich eher Bedenken, mir fürchterlich ins Knie zu schießen. Abgesehen von der Tatsache, dass es nicht wirklich notwendig ist, sofort hinter jeder kleinen Änderung hinterherzuhecheln, durch die Änderungen von Towo hat sich das nVidia-Problem wenn schon nicht gelöst, so doch verlagert. Irgendwo hier hatte ich auch einen Patch für ATI gesehen, den ich mir anschauen werde. Wenn das passt, wird John Bridgman angetriggert, wie es in Zukunft damit bei ATI aussieht. Genau das wäre der richtige Weg für die Zukunft.
Grade kam noch das Posting von ralv rein, dem ich nur zustimmen kann. Wir stehen nun mal mit aptosid evolutionär an der Spitze der debian-Welt, da kann es schon mal zu kleinen Unpässlichkeiten kommen. Das darf aber nicht gegen slh gehen. die Arbeit, die der Mann macht, ist wichtig und wertvoll. Lieber so und mit ein paar kurzfristigen Ärgernissen, als nur Streichelzoo und keine wirkliche Entwicklung. Ich muss auch bei einer Distribution nicht unbedingt alles aus einer Hand haben, einen Patch oder Haken ein oder auszupflegen ist doch kein Teufelswerk. Und der Grundtenor, dass die vom Kernel Abhängigen, also die Treiberhersteller (und auch die Community-Entwickler) dem Kernel zu folgen haben, ist richtig. Andersrum wäre eigentlich nur Stagnation die Folge und das will wirklich keiner. Und es gibt wirklich auch ohne Towo oder mich genügend Alternativen.
-
@ralv: ich stimme dir 100%ig zu! (und zwar als betroffener)
slh hat ne sehr klare linie, und das finde ich prinzipell schon mal gut. leute (insb. politiker, aktuell die liebe regierung) die ihr fähnchen immer nach der allgemeinen stimmungslage richten kann ich nicht ab. diese klare linie führt zu klaren entscheidungen, ohne kompromisse.
BKL ist tot, und slh hat entschieden, nicht zu warten. das killte virtualbox, flrgx und jetzt eben nvidia. pech für die user? sehe ich nicht so: zum einen haben wir dankenswerter weise hier towo und agaida, die das fachwissen haben und die mit der entscheidung nicht einverstanden sind, und eine alternative anbieten. wenn es ne alternative gibt, warum dann über slh motzen? und das das dann nicht mehr offizell supportet wird - glaubt ihr wirklich, dass towo seinen selbstgebauten kernel gar nicht supportet? grade wenns um softwareprobleme geht, die mit dem kernel nur peripher zu tun hat? ist ja nicht so das man dann gleich zum paria wird...
außerdem: das ist ein temporäres problem: irgendwann wird nvidia seinen treiber fixen, wer weder towos noch agaidas kernel (oder den vanillakernel, den gibts ja auch immernoch) haben will, setzt eben die kernel-metapakete auf hold und wartet bis sich das problem erledigt hat. aber hier so einen aufstand machen, nur weil andere nicht aus jux und dollerei ohne bezahlung eine maßgeschneiderte lösung für irgendjemanden basteln finde ich ziemlich undankbar!
-
Noch eine Korrektur - Ich bin mit der Linie einverstanden, weil sie richtig ist. Bei der praktischen Umsetzung muss ich leider passen: Nicht alles was richtig ist, ist zum Zeitpunkt der Entscheidung auch für jeden praktikabel. Da bin ich ganz klar Opportunist und stelle für mich Bedienbarkeit vor political correctness. Wenn der freie Treiber noch weiter aufholt oder aber ATI respektive vNidia reagiert, ist das Thema eh gegessen. So wie es ist, ist es auf jeden Fall besser als bei Ubuntu - da steht man in einem solchen Fall voll im Regen und das für mindestens 6 Monate.
-
und slh ist ja nicht alleine, Linus hat, wie ich oben schon verlinkte, nachgezogen:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4ba8216cd90560bc402f52076f64d8546e8aefcb
greetz
devil
-
Allerdings kommt Absicht ins Spiel, wenn dieser Patch mit den nächsten Kerneln nicht wieder rückgängig gemacht wird. Aber das ist im Moment Spekulation.
der wird 100%ig nicht zurückgenommen.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4ba8216cd90560bc402f52076f64d8546e8aefcb
greetz
devil
Ich meinte natürlich Kernel-Subversion, wenn das dann mit 2.6.29 oder 2.6.30 kommt, ist es doch auch ok.
Bis 2.6.29 sind es immerhin ca. 2 Monate. D.h. es könnte in der Zeit auch ein neues Aptosid-Release geben. Wäre nicht gerade gut, wenn da kein Nvidia-3D geht.
-
So, ich habe nun Nvidia 260.19.44, welcher heute nach sid kommt, in einer gepatchten Version auf Frickel geladen.
Diese Version baut auch gegen den aktuellen aptosid-Kernel.
Gebaut wurde er, es gba zumindest keine Fehlermeldung. Geladen wird er auch aber X mag ihn nicht. Im kern.log steht was von Version mismatch. Wenn ich denn den richtigen Treiber habe, am Paket stand nix von frickel. amd64. Nicht tragisch, meine i686 habe ich nicht angefasst - watt lüppt, datt lüppt. :wink:
-
@OppaErich
Hast du ach nvidia-glx 260.19.44 von towo installiert?
-
Nicht absichtlich...einfach D-U mit frickel drin aber nur non-free, also ohne den towo-Kernel. Ich muss gestehen, ich habe nicht auf X-Geschichten geachtet. Muss vielleicht noch nvidia-glx reinstall machen.
Ich bin hier jetzt eigentlich durch, ich geh dann mal spielen. :)
-
ihr seid im falschen teil des threads, in freie rede.
greetz
devil
-
Heute scheint Falschtag zu sein. Falsche Version, falscher IRC-Kanal, falsches Forum. :shock:
-
Hallo,
zunächst ist doch fest zu halten, und ich gehe doch sehr davon aus, dass Torsten hier kein Märchen erzählt:
Richtig ist, BKL ist Geschichte. NVIDIA benötigt BKL an sich auch nicht.
Geplant war, BKL aus Kernel 2.6.39 komplett zu entfernen, ob es dabei bleibt werden wir erst sehen, wenn das Mergewindow geschlossen wurde.
Richtig ist weiterhin, das Nvidia reagieren muß und sicherlich auch wird.
Wir reden hier aber über eine Änderung am Kernel, die es upstream noch gar nicht gibt, sondern egoman in den aptosid Kernel aufgenommen wurde.
Nvidia kann also gar nicht reagieren, solange diese Änderung nicht upstream erfolgt.
Da ich aber auch Ferdinand keine Märchen unterstelle, gehe ich davon aus, dass Stefan zwar absichtlich eine Änderung mit BKL am Kernel vorgenommen hat, aber nicht wusste, dass dann der NVidia Treiber nicht mehr baut.
Weiterhin haben wir mit dem Frickel Repo eine Alternative.
Aber dennoch bin ich hier mit einigen Kommentaren nicht einverstanden:
slh hat seit anbeginn von sidux nie einen hehl daraus gemacht, dass proprietäre treiber ihn nicht interessieren. er würde niemals selbst einen solchen bei sich installieren. wenn ihr euch erinnert: fglrx ging jahrelang nicht bei sidux.
Ferdinand, das ist richtig, aber wenn es um sidux Anwender mit höheren 3D Anforderungen ging, wurde schon auf sidux.com von Seiten des Teams von Ati/AMD abgeraten und fleißig für Nvidia geworben.
@BX13 schrieb: Klar, die Macher von aptosid geben den Ton an. Aber etwas mehr Nachsicht mit der Community, auch zu Lasten der Aktualität der Distribution, wäre schön. Finde ich.
Das findest Du meines Erachtens ganz richtig, aber wie Torsten schon schrieb:
Wir reden hier aber über eine Änderung am Kernel, die es upstream noch gar nicht gibt, sondern egoman in den aptosid Kernel aufgenommen wurde.
@DonKult, diese Aussage verstehe ich nicht:
Da sind zum einen die vielen vielen Nutzer die keine Nvidiakarte einsetzen. Warum sollten die auf den Fortschritt verzichten.
Worin liegt der Fortschritt, etwas zu entfernen, was noch nicht Upstream ist und was dazu führt, dass die vielen Nvidia Karten Nutzer bei vernünftigem 3D im Regen stehen. Haben denn Nutzer von Intel- und AMD-Karten durch das Entfernen Vorteile?
BKL ist tot, und slh hat entschieden, nicht zu warten. das killte virtualbox, flrgx und jetzt eben nvidia. pech für die user? sehe ich nicht so: zum einen haben wir dankenswerter weise hier towo und agaida, die das fachwissen haben und die mit der entscheidung nicht einverstanden sind, und eine alternative anbieten. wenn es ne alternative gibt, warum dann über slh motzen? und das das dann nicht mehr offizell supportet wird - glaubt ihr wirklich, dass towo seinen selbstgebauten kernel gar nicht supportet? grade wenns um softwareprobleme geht, die mit dem kernel nur peripher zu tun hat? ist ja nicht so das man dann gleich zum paria wird...
Oh ja, und wenn noch mehr Dinge rausfliegen, stellt demnächst noch ein weiterer Nutzer für Soundkarten mit proprietären Treibern ein eigenes Repo zur Verfügung, alle Verfechter von sauberen Upgradepfaden werden sich sicher sehr darüber freuen, noch weitere Fremdrepos aktivieren zu müssen. Damit möchte ich nichts gegen die Arbeit von Alf oder Torsten sagen.
außerdem: das ist ein temporäres problem: irgendwann wird nvidia seinen treiber fixen, wer weder towos noch agaidas kernel (oder den vanillakernel, den gibts ja auch immernoch) haben will, setzt eben die kernel-metapakete auf hold und wartet bis sich das problem erledigt hat. aber hier so einen aufstand machen, nur weil andere nicht aus jux und dollerei ohne bezahlung eine maßgeschneiderte lösung für irgendjemanden basteln finde ich ziemlich undankbar!
@cid-baba, ich habe aber keine Zeit für solche Sachen, um es mal ganz deutlich zu sagen. Ich bin ambitionierter Linux Nutzer, ich befasse mich gerne mit Linuxdistributionen und ihren Eigenheiten, aber bitteschön immer noch als Nutzer. Und für mich ist es sinnvoller, mit meiner Partnerin einen langen Spaziergang zu machen, als mich mit Unzulänglichkeiten in der EDV auseinander zu setzen. Und wenn nach einem Update dies und das nicht mehr geht, und zwar nicht, weil mal in Sid Pakete nicht zusammen passen, sondern weil etwas grundlegend an den Treibern und dem Kernel geändert wurde, und wenn ich dann im Hinterkopf habe, dass sidux und nun aptoasid als nutzerfreundliches Debian Sid Derivat konzipiert sein soll, dann passt da etwas nicht zusammen und meine Dankbarkeit hält sich dann in Grenzen.
Grade kam noch das Posting von ralv rein, dem ich nur zustimmen kann. Wir stehen nun mal mit aptosid evolutionär an der Spitze der debian-Welt, da kann es schon mal zu kleinen Unpässlichkeiten kommen. Das darf aber nicht gegen slh gehen. die Arbeit, die der Mann macht, ist wichtig und wertvoll. Lieber so und mit ein paar kurzfristigen Ärgernissen, als nur Streichelzoo und keine wirkliche Entwicklung. Ich muss auch bei einer Distribution nicht unbedingt alles aus einer Hand haben, einen Patch oder Haken ein oder auszupflegen ist doch kein Teufelswerk. Und der Grundtenor, dass die vom Kernel Abhängigen, also die Treiberhersteller (und auch die Community-Entwickler) dem Kernel zu folgen haben, ist richtig. Andersrum wäre eigentlich nur Stagnation die Folge und das will wirklich keiner. Und es gibt wirklich auch ohne Towo oder mich genügend Alternativen.
Alf, bitte präzisiere das "wir" mit "wir ambitionierten Entwickler". Denn die Zeit, in der ihr euch damit beschäftigt, habt ihr für anderes nicht. Wenn euch das gefällt, ist das für euch in Ordnung. Die meisten Nutzer auch von aptosid möchten mit ihrer Distribution arbeiten, und nicht ständig an ihrer Distribution. Und als solches wurde sidux und aptosid immer promoted. Wenn sich das ändern soll, dann sollte das auch ehrlich gesagt werden.
Kleine Unpässlichkeiten sind es für Fachleute, für Nutzer ist es ärgerlich. Und bei Kritik gleich zu kommen mit, es gibt doch Alterntiven, damit machen es sich Entwickler schön einfach. Und der Status Quo ist, auch wenn Linus nachziehen wird:
Nvidia kann also gar nicht reagieren, solange diese Änderung nicht upstream erfolgt.
Für mich als Nutzer bedeutet Stagnation übrigens, wenn ich mich mehr damit auseinander setzen muss, wie ich mein Werkzeug funktionstüchtig bekomme, als einfach mit dem Werkzeug zu arbeiten. Bitte versteh das nicht falsch: Bis zu einem bestimmten Maß lasse ich mir das gefallen, Linux ist eines meiner Hobbies und es macht mir auch Spaß, mal etwas hinzubiegen.
Das Verhältnis zwischen Entwicklern und der anwendenden Community ist sicherlich vielschichtig. Einige Anwender überspannen den Bogen bei Forderungen, andere sind einfach nur dankbar. Aber auch für Entwickler gilt doch: Einige möchten, dass eine große Anzahl an Anwendern gut mit ihrer Software klar kommt, andere machen einfach ihr Ding und stellen es zur Verfügung, und die Anwender haben damit einfach klar zu kommen.
Ich bemühe mich, beide Seiten zu sehen aber wenn ich merke, dass Entwickler möchten, dass ich bitteschön genau die gleiche Einstellung zum Computer haben soll, wie sie, und sonst nichts zu prinzen haben, dann werde ich pampig.
Viele Grüße,
Holger
-
@holger:
Grundsätzlich stimme ich mit Dir überein, 2 kleine Einschränkungen. Ich habe meine Meinung als reiner Anwender zum Thema BKL und aptosid wohl mehr als lautstark geäussert. Es ist mir auch wurst, wem ich damit auf die Füsse getreten habe. Feingefühl gehört nicht unbedingt zu meinen Stärken. Diese Meinung vertrete ich als reiner Anwender immer noch und die lautet: Muss dieser Mist wirklich sein?
Ich bin auch nicht Kernelentwickler, kenne aber die Werkzeuge gut genug, um für mich ärgerliche Zustände zu ändern. Die Motivationen eines Entwicklers hat ja DonKult hinreichend beschrieben. Glücklich bin ich mit der Zeit, die ich aufwenden muss, um einen neuen. für mich funktionierenden Kernel zu braten, auch nicht. Da dass aber grade noch ins Tagesgeschäft reinpasste und ich dadurch nur ein paar Pläne von mir umstellen musste, für mich kein Problem bis auf den Zeitpunkt. Wenn die Sachen, die ich mir eh (geplant eigentlich eher mittelfristig) anschauen wollte, dann auch wirklich laufen, macht ein angepasster Kernel einen Aufwand von ca. 20 min. Das kann ich verschmerzen. Der Weg dahin kostest aber die von Dir angesprochene Zeit und schmerzt wirklich sehr.
Zum Thema sid und aptosid: Ich habe aptosid eingentlich ausgewählt, weil aptosid für mich mehrere Vorteile hatte und immer mehr hat: aptosid ist debian, aptosid ist nicht das offizielle sid, aptosid ist so aktuell, wie es ein debian sein kann. Der Pflegeaufwand hält sich in sehr eng geteckten Grenzen, von kleinen Ausnahmen mal abgesehen :twisted:
Ganz klar: Wäre es möglich, einen oder mehrere Server auf Dauer auf der Basis von Arch stabil zu betreiben, wäre ich nicht bei debian, in welcher Form auch immer gelandet. Da ich aber nicht wahnsinnig genug bin, das bei mir und auch Kunden durchzuziehen, ist debian die beste Wahl. Ich meinte mit Alternativen also nicht ein anderes Linux, sondern allenfalls einen anderen Kernel. So wie Towo und ich den bauen, sehe ich da auch keinerlei Probleme darin, dass upgrade-Pfade gebrochen werden. Dem ist wirklich nicht so, aptosid-Kernel und meiner, teilweise sogar frickel koexistieren gar prächtig. Mit Towos Erfolgen ist es jetzt ja auch möglich, slhs Kernel mit nVidia zu betreiben.
Und auch wenn es nervt - Sid ist der debian-Entwicklungszweig. Das muss man sich immer wieder vor Augen führen. Wir als Aptosid-Benutzer sind also je nach Sichtweise in der (un)glücklichen Lage, die aktuelle Entwicklung voll mitzubekommen. Viele der Sachen, die bei debian jetzt anstehen, habe ich schon seit Monaten in Betrieb und verfolge die Entwicklung. Es ist davon auszugehen, dass die anstehende großen Änderungen recht schmerzfrei durchgehen werden. Ich denke da so an KDE - ganz ohne Reibungsverluste wird aber auch das nicht passieren. Je nach persönlicher Einstellung zum gelieben Linux ist aber zu befürchten, dass ich an dieser Stelle mit meiner Definition von "kleineren Probemen" völlig daneben liege und der Adrenalinspiegel bei einigen Usern doch bedenklich steigen könnte. ;)
Zum Thema stabil und Stagnation, nicht ganz ernstgemeint - Meine Signatur.
-
Holger,
Da ich aber auch Ferdinand keine Märchen unterstelle, gehe ich davon aus, dass Stefan zwar absichtlich eine Änderung mit BKL am Kernel vorgenommen hat, aber nicht wusste, dass dann der NVidia Treiber nicht mehr baut.
richtig, so war es.
und Linus hat mittlerweile nachgezogen, wie ich anderorten schon verlinkt habe.
ob das in 2.6.28-1 dann einfliesst oder erst in 2.6.29, bleibt abzuwarten, spielt im endefeekt auch keine rolle.
greetz
devil
-
http://www.nvnews.net/vbulletin/showthread.php?s=6a61e9d5c6bb32ad6928b6fc96362a9c&t=160714
War wohl "bit rot" in Nvidia-Source ! slh in dieser Beziehung rehabilitiert!
Asche auf mein Haupt.
-
Hm?
2.6.38-gitX ist linux-next, sprich 2.6.39, nix mit bit rot.
Im Normalfall werden keine solche Änderungen in einem Pointrelease einde stable Serie gemacht.
-
Hallo holgerw,
weil hier ja "freie Rede" angesagt ist, auch mal mein Senf dazu...
"Ferdinand, das ist richtig, aber wenn es um sidux Anwender mit höheren 3D Anforderungen ging, wurde schon auf sidux.com von Seiten des Teams von Ati/AMD abgeraten und fleißig für Nvidia geworben."
Selbst wenn anfangs alles mit irgendeiner Grafikkarte funktioniert hat, kommen zwischenzeitlich irgendwelche unangekündigten Basisänderungen, und plötzlich geht- nichts mehr. So wie bei mir mit 2 laufenden Systemen an einem Mainboard kann ich zumindest versuchen, Hilfe zu bekommen; 1- System- Rechner bieten da keinerlei Chancen, weil nichts mehr geht. Die Grafikkarte ist ein Basisteil, ohne das ich mir den Rechner sparen kann. Fair wäre zumindest, wenn solche Kardinaländerungen zur Diskussion gestellt würden, bevor das Kind in den Brunnen gefallen ist. Aber das ist wohl mal wieder der Satz mit X.
"Klar, die Macher von aptosid geben den Ton an. Aber etwas mehr Nachsicht mit der Community, auch zu Lasten der Aktualität der Distribution, wäre schön. Finde ich."
"Das findest Du meines Erachtens ganz richtig, aber wie Torsten schon schrieb:
Zitat:
Wir reden hier aber über eine Änderung am Kernel, die es upstream noch gar nicht gibt, sondern egoman in den aptosid Kernel aufgenommen wurde."
Und was macht der "einfache Anwender" jetzt? Hier die 6 oder 7 Threads mit vielleicht 100 Beiträgen zum Thema durchlesen, in Handbuch und Wiki suchen, von den aufgefundenen dutzenden Tipps einige probieren und ggfs. sein System weiter zerschießen??
"Da sind zum einen die vielen vielen Nutzer die keine Nvidiakarte einsetzen. Warum sollten die auf den Fortschritt verzichten."
"Worin liegt der Fortschritt, etwas zu entfernen, was noch nicht Upstream ist und was dazu führt, dass die vielen Nvidia Karten Nutzer bei vernünftigem 3D im Regen stehen. Haben denn Nutzer von Intel- und AMD-Karten durch das Entfernen Vorteile?"
Sicher, die reiben sich jetzt die Hände, daß sie keine NVidia haben... und morgen geht's andersrum. Tut mir leid, für solchen Mist fehlt auch mir jegliches Verständnis.
"BKL ist tot, und slh hat entschieden, nicht zu warten. das killte virtualbox, flrgx und jetzt eben nvidia. pech für die user? sehe ich nicht so: ...%"
"Oh ja, und wenn noch mehr Dinge rausfliegen, stellt demnächst noch ein weiterer Nutzer für Soundkarten mit proprietären Treibern ein eigenes Repo zur Verfügung, alle Verfechter von sauberen Upgradepfaden werden sich sicher sehr darüber freuen, noch weitere Fremdrepos aktivieren zu müssen. ..."
Ja, bei agaida kann ich mir ja noch den Einzeltreiber laden und installieren; was mache ich mit dem Frickelplatz? Keine Ahnung, was ich mir mit Öffnung dieses Repos alles antue. Mag ja sein, daß ich zu (...) bin, um mit sowas umzugehen; aber andere "einfache" Nutzer werden das gleiche Problem haben.
"außerdem: das ist ein temporäres problem: irgendwann wird nvidia seinen treiber fixen, wer weder towos noch agaidas kernel (oder den vanillakernel, den gibts ja auch immernoch) haben will, setzt eben die kernel-metapakete auf hold und wartet bis sich das problem erledigt hat. "
"... ich habe aber keine Zeit für solche Sachen, um es mal ganz deutlich zu sagen. Ich bin ambitionierter Linux Nutzer, ich befasse mich gerne mit Linuxdistributionen und ihren Eigenheiten, aber bitteschön immer noch als Nutzer. ... Und wenn nach einem Update dies und das nicht mehr geht, und zwar nicht, weil mal in Sid Pakete nicht zusammen passen, sondern weil etwas grundlegend an den Treibern und dem Kernel geändert wurde, und wenn ich dann im Hinterkopf habe, dass sidux und nun aptoasid als nutzerfreundliches Debian Sid Derivat konzipiert sein soll, dann passt da etwas nicht zusammen und meine Dankbarkeit hält sich dann in Grenzen."
Ich bin ja noch nicht so lange dabei, habe mit meiner angeblichen Dau- Fragerei aber wohl schon einigen Wirbel erzeugt; aber von der Fremdeinschätzung zu Anfang meiner Beschäftigung mit Sidux/ aptosid, daß die Debian- Abteilung stabil (trotz "unstable") und nutzerfreundlich sei, bin ich völlig abgekommen. Bastelfreundlich- ja absolut, aber für längere produktive Arbeit ohne absolutes Fachwissen völlig ungeeignet.
"... Ich muss auch bei einer Distribution nicht unbedingt alles aus einer Hand haben, einen Patch oder Haken ein oder auszupflegen ist doch kein Teufelswerk. Und der Grundtenor, dass die vom Kernel Abhängigen, also die Treiberhersteller (und auch die Community-Entwickler) dem Kernel zu folgen haben, ist richtig. Andersrum wäre eigentlich nur Stagnation die Folge und das will wirklich keiner. Und es gibt wirklich auch ohne Towo oder mich genügend Alternativen."
Sicher, nur wie findet man sich im dem Tohuwabohu noch zurecht? Ich hab beispielsweise jetzt mal wieder versucht, alle Tipps für die VirtualBox zu sortieren. Logisch und einfach ist da was anderes. Die Herstellerinfo sollte ja eigentlich das aktuellste und stimmigste bieten; aber schon die recht neue Anleitung von agaida im Wiki ist nicht mehr aktuell. Details dazu erspare ich mir hier.
"Die meisten Nutzer auch von aptosid möchten mit ihrer Distribution arbeiten, und nicht ständig an ihrer Distribution. Und als solches wurde sidux und aptosid immer promoted. Wenn sich das ändern soll, dann sollte das auch ehrlich gesagt werden."
Kann man zwischen den Zeilen lesen, ergibt sich zwangsläufig; aptosid ist bereits abgedriftet. Ich frage mich so manches mal: wozu brauchst du deinen Rechner wirklich? Ja klar, zunächst zum arbeiten, nicht zum basteln. Aber letzteres kann auch interessant sein, aber doch bitte nicht jeden Tag.
"Kleine Unpässlichkeiten sind es für Fachleute, für Nutzer ist es ärgerlich. Und bei Kritik gleich zu kommen mit, es gibt doch Alterntiven, damit machen es sich Entwickler schön einfach. Und der Status Quo ist, auch wenn Linus nachziehen wird:
"Nvidia kann also gar nicht reagieren, solange diese Änderung nicht upstream erfolgt."
"Für mich als Nutzer bedeutet Stagnation übrigens, wenn ich mich mehr damit auseinander setzen muss, wie ich mein Werkzeug funktionstüchtig bekomme, als einfach mit dem Werkzeug zu arbeiten. Bitte versteh das nicht falsch: Bis zu einem bestimmten Maß lasse ich mir das gefallen, Linux ist eines meiner Hobbies und es macht mir auch Spaß, mal etwas hinzubiegen."
Stagnation ist ja Stillstand; türmen sich die Hürden, sein System dauerhaft lauffähig zu erhalten, aber jeden Tag höher, ist das nichts anderes als Rückschritt. Um den Problemen zu entgehen, kann man Vorschläge machen, die nicht gehört oder sonstwie dämlich abgemeiert werden oder irgendwann einfach in den Topf von mehr als 100 Alternativen greifen.
"... Aber auch für Entwickler gilt doch: Einige möchten, dass eine große Anzahl an Anwendern gut mit ihrer Software klar kommt, andere machen einfach ihr Ding und stellen es zur Verfügung, und die Anwender haben damit einfach klar zu kommen.
... aber wenn ich merke, dass Entwickler möchten, dass ich bitteschön genau die gleiche Einstellung zum Computer haben soll, wie sie, und sonst nichts zu prinzen haben, dann werde ich pampig."
Aber das letztere lohnt sich nicht; da bekommt man nur Magengeschwüre. Irgendwie sind auch freie Entwickler Diensteanbieter; aber wie ich erkennen kann, gibt es auch hier genügend "Experten", die nicht um den Sinn des Wortes wissen. Wenn die nicht auf einen Bedarf eines Nutzers eingehen wollen, müssen sie es lassen, dürfen sich aber auch bei Angriffen nicht beleidigt fühlen.
Schönes Wochenende
Phoenix
-
@DonKult, diese Aussage verstehe ich nicht:
Da sind zum einen die vielen vielen Nutzer die keine Nvidiakarte einsetzen. Warum sollten die auf den Fortschritt verzichten.
Worin liegt der Fortschritt, etwas zu entfernen, was noch nicht Upstream ist und was dazu führt, dass die vielen Nvidia Karten Nutzer bei vernünftigem 3D im Regen stehen. Haben denn Nutzer von Intel- und AMD-Karten durch das Entfernen Vorteile?
Irgendeinen Vorteil wird es wohl haben, sonst hätte man sich wohl nicht die Arbeit gemacht ihn zu entfernen. ;) Für die "hochqualifizierten" Benchmarks sind Newsportale zuständig. Bisherige Realtime-Kernelfreunde sollte das jedenfalls freuen. Für mich persönlich, da mich Performance meist nur perifär interessiert, liegt der Vorteil größtenteils darin, dass slh nach oben berichten kann, dass alles auch ohne BKL funktioniert. Mal von binären Unfällen anderer abgesehen…
Und der Status Quo ist, auch wenn Linus nachziehen wird:
Nvidia kann also gar nicht reagieren, solange diese Änderung nicht upstream erfolgt.
Naja, der Commit entfernt die Option BKL - das ist seit langem geplant und hat selbst keine direkten Auswirkungen auf fremdcode - wenn ja wenn der damit zurecht kommt, dass die Option nicht aktiviert ist. Nvidia verlangte halt zu lange ein aktives…
"Bereiten sie sich bitte darauf vor das Haus zu räumen, ich werde es in ein paar Monaten abreisen!" Wenn ich dann bis 5 Minuten vor Sprengung warte - wobei die später kam als vorher angekündigt - dann bin ich selber Schuld…
Für mich als Nutzer bedeutet Stagnation übrigens, wenn ich mich mehr damit auseinander setzen muss, wie ich mein Werkzeug funktionstüchtig bekomme, als einfach mit dem Werkzeug zu arbeiten. Bitte versteh das nicht falsch: Bis zu einem bestimmten Maß lasse ich mir das gefallen, Linux ist eines meiner Hobbies und es macht mir auch Spaß, mal etwas hinzubiegen.
Es sei euch allen ungenommen statt diesem und viele andere Threads zu befeuen stattdessen ein wenig Wandern zu gehen. "Zur Not" auch mit der besseren Hälfte.
Aber eines sollte klar sein: aptosid ist keine Friede-Freude-Eierkuchen Distribution. Man muss schon damit rechnen, dass nach einem d-u mal was nicht geht - und das kann nun eben auch mal 3D für Nvidia sein - davon geht aber keinesfalls die Welt unter, niemand hat sich verschworen und die Bestechungszahlungen von ATI an slh halten sich auch in Grenzen. Die Lösung des Problems ist immerhin solange Nvidia nicht reagiert hat genau einen Tastendruck entfernt: Pfeiltaste nach unten - in Grub um einen alten Kernel auszuwählen… Also, wofür diese Aufregung? Vor allem weils ja jetzt auch tausendfach im Forum steht, dass es mit Nvidia Probleme gibt - der Anwender, der sich da jetzt nicht drum kümmern möchte lässt das upgrade eben mal für heute sein und geht stattdessen Powerwalken…
-
Phoenix,
Selbst wenn anfangs alles mit irgendeiner Grafikkarte funktioniert hat, kommen zwischenzeitlich irgendwelche unangekündigten Basisänderungen, und plötzlich geht- nichts mehr. So wie bei mir mit 2 laufenden Systemen an einem Mainboard kann ich zumindest versuchen, Hilfe zu bekommen; 1- System- Rechner bieten da keinerlei Chancen, weil nichts mehr geht. Die Grafikkarte ist ein Basisteil, ohne das ich mir den Rechner sparen kann. Fair wäre zumindest, wenn solche Kardinaländerungen zur Diskussion gestellt würden, bevor das Kind in den Brunnen gefallen ist. Aber das ist wohl mal wieder der Satz mit X.
Satz mit X?
es gibt auch sätze ohne X. will sagen, grafikkarten gehen immer, es sei denn sie sind kaputt.
es gab zeiten, da gabs kein bunt sondern nur den satz ohne X. es soll sogar leute geben, die damit arbeiten.
wie sich jetzt im endeeffekt rausstellte, war das ganze einfach im nvidia treiber in ein oder 2 zeilen zu fixen ohne den kernel auch nur anzuschauen.
Und was macht der "einfache Anwender" jetzt? Hier die 6 oder 7 Threads mit vielleicht 100 Beiträgen zum Thema durchlesen, in Handbuch und Wiki suchen, von den aufgefundenen dutzenden Tipps einige probieren und ggfs. sein System weiter zerschießen??
du trägst doch selber dazu bei, seitenweise die threads zu verlängern.
ich fand jetzt das geheule doch sehr übertrieben, unsachlich, z.t. beleidigend.
es wäre sinnvoller, sich auf die technischen aspekte zu konzentrieren, dann muss auch keiner in vielen threads nach lösungen suchen.
und ob jetzt deine obige frage eine rethorische war, oder ob du wirklich nicht weiterkommst (in bezug auf nvidia) weiss auch kein mensch.
Ja, bei agaida kann ich mir ja noch den Einzeltreiber laden und installieren; was mache ich mit dem Frickelplatz? Keine Ahnung, was ich mir mit Öffnung dieses Repos alles antue. Mag ja sein, daß ich zu (...) bin, um mit sowas umzugehen; aber andere "einfache" Nutzer werden das gleiche Problem haben.
dann sind diese user einfach falsch hier, tut mir leid.
Kann man zwischen den Zeilen lesen, ergibt sich zwangsläufig; aptosid ist bereits abgedriftet. Ich frage mich so manches mal: wozu brauchst du deinen Rechner wirklich? Ja klar, zunächst zum arbeiten, nicht zum basteln. Aber letzteres kann auch interessant sein, aber doch bitte nicht jeden Tag.
da muss ich leider wiedersprechen: nichts ist abgedriftet. aptosid verfolgt das gleiche ziel, was wir vor 4 jahren bei gründung von sidux formuliert haben.
vielleicht sagst du mir, was sich da geändert hat.
Irgendwie sind auch freie Entwickler Diensteanbieter; aber wie ich erkennen kann, gibt es auch hier genügend "Experten", die nicht um den Sinn des Wortes wissen. Wenn die nicht auf einen Bedarf eines Nutzers eingehen wollen, müssen sie es lassen, dürfen sich aber auch bei Angriffen nicht beleidigt fühlen.
anspruchsdenken, mit dem ich nicht konform gehen kann, sorry. wir haben nichts zu verkaufen, wir bieten kostenlos ein produkt und auch noch tag und nacht support dazu. keiner von uns muss irgendwas, erst recht nicht sich angreifen lassen.
* bäh, jetzt hab ich auch noch selbst überflüssigerweise die threads verlängert.
greetz
devil
-
Hallo David,
Irgendeinen Vorteil wird es wohl haben, sonst hätte man sich wohl nicht die Arbeit gemacht ihn zu entfernen. Wink Für die "hochqualifizierten" Benchmarks sind Newsportale zuständig.
Ein harter Fakt, dass ungefähr ein Drittel der Linuxanwender mit Nvidia dann kein 3D mehr hat gegen irgendwelche Vorteile, die es schon haben wird, sorry, aber da verliert meines Erachtens das irgendwie schon haben wird als Argument :-)
Naja, der Commit entfernt die Option BKL - das ist seit langem geplant und hat selbst keine direkten Auswirkungen auf fremdcode - wenn ja wenn der damit zurecht kommt, dass die Option nicht aktiviert ist. Nvidia verlangte halt zu lange ein aktives…
Ich glaube, Nvidia interessiert, was beim Status Quo upstream ist und nicht, was schon als "demnächst" mal noch in der Diskussionsphase ist.
Es sei euch allen ungenommen statt diesem und viele andere Threads zu befeuen stattdessen ein wenig Wandern zu gehen. "Zur Not" auch mit der besseren Hälfte.
David, hier im Forum zu diskutieren nenne ich Kommunikation und das ist für mich keine Zeitverschwendung, sollte allerdings gleich meine Frau ins Zimmer kommen und mit mir etwas unternehmen wollen, dann würde dies hier erst einmal zur Seite gelegt :-)
Und ich gehe doch schon davon aus, dass Du genau verstehst, wie ich das in meinem Kommentar mit dem Spazieren gehen gemeint habe, bitte reiße das nicht aus dem Kontext.
Ich habe klar gemacht, dass wir mit der Sachlage umgehen können, bei mir lief der Nvidia Bau mit Towos neuen Paketen hervorragend, aber ich habe auch klar gemacht, das ich mit einigen Äußerungen hier nicht einverstanden bin und das tue ich auch weiterhin.
Aber eines sollte klar sein: aptosid ist keine Friede-Freude-Eierkuchen Distribution. Man muss schon damit rechnen, dass nach einem d-u mal was nicht geht - und das kann nun eben auch mal 3D für Nvidia sein - davon geht aber keinesfalls die Welt unter, niemand hat sich verschworen und die Bestechungszahlungen von ATI an slh halten sich auch in Grenzen. Die Lösung des Problems ist immerhin solange Nvidia nicht reagiert hat genau einen Tastendruck entfernt: Pfeiltaste nach unten - in Grub um einen alten Kernel auszuwählen… Also, wofür diese Aufregung?
Erstens habe ich zwischen Reibereien durch die Paketsituation in Sid und dem Entfernen grundlegender Funktionen deutlich unterschieden.
Und zweitens habe ich doch geschrieben, dass ich hier mit einigen Aussagen nicht einverstanden bin, die Sache ist zu lösen, für mich zumindest, ob für einen aptosid Anfänger, kann ich schwer beurteilen.
Viele Grüße,
Holger
-
Phoenix,
Bei allem Respekt...aber du schießt weit über das Ziel hinaus. Eine Äußerung wie:
Aber das letztere lohnt sich nicht; da bekommt man nur Magengeschwüre. Irgendwie sind auch freie Entwickler Diensteanbieter; aber wie ich erkennen kann, gibt es auch hier genügend "Experten", die nicht um den Sinn des Wortes wissen. Wenn die nicht auf einen Bedarf eines Nutzers eingehen wollen, müssen sie es lassen, dürfen sich aber auch bei Angriffen nicht beleidigt fühlen.
kannst du vielleicht gegenüber einem bezahlten Entwicklerteam bringen, aber nicht gegenüber Freiwilligen! Und Angriffen "muss" sich hier schon mal gar keiner aussetzen...man darf sich dann also auch durchaus beleidigt fühlen. Was du ja offenbar auch tust. Denn dein ganzer Text ist purer Frust und, in meinen Augen, Nachtreten.
Agaida machte es nochmal deutlich: aptosid beruht auf dem Entwicklerzweig für Debian. Wer sich das und die damit möglicherweise verbundenen Unannehmlichkeiten nicht bewusst machen kann/will, der sollte ernsthaft den Wechsel zu einer anderen Distri erwägen. Und dabei geht es gar nicht darum, hier einen elitären Kreis zu bilden. Es gibt doch für nahezu jede Benutzergruppe abgestimmte Distris. Und wenn ich mich für eine entscheide, dann erkenne ich damit auch den Weg an, den ihre Macher verfolgen. Wenn ich damit nicht mehr einverstanden bin, muss ich halt wechseln. Wie gesagt, es gibt genug Auswahl...
Wenn Du sowas wie Basisdemokratie bei der Entwicklung einer Distri haben möchtest, dann würde ich gerne mal sehen, wie schnell sich die wohl weiterentwickelt (siehe die Threads hier...)
-
Und wenn ich mich für eine entscheide, dann erkenne ich damit auch den Weg an, den ihre Macher verfolgen. Wenn ich damit nicht mehr einverstanden bin, muss ich halt wechseln. Wie gesagt, es gibt genug Auswahl...
eben, ich erkenne den generellen weg an, der beschritten wird. einzelentscheidungen wird immer jemand bemäkeln und das ist auch gut so. das hat aber nichts mit der form der hier stattgefundenen diskussion in ihrer breite und emotionalität zu tun.
greetz
devil
-
Irgendwie sind auch freie Entwickler Diensteanbieter [...]wenn die nicht auf einen Bedarf eines Nutzers eingehen wollen, müssen sie es lassen
Da gibt's eine Gerichtsentscheidung in Deutschland? Wenn ja, dann würde ich sofort meine namentlich gezeichneten Übersetzungen des Handbuchs von deutschen Servern nehmen wollen.
Aber ich denke, da wurde nur fantasiert. Also bleiben sie.
hubi
-
Hallo @Phoenix,
trotz Deines Frustes bin ich auch mit einigen Deiner Äußerungen nicht d'accord:
Bastelfreundlich- ja absolut, aber für längere produktive Arbeit ohne absolutes Fachwissen völlig ungeeignet.
Ich maße mir nun gar nicht an, solch ein extremes Fachwissen zu haben, aber ich komme mit Aptosid eigentlich gut klar :-)
Aber das letztere lohnt sich nicht; da bekommt man nur Magengeschwüre.
Ich finde schon, dass Kritik gut ist, @Bluelupo hat doch gerade mit diesem Thread eine Diskussion begonnen, und die soll doch auch kritisch sein. Und hier sind doch schon einige Missverständnisse ausgeräumt worden.
Irgendwie sind auch freie Entwickler Diensteanbieter
Das sehe ich anders. Ein Dienstanbieter leistet gegen Bezahlung eine mit einem Anspruchnehmer ausgehandelte Leistung. Weder Debian, openSUSE noch aptosid bieten solche Dienste an. Wenn Du im Rahmen von freier Software Dienstleistungen in Anspruch nehmen willst, kannst Du etwa an Novell herantreten, aber ich bin ziemlich sicher, dass das sehr teuer wird :-)
Hallo @ralv,
Und wenn ich mich für eine entscheide, dann erkenne ich damit auch den Weg an, den ihre Macher verfolgen. Wenn ich damit nicht mehr einverstanden bin, muss ich halt wechseln. Wie gesagt, es gibt genug Auswahl...
Wenn Du sowas wie Basisdemokratie bei der Entwicklung einer Distri haben möchtest, dann würde ich gerne mal sehen, wie schnell sich die wohl weiterentwickelt (siehe die Threads hier...)
Du hast recht, aber eine Distribution beinhaltet auch immer den Bezug zu einer anwendenden Gemeinschaft. Und ich unterscheide zwischen der Entwicklung von Software wie Kernel, KDE, Gnome und der einer Distribution. Was heißt denn Distribution? Das heißt doch, eine für Anwender vernünftig nutzbar zusammengestellte Softwaresammlung zur Verfügung zu stellen. Und als Distributor muss sich ein Team dadurch weitaus mehr Bedürfnissen von Anwendern stellen als etwa Linus bei seinen Entscheidungen zum Kernel.
Natürlich hat Aptosid eine andere Zielgruppe als Mandriva, aber auch das Team hier möchte uns sicherlich eine einfach zu installierende und zu handhabende Distribution anbieten.
Viele Grüße,
Holger
-
zitiert aus: http://aptosidusers.de/index.php?module=news&func=display&sid=5
Haftungsausschluss:
Dies ist experimentelle Software. Benutzung geschieht auf eigenes Risiko. Das aptosid-Projekt, seine Entwickler und Teammitglieder können unter keinen Umständen haftbar gemacht werden für Schäden an Hard- oder Software, Datenverlust oder anderen, direkten oder indirekten Schäden, entstanden durch die Benutzung dieser Software. Sollten Sie mit diesen Bedingungen nicht einverstanden sein, so ist es Ihnen nicht gestattet, diese Software weiter zu benutzen oder zu verteilen.
-
...Irgendwie sind auch freie Entwickler Diensteanbieter
Das sehe ich anders....
Viele Grüße,
Holger
Hi Holger,
da schließe ich mich an! Die Entwickler sollten sich lediglich an die von Ihnen formulierte Strategie halten, weil damit für die Anwender eine gewisse Planbarkeit und Verläßlichkeit steht oder fällt.
Meines Erachtens sind dies:
1.) das im Willkommens-Intro im Manual formulierte Kapitel (Auszug):
aptosid ist ein Betriebssystem, das auf dem Linux-Kernel und dem GNU-Projekt basiert. Dazu kommen Anwendungsprogramme von Debian. aptosid ist den Grundwerten des Gesellschaftsvertrags von Debian verpflichtet.
...
Angemerkt sei: da aptosid den "unstable" Zweig von Debian (Sid) nutzt, soll man sich mit der Verwendung eines Terminal vertraut machen.
Wenn man dem "aptosid-Weg" folgt, wird man immer das beste haben, was aptosid gemeinsam mit Debian sid anzubieten hat.
2.) Im wesentlichen Punkt 4 und 5 des oben angezogenen Gesellschaftsvertrages
http://www.debian.org/social_contract.de.html
Sicher läßt das Ganze noch Interpretationsspielräume. Den Freiheitsgrad innerhalb dieser selbstbestimmend zu definieren und zu agieren, ist sicher den Entwicklern zu überlassen, da diese ja schließlich auch die Arbeit haben und machen.
-
Die Strategie klappt doch. Aptosid ist stabil, schick, schnell und eigentlich rundum zum Wohlfühlen. Da ist nur diese Kleinigkeit mit dem Namen. Diese Herkunft kann und soll aptosid nicht verleugnen. Ich kenne da eine etwas größere Distribution, die in einigen Sachen auch auf Sid aufbaut. Die verleugnen diese Herkunft, gehen zum Teil noch über den Rahmen des experimentellen hinaus und nennen sich einsteigerfreundlich. Lauter zufriedene Nutzer bekunden jeden Tag ihre Freude über diese Distri. Und das weltweit.
Ich hab mal 2 Tage lang alle Mail an uu.de auch auf mich umgelenkt. Die meistbenutzten Worte waren Hilfe und "geht nicht" in den verschiedensten Graden der Verzweiflung. Und das alles ohne Alternativen innerhalb der Distribution. Da haben wir doch ein echtes Luxusproblem.
Und auch wenn mein aptosid grad ein wenig schwächelt, da war ich dran schuld, dass kann ich aber auch selbst wieder reparieren.
-
das wäre doch jetzt eigentlich ein nettes schlusswort für diesen thread und das thema?
greetz
devil
-
das wäre doch jetzt eigentlich ein nettes schlusswort für diesen thread und das thema?
greetz
devil
Hallo Ferdinand,
dem schließe ich mich doch an :-)
Viele Grüße,
Holger
-
mehr als einiges scheint ja gesagt zu sein!