ubuntuusers.de

6. März 2009


Ich habe vor kurzem einen Planeten aufgesetzt und mich deswegen erstmal versucht schlau zu machen, was es diesbezüglich an Software gibt. Die Suche war ziemlich ernüchternd denn erstens gibt es bis jetzt keine gute Sammlung der vorhandenen Programme und zweitens gibt es auch nicht wirklich viele davon.

Deswegen habe ich hier nun eine kleine Übersicht der vorhandenen Alternativen inklusive ihrer Sprachen und ihrem Entwicklungsstatus erstellt.

Als erstes muss natürlich die Mutter der Planeten genannt werden. Also die erste Software dieser Art die von sich hören gemacht hatte: Planet. Planet ist rein in Python geschrieben und wurde ursprünglich für den Debian- und den Gnome-Planeten entworfen worden. Mittlerweile benutzten aber eine ganze Reihe von Projekten Planet. Der Code kann bequem aus einem Bazaar-Repository bezogen werden, liegt aber auch als tar vor. Nachteil von Planet ist jedoch eindeutig, dass es anscheinend nichtmehr weiterentwickelt wird. Die letzte Änderung im Entwicklungs-Repository stammt aus dem April 2007. Ich habe bei meinen Tests auch einige Bugs entdeckt die vor allem mit dem Encoding zusammenhängen. Planet hat anscheinend mit bestimmten Feeds Problemen und kann sie deswegen nicht darstellen. Bei meiner Recherche habe ich entdeckt, dass viele Projekte Planet für ihre Zwecke modifizieren mussten damit er mit jedem Feed zurechtkam, leider ging von diesen Veränderungen nichts Upstream. Planet ist deswegen schön um ein bischen dran rum zu hacken, für den produktiv Einsatz ohne weiteres jedoch leider nicht geeignet.

Als nächstes möchte ich planet.rb nennen. Dies ist ein in Ruby geschriebener Planet, welcher leider auch seit März 2007 nichtmehr weiterentwickelt wird. Es benötigt Ruby und HTree aber da es auch seit fast zwei Jahren nichtmehr weiterentwickelt wird habe ich es mir nicht genauer angesehen.

Dann bin ich auf moonmoon gestoßen, welches in PHP5 geschrieben wurde. Im Gegensatz zu den meisten Planet-Programmen kommt moonmoon ohne Cron aus. Die Feeds werden on-the-fly beim Aufruf des Planeten aktualisiert. Das es ohne Cronjob auskommt ist jedoch kein Vorteil sondern eher ein Nachteil. Denn erstens dauert das Laden des Planeten deswegen länger weil ja erstmal alle Feeds aktualisiert werden müssen und zweitens erzeugt dies unnötig Traffic auf den Feeds. Mich hat das schonmal abgeschreckt und ich hab dieses Programm nicht weiter unter die Lupe genommen. Im Repository sehe ich, dass es eine cron.php gibt was zumindest darauf hin deutet, dass es eine optionale Cron Unterstützung gibt. e2b hat mich darauf hingewiesen, dass die letzte Version von moonmoon im Dezember 2008 veröffentlicht wurde.

Feedjack ist eine weitere in Python geschriebene Planet-Software welche auf dem Django-Framework basiert. Es scheint sehr viele Features zu besitzen und die letzte Änderung im Repository stammt aus dem August 2008, was jetzt noch nicht sooo lange her ist. Da mich die Installation des Django-Frameworks etwas abgeschreckt hat und ich mir dachte, dass es doch etwas leichtgewichtigeres geben muss habe ich mich weiter umgesehen.

Die letzte Software die ich gefunden habe und die für welche ich mit letzten Endes entschieden habe ist Venus. Venus ist ein Fork des ganz zu Beginn genannten Planet und ist wie dieser in Python geschrieben. Venus wird aktiv entwickelt, die letzten Änderungen im Repository stammen von Ende Februar diesen Jahres. Die Code-Basis von Planet wurde von Venus stark überarbeitet, die bekannten Bugs gefixt und viele neue Features eingebaut. Venus besitzt eine ganze Anzahl an Möglichkeiten um Templates zu generieren. Sowohl htmltmpl, als auch Django, xslt und genshi werden unterstützt, wenn man sie installiert hat. Diese sind bis auf htmltmpl jedoch optional, man muss also zum Beispiel nicht Django installiert haben um den Planeten nutzen zu können. Python alleine reicht vollkommen aus. Die Installation und Konfiguration ist wie bei Planet denkbar einfach. Die Feeds werden über Cron aktualisiert und es gibt einige Filter-Möglichkeiten. Venus kommt bereits mit 7 unterschiedlichen Themes, doch die wird man eh dem Thema des eigenen Planeten anpassen wollen.

Gerhard hat mich noch auf Plagger aufmerksam gemacht. Plagger ist in Perl geschrieben und ist im Gegensatz zu den anderen Lösungen nicht nur ein Planet sondern bietet noch jede Menge andere Einsatzzwecke. Die letzte stable Version wurde zwar vor einigen Jahren veröffentlich, doch im Development-Repository scheinen regelmässig noch Änderungen und Verbesserungen der einzelnen Plugins gemacht zu werden. Der letzte Edit ist keine zwei Wochen alt.

Wenn jemand also einen Planeten aufstellen möchte kann ich ihm nur zu Venus oder Feedjack raten. Moonmoon und Plagger scheinen jedoch auch noch brauchbare Alternativen zu sein. Alle anderen werden nichtmehr weiterentwickelt und sind zum Teil zu buggy um produktiv genutzt werden zu können. Interessant finde ich noch, dass keines dieser Programme eine richtige Datenbank wie SQLite zum Speichern der Feeds benötigt.

GPS, Openstreetmap und Linux

Inspiriert von Dirks letztem Blogeintrag und nicht zuletzt um ihm bei seiner Entscheidung zu helfen, ist dieser Artikel entstanden.

Yvonne hat es ja schon angesprochen, daß wir ein neues Hobby haben. Die ersten Versuche mit einer GPS-Bluetoothmaus waren recht ernüchternd. Die Qualität der Tracks war nicht wirklich gut genug, daß man damit was vernünftiges anfangen konnte. So haben wir uns einen Garmin etrex Legend HCx zugelegt. Das ist ein feines Gerät. Der Empfänger ist so empfindlich, daß man auch in der Mitte eines Zimmers einen GPS-Fix hat. Der Empfänger meines Tablets ist da um einiges unsensibler… Auf der MicroSD-Karte ist ausreichend Platz für Karten.

Yvonne ist mit wachsender Begeisterung mit dem etrex (trexxie wird das Gerät genannt…) unterwegs. Ich habe die Aufgabe, den trexxie mit Karten zu bestücken und dafür zu sorgen, daß die Tracks auch vom trexxie runter kommen. Natürlich sollen die Programme auch für Benutzer nutzbar und etwas bunt sein.

trexxie wird per USB angesprochen. In Hardy heißt die Schnittstelle /dev/ttyUSB0 und seit Intrepid usb: Damit der gewöhnliche Benutzer auch auf die Schnittstelle zugreifen kann, ist eine udev-Regel anzulegen:

SYSFS{idVendor}=="091e", SYSFS{idProduct}=="0003", MODE="666"

Es reicht, den trexxie einfach wieder am PC anzustecken.

Freie Karten für den trexxie auf der Datenbasis von OSM Für Europa und Deutschland kann man hier runterladen. Es reicht aus, das Archiv zu entpacken und die Datei auf der Speicherkarte im Ordner /Garmin zu speichern. Die Datei sollte auch wirklich gmapsupp.img heißen ;-) Ausführliche Informationen kann man hier nachlesen.

Um Daten vom trexxie runter zu laden und zu bearbeiten, gibt es für Linux mehrere Programme:

Mit Qlandkarte kann man Tracks und Wegpunkte auf trexxie hoch und runter laden und Ausschnitte aus Karten hochladen. Dazu sind natürlich entsprechende Karten in Qlandkarte einzubinden. Auf Basis der Openstreetmap-Karten werden hier Karten zur Verfügung gestellt. Auf dieser Seite wird auch das Einbinden der Karten beschrieben. Die Idee, Tracks mit Qlandkarte zu bearbeiten, haben wir verworfen. Qlandkarte schmeißt alle Zeitstempel raus und macht so die Tracks für OSM untauglich. Schade…

Viking funktionierte hier in der Version 0.9.8 am besten. Diese Version wird auch in Ubuntu 09.04 sein. Drum hab ich die einfach auf allen Rechner hier selber kompiliert.

Mit Viking kann man die Tracks auch recht einfach direkt vom trexxie runter laden (File → Aqire → From GPS). Das Bearbeiten der Tracks ist sehr einfach. Man kann diverse Karten einbinden, die bei der Orientierung helfen. Ist man mit den Tracks fertig, kann man diese anschließend direkt auf dem OSM-Server hochladen. Will man die Tracks in JOSM weiterbearbeiten, kann man diese wieder vom OSM-Server runterladen.

GPS, Openstreetmap und Linux

Inspiriert von Dirks letztem Blogeintrag und nicht zuletzt um ihm bei seiner Entscheidung zu helfen, ist dieser Artikel entstanden.

Yvonne hat es ja schon angesprochen, daß wir ein neues Hobby haben. Die ersten Versuche mit einer GPS-Bluetoothmaus waren recht ernüchternd. Die Qualität der Tracks war nicht wirklich gut genug, daß man damit was vernünftiges anfangen konnte. So haben wir uns einen Garmin etrex Legend HCx zugelegt. Das ist ein feines Gerät. Der Empfänger ist so empfindlich, daß man auch in der Mitte eines Zimmers einen GPS-Fix hat. Der Empfänger meines Tablets ist da um einiges unsensibler… Auf der MicroSD-Karte ist ausreichend Platz für Karten.

Yvonne ist mit wachsender Begeisterung mit dem etrex (trexxie wird das Gerät genannt…) unterwegs. Ich habe die Aufgabe, den trexxie mit Karten zu bestücken und dafür zu sorgen, daß die Tracks auch vom trexxie runter kommen. Natürlich sollen die Programme auch für Benutzer nutzbar und etwas bunt sein.

trexxie wird per USB angesprochen. In Hardy heißt die Schnittstelle /dev/ttyUSB0 und seit Intrepid usb: Damit der gewöhnliche Benutzer auch auf die Schnittstelle zugreifen kann, ist eine udev-Regel anzulegen:

SYSFS{idVendor}=="091e", SYSFS{idProduct}=="0003", MODE="666"

Es reicht, den trexxie einfach wieder am PC anzustecken.

Freie Karten für den trexxie auf der Datenbasis von OSM Für Europa und Deutschland kann man hier runterladen. Es reicht aus, das Archiv zu entpacken und die Datei auf der Speicherkarte im Ordner /Garmin zu speichern. Die Datei sollte auch wirklich gmapsupp.img heißen ;-) Ausführliche Informationen kann man hier nachlesen.

Um Daten vom trexxie runter zu laden und zu bearbeiten, gibt es für Linux mehrere Programme:

Mit Qlandkarte kann man Tracks und Wegpunkte auf trexxie hoch und runter laden und Ausschnitte aus Karten hochladen. Dazu sind natürlich entsprechende Karten in Qlandkarte einzubinden. Auf Basis der Openstreetmap-Karten werden hier Karten zur Verfügung gestellt. Auf dieser Seite wird auch das Einbinden der Karten beschrieben. Die Idee, Tracks mit Qlandkarte zu bearbeiten, haben wir verworfen. Qlandkarte schmeißt alle Zeitstempel raus und macht so die Tracks für OSM untauglich. Schade…

Viking funktionierte hier in der Version 0.9.8 am besten. Diese Version wird auch in Ubuntu 09.04 sein. Drum hab ich die einfach auf allen Rechner hier selber kompiliert.

Mit Viking kann man die Tracks auch recht einfach direkt vom trexxie runter laden (File → Aqire → From GPS). Das Bearbeiten der Tracks ist sehr einfach. Man kann diverse Karten einbinden, die bei der Orientierung helfen. Ist man mit den Tracks fertig, kann man diese anschließend direkt auf dem OSM-Server hochladen. Will man die Tracks in JOSM weiterbearbeiten, kann man diese wieder vom OSM-Server runterladen.

Letzten Monat habe ich mit fast 23GB Traffic meinen “Inklusivtraffic” von 25GB überschritten. Zeit das Blog etwas aufzuräumen und Bilder zu verkleinern. Da sich hier ein paar hundert Bilder und deren Thumbnails angesammelt haben, soll das Verfahren möglichst automatisch ablaufen und das Ergebnis in möglichst kleine Bilder resultieren, die dennoch gut aussehen.

Mit Imagemagick, Gimp, optipng und pngcrush stehen ein paar Kandidaten zur Auswahl, die hier Besserung versprechen. Ersteinmal gilt es jedoch herauszufinden welches Programm am besten komprimiert. Als Vorlage benutze ich diesen Screenshot.

Vorlage: 68966 Bytes

Vorlage: 68966 Bytes

Ich denke das Bild ist ein gutes Beispiel für Screenshots von Anwendungsprogrammen. Im Original hat das Bild eine Größe von 68966 Bytes. Diesen Wert gilt es also deutlich zu verbessern.

Gimp

Als erstes muss sich Gimp beweisen. Am einfachsten reduziert man die Größe eines PNG-Bildes indem man die Farbpalette reduziert. Gimp kann eine “optimale Palette” erzeugen und so eine auf das Bild angepasste Palette produzieren. Die Funktion findet sich unter “Bild -> Modus -> Indiziert -> Optimale Palette erzeugen” und schrumpft das Bild auf 27026 Bytes ein, d.h. das mit GIMP erzeugte Bild hat nur noch rund 39% der ursprünglichen Dateigröße ohne dass das Bild groß dabei leidet.

Optimale Palette mit The Gimp: 27026 Bytes

Optimale Palette mit The Gimp: 27026 Bytes

Imagemagick

Als nächstes kommt convert aus dem Paket Imagemagick auf die Testbank. Erst einmal versuche ich wieder die Farbpalette zu reduzieren.

$ convert -colors 16 orig.png convert_colors16.png
$ convert -colors 256 orig.png convert_colors256.png

Das Ergebnis ist unter aller Katastrophe, die Bilder sind größer als vorher. Das auf 16 Farben reduzierte Bild hat 103425 Bytes und das mit 256 Farben 184634 Bytes. Convert komprimiert wohl die Bilder nicht per Default, dies muss man mit der Option –quality erst aktivieren. 1000 steht dabei für die höchstmögliche Kompression.

$ convert -colors 16 -quality 1000 orig.png convert_colors16_quality1000.png
$ convert -colors 256 -quality 1000 orig.png convert_colors256_quality1000.png

Auch hier ist das Ergebnis wieder schlecht. Das 16 Farben Bild läuft danach mit 56196 Bytes in Ziel, das Bild mit 256 Farben mit 85889 Bytes. Ergebnis: convert kann keine optimale Palette erzeugen. Dadurch sieht das Bild schrecklich aus und ist dennoch größer als es sein müsste…

optipng

optipng ist ein Programm, dass speziell zum Optimieren und Verkleinern von .png Bildern geschrieben wurde. Es lässt sich in Ubuntu und Debian aus den Paketquellen installieren. Ich komprimiere einmal das “Original” und einmal ein Bild, das ich vorher mit convert auf eine Palette mit 256 Farben komprimiert habe.

$ optipng -k orig.png
$ optipng -k convert_colors256_quality1000.png

Auch hier ist das Ergebnis wieder mager. optipng komprimiert die Vorlage auf 63539 Bytes, also auf rund 92% des ursprünglichen Bildes. Das Bild mit 256 Farben wird von 184634 Bytes auf 85620 Bytes komprimiert. Gut, wenn man sich die 50% Ersparnis ansieht. Doch schlecht, wenn man bedenkt, dass GIMP ein 27kb großes Bild erzeugen kann…

pngcrush

Alternativ zu optipng gibt es pngcrush. Das Programm findet man ebenso in den Quellen. Auch hier komprimiere ich einmal das Original und einmal das mit Convert auf 256 Farben reduzierte Bild.

$ pngcrush -c 3 -brute orig.png pngcrush.png
$ pngcrush -c 3 -brute convert_colors256_quality1000.png pngcrush_convert_colors256_quality1000.png

Das Ergebnis deckt sich praktisch völlig mit optipng. Einmal bekomme ich 63793 Bytes und einmal 85889 Bytes. Wieder alles deutlich größer als Gimp…

Script-Fu

The Gimp ist also wohl nicht zu schlagen. Kein anderes Programm schafft es auch nur annähernd in die Reichweite der Größenreduktion von Gimp zu kommen. Einen Haken hat die Sache allerdings… Ein paar Hundert Bilder in Gimp zu laden und sich durch die Menüs zu hangeln? Das wäre enorm viel Klickarbeit.

Aber wozu hat Gimp einen Modus mit dem man eigene Skripte ausführen kann? Mit Script-Fu kann man Gimp komplett über Skripte bedienen. Im uu.de Forum hatte mir ein guter Geist schon einmal ein Skript geschrieben, das für alle .png Dateien in einem Ordner eine optimale Palette erzeugt. Es hatte noch eine Fallunterscheidung gefehlt, die die Indezierung nur auf Bilder loslässt, die noch nicht indeziert wurde. Doch jetzt klappt das :) Wer so etwas sucht, der speichert das Skript


(define (batch-generate-optimum-palette pattern
	dither-type
	palette-type
	num-cols
	alpha-dither
	remove-unused
	palette
	)

	(let* ((filelist (cadr (file-glob pattern 1))))
		(while (not (null? filelist))
			(let* (
				(filename (car filelist))
				(image (car (gimp-file-load RUN-NONINTERACTIVE filename filename)))
				(drawable (car (gimp-image-get-active-layer image)))
			)
			(if (= FALSE (car (gimp-drawable-is-indexed drawable)))
				(gimp-image-convert-indexed image dither-type palette-type num-cols alpha-dither remove-unused palette)
				)
				(set! drawable (car (gimp-image-get-active-layer image)))
				(gimp-file-save RUN-NONINTERACTIVE image drawable filename filename)
				(gimp-image-delete image)

			)
			(set! filelist (cdr filelist))
		)
	)
)

in ~/.gimp-2.6/scripts/batch-generate-optimum-palette ab. Danach kann man es über

$ gimp -i -b '(batch-generate-optimum-palette "*.png" 0 0 256 TRUE TRUE "")' -b '(gimp-quit 0)'

ausführen. Alle .png Bilder, die sich im aktuellen Ordner der Shell befinden, werden dann automatisch optimiert. Legt man dazu noch ein Alias für die Shell an, so hat man ein perfektes Werkzeug um Bilder in großen Massen für das Web aufzubereiten. So habe ich hoffentlich noch etwas Zeit, bis ich den nächst höheren Hostingtarif wählen muss…

In diesem Artikel beschreibe ich, wie man eine aktuelle Version des XviD-Codecs kompiliert und ein Debian-Paket daraus baut.

Zunächst lädt man sich den Quelltext der aktuellen Version herunter. Ich habe dazu den release tarball Version 1.2.1 benutzt. Man kann natürlich auch eine CVS-Version, bzw. den daily snapshot benutzen.
Die .tar.gz-Datei kopiert man am Besten nach /var/tmp/ – das temporäre Arbeitsverzeichnis unter Linux. Anschließend wird die Datei entpackt. Falls man lieber die CVS-Version benutzen möchte, wechselt man nach /var/tmp/ und lädt mit diesem Befehl den aktuellen snapshot herunter:
cvs -d:pserver:anonymous@cvs.xvid.org:/xvid co xvidcore

Nun wechselt man in das Verzeichnis /var/tmp/xvidcore/build/generic. Der Build-Vorgang ist Standard:

  • configure
  • make
  • make install

Lediglich bei der CVS-Version muss zu Beginn (also vor ./configure) ./bootstrap.sh ausgeführt werden.

Da am Ende ein .deb-Paket erstellt werden soll, sind noch ein paar Anpassungen notwendig.
Zunächst habe ich festgestellt, dass die Datei “config.sub” fehlt. Als Lösung habe ich diese Datei vom Paket automake benutzt, d.h. erstmal kopiert. Mit locate config.sub kann man feststellen, wo solche Dateien im System vorhanden sind. Falls jemand hierfür eine bessere Lösung gefunden hat, hinterlasse bitte einen Kommentar. Nunja, dies gilt eigentlich grundsätzlich für meinen Blog. :-)

Der erste Schritt: configure. Um ein Paket zu erstellen, müssen die Binärdateien installiert werden. Dies soll allerdings nicht im System geschehen, sondern im Arbeitsverzeichnis. configure bietet hier die Möglichkeit das Ziel mit dem Parameter “prefix” anzugeben. Weiterhin muss die Architektur angegeben werden (zumindest wurde sie bei mir nicht korrekt erkannt). Die bisherigen Schritte:

florian@bugie:/var/tmp$ cd xvidcore/build/generic/
florian@bugie:/var/tmp/xvidcore/build/generic$ cp /usr/share/automake-1.10/config.sub ./
florian@bugie:/var/tmp/xvidcore/build/generic$ ./configure --build=i386-pc-linux-gnu --prefix=/var/tmp/xvidcore/build/generic/libxvidcore4_1.2.1_i386/usr

Sobald der letzte Befehl mit Enter bestätigt wurde, wird der configure-Vorgang gestartet. Er sollte ohne error durchlaufen. Falls ihr einen error bekommt, hoffe ich mal, dass ihr an Hand der Fehlermeldung eine Lösung findet (oder einfach hier nachfragen). Dies gilt auch für die übrigen Schritte.

Die nächsten beiden Schritte sind einfach, können allerdings ein bisschen dauern:
make
make install

Jetzt sollten diese Dateien vorhanden sein:

/var/tmp/xvidcore/build/generic/libxvidcore4_1.2.1_i386/usr/lib
/var/tmp/xvidcore/build/generic/libxvidcore4_1.2.1_i386/usr/lib/libxvidcore.so.4.2
/var/tmp/xvidcore/build/generic/libxvidcore4_1.2.1_i386/usr/lib/libxvidcore.a
/var/tmp/xvidcore/build/generic/libxvidcore4_1.2.1_i386/usr/include
/var/tmp/xvidcore/build/generic/libxvidcore4_1.2.1_i386/usr/include/xvid.h

Und jetzt kann eigentlich nichts mehr schief gehen – XviD ist kompiliert und “installiert”.

Es folgt das Erstellen des .deb-Pakets. Grundlegend hierfür ist die control-Datei. In ihr stehen Informationen wie die Version, Abhängigkeiten, Paketname, etc. Ich habe diese Datei benutzt:

Package: libxvidcore4
Version: 2:1.2.1
Section: libs
Priority: optional
Architecture: i386
Depends: libc6 (>= 2.7-1)
Installed-Size: 1140
Maintainer: Florian Bugiel <blog.bugie.de>
Description: High quality ISO MPEG4 codec library
 Xvid is a high quality/performance ISO MPEG4 codec. This package contains
 the runtime core library that can be used by various programs (among them
 mplayer/mencoder, transcode)

Diese drei Dinge sollen angepasst werden:

  • Version
  • Installed-Size
  • Maintainer

Bei “Version” trägt man die XviD-Version ein, die benutzt wird. Bei mir ist dies “1.2.1″. Allerdings steht bei der Version aus dem Ubuntu-Repository “2:” davor. Damit man einfach aktualisieren kann, kommt ebenfalls “2:” davor. Falls man eine CVS-Version benutzt kann man aktuellere Versionen auf diese Weise durchnummerieren: “2:1.2.1-1″, “2:1.2.1-2″, “2:1.2.1-3″, usw.
“Installed-Size” ist die Größe der installierten Dateien in kb. Hierfür rechnet man einfach die Größen der Dateien in /var/tmp/xvidcore/build/generic/libxvidcore4_1.2.1_i386/usr zusammen.
Der dritte Punkt “Maintainer”: da schreibt ihr euren Namen rein, da ihr das Paket zur Verfügung stellt. :-)
Nun erstellt man zunächst ein Verzeichnis DEBIAN im Verzeichnis libxvidcore4_1.2.1_i386 und darin die Datei control mit dem besprochenen Inhalt:

 mkdir /var/tmp/xvidcore/build/generic/libxvidcore4_1.2.1_i386/DEBIAN
florian@bugie:/var/tmp/xvidcore/build/generic$ cd libxvidcore4_1.2.1_i386/DEBIAN/
florian@bugie:/var/tmp/xvidcore/build/generic/libxvidcore4_1.2.1_i386/DEBIAN$ ls -l
insgesamt 4
-rw-r--r-- 1 florian florian 411 2009-03-06 11:58 control
florian@bugie:/var/tmp/xvidcore/build/generic/libxvidcore4_1.2.1_i386/DEBIAN$

Nach einem Wechsel nach /var/tmp/xvidcore/build/generic wird das Paket mit diesem Befehl erstellt: dpkg --build libxvidcore4_1.2.1_i386

Und fertig ist das XviD-Paket: libxvidcore4_1.2.1_i386.deb

Anmerkung: Ein gutes, englischsprachiges Howto, wie man Debian-Pakete baut, habe ich hier gefunden.

Eine Java Applikation hat immer java.IO.Exception: Too many open files geworfen. Nun, normalerweise ist das ein eindeutiges Zeichen für einen Programmierfehler, es sei denn man braucht wirklich weit mehr als 50.000 Filehandles. Anstelle das Problem an der Wurzel zu fassen, kann man natürlich Linux dazu bringen, mit mehr File Handles zu arbeiten.  cat /proc/sys/fs/file-max zeigt das momentane Maximum. Mit lsof -X|wc -l erfährt man wieviel Files derzeit geöffnet sind. Wobei man natürlich berücksichtigen muß, das unter *nix alles als Datei zählt, also auch Pipes, Sockets usw. Deshalb das -X, das lässt TCP/UPD weg. Mit sysctl -A|grep fs.file-max sieht man, was der Max Wert ist. In /etc/sysctl.conf ist wahrscheinlich noch keine Zeile für fs.file-max vorhanden. Wenn nicht, oder ein kleiner Wert drinnen steht, kann man z.B. fs.file-max=200000 setzen. Die Änderung kann man dem Kernel mit mitteilen, indem man sysctl -p aufruft. 

Noch ein Wort zur Anzahl der geöffneten Files. Die Anzahl der geöffneten Files ist immer sehr hoch, fast möchte man der Angabe mißstrauen, aber nur, um mal ein Beispiel zu geben. Wenn man sich mit nano readme eine Datei ansieht, wieviel Dateien sind dann dafür geöffnet wurden? (Dateien im Sinne von *nix) 

lsof -p 14009
COMMAND   PID USER   FD   TYPE DEVICE    SIZE   NODE NAME
nano    14009  bed  cwd    DIR    3,1    4096 114898 /home/bed
nano    14009  bed  rtd    DIR    3,1    4096      2 /
nano    14009  bed  txt    REG    3,1  149600 147216 /bin/nano
nano    14009  bed  mem    REG    3,1 1282912 139241 /usr/lib/locale/locale-archive
nano    14009  bed  mem    REG    3,1    9680 229783 /lib/i686/cmov/libdl-2.7.so
nano    14009  bed  mem    REG    3,1 1413540 229045 /lib/i686/cmov/libc-2.7.so
nano    14009  bed  mem    REG    3,1  249836 204406 /lib/libncursesw.so.5.7
nano    14009  bed  mem    REG    3,1   37776 199842 /usr/share/locale/de/LC_MESSAGES/nano.mo
nano    14009  bed  mem    REG    3,1   25700 197817 /usr/lib/gconv/gconv-modules.cache
nano    14009  bed  mem    REG    3,1  113248 204464 /lib/ld-2.7.so
nano    14009  bed    0u   CHR 136,11             13 /dev/pts/11
nano    14009  bed    1u   CHR 136,11             13 /dev/pts/11
nano    14009  bed    2u   CHR 136,11             13 /dev/pts/11

Also 13, beeindruckend, oder? Und nano ist weiß Gott nicht die Krone der Editoren. gedit schafft es in diesem Beispiel auf sage und schreibe 137! Da kommt auf einem laufenden System also ganz schön was zusammen.

Aber es gibt auch noch einen weiteren Grund für die eingangs erwähnte Fehlermeldung Too many open files. Denn häufig ist es nicht das Systemlimit, sondern das userlimit, welches einem da einen Strich durch die Rechnung macht. Anders, als man es häufig liest, ist die Aussage von ulimit nicht aussagekräftig. Die Meldung unlimited jedenfalls darf man nicht falsch verstehen. Erst ein ulimit -n zeigt die wirklich mögliche maximale Zahl der offenen Files. Default ist hier bei Debian artigen Distributionen 1024.

Nun kan ein gewöhnlicher Sterblicher nicht einfach ulimit -n 8192 eingeben, das geht nur als root und gilt dann auch nur für ihn.

Man muß in /etc/security/limits.conf für den betreffenden User einen Eintrag anlegen. Z.B. Für den User horst:

horst	-	nofile		8192
Danach kann der user horst sich einloggen und mit ulimit -n überprüfen, ob nun das Limit auf 8192 gestellt ist. Verkleinern kann horst es übrigens jederzeit, aber nicht wieder erhöhen. So, nun kann er den java Client wieder starten und hat keine Probleme mehr :-)

Via (Confluence Docs 2.10)

5. März 2009

Der Treiber von AMD/ATI wird die Karten der R300, R400 und R500-Reihe nicht mehr unterstützen. Welche Auswirkungen hat das für Besitzer solcher Karten? Welche Treiber können stattdessen benutzt werden, mit denen was genau funktioniert? Da ich natürlich nicht alle Karten durchtesten kann, stützen sich diese Angaben größtenteils auf die vorhandene Dokumentation - korrigiert mich also, wenn manche Angaben nicht der Realität entsprechen.

Alternative Treiber und ihre Fähigkeiten

Es gibt zwei alternative Open-Source-Treiber. Der radeon und radeonHD. Wichtig ist aber nicht nur, dass diese Treiber existieren, sondern wie gut sie mit welchen Karten umgehen können. Grundsätzlich unterstützt der radeon-Treiber Karten ab R100, radeonHD solche ab r500.

2D-Unterstützung

Der radeon-Treiber bietet auf allen betroffenen Karten XAA und EXA. Ebenso der radeonHD für r500 Karten.

3D-Unterstützung/DRI

Der radeon-Treiber bietet 3D-Untersützung bis zur r500. RadeonHD scheint auf dem Weg zu sein, dies ebenfalls für die r500-Karten anzubieten. Noch aber ist es nicht soweit, dass dies standardmäßig aktiviert ist.

RandR 1.2

Radeon und radeonHD unterstützen beide diese XServer-Erweiterung.

Folgerungen

Technische Fähigkeiten ermöglichen Funktionen, sind aber für sich genommen witzlos. Daher kurz die Folgerung, welche Anwendungen wie gut funktionieren sollten.

Dualhead

Es sollte wenige technische Barrieren geben, mit der RandR-Erweiterung eine Multi-Monitorkonfiguration einzurichten.

Compiz

Keine Sorgen müssen sich die Anhänger der 3D-Desktops machen. Da 3D-Unterstützung auch mit den offenen Treibern vorhanden ist, dürfte Compiz & Co funktionieren. ATIs Catalyst war meiner Erfahrung nach in diesem Punkt und auch bei der Videoausgabe eher fehleranfälliger als die offenen Pendants.

Spiele

So schön die Auflistung oben klingt: Für Spieler ist die Situation trotzdem unangenehm. Natürlich laufen manche Spiele mit den offenen Treibern. Manche sogar besser als mit dem proprietären. Trotzdem berichten viele Spieler immer wieder, dass dieses und jenes Spiel nur mit ATIs Treiber funktioniert. Gerade neuere Spiele, gerade DirectX-Spiele per Wine. So ist es z.B. mit dem radeon-Treiber und meiner Radeon 9800 nur selten möglich, DirectX-Spiele per Wine zu spielen, weil dann die Beschleunigung versagt. Das ist nicht in jedem Fall schlimm gewesen - aber wie viele Spiele bieten schon einen alternativen OpenGL-Modus, wenn sie nicht sowieso schon vollständig darauf basieren?

Moin liebe Lesergemeinde,

kürzlich wollte ich einen Musikstream aus dem Internet aufnehmen. Da ich aber keine Lust hatte extra Software zu suchen, die das ohne Probleme beherrscht, habe ich mich daran erinnert, dass Gnome in der Standard-Ubuntu-Installation schon einen Audio-Recorder besitzt. Dieser ist unter Anwendungen – Unterhaltungsmedien – Audio-Recorder zu finden. Dieser kann bei installiertem Lame direkt in MP3 aufnehmen – na wunderbar. Allerdings musste ich nun das aufnehmen können, was aus meinen Boxen dröhnt.

Das geht mittels dem genialen Pulse Audio System. Im Volume Control von Pulse Audio (pavucontrol). Dort gibt es den Reiter Recording. Startet man im Recorder nun eine Aufnahme, sollteim Recording-Tab der Eintrag gnome-sound-recorder erscheinen. Mit einem Klick auf das Dropdown-Feld wählt man mit Move-Stream das Ausgabemedium auf dem gerade der aufzunehmende Stream läuft. Nun sollte der Gnome-Audio-Recorder einen Lautsträke-Pegel anzeigen. Das wars!

gnome_recorder

Gestern war ich auf der CeBIT und habe die Chance ergriffen mal mit den Leuten von Zarafa zu sprechen. Anliegen war immernoch meine Synchronisations Problematik. Ich habe das zwar mittlerweile alles in Griff bekommen, aber irgendwie wäre ein eigener Server doch schöner.

Die Ernüchterung kam relativ schnell. (Zitate sind nur sinngemäß)

Ja, wir sind MAPI kompatibel, und nutzen für die Authentifizierung SOAP, aber nein, OpenChange oder OpenMapi funktioniert nicht.

Sehr schade. Auf die Frage warum denn ein OpenSource Groupware Server, der auf Linux basiert, keinen einzigen Linux Client (sehen wir mal von IMAP und iCal Transport ab) unterstützt, bekam ich eine sehr interessante Antwort:

Es gäbe ja keinen vernünftigen Groupwareclient unter Linux, ja gut, Evolution ist schon nicht schlecht, aber auch nicht so dolle… Das liegt daran, das Evolution, ehemals Ximian, von Suse aufgekauft wurde, diese wiederumvon Novell aufgekauft wurden und da Novell Groupwise bevorzugt, würde Evolution ja auch eh vernachlässigt.

Ganz interessant erscheint für uns allerdings der Client Kmail (Anmerkung: ich denke er meinte Kontact) von KDE, in diese Richtung würde man in Zukunft mal ein Auge drauf haben.

Also alles in allem nicht gerade zufriedenstellend. Warum ist eine Groupwarelösung, auf Linux basierend, nicht in der Lage auch Linux Clients zu bedienen? Gut, sie wollen ein Exchange-Ersatz sein, allerdings günstiger und mit mehr Features. Ich denke, dass sie mit einer Lösung für Evolution/Kontact zusätzlich zu Outlook unter Windows an der Stelle doch auch ein gutes Alleinstellungsmerkmal hätten und so eine größere Zielgruppe erreichen könnten.

Immerhin wird die kommende Zarafa Version wahrscheinlich einen CalDAV Transport mitbringen. Ob es eine Möglichkeit geben wird an seine Kontakte zu kommen, ist noch nicht klar.

Ich denke, an der Stelle werde ich das Zarafa Buch zuschlagen und das Thema wäre dann für mich gegessen. Jedenfalls solange bis das OpenChange bzw. OpenMAPI Projekt es vielleicht doch noch schaffen ;) In der Zwischenzeit leistet mir Google gute Dienste…

Zugestehen muss ich, dass ich bis vor einigen Monaten nicht einmal wusste, wo Chemnitz liegt. Dank dem edlen Bürgermeister bin ich auf die Linux Tage zu Chemnitz gestossen, bei welchen sich eben jener Meister vortrefflich als Organisator und Tätschmeister verausgabt. In gut einer Woche geht es dort los und ich werde - begleitet durch Sohn und Frau - die Reise nach Chemnitz am Freitag in einer Woche in der Früh antreten. Wir waren noch nie in dem Teil Deutschlands und deswegen freuen wir uns gleich doppelt. Übernachten werden wir im Hotel Europark, ganz in der Nähe von der Technischen Universität, wo die Linux Tage stattfinden.

Vor ein paar Wochen hat mich der Meister angefragt, ob ich denn gerne an den Linux Tagen für das RadioTUX moderieren möchte. Das mache ich natürlich gerne, hatte aber leider infolge der Conficker-Affaire keine Ressourcen mehr zur Verfügung, um mich entsprechend einzubringen. Das habe ich nun - so weit sich das noch flicken liess - nachgeholt und ich hoffe, dass ich auch mein Thema zur Linux Nacht noch zusammentragen kann. Dort will ich über verschiedene, freie Produkte diskutieren, mit denen sich ein Online-Büro realisieren lässt (Groupware).

Auf jeden Fall freue wir uns alle drei auf die Reise nach Chemnitz. Es ist ohnehin höchste Zeit, dass ich wieder einmal etwas für mich und mein Hobby tue. Und wenn es für die Familie auch passt - umso besser!

Ähnliche Artikel

Und ich sage dankeschön für viele gebündelte Inforamtionen aus der OpenSource Scene. Echt schade, das anrichter aufhört. Hoffentlich bleibt die Seite als Nachschlagewerk erhalten, das wäre sehr nett.

Also dann noch mal, vielen Dank von www.kde4.de

Seit fast 2 Monaten benutze ich nun Amarok2. Nüchtern betrachtet wäre ich besser noch ein wenig bei der 1.4er Version geblieben.Amarok2 ist zweifellos ein sehr guter Audio-Player. Allerdings fallen einige Dinge doch sehr negativ auf. Die Performance ist dank Plasmoids ein wenig lahmer, ab und an schmiert er ab (beim einstecken eines USB Sticks, manchmal kommt kein Ton mehr aus den Boxen nach einer gewissen Zeit). Was mir jedoch richtig auf den Zeiger geht ist die dynamische Playlist.Songs, die längst aus meiner Sammlung gelöscht wurden tauchen immer noch in der dynamischen Playlist auf und ich kann nichts dagegen tun. Ärgerlich daran ist, dass die Wiedergabe bei diesen Tracks stoppt und ich händisch das nächste Lied anwählen muß.

Irgendwie bekomme ich es auch nicht hin mir die “Sternchen” – also meine persönliche Bewertungen in der Playlist anzeigen zu lassen. Klingt dämlich, aber ich schaffs nicht. Entsprechend fehlt mir da die Filterung. Entsprechend kann ich auch nichts dynamisches mit diesem Kriterium erzeugen :-( .

Positiv dagegen fallen die aufgeräumten Menüs auf, die Oberfläche wirkt schicker, Das Programm wurde noch Last.fm lastiger und die Kriterienvergabe bei Playlisten ist sehr elegant gelöst. Über die ungewöhnlichen Buttons zur Steuerung kann ich nichts sagen, da ich das mit der Tastatur regle; sehen aber ganz toll aus finde ich :)

Die Geschichte mit der Script Api zieht mir nicht so die Fritten vom Teller, da die Dokumentation für mich irgendwie noch nicht so ausreichend ist. Statt alles auf JavaScript(!!!) zu setzen hätte man meiner Meinung nach alles besser beim Alten gelassen, aber vielleicht fehlt mir da noch der Durchstieg.

Unterm Strich ist Amarok2 ein klasse Programm, das noch ein wenig “reifen” muß.

4. März 2009

Auch diese Woche werden wir mit einem neuen Release Candidate für den Kernel 2.6.29 beglückt.

Diese siebte Version behebt einige gravierende Fehler im neuen Netzwerktreiber ATL1c und ebenso in einem Treiber für den Firewire-DVB-Empfänger FireDTV, der bis vor einer Woche noch als firesat bekannt war. Frei nach dem Motto "Neue Treiber können keine Rückschritte machen" (Original: "new drivers can't regress") haben diese noch Eingang in der Kernel gefunden, brachten aber anscheinend Probleme mit sich wenn sie in den Kernel mit hinein kompiliert wurden, ob man die entsprechende Hardware nun nutzte oder nicht. Im Vergleich dazu hält sich der Rest der Änderungen seit -rc6 in Grenzen, es handelt sich dabei in erster Linie um kleinere Korrekturen im Bereich der Treiber.

Umso näher die Zahl hinter dem "-rc" an die "10" herankommt, umso mehr juckt es Torvalds, eine End-Version daraus zu machen. Dass aufgrund der noch recht langen Liste an Problemen zumindest ein -rc8 ausstehen dürfte, kann er trotzdem nicht verleugnen.

Apropos Kernel: Ubuntu-Anwender, die gerne mal den unangepassten Vanilla-Kernel ausprobieren möchten, jedoch das Herunterladen und Kompilieren scheuen, können nun auf ein Personal Package Archive zurückgreifen, das fertige Pakete verschiedenster Kernel-Versionen enthält. Eine ausführliche Beschreibung findet sich im Ubuntu-Wiki: Kernel Mainline Builds
Dazu sei jedoch gesagt, dass weiterhin die Verwendung des Ubuntu-Kernel von den Ubuntu-Entwicklern empfohlen wird. Speziell die Verwendung des Entwickler-Kernels kann bisweilen seltsame Früchte tragen, sodass vom Einsatz auf produktiven Systemen abgeraten wird.

Quellen: Linux Kernel Mailing List, Ikhaya

 

Das alle möglichen Games auf Basis der Quake Engimes unter Linux laufen ist nicht nur allgemein bekannt, sondern den Jungs auch hoch anzurechnen :)

Mit den Pointbase Releases kann man Knaller wie Doom3, Return to Castle Wolfenstein, Quake 4, Quake 3 ohne Probleme zocken. Einfach die *.pak Dateien aus den Base Ordnern in die Linux-Installation kopieren und ab geht die Post.

Nun bin ich über etwas ziemlich Cooles für Quake I, die Mutter aller 3d Shooter gestolpert: unmengen an freien und besseren Engimes, die das Ganze ein wenig aufpolieren.

Mein momentaner Favorit ist tenebrae. Selbes Schema, ähnlicher Spaß

Obwohl ich kein KDE-Nutzer bin: Amarok gehört zu meinen täglich genutzten Standardprogrammen Es ist der beste Player den ich bisher gesehen habe. Doch wie so vieles in Verbindung mit KDE 4 stehende hat auch Amarok 2 herbe Kritik einstecken müssen. Berechtigte Kritik?

Zur Versionsnummer: Amarok 2 in der aktuellen Version (2.0.1), Amarok 1 in der aus den Intrepid-Quellen (1.4.10)

Vergleich

Amarok dürfte vornehmlich für eine Sache genutzt werden: Lokal gespeicherte Musik abspielen. Ab und an gesteuert durch Tastenkombinationen, und einige Nutzer dürften manche Texte nachlesen wollen. Genau diese Anforderungen sollen hier betrachtet werden.

Sammlung erfassen

Die Sammlung muss nicht wirklich oft komplett neu erfasst werden. Doch wenn, dann ist es möglichst schnell und mit möglichst wenig Systemauslastung natürlich angenehm - was allerdings ein Widerspruch ist. Beim Vergleich wurde an den Datenbankeinstellungen nichts verändert, also wurden unterschiedliche Datenbanken miteinander verglichen:

Amarok 1Amarok 2
3:004:18

Überraschend, dass Amarok 1 hier schneller war. Dabei hatte ich Verbesserungen erwartet. Andererseits ist das Meckern auf hohem Niveau: In nichtmal 5 Minuten 29GB zu indexieren scheint mir nicht schlecht.

Das Importieren aus Amarok 1 passierte positiv schnell und angenehm problemlos.

Sammlungsansicht

Die Sammlung von Amarok 1 ist alphabetisch in Blöcke unterteilt, bei Amarok 2 nur alphabetisch gelistet. Daher fehlt diese Orientierungsmarke. Dazu kommt, dass der Kontrast zwischen den abwechselnd wiederkehrenden Farbmarkierungen beim Standarddesign von Amarok 1 größer ist, auch das aufklappende "+" sieht zumindest größer aus.

Lyrics

Bei den zusätzlich anzeigbaren Liedtexten muss man sich im Vorgänger durch die Menüs hangeln, bei Amarok 2 dagegen das neue Widget-Fenster bemühen. Da die Standard-Lyricplugins im ersten Amarok ziemlich kaputt sind, konnte Amarok 2 hier nur gewinnen. Allerdings werden ein paar Zeilen weniger angezeigt. Und der oft erscheinende horizontale Scrollbalken stört.

Playlist

Darüber kann man nicht streiten: Die neue Playlist fasst weniger gleichzeitig sichtbare Lieder. Außerdem ist sie schmaler. Dafür sind die Kontrollknöpfe größer, und prominent links platziert.

Shortcuts

Globale und lokale Shortcuts waren im Vorgänger widernatürlich in zwei Menüs unterteilt. Das macht Amarok 2 besser, hier fasst ein Menü beide Systeme. Dafür tritt eine typische KDE 4-Schwäche auf: Die Standardgröße des Menüs passt nicht zum Inhalt, ist etwas zu klein. Bei Amarok 1 ist das dagegen passgenau abgestimmt.

Während im ersten Amarok hier noch unten eine statische Eingabemöglichkeit angezeigt wurde, klappt die nun auf, wenn man auf eine Option klickt. An sich nicht verkehrt, führte hier aber dazu, dass das mit "OK" bestätigen wurde - und sich so das gesamte Menü schloss.

Kontextinformationen

Beim Abspielen zeigen beide Player Informationen zum Lied an. Und beide haben Nachteile: Bei Amarok 2 ist das Widget viel zu schmal. So kann nichtmal der Interpret "Blind Guardian" vollständig dargestellt werden, dabei ist das nichtmal ein langer Name. Die Icons vermitteln nicht gleich ihre Bedeutung, und der erklärende Hovertext erscheint nur, wenn man über den Text neben dem Icon fährt. Darauf muss man erstmal kommen. Lieblingsstücke und Empfehlungen sucht man vergeblich.

Dafür zeigt der Vorgänger nur entweder die Sammlung oder die Metainformationen an. Mit einem vertikalen Scrollbalken sind hier einige Infomationen mehr zugänglich.

Gapless

Beiden Versionen gemeinsam ist, dass beim Liederwechsel keine Pause entsteht. Einzig ein wirklich sehr kleines Stottern lässt den Liedübergang hörbar werden.

Fazit

Amarok 2 macht einige Dinge anders. Manche schlechter, andere besser. Die Widget-Ablage in der Mitte muss man nicht mögen. Es scheint bisher so, als ob es den Entwicklern schwer fällt, diesen Platz sinnvoll zu nutzen. Das System hat vor allem den Nachteil, dass Funktionen wie die Lyricanzeige nicht mehr ihren festen Platz haben. Dafür können sie einen prominenteren zugewiesen bekommen.

Trotzdem ist Amarok 2 in den Kernfunktionen ein würdiger Nachfolger, dessen volles Potential aber noch entwickelt werden muss. Wird das gelingen?


Die Linux Foundation übernimmt die Domain Linux.com, die bisher von Sourceforge verwaltet und mit Infos bestückt wurde. Noch steht nicht fest, wie Linux.com aufgebaut sein soll; zu diesem Zweck wurde ein „IdeaForge“ eingerichtet, damit die Linux-Community ihre Gedanken und Ideen einbringen kann.

Die ersten grafischen Änderungen auf Linux.com lassen schon einmal Großes erhoffen: die Änderungen sind durchweg positiv.

Das alte Linux.com Das neue Linux.com Linux.de

Linux.de hingegen ist nach wie vor ein Schandfleck. Man kann es nicht anders sagen. Wer zum ersten Mal von „Linux“ hört und bei Google danach sucht, stößt bei Ergebnis 2 und 3 (Suchergebnis 1 ist wie so oft der entsprechende Wikipedia-Eintrag) auf diese mehr als hässliche Seite.

Aber Linux.de ist nicht nur extrem hässlich – es ist auch noch überaus veraltet. Bei den „Bezugsquellen“ wird Ubuntu nicht einmal erwähnt, dafür aber nicht mehr existierende deutsche Linux-Distributionen.

Die Linux.de-Betreiber können die Verantwortung, die sie durch den Besitz der wertvollen Domain Linux.de haben, ganz offensichtlich nicht im notwendigen Maße erfüllen.

Warum also wenden sich die Linux.de-Betreiber nicht an die deutschsprachige Gemeinschaft, um Linux.de wieder auf Vordermann zu bringen?

Linux ist ein eingetragenes Warenzeichen von Linus Torvalds. Die Domain Linux.de zu besitzen ist also kein Recht, sondern ein Privileg – dieses Privileg treten die Verantwortlichen von Linux.de jedoch tagtäglich mit Füßen.

Linux Format CoverDie aktuelle Ausgabe des Linux Format Magazins hat KDE getestet und daraus sogar eine Titelstory gemacht. Derzeit kann man das ganze sogar downloaden.

Der Download steht in zwei Varianten zur Verfügung einer  60 MB und einer 125 MB großen Variante.

Es gilt sich aber zu beeilen, da der Download nur 24 Stunden zur Verfügung steht.

Quelle

Weitere Artikel:

3. März 2009

Hallo!

 Die Linuxcommunity berichtet, dass sich die Entwickler von KDE und Gnome in den neuen Versionen einen Schutz gegen Linuxviren einbauen möchten. Hintergrund ist der, dass ein Linuxbenutzer ein Tutorial veröffentlicht hat, wie man in 5 Schritten einen Virus programmieren kann. Dabei nutzt der User namens foobar die Gutgläubigkeit von KDE bzw. Gnome aus, und kann mit einer .desktop-Datei Schaden auf dem PC eines Anwenders anrichten.

Das Feature von KDE soll ab den kommenden 4er Versionen überprüfen, ob es sich bei .desktop Dateien wirklich um ausführbare Dateien handelt und zeigt ggf. einen Warnhinweis an. Gleiches sehen die Entwickler von Gnome vor.

Nun, da es bei diesen "Viren" um Dateien handelt, die der User selbst, d.h. manuell ausführen muss, sind die gefakten .desktop Dateien keine bösen Viren, die sich unbemerkt ins System einfressen und dort nie wieder gefunden werden können, sondern eher Dateien, die man lieber nicht ausführen sollte und mit gesundem Menschenverstand auch nicht ausführen wird.

Insofern wäre es ja auch ein Virus, wenn man ein ausführbares Script mit dem Inhalt

sudo rm -rf
manuell ausführen würde, was keine täte, weil man bei Fremdquellen vorsichtig ist.

 

Die Vorgehensweise, die die Entwickler von KDE und Gnome an den Tag legen, sind insofern auch keine wahren Maßnahmen, die gegen Viren unter Linux vorgehen, sondern eine kleine Neuerung, die WARNT, falls irgendetwas spanisch in der Datei zu sein scheint Wink.

Also bleiben die Antivirenmaßnahmen erst einmal in der Schublade und werden erst herausgekramt, wenn ernsthafte Gefahr besteht. Ob und wann diese Zeit kommt, wir werden es bald wissen....

Links zum Thema:

Bildquelle: Linux-Communtiy

Ich muss öfters Dokumente einscannen und als PDF abspeichern. Ein Job den eigentlich gscan2pdf wunderbar macht. Doch, wenn ich nur eine Seite einscannen möchte, so ist gscan2pdf einfach ein bisschen “zu viel”. Das Programm starten und sich durch die Dialoge zu hangeln dauert einfach länger als der Scan selber.

Als kleinen Workaround habe ich mir scan2pdf geschrieben. scan2pdf ist ein simples kleines Kommandozeilenprogramm, das eine Seite scannt und das Ergebnis als .pdf auf den Desktop abspeichert. Mehr kann und soll das Programm gar nicht machen. Wer will kann es über

$ sudo wget http://www.christoph-langner.de/static/scan2pdf-1.0.sh -O /usr/local/sbin/scan2pdf
$ sudo chmod +x /usr/local/sbin/scan2pdf

installieren. Das Programm scannt dabei eingelegte Dokumente als .tif. Damit es den Scan später in ein PDF umwandeln kann braucht es das Paket libtiff-tools. Dieses ist üblicherweise nicht bei einem Ubuntu installiert. Es muss daher via

$ sudo apt-get install libtiff-tools

nachinstalliert werden. Alle anderen Abhängigkeiten sind von Haus aus bei einem Ubuntu installiert. Danach kann man via

$ scan2pdf -m gray -r 150

scannen. Eine Eingabe eines Dateinamens habe ich nicht vorgesehen. Die Dateien werden nach dem Scan (bei mir) eh nochmal umbenannt. Also Optionen gibt es

$ scan2pdf --help
Usage: scan2pdf -m {lineart,gray,color} -r [resolution in dpi]
 -m: Scan mode, choose lineart, gray or color
 -r: Resolution in dpi

Beim ersten Aufruf des Programms erscheint ein kleiner Dialog, über den man seinen Scanner auswählen kann. Die Info wird dann zusammen mit ein paar Details zum Scanner in der Datei ~/.scan2pdf abgelegt.

Scannt man mehrere Dateien hintereinander, so werden sie als scan1.pdf, scan2.pdf usw. auf dem Desktop abgelegt. Die Namen und Pfade lassen sich bei Bedarf im Skript anpassen. Richtig elegant und bequem wird es, wenn der Scanner eine Tasten zum Auslösen einer Aktion besitzt.

Scanbutton an einem Canon CanoScan N650U

Scanbutton an einem Canon CanoScan N650U

Diese Tasten kann man auch unter Linux benutzen. Eine Liste unterstützter Scanner findet man hier und Infos zum Programm - wie so oft - im Wiki von uu.de. Hat man das Programm über

$ sudo apt-get install scanbuttond

installiert, so kann man über

$ scanbuttond -f
button 1 has been pressed on plustek:libusb:001:004
button 1 has been pressed on plustek:libusb:001:004

ausprobieren ob es funktioniert. Sobald Ausgaben beim Druck auf einen der Buttons am Scanner erscheinen funktioniert das Programm. Die Konfiguration des Programms erfolgt über die Datei /etc/scanbuttond/buttonpressed.sh. Hier habe ich mein kleines Skript eingetragen. Man kommentiert bspw. die Zeile

[...]
echo "button 1 has been pressed on $2"
[...]

aus und fügt nach ihr

[...]
/usr/local/sbin/scan2pdf -m gray -r 150
[...]

ein. Damit wird scan2pdf beim Druck auf die erste Taste ausgeführt und scannt das eingelegte Dokument mit Graustufen und 150dpi ein. Wer andere Werte bevorzugt trägt einfach eine andere Auflösung oder einen anderen Scanmodus ein. Nun fehlt nicht mehr viel. Nachdem man scanbuttond konfiguriert hat, muss man es nur noch ausführen

$ scanbuttond

Damit dies in Zukunft automatisch beim Einloggen in die Desktopumgebung passiert, muss man es für den Autostart noch unter “System -> Einstellungen -> Sitzung” als Startprogramm hinzufügen. Als Einstellungen wählt man

  • Name: scanbuttond
  • Befehl: scanbuttond
  • Kommentar: scanbuttond starten

Ab jetzt wird scanbuttond automatisch beim Einloggen gestartet und man kann über die Buttons des Scanners automatisch Scans auslösen.

cebit09_1

Die CeBit 2009 hat heute für die Besucher geöffnet. Und ich habe mir das ganze gleich mal angetan. Derzeit weiß ich aber noch nicht so ganz was ich von der Messe halten soll. Ich bilde mir jedenfalls ein, dass die Messe letztes mal besser war. Die zurück gegangenen Besucherzahlen waren sehr deutlich zu spüren und betreffen wohl nicht überwiegend nur die asiatischen Aussteller, wie ich in den letzten Tagen irgendwo mal gelesen habe. Die hohen Ansprüche, die die Veranstalter haben werden wohl nicht mal im Ansatz erfüllt werden.

Ein erster Kritikpunkt ist in meinen Augen, dass die Veranstalter die Messe künstlich größer gemacht haben als sie letztenendes war. Die Hallen waren doch ziemlich leer und teilweise sogar fast zur Hälfte durch Wände abgesperrt. Hier hätte man sich vielleicht ein paar Hallen - und für die Besucher die Lauferei - sparen können. Man fühlte sich beispielsweise schon ein wenig verkohlt, wenn man in eine große Halle kommt in der die “Green IT World” vorgestellt werden soll, und diese dann doch recht leer ist.

Das Highlight der CeBit war natürlich der Open-Source-Bereich. Besonders viel Interesse war zu der Zeit, als ich mich dort aufgehalten habe, am Ubuntu-Stand zu beobachten. Ansonsten waren die üblichen Verdächtigen zu finden, KDE, Mozilla, FSFE, OpenOffice.org, Debian und einige andere.

Den Vogel in Sachen Größenwahn hat in meinen Augen wieder einmal die Telekom abgeschossen. Wird der überdimensionierte Stand jedes Jahr größer oder täuscht das? Ich weiß es nicht.

Die Herrschaften von Vodafone haben auch mal wieder einen kräftigen Griff in die Tonne getätigt. Die Firma hatte ein ganzes Pavillon, wo dem normalen Bürger gleich am Eingang deutlich klar gemacht wurde, dass man unerwünscht sei. Das Pavillon wäre wohl nur für Geschäftskunden interessant. Wenn ich für meine Eintrittskarte Geld bezahlt hätte wäre das schon sehr ärgerlich, hat man doch schließlich das auch mit bezahlt.

Interessant fand ich jedoch den Gigabus, der auf der CeBit vorgestellt wird. Hierbei handelt es sich um einen Reisebus, der an allen Plätzen einen Bildschirm und von überall unterwegs Zugang zum Internet verspricht. Der Bus will wohl so etwas wie die eierlegende Wollmilchsau unter den Reisebussen werden. Das gute Stück soll stolze 600.000 Euro in der Anschaffung kosten. Dennoch fand ich den Bus sehr nett ausgestattet und interessant.

Was mich sehr enttäuscht hat auf der CeBit war ASUS, der Hersteller des bekannten Eee PC. Auf der Messe werden die Netbooks und Nettops nicht nur ausschließlich mit Microsofts Windows vorgeführt, man bewirbt auch noch das Betriebssystem aus Redmond als die beste Lösung für die Geräte.

cebit09_4

It’s Better with Windows? Nun ja. Darüber kann man sicherlich streiten. Ich bin der Meinung, dass ich ASUS einen Gefallen getan hätte, wenn man sich von den anderen abgehoben hätte und auch Linux auf den Netbooks vorgeführt hätte. Auch Dell, die Ubuntu im Programm haben, verzichten auf eine Präsentation des freien Betriebssystems auf ihren Geräten. Eigentlich ziemlich schade, wie ich finde.

Das klingt nun alles ziemlich negativ, so ist es aber nicht ganz gemeint. Es gab hier und da auch interessante Dinge zu sehen. Auch wenn ich den großen Andrang um die 3D-Display-Systeme sind nicht ganz nachvollziehen kann. Gerne hätte ich das T-Mobile G1 mal in die Hand genommen, jedoch waren Google und Android leider nicht vertreten. Vielleicht hätte man das an dem überdimensionierten Telekom-Stand gefunden, durch die Menschen wollte ich mich dann dort doch nicht durchdrängeln.

Fazit: Die CeBit ist nach wie vor eher eine Messe für Geschäftsleute, an einigen Ständen sind jedoch auch die “normalen” Besucher gerne gesehen. Jedenfalls habe ich nun wieder für das nächste Jahr ausreichend Kugelschreiber gesammelt. Dass die Veranstalter für die teilweise halbleeren Hallen genauso viel Geld von den Besuchern verlangen finde ich schon ein bisschen unverschämt. Wer sich für Technik interessiert ist aber auf der Messe nicht fehl am Platze. Es war zwar nicht die beste CeBit, die ich besucht habe, aber auch nicht so schlecht, dass ich nicht wieder hingehen würde. Ich hoffe einfach mal darauf, dass es im nächsten Jahr wieder ein paar Aussteller mehr gibt, damit die Wege nicht so lang sind und es wieder ein wenig mehr zu sehen gibt.

cebit10pre

Was es so alles neues auf der CeBit gibt kann man beispielsweise in den Specials auf Golem.de und bei heise nachlesen.

Meine Eindrücke direkt vor Ort habe ich auch ein wenig via Twitter festgehalten. Wer möchte kann sich das hier noch einmal durchlesen.

Als Besitzer eines Notebooks mit 512MB Hauptspeicher fechte ich einen dauernden Kampf um freie Ressourcen aus. Seit Oktober steht mir hier Xubuntu zur Seite (siehe: Ein Steinbock in anderer Geschmacksrichtung), das somit die Nachfolge des Gnome-basierten Ubuntu angetreten hat.

Mit dieser Umstellung konnte ich auf meinem System fast 40MB sparen, womit der Xfce-Desktop nach meinen Anpassungen nur noch 240 MB des Hauptspeichers belegte. Dabei handelt es sich um den Wert, auf den sich die Speichernutzung nach Hochfahren und Anmelden ohne zusätzlich gestartete Programme nach einiger Zeit einpendelt.

Jaunty konnte mich hier positiv überraschen. Obwohl die Installation in der VirtualBox eher mehr Speicher in Beschlag nahm, begnügte sich Ubuntu 9.04-alpha5 mit 224 MB nachdem es meinen Wünschen entsprechend angepasst war (siehe die Info unten). Insofern war ich schon gespannt, wie Xubuntu abschneiden würde, da es in einer VirtualBox mit im Vergleich zur Gnome-Variante identischen Einstellungen, tendenziell sparsamer lief (um etwa 15MB). Nach frischer Installation und Anpassung kam aber eher eine Enttäuschung - auch die Xubuntu-Installation will 220 MB haben.

Natürlich beklage ich mich hier auf hohem - oder eher niedrigem - Niveau. Auch wenn Xfce bei mir keinen Gewinn gegenüber Gnome bringt, so habe ich mit Jaunty immerhin 20 MB im Vergleich Intrepid gespart. Irgendwo muss bei den grafischen Oberflächen und all den Daemons und Diensten, die für Bequemlichkeit sorgen, ein Mindestmaß an Ressourcenbedarf da sein und irgendwann kann nun mal nix mehr gekürzt werden, ohne dass am falschen Ende gespart wird.

Ich kann mich auch der Ansicht von Keir Thomas, die Ubuntu-Entwicklung stagniere, weil es keine neuen Endanwender-Funtkionen in Jaunty gebe nicht anschließen. Ja, die Neuerungen, die der Benutzer sieht, halten sich im Rahmen (OpenOffice 3, Notifications...), aber was der Anwender spürt (schnellerer Bootvorgang, Qt 4.5) zählt schließlich auch. Der Fokus liegt bei der kommenden Version eben nicht so stark auf Putz und Farbe, sondern mehr auf der Mauer darunter.

Info: Meine Anpassungen sind die Installation des SSH-Servers (Paket ssh), der Oberfläche für die Uncomplicated Firewall (Paket: gufw) und das Deaktivieren jeglichen Compositings.
In den aktuellen Vergleichen habe ich noch dazu auf die Aktivierung des VNC-Servers verzichtet, ebenso auf die Multicast-DNS-Dienstermittlung (avahi-daemon), die Bluetooth-Geräteverwaltung (bluetooth), den entfernten Backup-Server (rsync) und die gemeinsamen Ordner (samba). Dafür ersetze ich den Network-Manager durch Wicd.

 

2. März 2009

Gestern habe ich mein altes Motherboard gegen ein Neues ausgetauscht und gleichzeitig noch die Grafikkarte gewechselt. Danach wieder alle Platten ran gestöpselt und den Rechner hochgefahren - und ich konnte sofort da weiter machen, wo ich aufgehört hatte - ohne lästige Treiberinstallationen bzw. Neuaktivierungen  o.ä. durchführen zu müssen. Wieder ein Grund mehr, warum ich Linux schätze.

Ähnliche Artikel:

  1. Fernwartung mit NX (II) - Update
  2. Abschied von Openmoko
  3. PSPP - eine freie Alternative zu SPSS