Diese Seite sollte eigentlich nur eine kleine Gehirnstütze für mich selbst werden, wurde dann aber doch etwas umfangreicher, sodass ich sie auch auf uninformativ.de verlinkt habe. Aufgrund des ursprünglichen "Merkzettel-Charakters" ist aber nicht wirklich viel in richtiger "Tutorial-Form" geschrieben und wahrscheinlich auch einfach viel zu ungenau erklärt dafür. Man möge mir das verzeihen, vielleicht findet der ein oder andere ja trotzdem etwas Hilfreiches hier. :)
Ausgeliefert wurde das Notebook natürlich anfangs mit Windows XP und lief dort auch (nachdem die Kiste vom üblichen Schund befreit wurde - vorher kam es sogar zu regelmäßigen Abstürzen und Herunterfahren ließ sich der Rechner auch nicht!) ziemlich gut eigentlich. Da ich den Laptop aber sehr häufig in der Uni im public-WLAN betreibe, hatte ich kein wirklich gutes Gefühl bei der Sache. Das Tutorial auf meiner Seite zur Absicherung von Windows XP entstand während einem Versuch, alle unnötigen Ports in ebendiesem System zu schließen.
Die Nebeneffekte (kein Zugriff mehr auf SMB-Shares z.B.) und die Tatsache, dass dennoch hin und wieder scheinbar aus dem Nichts Sockets auftauchten, die auf allen Interfaces horchten, sowie ein allgemeines Gefühl des Kontrollverlustes, führten mich dann letztendes dazu, Linux auf die Kiste zu knallen. Bereits kurz nach Erwerb des Books versuchte ich es kurz mit Fedora Core 5, was aber keinen richtigen Erfolg brachte - vorallem WLAN funktionierte nicht. FC5 überlebte also nicht besonders lange.
Ungefähr ein Jahr später dann machte mich ein Freund auf einen Erfahrungsbericht auf Suzans Seite aufmerksam. Siehe da, fast mein Notebook! Die Entscheidung stand fest, ich kaufte mir eine zweite Festplatte (wollte XP wegen der schlechten Erfahrungen mit FC5 nicht gleich ganz opfern und Umpartitionieren war wegen einer angeknacksten Partitionstabelle (...) nicht drin.) und legte los mit Ubuntu Feist Fawn.
Natürlich besteht ob der Existenz von Suzans Bericht eine gewisse Redundanz, auch bin ich im Sinne einer "Veröffentlichung" verdammt spät dran. Ich habe mich jedoch ein stärker auf die Dinge konzentriert, die nicht sofort Out-Of-The-Box gingen (auch wenn es meist nur kleine Korrekturen waren) und es sollte ja, wie gesagt, eine Hilfe für mich selbst sein. Davon abgesehen gibt es ein paar Hardware-Unterschiede und natürlich hat jeder so seine eigenen Schwerpunkte.
Schlussendlich bleibt leider noch eines zu sagen: Feisty habe ich bereits einige Zeit vor diesem "Guide" installiert. Deswegen ist dieses und jenes Detail leider in Vergessenheit geraten. Sobald es mir wieder über den Weg läuft, wird es aber sofort nachgetragen und für's nächste Mal gelobe ich Besserung. ;) Außerdem kann es sein, dass im Laufe der Zeit Updates eingespielt wurden, die Probleme der Urversion beseitigten, weswegen hier manches als "sofort lauffähig" tituliert wurde - denn nicht alles habe ich direkt nach der Installation so eingerichtet und dann für immer so gelassen. Manches ist neueren Datums und der ganze Bericht/Guide/whatever ist auch erst dann "fertig", wenn ich mich von Feisty Fawn verabschieden sollte. Ob das nun direkt zu Ubuntu 7.10 sein wird, ist noch offen.
Wie dem auch sei, bei Kritik, Ergänzungen oder was auch immer, würde
ich mich über eine kurze Response mittels der
uninformativ-Seite
sehr freuen. :)
Beginnen wir mal mit einer Bestandsaufnahme, was in meiner Kiste so alles drin ist:
Mein Epson AcuLaser C1100N lässt sich mittlerweile problemlos betreiben, die Einrichtung war aber relativ wirr und sehr fehlerbehaftet. Ich werde auch nicht mehr näher darauf eingehen, da zum Zeitpunkt einer erneuten Ubuntu-Installation sowieso Version 7.10 verfügbar sein dürfte, was einerseits eh wieder vieles ändert und zweitens eine neue Drucker-Einrichtung mitbringen soll.
In Feisty Fawn ist der mitgelieferte ATi-Treiber für den X-Server leider noch "verstümmelt" und so hat man nicht einmal mit der Live-CD eine grafische Ausgabe. Wenn man Glück hat, kommt man jedoch noch an die Console (STRG+ALT+F1) und kann das Problem folgendermaßen lösen:
sudo /etc/init.d/gdm stop sudo -s -H apt-get update apt-get upgrade apt-get install xorg-driver-fglrx sudo aticonfig --initial sudo /etc/init.d/gdm start
Danach sollte man ein GUI zur Verfügung haben und kann mit der Installation fortfahren. Eventuell ist derselbe Schritt noch einmal nach beendetem Setup nötig.
Um diese zu aktivieren, muss man ans Ende der /etc/X11/xorg.conf folgendes einfügen:
Section "Extensions"
Option "Composite" "Disable"
EndSection
Section "ServerFlags"
Option "AIGLX" "off"
EndSection
Die Hauptsache ist eigentlich, Composite abzuschalten - denn der ATi-Treiber kann unter Feisty noch kein Composite und Hardware-OGL gleichzeitig, das soll erst ab Ubuntu 7.10 funktionieren. Zur Folge hat das dann, dass man (ohne Umwege) kein Compiz/Beryl mehr nutzen kann.
Ob die Hardwarebeschleunigung funktioniert, erkennt man an der Ausgabe von
fglrxinfo
die etwa so aussehen müsste:
display: :0.0 screen: 0 OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: ATI Mobility Radeon X1300 OpenGL version string: 2.0.6334 (8.34.8)
Steht dort dagegen etwas von "Mesa OpenGL", dann ist keine Hardwarebeschleunigung aktiv!
Viel Strom lässt sich mit Powerplay sparen - jedoch nur, wenn der restricted ATi-Treiber geladen ist, d.h. nicht unter XGL!
Der Schlüssel zu Powerplay ist das Programm "aticonfig". Z.B. kann man sich mit
aticonfig --lsp
die verfügbaren Takt-/Spannungsmodi anzeigen lassen. Auswählen kann man den gewünschten dann z.B. mit
aticonfig --set-powerstate=1
Es macht auch Sinn, nach dem Anmelden in den Modus mit dem niedrigsten Verbrauch zu wechseln. Dazu trägt man unter einfach oben genannten Befehl ein. Von da an sollte beim Anmelden der Bildschirm einmal kurz beim Wechsel des Powerplay Modus' flackern.
Am einfachsten ist es, einen externen Monitor bereits beim Booten (evtl. genügt auch der Start des X-Servers, das hieße dann: X-Server mit STRG+ALT+BACKSPACE neu starten würde reichen) angeschlossen zu haben, dann nämlich kennt der X-Server bereits die möglichen Auflösungen dieses Bildschirms. Dann allerdings sind auch direkt beide Displays aktiviert, internes Notebook-Display und der externe Monitor.
Achtung: Mein Skript funktioniert mit XGL/Compiz nicht! Der Grund ist, dass "aticonfig" mit dem XGL-X-Server nicht richtig zusammenarbeitet.
Um nun zwischen beiden wechseln zu können, benötigt man zuerst einmal das Paket xrandr. Dieses wird dann mit oben genanntem "aticonfig" in folgendem Skript, welches man sich irgendwo hinspeichern kann, zusammenarbeiten:
#!/bin/bash
# Devices:
# crt1: externer Monitor
# lvds: Notebook-Display
# Auflösung in Hochkomma setzen und Leerzeichen beachten!
# Bspw.: "1280 x 800"
# Aufrufbeispiele:
# ./moni_switch crt1 "1280 x 1024"
# ./moni_switch lvds "1280 x 800"
# Optional kann als dritter Parameter die Refreshrate angegeben werden,
# welche aber NICHT ueberprueft wird!
DEV=$1
RES=$2
echo "Enabling Monitor: $DEV, Resolution: $RES"
echo ""
aticonfig --nobackup --enable-monitor=$DEV
NUM=`xrandr -q | egrep -e "$RES" | awk '{ printf("%s", substr($0, 2)); }' | cut -d " " -f1`
echo "$RES now at <$NUM>, switching ..."
echo ""
xrandr -s $NUM
if [ ! -z $3 ]; then
echo "Refreshrate: $3"
xrandr -r $3
fi
echo "Done."
Als sehr nervig empfinde ich ein Touchpad, das bei einem unbedachten Berühren gleich einen Klick auslöst. Dieses Verhalten lässt sich aber bequem abstellen. In der /etc/X11/xorg.conf ist im richtigen Device-Abschnitt (Synaptics Touchpad, einfach zu erkennen) folgende Einstellung hinzuzufügen:
Option "MaxTapTime" "0"
Betreibt man Feisty Out-Of-The-Box (also ohne zusätzliche Stromsparsachen - wie sich das auswirkt, keine Ahnung), kann man den Takt der CPU direkt beeinflussen. Ist z.B. hilfreich, um Programmen, die den Takt falsch erkennen, auf die Sprünge zu helfen.
Als root reicht ein einfaches
echo 1667000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
um den CPU-Takt auf 1.667GHz zu setzen. Zwei Dinge beachten:
Da Bluetooth im Feisty-Kernel schon tief verankert ist, ist hier ähnlich wie beim WLAN kaum mehr etwas einzurichten - ebenso problemlos funktioniert auch hier übrigens der Hotkey. Lediglich die beiden Pakete gnome-bluetooth und gnome-phone-manager sollten noch nachinstalliert werden.
Um Dateien zu empfangen, genügt es, zu starten. Dieses Programm kümmert sich dann um eingehende Dateitransfers etc.
Um Dateien zu versenden, ist noch das Paket nautilus-sendto erforderlich, das aber eigentlich schon vorhanden sein dürfte. Wie der Name schon sagt, kann man im Nautilus dann eine beliebige Datei rechts anklicken, "Senden an" und schon hat man Bluetooth zur Auswahl.
UMTS/GRPS habe ich noch nicht zum Laufen bekommen. Das Stichwort ist wohl rfcomm, näheres siehe Quelle. Mittlerweile glaube ich, dass ich das so schnell nicht hinbekommen werde, da mein Handy bei entsprechenden Versuchen immer abstürzte.
Zu Debug-/Einrichtungszwecken sind besonders die beiden Befehle "hciconfig -a" (detailliertere Infos über das Bluetooth-Device ansich) und "hcitool scan" hilfreich. Letzteres scant die Umgebung nach anderen Bluetooth-Geräten. Ist man sich also sicher, dass die Gegenseite korrekt arbeitet, wird diese aber nicht bei einem Scan angezeigt, tja, dann stimmt was nicht. "sdptool browse" zeigt einem alle Services von in der Nähe verfügbaren Geräten an.
Dauerhaftes Pairing habe ich nur über einen kleinen Umweg hinbekommen. Zuerst einmal benötigt man eine Anwendung, die überhaupt dauerhaftes Pairing benötigt, bspw. obexftp. Nun startet man im Hintergrund folgendes:
sudo passkey-agent --default /usr/bin/bluez-pin
Als Ausgabe erhält man erstmal nichts. Will man sich aber nun die verfügbaren Dateien mittels "obexftp" anzeigen lassen, also:
obexftp -b ADRESSE -l
Dann wird man zuerst am Handy, dann am Rechner zur Eingabe einer (beliebigen, aber natürlich derselben PIN) aufgefordert. Hat das geklappt, war's das erstmal und der Passkey-Agent kann wieder abgeschaltet werden. Nun hat man aber in den meisten Handys die Möglichkeit, sich die gekoppelten Geräte anzeigen zu lassen und dann dort einzustellen, dass Verbindungen mit diesen ohne Bestätigung zugelassen werden können. Sicherlich keine elegante oder sichere Variante, da die Adresse mit großer Wahrscheinlichkeit auch wieder gespooft werden kann, aber anders habe ich es bisher nicht hingekriegt.
Einen komfortablen Dateiaustausch ermöglicht dann das Paket gnome-vfs-obexftp, das Obex in Nautilus integriert: Einfach "obex:/" in der Adresszeile eingeben.
Um herauszufinden, welches Modem man hat, soll man laut der Ubuntu-Hilfe folgendes tun:
wget http://linmodems.technion.ac.il/packages/scanModem.gz zcat scanModem.gz > scanModem chmod u+x scanModem sudo ./scanModem less Modem/ModemData.txt
Der relevante Abschnitt dürfte wohl der folgende sein. Das Modem ist also ein unpraktisches Softmodem und nutzt die Soundkarte zur "Tonherstellung" ;=)
The HDA modem codec file is: /proc/asound/card0/codec#1
-----------------------------------
Codec: Conexant ID 2bfa
Address: 1
Vendor Id: 0x14f12bfa
Subsystem Id: 0x14f100c3
Revision Id: 0x90000
The audio card hosts a softmodem chip with Vendor ID: 0x14f12bfa
14f1 is the Conexant Vendor ID, and 0x14f12bfa a softmodem chipset.
Get a hsfmodem package through http://www.linuxant.com
For candidate modem in PCI bus: 00:1b.0
Class 0403: 8086:27d8 Audio device: Intel Corporation 82801G
Primary PCI_id 8086:27d8
Subsystem PCI_id 1028:01bd
Softmodem codec or Vendor from diagnostics: ID
from Archives: 14f1, a Conexant type,
Lacking a dsp (digital signal processing) chip, the modem is a software
intensive or "softmodem" type. Its primary controller manages the traffic
with the CPU. But the software needed is specified in the Subsystem.
-----------------------------------------
Support type needed or chipset: hsfmodem
Dell bietet auf seiner Seite seit kurzem einen (unbeschränkten) Treiber dafür an - "unbeschränkt" deshalb, weil der kostenlose Treiber von Linuxant angeblich auf 14.4kbps limitiert ist und keine Fax-Unterstützung bietet, eine nach oben hin offene Version gibt es dort angeblich nur für rund 20 Dollar. Und "angeblich" deshalb, weil ich es nicht ausprobiert, sondern dies nur aus einem der Kommentare auf Suzans Seite entnommen habe.
Der Dell-Treiber ließe sich mittels gdebi (bzw. "gdebi-gtk" für eine Version mit GUI) wohl installieren, aus Mangel an Bedarf und Gelegenheit (wo fliegt denn hier überhaupt noch ein Modem-Kabel rum?) habe ich es aber ganz gelassen.
Viele Webcams werden direkt ohne Treiber unterstützt, so auch meine beiden. Anschließen und gut. Eine gute Übersicht, was genau unterstützt wird, findet sich in den Quellen. Um herauszufinden, welche Webcam man hat, schließe man sie einfach an und gebe
lsusb
ein. Dort findet man dann die nötigen ID's. Da der Treiber "gspca" bei Feisty direkt dabei ist, dürften also mindestens diese Webcams auf Anhieb laufen (und das sind dort in der Liste eine ganze Menge).
Ein paar Programme zur Nutzung findet man im Ubuntu-Wiki-Eintrag, für einfache Shots tut es camorama. Wegen des unfreundlichen ATi-Treibers sollte man aber die Finger von xawtv lassen - kann man nicht widerstehen, so sollte man xawtv unbedingt mit dem Parameter "-remote" aufrufen, da man sonst nur einen schwarzen Bildschirm und womöglich einen kompletten Freeze erhält. Aber auch dann neigt der X-Server sehr gerne zu Abstürzen.
Videos von der Webcam aufnehmen kann man "ganz einfach" mit vlc (was aber sowieso installiert sein sollte, wenn man hin und wieder ein Video-File anschauen will). Unter kann man erst einmal ein bisschen rumspielen, das Video-Device wird man vermutlich auf "/dev/video0" stellen müssen. Nicht vergessen sollte man auch, dass alles unter natürlich auch berücksichtigt wird (auch später an der Command-Line), darunter z.B. die Auflösung in der man aufnehmen will. Normal bei Billig-Cams: Je höher die Auflösung, desto niedriger die FPS. Kann man nichts machen. :(
Um Sound richtig von der Soundkarte aufnehmen zu können, müssen eigentlich nur die Regler im OSS-Mixer vorher aufgedreht werden, und natürlich darf nichts anderes nebenher laufen, was die Soundkarte blockieren könnte. Zu Alsa habe ich VLC noch nicht bewegen können, intensiv probiert allerdings auch noch nicht - per OSS klappt es genauso gut, dann muss eben die Musik kurz aus. ;)
VLC kann man auch so starten, dass es direkt die Webcam/den Sound öffnet und mitschneidet. Man sollte aber erstmal mit den Codecs rumspielen und schauen, was gut zusammenpasst und sich auch möglichst überall abspielen lässt. Hat man seine Settings gefunden, wird erst einmal getestet, ob VLC mit den Parametern die Devices richtig öffnet. Man nimmt aus dem Öffnen-Dialog den String aus dem Feld hinter und klatscht ihn VLC als Parameter hin - das müsste schon genügen. Den String aus muss man etwas umformen: Das vordere ":sout=" muss weg und durch ein "--sout=" ersetzt werden, der nachfolgende Teil muss durch "'" gekapselt werden. Ganz am Ende könnte also ein solcher Aufruf dabei herauskommen (natürlich in einer Zeile, falls falsch dargestellt):
vlc v4l:// :v4l-vdev="/dev/video0" :v4l-adev="/dev/dsp" :v4l-norm=3 :v4l-frequency=-1 :v4l-width=176 :v4l-height=144 --sout='#transcode{vcodec=mp4v,vb=1024,scale=1,acodec=mpga,ab=128,channels=2}:duplicate{dst=display,dst=std{access=file,mux=mp4,dst="/home/user/Desktop/vlctest.avi"}}'
Wenn man schon unter Linux ist, kann man natürlich auch gleich dessen Vorzüge nutzen. Warum also nicht dem Dateinamen gleich Datum und Uhrzeit verpassen? Am Ende sieht der Aufruf dann so aus:
vlc v4l:// :v4l-vdev="/dev/video0" :v4l-adev="/dev/dsp" :v4l-norm=3 :v4l-frequency=-1 :v4l-width=176 :v4l-height=144 --sout="#transcode{vcodec=mp4v,vb=1024,scale=1,acodec=mpga,ab=128,channels=2}:duplicate{dst=display,dst=std{access=file,mux=mp4,dst="/home/user/Desktop/webcam-`date +%Y-%m-%d--%H-%M-%S`.avi"}}"
Zu beachten ist hier noch, dass die "'" um den sout-Parameter herum durch normale Anführungszeichen ersetzt wurden - die Shell nimmt sonst alles innerhalb der "'" einfach so hin und erkennt die Backticks für den Date-Teil nicht. Womöglich gibt es auch Probleme, wenn man das direkt so als Starter auf dem GNOME-Desktop anlegt - dann einfach in ein Skript packen. Das Ergebnis ist dann ein Link auf dem Desktop, den man einfach anklickt, die Aufnahme beginnt mit Datum und Uhrzeit im Dateinamen, wird auf dem Desk (oder eben sonstwo) abgelegt, man sieht und hört direkt, was man tut, und das Ganze endet mit einem Klick auf "Stop". Nach der kleinen Einrichtung kann's einfacher ja kaum mehr sein.
Vielleicht fällt auf, dass "Channels" auf "2" steht, obwohl man erstens quasi garantiert kein Stereo-Mikro hat und zweitens die Soundkarte im Notebook das auch gar nicht kann. Auch ist die Auflösung fest verdrahtet, was nicht so toll ist, falls man doch mal irgendwie anders aufnehmen will. Daher mal schnell ein kleines Script zusammengehackt, welches auf Mono getrimmt ist und Parameter für x- und y-Achsen aufnimmt:
#!/bin/bash
# Aufrufbeispiele:
# ./webcam_capture.sh 320 240
# ./webcam_capture.sh 176 144
X=$1
if [ -z $1 ]; then
X=320
fi
Y=$2
if [ -z $2 ]; then
Y=240
fi
vlc v4l:// :v4l-vdev="/dev/video0" :v4l-adev="/dev/dsp" :v4l-norm=3 :v4l-frequency=-1 :v4l-caching=300 :v4l-width=$X :v4l-height=$Y :no-v4l-stereo --sout="#transcode{vcodec=mp4v,vb=1024,scale=1,acodec=mpga,ab=128,channels=1}:duplicate{dst=display,dst=std{access=file,mux=mp4,dst="/home/user/Desktop/webcam-`date +%Y-%m-%d--%H-%M-%S`.avi"}}"
Ein bisschen Begeisterung sei an dieser Stelle nebenbei mal erlaubt: Im Gegensatz zu Windows mit den originalen Hersteller-Treibern ist es unter Linux völlig problemlos möglich, meine beiden Webcams parallel zu betreiben - auch wenn diese fast identisch sind und mit demselben Treiber (auch unter Linux) angesprochen werden. Es werden einfach und automatisch zwei Devices angelegt, die seperat angesteuert werden können, und fertig. Klasse!
Man mag es zwar kaum glauben, aber auch in so mancher Linux-Distribution gibt es Sachen, die sinnlos im Netzwerk lauschen. Ansehen kann man sich das mittels:
netstat -tulpen | grep -v 127.0.0.1
Bei Bedarf mit "sudo" ausführen, wenn man Näheres erfahren will. Im Normalfall dürfte man alles abschalten können bis auf den "dhclient", denn dieser wird für das automatische Beziehen einer IP (meist im WLAN) benötigt. Wie genau man das Einzelne deaktiviert, kann ich leider momentan bis auf den "avahi_daemon" nicht mehr sagen, weil: vergessen. Google hilft.
In der /etc/default/avahi-daemon muss folgendes stehen, um ihn (nach dem nächsten Reboot) dauerhaft zu deaktivieren:
# 0 = don't start, 1 = start AVAHI_DAEMON_START=0
Über Sockets, die an 127.0.0.1 gebunden sind, braucht man sich übrigens keine Gedanken zu machen: Diese sind von außerhalb des eigenen Rechners nicht zu erreichen. Deshalb sind sie auch gleich in obigem Command ausgeblendet worden.
Vermutlich ist dieses Vorgehen nicht ganz "sauber", aber trotzdem sehr praktisch: Die NIC bekommt eine feste IP und ist immer an. Als Preis dafür hat sie eine höhere Metrik, wodurch das WLAN bevorzugt werden soll. Ihre IP ist dieselbe, die der WLAN-AP mir zuteilt, was zuhause einen großen Vorteil hat: DCC im IRC funktioniert auf beiden Interfaces anstandslos.
Die Datei /etc/networking/interfaces ist folgendermaßen zu editieren:
auto lo
iface lo inet loopback
#auto eth0
#iface eth0 inet dhcp
auto eth0
iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.1
metric 2
#auto eth1
#iface eth1 inet dhcp
#auto eth2
#iface eth2 inet dhcp
#auto ath0
#iface ath0 inet dhcp
#auto wlan0
#iface wlan0 inet dhcp
Bis auf eth0 sind alle Interfaces auskommentiert und werden der Verwaltung durch den NetworkManager überlassen. eth0 jedoch bekommt diese festen Settings, bei denen es dann auch bleibt.
Der NetworkManager stellt einen Mechanismus zur Verfügung, um nach erfolgreicher Verbindung automatisch bestimmte Skripte laufen zu lassen. Soetwas bietet sich natürlich perfekt an, um einen automatischen Zeitabgleich mit der bundesdeutschen Atomuhr vorzunehmen.
Die Skripte, die ausgeführt werden sollen, befinden sich im Verzeichnis /etc/NetworkManager/dispatcher.d - was dort liegt, wird (angeblich) in alphabetischer Reihenfolge gestartet. Bei mir genügte das aber nicht und der Name des Skriptes musste mit zwei Ziffern beginnen. Man lege also bspw. eine Datei namens "02uhrzeit" dort an:
#!/bin/sh
#Aktion einlesen
ACTION=$2
#ist das Netzwerk oben?
if [ "$ACTION" = "up" ]; then
#Zeit holen
ntpdate ptbtime1.ptb.de
fi
und gebe ihr hinterher dieselben Rechte wie der bereits vorhandenen Datei "01ifupdown". Sobald man sich nun also mit einem WLAN oder etwas anderem verbindet, wird dieses Skript aufgerufen und die Zeit gesetzt.
Sehr praktisch, um sich eine abhörsichere Strecke aus einem leicht abzuhörenden Netzwerksegment heraus zu legen (also z.B. von der Uni aus zum eigenen IRC-Server oder Proxy, falls verfügbar).
ssh -p 1337 -L 127.0.0.1:3090:mein.irc-server.de:3342 user@ssh-server.de
Dieser Befehl bewirkt folgendes: Zuerst einmal meldet man sich normal per SSH als "user" auf "ssh-server.de" an (dort auf Port 1337). Auf dem lokalen Interface 127.0.0.1 (es kann also auch keiner sonst im LAN den Tunnel mitbenutzen/missbrauchen) wird dann der TCP-Port 3090 geöffnet. Verbindet man nun auf diesen Port, dann erstellt der SSH-Daemon auf dem Rechner "ssh-server.de" von sich aus eine Verbindung nach "mein.irc-server.de" / Port 3342.
Sofern nicht erst bei dieser Anmeldung, sondern eben bereits im Vorfeld auf gesicherten Kanälen, Zertifikate ausgetauscht werden, dann kann dieser Tunnel als abhörsicher betrachtet werden.
Zu beachten ist noch: Sind "mein.irc-server.de" und "ssh-server.de" identische Rechner, dann ist so auch ein Zugriff auf Ports auf "ssh-server.de" möglich, die dort an 127.0.0.1 gebunden sind! Es wäre also bspw. möglich, auf "ssh-server.de" einen HTTP-Proxy laufen zu lassen, diesen an 127.0.0.1 zu binden (und somit schon einmal auf der wesentlich sichereren Seite bzgl. Missbrauch durch Fremde zu sein), dann einen SSH-Tunnel zu legen und schlussendlich über diesen normal zu surfen. Dadurch ist z.B. Online-Banking in einem öffentlichen Netzwerk wesentlich gefahrloser möglich.
Wie bereits eben erwähnt, ist es ohne XGL nicht möglich, mit dem ATi-Treiber Compiz zu betreiben. Abhilfe kann XGL schaffen. Ja! :p
Zuerst einmal benötigt man das Paket xserver-xgl. Ist das erfolgreich installiert, sind noch ein paar Skripte notwendig. Vorweg: Man wird in GDM zwei seperate Sessions auswählen können: Einmal ein normales GNOME mit hardwarebeschleunigtem OpenGL, dann eine weitere Session, in der zwar Compiz läuft und man dort auch in guter Geschwindigkeit alle Effekte sieht, die jedoch für andere Anwendungen kein Hardware-OpenGL mehr bietet.
Das erste Skript wird nun /usr/local/bin/startxgl.sh sein, das man mit folgendem Inhalt füllt:
#!/bin/sh Xgl :1 -fullscreen -ac -accel xv:pbuffer -accel glx:pbuffer & DISPLAY=:1 cookie="$(xauth -i nextract - :0 | cut -d ' ' -f 9)" xauth -i add :1 . "$cookie" setxkbmap -model pc105 -layout de & exec dbus-launch --exit-with-session gnome-session
Natürlich ist diese Datei noch für alle User ausführbar zu machen:
sudo chmod a+x /usr/local/bin/startxgl.sh
Das zweite Skript ist eigentlich kein Skript, sondern die zusätzliche Session für GDM, die angelegt werden muss. Nennen wir die Datei /usr/share/xsessions/xgl.desktop und füllen sie mit folgendem Inhalt:
[Desktop Entry] Encoding=UTF-8 Name=GNOME with XGL/Compiz Comment= Exec=/usr/local/bin/startxgl.sh Icon= Type=Application
In meiner Quelle stand, dass diese Datei auch ausführbar sein soll, was ich jedoch für überflüssig halte. Ausprobiert habe ich es allerdings auch nicht, bei mir ist sie ausführbar.
Beim Anmelden kann man diese Session nun auswählen und dann dort Compiz aktivieren (normaler Weg, ).
Die bei Feisty Fawn mitgelieferten Fonts sehen nicht schön aus. Wer im Besitz einer Windows-Lizenz ist (evtl. geht es auch ohne, kA ;)), kann allerdings seine Fonts wie folgt ganz einfach benutzen:
Falls es noch nicht existiert, dann das versteckte Verzeichnis ".fonts" im eigenen Homedir erstellen:
mkdir ~/.fonts
In dieses Verzeichnis nun alle Dateien aus C:\Windows\Fonts kopieren, dabei auf Kollisionsfreiheit mit bereits existierenden Fonts achten und sich dann neu in GNOME anmelden - dann müssten die Schriftarten zur Verfügung stehen.
Um sie nun allerdings auch in ihrer wahren Pracht genießen zu können, müssen ein paar Settings beim Font-Rendering geändert werden. Unter kann man sich erst einmal die Fonts setzen. Im gleichen Fenster sollte dann die "Schriftwiedergabe" auf "Schwarz-Weiß", unter "Details" das Hinting auf "Stark" setzen und die "Reihenfolge der Subpixel" auf "RGB" belassen. Falls das nicht zu einem klaren Schriftbild führt, rumprobieren. ;)
Nutzt man einfarbige Desktop-Hintergründe oder stört es einen schlichtweg, dann lassen sich die Schlagschatten der Symbole abstellen - allerdings mit dem Preis, dass man dann einen hässlichen Rand um die Schrift herum hat. Nutzt man aber wie gesagt einfarbige Hintergründe, dann fällt das nicht mehr auf.
Ändern lässt sich das Verhalten von Nautilus (welcher zur Darstellung des Desktops genutzt wird) in der ~/.gtkrc-2.0. Falls diese noch nicht existiert, so erstelle man sie mit folgendem Inhalt:
# --------------------- Schriftfarbe der Desktop-Icons
style "desktop-icon" {
NautilusIconContainer::frame_text = 1
text[NORMAL] = "#000000" # Schriftfarbe
base[NORMAL] = "#FFFFFF" # Hintergrundfarbe
NautilusIconContainer::normal_alpha = 0
}
widget_class "*DesktopIcon*" style "desktop-icon"
Eigentlich sollte der Rand um die Schrift mit einem Alpha-Wert von 255 nicht mehr zu sehen sein - das GNOME von Feisty scheint jedoch verbuggt, wodurch dieser Wert nicht umgesetzt wird. Dürfte im nächsten Ubuntu behoben sein.
Um diese Einstellungen dann zu übernehmen, muss Nautilus einmal neu gestartet werden:
killall nautilus
Wenn der GNOME-Splashscreen nicht in das restliche Design passt, kann man ihn verbannen. Man starte
gconf-editor
und setze dort unter "apps / gnome-session / options" die Option "show_splash_screen" auf false.
Wenn irgendetwas nicht mehr stimmt, kann man die GNOME-Panels auf ihre Fabrikwerte zurücksetzen lassen:
gconftool-2 --recursive-unset /apps/panel killall gnome-panel
Eine sehr merkwürdige Auswirkung hat das Aktivieren der Hilfstechnologien zur Barrierefreiheit. Denn sind diese in Betrieb, kann Nautilus extrem lange brauchen, um (größere) Verzeichnisbäume zu öffnen. Abhilfe fand ich nur im Deaktivieren dieser Hilfstechnologien. Klar aber: Dann sieht man den Fensterinhalt beim Verschieben nicht mehr.
Ein anderer Punkt sind natürlich Thumbnails und ähnliches. Automatisches Thumbnailing kann man einerseits im Nautilus direkt abstellen, zusätzlich aber noch unter "desktop / gnome / thumbnailers" und dort dem Wert "disable_all".
Manche Spiele erkennen den CPU-Takt nicht richtig, da dieser aufgrund niedriger Last noch ganz unten sein kann - das und ständige HLT's vom OS an die CPU können das Timing das Spiels etwas (sehr) zerfetzen.
Prinzip des Workarounds ist es nun, zuerst einmal Hintergrundlast auf die CPU zu legen. Dadurch "springt sie an" (man muss also den Takt nicht von Hand nachkorrigieren, was bei mir im Übrigen auch keinerlei weitere Besserung brachte) und bleibt auch "an" - das OS dürfte also nicht mehr so oft auf die Idee kommen, die CPU schlafen legen zu wollen. Genauer gesagt geht es nur um einen Kern, da ja ein schöner DualCore in der Kiste schlummert. Dieser Load-Prozess bekommt dann niedrigste Priorität, sodass er das Spiel selbst nicht beeinflusst - welches im Anschluss dann gestartet und auch auf denselben Kern gepinnt wird.
Eine richtige Lösung ist das aber nicht, denn eigentlich müsste man alle Stromsparfunktionen der CPU abschalten - und zudem einige Bugs in ihr beseitigen. Wie dem auch sei, man benötigt die beiden Programme "renice" (müsste eigentlich verfügbar sein) und "taskset". Leider weiß ich nicht mehr, wo letzteres herkam, falls ich es überhaupt aus einer externen Quelle habe. Natürlich noch ein Programm, das den Load erzeugt, aber das ist schnell geschrieben:
#includeint main(void) { printf("CPU-Load.\n"); while (1); }
Ginge evtl. auch mit Bordmitteln, aber so geht's auf jeden Fall ... Das Spiel selbst umhüllt man dann mit einem kleinen Skript:
#!/bin/bash GAMEPATH="<pfad zum spiel>" LOADPATH="<pfad zur load-binary>" taskset 0x00000001 $LOADPATH & LOADPID=$! renice 19 -p $LOADPID taskset 0x00000001 $GAMEPATH kill $LOADPID
In die /etc/rc.local einfügen, dabei "binary.x86" natürlich durch den richtigen Namen ersetzen:
chmod o+w /proc/asound/card0/pcm0p/oss echo "binary.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss
Wenn es zu einem Freeze im Spiel kommt, dann dort die Musik abstellen.
In der Datei ~/.bashrc lassen sich einige nützliche Dinge einstellen. Bitte darauf achten, dass manches schon vorhanden sein kann.
"ls" immer farbig, ausführlich, Größen besser lesbar und mit Anzeige von versteckten Files:
alias l='ls -hal --color=auto'
Ein "light-weight" Prompt:
# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color)
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
;;
*)
#PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
#PS1='\[\033[01;30m\]${debian_chroot:+($debian_chroot)}\w\[\033[00;30m\] \$ '
PS1='${debian_chroot:+($debian_chroot)}\w \$ '
;;
esac
# Comment in the above and uncomment this below for a color prompt
#PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
#PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"'
PROMPT_COMMAND='echo -ne "\033]0;${PWD/$HOME/~}\007"'
;;
*)
;;
esac
Es kann vorkommen, dass JUnit nicht im Classpath ist, wenn man sich außerhalb von Eclipse/NetBeans bewegt. Ganz am Ende hinzufügen:
# java classpath für junit export CLASSPATH=$CLASSPATH:.:/usr/share/java/junit.jar
Neue Methode, um Piepser generell und überall abzuschalten: Man öffne die Datei /etc/modprobe.d/isapnp als Root und kommentiere den Eintrag mit "alias pnp:dPNP0800 pcspkr" aus. Nach einem Reboot ist der PC-Speaker komplett deaktiviert und gibt so schnell nichts mehr von sich.
Temporär ausprobieren kann man das mit:
sudo modprobe -r pcspkr echo -e "\a"
Hier sollte dann kein Piep zu hören sein.
Alte Anleitung:
Grade in der Uni sehr nervig, wenn es ständig blöde piept. Will man nicht gleich den ganzen Support für den PC-Speaker aus dem Kernel entfernen, (Nachtrag: Genau das habe ich jetzt oben gemacht - ich wusste nur bisher nicht, dass das ein simples Kernel-Modul ist, sondern dachte, es wäre "fest" drin ;)) kann man an zwei anderen Punkten ansetzen, um das meiste endlich zur Ruhe zu bringen.
In der /etc/inputrc kann man folgende Einstellung vornehmen, um bei Tab-Completion keine Beeps mehr zu erhalten:
# do not bell on tab-completion set bell-style none
Ein weiterer Lärmfaktor ist "less". Wieder in der ~/.bashrc lässt sich ein Wert definieren, der "less" immer mit dem Parameter "-q" aufruft:
export LESS="-q"
Bisher ungeklärt: Einmal an einem TTY angemeldet (ob wieder abgemeldet oder nicht, spielt keine Rolle), ertönt ein sehr lauter Piep beim Herunterfahren des Rechners.
Schuld ist (mal wieder) der ATi-Treiber, der einigen Videos mit bestimmtem Codec einen krassen Blau-Stich verpasst. Umgehen lässt sich das Problem bisher nur, indem man das Programm "gstreamer-properties" startet und dort unter den Punkt "X Window System (Kein Xv)" auswählt.