Zur Version mit Bildern
freiesMagazin September 2011 (ISSN 1867-7991)
Topthemen dieser Ausgabe
Plattformen für die Entwicklung und Verwaltung von Open-Source-Projekten
Beim Erlernen einer Programmiersprache macht man sich gewöhnlicherweise wenig Gedanken über eine Versionsverwaltung. Mit zunehmendem Fortschritt gelangt man jedoch häufig an einen Punkt, an dem man nicht mehr für sich alleine ein Projekt entwickelt. Besonders die Open-Source-Gemeinde ist dabei auf die Mitarbeit der Gemeinschaft aus aller Welt angewiesen. (weiterlesen)
„I don't like spam“, oder wie man einen Mailserver testet
Es begann mit einem Irrtum. Im Werbebrief vom Google für den AdWords-Dienst befand sich ein Gutschein über 75 Euro, der auf einen völlig fremden Menschen ausgestellt war. Wenn man Sandra Fründt, Head of Business Marketing Google Deutschland, auf ihren Fehler aufmerksam machen will, stößt man auf ein Problem: Im Schreiben ist überhaupt keine E-Mail-Adresse angegeben. Die Frage ist: Wie findet man die E-Mail-Adresse heraus und kann dazu noch testen, ob sie existiert? (weiterlesen)
i3 – ein Tiling Fenstermanager
Fenstermanager gibt es viele, die bekanntesten sind wohl Metacity (GNOME 2), KWin (KDE) oder Compiz. Diese Fenstermanager verfolgen alle ein ähnliches Konzept: Die Fenster liegen relativ ungeordnet auf dem Bildschirm und können überall hin verschoben werden. Tiling Fenstermanager – wie i3 – bauen auf einem anderen Konzept auf: Diese behandeln den Bildschirm wie eine Art Tabelle. Dadurch sind die Fenster (bis auf Ausnahmen) an einem festen Platz und können durch Tastenkombinationen in andere Positionen gebracht werden. (weiterlesen)
Zum Index
Linux allgemein
Plattformen für die Entwicklung und Verwaltung von Open-Source-Projekten
Trinity – Desktop ohne Zukunft
Der August im Kernelrückblick
Anleitungen
Wie man einen Mailserver testet
Perl-Tutorium: Teil 2
Software
i3 – ein Tiling Fenstermanager
Cassandra – Die Datenbank hinter Facebook
Community
Rezension: The Python Standard Library
Rezension: Python von Kopf bis Fuß
Magazin
Editorial
Leserbriefe
Veranstaltungen
Konventionen
Impressum
Zum Index
Mehret und teilet Euch
freiesMagazin vergrößert sich
Letzten Monat riefen wir auf unserer Webseite [1]
und natürlich auch im Editorial der freiesMagazin-Ausgabe 08/2011 [2]
zur Unterstützung unseres Teams auf. Gesucht waren Layouter, Korrektoren
und Autoren.
In den ersten beiden Kategorien hatten wir viele Zuschriften, sodass
wir das Team entsprechend aufstocken konnten. Acht neue Mitglieder
hat freiesMagazin dazu gewonnen, die uns nun tatkräftig unterstützen und
die alten Teammitglieder entsprechend entlasten. Die Alteingesessenen
werden den „Noobs“ aber natürlich ebenfalls mit Rat und Tat zur
Seite stehen.
Autoren werden aber natürlich auch weiterhin gesucht. Derzeit
erkennen wir bei geplanten Artikeln einen sehr starken Hang zu
Programmierthemen. Sicherlich ist ein Großteil unserer Leser
irgendwie mit Programmiersprachen in Kontakt, sodass sich die
meisten dafür begeistern können. Dennoch wollen wir auch etwas
Abwechslung bieten, sodass jeder dazu aufgerufen ist, das Magazin
mitzugestalten. freiesMagazin lebt von den Inhalten, die von den Lesern
für die Leser geschrieben werden.
freiesMagazin teilt sich
Ein Leser fragte uns kürzlich, ob man die Artikel im Magazin auch
einzeln als PDF herunterladen kann. Bisher ist so etwas nicht möglich,
auch wenn sich natürlich jeder mit pdftk (siehe freiesMagazin 03/2009 [3])
oder per Druckdialog seine Lieblingsthemen selbst speichern kann.
Dennoch möchten wir wissen, ob der Wunsch bei den Lesern überhaupt
da ist, das PDF in einzelnen Teilen direkt herunterladen zu können.
Aus dem Grund haben wir eine Umfrage gestartet [4].
Dabei kam dann auch gleich die Frage auf, ob man die HTML-Mobilversion
ebenfalls nicht besser in einzelne Seiten aufspaltet und nicht mehr
als ganzes anbietet. Dies würde dann eine direkte Verlinkung leichter
machen und spart auch etwas Ladezeit. Zusätzlich kann man diese
Versionen dann leichter drucken, wenn man nur an einem Thema
interessiert ist.
Wir sind gespannt auf Ihre Antworten
und wünschen Ihnen nun viel Spaß mit der Ausgabe.
Ihre freiesMagazin-Redaktion
Links
[1] http://www.freiesmagazin.de/20110725-freiesmagazin-sucht-unterstuetzung
[2] http://www.freiesmagazin.de/freiesMagazin-2011-08
[3] http://www.freiesmagazin.de/freiesMagazin-2009-03
[4] http://www.freiesmagazin.de/20110828-sollen-artikel-einzeln-abrufbar-sein
Das Editorial kommentieren
Zum Index
von Patrick Meyhöfer
Beim Erlernen einer Programmiersprache macht man sich gewöhnlicherweise
wenig Gedanken über eine Versionsverwaltung. Mit zunehmendem Fortschritt
gelangt man jedoch häufig an einen Punkt, an dem man nicht mehr für sich
alleine ein Projekt entwickelt. Besonders die Open-Source-Gemeinde ist dabei
auf die Mitarbeit der Gemeinschaft aus aller Welt angewiesen.
In der Regel kann ein Versionsverwaltungssystem wie CVS, SVN, Git oder Mercurial,
um nur
einige zu nennen, auch einfach über die Paketverwaltung
auf dem eigenen System installiert und genutzt werden. Der Reiz der
nachfolgenden Plattformen ist jedoch, dass diese weltweit über das Internet
von jedem Entwickler und potentiell interessiertem Nutzer erreichbar sind
und einige interessante Zusatzfunktionen bieten.
SourceForge
Eine der ältesten (1999 gegründet) und am meisten genutzten Plattformen mit
über 300.000
Projekten und mehr als 2 Millionen registrierten Benutzern
ist SourceForge [1].
Viele bekannte Programme hosten ihren Quelltext
dort, z. B. Inkscape, FileZilla, Pidgin u. v. m.
Funktionen
Schaut man sich die umfangreichen
Funktionen [2]
von SourceForge näher an, bemerkt man, dass bereits fast alles vorhanden ist,
was man sich als Entwickler so vorstellen kann:
- unterstützt werden Git, Mercurial und SVN
- zentrales Verzeichnis (engl. Repository) des gesamten Quelltextes und
weiterer Dokumente, sowie Mailinglisten, Foren und Diskussionsbeiträge
- Berechtigungsvergabe
- detaillierte Statistiken
- Ticketsystem für Fehlermeldungen
Registrierung und Erstellung eines Projektes
Die Registrierung läuft problemlos und schnell ab. Da es heute bereits fast
zum guten Ton gehört, bietet auch SourceForge eine Registrierung über OAuth
an, sodass man nicht das Registrierungsformular ausfüllen muss, sondern sich
über Anbieter wie Google oder Yahoo, nach einer kurzen Bestätigung auf
SourceForge anmelden kann.
Ein Projekt ist nach der Anmeldung sehr schnell erstellt. Man vergibt einen
Projektnamen und eine URL, unter der das Projekt erreichbar ist.
Zusätzlich kann man verschiedene Optionen auswählen, wobei die Verwendung
des Versionssystems eine der wichtigsten Entscheidungen ist. Sind alle
Einstellungen erledigt, landet man in dem optisch gut gestalteten
Admin-Bereich.
Ab da kann man mit der Verwaltung des Projektes beginnen, u. a. mit dem
Einblick in offene Tickets, dem Schreiben von Wikiseiten, dem Einsehen von
Statistiken usw.
Google code
Ebenfalls sehr beliebt ist die Plattform Google code [3].
Google nutzt die Plattform als seine zentrale Basis für die Entwicklung des
Smartphone-Betriebssystems Android oder für das Google Web Toolkit. Zudem bietet
es aber allen Entwicklern von Open-Source-Projekten ebenfalls eine Möglichkeit,
ihr Projekt zu veröffentlichen und zu verwalten.
Funktionen
Etwas weniger umfangreich als SourceForge, aber doch mit allen nötigen
Funktionen, die man zum Grundumfang zählen sollte, kann auch Google code
aufwarten.
So stellt Google folgende Funktionen bereit:
- zentrales Verzeichnis (engl. Repository) des gesamten Quelltextes und
weiterer Dokumente
- 2 GB Speicherplatz für Dateien im Verzeichnisbaum und
2GB im Downloadbereich
- unterstützt werden Git, Mercurial und SVN
- Dateien online bearbeiten inklusive
Syntax-Hervorhebung (wurde extra für Chrome OS eingeführt)
- Wiki
- Ticketsystem für Fehlermeldungen
Vor kurzem erst ist das Versionskontrollsystem Git hinzugekommen, Google
bietet jedoch auch eine Portierung von SVN nach Git
an [4].
Registrierung und Erstellung eines Projektes
Sofern man einen Google-Account sein Eigen nennt, benötigt man keine weitere
Registrierung und kann direkt auf der Einstiegsseite ein neues Projekt
erstellen.
Es werden, ähnlich wie bei SourceForge, lediglich einige wenige
Standardinformationen abgefragt. Man sollte allerdings, wie bei fast allen
Plattformen, der englischen Sprache zumindest grundlegend mächtig
sein, da die Seiten selten ins Deutsche übersetzt sind.
Anschließend landet man im Admin-Bereich, der Google-typisch recht schlicht
und im klassischen Design gehalten ist.
GitHub
Mit der wachsenden Beliebtheit von Git als verteiltes, dezentrales System
(d. h. man benötigt nicht zwingend einen Server) findet GitHub [5]
immer größeren Zuspruch [6].
Laut eigener Aussage nutzen bereits über 900.000 angemeldete Benutzer GitHub.
Im Gegensatz zu SourceForge oder Google code bietet GitHub auch Hosting
gegen Bezahlung an, sofern das entwickelte Projekt keine Open-Source-Lizenz
besitzt. Für alle quelloffenen Projekte ist die Plattform jedoch kostenlos.
Einige sehr bekannte Projekte, die ihre Quelltexte auf GitHub verwalten sind
z. B. jQuery, PHP und Perl.
Funktionen
Im Vergleich zu den bereits vorgestellten Plattformen steht auch GitHub in
Sachen Funktionalität nicht nach. So bietet GitHub:
- zentrales Verzeichnis (Repository) des gesamten Quelltextes und
weiterer Dokumente
- Quelltext-Management nur mit Git
- Dateien online bearbeiten, inklusive Syntax-Hervorhebung
- Wiki
- Ticketsystem für Fehlermeldungen
GitHub ist bestrebt, eine Plattform anzubieten, auf der die Nutzer
untereinander interagieren, ein sogenanntes „social coding“.
Dies bedeutet,
dass Kommentare bei den Quelltexten möglich sind und dass man
unterschiedlichen Entwicklern bei ihren Projekten verfolgen kann. Es ist
ausdrücklich gewünscht auch mit dem Entwickler
in den Kontakt zu treten, um
einen Meinungsaustausch zu ermöglichen.
Registrierung und Erstellung eines Projektes
Bei der Registrierung muss man sich entscheiden, ob man einen kostenlosen
Account anlegt, der dann nur für Open-Source-Projekte
genutzt werden darf oder verschiedene
andere Preismodelle nutzt. Es werden bei der
Anmeldung nur Benutzername, E-Mail-Adresse und das Passwort für die Registrierung benötigt.
Die Prozedur im Anschluss ist analog zu oben bereits beschriebenem Vorgehen:
Projekt nach dem Login erstellen und man gelangt zum Adminbereich.
Alternativen in der Kurzübersicht
Die drei aufgeführten Plattformen sind meiner Meinung nach die
populärsten und meist genutzten Angebote in der FOSS-Gemeinschaft.
Wer bisher noch keine passende Plattform in diesem Beitrag gefunden hat,
sollte sich einmal folgende Alternativen näher ansehen:
- Gitorious [7] – als Alternative zu GitHub
- Launchpad [8] – besonders bei der Ubuntu-Entwicklung
interessant und viel genutzt (PPA erstellen etc.); nutzt Bazaar
- Codeplex [9] – von Microsoft, vorwiegend für
die .NET-Entwicklung genutzt
- Bitbucket [10] – für Mercurial-Projekte
- BerliOS [11] vom Fraunhofer-Institut betrieben und
durch öffentliche Gelder gefördert
- JavaForge [12] – läuft auf der Amazon Cloud
Fazit
Wer einen guten und verlässlichen Dienst für seine Entwicklung sucht, ist
mit allen Diensten gut bedient. Für kleinere und mittlere Projekte bietet
sich meiner Meinung nach Google code an, da es eine sehr übersichtliche
und schnelle Benutzerschnittstelle bietet. Der Registrierungsprozess, wenn
man noch kein Google-Konto besitzt, ist allerdings der aufwändigste.
Legt man mehr Wert auf große Funktionsvielfalt und der jahrelangen
Erfahrung, ist man mit großen Projekten bei SourceForge besser aufgehoben.
Der neue Trend für alle, die auf Git setzen, scheint derzeit GitHub zu sein.
Das relativ junge Projekt mit dem neuartigen Ansatz scheint für die Zukunft
ebenfalls gerüstet.
Möchte man keinem fremden Dienst seine Quelltexte anvertrauen, so ist als
Alternative auch ein eigens aufgesetzter Server möglich, der verhältnismäßig
schnell eingerichtet ist.
Links
[1] http://sourceforge.net/
[2] http://sourceforge.net/apps/trac/sourceforge/wiki/WikiStart#HostingwithSourceForge.net
[3] http://code.google.com/hosting/
[4] http://www.linux-magazin.de/NEWS/Google-gibt-Git-Support-fuer-Google-Code-bekannt
[5] https://github.com/
[6] http://www.heise.de/developer/meldung/Microsoft-Open-Source-Entwickler-bevorzugen-Code
[7] http://gitorious.org/
[8] https://launchpad.net/
[9] http://www.codeplex.com/
[10] https://bitbucket.org/
[11] http://www.berlios.de/
[12] http://www.javaforge.com/project/11
[13] http://redmonk.com/sogrady/2011/06/02/blackduck-webinar/
[14] http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilitie
[15] http://www.netzwelt.de/news/87291_2-einfuehrung-dezentrale-versionsverwaltung-programm-git.html
Autoreninformation |
Patrick Meyhöfer (Webseite)
ist durch sein Studium auf die verschiedenen
Versionskontrollsysteme aufmerksam geworden und hat seitdem viele
Hostingangebote für Open-Source-Software getestet.
|
|
Diesen Artikel kommentieren
Zum Index
von Martin Gäßlin
Das Trinity Desktop Environment [1] ist ein
von Timothy Pearson ins Leben gerufener
Fork [2]
der Desktopumgebung KDE 3.5. In diesem Artikel wird aus Sicht eines
KDE4-Entwicklers dargestellt, wieso das Projekt keine Zukunft hat.
Was ist Trinity?
Trinity startete anfangs mit einigen Codeänderungen an KDE 3.5,
die für ein weiteres KDE 3.5.11 vorgeschlagen wurden, nachdem die
ersten Releases der moderneren 4.x-Serie bereits erfolgt
waren [3].
Dies wurde von vielen KDE-Entwicklern mit Unverständnis
aufgenommen [4]
und vom Release Team wurde klargestellt, dass es keine weiteren
Releases für KDE 3.5 geben wird und der Branch für Feature-Entwicklung
geschlossen ist [5].
Des Weiteren wurde es als Problem angesehen, dass der Code nicht von
den Hauptentwicklern begutachtet wurde und deshalb, um
Verwechslungen zu vermeiden, nicht den Namen „KDE“ verwenden
sollte [6].
Dies führte im März 2010 dann zur ersten Veröffentlichung von
Trinity mit der Versionsnummer 3.5.11 [7].
Trinity startete mit dem Code von KDE 3.5.10 und integrierte eigene
Patches und Patches von verschiedenen Distributionen, die zu diesem
Zeitpunkt KDE 3.5 noch im Angebot hatten. Trinity lebt als eigener
Branch in den KDE-Repositories [8].
Man könnte also sagen, dass Trinity den „Segen“ von KDE erhalten hat,
3.5 zu forken.
Geschichtlicher Abriss
KDE 3.5 erblickte im November 2005, vor mehr als fünf Jahren, das
Licht der Welt. Seitdem wurden nur noch Maintenance-Releases
veröffentlicht, welche mit 3.5.10 im August 2008, also etwa drei
Jahre nach dem ersten Release, eingestellt wurden. Das 3.5-Release
wurde von der Community als letzte Veröffentlichung der 3.x-Serie
geplant und in dem Release Announcement findet sich bereits der
Hinweis, dass die nächste Version KDE 4 sein
wird [9]. Über die
APPEAL-Meetings [10]
wurde die Richtung ausgearbeitet, in welche die zukünftige Entwicklung
weitergehen sollte. Dies zeigte sich auch auf der
Entwicklerkonferenz aKademy 2005 in Malaga, bei der KDE4 das große
Thema war [11].
Nun entscheidet sich eine Entwickler-Community wie KDE mit hunderten
von Entwicklern nicht einfach so aus Spaß für ein Projekt wie KDE4
und die großen Änderungen, die damit einhergingen. Hierfür muss es
triftige Gründe geben. Einer davon war, dass im Juni 2005
die erste Version von Qt 4 veröffentlicht wurde und KDE 3.5 noch
auf Qt 3 aufbaute. Qt 4 stellte einen größeren Umbruch dar, bei dem
es mit einfachem Neu-Kompilieren nicht getan ist. Vieles muss
konzeptionell anders angegangen werden, was im Endeffekt zu einem
Neuschreiben großer Teile der GUI Schicht führt.
In vielen Bereichen erkannten die Maintainer, also die Entwickler,
die den Code am besten kennen, dass die Quellcodebasis sich nicht
dafür eignet eine Plattform zu schaffen, um die Entwicklung über das
nächste Jahrzehnt zu tragen. Dies führte zur Einstellung einiger
Komponenten und zum Neuschreiben von Anwendungen und Frameworks.
Das populärste Beispiel dafür dürfte das von Aaron Seigo, damals
Maintainer der KDE-Kontrollleiste Kicker, initiierte Projekt des
Plasma Desktops [12]
sein, der sowohl Kicker, KDesktop als auch Superkaramba ersetzen
sollte. Kicker zeigte nicht die Flexibilität, die erwünscht war. So
war Kicker eine Kontrolleiste und egal, wie viele Schalter man
bewegte, es blieb eine Kontrollleiste. Plasma hingegen ist
heutzutage ein flexibles Framework zum Erstellen individueller
Workspaces, wie im Artikel „Plasma erobert die Welt“ in freiesMagazin
01/2011 [13]
dargestellt wurde. Ein Ziel war es, bei der Entwicklung nie wieder in eine
Situation zu kommen, den Desktop komplett wegschmeißen und
reimplementieren zu müssen. Betrachtet man aktuell die Aktivitäten
bezüglich Applets in QML und der Umstellung auf
libplasma2 [14],
so ist offensichtlich, dass dieses Ziel erreicht wurde.
Wem ist geholfen mit Trinity?
Mittlerweile liegt KDE Plasma mit dem Ende Juli veröffentlichten KDE
Plasma Workspaces 4.7 in der achten Inkarnation vor. Die
Funktionalität der alten Anwendungen Kicker, KDesktop und
Superkaramba ist bis auf wenige kleine Ausnahmen vollkommen
implementiert. Zusätzlich gibt es hunderte von Funktionen, die
mit dem alten Framework nicht möglich gewesen wären. Über die
Themeingfunktionalität und die vielseitigen
Einstellungsmöglichkeiten lässt sich auch sehr leicht ein Desktop
nachbauen, der aussieht und sich verhält wie KDE 3.5.
Natürlich steht es jedem Anwender frei, zu nutzen, was er will und
jedem Entwickler, zu arbeiten, woran er will. Das ist ja gerade der
Vorteil Freier Software. Gäbe es genügend Entwickler, die mit
den Entwicklungen von KDE 4 nicht einverstanden gewesen wären, so
hätte KDE 3.5 weiterentwickelt werden können. Dies war aber nicht
der Fall und somit stellt sich die Frage, wem mit Trinity geholfen
ist, wenn mit wenigen Einstellungsveränderungen auch das „KDE3.5
computing style“ erhalten werden kann, wie es das Ziel von Trinity
ist [15]. Geht es nur darum,
Kicker, KDesktop und Superkaramba unabhängig von KDE Plasma als
Desktopumgebung zu erhalten, stellt sich die Frage, warum dann das
komplette KDE 3.5 geforkt wurde. Nicht alle Bereiche des Desktops
wurden neu geschrieben, viele Anwendungen auch inkrementell
weiterentwickelt ohne Verlust von bestehender Funktionalität, wie
beispielsweise der Fenstermanager KWin.
Die Funktionalität von Trinity ist durch den in KDE 3.5 vorgegebenen
Feature Freeze auf dem Stand von 2005 eingefroren. Das betrifft
alle Komponenten. So muss man sich doch fragen, was man zum
Beispiel mit einem Webbrowser (Konqueror) und Rendering-Engine
(KHTML/KJS) will, der die letzte Funktionalität weit vor dem Start
von HTML 5 oder der heutzutage weit verbreitesten JavaScript-Bibliothek
jQuery [16] erhalten
hat? Bei solchen Komponenten wäre es doch eigentlich sinnvoller, die
neuere Komponenten zu verwenden, allein schon, um die Bugfixes
zu erhalten.
Selbstverständlich hatte KDE 3.5 auch Bugs, sonst hätte es ja keinen
Bedarf für 10 Minor Releases gegeben. Auch mit KDE 3.5.10
wurden nicht alle offenen Fehler beseitigt und in den weiterhin
bestehenden Komponenten wurden in den 4.x-Releases viele Fehler
behoben, die auch schon in KDE 3.5 präsent waren. Da 3.5 aber von
den Entwicklern verlassen wurde, werden solche Bugfixes nicht
zurückportiert. In vielen Fällen sind die aktuellen Entwickler erst
nach KDE 3.5 hinzugestoßen und haben selbst nie an KDE 3.5
entwickelt. Durch Umstellung des Build-Systems von
autotools [17] auf
CMake [18] ist es auch nicht
leicht, mal eben schnell einen Patch unter KDE 3.5 zu testen. Hinzu
kommt, dass die Entwickler nicht wissen, ob Fehler in 3.5 auch
bestanden, und es werden kaum noch Fehler für 3.5 gemeldet.
Für die Trinity-Entwickler ist es somit nicht einfach,
Änderungen bei weiterbestehenden Komponenten aus der 4.x-Serie
nach Trinity zurückzuportieren. Die Nutzer von Trinity müssen
weiterhin mit den alten und zum Teil seit Jahren behobenen Fehlern
leben.
Problem der Abhängigkeiten
Die grundsätzlichen Probleme, die zur Entwicklung der 4.x-Serie
führte, bestehen natürlich auch für Trinity. Qt 3 hat sein
End-of-life vor Jahren erreicht [19],
und um zukunftssicher zu bleiben, muss Trinity auf Qt 4 umstellen.
Die Debian-Qt/KDE-Maintainer planen Qt 3 in Wheezy nicht mehr
bereitzustellen [20].
Der grundsätzliche Aufwand zur Portierung auf Qt 4 ist natürlich
für Trinity genauso vorhanden, wie er für die KDE-Community
bestand. Zwar bietet Qt 4 eine Kompatibilitätsschicht an, jedoch
wird diese mit Qt 5 entfernt, das sich bereits in Entwicklung
befindet. Um zukunftssicher zu bleiben, muss Trinity einen
kompletten Port durchführen, der in vielen Teilen zu einem Rewrite
führen wird, wie er auch für KDE 4.x nötig war. In all den
Bereichen, in denen die Anwendungen weiterleben, stellt sich die
Frage, warum man erneut durchführt, was bereits durchgeführt wurde?
Warum zweimal auf Qt 4 portieren mit all den Problemen, die das mit
sich bringt?
Aber natürlich ist nicht nur Qt ein Abhängigkeitsproblem. Der
komplette Linux-Stack befindet sich in ständiger Bewegung und eine
einzige Komponente einzufrieren, ist kaum möglich. So verwendet
Trinity noch HAL [21],
obwohl fast alle Distributionen HAL entfernen, da es von niemandem
mehr verwendet wird und die Funktionalität in den Linux-Kernel
verlagert wurde. So besteht ständig die Gefahr, dass der Stack sich
in eine Richtung bewegt, die es unmöglich macht, Trinity ohne
Anpassungen zu verwenden. So findet man auch in der
Trinity-Roadmap [22]
hauptsächlich Aufgaben in diesem Bereich. Aufgaben, um das tote KDE
3.5 irgendwie mit einem neueren Stack am Leben zu erhalten. Neue
Funktionen kommen dadurch noch nicht hinzu und das
Regressionspotential ist selbstverständlich sehr hoch.
Manpower
Die KDE Community besteht heutzutage aus hunderten von Entwicklern,
die spezialisiert an einem Bereich arbeiten. Es gibt kaum
Entwickler, die über alle Bereiche hinweg wirken. Dies ist auch
logisch: Man spezialisiert sich und kann nicht qualifiziert in
anderen Bereichen entwickeln. Ein Workspace-Entwickler wird somit
nicht in der Lage sein, konstruktiv zu KDEPIM beizutragen. Für
Trinity gilt natürlich das Gleiche. Die Entwicklergemeinschaft an
Trinity müsste ähnlich groß sein wie die von KDE. Jedoch kann man,
wenn man sich den SVN Log anschaut, die aktiven Trinity-Entwickler
an einer Hand abzählen. Dies ist natürlich keine Ausgangsbasis, um
eine Desktopumgebung zu entwickeln. Natürlich besteht immer die
Hoffnung, neue Entwickler anzuwerben. Das dürfte aber bei einer
Codebasis, die von den ursprünglichen Entwicklern aufgegeben wurde,
schwierig sein. Auch müssten unabhängige Entwickler sehr schnell
wieder zum gleichen Schluss kommen, wie die KDE-Entwickler: Die
Basis eignet sich nicht, um sie weiterzuentwickeln, ein Rewrite ist
erforderlich.
KDE trennt die Aufgaben der Software-Entwicklung und Paketierung.
Die KDE-Community stellt nur Quellcode zur Verfügung und die
Distributionen erstellen daraus Pakete. In Trinity ist dies nicht
der Fall, die Entwickler müssen auch eigene
Paketquellen [23] pflegen.
Der Aufwand wird dabei ständig wachsen, beispielsweise durch das
Entfernen Qt 3 aus den offiziellen Paketquellen.
Aber nicht nur Entwickler und Paketbauer werden benötigt, auch
Übersetzer. Bereits seit Mai 2009 wurden die Übersetzungen für KDE 3.5
eingestellt [24].
Das automatisierte Übersetzungssystem in der KDE-Infrastruktur
berücksichtigt nur noch aktuelle Releases, womit Trinity ein
eigenes Übersetzungssystem einführen müsste und eigene Übersetzer
finden muss. Das ist kein leichtes Unterfangen, wenn man sieht, dass
selbst stark genutzte Software, wie die der KDE-Community,
Probleme hat, Übersetzer für alle Sprachen zu finden.
Qualität
Als letzter Punkt soll die Qualität betrachtet werden. Die KDE-Community
legt hohen Wert auf Codequalität. Dazu gibt es statische Code
Checker [25], welche einfach zu behebende Fehler aufdecken.
Diese Checks schließen den Trinity-Branch nicht mit ein und sind zudem an Qt 4
angepasst. Codeänderungen in KDE werden immer im
Peer-Review-Verfahren [26]
begutachtet. Für größere Änderungen gibt es eine
ReviewBoard-Instanz [27] und diese vorgeschlagenen
Änderungen werden mit der Community über die Mailinglisten diskutiert.
Für triviale Änderungen, die nicht über ReviewBoard laufen, erfolgt
zumindest ein Post-Commit-Review durch die Maintainer. Continuous
Integration und eine große Anzahl von Entwicklern und Testern, die
tagtäglich den neuesten Stand von KDE-Software in ihrem produktiven
Arbeitsumfeld einsetzen, stellen sicher, dass die Software nicht von
Regressionen heimgesucht wird.
Bei Trinity gibt es jedoch keinen Code-Review. Wer sollte es auch reviewen?
Die Software ist ohne Maintainer und es gibt niemanden mehr, der sich
verlässlich mit dem Code auskennt. Änderungen in dem Umfang einer Portierung von Qt 3 nach Qt 4 sind daher sehr gefährlich. Es gibt nicht
nur keine Reviews, sondern auch keine gute Commit Policy. In Trinity
wurde eine Vielzahl an Bulk-Änderungen vorgenommen. So zum Beispiel eine
Menge an Änderungen [28]
als Bugfixes vom Chakra-Projekt. Ob dies wirklich Bugfixes waren oder nicht,
ist schwer zu beurteilen. Die Änderungen betreffen zum Beispiel den
Fenstermanager KWin, aber die Entwickler wurden nie um ein Review gebeten.
Dies schließt Dateien ein, die essentielles Verhalten wie die Stackingorder
betreffen. Fehler in diesem Bereich sind schwer zu bemerken und noch
schwieriger zu finden. Die Entwicklung dieser Komponente ist abgeschlossen
und die Anzahl an Änderungen vom KWin-Team ist sehr gering. Kann man davon
ausgehen, dass die Trinity-Entwickler diese zentrale, schwer zu verstehende
Komponente so gut beherrschen, dass sie ohne Hilfe Änderungen vornehmen können?
Richtig gefährlich wird es aber, wenn die Trinity-Entwickler
Änderungen an Komponenten mit ABI-Versprechen vornehmen. In einem
der „Bugfixes“ von Chakra findet sich eine Änderung an einer Header
Datei für die Fensterdekorationen [29].
Diese Änderung bricht die binäre Schnittstelle der Fensterdekorations-API. Eine für KDE 3.2+ kompilierte Fensterdekoration wird mit
Trinity nicht mehr funktionieren. In diesem Fall würde dies nur zu
einem Laufzeitfehler führen, bei Änderungen zur Umstellung auf Qt 4
jedoch zu einer kompletten inkompatiblen ABI und API [30].
Das Ergebnis ist, dass der Fenstermanager beim Starten direkt
abstürzt, wenn eine 3rd-Party-Dekoration verwendet wird. Die
KDE-Entwickler hatten bei ihrer Portierung nach Qt 4
sichergestellt, dass eine binärinkompatible Fensterdekoration nicht
geladen wird. Dieses domainspezifische Wissen haben die
Trinity-Entwickler verständlicherweise nicht.
Fazit
Gut gemeint ist nicht immer gut gemacht. Trinity mag gut gemeint
sein und enttäuschten Nutzern „ihr“ KDE 3.5 zurückgeben. Die
Illusion, dass Trinity KDE 3.5 am Leben erhalten kann, muss man den
Nutzern aber nehmen. Möchte Trinity nur den Desktop am Leben
erhalten, wird viel zu viel Code angefasst, was zwangsläufig zu
Fehlern führen wird. Zukunftssicher ist und kann Trinity mit der
aktuellen Manpower nicht sein.
Anwendern, die mit KDE Plasma nicht zurechtkommen, ist
wahrscheinlich eher mit einer anderen Desktopumgebung oder Distribution geholfen, die noch KDE 3.5 unterstützt
(z. B. Debian Lenny). Hierbei ist garantiert, dass zumindest
Sicherheitsupdates zur Verfügung gestellt werden und Funktionalität
nicht zerstört wird.
Links
[1] http://trinitydesktop.org/
[2] http://de.wikipedia.org/wiki/Abspaltung_(Softwareentwicklung)
[3] http://lists.kde.org/?l=kde-devel&m=125857018413079&w=2
[4] http://lists.kde.org/?l=kde-devel&m=125858829212077&w=2
[5] http://lists.kde.org/?l=kde-devel&m=125857983730550&w=2
[6] http://lists.kde.org/?l=kde-devel&m=125858816411879&w=2
[7] http://www.pro-linux.de/news/1/15731/trinity-projekt-fuehrt-kde-3-fort.html
[8] http://websvn.kde.org/branches/trinity/
[9] http://www.kde.org/announcements/announce-3.5.php
[10] http://dot.kde.org/2005/04/05/appeal-meeting-springtime-berlin
[11] http://conference2005.kde.org/sched-devconf.php
[12] http://aseigo.blogspot.com/2005/06/plasma.html
[13] http://www.freiesmagazin.de/freiesMagazin-2011-01
[14] http://aseigo.blogspot.com/2011/05/libplasma2.html
[15] http://trinitydesktop.org/about.php
[16] http://en.wikipedia.org/wiki/Jquery
[17] http://en.wikipedia.org/wiki/Autotools
[18] http://en.wikipedia.org/wiki/Cmake
[19] http://qt.nokia.com/about/news/archive/press.2007-01-22.4604809587/
[20] http://lists.debian.org/debian-devel/2011/05/msg00236.html
[21] http://en.wikipedia.org/wiki/HAL_(software)
[22] http://trinitydesktop.org/wiki/bin/view/Developers/RoadMap
[23] http://trinitydesktop.org/installation.php
[24] http://osdir.com/ml/release-team/2009-06/msg00048.html
[25] http://quality.kde.org)
[26] https://secure.wikimedia.org/wikipedia/de/wiki/Peer-Review
[27] http://reviewboard.kde.org/
[28] http://websvn.kde.org/?view=revision&revision=1172677
[29] http://websvn.kde.org/branches/trinity/kdebase/kwin/lib/kdecoration.h?r1=1172677&r2=1172676&pathrev=1172677
[30] http://websvn.kde.org/branches/trinity/kdebase/kwin/lib/kdecoration.h?r1=1212480&r2=1215552
Autoreninformation |
Martin Gräßlin (Webseite)
ist erst mit der 4.x Serie von KDE als Entwickler dazugestoßen und
heute Maintainer des Fenstermanagers KWin.
|
|
Diesen Artikel kommentieren
Zum Index
von Mathias Menzer
Basis aller Distributionen ist der Linux-Kernel, der fortwährend weiterentwickelt wird. Welche Geräte in einem halben Jahr unterstützt werden und welche Funktionen neu hinzukommen, erfährt man, wenn man den aktuellen Entwickler-Kernel im Auge behält.
Linux 3.1 veröffentlicht
Etwas mehr als zwei Wochen nach Freigabe des Kernels 3.0 präsentierte Torvalds die erste Vorabversion des Nachfolgers [1]. Es fand sich kein großer Wurf unter den eingebrachten Änderungen, womit sich bereits andeutet, dass 3.1 ähnlich seinem Vorgänger das Konzept des kleinen, stetigen Fortschritts weiterführt. Dennoch wurde kräftig an der Virtualisierungslösung KVM geschraubt, es gab auch Anpassungen an der Speicherschnittstelle iommu. Gerade im Treiber-Bereich kam einiges hinzu, zum Beispiel bei den Video-und DVB-Treibern, aber auch der Netzwerk-Teil erfuhr umfassende Änderungen. Am Treiber der GPIO-Schnittstelle (General Purpose Input/Output, Mehrzweck-Ein/Ausgabe) wurde scheinbar viel getan, tatsächlich wurden jedoch nur Dateien umbenannt, sodass ein großes Volumen an Änderungen zusammen kam.
3.1-rc2 [2] war noch weniger spektakulär, weshalb Torvalds gleich unterstellte, dass die Entwickler entweder faul oder im Urlaub seien. Immerhin gab es einen neuen Namen für den Kernel: „Wet Seal“ („nasse Robbe“). Der folgende -rc3 [3] passte ebenfalls in Torvalds Traum vom ruhigen Entwicklungszyklus, sodass er sich gleich dafür bei den Entwicklern bedankte – zu früh, wie sich zur vierten Vorabversion abzeichnete [4]: Waren die Änderungen an xfs noch überwiegend kosmetischer Natur, wurden hier fast alle Komponenten verschoben, was sich sehr stark auf die Zahl der geänderten Zeilen auswirkte. Daneben sehen die Änderungen zum Beispiel am wiimote-Treiber unscheinbar aus, sind mit über 250 geänderten Zeilen für einen -rc4 jedoch ein ganz schöner Batzen. Ähnlich sieht es auch beim target-Treiber aus, der Partitionen als iSCSI-Geräte im Netzwerk anbieten kann. Dabei wurde der wiimote-Treiber unter anderem an neue Gegebenheiten der Infrastruktur für Eingabegeräte angepasst und der iscsi-target-Treiber um verschiedene Funktionen erweitert und einige Fehler ausgemerzt. Doch obwohl notwendig oder zumindest sinnvoll, bringen solch große Änderungen immer die Gefahr mit, etwas kaputt zu machen und damit den Entwicklungsprozess zu verlängern. Mit -rc4 ging auch noch einmal eine Namensänderung einher. 3.1 heißt derzeit „Divemaster Edition“, ein Hinweis auf Torvalds Hobby.
Probleme mit 3.0
Schon auf kernel.org [5] ist nach der Änderung des Versionsnummern-Schemas noch nicht alles angepasst. Zwar werden die Änderungen der Patches der aktuell stabilen Reihe 3.0 mittlerweile dargestellt, für den Testing-Zweig 3.1 fehlt diese komfortable Funktion jedoch noch. Auch die Fedora-Entwickler befürchten Probleme und haben kurzerhand beschlossen, der nächsten Fedora-Version den Kernel 2.6.40 beizulegen – ein umbenannter 3.0-Kernel. Der Entwickler Dave Jones erwähnte, interessanterweise auf Google+ [6], dass eine Reihe von Änderungen an Userspace-Paketen notwendig wäre, wenn das neue Schema übernommen würde. Die von ihm befürchteten Gerüchte, dass Red Hat damit einen Fork des Linux-Kernels forcieren wolle, blieben jedoch aus. Die Diskussion glitt später etwas ab, als Torvalds um einen Fork von GNOME [7] bat, um weiterhin GNOME 2 anstatt Version 3 nutzen zu können [8].
Kernel mit Langzeit-Unterstützung
Mitte des Monats machte sich Greg Kroah-Hartman Gedanken darüber, wie Kernel-Versionen gehandhabt werden sollen, die über längere Zeiträume unterstützt werden [9]. Bislang wurden die sogenannten Longterm-Kernel mehr oder minder willkürlich gewählt, weil das eine oder andere Unternehmen wie zum Beispiel Novell, Kroah-Hartmans Arbeitgeber, darauf eine Enterprise-Distribution aufbaute. So kamen neben den mittlerweile fallen gelassenen 2.6.16 und .27 immerhin drei derzeit noch gepflegte Langzeit-Kernel zusammen (2.6.32, .34, .35 – kernel.org zeigt dies derzeit nicht korrekt an). Hier soll etwas mehr Struktur einkehren; so schlug Kroah-Hartman vor, künftig jedes Jahr einen Longterm-Kernel auszuwählen, der dann für zwei Jahre gepflegt wird. Die „normalen“ Kernel sollen wie gehabt unterstützt werden, bis der Nachfolger freigegeben wurde. Dies würde bedeuten, dass zu jeder Zeit zwei Longterm- und ein stabiler Kernel unterstützt werden, was deutlich überschaubarer wäre.
Einbruch auf kernel.org
Eher unerfreulich endete der August für die Kernel-Entwickler, als entdeckt wurde, dass in einen der Server von kernel.org eingebrochen worden war [10]. Die Einbrecher hatten root-Zugriff erlangt, Dateien des SSH-Servers verändert und einen Trojaner installiert. John Hawley, der Betreuer der kernel.org-Server, bemerkte es, als er die Ursache der Leistungsprobleme nachging. Es wird vermutet, dass die Angreifer über einen kompromittierten Benutzeraccount lokalen Zugriff erlangten. Wie sie sich danach root-Rechte verschafften, wird derzeit untersucht. Hawleys Ansicht nach blockiert der Entwickler-Kernel 3.1-rc2 jedoch den genutzten Exploit-Code. Derzeit werden auch alle Server von kernel.org neu installiert.
Der Entwickler Jonathan Corbet stellte heraus, dass der Kernel-Code innerhalb der Versionsverwaltung Git nicht verändert worden sei. Die Entwickler sind sich hierin sicher, da Architektur von Git jede Datei und jede Änderung mit einem Hash versieht, welcher die Integrität aller Inhalte gewährleistet. Änderungen wären den Entwicklern beim nächsten Abgleich mit kernel.org aufgefallen und wären dadurch entdeckt worden [11].
Links
[1] https://lkml.org/lkml/2011/8/7/102
[2] https://lkml.org/lkml/2011/8/14/281
[3] https://lkml.org/lkml/2011/8/22/333
[4] https://lkml.org/lkml/2011/8/29/8
[5] https://master.kernel.org/
[6] https://plus.google.com/106327083461132854143/posts/SbnL3KaVRtM
[7] http://www.gnome.org/
[8] http://www.pro-linux.de/news/1/17348/linus-torvalds-kritisiert-gnome-3.html
[9] http://www.kroah.com/log/linux/longterm-proposal-08-2011.html
[10] http://www.pro-linux.de/news/1/17448/einbruch-bei-kernelorg.html
[11] http://linux-foundation.org/weblogs/lwf/2011/08/31/the-cracking-of-kernelorg/
Autoreninformation |
Mathias Menzer (Webseite)
hält einen Blick auf die Entwicklung des Linux-Kernels. Dafür erfährt er frühzeitig Details über neue Treiber und interessante Funktionen.
|
|
Diesen Artikel kommentieren
Zum Index
von Christian Imhorst
Es begann mit einem Irrtum. Im Werbebrief vom Google für den
AdWords-Dienst befand sich ein Gutschein über 75 Euro, der auf
einen völlig fremden Menschen ausgestellt war. Wenn man Sandra
Fründt, Head of Business Marketing Google Deutschland, auf ihren
Fehler aufmerksam machen will, immerhin hat sie diesen Brief
unterschrieben, stößt man auf ein Problem: Im Schreiben ist
überhaupt keine E-Mail-Adresse angegeben. Das Unternehmen, das mit
Suchmaschine und E-Mail-Dienst im Internet groß geworden ist, zeigt
sich in seiner Werbung ganz schön verschlossen.
Auf der Suche nach einer E-Mail-Adresse
Jetzt kann man sich eine mögliche und formal richtige E-Mail-Adresse
für die Empfängerin ausdenken, eine E-Mail an diese Adresse
schicken und darauf warten, ob der Mailserver die Nachricht auch
erfolgreich zustellen kann. Wenn er nämlich scheitert, bekommt man
eine Fehlermeldung als Antwort zurück. Entweder probiert man so
lange herum, bis diese Antwort ausbleibt, oder man kann, um das Ganze
abzukürzen, den Test auch in die Konsole verlagern. Das
Werkzeug für diesen Test ist das Telnet [1], für das bei den
meisten
GNU/Linux-Distributionen, MacOS X und sogar bei Windows ein Tool vorinstalliert oder schnell nachträglich zu installieren ist.
In der Vergangenheit war Telnet eine unverschlüsselte und daher
unsichere Methode für die Fernwartung von Rechnern. Der Vorteil von
Telnet ist aber, dass man sich über den entsprechenden Port mit so
ziemlich jedem Server verbinden kann, der ein textbasiertes
Protokoll beherrscht, also auch mit Mailservern. Diesen Vorteil
muss man allerdings mit Vorsicht genießen, da er auch von Spammern
genutzt wird.
Woher kommt das Wort „Spam“?
Die Bezeichnung „Spam“ für Massenmails zu Werbezwecken im Internet
wurde durch einen Sketch der englischen Komikertruppe
Monty Python geprägt. Der Sketch [2] spielt in einem
Imbiss, in dem es fast ausschließlich nur Spam (spiced ham), also
„gewürzten Schinken“, auf der Speisekarte gibt. Auf die Frage, ob
es auch etwas ohne Spam gäbe, antwortet die Kellnerin: „Well,
there's spam egg sausage and spam, that's not got much spam in
it.“ Woraufhin die Kundin sagt: „I don't want ANY spam!“. Später,
beim Versuch, etwas ohne Spam zu bestellen, kreischt sie sogar: „I
don't like spam!“ Spam wird in dem Sketch 132 mal genannt und steht
synonym für eine unnötig häufige Verwendung und Wiederholung.
|
Wie funktioniert E-Mail eigentlich?
Bevor es losgeht, sollte man sich noch kurz klar darüber werden, was
beim Versenden von E-Mails überhaupt passiert und ein paar Begriffe
klären. In der Regel schreibt man eine E-Mail mit einem
E-Mail-Programm, das auch E-Mail-Client oder, etwas technischer,
„Mail User Agent“ (MUA) genannt wird. Traditionell werden die E-Mails
vom „Mail Transfer Agent“ (MTA), das ist dann der Mailserver,
entgegengenommen, falls nicht ein „Message Submission Agent“ (MSA)
dazwischen geschaltet ist, der die E-Mails vom MUA an den MTA
übergibt. Das Protokoll zum Versenden der Nachrichten zwischen
diesen Servern heißt „Simple Mail Transfer Protocol“ (SMTP). Auf der
Empfängerseite ist der „Mail Delivery Agent“ (MDA) verantwortlich für
die Zustellung
zum E-Mail-Client. Die Protokolle, die zum Abholen
von Nachrichten verwendet werden heißen „Post Office Protocol“ (POP)
oder „Internet Message Access Protocol“ (IMAP).
Nach der Theorie die Praxis
Normalerweise fragen Mailserver beim Versenden von E-Mails nach dem
vollständigen Namen
einer Domain. Da hier keine E-Mail verschickt
werden soll, wird mit dem Befehl nslookup nach dem entsprechenden
Domainnamen gesucht:
$ nslookup -q=mx google.com
Server: 192.168.178.1
Address: 192.168.178.1#53
Non-authoritative answer:
google.com mail exchanger = 50 alt4.aspmx.l.google.com.
google.com mail exchanger = 10 aspmx.l.google.com.
google.com mail exchanger = 20 alt1.aspmx.l.google.com.
google.com mail exchanger = 30 alt2.aspmx.l.google.com.
google.com mail exchanger = 40 alt3.aspmx.l.google.com.
Gesucht wird nach dem „Mail Exchange Resource Record“ (MX-Eintrag)
der Domain google.com im „Domain Name System“ (DNS), der sich
ausschließlich mit dem E-Mail-Dienst (SMTP) beschäftigt. Wie man
sieht hat Google gleich mehrere MX-Einträge mit unterschiedlichen
Prioritäten, damit bei einem Ausfall der jeweils andere die E-Mails
entgegen nehmen kann. Der Eintrag mit dem höchsten numerischen Wert
hat meist die niedrigste Priorität. Das nutzen Spammer gerne aus,
indem sie sich mit dem Mailserver mit der niedrigsten Priorität
verbinden, um Spamfilter zu umgehen, die auf dem Server mit der
höchsten Priorität laufen. Laut dem MX-Eintrag ist der Server mit
der höchsten Priorität aspmx.l.google.com. Mit dem wird jetzt die
Verbindung über Telnet und dem Port 25 für SMTP aufgebaut:
$ telnet aspmx.l.google.com 25
Trying 74.125.39.27...
Connected to aspmx.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP 3si5028908fav.179
Was in diesem Fall bei Google klappt, kann bei anderen Mailservern
schon schief gehen. Zur Abwehr von Spammern lassen einige
Mailserver –
zum Beispiel von GMX – eine Verbindung zum Server im
MX-Eintrag gar nicht erst zu, wenn die Anfrage über die dynamische
IP eines Client-PCs gestellt wird und nicht von einem anderen
Mailserver kommt. Es kann aber auch sein, dass der Mailserver
aufgrund einer Störung einfach nicht erreichbar ist.
Was einem der Statuscode so sagt
Die letzte Zeile der obigen Ausgabe beginnt mit einer Zahl, nämlich
220. Im SMTP-Protokoll werden Befehle der Reihe nach ausgeführt und
jeder Befehl wird mit einem Statuscode beantwortet. Die
Beschreibung, die auf den Statuscode folgt, ist für Menschen
gedacht und für das Protokoll
ohne Bedeutung. Beginnt der
Statuscode so wie in diesem Fall mit einer 2, dann war die
Bearbeitung erfolgreich, bei einer 3 fehlen noch Informationen und
bei einer 5 ist ein Fehler aufgetreten.
Als erstes erwartet der Server eine Begrüßung in Form eines HELO,
dabei ist es im Prinzip völlig egal, welches Argument man nach dem
Befehl einträgt, auch wenn man eigentlich die eigene Domain angeben
sollte:
helo hi
250 mx.google.com at your service
Der Statuscode mit der 2 am Anfang zeigt, dass der Befehl
erfolgreich bearbeitet wurde und der Server zu Diensten steht.
Anschließend gibt man die E-Mail-Adresse des Absenders mit dem
Befehl MAIL FROM ein:
mail from: <test.user@googlemail.com>
250 2.1.0 OK 3si5028908fav.179
Die spitzen Klammern vor und nach der E-Mail-Adresse sind wichtig.
Ansonsten erhält man einen Syntax Error. Als nächstes gibt man
einen Empfänger ein, zum Beispiel eine Adresse von der man weiß,
dass sie existiert:
rcpt to: <larry.page@google.com>
250 2.1.5 OK 3si5028908fav.179
Gibt es die E-Mail-Adresse wirklich?
Die 250 oben verrät, dass der Befehl erfolgreich war. Die
E-Mail-Adresse scheint zu existieren. Doch auch hier gibt es die ein oder andere Falle, die Mailserver Spammern stellen.
Manche Mailserver haben ein Catch-All für E-Mails, dann laufen alle
E-Mails mit einer formal richtigen E-Mail-Adresse
der Domain in der
gleichen Mailbox zusammen und der Mailserver antwortet in diesem
Fall bei jeder formal gültigen Adresse mit einem „OK“.
Vielleicht wird auch eine Graue Liste zur Spambekämpfung
eingesetzt. Dabei wird die erste E-Mail von einem unbekannten
Absender abgewiesen und erst nach dem nächsten Zustellversuch
angenommen.
Eine weitere Methode ist das „Sender Policy Framework“ (SPF). Hier
schaut der empfangende Mailserver nach, ob die Domain im Befehl
MAIL FROM mit dem Argument des Befehls HELO übereinstimmt.
Wenn das nicht der Fall ist, kann es gut sein, dass der Rechner
E-Mails für diese Domain gar nicht versenden darf. Dadurch soll
das Fälschen von Absendern auf SMTP-Ebene erschwert werden.
Der nächste Versuch zeigt, dass der Mailserver von Google vermutlich
kein Catch-All verwendet:
rcpt to: <sandra.fruendt@google.com>
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipients email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://mail.google.com/support/bin/answer.py?answer=6596 3si5028908fav.179
Auch ohne den Statuscode sieht man, dass hier etwas falsch läuft.
Die E-Mail-Adresse existiert laut dem Mailserver nicht. Das kann
auch wiederum mehrere Ursachen haben: Entweder ist Frau Fründt eine
Externe und gehört nicht zum Unternehmen oder es gibt dort mehr als
eine Sandra Fründt oder die Administratoren bei Google halten ein
einheitliches Namensschema für E-Mail-Adressen in einem Unternehmen
für überbewertet. Ein paar Versuche später wird klar, dass der
letzte Punkt zutrifft. Mit dem Befehl QUIT schließt man die
Telnet-Sitzung wieder.
Zum Validieren reicht es nicht
Am Ende konnte die – vermutlich – korrekte E-Mail-Adresse von Frau
Fründt zusammen mit den hier gesammelten Infos nur durch weiteres
Googeln genauer abgeglichen werden. Zur Validierung von
E-Mail-Adressen ist das Verfahren aus den oben genannten Gründen
somit nur begrenzt geeignet und wäre mit einem Webdienst wie
verify-email.org [3] wesentlich
schneller gegangen. Im Prinzip lässt sich so eigentlich nur
ermitteln, ob zum Zeitpunkt der Abfrage der Mailserver bereit oder
in der Lage ist, den Mailversand zu einer bestimmten E-Mail-Adresse
durchzuführen. Das kann für die
Fehlerdiagnose bei Versandproblemen
durch das Mailprogramm sehr hilfreich sein, indem man seinen
eigenen oder den Mailserver des Providers testet und dessen
Funktionsweise direkt in einer seiner Protokollsprachen SMTP, POP3
oder IMAP überprüft, aber auch zum Testen der eigenen Spamfilter.
Bonuslevel: Eine E-Mail über Telnet versenden
Eine E-Mail über Telnet zu versenden ist zwar etwas komplizierter,
kann sich aber zum Testen durchaus
lohnen [4]. Als Beispiel
dient hier der Maildienst von Google, wobei andere
E-Mail-Dienst-Anbieter ähnlich funktionieren sollten.
Das SMTP-Protokoll wurde aufgrund der zunehmenden Spamproblematik um
Verfahren zur Authentifizierung und Verschlüsselung
erweitert [5].
Um eine E-Mail zu verschicken, muss man häufig diese Erweiterungen
des Mailservers nutzen. Welche aktiv sind, findet man
mit dem Befehl EHLO heraus, der für „Enhanced HELO“ steht:
$ telnet smtp.googlemail.com 25
Trying 74.125.39.16...
Connected to googlemail-smtp.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP d1sm327505fai.4
helo hi
250 mx.google.com at your service
ehlo hi
250-mx.google.com at your service, [89.182.218.152]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250 ENHANCEDSTATUSCODES
Wie man an dem Beispiel gut sehen kann, schweigt sich der Befehl
HELO darüber aus, welche Fähigkeiten der Server bei
Verschlüsselung, Authentifizierung und so weiter besitzt. Die
bekommt man nur als Antwort auf EHLO. Die Ausgabe von STARTTLS
zeigt zum Beispiel, dass der Server Verschlüsselung unterstützt.
Codiertes Login
Aufgrund des vermehrten Spamaufkommens verlangen Mailserver
heutzutage eine Authentifizierung. Zur Vorbereitung der
Authentifizierung und weil man gleich sowieso eine verschlüsselte
Verbindung über openssl aufbauen muss, verlässt man den Server
jetzt mit dem Befehl QUIT.
Die Authentifizierung findet in einer Base64-Kodierung statt. Dazu
gibt man im Terminal den Befehl base64 ein und drückt „Enter“.
Anschließend folgt der Anmeldename, wieder gefolgt von „Enter“. Um
die Eingabe zu beenden, drückt man die Tasten „Strg“ + „D“ und erhält
in etwa folgendes Ergebnis:
$ base64
test.user@gmail.com
dGVzdC51c2VyQGdtYWlsLmNvbQo=
Das Passwort wird genauso mit Base64 kodiert. Wenn das erledigt ist,
baut man die verschlüsselte Verbindung zum Mailserver mit openssl
auf:
$ openssl s_client -starttls smtp -crlf -connect smtp.googlemail.com:25
Es folgt eine wirklich lange Ausgabe im Terminal, in der man unter
anderem sehen kann, dass Zertifikate ausgetauscht werden. Wenn
diese erste Hürde überwunden ist, begrüßt man den Server wieder mit
EHLO:
ehlo hi
250-mx.google.com at your service, [89.182.218.152]
250-SIZE 35882577
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH
250 ENHANCEDSTATUSCODES
Nach der Begrüßung folgt das Login mit dem Befehl AUTH LOGIN und dem
Base64-kodierten Benutzernamen gleich dahinter:
auth login dGVzdC51c2VyQGdtYWlsLmNvbQo=
334 UGFzc3dvcmQ6
Der Statuscode 3 zeigt an, dass der Server noch weitere Infos
benötigt. Die Beschreibung, die einen darauf hinweisen soll, was
genau noch fehlt, ist übrigens auch Base64-kodiert:
$ base64 -d
UGFzc3dvcmQ6
Password:
Das heißt, man soll das Passwort eingeben, natürlich Base64-kodiert:
RGFzaXN0R2VoZWltCg==
235 2.7.0 Accepted
Sender und Empfänger
Nach der Eingabe des Base64-kodierten Passworts wird die E-Mail
geschrieben. Mit den Befehlen MAIL FROM und RCPT TO werden
Sender und Empfänger der E-Mail festgehalten:
mail from: <test.user@gmail.com >
250 2.1.0 OK l22sm324987fam.37
rcpt to: <empfaenger@beispiel.net>
250 2.1.5 OK l22sm324987fam.37
Wichtig ist, dass die E-Mail-Adressen in spitzen Klammern stehen.
Man kann RCPT TO auch mehrmals benutzen, wenn man die E-Mail an
weitere Empfänger versenden möchte.
Der Befehl DATA gibt an, dass jetzt die E-Mail folgt. Zu Beginn
gibt man der E-Mail beliebige Kopfzeilen mit, wobei Absender,
Empfänger und Betreffzeile hier am sinnvollsten sind. Welche
Adressen man in den Kopfzeilen einträgt, ist egal, es können ganz
andere sein, als die, die in den Befehlen MAIL FROM und RCPT TO
weiter oben eingetragen wurden. So einfach kann man Absender
fälschen.
data
354 Go ahead l22sm324987fam.37
From : Test <test.user@gmail.com>
To: Empfaenger <empfaenger@beispiel.net>
Subject: Hier kommt eine Testmail
Hallo Empfaenger,
hier kommt eine Testmail.
Viele Gruesse.
Wenn der Text fertig ist, beendet man den Befehl DATA mit einem
einzelnen Punkt in einer separaten Zeile. Nach der Bestätigung der
Eingabe durch den Mailserver ist die E-Mail verschickt und man
verlässt Telnet wieder über den Befehl QUIT.
Links
[1] http://de.wikipedia.org/wiki/Telnet
[2] http://www.youtube.com/watch?v=anwy2MPT5RE
[3] http://wiki.ubuntuusers.de/Mailserver_testen
[4] http://www.linux-magazin.de/Heft-Abo/Ausgaben/2002/04/Transport-Sicherung
Autoreninformation |
Christian Imhorst (Webseite)
hat bis heute keine Reaktion auf seine E-Mail an
Frau Fründt erhalten. Durch eine weitere Recherche mit Google hat
er mittlerweile auch ihre Handy-Nummer, die auf einer einsam
gelegenen Seite von Google selbst gleich neben ihrer Jobbezeichnung
und ihrer E-Mail-Adresse steht. Vielleicht schreibt er ihr mal eine
SMS, um nachzufragen, ob seine E-Mail auch wirklich bei ihr
angekommen ist, sobald er herausgefunden hat, wie man das über die
Kommandozeile macht.
|
|
Diesen Artikel kommentieren
Zum Index
von Herbert Breunung
Während der vorige Teil dieses Tutoriums zu einer Hälfte aus
Vorbereitungen bestand und die andere Hälfte auf ein kleines
Programm hinarbeitete, wird dieses Mal nur noch programmiert. Dies
bedeutet aber nicht, dass wesentlich mehr Befehle auswendig zu
lernen sind, sondern dass der Student mehr von der Syntax begreifen
lernt: Was eigentlich ein Punkt oder Komma macht, wo man Klammern
setzt und was der Unterschied zwischen den runden und den geschweiften
Klammern ist.
Da „Syntax begreifen“ auch das Wissen umfasst, was wann angebracht
ist, wird damit begonnen, die Vor- und Nachteile von Alternativen
abzuwägen. Dazu gehört es auch, sein Programm stets fit zu halten.
Gerade weil das Projekt praxisnah stetig wächst, kann dabei gezeigt
werden, worauf man frühzeitig achten sollte, damit die Freude beim
Programmieren nicht vergeht.
Doch bevor die Lektion beginnt, würde vielleicht etwas Wiederholung
gut tun, es sei denn, alle der folgenden Befehle, Operatoren und
Zeichen können selbstständig und mit eigenen Worten erklärt werden:
use print say my our undef open read readline getc eof close chomp chdir
$ < > = ; #
Auch die erwähnten Pragmata und Module sollten nicht der
Vergessenheit anheimfallen:
strict warnings diagnostics utf8
FindBin File::Slurp IO::All
Wem dies nichts mehr sagt, sollte sich am besten noch einmal Teil 1
des Tutoriums aus freiesMagazin 08/2011 [1]
vornehmen.
Lösung der Aufgabe
Zur Festigung wurde letztes Mal aufgetragen, einen kleinen
Anfang des Notizprogramms zu schreiben. Deshalb heißt es jetzt:
„Editoren raus, Hausaufgabenkontrolle!“ Streng wird es jedoch
nicht, da die Aufgabe sich sehr vielfältig lösen lässt und nur die
eigene Zufriedenheit mit dem Programm zählt, das selbstverständlich
ohne Fehler oder Warnungen laufen sollte. Die kürzeste und klarste
Lösung ist wohl:
use v5.12;
use warnings;
use FindBin;
use File::Slurp;
chdir $FindBin::Bin;
say read_file('notizblock.txt');
print "Neue Notiz: ";
my $notiz = <STDIN>;
append_file
( 'notizblock.txt', $notiz );
use ist bereits bekannt. Das Programm verlangt mindestens Version
5.12.0, warnt auch vor möglichen Problemen. Weiterhin wird die
Information benötigt, in welchem Verzeichnis das Skript läuft,
für das das Modul FindBin benutzt wird. File::Slurp stellt die
Befehle read_file und append_file bereit, mit deren Hilfe Dateien
einfach gelesen und geschrieben werden können.
Als erstes macht chdir das Skriptverzeichnis zum
Arbeitsverzeichnis, damit die Datei mit den gespeicherten Notizen
gefunden werden kann. Diese liest read_file ein und say gibt
deren Inhalt sofort über das Terminal aus. print bringt die
Aufforderung, die nächste Notiz einzugeben. Die liest <STDIN>,
und das Gleichheitszeichen = legt sie in $nachricht ab.
append_file öffnet die Datei erneut am Dateiende und hängt die
Nachricht dort an.
Wer noch eine Notiz eingeben will, startet bn
(im letzten Tutorial angelegter Alias) noch einmal.
Dieses Programm war knapp, verständlich und eine sehr gute Lösung,
wäre die Benutzung von File::Slurp erlaubt. Denn wenn es einmal
komplizierter wird (einzelne Bytes auslesen) oder nicht die ganze
Datei benötigt wird, muss man auf open, read und close
zurückgreifen, was wenigstens einmal geübt werden sollte.
use v5.12;
use warnings;
use FindBin;
chdir $FindBin::Bin;
open my $FH, '+<',
'notizblock.txt';
say do { local $/; <$FH> };
print "Neue Notiz: ";
my $notiz = <STDIN>;
print $FH $notiz;
Der erste „Trick“ weshalb diese Fassung kaum länger ist: Die Datei
wird im Lese- und Schreibmodus (+<) geöffnet. Nachdem sie
vollständig gelesen wurde und der Zeiger mit der Lese- oder
Schreibposition am Ende der Datei steht, fügt jedes Schreiben
(letzte Zeile) etwas an. Die eigentliche Nuss steckt jedoch in
Zeile 8, die jetzt erklärt wird.
Blöcke und Spezialvariablen
Ein Paar geschweifte Klammern und die darin enthaltenen Befehle
(durch ein Semikolon ; getrennt) nennt man Block. Solche Blöcke
sind Programmteile, die nur bei Bedarf oder wiederholt
ausgeführt werden. Mit einem do vor dem Block wird dieser nur
einmalig und sofort abgearbeitet und das Ergebnis, meist das
Ergebnis des letzten Befehls im Block, kann genutzt werden.
Im Listing oben bekommt das do ein say zur Ausgabe. Die
eigentliche Magie passiert aber in dem Block. Variablen wie $/
werden tatsächlich oft als magisch bezeichnet, weil sie das
Verhalten von Perlbefehlen ändern und auch ihr etwas seltsames
Äußeres trägt zu dieser Bezeichnung bei. Statt $/ könnte man
genauso gut $INPUT_RECORD_SEPARATOR oder $RS schreiben, aber dazu
müsste man use English; zufügen. Das Modul English stellt, getreu
seinem Namen, den magischen Variablen
einen englischen Alias zur
Seite. Dazu sind jedoch viele Programmierer zu bequem oder sie
tolerieren die damit verbundenen Geschwindigkeitseinbußen nicht, die sich
allerdings mit use English '-no_match_vars'; umgehen lassen. Der
Kürze wegen verzichtet das Beispiel jedoch darauf.
<$FH> liest eine Zeile aus der geöffneten Datei. Doch woher weiß
Perl wo die Zeile endet? Am Zeichen, welches das Zeilenende
markiert. Da es nicht sichtbar ist, schreibt man \n (Das n
steht für „newline“, zu deutsch „neue Zeile“). Dieses \n ist
normalerweise der Inhalt von $/. Es wird von < > (readline)
benutzt und chomp entfernt immer nur die Zeichen, die sich in
$/ befinden. In dem kleinen Block wird $/ entleert, sodass < >,
ohne ein Zeilenende erkennend, die gesamte Datei bis ans eof
(Dateiende) einliest.
Um andere < >-Operationen nicht zu
beeinflussen, sollte diese Änderung von $/ nur in diesem Block
wirksam sein. Alle Spezialvariablen sind nämlich von Hause aus
global, d. h. im gesamten Perl-Slript bekannt. Um dies einzuschränken
ist das Wort local da. Es ist der weniger strenge Vorläufer von
my (genaueres dazu folgt in einem späteren Tutorium),
der $/ bis zum Ende des Blocks mit einem anderen Wert
(undef da nichts zugewiesen) überschreibt.
Magische Variablen haben meist recht logische Namen (perldoc
perlvar hilft), ihre Form gibt fast immer einen Hinweis auf ihre
Bedeutung. Der Schrägstrich (Slash) in $/ deutet eine geöffnete
Klappe an, in die sich etwas von oben hineinschütten lässt.
Die Benutzung
der Spezialvariablen, sollte jedoch auf ein Minimum beschränkt
werden und in Produktivcode sind die Kurzformen gänzlich zu
vermeiden.
Kontext
Doch auch das aktuelle Programm kann verbessert werden. $nachricht
wird nur einmal gefüllt und gleich danach nur einmal gebraucht.
Könnte man nicht auch print $FH <STDIN>; schreiben? Beinahe, es
müsste richtig lauten:
print $FH scalar <STDIN>;
Was scalar tut, könnte manchen dämmern, da bereits
bekannt ist, was skalare Variablen sind. Deutschlehrer sagen
Singular dazu, das Gegenteil von Plural (Mehrzahl). Es beschreibt
nämlich, dass <STDIN> nur einen Wert liefern soll. Würde man es
weglassen, passierte etwas ungemein Heimtückisches. print
erwartet eine Mehrzahl an Werten, die es hintereinander ausgibt.
Das folgende < > bekommt das mit und erfüllt diese Forderung
gerne. Ungünstig ist nur, dass der Begriff „Mehrzahl“ kein Ende
definiert. Der Nutzer würde eine Notiz nach der anderen eingeben,
ohne jemals weiter zu kommen. Was an dieser Stelle nach böser Falle
aussieht, ist sonst eine Quelle von Perls großer Macht. Das Prinzip
nennt sich Kontext oder auch Kontextsensitivität und bedeutet, dass
einzelne Befehle den Ton angeben (den Kontext bestimmen) und der
Rest versucht seine Ergebnisse anzupassen. Wegen dieses Prinzips
konnte ein Plus (+) seine Summanden in Zahlen umwandeln lassen.
Automatisches close
Weil Perl so viel Freiheit und integrierte Intelligenz bereitstellt,
fordert es den Programmierer auf, seine Absicht genau auszudrücken.
Das vorgestellte Beispiel war auf Kürze optimiert und jeder fähige
Coder versteht es auch. Aber größere Programme sollten vor allem
robust sein. Damit ist gemeint, dass man es leicht ändern kann,
ohne dass sofort das halbe Programm aufhört zu arbeiten. Das heißt
manchmal auf clevere Kniffe zu verzichten und in diesem Fall das
close $FH; dazu zu schreiben, auch wenn das Dateihandle
automatisch am Ende geschlossen wird.
Was gute Programmierer auch ausmacht: Sie planen jede Möglichkeit
ein. Wenn keine notizblock.txt vorhanden ist, dann wirft das
bisherige Programm:
readline() on closed filehandle $FH at bn.pl line 8
Das war zwar nur eine Warnung (kein Abbruch) aber der Rest des
Programms funktioniert nicht. Willkommen im Alltag! Das
Handle in $FH wurde für „zuerst lesen, dann schreiben“
initialisiert. Aus einer nicht vorhandenen Datei kann nichts
gelesen werden. Daher die Fehlermeldung. Und da nichts gelesen
wurde, kann später auch nicht mit dem Handle geschrieben werden
(zweite Meldung).
Menschen, die schon etwas Perl kennen, schreiben deshalb so etwas wie:
open( ... ) or die "Keine notizblock.txt vorhanden";
Selbst wenn man nicht weiß, was genau das logische Oder (or)
macht, kann man es sich doch denken, denn es liest sich wie ein
(englischer) Satz: „Öffne die Datei oder stirb.“ Genau das tut es
auch, wobei die einfach ein anderer Name für print STDERR
"Nachricht", verbunden mit dem Programmabbruch, ist.
STDERR ist das Handle der Standardfehlerausgabe. Meist ist
daran ebenfalls die Shell gebunden wie bei STDIN und STDOUT. In
letzter Zeit hat es sich aber durchgesetzt use autodie; zu
schreiben. Durch dieses Pragma sterben die Programme automatisch,
wenn Befehle wie open Probleme haben, und die dabei entstehenden
Fehlermeldungen sind weit informativer als das, was sich
Programmierer meist einfallen lassen. Da „Gib ein Bier oder stirb!“
der einzige Weg ist, in einer klingonischen Bar seinen Durst zu
löschen, bekam autodie den Beinamen des klingonischen
Programmierstils.
Weil ein Tod nur hilft, einen Konflikt schneller zu erkennen, ihn
aber nicht löst, wäre es besser, mit einem Handle anhängend auf die
Datei zuzugreifen und das Handle mit dem nächsten Befehl wieder zu
schließen. Dies verändert die Datei nicht, würde im Falle der
Nichtexistenz aber eine leere Datei anlegen. Sicherlich täte der
aus Perl einfach aufrufbare Unix-Befehl touch dasselbe,
aber die Anwendung
soll ja auch unter Windows laufen.
{ open my $FH, '>>',
'notizblock.txt' }
Der Befehl im Block wird normal ausgeführt. Ohne do verzichtet man
einzig auf das Ergebnis von open. Nur die Variable $FH wird
wegen des my mit der schließenden Klammer gelöscht, als wenn es
sie nie gegeben hätte. Davor wird mit dem darin enthaltenen Handle
ein close ausgeführt. Gäbe es noch eine zweite Variable $FH vor
der öffnenden Klammer, sie wäre von all dem unberührt. Lediglich ab
dem my $FH lässt sich im inneren Block mit $FH einzig auf die
neue, „innere“ Variable zugreifen.
Guter, trockener Code
Erfahrene Programmierer hätten vielleicht ein Problem damit, dass
der Dateiname zweimal auftaucht. Sie würden den Dateinamen am
Programmanfang in eine Variable geben und diese anstatt des Names
verwenden.
...
my $datei = 'notizblock.txt';
chdir $FindBin::Bin;
{ open my $FH, '>>', $datei; }
open my $FH, '+<', $datei;
...
Das mag etwas übertrieben wirken, hat aber drei wichtige Gründe:
- Man sollte Dopplungen vermeiden, wo es geht. Durch das Befolgen
des DRY-Prinzips („dry“ heißt auf deutsch „trocken“ und steht für
„don't repeat yourself“) werden
Programme wesentlich leichter änderbar. Sollen die Notizen später
in einer anderen Datei gespeichert werden, braucht der Autor nur
eine Stelle ändern anstatt zwei.
- Der Autor muss die Stelle nicht suchen, da sie am Anfang ist.
- Gute Variablennamen machen den Quellcode verständlicher
als zufällige Daten im Code.
In diesem Beispiel ist der Unterschied nicht so wesentlich, aber es
ist entscheidend, frühzeitig dafür ein Auge zu entwickeln. Die
wahre Ursache, warum es Programme gibt, die eher an ein Haarknäuel
im Ausguss erinnern, ist nicht die Wahl der Sprache. Sie entstehen,
wenn jemand seine Werkzeuge und vor allem die logische Struktur der
Aufgabe nicht versteht. Meist gewinnt man das Verständnis in allen
Feinheiten aber erst während des Programmierens, weshalb es für den
Erfolg wesentlich ist, Gebilde aufzubauen, die sich leicht ändern
lassen.
Bedingte Ausführung und Dateitests
Optimal wäre es, den kleinen Block mit dem open nur dann
auszuführen, wenn die Datei wirklich fehlt. Der dafür zu
gebrauchende Befehl lautet in fast allen Sprachen if („wenn“).
Dem folgt die Bedingung in runden Klammern. Wird die Bedingung als
„wahr“ ausgewertet (Ergebnis nicht leer, 0 oder undef) wird der
darauf folgende Block ausgeführt. Perl kennt auch noch ein
unless, das den Block ausführen lässt, wenn die Bedingung
„unwahr“ ist.
Das Prüfen, ob die Datei vorhanden ist, geht in Perl sehr einfach.
Dazu gibt es die Dateitestoperatoren, welche sich am
Unix-Kommandozeilenprogramm test orientieren und mit einem Minus
- beginnen. Die Prüfungen orientieren sich meist am ersten
Buchstaben dessen, was geprüft wird. Auf die Existenz der Datei wird im
Beispiel mit dem Operator -e getestet:
unless (-e $datei)
{ open my $FH, '>>', $datei; }
Wenn der Block nur einen Befehl enthält, kann man auch eine andere
Schreibweise wählen. Die nennt sich „nachgestellt“, weil hier das if
oder unless nach dem Befehl steht:
open my $DH, '>>', $datei unless -e $datei;
Dabei lassen sich nicht nur die geschweiften, sondern auch die
runden Klammern um die Bedingung weglassen. Einen Unterschied gibt
es nur für die Variable, die jetzt einen größeren Geltungsbereich
hat.
Der Aufruf open ist nicht mehr in einem Block { }
eingeschlossen. Deshalb muss das my im folgenden Befehl entfernt
werden, da deren Geltungsbereich schon bestimmt wurde. Oder man
wählt zwei verschiedene Variablennamen.
Sowohl das zweimalige Öffnen einer Datei mit einem Handle, als auch
das Öffnen einer Datei mit zwei Handle ist in Perl vorgesehen. Mit
seek lässt sich sogar die aktuelle Lese- und Schreibposition
versetzen, die tell $handle; einem mitteilt. Mehr dazu sagt die
perldoc, wenn sie gefragt wird (Erklärung einer function – eines
Perl-Befehls):
$ perldoc -f seek
$ # Dokumentation fuer ein Modul
$ perldoc File::Slurp
$ # unter Unix geht das auch
$ man File::Slurp
In den nächsten Abschnitten wird wieder File::Slurp verwendet. Es
macht das Programm klarer und reicht vom Funktionsumfang bis
mindestens Teil 4 dieses Tutoriums völlig aus, da jede Nachricht
eine Zeile belegt. Weil Enter die Eingabe abschließt, können die
Zeilenumbrüche nur am Ende jeder Notiz stehen. Dann muss man die
Zeilenabbrüche \n auch nicht mit chomp entfernen, sondern kann
sie gleich mit speichern.
Die üblichen Vergleiche
Sobald das Programm zwei-, dreimal verwendet wurde fällt auf, dass
eine Nachricht bei jedem Aufruf eingegeben werden muss. Oft dient
ein Notizblock jedoch nur der Erinnerung. Deshalb sollte man die
Eingabe abbrechen können, sodass nichts gespeichert wird.
say read_file($datei) if -e $datei;
print "Neue Notiz: ";
my $notiz = <STDIN>;
append_file($datei, $notiz)
if $notiz ne "\n";
Um Texte zu vergleichen, nimmt man die Operatoren eq (kurz für
„equal“, d. h. „gleich“) oder ne („not equal“ – „ungleich“). Die
letzte Zeile liest sich somit wie ein englischer Satz: „Füge an die
$datei die $notiz, wenn die $notiz nicht nur aus dem
Zeilenende besteht“. Mögliche Alternativen wären auch unless
$notiz eq "\n" oder if not $notiz eq
"\n" (das Wörtchen not verneint eine Aussage).
So wie das Plus (+) erwartete (erzwang), dass beide Operanden (die
Werte links und rechts) Zahlen sind, so erzwingen die Operatoren
eq und ne den Stringkontext (Text). Es gilt die Faustregel:
Sind es Symbole oder Formelzeichen, geht es um Zahlen; besteht der
Operator aus Buchstaben, geht es auch um Buchstaben. Zahlen
vergleich man mit == und da <> anderweitig im Gebrauch ist, wird
Ungleichheit mit != geprüft. Das ist insoweit logisch, da ein
Ausrufezeichen ! fast immer das Gegenteil ausdrückt (wie not auch).
Die Regel befolgend beziehen sich <, <=, >, >= nur auf
Zahlen. Wörter lassen sich alphabetisch sortieren. < prüft ja nur
ob zum Beispiel die 3 vor der 4 am Zahlenstrahl steht. Da dem so
ist, gibt 3 < 4 oder "3" < "4" einen positiven Wert (meist 1).
Auf Englisch spricht man das < „lower than“ aus. Deswegen ist lt
identisch zu <, nur auf Text bezogen: 'a' lt 'b' ist auch wahr.
Dies lässt sich jetzt analog fortführen: „lower equal“ (kleiner
gleich) wird zu le, „greater than“ zu gt, „greater equal“ zu
ge. perldoc perlcheat zeigt einen Spickzettel, auf dem solche
Dinge übersichtlich zusammengefasst sind. Den dort auf ge
folgenden, sehr nützlichen Raumschiffoperator für Vergleiche
erklärt der nächste Teil.
Zahlen
Zahlen müssen nicht in Anführungszeichen gestellt werden, da Perl
auch ohne sie ermittelt, wo sie anfangen und aufhören. Sie bestehen
ja lediglich aus den zehn Ziffern und ein wenig mehr. Es könnte ein
Minuszeichen davor stehen. Wobei das - auch als Operator negieren
kann, also - 5 und -5 ergeben das Gleiche. Der Punkt ist das
Komma für gebrochene Zahlen, da Kommata in Perl (und vielen anderen
Sprachen) für Aufzählungen von Werten (Listen) da sind. Aber Obacht,
der Punkt ist auch der Operator der Zeichenketten verbindet:
'der ' . 'Hirsch' # entspricht 'der Hirsch'
4 . 5 # '45', Verkettung von Text
4 .5 # '45', auch hier ist .
# Stringoperator
4. 5 # Fehler
4.5 # 4,5
4.0 . 's' # '4s'
Zahlen dürfen Unterstriche enthalten (1_000_000). Perl ignoriert
sie, weil sie nur der Lesbarkeit dienen. Wie bei Taschenrechnern
schreibt sich die Million auch als 1e6, weil es 1 mal 10 hoch 6
ist (1*10**6). Wer in Mathe aufgepasst hat, weiß jetzt auch, dass
ein Hundertstel identisch zu 1E-2 sind. Das e steht für
„Exponent“ und darf klein oder groß geschrieben werden.
4 == 4.0 # wahr, denn 4 ist 4
4 eq 4.0 # wahr, weil 4.0 zu 4,
# dann '4' wird
4 eq '4.0' # falsch, weil '4' und
# '4.0' nicht der selbe Text ist
Da Rechner keine 10 Finger haben, können sie nur bis 1 zählen und
rechnen deswegen mit 0 und 1. Für sie ist eine Million
0b11110100001001000000. Beginnt in Perl eine Ziffernfolge mit 0
(Null) ist das ein Signal: Achtung, die Zahl ist nicht dekadisch
kodiert (Zehnersystem wie in der Schule) sondern oktal. In diesem
System kommt nach der 7 die 10 (Zählwert 8), weil die Ziffern nur
bis 7 gehen. 0b (Null und klein b) ist der Vorsatz für binäre
Zahlen (zwei Ziffern) und 0x der für hexadezimale Zahlen .
Textangaben
Im letzten Beispiel war es sehr wichtig, doppelte Anführungszeichen
um "\n" zu legen. damit die spezielle Notation \n als
Zeilenumbruch interpretiert werden kann. Neben doppelten
Anführungszeichen gibt es auch noch einfache Anführungszeichen
(Hochkommata). Diese einfachen Anführungszeichen nehmen alles
wörtlich, was zwischen ihnen steht, es gibt aber zwei Ausnahmen. Um
auch mal ein Hochkomma im Text vorkommen zu lassen, wird ihm ein
Backslash \ vorangestellt. Das nennt man „escapen“ [2]. Auf deutsch: Das Zeichen
wird durch ein zusätzliches Zeichen seiner sonstigen Bedeutung
enthoben.
say 'hab\'s kapiert';
In der Shell erscheint hab's kapiert. Aber wie schafft man es,
wenn in einem Tutorium zeichengetreu hab\'s kapiert zur
Anschauung ausgegeben werden soll? Dann wird das Escape-Zeichen wiederum
„escaped“:
say 'hab\\\'s kapiert';
Die doppelten Anführungszeichen können (wie es ihre Form andeutet)
wesentlich mehr. In ihnen werden \n und die anderen
Escape-Sequenzen gegen unsichtbare Steuerzeichen ausgetauscht und
auch Variablen, die man dort einfügt, werden durch ihren Inhalt
ersetzt. Evaluieren heißt das in der Fachsprache.
Neben “ und gibt es noch die Backticks ``. Was in sie
gestellt ist, wird sofort ausgeführt (wie in der Shell, deren
Ausgabe (STDOUT) das Ergebnis ist). Das war vorhin mit der Aussage
„touch ausführen“ gemeint. Backticks interpretieren ebenfalls
Variablennamen und Steuerzeichennotationen wie \n ähnlich den
doppelten Anführungszeichen. „Quoten“ (in Anführungszeichen oder
Ähnliches setzen) ist in Perl ein breites Feld, über das noch
berichtet wird. Als Grundlage reicht das hier vermittelte Wissen
jedoch erst einmal.
Arrays
Zurück zum Notizprogramm. Endlich ist es solide, aber der
Funktionsumfang ist noch dünn. Was jetzt am dringendsten fehlt, ist
eine Möglichkeit, Nachrichten zu löschen. Am besten einzeln
natürlich. Später könnte man noch die Reihenfolge ändern. Dazu
müsste man jede Zeile in eine andere Variable geben ($notiz1, $
notiz2, usw.), aber eigentlich gehören diese ganzen Variablen
zusammen. Beim Speichern in die Datei lässt sich auf dem Weg kaum
bestimmen, welche Variablen dazugehören. Die ganze Liste an Notizen
sollte am besten in einer Variable deponiert sein. Dann fragt man
nur nach dem Wert Nummer 1, dem letzten oder allen Werten.
So geht es auch, nur dass Arrays bei 0 anfangen zu zählen (wie dieses
Tutorium), also das Feld Nummer 1 den zweiten Wert enthält.
Array-Variablen beginnen mit der Sigil @ („at“ genannt; das „a“
steht für Array). So lassen sie sich leicht unterscheiden und man
kann @notiz und $notiz haben.
Larry Wall sieht das $ als Zeichen für Einzahl und @ als Zeichen
für Mehrzahl an, so wie im deutschen die Endung „en“. Wenn man das
weiß, wird auch klar, wieso man $notiz[0] schreiben muss, wenn man
die erste Nachricht aus @notiz haben will und wieder
@notiz[0,1] wenn die erste und zweite Nachricht interessiert.
Das Füttern der Arrays ist denkbar einfach:
my @ziffern = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9);
my @ziffern = (0 .. 9); # das Gleiche kuerzer
# dank dem Rangeoperator ..
my @farben = ('rot', 'blau', 'gruen', 'gelb');
my @farben = qw(rot blau gruen gelb); # kuerzer
Runde Klammern umfassen ein Array, auch das Array an Werten, die
einem Befehl gegeben werden. Dort kann man sie aber oft weglassen,
und sie werden nur geschrieben, um klar zu stellen, wo das Array
endet. qw („quote words“, setze von Leerzeichen oder Tabulatoren
getrennte Wörter in Anführungszeichen) ist schon praktisch, aber im
Moment drängt eher die Frage: Wie trennt man den Dateiinhalt in
einzelne Zeilen? Wer genau aufgepasst hat, ahnt vielleicht, dass
read_file mitbekam, dass say ein Array an Werten erwartete und
es auch lieferte.
if (-e $datei) {
my @notizen =
read_file( $datei );
print @notizen;
}
print "Neue Notiz (nur Enter wenn
keine): ";
my $notiz = <STDIN>;
append_file($datei, $notiz)
if $notiz ne "\n";
Über Arrays iterieren
Schöner wäre es, wenn vor jeder Nachricht die Nummer stünde, sodass
der Nutzer entscheiden kann, welche Nachricht gelöscht werden soll. Dazu
braucht es eine Schleife. Damit sind weder
Knoten noch Rennkurven
gemeint, sondern Blöcke, die mehrmals ausgeführt werden. Wie oft
die Schleife durchlaufen wird, entscheidet entweder eine Bedingung
wie bei if (dazu nächstes Mal mehr) oder man wählt die
for-Schleife. (Man kann auch auch foreach schreiben.) In die
runden Klammern nach for kommt ein Array oder eine Liste an
Werten. Der darauffolgende Block wird für jeden Wert der Liste einmal
ausgeführt und die sogenannte Laufvariable hat bei jeder Runde als
Inhalt diesen Wert.
for my $notiz (@notizen) { print $notiz; }
Achtung: Auch wenn die Definition von $notiz vor dem Block
geschieht, gibt es die Variable nur innerhalb des Blocks.
Gesucht waren aber auch die Nummern der Notizen. Also sollte
man die Nummern hochzählen und mit der Nummer bekommt man per $notizen[$nr] auch die zugehörige Notiz. Zum Glück weiß jedes
Array, wie viele Elemente es hat. Im skalaren Kontext verrät es das
oder man lässt sich mit $#notizen die Nummer des letzten Elements
geben, was eins weniger als die Gesamtzahl ist. Mit diesem Wissen wird
Folgendes möglich:
for my $nr (0 .. $#notizen)
{ print "[$nr]", $notizen[$nr] }
Die ersten eckigen Klammern bei print sind nur Dekoration für die
Aufzählung. Und natürlich kennt Perl eine kürzere Version dieser
Zeile. Wenn keine Laufvariable benannt wird, gibt es eine
Spezialvariable, welche diese Aufgabe übernimmt. $_ ist die
absolut prominenteste Spezialvariable. Wie andere Prominenz auch,
bestimmt sie gerne das Thema. Wenn einmal
das Gesprächsthema steht
(z. B. der Reliable Replacement Warhead), möchte man es nicht jedes
mal aussprechen. Man benutzt einen Pronom oder lässt sogar das
weg. Perl funktioniert auch hier wie eine natürliche Sprache. Wenn
Befehle wie
print gar keine Parameter/Daten
bekommen, schauen sie, was $_ anbietet.
Deshalb wirkt
for my $notiz (@notizen) { print $notiz; }
identisch zu
for (@notizen) { print }
was in der nachgestellten Form so aussieht:
print for @notizen;
die ebenfalls implizit, d. h. von außen nicht sichtbar, $_ benutzt.
Im aktuellen Fall ist $_ sichtbar, da die Laufvariable mehrfach
angewendet wird, bevor der auszugebende Text steht.
print "[$_] ", $notizen[$_]
for 0 .. $#notizen ;
Neue Aufgabe
Um das Niveau der „Hausaufgabe“ etwas zu heben, ein Hinweis vorab:
Um Werte aus dem Array zu löschen, braucht es den Befehl splice.
delete funktioniert an bestimmten Stellen nicht so, wie Anfänger
es sich vorstellen. Selbstständiges Nachschlagen in der Dokumentation
sollte jeder können, der sich Programmierer nennen will. Und wer
daran Gefallen findet, darf auch das Verschieben der Notizen
implementieren.
Ausblick
Im nächsten Teil des Tutoriums gibt es mehr zu Schleifen, mehr zu
Arrays und der dritte Variablentyp (neben Skalaren und Arrays) wird
vorgestellt. Auch Subroutinen (manche nennen auch sie Funktionen
oder Prozeduren) werden ein
Thema sein, um das Programm
verständlich und leicht änderbar zu halten.
Links
[1] http://www.freiesmagazin.de/freiesMagazin-2011-08
[2] http://de.wikipedia.org/wiki/Escapen
Autoreninformation |
Herbert Breunung (Webseite)
ist seit sieben Jahren mit Antworten, Vorträgen, Wiki- und
Zeitungsartikeln in der Perlgemeinschaft aktiv. Dies begann mit dem
von ihm entworfenen Editor Kephra,
den er leidenschaftlich gerne pflegt. Daneben beschäftigt er sich
hauptsächlich mit wxPerl und Perl 6.
|
|
Diesen Artikel kommentieren
Zum Index
von Robert Knauer
Fenstermanager gibt es viele, die bekanntesten sind wohl Metacity (GNOME 2), KWin
(KDE) oder Compiz. Diese Fenstermanager verfolgen alle ein ähnliches Konzept:
Die Fenster liegen relativ ungeordnet auf dem Bildschirm und können überall hin
verschoben werden. Tiling Fenstermanager, wie i3 [1], bauen auf
einem anderen Konzept auf: Diese behandeln den Bildschirm wie eine Art Tabelle. Dadurch
sind die Fenster (bis auf Ausnahmen) an einem festen Platz und können
durch Tastenkombinationen in andere Positionen gebracht werden.
Was zuerst seltsam klingt, entpuppt sich bei genauerem Hinsehen und Einarbeiten
als praktisch und zeitsparend. Auch die oft wenig benutzten Arbeitsflächen, die
auch bei anderen Fenstermanagern vorhanden sind, nutzt man so viel intensiver.
Für den folgenden Artikel sollte man Konfigurationsdateien editieren können und
kein Problem mit Manpages haben. Unter manchen Distributionen (z. B. Fedora,
openSUSE, Linux Mint) ist auch das Kompilieren von Programmen nötig.
Das Konzept
Bei i3 läuft fast alles über Tastenkombinationen ab, auf eine Maus kann man bei
der Steuerung von i3 verzichten. Konfiguriert wird der Fenstermanager nicht über
eine grafische Oberfläche sondern einzig und allein über eine
Konfigurationsdatei.
Fenster, die man in den Floating Mode versetzt hat, verhalten sich genau wie bei
einem gewöhnlichen Fenstermanager. Sie lassen sich mit der Maus beliebig
vergrößern, verkleinern und auch verschieben. Fenster, die nicht im Floating
Mode sind, ordnen sich automatisch so an, dass sie den Platz optimal ausnutzen.
Die Installation
Der Fenstermanager ist in den Paketquellen von Ubuntu, Debian und Arch Linux
vorhanden. Bei anderen Distributionen, wie z. B. Fedora, openSUSE oder Linux Mint
muss man i3 und auch i3lock und i3status (falls benötigt, darauf wird später
noch eingegangen) selbst kompilieren.
Wer einen Login-Manager wie xdm, gdm oder kdm verwendet, sollte nach der
Installation eine entsprechende Auswahlmöglichkeit vorfinden.
Ohne Login-Manager reicht der Eintrag exec i3 in der Datei ~/.xinitrc aus.
Zusätzlich muss dmenu installiert werden. Es
wird zum Starten von Anwendungen in
i3 verwendet und ist ebenfalls in den meisten Paketquellen vorhanden.
Die Grundlagen
Um ein Programm zu starten, drückt man „Alt“ + „V“ (in der Standardkonfiguration).
Dadurch öffnet sich am oberen Bildschirmrand dmenu, in das man ein Shellkommando
eintippen kann, in diesem Fall den Namen eines Terminals (beispielsweise xterm, roxterm
oder gnome-terminal). Es öffnet sich ein Fenster, das nicht mit der Maus
verschiebbar ist und den ganzen Bildschirm ausfüllt. Es ist fokussiert,
erkennbar am blauen Fensterrahmen.
Dieses Fenster wird nun mit „Alt“ + „Umschalt“ + „Leertaste“ in den Floating Mode versetzt.
Das Terminal ist nun ein kleines Fenster in der linken oberen Ecke, das mit
„Alt“ + „Umschalt“ + „Leertaste“ wieder in den normalen Tiling Modus versetzt wird.
Nachdem das Fenster wieder den ganzen Bildschirm ausfüllt, wird ein weiteres
Fenster geöffnet („Alt“ + „V“). Es erscheint unter dem anderen Fenster und nimmt nun
den halben Bildschirm ein. Wenn man das untere Fenster mit der Maus fokussiert
und „Alt“ + „Umschalt“ + „Pfeil rechts“ drückt wird der Bildschirm vertikal geteilt, das untere Fenster ist nun rechts.
Anstatt den Fokus mit der Maus zu wechseln können dazu auch die
Tastenkombinationen „Alt“ + „Richtungstaste“ verwendet werden.
Wenn
man nun das rechte Fenster fokussiert und
„Alt“ + „Umschalt“ + „ Pfeil runter“ drückt nimmt nun jedes Fenster ein Viertel des Bildschirms ein.
Jetzt soll das linke obere Fenster die ganze Bildschirmbreite einnehmen, das
rechte untere Fenster jedoch so bleiben. Dazu wird das obere Fenster fokussiert
und „Alt“ + „Strg“ + „Pfeil rechts“ gedrückt. Um die Aktion wieder rückgängig zu machen
drückt man „Alt“ + „Umschalt“ + „Pfeil links“. Um die Fenster wieder zu schließen, fokussiert man sie und drückt „Alt“ + „Umschalt“ + „Q“.
Eine weitere wichtige Eigenschaft von i3 sind die Arbeitsflächen. Es stehen 10 davon
zur Verfügung. Zwischen ihnen kann man mit „Alt“ + „Nummer“ (0-9) umschalten, ein
fokussiertes Fenster kann man mit „Alt“ + „Umschalt“ + „Nummer“ verschieben. Eine Übersicht
der benutzten Arbeitsflächen findet man links unten in der Ecke des Bildschirms.
Hier noch einmal die Tastenkombinationen:
Tastenkombinationen |
„Alt“ + „V“ | Programm starten (dmenu) |
„Alt“ + „Umschalt“ + „Leertaste“ | Wechsel Tiling Mode/Floating Mode |
„Alt“ + „Umschalt“ + „Pfeiltaste“ | Fenster verschieben (oder Fenster strecken rückgängig machen) |
„Alt“ + „Strg“ + „Pfeiltaste“ | Fenster über mehrere Spalten / Zeilen strecken |
„Alt“ + „Umschalt“ + „Q“ | Fenster schließen |
„Alt“ + „Nummer“ | Arbeitsfläche wechseln |
„Alt“ + „Umschalt“ + „Nummer“ | Fenster auf Arbeitsfläche verschieben |
„Alt“ + „Pfeiltaste“ | Fokus wechseln |
|
Mit diesem Wissen sollte man ein bisschen mit i3 rumprobieren, denn das sind die
Grundlagen, mit denen man schon ganz gut auskommt. Aber natürlich geht noch mehr.
Konfiguration
Die Konfigurationsdatei ist unter /etc/i3/config bzw. ~/.i3/config zu finden,
wobei die Datei im Home-Verzeichnis bevorzugt wird. Die Datei /etc/i3/config
sollte für den Anfang brauchbar sein, wenn man etwas ändern will, ist sie
relativ selbsterklärend.
Anpassung und Erweiterung
Statusbar
Auf den ersten Blick fällt bei i3 auf, dass es keine Panels gibt, also auch
keine Möglichkeit für eine Uhr, eine Anzeige des Netzwerkstatus, des Akkustands
und vieles weiteres mehr. Doch auch dafür gibt es eine Lösung: i3status [2].
i3status alleine ermittelt nur die nötigen Informationen (Uhrzeit, WLAN-Status
etc.), bereitet sie auf und gibt sie als Text an ein anderes Programm weiter,
welches dann die grafische Anzeige übernimmt. In diesem Beispiel wird dafür
dzen2 [3] verwendet.
Installation und Konfiguration
Es müssen i3status und dzen2 installiert werden (je nach Distribution aus der
Paketverwaltung oder selbst kompilieren). Nun muss die Datei /etc/i3status.conf
so angepasst werden, dass später die richtigen Informationen angezeigt werden.
Zuerst wird sichergestellt, dass in der general-Sektion der Konfigurationsdatei
output_format auf dzen2 gesetzt ist. Der Rest der Datei ist mit Beispielen
versehen, die den eigenen Bedürfnissen beliebig angepasst werden können, im
Zweifelsfall hilft auch die Manpage [4].
Nun kann getestet werden, ob die Konfiguration den Wünschen entspricht:
$ i3status | dzen2
Es erscheint eine Statusleiste am oberen Bildschirmrand. Wenn die angezeigten
Informationen den eigenen Wünschen entsprechen, fehlt nur noch die Konfiguration
von dzen2, da die Statusleiste am oberen Bildschirmrand die Fensterrahmen
verdeckt und am unteren Bildschirmrand (neben der Arbeitsflächen-Anzeige) somit
besser aufgehoben ist.
Als Vordergrundfarbe ist weiß am besten geeignet, als Hintergrundfarbe schwarz:
-fg white -bg black.
Da links die Arbeitsflächen sind, soll die Schrift am rechten Rand sein:
-ta r.
Außerdem muss noch ein Font festgelegt werden:
-fn misc-fixed-medium-r-normal--12-120-75-75-C-70-iso8859-1".
Jetzt folgen die Einstellungen, die man individuell anhand der
Bildschirmauflösung ausrechnen muss. Die Breite der Leiste:
-w Bildschirmbreite minus 195.
Die y-Position:
-y Bildschirmhöhe minus 15.
Und zum Schluss noch die x-Position:
-x 195.
In der Standardeinstellung beendet sich dzen2 bei einem Rechtsklick, das ist oft
nicht gewünscht und lässt sich wie folgt ausschalten:
-e button3=.
Mit diesen Optionen entsteht also folgender Kommandozeilen-Befehl:
$ i3status | dzen2 -fg white -bg black -ta r -fn "-misc-fixed-medium-r-normal--12-120-75-75-C-70-iso8859-1" -w Bildschirmbreite minus 195 -y Bildschirmhoehe minus 15 -x 195 -e button3=
Passen die Einstellungen nicht, hilft ein Blick in die README-Datei von dzen2 [5].
Wenn die Einstellungen getestet sind, kann man die Statusbar bei jedem Start von
i3 mitstarten lassen. Dazu genügt folgender Eintrag in die Konfigurationsdatei
von i3 (~/.i3/config bzw. /etc/i3/config):
exec i3status | dzen2 {dzen2-Parameter}
Danach ist ein Neustart von i3 nötig, von nun an wird i3status automatisch mit
gestartet.
Bildschirmhintergrund
Wer den tristen schwarzen Hintergrund satt hat, sollte xsri probieren. Mit diesem
kleinen Programm kann man auf den Rootscreen von X Bilder zeichnen lassen. Auch
hier hilft ein Blick in die Manpage [6].
Nach der Installation aus der Paketverwaltung kann man auch dieses Programm bei
jedem Start von i3 ausführen lassen. Dies geschieht mit einem kleinen Eintrag in der
Konfiguration von i3 ( ~/.i3/config bzw. /etc/i3/config):
exec xsri {Parameter}
Die Parameter muss man individuell auswählen, so kann man z. B. nur eine andere
Farbe als Hintergrund festlegen:
$ xsri -{}-color=FARBE
Oder man setzt einen Farbverlauf von oben nach unten:
$ xsri -{}-color=FARBE1 -{}-color2=FARBE2 -{}-vgradient
Oder vollzieht das Gleiche von links nach rechts:
$ xsri -{}-color=FARBE1 -{}-color2=FARBE2 -{}-hgradient
Oder man setzt auch ein Hintergrundbild, das im Idealfall genau so groß wie die
Bildschirmauflösung ist:
$ xsri /pfad/zum/bild
Das sind noch lange nicht alle Möglichkeiten. Wer noch mehr ausprobieren will,
sollte sich die oben erwähnte Manpage [6] ansehen.
Screenlocker
Auch um den Bildschirm zu sperren liefert i3 ein Werkzeug mit: i3lock [7] .
Nachdem man es installiert hat (wieder je nach Distribution aus der
Paketverwaltung oder selbst kompilieren), kann man es durch ein einfaches
$ i3lock
aufrufen. Der Bildschirm wird weiß und versetzt sich erst nach der Eingabe des
eigenen Passwortes wieder in den alten Zustand.
Aber natürlich kann man auch hier noch eine Menge Parameter übergeben:
- Standardmäßig forkt sich i3lock in den Hintergrund, wenn man das (aus welchem
Grund auch immer) nicht will, kann man diese Funktion mit -n bzw. --nofork
deaktivieren.
- Wenn man möchte, dass i3lock bei Eingabe eines falschen Passworts piept, hilft
der Parameter -b bzw. --beep.
- i3lock kann beim Start automatisch den Bildschirm ausschalten. Diese Funktion
wird mit -d bzw. --dpms aktiviert.
- Wenn man statt des weißen Bildschirms eine andere Farbe will, kann man diese
mit -c FARBE bzw. --color FARBE festlegen.
- Auch ein Bild lässt sich festlegen. Dazu verwendet man den Parameter -i /pfad/zum/bild bzw. --image /pfad/zum/bild.
- Zusammen mit dem Parameter -i bzw. --image kann man mit dem -t bzw. --tiling
Parameter festlegen, dass sich das Bild kacheln (wiederholen) soll.
- Ein kleines „Easteregg“ hat i3lock auch noch zu bieten. Wenn man ein Bild von
einem Desktop
und mit dem Parameter -p win bzw.
--pointer win einen Mauszeiger anzeigen lässt, scheint es so als ob der Computer
nicht gesperrt ist. Vielleicht fällt ja irgendwann mal jemand drauf herein …
Genauere Beschreibungen der Parameter findet man auch in der Manpage [8].
Außerdem muss noch angemerkt werden, dass i3lock für Bildunterstützung (-i
bzw. --image) mit der Cairo-Bibliothek kompiliert sein muss. Das ist nur bei
Ubuntu der Fall, Arch Linux bietet dazu ein Paket im AUR [9]. Bei anderen
Distributionen muss man mit den entsprechenden Parametern selbst kompilieren.
Fazit
Für experimentierfreudige Nutzer, die nicht vor Konfigurationsdateien
zurückschrecken, ist i3 auf jeden Fall einen Blick wert. Ob man im Endeffekt die
Einarbeitungszeit für den Umstieg aufbringen will, muss jedoch natürlich jeder
selbst für sich entscheiden.
Wer sich an den Umstieg wagen will, sollte sich auf jeden Fall auch den
„i3
User's Guide“ [10] genauer
ansehen. In der Anleitung werden alle Möglichkeiten, die der
Fenstermanager i3 bietet, ausführlich erklärt.
Links
[1] http://i3wm.org/
[2] http://i3wm.org/i3status/
[3] http://dzen.geekmode.org/
[4] http://i3wm.org/i3status/manpage.html
[5] http://dzen.googlecode.com/svn/trunk/README
[6] http://linux.die.net/man/1/xsri
[7] http://i3wm.org/i3lock/
[8] http://manpages.ubuntu.com/manpages/natty/man1/i3lock.1.html
[9] https://aur.archlinux.org/packages.php?ID=50985
[10] http://i3wm.org/docs/userguide.html
Autoreninformation |
Robert Knauer
benutzt seit 3 Jahren Linux, anfangs Ubuntu mit GNOME. Vor einem
Jahr kam der Wechsel auf Arch Linux mit i3 und ist seitdem begeistert von den
Möglichkeiten eines Tiling Fenstermanagers.
|
|
Diesen Artikel kommentieren
Zum Index
von Jochen Schnelle
Datenbanksysteme gibt es heutzutage viele – sowohl relationale wie
z. B. MySQL, PostgreSQL oder Oracle als auch die verschiedenen
Systeme aus dem Bereich der sogenannten „NoSQL“-Datenbanken (siehe
„NoSQL – Jenseits der relationalen Datenbank“ in freiesMagazin
8/2010 [1]). Zu
letzteren gehört auch Cassandra [2],
wobei diese Datenbank in sofern „anders“ ist, als dass sie
ursprünglich von Facebook [3] speziell für
Facebook und deren spezifische Probleme entwickelt wurde.
Entwicklung
Die Entwicklung von Cassandra wurde durch das sogenannte „Inbox
Search Problem“ motiviert. Dabei geht es darum, dass ein
Facebooknutzer seine erhaltenen und gesendeten Nachrichten nach
Begriffen durchsuchen kann. Grundsätzlich ist dies natürlich leicht
machbar. Bei Facebook bestand das Problem aber darin, dass es für
die Anzahl der aktiven Nutzer kombiniert mit der gespeicherten und
konstant (sowie vermutlich relativ schnell) wachsenden Datenmenge
keine ausreichend performante Lösung mehr mit MySQL & Co. gab. Also
wurde Cassandra entwickelt – und das Problem damit erfolgreich
gelöst. Die Datenbank ist dabei in Java implementiert.
Aufgrund der Anforderungen ist es nicht verwunderlich, dass
Cassandra auf hohe Schreib- und Lesedurchsätze optimiert ist, wobei
in der Standardeinstellung die Schreibvorgänge asynchron erfolgen,
d. h. die Daten werden erst im RAM gehalten und dann „gebündelt“ auf
die Festplatte geschrieben. Des Weiteren unterstützt Cassandra die
Partitionierung der Datenbank, wobei die Rechner auch an
verschiedenen Orten (Rechenzentren) stehen können. Außerdem
beherrscht die Datenbank Replikation, automatische Erkennung von
ausgefallenen Rechnern im Datenbankverbund und ist sehr gut
skalierbar. Die Details und Hintergründe hierzu findet man in der
sechsseitigen Veröffentlichung „Cassandra – A Decentralized
Structured Storage System“ [4],
welche sehr empfehlenswert ist, wenn man sich näher mit Cassandra
beschäftigen möchte.
Open Source
Nun erfreut sich Facebook bekanntlich nicht uneingeschränkter
Beliebtheit unter den Computernutzern und mancher Leser mag
Cassandra deswegen kritisch gegenüberstehen. Erfreulicherweise kann
an dieser Stelle aber Entwarnung gegeben werden: Cassandra wurde im
Frühjahr 2009 an die Apache Foundation [5]
übergeben und ist somit Open Source unter der Apache-Lizenz. Seit
Februar 2010 ist die Datenbank ein „Top-Level-Projekt“, die
Entwicklung wird somit aktiv vorangetrieben.
Datenmodell
Cassandra besitzt ein relativ einfaches Datenmodell [6] [7].
Dies ist eine Mischung aus einem Key-Value-Store und einer
spaltenorientierten Datenbank [8].
Die Daten werden dabei in „Column Families“ (kurz: CF) organisiert.
Eine CF besteht aus beliebig vielen „Row Keys“, welchen wiederum
beliebig viele Schlüssel-Werte-Paare zugeordnet werden können. Im
Cassandra-Kontext werden die Schlüssel dabei als „Column“ (auf
deutsch: Spalte) bezeichnet. Eine CF ist also eine mehrdimensionale
Map. Verschiedenen Row Keys können Werte für gleiche Spalten
zugeordnet werden – dies muss aber nicht der Fall sein. Des
Weiteren ist das Datenmodell von Cassandra zwar strukturiert, es
besteht aber keine Notwendigkeit der Definition vorab. Das heißt im
laufenden Betrieb können jederzeit neue Columns hinzugefügt werden.
Eine Column Family mit zwei Row Keys kann also z. B. so aussehen:
Row Key: "User_1"
Column "Name" - Wert: "Otto"
Column "Alter" - Wert: "40"
Row Key: "User_2"
Column "Name" - Wert: "Susi"
Column "Alter" - Wert: "25"
Column "Nickname" - Wert: "TurboS"
Neben den zuvor beschriebenen Column Families kennt Cassandra noch
„Super Columns“. Hierbei handelt es sich um eine erweiterte
Variante der normalen CF, die eine Ebene mehr hat. Dies kann man
sich so vorstellen, dass die Column wiederum eine Column Family
ist. Das folgenden Schema verdeutlicht dies:
Row Key: "User_1":
Super Column "Name":
Column "Vorname" - Wert: "Otto"
Column "Nachname" - Wert: "Normal"
Super Column "Kontaktdaten":
Column "E-Mail" - Wert: "otto@example.de"
Column "Jabber" - Wert: "on@superjabber.de"
Row Key: "User_2":
Super Column "Vorname":
Column "Vorname" - Wert: "Susi"
Column "Nachname" - Wert: "Sorglos"
Column "Maedchenname" - Wert: "Sonnenschein"
Super Column "Kontaktdaten":
Column "E-Mail" - Wert "susi@sorglos.de"
Zu erwähnen ist noch, dass die Datenbank zusätzlich zu jedem Wert
einen „Timestamp“ (auf deutsch: Zeitstempel) speichert, der angibt, wann der
Wert in die jeweilige Column geschrieben wurde. Dies geschieht automatisch.
CF und Super Columns wiederum werden in „Keyspaces“ abgelegt. Ein
Keyspace kann dabei beliebig viele Column Families und Super
Columns enthalten. Die Daten sind dabei aber völlig getrennt
voneinander, der Keyspace ist also eine Art „Sammelcontainer“.
Abfragen der Datenbank über mehrere Column Families hinweg, was
einem „Join“ über mehrere Tabellen in relationalen Datenbanken
entspräche, gibt es in Cassandra nicht.
Cassandra kennt keine verschiedenen Datentypen, alles wird intern als
„ByteType“ gespeichert, wobei sowohl Schlüssel als auch Werte
beliebig
lang sein können. Da binäre Daten für Menschen bekanntlich
recht schwierig zu lesen sind, gibt es natürlich auch die
Möglichkeit, Daten z. B. als ASCII- oder UTF-8-Text zu speichern.
Installation
Die Installation von Cassandra ist recht simpel. Die einzige
Voraussetzung ist, dass Java auf dem Rechner installiert ist.
Cassandra ist nicht sonderlich wählerisch, was die
Java-Implementierung angeht, solange es eine halbwegs aktuelle
Version 6 (bezogen auf Sun Java) ist. Die Datenbank läuft mit Sun
Java, OpenJDK (welches viele Linux-Distributionen mitbringen) sowie
diversen anderen Java-Implementierungen, welche aber eher im
gewerblichem Umfeld zu finden sind.
Danach muss man lediglich von der Downloadseite des
Projekts [9] das
aktuelle, gepackte Archiv mit der vorkompilierten Version
herunterladen und diese in ein Verzeichnis entpacken. Zum lokalen
Testen kann dies im Homeverzeichnis erfolgen, für die systemweite
Nutzung empfiehlt sich unter Linux/Unix natürlich eher /opt.
Cassandra läuft aber auch unter Windows. Dazu sind nur
einige Pfade (z. B. für den Speicherort der Logdateien) anzupassen,
da in der Voreinstellung Unix-/Linux-Pfade eingetragen sind.
Details dazu findet man im Blogeintrag „Cassandra Installation and
Configuration“ [10].
Im Folgenden wird davon ausgegangen, dass Cassandra im Verzeichnis
/opt/cassandra liegt. Für diesen Artikel wurde die
Programmversion 0.8.2 verwendet.
Erste Schritte
Bevor es richtig los geht, noch einige Bemerkungen vorab: Im
Folgenden wird das Schreiben und Lesen von Daten in die Datenbank
an sich gezeigt. Dazu wird eine einzelne Instanz der Datenbank auf
dem lokalen Rechner genutzt. Wer Partitionierung, Replikation und
Ähnliches nutzen möchte, dem seien die diversen Hilfeseiten zu
diesen Themen im Cassandra-Wiki [11]
empfohlen. Des Weiteren unterstützt Cassandra auch die
Authentifizierung von Nutzern [12],
worauf hier auch nicht weiter eingegangen wird. Ein Großteil der
Konfiguration wird in der Datei /opt/cassandra/conf/cassandra.yaml
vorgenommen [13].
Als Erstes muss man die Datenbank starten. Dies geschieht via
Terminal mit Root-Rechten und dem Befehl
# /opt/cassandra/bin/cassandra
Das Programm startet dabei dann automatisch im Hintergrund
(Daemon), wobei nichtsdestotrotz beim Start eine Reihe vom
Meldungen ausgegeben werden. Sollte hier ein Fehler auftreten, so
sollte man zuerst die Java-Version prüfen. Ist der Start
erfolgreich verlaufen, so lauscht die Datenbank jetzt auf
localhost und Port 9160. Möchte man das Programm im Vordergrund
starten, um z. B. beim Testen alle Ausgaben im Terminal zu sehen, so
fügt man einfach die Option -f beim Start hinzu.
Cassandra an sich wird über die
Thrift-Schnittstelle [14] angesprochen.
Neben Java gibt es auch noch für diverse andere Programmiersprachen
wie Python, Ruby und Perl Bibliotheken, um auf die Datenbank
zuzugreifen. Im Folgenden wird auf die Cassandra-Kommandozeile
(kurz: Cassandra CLI) zurückgegriffen, welche in der
Standardinstallation bereits enthalten ist. Die Kommandozeile
startet man über den Befehl
$ /opt/cassandra/bin/cassandra-cli
woraufhin eine kurze Willkommensmeldung und der neue Prompt
[default@unknown]
erscheint. Die Eingabe von
[default@unknown] help;
listet alle verfügbaren Befehle auf, wobei die Liste mit 24 Befehlen
sehr übersichtlich ist. Eine recht detaillierte Hilfe zu jedem
Befehl ist ebenfalls vorhanden. Diese erreicht man, indem man
help gefolgt vom Befehl aufruft, also z. B.
[default@unknown] help create keyspace;
Wie man sieht, muss jede Befehlszeile – wie unter Java auch üblich –
mit einem Semikolon ; abgeschlossen werden.
Jetzt verbindet man sich mit dem laufenden Cassandra-Server über den
Befehl
[default@unknown] connect localhost/9160;
Eine kurze Statusmeldung zeigt, ob die Verbindung erfolgreich
erstellt wurde. Da außer dem Keyspace System, welche von der
Datenbank selbst genutzt wird, keiner angelegt ist, muss zuerst ein
neuer angelegt werden:
[default@unknown] create keyspace demo;
Weiterhin muss man der Datenbank mitteilen, dass man diesen jetzt
aktiv nutzen möchte:
[default@unknown] use keyspace demo;
Der Prompt ändert sich dann auch zu
[default@demo]
Eine Column Family anlegen und löschen
Jetzt kann man eine oder mehrere Column Families oder Super Columns
anlegen. Dies geschieht mit dem Befehl
[default@demo] create column family Kontakt;
wodurch die CF Kontakt angelegt wird. Diese CF kann man nun mit Inhalt
füllen. Allerdings erwartet Cassandra alle Schlüssel, Spalten und
Werte in der Form „BytesType“, dem weiter oben bereits erwähnten
Standarddatentyp. Dieser ist für Menschen aber schwerlich zu
nutzen, daher empfiehlt es sich, Text UTF-8-kodiert abzulegen. Dazu
gibt es drei Wege.
Der erste Weg ist, dass man die Datenbank veranlasst anzunehmen,
dass alles UTF-8 ist. Dies erledigt man mit dem Befehl assume (auf
Deutsch: „annehmen“):
[default@demo] assume Kontakt comparator as utf8;
Assumption for column family 'Kontakt' added successfully.
[default@demo] assume Kontakt validator as utf8;
Assumption for column family 'Kontakt' added successfully.
[default@demo] assume Kontakt keys as utf8;
Assumption for column family 'Kontakt' added successfully.
Auf diesem Weg wurde für Spaltennamen, Werte und Schlüssel UTF-8 als
Eingabe- und Ausgabekodierung festgelegt. Der Erfolg jedes
assume-Befehls wird bestätigt (wie oben auch zu sehen ist).
Der zweite Weg wäre, dass man die Kodierung
direkt beim Anlegen der
CF angibt. Dies bietet sich immer dann an, wenn man weiß, dass man
eine feste Anzahl von Spalten hat. Der Befehl dafür lautet:
[default@demo] create column family Kontakt2 with key_validation_class = UTF8Type and comparator = UTF8Type and
... column_metadata = [
... {column_name: 'name', validation_class: UTF8Type},
... {column_name: 'alter', validation_class: IntegerType}];
wodurch man die CF Kontakt2 angelegt hat.
Der dritte Weg besteht darin, jedem Wert explizit die Kodierung
voranzustellen, was weiter unten im Abschnitt „Zählerspalten“
genutzt wird. Da dies aber zumindest auf der Kommandozeile
erheblich mehr Tipparbeit ist, empfiehlt sich dieser Weg nur für
kurze Tests bzw. Abfragen.
Zurück zum Beispiel: Da im folgenden die CF Kontakt nicht mehr
benötigt wird, kann diese gelöscht werden, und zwar mit dem Befehl
drop:
[default@demo] drop column family Kontakt;
Daten einpflegen
Jetzt kann man Daten in die Datenbank einpflegen. Die API von
Cassandra ist hier recht simpel, weil es nur drei Operationen gibt:
set, also das Hinzufügen von Daten, get, das Abfragen von Daten
und del zum Löschen von Daten.
Als Erstes werden ein paar Daten in den Datenbank eingegeben:
[default@demo] set Kontakt2['User_1']['alter'] = 25;
Value inserted.
[default@demo] set Kontakt2['User_1']['name'] = 'Susi';
Value inserted.
So wurde in der CF Kontakt2 der Schlüssel User_1 angelegt,
die Spalte alter mit dem Wert 25 und die Spalte name mit dem
Wert Susi gefüllt. Cassandra unterscheidet bei den Spaltennamen
übrigens zwischen Groß- und Kleinschreibung, d. h. man könnte sowohl
eine Spalte name als auch eine Spalte Name in der selben CF
haben. Weiterhin können Werte auch temporär angelegt werden. Dazu
muss man zusätzlich eine Time to live (übersetzt:
Überlebenszeit) in Sekunden angeben. Nach Ablauf der Zeit löscht
die
Datenbank den Wert dann selbstständig [15].
Möchte man diese Daten nun abfragen, geschieht dies beispielsweise mit dem folgendem Befehl:
[default@demo] get Kontakt2['User_1'];
=> (column=alter, value=25, timestamp=1311881829502000)
=> (column=name, value=Susi, timestamp=1311881821337000)
Returned 2 results.
Im obigen Beispiel
wurden alle Daten von User_1 abgefragt. Natürlich kann man
zusätzlich auch noch die Spalte spezifizieren, wie zum Beispiel:
[default@demo] get Kontakt2['User_1']['name'];
=> (column=name, value=Susi, timestamp=1311881821337000)
Möchte man alle Datensätze einer CF abfragen, so lautet der Befehl:
[default@demo] list Kontakt2;
Using default limit of 100
-------------------
RowKey: User_1
=> (column=alter, value=25, timestamp=1311881829502000)
=> (column=name, value=Susi, timestamp=1311881821337000)
Für das folgende Beispiel wird noch ein zweiter und dritter Datensatz
angelegt:
[default@demo] set Kontakt2['User_2']['name'] = 'Otto';
Value inserted.
[default@demo] set Kontakt2['User_2']['alter'] = 30;
Value inserted.
[default@demo] set Kontakt2['User_3']['name'] = 'Susi';
Value inserted.
[default@demo] set Kontakt2['User_3']['alter'] = 30;
Value inserted.
Cassandra unterstützt auch die Indizierung von Spalten, um nach
Werten in Spalten über mehrere Schlüssel hinweg suchen zu können.
Die Indizierung muss explizit vorgenommen werden. Dazu aktualisiert
man die Definition der CF Kontakt2:
[default@demo] update column family Kontakt2 with key_validation_class = UTF8Type and comparator = UTF8Type and
... column_metadata = [
... {column_name: 'name', validation_class: UTF8Type},
... {column_name: 'alter', validation_class: IntegerType, index_type: KEYS}];
Mit dem Befehl update wird eine vorhandene CF komplett
aktualisiert, weshalb man auch sämtliche Vorgaben, die man schon bei
create gemacht hat, wiederholen muss, weil diese sonst wieder mit
den Standardvorgaben überschrieben werden. Hier wird mit dem Update
zusätzlich die Spalte alter indiziert. KEYS ist übrigens der
einzige Indextyp, der aktuell von Cassandra unterstützt wird.
Das erfolgreiche Anlegen des Indexes kann man auch prüfen (die
folgende Ausgabe ist gekürzt):
[default@demo] describe keyspace demo;
Keyspace: demo:
...
Column Families:
ColumnFamily: Kontakt2
...
Built indexes: [Kontakt2.Kontakt2_alter_idx]
Column Metadata:
Column Name: alter
Validation Class: org.apache.cassandra.db.marshal.IntegerType
Index Name: Kontakt2_alter_idx
Index Type: KEYS
Column Name: name
Validation Class: org.apache.cassandra.db.marshal.UTF8Type
Mit Hilfe des Indexes kann man jetzt Abfragen starten, wie z. B.:
[default@demo] get Kontakt2 where alter = 30;
-------------------
RowKey: User_2
=> (column=alter, value=30, timestamp=1311882142180000)
=> (column=name, value=Otto, timestamp=1311882132982000)
-------------------
RowKey: User_3
=> (column=alter, value=30, timestamp=1311882174898000)
=> (column=name, value=Susi, timestamp=1311882156188000)
Cassandra kann übrigens nicht allein abfragen, ob ein Wert kleiner oder
größer ist. Der Befehl
[default@demo] get Kontakt2 where alter < 30;
No indexed columns present in index clause with operator EQ
führt, wie man sieht, zu einem Fehler. Weitere Hinweise und Details
zu Indices findet man in der Dokumentation [16].
Möchte man etwas löschen, so dient dazu der Befehl del:
[default@demo] del Kontakt2['User_3'];
row removed.
del akzeptiert als Argument nicht nur – wie hier im Beispiel –
Rowkeys, sondern auch Spaltennamen, sowohl von regulären Spalten
als auch von im Folgenden beschriebenen „Super Columns“.
Anlegen von „Super Columns“
Das Anlegen von CF vom Typ „Super Columns“ funktioniert im Prinzip
genauso, nur muss man angeben, dass man eine Super Column anlegen will:
[default@demo] create column family Super1 with column_type = 'Super' and comparator = 'UTF8Type' and
... subcomparator = 'UTF8Type' and key_validation_class = 'UTF8Type';
column_type legt also fest, dass die CF vom Typ Super sein soll.
Jetzt kann man wie gewohnt Daten eingeben, wobei man eine Spalte
mehr hat, nämlich die Super Column:
[default@demo] set Super1['User_1']['name']['vorname'] = 'Susi';
Value inserted.
[default@demo] set Super1['User_1']['name']['nachname'] = 'Sorglos';
Value inserted.
[default@demo] set Super1['User_1']['kontaktdaten']['email'] = 'susi@sorglos.de';
Value inserted.
name und kontaktdaten sind in diesem Beispiel die Super Columns.
Abfragen funktionieren analog wie bei normalen CFs:
[default@demo] get Super1['User_1'];
=> (super_column=kontaktdaten,
(column=email, value=susi@sorglos.de, timestamp=1311963575308000))
=> (super_column=name,
(column=nachname, value=Sorglos, timestamp=1311963511018000)
(column=vorname, value=Susi, timestamp=1311963486598000))
Weitere Informationen findet man im Cassandra-Wiki und auch im
Blogeintrag „WTF is a Super Column“ [17],
welcher auch ein Beispiel für die Umsetzung der Datenbankstruktur
für ein Blog enthält.
Wer ein komplettes, lauffähiges Programm sucht, welches auf
Cassandra basiert, dem sei Twissandra [18]
empfohlen. Das ist ein Twitter-Klon, der in Python geschrieben ist und Cassandra
als Datenbank im Hintergrund verwendet.
Alternative Spaltennamen
Bisher wurde immer ein Text als Spaltenname verwendet. Dies ist zwar
in vielen Fällen sinnvoll, Cassandra erlaubt aber auch andere
Alternativen, wie z. B. eine zeitbasierte UUID („Universally Unique
Identifier“, auf Deutsch „universelle, eindeutige
Identifizierung“), im Cassandra-Kontext „timeuuid“ genannt. Der
Einsatz einer timeuuid ist immer dann sinnvoll, wenn man Werte
zeitabhängig sortieren will, z. B. versendete oder empfangene
Nachrichten. Der Einsatz von timeuuid als Spaltenname ist nicht
weiter schwierig:
[default@demo] create column family Nachrichten with key_validation_class = 'UTF8Type' and comparator = 'LexicalUUIDType';
... schemas agree across the cluster
[default@demo] set Nachrichten['User_1'][timeuuid()]=utf8('Text 1');
Value inserted.
[default@demo] set Nachrichten['User_1'][timeuuid()]=utf8('Text 2');
Value inserted.
[default@demo] set Nachrichten['User_1'][timeuuid()]=utf8('Text 3');
Value inserted.
[default@demo] get Nachrichten['User_1'];
=> (column=f02fde80-c123-11e0-0000-10dcf378bfff, value=Text 1, timestamp=1312742091887000)
=> (column=f3aa5f40-c123-11e0-0000-10dcf378bfff, value=Text 2, timestamp=1312742097719000)
=> (column=f5dd44d0-c123-11e0-0000-10dcf378bfff, value=Text 3, timestamp=1312742101405000)
Returned 3 results.
Man muss also lediglich als Spaltenname timeuuid() einsetzen. Dies
funktioniert natürlich auch bei Super Columns.
Zählerspalten
Zu guter Letzt sei noch erwähnt, dass Cassandra auch „Counter
Columns“ (auf Deutsch: „Zählerspalten“) kennt. Diese müssen beim
Anlegen der CF explizit definiert werden:
[default@demo] create column family zaehler with default_validation_class=CounterColumnType;
Mit den Befehlen incr und decr können nun die Zähler erhöht und
reduziert werden:
[default@demo] incr zaehler[utf8('User_1')][utf8('zahl')];
Value incremented.
[default@demo] incr zaehler[utf8('User_1')][utf8('zahl')];
Value incremented.
[default@demo] get zaehler[utf8('User_1')];
=> (counter=7a61686c, value=2)
Returned 1 results.
[default@demo] incr zaehler[utf8('User_1')][utf8('zahl')] by 10;
Value incremented.
[default@demo] decr zaehler[utf8('User_1')][utf8('zahl')] by 5;
Value decremented.
[default@demo] get zaehler[utf8('User_1')];
=> (counter=7a61686c, value=7)
Für wenn ist Cassandra interessant?
Die allerwenigsten Nutzer werden auch nur annähernd so viele
Daten haben, dass sie eine verteilte Datenbank brauchen, welche
zusätzlich hohe Schreib-/Leseraten bietet und auch Datenmengen im
zweistelligen Terabyte-Bereich handhaben kann. Replikation
beherrschen heutzutage ebenfalls viele Datenbanken, inkl. die
Vertreter aus der relationalen Riege wie MySQL oder PostgreSQL
(seit dem letzten Major-Release).
Nichtsdestotrotz ist Cassandra auch für kleine Datenmengen und
einfache Setups von Interesse, wenn man sich das Datenmodell zu
Nutze macht. Die Daten werden in den Column Families bzw. Super
Columns zwar hoch strukturiert gespeichert, es besteht jedoch kein
Zwang, vorab ein Schema in Form von Spaltennamen oder Schlüssel
festzulegen. Von daher bietet sich Cassandra für Anwendungen mit
dynamisch wachsenden Inhalten, wie z. B. Blogs und Wikis, an. Für
diese ist weiterhin auch interessant, dass die Datenbank
standardmäßig einen Zeitstempel mitschreibt, sodass das
chronologische Auslesen ohne Weiteres mit Bordmitteln erledigt
werden kann. Dazu sei auch noch gesagt, dass die APIs in den
verschiedenen Programmiersprachen zumeist Möglichkeiten
bieten, die Sortierreihenfolge zu beeinflussen, was auf der
Kommandozeile nicht möglich ist. Der Zeitstempel kann z. B. für den
Revisionsverlauf in einem Wiki oder den zeitlichen Verlauf eines
Blogs genutzt werden.
Weiterhin kann es ein Vorteil sein, dass Cassandra sehr einfach zu
installieren ist. Außer einer halbwegs aktuellen Java-Version hat
das Programm keine Abhängigkeiten und ist nach dem Entpacken des
Download-Archivs direkt einsatzbereit.
Fazit
Cassandra bietet einen interessanten Ansatz, Daten strukturiert zu
speichern, ohne an ein festes Schema gebunden zu sein. Dabei bietet
sich die Datenbank in erster Linie für Text an. Weiterhin skaliert
Cassandra sehr gut, sodass der Einsatz einer einzelnen,
gegebenenfalls lokalen Instanz genauso möglich ist, wie ein
Datenbankverbund über mehrere Rechner und Rechenzentren hinweg.
Links
[1] http://www.freiesmagazin.de/freiesMagazin-2010-08
[2] http://cassandra.apache.org/
[3] http://www.facebook.com/
[4] http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf
[5] http://www.apache.org/
[6] http://wiki.apache.org/cassandra/DataModel
[7] http://maxgrinev.com/2010/07/09/a-quick-introduction-to-the-cassandra-data-model/
[8] http://de.wikipedia.org/wiki/Spaltenorientierte_Datenbank
[9] http://cassandra.apache.org/download/
[10] http://schabby.de/cassandra-installation-configuration/
[11] http://wiki.apache.org/cassandra/
[12] http://www.datastax.com/docs/0.8/configuration/authentication
[13] http://wiki.apache.org/cassandra/StorageConfiguration
[14] http://thrift.apache.org/
[15] http://www.datastax.com/docs/0.8/cli/using_cli#setting-an-expiring-column
[16] http://www.datastax.com/docs/0.8/data_model/secondary_indexes
[17] http://arin.me/blog/wtf-is-a-supercolumn-cassandra-data-model
[18] https://github.com/twissandra/twissandra
Autoreninformation |
Jochen Schnelle (Webseite)
interessiert sich zwar nur marginal für Facebook,
das Konzept von Cassandra hat aber trotzdem sein Interesse geweckt.
|
|
Diesen Artikel kommentieren
Zum Index
von Jochen Schnelle
Wer seine Python-Kenntnisse vertiefen und verbessern will, wird sich
früher oder später auch mit der Standardbibliothek beschäftigen. Da
Python der Philosophie „batteries included“ folgt, ist diese recht
umfangreich. Auch wenn die Online-Dokumentation [1]
sehr ausführlich ist, so
wünscht man sich vielleicht doch an der ein oder anderen Stelle
weniger Erklärungen der API und ein paar mehr Beispiele. An diesem
Punkt setzt das Buch „The Python Standard Library by Example“ an.
Hält man das Buch in den Händen fällt zunächst auf, dass es sich
durchaus um „schwere“ Literatur handelt. 1300 Seiten und ein
Gewicht von etwas mehr als 1,6 kg sind mehr als die meisten anderen
IT-Bücher. Das Buch ist also nichts für die kleine Gute-Nacht-Lektüre, über die man einschlafen möchte und die einem dann
auf den Kopf fällt.
Das Buch ist in 19 thematisch geordnete Kapitel unterteilt, welche
wiederum in Unterkapitel untergliedert sind: eins pro vorgestelltem
Modul. Je nach Umfang und Komplexität des jeweiligen Moduls sind die
Unterkapitel zwischen zwei und ca. 40 Seiten lang. Die Themengebiete,
welche unter anderem behandelt werden, sind: Text inklusive regulärer
Ausdrücke, Datenstrukturen, Dateizugriff, persistente Datenspeicherung
(Datenbanken), Umgang mit Archiven und Datenkompression, Threads und
Prozesse, Internet-/Netzwerkzugriff, Anpassen der Python-Umgebung
sowie Tests, Debugging, Performancemessung und -verbesserung.
Die Struktur der Kapitel ist dabei immer gleich. Zu Beginn jedes
Kapitels wird ein kurzer Überblick über die im Folgenden behandelten
Module und deren Aufgabe gegeben. Die Einleitung der Unterkapitel
besteht aus einer etwas detaillierten Einführung in das Modul sowie
einem Hinweis darauf, seit welcher Pythonversion es in der
Standardbibliothek enthalten ist. Das Ende jedes Unterkapitels bilden
Links auf weiterführende Literatur und weitere Erklärungen im
Internet.
Dazwischen findet man dann jede Menge Beispiele zu den Klassen und
Funktionen der jeweiligen Module. Dabei wird pro Beispiel, so weit
möglich, immer nur eine Klasse bzw. Funktion gezeigt, oft gefolgt
von einer kurzen Erläuterung. Alle Beispiele bestehen aus dem
Python-Quelltext sowie der zugehörigen Ausgabe des Programms. Die
meisten Beispiele nutzen viele print-Statements bzw. das
Logging-Modul, welche per Ausgabe auf die Kommandozeile deutlich
machen, was gerade passiert. Von daher ist es auch nicht verwunderlich,
dass man sehr wenige „echte“ Programme findet, bei denen man den
Programmcode eins zu eins für das eigene Projekt übernehmen kann. Allerdings
sollte es auch kein größeres Problem sein, aus den Beispielen und
zugehörigen Erklärungen ein „richtiges“ Programm zu bauen.
Der Autor, Doug Hellmann, selber Softwareentwickler und Communication
Director der Python Software Foundation, versteht es dabei geschickt,
die Beispiele kompakt aber trotzdem verständlich, übersichtlich und
nachvollziehbar zu halten. Gleiches gilt für den erklärenden Text
zwischen den Beispielen. Das Buch ist in gut verständlichem Englisch
geschrieben. Mit Schulenglisch und etwas Übung sollte man das Buch
weitgehend verstehen können.
„The Python Standard Library by Example“ ist aber kein Buch für
Neueinsteiger. Dies wird auch in der Einleitung explizit gesagt. Es
wird vorausgesetzt, dass man schon ein wenig Umgang mit Python hatte
und zumindest die grundlegenden Datentypen und eingebauten Befehle
geläufig sind. Ab der Stufe „fortgeschrittener Einsteiger“ sollte
man aber keine Probleme mehr haben, den überwiegenden Teil der Beispiele
nachzuvollziehen und zu verstehen. Hinzu kommt, dass die Kapitel alle
in sich abgeschlossenen sind und in beliebiger Reihenfolge gelesen
werden können bzw. – bei Desinteresse an einem bestimmten Thema –
auch ganze Kapitel beim Lesen ausgelassen werden können.
Das Buch bezieht sich komplett auf Python 2.x, wobei laut Aussage des
Autors alle Beispiele auch unter der neuesten und letzten 2er Version,
Python 2.7, getestet sind. Weiterhin ist noch anzumerken,
dass das Buch etwas Unix-/Linux-lastig ist. Dies liegt wohl auch
daran, dass der Autor selber Mac OS X einsetzt. Positiv ist dabei aber,
dass es immer einen Hinweis im Buch gibt, wenn ein Beispiel nicht unter
Windows lauffähig ist.
Weiterhin ist noch zu erwähnen, dass das Buch aus dem recht populären
Blog von Doug Hellmann „Python Module of the Week“ [2]
hervorgegangen ist.
Daraus macht der Autor auch keinen Hehl, diese Tatsache wird ebenfalls
in der Einleitung explizit erwähnt. Auch wenn für das Buch viele
Beispiele erweitert und aktualisiert wurden, so findet der regelmäßige
Leser des Blogs im Buch eher wenig Neues.
Das Buch kann auch als gute Ergänzung zu „Python – The Essential
Reference 4th Edition“ aus dem gleichen Verlag (Buchrezension siehe
freiesMagazin 9/2010 [3])
gesehen werden, da dort ebenfalls die
Standardbibliothek behandelt wird, aber mit weniger Beispielen und mehr
und umfassenderen Erklärung zur API.
Zusammenfassend kann gesagt werden: Wer sich intensiver mit Pythons
Standardbibliothek auseinandersetzen möchte oder wer in der
Standarddokumentation Beispiele vermisst, der sollte auf jeden Fall
über den Kauf dieses Buches nachdenken.
Buchinformationen |
Titel | The Python Standard Library by Example |
Autor | Doug Hellmann |
Verlag | Addison Wesley, 2011 |
Umfang | 1344 Seiten |
ISBN | 978-0321767349 |
Preis | ca. 40,- Euro |
|
Links
[1] http://docs.python.org/library/index.html
[2] http://www.doughellmann.com/PyMOTW/index.html
[3] http://www.freiesmagazin.de/freiesMagazin-2010-09
Autoreninformation |
Jochen Schnelle (Webseite)
programmiert selber in Python. Das Buch hat ihm einen
besseren und tieferen Einblick in verschiedene Module der
Standardbibliothek gegeben.
|
|
Diesen Artikel kommentieren
Zum Index
von Michael Niedermair
Das Buch „Python von Kopf bis Fuß“ von Paul Barry hat sich zur
Aufgabe gemacht, dem Anfänger die Programmiersprache Python
praxisnah und spielerisch zu vermitteln. Dabei wird auf die
Grundlagen der Sprache, das Wichtigste über Persistenz,
Ausnahmebehandlung, Webentwicklung, die Anbindung an die Datenbank
SQLite und die Google App Engine eingegangen oder wie man allgemein
„Daten in den Griff“ bekommt. Zusätzlich werden auch mobile Apps
für Android-Smartphones behandelt.
Was steht drin?
Das Buch ist in elf Kapitel aufgeteilt (plus Anhang und Index) und
umfasst 458 Seiten. Eine ausführliche Einführung (31 Seiten)
beschreibt den Inhalt, das Konzept von „Kopf bis Fuß“ und was den
Leser in jedem Kapitel erwartet.
Im ersten Kapitel (32 Seiten) geht es um die Einführung von Python,
die Installation der Version 3 und wie man mit IDLE leichter Python
lernen kann. Es wird anschließend gezeigt, wie man Listen erstellt, mit
diesen arbeitet und z. B. in Schleifen ausgibt. Mittendrin befindet
sich eine kleine FAQ. Es folgt die Erstellung von Funktionen
bei der auch gezeigt wird, was es mit Rekursion auf sich hat.
Im zweiten Kapitel (39 Seiten) wird Code wiederverwendet um zu zeigen,
wie z. B. Funktionen in Module umzuwandeln und dabei Namensräume anzuwenden
sind oder ein Paket zu erstellen ist. Im Anschluss wird gezeigt, wie
man seinen Code auf der Internetplattform PyPI (Python Package
Index [1]) als registrierter Nutzer
hochladen und somit anderen Leuten zur Verfügung stellen kann.
Im dritten Kapitel (31 Seiten) wird gezeigt, wie man mit Fehlern
umgeht und diese abfangen kann. Als Beispiel wird hier unter anderem
das zeilenweise Auslesen einer Textdatei und das Parsen der Zeilen
verwendet.
Im vierten Kapitel (34 Seiten) geht es um Persistenz und wie man
Daten in Dateien speichern und wieder auslesen kann.
Im fünften Kapitel (34 Seiten) wird der Umgang mit Daten beschrieben und
aufgezeigt, wie man diese sortiert, formatiert, entsprechend umwandelt und
Duplikate bei Listen erkennt.
Im sechsten Kapitel (40 Seiten) stehen Dictionaries sowie die
Erstellung von eigenen Klassen im Mittelpunkt und wie man Klassen
durch Vererbung erweitert.
Im siebten Kapitel (41 Seiten) wird gezeigt, wie man ein Programm
ins Web bekommt bzw. wie man eine „Webapp“ erstellt. Dabei wird auf
die entsprechende Datenmodellierung und das
MVC-Konzept [2]
eingegangen.
Im achten Kapitel (37 Seiten) geht es darum, wie man Python auf seinem
Smartphone einrichtet und hier kleine Anwendungen schreibt. Dabei wird
auch gezeigt, wie man mit dem Simulator auf dem PC die Anwendung
entwickeln und testen kann.
Im neunten Kapitel (58 Seiten) werden Formulare und Daten-Dialoge
bei mobilen Anwendungen besprochen. Es wird gezeigt, wie man die
integrierte SQLite-Datenbank verwenden und dort seine Daten
ablegen, abrufen etc. kann. Ein kurzer Ausflug in SQL ist
inbegriffen.
Im zehnten Kapitel (45 Seiten) geht es um viel besuchte Webapps.
Reicht der Server für die Last aus, ist die Datenbank schnell genug
und der Plattenplatz ausreichend, usw. Es wird gezeigt, wie man die
Google App Engine für seine Webapp nutzen kann, um Formulare, Eingaben etc.
mit dem entsprechenden Framework zu verwenden.
Am Ende wird beschrieben, wie man seine Webapp in die Cloud bekommt.
Im elften Kapitel (37 Seiten) geht es um
Bereiche, die sich in den anderen Kapiteln nicht haben
einfügen lassen, wie z. B. die Verwendung komplexerer CSV-Dateien,
das Arbeiten mit dem „Zeit-zu-Sekunden-zu-Zeit-Modul“ und die
Portierung auf Android.
Im Anhang werden die Bereiche kurz erwähnt, die in den vorherigen
Kapitel nicht behandelt worden sind, aber nach Meinung des Autors
erwähnenswert sind, wie z. B. die Verwendung einer professionellen IDE,
Testen von Anwendungen, fortgeschrittene Spracheigenschaften,
reguläre Ausdrücke usw. Den Abschluss bildet das
Stichwortverzeichnis mit zwölf Seiten.
Wie liest es sich?
Das Buch ist für den absoluten Anfänger geschrieben und zeigt
spielerisch, unterstützt mit vielen Bildchen – die u. a. Sprechblasen
enthalten – wie man sich der Sprache Python nähert. Die
grundlegenden Kenntnisse einer Programmiersprache werden dabei
vorausgesetzt. Dazwischen sind FAQs enthalten, die versuchen,
mögliche Fragen zu dem Bereich zu beantworteten. Viele Abschnitte
sind redundant und wiederholen sich, um besser im Gedächtnis zu
bleiben. Jedes Kapitel enthält viele Übungen, die teilweise aufgelöst
werden.
Der Text ist verständlich und man kann diesem meist ohne
Schwierigkeiten folgen. Der erfahrene Benutzer wird die eine oder
andere Seite überspringen, gerade wenn mal wieder viele Bilder
verwendet worden sind.
Kritik
Das Buch ist für den Python-Anfänger geschrieben und für diesen geeignet.
Allerdings muss der Leser die Art der Reihe „von Kopf bis Fuß“
mögen, vor allem die vielen Bilder (teilweise aus den 50er-/60er-Jahren
des letzten Jahrhunderts), die den Leser auch leicht vom
eigentlichen Thema ablenken können. Die Reihenfolge der Kapitel
erscheint manchmal etwas merkwürdig und der Anfänger erkennt nicht
gleich den Sinn der Reihung. Zum Ausprobieren des Codes wird hier
meist nur IDLE verwendet. Die Verwendung einer entsprechenden
Entwicklungsumgebung, die gerade den Anfänger hilfreich
unterstützt, wird daher deutlich vermisst. Bei einigen Bereichen
wird die Komplexität der Aufgabe/Übung deutlich erhöht, was einen
reinen Anfänger eventuell überfordert. Gerade an solchen Stellen ist
dann Zusatzliteratur notwendig. Es stellt sich die Frage, ob der
Python-Anfänger gleich ein Android-Smartphone oder eine Google App
Engine als Programmierzielplattform verwenden will.
Der Index ist bei diversen Einträgen mit zusätzlichen Stichworten
wie Codeworten, Variablen etc. versehen und verweist auch öfter
auf andere Einträge, ohne eine Seitenangabe zu enthalten. Für den
Anfänger wirkt dies eher verwirrend. Die angegeben Seitenzahlen
sind nicht immer sinnvoll ausgewählt, z. B. „TypeError-Ausnahme
56-57, 116, 247-249, 283-285“. Der Haupteintrag ist nicht besonders
markiert, was dazu führt, dass man je nach Eintrag lange sucht, bis
man die entsprechende Erklärung findet. Es entsteht der Eindruck,
dass der Index erst automatisch erstellt und dann von Hand
bearbeitet worden ist.
Für den schon erfahrenen Benutzer ist das Buch weniger geeignet und
dieser kann auf andere Python-Exemplare aus dem Verlag
zurückgreifen, wo er für das Geld mehr erhält.
Buchinformationen |
Titel | Python von Kopf bis Fuß (1. Auflage) |
Autor | Paul Barry, übersetzt von Lars Schulten |
Verlag | O‘Reilly, Mai 2011 |
Umfang | 458+31 Seiten |
ISBN | 978-3-89721-318-0 |
Preis | ca. 44,90 Euro |
|
Links
[1] http://pypi.python.org/pypi
[2] https://secure.wikimedia.org/wikipedia/de/wiki/Model_View_Controller
Autoreninformation |
Michael Niedermair
ist Lehrer an der Münchener IT-Schule und unterrichtet hauptsächlich Programmierung, Datenbanken und IT-Technik. Er beschäftigt sich seit Jahren mit vielen Programmiersprachen und setzt gerade Python im Zusammenhang mit FontForge für die Fonterstellung beim Linux Libertine Projekt ein.
|
|
Diesen Artikel kommentieren
Zum Index
Für Leserbriefe steht unsere E-Mailadresse
zur Verfügung - wir freuen uns über Lob,
Kritik und Anregungen zum Magazin.
An dieser Stelle möchten wir alle Leser ausdrücklich ermuntern,
uns auch zu schreiben, was nicht so gut gefällt. Wir bekommen
sehr viel Lob (was uns natürlich freut), aber vor allem durch
Kritik und neue Ideen können wir uns verbessern.
Leserbriefe und Anmerkungen
Mobilausgabe
->
Haben Sie schon einmal über eine für E-Reader aufbereitete Ausgabe Ihres
Magazins nachgedacht? Wie vielleicht/bestimmt andere Leser ebenso, würde
ich mich darüber freuen, wenn ich freiesMagazin auf meinem Kindle (oder
anderem E-Reader) lesen könnte.
Für den Fall, dass Sie sich damit nicht auskennen, eine kurze Erklärung:
Es gibt es sehr gutes, freies Tool namens Calibre, mit dem man E-Books
verwalten und Online-Inhalte aufbereiten kann. Calibre läuft unter Linux
genauso wie unter Windows. Das Abrufen von Online-Inhalten kann mit
Hilfe sog. Recipes bzw. Schemata selbst angepasst und erweitert werden.
Seit dem Kauf meines E-Readers habe ich nun schon einige Recipes selbst
erstellt, um verschiedene Webangebote für das Lesegerät aufzubereiten.
Ich habe auch versucht, das Mobile-Angebot von freiesMagazin
entsprechend aufzubereiten. Allerdings ist das HTML automatisiert kaum
zu verarbeiten.
Gerald Backmeister
<-
Zur Mobilausgabe haben wir uns schon viele, viele Gedanken gemacht.
Bisher ist es uns aber nicht gelungen mit den vorhandenen Daten
(LaTeX, PDF oder HTML) eine für uns akzeptable Version zu
erzeugen. (Erzeugen konnten wir natürlich ein ePub mit Calibre.)
Ihre Aussage „Allerdings ist das HTML automatisiert kaum zu
verarbeiten.“ können wir damit unterschreiben und sind ebenfalls daran
verzweifelt.
Die einzige Idee, die wir bisher hatten, war ein zusätzliche PDF-Version
im A5-Hochformat, die dann von Calibre in ePub verarbeitet wird. Das war
uns aber dato zu viel Arbeit, zumal unsere Leser laut der im Januar
gestellten Umfrage [1]
keine Mobilversion benötigen oder mit dem aktuellen Angebot noch
zufrieden sind.
Sollte es aber jemand wirklich schaffen, das bereitgestellte,
dreispaltige PDF, die HTML-Version oder sogar den LaTeX-Code – den
wir dann bereitstellen würden – in ein akzeptables ePub zu wandeln,
würden wir natürlich nicht Nein sagen.
Dominik Wagenführ
Einzelne PDF-Artikel
->
Ich lese freiesMagazin sehr gerne, allerdings möchte ich manchmal auch
einzelne gute Artikel als PDF auf meiner Festplatte archivieren und
dann brauche ich oft nicht das gesamte Magazin, zumal das
durchforsten ganzer Magazine auch aufwändiger ist, wenn man nur
einen einzigen Artikel haben möchte. Daher würde ich es toll
finden, wenn Ihr auf der Webseite ein Formular erstellen würdet,
mit dem man dann von einzelnen Artikeln einer Ausgabe eine PDF
Dateien generieren und downloaden könnte.
Oliver C.
<-
Ich halte das für eine gute Idee und
habe sie an unser Webteam weitergeleitet. Ggf. kann man da mit pdftk
etwas machen. Die Frage ist, ob es so etwas schon vorgefertigt gibt oder
ob wir diese Webanwendung selbst schreiben müssen.
Wir halten Sie aber auf dem laufenden und werden es auf der Webseite
ankündigen, sollte es so eine Funktion irgendwann geben. Vorab haben
wir aber schon einmal eine kleine Umfrage gestartet, um zu prüfen
wie viele Nutzer so eine Funktion in etwa hätte [2].
Dominik Wagenführ
xkcd-Comics
->
Nach kurzem Überfliegen des PDFs ist mir aufgefallen, dass Sie einen
xkcd-Comic benutzten. Ein zusätzlicher Bestandteil des Comics
sind die title-Texte, welche oft vergessen werden. Es würde mich
freuen, wenn sie beim erneuten Benutzen dieser Comics den
title-Text mit benutzen würden.
n
<-
Wir vergessen den Titel nicht nur oft, sondern immer. ;) Das Thema
beschäftigt uns seit mehreren Jahren, seit wir die xkcd-Comics
nutzen. Wir würden diese Beschreibung gerne, ähnlich wie im Browser,
per Mouse-over anzeigen. Bisher unterstützt aber nur der Adobe Reader
so ein Feature. Sollten die anderen PDF-Betrachter irgendwann mitziehen
oder es eine andere Möglichkeit geben, die Beschreibung versteckt
anzuzeigen, fügen wir diese so schnell wie möglich ein.
Ein allgemeiner Hinweis noch an dieser Stelle: Wer uns einen Leserbrief
schreibt und eine Antwort erhalten möchte, sollte eine gültige
E-Mail-Adresse angeben. Ansonsten fällt uns das Antworten sehr schwer.
Dominik Wagenführ
Perl-Tutorium – Teil 1, freiesMagazin 08/2011
->
Wenn man als Shebang #!/usr/bin/env perl benutzt, funktioniert
das ganze sogar für perlbrew.
Jonathan Kolberg (Kommentar)
Fedora 15, freiesMagazin 07/2011
->
Bezüglich des Startproblems von GNOME 3 in der VirtualBox habe ich
evtl. eine Lösung anzubieten. Das Problem ist anscheinend, dass
GNOME 3 unter Fedora 15 in der VirtualBox nicht auf Deutsch laufen
will. Stellt man die Sprache allerdings auf Englisch um, läuft es
bei mir problemlos. Ich habe das ganze auch [in meinem Blog]
beschrieben [3].
wolowitz (Kommentar)
Printausgabe
->
Gibt's freiesMagazin nur online [oder] auch demnächst als Heft?
Volker Geißler
<-
freiesMagazin erscheint auschließlich in einer Online-Version und dies wird
wohl auch so bleiben.
Sowohl Aufwand wie auch Unkosten für eine Printausgabe wären für ein
Projekt wie freiesMagazin viel zu hoch – schließlich speist sich
freiesMagazin aus dem Antrieb seiner freiwilligen Mitarbeiter.
Thorsten Schmidt
<-
Zusätzlich gehen die Leserzahlen von Printausgaben fast jedes Magazins
am Kiosk seit Jahren kontinuierlich zurück. In Zeiten des Internets
sind fast alle Informationen online abrufbar, sodass nur noch wenige
Leute wirklich echtes Papier in den Händen brauchen. Aus dem Grund
wäre es auch nicht sinnvoll, auf dieses „tote Pferd“ zu setzen.
Dominik Wagenführ
Links
[1] http://www.freiesmagazin.de/20110110-umfrage-mobilversion-freiesmagazin
[2] http://www.freiesmagazin.de/20110828-sollen-artikel-einzeln-abrufbar-sein
[3] http://wolowitzblog.wordpress.com/2011/05/29/fedora-15-mit-gnome-3-unter...
Die Redaktion behält sich vor, Leserbriefe gegebenenfalls zu
kürzen. Redaktionelle Ergänzungen finden sich in eckigen Klammern.
Die Leserbriefe kommentieren
Zum Index
(Alle Angaben ohne Gewähr!)
Sie kennen eine Linux-Messe, welche noch nicht auf der Liste zu
finden ist? Dann schreiben Sie eine E-Mail mit den Informationen zu
Datum und Ort an.
Zum Index
freiesMagazin erscheint immer am ersten Sonntag eines Monats. Die Oktober-Ausgabe wird voraussichtlich am 2. Oktober unter anderem mit folgenden Themen veröffentlicht:
- PHP-Programmierung – Teil 1: HTML
- Rezension: Einführung in die Android-Entwicklung
Es kann leider vorkommen, dass wir aus internen Gründen angekündigte Artikel verschieben müssen. Wir bitten dafür um Verständnis.
Zum Index
An einigen Stellen benutzen wir Sonderzeichen mit einer bestimmten
Bedeutung. Diese sind hier zusammengefasst:
$: | Shell-Prompt |
#: | Prompt einer Root-Shell – Ubuntu-Nutzer können
hier auch einfach in einer normalen Shell ein
sudo vor die Befehle setzen. |
~: | Abkürzung für das eigene Benutzerverzeichnis
/home/BENUTZERNAME |
Zum Index
|
Erscheinungsdatum: 4. September 2011 |
|
|
Redaktion |
| Frank Brungräber | Thorsten Schmidt |
| Dominik Wagenführ (Verantwortlicher Redakteur) |
| |
Satz und Layout |
| Ralf Damaschke | Andrej Giesbrecht |
| Tobias Kempfer | Nico Maikowski |
| Ralph Pavenstädt | Matthias Sitte |
| |
Korrektur |
| Daniel Braun | Andreas Breitbach |
| Bastian Bührig | Stefan Fangmeier |
| Mathias Menzer | Florian Rummler |
| Karsten Schuldt | Janis von Seggern |
| Stephan Walter | Toni Zimmer |
| |
Veranstaltungen |
| Ronny Fischer |
| |
Logo-Design |
| Arne Weinberg (GNU FDL) |
|
Dieses Magazin wurde mit LaTeX erstellt. Mit vollem Namen
gekennzeichnete Beiträge geben nicht notwendigerweise die Meinung
der Redaktion wieder. Wenn Sie
freiesMagazin ausdrucken möchten, dann
denken Sie bitte an die Umwelt und drucken Sie nur im Notfall. Die
Bäume werden es Ihnen danken. ;-)
Soweit nicht anders angegeben, stehen alle Artikel, Beiträge und Bilder in
freiesMagazin unter der
Creative-Commons-Lizenz CC-BY-SA 3.0 Unported. Das Copyright liegt
beim jeweiligen Autor.
freiesMagazin unterliegt als Gesamtwerk ebenso
der
Creative-Commons-Lizenz CC-BY-SA 3.0 Unported mit Ausnahme der
Inhalte, die unter einer anderen Lizenz hierin veröffentlicht
werden. Das Copyright liegt bei Dominik Wagenführ. Es wird erlaubt,
das Werk/die Werke unter den Bestimmungen der Creative-Commons-Lizenz
zu kopieren, zu verteilen und/oder zu modifizieren. Das
freiesMagazin-Logo
wurde von Arne Weinberg erstellt und unterliegt der
GFDL.
Die xkcd-Comics stehen separat unter der
Creative-Commons-Lizenz CC-BY-NC 2.5 Generic. Das Copyright liegt
bei
Randall Munroe.
Zum Index
File translated from
TEX
by
TTH,
version 3.89.
On 21 Sep 2011, 18:05.