ubuntuusers.de

8. März 2014

Etherpad Lite auf pad.trashserver.net

Etherpad Lite auf pad.trashserver.net

Etherpad ist Software, die es verschiedenen Benutzern ermöglichst, gemeinsam und gleichzeitig via Webbrowser an einem einfachen Textdokument zu arbeiten. Die Benutzer bekommen je eine Textfarbe zugeordnet um sie unterscheiden zu können (siehe Pad unter http://pad.trashserver.net). Da Etherpad Lite Open Source Software ist, kann sie auch auf einem eigenen (Root-) Server installiert werden. Wie ihr einen eigenen Etherpad Server aufsetzt erfahrt ihr in diesem Beitrag.

Zuerst müssen node.js und die anderen benötigten Pakete installiert werden:

sudo -s
apt-get install gzip git-core curl python
apt-get install nodejs

Ein neuer Benutzer “etherpad” wird erstellt und ein Homeverzeichnis unter /opt/etherpad/ für ihn angelegt. Unter diesem Benutzer wird Etherpad später laufen.

mkdir /opt/etherpad
useradd etherpad -d /opt/etherpad
chown etherpad:etherpad /opt/etherpad

Jetzt loggt ihr euch als etherpad User ein und holt euch das aktuelle Etherpad Lite von Github:

sudo -u etherpad -i
git clone git://github.com/ether/etherpad-lite.git

Konfiguration

Betretet das etherpad-lite Verzeichnis und kopiert die Beispiel-Konfigurationsdatei:

cd etherpad-lite
cp settings.json-template settings.json

In der Konfigurationsdatei settings.json müssen einige Änderungen vorgenommen werden. Die Einstellungen sind gut dokumentiert und müssen an dieser Stelle nicht speziell erklärt werden.

MySQL Datenbank nutzen

Standardmäßig nutzt Etherpad Lite die “DirtyDB”. Es wird empfohlen, eine andere Datenbank zu nutzen, z.B. eine MySQL Datenbank. Hier wird eine korrekt aufgesetzte MySQL Datenbank vorausgesetzt.

"dbType" : "dirty",
//the database specific settings
"dbSettings" : {
"filename" : "var/dirty.db"
},

/* An Example of MySQL Configuration
"dbType" : "mysql",
"dbSettings" : {
"user"    : "root",
"host"    : "localhost",
"password": "",
"database": "store"
},
*/

wird geändert in

"dbType" : "mysql",
"dbSettings" : {
"user"    : "etherpad-user",
"host"    : "localhost",
"password": "etherpad-passwort",
"database": "etherpad-db"
},

Achtet vor allem auf die entfernen Kommentarzeichen “/*”.

Etherpad Service erstellen

Damit das Etherpad mit dem “service” Kommendo des init-Systems gestartet werden kann (z.B. service etherpad start), wird ein init-Script unter /etc/init.d/etherpad-lite angelegt:

exit
nano /etc/init.d/etherpad-lite
#!/bin/sh
### BEGIN INIT INFO
# Provides:          etherpad-lite
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts etherpad lite
# Description:       starts etherpad lite using start-stop-daemon
### END INIT INFO

PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/opt/node/bin"
LOGFILE="/var/log/etherpad-lite/etherpad-lite.log"
EPLITE_DIR="/opt/etherpad/etherpad-lite"
EPLITE_BIN="bin/run.sh"
USER="etherpad"
GROUP="etherpad"
DESC="Etherpad Lite"
NAME="etherpad-lite"

set -e

. /lib/lsb/init-functions

start() {
  echo "Starting $DESC... "

    start-stop-daemon --start --chuid "$USER:$GROUP" --background --make-pidfile --pidfile /var/run/$NAME.pid --exec $EPLITE_DIR/$EPLITE_BIN -- $LOGFILE || true
  echo "done"
}

#We need this function to ensure the whole process tree will be killed
killtree() {
    local _pid=$1
    local _sig=${2-TERM}
    for _child in $(ps -o pid --no-headers --ppid ${_pid}); do
        killtree ${_child} ${_sig}
    done
    kill -${_sig} ${_pid}
}

stop() {
  echo "Stopping $DESC... "
  if test -f /var/run/$NAME.pid; then
    while test -d /proc/$(cat /var/run/$NAME.pid); do
      killtree $(cat /var/run/$NAME.pid) 15
      sleep 0.5
    done
    rm /var/run/$NAME.pid
  fi
  echo "done"
}

status() {
  status_of_proc -p /var/run/$NAME.pid "" "etherpad-lite" && exit 0 || exit $?
}

case "$1" in
  start)
      start
      ;;
  stop)
    stop
      ;;
  restart)
      stop
      start
      ;;
  status)
      status
      ;;
  *)
      echo "Usage: $NAME {start|stop|restart|status}" >&2
      exit 1
      ;;
esac

exit 0

Ausführungsrechte setzen:

chmod +x /etc/init.d/etherpad-lite

Mit dem folgenden Befehl wird das Etherpad gestartet. Es kann jedoch einige Sekunden dauern, bis das Etherpad erreichbar ist.

service etherpad-lite start

Apache Webserver Proxy

Normalerweise wartet das Etherpad auf Port 9001 auf Anfragen. Für den bequemeren Zugriff kann allerdings auch ein Apache Proxy eingerichtet werden, der Anfragen auf eine bestimmte Subdomain (z.B. pad.trashserver.net) an das Etherpad weiterleitet. Ein installierter Apache Webserver ist Voraussetzung. Für die Proxy-Funktion müssen die Apache proxy-Module aktiviert werden:

a2enmod proxy
a2enmod proxy_http

Ein neuer VirtualHost wird in der VirtualHost-Konfiguration erstellt: (z.B. in /etc/apache2/sites-available/etherpad)

<VirtualHost *:80>
ServerName pad.trashserver.net
ProxyPreserveHost On
ProxyRequests Off
ProxyVia Off
ProxyPass / http://127.0.0.1:9001/
ProxyPassReverse / http://127.0.0.1:9001/
</VirtualHost>
a2ensite etherpad
service apache2 restart

Nach einem Neustart des Apache Webservers ist das Etherpad über die definierte Subdomain erreichbar.

Etherpad updaten

Es schadet nicht, von Zeit zu Zeit auf die aktuellste Etherpad Version zu updaten. Ein Update erfolgt über diese 3 Kommandos:

sudo -u etherpad -s
cd etherpad-lite
git pull origin
exit
service etherpad restart

 

BitCoin. Cheffinnen von Trading-Sites werden tot in Wohnungen gefunden. Ein Magic the Gathering Online Exchange geht insolvent. FlexCoin gehackt.

Der Kurs zeigt sich trotzdem relativ unbeeindruckt, was mich irgendwie verblüfft. Egal. Es macht momentan Spass BitCoin zu verfolgen. Gerade die “Suche” nach Satoshi Nakamoto.

2011 bastelte ich einen Megabitmeter und als er mir letztens wieder in die Hände fiel, dachte ich mir hey, BitCoins<–>Dollar anzeigen lassen!

Im Endeffekt hole ich mir nur mit etwas Python (schlechtes Python, btw) den aktuellen Kurs vom letzten halbwegs stabilen BitCoin Trader Bitstamp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/usr/bin/python

import json
import urllib2
import math
import time

# configure
url = "https://www.bitstamp.net/api/ticker/"
analogmeter = "/dev/ttyUSB0"

# runtime loop
while True:

    # parse api json result
    data = json.load(urllib2.urlopen(url))
    value = math.floor(float(data["last"]))
    value = str(int(value)) + '\n' # use ALL the data types

    # write to usb device
    f = open(analogmeter, 'w')
    f.write(value)
    f.close()

    # wait until the next refresh
    time.sleep(60)

Heute habe ich ein paar Änderungen am Theme vorgenommen welche hauptsächlich für die neue Suchfunktion bestimmt sind. Dass ausfälligste ist jetzt die neue Sucheingabe in der Navigationsleiste über die ihr alle durch alle Artikel im Blog suchen könnt. Außerdem habe ich den Blogtitel jetzt auf die Farbe Schwarz umgestellt. Ich wünsche euch viel Spaß beim suchen und finden. 😉

Powerwalker UPS Stromfluss

Powerwalker UPS Webinterface

Wie ich gestern schon geschrieben habe, bin ich jetzt auch im Besitz einer kleinen USV / UPS Anlage für meinen Homeserver. Heute war die Server-Software dran, die mit der Bluewalker PowerWalker VI 650 LCD Anlage mitgeliefert wurde. Die aktuelle Version 2.11 der Management-Software habe ich mir von der Powerwalker Website heruntergeladen. Es stehen eine grafik- und eine textbasierte Version zur Verfügung. Grafik ist für Looser, also habe ich mir die textbasierte Version geholt (Direktlink zum Download). Nein, natürlich nicht ;) Ich habe auf dem Server nur keinen XServer und ein CLI ist mir lieber.

Bevor ViewPower installiert wird, muss zuerst noch sichergestellt werden, dass auf dem Server Java installiert ist:

sudo -s
apt-get install openjdk-7-jre-headless

Im heruntergeladenen tar.gz Archiv liegt eine .bin Datei, die man als root einfach ausführt. Sie startet das Setup:

./installViewPower_Linux_text_x86_64.bin

Als nächstes wird die Sprache gewählt. Englisch ist okay, Deutsch verständlicher. Ich wähle “4″.

Jetzt muss ein Pfad gewählt werden, in den die ViewPower Software installiert werden soll. Ich habe mich für das Verzeichnis  /opt/ViewPower entschieden. Im /opt/ Verzeichnis ist die Software sicher vor umherwütenden Updateroutinen des Paketmanagers. Man wird gefragt, ob man Links erstellen will. Damit sind wohl Links gemeint, die bei einer graphischen Installation z.B. auf dem Desktop liegen. Brauchen wir nicht, also wieder “4″ gewählt.

Man bekommt nochmal eine kurze Übersicht der gewählten Einstellungen, kann mit ENTER bestätigen und ViewPower wird installiert. In die Datei /etc/rc.local wurde am Ende automatisch ein Autostart-Eintrag geschrieben, sodass der ViewPower Server mit dem System startet. Wer seinen Server nicht komplett neu starten will, kann natürlich auch in das ViewPower Programmverzeichnis wechseln und ein

./ViewPower &

ausführen. Möglicherweise startet der Server nicht korrekt und gibt diese Fehlermeldung aus:

“strings: ‘/lib/libc.so.6′: No such file”

In diesem Fall hilft es, einen einfachen symbolischen Link an die richtige Stelle zu setzen. Für 64-Bit Systeme (Ubuntu):

ln -s /lib64/x86_64-linux-gnu/libc.so.6 /lib64/libc.so.6

Und für 32-Bit Systeme:

ln -s /lib/i386-linux-gnu/libc.so.6 /lib/libc.so.6

Sobald der Link gesetzt ist, sollte ViewPower korrekt starten.

Unter der Adresse http://ip.des.servers:15178/ViewPower/ ist die Weboberfläche zu finden, über die sich die UPS einstellen und überwachen lässt. Leider ist die ganze GUI Adobe Flash basierend, sodass man um Flash im Browser nicht umher kommt. Schade.

Zuerst sollte das Administrator-Passwort für den Manager geändert werden. Loggt euch oben rechts mit dem Passwort “administrator” ein. Danach klickt ihr auf “ViewPower Configuration” => “Change Password”.

Die Sprache lässt sich übrigens im “Language” Menü ändern – wer hätte das gedacht ;)

Eigentlich ist die Software jetzt fertig eingerichtet und der Konfiguration der UPS steht nichts mehr im Wege. Wenn mich da nicht noch etwas stören würde: ViewPower läuft nur vollständig mit root-Rechten. Bisher habe ich dafür noch keine Lösung, bin aber auf der Suche …

Powerwalker UPS Ereignisübersicht

Powerwalker UPS Ereignisübersicht

BitCoin. Cheffinnen von Trading-Sites werden tot in Wohnungen gefunden. Ein Magic the Gathering Online Exchange geht insolvent. FlexCoin gehackt.

Der Kurs zeigt sich trotzdem relativ unbeeindruckt, was mich irgendwie verblüfft. Egal. Es macht momentan Spass BitCoin zu verfolgen. Gerade die “Suche” nach Satoshi Nakamoto.

2011 bastelte ich einen Megabitmeter und als er mir letztens wieder in die Hände fiel, dachte ich mir hey, BitCoins<->Dollar anzeigen lassen!

Im Endeffekt hole ich mir nur mit etwas Python (schlechtes Python, btw) den aktuellen Kurs vom letzten halbwegs stabilen BitCoin Trader Bitstamp

#!/usr/bin/python

import json
import urllib2
import math
import time

# configure
url = "https://www.bitstamp.net/api/ticker/"
analogmeter = "/dev/ttyUSB0"

# runtime loop
while True:

    # parse api json result
    data = json.load(urllib2.urlopen(url))
    value = math.floor(float(data["last"]))
    value = str(int(value)) + '\n' # use ALL the data types

    # write to usb device
    f = open(analogmeter, 'w')
    f.write(value)
    f.close()

    # wait until the next refresh
    time.sleep(60)

7. März 2014

Problem

Responsives Webdesign ist in. Dieses wird vor allem durch Regeln in CSS-Sytlesheets umgesetzt. Problem an der Sache ist allerdings, dass die übertragenen Daten hierdurch meist die gleichen bleiben.

Bilder beispielsweise bleiben gleich groß und werden nur herunter skaliert. Das hat gerade auf mobilen Geräten (Smartphones etc.) noch langsamere Übertragungszeiten zur Folge. Zudem ist das Netz schon von vornherein nicht überall perfekt ausgebaut. Es gibt zum Beispiel „Funklöcher“, wo Daten nur per EDGE übertragen werden. Oder man ist bereits gedrosselt, weil man sein Datenvolumen aufgebraucht hat etcpp.

Wenn ich meinen eigenen Blog vor der Optimierung anschaute, dann wurden bei einem Aufruf der Startseite 11,4 MB innerhalb von circa 8 Sekunden übertragen – am Desktop mit 16000er DSL. Mobil würde das aufgrund der höheren Latenz und Auslastung wohl noch länger dauern. Zudem ist die Größe einfach unzumutbar für aktuelle Flatrates. Überschlägt man mal mit 10 MB pro Aufruf und einer monatlichen Internet-Flatrate von 300 MB, dann könnte man die Website einmal täglich aufrufen und das gesamte Datenvolumen wäre weg. Nicht schön.

Möglicher Ausweg: Picturefill

Eine perfekt Lösung für dieses Problem gibt es momentan nicht. Das liegt vor allem an einem fehlenden Standard. So existiert nur ein Entwurf des W3C zu <picture>, das sehr ähnlich wie Picturefill arbeitet. Das grundlegende Prinzip von beiden ist dabei, abhängig von der Bildschirmbreite ein entsprechendes Bild zu zeigen. So erhält ein Desktop mit großem Bildschirm (Diagonale z. B. 22"), ein großes Bild. Ein kleines Smartphone (3") dagegen ein kleineres Bild.

Picturefill ist daher meiner Meinung nach besser wie gar kein Workaround und „füllt“ damit – vorerst – diese Lücke. Im Folgenden daher die genauere Einrichtung von Picturefill.

Einrichtung von Picturefill

  1. Archiv von GitHub herunterladen
  2. JavaScript einbinden

    <script type="text/javascript" src="/Pfad/zur/Datei/picturefill.js"></script>    
    

    In den HTML-Header wird – am besten verkleinert und komprimiert – auf picturefill.js verlinkt. Der Polyfill matchmedia sorgt zusätzlich für Kompatibilität. Dieser ist dabei im Ordner external versteckt.

  3. Bilder in HTML einbinden. Dazu ein Beispiel:

    <span data-picture data-alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">
        <span data-src="small.jpg"></span>
        <span data-src="medium.jpg"     data-media="(min-width: 400px)"></span>
        <span data-src="large.jpg"      data-media="(min-width: 800px)"></span>
        <span data-src="extralarge.jpg" data-media="(min-width: 1000px)"></span>
    
        <!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. -->
        <noscript>
            <img src="small.jpg" alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">
        </noscript>
    </span>  
    

    Der Aufbau geht dabei also vor allem über <span>s. Der oberste <span> wird durch „data-picture“ gekennzeichnet, damit Picturefill überhaupt auf diesen angewendet wird. Anschließend wird in mehreren <span>s die vorhandenen Bildgrößen definiert. Welches Bild davon im Browser angezeigt wird, wählt Picturefill über data-media aus. In data-media steht dabei nichts anderes als die aus CSS3 bekannten Media Queries.

    Der <img>-Tag in den noscript-Blöcken dient, wie der Kommentar darüber bereits sagt, für Browser mit deaktiviertem JavaScript. Dieser ist aber auch für den Google-Suchmaschinen-Bot interessant.

Wenn man mehr Hintergrundinformationen zu Picturefill erfahren möchte, findet diese in der README-Datei auf GitHub. Dort ist zum Beispiel im Detail beschrieben, wie mit JavaScript aus den data-Attributen der <img>-Tag lokal erstellt wird und wie man auf „Retina-Displays“ höher auflösende Bilder anzeigt.

Wo setzt man die Grenzen?

Eine Frage bleibt aber noch offen: Ab welcher Breite lädt man andere Bilder? Die Antwort darauf ist indes schwierig. Allerdings kann man sich meist an seinem bestehenden responsiven Design orientieren. Dabei gibt es bei mir einmal eine Änderung bei einer Breite von 700 px und 450 px. Ein weitere Ansatzpunkt ist die Bildgröße. So wäre es beispielsweise nicht sinnvoll ein 1200 px weites Bild auf einem 450 px weiten Smartphone-Bildschirm anzuzeigen.

Alternativen

Die Lösung mit Picturefill hat jedoch auch Nachteile: Zum Beispiel ist das HTML – in meinen Augen – nicht mehr 100 %ig valide. Das liegt vor allem daran, dass die eigentlichen <img>-Tags erst durch das JavaScript erzeugt werden.

Außerdem ist ein manueller Eingriff in den Quelltext jedes Artikels nötig. Das mag bei einem neuen Blog wie hier nicht unbedingt ins Gewicht fallen. Aber gerade bei einem Webauftritt, der schon längere Zeit besteht, kann sich dieser – womöglich noch manuelle Prozess – ziehen.

Hier könnte stattdessen zum Beispiel Adaptive Imagesinteressant sein. Gegen diese serverseitige Alternativen mit PHP habe ich mich aber entschieden, weil zur Nutzung unter anderem ein separater Cookie nötig ist. Eine mögliche weitere Alternative ist Mobify.js. Dieses Stück JavaScript ermöglicht es vor dem Rendern, das HTML clientseitig zu editieren. Konkret bedeutet dies, dass die Bild-URL innerhalb von <img> in Form von src noch vor dem eigentlichen Herunterladen geändert wird, auf zum Beispiele eine kleinere Version. Damit sind keine Umwege über <span>s wie bei Picturefill nötig. Als Resultat wird aber dennoch das kleinere Bild geladen. Allerdings hapert es da noch ein wenig mit dem IE-Support.

Wer mehr über das gesamte Problem und weitere Alternativen erfahren will, findet zum Thema (englische) Artikel auf CSS-Tricks.com und Smashing Magazine.

Problem

Responsives Webdesign ist in. Dieses wird vor allem durch Regeln in CSS-Sytlesheets umgesetzt. Problem an der Sache ist allerdings, dass die übertragenen Daten hierdurch meist die gleichen bleiben.

Bilder beispielsweise bleiben gleich groß und werden nur herunter skaliert. Das hat gerade auf mobilen Geräten (Smartphones etc.) noch langsamere Übertragungszeiten zur Folge. Zudem ist das Netz schon von vornherein nicht überall perfekt ausgebaut. Es gibt zum Beispiel „Funklöcher“, wo Daten nur per EDGE übertragen werden. Oder man ist bereits gedrosselt, weil man sein Datenvolumen aufgebraucht hat etcpp.

Wenn ich meinen eigenen Blog vor der Optimierung anschaute, dann wurden bei einem Aufruf der Startseite 11,4 MB innerhalb von circa 8 Sekunden übertragen – am Desktop mit 16000er DSL. Mobil würde das aufgrund der höheren Latenz und Auslastung wohl noch länger dauern. Zudem ist die Größe einfach unzumutbar für aktuelle Flatrates. Überschlägt man mal mit 10 MB pro Aufruf und einer monatlichen Internet-Flatrate von 300 MB, dann könnte man die Website einmal täglich aufrufen und das gesamte Datenvolumen wäre weg. Nicht schön.

Möglicher Ausweg: Picturefill

Eine perfekt Lösung für dieses Problem gibt es momentan nicht. Das liegt vor allem an einem fehlenden Standard. So existiert nur ein Entwurf des W3C zu <picture>, das sehr ähnlich wie Picturefill arbeitet. Das grundlegende Prinzip von beiden ist dabei, abhängig von der Bildschirmbreite ein entsprechendes Bild zu zeigen. So erhält ein Desktop mit großem Bildschirm (Diagonale z. B. 22"), ein großes Bild. Ein kleines Smartphone (3") dagegen ein kleineres Bild.

Picturefill ist daher meiner Meinung nach besser wie gar kein Workaround und „füllt“ damit – vorerst – diese Lücke. Im Folgenden daher die genauere Einrichtung von Picturefill.

Einrichtung von Picturefill

  1. Archiv von GitHub herunterladen
  2. JavaScript einbinden

    1
    <script type="text/javascript" src="/Pfad/zur/Datei/picturefill.js"></script>
    

    In den HTML-Header wird – am besten verkleinert und komprimiert – auf picturefill.js verlinkt. Der Polyfill matchmedia sorgt zusätzlich für Kompatibilität. Dieser ist dabei im Ordner external versteckt.

  3. Bilder in HTML einbinden. Dazu ein Beispiel:

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    <span data-picture data-alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">
        <span data-src="small.jpg"></span>
        <span data-src="medium.jpg"     data-media="(min-width: 400px)"></span>
        <span data-src="large.jpg"      data-media="(min-width: 800px)"></span>
        <span data-src="extralarge.jpg" data-media="(min-width: 1000px)"></span>
        <!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. -->
        <noscript>
            <img src="small.jpg" alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">
        </noscript>
    </span>
    

    Der Aufbau geht dabei also vor allem über <span>s. Der oberste <span> wird durch „data-picture“ gekennzeichnet, damit Picturefill überhaupt auf diesen angewendet wird. Anschließend wird in mehreren <span>s die vorhandenen Bildgrößen definiert. Welches Bild davon im Browser angezeigt wird, wählt Picturefill über data-media aus. In data-media steht dabei nichts anderes als die aus CSS3 bekannten Media Queries.

    Der <img>-Tag in den noscript-Blöcken dient, wie der Kommentar darüber bereits sagt, für Browser mit deaktiviertem JavaScript. Dieser ist aber auch für den Google-Suchmaschinen-Bot interessant.

Wenn man mehr Hintergrundinformationen zu Picturefill erfahren möchte, findet diese in der README-Datei auf GitHub. Dort ist zum Beispiel im Detail beschrieben, wie mit JavaScript aus den data-Attributen der <img>-Tag lokal erstellt wird und wie man auf „Retina-Displays“ höher auflösende Bilder anzeigt.

Wo setzt man die Grenzen?

Eine Frage bleibt aber noch offen: Ab welcher Breite lädt man andere Bilder? Die Antwort darauf ist indes schwierig. Allerdings kann man sich meist an seinem bestehenden responsiven Design orientieren. Dabei gibt es bei mir einmal eine Änderung bei einer Breite von 700 px und 450 px. Ein weitere Ansatzpunkt ist die Bildgröße. So wäre es beispielsweise nicht sinnvoll ein 1200 px weites Bild auf einem 450 px weiten Smartphone-Bildschirm anzuzeigen.

Alternativen

Die Lösung mit Picturefill hat jedoch auch Nachteile: Zum Beispiel ist das HTML – in meinen Augen – nicht mehr 100 %ig valide. Das liegt vor allem daran, dass die eigentlichen <img>-Tags erst durch das JavaScript erzeugt werden.

Außerdem ist ein manueller Eingriff in den Quelltext jedes Artikels nötig. Das mag bei einem neuen Blog wie hier nicht unbedingt ins Gewicht fallen. Aber gerade bei einem Webauftritt, der schon längere Zeit besteht, kann sich dieser – womöglich noch manuelle Prozess – ziehen.

Hier könnte stattdessen zum Beispiel Adaptive Imagesinteressant sein. Gegen diese serverseitige Alternativen mit PHP habe ich mich aber entschieden, weil zur Nutzung unter anderem ein separater Cookie nötig ist. Eine mögliche weitere Alternative ist Mobify.js. Dieses Stück JavaScript ermöglicht es vor dem Rendern, das HTML clientseitig zu editieren. Konkret bedeutet dies, dass die Bild-URL innerhalb von <img> in Form von src noch vor dem eigentlichen Herunterladen geändert wird, auf zum Beispiele eine kleinere Version. Damit sind keine Umwege über <span>s wie bei Picturefill nötig. Als Resultat wird aber dennoch das kleinere Bild geladen. Allerdings hapert es da noch ein wenig mit dem IE-Support.

Wer mehr über das gesamte Problem und weitere Alternativen erfahren will, findet zum Thema (englische) Artikel auf CSS-Tricks.com und Smashing Magazine.

Das Domain-Name-System, kurz DNS löst die für Menschen leicht merkbaren Domains (z.B. fliegentoeter.eu) nach den IP-Adressen der Webseite auf. Normalerweise verwendet der Computer/Handy etc. die DNS-Server des Internetdienstanbieters (Telekom, KabelDeutschland…). Nun gibt es aber bestimmte Voraussetzungen warum man andere DNS-Server verwenden möchte.

Gründe für die Änderung:

Mein erster Grund waren die häufigen DNS-Fehler der Telekom. Der nächste Grund wäre Zensur. Das beste Beispiel dafür ist zur Zeit wohl England. Dort werden bestimmte Webseiten in den DNS-Einstellungen der Internetanbieter gesperrt und können so nicht aufgerufen werden. Ein weiterer wichtiger Grund ist das DNS-Leak bei der Verwendung eines VPN-Dienstes.

Welche Alternativen DNS-Server verwenden?

Anbieter für zensurfreie DNS-Server gibt es viele. Am bekanntesten sind wohl OpenDNS und Google DNS. Die DNS-Server der Swiss Privacy Foundation kommen bei mir zum Einsatz. Sie enthalten keine Sperrlisten und legen keine Logfiles an. Also ideal um Zensur zu umgehen und in Verbindung eines VPNs anonym zu bleiben. Zudem sind sie schnell und bisher konnte ich noch keine Ausfälle (wie bei der Telekom) feststellen. Es kann nicht schaden den technischen Newsfeed (RSS-Version) zu verfolgen, falls sich ein Server ändern sollte.

DNS-Server ändern:

Eine Anleitung zur Änderung unter Windows findet man hier: Hilfe zu Windows
Nachfolgend eine Erklärung für Ubuntu (sollte aber auch für die meisten anderen Linux-Systeme gelten):

Um die DNS-Server zu ändern klickt man auf das Netzwerksymbol in der oberen Menüleiste, danach auf “Verbindungen bearbeiten”.

In diesem Fenster wählt man nun das Ethernet oder Funknetzwerk, deren DNS-Server man ändern möchte und klickt auf “Bearbeiten”.

Dann navigiert man zu den “IPv4-Einstellungen”, wählt bei “Methode” “Automatisch (DHCP), nur Adressen und trägt bei “DNS-Server” die gewünschten Server mit einem Komma getrennt ein.

Für die DNS-Server der Swiss Privacy Foundation wäre das zum Zeitpunkt dieses Beitrags dann: 77.109.138.45, 77.109.139.29, 87.118.85.241

Für die IPv6-Einstellungen habe ich bisher noch keine wirklich gute Alternative gefunden und deshalb erst mal die Google DNS-Server eingetragen: 2001:4860:4860::8888, 2001:4860:4860::8844

Dann ein klick auf “Speichern” und die DNS-Server sind geändert. Ob es funktioniert hat zeigt ein Blick in die Verbindungsinformationen:

Test:

Auf whoer.net kann man sich seine IP-Adresse und auch die verwendeten DNS-Server anzeigen lassen. Bei dnsleaktest.com kann die Verbindung auf DNS-Leaks überprüft werden.

Diesen Beitrag teilen: auf Facebook teilen auf Google+ teilen auf Twitter teilen

Mehr auf FliegenToeter.

Mozilla erweitert voraussichtlich in Firefox 30 sein Telemetrie-Feature um die Möglichkeit von Telemetrie-Experimenten. Dabei handelt es sich um zeitlich begrenzte Tests für eine statistisch relevante Zielgruppe.

Firefox besitzt mit dem Telemetrie-Feature eine Mess-Infrastruktur, um diverse Leistungsdaten während des Browserbetriebs anonym an die Mozilla-Server zu übertragen. Dieses Feature ist standardmäßig für Nutzer der Nightly- und Aurora-Versionen aktiviert und für Nutzer der Beta- sowie finalen Versionen deaktiviert. Telemetrie liefert Mozilla wichtige Erkenntnisse zur Nutzung des Browsers und möglichst jeder Nutzer sollte das Telemetrie-Feature aktivieren (Einstellungen → Erweitert → Datenübermittlung) – denn nur wer seine Daten übermittelt, für den kann gezielt optimiert werden.

Bei den Telemetrie-Experimenten handelt es sich um eine Erweiterung dieses Features. Nutzer, welche Telemetrie nicht aktiviert haben, nehmen auch nicht an den Telemetrie-Experimenten teil. Die Idee dahinter ist es, Daten einer statistisch relevanten Zielgruppe zu erhalten. Zu diesem Zweck ruft Firefox bei Nutzern mit aktivierter Telemetrie in regelmäßigen Abständen eine Liste mit aktuellen Experimenten ab. Diese enthält unter anderem Beginn und Ende des jeweiligen Experiments, die URL zum dazugehörigen Add-on, denn die durchgeführten Experimente werden als Add-on installiert, und Bedingungen für die Teilnahme wie das Betriebssystem und die Firefox-Version, aber auch eine JavaScript-Funktion, welche Zugriff auf die kompletten Telemetrie- und FHR-Daten hat. Bei FHR handelt es sich um ein weiteres optionales Feature zur Erhebung von Leistungsdaten in Firefox, welches allerdings standardmäßig in allen Release-Kanälen aktiviert ist.

Die Add-ons können die vorhandene Telemetrie- und FHR-Infrastruktur nutzen, aber auch neue Messungen einführen, welche Firefox normalerweise nicht besitzt. Jeder Nutzer kann an nur maximal einem Experiment gleichzeitig teilnehmen. Die Experimente enden automatisch nach einer bestimmten Anzahl von Tagen, außerdem können diese gezielt über den Add-on Manager, welcher einen eigenen Tab für die Telemetrie-Experimente erhält, deaktiviert werden. Deaktiviert der Nutzer Telemetrie, werden damit umgehend auch die Telemetrie-Experimente beendet und entfernt. Der Status der Experimente soll außerdem auf about:support und in den Absturzberichten angezeigt werden. Ziel für die Auslieferung des Features ist Firefox 30.

6. März 2014

Aviate Screenshot

Was meint Mobiltelefon angeht, war ich bisher nicht so der Spezialexperte im Kostümieren: Nexus 4 — Das ist das nackte Android, so wie Google es erschaffen hat. Ohne die ganze Bloatware, die Samsung & Co. inzwischen mitliefern. Dann kam Aviate vor einigen Monaten. Seither habe geht es rund.

Aviate ist ein Launcher für Android — also die App, die quasi den Desktop darstellt. Und während Apple immer noch nur das anbietet, was bei Windows ein Desktop voller Programm-Icons wäre, können die Launcher bei Android richtig viel. Und am besten gefällt mir, was Aviate macht: Je nachdem wie spät es ist oder wo ich bin (In welchem WLAN), zeigt mir die App unterschiedliche Funktionen an.

Auf dem Homescreen habe ich unten ganz normal die Kamera, den Browser, das Telefon, die Hangout-/SMS-App und die Kontakte, zusammen mit einem Foto, das mir gute Laune macht. Oben drüber ist dann die Leiste für den „Space“ — also den Anwendungsfall, den Aviate gerade unterstellt. Wenn ich zu Hause bin und die Uhrzeit früh, zeigt mir Aviate den „Morning“-Space an. Auf dem Weg zur Arbeit den „Going Somewhere“-Space, bei der Arbeit den „Work“-Space und zurück zu Hause den „Home“- und später den „Night Time“-Space. Jedesmal gibt es andere App-Icons.

Bei „Going Somewhere“ habe ich beispielsweise die Navigationsapp, die DB-App und die Podcast-App. Wenn ich da auf den „Home“-Knopf drück, geht die Navigations-App auf und sucht mir dann eine Bahn-Verbindung raus. Bei der Arbeit werden mir zusätzlich die nächsten Termine in meinem Kalender angezeigt und ein Kurzlink zum Erstellen eines neuen Termins. Neuerdings gibt es einen „Listening“-Space, der Infos zur aktuellen Musik heraussucht — ob ich das wirklich brauche, weiß ich noch nicht. Chic ist es aber.

Mittlerweile stellt Aviate recht zuverlässig den gerade passenden Space ein. Man kann aber auch manuell wechseln und natürlich kommt man auch einfach an eine alphabetische Liste der Apps, so dass man nie lange suchen muss.

Seit heute unterstützt Aviate auch Icons-Sets, wie sie für andere Launcher schon lange verfügbar sind. Damit bekommen alle App-Icons ein einheitliches Aussehen — zumindest, wenn ein passendes Icons erstellt wurde. Bei unbekannten Apps wird einfach das normale Icon in den Style gepresst. Ich habe mir das „Lumos“-Paket installiert — das umfasst die meisten Icons und sieht von denen, die ich ausprobiert habe, am besten aus. Seit die Oberfläche so ansehnlich ist und viele Funktionen zum Beispiel für Mail und Kalender so einfach zu erreichen sind, habe ich den Eindruck, viel mehr von meinem Telefon zu haben.

Aviate lässt sich immer noch nur mit einem Einladung-Code aktivieren. 3 Codes habe ich noch. Wenn Du Aviate ausprobieren möchtest, hinterlass einen Kommentar mit einem guten Witz und der E-Mail-Adresse, an die die Einladung gehen soll.

Video

Links

Aviate Screenshot

Was meint Mobiltelefon angeht, war ich bisher nicht so der Spezialexperte im Kostümieren: Nexus 4 — Das ist das nackte Android, so wie Google es erschaffen hat. Ohne die ganze Bloatware, die Samsung & Co. inzwischen mitliefern. Dann kam Aviate vor einigen Monaten. Seither habe geht es rund.

Aviate ist ein Launcher für Android — also die App, die quasi den Desktop darstellt. Und während Apple immer noch nur das anbietet, was bei Windows ein Desktop voller Programm-Icons wäre, können die Launcher bei Android richtig viel. Und am besten gefällt mir, was Aviate macht: Je nachdem wie spät es ist oder wo ich bin (In welchem WLAN), zeigt mir die App unterschiedliche Funktionen an.

Auf dem Homescreen habe ich unten ganz normal die Kamera, den Browser, das Telefon, die Hangout-/SMS-App und die Kontakte, zusammen mit einem Foto, das mir gute Laune macht. Oben drüber ist dann die Leiste für den „Space“ — also den Anwendungsfall, den Aviate gerade unterstellt. Wenn ich zu Hause bin und die Uhrzeit früh, zeigt mir Aviate den „Morning“-Space an. Auf dem Weg zur Arbeit den „Going Somewhere“-Space, bei der Arbeit den „Work“-Space und zurück zu Hause den „Home“- und später den „Night Time“-Space. Jedesmal gibt es andere App-Icons.

Bei „Going Somewhere“ habe ich beispielsweise die Navigationsapp, die DB-App und die Podcast-App. Wenn ich da auf den „Home“-Knopf drück, geht die Navigations-App auf und sucht mir dann eine Bahn-Verbindung raus. Bei der Arbeit werden mir zusätzlich die nächsten Termine in meinem Kalender angezeigt und ein Kurzlink zum Erstellen eines neuen Termins. Neuerdings gibt es einen „Listening“-Space, der Infos zur aktuellen Musik heraussucht — ob ich das wirklich brauche, weiß ich noch nicht. Chic ist es aber.

Mittlerweile stellt Aviate recht zuverlässig den gerade passenden Space ein. Man kann aber auch manuell wechseln und natürlich kommt man auch einfach an eine alphabetische Liste der Apps, so dass man nie lange suchen muss.

Seit heute unterstützt Aviate auch Icons-Sets, wie sie für andere Launcher schon lange verfügbar sind. Damit bekommen alle App-Icons ein einheitliches Aussehen — zumindest, wenn ein passendes Icons erstellt wurde. Bei unbekannten Apps wird einfach das normale Icon in den Style gepresst. Ich habe mir das „Lumos“-Paket installiert — das umfasst die meisten Icons und sieht von denen, die ich ausprobiert habe, am besten aus. Seit die Oberfläche so ansehnlich ist und viele Funktionen zum Beispiel für Mail und Kalender so einfach zu erreichen sind, habe ich den Eindruck, viel mehr von meinem Telefon zu haben.

Aviate lässt sich immer noch nur mit einem Einladung-Code aktivieren. 3 Codes habe ich noch. Wenn Du Aviate ausprobieren möchtest, hinterlass einen Kommentar mit einem guten Witz und der E-Mail-Adresse, an die die Einladung gehen soll.

Video

Links

Beim Einstieg dieses Artikels wird einem schonmal ganz anders: Für ein einfaches Laden der Website moto.oakley.com brauchte jemand fast 89 MB. Heute sind es immerhin noch 15 MB. Hauptgrund sind vor allem die Bilder. Wie kann man diese also verkleinern? Bei großen Mengen an Bilder sollte dies – natürlich – möglichst schnell und automatisiert vonstattengehen. Ich werde dabei ein paar Programme aus dem oben bereits verlinkten Artikel testen.

JPEG

Als erstes Format kommt JPEG in Frage. Es ist wohl das populärste Rastergrafikformat, denn es wird beispielsweise in so gut wie allen Kameras verwendet.

JPEGrescan

JPEGrescan benötigt nur perl und das perl-Modul (file-)slurp. Unter Linux-Distributionen geht die Installation damit schnell vonstatten.

Das Ziel von JPEGrescan ist dabei, den Komprimierungsrad der JPEGs so anzupassen, dass wirklich kein Datenverlust – in Form von zum Beispiel Artefakten – auftritt. Dementsprechend fallen auch die Größeneinsparungen meist in den einstelligen Prozentbereich.

Kompilieren muss man hier nichts, sondern kann nach dem Herunterladen des Skripts sofort loslegen. Dazu braucht es nur ein einfaches

$ jpegrescan in.jpg out.jpg

adept-jpg-compressor

Ein alternatives Werkzeug ist adept-jpg-compressor. Es ist eigentlich nur ein einfaches Shellskript, welches das Bild zuerst aufteilt. Anschließend wird einzeln probiert, wie stark jeder Teil komprimiert werden kann, um noch die gleiche Qualität zu bieten. Zum Schluss wird das Bild wieder zusammengesetzt. Vorteil: Nicht jeder Bildteil muss gleich stark komprimiert werden. Eine ausführlicherer und bebilderte Beschreibung gibt es in der README auf GitHub.

Die Programmabhängigkeiten belaufen sich überdies auf ImageMagick, jpegoptim, dem weiter oben genannten JPEGrescan und einigen „Standard-Shell-Tools“. Damit ist die Installation und Ausführung simpel: Einfach nur das Shellskript herunterladen und per

bash adept.sh /path/to/image.jpg

im selben Ordner starten. Das angepasste Bild wird im selben Verzeichnis mit dem Namenssuffix „adept_compress.jpg“ gespeichert.

Leider fiel in meinem Test die „adepted“ Version des Bildes größer aus als das Original. Möglicherweise hängt dies mit der Fehlermeldung von ImageMagick zu Fonts zusammen. Allerdings habe ich dazu keine weiteren Infos oder eine Lösung gefunden.

PNG

PNG unterscheidet sich vor allem in zwei Punkten gegenüber JPEG:

  • Unterstützung von Transparenz
  • verlustfreies Bildformat (d. h. keine Artefakte)

Der gesamte Verkleinerungsprozess gliedert sich bei PNGs in drei Schritte – und damit drei Programme.

Verlustbehaftete Kompression

Das Programm meiner Wahl beim verlustbehafteten Komprimieren war pngquant2. Es reduziert vor allem die Anzahl der verwendeten Farben, nämlich von 24-bit auf maximal 8-bit (also 256 Farben). Einerseits ist die geringe Anzahl an Farben bei einem direkten Vergleich zwischen Original und deutlich sichtbar. Allerdings wird die Größe des Bildes auch deutlich verkleinert – was bei Bildern für das Web meiner Meinung nach höher wiegt.

Von Version 1.0, die sich noch in Quellen zahlreicher Linux-Distributionen findet, wird indes abgeraten. Beispielsweise wird pngquant2 erst ab Ubuntu 14.04 in den offiziellen Quellen liegen. Daher bleibt nur der Weg von Fremdquellen oder des Kompilierens (siehe dazu weiter oben die verlinkte Website).

Die grundlegende Anwendung erfolgt dabei über

pngquant <Datei_zum_Komprimieren.png>

Außerdem verwende ich immer den Parameter -s1. Dies verlängert die Komprimierungszeit ein wenig, erhöht die Qualität allerdings auf ein Maximum. Ein Beispiel findet sich auch hier im Archiv mit den Testbildern unter Spiel/png/speed-fs8. Ferner kann man mit der Anzahl der Farben spielen, um so ggf. ein kleineres Resultat zu erhalten:

pngquant <AnzahlFarben> <Datei_zum_Komprimieren.png>

Im Archiv mit allen Testbildern gibt es dazu ein paar Beispiele unter Spiel/png/numberofcolors. Die komprimierten PNGs erhalten immer den Zusatz -or8.png oder -fs8.png.

Filter

Der nächste Schritt ist das Herausfinden des besten Filters.

pngwolf

pngwolf wollte bei mir einfach nicht durch den Compiler und damit auch nicht verwendet werden… Im Folgenden dennoch mein Vorgehen – vielleicht liegt der Fehler einfach bei mir:

  1. Sourecode von GitHub holen
  2. drei Abhängigkeiten herunterladen

    • GAlib: http://lancet.mit.edu/ga/dist/
    • 7-Zip: http://www.7-zip.org/download.html
    • zlib: http://zlib.net/
  3. Ablegen der heruntergeladenen Archive als Unterverzeichnis des Sourcecodes von pngwolf

  4. Umbenennen der drei Ordner in galib, 7zip und zlib
  5. Patch anwenden

    $ patch -p 0 < sevenzip920.patch
    
  6. erhält Fehler vom Patchen → ignoriert

  7. CMake im Ordner von pngwolf ausführen

    $ cmake CMakeLists.txt
    
  8. eigentliches Make (immer noch im selben Verzeichnis)

    $ make
    

Auch ein Skript gab das selbe Resultat. Scheint aber mehr Leuten so zu gehen.

optipng

Die Alternative war dann optipng. Dieses Programm gibt es wiederum in eigentlich jedem Paketrepositorium, zum Beispiel Ubuntu oder Arch Linux. Die Installation ist damit schnell.

Der Programmaufruf ist per

    optipng -out Bild_opti.png Bild.png

möglich. Die Ausgabe erfolgt hier dann in Bild_opti.png.

Den Komprimierungsgrad kann man dabei über eine Option -o[N] festlegen. [N] kann durch eine Zahl zwischen 0 und 7 ersetzt werden, wobei 7 am längsten dauert und somit am besten komprimiert. Standardeinstellung ist 2.

Als Beispiel habe ich mal die Ergebnisse ein und des selben Bildes verglichen. Mit der Option -o7 benötigte mein Rechner 3 Minuten 33 Sekunden. Mit den Standardoptionen 13,8 s. Die Dateigröße hat sich dabei um gerade mal 9,1 kByte verändert – beide Ausgaben des Spielscreenshots sind dabei annähernd 3 MB groß. (im Archiv mit allen Testbildern finden sich die Bilder unter Spiel/png/optipng-test-o-Option) Ob sich die längere Verarbeitungsdauer also lohnt, muss jeder selbst entscheiden.

Verlustfreie Kompression

Letzter Schritt ist das verlustfreie Komprimieren. Interessant ist hier zopfli. Das verwendete Verfahren ist zu zlib kompatibel, die Dateien werden dabei allerdings um 5 % kleiner. Jedoch verlängert sich die Komprimierungsdauer.

Zur Installation das Archiv von Google Code herunterladen und, solange man nur zopflipng verwenden möchte, ein

make zopflipng

ausführen. Nach dem Kompilieren landet das Programm betriebsbereit im selben Ordner. Der einfachste Befehl ist dabei für ein Bild:

./zopflipng infile.png outfile.png

Eine längere Liste an Parametern, die auch Filter umfasst, findet sich dann unter ./zopflipng -h. Dafür, dass die Entwickler es als Alpha-Release bezeichnen, arbeitet es in einem ersten Test wirklich stabil.

Onlinetools

Die Onlinetools sind nur für einen Vergleich gedacht. Ich persönliche rate von diesen Diensten ab, weil man a) bei der Menge an zu verkleinernden Bildern begrenzt ist b) (ein kleineres Problem) nicht weiß, was die Dienste mit den Daten machen.

JPEGmini

JPEGmini ist – nach dem Namen eigentlich klar – zum Verkleinern von JPEG-Bildern gedacht. Auf der Startseite wird direkt mit Beispielen geworben, wie viel man durch JPEGMini sparen kann. Das Prinzip ist dabei eigentlich das selbe wie bei den anderen Programmen: den Komprimierungsgrad möglichst hoch und damit die Bildgröße klein halten. Nur soll es hier nicht mathematisch identisch sein, sondern „nur“ für das menschliche Auge identisch erscheinen.

Tinypng

tinypng ist dagegen für PNGs gedacht. Es setzt dabei ähnlich wie pngquant auf eine Reduktion der PNGs auf 8-bit.

Auswertung

Screenshot eines Spieles

Eine kleine Vorbemerkung: Im Nachhinein gesehen ähnelt dieser Screenshot wohl eher einem Foto statt einem „normalen“ Screenshot mit viel gleichfarbiger Fläche. Dafür gibt es noch ein zweites Beispiel im Anschluss.

PNG-Vergleich zum Spiel-Screenshot
Bild verwendete(s) Programm(e) Größe in kB
Original Screenshot per Druck-Taste unter Windows in RAM, anschließend gespeichert mit GIMP 3380
auf 256 Farben pngquant2 942
pngquant2 → optipng 924
pngquant2 → optipng → zopfli 878
tinypng 872

Gerade pngquant verkleinert das Bild immens. Von anfänglich 3380 kB auf 942 kB – das sind über 72 %. optipng und zopfli verkleinern das erhaltenen Bild um weitere 6,8 %. Mit 878 kB in der Endfassung sind die drei Werkzeuge zusammen annähernd so gut wie tinypng. Die 6 kByte Unterschied kann man gerade noch verschmerzen. ;) Allerdings ist das immer noch ein riesiger BLOB gegenüber JPEG…

JPEG-Vergleich zum Spiel-Screenshot
Bild verwendete(s) Programm(e) Größe in kB
Originales JPEG konvertiert aus PNG mit ImageMagick 656
manuell komprimiert mit GIMP 492
JPEGrescan 617
adept_compress 769
JPEGmini 454

JPEGMini kommt hier auf eine Dateigröße von circa 454 kB – das Ergebnis ist somit fast halb so groß wie das kleinste PNG-Bild. Das JPEGMini-Bild ist meiner Meinung nach qualitativ etwas schlechter als das manuell angepasste – aber dennoch finde ich das Resultat für ein Stück Software beachtlich. Man muss zudem, um Unterschiede überhaupt erkennen zu können, schon stark bei beiden Bildern zoomen.

JPEGrescan und adept_compress können dagegen nicht sehr viel Platz gut machen. Letzteres Werkzeug vergrößert das Bild in diesem Fall sogar.

Screenshot eines Programms

Bei einem Screenshot mit Programmen sieht die Sache dagegen anders aus: Hier kann pngquant seine volle Stärke ausspielen, da nicht wirklich mehr wie 256 Farben verwendet werden. Einzig die Programmicons auf der linken Seite schauen etwas schlechter aus. Zudem bietet hier PNG generell den Vorteil, dass die Schrift auch bei höheren Zoomstufen noch knackig scharf aussieht.

Bei JPEG erscheint dagegen mit zunehmender Komprimierung ein „grieseliger“ Schatten um die Schrift. Bei der manuellen Verkleinerung mit GIMP war ich also vor allem dadurch beschränkt. In dem Beispiel habe ich versucht, dieses Phänomen in einem akzeptablen Rahmen zu halten.

Unter anderem deshalb liegt der Größenunterschied zwischen dem JPEG und dem originalen PNG nur bei 44 kB. Das optimierte PNG-Bild dagegen ist mit 116 kB wesentlich kleiner gegenüber den anfänglichen 380.

Übersicht Dateigrößen zu Programm-Screenshots
Bild verwendete(s) Programm(e) Größe in kB
Original (mitgeliefertes Screenshot-Tool von Ubuntu 12.04) 380
JPEG manuelle Komprimierung mit GIMP 336
optimiertes PNG pngquant → optipng → zopfli 116

Fazit

Sollte das Bild also keine Transparenz beinhalten, werde ich Bilder im JPEG-Format abspeichern. Grund ist, dass JPEG in Summe meistens kleiner ausfallen bei annähernd ähnlicher Bildqualiät. Ausnahmen bilden hier Screenshots mit viel gleichfarbiger Fläche. PNG scheint da einfach unschlagbar zu sein.

Wenn es nicht allzu viele Bilder auf einmal sind, habe ich zudem vor, JPEGs manuell zu verkleinern. Zumindest kam ich hier mit Augenmaß auf eine ähnliche Dateigröße wie JPEGMini. Das bietet zudem den Vorteil, dass man Bilder auch zurecht schneiden kann. Damit bleibt der Fokus, gerade auf mobilen Geräte mit kleinem Bildschirm, auf das wichtigste Motiv erhalten.

Ansonsten gibt es aber auch genügend Methoden für die Kommandozeile – und damit ist der Prozess leicht automatisierbar.

Weiterführende Infos und Werkzeugliste für Formate wie svg oder gif

Beim Einstieg dieses Artikels wird einem schonmal ganz anders: Für ein einfaches Laden der Website moto.oakley.com brauchte jemand fast 89 MB. Heute sind es immerhin noch 15 MB. Hauptgrund sind vor allem die Bilder. Wie kann man diese also verkleinern? Bei großen Mengen an Bilder sollte dies – natürlich – möglichst schnell und automatisiert vonstattengehen. Ich werde dabei ein paar Programme aus dem oben bereits verlinkten Artikel testen.

JPEG

Als erstes Format kommt JPEG in Frage. Es ist wohl das populärste Rastergrafikformat, denn es wird beispielsweise in so gut wie allen Kameras verwendet.

JPEGrescan

JPEGrescan benötigt nur perl und das perl-Modul (file-)slurp. Unter Linux-Distributionen geht die Installation damit schnell vonstatten.

Das Ziel von JPEGrescan ist dabei, den Komprimierungsrad der JPEGs so anzupassen, dass wirklich kein Datenverlust – in Form von zum Beispiel Artefakten – auftritt. Dementsprechend fallen auch die Größeneinsparungen meist in den einstelligen Prozentbereich.

Kompilieren muss man hier nichts, sondern kann nach dem Herunterladen des Skripts sofort loslegen. Dazu braucht es nur ein einfaches

1
$ jpegrescan in.jpg out.jpg

adept-jpg-compressor

Ein alternatives Werkzeug ist adept-jpg-compressor. Es ist eigentlich nur ein einfaches Shellskript, welches das Bild zuerst aufteilt. Anschließend wird einzeln probiert, wie stark jeder Teil komprimiert werden kann, um noch die gleiche Qualität zu bieten. Zum Schluss wird das Bild wieder zusammengesetzt. Vorteil: Nicht jeder Bildteil muss gleich stark komprimiert werden. Eine ausführlicherer und bebilderte Beschreibung gibt es in der README auf GitHub.

Die Programmabhängigkeiten belaufen sich überdies auf ImageMagick, jpegoptim, dem weiter oben genannten JPEGrescan und einigen „Standard-Shell-Tools“. Damit ist die Installation und Ausführung simpel: Einfach nur das Shellskript herunterladen und per

1
bash adept.sh /path/to/image.jpg

im selben Ordner starten. Das angepasste Bild wird im selben Verzeichnis mit dem Namenssuffix „adept_compress.jpg“ gespeichert.

Leider fiel in meinem Test die „adepted“ Version des Bildes größer aus als das Original. Möglicherweise hängt dies mit der Fehlermeldung von ImageMagick zu Fonts zusammen. Allerdings habe ich dazu keine weiteren Infos oder eine Lösung gefunden.

PNG

PNG unterscheidet sich vor allem in zwei Punkten gegenüber JPEG:

  • Unterstützung von Transparenz
  • verlustfreies Bildformat (d. h. keine Artefakte)

Der gesamte Verkleinerungsprozess gliedert sich bei PNGs in drei Schritte – und damit drei Programme.

Verlustbehaftete Kompression

Das Programm meiner Wahl beim verlustbehafteten Komprimieren war pngquant2. Es reduziert vor allem die Anzahl der verwendeten Farben, nämlich von 24-bit auf maximal 8-bit (also 256 Farben). Einerseits ist die geringe Anzahl an Farben bei einem direkten Vergleich zwischen Original und deutlich sichtbar. Allerdings wird die Größe des Bildes auch deutlich verkleinert – was bei Bildern für das Web meiner Meinung nach höher wiegt.

Von Version 1.0, die sich noch in Quellen zahlreicher Linux-Distributionen findet, wird indes abgeraten. Beispielsweise wird pngquant2 erst ab Ubuntu 14.04 in den offiziellen Quellen liegen. Daher bleibt nur der Weg von Fremdquellen oder des Kompilierens (siehe dazu weiter oben die verlinkte Website).

Die grundlegende Anwendung erfolgt dabei über

1
pngquant <Datei_zum_Komprimieren.png>

Außerdem verwende ich immer den Parameter -s1. Dies verlängert die Komprimierungszeit ein wenig, erhöht die Qualität allerdings auf ein Maximum. Ein Beispiel findet sich auch hier im Archiv mit den Testbildern unter Spiel/png/speed-fs8. Ferner kann man mit der Anzahl der Farben spielen, um so ggf. ein kleineres Resultat zu erhalten:

1
pngquant <AnzahlFarben> <Datei_zum_Komprimieren.png>

Im Archiv mit allen Testbildern gibt es dazu ein paar Beispiele unter Spiel/png/numberofcolors. Die komprimierten PNGs erhalten immer den Zusatz -or8.png oder -fs8.png.

Filter

Der nächste Schritt ist das Herausfinden des besten Filters.

pngwolf

pngwolf wollte bei mir einfach nicht durch den Compiler und damit auch nicht verwendet werden… Im Folgenden dennoch mein Vorgehen – vielleicht liegt der Fehler einfach bei mir:

  1. Sourecode von GitHub holen
  2. drei Abhängigkeiten herunterladen

    • GAlib: http://lancet.mit.edu/ga/dist/
    • 7-Zip: http://www.7-zip.org/download.html
    • zlib: http://zlib.net/
  3. Ablegen der heruntergeladenen Archive als Unterverzeichnis des Sourcecodes von pngwolf

  4. Umbenennen der drei Ordner in galib, 7zip und zlib
  5. Patch anwenden

    1
    $ patch -p 0 < sevenzip920.patch
    
  6. erhält Fehler vom Patchen → ignoriert

  7. CMake im Ordner von pngwolf ausführen

    1
    $ cmake CMakeLists.txt
    
  8. eigentliches Make (immer noch im selben Verzeichnis)

    1
    $ make
    

Auch ein Skript gab das selbe Resultat. Scheint aber mehr Leuten so zu gehen.

optipng

Die Alternative war dann optipng. Dieses Programm gibt es wiederum in eigentlich jedem Paketrepositorium, zum Beispiel Ubuntu oder Arch Linux. Die Installation ist damit schnell vollbracht.

Der Programmaufruf ist per

1
optipng -out Bild_opti.png Bild.png

möglich. Die Ausgabe erfolgt dann in Bild_opti.png.

Den Komprimierungsgrad kann man dabei über eine Option -o[N] festlegen. [N] kann durch eine Zahl zwischen 0 und 7 ersetzt werden, wobei 7 am längsten dauert und somit am besten komprimiert. Standardeinstellung ist 2.

Als Beispiel habe ich mal die Ergebnisse ein und des selben Bildes verglichen. Mit der Option -o7 benötigte mein Rechner 3 Minuten 33 Sekunden. Mit den Standardoptionen 13,8 s. Die Dateigröße hat sich dabei um gerade mal 9,1 kByte verändert – beide Ausgaben des Spielscreenshots sind dabei annähernd 3 MB groß. (im Archiv mit allen Testbildern finden sich die Bilder unter Spiel/png/optipng-test-o-Option) Ob sich die längere Verarbeitungsdauer also lohnt, muss jeder selbst entscheiden.

Verlustfreie Kompression

Letzter Schritt ist das verlustfreie Komprimieren. Interessant ist hier zopfli. Das verwendete Verfahren ist zu zlib kompatibel, die Dateien werden dabei allerdings um 5 % kleiner. Jedoch verlängert sich die Komprimierungsdauer.

Zur Installation das Archiv von Google Code herunterladen und, solange man nur zopflipng verwenden möchte, ein

1
make zopflipng

ausführen. Nach dem Kompilieren landet das Programm betriebsbereit im selben Ordner. Der einfachste Befehl ist dabei für ein Bild:

1
./zopflipng infile.png outfile.png

Eine längere Liste an Parametern, die auch Filter umfasst, findet sich dann unter ./zopflipng -h. Dafür, dass die Entwickler es als Alpha-Release bezeichnen, arbeitet es in einem ersten Test wirklich stabil.

Onlinetools

Die Onlinetools sind nur für einen Vergleich gedacht. Ich persönliche rate von diesen Diensten ab, weil man a) bei der Menge an zu verkleinernden Bildern begrenzt ist b) (ein kleineres Problem) nicht weiß, was die Dienste mit den Daten machen.

JPEGmini

JPEGmini ist – nach dem Namen eigentlich klar – zum Verkleinern von JPEG-Bildern gedacht. Auf der Startseite wird direkt mit Beispielen geworben, wie viel man durch JPEGMini sparen kann. Das Prinzip ist dabei eigentlich das selbe wie bei den anderen Programmen: den Komprimierungsgrad möglichst hoch und damit die Bildgröße klein halten. Nur soll es hier nicht mathematisch identisch sein, sondern „nur“ für das menschliche Auge identisch erscheinen.

Tinypng

der charakteristische Panda von tinypng

tinypng ist dagegen für PNGs gedacht. Es setzt dabei ähnlich wie pngquant auf eine Reduktion der PNGs auf 8-bit.

Auswertung

Screenshot eines Spieles

Eine kleine Vorbemerkung: Im Nachhinein gesehen ähnelt dieser Screenshot wohl eher einem Foto statt einem „normalen“ Screenshot mit viel gleichfarbiger Fläche. Dafür gibt es noch ein zweites Beispiel im Anschluss.

PNG-Vergleich zum Spiel-Screenshot
Bild verwendete(s) Programm(e) Größe in kB
Original Screenshot per Druck-Taste unter Windows in RAM, anschließend gespeichert mit GIMP 3380
auf 256 Farben pngquant2 942
pngquant2 → optipng 924
pngquant2 → optipng → zopfli 878
tinypng 872

Gerade pngquant verkleinert das Bild immens. Von anfänglich 3380 kB auf 942 kB – das sind über 72 %. optipng und zopfli verkleinern das erhaltenen Bild um weitere 6,8 %. Mit 878 kB in der Endfassung sind die drei Werkzeuge zusammen annähernd so gut wie tinypng. Die 6 kByte Unterschied kann man gerade noch verschmerzen. ;) Allerdings ist das immer noch ein riesiger BLOB gegenüber JPEG…

JPEG-Vergleich zum Spiel-Screenshot
Bild verwendete(s) Programm(e) Größe in kB
Originales JPEG konvertiert aus PNG mit ImageMagick 656
manuell komprimiert mit GIMP 492
JPEGrescan 617
adept compress 769
JPEGmini 454

JPEGMini kommt hier auf eine Dateigröße von circa 454 kB – das Ergebnis ist somit fast halb so groß wie das kleinste PNG-Bild. Das JPEGMini-Bild ist meiner Meinung nach qualitativ etwas schlechter als das manuell angepasste – aber dennoch finde ich das Resultat für ein Stück Software beachtlich. Man muss zudem, um Unterschiede überhaupt erkennen zu können, schon stark bei beiden Bildern zoomen.

JPEGrescan und adept_compress können dagegen nicht sehr viel Platz gut machen. Letzteres Werkzeug vergrößert das Bild in diesem Fall sogar.

Screenshot eines Programms

Bei einem Screenshot mit Programmen sieht die Sache dagegen anders aus: Hier kann pngquant seine volle Stärke ausspielen, da nicht wirklich mehr wie 256 Farben verwendet werden. Einzig die Programmicons auf der linken Seite schauen etwas schlechter aus. Zudem bietet hier PNG generell den Vorteil, dass die Schrift auch bei höheren Zoomstufen noch knackig scharf aussieht.

Bei JPEG erscheint dagegen mit zunehmender Komprimierung ein „grieseliger“ Schatten um die Schrift. Bei der manuellen Verkleinerung mit GIMP war ich also vor allem dadurch beschränkt. In dem Beispiel habe ich versucht, dieses Phänomen in einem akzeptablen Rahmen zu halten.

Unter anderem deshalb liegt der Größenunterschied zwischen dem JPEG und dem originalen PNG nur bei 44 kB. Das optimierte PNG-Bild dagegen ist mit 116 kB wesentlich kleiner gegenüber den anfänglichen 380.

Übersicht Dateigrößen zu Programm-Screenshots
Bild verwendete(s) Programm(e) Größe in kB
Original (mitgeliefertes Screenshot-Tool von Ubuntu 12.04) 380
JPEG manuelle Komprimierung mit GIMP 336
optimiertes PNG pngquant → optipng → zopfli 116

Fazit

Sollte das Bild also keine Transparenz beinhalten, werde ich Bilder im JPEG-Format abspeichern. Grund ist, dass JPEG in Summe meistens kleiner ausfallen bei annähernd ähnlicher Bildqualiät. Ausnahmen bilden hier Screenshots mit viel gleichfarbiger Fläche. PNG scheint da einfach unschlagbar zu sein.

Wenn es nicht allzu viele Bilder auf einmal sind, habe ich zudem vor, JPEGs manuell zu verkleinern. Zumindest kam ich hier mit Augenmaß auf eine ähnliche Dateigröße wie JPEGMini. Das bietet zudem den Vorteil, dass man Bilder auch zurecht schneiden kann. Damit bleibt der Fokus, gerade auf mobilen Geräte mit kleinem Bildschirm, auf das wichtigste Motiv erhalten.

Ansonsten gibt es aber auch genügend Methoden für die Kommandozeile – und damit ist der Prozess leicht automatisierbar.

Weiterführende Infos und Werkzeugliste für Formate wie svg oder gif

Mein Jabber Server trashserver.net beherrscht ab sofort auch die Weitergabe von Statusinformationen zu Accounts via HTTP. Auf diese Weise kann der aktuelle Accountstatus (online, offline, …) ganz einfach in Blogs und Webseiten eingebunden werden. Wie das aussieht, seht ihr auf meiner Kontaktseite:

XMPP Status Kontakt

Zuständig für diese Funktion ist das Prosody Modul “mod_webpresence“. Wie ihr zusätzliche Module für Prosody installiert, erfahrt ihr in diesem Beitrag:

Ubuntu: Weitere Prosody XMPP Server Module installieren

Der HTML Code für die Darstellung auf meiner Blog Seite sieht wie folgt aus:

<li>
<strong>Jabber</strong> Chat: thomas.leister@trashserver.net<br>
(Onlinestatus:  <img alt="status-icon" src="http://trashserver.net:5280/status/thomas.leister" width="12" height="12" />
<iframe style="height: 20px; width: 60px; overflow: hidden;" src="http://trashserver.net:5280/status/thomas.leister/text" height="240" width="320" frameborder="0"></iframe>)
</li>

In das Diaspora* Profil kann der kleine Statusindikator auch eingebaut werden:

Status: ![XMPP Status Icon](http://trashserver.net:5280/status/thomas.leister)

Mittlerweile gibt es für den erfolgreichen XMPP Server Prosody 99 Erweiterungen, mit denen die Funktionalität sehr einfach erweitert werden kann. Zu den spannendsten Modulen gehören die Registrierung über ein Web-Frontend, Statusabfrage über HTTP und die Authentifizierung über den MDA Dovecot.

Alle verfügbaren Module sind inkl. kurzer Funktionsbeschreibung im Wiki bei Google Code aufgelistet

In diesem Beitrag geht es um die Installation und Aktivierung von neuen Modulen.

Meldet euch zunächst als root an eurem Server an und navigiert in das Verzeichnis /etc/prosody/ , in dem eure Prosody Konfiguration liegt.

sudo -s
cd /usr/local/

Jetzt wird das komplette Modul-Repository vom Google Code Server via Mercurial in den Ordner prosody-modules geklont. Ggf. muss zuerst Mercurial installiert werden, sodass der hg-Befehl verfügbar ist.

sudo apt-get install mercurial
hg clone http://prosody-modules.googlecode.com/hg/ prosody-modules

Nun wird die Hauptkonfiguration unter /etc/prosody/prosody.cfg.lua um folgende Zeile erweitert:

plugin_paths = { "/usr/local/prosody-modules" }

Diese sorgt dafür, dass Prosody im angegebenen Verzeichnis nach Modulen sucht und die neuen Module verfügbar gemacht werden.
Die einzelnen Module können nun zu “modules_enabled” hinzugefügt werden:

modules_enabled {
[...]
"register_web";  -- Modul für die Registrierung über das Webinterface
[...]
}

Wie hier schon zu sehen ist, fällt das “mod_” für den Modulbezeichner in der Konfiguration weg. Das gilt für alle Module. Damit die neue Konfiguration übernommen wird, wird der XMPP Server neu gestartet: (Achtung, nicht über “service”!)

prosodyctl restart

Da sich die meisten Module – genauso wie auch Prosody an sich – noch im Alpha- oder Betastadium befinden, ist es ratsam, sie von Zeit zu Zeit zu aktualisieren. Dazu wird in den prosody-modules Ordner gewechselt und der “hg pull” Befehl ausgeführt:

cd /usr/local/prosody-modules/
hg pull --update

Natürlich muss der XMPP- Server auch nach einem Modulupdate neu gestartet werden.

Auf dem Bild seht ihr einen kleinen Preview zu Version 0.3 meines Codeeditors BlogonautEdit. Sofort ins Auge stechen da natürlich die Tabs die derzeit ein Code Tab und ein Tab namens Revisionen beinhalten. Der Tab Revisionen ist der neue Tab unter dem ihr die Revisionen eurer Datei mit dem neuem Revisionssystem verwalten könnt. Dazu habe ich auch noch dass Kate Theme sowie einige neue Sprachen hinzugefügt. 🙂

BlogonautEdit-V0.3-Preview1

Viel Spaß bei der Vorfreude auf die neuen Features. 😉

Titel Kanban in der IT (2. Auflage)
Autor Klaus Leopold, Siegfried Kaltenecker
Sprache Deutsch
Genre Fachbuch
Herausgeber Carl Hanser Verlag, 2013
Seitenanzahl 290 Seiten

Agile Softwareentwicklung spielt in vielen Projekten bereits eine große Rolle. Andere sind wiederum erst dabei, es einzuführen. Das Buch „Kanban in der IT“ soll bei der Einführung von Kanban helfen.

Inhalt des Buches

Das Buch „Kanban in der IT“ untergliedert sich in drei Teile.

Der erste Teil beschäftigt sich mit den Prinzipien und Praktiken von Kanban. Dazu zählt natürlich auch das Kanban-Board und dessen Erstellung mitsamt WiP-Limits („Work in Progress“) und Serviceklassen. Messungen und Metriken sollen dabei helfen, den Prozess zu verbessern.

Der zweite Teil zielt dann eher auf den eigentlichen Wandel in einer Firma bzw. einem Projekt ab. Wie wird Kanban eingeführt und welche Probleme können dabei entstehen? Und dass Probleme und Konflikte entstehen, kann man mit Sicherheit vorab sagen, da Menschen sich allgemein ungern umstellen. Und ein neuer Arbeitsprozess ist keine Kleinigkeit.

Der dritte Teil zeigt zum Schluss Praxisbeispiele für die Einführung und Umsetzung von Kanban an. Hierbei werden auch verschiedene Moderationsmöglichkeiten für die einzelnen Meetings vorgestellt.

Praktischerweise findet sich am Ende jedes Kapitels eine kurze Zusammenfassung über den Inhalt und was man im Optimalfall gelernt hat. Als Kurzüberblick nach dem Lesen des Buches und Wiedereinstieg zu einem späteren Zeitpunkt sind diese Zusammenfassungen ebenfalls geeignet, auch wenn man dafür durch das Buch blättern muss.

Das komplette Inhaltsverzeichnis kann auf der Webseite zum Buch gefunden werden.

Zielgruppe

Wer sich das Buch zulegt, um sich in die Kanban-Prinzipien und -Praktiken einzuarbeiten, wird vielleicht etwas enttäuscht sein, da bereits nach 88 Seiten alles gesagt ist, was man wissen muss: Sehr kompakt, aber nicht weniger gut zeigen die beiden Autoren Klaus Leopold und Siegfried Kaltenecker in Teil I auf, was Kanban ist.

Teil II und III richten sich dann aber komplett an das Management bzw. an die Personen, die Kanban bei sich im Projekt einführen wollen. Es schadet sicherlich nicht, wenn auch ein „normaler“ Projektmitarbeiter diese Kapitel liest, aber sie sind nicht notwendig, um Kanban zu verstehen.

Schlimmer noch könnte es für einen Projektmitarbeiter, der diese Kapitel gelesen hat und sich auf die Einführung von Kanban in seinem Projekt freut, enttäuschend sein, wenn es am nächsten Morgen vom Management heißt: „Ihr macht jetzt Kanban. Wir haben das Board für Euch ausgearbeitet. Wer nicht 100% ausgelastet ist, fliegt raus.“ Dann hat das Management das Buch nämlich nicht gelesen – und vor allem nicht verstanden, was Kanban ist.

Im Buch wird mehrfach darauf hingewiesen, dass Kanban nicht von oben von der Leitung/Management über ein Projekt gestülpt werden darf, sondern die Projektmitarbeiter den Wandel herbeiführen müssen. Zusätzlich ist Kanban kein fester Prozess, sondern soll sich kontinuierlich verbessern.

Kritik

Für eine Einführung in Kanban ist das Buch zwar geeignet, aber es ist nicht der Hauptbestandteil. Die verschiedenen Kanban-Praktiken werden sehr gut im ersten Teil beschrieben. Der Begriff „Kaizen“ wird dabei erklärt und kann sich auch auf Nicht-Kanban-Projekte positiv auswirken.

Der Aufbau eines Kanban-Boards wird ebenfalls gut erklärt. Teil III ist dabei auch hilfreich, weil detailliert erklärt wird, wie ein Beispielmeeting zur initialen Gestaltung eines Kanban-Boards aussehen kann. Natürlich sind das auch nur wieder Erfahrungswerte der beiden Autoren – aber wie bei Kanban üblich gibt es eben keine festen Regeln, sondern nur Prinzipien und Hinweise, wie etwas gehen könnte, aber nicht zwingend muss.

Dieses „Kann, aber nicht Muss“ ist sehr erfreulich und erfrischend, weil man es mitunter aus dem eigenen Projekt anders gewöhnt ist. Dabei ist dies extrem wichtig, denn Kanban erfordert einen Kulturwandel, der von den Mitarbeitern eines Projekts kommen muss. Wenn man diese nicht überzeugt und abholt, wird die Umsetzung scheitern. Ein Überstülpen von oben bringt nichts.

Hierbei kann man diese Kanban-Mentalität auch auf andere Prozessänderungen bzw. auf alle Managemententscheidung anwenden, denn sehr oft ist nicht klar, in welche Richtung die Teamleitung läuft. Da ist es kein Wunder, wenn die Mitarbeiter nicht wie die Schafe brav in den Abgrund hinterher laufen.

Was vielleicht für den einen oder anderen ungewohnt ist, ist, dass Mitarbeiter nicht zu 100% ausgelastet sein müssen. Das Prinzip dahinter ist, dass der Durchsatz maximiert werden soll. Sprich, es soll viel erledigt werden und nicht viel angefangen werden. Das Prinzip „Stop Starting, Start Finishing“ ist spielt dabei nicht nur bei Kanban eine wichtige Rolle, sondern bei allen agilen Entwicklungsmethoden.

Fazit

Insgesamt war das Buch gut zu lesen, richtet sich aber eben eher an Management und Teamleitung und weniger an die Mitarbeiter in einem (zukünftigen) Kanban-orientierten Projekt.

Bei freiesMagazin wird ein Kanban-Board bereits seit 2007 eingesetzt, auch wenn der Begriff „Kanban“ bei der Einführung nicht bekannt war und auch heute keine Rolle spielt. Das Board hat sich im Laufe der Jahre immer wieder geändert, wobei die Mitarbeiter selbst den Inhalt und Aufbau bestimmen bzw. anregen. Jeden Monat gibt es eine kurze Analyse, welche Arbeiten gut gelaufen sind und wo vielleicht ein Engpass auftrat.

freiesmagazin-kanban-board.png

MATE – als Gnome2-Ersatz – und Xfce neigen häufig zu unangenehmen Tearing. Schade, beide bieten schließlich schöne Desktops mit reichlich Möglichkeit zur Einstellung, besonders Xfce. Besonders störend empfinden viele es beim Scrollen von Webseiten im Zusammenspiel mit weichem Bildlauf.

Compton ist ein Abkömmling von „xcompmgr-dana“, welcher weiterhin ein Abkömmling des „xcompmgr“ ist. Es arbeitet als leichtgewichtiger und eigenständiger Composite-Manager, unabhängig vom eingesetzten Fenster-Manager. Richtig konfiguriert, eliminiert Compton das störende Tearing. Natürlich ist Compton zu noch mehr fähig, was aber nicht das primäre Ziel des Artikels ist.

Compton ist Bestandteil des Debian Repository ab Jessie/Testing. Für Ubuntu steht ein PPA zur Verfügung, welches Pakete ab Version 12.04 bis 13.10 enthält. Ubuntu 14.04 LTS hat Compton bereits in die offiziellen Paketquellen aufgenommen.

Changelog

  • 16. Mär – Window Type Settings entfernt

Tearing-Effekt

Tearing bezeichnet ein Zerreißen der Darstellung bei bewegten Bildern.

Tearing Beispiel 1

Tearing Beispiel 1


Tearing Beispiel 2

Tearing Beispiel 2

Optional: Intel TearFree

Eins vorab: Benutzer einer Intel-Grafikeinheit, haben die Möglichkeit „TearFree“ als Option an den XServer zu übergeben.

1
2
3
...
Option "TearFree" "true"
...

Hilft. Oder verbessert. Besser geht es mit Compton.

Compton

Wichtig: Zuerst muss sichergestellt sein, dass der Compositer des Desktops deaktiviert ist.
MATE-Benutzer können dies unter „Einstellungen > Fenster“ festlegen.
Für Xfce erspare ich mir den Weg in die Einstellungen und benutze stattdessen folgenden Befehl:

1
xfconf-query -c xfwm4 -p /general/use_compositing -t bool -s false

Nun die Installation unter Debian:

1
sudo apt-get install compton

Ubuntu-Benutzer benötigen zuerst das offizielle PPA:

1
2
3
sudo apt-add-repository ppa:richardgv/compton
sudo apt-get update
sudo apt-get install compton

Folgende Konfiguration habe ich produktiv im Einsatz, Fading ist eingeschaltet, jedoch nur sehr diskret. Ebenso Schatten. Die Kategorien können alternativ entfernt werden.
Die Konfiguration für den angemeldeten Benutzer erstellen:

1
nano ~/.compton.conf

Der Inhalt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
# Shadow
shadow = false;
no-dnd-shadow = true;
no-dock-shadow = true;
clear-shadow = true;
shadow-radius = 7;
shadow-offset-x = -7;
shadow-offset-y = -7;
shadow-opacity = 0.7;
# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;
shadow-exclude = [ "name = 'Notification'", "g:e:Synapse", "n:w:Geany", "n:w:VLC*", "n:w:compton", "class_g = 'Conky'", "n:w:*Iceweasel*", "n:w:*Chromium*", "class_g ?= 'Cairo-dock'", "class_g ?= 'Notify-osd'" ];
# shadow-exclude = "n:e:Notification";
shadow-ignore-shaped = false;
 
# Opacity
menu-opacity = 1;
inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = false;
alpha-step = 0.06;
# inactive-dim = 0.2;
# inactive-dim-fixed = true;
# blur-background = true;
# blur-background-frame = true;
blur-background-fixed = false;
blur-background-exclude = [ "window_type = 'dock'", "window_type = 'desktop'" ];
 
# Fading
fading = true;
fade-delta = 2;
fade-in-step = 0.03;
fade-out-step = 0.03;
# no-fading-openclose = true;
fade-exclude = [ ];
 
# Other
backend = "glx";
mark-wmwin-focused = true;
mark-ovredir-focused = true;
use-ewmh-active-win = false;
detect-rounded-corners = true;
detect-client-opacity = true;
refresh-rate = 0;
vsync = "opengl-swc";
dbe = false;
paint-on-overlay = true;
sw-opti = false;
unredir-if-possible = true;
focus-exclude = [ ];
detect-transient = true;
detect-client-leader = true;
invert-color-include = [ ];
 
# GLX backend
glx-no-stencil = true;
glx-copy-from-front = false;
glx-use-copysubbuffermesa = false;
glx-no-rebind-pixmap = true;
glx-swap-method = "exchange";

Reichlich Erklärung zu den Punkten finden sich hier.

Um Compton automatisch mit der Anmeldung zu starten, lege ich einen Starter an:

1
nano ~/.config/autostart/compton.desktop

Der Inhalt:

1
2
3
4
5
6
7
8
[Desktop Entry]
Type=Application
Exec=compton -b
Hidden=false
Name[de_DE]=Compton
Name=Compton
Comment[de_DE]=
Comment=

Ohne Neuanmeldung kann Compton im Terminal mit „compton -b“ gestartet werden.

Wer sich bei der Suche nach einem Computer im Online-Shop von Dell umschaut, der stößt unter Umständen auf eine sonderbare Dienstleistung: Dell bietet für einen Preis von rund 20 Euro an, Firefox zu installieren. In erster Linie verletzt Dell damit allerdings die Markenrechte von Mozilla.

19,50 Euro, das ist der Preis, den Dell in seinem Online-Shop für die Installation von Firefox verlangt. Eine entsprechende Option wird zumindest beim Dell Optiplex 7010 gefunden. Doch ist dies überhaupt legitim? Das Portal thenextweb.com hat bei Mozilla nachgefragt, ob es eine Vereinbarung zwischen Dell und Mozilla geben würde, welcher Dell dazu berechtigt, was von Mozilla dem Artikel nach klar verneint worden ist.

Dell verteidigt die angebotene Option, man würde für die Dienstleistung zur Kasse bitten, nicht für das Produkt, womit das überhaupt kein Problem darstelle. Mozillas Trademark Policy ist diesbezüglich allerdings eindeutig: Auch die Dienstleistung darf nicht bezahlt werden, wenn eine Mozilla-Marke, in dem Fall der Produktname Firefox, verwendet wird. Wenn Dell hierfür also kassieren möchte, dann muss Dell dem Produkt einen Namen geben, welcher nicht mit Mozilla oder einer der Mozilla-Marken in Verbindung steht:

If you are using the Mozilla Mark(s) for the unaltered binaries you are distributing, you may not charge for that product. By not charging, we mean the Mozilla product must be without cost and its distribution (whether by download or other media) may not be subject to a fee, or tied to subscribing to or purchasing a service, or the collection of personal information. If you want to sell the product, you may do so, but you must call that product by another name—one unrelated to Mozilla or any of the Mozilla Marks (see the sections on “Modifications” and “Related Software” below). Remember that we do not want the public to be confused.

5. März 2014

Mozilla Research hat heute mozjpeg vorgestellt. Dabei handelt es sich um einen Encoder für JPEG-Grafiken, welcher die Dateigröße in der ersten Version bereits um bis zu zehn Prozent reduzieren und damit die Ladezeit von Webseiten verringern soll.

Das Team von Mozilla Research hat mit mozjpeg ein neues Projekt vorgestellt. Das Ziel ist ein JPEG-Encoder, welcher unter Beibehaltung größtmöglicher Kompatibilität zu bestehenden JPEG-Decodern eine verbesserte Kompression und damit kleinere Dateigrößen bieten soll.

Die Motivation hinter mozjpeg sei die Tatsache, dass JPEG bereits seit 1992 genutzt wird und das meist genutzte Bildformat mit verlustbehafteter Kompression im Web ist, nahezu jeder Photograph stelle seine Bilder im Web als JPEG bereit. Es sei zudem das einzige verlustbehaftete Bildformat, welches eine beinahe universelle Kompatibilität besitze, nicht nur mit Webbrowsern, sondern mit allen Programmen, welche Bilder darstellen können.

Die Anzahl an Bildern auf Webseiten sei in den vergangenen Jahren gewachsen und HTML, CSS sowie JavaScript seien im Vergleich von der Dateigröße her relativ klein. Daher seien JPEG-Grafiken ein naheliegendes Ziel zur Optimierung.

In Bezug auf die Kompressionseffizienz seien vorhandene JPEG-Encoder allerdings stagniert, so dass ein Ersetzen von JPEG durch ein anderes Bildformat schon häufig ein Diskussionsthema gewesen sei. Dies hätte allerdings den ganz großen Nachteil, dass es viele Jahre geprägt von schlechter Kompatibilität brauchen würde, bis ein mögliches Nachfolgeformat flächendeckend unterstützt würde. Mozilla bezweifle nicht, dass Verbesserungen der Algorithmen irgendwann den Aufwand wert sein werden, aber selbst wenn irgendwann die Zeit käme, dass ein Nachfolgeformat eingesetzt wird, dann würde JPEG noch immer eine ganze Zeit lang weit verbreitet bleiben.

Im Blog von Mozilla Research schreibt man, dass man sich gefragt habe, ob JPEG-Encoder nach über 20 Jahren wirklich ihr volles Kompressionspotential erreicht hätten und nach einigen Gesprächen mit Software-Ingenieuren sei die Antwort darauf ‘Nein’ gewesen, auch nicht unter Berücksichtigung der Kompatibilitätsanforderungen. Dies war der Anlass für das Projekt mozjpeg.

Mozilla hat mit der Ankündigung mozjpeg in Version 1.0 veröffentlicht. Dabei handelt es sich um einen Fork von libjpeg-turbo mit hinzugefügter jpgcrush-Funktionalität. Damit kann die Dateigröße von JPEG-Grafiken ohne Qualitätsverlust typischerweise um zwei bis sechs Prozent für nach JPEG enkodierte PNG-Grafiken verringert werden, für ein Set von 1.500 JPEG-Grafiken von Wikimedia hätte man die Dateigröße um durchschnittlich sogar zehn Prozent reduzieren können. Nach Mozillas Kenntnisstand besitzt kein bislang verfügbarer Encoder diese Funktionalität direkt eingebaut, darum hätte man sich dafür als erstes Feature von mozjpeg entschieden. Das nächste Ziel sei eine Verbesserung des Encodings durch eine sogenannte Trellis-Quantisierung.

Google möchte ebenfalls die Dateigröße von Bildern reduzieren, setzt hierbei aber vor allem auf sein eigenes Format WebP, welches einige namhafte Anhänger in der Webbranche hat. Mozilla ist von WebP allerdings wenig überzeugt.

Ich habe dem Blog eine neue Seite hinzugefügt die sich BlogonautEdit nennt. BlogonautEdit ist mein selbst entwickelter Codeeditor der nun über diese Seite Downloadbar ist. Dabei wird natürlich immer die Aktuellste Version zum Download zur Verfügung stehen. 🙂 Die Entwicklungsnews werden natürlich hier auf meinem Blog bekanntgegeben und darunter könnt ihr gerne auch neue Features wünschen oder Kritik mir mitteilen. 🙂 Natürlich wird aber nicht nur über BlogonautEdit geschrieben sondern ich schreibe weiter über alle Dinge die mich so interessieren und stelle auch weiter neue Schaltungen vor. 🙂

Ich habe mir überlegt dass ich an meinem Texteditor weiter programmieren werde und hier über die neuen Versionen zu berichten. Der Texteditor ist eigentlich ein Codeeditor welchen ich 2013 erschaffen habe. Der Code ist in Python geschrieben und funktioniert immer noch sehr gut als Basis. Wer Ideen für neue Features hat kann sie gerne über die Kommentarfunktion oder per Email mir mitteilen und ich werde sie wenn Möglich einbauen. 🙂 Wer sich jetzt schon mal den Codeeditor anschauen möchte kann dies gerne über die Repo machen. 🙂

MATE wurde gestern, dem 04. März, in Version 1.8 veröffentlicht.

Zwei neue Features sind sehr erfreulich. Damit diese in der Flut von „MATE 1.8 released“-Meldungen nicht untergehen, verfasse ich einen kurzen Artikel.

Metacity Support, Mate 1.8

Metacity Support, Mate 1.8

Window Snapping, Mate 1.8

Window Snapping, Mate 1.8

Installationsanleitungen für viele Distributionen finden sich hier.

Es bleibt abzuwarten, wann die Pakete in das Repository eingepflegt werden. Zum Zeitpunkt des Artikels, haben die Pakete das Repository für Debian und Ubuntu noch nicht erreicht.

Changelog

Caja (file manager)

  • Added option to use IEC units instead of SI units
  • Added “Open parent location” option in context menu in search view

Marco (window manager)

  • Added side-by-side tiling (windows snapping)

Panel

  • Added support to run dialog and main menu opening with metacity keybindings
  • Show a progress bar in logout dialog

Control center

  • Added support for Metacity as window manager

MATE Desktop library

  • Added MATE User Guide
  • Added mpaste tool for paste.mate-desktop.org

Eye Of MATE (image viewer)

  • Added shuffle mode in slideshow

Engrampa (file archiver)

  • Show always the “extract to” action in caja extension

Screensaver

  • Show date and time in lock dialog

Applets

  • Added undo functionality to sticky note applet
  • New “command” applet to show the output of a command
  • Rewritten “timer” applet in c
  • Mouse middle click on volume applet toggles mute state

Dropped packages

  • Replaced mate-doc-utils with yelp-tools
  • Replaced libmatekeyring/mate-keyring with libsecret/gnome-keyring
  • Replaced libmatewnck with libwnck
  • Replaced mucharmap with gucharmap
  • Replaced mate-bluetooth with blueman
  • Merged all caja extensions in a single package

Other improvements

  • Fixed a lot of code deprecations
  • Fixed a lot of bugs
  • Added and improved a lot of translations

Dash ist ein optisch ansprechendes Web-Dashboard für live System-Monitoring eines Computers im Browser. Es unterscheidet sich vor allem durch seine moderne Optik und Benutzerfreundlichkeit.
Zur Zeit befindet es sich noch im Beta-Status, verrichtet seine Dienste auf unterstützten Systemen aber bereits sehr gut. Eine Aufzeichnung der Aktivität findet nicht statt.

Voraussetzung für die Installation

Zu den unterstützten Systemen zählen bislang:

  • Arch
  • Debian 6, 7
  • Ubuntu 11.04+
  • Linux Mint 16+

Offiziell unterstützte Web-Server sind Nginx und Apache.

Benutzer von Debian-Derivaten installieren vorab das Paket „php5-json“:

1
sudo apt-get install php5-json

Womöglich ist „php5-json“ durch das Meta-Paket „php5-common“ bereits installiert. Neuere Ubuntu-Versionen trennten das Modul jedoch aus diesem Paket.

Bei der Einrichtung gehe ich vom Web-Root „/var/www/linux-dash-master“ aus. „www-data“ ist ausführender Besitzer des Web-Servers.

Installation

1
2
3
cd /var/www
wget https://github.com/afaqurk/linux-dash/archive/master.zip && unzip master.zip && rm master.zip
chown -R www-data: linux-dash-master

Achtung: Dash kann „dnsmasq“ auf aktive Leases überwachen. Hierzu liest es die Datei „/var/lib/misc/dnsmasq.leases“. Falls „open_basedir“ in PHP gesetzt ist, bitte „/var/lib/misc“ als Pfad ergänzen.

Im Anschluss kann Dash über den Web-Browser aufgerufen werden.

Falls der Zugriff beschränkt werden soll, kann mit Hypertext Access gearbeitet werden. Unter dem Punkt „CGP absichern“, habe ich hier bereits ausführlich den Vorgang beschrieben. Abgesehen vom Namen, lässt sich die Einrichtung so übernehmen.
Sollte Aufzeichnung der Systemaktivität eine Anforderung sein, empfehle ich den gesamten Artikel.

Update

Da Dash sich in aktiver Entwicklung befindet, kann ein Blick in das Git-Repository von Zeit zu Zeit nicht schaden.
Der Update-Vorgang entspricht eins zu eins der Installation. Vorausgesetzt ihr habt euch an den Artikel gehalten.

Anhang

Dash: Live System-Monitoring im Web-Browser

Dash