Re: (OT) Re: Intel T5470 in HP 6820s taktet nicht runter?

Hallo,

Vor allem, dass auf einem gewissen Samsung-Notebook der
Linux-Kernel überhaupt nicht bootet.

Ja, auch das sagt viel aus. Man kan sich aber geflissentlich darüber
streiten, über *was*. Ich behaupte, das sagt sehr viel über Linux aus,
und seine immernoch masiven Probleme, Hardware vernünftig zu
unterstützen.

Auf Standardhardware funktioniert es und die gröbsten Kinderkrankheiten
sollten aus Linux raus sein (siehe LinuxBIOS etc.) Das Fragezeichen sind
imho die Chipsätze und deren Initialisierung, weil die nicht bekannt ist. Wo
wir wieder beim BIOS wären, was eigentlich schon seit Jahren garnicht mehr
existieren dürfte. Und bei Software.

Soetwas hätte man zur Zeit des Notebook-Designs feststellen können, hat
man
aber nicht.

Es kann aber auch sein, *das* man es festgestellt hat, es ein Bug in
Linux ist/war, und man keine Lust hatte einen Workaround dafür zu
produzieren, richtig?

Würden die Hersteller es etwas ernster nehmen, so hätten sie wenigstens
einen Bugreport eingestellt. Aber man wartet auf die engagierten Nutzer.

Zudem: Kaum ein Gerät ist offiziell für Linux zertifiziert, noch gibt es
Linux-Treiber dafür.
Ja, genau. Und was sagt uns das?

Dass entweder das Treibermodell von Linux besch*** ist (was ich nicht
glaube, siehe die vielen vorhandenen Treiber), dass die Lizenzpolitik der
Linuxtreiber besch*** ist (was ich nicht finde, aber das ist
Betrachtungssache) oder dass die Hersteller die Informationen zu den Geräten
nicht rausrücken wollen (was ich persönlich am wahrscheinlichsten finde).

Ich habe da vor kurzem was *sehr*
orginelles gefunden:
http://www.linux.com/articles/30873
Das sagt eigentlich alles as zum Thema Linux und Realität.

Interessant ist es wirklich. Ich wusste nicht, dass es solche Prognosen
gibt/gab.

Andererseits kann man jede Statistik so drehen, dass es "passt". Und
Microsoft hat Marketing, Linux weniger. Das ist wie mit den meisten
kommerziellen Unixen - die haben ihren Markt bei Servern und der Rest ist
Randgruppe.

Das ganze
monolithische Design (unter Behauptung des Gegenteils) des Systems ist
von Grundauf falsch, und mittelfristig zum Scheitern verurteilt.
Stimmt, war aber zum Anfang von Linux ein sehr großes Plusargument.

Tja, die Zeiten ändern sich, und wenn Linux nicht *sehr* bald anfängt
auch zu ändern, wird irgendwann irgendjemand *wirklich* feststellen,
dass die viel zu lange in eine Sackgasse reingelaufen sind, und da jetzt
nicht mehr rauskommen.

So ist es.

Wobei es durchaus einige gibt, die das schon
bemerkt haben. Aber die, die die Entscheidung treffen, sind leider Blind
und verbohrt.

Wahr.

Das betrifft aber auch Windows, eben weil viele Firmen auf diese
Kompatiblität setzen. Wozu sonst gibt es heutzutage noch ein Gate A20,
Real/Protected Mode, ein BIOS ? Es wird immer erweitert, immer mehr Müll
schleicht sich ins System ein. Und raus bekommt man es nicht mehr.
Notwendig wäre ein Architekturwechsel, ein neuer Prozessor, ein neues
Betriebssystem. EFI ist ein Ansatz, aber auf PCs an sich nicht durchführbar.
Und wieder bleibt alles beim Alten.

Eben,
weil monolithisch unsicherer und schneller ist.

"Schneller" und Linux ist auch so eine Geschichte aus längst vergangenen
Tagen, an denen viele einfach aus Gewohnheit festhalten, obwohl es
längst nicht mehr zutrifft. Uns stabiler ist auch ein Gerücht.

Naja, Linux ist an sich schneller, leider sind die Programme so sehr
verschlampt (unsauber programmiert), dass der Geschwindigkeitsvorteil wieder
zunichte gemacht wird. Openoffice und Firefox sind in meinen Augen sehr
aufgeblähte Programme... was man an den Startzeiten und der
Speicherauslastung merkt. Ob das gut oder schlecht ist, mag jeder für sich
beurteilen.

Wenn Kilobyte und Megahertz eine Rolle spielen, wird sauber programmiert.
Inzwischen...

Und
inzwischen kommen die Kernel UPdates die einen Reboot erzwingen bei den
großen Linux Distros mindestens genauso oft wie der MS Patchday, das
Argument ist also auch hin.

Ja. Wobei das eigentlich eine notwendige Konsequenz ist - je bekannter ein
System wird, desto stärker wird es auf Sicherheitslücken überprüft. Je mehr
Nutzer ein System hat, desto mehr Böslinge gibt es, die darauf unbefugt
zugreifen wollen. Also gibt es immer mehr Sicherheitslücken. Von Bugs mal zu
schweigen, aber die gibt es bei Linux wenigstens für jeden sichtbar.

Gleiches betrifft auch Windows - NT 3.x enthielt den Grafiktreiber im
Userspace, NT 4.0 hatte ihn plötzlich im Kernelspace, damit die
Grafikausgabe schneller möglich war.

Nich ganz. Erst bei 2000 war er im Kernelspace IIRC. Großes Geschrei
damals. Und, was ist passiert? Wie oft haben Grafiktreiber den Kernel
weggerissen?

Mir oft genug, wenn sich zwei Treiber beißen (nv4_disp.dll). Und erst
gestern kam die Frage, wie man ständig wiederkehrende Bluescreens unter
Vista beseitigen kann. Ich vermute das vorinstallierte und deinstallierte
NAV, aber das ist nur eine Idee. Woran es im Endeffekt liegt - wer weiß das
schon.

Und wenn ich im laufenden Betrieb meine (CardBus-)TV-Karte herausziehe,
bekomme ich oft einen BlueScreen. Obwohl sowohl Hardware als auch
Software
dafür eigentlich ausgelegt sein müssten.

Das ist einer der der Nachteile an Windows. Es gibt unzweifelhaft jede
Menge unfähige Programmierer und Hardwareentwickler, die mit
irgendwelchen Schweinereien es schaffen, das System wegzureißen. Ich
behaupte mal keck, dass das kein strukturelles Problem von WIndows ist,
sondern sich schlicht nicht vermeiden lässt, und durhc die schiere masse
an teilweise billigster Hardware zustandekommt.

Meine Meinung. China-Billig ist halt billig. Trotzdem habe ich es, benutze
es, und lebe mit den Macken. Komisch, oder...? Und ohne Datenblätter kann
man keine Treiber entwickeln - was wieder ein Nachteil für Linux ist.

Wobei man dazu sagen
muss, dass solche Dinge *extrem* selten (geworden) sind. Ich habe schon
*seeeehr* lange keinen Bluescreen mehr gesehen, ausser die Hardware war
faktisch kaputt.

Ich mehrfach, in Bezug auf Treiber; auch auf verschiedenen Rechnern mit
verschiedenen Hardwarekomponenten, wo ein hier nerviger Treiber nie drauf
war.

Es gibt genug andere Betriebssysteme, teilweise wesentlich kleiner. Aber
welcher Hardwarehersteller schreibt schon Treiber für ein Betriebssystem,
wo
eben kein großer Konzern hinter steht?

Das hat damit nix zu tun. Red Hat und Novell sind durchaus groß, und die
Hersteller *würden* für Linux Triber schreiben, wenn sie das nur einmal
in 3 Jahren tun müssten, anstatt dreimal pro monat.

Korrekt. Aber wenn sie einfach die Specs veröffentlichten, gäbe es
kostenlose Treiber, für die die Hersteller nichtmal Support leisten müssten
und die - wenn schon nicht alle Funktionen - doch wenigstens die
Benutzbarkeit der Hardware sichern. Je besser die Specs desto besser auch
der Treiber.

Aber das ist den Herstellern zu - ja, zu doof? - und sie leben lieber damit,
dass die Hardware nicht unterstützt wird. Die Alternative wäre nämlich
ständig Neuprogrammieren - oder im Source veröffentlichen. Letzteres wollen
die Kernelentwickler damit erreichen.

Im Gegenteil, würden die Hersteller die Spezifikationen offenlegen (ohne
NDA), gäbe es _gratis_ Treiber für Geräte unter Linux. Solange aber die
Dokumentation von Hardware wie ein Geschäftsgeheimnis einbehalten wird,
geht
das nicht.

Schonmal darüber nachgedacht, dass das, gearde bei Grafikkarten, oft
tasächlich Geschäftsgeheimnisse *sind*?

Ja. Und ich frage mich, wozu.
Wenn der Treiber _so_ wichtig ist, dann ist die Hardware unwichtig. Aber
dann müsste man den Treiber verkaufen und nicht das Gerät. Also ist der
Treiber zu wichtig und die Hardware nicht so leistungsfähig/relevant, wie
man uns vorsimulieren will.

Sie sind gegen Binärtreiber aus Gründen, die ich nachvollziehbar finde.

Die sind nur deswegen nachvollziehbar, weil das System untendrunter ein
Fehlentwicklung ist.

Ansichtssache. Es existiert keine wirkliche Alternative. Und genug
gescheiterte Betriebssysteme.

Außerdem ist es nicht gerade intelligent, in einem komplett offenen
System
ein paar weiße Flecken zu erlauben.

Aha, du bist also generell gegen closed source auf Linux? Dann kannst Du
das System gleich komplett Einstampfen.

Gegen closed source im Kernel, denn der ist das Fundament.
Anwendungen sind eine andere Baustelle, da bin ich für kommerzielle
Entwicklungen.

Ich bin einfach der gleichen Ansicht wie die Kernelentwickler - Binärtreiber
sind nicht die geeignete Methode, um Fehler zu finden. Und sicher ist, dass,
wenn ein Hersteller einen Schrott-Treiber (wie meine TV-Karte) produziert,
der ziemlich schnell - für die Stabilität - umgeschrieben würde. Wichtig
sind die Informationen und die Community ist dafür imho "groß genug", um
solche Sachen zu machen.

Ansonsten *sollte* es überhaupt keinen Unterschied machen, ob man von
einer Closed source Applikation oder einem Hardware Treiber redet. Dass
das doch einen Unterschied macht liegt wie ich schon erwähnt habe an der
Fehlkonstruktion die der Linux Kernel ist.

Dann nimm den Kernel weg und du landest bei GNU. Gilt das Prinzip da
immernoch? Schließlich hindert dich ja niemand dran, einen anderen Kernel zu
verwenden, nur, welcher käme da in Frage?

Wenn es eine sauber und
stablie TreiberAPI gäbe, gäbe es auch überhaupt keine Grund, irgendetwas
gegen Closed SOurce Treiber zu haben, und die Hersteller könnten die
notwendigen Treiber mit einem vertretbaren Aufwand bereitstellen *und*
pflegen.

Keine Frage. Aber die Entwickler (zu denen ich mich nicht zähle) möchten
halt die Treiber _selbst_ pflegen.

Da gibt es dann keine Doku, wenig Doku oder NDA.
Und da gibt es sehr gute Gründe für.

Sehe ich anders, allerdings bin ich kein Hardwareentwickler.

Davon abgesehen reicht "gebrauchbar" bei weitem nicht. Drucken
kann ich mit Linux (inzwischen). Meistens. Die Qualität der Ausdrucke
ist aber in 99% der Fälle sichtbar schlechter bis hin zu miserabel
verglichen zu Windows.

Wer schreibt die Treiber für Windows, wer schreibt sie für Linux?
Vor allem: Wer von beiden kennt die Hardware genauer?
Und warum ist das so???

Weil die Druckerhersteller ihre Drucker so primitiv bauen, dass der Treiber
die Hardware ansteuert, statt dem Drucker zu sagen, wie es klappen soll?
Wenn ein Drucker zu 80% aus Software (= [Windows-] Treiber), dann ist für
mich etwas an der Entwicklung vorbeigegangen.

Was macht Dich so sicher, dass das nicht schlicht Bugs im
ACPI code in Linux sind?

Dass es fast überall läuft und nur Ausnahmen nicht funktionieren.
Irgendetwas müssen diese "bestimmten Systeme" ja anders machen als die
anderen... was macht dich so sicher, dass nicht die Systeme die
Spezifikation anders ausgelegt haben?

Nein, warum auch. Es gibt betriebsystemunabhängige Tools, die die ACPI
Tabellen überprüfen.

Komplett? Nach welcher Spezifikation?

Wozu gibt es die
Informationen, wenn sie nicht ausgelesen werden soll?

Wenn sie nicht ausgelesen werden können, wie macht Windows das dann, mit
ein und *demselben* Code, auf beinahe jeder Hardware die in den letzten
8 Jahren auf den Markt gekommen ist?

Wobei man inzwischen auch Treiber nachinstallieren muss.
Die Frage ist immer, gegen welche Implementation man prüft.
Ich würde mich nicht wundern, wenn es TCP/IP-Implementationen gibt, die
standardkonform, aber inkompatibel zum Internet wären. Die haben nur keine
Überlebenschance und sterben früh. Nur mit dem Unterschied, dass beide
Implementationen von ACPI "leben".

Ausserdem ist das gar nicht (mehr) das Hauptproblem. Das
Problem ist das Linux und Linux Treiber an allen ecken und enden beim
schalten der ACPI states verreckt.
*Tonnenweise* Linux Treiber,
insbesondere für ältere Hardware, verkraften oft schon S1 nicht,
geschweigedenn S3 oder gar noch höheres. Das hat mit ACPI Tabellen oder
BIOS Fehlern rein überhaupt gar nichts zu tun.

Das stimmt. Betrifft aber Windows in genau dem gleichen Maße; auch bei
moderner Hardware und Billigtreibern. So schaltet sich mein Display nach dem
Standby manchmal nicht ein und bleibt schwarz, das System selbst läuft aber.
Sowohl mit den aktuellen als auch mit den mitgelieferten Treibern!

Irgendetwas stimmt nicht, und sei es noch so unwichtig, wenn es nicht
stimmt rege ich mich total auf, und verweigere die Arbeit.
Das war einmal. Unwichtige Fehler werden umgangen.
Oft höchstens mit Gewalt.

Wer behauptet, dass Windows solche Fehler nicht einfach übergeht? Vielleicht
merkt es ja niemand, nur seltsame Fehler treten dann woanders auf?

Sowohl auf Seiten der Hardware als auch auf Seiten der Software.
Warum sollte jemand einen Treiber optimieren, wo doch die Rechenleistung
eh
schnell genug zunimmt?

Ja, leider. Aber willst Du mir jetzt sagen, das wäre bei Linux anders
oder besser? Im Gegenteil, im Gegenteil. Guck Dir das Monster KDE doch
mal an. Das braucht inzwischen alleine mehr Ressourcen als ein
komplettes WindowsXP.

Seh ich auch so. KDE 1 hat mir gefallen, 2 fand ich vom Stil nicht so
hübsch, 3 ist überbläht.

[SMB]
Nicht richtig. Es gab (und gibt) durchaus mal eine ganze Reihe von
technisch bessern Alternativen, sogar völlig offengelegte. Stattdessen
hat man mit der Umarmung des MS Protokols überhaupt erst für das heute
existiernde von Microsoft kontrollierte Monopol gesorgt. NCP, Streetalk
Appletalk, um nur ein paar Beispiele zu nennen.

Ich weiß dazu nur, dass SMB mit allen Windows-Versionen ab 3.1 (3.0?)
mitgeliefert wurde, für DOS/OS2 erhältlich war und damit schon aus Gründen
der Einfachheit bei uns zu Hause eingesetzt wurde. Ergo musste Linux, um in
die Infrastruktur zu passen, auch damit arbeiten.

Von Streetalk habe ich noch nie etwas gehört. AppleTalk gab es nur für
Apples von Haus aus (ob es von Linux unterstützt wird, weiß ich nicht) und
NCP wird von Linux irgendwie unterstützt. Das war alles vor meiner Zeit.

Das heute jedes NAS und
allws was sonst noch "Netzwerk" spricht nur noch das krüppelige, immer
noch 100% proprietäre SMB kann liegt zu einem guten Teil an Samba.
Herzlichen Glückwunsch.

Ohne Samba hätte Linux bei uns nichtmal ein Netzwerk gesehen. Und das ging
bestimmt nicht nur mir so.

Ohne Basteleien übrigens heute auch noch nicht... nur
wurde es ein bisschen weiterentwickelt und heißt anders.
Ich kann der Aussage nicht folgen. Es gibt einige, auch sehr große
Netze, in denen SMB komplett verboten ist. DIe funktionieren auch, und
sogar sehr, sehr gut.

Erfordert dann aber Basteleien, nämlich die Benutzung von anderen
Protokollen, die nicht ohne entsprechenden administrativen Aufwand überredet
werden können.

Ach nein, stimmt
nicht. Das Minderwertigste Protokoll dieser Art ist NFS, erst dann
kommt
SMB/CIFS. ;-) Von der Sorte gibt es dutzende weitere Beispiele.

Und da man das Konzept ohne eine komplette Neuentwicklung
nicht umschmeißen kann, bleiben die Grundgedanken von damals erhalten.

Tja, dann muss man halt mal was neues, besseres Entwickeln, anstatt am
Rockzipfel von Microsoft zu hängen und hinter deren Änderungen in SMB
herzuhecheln. Nur sind das Fehler die vor 10 Jahren gemacht wurden.

Ja. Vor meiner Zeit.

Gruß,
Sebastian


.

Relevant Pages