Achtung, hier folgt ein auch für meine Verhältnisse ungewohnt technischer Beitrag. Das hat folgende Gründe: Am Dienstag stand ich vor der Herausforderung einen Video Streaming Server unter Linux zu installieren, damit es möglich ist, Videos in SecondLife für das Bildungsraumprojekt von Werner Sesink zu zeigen. Da ich das als ziemlichen K(r)ampf empfunden habe, der aber letztendlich erfolgreich war, schreibe ich mein Vorgehen hier auf, vielleicht hilft es ja irgendwem irgendwann.

Der Darwin Streaming Server ist eingentlich ein ziemlich geiles Teil. Man kann darüber rtsp-Video-Streams (statische Dateien oder auch Livestreams) und auch MP3-Streams senden. Das beste dabei ist, dass dieser unter einer Open-Source-Lizenz steht. Andere Firmen lassen sich hierfür teuer bezahlen.

linuxuser hat zur Installation des Darwin Streaming Servers eine hervorragende Anleitung geschrieben, allerdings ist diese von 2005 und nicht alle meine Probleme konnte ich damit lösen.

Download der Quelltexte

Für den Download muss man sich bei Apple registrieren. In meiner Naivität hatte ich zuerst die aktuelle Version 6.0.x heruntergeladen. Diese hat aber beim kompilieren viel zu viele Fehler geschmissen (so ähnlich sah das aus), sodass ich es mit der Vorversion 5.5.5 probiert habe und auch dabei geblieben bin.

Installation und Kompilieren der Quelltexte

Die Datei DarwinStreamingSrvr5.5.5-Source.tar.gz habe ich hochgeladen (Verzeichnis beliebig) und mit
tar xvzf DarwinStreamingSrvr5.5.5-Source.tar.gzentpackt. Im Verzeichnis DarwinStreamingSrvr5.5.5-Source kompilierte ich anschließend die Quellen mittels
BuilditDas ging auch soweit problemlos. Von linuxuser war ich bereits vorgewarnt, dass das Buildit-Skript nicht fehlerfrei funktioniert. Es erstellt zwar die kompilierten Dateien, aber nicht in den Verzeichnissen, in denen das nun folgende Installationsskript diese erwartet. Zunächste führte ich also das Installationsskript aus:
InstallNun muss man penibel die Fehlermeldungen abarbeiten, der häufigste Fehler ist dieser Art:
copying qtpasswd to /usr/local/bin/qtpasswd
cp: cannot stat `qtpasswd': No such file or directoryIn diesem Fall konnte also die Datei qtpasswd nicht gefunden werden. Mit dem Befehl
find -name "qtpasswd"findet man, wo das Build-Skript die Datei abgelegt hat und kopiert sie von dort an die vom Installationsskript gewünschte Stelle:

cp qtpasswd.tproj/qtpasswd /usr/local/binBei mir waren noch folgende Dateien an der falschen Stelle (ohne Gewähr auf Vollständigkeit):

cp PlaylistBroadcaster.tproj/PlaylistBroadcaster /usr/local/bin
cp MP3Broadcaster/MP3Broadcaster /usr/local/bin
cp WebAdmin/src/streamingadminserver.pl /usr/local/sbin
cp StreamingLoadTool /usr/local/bin/StreamingLoadTool
cp streamingloadtool.conf /etc/streaming/streamingloadtool.conf
cp -R AdminHtml /var/streaming/AdminHtmlKopiert man den Admin-Ordner nicht, bekommt man bei Start des Servers die Fehlermeldung “Couldn’t find the en language messages file!”

(Übrigens löscht das Installationsskript die mühsam verschobenen Dateien wieder, wenn ihr es ein zweites Mal ausführen solltet.)

Die Datei perlpath.pl befand sich auch an der falschen Stelle, sie musste von DarwinStreamingSrvr5.5.5-Source/WebAdmin/ nach DarwinStreamingSrvr5.5.5-Source/ kopiert werden.

Die Gruppe qtss gab es auch nicht, die musste ich manuell anlegen:

groupadd qtssDa ich nicht mehr sicher weiß, ob die Vergabe des Adminbenutzernamens und -passworts mit dem Skript geklappt hatte (ich meine, das ging nicht), schreibe ich hier noch hin, wie man das manuell erledigt:
qtpasswd $username$username könnt ihr frei wählen. Das ist dann der Benutzername, mit dem man sich in der Webadminoberfläche einloggt. Anschließend müsst ihr noch das gewünschte Passwort eingeben.

Start und Konfiguration

Der Rest war dann geschenkt. Der Serverprozess konnte gestartet werden

/usr/local/sbin/DarwinStreamingServerund anschließend die Webadministration

/usr/local/sbin/streamingadminserver.plIm Webinterface kann man sich mit den mittels qtpasswd generierten Zugangsdaten einloggen und muss nur den Pfad zu den Videos anpassen (da wo man eben die Videos gespeichert hat oder haben wird).

Testen (in Apples QuickTime-Player, VLC hatte bei mir nicht geklappt?!) lässt sich die Installation leicht über eines der beigelegten Demo-Movies:rtsp://meinserver.tld/sample_300kbit.movEine brauchbare Dokumentation des DSS-Servers findet sich übrigens auch hier.

Schlusswort

Funktioniert.

Gestern startete die Vortragsreihe E-Learning im e-learning-center. Martin Leidl und Antje Müller stellten die Ergebnisse des ZweitesLeben-Seminars aus dem letzten Semester vor. Eine gute Gelegenheit die Gedanken zum ZweitenLeben zu ordnen und ein kleines Resümee zu ziehen.
Der Ansatz sich mit dem ZweitenLeben zu beschäftigen lag in der Frage, worin dessen Mehrwert für Bildungsprozesse liegt und wie man diesen optimal nutzen kann. Die anfangs leise Ahnung hat sich mittlerweile größtenteils in Gewissheit gewandelt. Kurz gesagt: Der Mehrwert des ZweitenLebens bei Bildungsprozessen ist überschaubar. Es gibt keine didaktisch bahnbrechenden Neuerschaffungen oder Neukombinationen. Viele Angebote beschränken sich auf das Replizieren realer Szenarien, die dadurch aber nicht zwangsläufig einen Mehrwert erhalten.

Die Stärken des ZL liegen in der synchronen Kommunikation (also Kommunikation ohne merklichen Zeitversatz). Es ist eben doch etwas anderes, ob man in einem Chatfenster ein Semikolon gefolgt von einem Minuszeichen und einer geschlossenen Klammer eingibt oder das dreidimensionale Gegenüber per Gestenfunktion mit dem rechten Auge zwinkert, auch wenn beides technisch vermittelt ist. Durch die neu hinzugekommene VoIP-Funktion wird dieser Vorteil noch weiter ausgebaut.

Eine weitere Stärke besteht in der Möglichkeit Visualisierungen zu erschaffen, zu bearbeiten und daran kollaborativ zu arbeiten, beispielsweise indem man mit seinem Avatar auf Objekte deutet. Wenn ich aber einen Wikiauszug nur dadurch “inworld” bekomme, dass ich einen Screenshot als Textur auf ein Objekt lege, wird mir schwindelig vom Kopfschütteln. An diese Stelle schließt sich auch eine zentrale Erkenntnis unserer Dozenten an:

Wenn ZL überhaupt Mehrwert produziert, dann nur durch die Kombination mit bereits bestehenden Web 2.0-Konzepten. Diese Integration ist zwar an verschiedenen Stellen möglich, sei es durch das Inworld-Lesen von RSS-Feeds oder durch das Inworld-Bloggen, doch ist das ganze nur eingeschränkt und umständlich möglich. So haben wir auch im Seminar das Gegenstück der synchronen, die asynchronen Kommunikation größtenteils außerhalb des ZL durchgeführt.

Martin erwähnte während des gestrigen Vortrags die theoretische Persistenz von ZL, also dessen Dauerhaftigkeit. Diesem lässt sich sehr gut die praktische Reliabilität gegenüberstellen, die sich gerne mal in längeren Offlinezeiten äußerte (vgl. Aus allen Nähten platzend). Während der Präsentation gestern gewährte ZL auch keinen Einlass.

Gerne vergessen werden die kommerziellen Interessen des Anbieters LindenLab, die durch die hohen Serverkosten nicht ganz ungerechtfertigt sind. Einen anderen Ansatz stellt hierbei das OpenSource-Projekt Croquet dar, das durch seine P2P-Technologie die Netzwerklast dezentral schultert, allerdings laut Martin noch nicht wirklich benutzbar ist. Croquet verspricht eine bessere Integration der Web 2.0-Elemente und könnte daher eine vielversprechende Alternative zu ZL werden. Einen Eindruck kann man bei youTube gewinnen (bezeichnend allerdings der Kommentar von danielfoxtutorials: “This looks all very cool until you actually try to use it.”

Technisch vermittelte Prozesse laufen stets Gefahr, das Digital Divide voranzutreiben, sei es durch fehlenden oder nur eingeschränkten Zugang zum Internet oder durch fehlende bzw. veraltete Technik. Die hohen Systemanforderungen des ZL verschärfen dieses Problem noch. Die noch einigermaßen aktuellen Laptops der CSW genügten den Anforderungen nicht, ein 100$-Laptop wird da keine Ausnahme machen.

Gleichzeitig ermutigt und vorgewarnt durch Annas erfrischende Offenheit über ihre Probleme beim Interview mit Bernd Schmitz habe ich heute mein Interview mit Lexa Merlin von der vhs Goslar geführt. Da die vhs einen eigenen TeamSpeak – Server betreibt, hatten wir uns schnell auf ein VoIP-Interview verständigt. Zeitgleich war Starkey, ein Student der Erziehungswissenschaften (die Uni habe ich vergessen) vor Ort, der um Erlaubnis bat, beim Interview zuhören zu dürfen. Dieser Bitte haben wir großzügigerweise stattgegeben. Lexa hat mir gleich zu Beginn das Du angeboten und erzählt, dass sich die vhs-Dozenten im ZL duzen, aber weiterhin im RL siezen. Das Interview dauerte ca. 30 Minuten und ist in sehr angenehmer Atmosphäre verlaufen, auch wenn ich genau wie Anna gerne mal ins Sie verfallen bin. Nach dem Interview kam die Stunde der Wahrheit: Wider meines normalen Misstrauens in die Fehlerfreiheit von Technik hatte ich die Aufnahmefunktion von TeamSpeak zuvor nicht getestet, doch zum Glück wurde mein Leichtsinn nicht bestraft. Mit Erleichterung stellte ich fest, dass alles aufgezeichnet wurde. Alles in allem also ganz gut verlaufen.

Gestern Abend haben wir uns zum zweiten Mal im ZL getroffen und diesmal lief es (wie ich finde erwartungsgemäß) deutlich disziplinierter ab, als noch beim ersten Treffen. Das ließ sich beispielsweise daran festmachen, dass niemand mehr im TeamSpeak ungefragt dazwischen plapperte, was durch die “Jeder-muss-sich-melden-bevor-er-was-sagen-darf”-Maßnahme wirksam unterbunden wurde. Im ErstenLeben müssen solche Erwartungen an Verhaltensweisen in der Regel nicht explizit kommuniziert werden. Die Studis wissen, dass in einer Lehrveranstaltung nicht dazwischengeplappert werden darf. (Bzw. höchstens so laut, dass nur die unmittelbaren Nachbarn dadurch gestört werden.) Die erste Sitzung im ZL war bezüglich solcher Verhaltensweisen etwas unverbindlicher: es waren nicht alle pünktlich, manche/r hat während des Seminars die Kleidung gewechselt, kleinere Späßchen wurden gemacht. Dennoch lief die Sprachkommunikation über TeamSpeak auch hier schon recht geordnet ab. Durch die stärkere Reglementierung der Kommunikation wurde diese meinem Empfinden nach effektiver und ich hatte im Gegensatz zur ersten Sitzung nicht das gelegentliche Gefühl, ich könnte mit meiner Zeit etwas sinnvolleres anfangen. Bezeichnend fand ich übrigens die Situation, als nach Freiwilligen für das Rollenspiel gesucht wurde. Erst nach längerem Hin und her ließen sich zwei (Frei)willige finden. Insgesamt also “fast wie in echt”™.

Wade Roush schreibt im Technology Review, dass die ZweiteLeben-Software nicht mit den steigenden Benutzerzahlen zurecht kommt. Das Problem dafür liegt laut Zero Linden, Software-Entwicklungsmanager bei Linden Lab, darin, dass “diese Architektur [nicht] skalierbar ist“, im Klartext heißt das wohl, je mehr Menschen sich im ZL tummeln, umso langsamer und unbenutzbarer wird es. Bisher hatte sich dieses Problem für mich in noch erträglichen und nur gelegentlich auftretenden Login- oder Performanceproblemen geäußert. Für die Akzeptanz des ZL u.a. anderem auch für Bildungsprozesse ist die Zuverlässigkeit des Systems unerlässlich. Stell dir vor, du willst ein Seminar besuchen und der Raum ist abgeschlossen? Oder das ganze Gebäude? Oder der Campus war weg? Oder die Welt? Linden Labs arbeitet an einer neuen Architektur, die weit besser skalierbar sein soll als bisher, aber auch erst 2008 erscheinen soll. Mal schauen, vielleicht stehen wir ja im Herbst vor verschlossenen ZL-Toren?

“First life is a 3D analog world […]”, für das es, wenn es nach getafirstlife.com geht, mal wieder nötig ist Werbung zu machen. Denn obwohl der Autor dieser Seite mehrfach darauf besteht, kein ZweitesLeben-Hasser zu sein, ist auch er (genauso wie ich) ziemlich überrascht über den Hype, den es derzeit um ZweitesLeben gibt. Mehr dazu im seinem Blog.