Die monatliche GNU-Kolumne
Brave GNU World
von Georg C. F. Greve
Die monatliche GNU-KolumneBrave GNU Worldvon Georg C. F. Greve |
|
Willkommen zu einer weiteren Ausgabe der Brave GNU World, die diesen Monat wieder etwas technischer daherkommen wird. Doch auch wenn die Projekte zum Teil vielleicht von primärem Interesse für Entwicklerinnen sind, so steht zu hoffen, daß auch technisch nicht so versierte Leser neue Perspektiven und Anregungen aus diesen Projekten ziehen.
Den Anfang macht diesen Monat Twin [5] von Massimiliano Ghilardi, eine Multi-Fenster, Multi-Anwendungs Umgebung auf Text-Basis. Konsequenterweise steht Twin für "Text WINdows" oder besser noch für "a textmode window environment".
Die Zielgruppe des Projekts sind Menschen, die eine Umgebung mit mehreren Fenstern möchten, ohne dabei automatisch die gesamten Fähigkeiten von X11 zu wollen bzw. brauchen - speziell dessen nicht unerheblichen Resourcenbedarf.
Die Kombination von Twin mit Links, einem Text-Mode Webbrowser, benötigt etwa nur 5% der Resourcen im Vergleich zu X11 mit dem grafischen Browser Konqueror. Dabei laufen unter Twin auch alle Programme, die auf der Konsole oder in einem anderen Terminal benutzt werden können.
In einer Zeit, wo Grafikkarten sich mit neuen Fähigkeiten überschlagen und das gestern noch Unbezahlbare morgen bereits auf dem Grabbeltisch landet, mutet dies etwas anachronistisch an. Doch wie bereits zum RULE Projekt in der letzten Ausgabe [6] erläutert, gilt diese Feststellung nur für einen kleinen Teil der Menschheit.
An vielen Orten werden Menschen noch lange Zeit darauf angewiesen sein, Hardware zu verwenden, die mittlerweile schon als veraltet gilt. Dies gilt beispielsweise auch für einige Schulen in finanziell besser gestellten Ländern.
Darüber hinaus gibt es jedoch eine weitere Gruppe, die von Twin profitiert und die bei der Entwicklung neuer Software zumeist nicht im Zentrum steht: Die Blinden und Sehbehinderten. Da sie auf Braille-Terminals angewiesen sind, haben sie für grafische Benutzeroberflächen wenig Verwendung.
Dank Twin können nun auch sie in den Genuß einer Umgebung mit mehreren Fenstern und Applikationen kommen und tatsächlich erzählt Massimiliano, daß er viel Feedback von dieser Nutzergruppe erhält, was ihn anfangs überraschte.
Auf technischer Seite besteht das Projekt aus einem Server, der seinerseits "twin" heißt, wie auch das gesamte Projekt. Dieser nimmt die Verbindungen von den Clients entgegen und erzeugt bzw. verändert Fenster nach deren Angaben. Außerdem verwaltet der Server dynamisch die verschiedenen Displays bzw. Anzeigegeräte.
Unterstützt werden momentan die Konsole mit Maus-Benutzung über gpm und jedes termcap oder ncurses kompatibles Terminal mit Maus-Unterstützung über das "xterm" Mausprotokoll, falls vorhanden. Doch auch X11 kann mittels eines einfachen X11-Treibers oder des grafisch angereicherten gfx-Treibers zur Ausgabe ebenso verwendet werden, wie ein weiterer Twin Server auf einem anderen Rechner.
Grundsätzlich wird auch das General Graphics Interface (GGI) unterstützt, allerdings fehlt diesem im Moment noch die Keyboardunterstützung, was für die meisten Anwendungen problematisch sein dürfte.
Zu den weiteren Komponenten gehören die Bibliotheken libTw, die die Aufgabe der Kommunikation mit dem Server übernimmt, sowie libTT, die als Toolkit-Bibliothek die eher grafisch orientierten Funktionen des Servers zu eher am Fenster/Objekt orientierten Funktionen abstrahiert. Und als Dritte im Bunde gibt es noch die libTutf, eine Unicode-Bibliothek, mit der Texte von und nach Unicode übersetzt werden können. Diese wird vermutlich im Laufe der Zeit zugunsten der Benutzung von Standardbibliotheken wegfallen, sobald die letzten offenen Frage geklärt sind.
Und schließlich sind da noch die Clients. Es gibt momentan noch relativ wenige, von denen zwei im Server eingebaut sind. Integriert wurden aus technischen Gründen im Moment der Fenster-Manager, der über ein "~/.twinrc" Konfigurationsfile konfiguriert werden kann, sowie ein einfaches Terminal, welches die Konsole emuliert.
Weitere Clients sind ein zusätzlicher Terminal-Emulator (twterm), ein Login-Manager ähnlich xdm/gdm/kdm (twdm), ein System-Monitor (twsysmon), Utilities, um Displays beim Server an- bzw. abzumelden, sowie mehrere kleine Clients, die mehr zum Testen als zum wirklichen Arbeiten geeignet sind.
Seinen Anfang hatte das Projekt bereits 1993 als DOS Programm, wobei jedoch die Multitasking-Probleme irgendwann das Projekt einschliefen ließen. Erst als Massimiliano 1999 auf GNU/Linux umstieg und das Projekt auf seine neue Plattform portierte, kam wieder Leben in die Entwicklung.
Das Projekt ist komplett in C geschrieben, einer der Gründe für seinen geringen Speichebedarf - der Twin Server benötigt im Normalfall weniger Speicher als die die Bash Shell. Und natürlich ist Twin Freie Software - als Lizenzen kommen die GNU General Public License (GPL) für Server und Clients und die GNU Lesser General Public License (LGPL) für die Bibliotheken zur Anwendung.
Die weitere Entwicklung treibt Massimiliano in seiner (recht knappen) Freizeit voran, dabei hat er noch viele Ideen. So steht zunächst die Fertigstellung der Toolkit-Bibliothek und ihrer Dokumentation auf dem Plan, dann sollen zunehmend auch Editoren, Taskbars, File-manager, Webbrowser, Email-Programme und TTY-basierte Programme an die Bibliothek angepasst werden.
Dafür hat Massimiliano ausdrücklich darum gebeten, seine Bitte um Hilfe weiterzuleiten, denn es gibt viel zu tun. So sucht er beispielsweise Freiwillige für die Dokumentation der Kommunikations-Bibliothek, das Schreiben eines libTw Screensavers, die Fertigstellung von twdialog, dem Twin-Äquivalent von Dialog oder auch die Arbeit an twclip, einem Utility, um Clipboard-Inhalte zu kopieren und einzufügen.
Wer Interesse an der Mitarbeit hat, dem sei die Mailingliste empfohlen, Anwender finden zumindest bei der Debian Distribution Twin bereits im stabilen Zweig.
Weiter geht es mit einigen Projekten, die das Leben von C++ Entwicklern einfacher machen sollten und alle von Christian Holm Christensen um den 1. Dezember 2002 veröffentlicht wurden. [7]
Wenn Menschen mit Computern kommunizieren sollen, müssen sie sich auf eine gemeinsame Sprache verständigen, die für die Kommunikation verwandt wird. Speziell, wenn diese Kommunikation sehr komplex oder zeitfern geschieht. Das ist insbesondere der Fall für Programmiersprachen oder Konfigurationsdateien.
Das wesentliche Problem ist dabei, daß Funktionen zur syntaktischen Prüfung und zum Lesen bzw. Auswerten von solchen Sprachen schnell sehr komplex werden können. Bei eventuell notwendigen Änderungen der Definition, bzw. Grammatik der Sprache kann dies schnell zu langwierigen Fehlersuchen führen.
Darüberhinaus stellt ihre Erstellung im Normalfall eine recht mühselige Fleißarbeit ohne große intellektuelle Herausforderungen dar, die gerne vermieden wird.
Aus diesem Grund wurden Werzeuge geschaffen, die die Übersetzung von grammatikalischen Definitionen in Funktionen, die diese Grammatik lesen können, automatisieren. Natürlich bedeutet dies, daß auch die Definition der Grammatik selber wieder maschinenlesbar sein muß. Die im Informatik-Umfeld wohl gebräuchlichste Form der Definition ist die der "Lookahead Left to Right Parsing" (LALR) kontextfreien Grammatik.
Einer der besten und gebräuchlichsten LALR(1) Parser ist Bison [8], das Yacc-Äquivalent des GNU-Projekts. Yacc steht dabei übrigens für "Yet Another Compiler-Compiler" und Bison ist mit Bedacht kompatibel zu Yacc gehalten, um den Umstieg zu erleichtern.
Hand in Hand mit Bison arbeitet häufig Flex [9], mit dessen erzeugten Routinen eine Quelle in einzelne Ausdrücke zerlegt werden kann, denn es erlaubt die automatische Generierung von Sourcecode, mit dem in Texten nach Mustern gesucht wird; neudeutsch "pattern-matching" genannt. Auch Flex ist das GNU-Gegenstück zu einem anderen Programm - in diesem Fall "Lex".
Es steht zu hoffen, daß dieser Überblick auch für technisch nicht so versierte Leser verständlich war, wer tiefer einsteigen mächte, findet im Web einige Einstiegspunkte. [10]
Sowohl Bison [8], als auch Flex [9] erzeugen im Normalfall C Sourcecode. Wird dieser in C++ verwandt, so werden Teile des globalen Namensraums aufgefüllt; zudem stehen keine C++-Interfaces zur Verfügung.
Aus diesem Grund hat Christian Holm Christensen mit Yacc/Lexx-- eine Gruppe von Header-Files geschrieben, die es erlauben, die C-Ausgabe von Bison und Flex in C++ Klassen zu kapseln. Die Änderungen an den Spezifikationen wurden dabei bewußt auf ein Minimum beschränkt, um die Flexibilität zu groß wie möglich zu halten.
In der Tat verfügt Flex selbst über eine Möglichkeit zur Erzeugung von C++ Sourcecode, allerdings war diese Christian zu wenig flexibel und paßte sich zudem schlecht in die über Bison erzeugten Parser-Klassen ein. Daher wollte er eine einheitliche Kapselung von Beiden. Tatsächlich war es eben diese Asymmetrie zwischen der C-Ausgabe von Bison und der C++-Ausgabe von Flex, die ihn zu diesem Projekt veranlaßte.
Im Vergleich mit Projekten wie z.B. bison++, das den Vorteil der direkten C++ Aushabe hat, sieht Christian die Vorteile seines Ansatzes darin, daß er nicht von den Interna der verwandten Yacc/Lex Implementation abhängt. Daher ist es stabiler gegenüber Änderungen in den Yacc/Lex Projekten und auch nicht unmittelbar von deren internen Änderungen betroffen.
Dennoch gibt es einige Yacc/Lex-Klone, die merkwürdige Verhaltensweisen an den Tag legen und nicht POSIX-Kompatibel sind; mit diesen kann es Schwierigkeiten geben, was zu den speziellen Problemen des Projekts gehört.
Daher plant Christian für die nächste Zukunft, noch mehr Yacc/Lex Implementationen zu testen und wäre über Hilfe auf diesem Gebiet sehr erfreut. Auch beim Testen mit anderen Compilern und auf anderen Plattformen ist Hilfe sehr willkommen.
Die GNU Readline Bibliothek [11] stellt Funktionen zur Verfügung, die es erlauben, eine vielseitige Kommandozeile in eigene Projekte zu integrieren.
So verfügt GNU Readline über einen vi und einen EMACS Mode, kann alte Eingaben speichern, wiederherstellen und erneut editieren lassen oder auch die Anfänge von früher eingegebenen Kommandos ähnlich der csh-Shell komplettieren.
Das Readline-- Projekt von Christian Holm Christensen erlaubt durch C++ Klassen den Zugriff auf die GNU Readline Bibliothek mittels C++. Zielgruppe des Projekts sind wenig überraschend die C++-Entwickler, die in ihren Programmen ein Kommandozeilen-Interface verwenden möchten.
Entstanden ist das Projekt, als Christian selber ein Kommandozeilen-Interface benötigte, um seinen C++ Parser zu testen, im Rahmen dessen Erstellung er auch das vorherige Projekt aus der Taufe hob.
Das größte Problem ist dabei allerdings, daß die Bibliothek noch nicht Thread-Safe ist, also in komplexen Programmen mit Vorsicht behandelt werden sollte. Dies zu beheben, sowie das Interface noch besser zu gestalten, sind die weiteren Pläne für das Projekt. Das Interface ist zwar vollständig, aber nach seinem persönlichen Dafürhalten an manchen Stellen nicht intutiv.
Mit Option-- stellt Christian einen C++ Parser für Kommandozeilen-Optionen zur Verfügung; also eine Bibliothek, die es erlaubt, in C++ die beim Programmaufruf übergebenen Optionen zu erfassen und auszuwerten.
Der Vorteil des Projekts besteht darin, daß mögliche Optionen durch Template-Klassen repräsentiert werden und das Projekt daher sehr flexibel ist. Allerdings ist es auf Positions-Unempfindlichkeit festgelegt. Wenn Benutzer also durch die Syntax dadurch gezwungen werden sollen, eine bestimme Option nur am Ende der Kommandozeile anzugeben, ist Option-- eher ungeeignet.
Mit der Arbeit an diesem Projekt hat Christian ursprünglich begonnen, als das ROOT-Projekt Kommandozeilen-Optionen benötigte, obwohl dort letztlich eine andere Lösung eingesetzt wurde.
Als er selber jedoch feststellte, etwas in dieser Art zu brauchen, stellte Christian das Projekt fertig und es ist mittlerweile so stabil, daß außer weiteren Tests wenig geplant ist.
Das letzte Projekt von Christian Holm Christensen für diese Ausgabe ist Thread--, ein Projekt zur Benutzung von Threads in C++ Programmen.
Da das Konzept von "Threads", auf deutsch "Fäden" vermutlich nicht allen Lesern ein Begriff sein dürfte, sei hier kurz eine kleine Erklärung eingeschoben.
Grundsätzlich arbeiten Computer linear. Erhalten sie eine Aufgabe, so arbeiten sie diese Schritt für Schritt mit ihrer vollen Kapazität ab. Nun würde dies aber zunächst im Regelfall nur die Ausführung eines einzigen Programms erlauben.
Um die Bearbeitung mehrerer Programme simultan zu ermöglichen - das sogenannte "Multi-Tasking" - springt der ausführende Kern des Computers, der Prozessor, von Aufgabe zu Aufgabe. Jede dieser Aufgaben wird für sich wiederum linear bearbeitet, aber die Methode erlaubt zumindest das Teilen der Arbeitszeit zwischen verschiedenen Programmen.
Da die Programme und ihre Aufgaben jedoch immer komplexer werden, ist die lineare Abarbeitung innerhalb eines Programms ebenfalls häufig unzureichend. Hier bieten die Threads Abhilfe, da sie erlauben, Programme in einzelne "Anweisungsfäden" aufzuteilen, die sich linear abarbeiten lassen, um z.B. bestimmte Unteraufgaben zu lösen.
Die Interaktion und Kommunikation zwischen diesen verschiedenen Threads muß natürlich auch koordiniert und gesteuert werden, eine Funktionalität, auf die durch Thread-- aus C++ zugegriffen werden kann.
Im Gegensatz zu ähnlichen Projekten, wie z.B. Boost::Thread, ZThread oder Common C++, wird bei Thread-- darauf verzichtet, Präprozessor-Makros über den Code zu verteilen und die Implementations-spezifischen Dinge sind stattdessen in Traits untergebracht. Dadurch wird die Bibliothek sehr klein und erweiterbar.
Geschrieben hat Christian Thread-- usprünglich, um die Thread-Sicherheit von Readline-- zu testen und es funktioniert nach seinen Angaben unter GNU/Linux, allerdings machen Versionen des GCC von 2.95.x und darunter Schwierigkeiten, es sollte also auf die GCC-Version geachtet werden.
Die anderen Probleme sind Semaphoren unter Solaris und Threads unter Win32. Auf anderen Plattformen konnte er es bisher nicht testen. Hilfe ist mit diesen Problemen, sowie dem Testen auf anderen Plattformen außerordentlich willkommen.
Damit genug der von Christian geschriebenen Projekte. Wer regelmäßig in der Brave GNU World liest, dem wird das Fehlen von zwei wesentlichen Informationen aufgefallen sein. Diese sollen jetzt nachgeliefert werden.
Erstens: Als Programmiersprache kam für alle Projekte C++ mit den GNU Autotools zur Anwendung und zweitens: Alle Projekte sind als Freie Software unter der GNU Lesser General Public License (LGPL) verfügbar. Zu finden sind sie auf der C++ Seite von Christian. [7]
Wie in Ausgabe 40 [12] der Brave GNU World bereits erwähnt wurde, hatte die FSF Europe [13] am 30. April 2002 eine Empfehlung [14] an die Europäische Union gerichtet. In dieser Empfehlung, die von über 50 Parteien quer durch Europa unterstützt wurde, wurden die Vorteile Freier Software für die Region Europa und die europäischen Länder dargelegt und eine intensivere Förderung empfohlen.
Hintergrund der Empfehlung war, daß im letzten Jahr das 6. Rahmenprogramm [15] zur Forschungs- und Entwicklungsförderung beschlossen wurde. Diese Programme laufen jeweils vier Jahre und beinhalten den Löwenanteil europäscher Fördergelder im wissenschaftlichen Gebiet. Dabei liegt ein Schwerpunkt darauf, über Forschungsförderung eine Förderung der europäischen Wirtschaft und Gesellschaft zu erreichen.
Obwohl es im 5. Rahmenprogramm bereits erste Initiativen zu Freier Software gab, war im 6. Rahmenprogramm ursprünglich nicht vorgesehen, Freie Software zu fördern. Dies war der Anlaß für die von der FSF Europe ausgesprochene Empfehlung.
Am 17. Dezember 2002 wurde nun das 6. Rahmenprogramm beschlossen, und es scheint, daß die Empfehlung, Freie Software bei der Prüfung von Projektanträgen positiv zu werten, Gehör fand. Das "Information Society Technologies" (IST) Work Programme, in dem die Förderung der Informatik und Informationstechnologie behandelt wird, enthält nun eine Aussage, die Freier Software bevozugte Behandlung verschaffen kann.
Damit wurde das gesamte Budget des IST-Work Programme, für das immerhin 1,725 Milliarden Euro zur Verfügung stehen, für Freie Software geöffnet. Dies dürfte die größte Summe sein, die jemals für eine Förderung Freier Software verfügbar war; wenn natürlich in diesem Fall nicht exklusiv.
Um nun die Unternehmen, Universitäten und Forschungseinrichtungen dabei zu unterstützen, in diesem Rahmen Projekte mit und für Freie Software ins Leben zu rufen, hat die FSF Europe am 18. Dezember 2002 alle interessierten Parteien dazu aufgerufen, sich mit ihr in Verbindung zu setzen. [16]
Ziel ist es, möglichst je ein Freies Software-Projekt zu den wichtigen Themengebieten im 6. Rahmenprogramm an den Start zu bringen, um diese Fördergelder nicht für proprietäre Software verwendet zu sehen. Denn Gebiete wie eDemocracy, eHealth oder eSecurity können zum Teil maßgebliche Auswirkungen auf unsere Zukunft haben und verlangen nach Freier Software.
Es erfordert viel Zeit und Arbeit, diese Projekte aufzubauen, zu organisieren und mit der Verwaltung in Brüssel abzustimmen, doch die FSF Europe wird ihr Möglichstes tun, um die geschaffenen Chancen durch entsprechende Projekte genutzt zu sehen.
Gegen Ende dieser Ausgabe ist es mir persönlich eine große Freude, auf eine weitere besondere Kolumne hinzuweisen. Mario Fux, ein langjähriger aktiver Leser der Brave GNU World hat letztes Jahr damit begonnen, eine ähnliche Kolumne zum Thema Freie Software in der Schule zu schreiben.
Es existieren bereits 5 Ausgaben der "TUX&GNU@school" Kolumne in deutsch und englisch, die mittlerweile als Gastpublikation auf der FSF Europe Homepage [17] ihr Zuhause gefunden hat. Ich wünsche Mario, sowie Christian Selig and Kristian Rink, die ihn als redaktioneller Beirat unterstützen, alles Gute für die Zukunft und ermutige besonders - aber nicht nur - Leser aus dem schulischen Umfeld, dort einmal einen Blick zu riskieren.
Damit genug der Brave GNU World für diesen Monat, wie üblich bitte ich um Fragen, Anregungen und Kommentare per Email. [1]
An diese Adresse sollten auch Projektvorschläge geschickt werden, wobei ich die Autoren ermuntern möchte, sich die Zeit zu nehmen. Es mag verdächtig nach Dokumentation aussehen, ist aber ein guter Weg, andere Menschen über das eigene Projekt zu informieren.
Und bitte auch keine Angst bezüglich der Wichtigkeit des eigenen Projekts. Tatsächlich ist mir bisher noch kein Projekt untergekommen, das so uninteressant gewesen wäre, daß sich nicht zumindest ein paar interessante Zeilen dazu schreiben ließen.
In diesem Sinne, bis zum nächsten Monat.
| Der Autor |
![[Ein Foto von Georg Greve]](urban-small-2.png)
Dipl.-Phys. Georg C. F. Greve beschäftigt sich seit etlichen
Jahren mit Freier Software und kam früh zu GNU/Linux. Nach
Mitarbeit im GNU-Projekt und seiner Aktivität als dessen
europäischer Sprecher hat er die Free Software Foundation
Europe initiiert, deren Präsident er ist. Mehr
Informationen finden sich unter http://gnuhh.org.
|
Copyright (C) 2003 Georg C. F. Greve and Linux-Magazin
Permission is granted to make and distribute verbatim copies of this transcript as long as the copyright and this permission notice appear.