Ich bin momentan am ueberlegen fuer ein paar eigene (Test-)Projekte ein Versionsverwaltungssystem einzusetzen um Aenderungen am Code besser nachvollziehen zu koennen.
Prinzipiell wuerde eine lokale Variante reichen. Spaeter vielleicht auch etwas, bei dem ich ueber das Netz zugreifen kann? Wie sehen da die Erfahrungen meiner Leserschaft aus? SVN, Git, Mercurial oder doch was ganz anderes?

Nach Fedora und Slackware habe ich eine relativ lange Zeit Arch Linux auf dem Notebook genutzt. Mittlerweile ist auf dem Desktop Gentoo als weitere Distribution dazu gekommen.Nun bin ich auf die Idee gekommen, diese beiden Distributionen zu vergleichen. Allerdings muss ich anmerken, dass dies ein rein subjektiver Vergleich ist und ich hier keinerlei Flamewars ausloesen will. Die genannten Vor- und Nachteile beziehen sich rein auf meine Vorstellungen von einem guten System und sollten daher nicht missverstanden werden.

Installation:

Gentoo laesst sich sowohl aus einer bestehenden Installation heraus als auch von einer Live-CD installieren. Es gibt auf der letzteren auch einen grafischen und einen textbasierten Installer. Allerdings hat keiner der beiden bei mir zufriedenstellend funktioniert. Daher habe ich mich fuer die manuelle Installation entschieden.

Dank des sehr ausfuerlichen Gentoo-Handbuchs hat dies aber kein Problem dargestellt. Den einen oder anderen Kniff lernt man auch dabei und man ist wirklich flexibel in seiner Konfiguration. Allerdings gibt es die eine oder andere Huerde wie z.B. wenn das Root-Device auf einem LVM liegt und die Initrd per default keine LVM-Unterstuetzung mitbringt.

Fuer Einsteiger halte ich die Installation nur bedingt empfehlenswert, da sie eben nicht wirklich intuitiv zu handhaben ist. Als Installationsmedium kam bei mir die Gentoo-Live-DVD zum Einsatz, ich habe spaeter aber fast alle Pakete aus dem Netz geladen. Somit brachte der groessere Umfang der DVD keinen Vorteil.

Fuer die Netzanbindung, sorgte ein Notebook, dass ich per Crossover-Kabel mit dem PC verbunden hatte. Es hat als kleiner Router gedient, da auf der DVD keine passenden Treiber fuer die WLAN-Karte vorhanden waren.

Die Installation braucht Zeit. Am besten man nimmt sich das Ganze an einem freien Tag oder einer schlaflosen Nacht vor. Ohne die noetige Routine dauert die Vorbereitung des Systems schon etwas. Das Kompilieren des kompletten Systems dauert, je nachdem was der Rechenknecht unter der Haube hat und welchen Umfang die installierte Software hat, zwischen ein paar Stunden und mehreren Tagen. Dies ist mir definitiv zu lange. So lange das System laeuft, gibt es kein Problem, aber wenn mir mal die Platte abrauchen sollte, waere ich schwer am ueberlegen, ob es wieder Gentoo sein muss. Aus Platzgruenden sichere ich naemlich nur Nutzdaten und nicht das komplette System. Auf jeden Fall wuerde ich mir ein Script schreiben, das mir die Konfiguration automatisiert und eine unbeaufsichtigte Installation ermoeglicht.Viel wahrscheinlicher ist jedoch, dass ich ein komplett neues System mit Arch Linux aufsetzen wuerde.

Bei Arch Linux habe ich mich fuer eine FTP-Installation entschieden, da man nur mit dieser die Moeglichkeit hat ohne grosses Frickeln ein verschluesseltes Root-Device zu erstellen, das spaeter beim Booten auch korrekt funktioniert. Nach dem Download der Installations-CD, startet ein Textbasierter Installer, der einem die noetigste Arbeit abnimmt. Die CDs sind zwischen 12 und 530MB gross und sollten somit den wenigsten Probleme bereiten.

Der Installer ist aufgeraeumt, setzt aber vom User ebenfalls einige Kenntnisse voraus. So muss man seine Festplatten manuell auf der Shell partitionieren, seine Konfigurationsdateien mit einem Editor seiner Wahl editieren und z.B. fuer ein verschluesseltes Root-Device die Konfigurationsdatei, mit der spaeter die Initrd erstellt wird, abaendern.

Obwohl meine letzte Installation schon ein paar Monate zurueck liegt, ging das ganze schnell von der Hand. In knapp 20min hatte ich das Basis-System installiert. Ich habe mir dann nach ein paar Tagen aus Unachtsamkeit die Partiionstabelle kaputt gemacht. Beim 2. Anlauf war die Konfiguration in 10min durch. Dazu muss man sagen, dass ich nur ueber eine DSL-1000 Anbindung verfuege und ich die kompletten Pakete aus dem Netz gezogen habe. Mit mehr verfuegbarer Bandbreite, waere das ganze noch schneller gegangen.

Die Verwendung von LVM und dm-crypt haben hier fast keine Probleme verursacht. Es war notwendig Zeile in der /etc/mkinitcpio.conf zu aendern. Der Rest lief dann von alleine.

Nach der Installation des Basissystems habe ich dann nach und nach die benoetigte Software installiert. Diese haette ich auch schon bei der Installation auswaehlen koennen, aber ich finde es besser die Pakete schrittweise zu installieren, weil ich nebenher schon am laufenden System schrauben kann.

Alles in allem ist die Installation deutlich staerker automatisiert als bei Gentoo ohne Installer. Durch die Binaerpakete, die man nicht extra kompilieren muss, spart man auch jede Menge Zeit.

Ressourcenverbrauch:

Hier schneidet Gentoo relativ schlecht ab. Das laufende System verbraucht zwar nicht mehr CPU-Zeit oder Arbeitsspeicher als ein vergleichbares mit einer anderen Distribution aber die Quelltexte zum kompilieren brauchen einige Gigabyte an Festplattenplatz und das Kompilieren jedes einzelnen Pakets kostet massig Leistung. Es ist, zumindest mit einer Dualcore-CPU, moeglich nebenher auf dem System zu arbeiten aber so richtig Spass macht es doch nicht wenn bei jedem Update alle neuen Pakete lokal kompiliert werden muessen. Ich persoenlich merke auch keinen spuerbaren Performance-Zuwachs durch das lokale Kompilieren der Pakete. Somit waere der einzige Vorteil dieser Technik, dass man Pakete sehr viel genauer anpassen kann als bei anderen Distributionen.

Bei Arch verbraucht sowohl das System mit den sauber vorkonfigurierten Paketen als auch der Betrieb selbst nicht besonders viele Systemressourcen. Das System ist sowohl performant als auch schlank und ueberzeugt damit. Da Einfachheit und Schlankheit unter anderem Grundzuege der Philosophie des "Arch Way" sind, kann Arch hier definitiv punkten.

Paketmanagement:

Die imho wichtigste Eigenschaft einer guten Linuxdistribution ist ein gutes und durchdachtes Paketmanagement. Bei Gentoo ist dieses, wie schon gesagt, fast komplett Quellcode basiert. Das Paketmanagement nennt sich Portage. Zu jedem Paket wird der Quellcode geladen, lokal entpackt und kompiliert. Zusaetzlich kann man durch das System der USE-Flags die Pakete auf seine persoenlichen Beduerfnisse anpassen. Es ist so z.B. moeglich die KDE-Unterstuetzung bestimmter Software nicht mit zu kompilieren, wenn man ohnehin nur Gnome einsetzt. Das macht das System sehr anpassbar.

Das Angebot an Paketen ist riesig. Es gibt fast nichts was es nicht gibt und ausser dem offiziellen Paketen gibt es auch noch Overlays. Es ist Problemlos moeglich sogar Spiele wie z.B. Quake IV und Addons dazu ueber das Paketmanagement zu installieren und aktuell zu halten. Selbstverstaendlich benoetigt man fuer kommerzielle Spiele die orginal CDs/DVDs und einen original Key. Allerdings nimmt einem das Paketmangement z.B. das Kopieren von notwendigen Daten der Spiele-CD ab. Diese Funktionalitaet passt bestimmt einigen Leuten nicht, macht das System aber auch attraktiv fuer Menschen, die auch unter Linux spielen und nicht jedes Spiel manuell installieren und aktuell halten wollen.

Mit ein paar Kniffen laesst sich auch das Portage System beschleunigen, so dass es weniger negativ ins Gewicht faellt.

Arch besitzt, wie Gentoo mit dem Portage-System, ein eigenes Paketmangement und baut weder auf RPM noch auf APT auf. Das ganze nennt sich "pacman". Das kommt von "package manger" und nicht von dem Spiel.

Pacman arbeitet flott, ist gut konfigurierbar und die Pakete sind in gut vorkonfigurierter Form vorhanden. So lange es sich nicht um wenig bekannte oder Nischensoftware handelt, kann man davon ausgehen, dass ein Paket vorhanden ist. Bei Bedarf ist es zudem problemlos moeglich Pakete mittels ABS selbst zu bauen. ABS selbst ist wie Portage auch ein Paketsystem, das sich ebenfalls an den BSD-Ports orientiert. Und sollte es Pakete geben, die nicht im reichhaltigen Repository zur Verfuegung stehen, so bekommt man diese mit hoher Wahrscheinlichkeit im Arch User Repository.

Auch bei Arch ist die Liste der verfuegbaren Software lang. Allerdings nicht so lang wie bei Gentoo.

Die verfuegbare Software ist aber oft aktueller als bei Gentoo. Ich habe schon erlebt, dass bestimmte Software schon einen Tag nach dem Release als Paket verfuegbar war. Eigentlich wuerde ich behaupten, dass man die Pakete in so kurzer Zeit gar nicht vernuenftig testen kann, aber mir ist bisher nichts negatives in dieser Hinsicht aufgefallen.

Im Gegensatz zu einigen anderern Binaerdistributionen sind die kompletten Pakete auf die i686 Prozessorarchitektur opimiert und nutzen somit mehr Funktionen moderner Prozessoren als andere Distributionen.

Anmerkung

Dieser Artikel lag hier ueber ein Jahr als Entwurf im System und sollte eigentlich ausfuehrlicher werden. Allerdings habe ich wegen Hardwareproblemen meinen Desktop ein paar Monate nicht nutzen koennen und darauf hin Arch installiert. Da ich mich seit dem nicht mehr mit Gentoo beschaeftigt habe waere es unfair gewesen mich bei weiteren Vergleichen auf eine Gentoo-Installation zu beziehen, die schon ueber ein Jah zurueck liegt.

Mittlerweile nutze ich auf meinem Notebook und dem Desktop nur noch Arch Linux, auf dem Router OpenWRT und auf dem Server Debian. Momentan bin ich mit diesem Setup wunschlos gluecklich. Vielleicht werde ich eines Tages nochmal auf Gentoo zurueck kommen, aber das habe ich momentan nicht vor. Momentan wuerde ich eher FreeBSD statt Gentoo nutzen.

Heute bin ich nun zum Entschluss gekommen diesen Artikel mit ein paar Korrekturen abzuschicken und teils unfertig ins Blog zu entlassen, da ich wahrscheinlich nicht dazu kommen wuerde ihn in dem Umfang zu vollenden in dem er geplant war. Ich hoffe, dass der eine oder andere trotzdem damit etwas anfangen kann.

Anmerkung Nr. 2

Der Artikel wurde am 19.04.2009 nochmals ueberarbeitet. Es wurden keine inhaltlichen Aenderungen vorgenommen sondern hauptsaechlich die Formatierung ans neue CMS angepasst sowie Rechtschreibfehler entfernt und Formulierungen ueberarbeitet.

Nach ein paar Monaten Testbetrieb meines Jabberservers bin ich nun der Meinung, dass ich jabber.roothausen.de auch fuer andere zugaenglich machen kann.
Hier ein paar Details:

• es laeuft ejabberd
• erreichbar ist das Ganze unter jabber.roothausen.de auf den Ports 5222/5223
• TLS/SSL ist ueber ein Zertifikat von CAcert realisiert

Falls noch jemand einen Jabberserver sucht, kann er/sie sich mit einem der gaengigen Clients einen Account registrieren.
Ich bin somit auch per pfleidi [at] jabber.roothausen.de erreichbar.

Linus Torvalds hat Probleme mit Flash:

This is "high" priority because the wife will kill me if she doesn't have her videos. And the adobe player won't install on current rawhide due to some library issues.

Gerade mein Prof fuer Betriebssysteme:

Windows ist Playmobil und UNIX ist Lego.

Kann man immer mal gebrauchen.

Der imho coolste Feedreader wurde in Version 0.8 veroeffentlicht.
Das Changelog sieht schon mal vielversprechend aus:

0.8 (2008-03-07): implemented custom configurability of feed list and article list format improved reload speed by checking the Last-Modified header added special tags to rename feeds added macro support added Ruby scripting support directly integrated nxml/mrss code since API and ABI are a moving target

Mir ist gerade das Tool iperf aufgefallen, mit dem man sehr komfortabel seinen Datendruchsatz messen kann. Und das sowohl fuer rohe TCP oder UDP-Pakete:

Auf einem PC (oder wie bei mir auf dem Router) laesst man den Server laufen:

root@flynet:~# iperf -su
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:   106 KByte (default)
------------------------------------------------------------

Danach kann man mit einem anderen Rechner den Durchsatz testen:

In diesem Fall werden UDP-Pakete uebertragen. Ohne die Option -u bei Server und Client waeren es TCP-Pakete. Wichtig ist auch die Option -b, da sonst die Bandbreite auf 1MBit/s begrenzt ist.

Zum Schluss sieht man dann so etwas:

[  3] local 192.168.13.23 port 33010 connected with 192.168.13.1 port 5001
[  3]  0.0-60.0 sec    200 MBytes  28.0 Mbits/sec
[  3] Sent 142996 datagrams
[  3] Server Report:
[  3]  0.0-60.0 sec    200 MBytes  28.0 Mbits/sec  1.305 ms   13/142996 (0.0091%)

Hier sieht man auch erst mal, was von den brutto 54MBit/s bei WLAN uebrig bleibt.

Die tollste Live-Distribution der Welt ist nun in der finalen Version 1.1 verfuegbar.
Was grml genau ist erkaert Wikipedia ganz gut:

grml (sprich: grummel) ist eine auf Debian/unstable basierende Linux-Distribution, die sich als Live-CD direkt von einer CD/DVD starten lässt. Sie wurde als kleines Rettungssystem mit flexiblem Startprozess entworfen. Ursprünglich auf Knoppix basierend, hat sich grml inzwischen zu einem eigenen Debian-Derivat weiterentwickelt.

Wenn man ohne Desktopumgebung unterwegs ist und mal schnell die Aufloesung aendern moechte, hilft der Befehl xrandr:

xrandr -s 1280x1024

Wie ich schon des oefteren berichtet habe, nutze ich das Arch User Repository, kurz AUR recht ausgiebig. Es ist unter anderem auch einer der Gruende, wesshalb ich Arch Linux so mag: Man bekommt einfach jegliche Software ohne dass man, wie bei anderen Distros, total umstaendlich Pakete erstellen oder von Hand pflegen muss.
Heute bin ich auf zwei Pakete gestossen, die einem das Arbeiten mit dem Packetmanager pacman und AUR sehr erleichtern.
Beim einen handelt es sich um yaourt. Dies ist ein Shellscript, welches als Frontend fuer pacman, das unter anderem farbige Ausgaben liefert, nicht benoetigte Pakete entdeckt und auch zum einfachen installieren und aktualisieren von AUR genutzt werden kann. Fuer alle Arch-User: Schaut es euch an. Es lohnt sich.
Das zweite Tool ist aurvote mit dem man fuer bestimmte Pakete waehlen kann, damit diese in das Comminty-Repository kommen.

Eigentlich ist das OpenSync-Projekt ja eine tolle Sache, deren Konzept ich toll finde. Grundlegend schaut es so aus, dass man eine Bibliothek, die so genannte libopensync, benoetigt. Darauf aufbauend kann man sich dann Plugins zur Synchronisation wie z.B. fuer Sunbird, Evolution, SyncML etc. installieren. Angesprochen wird das ganze dann entweder ueber eine grafische Oberflaeche oder ein Shellprogramm.

Allerdings ist das Projekt noch recht jung und das merkt man. Ich habe nun bisher 3 Versuche gestartet die Software auf meinem Notebook unter Arch Linux zum Laufen zu bringen. Geplant war eine Synchronisation des Kalenders meines Mobiltelefons mit einem WebDAV-Share auf dem eine iCal-Datei liegt.

Installation:

Versuch 1

Installieren der libopensync mittels pacman und dann Kompilieren der Plugins mit PKGBUILDs aus dem Arch User Repository. Hier sind die Versionen des SyncML- und Sunbird-Plugins aus AUR allerdings inkompatibel zur Version 0.36 die pacman installiert hat. Also das war schonmal nichts.

Versuch 2:

Installation ueber modifizierte PKGBUILDs, die sich die Sourcen aus dem Subversion-Repository holen. Ergebnis: Libopensync, das SyncML-Plugin und das File-Plugin kompilieren. Leider ist im Subversion-Repository kein aktuelles Sunbird-Plugin enthalten und das Shellprogramm erkennt das Fileplugin nicht. Somit war nichtmal ein Synchronisationstest moeglich.

Versuch 3:

Nun habe ich probiert mir meine PKGBUILDs so umgebaut, dass fuer alle notwendigen Pakete eine aeltere Version (0.22) verwendet wird. Ergebnis: Alles notwendige kompiliert korrekt, nur das absolut notwendige SyncML-Plugin nicht. Anscheinend hatte das Plugin Probleme mit der Version 0.4.6 der libsyncml, die ich installiert hatte. Nach einem Downgrade auf 0.4.5 kompiliert das Paket sauber durch. Auch das Kompilieren der Version 0.22 des Shellprogramms msynctool funktioniert. Ist doch zumindest mal was.

Vorbereitungen:

Also mal kucken, ob auch alle Plugins erkannt werden:

Konfiguration :

Nach diesem Krampf bin ich, wie in diesem Howto beschrieben, vorgegangen. Zuerst wird ein Profil zum Backup der Daten, die auf dem Handy liegen, angelegt:

Danach sollte man bluetooth starten. Bei meinem Thinkpad erledigt dies das folgende Script, dass ueber eine Tastenkombination gestartet wird:

Nun mal kucken, ob das Handy gefunden wird:

 hcitool scan
Scanning ...
    00:11:XX:XX:XX:XX  WolleRosekaufe?

Bei 00:11:XX:XX:XX:XX handelt es sich um die Bluetoothadresse des Handys diese hier wurde annonymisiert.

Anschliessend kann man mit spdtool ein paar Informationen ueber das Telefon ergattern. Eine Eingabe von "sdptool browse 00:11:XX:XX:XX:XX " sollte unter anderem etwas in der Art liefern:

Service Name: SyncMLClient
Service RecHandle: 0x1000b
Service Class ID List:
  UUID 128: 00000002-0000-1000-8000-0002ee000002
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 11
  "OBEX" (0x0008)

Konfiguration des Datei-Plugins:

Startet man nun mit "msynctool --configure filenokia 1" die Konfiguration, kann man eine XML-Datei mit Hilfe von vi(m) editieren. Diese sollte folgenden Inhalt haben:

Konfiguration des SyncML-Plugins:

Ist dies erledigt, kann der SyncML-Client mit "msynctool --configure filenokia 2" konfiguriert werden:

Validieren laesst sich das Ganze mit "msynctool --showgroup filenokia".

Achtung: Da es unter Umstaenden zu Datenverlust kommen kann, sollte man seine Kontakte und wichtige Daten zuvor auf eine Speicherkarte sichern, damit man die im Falle eines Fehlers wieder herstellen kann.

Synchronisation:

Der eigentliche Sync-Vorgang laesst sich mit "msynctool --sync filenokia" anstossen. Mit dieser Konfiguration laesst sich nun das Adressbuch etc. als Backup auf die Festplatte synchronisieren. Bei mir hat super funktioniert.

Thunderbird/Sunbird/WebDAV-Kalender:

Synchronisation in einzelne Dateien ist ja ganz ok, aber eigentlich will man ja auch mit den Dateien arbeiten und zumindest seinen Kalender auf das Handy uebertragen. Hierfuer nutze ich das Sunbird-Plugin. Um dieses zu nutzen, legt man zuerst ein neues Profil an:

Nun kann man man wieder heraus finden, welches Plugin unter welchem Punkt zu konfigurieren ist:

msynctool --showgroup nokiasun 
Groupname: nokiasun
Member 2: sunbird-sync
    No Configuration found: Member has not been configured
Member 1: syncml-obex-client
    No Configuration found: Member has not been configured

Konfiguration des SyncML-Plugins:

Bei der Konfiguration mit "msynctool --configure nokiasun 1" kann der selbe Eintrag wie weiter oben beim SyncML-Plugin verwendet werden:

Konfiguration des Sunbird-Plugins:

Hier fuehrt man "msynctool --configure nokiasun 2" aus und traegt seinen WebDAV-Share samt Zugangsdaten ein. Da das Passwort im Klartext vorliegt, sollte man ~/.opensync eventuell speziell sichern, damit kein anderer Benutzer des Rechners Zugriff darauf erhaellt. Da meine Festplatte sowieso verschluesselt ist, werde ich darauf nicht weiter eingehen.

Hier kann man nun auch mit "msynctool --sync nokiasun" die Synchronisation starten.

Fazit:

Das beschriebene Setup funktioniert zwar prinzipiell aber man merkt stark, dass OpenSync noch stark weiterentwickelt werden muss. Die von mir verwendete Version ist auch nicht mehr die neuste aber leider funktioniert das Sunbird-Plugin bei anderen nicht. Das Synchronisieren sollte zwar prinzipiell moeglich sein, doch haengt der Vorgang bei einer direkten Synchronisation sehr oft. Ich habe bessere Ergebnisse erzielt als ich eine dritte Gruppe bestehend aus dem File-Plugin aus der ersten Gruppe und dem Sunbird-Plugin der zweiten Gruppe angelegt habe. Die Synchronisation ueber den Umweg WebDAV <=> File <=> Handy funktioniert, im Gegensatz zum direkten Abgleich, meistens.

Aufgetretene Fehler:

• haengenbleiben von msynctool waehrend der Synchronisation
• Probleme bei Eintraegen die sich wiederholen
• Probleme bei vielen Eintraegen im Kalender (ausmisten des Kalenders erforderlich)
• teilweise treten Terminkonflikte auf wo gar keine sind

Was noch nicht geht:

• Synchronisieren des Adressbuchs
• Synchronisieren der Todo-Liste aus Lightning
• problemloses synchronisieren

Alles in allem, bin ich nun froh ueberhaupt eine Moeglichkeit zu haben ab und zu den Kalender abzugleichen. Nun habe ich wenigstens wichtige Geburts- und Feiertage im Handy gespeichert. So wie ich gehoert habe, ist die aktuelle Version 0.3X sowieso nur fuer Entwickler gedacht und laut der Opensync-Website wird momentan stark an Version 0.40 gearbeitet. Darum bin ich noch der Hoffnung, dass sich dieses Projekt in absehbarer Zeit wirklich benutztbar wird und ohne grosses Frickeln installiert werden kann. Bis dahin bin ich zumindest mit der bisherigen Loesung zufrieden.

Weiterfuehrende Links:

• http://blog.dukanovic.com/?p=5
• http://opensync.org/
• http://wiki.ubuntuusers.de/OpenSync/Plugin-Sunbird

Gerade bin ich auf ein Tool gestossen, mit dem man sehr schoen beliebige Programme auf Linux fernsteuern kann. Es hoert auf den Namen anyremote.
Fuer das fernsteuern benoetigt man ein Geraet, dass man per Bluetooth oder Infrarot ansprechen kann und am PC einen Empfaenger. In meinem Fall dient als "Fernbedienung" mein Mobiltelefon, ein in die Jahre gekommenes Nokia 6630 und der eingebaute Bluetooth-Chip meines Thinkpads. Demnaechst werde ich das Ganze noch auf meinem Desktop mit einem D-Link Stick testen.
Ich habe mit die Software mit Hilfe des PKGBUILDs aus dem AUR kompiliert und installiert. Fuer andere Distributionen als Arch Linux gibt es vielleicht vorgefertigte Pakete oder man muss sich das Programm selbst kompilieren. Fuer Handys mit Java-Runtime gibt es dann das Programm zum download.
Ist die Software sowohl auf dem PC als auch auf dem Handy installiert, kann man bei beiden Bluetooth einschalten. Ueberpruefen, ob das Handy in Reichweite ist, kann man mit "hcitool scan". Bei meinem Bluetooth-Stick musste ich diesen noch mit "hciconfig -a hci0 up" aktivieren.
Wenn das alles funktioniert hat, kann man als User z.B. mit
anyremote -f /usr/share/anyremote/cfg-data/Server-mode/xine.cfg
den anyremote-Server fuer xine starten. Nun kann man, nach dem Verbinden, mit der Java-Software auf dem Handy grundlegende Funtkionen wie laut/leise, Pause, Vollbild etc. vom Handy aus steuern. Wichtig ist allerdings im Falle xine, dass xine mit der Option "-n" im Netzwerkmodus gestartet wird. Sonst funktionieren die xine-remote Kommandos nicht, die anyremote nutzt.
Ausser xine gibt es noch genug andere vorgefertigte Konfigurationen, die man nutzen kann wie zum Beispiel fuer Amarok, Xmms, Kmplayer, Rythmbox, MythTV etc.
Ich werde das Tool in Zukunft jedenfalls oefter nutzen.

Obwohl sich netcfg2 von ArchLinux noch im Teststadium befindet, habe setze ich es schon seit mehreren Monaten erfolgreich ein.
Ein wirklich cooles Feature ist die Moeglichkeit beim Start automatisch das WLAN-Profil, das gerade in Reichweite ist, zu starten. Hierzu richtet man in /etc/network.d/ die gewuenschten Profile ein. Um das Feature beim Systemstart zu starten, traegt man folgendes in die /etc/rc.conf ein:

# Network profiles are found in /etc/network.d/ NETWORKS=(auto-wireless eth1)

eth1 sollte durch das entsprechende WLAN-Interface ersetzt werden.
Bei mir laeuft so ein Setup seit ein paar Wochen sehr erfolgreich. Ob ich nun zu Hause, bei Freunden oder an der FH bin, immer wird das richtige Profil geladen.
Bei Bedarf lassen sich so auch noch automatisch Dienste wie OpenVPN etc. starten.