Leider unterstützt die aktuelle Version von Skype für Linux das versenden von SMS nicht. Wer hier mithalten möchte, der muss in die Trickkiste greifen: die Skype API.

Philipp Kolmann hat eine kleine GUI in Python geschrieben, mit Hilfe derer man über die Skype API SMS verschicken kann:

Die originale Installationsanleitung findet sich hier:

http://forum.skype.com/index.php?showtopic=96258

Leider tritt nach einer Installation entsprechend dieser Anleitung der Fehler “Segmentation fault” auf und das Programm stürzt ab. Unter Ubuntu 8.10 hat diese Anleitung funktioniert:

http://forum.skype.com/index.php?showtopic=96258&st=60#entry1613181

Es wird eine angepasste Version von xodeus.dk installiert.

Darüber hinaus muss python mit den entsprechenden Bindings wie python-gtk installiert sein.

Jedes Mal, wenn ich mir ein Gentoo aus dem Testing Zweig kompiliere, habe ich das Problem, dass weder Maus noch Tastatur unter X per default funktionieren.

An sich ist das natürlich nicht so toll, da KDE leider (noch) nicht sprachgesteuert werden kann.

Gelöst werden kann das Problem mit folgendem Eintrag in
der /etc/X11/xorg.conf:
Section “ServerFlags”
Option “AllowEmptyInput” “false”
EndSection

Alternativ kann man xorg-x11 mit USE=”-hal”, oder ohne eine Angabe der INPUT_DEVICES in der xorg.conf kompilieren. Sollte anschließend auch funktionieren.

Mein neues Thinkpad wurde mit einem “Vista ready”-Aufkleber geliefert. Natürlich durfte das nicht so bleiben und so musste mindestens ein neuer Sticker her.

Nach einer kurzen Suche bei Google, traf ich dann auf linux-sticker.de. Vorraussetzung war, dass man bei dem Shop meiner Wahl mit PayPal bezahlen konnte.

Natürlich habe ich nicht nur einen Sticker bestellt, sondern, – wenn man schon mal dabei ist – gleich ein paar mehr unterschiedlichen Typs.

Die Lieferung erfolgte schnell und rechtzeitig. Die Versandkosten sind mit < 2 Euro angemessen.

Die bestellten Tux-Kontur Ansteckpins machen einen sehr guten Eindruck. Der Druck ist sauber ausgeführt und Tux ist auch ein wenig bauchig.

80 Cent für einen Tasten-Sticker finde ich für so ein kleinen Schnipsel nicht gerade günstig. Der Tastensticker war nicht präzise ausgeschnitten und so ergab sich auf dem schwarzen Thinkpad ein weißer Rand, was nicht gerade schön ist.

Der Notebook-Sticker für 90 Cent klebt bisher gut. Ich frage mich allerdings, wie lange der Aufkleber halten wird. Es scheint sich bei diesem Aufkleber lediglich um nicht beschichtetes Papier zu handeln. Der Druck wirkt ein wenig krisselig. Die letzen kostenlosen und beschichteten Ubuntu-Sticker haben sich nach ein paar Monaten im Wohlgefallen aufgelöst. Es bleibt abzuwarten, wie sich dieser Sticker halten wird.

Zusätzlich zu den Stickern für das Notebook habe ich auch ein Set “Maxi-Sticker” geordert. Die großen Tuxe auf einem DIN-A4 Blatt sind sauber ausgeschnitten und die Druckqualität wirkt optisch gut. Die Farbe lässt sich jedoch, wie bereits hier:

http://clockwork.supersized.org/archives/61-Erfahrung-mit-Linux-Sticker.de.html

bemängelt leicht mit dem Finger abkratzen. An mechanisch belasteten exponierten Stellen dürften diese Aufkleber nicht lange freude bereiten.

Fazit:

Mit den Tux-Maxi-Stickern werde ich wohl nicht viel anfange können. Für das Auto sind diee nicht zu gebrauchen. Hier sind wohl ca. 10 Euro verloren. Die Lebensdauer der Notebook-Sticker wird weiter unter harten Bedingungen getestet.

Die Idee, endlich mal einen vernünftigen Hostnamen in /etc/hostname auf dem Server von vibora.de zu setzen war ja an sich gar nicht mal so schlecht.

Bis ich dann gerade mal auf die Idee kam, ejabberd neu zu starten. Mit dem Ergebnis, dass sich nun ejabberd zwar starten lässt, aber nicht auf den entsprechenden Ports horcht.

Okay. Nachdem ich mich durch einige nichtssagenden Log-Dateien in dieser etwas merkwürdigen Programmiersprache erlang gegoogelt hatte, kam ich dann dahinter, dass es sich scheinbar doch um ein Problem mit dem Hostnamen handelt:

http://wiki.laptop.org/go/Ejabberd_Configuration#Troubleshooting

“You may get this error if you change your hostname

Try the following to fix ejabberd, basically reinstall it”

DAS nenne ich natürlich mal eine komfotable Lösung. Das erinnert mich doch schwer an das “Troubleshooting” von Windows XP.

Noch dazu kommt das reichlich merkwürdige starten und stoppen von ejabberd:

http://www.gentoo-wiki.info/Ejabberd#Starting.2FStopping_ejabberd

“Starting ejabberd will work most times, and still give you [ !! ] and be working. Also because of this, issuing a stop will not work either, but instead you will have to kill the process manually.”

Fazit: nächstes mal einen anderen Jabber Server benutzen.

Da der Mebus (und auch einige andere) gerne mal per scp “Dinge” (wie z.B. Textdateien, oder ähnliches) auf meinen Desktop-Rechner rüberschieben und ich ungern meine ganzen 500GB meiner /home für sowas zur Verfügung stellen möchte, habe ich kurzer Hand einige Disk-Quotas eingerichtet.

Ich zeige hier anhand eines Beispieles, wie so etwas eingerichtet wird:

Zunächst installiert man sich die beiden Pakete quota und quotatool.

Anschließend wird ein Image angelegt:

dd if=/dev/zero of=/home/disk-quota.ext3 count=40960

(count=40960 entspricht etwa 20MB, da dd eine block size von 512byte benutzt. Also 40960*512=20971520.)

Jetzt muss natürlich ein Dateisystem angelegt werden:

mkfs -t ext3 -q /home/disk-qouta.ext3 -F

Nun schreiben wir einfach folgendes in die /etc/fstab:

/home/disk-quota.ext3    /home/quota      ext3    rw,loop,usrquota,grpquota       0       0

Das sorgt für ein automatisches mounten nach dem reboot und erleichtert zudem das mounten/umounten beim testen:

mount /home/quota

Nun muss quota überprüft und aktiviert werden:

quotacheck -ma
quotaon -a

Ist dies erledigt, können wir mithilfe von quotatool das Quota für den Benutzer setzen ebenso wie ein “hardlimit”:

quotatool -u quota -b -l 20M /

Hierbei gilt, dass -u quota das Quota für den Benutzer quota setzt und -b -l 20M ein Hardlimit von 20Megabyte.

Eine Einsicht in alle Quotas bekommt man mithilfe von

repquota /home/quota/

angezeigt.

PGP ist ja an sich eine feine Sache. Auch, dass man das mittlerweile so einfach in Mail-Clients integrieren kann. Dachte ich zumindest.
KMail mochte das Signieren von E-Mails anscheinend gar nicht. Wenn ich eine signierte E-Mail abschicken wollte, kam die Fehlermeldung “Signieren fehlgeschlagen: Falsche Passphrase”. Nach einer Passphrase wurde ich aber gar nicht erst gefragt.
Nunja, es ist schön, dass es Dokumentationen auf kde.org gibt:
http://kontact.kde.org/kmail/kmail-pgpmime-howto.php

Folgende Schritte waren bei mir also nun Notwendig, damit KMail auch meine Mails signieren wollte:
Zunächst musste ich sicherstellen, dass die Pakete kgpg gpgsm kleopatra gnupg-agent und pinentry-qt installiert sind.

Anschließend musste ich die Datei ~/gnupg/gpg-agent.conf anlegen und folgendes in die Datei eintragen:

pinentry-program /usr/bin/pinentry-qt
no-grab
default-cache-ttl 1800

Unter KGpg war ein Standardschlüssel entsprechend festzulegen und unter Einstellungen > KGpg einrichten  … > GnuPG-Einstellungen einen Haken bei “GnuPG-Agent benutzen” zu setzen.

Zum Schluss musste ich noch

eval “$(gpg-agent –daemon)”

ausführen und diesen Befehl in meine neu angelegte Datei ~/.kde/env/gpgagent.sh schreiben.

Ob GnuPG nun mit dem Agenten zusammenarbeitet, kann man mithilfe von

echo “test” | gpg -ase -r 0xDEFDBAEB | gpg

testen (hier bitte natürlich die eigene Schlüssel-ID verwenden!). Der Befehl muss in derselben Shell eingegeben werden, wie zuvor

eval “$(gpg-agent –daemon)”.

Jetzt nur noch ab/- und anmelden, damit das “Skript” auch initialisiert wird und KMail kann auf einmal fröhlich signieren/verschlüsseln.

KompoZer ist ein WYSIWYG-Editor, der eigentlich ein Bug Fix zu  NVU sein sollte. Doch das Projekt scheint in letzter Zeit LEIDER eher vernachlässigt zu werden, wie ich heute feststellen musste, als sich das Programm nach einem “Segmentation fault” ohne Vorwarnung verabschiedet hat. Ich benutze die Software gelegentlich, wenn das Ersellen von HTML Code per Hand zu lange dauern würde.

Der letzte Release der Software war am 30. August 2007.  Insgesamt sind über 300 kritische Bugs offen, um die sich niemand kümmert.  Es gibt ca. 230 Feature Requests und nur 6 Patches.

Ist das die Qualität von Linux Software ?

Mal schauen, an welchem Projekt ich mich demnächst beteilige. Dies ist jedenfalls schon mal ein Kandidat.