Archiv des Autors: fooza

Ich mag Lachs

Veröffentlicht am von

Fisch allgemein sollte viel öfter auf meiner Speisekarte stehen. Wenn er denn die Ansprüche erfüllen würde, die man gemeinhin damit assoziert. Aber heutzutage muss man wohl eher hohe Antibiotika-Dosen mit Lachs assoziieren als ungesättigte Fettsäuren oder Vitamine, im schlimmesten Fall Viren und andere Krankheitserreger. Das schlechte Gewissen beim Kauf industriell gefertigter Nahrungsmittel ist natürlich schon längere Zeit vorhanden, eine Dokumentation wie Lachsfieber bringt das wieder gleich nach oben und macht deutlich, dass ein Abwarten und Hoffen kein Ausweg ist. Aber was tun? Ein Auswandern an irgendeinen entlegenen Platz auf diesen Planeten – gibts den überhaupt – ändert nichts an der Situation und entspricht dem Kopf-in-den-Sand-stecken. Gewalt gegen Firmen oder Menschen, denen wirtschaftlicher Erfolg wichtiger als alles andere ist, würde auch nicht zu einer Verbesserung führen, höchstens zu mehr Gewalt. Und politische Arbeit? So wie der WWF? Der in Norwegen hohe Geldbeträge dafür bekommt, dass das ökologische Image des „Partners“ grüner wird? Ich hab da keine Antwort, jedenfalls bis jetzt nicht.

Aber es gibt zumindest immer wiederkehrende Muster in solchen oder ähnlichen Problematiken. Eines davon ist das „Modell“ der Aktiengesellschaft, eine der größten Seuchen überhaupt.

MotoLOLa?

Veröffentlicht am von

Nach doch recht langer Bedenkzeit hab ich mich entschlossen ebenfalls in die Welt der Smartphones einzutreten. Ein neues Handy musste jetzt eh ran und touch(en) wollte ich auch schon immer mal. Da Android aus der Linux-Ecke stammt und meine Abneigung gegenüber Apple größer ist als die gegenüber Google, sollte es natürlich ein Gerät mit dem kleinen grünen Dingens werden. Die Auswahl an Geräten ist nicht unübersichtlich, aber recht groß. Touch screen und Einsatz als Navi sollte es können, Musik in diversen Formaten abspielen ist mittlerweile eh Standard, mobiles Internet ist auch brauchbar. Nach reichlichem Überlegen und Abwägen zwischen diversen HTC- und Samsung-Modellen blieb ich dann beim Motorola Defy hängen, weil es alle Anforderungen erfüllte, preislich attraktiver war und auch noch den Bonus Spritzwasser- und Staubschutz aufwies (mein derzeitiges Handy ist auch so eins). Nachdem das Gerät nun am Freitag eintraf, freute ich mich darauf, damit das ganze Wochenende rumzuspielen. Zuerst mal musste der Router wieder WLAN bringen, was ich sonst nicht gebraucht hab. Daraufhin konnte ich alles wie gedacht am neuen Telefon einrichten: WLAN geht, Musik hören mit mitgeliefertem Headset und auch extra Ohrstöpseln war ok, Navi funzte und GPS ging auch. Toll. Beim Einrichten der Mailbox fiel mir dann allerdings auf, dass an’s Ohr gehalten nichts zu hören war. Per Freisprechen-Lautsprecher oder Headset kein Problem, nur dem Lautsprecher (Ohrmuschel) entwich kein Ton, egal was ich anstellte. Mir war die Problematik schon bekannt, in meinen Augen war das Problem erledigt und neuere Geräte sollten ohne diesen Fehler beim  Betatester^wKunden aufschlagen. Nein, Motorola hat es wohl nicht geschafft die Probleme zu beseitigen, obwohl es mit neueren Chargen nicht mehr auftreten sollte. Ich bin in solchen Fällen immer gleich geneigt, dem Verursacher der Lebenszeitverschwendung eine Rechnung zu kommen zu lassen. Aber da werd ich wohl auf Granit beißen. Jetzt heißt es erstmal zurück schicken und hoffen, dass der Ersatz den Ärger ausbügeln kann.

update: Schnell! Das Ersatzgerät traf noch vor der Empfangsbestätigung des Retour-Paketes ein. Allerdings verursachte die Versandverpackung sofort ein ungutes Gefühl in der Bauchgegend. Auch die Herstellerverpackung sah lädiert aus und erweckten Zweifel, dass das gelieferte Gerät wirklich neu ist. Die eigentlich auf den Neugeräten zum Schutz des Display angebrachte  Folie fehlte, dass Gerät lag verkehrt herum im Träger. Die Laune besserte sich nicht, als eine ältere Software-Version auf dem Telefon zu tage kam. Beim ersten Gerät erschien nach dem ersten Booten der MotoBlur-Assistent, hier nicht. Zumindest der Ohrmuschel-Lautsprecher funktionierte aber. Nach grundsätzlichen Einrichtungsschritten (kannte ich ja schon alles auf dem FF) und dem Einschalten des wlans lag das Telefon ’ne Weile und ging in den Standby. Hatte ich gedacht. Nein, es war komplett ausgegangen und musste neu gebootet werden. Das tratt in den nächsten Stunden immer wieder auf und folgerichtig hab ich den Kram wieder eingepackt und am nächsten Tag zurückgeschickt.

Sicherlich kann man Motorola die (zeitweilig) mangelhafte Qualität als Auslöser für die ganze unappetitliche Geschichte vorhalten. Aber da hier der Händler der Hort des Übels ist, verliert der rant hinsichtlich Motorola etwas an Farbe. Und die Wahl eines mir bereits bekannten Versandunternehmens mit vielleicht geringfügig höheren Preisen hätte mir den Ungemach wohl erspart. Demnächst mehr an der Stelle.

kaputter flash-sound… und was das mit der glibc zu tun hat

Veröffentlicht am von

Manch einer wird das vermutlich schon bei fefe gelesen haben, aus fedora-Kreisen gibt es Beschwerden über defektes Audio beim Abspielen von youtube-Videos. Betrifft mich jetzt erstmal nicht direkt, hier funktioniert das gut und stabil. Aber den Bugreport sollte jeder, der weiß, was memcpy und memmove sind, mal lesen.

Kurzabriss (aus meiner Sicht; alle Details versteh ich [noch] nicht): Von Intel-Leuten wird bei der glibc-Entwicklung ein Patch eingereicht, der die oben angesprochenen Speicherfunktionen für diverse Intel-CPUs (bei 64Bit-Systemen)  beschleunigt, teilweise erheblich (fefe ist der Meinung, dass die erhebliche Beschleunigung auf einen möglichen Fehler in der Atom-CPU zurückzuführen ist). Einzige Begründung ist eben diese Beschleunigung. Und diese Änderung krempelt die interne Arbeitsweise der Befehle um, was aber bedeutet, dass bestimmte Annahmen bei der Nutzung über den Haufen geworfen werden. Für memcpy(3) ist zB. eine Annahme, dass die Speicherbereiche von Quelle und Ziel nicht überlappen dürfen. Hat man diese Situation im Programm, ist memmove(3) zu nutzen. Bei Adobe wiederum hat man sich für diese Annahmen offensichtlich nicht interessiert, was bisher nicht negativ aufgefallen sein dürfte. In neueren Linux-manpages von memcpy fehlt da ein interessanter Nebensatz, der den Spezialfall der überlappenden Speicherbereiche als undefiniert bezeichnet. Und jetzt (tatsächlich wurde der Fehler schon im September/Oktober letzten Jahres diskutiert) führt diese Situation eben dazu, dass der bestehende Code im flashplayer mit der alten glibc-Version (Fedora 13) funktioniert, aber in der neuen Fedora-Version 14 nicht mehr. Kein großes Ding, möchte man meinen, es wurden auch verschiedene Würgarounds gefunden – der Fehler in der glibc existiert aber eben weiter. Wenig überraschend tauchen nach und nach weitere Programme auf, die plötzlich Probleme haben.

Was dann am stärksten in dieser Situation nervt, ist die Tatsache, dass die Verantwortung gegenseitig hin- und hergeschoben wird. Die Fedora-Leute (die imo keine Schuld trifft) meinen, dass das nur upstream (also bei den glibc-Leuten) zu behandeln sei; die glibc-Entwickler sagen, dass Adobe schuld ist, weil sie eben den Code nicht so einsetzen, wie das zu machen ist; und Adobe kommt nicht aus dem Arsch, um einen Fix bereitzustellen. Öhm, und was ist jetzt mit dem Fehler in der glibc? Die Entwickler meinen, dass Verhalten der Funktion ist ok und bedarf keiner Änderung. Linus Torvalds, der von dem Fehler eben auch betroffen ist, hat aber einige Argumente aufgezählt, warum es eben nicht ok ist (Stichwort: prefetch-Logik einer CPU). Es ist nicht das erste Mal, dass die glibc-Entwickler eine gewisse Sturheit an den Tag legen und sinnvolle Argumente vom Tisch wischen. Bis dato bleiben die Änderungen bestehen.

In einem Post, der in der weiter fortgeschrittenen Diskussion (in dem bug-report) auftaucht, macht ein Kommentator einen weiteren, imo schwerwiegenden Aspekt deutlich. Wenn das Verhalten vom memcpy zu falschen Speicherzugriffen führt und vielleicht auch Speicherbereiche überschreibt, ist das ein Sicherheitsproblem. Da die glibc auch noch ein elementarer Bestandteil jedes Std-Linux-Systems ist, kann das auch als schwerwiegendes Problem bezeichnet werden, denn falls ein Malware-Schreiber einen Weg finden sollte, wie dieses Problem für ihn nutzbar ist, dann sind da recht schnell alle Distributionen betroffen, sprich die Wirkung wäre verheerend.

update: ich war gerade fertig mit schreiben und hab auf der glibc-Mailingliste nachgesehen, ob es nicht vielleicht Neuigkeiten in der Angelegenheit gibt. Entgegen meiner Befürchtung, dass nichts zu finden ist, war tatsächlich ein neuer Patch da, der zumindest einen der vorgeschlagenen workarounds implementiert und sicheres Verhalten bewirkt.

BFS raus der Warteschleife

Veröffentlicht am von

Es hat also doch nicht so lange gedauert bis zur Veröffentlichung der BFS-Version, die mit dem 2.6.38er Kernel eingesetzt werden kann. Natürlich läuft der lokale Rechner hier schon mit so einem und tut das sehr gut. Interessanterweise gibt es im oben verlinktem Verzeichnis auch einige weitere Patches, die zeigen, wie das eigene System noch etwas mehr auf Desktop-Bedürfnisse angepasst werden kann. Es gibt schliesslich im Standard-Kernel nicht wenige Annahmen oder Kompromisse, die für embedded-Systeme genauso gelten wie für dicke Mainframe-Kisten oder Cluster.

BFS für 2.6.38 in Warteschleife

Veröffentlicht am von

Alle letzten Kernel-Versionen liefen hier mit dem BFS, weil einfach der reine Eindruck von Interaktivität immer spürbar besser war. So erscheint es logisch, mit dem Release eines neuen Kernels bzw. einer neuen Version auch nach einem Update des Schedulers zu kucken. Der lässt allerdings auf sich warten. Wie jetzt in Kolivas‘ Blog nachzulesen ist, war er etwas überrascht vom schnellen Release und auch anderweitig mit weiterer Software beschäftigt, weswegen noch keine neue Version auf dem Tisch liegt. Das wird auch noch eine Weile so bleiben, will Kolivas doch erstmal die Auswirkungen des autogroup-Patches beobachten.

Journalistische Standards beim NDR

Veröffentlicht am von

Hier oder auch bei fefe wurde auf eine Sendung des NDRs hingewiesen, die sich in die gegenwärtige Diskussion um die Nutzung der Kernenergie einreiht. Bis jetzt hab ich nur den kurzen Ausschnitt gesehen, über den so viele aufgebracht sind, soll er doch ratlos suchende Reaktorfahrer bei einem zufällig gefilmten Störfall im KKW Brokdorf zeigen. Mich wurmen an diesem Beitrag bzw. an der Diskussion mehrere Dinge: da weiß auf einmal jeder wie ein Reaktorfahrer im Falle einer Störung zu reagieren hat, oder was? Sollen die da hysterisch schreiend auf den Knöpfen der Anlagenkontrolle rumdrücken oder wie sollen die denn nach Meinung der grummelnden Mehrheit reagieren? In meinen Augen (und nach meiner Vorstellung) tritt da ein Fehler auf und die Verantwortlichen versuchen zuerst die Ursache zu klären, warum da etwas als Fehler gemeldet wird und ob die Quelle tatsächlich in diesem Anlagenteil liegt. Dass die da erstmal einen Plan zur Hand nehmen, find ich sinnvoll. Viele andere (siehe utube-Kommentare) sehen darin Ratlosigkeit. Na klar.

Und was bitte geht beim NDR vor, wenn in dem Beitrag behauptet wird, dass das die Warte des AKWs ist und der Störfall gerade eine ernste Situation im Betrieb darstellt, obwohl es sich laut eines Kommentars im Kurzvideo und auch laut einer bei fefe eingetroffenen Mail tatsächlich um den/einen Reaktor-Simulator der Kraftwerksschule Essen handeln soll? Für Außenstehende ist jetzt erstmal schwer beweisbar, welche Warte da wirklich zu sehen ist. Aber wenn sich das als Tatsache herausstellen sollte, müsste die Frage nach den Standards der Arbeit beim NDR auf den Tisch. Erklärung dazu: Es gibt zwei unterschiedliche Videos bzw. Streams, in einem kommt die Szene nicht vor, im anderen aber. Dann passt das ja wieder mit den Standards, allerdings fragt ich mich schon, warum die sich beim NDR in den Fuß schießen wollen und zusätzlich Verwirrung stiften. Was die Wertung der Handlung der Reaktorfahrer angeht, steht meine Meinung weiterhin oben.