Einträge von Uwe Weissenbacher

Einen Artikel habe ich dem Internet Explorer ja bereits gewidmet. Auch wenn ich dieses Stück Software niemals freiwillig benutzen würde und es so viel Aufmerksamkeit eigentlich nicht verdient, so muss ich doch ab und an damit arbeiten. Und heute hat mir der IE wieder zehn Minuten meiner kostbaren Zeit gestohlen. Ein Webserver, den ich testen wollte lief nicht auf dem Standardport. Also text.example.com:20000 in die Adressleiste des IE. Der Browser meint dazu "Die Seite kann nicht angezeigt werden - Fehler: Server oder DNS kann nicht gefunden werden". Um die Geschichte abzukürzen: im Netz stimmte natürlich alles, der Internet Explorer will jedoch ein Protokoll sobald ein Port angegeben wird. http://test.example.com:20000 funktionierte dann auch. Einen technischen Grund für dieses Verhalten gibt es nicht, denn ein Domainname kann sowieso keinen Doppelpunkt enthalten. Folgerichtig frisst der Firefox text.example.com:20000 auch problemlos. Vielleicht hat sich das inzwischen im IE7 gebessert, aber ich muss Microsoft trotzdem ein Kompliment für dieses tolle Verhalten des IE6 aussprechen.

Heutzutage ist es sinnvoll und nur vernüftig TCP Verbindungen abzusichern. Dies geschieht bei HTTP (aber auch einigen anderen Protokollen) über TLS/SSL. Falls allerdings Probleme auftreten ist die Möglichkeit durch Mitsniffen Hinweise auf Fehler zu erhalten verbaut. Auch die beliebte Methode eine Serveranwendung mit telnet oder netcat zu testen ist nicht mehr ohne weiteres durchführbar. Die bekannteste SSL Implementation OpenSSL bietet allerdings ein Dienstprogramm, welches dies wieder ermöglicht. Zur besseren Übersicht sind die getippten Kommandos grün hinterlegt:

$ openssl s_client -host www.gmx.de -port 443
CONNECTED(00000003)
depth=0 /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDUzCCArygAwIBAgIQSrsfqH7F4QWACHs9HWpPkzANBgkqhkiG9w0BAQQFADCB
zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh
d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl
cnZlckB0aGF3dGUuY29tMB4XDTA2MDIxMDA5NTUxNloXDTA3MDIxNzA4NTcwMVow
WDELMAkGA1UEBhMCREUxDzANBgNVBAgTBkJheWVybjEPMA0GA1UEBxMGTXVuaWNo
MREwDwYDVQQKEwhHTVggR21iSDEUMBIGA1UEAxMLd3d3LmdteC5uZXQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALv4J7mPoIhpMzqWmGEJKIxLlkD/Y4bKhXGP
EN11bdPPL1xcaCB95+r1lW4yvrC+NOQRre/Zt1vvXUtw+CKjzWL17xk5ORxejx5d
WCaZ+AtjKL3j7PrZkErx7X7ZqNcRgmPn2bfPfYnYR3gjp7AJitslmb+5Cp2a7dfo
pjYGOEnbAgMBAAGjgaYwgaMwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC
MEAGA1UdHwQ5MDcwNaAzoDGGL2h0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ
cmVtaXVtU2VydmVyQ0EuY3JsMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYW
aHR0cDovL29jc3AudGhhd3RlLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB
BAUAA4GBABrINqdDTKfUd7BTpZLl4i0zHzWCff851588VxUL8+3OUqIHgTzdvWmx
9JeM8RoiCXfX84dt5y3pdeYi9FWJM5rBRxbijzw3f5zSyJloz7xSpV08F/Ii+svs
MKUhTkNSbMwa9vnWIogK4prbUj0yHfCrdsZLmHI4zAliK0e8lHfF
-----END CERTIFICATE-----
subject=/C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
issuer=/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
---
No client certificate CA names sent
---
SSL handshake has read 1419 bytes and written 322 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 67DE63728E1EF1E860BFE2B8E54A65EA52DA8AFA8F5D3A202746A36D2BCC5558
Session-ID-ctx:
Master-Key: E6C37C6E7C56A8C95366C26102A41BE8233E079A4371AA20996EFF7DC539BDCE424F326A3F494F81C3CA03712D91F08E
Key-Arg : None
Start Time: 1165442910
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
GET / HTTP/1.0
HOST: www.gmx.de

HTTP/1.1 302 Found
Date: Wed, 06 Dec 2006 22:08:42 GMT
Server: Apache
Location: https://www.gmx.net/de/
Vary: Accept-Encoding
Content-Length: 207
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://www.gmx.net/de/">here</a>.</p>
</body></html>
closed

Auch wenn die meisten Webentwickler mit dem Internet Explorer aufgrund der unzureichenden Umsetzung der Standards und des katastrophalen Sicherheitsmodells auf Kriegsfuss stehen surfen im insbesonderen amerikanische Nutzer oft noch mit diesem Browser.

Neu entwickelte Webseiten müssen also auch noch mit diesen IE Versionen getestet werden. Dafür ist allerdings nicht zwangsläufig die Installation von Windows notwendig. Das Projekt IEs4Linux installiert die Versionen 5, 5.5 und 6 des Internet Explorers vollautomatisch unter Linux. Der kostenlose Programm Wine gaukelt dem IE Versionen dabei die richtige Systemumgebung vor.


Die Verfügbarkeit dieses Browsers ist nicht nur für Entwickler ein Segen. Auch wenn fremde Webseiten nur mit dem Internet Explorer funktionieren (ja solche gibt es immer noch) lässt sich der unter Linux laufende IE einsetzen. Allerdings sollte man sich überlegen, ob die Seite wirklich unverzichtbar ist und man nicht auch woanders, wo man Besucher und die Standards respektiert, fündig wird.

Darüber hinaus muss natürlich ein anständiger Browser her. Mein Favourit ist dabei Mozilla Firefox, dessen größter Vorteil eindeutig die zahllosen Plugins sind.

Heise schreibt über einen Telekom Router, der sich offenherzig gibt. Allerdings fiel es mir schwer daran zu glauben, dass es sich hier nur um ein Problem von Telekom Hardware handeln sollte. Also beschloss ich meinen eigenen kleinen Test zu starten. "Geöffnet" vollständig lesen »

Die folgende Begebenheit hat sich vor einigen Monaten ereignet und deshalb muss ich es aus meinem Gedächtnis rekonstruieren. Daher hoffe ich, dass die Datails noch stimmen.

Ein Notebook mit Debian an Board sollte umgestöpselt werden. Am neuen Standort war Windows (vermutlich Server 2003, aber ich weiss es nicht genau) für die Adressvergabe per DHCP zuständig. Der geneigte Leser wird es an dieser Stelle sicher ahnen: hätte das Notebook seine Adresse problemlos erhalten, wäre dieser Artikel nicht zustande gekommen. In tcpdump erschienen DHCPDISCOVER vom Notebook und DHCPOFFER vom Server und danach herrschte Funkstille. Im Windows-eigenen Paketsniffer wurde zur Verwunderung der Beteiligten keines der Pakete angezeigt.

Nachdem etwas im Nebel gestochert worden war, kam mir die Idee es könnte sich um ein Datumsproblem handeln. Denn im Notebook war der Akku defekt und auch die Sekundärversorgung war offensichtlich so leer, dass die Uhrzeit nicht mehr gehalten werden konnte. Die Zeit wurde bei jedem stromlosen Flurgang (oder Umzug) auf den 01.01.2002 zurückgesetzt. Nachdem Uhrzeit und Datum wieder richtig eingestellt waren erhielt der Client seine IP ohne Probleme. Warum allerdings keines der beteiligten Systeme es für nötig gehalten hat irgendeine Fehlermeldung in das Logfile zu schreiben ist mir bis heute ein Rätsel.

Wenn man Linuxhilfe benötigt, wird man oft dazu aufgefordert Konfigurationsdateien bei Services wie zum Beispiel pastebin oder nopaste zu hinterlegen. Viele machen es den Helfern aber unnötig schwer. Eingestreute Kommentar- und Leerzeilen verschlechtern die Übersichtlichkeit für den Profi. Daher sollte diese vorher entfernt werden:

egrep -v '^[[:space:]]*$|^[[:space:]]*#' /path/to/file

Zum Vergleich meine vollständige /etc/rc.conf

# /etc/rc.conf: Global startup script configuration settings

# UNICODE specifies whether you want to have UNICODE support in the console.
# If you set to yes, please make sure to set a UNICODE aware CONSOLEFONT and
# KEYMAP in the /etc/conf.d/consolefont and /etc/conf.d/keymaps config files.

UNICODE="no"

# Set EDITOR to your preferred editor.
# You may use something other than what is listed here.

#EDITOR="/bin/nano"
EDITOR="/usr/bin/vim"
#EDITOR="/usr/bin/emacs"

# XSESSION is a new variable to control what window manager to start
# default with X if run with xdm, startx or xinit. The default behavior
# is to look in /etc/X11/Sessions/ and run the script in matching the
# value that XSESSION is set to. The support scripts are smart enough to
# look in all bin directories if it cant find a match in /etc/X11/Sessions/,
# so setting it to "enlightenment" can also work. This is basically used
# as a way for the system admin to configure a default system wide WM,
# allthough it will work if the user export XSESSION in his .bash_profile, etc.
#
# NOTE: 1) this behaviour is overridden when a ~/.xinitrc exists, and startx
# is called.
# 2) even if ~/.xsession exists, if XSESSION can be resolved, it will
# be executed rather than ~/.xsession, else KDM breaks ...
#
# Defaults depending on what you install currently include:
#
# Gnome - will start gnome-session
# kde-<version> - will start startkde (look in /etc/X11/Sessions/)
# Xsession - will start a terminal and a few other nice apps

#XSESSION="Gnome"
XSESSION="kde-3.5"

Und die gekürzte Fassung

UNICODE="no"
EDITOR="/usr/bin/vim"
XSESSION="kde-3.5"

Versicht ist allerdings bei Shellscripten geboten, da die Shebang hierbei auch entfernt wird.

Ich hab mal wieder einen Windows PC in Behandlung. Ein Verzeichnis (oder "Ordner" wie Microsoft es nennt) war nicht zu löschen. Es kam stets die Meldung:

Datei kann nicht gelöscht werden: Die Quelldatei oder vom Quelldatenträger kann nicht gelesen werden

Die "üblichen Tricks" (chkdsk, löschen vom Kommandoprompt aus, Abgesicherter Modus) haben alle versagt. Den ersten brauchbaren Hinweis gab ein Heise Hotline Artikel: Verzeichnis lässt sich nicht löschen. Den dort vorgeschlagenen Befehl quittierte Windows jedoch mit einem Netzwerkfehler. Allerdings schien das Problem identisch; die UNC wurde nicht konsistent eigehalten. Den entscheidenden Tipp gab es dann hier. Ich musste das übergeordnete Verzeichnis beschreibbar freigeben und konnte das problematische Verzeichnis dann problemlos mit Konqueror (einfach smb://ipadresse in die Adresszeile) löschen.

Another job well done.

In einer perfekten Welt wären Verbindungsprobleme nicht existent und Netzwerke würden immer funktionieren. Leider leben wir nicht in einer solchen und so muss man mit den Auswirkungen dieser Fehler klar kommen. Unterbricht eine SSH Verbindung weil die Gegenstelle nicht mehr reagiert (und auch keine ICMP Message schickt, die anzeigt, dass die Verbindung unterbrochen ist), so wartet der Client unter Umständen eine kleine Ewigkeit bis der Timeout zuschlägt und das Terminal wieder freigibt. Die übliche Abbruchmethode für Konsolenprogramme via CTRL+C funktioniert nicht, da der SSH Client dieses Tastenkombination einfach an den Server durchleitet. Das gleiche gilt für Telnet, dass auch oft benutzt wird um andere Dienste wie zum Beispiel HTTP oder POP3 zu testen.

Das Terminal zu schliessen oder den Prozess zu töten kann natürlich keine Lösung sein, zumal die Entwickler dieser Clients bereits an dieses Problem gedacht haben. Sowohl für SSH als auch für Telnet existiert ein so genannter Escape Character, um aus der Session zu entkommen und Zugriff auf das Programm zu erhalten.

Dieses Zeichen ist für SSH in der Voreinstellung die Tilde (~). Auf einer deutschen Tastatur ist sie über AltGr+ zu erreichen. Natürlich kann auch ein anderes Zeichen definiert werden. Die SSH Manpage sagt dazu:

-e escape_char
Sets the escape character for sessions with a pty (default: `~'). The
escape character is only recognized at the beginning of a line. The
escape character followed by a dot (`.') closes the connection; followed
by control-Z suspends the connection; and followed by itself sends the
escape character once. Setting the character to ``none'' disables any
escapes and makes the session fully transparent.

Folgende Befehle sind dann laut Manpage möglich

The supported escapes (assuming the default `~') are:

~. Disconnect.

~^Z Background ssh.

~# List forwarded connections.

~& Background ssh at logout when waiting for forwarded connection / X11 ses-
sions to terminate.

~? Display a list of escape characters.

~B Send a BREAK to the remote system (only useful for SSH protocol version 2
and if the peer supports it).

~C Open command line. Currently this allows the addition of port forward-
ings using the -L and -R options (see above). It also allows the cancel-
lation of existing remote port-forwardings using -KR hostport. !command
allows the user to execute a local command if the PermitLocalCommand
option is enabled in ssh_config(5). Basic help is available, using the
-h option.

~R Request rekeying of the connection (only useful for SSH protocol version
2 and if the peer supports it).

Ein Zirkumflex (^) steht übrigens für die Taste Ctrl (Strg). Funktionieren diese Kombinationen nicht, so ist auf dem Client PC vielleicht deadkeys als Tastaturlayoutvariante eingestellt. In diesem Fall muss die Tilde zwei mal gedrückt werden um diese Kommandos ausführen zu können. Soll die Tilde auf der Shell der Gegenseite ankommen ist sogar ein viermaliger Druck notwendig.

Telnet zeigt das Escape Zeichen beim Verbindungsauf an:

$ telnet www.google.de 80
Trying 72.14.221.104...
Connected to www.google.de.
Escape character is '^]'.

Dieses eckige Klammer (]) ist auf Tastaturen mit englischem Layout leicht zu erreichen und es muss tatsächlich nur Ctrl (Strg) und die ]-Taste gedrückt werden. Beim deutschen Layout wird zusätzlich noch AltGr gebraucht, wodurch die Kombination fast schon zum Affengriff wird. Dort muss Strg+AltGr+9 gedrückt werden, damit man in den Kommandomodus von telnet wechselt. Natürlich lässt sich auch dieses Zeichen ändern:

-e escapechar
Sets the initial telnet escape character to escapechar. If escapechar is
omitted, then there will be no escape character.

Mit einem einfachen Druck auf Return wechselt telnet vom Prompt zurück in die Verbindung.

Sorry. Aber ich muss jetzt meinem Ärger mal eben Luft machen. Ich benutze im Büro Debian, weil eigentlich alle Linux Büchsen hier damit laufen. Bei dieser Distribution sind in der Datei /etc/apt/sources.list URIs eingetragen, von denen sich das System Paketlisten besorgen kann (vergleichbar mit den RSYNC mirrors bei Gentoo). Dort sind bei mir sowohl einige HTTP als auch FTP Sourcen eingetragen. Das man bei Debian immer zig Einträge in dieser Datei braucht, damit man seine Software zusammenbekommt (mplayer, acroread, etc.), empfinde ich zwar als ziemlich störend, aber es hat immerhin einen nachvollziehbaren Grund (Lizenzgeraffel, falls sich jemand dafür intressiert).

Das Netz hier ist ziemlich dicht, nach außen geht es nur über den HTTP oder FTP Proxy. Das ganze lässt sich auch im Konfigurationsfile (/etc/apt/apt.conf) das Paketmanagement Frontends apt einstellen:

Acquire::ftp
{
Proxy "ftp://foobar:2121";
ProxyLogin
{
"USER $(SITE_USER)@$(SITE)";
"PASS $(SITE_PASS)";
};
};
Acquire::http::Proxy "http://barfoo:8080";

Dann aber wurde der FTP Proxy im Zuge einer Umstellung abgeschaltet. Glücklicherweise ist FTP ins Internet damit noch nicht gekappt, denn der HTTP Proxy beherrscht auch dieses Protokoll. Die FTP-in-HTTP-Verpackung sieht dann zum Beispiel in etwa so aus:

GET ftp://ftp.de.debian.org HTTP/1.1
...

Diese Umstellung sollte kein Problem darstellen, da der entsprechenden Konfigurationszeile das Zugriffsschema voransteht (http:// oder ftp://). Also war ftp://foobar:2121 einfach durch http://barfoo:8080 zu ersetzen. Der Erfolg blieb leider aus und es hagelte nur Connection Timeouts. An dieser Stelle ist der erste Gedanke natürlich: was passiert da auf dem Netz? Ethereal zeigt dann, dass apt offentlich versucht FTP mit dem HTTP Proxy zu sprechen. Klarer Fall: da hab ich etwas falsch konfiguriert. Nach mehrmaliger Prüfung war aber beim besten Willen kein Fehler zu finden. Alle Quellen im Netz hatten es auch so eingestellt. Fast vom Stuhl gefallen bin ich, als ich folgenden Abschnitt in man sources.list lesen konnte.

It is possible to proxy FTP over HTTP by setting the ftp_proxy environment variable to a http url - see the discussion of the http method above for syntax. You cannot set this in the configuration file and it is not recommended to use FTP over HTTP due to its low efficiency.

Hallo? Geht's noch ein bischen schizophrener? Wenn etwas in einer Environment Variable gesetzt ist funktioniert es. Im applikationseigenen Konfigurationsfile wird nicht angenommen. Allein das ist schon krank, aber es geht ja noch weiter. Die Proxyurl, vor der eindeutig http:// steht, dann ohne jegliche Fehlermeldung zu etwas anderem zu verwursten und dann zu behaupten der Server wäre kaputt setzt dem ganzen die Krone auf. Eine leidlich vollständige Dokumentation entbindet nicht davon einigermaßen sinnvolle Fehlermeldungen auszugeben.

Danke. Jetzt geht's mir besser.

Nachtrag
Natürlich will ich nicht nur meckern, sondern auch eine konkrete Problemlösung anbieten. Systemweite Environment Variablen werden bei Debian normalerweise in /etc/environment gesetzt. Allerdings werden diese offensichtlich nur bei einem Login und nicht bei einem Benutzerwechsel zu root ausgelesen. Daher sollte man den Proxy zusätzlich in /root/.profile setzen.

export http_proxy="http://barfoo:8080"
export ftp_proxy="http://barfoo:8080"

Der i810 Treiber mit dem ich mein Spielzeug unter X.org betreibe hat die Fähigkeit den externen Monitorausgang und den TFT des Laptops gleichzeitig zu versorgen. Diese Versorgung hört bei DRI allerdings prinzipbedingt auf. Dies betrifft zum Beispiel die Anzeige von Videos, die ohne DRI (je nach Anzeigegröße) nur zäh abgespielt werden würden.
Denkbar folgendes Problem für die Praxis: man will einen Film auf einem Beamer über den Monitorausgang ansehen, es erscheint jedoch nur ein blaues Overlaybild.
Das ganze würde ich natürlich nicht schreiben, wenn ich nicht auch eine Lösung parat hätte. Es ist möglich DRI-Ziel umzuschalten. Mit

xvattr -a XV_PIPE -v 0

aktiviert man DRI auf dem VGA-Ausgang und mit

xvattr -a XV_PIPE -v 1

holt man es wieder auf Laptopbildschirm zurück. Ich weiss nicht, ob dies auch bei anderen Treibern als dem i810 oder in anderen Konfigurationen funktioniert. Über entsprechende Hinweise würde ich mich freuen.

Billige Tintenstrahldrucker werden von den Herstellern zum Selbstkostenpreis (oder sogar darunter) unters Volk geworfen, um dann mit den Tintenpatronen Gewinn zu machen. Natürlich soll man ein so subventioniertes Stück Hardware nicht auch noch ins Netz einbinden können, denn dafür haben die Hersteller teure netzwerkfähige Geräte. Soviel vorweg, nun zur eigentlichen Aufgabenstellung. Gegeben:

• HP 1510 PSC (Tintenstrahldrucker, Scanner, Kopierer)


• Linux Router, der als Druckserver fungieren soll


• per WLAN angebundenes WinXP Notebook

Die Aufgabe:
Das WinXP Notebook soll auf dem am Linux Router angeschlossenen Multifunktionsgerät drucken und scannen können.
"Eingerichtet" vollständig lesen »

Das die Bourne Shell Platzhalter erlaubt dürfte niemanden wirklich überraschen.

uwe@krusty ~/temp/test $ ls IMG_*
IMG_0082.JPG IMG_0088.JPG IMG_0090.JPG IMG_0092.JPG IMG_0096.JPG
IMG_0084.JPG IMG_0089.JPG IMG_0091.JPG IMG_0095.JPG IMG_0098.JPG
uwe@krusty ~/temp/test $ ls IMG_00?2.JPG
IMG_0082.JPG IMG_0092.JPG

Diese Platzhalter können bei beliebigen Befehlen verwendet werden, so zum Beispiel auch bei scp. Wie kopiert man aber nun am geschicktesten IMG_0082.JPG und IMG_0084.JPG auf einen entfernten Rechner? Benutzt man hier Platzhalter

uwe@krusty ~/temp/test $ scp IMG_008?.JPG 192.68.68.235:
IMG_0082.JPG 100% 1062KB 1.0MB/s 00:00
IMG_0084.JPG 100% 335KB 335.1KB/s 00:00
IMG_0088.JPG 100% 1302KB 1.3MB/s 00:00
IMG_0089.JPG 100% 1071KB 1.1MB/s 00:00

so wird zuviel kopiert. Glücklicherweise kann man sich hier einer Zeichenklasse bedienen, wie sie von regulären Ausdrücken bekannt ist.

uwe@krusty ~/temp/test $ scp IMG_008[24].JPG 192.68.68.235:
IMG_0082.JPG 100% 1062KB 1.0MB/s 00:00
IMG_0084.JPG 100% 335KB 335.1KB/s 00:00

Gerade bei vielen Dateinamen die sich nur gering unterscheiden kann dieser kleine Trick einiges an Tipparbeit ersparen.

Irssi hat in seiner neuen Version endlich eine Option bekommen um den Augenkrebs, den UTF-8 benutzende Mitmenschen verursachen, Einhalt zu gebieten. Und nach guter Irssi-Tradition ist dieses Feature natürlich wieder kaum dokumentiert. Deshalb hier eine kleine Anleitung.

Zeichensatzkonvertierung einschalten

/set recode on

Zeichensatz der per Default ausgegeben wird: iso-8859-15

/set recode_out_default_charset iso-8859-15

Zeichensatz des Terminals: iso-8859-15

/set term_charset iso-8859-15

Einstellungen speichern

/save

Und man ist zumindest im IRC von dieser Pest befreit.

In letzter Zeit ist so einiges passiert, aber schön der Reihe nach. Der Gips ist schonmal ab und ich kann wieder einigermaßen tippen, auch wenn die Hand noch nicht voll beweglich ist.
Der Abschnitt Furtwangen ist für mich vor kurzem zu Ende gegangen und ich schreibe zur Zeit in Ulm an meiner Diplomarbeit (das Thema wird sicherlich auch noch einige Blogeinträge abwerfen, sofern ich Zeit finde). Die Wohnung ist leergeräumt und ich werde in Fuwa eigentlich nur noch erscheinen um meine Diplomarbeitspräsentation zu halten und um mein Diplom abzuholen.

Aber natürlich war nicht alles am Studium mitten im Schwarzwald schlecht (auch wenn es manchmal ziemlich öde war) und ich hab mir die letzten paar Semester etwas Zeit genommen um ein paar Eindrücke von diesem Fleckchen Erde festzuhalten.

"Verabschiedet" vollständig lesen »

Wieder gab es hier längere Zeit nichts zu hören und ich muss euch auch jetzt noch auf später vertrösten, obwohl ich eine ganze Menge im Kopf hab über das ich eigentlich bloggen möchte. Mein rechter Arm steckt im Gips und beherbergt momentan zwei Drähte die den Knochen zusammenhalten. Längere Texte zu tippen macht keinen wirklichen Spass und deshalb werde ich erstmal ein paar Wochen keine neuen Artikel schreiben. Aber keine Angst; aufgeschoben ist nicht aufgehoben.