Was die Welt nicht alles braucht!
Nach langem überlegen habe ich mir heute gleich 2 SheevaPlugs bestellt. Diese sollten dann wohl innerhalb der nächsten 2-3 Wochen bei mir ankommen.
Bestellt habe ich diese in Großbritannien, da der einzige deutsche Reseller den ich ergoogelt habe für einen einzigen Plug 230€ haben will. Daher habe ich diese bei newit.co.uk für deutlich weniger bestellt.
Ich verwende ja seit einiger Zeit Google Reader als Feedreader. Darin gibt es eine Funktion in der man Beiträge anderen Leuten empfehlen kann. Wer wissen möchte was ich empfehle kann sich dies gerne mal ansehen » Link.
Hintergrund ist der das ich mir abgewöhnt habe jede News die es schon 1000 mal im Netz gibt auch noch in mein zu Blog zu stellen, es gibt schon mehr als genug solcher Newsblogs ;-)
In meiner Firma verwenden wir mehrere Mobotix M12-DevKits. Das ist eine spezielle Variante einer normalen M12 Kamera welche man für eigene Lösungen verwenden kann.
Zumindest in der Version 3.4.2.16 lief diese mit einem SW-Sensor noch einwandfrei. Wir haben 2 neue Kameras (gleicher Typ, andere Software-Release) bekommen mit der Software 3.4.5.10 und 3.4.5.18 welche nach ca. einer Stunde immer wieder neu Starten.
Das ganze konnte mit mehreren Konfigurationsdateien und den Werkseinstellungen verifiziert werden. Was aber halt (ein Tip von einem freundlichen Mototix Mitarbeiter): In der Bildsensorkonfiguration den SW-Sensor mal auf Farbsensor zu konfigurieren! Seitdem läuft unsere Kamera durch, ohne einen einzigen Reboot.
Im Eventlog findet man bei diesem Fehler nur div. Rote Meldungen das es Fehler mit dem Bildprozess gab (Fehlercode #51) und dieser neu gestartet werden muss. Auch war, wenn man den Fehler hatte öfters mal das Bild weg (4-5 Sekunden).
Ein Softwareupgrade seitens Mobotix steht noch aus, ich gehe aber davon aus das dies noch im Dezember erscheinen wird. Mit dem Workaround von oben (bei welchem ich keine Nachteile Feststellen konnte) kann die Kamera aber wie gewohnt genutzt werden.
Ich hab ja auch vor ca. 2 Jahren angefangen neue Webanwendungen nur noch mit Python zu schreiben da mir PHP langsam aber sicher auf den Keks ging.
Am Anfang habe ich mit SQLite,Cheetah,SVN und CherryPy gearbeitet, was mir damals auch ausreichte. Doch mittlerweile haben sich meine Anforderungen und Wünsche geändert.
Bei der Suche nach Alternativen zu meinen bisherigen Tools war mir vor allem das Ubuntuusers-Webteam sehr hilfreich, daher kurz und Bündig: Danke!
Das erste was ich getauscht habe war das Templating, was nicht heißen soll das Cheetah eine schlechte Template Engine wäre. Aber wenn man sich an die Vorteile von Jinja2 (vor allem den prima UTF-8 Support) mal gewöhnt hat will man kaum noch was anderes verwenden. Auch warf Cheetah bei mir viele Fehler bezüglich Python 2.4 Kompatibilität. Ein anderer, in meinen Augen großer, Vorteil ist das Jinja2 seine Template auch aus einer Datenbank oder auch anderswo her beziehen kann.
Plain-SQL mit SQLite war am Anfang eine schöne Sache, doch jedes mal die Daten in Objekte einzulesen ist natürlich mehr oder weniger Aufwendig und daher auch sehr Fehleranfällig. Es musste also ein ORM her. Schon schnell (und durch einige Tipps vom Webteam) wurde mir klar das SQLAlchemy genau das ist was ich Suche!
Auch eine schöne Sache ist natürlich SQLAlchemy Migrate das es einem auf einfache weise erlaubt sein Datenbanklayout zu verwalten.
Auch an dieser Stelle war ich nach einiger Zeit mit CherryPy nicht mehr zufrieden. Vor allem das URL-Management und die eher fragwürdige Tauglichkeit unterhalb von mod_wsgi machten mir große Probleme. Aber auch cherrypy.session wollte nicht richtig Arbeiten sobald es mit mod_wsgi laufen sollte (Da wurde gerne mal ne Session vergessen).
Auch hier kam ein Tipp vom Webteam: Werkzeug!
Am Anfang habe ich hier gerne Subversion verwendet, was vor allem daran lag das ich dies schon (nach CVS) eine halbe Ewigkeit kenne. Nachteilig war vor allem die Mobile Offline Nutzung, den auf ein Repository auf dem Server kommt man ohne Netzwerk/Internetverbindung nicht ran. Mit Mercurial geht das ohne Problem (git oder bazaar hätten das aber natürlich auch geschafft).
Hätte ich gleich das Webteam gefragt hätte ich mir ca. 4 Wochen arbeiten und jede Menge Frust mit Subversion sparen können!
Ich vermute das schon jeder diesen Link hier kennt.
Auf jeden Fall lohnt es sich mal "reinzuklicken", den es zeigt mal wieder mehr wie doof (oder Verzweifelt) man sein kann ;-)
So, wir haben es hinter uns: Die Ubucon 2009 ist vorbei!
Ich selbst war (leider) nur in 3 Vorlesungen:
Dies war meiner Meinung nach der interessanteste Vortrag auf der Ubucon 2009. Den es zeigte genau das was ich immer predige: Sperrt eure Bildschirme wenn ihr vom Rechner weggeht!
Den selbst ohne funktionierende Internetverbindung kann man ziemlich einfach genug Backdoors für eine ganze Familie einbauen. Demnächst gibt es wohl auch unter ubucon.de die Präsentation als Download (so wie jedes Jahr).
Hier war ich leider etwas enttäuscht, den zu oft war es Offtopic. Es wäre schöner gewesen wirklich gezielt die Neuerungen von Karmic zu zeigen, als ständig Diskussionen über WebKit, Firefox, Ekiga usw... anzustoßen.
Ich denke auch das man mit weniger Zeit (ca. 60 Minuten hätten gereicht) das ganze etwas mehr Komprimiert hätte und so diese Offtopic Sachen vermieden hätten werden können.
Wie auf jedem OpenSource Event konnte man natürlich auch auf der Ubucon 2009 seine GnuPG Keys signieren lassen.
Auch eine sehr Starke Präsenz zeigte das Team Rund um CAcert: Ich vermute es waren um die 10 Assurer anwesend. Zusätzlich erreichten sogar noch einige direkt auf der Ubucon diesen Status!
Die Ubucon 2009 war meiner Meinung nach ein voller Erfolg! Am besten hat es mir gefallen das man 10€ für die Anmeldung Zahlen musste. So konnte ziemlich effektiv vermieden werden das man Namensschilder für 10-Jahre über hat. Die Verpflegung war natürlich wie immer Erstklassig (Berliner, Käse- und Wurstsemmeln, Getränke,...) so das man auch hier nicht zu kurz kommt!
Das gleiche gilt für die Social Events: Genau so muss es sein!
Ich selbst werde als auch nächstes Jahr mit meiner Freundin die Ubucon besuchen, egal wo diese sein wird. Das einzige was letztes Jahr besser war ist der Empfangsraum gewesen, den dieser war zusammen mit dem Hackcenter doch Recht eng!
Ich bin ja seit einiger Zeit der Entwickler von pyNeighborhood.
In der letzten Version 0.5.0 wurde das Suchen von Netzwerkfreigaben über smbtree erledigt. Es stellte sich jedoch heraus das dies nicht unbedingt die cleverste Entscheidung war. Daher haben wir für Version 0.5.1 wieder eine Browsing-Engine auf Basis von Version 0.4 entwickelt.
Das ist nicht die einzige Umstellung, auch wurde die Versionsverwaltung von Subversion auf Bazaar umgestellt, da sich diese wesentlich besser in Launchpad integriert.
Zusätzlich verwendet pyNeighborhood jetzt intern SQL zur Speicherung der Daten. Keine Angst, niemand muss deswegen eine Datenbank installieren: Wir verwenden SQLite.
Da nicht jeder Drag & Drop mochte haben wir jetzt auch implementiert das man mit einem Doppelklick eine Freigabe mounten kann. Der Rest der Änderungen sind hauptsächlich Bugfixes.
Da es sich hierbei um eine -rc0 Version handelt bitte ich darum pyNeighborhood einfach mal zu testen. Wenn alles gut läuft könnte dies auch die alte pyNeighborhood Version aus Ubuntu oder Debian ersetzen, was natürlich sehr wünschenswert wäre!
pyNeighborhood steht unter der GPL-3 Lizenz und ist somit also OpenSource Software. Am einfachsten geht es wenn man Ubuntu verwenden, den hierfür habe ich schon ein fertiges PPA. Die andere Möglichkeit wäre direkt die aktuelle Bazaar Version zu verwenden in der vielleicht schon der ein oder andere Bug mehr ausgemerzt wurde. An diese kommt man über die Projektseite, auf welcher man auch gefundene Fehler melden sollte.
Was pyNeighborhood noch fehlt ist ein richtiges schönes Logo im SVG-Format ;-)
Als ich dieses Bild sah dachte ich mir, das die doch glatt "Und dann ab in den Mixer" vergessen haben welches man ja aus der Werbung für einen beliebten Joghurt kennt!
Durch den schnellen Tod meiner ISDN Karte (AVM B2 Version 4.0 PCI) habe ich eine andere Lösung gesucht meinen Asterisk Server am ISDN Basisanschluss der Telekom anzuschließen.
ISDN Karten gibt es wie Sand am Meer, doch hat mir meine B2 prima gezeigt was passiert wenn eine kaputte Karte mal den ganzen Server lahmlegt. Daher wollte ich auf eine Lösung verzichten die im Server steckt. Folglich kam also nur ein Media-Gateway in Frage!
Nach einiger Recherche stoß ich immer und immer wieder auf die Firma Patton, welche Quer übers Internet gute Rezessionen erhielt.
Meine Entscheidung fiel auf das Patton SmartNod 4552, da dieses sowohl einen internen als auch einen externen S0-Bus hat. Mit ~250€ ist es sogar günstiger wie manche ISDN Karte.
Die Konfiguration ist sehr flexibel, auch gibt es Telnet und SSH Zugang. Was man aber definitiv kritisieren muss ist die in einigen Fällen komplexe Konfiguration, den gerade wenn man das Teil von Grund auf Konfigurieren will (d.h. die Basiskonfiguration löscht man erstmal) ist man damit als Patton-Neuling doch etwas beschäftigt. Nachdem man das Grundkonzept verstanden hat erweist sich die Konfiguration aber als sehr flexibel, einem ISDN & VoIP Neuling wünsche ich aber verdammt viel Glück bei der Konfiguration ;-)
Durch einen Zufall konnte ich heute endlich mal FireWire ausprobieren. Dies liegt daran das ein Arbeitskollege von mir eine Sony DCR-HC51E auf seiner Hochzeit dabei hatte. Leider wusste niemand so genau wie man da Videos runter bekommt :-(
Glücklicherweise verfügt die Kamera über einen Firewire Anschluss so das man mit Kino auch unter Linux ohne große Probleme die Videos von der Kamera bekommt.
Vorbereiten muss man nicht viel, es genügt wenn die Kernelmodule raw1394 und dv1394 geladen sind:
sudo modprobe raw1394 sudo modprobe dv1394
Als Software ist Kino sehr gut, bei der Fehlersuche ("Steckt die Kamera richtig?") ist gscanbus von Vorteil da man die Bustopologie damit sehen kann:
sudo aptitude install kino gscanbus
Das einzige was man jetzt noch beachten muss ist, das Kino ja Lese und Schreibrechte auf /dev/raw1394 benötigt. Immer wieder gibt es Anleitungen wie "Nimm einfach den Benutzer in die Gruppe disk mit auf."... Bitte, macht sowas nicht! Den nicht nur /dev/raw1394 hat als Gruppe disk, sondern vor allem auch Datenträger (Festplatten), wodurch es ermöglich wird das man ohne weitere Hürden direkt die Festplatte manipulieren kann, da man ja Schreibrechte direkt auf den Datenträger hat (vorbei am Dateisystem).
Es ist, zumindest wenn man Kino nicht oft braucht viel sinnvoller Kino Temporär als root (mit sudo) laufen zu lassen. Zwar hat Kino dadurch mehr Rechte, und könnte diese durch eine Sicherheitslücke in Kino missbrauchen, aber man öffnet nicht einem User (und somit vielen anderen Sicherheitslücken) die ganzen Datenträger.
Die Sicherheitstechnisch sinnvollste Lösung wäre eine Anpassung der udev Regeln, dies aber auch nur auf den ersten Blick. Den über das IEEE1394 Subsystem ist eh Zugriff auf das restliche System möglich.
Meiner Meinung nach sollte man daher Kino wirklich "einfach" als root (mit sudo) laufen lassen, was sicherlich einigen Administratoren nicht gefallen wird:
sudo kino
Die Videodateien, auch die Exportierten Videos, gehören so aber leider dem Benutzer root. Um das zu ändern kann man dies hier ausführen:
sudo chown benutzer:benutzer /pfad/zu/den/videos/*.dv
Nach diesem Befehl gehören die Dateien dem Benutzer benutzer, und man kann diese wie gewohnt bearbeiten.
Video mit Kino von der Firewire tauglichen Kamera zu laden ist relativ einfach. Stolpersteine gibt es eigentlich nur beim Sicherheitsaspekt, was aber wenn man es nicht täglich brauch verschmerzlich ist.
Ich gehe in diesem Artikel nicht weiter auf Kino ein, da es hierfür schon mehr als genug Dokumentation (auch deutsche) im Netz gibt.
Getestet habe ich alles was in diesem Artikel steht unter Ubuntu Hardy Heron (64-Bit, 8.04 LTS), es sollte aber auch auf andere Distributionen übertragbar sein.