ubuntuusers.de

28. Juli 2008

Für die diesjährige Ubucon habe ich bereits einen Vortrag über "Tipps und Tricks bei der Shellprogrammierung" (für Fortgeschrittene) eingereicht. Ich wurde gefragt, ob ich mir vorstellen könnte auch einen Workshop zu halten. Klar. Den würde ich dann auch zum Thema Shell-Programmierung machen, dann allerdings für Anfänger und für Einsteiger.

Wenn Ihr irgendwelche Vorschläge habt, was Ihr in Vortrag oder Workshop sehen oder hören wollt, dann nur her damit.

Der Vortrag soll eine Stunde dauern, den habe ich schon so gut wie fertig.

Bei dem Workshop bin ich mir über den Umfang noch nicht im Klaren.

Ich freue mich darauf, viele von denen, die ich nur virtuell kennengelernt habe, dort real zu treffen.

27. Juli 2008

Vegeta war so freundlich meinen Blog im ubuntuusers Planet hinzuzufügen, da dachte ich mir, ich stelle mich hier mal kurz vor.

Also ich heiße Martin Gräßlin, im Forum habe ich den Usernamen martingr. Ich bin Mitglied des Ubuntuusers Wiki-Teams und treibe mich daher im Forum Rund ums Wiki und im KDE Forum herum.

Seit Anfang des Jahres entwickel ich auch aktiv an KDE mit und im 4.1 Release wird nun auch ein bißchen Code von mir enthalten sein. Aktuell darf ich auch an einem Google Summer of Code Projekt für die KDE arbeiten. Meine meisten Artikel zur Zeit sind zu diesem kleinen Projekt ;-)

Auf dem Weg zum Relase von Ubuntu 8.10 kommt nun die dritte Testversion mit einigen Neuerungen. Der Fokus liegt bei der dritten Alpha vor allem auf die neuen Softwarekomponenten, unter denen sich auch der neue Kernel 2.6.26 befindet.

Wer auf grosse Änderungen hofft, wird enttäuscht. Neu ist ausser dem Kernel lediglich noch die X.org, die in der Version 7.4 vorliegt, was auch Probleme mit einigen Grafik Treibern zur Folge haben kann.

Mit der Alpha 3 ist es aber wieder möglich, Intrepid Ibex als Live Version von der Live CD aus zu booten, was bei den bisherigen Alpha-Versionen von Intrepid nicht möglich war. ACHTUNG! Für den produktiven Einsatz ist die Alpha Version jedoch noch lange nicht geeignet, und sollte deshalb nur von Entwicklern und neugierigen Testern eingesetzt werden.

Der Link zu den Versionen

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Auch wenn ich es für absoluten Quatsch halte: der Würfel kann jetzt teilweise mit zwei Bildschirmen umgehen. Dabei werden zwei Arbeitsflächen so skaliert, dass sie auf einen Bildschirm passen. Ist nicht wirklich schön, aber anders geht es fast nicht. So sieht das ganze dann aus:

Die unangenehmen Sachen bei Dual Screen ist, dass es den Code richtig verunstaltet. Hatte ich mit einer größeren Änderung es endlich geschafft die perspektivische Projektion nicht mehr im Würfel zu definieren, musste ich es jetzt wieder reinnehmen, da alles perspektivisch verzerrt war. Auch die Animationen etc. funktionieren nicht mehr korrekt, bzw. müssen nun angepasst werden. Tja da muss ich durch ;-)

Im vorherigen Beitrag 10 Gründe für Jabber habe ich schon erwähnt, was die Vorteile von Jabber sind. Ein großer Vorteil von Jabber ist, dass man einen eigenen Jabber-Server betreiben kann und damit die volle Kontrolle über seine persönlichen Daten behält (und natürlich auch viele nützliche Plugins benutzen kann). Über das Wiki von ubuntuusers.de bin ich auch Openfire aufmerksam geworden. Openfire wird von Ignite Realtime entwickelt und wurde unter GPL veröffentlich.

Features

  • in Java implementiert
  • Konfiguration vollständig über übersichtliches Webinterface möglich
  • interne Datenbank oder Datenbank-Anbindung (MySQL, …)

Plugins

  • IM-Gateway (AOL Instant Messenger, Gadu-Gadu, ICQ, IRC, MSN, Yahoo! Messenger) für die Anbindung an andere IM-Netzwerke
  • Broadcast für Broadcast-Nachrichten (Nachricht an viele Benutzer)
  • Content Filter um den Inhalt von Nachrichten filtern zu können
  • Monitoring Service für die Überwachung des Jabber-Servers
  • und viele mehr

Installation (unter Ubuntu 6.06)

  • Java installieren mit apt-get install sun-java5-jre
  • Openfire herunterladen von igniterealtime.org/downloads (tar.gz-Version)
  • Archiv entpacken mit tar xvfz openfire_3_5_2.tar.gz
  • Openfire starten mit ./bin/openfire start
  • Konfiguration starten mit dem Browser domain.tld:9090 aufrufen und dem Wizard folgen

Versucht man Openfire auf einem vServer/VPS zu starten sollte man die Datei ./bin/openfire anpassen. Dort müssen bei den Aufrufen von java noch die Paramter -Xms12m -Xmx24m eingefügt werden. Ansonsten versucht die VM von Java zu viel Speicher zu reservieren und der Server bricht beim Starten ab.

weitere Informationen zu Openfire gibt es im Wiki von ubuntuusers.de.

Die LiveCD Linpus Linux Lite wurde bereits im freiesMagazin 07/2008 und in der LinuxUser 03/2008 vorgestellt. Die leichtgewichtige Linux-Distribution aus Taiwan besticht auf der einen Seite laut eigener Aussage mit ihren Mindestanforderungen von einer 366 Mhz CPU, 128 MB RAM und Festplattenplatz von ca. 512 MB (auf einem frisch installiertem Linpus zeigt df -h bei mir allerdings 775 MB an) und auf der anderen mit zwei Oberflächenmodi: einen einfachen und einen erweiterten Modus.

Linpus Linux Desktop

Linpus Linux Desktop im einfachen Modus.

Um Linpus auf seinem eigenen Mini-PC, älterer Hardware oder in einer virtuellen Maschine zu testen, kann man zuerst die LiveCD booten und, wenn einem das System zusagt, Linpus installieren. Allerdings ist die Funktion ziemlich versteckt, doch durch pilotennetz.de: Linpus Linux Lite auf Festplatte installieren bin ich drauf gekommen, wie es geht.

Nachdem ich die LiveCD vom wohl langsamsten Server in ganz Taiwan nach mehreren Stunden endlich heruntergeladen hatte (der Download via Torrent von LinuxTracker geht wesentlich schneller), habe ich sie in einer virtuellen Maschine gebootet und auf einer virtuellen Festplatte eine Partition mit dem ext3-Dateisystem formatiert. Wenn man die gesamte Festplatte nutzen möchte, würde ich auf einem richtigen Computer genauso vorgehen, außer man will Linpus als Zweit- oder Drittsystem installieren. Dann sollte man die Festplatte vorher mit einem Programm wie GParted oder vergleichbaren vorbereiten. So habe ich die gesamte Festplatte genommen, und dazu das Terminal der LiveCD benutzt, was sich unter “Settings” verbirgt.

Das Terminal

Das Terminal findet man im Bereich "Settings".

Am besten stellt man zuerst in der Konsole das us-amerikanische Tastaturlayout auf Deutsch um:

setxkbmap -layout de; setxkbmap -variant "nodeadkeys"

Danach besorgt man sich durch sudo -s Root-Rechte, ein Passwort ist dafür übrigens nicht nötig, und ruft anschließend das Programm fdisk zum partitionieren auf:

[linpus@LINPUS ~]$ sudo -s
[root@LINPUS ~]# /sbin/fdisk /dev/hda
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

The number of cylinders for this disk is set to 6383.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-6383, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-6383, default 6383):
Using default value 6383

Command (m for help): p

Disk /dev/hda: 3294 MB, 3294625792 bytes
16 heads, 63 sectors/track, 6383 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1        6383     3217000+  83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
[root@LINPUS ~]#

Wenn man Linpus auf einem USB-Stick oder auf einer SATA-Festplatte installieren will, muss man “hda” durch “sda” und “hda1″ durch “sda1″ ersetzen. Während dieses Vorgangs erscheint eine Fehlermeldung, die man getrost ignorieren kann, indem man sie weg klickt.

Eine Fehlermeldung, die eigentlich keine ist.

Eine Fehlermeldung, die eigentlich keine ist.

Nach der Formatierung kann man mit mkfs.ext3 das entsprechende Dateisystem erstellen.

[root@LINPUS ~]# /sbin/mkfs.ext3 /dev/hda1

Das Skript, das Linpus auf die Platte spielt liegt im Verzeichnis /boot/tools und wird mit

[root@LINPUS ~]# cd /boot
[root@LINPUS boot]# tools/make_disk.sh /dev/hda1

aufgerufen.

Der große Augenblick: Linpus Lite wird kopiert.

Der große Augenblick: Linpus Lite wird kopiert.

Dummerweise erzeugt das Skript eine Grub-Konfiguration, die nicht bootfähig ist, und man muss die entsprechende Datei nochmal bearbeiten. Dazu muss die Partition auf der Festplatte in das Live-System wieder eingebunden werden:

mkdir /mnt/hda1; mount /dev/hda1 /mnt/hda1

Anschließend kann man sie dann mit dem Editor vi bearbeiten

[root@LINPUS ~]# vi /mnt/hda1/boot/grub/grub.conf

oder einfach hier herunterladen, um sie in das Verzeichnis zu kopieren; das kann man natürlich auch gleich im Terminal erledigen:

curl http://www.imhorst.net/wp-content/uploads/2008/07/grub.conf > \
/mnt/hda1/boot/grub/grub.conf

Die Datei grub.conf habe ich nach dem Vorbild von pilotennetz.de folgendermaßen angepasst: Der Eintrag “vmlinuz” wurde durch “bzImage” ersetzt. Bei der Wartezeit vor dem Boot (timeout) habe ich 5 Sekunden eingetragen und “hiddenmenu” mit einem Kommentarzeichen (#) versehen, damit das Grub-Menü vor dem Start angezeigt wird. Den “ramdisk_size” habe ich von 4444 auf 32000 erhöht, der Wert kann eventuell auch niedriger gewählt werden. Die neue grub.conf sieht dann ungefähr so aus:

default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
# hiddenmenu

title Linpus Linux Lite
        rootnoverify (hd0,0)
        kernel /boot/bzImage changes=/dev/hda1 root=/dev/ram0 rw max_loop=255
init=linuxrc selinux=0 vga=0x314 splash=silent quiet loglevel=1 console=tty1 acpi
=force load_ramdisk=1 prompt_ramdisk=0 ramdisk_size=32000 from=/dev/hda1
probeusb
        initrd /boot/initrd.gz

title Linpus Linux Lite(rescue)
        rootnoverify (hd0,0)
        kernel /boot/bzImage changes=/dev/hda1 root=/dev/ram0 rw max_loop=255
init=linuxrc selinux=0 vga=0x314 splash=silent quiet loglevel=1 console=tty1 acpi
=force load_ramdisk=1 prompt_ramdisk=0 ramdisk_size=32000 from=/dev/hda1
probeusb rescue
        initrd /boot/initrd.gz

Abschließend muss das Dateisystem noch ordentlich ausgehängt und der Rechner neu gestartet werden.

umount /mnt/hda1; /sbin/shutdown -r now

Der Computer sollte nun auch ohne die LiveCD von der Festplatte booten. Wenn das geklappt hat, muss Linpus Lite noch weiter angepasst werden: Es fehlen zum Beispiel Repositories, um weitere Software nachzuladen, und deutsche Sprachpakete. Außerdem muss das Tastatur-Layout dauerhaft auf einen deutschen Zeichensatz umgestellt werden, sonst hat man nach jedem Neustart eine us-amerikanische Tastatur.

SCIM auf dem erweiterten Desktop

SCIM auf dem erweiterten Desktop

Über das Programm SCIM (der kleine Button in der Taskleiste rechts unten auf der linken Seite) kann man auch ein deutsches Tastaturlayout einstellen. Durch einen Rechtsklick ruft man ein Menü auf, in dem man dann “SCIM Setup” auswählt. Dort wählt man “Global Setup”, um die deutsche Tastatur einzustellen und einen Haken bei “Share the same input method among all applications” zu setzen. Allerdings vergisst SCIM die Einstellungen wieder, wenn man zwischen den Desktopmodi wechselt. Am besten ist es, wenn man ein kleines Skript schreibt, das man tastatur nennt und nach /usr/bin kopiert, um es schnell aufrufen zu können:

#!/bin/bash
setxkbmap -layout de
setxkbmap -variant "nodeadkeys"

So kann man Linpus erstmal immer wieder an die deutsche Tastatur erinnern. Nun gilt es, Linpus Linux Lite einzurichten.

Instant Messaging (IM) ist ein praktischer Dienst im Web. Gegenüber eMail hat IM den Vorteil, dass man direkter kommunizieren kann. So sieht man z.B. ob der Kommunikationspartner gerade online ist. Es gibt eine vielzahl von unterschiedlichen IM-Diensten im Web: ICQ, MSN und Skype um nur einige davon zu nennen. Diese Dienste haben eines gemeinsam: sie werden von Unternehmen betrieben, die Geld verdienen möchten und basieren meist auf geschlossenen Protokollen. Das hört sich erstmal nicht dramatisch an, denn die Anbieter stellen ihren Dienst schließlich kostenlos zur Verfügung. Wirft man allerdings einen Blick in die AGBs dieser Anbieter sieht das nicht mehr ganz so rosig aus. Bei ICQ gibt man z.B. das Copyright an den versendeten Nachrichten auf.

You agree that by posting any material or information anywhere on the ICQ Services and Information you surrender your copyright and any other proprietary right in the posted material or information. You further agree that ICQ LLC. is entitled to use at its own discretion any of the posted material or information in any manner it deems fit, including, but not limited to, publishing the material or distributing it. Quelle: ICQ

Neben den proprietären IM-Diensten gibt es auch einen offnen Dienst: Jabber. Jabber ist ein offenes Protokoll und kann frei verwendet werden.

10 Gründe für Jabber (und gegen ICQ, MSN & Co.)

  1. Jabber ist freie Software.
  2. Bei Jabber gibt es keine nervige Werbung.
  3. Jabber ist für alle Plattformen (Window, Linux, Mac, …) verfügbar.
  4. Die Ausfallsicherheit bei Jabber ist sehr hoch, da es keinen Single-Point-Of-Failure gibt (vgl. Login bei ICQ)
  5. Jabber ist sicher, da die Kommunikation zwischen Client und Server kann verschlüsselt werden.
  6. Mehrere simultane Logins. Bei Jabber kann man sich mehrfach anmelden z.B. von Handy, daheim und im Büro.
  7. Jeder kann einen eigenen Jabber-Server aufsetzen und hat damit die volle Kontrolle über seine persönlichen Daten.
  8. Jabber bietet die Möglichkeit eine Verbindung zu anderen Netzwerken wie z.B. ICQ und MSN aufzubauen. Somit kann man über Jabber auch Freunde erreichen, die keinen Jabber-Account haben.
  9. Jabber bietet alle Funktionen, die man aus anderen IM-Netzwerken kennt (z.B. Chat-Räume, Gruppen, …).
  10. Jabber wird auch von Unternehmen verwendet.

weitere Argumente für Jabber: deshalbfrei.org, ulm.ccc.de, waterstorm.de und daniel.omschallom.com

Für mich sind das genügend gute Argumente um nach und nach auf Jabber umzusteigen. In nächster Zeit werden daher Artikel folgen, die die Einrichtung von Jabber unter Ubuntu genauer beschreiben.

Bildquelle: PHOTOCASE kallejipp

26. Juli 2008

Unter Linux ist eine Vielzahl von Paketen, die entweder im .deb (debian) oder .rpm (Red Hat Package Managers) Format vorliegen, verfügbar. Ubuntu basiert bekannterweise auf Debian, also werden die .deb Pakete in Ubuntus Paket-Verwaltungssystem installiert. Will man nun aber eine breitere Palette haben, oder man findet kein passendes .deb Paket, jedeoch aber eines in .rpm oder .tgz, kann dieses ganz leicht mit einem Programm namens Alien umkonvertiert werden.

Um das Konsolenprogramm Alien verwenden zu können, müssen unter Ubuntu die folgenden Pakete installiert werden:

sudo apt-get install alien rpm lsb

Wie wird umgewandelt?

In einem Terminal lässt sich nun das fremde Paket mit dem folgenden Befehl in ein Ubuntu Paket umwandeln:

sudo alien <fremdes Paket> z.B.: sudo alien /home/user/Desktop/einprogramm.rpm

Nach dem erfolgreichen Ausführen des Befehles lässt sich im gleichen Verzeichniss, in unserem Beispiel der Desktop, ein .deb Paket finden, dass wie gewohnt installiert werden kann.

Wer das Paket noch vor dem konvertieren bearbeiten will, der kann mit diesem Befehl…:

sudo alien -g <fremdes Paket> 

… ein Verzeichniss erstellen, in dem alle Dateien des Paketes unformatiert abgelegt werden, und diese bearbeiten. Anschliessend kann dieses mit dem obigen Befehl in ein Ubuntu Paket umgewandelt werden.

Ubuntuusers Wiki Alien Homepage

Ja es ist passiert. Ich habe auf git umgestellt. Ich hatte zuletzt einige noch nicht ins SVN eingespielte Änderungen und habe an verschiedenen Sachen gleichzeitig gearbeitet. Ohne Versionsverwaltung ein echtes Problem. Einen eigenen Branch im SVN wollte ich auch nicht mehr. Die Lösung des Problems: git

Nun kann ich auf meiner Festplatte commits vornehmen ohne auf einen externen Server angewiesen sein. Kann also weiterentwickeln an noch nicht eingespielten Bereichen und habe dennoch eine Versionierung.

Natürlich ist git noch etwas gewöhnungsbedürftig. Aber ich denke mal, dass ich mich so langsam aber sicher eh einarbeiten muss, da ich davon ausgehe, dass die KDE langfristig auch ein git verwenden wird. Mal abwarten.

Vor zweieinhalb Jahren wurde das augenzwinkernde Echtzeitstrategie Games S.W.I.N.E. als Free Christmas Edition vom Hersteller StormRegion freigegeben. Heute habe ich es endlich mal ausprobiert.Es funktioniert tadellos mit der wine Version, die in Ubuntu Hardy ist. Kein Wunder, ist ja nicht ganz neu, braucht nur DX 8.0. Sieht aber schweinegeil aus. Ein Problem gibt es allerdings. Man muß den video Ordner  .wine/drive_c/Programme/Stormregion/S.W.I.N.E/ video_de umbenennen oder löschen. Die Meckermeldung, das die Videosequenz nicht gefunden werden konnte, kann man getrost wegklicken. Als Screenshot habe ich mal keine Szene aus dem Spiel genommen, sondern die Missionsende Meldung. Fand ich niedlich. Was mir mittlerweile aufgefallen ist, S.W.I.N.E. läuft nur mit 800x600 bei mir. Muss ich mal näher untersuchen. Merkt man im Spiel aber gar nicht.

Mittlerweile habe ich mehrere Male sowohl Ubuntu Hardy Heron als auch Arch Linux in aktueller Version auf dem TabletPC installiert – Zeit für einen Vergleich dieser beiden Distributionen.

Als Testsystem dient einmal mehr mein Acer Travelmate C111 TabletPC mit Celeron 1Ghz Ultra Low Voltage CPU, 1Gb RAM, 20Gb Harddisk, Touchscreen/Stift, rotierbarem Bildschirm und Intel 2200BG Wireless Lan.

Installation

Arch Linux

Die Installation von Arch Linux läuft über ein externes CD-Rom-Laufwerk reibungslos. Das Basissystem mit knappen 300Mb ist über einen terminalbasierenden Installer und mit Hilfe der guten Installationsanleitung recht schnell installiert, die weitere Einrichtung des Systems mit Xorg, Gnome, Software und die Konfiguration von Touchscreen, Wlan und Spezialtasten nimmt aber noch einige Zeit in Anspruch. Konfigurationseinstellungen werden grundsätzlich in einfachen Textdateien vorgenommen. Das Wiki ist bzgl. der Installation und Konfiguration von Arch Linux sehr hilfreich und verständlich geschrieben, trotzdem ist etwas Erfahrung im Umgang mit Linux und Terminal empfehlenswert.

Ubuntu Linux

Ubuntu Linux lässt sich auf dem Acer Travelmate C110 sehr einfach installieren – LiveCD einlegen, Rechner starten, grafisches Installationsprogramm durchlaufen – fertig. Für alle Fälle gibt es auch hier gute Installationsanleitungen im sehr umfangreichen deutschsprachigen Wiki. Separates Installieren und Einrichten von Xorg und Gnome fallen weg. Eine grosse Anzahl vorinstallierter Software ist dabei, die Nachinstallation benötigter Software ist ähnlich einfach wie unter Arch Linux.

Extraarbeit macht das Einrichten von aktivem WLan nach Suspend/Hibernate, der Touchscreen inkl. Bildschirmrotation und die Spezialtasten.

Ubuntu erstellt im Gegensatz zu Arch Linux während der Installation in der Konfigurationsdatei des Bootmanagers Grub automatisch alle Einträge für auf der Festplatte schon existierende Betriebssysteme.

Software

Arch Linux

Arch Linux bietet eine grosse Menge Softwarepakete in eigenen Repositories, vervielfacht wird diese Menge durch das Arch Linux User-Community Repository (AUR) – dort findet man die Sourcen vieler weiterer Pakete, oft in sehr aktueller Form. Der Paketmanager Pacman verrichtet seine Arbeit im Terminal zuverlässig und bietet eine Fülle an Optionen, auch Abhängigkeiten werden zuverlässig aufgelöst. Wenn es doch nötig sein sollte können externe Repositories für Binärpakete einfach eingebunden oder auch eigene Repositories erstellt werden.

Ein weiteres Programm zur Paketverwaltung ist das ebenfalls im Terminal zu benutzende Yaourt welches die Paketverwaltung inklusive Abhängigkeiten, Installation, Paketinformation, Deinstallation etc. und das übersetzen im Quellcode vorliegender Pakete aus dem AUR in sich vereinigt und automatisiert. Als kleines Schmankerl gibt es dann noch eine farbige Terminalausgabe.

Durch das Rolling Release-System verspricht Arch Linux permanente Aktualität aller installierten Pakete, allerdings sollten Updates aus diesem Grund auch häufiger gemacht werden um Inkonsistenzen durch längere Pausen zu vermeiden. Arch Linux liefert kein grafisches Paketmanagement-Frontend mit, eine Übersicht erhältlicher Software findet man hier im Wiki

Ubuntu Linux

Abgesehen von AUR und dem Rolling-Release-System kann man obigen Text fast 1:1 übernehmen, der Paketmanager heisst hier Apt und ist eine lange Zeit bewährte Software, Source-Pakete und -Abhängigkeiten können aus den verschiedenen Ubuntu-Repositories ebenfalls heruntergeladen werden – die Paketmanager nehmen sich hier nichts. Zu beachten ist das zwei Systeme zur Paketverwaltung zu Verfügung stehen, neben Apt existiert auch Aptitude. Eine gemischte Anwendung dieser beiden Paketverwaltungssysteme sollte aufgrund der Möglichkeit von Abhängigkeitsproblemen vermieden werden. Einen grossen Vorteil gegenüber Arch Linux unter Gnome – vor allem für Einsteiger – bietet Ubuntu mit dem bereits mitgeliferten, grafischen Paketmanagement-Frontend Synaptic (GTK). Diese Software macht es gerade Einsteigern sehr viel einfacher Pakete zu installieren oder zu löschen.

Ubuntu erscheint im Gegensatz zu Arch Linux’ Rolling-Release-System zweimal jährlich in neuer Version. Aus diesem Grund muss etwa alle sechs Monate eine komplette Systemaktualisierung durchgeführt werden sofern man auf dem aktuellen Stand bleiben möchte. Die Möglichkeit Pakete unabhängig von den Ubuntuservern aktuell zu halten bieten von vielen Benutzern der grossen Ubuntugemeinschaft bereitgestellte externe Repositories.

ACPI, Suspend & Hibernate

Arch Linux

Suspend und Hibernate können mit dem Paket pm-utils eingerichtet werden und funktionieren einwandfrei. Das dynamische Takten der CPU zwischen 600 und 1000Mhz macht ebenfalls keine Probleme. Der Akkubetrieb wird automatisch erkannt, die Akkulaufzeit wird ab Installation mit 2 Stunden 15 Minuten angegeben. Das automatische Herunterfahren bei kritischem Akkuladezustand funktioniert ebenfalls. Die Ereignisanzeige des Akku/ACPI-Applets zeigt ebenso wie unter Ubuntu keinerlei Ereignisse und scheint abgesehen von der Ladezeitanzeige und Standby/Hibernate-Menüpunkten funktionsuntüchtig. Das Drehen des Bildschirms löst wie auch unter Ubuntu keinen ACPI-Event aus.

Ubuntu Linux

Auch hier funktionieren die dynamische Taktung und Schlafmodi zuverlässig, einzig das auf einem Intel BG2200 basierende Wireless Lan nimmt sich nach dem Aufwachen eine Auszeit (sh. unten). Die Akkukapazität schätzt Ubuntu auf 1 Stunde 50 Minuten, auch hier machen automatische Ereignisse bei kritischem Ladezustand keine Probleme.

Wireless LAN

Arch Linux

Die Einrichtung der Intel 2200BG verläuft reibungslos, als Bestätigung der Intel-Lizenzen muss in Grub als Bootoption intel-wireless mitgegeben werden. Im laufenden Betrieb macht Arch Linux hier absolut keine Probleme. Um die WLan-Karte nach Suspend und Hibernate zuverlässig zu reaktivieren ist der Wechsel vom NetworkManager zu WICD nötig, für das manuelle De-/Aktivieren ist das Paket acerhk zu installieren welches in den Repositories verfügbar ist.

Ubuntu Linux

Die Einrichtung verläuft hier vollautomatisch, manuelles Eingreifen durch den Admin ist nicht nötig. Im Standardbetrieb gibt es ebenfalls keine Probleme, einzig nach Suspend und Hibernate verweigert Ubuntu trotz manuellem Nachkonfigurieren sporadisch ein Reaktivieren der Karte. Auch hier ist das Paket acerhk nötig.

Touchscreen und Rotation

Arch Linux

Der mit Stift bedienbare Touchscreen wird unter Arch Linux durch manuelle Konfiguration der Datei /etc/X11/xorg.conf, Installation des selbst zu kompilierenden Paketes linuxwacom (in AUR verfügbar) und einer Zeile in der Datei /etc/rc.local eingerichtet und funktioniert dann beispielsweise mit Gimp, Inkscape oder Xournal problemlos. Die Bildschirmrotation mit XRandr funktioniert ebenfalls, sowohl mit als auch ohne Compiz Fusion bleibt Gnome auch nach Rotation funktionstüchtig. Auch die allgemeine Bedienung von Gnome (Menüs, Fenster,…) gelingt nach kurzer Eingewöhnungsphase auch mit dem Stift recht gut.

Ubuntu Linux

Hier bleibt nicht viel zu sagen, Touchscreen und Stift funktionieren nach nahezu identischer Einrichtung ebenfalls problemlos, das nötige Treiberpaket heisst wacom-tools und muss nicht selbst kompiliert werden, die Extrazeile in der /etc/rc.local ist nicht nötig.

Ein grösseres Problem könnte den Eye-Candy-Liebhabern auffallen – unter Ubuntu wird der Bildschirm nach Rotation mit laufendem Compiz Fusion nicht mehr neu gezeichnet, das System lässt sich nur noch blind bedienen – zu sehen bekommt man ausschliesslich ein Standbild. Auf Launchpad gibt es einen entsprechenden Bugreport.

Sondertasten

Hier braucht man gar nicht erst einen Unterschied suchen – mittels xev und xbindkeys lassen sich alle Sondertasten einrichten, die Taste zum Ein-/Ausschalten von Wlan kann mit einem kleinen zusätzlichen Script ebenfalls zu dieser Funktion überredet werden, die fünf Tasten auf dem Bildschirm können im Tablet-Modus z.B. mit Funtionen zum Scrollen oder Rotieren des Bildschirms belegt werden. Auch die LED unter dem Mail-Button kann relativ einfach mittels dem Paket acerhk und minimaler Editierarbeit zum Leuchten gepracht werden, in Verbindung mit dem Emailprogramm Claws-Mail kann sie zur Signalisierung neuer Nachrichten im Posteingang genutzt werden.

Beide Betriebssysteme kommen gleichermassen mit den Sondertasten zurecht, der Einrichtungsaufwand ist identisch.

Geschwindigkeit

Arch Linux bietet ausschliesslich i686 oder x86_64-optimierte Pakete an. Einen messbaren Geschwindigkeitsunterschied zu Ubuntu Hardy in aktueller Version mit seinen generischen ab i386er-Architektur lauffähigen Paketen konnte eine Reihe von Benchmarks mittels GtkPerf und der Phoronix Test Suite darstellen, Arch Linux scheint im Grossteil der Benchmarks etwas besser abzuschneiden, einen deutlichen Unterschied sieht man beispielsweise bei der GZip-Kompression.

Beim normalen Arbeiten am Rechner sollten die Unterschiede allerdings abgesehen von der etwas höheren GTK-Geschwindigkeit, die möglicherweise für ein flüssigeres Gefühl beim Arbeiten mit der Desktopumgebung vermittelt, nicht auffallen.

Speicherplatzbedarf

Mit sämtlicher installierter hier benötigter Extra-Software kommen sowohl Ubuntu als auch Arch Linux (Gnome) auf ca. 2,8Gb Fesplattenplatzbedarf. Ubuntu liess sich mittels Apt und Synaptic auf ca. 1,6Gb entschlacken, unter Arch Linux schlug dieser Versuch fehl. Alle Pakete einzeln über Pacman oder Yaourt durchzugehen ist sehr zeitaufwändig, ein grafischer Paketmanager unter Gnome/GTK der Abhängigkeitsprobleme oder gefährliche Löschversuche durch Warnungen kennzeichnet konnte noch nicht gefunden werden. Auch auffallend war dass Ubuntu beispielsweise die separate Installation von OpenOffice-Writer zulässt, Arch Linux jedoch nur die komplette OpenOffice Suite anbietet.

Fazit

Arch Linux

Die Einrichtung ist wesentlich aufwändiger und erfordert zumindest Grundwissen bezüglich Linux und Terminal, im laufenden Betrieb existieren hier kaum Probleme. Die Möglichkeit Software aus dem AUR relativ einfach selbst übersetzen zu können bietet viele Möglichkeiten, nachteilig wirkt sich der entsprechende Zeitaufwand aus. So benötigte das testweise Übersetzen von Firefox auf dem 1Ghz Celeron ca. 1,5 Stunden, Wine in einer älteren Version immerhin noch 1 Stunde. Nötig wird das Selbstbauen von Paketen für den Durchschnittsanwender aber nur in Ausnahmefällen. Das Zusammenstellen des eigenen Systems ab der Grundinstallation vermittelt bis zu einem gewissen Grad gute Kenntnisse über die Strukturen von Dateisystem, Diensten, Konfiguration und Paketen. Durch das Rolling Release-System bietet Arch Linux permanente Aktualität.

Ubuntu Linux

Die Einrichtung des Systems gelingt zügig, nur für einige Spezialfeatures muss per Hand nachgearbeitet werden. Der grafische Installationsassistent führt den Benutzer sicher und schnell durch die Installation, danach ist das System mit allen grundlegend nötigen Softwarepaketen ausgestattet. Die langen Releasezyklen bergen ein gewisses Risiko beim fälligen Aktualisieren. Einige kleinere Fehler trüben hier den Spass beim täglichen Arbeiten, trotz allem ist Ubuntu weiterhin erste Wahl für Linux-Einsteiger.

Tja, so'n Wide Screen Display ist schon toll, wenn man einen Film gucken möchte. Aber wann macht man das schon auf einem Laptop, wenn man nicht gerade im Hotel sitzt und wartet, bis es Essenszeit ist. Wenn man Spiele spielen will, die einen 4:3 Bildschirm voraussetzen, dann kommt man schon in Schwulitäten, denn den unteren Teil des Screens muß man erraten, sehen kann man den nämlich nicht.

Eine einfache Lösung ist das starten eines dedizierten X-Servers mit der passenden Auflösung, dann klappt es auch mit StarCraft. Das Prinzip ist aber auch für jedes andere Programm geeignet, welches nicht selbstständig den Wide Screen erkennt. Dieser Tipp ist etwas ausführlicher, deshalb bitte im erweiterten Teil weiterlesen.


"starcraft mit wine auf Widescreen" vollständig lesen

25. Juli 2008

Mal kurz etwas Werbung (für ein Hobbyprojekt, ich bleib mir treu ;-) )

Die VAZ ist ein kostenloses monatliches Onlinemagazin im PDF Format, mit Informationen über Developerkram und Games.

Ps: in der Aprilausgabe ist ein Interview mit Kai-Li, den WoP Spielern ganz sicher bekannt ;-) Webseite der VAZ

VAZ-Online

Ein anderes Magazin nennt sich freies Magazin. Supertoll aufgemacht und richtet sich primär an Linux Beginner.
Magazin | freiesMagazin   

Schaut einfach mal vorbei. (ähh, den Slogan kenn ich doch ?)

Angefangen hat alles während der Konvertierung am Wochenende. Als wir dabei waren die Wiki-Seiten zu kopieren, kam es ständig zu Ausfällen beim NFS. Matthias (smurfix) war deshalb auch innerhalb kürzester Zeit dreimal im Rechenzentrum, unter anderem auch um 3 Uhr morgens, und hat uns dann schlussendlich einen anderen Server von noris-network temporär zur Verfügung gestellt. Mit dem hat dann auch alles gut funktioniert. Die Ursache hier, war vermutlich eine Fehlfunktion des (fest eingebauten) SCSI-Controllers bei SMP.

Als wir dann endlich Online gingen, wurden wir jedoch mit einer Vielzahl von Anfragen regelrecht überrannt. Kurz darauf ging ubuntu-eu aber auch schon wieder offline, damit wir das NFS wieder auf einen unserer eigenen Server umziehen konnten. In den folgenden Tagen hatten wir leider noch Probleme, gute Werte für die Apache Config zu finden, um die sorgfältig vom Server-Team überlegte Server Architektur mit Load Balancing auszunutzen.

Es gab in der Zwischenzeit auch noch einige Optimierungen am Caching vom Wiki und ein paar slowqueries wurden entfernt. Das betraf unter anderem die Suche nach verwaisten und fehlende Seiten im Wiki.

Das derzeitige Problem liegt aber immer noch an der Server-Architektur, welche zwar für PHP-Skripte und statische Dateien perfekt ausgelegt ist, aber leider nicht optimal für persistente Python Anwendungen geeignet ist. Das Server-Team wird sich, sobald es wieder vollständig da ist (aus irgend einem für uns unerklärlichen Grund sind die nach den Turbulenzen fast alle auf Urlaub gefahren *g*), noch genauere Gedanken über die Umsetzung machen.

Die restlichen Probleme sind aber kleinerer Natur. Unser Trac sammelt brav alle Server-Errors und eure User-Reports um die wir uns in den nächsten Tagen verstärkt kümmern werden. Auch der Suchindex hat während den NFS-Problemen ein paar kleinere Schäden davon getragen und muss noch neu generiert werden.

Wir bedanken uns für eure Geduld, und vor allem auch bei allen Admins die uns tage- und nächtelang geholfen haben (heute ist ja schließlich SysAdmin-Day) und bei dem französischen Team, die ebenfalls einige Probleme mit uns durchgestanden haben. Besonderen Dank haben sich auch noch Matthias Ulrichs (Server-Team Leiter), Herve Rousseau (ein französicher Admin) und Thomas Johansson verdient.

Aus technischen Gründen konnten wir die Kommentare nicht aus dem alten Blog mit importieren. Alte Kommentare lesen.

Na, das sieht ja jetzt schon richtig schnuckelig aus. Gut zu wissen, das es nun endlich wieder vorwärts geht. Das Beschädigen eines 'Objekts' in der Zelle wird die Leistungsfähigkeit der Arbeit der Einheit (z.B Objekt-Produktion / Rohstoffförderung) reduzieren. Auch sehen die Inseln besser aus und es ist flexibler um die Unterkonstruktionen zu platzieren.

Die ToDo Liste für die Alpha schrumpft. Nun macht Martin Urlaub, danach geht es mit frischem Schwung weiter. (Hoffentlich)

Das Mitglied Chrisss hat auf Ubuntuusers.de einen interessanten Denkanstoß zu den Inhalten des Planeten aufgeworfen. Leider driftet der Thread jetzt sehr ins Off-Topic ab, so wie ich das gerade beim überfliegen sehe, dennoch haben wir uns überlegt darauf zu reagieren. Wir werden für den Planeten künftig bestimmte Artikel speziell mit dem Tag “Ubuntuusers” versehen, nicht mehr mit dem Tag “Ubuntu”. Somit ist gewährtleistet, dass nicht zu viele Themen doppelt und dreifach auf dem Planeten erscheinen.

Der Feed, der zum Planet führt bleibt aber weiterhin über http://feeds.feedburner.com/OSHELPDESKORGUbuntu erreichbar. Wir haben lediglich die Verlinkung dort hin verändert.

Diskussionsbeitrag im Forum

Die von Intel entwickelte Linux-Distribution Moblin soll in der bald erscheinenden Version nun doch nicht auf Ubuntu basieren. Stattdessen soll Fedora die Basis bilden. Die Entscheidung sei rein technisch gewesen, so Intel.

Moblin ist eine Linux-Distribution, welche speziell auf mobile Geräte ausgelegt ist. Diese bereits 2007 vorgestellte Plattform wurde im Laufe der Zeit speziell auf Intels mobilen “Atom”-Prozessor angepasst.

In den nächsten Wochen soll bereits die Version 2.0 von Moblin erscheinen, welche bereits auf Fedora anstelle von Ubuntu basieren wird.
Als Grund wird die Tatsache genannt, dass Ubuntu mit Debian-Paketen, und Fedora mit RPM Paketen arbeitet. Da es mit RPM möglich ist nur Pakete einer bestimmten Lizenz zu installieren fiel die Wahl auf Fedora.

Des weiteren ist für Moblin 2.0 eine neue Oberfläche und neue Anwendungen anekündigt worden.

Wie ich finde sollte man diese Entscheidung auch als eingefleischter Ubuntu-Anhänger nicht kritisieren, da es immer noch löblich ist, wenn auf freie Software gesetzt wird.

Bei meinen Recherchen und Exkursionen zu alternativen Desktops und Fenstermanagern habe ich nun offenbar die Lösung für mein nur sporadisch funktionierendes Suspend to Ram gefunden. Ich verwende momentan Gnome mit Openbox als Windowmanager, damit sind die Schwabbelfenster weg, aber auch diese merkwürdigen kurzzeitigen freezes der Anwendungen. Ich habe ja glaube ich bereits erwähnt, das manchmal die Eingabe in einem beliebigen Fenster nicht möglich war und dann irgendein Prozess im Hintergrund neustartete und es dann wieder geht. Supend to RAM hat eigentlich immer nur bei ersten Mal funktioniert, Bei weiteren Versuchen ist es meist schief gegangen und ich musste den Rechner hart ausschalten. Doch nun mit OpenBox scheint das Problem auch weg zu sein, jedenfalls habe ich nun viermal hintereinander den Standby benutzt und das System ist blitzartig wieder zum Leben erwacht.

Die Kollegen von ubuntu-center.de sprechen derzeit über ein meiner Meinung nach sehr interessantes Thema, die Oberflächengestaltung unter GNOME bzw. mit Gtk+. Der Grund dafür ist das neue Design der Seite, welches vor wenigen Tagen vorgestellt wurde. Daraufhin hatte einer der Beteiligten die Idee, ein GNOME-Thema im selben Gewand zu erstellen.

Da mich das Thema Oberflächengestaltung sehr interessiert, will ich nun auch meinen Beitrag dazu abgeben. Was ist eigentlich die Grundlage eines Designs? Sind es diese kleinen Dateien, welche sich im themes-Ordner befinden? Nein, diese Dateien sind nur das Ende der Fahnenstange. Diese Dateien, die sogenannten Themen, setzen auf einer Engine auf. Die muss programmiert werden und benutzt das Gtk+-Toolkit. Läufige Engines sind Murrine, sehr schnell und anpassungsfähig, Clearlooks, die GNOME Standard-Engine, Ubuntulooks, eine von Ubuntu modifizierte Clearlooks-Engine und noch andere Engines, wie zum Beispiel Aurora, welche zwar ganz nett, allerdings ziemlich langsam ist.

Auch wenn ich es selbst noch nie ausprobiert habe, die Erstellung einer Engine ist alles andere als einfach. Sie bestimmt das Aussehen, die Anpassungsfähigkeit, die Geschwindigkeit und noch viele weitere Eigenschaften. Die Erstellung eines Themas dagegen, welches auf einer bestimmten Engine aufbaut, ist nicht besonders schwierig. Allerdings kann ein Thema nur im Rahmen der Grenzen der Engine entwickelt, bzw. gestaltet werden. Diese Grenzen sind meistens sehr eng, sodass außer der Farbwahl bzw. kleinerer Anpassungen nicht sehr viel Raum für kreative Ideen bleibt.

Die kommende Version von Ubuntu, Intrepid Ibex, soll übrigens von einer Clearlooks-basierenden Engine als Grundlage des Designs zu einer Murrine-basierenden wechseln. Murrine ist wohl eine der beliebtesten Engines. Entwickelt von Cimi, einem italienischen Programmierer, unterstützt sie zum Beispiel in der aktuellen Entwicklerversion echtes RGBA.


English text below:

Am letzten Freitag im Juli ist alljährlich der Sysadminday.

An diesem Tag soll mal den Leuten hinter den Kulissen gedankt werden, die es möglich machen, dass Mails verschickt werden können, Webserver laufen, ...

Von Geschenken möchte ich gar nicht reden, aber vielleicht könnt Ihr User einmal die Gelegenheit nutzen, den Menschen, die Euch das Arbeiten oder das Internet oder den Zugang zum Internet ermöglichen, einfach "Danke" zu sagen.

Wer sich unter dem Beruf gar nichts vorstellen kann, sollte mal einen Blick in die Wikipedia werfen.

Every year on the last friday of July, we celebrate Sysadminday.

On this day we should thank all people behind the scenes who make it possible to send mails, to look at web pages, ...

I do not want to talk about giving gifts, but take the chance to say "Thank you" to the people who give you the opportunity to work, to use the internet or to get access to the internet.

Who does not have a clue about the job should take a look at the wikipedia article.

Ein Kommentar von „Serengeti“ zu unserem neuen Design hat mich neugierig gemacht. Wie gestaltet man selbst die Buttons, Auswahlboxen etc. für Gnome? Ist das wirklich so schwierig? Ein erster Blick hinter die Kulissen zeigt mir, dass es sooo schwierig nicht sein kann, nur etwas umständlich. Alles, was man auf dem Desktop sieht, besteht aus vielen kleinen Dateien, die auch noch in unterschiedlichen Ordnern zu finden sind. Ebenso sind die zugehörigen Konfigurationen über verschiedene Dateien verteilt.

Ich habe im Moment so gut wie „Null Ahnung“ und weiß auch noch nicht, auf was ich mich hier einlasse :cool: ,  werde mich aber intensiver mit diesem Thema beschäftigen und in loser Folge (je nachdem, wie es meine Zeit erlaubt) darüber berichten.

So, und das habe ich bisher herausgefunden:

  • Alle Theme-Dateien aus der Grundinstallation befinden sich im Ordner usr/share/themes.
  • Eigene oder heruntergeladene Themedateien kann man im (versteckten) Homeordner .themes ablegen und werden mit in die Auswahl eingebunden.
  • Die Themes verwaltet man über das Tool Erscheinungsbild im Menü System → Einstellungen.
  • Alle Dateien für das Erscheinungsbild der Buttons, Slider, Auswahlboxen, Optionsfelder etc. befinden sich (innerhalb eines Themeordners) in dem Ordner gtk-2.0!
  • Alle Dateien, die für das Aussehen der Fenster zuständig sind, befinden sich ebenfalls in einem eigenen Ordner (innerhalb eines Themeordners). Dieser Ordner heißt metacity-1!
  • Der Name des Themeordners wird zur Auswahl angezeigt.

Puh, kleine Pause! ;-)
Das ist alles ein wenig verwirrend. Weil man ja flexibel sein will und z.B. die Fensterrahmen von „Human“ (metacity-1) mit den Fensterinhalten von „Crux“ (gtk-2.0) frei kombinieren kann. Außerdem hat man die (begrenzte) Möglichkeit, diverse Farben über das Tool → Erscheinungsbild einzustellen. Symbole und Mauszeiger kann man ebenfalls einstellen, das interessiert jetzt aber weniger.

  • Das komplette Aussehen eines Desktops wird in ini-Dateien gespeichert. Wenn man nun im Tool –>Erscheinungsbild ein Theme angepasst hat, kann man dieses unter einem eigenen Namen speichern. Im Ordner .themes wird daraufhin ein Ordner mit diesem Namen angelegt und dieser wiederum enthält besagte ini-Datei.
  • Da ich zuerst die Buttons ändern will, ist es die erste Aufgabe, die Datei gtkrc im Ordner gtk-2.0 zu studieren und zu versuchen, die Syntax zu verstehen.
  • Wie mache ich das? Nach dem „Try and Error“ – Prinzip, also zu gut deutsch: „Probieren, testen und aus Fehlern lernen…“ ;-)
  • Dazu nehme ich mir das Theme Cillop-Go von Emrah Ünal als Vorlage und spiele mit den Einstellungen.
  • Bei Fragen schaue ich ins GTK Theming Tutorial (ist leider englisch, kennt jemand ein deutsches Tutorial?)
  • Und um zu testen, installierte ich mir The Widget Factory, damit kann man schnell und einfach GTK+ GUI’s ansehen. (ist in den Ubuntu-Quellen enthalten. In Synaptic einfach mal nach „widget factory“ suchen).

Ok, soviel für heute. Wer Ideen, Wünsche, Hinweise, Linktipps hat oder Fehler findet… hinterlasst doch bitte einen Kommentar, alles ist herzlich Willkommen!

24. Juli 2008

In letzer Zeit, wahrscheinlich in Verbindung mit der Veröffentlichung von Inyoka, lese ich immer häufiger Beiträge, welche das Team von ubuntuusers.de kritisieren. Nun ist ja Kritik im Prinzip nichts Schlechtes, vorausgesetzt sie verfolgt den Sinn von Verbesserung am Bestehenden und wird in der richtigen Form vorgebracht.

Häufig sieht Kritik aber anders aus. Kritik ist destruktiv und keinesfalls zielführend, sondern verfolgt lediglich das Ziel der Niedermachung oder dem Ablass von Frust. Ein sehr gutes Beispiel dafür, ist ein neuerer Beitrag eines Forumnutzers. Er ist der Meinung, dass die neue Forensoftware sehr fehlerbehaftet sei und dass die Entwickler es nicht ausführlich genug mit anderen Browsern als Mozilla Firefox, dem Standardbrowser unter Ubuntu, getestet hätten.

Nunja, dass die Software 100%-ig fehlerfrei ist, hat auch niemand behauptet. Ich finde es auch zulässig, dass ein so großes Projekt wie es Inyoka ist, nicht vom Start weg perfekt funktionieren muss. Es wird immer noch daran gearbeitet und irgendwann wird es auch ziemlich fehlerfrei sein, dieser Meinung bin ich, denn die freiwilligen (!) Entwickler leisten tolle Arbeit.

Ich antwortete auf den Beitrag eines Nutzers und sagte, dass der monatelange Beta-Test dazu da war, auftretende Probleme zu melden, sodass Inyoka bei der Veröffentlichung auch wirklich ordentlich funktionsfähig ist. Wie erwartet, hatte der Forumnutzer Inyoka nicht im Voraus getestet, geschweigedenn Fehler gemeldet. Auf meine Aussage hin, dass er sich nun nicht groß beim Team von ubuntuusers beschwerden kann, da er die Entwickler ja weder bezahlt, noch einen kleinen Beitrag – z. B. Bug-Reports – am Projekt geleistet hat, reagierte er hitzig, ja beinahe aufgebracht. Das Testen des Forums sei Sache der Entwickler und nicht die der Benutzer. Meiner Meinung nach ist das Prinzip von OpenSource bzw. einer funktionierenden Gemeinschaft noch nicht bei ihm angekommen.

Persönlich finde ich es sehr dreist, was der Benutzer für Ansprüche stellt, aber nicht bereit ist etwas dafür zu tun. Meinerseits habe ich zahlreiche Fehler an Inyoka gemeldet, das Team hat mir praktisch zu jeder Meldung eine Rückantwort gegeben und die Fehler wurden behoben – alle. Dass sich das Team wirklich gründlich um die Fehlermeldungen gekümmert hat, fand ich persönlich vorbildlich. Ich musste nie wirklich lange auf eine Rückmeldung warten und es wurden auch kleine, nicht sonderlich kritische Schönheitsfehler behoben. Außerdem läuft das Portal, im Verhältnis zur relativ kurzen Entwicklungsdauer und zur Komplexität des Projektes ziemlich rund. Man merkt keinesfalls, dass es sich beim Team um ein Heer von Freiwilligen und nicht um bezahlte Programmierer handelt. Das Portal wirkt von A bis Z professionell und falls die Entwicklung das aktuelle Tempo beibehält, werden auch die letzten kleinen Fehler behoben werden.