4. Februar 2010 - 15:38
GEZ versucht (verzweifelt?) ihr Image zu retten
Die GEZ genießt ja bekanntlich nicht den allerbesten Ruf in der Bevölkerung. Viele fühlen sich verfolgt und bezeichnen sie gar als “moderne Raubritter des 20./21. Jahrhunderts”.
Sie hat aber auch schwer zu kämpfen mit den säumigen Zahlern. Trotz geduldigen Hinweisen per Briefpost, netten Errinnerungswerbespots im Fernsehen und schlagkräftigen Argumenten wie “Weil’s einfach Pflicht ist!”, sinkt die Zahlungsmoral ständig.
Naja, zum Glück geht man aber jetzt neue Wege und sucht den Kontakt zu den Kritikern auf http://www.gez-meine-meinung.de.
Wer noch eben einige Minuten/Stunden/Tage totzuschlagen hat kann dort im Forum die ein oder andere mehr oder weniger lustige Geschichte lesen oder gar selbst eine Posten.
Aber Achtung das Forum ist nur von 18-22 Uhr geöffnet. Und nicht ärgern wenn dein Post nicht veröffentlicht wird. Es findet nämlich vorab eine Zensur seitens der Moderatoren statt. Ist auch verständlich. Man muss schon darauf achten, dass die fiesen Geschichten besser nicht auf der eigenen Webseite veröffentlicht werden.
Ach ja, und falls du eine Antwort eines GEZ Mitarbeiters im Forum finden solltest bitte ich dich den Link dorthin bitte hier als Kommentar zu posten. Habe nämlich noch keine einzige finden können. Thx.
24. Januar 2010 - 17:53
Tool-Tip: weather-wallpaper
Auf der Suche nach einem Applet für Gnome, dass mir Auskunft über die aktuelle Wetterlage gibt bin ich über dieses coole Tool namens weather-wallpaper gestolpert.
Es generiert in einstellbaren Zeitabständen ein Hintergrundbild passend zum Wetter ;)
Siehe auch die weather-wallpaper Projekt Homepage für mehr Infos.

Anmerkung: Das links unten im Bild ist übrigends das good-weather gDesklets Applet.
18. Januar 2010 - 0:02
Cuda Entwicklungsumgebung unter Ubuntu 9.10 (karmic)
Da mir seid kurzem ein Laptop mit CUDA fähiger Grafikkarte zur Verfügung steht und in meiner TODO-Liste auch noch die Fortführung einer CUDA beschleunigten Variante von Enblend/Enfuse herumgammelt, habe ich mich nun einmal aufgemacht eine entsprechende Entwicklungsumgebung einzurichten.
- NVIDIA Treiber mit CUDA Support
- NVIDIA CUDA Toolkit (Runtime Environment)
- NVIDIA CUDA SDK (Development Kit)
Obwohl momentan CUDA 2.3 schon released ist und auch CUDA 3.0 schon als Beta in den Startlöchern steht, habe ich mich für die ältere Version 2.2 entschieden.
Für die neue 2.3er Version müsste man nämlich den “NVIDIA Driver 190.18 Beta for Linux” installieren. Für die 2.2er Version reicht der “NVIDIA Driver for Linux 185.18.14″. Diesen bringt Ubuntu 9.10 (karmic) schon von Haus aus mit und erspart so unnötiges Treibergefrikel.
Für CUDA 2.2 muss also kein extra Treiber installiert werden. Der neueste Ubuntu-eigene Treiber genügt.
Das CUDA Toolkit habe ich per sudo in das standardmäßig vorgegebene
/usr/local/cuda Verzeichnis installiert:
flo@acer ~ $ sudo sh cudatoolkit_2.2_linux_64_ubuntu8.10.run Verifying archive integrity... All good. Uncompressing NVIDIA CUDA............................................. Enter install path (default /usr/local/cuda, '/cuda' will be appended): „lib“ -> „/usr/local/cuda/lib“ „lib/libcufft.so.2.2“ -> „/usr/local/cuda/lib/libcufft.so.2.2“ „lib/libcufft.so.2“ -> „/usr/local/cuda/lib/libcufft.so.2“ ... „bin/ptxvars.cu“ -> „/usr/local/cuda/bin/ptxvars.cu“ „bin/cudafe“ -> „/usr/local/cuda/bin/cudafe“ ======================================== * Please make sure your PATH includes /usr/local/cuda/bin * Please make sure your LD_LIBRARY_PATH includes /usr/local/cuda/lib * or add /usr/local/cuda/lib to /etc/ld.so.conf and run ldconfig as root * Please read the release notes in /usr/local/cuda/doc/ * To uninstall CUDA, delete /usr/local/cuda * Installation Complete
Das CUDA SDK wird fast genauso installiert. Allerdings habe ich das SDK statt, wie vorgeschlagen ins HOME, unter
/opt installiert. Evtl. könnte man das SDK auch gleich zum Toolkit unter /usr/local/cuda installieren, um alles auf einem “Haufen” zu haben. Die Pfade wären in den folgenden Schritten dann entsprechend anzupassen.
flo@acer ~ $ sudo sh cudasdk_2.21_linux.run Verifying archive integrity... All good. Uncompressing NVIDIA CUDA SDK............................................. Enter install path (default ~/NVIDIA_CUDA_SDK): /opt/cuda/sdk Could not locate CUDA. Enter the full path to CUDA. If you do not know the path, accept the default and then modify the CUDA_INSTALL_PATH variable in /opt/cuda/sdk/common/common.mk. Enter CUDA install path (default /usr/local/cuda): „sdk/Makefile“ -> „/opt/cuda/sdk/Makefile“ „sdk/ReleaseNotes.html“ -> „/opt/cuda/sdk/ReleaseNotes.html“ ... „sdk/tools“ -> „/opt/cuda/sdk/tools“ „sdk/tools/CUDA_Occupancy_calculator.xls“ -> „/opt/cuda/sdk/tools/CUDA_Occupancy_calculator.xls“ ======================================== Configuring SDK Makefile (/opt/cuda/sdk/common/common.mk)... ======================================== * Please make sure your PATH includes /usr/local/cuda/bin * Please make sure your LD_LIBRARY_PATH includes /usr/local/cuda/lib * To uninstall the NVIDIA CUDA SDK, please delete /opt/cuda/sdk * Installation Complete
a) LD_LIBRARY_PATH für CUDA libs setzen
Um die CUDA Libraries zu nutzen müssen diese in den Library Suchpfad aufgenommen werden und das geht so:
flo@acer ~ $ cat /etc/ld.so.conf.d/cuda.conf /usr/local/cuda/lib/ flo@acer ~ $ sudo ldconfig
b) CUDA BIN Verzeichnis zum PATH hinzufügen
Der CUDA Compiler nvcc muss im PATH gefunden werden. Eine Möglichkeit das zu erreichen ist den Pfad in der Bash Konfiguration zu erweitern:
flo@acer ~ $ cat /etc/bash.bashrc ... PATH=$PATH:/usr/local/cuda/bin
Sobald eine neue Shell geöffnet wird, wird der Pfad nun entsprechend angepasst.
c) Compiler-Flags für GCC 4.4/Ubuntu 9.10 anpassen
Als letztes muss nun noch ein kleiner Eingriff in die CUDA Compilerflags erfolgen, um CUDA mit dem GCC 4.4 (standard bei Ubuntu 9.10) nutzen zu können. Konkret muss das Flag “-O2″ entfernt werden und das geht so:
flo@acer ~ $ sudo cp /opt/cuda/sdk/common/common.mk /opt/cuda/sdk/common/common.mk.org flo@acer ~ $ sudo sed -i 's/COMMONFLAGS += -O2/#&/' /opt/cuda/sdk/common/common.mk
d) Freuen und evtl. mit einem der mitgelieferten Beispiele gleich Testen ;)
- CUDA Downloadseite
(Um zum Download von CUDA 2.2 zu gelangen als OS “Linux 32Bit/64Bit” und als Linux Version “Ubuntu 8.10” auswählen, sonst wird nur die aktuelle CUDA Version 2.3 angezeigt!) - Blogpost zur Anpassung der Compilerflags für GCC 4.4/Ubuntu 9.10
- CUDA Kurse und Podcasts von Vorlesungen zu GGPU
16. Januar 2010 - 22:41
Mylyn WTP aka Generic Web Templates Connector unter Eclipse Galileo installieren
Seid einiger Zeit nutze ich nun die Integration des Bugzilla Bugtrackers in Eclipse mittels Mylyn. Soweit funktioniert das auch sehr gut. Allerdings würde ich gerne auch Bugs einiger Projekte verwalten, für deren Bugtracker es keinen Mylyn Connector gibt.
Konkret würde ich es gerne schaffen den BerliOS Bugtracker in Mylyn zu integrieren. Dieser verfügt meines Wissens nach aber über keine Schnittstelle für externe Anwendungen – kann also nur über die Weboberfläche bedient werden. Soweit so schlecht.
Meine Google Recherchen ergaben, dass BerliOS wohl eine sehr ähnliche Bugtracker Software wie Sourceforge einsetzt. Außerdem fand ich einige Seiten die von einer erfolgreichen Integration des
Sourceforge Bugtrackers in Mylyn mittels eines generischen Web Template Connectors sprachen.Allerdings ist dieser in der Standardinstallation nicht enthalten und auch in den standard Update Sites nicht (mehr) verfügbar. Nach einiger Sucherei fand ich heraus das irgendwann das Projekt in die Incubator Update Site von Mylyn verschoben wurde:
“The generic web repository connector is NOT part of the default Mylyn install. You can install it from the incubator update site. See Mylyn download page for more details.”
Diese war gar nicht so leicht herauszufinden, deshalb erspare ich euch das Suchen. Die Adresse lautet wie folgt:
Mylyn incubator update site - http://download.eclipse.org/tools/mylyn/update/incubator/
Sobald diese in Eclipse hinzugefügt wurde kann man die WTP aka Generic Web Templates Connector aka “Mylyn Connector: Web Templates (Advanced)” auswählen und installieren.
Nachdem ich man es nun geschafft hat den WTP Connector zu installieren muss dieser noch für die Weboberfläche des BerliOS Bugtrackers konfiguriert werden. Ausgehend von der Sourceforge Konfiguration, welche mitgeliefert wird, habe ich schon begonnen eine Konfiguration für BerliOS zu erstellen. Bislang allerding mit eher mäßigem Erfolg.
Einloggen scheint schon zu klappen, allerdings werden noch keine Bugs importiert. Sobald das letzte Puzzle-Teilchen auch noch gefunden ist werde ich die Lösung natürlich wie immer mit allen teilen die’s interessiert ;)
- 15:52
NTFS-Schreibzugriff unter Ubuntu Linux
Leider bietet Ubuntu karmic standardmäßig nur NTFS-Lesezugriff. Um auch schreibend auf NTFS formatierte Medien zugreifen zu können muss man das Konfigurationstool ntfs-config installieren und unter dem neu hinzugekommenen Menüpunkt System->Systemverwaltung->NTFS Konfigurationstool den Schreibzugriff für die entsprechenden Partitionen aktivieren.
Die Installation kann unter Ubuntu karmic einfach mit einem Klick auf folgenden Link vorgenommen werden: apt://ntfs-config
Für externe Medien muss man — umständlicherweise — den ersten Dialog zunächst mit Anwenden bestätigen und im, dann erscheinenden, zweiten Dialog den Schreibzugriff für externe Medien aktivieren.
Genau erklärt findet man das Ganze auch noch im Ubuntu Geek Blog Artikel über NTFS Schreibsupport
28. Dezember 2009 - 15:57
Versioniertes Backup aka “Time-Machine” für Linux
Da durch akutes Festplattensterben in meiner Umgebung die Aufmerksamkeit mal wieder auf ein ordentliches Backup gelenkt wurde, habe ich mich heute mal etwas mit der Thematik auseinandergesetzt. Und wenn ich schon dabei bin, will ich es natürlich richtig machen.
Ein einfaches rsync-Backup mit Rotationen, wie es z.B. rsnapshot bietet, ist mir nicht genug, da ich nur eine begrenzte Anzahl an alten Versionen aufheben kann.
Interessant ist auch der Ansatz eines versionierten Dateisystems namens ext3cow, dass wohl schon recht nahe an Apples Time-Machine herankommt. Leider ist das Ganze wohl noch nicht ganz ausgereift und wird wohl noch einge Zeit brauchen bis es seinen Weg in den Linux Kernel findet.
Die optimale Lösung setzt wohl auf Subversion in Verbindung mit einigen Scripten, die sich um ein regelmäßiges, automatisches einchecken kümmern. Wie man so etwas hinbekommt beschreibt Christopher Ingram in seinem Blog in drei ausführlichen Einträgen (Teil 1, Teil2, Teil3).
Wie’s aussieht werde ich letztere Lösung in naher Zukunft an zwei Standorten einrichten und werde berichten wie’s gelaufen ist.
17. November 2009 - 18:47
SimpleSAMLphp und Suhosin
Letztens musste ich SimpleSAMLphp als SP/IdP für mein lokales SSO Entwicklungssystem aufsetzen. Allerdings wollte der SSO Vorgang nicht recht funktionieren.
Nach einigem Stochern in den Logs bin ich auf folgendes gestoßen:
flo@acer ~ $ tail -f /var/log/apache2/error.log ... [Sun Nov 15 15:41:52 2009] [error] [client 127.0.0.1] ALERT - configured GET variable value length limit exceeded - dropped variable 'SAMLRequest' (attacker '127.0.0.1', file '/var/www/simplesaml/saml2/idp/SSOService.php'), referer: http://sp-ssphp.localhost/simplesaml/saml2/sp/idpdisco.php?entityID=http%3A%2F%2Fsp-ssphp.localhost%2Fsimplesaml%2Fsaml2%2Fsp%2Fmetadata.php&return=http%3A%2F%2Fsp-ssphp.localhost%2Fsimplesaml%2Fsaml2%2Fsp%2FinitSSO.php%3FRelayState%3Dhttp%253A%252F%252Fsp-ssphp.localhost%252Fsimplesaml%252Fexample-simple%252Fsaml2-example.php&returnIDParam=idpentityid
Die Logmeldung weißt auf einen Verstoß gegen die Suhosin Richtlinen für die maximale Parameterelänge hin. Da die SAML2 Nachricht “vorneherum” via GET Variable übertragen wird ergibt sich ein recht ansehnliche Parameterlänge, welche von Suhosin als Angriff gewertet und geblockt wird.
Um das Problem zu beheben muss einfach die maximale Parameterlänge in der /etc/php5/conf.d/suhosin.ini erhöht werden. Eine Erhöhung von 512 auf 1024 hat in meinem Fall ausgereicht:
flo@acer ~ $ cat /etc/php5/conf.d/suhosin.ini ... ;suhosin.get.max_value_length = 512 suhosin.get.max_value_length = 1024 ...
Viel Spass!
Nachtrag
Folgendes muss auch noch angepasst werden:
flo@acer ~ $ cat /etc/php5/conf.d/suhosin.ini ... ;suhosin.cookie.max_name_length = 64 suhosin.cookie.max_name_length = 128 ...


Kein Grund zur Panik! 

Kommentare: