Donnerstag, 24. September 2015

Übertragung von Dateien per USB zwischen Android 5.1 und Ubuntu 14.04

Im August 2015 hat mein altes Smartphone leider den Geist aufgegeben und ich habe mir ein neues gekauft.
Es wurde ein Motorola MotoG 3 mit Android 5.1.

Es kam nun der Tag an dem ich Video gemacht habe und die 1,8 GB große Datei zum Schneiden auf mein Notebook mit Ubuntu 14.04 kopieren wollte.
Ganz einfach: USB Kabel anstecken und los. Aber Pustekuchen!

Im Thunar (also dem Filebrowser auf meinem Xubuntu) gab es zwar das Gerät MotoG und ich konnte auch bis zu den Bildern navigieren aber dann ging es nicht weiter.
Nicht einmal ein Foto ließ sich öffnen.

Ich hatte zuvor noch eine Android Version bei der ich den internen Speicher als USB Mass Storage mounten konnte. Das geht mit Android 5.1. nicht mehr.

Es gibt nur noch MTP oder das ältere PTP. Mein Ubuntu kommt damit aber erstmal nicht so ohne Weiteres klar.
Es wäre noch ein Transfer über WLAN denkbar aber dafür müsste wieder auf dem Telefon irgendwas installiert werden. Ich bin genervt.

Kurz vor Abbruch der Aktion finde ich diese Seite:
https://linuxundich.de/gnu-linux/gerate-mit-android-3-0-oder-4-0-via-mtp-in-ubuntu-linux-einbinden/


Ich installiere mtpfs nach und im Anschluß kann ich das Telefon manuell über die Konsole per MTP mounten und die Datei in akzetabler Zeit kopieren.

Also zusammengefasst:

# Install mtpfs
sudo apt-get install mtpfs mtptools

# Mountpoint erstellen
mkdir ~/android

# Telefon mounten (vorher per USB anschließen und auf dem Phone MTP einstellen)
sudo mtpfs -o allow_other ~/android

# Datei kopieren
cp ~/android/...mp4 ~/Videos

# Umount
sudo umount android/


Mittwoch, 9. September 2015

Das Ziegenproblem

Irgendwie hat ein Kollege heute im Büro das Ziegenproblem angesprochen von welchem ich noch nie gehört hatte.

Details siehe hier:
http://de.wikipedia.org/wiki/Ziegenproblem

Zusammengefasst stelle man sich die gute alte GameShow Geh aufs Ganze mit dem Zonk vor: Es gibt 3 geschlossene Tore - hinter einem steht ein Auto als Gewinn, hinter den beiden anderen der Zonk als Niete.

Der Spieler soll sich ein Tor aussuchen. Der Moderator bringt nun etwas Spannung ins Spiel indem er eines der beiden anderen Tore öffnen läßt. Dahinter kommt der Zonk (die Ziege) zum Vorschein.

Nun soll der Kandidat seine Wahl noch einmal überdenken. Soll er bei seiner Wahl bleiben oder das andere geschlossene Tor wählen? Bei welchem der verbleibenden 2 geschlossenen Tore ist die Gewinnwahrscheinlichkeit größer?

Ich bin auch nicht schlauer als die meisten und sage 50:50 - egal. Es sind noch 2 Tore und eine neue Entscheidung - das Auto kann hinter dem einen und genau so gut hinter dem anderen Tor sein.

Mein Kollege sagt Auswahl wechseln, denn für das zuerst gewählte Tor liegt die Gewinnwahrscheinlichkeit bei 33,3% und bei dem anderen bei 66,6%.

Er kritzelt folgendes auf (Spieler wählt Tor 1 und Moderator öffnet 2 oder 3):


Das zu Anfang für jedes Tor eine Wahrscheinlichkeit von 33,3% (also 1 Drittel) besteht ist klar. Dass nach Auflösen eines Tores dessen Wahrscheinlichkeit zu dem geschlossenen Tor addiert wird leuchtet mir nicht ein. Ich glaube das nicht. Ich glaube weiter an 50:50.

Mein Kollege zeigt mir den o.g. Wikipedia Artikel, die Tabelle mit den 9 Möglichkeiten usw. Ich lese das alles aber das macht die Sache nur komplizierter und nicht durchschaubar. Ich lese, das es viele - teils prominente - Zweifler an den 66,6% gibt und bin überzeugt, den Gegenbeweis zu finden.

Als Programmierer wähle ich den für mich einfachsten Weg: In 10 Minuten entsteht ein kleines Java-Programm mit dem ich Spiele laufen lasse und zähle wie oft der Kandidat gewinnt, wenn er:

a) bei seinem zu Anfang gewählten Tor bleibt
b) zum anderen Tor wechselt

Natürlich lasse ich noch die Gesamtverteilung der Gewinnertore zählen, um die gleichmäßige Verteilung zu prüfen. Bei 10 Durchläufen lässt diese noch stark zu wünschen übrig, bei 100 wird es besser und bei 10.000 Spielen liegen alle Tore bei 33%, d.h. jedes Tor ist annähernd gleich oft ein Gewinnertor gewesen. Damit ist das Ergebnis repräsentativ.

Ich lese die Auswertung der Kandidaten-Entscheidung und kann es kaum glauben:

...
Game:  Auto   Ziege  Ziege
Game:  Ziege  Auto   Ziege
Game:  Auto   Ziege  Ziege
---- STATS -----------------------
1: 33%   -  3336
2: 33%   -  3320
3: 33%   -  3344
---- WIN Stats -------------------
No switch: 3355
Switch   : 6645

Wenn der Kandidat nicht wechselt (No switch) gewinnt er von 10.000 Spielen 3.355 Mal das Auto, wenn er wechselt (Switch) gewinnt er 6.645 Mal.
Ungläubig lasse ich die Simulation noch einmal laufen mit nahezu gleichem Ergebnis. Die 66,6% stimmen also.
Wechseln ist statistisch gesehen von Vorteil. Ich verstehe es natürlich noch immer nicht aber weiss jetzt das ich falsch liege und bei mir ein Denkfehler vorliegt.
Die Simulation lügt nicht. Das Programm hat stur 10.000 Spiele durchgespielt.


Die Sache lässt mich nicht los. Ich will es verstehen! Ich grübel und grübel und komme schließlich zur Position des Moderators. Dieser kann nicht unbedingt frei entscheiden, welches der beiden verbleibenden Tor er öffnet:

  1. Wenn der Spieler als erstes das Tor wählt hinter dem das Auto steht kann der Moderator entscheiden welches der beiden verbleibenden Tore er öffnet (beides Ziegentore)
  2. Falls der Spieler jedoch ein Tor mit der Ziege gewählt hat, hat der Moderator keine Wahl: Das zu öffnende Tor steht fest, denn das Auto-Tor ist tabu.

Grundsätzlich ist die Position des Moderators nicht relevant aber bei mir hat das zum Verständnis beigetragen:

Die Gewinnwahrscheinlichkeit des zuerst gewählten Tores liegt bei 33,3% - klar.

Daraus ergibt sich für den Moderator:

  1. 33,3%: Moderator hat freie Auswahl zwischen den beiden Ziegen-Toren:
    Für den Spieler bedeutet das: Wechsel => Ziege, Nicht-Wechsel => Auto
  2. 66,6%: Moderator hat keine Wahl, da nur noch ein Ziegentor übrig ist
    Für den Spieler bedeutet das: Wechsel => Auto, Nicht-Wechsel => Ziege
Damit habe ich die Kurve gekriegt und kann es nachvollziehen.

Wechsel bedeutet zu 66,6% Gewinn aber eben auch zu 33,3% Ziege.
Nicht-Wechsel bedeutet nur zu 33,3% Gewinn und zu 66,6% Ziege.


Ich  habe vor Schreiben dieses Posts noch folgenden Artikel gelesen:
http://www.zeit.de/2004/48/N-Ziegenproblem

Dort steht, dass tatsächlich die Perspektive des Moderators vielen beim Verständnis der Sache hilft. Immerhin bin ich darauf allein gekommen - wenigstens etwas ;)


Und noch ein Nachtag: Der größte Teil meines Simulationsprogramms war für die Entscheidung (oder Zwangswahl) des Moderators nötig.
Als das Programm fertig war habe ich festgestellt, dass zum Bestimmen des Ergebnisses das durch den Moderator geöffnete Tor unerheblich ist.

Dieser Kommentar bei Heise bringt es einfach auf den Punkt:
http://www.heise.de/forum/heise-online/News-Kommentare/Wo-ist-das-Auto-25-Jahre-Ziegenproblem/Aah-einfacher-als-ich-zuerst-dachte/posting-23691706/show/

Richtig: Wenn der Spieler sich nicht beeinflussen lässt und bei seiner ursprünglichen Wahl bleibt, bleibt auch seine Chance auf das Auto bei 33,3%. Das Öffnen eines der anderen Tore ist für seine Gewinnchance unerheblich.
Die verbleibenden 66,6% entfallen auf das andere Tor. Es geht gar nicht anders.


Und noch ein Nachtrag

http://www.siegfriedraisin.de/index.php?option=com_content&view=article&id=16%3Aloesung-das-ziegenproblem&catid=14%3Aloesungen-zu-den-raetseln&Itemid=30&lang=de


Dehnen wir das Problem auf 100 Tore aus. 1 Auto, 99 Ziegen. Der Spieler wählt ein Tor. Die Gewinnchance liegt bei 1%. Zu 99% befindet sich das Auto aber in irgendeinem der anderen Tore.

Der Moderator öffnet beliebig viele der 99 nicht gewählten Tore. Maximal 98 so dass wir wieder beim Ursprungsproblem sind.
Es leuchtet jetzt ein: Zu 99% befindet sich das Auto hinter dem 99. Tor. Dieses durfte der Moderator die ganze Zeit nicht öffnen weil dahinter das Auto ist. 1% bleibt weiterhin beim ursprünglich gewählten Tor.


Wie auch immer: Wenn man die Kommentare bei Heise überfliegt sieht man, dass noch immer viele Leute an 50:50 glauben.
Meine Simulation hat mir gezeigt, dass ich falsch liege. Der Rest kommt, wenn man seine Gedanken öffnet.

Dienstag, 8. September 2015

Aufbau eines lokalen Wiki für technische Dokumentation

Nachtrag: Ich habe inzwischen DocBook XML als die wesentliche bessere Möglichkeit entdeckt (siehe entsprechender Blogeintrag).
Ich lasse den Artikel aber einfach mal so stehen.



Auf der Suche nach einer soliden Basis zur Erstellung technischer Dokumentationen für Kunden-Systeme habe ich mir MediaWiki genauer angeschaut. MediaWiki ist das System welches auch hinter Wikipedia steckt. Es steht unter der GNU2 Lizenz zur Verfügung.

MediaWiki bietet folgende Vorteile für die Dokumentation:

  1. Leistungsfähige Web-Schnittstelle zur Recherche in der Dokumentation. Da so gut wie alle Leute Wikipedia kennen fällt die Navigation leicht.
  2. Dokumentation kann in Artikel aufgeteilt werden und ist dennoch zentral verfügbar.
  3. MediaWiki Installation kann lokal beim Kunden eingerichtet werden, so dass die Dokumentation nur intern abgerufen werden kann
  4. Es können mehrere Nutzer an der Dokumentation arbeiten
  5. Versionierung wird unterstützt.
  6. Schlankes System dass auf einer kleinen VM installiert werden kann
  7. Einfaches Backup der dahinterstehenden MySQL Datenbank
  8. Buch-Funktion: Aus dem Wiki kann ein buch-ähnliches PDF mit Inhaltsverzeichnis, Seitenzahlen usw. erzeugt werden. Dazu später mehr.

Buchfunktion


Erfahrungsgemäß möchten Kunden eine Druckversion der Doku oder zumindest ein ordentlich aufbereitetes PDF haben. Dies macht Sinn, denn was nützt bei einem Ausfall der IT eine Dokumentation, die sich auf dem ausgefallen System befindet.
MediaWiki bietet die Möglichkeit, verschiedene Artikel zu einem Buch zusammen zu führen. Auf wikipedia.de kann man das einfach ausprobieren:

  1. www.wikipedia.de aufrufen und einen Artikel aufrufen (z.B. Münchehofe).
  2. Im Menübereich (links) im Bereich Drucken/exportieren auf Buch erstellen klicken.
  3. Auf der nächsten Seite Buchfunktion starten klicken
  4. Man gelangt wieder zum Artikel und kann am Ende der Seite im Bereich Buchgenerator die Seite zum Buch hinzufügen
  5. Man kann auf diese Weise beliebig viele Artikel zum Buch hinzufügen
  6. Sobald alle Artikel hinzugefügt sind klickt man im Bereich Buchgenerator auf Buch zeigen.
  7. Dort kann man Titel und Untertitel festlegen, zwischen 1- oder 2-spaltigem Layout wählen und die Reihenfolge der Artikel ändern (mit der Maus verschieben).
  8. Im Bereich Herunterladen kann die Erstellung einer PDF-Version anstoßen. Diese steht kurze Zeit später zum Download bereit.
Einfach mal probieren. Das PDF sieht wirklich gut aus. Inhaltsverzeichnis, Teilüberschriften, Bilder, Quellen - alles ist drin. Das kann man schon abgeben.

Wer heute also eine Plagiatsarbeit abgeben möchte, klickt die Artikel einfach bei Wikipedia zusammen und macht gleich ein Buch daraus - fertig ;)

Lokale Installation


Eine lokale Mediawiki-Installation ist in einer Linux-Apache-MySQL-PHP Umgebung in wenigen Minuten startklar. Darauf gehe ich nicht weiter ein. Mehr hier:


Man wird aber schnell feststellen, dass der Buchgenerator fehlt. Diesen lokal zum Laufen zu bekommen empfand ich als relativ schwierig.

Ich habe 2 Möglichkeiten zur Erstellung von Büchern aus einem Wiki gefunden:

  1. Über Collection extension, Parsoid-Service und den Offline Content Generator (OCG): Diese Variante wird von wikipedia.org und wikipedia.de eingesetzt und scheint der in Zukunft favorisierte Weg zu sein. Kapitel und Teilüberschriften werden durchnummeriert und man kann zwischen 1- oder 2-spaltigem Seitenlayout wählen.
  2. Über Collection extension und mwlib von PediaPress: Kapitel und Teilüberschriften werden nicht durchnummeriert und es wird nur das 1-spaltige Layout unterstützt.

Installation Collection extenstion


Die Collection extension wird für beide Varianten benötigt. Diese ermöglicht das Sammeln der Artikel und erweitert die Wiki-Oberfläche um die Buchfunktion.

Installation der Collection extension:
https://www.mediawiki.org/wiki/Extension:Collection#Installation

Das Einbinden der extension geschieht in der LocalSettings.php im mediawiki Hauptverzeichnis:

require_once "$IP/extensions/Collection/Collection.php";


Je nach genutzter Variante (Parsiod+OCG oder mwlib) müssen noch weitere Anpassungen in der LocalSettings.php erfolgen (mehr nachfolgend).


Variante 1: Parsoid-Service und OCG


Zusätzlich zur Collection extension müssen folgende Dinge installiert werden:
  1. Offline Content Generator (OCG) bundler: Der bundler packt die gesammelten Artikel inklusive der Bilder usw. in ein ZIP-Archiv.
    Die Inhalte werden dabei als JSON bzw. SQLLite Datenbankdateien abgelegt.
  2. OCG-latexer: Der ocg-latexer erstellt aus dem vom ocg-bundler gelieferten Archiv mit Hilfe von Latex ein PDF Dokument
  3. OCG-service: Der ocg-service stellt einen Server bereit, der ocg-bundler und ocg-latexer steuert. Die Collection extension stellt eine Verbindung mit dem ocg-service her, um die PDF-Erzeugung anzufordern.
  4. Parsoid Service: Der ocg-bundler benötigt entweder eine Parsoid-Service oder ein RESTFUL-API, um die Daten aus der MediaWiki Installation abzufragen. Ich habe den Parsoid Service verwendet. Dieser stellt ein API für den Zugriff auf das Wiki zur Verfügung.
Für eine einfache lokale Installation ist das ganz schön aufwändig. Die ganze Sache zum Arbeiten zu überreden ist ebenfalls nicht ganz einfach.

Die Installation der OCG-Komponenten ist hier beschrieben:

http://wikitech.wikimedia.org/wiki/OCG

Konfigurieren und Starten des OCG-Service


Das Wiki stellt eine Verbindung mit dem OCG-Service her, um die gewählten Artikel in ein PDF zu bringen. Damit das funktioniert, muss der OCG-Service gestartet werden.
Der OCG-Service nutzt wiederum den Parsoid Service. Standardmäßig wird der online verfügbare Wikipedia Parsoid-Service genutzt, der aber natrürlich keinen Zugriff auf ein lokal installiertes Wiki hat.
Daher muss vor Starten des OCG-Service im Verzeichnis mw-ocg-service ein Konfigurationsdatei localsettings.php mit folgendem Inhalt erstellt werden:

module.exports = function(config) {
  // host + port where PARSOID is running
  config.backend.bundler.parsoid_api = "http://localhost:8000";
  // the prefix here should match $wgDBname in your LocalSettings.php
  config.backend.bundler.parsoid_prefix = "localhost";
  // Use the Parsoid "v3" API
  config.backend.bundler.additionalArgs = [ '--api-version=parsoid3' ];
}

Beim Start des OCG-Service wird mit der Option -c die Konfigurationsdatei angegeben:

peter@gorgonzola:~$ ./mw-ocg-service.js -c localsettings.js

Der OCG-Service sollte danach ohne Fehlermeldungen hochfahren.


Konfigurieren und Starten des Parsoid Service


Ich habe Parsoid aud dem GIT Repository geholt und eingerichtet:
https://www.mediawiki.org/wiki/Parsoid/Developer_Setup

Die Installation des Parsoid Service aus einem Ubuntu Repo wird hier beschrieben:
https://www.mediawiki.org/wiki/Parsoid/Setup


Wie im Developer Setup beschrieben habe ich die Datei api/localsettings.js aus der Vorlagedatei erstellt und ungepasst.

Der Start des Parsoid Service erfolgt über:

peter@gorgonzola:~$ node api/server.js

Der Dienst muss ohne Fehlermeldungen hochfahren.

Anpassen der LocalSettings.php

Im  mediawiki Hauptverzeichnis müssen noch folgende Zeilen in der LocalSettings.php am Ende ergänzt werden:

$wgCollectionFormatToServeURL['rdf2latex'] =
$wgCollectionFormatToServeURL['rdf2text'] = 'http://localhost:17080';

// MediaWiki namespace is not a good default
$wgCommunityCollectionNamespace = NS_PROJECT;

// Sidebar cache doesn't play nice with this
$wgEnableSidebarCache = false;

$wgCollectionFormats = array(
    'rdf2latex' => 'PDF',
        'rdf2text' => 'Plain text',
);
 
$wgLicenseURL = "http://creativecommons.org/licenses/by-sa/3.0/";
$wgCollectionPortletFormats = array( 'rdf2latex', 'rdf2text' );
Damit wird der OCG-Service in die Wiki-Oberfläche eingebunden (localhost:17080).

Probleme mit Bildern


Ich hatte zunächst Probleme mit den eingebundenen Bildern. Diese werden im Wiki-Artikel in der Regel so eingebunden:

[[Datei:Bild.jpg|mini|Bildtitel]]

Entscheidend ist die Größenangabe mini. Ohne diese wird das Bild 1:1 mit 72dpi in das PDF aufgenommen und ragt entweder aus dem Dokument heraus (bei höher aufgelösten Bildern) oder ist unscharf (bei kleinen Bildern).

Mit der Größenangabe mini hatte ich zunächst das Problem, dass die Bilder gar nicht mehr im PDF auftauchten.
Nach intensiver Suche habe ich herausgefunden, dass der OCG die Bilder mit der Größe mini in einer Breite (Auflösung) von 1200px anfordert. Wenn die Bilder nicht in dieser Auflösung vorliegen, bekommt der OCG anstelle des Bildes einen HTML 404 und diese Textdatei kann im weiteren Verlauf der Verarbeitung nicht in das PDF eingebunden werden.

Fürs erste lade ich also alle Bilder mit width=1200px hoch.


Variante 2: PediePress mwlib


Habe ich mir nicht mehr angeschaut.


Fazit

Die Buchfunktion ist eine schöne Sache. Allerdings ist das Aufsetzen kompliziert. Einige Dinge (wie z.B. Tabellen) werden nicht dargestellt.
Ausserdem bleibt das Problem, dass ein Wiki kein Inhaltsverzeichnis besitzt. Es handelt sich um eigenständige Artikel, die zur Erstellung eines Buches immer in einer bestimmten Reihenfolge zusammengestellt werden müssen.

Ich habe weiter gesucht und inzwischen DocBook XML als die für meine Zwecke bessere Variante entdeckt (siehe entsprechender Blog Artikel).