Kategorie: e-learning

Ein altes Mediawiki umziehen, ein Mediawiki-Offline-Backup mit httrack erzeugen und Tipps für eine Confluence-Migration mit dem Ziel Mediawiki


Durch den Erfolg der Wikipedia ist die Mediawiki-Software sehr bekannt geworden und an vielen Orten im Einsatz. Da so ein Mediawiki gut funktioniert und die Tendenz hat zu wachsen, wenn fleißige Leute an den Inhalten mitarbeiten, stellt sich irgendwann die Frage nach einer Migration auf einen neuen Server.
Im Gegensatz zu vielen PHP-basierten Anwendungen ist es häufig nicht möglich, bei einer Neuinstallation einfach die alte Datenbank für die neue Installation zu übernehmen. Das hängt damit zusammen, dass das Mediawiki kontinuierlich weiterentwickelt worden ist, was an der Oberfläche (glücklicherweise) nicht zu erkennen ist.
Der Erfolg vom Mediawiki hängt gerade an dieser einfachen Oberfläche. Das ist aber auch ein Kritikpunk bzw. der Grund für noch einfacher (auch für Leute die schon von der Mediawiki-Syntax überfordert sind) bedienbare kommerzielle Alternativen wie z.B. Atlassian Confluence, das aber in Zukunft nur noch in der Cloud angeboten wird, was die Zahl von Mediawiki-Installationen im Geltungsbereich der DSGVO sicher in die Höhe treiben wird. Wer mal in die Bredouille kommt, so etwas realisieren zu müssen, dem können diese Infos hier helfen:
https://bluespice.com/de/migration-von-confluence-nach-bluespice-mediawiki/
Bluespice hat dankenswerterweise seine Migrationsscripte auf GitHub zur Verfügung gestellt:
https://github.com/hallowelt/migrate-confluence
Glücklicherweise bietet auch eine ältere Mediawiki-Installation vielfältige Möglichkeiten die Inhalte im XML-Format zu exportieren, dass ein ganz aktuelles Mediawiki wieder importieren kann. Ähnlich wird übrigens auch bei einer Confluence zu Mediawiki Migration vorgegangen (siehe oben im Github-Link).
Mediawiki Grundinstallation auf einem neuen Server (hier ein Ubuntu-Server 20.4LTS):


sudo apt-get install apache2 mariadb-server -y
sudo  apt-get install php libapache2-mod-php php-common \
php-mbstring php-xmlrpc php-soap php-gd php-xml php-intl \
php-mysql php-cli php-mcrypt php-zip php-curl -y
sudo apt-get install php libapache2-mod-php php-common \
php-mbstring php-xmlrpc php-soap php-gd php-xml php-intl \
php-mysql php-cli  php-zip php-curl -y
sudo  apt install php-apcu
sudo systemctl start apache2
sudo systemctl enable apache2
sudo systemctl start mysql
sudo systemctl enable mysql
sudo mysql_secure_installation
mysql -u root -p
wget https://releases.wikimedia.org/mediawiki/1.36/mediawiki-1.36.1.tar.gz 
(immer eine aktuelle Version verwenden! Erst schauen unter https://releases.wikimedia.org/mediawiki/ )

cd /var/www/html/
tar -xvzf /home/itmc-admin/mediawiki-1.36.1.tar.gz
(use always newest version) 
mv mediawiki-1.36.1/ mediawiki
chown -R www-data:www-data /var/www/html/mediawiki
chmod -R 755 /var/www/html/mediawiki
chmod -R 755 /var/www/html/mediawiki
hostnamectl set-hostname [YOURHOSTNAME]
sudo apt-get install imagemagick

Dann die zentrale Konfigurationsdatei /var/www/html/mediawiki/LocalSettings.php anpassen und dem Apachen eine /etc/apache2/sites-available/mediawiki.conf bauen (ssl/Zertifikate usw.).
Beide Dateien sind stark abhängig von den lokalen Gegebenheiten.

Export der Inhalte auf dem alten Mediawiki:

Wegen des hohen Versionsunterschieds wurde der Weg über einen XML-Export gewählt.

In /mediawiki/maintenance


cd /srv/www/htdocs/mediawiki/
php dumpBackup.php  --full --quit > wikinamedump.xml

Dann wikinamedump.xml und das Verzeichnis “images” übertragen per scp auf die neue Maschine.

Importieren der alten Inhalte des Wikis auf der neuen Maschine:

User Anonymous anlegen (beliebiges PW) dann erst geht:


php importDump.php --conf ../LocalSettings.php  /home/itmc-admin/wikinamedump.xml --no-local-users

Images Verzeichnis übertragen und Rechte einstellen:


chmod -R 755 images

Dann in maintenance die Bilder in der Datenbank neu indizieren, die Wiki-Links updaten und einen Rebuild durchführen:

 

cd maintenance/
php importImages.php --dry --search-recursively /var/www/html/mediawiki/images/
php importImages.php  --search-recursively /var/www/html/mediawiki/images/
php refreshLinks.php
php update.php
php rebuildall.php

Manchmal kann eine lokale Sicherung eines Mediawikis Gold wert sein, insbesondere, wenn man dort seine IT-Umgebung dokumentiert. Klar, man kann das über einen lokalen Webserver und eine Datenbank laufen lassen, aber dass ist oft ein Overkill. Einen ganz sauberen PDF-Export eines größeren Mediawikis habe ich seit Jahren nicht mehr gesehen und da viel mir der wunderbare statische Website-Kopierer httrack ein. Ich war nicht der Erste mit der Idee und ich habe dazu diese
https://www-public.imtbs-tsp.eu/~berger_o/weblog/2008/05/30/offline-backup-mediawiki-with-httrack/
und diese Anleitung
https://github.com/oschrenk/scripts/blob/master/backup-mediawiki-de.sh
gefunden. Leider ist das „moderne“ Webdesign auch an den Mediawiki-Themes nicht spurlos vorbeigegangen. Developer moderner Frameworks finden es cool, das Laden von CSS-Dateien abhängig von Javascript-Code zu machen, der Parameter wie Seitenbreite des Fenster, Device usw. für responsive Design ermittelt. Ein statischer Website-Kopierer hat da natürlich verloren. Das Ergebnis sieht dann aus, als ob Stylesheets ganz abgeschaltet worden sind. „Erwachsene Browser“, oder Browser für Erwachsene, wie der Firefox ermöglichen es, so etwas unter „Ansicht“, „Webseiten-Stil“, „kein Stil“ zu erzwingen.
Da ich im Fall der statischen Kopie aber nicht auf die Formatierung verzichten möchte, habe ich die oben verlinkten Scripte so modifiziert, dass ich das Stylesheet des Mediawiki-Standardthemes per Loop in die generierten HTML-Seitern hinein mogele.
Installieren von httrack:
apt-get install httrack
Das Ganze mache ich automatisch regelmäßig per cron-job:

5 3 * * 7 /home/admin/backup-mediawiki-de.sh > /dev/null 2>&1

Als kleines Features wurden noch ein Zip-Archiv mit einem Passwort in das Script integriert.
Sonntags um 3:05 Uhr lasse ich das backup-Script /home/admin/backup-mediawiki-de.sh ausführen, welches folgenden Inhalt hat:


#! /bin/sh

# Inspired by blogpost from http://www-public.it-sudparis.eu/~berger_o/weblog/2008/05/30/offline-backup-mediawiki-with-httrack/
# And ttps://github.com/oschrenk/scripts/blob/master/backup-mediawiki-de.sh
# Modified for modern Mediawiki and zip-Backup, A.Bischoff

# -w            mirror web sites (--mirror)
# -O            backup directory
# -%P           extended parsing, attempt to parse all links, even in unknown tags or Javascript (%P0 don't use) (--extended-parsing[=N])
# -N0           Saves files like in site Site-structure (default)
# -s0           follow robots.txt and meta robots tags (0=never,1=sometimes,* 2=always) (--robots[=N])
# -p7           Expert options, priority mode: 7 > get html files before, then treat other files
# -S            Expert option, stay on the same directory
# -a            Expert option, stay on the same address
# -K0           keep original links (e.g. http://www.adr/link) (K0 *relative link, K absolute links, K3 absolute URI links) (--keep-links[=N]
# -A25000       maximum transfer rate in bytes/seconds (1000=1kb/s max) (--max-rate[=N])
# -F            user-agent field (-F "user-agent name") (--user-agent )
# -%s           update hacks: various hacks to limit re-transfers when updating (identical size, bogus response..) (--updatehack)
# -x            Build option, replace external html links by error pages
# -%x           Build option, do not include any password for external password protected websites (%x0 include) (--no-passwords)

site=YOURWIKIHOST
# YOURWIKIHOST z.B. www.wikipedia.de

sitepath=$site/mediawiki
topurl=https://$site/mediawiki/index.php
backupdir=/home/admin/wiki-backup/$site

echo "==== cleaning up ===="
echo
rm -r $backupdir

httrack -w $topurl/Spezial:Alle_Seiten \
-O "$backupdir" -%P -N0 -s0 -p7 -S -a -K0 -A999000 \
-F "Mozilla/4.5 (compatible; HTTrack 3.0x; Windows 98)" \
-%s -x -%x  \
"-$sitepath/Spezial:*" \
"+$sitepath/Spezial:Letzte_Änderungen" \
"-$sitepath/index.php?*" \
"-$sitepath/Diskussion:*" \
"-$sitepath/Benutzer_*" \
"-$sitepath/Kategorie_Diskussion_*" \
"+$sitepath/images/*" \
"+*.css"

echo "wget start"

for page in $(grep "link updated: $sitepath/index.php/" $backupdir/hts-log.txt | sed "s,^.*link updated: $sitepath/index.php/,," | sed "s/ ->.*//" | grep -v Spezial:)
do
wget -nv -O $backupdir/$sitepath/index.php/${page}_raw.txt "$topurl/index.php?index=$page&action=raw"
done

echo "wget done"

# Andreas repair css and js

wget -nv -O $backupdir/$sitepath/index.php/mediawiki.css "https://$site/mediawiki/load.php?lang=de&modules=skins.vector.styles.legacy&only=styles&skin=vect
wget -nv -O $backupdir/$sitepath/index.php/mediawiki.js "https:// $site/mediawiki/load.php?lang=de&modules=startup&only=scripts&raw=1&skin=vector"

FILES="$backupdir/$sitepath/index.php/*.html"
for html in $FILES
do
   echo "file: $html"
   sed -i -e  's|</head>|<link rel="stylesheet" href="mediawiki.css"/><script async="" src="mediawiki.js"></script></head>|' $html

done
#
# my html
cp /home/itmc-admin/index2.html  $backupdir/index.html
# Andreas Add Date
current_time=$(date "+%d.%m.%Y um %H:%M:%S Uhr")
sed -i -e  "s|<BODY>|<BODY><h1>Backup erzeugt durch cronjob am $current_time |"  $backupdir/index.html

# Andreas create ZIP File – cut here if you don’t need an zip Archive
# remove –passwort Option if the wiki content is public
rm  /home/admin/wiki-offline.zip
#cd $backupdir/mediawiki;
ln -s $backupdir /home/admin/wiki-offline
zip -r --password ******* /home/admin/wiki-offline.zip ./wiki-offline
rm /home/admin/wiki-offline
#cd /home/admin;
cp /home/admin/wiki-offline.zip /var/www/html/backup/

echo "geschafft"

 

Das Script ist an deutschsprachige Mediawiki-Installationen angepasst. Für andere Sprachen müssen die Links im Script für die sprachspezifischen Spezialseiten angepasst werden.
Wenn man das Script etwas modifiziert, kann das Script sicher auch für httrack-Abzüge von modernen WordPress-Sites verwendet werden. Relevant ist dann der Teil ab „# Andreas repair css and js“, der Links zu CSS- und Javascript-Dateien vor den abschließenden „head“-Tag ins HTML hineinoperiert. Wenn ich mal Lust habe, forke ich vielleicht httrack für eine Option auf der Kommandozeile, um direkt dort zusätzliche Javascript- und CSS-Links angeben zu können, die automatisch in jede Seite eingebaut werden.

Die Jitsi-/BBB-/ZOOM-Story – oder Videokonferenzen in der Covid19 Pandemie an der Universität Duisburg-Essen


Als kurz vor dem Lockdown der DFN-Verein (Deutsches Forschungsnetz) ankündigte, dass der DFN-Conf Videokonferenzservice für alle Eventualitäten gerüstet sei und keine Kapazitätsprobleme zu erwarten sind, war Fachleuten im ZIM sofort klar, dass die Kapazitäten niemals ausreichen werden. Der DFN-Verein hat in Vor-Corona-Zeiten Kapazitäten von gerade einmal 2000 gleichzeitigen Videokonferenzteilnehmern bereitgehalten. Bei über 400 angeschlossenen Hochschulen kann so eine geringe Kapazität nicht ausreichen, wenn der Dienst plötzlich stark nachgefragt wird.

Leider hat aber das zentrale Videokonferenzangebot des DFN dafür gesorgt, dass lokal an vielen Hochschulen keine eigenen Lösungen mehr vorgehalten worden sind. An der UDE war das anders. Unterstützt von den Kolleginnen und Kollegen im Bereich Lerntechnologien habe ich mir vor einigen Jahren diverse freie Videokonferenzsoftwarelösungen (z.B. OpenMeetings, Palava, Jitsi-Desktop) angeschaut. Openmeetings, ein freier Adobe Connect Clone, war einige Zeit im Testbetrieb an der UDE und damals noch Flash-basiert. OpenMeetings , Jitsi und BigBlueButton (BBB) nutzen WebRTC als Basistechnologie. BBB hat ähnlich wie OpenMeeting früher Flash als Video- und Audio-Übertragungstechnik eingesetzt.

Es war zu Beginn des Lockdowns nicht klar, wie die Hochschullehre im folgendem Semester organisiert werden kann. Sollte der Weg gewählt werden alle Vorlesungen einfach per Videokonferenz anzubieten oder nur in eine Richtung ohne Rückkanal für die Studierenden ein Stream anzubieten oder besser auf ein Learning Content Management System wie Moodle gesetzt werden, um die Lehre asynchron zu realisieren? Im (aus IT-Sicht) Worst-Case-Szenario würde man alle Veranstaltungen einfach per Videokonferenz anbieten. Allerdings kommen Videokonferenzlösungen dann sehr schnell an Ihre Grenzen. Wenn Sie beispielweise eine Videokonferenz mit 100 Teilnehmern veranstalten möchten, muss jeder Teilnehmer 99 Videobilder gleichzeitig empfangen können, was private Internetzugänge von der benötigten Bandbreite nicht hergeben. Deshalb reduzieren alle Videokonferenz-Werkzeuge die Anzahl der maximal gleichzeitig übertragenen Streams.  Teilnehmerzahlen von über 1000 sind so gar nicht zu realisieren. Bei einem normalen synchronen Vorlesungsbetrieb an einer Universität mit über 40.000 Studierenden ist das technisch mit Inhouse-Lösungen zu Spitzenlastzeiten möglicherweise auch nicht zu stemmen. Da sich aber die Hochschule für einen asynchronen Lehrbetrieb mit Moodle entschieden hat, verteilt sich die benötigte Bandbreite über den ganzen Tag und Lastspitzen werden vermieden.

Wir im ZIM haben uns dazu entschieden, mehrgleisig auf die neuen Bedarfe zu reagieren. Einerseits haben wir sehr rasch einen Jitsi-Server für WebRTC-Videokonferenzen aufgesetzt und später Lizenzen für ZOOM-basierte Videokonferenzen in der Cloud beschafft. In der Fakultät Biologie hat Ken Dreger zeitgleich damit begonnen den WebRTC-Dienst BigBlueButton zu evaluieren. Dieser Dienst wurde später gemeinsam mit der Fakultät Biologie, der Wirtschaftsinformatik und dem ZIM auch hochschulweit in den Betrieb genommen. Ein spezieller BBB-Server für die Gremienarbeit, der für alle Teilnehmer eine Anmeldung mit der Unikennung erzwingt, wurde ebenfalls realisiert.

Bei der eingekauften proprietären Lösung ZOOM liegen die live Audio- und Video-Streams Prinzip bedingt beim Anbieter auf dem Vermittlungsserver unverschlüsselt vor. Um auch Konferenzen zu ermöglichen, in denen personenbezogene Daten oder anderweitig schützenswerte Inhalte ausgetauscht werden, wurde im ZIM auch ein sogenannter „on-premise“ ZOOM-Server installiert, bei dem alle Audio-und Videodaten unverschlüsselt nur auf einem Server in der Hochschule vorliegen. Um die Sammlung von Metadaten durch den Anbieter zu verhindern, ist nun auch eine völlig anonyme Anmeldung der Initiatoren einer Zoom-Videokonferenz im ZIM realisiert worden. Wenn allerdings auch nur ein Teilnehmer per Telefon oder WebRTC an einer Konferenz auf dem ZOOM-on-premise-Server teilnimmt, werden im ersten Fall Audio und im zweiten Fall auch das Video der Konferenz über ZOOM-Server in die Cloud geleitet. Die Daten, die Sie darüber hinaus in Ihrem ZOOM-Profil pflegen und auch die Aufzeichnungen dort, verantworten Sie aber als Lehrende selber.

WebRTC (Web Real Time Conferencing)

WebRTC, also Echtzeitkonferenzen im Browser sind heute in allen aktuellen Browsern nutzbar, selbst der Microsoft Browser Edge und Apples Safari beherrschen das mittlerweile gut. Dazu ist in den Webbrowsern Programmcode integriert, der auf die Webcam und das Audio-Interface (Mikrofon/Lautsprecher) zugreift, Ton und Video komprimiert (kodiert) und empfangene Daten dekomprimiert (dekodiert).  Diese Softwarekomponente wird CODEC (von coding und decoding) genannt. Wegen der im WebRTC-Standard notwendigen Interoperabilität der verschiedenen Browser muss die das W3C-Standartisierungsgremium (World Wide Web Consortium) auf CODECs einigen, die von allen Browser-Herstellern unterstützt werden (VP8, H264 für Video und Opus, G711 PCMA und PCMU für Audio). Da die beiden führenden Browser mit einer Open Source-Lizenz entwickelt werden, müssen auch die verwendeten CODECs Open Source sein. Und hier zeigt sich der wesentliche Unterschied zu proprietärer Videokonferenz Software wie z.B. Zoom. Diese muss nicht mit anderer standardisierter Software zusammenarbeiten, ist nur für diesen einzigen Zweck geschrieben worden und kann auch hochwertige kommerzielle Closed Source CODECS einsetzen, die eine höhere Kompression ermöglichen. Insofern ist der Vergleich der Audio- und Video-Qualität von WebRTC basierten Lösungen mit proprietären, nicht interoperablen Lösungen müßig. WebRCT-basierte Videokonferenzen mit BBB und Jitsi werden an der UDE über Uni-eigene Server abgewickelt. Weder Metadaten (wer kommuniziert mit wem) noch Inhalte können auch dem über sichere HTTPS abgesicherten Transportweg abgehört werden. Eine echte Ende-zu-Ende Verschlüsselung kann Prinzip bedingt auf einfache Weise nun zwischen zwei Kommunikationspartnern realisiert werden. Jitsi bietet beispielsweise so eine Möglichkeit. Wenn Sie zu zweit eine Jitsi-Konferenz durchführen, werden weder Ton noch Bild über den Jitsi-Server der UDE geleitet. Sie kommunizieren dann direkt Ende-zu Ende verschlüsselt und kein Geheimdienst dieser Welt kann sie abhören, sofern sie Ihrem PC und dem installierten Betriebssystem vertrauen können.  Eine Ende-zu-Ende Verschlüsselung mit mehr als zwei Teilnehmern ist viel schwieriger zu realisieren, da dann beim Verbindungsaufbau ein geheimer Session-Schlüssel mit allen Teilnehmern ausgetauscht werden müssen, den der zentrale Server nicht mitbekommen darf.

Ein weiterer Vorteil der WebRTC-Dienste ist die einfache Integration in vorhandene Webdienste wie z.B. Moodle und Rocket-Chat.

In Webbrowsern sind Sicherheitsmechanismen eingebaut, die verhindern sollen, dass eine Browser-Nutzerin oder ein Nutzer heimlich beim Besuch einer Webseite abgehört wird. Deshalb fragen die Browser immer nach, ob der Zugriff auf Kamera, Mikrofon und gegebenenfalls den Desktop, falls etwas präsentiert werden soll, durch den Nutzer erlaubt wird. Die Freigabe wird für jeden Server einzeln gespeichert und kann auch widerrufen werden. Im Falle von BBB sind das aber 10 verschiedene Server auf die, je nach aktueller Last, verwiesen wird. Leider ist das für ungeübte Nutzer eine zusätzliche Fehlerquelle bei webbasierten Videokonferenzen. Übrigens unterstützt auch ZOOM den Zugang über WebRTC zu Videokonferenzen ohne Installation des ZOOM-Clients. Allerdings ist diese Funktion (möglicherweise beabsichtigt) etwas versteckt und funktioniert nicht so zuverlässig wie von Jitsi und BBB gewohnt.

WebRTC-Probleme mit Mikrofon, Kamera oder Netzwerkanbindung können Sie auf dieser Testseite ganz hervorragend eingrenzen: https://test.webrtc.org/

Beschränkte Internetzugänge

Alle hier beschriebe Dienste funktionieren nun auch über extrem limitierte Internetzugänge, wie z.B. dem Verwaltungsfirewall der UDE oder in NAT-Netzen mit privaten Internet-Adressen. Auch die von Providern gerne verkauften limitierten DSLite-Internetzugänge stellen kein Problem mehr dar. Sofern auch nur der Port 443 für HTTPS offen ist, lassen sich Jitsi und BBB nutzen. Ermöglicht wird das durch im ZIM betriebene STUN und TURN-Server, die bei solchen limitierten Zugängen für eine „Vermittlung“ zwischen Client und Server sorgen. Auf wenn diese „Vermittlung“ wegen einem beschränten Internetzugang beim Verbindungsaufbau benötigt wird, bleibt die oben erwähnte Ende-zu-Ende-Verschlüsselung bei Jitsi mit zwei Teilnehmern intakt.

Echtzeit Videokonferenz versus Live-Stream versus Stream einer Konserve

Häufig wird die Qualität einer Videokonferenz an Streaming-Angeboten für vorher aufgezeichnete und komprimierte  Videokonserven wie Netflix oder Youtube gemessen. Da bei einer Videokonferenz die Latenz höchsten 150 Millisekunden betragen darf, ist der technische Aufwand aber bei einer Konferenz ungleich höher als bei einem Live- oder Konserven-Stream.  Bei höheren Verzögerungen fallen sich die Teilnehmerinnen unabsichtlich ins Wort, weil sie von einer Sprechpause des Gegenübers ausgehen. Bei einem (Live) Stream ist es völlig egal, ob er erst nach 10 Sekunden beginnt und der CODEC die Zeit für eine verbesserte Kompression und für ein Puffern (Buffering) nutzen kann, welches Latenz und Jitter (Verzögerungen und ungleichmäßige Übertragung in Paketen) überbrücken kann. Insofern ist es für eine Streaming-Anwendung im Gegensatz zu einer Videokonferenz auch gleichgültig, ob LAN oder WLAN eingesetzt wird, wenn nur die verfügbare Bandbreite insgesamt ausreicht. Die Kompression über eine lange Pufferzeit spart viel Übertragungsbandbreite, weil der CODEC nur Blöcke im Bild neu übertragen muss, in denen sich etwas ändert. Der CODEC kann in einem langen Puffer auch Blöcke zwischenspeichern, was schnelle Bewegungen im Vordergrund bei wenig Veränderung im Hintergrund abfedert. Daher schaffen Streaming-Dienste es, eine höhere Videoqualität mit geringerem Bandbreitenbedarf zu übertragen, als es in Videokonferenzen möglich ist. Und hier wird bisher nur ein wirklicher Live-Stream mit einer Echtzeit-Videokonferenz verglichen. Wenn eine Quelle als Konserve vorliegt, kann mit speziellen CODECS vorher offline komprimiert werden, da der CODEC dann “alle Zeit der Welt” hat, um das Video vorab zu komprimieren. Hochkomprimierende offline-CODECS für Konserven benötigen dazu ein Vielfaches der Laufzeit des Videos und sind deshalb für Live-Anwendungen nicht geeignet. All das ist einem CODEC für Echtzeit-Videokonferenzen nur eingeschränkt oder im Fall der Konserve gar nicht möglich.

Welches Tool für welche Anwendung?

Für eine spontane kleine Videokonferenz oder selbstorganisierte Lerngruppen von Studierenden ohne große Organisation eignet sich besonders Jitsi, da gar keine Zugangsdaten eingegeben werden müssen und man sich den Raum, also die URL einfach ausdenken kann. Z.B. https://jitsi.uni-due.de/spontanestreffen funktioniert sofort und weltweit. Der erste Teilnehmer kann auch die Eingabe eines Passwortes erzwingen, so dass sichergestellt werden kann, dass der Nutzerkreis eines Raumes eingeschränkt wird. Ein spezieller Datensparmodus ermöglicht auch die Teilnahme ausschließlich per Audio, so dass notfalls auch ein sehr limitierter Internetzugang, beispielsweise ein stark volumenbeschränkter LTE-Zugang, ausreicht.  Für Android und IOS gibt es jeweils auch eine komfortable Jitsi-App. Auch ein Streaming-Server für automatisierte Streams ist im ZIM an Jitsi angebunden worden. In der aktuellen Jitsi-Version ist es auch möglich eine sehr große Teilnehmerzahl mit zunächst abgeschalteten Mikrofonen und Kameras beitreten zu lassen, wenn der Moderator (Initiator) dieses in den Einstellungen festlegt. Der Moderator ist aber auf die Disziplin der Teinehmer angewiesen. Schauen Sie sich für Details die Dokumentation auf den ZIM-Seiten zu Jitsi an. Für Konferenzen ab ca. 10 Teilnehmern nutzen Sie aber besser BBB, dass dem Moderator wesentlich mehr Möglichkeiten bietet.

Für sehr komfortable Konferenzen in BBB mit guter Präsentations- und Moderationsmöglichkeiten ist es erforderlich, dass zumindest die/der Einladende sich mit Unikennung und Passwort am BBB-Server anmeldet um einen Meeting-Raum zu erstellen. Die Berechtigung dazu muss vorher dazu vergeben werden, wenden Sie dafür an die Hotline des ZIM. Sowohl für Jitsi als auch BBB (Gremienserver) ist im ZIM eine Telefoneinwahl mit FreePBX (Asterisk) realisiert worden.

Über den Microsoft-Bundesvertrag haben Sie darüber hinaus auch die Möglichkeit kostenfrei MS-Teams zu nutzen. Dazu müssen sie aber als Einzelperson die Vertragsbedingungen von Microsoft akzeptieren und ein MS-Office365-Konto anlegen. Das ist allerdings kein Dienst des ZIM und wir können keinen Support oder eine Datensicherung dazu anbieten. Damit Studierende und Lehrende dort überhaupt zusammenarbeiten können, war eine Zusammenlegung der Tenents für Mitarbeiter und Studierende der UDE durch Kollegen im ZIM notwendig. Sie sind persönlich verantwortlich, wenn Sie in der Microsoft-Cloud dienstliche personenbezogene Daten speichern und verarbeiten. Bedenken Sie dabei die DSGVO und die vom EUGH „gekippte“ Privacy Shield Regelung. Aktuell hält ein Arbeitskreis der Datenschutzkonferenz  den rechtskonformen Einsatz von Microsoft 365 in öffentlichen Institutionen für unmöglich.

Auch der DFN-Conf-Dienst scheint nun wieder zuverlässig zu funktionieren. Ob er allerdings dem Semesterbeginn Stand hält, bleibt aber abzuwarten.

Den ZOOM-Cloud-Dienst können Sie für Lehre einsetzen, sofern Sie keine Datenschutzbedenken haben. Bei Dienstbesprechungen dürfen Sie ausschließlich Dienste einsetzen, die an der UDE betrieben werden, d.h. Jitsi, BBB oder ZOOM mit dem „on-premise“-Server. Für Gremiensitzungen empfehlen wir ausdrücklich den BBB-Gremienserver, da dort bei der Anmeldung jeder Teilnehmer mit Unikennung und Passwort authentifiziert wird.

Was alles schiefgehen kann – die drei Feinde der Videokonferenz:

  • Latenz und Jitter
    Wenn Sie am Teilnahmeort eine LAN-Verkabelung haben, nutzen Sie diese auch! Im WLAN haben Sie immer ein geteiltes Medium, daheim mit Nachbarn und Familienangehörigen an der Uni mit Kollegen und Studierenden, die unvermittelt und unabsichtlich für kurzfristige Verzögerungen beim Datentransfer sorgen. Selbst wenn Sie ganz allein einen WLAN-Router nutzen und wirklich Niemand mit einem Gerät in der Nähe ist, fangen Sie sich durch das WLAN eine vermeidbare zusätzliche Latenz (also Verzögerungen) ein. Sowohl bei der Telefonie als auch bei einer Videokonferenz akzeptieren Menschen eine Latenz von höchstens 150 Millisekunden. Bei höheren Verzögerungen fallen sich die Teilnehmerinnen unabsichtlich ins Wort, weil sie von einer Sprechpause des Gegenübers ausgehen. Schlimm wird es auch wenn Sie sich den WLAN Funkkanal teilen und Audio- und Video-Pakete unregelmäßig verzögert ankommen (Jitter), da dann Aussetzer in Ton und Bild vorkommen.
  • Rückkopplungen
    Benutzen Sie bei Videokonferenzen immer ein Headset oder zumindest einen Kopfhörer. Ansonsten kann es passieren, dass ihr Mikrofon den Ton aus Ihrem Lautsprecher aufnimmt und so ein Echo der aktuell Sprechenden erzeugt, was speziell für den Sprecher aber auch für alle Teilnehmerinnen sehr unangenehm ist. Im schlimmsten Fall erzeugen sie sogar einen unangenehmen Pfeifton, der sich immer weiter aufschaukelt. Moderne Videokonferenzsysteme versuchen solche Echos per Software zu unterdrückten, was aber nicht immer zuverlässig funktioniert. Auch eine schlechte Entkopplung von Mikrofon und Lautsprecher in einem minderwertigen Headset kann so eine Rückkopplung auslösen. Einige Bluetooth-Headsets vertragen sich nicht gut mit dem WAN-Chipsatz mancher Notebooks und können so für zusätzliche Latenz sorgen. Wenn Sie über kein Headset verfügen, schalten Sie Ihr Mikrofon immer ab, wenn Sie nicht selber sprechen.
  • Bandbreite Zuhause / der gebuchte Tarif und die Wirklichkeit
    Internet-Provider überbuchen ihre verfügbare Bandbreite, weil sie davon ausgehen, dass nicht alle ihre Kunden den Zugang gleichzeitig mit der gebuchten Maximalgeschwindigkeit nutzen. Deshalb können Sie nicht davon ausgehen, dass Ihnen wirklich die gebuchte Bandbreite immer zur Verfügung steht. Derzeit sind durch massive Homeoffice-Nutzung viele Internetprovider überlastet.  Unter unter https://www.uni-due.de/zim/speedtest/ können Sie testen, wie schnell Ihr Internetzugang wirklich ist.  Auch kurzfristige Verzögerungen und Jitter durch einen geteilten Zugang können Probleme verursachen. Ihre Internetverbindung ist immer der Flaschenhals, ganz selten der Server. Fast alle privaten Internetzugänge sind asynchron konfiguriert, d.h. die Daten von Ihrer Webcam bzw. Audio sind im Upstream (also von Ihnen aus zum Server) begrenzt. Vermeiden Sie die zeitgleiche Nutzung auch durch Familienmitglieder von anderen Internetdiensten während einer Videokonferenz. Wählen Sie immer eine geringe Videoauflösung, sofern die VC-Software das erlaubt. Die Tonübertragung benötigt sehr viel weniger Bandbreite als ein Videobild. Wenn es in einer größeren Konferenz Probleme gibt, sollte nur der aktuell Sprechende ein Videobild senden. Notfalls sollten Sie ganz auf Video zugunsten der Audiokonferenz verzichten.
    Alternativ können Sie Ihren Router daheim so konfigurieren, dass die Bandbreite fair aufgeteilt wird. Das funktioniert rudimentär mit jeder Fritz-Box  und ganz ausgezeichnet mit einem Router der mit der Open Source DD-WRT-Firmware (Einstellung unter NAT/QoS) betrieben wird. Die Fritzboxen priorisieren in der Default-Einstellung Dienste, die sie für Echtzeitanwendungen halten, allerdings liegen sie dabei häufig falsch. Beispielsweise wird der Dienst Wetransfer von Fritzboxen als Echtzeitanwendung priorisiert und killt bei einem großen Upload dann gerne gleichzeitig ablaufende Videokonferenzen. In der DD-WRT-Routerfirmware ist, im Gegensatz zu OpenWRT , die Priorisierung komfortabel konfigurierbar, ohne dass Software nachinstalliert werden muss. Möglichweise haben Sie noch ein älteres unterstütztes Gerät herumliegen, dass Sie für diesen Zweck weiterverwenden können.

Smartphones in Uni-Netz – die mobile Herausforderung


Im Jahre 2005 war noch kein iPhone in Sicht, trotzdem gab es schon lange vorher innovative Smartphones. Verbreitet waren vor 10 Jahren Geräte der Hersteller HTC mit Windows Mobile 2003 oder Nokia mit Symbian als Betriebssystem, die per Stift oder Tastatur bedient wurden. Die “Windows Mobile” Geräte hatten Bezeichnungen wie MDA oder XDA. Das Webforum XDA-Developers stammt übrigens aus dieser Zeit. Einer der Benutzer des Forums mit dem Namen Cyanogen veröffentlichte dort 2009 eine Android-Modifikation, die heute Basis für die führende Open-Source Android-Distribution ist. Der Marktführer bei Feature- und Smartphones war Nokia mit Geräten, die schon 2005 sowohl WLAN als auch Voice over IP unterstützten. Smartphones waren damals aber sehr teuer und Managern bzw. Firmenkunden vorbehalten. UMTS-Datenverträge schlugen mit wenig studierendenkompatiblen Preisen von weit über 60 € im Monat zu Buche.

Und heute?

Heute ist gibt es Datenflats für 2,95 € monatlich und das mobile Internet ist in den Ballungsräumen überall verfügbar. Es gibt kaum noch Mobilfunknutzer/-innen, die kein Smartphone verwenden. Für viele junge Menschen ist das Smartphone das zentrale Gerät für den Internetzugang und die Kommunikation. Ortsbezogene Dienste sind heute allgegenwärtig. Nutzerdaten für ortsbezogene Werbeprofile sind die Währung, in der heute Dienste und Apps bezahlt werden.

Wo geht es in Zukunft hin?

In der Rückschau sieht man, dass neue Technologien nicht von heute auf morgen etabliert werden, sondern dass sich die Entwicklung immer lange vorher abzeichnet. Allerdings ist immer schwer zu erraten, wohin die Reise wirklich geht. Während 2006 angenommen wurde, dass Mobiltelefone immer kleiner werden, ist derzeit das Gegenteil der Fall. Die Displays werden größer und hochauflösender. Die Nutzer wollen nicht irgendwelche Mobilseiten sehen, sondern “das ganze Internet”. Das ist übrigens das Argument, mit dem das erste iPhone beworben wurde. Andererseitshaben sich andere Vorhersagen bezüglich der Sprachein- und ausgabe für Smartphones bewahrheitet (Andreas Bischoff, Virtual Reality und Streaming-Technologien in der webbasierten multimedialen Lehre und für Ubiquitous Computing, BoD 2006.).

Die Zukunft von gestern, eine Celluon Lasertastatur an einem Campaq iPaq im Jahre 2005 - heute baut diese Firma Laser-Projektoren

Die Zukunft von gestern, eine Celluon Lasertastatur an einem Campaq iPaq im Jahre
2005 – heute baut diese Firma Laser-Projektoren

Neue mobile Anwendungen auch fürs lernen
Mobile Augmented Reality Anwendungen werden in Zukunft den Endkundenmarkt erreichen. Google bereitet mit den Produkten Glaces und Cardboard den Markt für solche Applikationen. Die Rechen- und Grafikleistung der mobilen Geräte öffnet diesen Technologien den Einsatz auf Geräten. Für die Hochschule können diese Entwicklungen im Bereich mobiles Lernen zukünftig sehr interessant werden. Mit ein wenig Fantasie lassen sich ganz neue mobile ortsbezogene Lernszenarien realisieren. In wenigen Jahren werden möglicherweise AR-Brillen mit Mobilfunkanbindung den Campusalltag dominieren. Interessant ist auch die mögliche Integration von neuen laserbasierten Projektoren in Mobiltelefonen.

VR-Brille realisiert mit DIVE und Smartphone     VR-Brille realisiert mit DIVE und Smartphone

VR-Brille realisiert mit DIVE und Smartphone

Also alles gut?

Ein weiteres Zukunftsthema wird mobile Security werden. Ähnlich wie Windows auf dem Desktop ab Ende der 90er Jahre Ziel von Angriffen über das Internet wurde, blüht dieses Schicksal nun Android als dominierender Betriebssystemplattform für Smartphones. Ist ein Smartphone erst einmal von Malware durchdrungen, ist es ein Leichtes, diese Geräte und so die Nutzer zu verfolgen, persönliche Kontaktdaten und Passwörter abzugreifen oder das Telefon gar als Abhörwanze zu betreiben. Die Hersteller haben wenig Interesse daran, für Security-Updates zu sorgen, nachdem die Geräte erst einmal verkauft worden sind. Die großen Gewinner der Smartphone-Welle sind Konzerne wie Apple, Google und Amazon, die Nutzerdaten aggregieren und verkaufen. Die digitale Spaltung der Gesellschafft setzt sich im Mobilbereich fort. Aufgeklärte, kreative Nutzer beherrschen die Technologie, „rooten“ ihre Geräte, sind in der Lage Security-Fixes zu installieren und Werbeangebote zu blockieren, während das Gros der Anwender der Technologie und den Konzernen hilflos ausgeliefert sein wird. Information ist der Rohstoff des
21. Jahrhunderts und die Nutzer/-innen sind, wie auch in den sozialen Netzwerken, die eigentliche Ware. Ein erschreckendes Beispiel dafür ist Google. Der Dienst Google Now speichert beispielsweise die „Ok Google“ Sprachsuchen aller Nutzer für immer als Audio-Datei ab, sofern der Suchverlauf in den Benutzereinstellungen aktiviert ist.

Der große Datendurst


Die attraktiven neuen mobilen Dienste benötigen höhere Übertragungsbandbreiten und der mobile Datendurst steigt rasant an. Die Netze lassen sich aber nicht beliebig leicht ausbauen. Bezüglich der für den Mobilfunk freien Frequenzen setzt die Physik Grenzen durch die notwendigen Antennengrößen bei niedrigeren und der höheren Dämpfung bei höheren Frequenzen. Die Deregulierung der nutzbaren Frequenzbänder kann da nur wenig Abhilfe schaffen. Der prognostizierte exponentielle Anstieg der Datenmenge in den mobilen Netzen kann nur durch eine erhöhte Dichte von Mobilfunkantennen mit kleinerer Reichweite, mit sogenannten Femtozellen realisiert werden. Es ist durchaus denkbar, dass in einigen Jahren das ZIM neben WLAN-Accesspoints auch solche Femtozellen am Campus installieren wird. Die Mobilfunkprovider reagieren auf den Kapazitätsengpass mit einer Kontingentierung des Datenvolumens. Das Argument, durch das immer verfügbare schnelle LTE-Mobilfunknetz werde die „alte“ WLANTechnologie überflüssig, relativiert sich durch die Limitierung durch Volumentarife. Daraus folgt für die Hochschule, dass der Ausbau von WLAN als Alternative zu LTE mit hoher Priorität vorangetrieben werden muss. In Zukunft muss dabei auf den 5GHz-Frequenzbereich mit seinen höheren Datentransferraten und Kanälen fokussiert werden, um eine hohe Qualität für die Nutzung zu gewährleisten. Es ist zu erwarten, dass bald alle Smartphone-Hersteller den überlegenen 5GHz 802.11ac-Standard unterstützen werden. Innovative Verfahren, wie die auch für das „Freifunk“ eingesetzte WLAN-Mesh-Funktechnik werden zukünftig auch auf dem Campus eine große Rolle spielen. Vielleicht wird das Bandbreitenproblem auch durch sich selbst organisierende Mesh-Netze, bestehend aus den Smartphones der Nutzer, zu lösen sein. Die technischen Voraussetzungen bringt das Linux-basierte Android zumindest theoretisch mit. Man darf gespannt sein!

Diesen Artikel hatte ich ursrünglich für die Broschüre 10 Jahre ZIM an der Universität Duisburg-Essen erstellt.

 

Wikipedia wird mit HTTPS sicherer – Reparaturarbeiten am Pediaphon


Durch eine Anfrage eines Nutzers bin ich auf Probleme mit der Textkodierung der Pediaphon-Funktion „eigene Texte sprechen“ aufmerksam geworden. Nur ist diese Funktion auch in der Lage weiche Trennstriche, wie sie beispielsweise per Cut&Paste aus Word in das Eingabefeld kommen, zu erkennen und nicht mitzusprechen. Eine Stimme hat diese weichen Trennstriche als „bedingter Trennstrich“ oder als „Verneinung“ mitgesprochen. In Word wird das Negationszeichen, also wortwörtlich die “Verneinung” als weiches Trennzeichen verwendet.

Nach der Reparatur fiel mir ein auch einmal zu testen, ob das Sprechen von Wikipedia-Artikeln noch funktioniert, nachdem die Wikipedia, wie viele andere Webseiten nach den Snowden-Enthüllungen auch, nun nur noch per HTTPS abzufragen ist. Und tatsächlich, der Redirect von HTTP auf die entprechende HTTPS-Artikelseite führt in den Pediaphon-Scripten zu einem Problem, so dass bei allen Anfragen nur noch der normalerweise am Endes des Artikels angehängte Erklärungstext gesprochen wurde. Die Ursache war schnell gefunden, die Änderung für alle Sprachen und Stimmen zu realisieren war aber etwas aufwendiger, da alle Sprachvarianten betroffen waren.

Bei den folgenden Tests ist mir sofort ein weiteres kleines Problem aufgefallen. Vor einigen Monaten hatte ich beschlossen, die Audoausgabe defaultmäßig von Flash auf HTML5 umzuschalten, da mittlerweile fast alle mir bekannten Browser den MP3-Codec im HTML5-Audio-Tag unterstützen und Flash deshalb (und wegen der ständigen Sicherheitslücken) als Webtechnik in den Mülleimer der Geschichte gehört. Übrigens unterstütze ich HTML5-Audio für das Pediaphon schon seit Firefox 3.5 ( 2010). Allerdings mussten die Nutzer diese Option bisher aktiv auswählen.

Beim Einsatz HTML5-Audio weigern sich aber Firefox und andere Browser (neuerdings?) trotz “Pragma” „no-cache“ im HTML-Header die vom Pediaphon generierten Audio-Dateien immer neu zu laden. Die Audio-Repräsentation z.B. des Artikels zu Edward Snowden heißt im Pediaphon immer edward_snowden.mp3, auch wenn zwischendurch Parameter wie Stimme und Sprechgeschwindigkeit verändert werden. Flash, Java und Windowsmedia können durch Parameter dazu gebracht werden, die Datei immer frisch nachzuladen. HTML5-Audio weigert sich aber beharrlich und spielt den Inhalt aus dem Cache ab, auch wenn manuell die Datei per Reload in einem neuen Fenster nachgeladen wurde. Abhilfe schafft ein Trick: Den Dateien ist im URL ein Parameter angehängt, der einen Zufallswert mitliefert:

 

edward_snowden.mp3?z=<zufallswert>

 

Der Browser lädt dann die richtige Datei, hält sie aber durch den geänderten URL für eine andere. So wir nun auch HTML5-Audio im Browser dazu bewogen dynamische MP3- oder Ogg-Dateien nachzuladen und nicht die Datei aus dem Cache zu verwenden. So funktioniert das Pediaphon wieder wie gewohnt.

 

me@market – die Pediaphon-App im Android-Market


Die neue Pediaphon-App ist nicht wirklich meine erste App im Android Market, aber die erste komplette Eigenentwicklung. Das geht wirklich Ruckzuck im Android-Market, 25 $ kostest es und eine viertel Stunde später ist man Entwickler und kann Apps in den Market einpflegen. Etwas verwirrend für den Neuling ist eine Verzögerung im Market beim Versionswechsel der Apps. Mit besonderer Sorgfalt sollte auch die Manifest-Datei erstellt werden damit nicht unnötig Benutzer kleiner Displays (320×240) und älterer Android-Versionen ausgesperrt werden. Die Pediaphon App bietet eine ähnliche Funktionalität wie die Online-Variante, nur ist für ein mehr “App-mäßiges Look-and-Feel” Ajax eingesetzt worden. Die MP3-Dateien kommen weiterhin vom Pediaphon-Server, also neudeutsch aus der Cloud.

Da für die Audio-Wiedergabe HTML5 eingesetzt wird, funktioniert die App erst richtig gut mit Android 2.3 Gingerbread. Mit 2.2 Froyo kann aber, wenn es denn das Endgerät hergibt auch auf FLASH bzw. reinen MP3 download ausgewichen werden. Android Versionen 2.1 und älter habe ich zunächst einmal ausgesperrt, evt. gibt es dafür später eine angepasste Version.

UPDATE: Die App läuft jetzt mit nativem Audio, d.h. Android ab Version 2.1 wird unterstützt.

Wenn man diesem Golem-Artikel glauben schenken darf, sind ein Großteil der Android-Nutzer schon mit 2.2 und 2.3 unterwegs. Ich halte das nicht für eine sehr realistische Einschätzung, mein ältestes Android-Gerät (ein SmartQ5) läuft unter Cupcake 1.5, ich bin aber auch schon länger dabei ;-) .

Hier der Link in den Android-Market im Web: http://market.android.com/search?q=Pediaphon
Die “offizielle” App-Seite (engl. da für alle Sprachversionen nur ein Entwickler-Link angegeben werden kann): https://blog.robotnet.de/pediaphon-app-for-android/
Viel Spaß mit der kostenlosen Pediaphon-Android-App!

Technisch wäre die App auch sehr leicht für IOS, also für iPhone und iPad umzusetzen, aber Apple verlangt ja recht happige Gebühren für Entwickler und ich müsste dafür für ein Stündchen an einen Intel-Mac, den ich leider nicht in Reichweite habe. Leider erlaubt Apple ja keine (professionelle) Crosscompilation auf anderen Betriebssytemen als MacOS.

Pediaphon QR-Code mit Android-Market Link für das Smartphone

Das Pediaphon-App im Android Market

Die Pediaphon-App im Android Market

Die Pediaphon-App

Das Pediaphon mit neuem Touch-Interface für Android, iPhone, iPad und iPad


Weil die HTML5-Audiounterstützung nun auf Android 2.3 Gingerbread ebenso gut funktioniert wie unter iOS auf den Apple-Mobilgeräten, war ich neugierig ob sich die gemeinsame Basis der beiden Welten (der Android-Webbrowser basiert ebenso wie der Safari-Browser auf der freien Webkit Rendering Engine) für eine HTML-basierte, an die Touch-Bedienung angepasste, eigene Oberfläche eignet. Die Ansicht, die Entwicklung von plattformübergreifenden HTML-basieren Anwendungen gegenüber nativen APPs zu favorisieren, vertrete ich schon seit langem. Besonders für e- und m-learning Anwendungen ist eine Standardisierung nützlich um zu verhindern, dass im Hochschulbereich immer knappe Entwicklungskapazitäten an einzelne Endgeräte verschwendet werden. Wiederverwendbarkeit und langer Lebenszyklus sind bei Web-basierten Anwendungen eher sicherzustellen als bei nativen APPs.

Ich wollte ursprünglich Sencha Touch einsetzen  bin aber durch einen Kollegen auf iWebkit aufmerksam geworden. iWebkit besticht durch seine Einfachheit in der Anwendung, schon rudimentäre HTML-Kenntnisse reichen aus um eine iWebkit-Seite zu erstellen. Auf dem iPhone und iPad sehen iWebkit-Seiten aus wie eine native APP und sie laufen auch ganz fabelhaft  auf Android- Nokia S60- Palm Pre- und Openmocko, basierten Geräten.

Als beispielhafte Anwendung wird hier ein eigenes Pediaphon-User-Interface für Webkit-basierte Mobilbrowser vorgestellt. Die Audioausgabe wird hier mit HTML5 realisiert, für Android 2.2 Froyo basierte Telefone gibt es auch eine Flash Alternative.

Hier einige Screenshots vom GUI (Auf einem Android 2.3 Gingerbread Emulator, aber auch schon live mit einem Orange San Francisco getestet):

Screenshot 1 Pediaphon iWebkit auf AndroidScreenshot 2 Pediaphon iWebkit auf Android

Screenshot 3 Pediaphon iWebkit auf AndroidScreenshot 4 Pediaphon iWebkit auf Android

Ausprobiert werden kann das Pediaphon iWebkit-Interface hier in Deutsch und in Englisch, Spanisch, Französisch und Italienisch.

HTML5-Audio für das Pediaphon nun auch mit Android 2.3 Gingerbread


Nachdem Apples iPad nun HTML5-Audio unterstützt habe ich lange auf das HTML5-Feature in Android gewartet. Nachdem ich einen enttäuschenden Kommentar zum neuen Gingerbreads-Browser gelesen habe, wollte ich wissen ob Audio-Streaming nun wenigstens funktioniert.

Der in Android 2.3 Gingerbread enthaltene Webkit-Browser unterstützt nun endlich auch HTML5-Audio. Sowohl MP3 wie auch der freie OGG-Container werden von Android unterstützt. Ausprobiert habe ich das mit dem Emulator des aktuellen Android-SDKs mit mp3-Audiodateien generiert von meinem Pediaphon, der Online-Sprachausgabe für die Wikipedia.

Android Gingerbread HTML5 audio

Android Gingerbread Emulator spielt HTML5-Audio im Browser

Mobile Learning Day 2010


Ich besuche heute den Mobile Learning Day 2010 an der FernUniversität in Hagen und moderiere dort ab ca. 14 Uhr eine Podiumsdiskussion zum Thema Mobile Learning Projekte aus der Wirtschaft.

Teilnehmer der Diskussion:
Dr. Matthias Kose, mobilinga GmbH
Karsten Meier, handylearn projects
Sandro Mengel, FernUniversität in Hagen

Update:

Mein Einstiegsgag mit dem Hinweis, dass wenn im Bundestag jetzt auch iPads verwendet werden dürfen, es mir ja gestattet sein dürfte meine Notizen von einer Lochkarte abzulesen kam im Publikum und bei Twitter sehr gut an. Sehr interessante Diskussion zum Einsatz IOS vs. Android vs. Plattformunabhängige Entwicklung von Content mit z.B. HTML5. Ich habe dort auch auf aktuelle günstige Android-Hardware und aktuelle Prepaid Internet-Flat Tarife hingewiesen.

Von Maciej Kuszpas Blog

(Foto Maciej Kuszpa. Im Blog des Organisators und Masterminds des Mobile Learning Day gibt es noch mehr Fotos)


(Dank an Oliver Baentsch von der FernUni Webredaktion für Fotos und den Tweed)

Rückblick auf den Mobile Learning Day 2010 auf der FernUni-Presseseite.

Pioneer Roboter im UMTS-Netz als Server, nun weltweit einsetzbar unabhängig von WLAN-Netzen


Die Fernbedienung des Pioneer 3 AT Mobilroboters über Mobiltelefone habe ich
bereits 2006 realisiert. Nun ist nicht nur das Telefon sondern auch der
Roboter über das UMTS-Netz direkt an das Internet angebunden. Damit der
Roboter als Server agieren kann, was im UMTS-Netz wegen privater IP-Adressen
eigentlich nicht möglich ist (wahrscheinlich als Sicherheitsfearture
gedacht), sind mehrere SSH-Tunnel zu einem öffentlich erreichbaren Rechner
aufgebaut worden, so dass Kommandos und Video-Stream an beliebige Clients
(auch in das UMTS-Netz) weitergeleitet werden können. Wenn die
UMTS-Netzversorgung nicht gegeben ist, findet ein Fallback zu GPRS statt
(grüne LED anstatt Blau für UMTS, siehe Bild). Angebunden ist der Pioneer
über ein Huawai E169 USB-UMTS .Modem (in USB-Stick Bauform auch unter dem
Namen Vodafone Mobile Connect Model K3520 HSDPA USB STICK ohne Simlock im
Handel erhältlich). Beide Geräte (der PDA und der Roboter) arbeiten zur Zeit
im D1-UMTS-Netz (MoobiAir), für das hier am Lehrgebiet zwei
Datenflat-Verträge verfügbar sind.
Für die Unterstützung des HUAWEI E169 musste der Linux-Kernel des Roboters
auf die Version 2.6.18 gebracht werden. Die Einwahl übernimmt hier wvdial
auf der Konsole, mit usbmodeswitch muss das Modem noch zur Zusammenarbeit
mit Linux überredet werden, da es sonst nur als ‘usb storage’ (was wohl als
Feature für die Erstinstallation der Windowstreiber gedacht war) erkannt
wird.

Das Pediaphon als Exponat der FernUniversität auf der Learntec 2007


Ich präsentiere das Pediaphon auf der Learntec 2007 in Karlsruhe auf de Stand der FernUniversität in Hagen.

Unsere Presseabteilung schreibt dazu:
Der M-Learning-Dienst Pediaphon des Lehrgebiets Prozesssteuerung und Regelungstechnik verwandelt deutsch- und englischsprachige Texte aus der freien Online-Enzyklopädie Wikipedia in gesprochene MP3-Dateien und Podcasts. Wissensdurstige können sich diese unterwegs vorlesen lassen, statt z. B. Musik zu hören: Das Pediaphon kann webbasiert oder mit jedem Mobiltelefon genutzt werden. Unterwegs genügt eine SMS, um die Abfrage zu starten. Diese Dateien lassen sich dann problemlos beispielsweise auf einen MP3-Player laden oder sich einfach direkt per Mobiltelefon anhören.

Der Stand der FernUniversität ist zu finden in der dm-arena der Messe Karlsruhe, Stand C 95.

Die Learntec 2007

Das Pediaphon