Archiv für den Monat: April 2011

Sucker_Punch_poster

Sucker Punch

Hinterlasse eine Antwort

Boah, ist der Film schlecht. Eigentlich zumindest. Jedenfalls wollte ich das direkt nach dem Film schreiben. Aber mit etwas Abstand…

…ist das Ding immer noch schlecht. Klar: Der Soundtrack ist super und stimmig und viele Bilder sind einfach nur cool. Aber warum muss man so eine doofe Pseudo-Handlung einbauen und doofe Off-Kommentare.

Denn die Action-Sequenzen finde ich – in aller comic-haften Übertreibung – einfach gut: Ob jetzt im Alternativ-Universum-Erster-Weltkriegs-Szenario Zombie-Dampf-Soldaten mit M4-Sturmgewehren und Mechs ins Alternativ-Universum-Erster-Weltkriegs-Szenario-Zombie-Dampf-Soldaten-Jenseits geballert werden oder die vier Damen vom Grill den Orks zeigen, wie das ist, wenn man nicht gegen zwei Mimimi-Hobbits kämpft – die Bilder und die Sequenzen stimmen, der Kameramann weiß, wo der Fokus liegen soll und die Musik passt super (gut, die Kulissen sehen irgendwie alle geklaut aus [Dragonheart und I Robot lassen grüßen]…egal, von den Bildern passt es…ja, der Schnitt ist manchmal auch etwas zu hektisch…aber das hier soll der Absatz mit den positiven Sachen sein…also Schluss jetzt).

Aber (ein Wort, dass in diesem Text viel zu häufig vorkommt) dann die doofe, doofe, idiotische Rahmenhandlung. Mit Pseudo-Charakterentwicklung (Nein, wir können das nicht tun…Ja, wir schaffen das…boah!) und nervigen Verschachtelungen. Ich fand die Laberei in 300 ja schon bescheuert und aufgesetzt und dann treibt er das hier noch weiter…in 300 war das Gerede wenigstens innerhalb der Action, als Off. Ne, in Sucker Punch wird während, neben, vor, über und beim Nachbarn der Handlung sinnlos Luft für noch sinnlosere Worte verbraucht.

Also heißt es warten auf den Director’s Cut oder aber den Viewer’s Cut – nur Action, keine doofe Rahmenhandlung…nur Babes, Waffen und Alternativ-Universum-Erster-Weltkriegs-Szenario Zombie-Dampf-Soldaten-Orks.

[xrr rating=3/5]

Lustige Programmierfehler

Hinterlasse eine Antwort

Programmierfehler ist jetzt nicht unbedingt richtig, denn das meiste sind simple Shellskripte, aber wir wollen mal nicht so kleinlich sein.
Für unser Kooperationsprojekt mit der SUB sollen wir einen zusätzliches Login anbieten, das nur auf lokale Resourcen im GoeNet zugreifen darf. Das ist soweit kein Problem, der Account wird einfach mit adduser erstellt und dann hängt man da mit iptables ein paar Regeln dran die mittels Ownermatch einfach alles verbieten.
Zusätzlich soll das Homeverzeichnis nach dem Ausloggen gelöscht werden, auch kein Problem das machen wir einfach über den das Init-Script des Displaymanagers, jedesmal wenn der startet schaut er nach welche Accounts lokal angelegt sind und schmeißt die Weg.
Schon am Freitag Nachmittag war allerdings irgendwas nicht in Ordnung, aus irgendeinem Grund stürzte der GDM schon beim booten ab, da ich ein bisschen mit upstart und rcconf rumgespielt habe, dachte ich mir das wär meine Schuld und verschiebe die Problembehebung einfach auf Montag …
Heute habe ich also die meiste Zeit des Tages damit verbracht einen Fehler in den Startabhängigkeiten zu suchen der nicht existiert. Genaugenommen kommen da eigentlich zwei Fehler auf einmal zusammen, zum einem meine unfähigkeit zu kommunizieren und zum anderen ein kleiner logischer Fehler in Niels GDM Anpassung.
Um diese Zusatzaccountgeschichte möglichst flexibel zu gestalten habe ich einfach /etc/default/custom-accounts  angelegt und dort stehen halt die Accountnamen drin die mein Script dann verarbeitet. Das gleiche macht Niels auch, hat er nur woanders abgelegt, nicht weiter schlimm ich wunderte mich nur die ganze Zeit warum der falsche Account angelegt wird …
Fehler zwei ist dann das wegwerfen des Homeverzeichnisses das sieht so aus:

HOMEDIR_TO_CLEAN=awk -F: -v user=$i 'user == $1 {print $(NF - 1)}' /etc/passwd
rm -rf $HOMEDIR_TO_CLEAN/*
rm -rf $HOMEDIR_TO_CLEAN/.[A-Za-z0-9]*

An dieser Stelle kann man sich überlegen, wenn in Niels Datei ein Account drin steht den ich nicht anlege und dessen Homeverzeichnis trotzdem gelöscht wird. Kleiner Tip, die Rückgabe des Awk-Kommandos ist dann leer …
Aus rm -rf nutzer/* wird dann /* und das ist etwas hinderlich -.-
Also ein kurzer if ! [ -z ] eingebaut -> nicht leer, und schon werfen wir beim booten auch nicht mehr unser Rootverzeichnis ins Nirvana. Natürlich ist das auch letztlich wieder meine Schuld, weil ich /bin, /sbin, /lib und /usr komplett in das AuFS lege, sonst würde da einfach eine Fehlermeldung stehen das man die Dateien nicht löschen kann …

man müsste sich Dinge auch notieren ..

Hinterlasse eine Antwort

Da ich dazu neige alles mögliche zu vergessen, was ich nicht irgendwo notiert habe und Google uns bei der Suche immer brav hilft, möchte ich hier mal wieder in ein paar Zeilen die Geschehnisse der letzten Wochen festhalten.

Den Witz mit der FX160 brauch ich nicht zu erwähnen, ich versteh nicht wieso eine Grafikkarte kein DVI unterstützt obwohl ein DVI-Port vorhanden ist, ist mir auch egal.
Nach einigen Stunden des Feintunings an unserem Diskless Debian, haben wir am vergangenen Montag ein paar Freiwillige das System testen lassen insgesamt ist es wohl bereit für den Produktiveinsatz. Ein paar kleine Bugs gab es noch zu beseitigen, von meiner Seite waren das natürlich wieder absolute Perlen administrativen Nicht-könnens. Herr Hinke, also ich, ist der Meinung den Kernel könnte man wenigstens schon noch selbst übersetzen und das tue ich auch gern und häufig. Ich vergesse dann nur ab und zu die Zielgruppe aus den Augen, so wurde mir freundlich mitgeteilt, dass Cardreaderunterstützung schon eine feine Sache ist im 21. Jahrhundert. Die Ausrede das ich keine Module kompiliere die ich selbst nicht benutze wurde nicht akzeptiert ..
Das hat natürlich direkt Fehler 2 hervorgerufen, nicht funktionierende udisks mit Active-Directory Accounts. Dazu sei nur erwähnt das der nscd vor dbus starten sollte, dann funktioniert es auch, zumindest in der Theorie. In der Praxis benötigt der eingesetze XFCE noch HAL, welches über PolicyKit gestartet werden soll und das tut es auch nachdem sich jemand einloggt.
Irgendwann ist mir aufgefallen das immer nach dem ersten Login das automagische Mounten von Laufwerken nicht klappt, weil HAL anscheinend zu spät startet. Die häßliche Lösung: hald –daemon=yes in die rc.local schreiben, mit der nächsten XFCE-Version fliegt das eh raus …
Der dritte Fehler war es dann sich darauf zu verlassen das man bei der Installtion schon drauf geachtet hat, das die Abhängigkeiten von sysv-rc alle geklappt haben. Nach dem nun die Uhrzeit synchronisiert wird, bevor man sich am AD anmeldet klappt das nun auch fehlerfrei. Zusätzlich ist die Bootzeit jetzt auf knapp 25 Sekunden herunter, was ich schon ganz in Ordnung finde.

Heute Nachmittag hab ich mir dann vorgenommen den Beweis anzutreten, dass das System auch Distributionsunabhängig ist und wollte Archlinux aufsetzen, mehr als das Basissystem hab ich aber auch nicht installiert, zwischendurch hab ich aus versehen noch ein LVM kaputt gespielt. Merke lvresize führt nicht selbstständig rezisefs aus … naja, das steht auch in jedem HowTo und in der manpage, aber wer liest sowas schon vorher?
Stattdessen hab ich neben Squeeze i386 ein amd64 aufgesetzt. Sobald dort unsere angegepassten Pakete eingespielt werden, könnte man also darüber nachdenken auf den x86-64 Clients ein 64-Bit System anzubieten.

Ein Gedanke ging mir noch durch den Kopf, ob man anhand des dhcp-request Pakets das Betriebssystem herausfinden kann, damit beschäftige ich mich vermutlich morgen. Hintergrund des ganzen ist eine Dualbootumgebung für den Kursbetrieb. Da beide Maschinen im AD betrieben werden, ich aber noch keine Möglichkeit gefunden habe, eine Windowskeytab “zu klauen”, möchte ich denen einfach je nach Betriebssystem einen anderen Hostnamen zuweisen.

Am Rande sei noch erwähnt das es lustig ist wenn eine Firma sich meldet mit “Hallo der Kollege der ihre Anfrage bearbeitet hat, arbeitet nicht mehr bei uns. Könnten Sie uns ihre Unterlagen noch mal zuschicken? Wir haben nur ein paar unvollständige Notizen gefunden…”, dabei geht es natürlich auch wieder um größeres Projekt und ich frage mich wie sich solche Firmen überhaupt auf dem Markt halten können Oo

Auch lustig ist es, wenn man beim Ausparken aus der elterlichen Hofeinfahrt (mit Mama’s Auto) mit dem Hoftor kollidiert, weil man vergessen hat es vorher auch zu öffnen. Naja ich fand es nicht lustig, meine Mutter schon, zum Glück hab ich nur ein Loch in die untere Plastikheckschürze gefahren -.-

Niels ist ja der Meinung das Wort “lustig” würde hier, also im Büro, ziemlich inflationär benutzt und wir sollten damit aufhören. Vor allem wenn man damit nicht lustig im Sinne von witzig meint. Eine brauchbare Alternative ist ihm allerdings nicht eingefallen. Da dieses Phänomen allerdings auch im deutschsprachigem EU-Ausland auftritt, scheint es zumindest zu keinen größeren Missverständnissen zu führen. Ich hab zwar manchmal den Eindruck dort versteht man mich auch nicht immer richtig, aber das liegt in den meisten Fällen vermutlich eher an meiner ungeschickten Wortwahl. In den anderen Fällen ist es wohl “nicht verstehen wollen” oder wie mir gestern mitgeteilt wurde, macht es anscheinend Spass mich (grundlos) zu ärgern -.-

Und weil ich das hier als Notizzettel gerne missbrauche, erinner ich mich grad nochmal daran Dienstag in die Werkstatt zu fahren.

Update: das Archlinux bootet auch, mir war nur nicht klar dass das ein “Profisystem” ist, wo der grafische Installer laut Herrn I. vim und bash sind…
Ich hab da ja eigentlich nichts gegen, aber von der “hauptsache bunt und shiny”-Fraktion hatte ich etwas anderes erwartet ..

desktop-optiplex-fx160-overview1

Optiplex FX 160 revisited

Hinterlasse eine Antwort

Eigentlich wollten Dennis und ich unsere DINO-System-Reihe mit ein paar kurzen Posts starten, die das an der Uni Göttingen eingesetzte Linux-Terminal-Projekt mal näher beleuchten. Und da sollte am Anfang eine kurze Einführung stehen, was das Ding genau macht, was es kann und was es von anderen Systemen unterscheidet.

Aber da kam leider der Frust über den kleinen Dell-Computer dazwischen, über den ich 2009 schon einmal geschrieben habe. Das Fazit von damals kann zwar grundsätzlich stehen bleiben, aber der Frust ist mittlerweile sehr viel größer: Was für eine höllen-doofe Grafikkarte haben die da verbaut???

Es hat Dennis (und mich im geringeren Maße) ein paar Stunden gekostet, das Gerät unter dem neuen DINO zum laufen zu bekommen, weil es dafür keinen vernünftig verfügbaren Treiber gibt! Und wir reden nicht von einem Treiber, der VA-API, 3D-Spielereien oder sowas bietet, sondern der einfach nur ein Bild auf den Bildschirm zaubert, dass nicht aus einem Farbverlauf pink-nach-blau aussieht. Allein die Suche in den Weiten des Netz ist grauenvoll…wenn man Treiber von Sharehostern laden muss, um ein funktionierendes System zu haben, läuft was falsch. Irgendwann haben wir dann bei github Treiber gefunden, aber auch die wollten kein Bild erzeugen.

Das hat erst nach meiner Schnapsidee geklappt, mal das VGA-Kabel anstelle des DVI zu nutzen. Gesagt, getan, Bild. Was für eine ******

Ich verstehe nicht, was die Dell-Entwickler bei der FX 160 geritten hat: Das Ding ist bis auf die Grafikkarte klasse, tut seinen Dienst, ist klein und sparsam und hat für Standard-Aufgaben genug Power. Selbst ein i810-Chipsatz wäre besser – aber nein…(und mir ist klar, dass die Systeme für die Windows-Umgebung gebaut sind, aber wenn man den Foren glaubt, ist die Treiber-Funktionalität da auch eher suboptimal…) Doof, doof, doof. Und sehr schade.