Captains Log

Vor Jahren stolperte ich mal über Core War: Dabei treten zwei selbstgeschriebene Computerspiele in einem Simulator gegeneinander an. Ziel ist es zu gewinnen, indem das eine Programm das andere aus dem simulierten Speicher tritt. Grundlage ist eine Programmiersprache namens "Redcode", die aussieht wie Assembler. Und sich eigentlich auch so anfühlt. ;-)
Man kann den Programmen dabei unterschiedliche Strategien mitgeben, wobei man keines der Programme so stricken kann, dass es wirklich völlig unbesiegbar ist.
 
Heute habe ich bei irgendwem auf meiner Blogroll gelesen, dass es das noch gibt, und die Community sogar recht aktiv ist, und zwar auf coreware.co.uk. Ich gestehe, es kribbelt mich in den Fingern, selber mal so ein Progrämmchen auf die Reise zu schicken. Den entsprechenden Interpreter gibt es zumindest auch als Port für FreeBSD. :-)
 
Aber die Zeit, die Zeit...

Vor einer Weile hatte ich mich in meinem Beitrag Barcodes für unterwegs zur mobilen Nutzung von Barcodes ausgelassen, und dabei u.A. auch soziale Netzwerke und so gezielt.
Wenn man mal davon ausgeht, das die Nutzung mobilen Equipments wie Handykameras und so in Zukunft weiter steigt, dann wird das zu einem ganzen Berg an Daten führen. Und mit dem kann man ganz abgefahrene Sachen anstellen, wie dieser Film zeigt:
Vorgestellt wird hier eine Technologie, mit der beliebig viele Bilder und auch Texte auf neue Art und Weise betrachtet werden können. Ein Teil dieser neuen Technologie beinhaltet das Zusammensetzen dreidimensionaler Modelle aus einer Vielzahl zweidimensionaler Fotos.
Prinzipiell ist das auch heute machbar, bei Panoramen wird z.B. ein großes Bild aus vielen kleinen zusammen gesetzt, die jeweils Überlappungen haben müssen. Dieser Prozess wird als "Stitching" bezeichnet. Die hier vorgestellte Technologie macht das aber wohl automatisch und kann, wie in dem Beispiel angegeben, aus allen Bilder von Notre Dame, die auf flickr liegen, ein 3D-Modell erstellen, das man von allen Seiten betrachten kann.

...wenn ich Verständnis für Eure Firmenpolitik aufbringen würde.
 
heise: Individualisierte Schlösser gegen unlizenzieren Chipnachbau:

Seit amerikanische Chiphersteller die Produktion neuer Chips ins Ausland verlagerten, klagen sie über Konkurrenz durch unlizenzierten Nachbau.

Als Sysadmin bekomme ich einiges zu sehen. Da hätten wir z.B. unsere eigenen Entwickler und ihre Begierden, die zu Auswüchen wie "Du mußt mal den Server auf Deutsch umstellen" und dergleichen führen.
Wie, den gesamten Server? Stundenlange Diskussionen über die Verwendung von Locales in der Umgebung des Users oder der Umgang mit Locales in der Anwendung selbst folgen.
 
Mein Verständnis schlägt aber in entsetzen oder wahlweise in einen Lachanfall um, wenn ich mir die kommerziellen Produkte diverser Hersteller anschaue.
IBM hat mit ihrem Backuptool aus der eierlegenden Wollmilchsau Tivoli-Familie so ein Ding im Angebot: Da wird die Anwendung brav in ein eigenes Verzeichnis installiert, und im Anschluß die Konfigurationsdateien dsm.sys und dsm.opt nach /usr/bin verlinkt.
Puh, und ich rege mich auf, wenn Open Source Makefiles auf den gcc ausgelegt oder für Linux "optimiert" sind. Nun gut, die Links muß man nicht haben, aber auch unterhalb des Anwendungsverzeichnisses gibt es ein ./bin, in dem die Files rumfliegen. Wobei die hier von anderen Textdateien Verstärkung erhalten, die man ebenfalls als "Konfigurationsdatei" bezeichnen könnte. Die wird aber nicht verlinkt. Warum das so ist verstehen aber wohl nur die Programmierer. Das sind wohl auch die einzigen, die erklären können, warum sowas nicht in ein ./etc-Verzeichnis landet.
 
BMC kann das auch, wie ich gerade gesehen habe. Bei diesem dreibuchstabigen Hersteller ist man wohl der Ansicht, "bin" steht für "alles, was binär ist". Um die Sache also nicht allzusehr zu verkomplizieren findet man bei deren Software auch gleich noch die Libraries in eben diesem Verzeichnis. Dann muß man sich auch keine Gedanken über den dynamischen Linker machen.
Oder aber die Programmierer arbeiten unter und primär für Windows. So sieht das nämlich aus, wenn unter ./bin auch ein ganzer Haufen Textdateien und jars liegen. Schaut unter Windows ja eh keiner rein, und da gibt es keine festgelegten und seit Jahrzehnten gut abgehangenen Verzeichnisstrukturen.
 
Ich wundere mich dann immer, warum ich unter /etc/rc3.d keinen Eintrag finde wie ./Verknüpfung mit unserhauptprogramm. Aber stimmt, es ist mir aufgefallen, weil ich noch ein SVC Manifest für die Software schreiben muß.
 
Wobei das wirklich positiv ist, denn die Software braucht keine Root-Rechte zur Installation, sondern nur ein Verzeichnis, in dem sie sich entladen darf. Und zwischendurch weist sie dann darauf hin, dass der Root mal aktiv werden darf.
Ist also nicht alles schlecht. ;)
 
Umgekehrt sollte es aber bei so einer Software aber nicht schwer sein eine Paketierung zu verwenden, die auch den Standards gerecht wird, oder? Bei solchen Äußerlichkeiten möchte ich manchmal garnicht wissen, was der eigentliche Programmcode so alles für Überraschungen bereit hält.

On my machine Miro 1.1 causes a segmentation fault when trying to play a video. While searching the net I found some forum threads dealing with this issue. The solution was to change the renderer vom gstreamer to xine.
What a pity: xine is the default renderer currently. I just tried the opposite way and changed the renderer to gstreamer and voila: Video! But no sound...
It turned out that a few gstreamer-plugins were missing, namely gstreamer-plugins-faad which contains a decoder for AAC. I just installed multimedia/gstreamer-plugins-all to take care of any other possible issue related to missing plugins.
 
To change the renderer used by Miro, edit /usr/local/lib/python2.5/site-packages/miro/frontend_implementation/VideoDisplay.py
Locate the following block:
if values == None:
# using both renderers at once still sometimes causes problems
#self.add_renderer("xinerenderer")
self.add_renderer("gstrenderer")
else:

Change to suite your needs...
 
PS: I upgraded from FreeBSD 6.3 to 7.0 without removing all ports, which seems to be the recommended way. Instead I did a portupgrade -afk --batch to update everything automatically. So it's possible that the segfault I encountered is just the result of a port that hasn't been rebuilt successfully.
PPS: Make sure to remove VideoDisplay.pyc and VideoDisplay.pyo after you edited VideoDisplay.py and start miro as root.