Informatik
Miranda: Mein neuer und alter Instant Messenger
Miranda IM war der Instant Messenger, den ich jahrelang nutzte. Nur mit der Zeit wurde das Projekt Miranda IM immer inaktiver und die fehlenden Updates sorgten auch für ungelöste Probleme im Programm. Ich wollte also einen neuen Instant Messenger finden. Allerdings hatte ich Ansprüche für den Instant Messenger und das implizierte, dass ich eine Evaluation hätte durchführen müssen. In diesem Artikel schreibe ich einerseits davon, wie ich zu Miranda IM gekommen war, warum ich von Miranda IM weg wollte, welche anderen Instant Messenger ich mir genauer anschaute und welche wichtigen Punkte ich dort für mich bewertete und wie ich im Endeffekt von Miranda IM weg ging, aber jetzt immer noch Miranda benutze. Der Artikel setzt an manchen Stellen gewiss IT-Know-how voraus.
Server auf Gentoo migriert
Vermutlich ist die Downtime niemanden außer denen, die den Server nutzen, aufgefallen, aber ich habe meinen Root-Server hier nun auf Gentoo umgestellt. Zuvor lief auf dem Server Debian und das seit dem ich den Server bei Hetzner habe, November 2011.
Eigentlich hatte ich schon länger vor, irgendwas an der Distribution des Servers zu verändern und da der Server nichts mit Enterprise-Kram zu tun hat, hat man da ja auch eine gewisse Freiheit. Zuerst kam mir in den Sinn, von Debian stable einfach auf testing zu wechseln für aktuellere Pakete, nur geht bei so einem dist-upgrade gefühlt mehr kaputt als wenn man das Updaten seines Gentoo-Systems eine Weile vernachlässigt hat. Dazu habe ich erst kürzlich von Debian (testing) auf Gentoo gewechselt auf meinem Desktop-PC in meinem Betrieb – so aktuelle Software! Und Debian testing ist immer noch Debian:
- Binärpakete mögen schön schnell sein zum Installieren. Leider ist da dann alles drin und den meisten Kram braucht man nicht einmal. Gentoo bietet da eine wundervolle Flexibität mit seinen USE-Flags.
- Wenn man viele Pakete mit der Zeit installiert, müllt das System immer weiter zu. Zwar trifft das auch auf Gentoo zu, aber bei Debian kommt durch unnötige feste Abhängigkeiten viel, viel mehr dazu. Bei Gentoo steuern die USE-Flags zum Paket die Abhängigkeiten und nicht die Paketnamen.
- Wenn man Software vorbei kompiliert und installiert an APT, stellt sich ein Gefühl des Chaos ein. Vor allem gilt das für viel aktuellere Pakete als in Debian enthalten sind. Mit Portage (den Paketmanager von Gentoo) fällt das einfach weg, da jene Pakete, die ich dann auf Debian bisher manuell kompiliert habe, einfach in Portage drin sind – seien sie nun maskiert oder nicht.
- Portage bietet einfache Möglichkeiten, einzelne Pakete zu konfigurieren und auch mehrere Versionen eines Paketes gleichzeitig installiert haben zu können. Bei Debian?
- Durch das native Kompilieren der Pakete auf den Prozessor gilt Gentoo 2-5% schneller. Klingt doch gar nicht schlecht!
Das ein funktionierendes Gentoo bei einem Update, vor Allem auf einem Server, sogleich kaputt geht, ist nur dann korrekt, wenn man blind Pakete mit ihren Abhängigkeiten installiert. Aber das macht ja hoffentlich niemand. Und für einen »wichtigen« Server hat man in der Regel ja auch einen Testserver
Gleich dazu habe ich die Festplatten des Servers neu partitioniert. Da ich damals einfach das Debian von Hetzner nahm, hatte ich auch deren Partitionierung gehabt. Und ehrlich gesagt verstehe ich nicht, warum dieses Partitionierungsschema darauf abzielt, ~60% der Festplattenkapazität auf einem Server dem /home-Verzeichnis zu bemessen. Natürlich ist die größte Partition mit meinem Schema nun /var, wie es sich für einen Server gehört, wenn auch ich die Festplatten in all der Zeit bisher kaum nutzte. Ich hatte dann eine Menge Spaß mit dem Partitionieren auf der Konsole (da ich aus Faulheit gerne zu GParted greife) und dem Software-RAID 1.
Die Installation von Gentoo lief reibungslos. Wenn man sich mit Linux auskennt und Gentoo auch schon mehr als einmal installiert hat, ist das ja auch nicht so ein Problem. Natürlich dauert das Ganze trotzdem länger, als wenn man jetzt einfach ein Debian nehmen würde.
Ich habe jetzt jedenfalls das Gefühl, in etwa zu wissen, was auf dem Server läuft. Es ist nicht so wie bei Debian, wo – wenn ich die Liste der installierten Pakete anschaue – ich mich frage, wessen Paket eine Abhängigkeit zu irgendeinem anderen Paket hat, dessen Funktionalität ich gar nicht benötige. Das ganze System ist viel schlanker und alle Pakete sind viel aktueller.
Und schade um die 268 Tage Uptime. Aber das war es wert!
Quelle No-Debian Bild: Link
Python 3 und Django – Abenteuer MySQL
Es scheitert an der Datenbank…
Ich bin ein Freund von Python 3 und würde mir am liebsten wünschen, dass es Python 2 gar nicht mehr gäbe; so viel ist besser geworden in Python 3! Neuerdings gibt es ja Django 1.5 offiziell auf PyPi, welches ebenso offiziell experimentell Python 3 unterstützt.
Ich spielte also gestern Abend mit dem Gedanken, ein privates Webprojekt, an welchem ich momentan mit Pyramid schreibe, eventuell auf Django umzustellen. Pyramid ist ebenso ein größeres Python-Webframework, welches aber an sich nur Schnittstellen bereitstellt. So benutzt man beispielsweise als ORM dann SQLAlchemy und so etwas wie Standard-Models gibt es auch nicht. Das erfordert allerdings auch, dass man sich auch mit Pyramid beschäftigt – aber es lässt einem viele Freiheiten. Die Schnittstellen sind dabei aber sehr flexibel und Pyramid soll laut Benchmarks etwa ⅓ (Yay, Unicode!) schneller sein als Django. Im Vergleich dazu ist Django aber ohnehin mindestens doppelt so schnell wie Ruby on Rails – welches bei vielen Entwicklern ja feuchte Träume auslöst – und vor allem gegenüber Symfony2, wo ich irgendeinen Benchmark sah, wo Pyramid 12× so schnell ist wie Symfony2. Von daher denke ich, dass selbst Django als full-stack-Framework keine schlechte Wahl ist. Wer jetzt an das Argument denkt, dass Entwicklungsdauer viel wichtiger ist als eine Website, welche 50ms schneller reagiert, der kennt Python nicht.
Für mein eben erwähntes Webprojekt nutze ich momentan SQLAlchemy und MySQL über OurSQL. OurSQL ist eine schnelle API für Python um auf MySQL zugreifen zu können. Mit Python 2 gab es damals eine quasi Standard-API für MySQL namens MySQLdb, die es aber nicht für Python 3 gibt und es wohl auch nie geben wird. Natürlich gibt es noch viele weitere APIs für MySQL, aber mit OurSQL habe ich einfach die besten Erfahrungen gemacht und es läuft einfach auch sauber: Auf Linux ebenso wie auf Windows. SQLAlchemy hat da als Beispiel schon von Haus aus Bindungen für OurSQL. Bei Django sieht es da anders aus…
Man merkt bei Django 1.5 deutlich, dass es nach wie vor ein Python 2 Framework ist. Viel zu deutlich. So gibt es beispielsweise für MySQL nur Bindungen für MySQLdb, was ja, wie eben erwähnt, nicht mehr weiterentwickelt wird für Python 3. Und OurSQL? In der Tat gab es da auf Github ein Projekt, welches aber seit seit mindestens einem Jahr nicht mehr aktualisiert wurde. Ich probierte es dennoch aus und ich bekam den Eindruck, dass es für Django 1.1 geschrieben wurde, denn es funktionierte nichts kaum etwas. Gutmütig wie ich war, schaute ich mir die Codebasis von dem Modul an und versuchte, die Fehler zu korrigieren… Zumindest funktionierte dann schon einmal das Starten der Django-App, aber das war es dann auch schon wieder. Beim Anlegen der Datenbank durch Django gab es den nächsten Fehler und dann ging mir die Lust aus – ich habe keine Lust auf Frickelware.
Weiterhin gutmütig versuchte ich es mit einer anderen Datenbank-API namens PyMySQL. Allerdings ließ mich die Anzahl der Issues auf Github schon schmunzeln und ich wurde von meiner Vorstellung nicht getäuscht: Es war ebenso Frickelware. Dass das Projekt an sich erst einmal Python 2-Syntax hatte, war ja nicht das Problem – Python hat ja ein Script dafür, um Python 2 Code nach Python 3 zu portieren und das läuft ziemlich anständig. Nur brachte das alles nichts, denn beim Installieren über Distribute gab es irgendein Problem beim Deserialisieren. Da dieses Paket aber kein C Paket war, kopierte ich es einfach manuell nach site-packages. Was im Endeffekt aber nichts brachte, denn Django erkannte das Paket nicht und auch beim Ablauf in Django, wie Django das Modul einbindet, fragte ich mich, ob der Autor überhaupt das Richtige in seine Dokumentation geschrieben hat. Vermutlich hätte man mit mehr Frickelei das Ganze zum Laufen bekommen, aber ich hatte darauf nun keine Lust mehr.
Und somit bleibe ich webtechnisch mit Python beim Web-Framework Pyramid. Vielleicht schafft es ja Django in Zukunft, sich mehr auf Python 3 auszurichten. Nur bis das geschehen ist, habe ich dieses Webprojekt wohl längst fertig.