Abbildung 1: Twin stellt mehrere Fenster beziehungsweise Anwendungen auf reiner Textbasis dar, also ohne Speicher fressende X11- und Windowmanager-Umgebung.

Diese Kolumne berichtet über aktuelle Entwicklungen innerhalb des GNU-Projekts und versucht, Einblicke in die zugrunde liegende Philosophie zu vermitteln. In dieser Ausgabe geht's um Twin, die C++-Pakete: Yacc/Lex–, Readline–, Option–, Thread– sowie um TUX&GNU@school und das 6. Rahmenprogramm der EU.

Willkommen zu einer weiteren Ausgabe der Brave GNU World, die in diesem Monat wieder etwas technischer ausfällt. Sind die Projekte auch vielleicht in erster Linie für Entwickler interessant, finden andere Leser hoffentlich zumindest Anregungen.

Twin

Abbildung 1: Twin stellt mehrere Fenster beziehungsweise Anwendungen auf reiner Textbasis dar, also ohne Speicher fressende X11- und Windowmanager-Umgebung.

Den Anfang macht Twin[5] von Massimiliano Ghilardi. Es handelt sich um eine Multi-Fenster-, Multi-Anwendungs-Umgebung auf Textbasis. Twin steht für Text Windows oder besser noch für “A textmode window environment”. Das Projekt richtet sich an alle, die eine Umgebung mit mehreren Fenstern brauchen, aber nicht gleich alle Fähigkeiten von X11, und gerade dessen erheblichem Ressourcenbedarf aus dem Weg gehen wollen. In Kombination mit Links und einem Text-Mode-Webbrowser benötigt Twin nur etwa fünf Prozent der Ressourcen des Konqueror unter X11. Dabei laufen unter Twin alle Programme, die auch auf der Konsole oder in einem anderen Terminal einsetzbar sind.

In einer Zeit, in der sich immer neue Grafikkarten mit immer neuen Fähigkeiten überschlagen und das gestern noch Unbezahlbare schon morgen auf dem Grabbeltisch landet, scheint das Projekt zunächst anachronistisch zu sein. Wie aber schon zum Rule-Projekt in der letzten Ausgabe[6] angemerkt, sind die Ressourcen andernorts knapper. Dort setzen die Benutzer Hardware ein, die hierzulande als veraltet gilt.

Aber auch eine andere Gruppe kann von Twin profitieren: Blinde und Sehbehinderte. Auf Braille-Terminals angewiesen haben sie für grafische Benutzeroberflächen keine Verwendung. Mit Twin erhalten auch sie eine Umgebung mit mehreren Fenstern und Applikationen. Massimiliano berichtet über viel Feedback von dieser Seite. Dem Verfahren liegt folgender Ansatz zu Grunde: Ein Server (Twin) nimmt die Verbindungen von den Clients entgegen und erzeugt oder verändert Fenster nach deren Angaben. Außerdem verwaltet der Server dynamisch die verschiedenen Displays beziehungsweise Anzeigegeräte.

Twin unterstützt gegenwärtig die Konsole einschließlich Mausbedienung über »gpm« und jedes Termcap- oder Ncurses-kompatible Terminal (Mausunterstützung über das Xterm-Mausprotokoll). Ein X11-Server ist mit Hilfe eines einfachen X11-Treibers oder des grafisch angereicherten Gfx-Treibers zur Ausgabe ebenso einsetzbar wie ein weiterer Twin-Server auf einem anderen PC. Grundsätzlich wird auch das General Graphics Interface (GGI) unterstützt, zurzeit aber noch ohne Keyboard.

Zu den weiteren Komponenten der Umgebung gehören noch die Bibliotheken Libtw, Libtt und Libtutf. Während die Libtw die Kommunikation mit dem Server übernimmt, abstrahiert die Libtt (eine Toolkit-Bibliothek) die grafikorientierten Funktionen des Servers zu fenster- oder objektorientierten Funktionen. Die Libtutf ist eine Unicode-Bibliothek, mit der Texte aus und nach Unicode übersetzt werden können. Diese Aufgabe soll aber schon bald durch Standardbibliotheken erfüllt werden.

Auf der anderen Seite sind da noch die Clients. Es gibt nur wenige, von denen zwei bisher im Server integriert sind: der Fenstermanager, der über ein »~/ .twinrc«-Konfigurationsfile eingerichtet wird, sowie ein einfaches Terminal, das 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 für das An- beziehungsweise Abmelden von Displays beim Server und mehrere kleine Clients, eher für Tests als zu produktiver Arbeit geeignet.

Das Projekt begann 1993 als DOS-Programm, die Multitasking-Probleme ließen es aber bald wieder einschlafen. Erst als Massimiliano 1999 auf GNU/Linux umstieg, kam wieder Leben in die Entwicklung. Twin ist vollständig in C geschrieben und benötigt nur wenig Speicher – normalerweise weniger als die Bash. Und natürlich ist Twin freie Software: Die GNU General Public License (GPL) gilt für Server und Clients, die GNU Lesser General Public License (LGPL) für die Bibliotheken.

In seiner recht knappen Freizeit möchte Massimiliano seine Toolkit-Bibliothek fertig stellen und dokumentieren, danach stärker Editoren, Taskbars, Filemanager, Webbrowser, E-Mail-Programme und TTY-basierte Programme daran anpassen. Er bittet um Hilfe, denn es gibt viel zu tun. Twin braucht Freiwillige für die Dokumentation der Kommunikations-Bibliothek, das Schreiben eines Libtw-Screensavers, die Fertigstellung von Twdialog, dem Twin-Äquivalent von Dialog, oder für 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 Twin bereits im stabilen Zweig der Debian-Distribution.

C++-Pakete

Abbildung 2: Die C++-Packages sind eine Sammlung von Tools und Bibliotheken, die Christian Holm Christensen für andere C++-Entwickler unter der LGPL veröffentlicht hat.

Weiter geht es mit Projekten, die das Leben von C++-Entwicklern einfacher machen wollen und alle von Christian Holm Christensen um den 1. Dezember 2002 veröffentlicht wurden.[7]

Funktionen zur syntaktischen Prüfung und zum Lesen beziehungsweise Auswerten von Programmiersprachen oder Konfigurationsdateien werden leicht komplex. Änderungen an der Definition oder Grammatik einer Sprache verstärken das Problem noch. Hier greifen Werkzeuge, die die Übersetzung von grammatikalischen Definitionen in Funktionen, die diese Grammatik lesen können, automatisieren. Natürlich muss auch die Definition der Grammatik selbst wieder maschinenlesbar sein.

In der Informatik ist die Definition der kontextfreien Grammatik “Lookahead Left to Right Parsing” (LALR) üblich. 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. Bison ist mit Bedacht kompatibel zu Yacc gehalten, um den Umstieg zu erleichtern.

Hand in Hand mit Bison arbeitet häufig Flex[9]. Mit von Flex erzeugten Routinen kann eine Quelle in einzelne Ausdrücke zerlegt werden, denn es erlaubt die automatische Generierung von Sourcecode, mit dem in Texten nach Mustern gesucht wird (Pattern-Matching). Auch Flex ist das GNU-Gegenstück zu einem anderen Programm – in diesem Fall des bekannten Lex. Weitere Informationen für den Einstieg in das Thema finden sich im Web.[10]

Yacc/Lex–

Sowohl Bison[8] als auch Flex[9] erzeugen zunächst C-Sourcecode. Um diesen in C++ verwenden zu können, werden Teile des globalen Namensraums aufgefüllt; darüber hinaus stehen keine C++-Interfaces zur Verfügung. Aus diesem Grund hat Christian Holm Christensen mit Yacc/Lex– eine Gruppe von Header-Files geschrieben, die es erlauben, die C-Ausgabe von Bison und Flex in C++-Klassen zu kapseln. Die erforderlichen Änderungen an den Spezifikationen hat er dabei bewusst auf ein Minimum beschränkt, um sie so flexibel wie möglich zu halten.

In der Tat verfügt Flex selbst über eine Möglichkeit zur Erzeugung von C++-Sourcecode, allerdings fand Christian sie zu wenig flexibel und sie passte sich zudem schlecht in die über Bison erzeugten Parserklassen ein. Daher wollte er eine einheitliche Kapselung von beiden. Tatsächlich hat ihn eben diese Asymmetrie zwischen der C-Ausgabe von Bison und der C++-Ausgabe von Flex zu diesem Projekt veranlasst.

Im Vergleich mit Projekten wie Bison++, das unmittelbar C++ ausgibt, sieht Christian die Vorteile seines Ansatzes darin, dass er nicht von den Interna der verwandten Yacc/Lex-Implementation abhängt. Einige Yacc/Lex-Klone zeigen merkwürdige Verhaltensweisen und sind nicht Posix-kompatibel; mit solchen Problemen hat das Projekt noch zu kämpfen. Christian will daher weitere Yacc/Lex-Implementationen testen und freut sich dabei über Hilfe, etwa bei Tests mit anderen Compilern und auf anderen Plattformen.

Readline–

Die GNU-Readline-Bibliothek[11] bietet Funktionen für eine vielseitige Kommandozeile in eigenen Projekten. Sie hat einen Vi- und einen Emacs-Mode, kann alte Eingaben speichern, wiederherstellen und erneut editieren lassen oder sie vervollständigt das Eintippen bereits früher aufgerufener Kommandos ähnlich der Csh-Shell. C++-Klassen erlauben es, objektorientiert auf die GNU-Readline-Bibliothek zuzugreifen. Die Zielgruppe für dieses Projekt sind vor allem C++-Entwickler, die in ihren Programmen ein Kommandozeilen-Interface verwenden möchten.

Das Projekt entstand, als Christian selbst ein Kommandozeilen-Interface benötigte, um seinen C++-Parser zu testen (der übrigens den Anstoß für das zuvor besprochene Projekt Yacc/Lex– gab). Sein Hauptproblem ist, dass die Bibliothek noch nicht Thread-safe, also in komplexen Programmen mit Vorsicht zu behandeln ist. 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 an manchen Stellen nicht intuitiv.

Option–

Mit Option– stellt Christian einen stabilen 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 liegt darin, dass mögliche Optionen durch Template-Klassen repräsentiert werden und das Projekt so 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.

Thread–

Das letzte Projekt von Christian Holm Christensen für diese Ausgabe ist Thread–, ein Projekt für die Benutzung von Threads in C++-Programmen. 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 nur die Ausführung eines einzigen Programms zur selben Zeit erlauben. Um die Bearbeitung mehrerer Programme simultan zu ermöglichen – das so genannte Multitasking -, teilt der Scheduler des Betriebssystems den auszuführenden Prozessen jeweils Zeittakte des Prozessors zu. Jeder dieser Prozesse wird für sich genommen wiederum linear abgearbeitet.

Um die Ressourcen noch besser zu nutzen, setzt der Thread-Ansatz auf Codefragmente, die mehrere Prozesse gemeinsam nutzen, wobei lediglich die zugehörigen Daten für jeden Prozess gesonderten Speicher belegen. Threads teilen so die Programme in einzelne Anweisungsfäden auf, die sich an gleichartigen Unteraufgaben orientieren, etwa für Verbindungen, die ein Webserver entgegennimmt.

Die Interaktion und Kommunikation zwischen diesen verschiedenen Threads muss natürlich koordiniert und gesteuert werden, eine Funktionalität, auf die durch Thread– aus C++ zugegriffen werden kann. Im Gegensatz zu ähnlichen Projekten, hier sind beispielsweise Boost::Thread, ZThread oder Common C++ zu nennen, wird bei Thread– darauf verzichtet, Präprozessor-Makros über den Code zu verteilen, die Implementations-spezifischen Dinge sind stattdessen in Traits untergebracht. Dadurch wird die Bibliothek sehr klein und erweiterbar.

Christian hat Thread– eigentlich geschrieben, um die Thread-Sicherheit von Readline– zu testen. Das Programm funktioniert stabil unter Linux, allerdings bereiten die GCC-Versionen 2.95.x und älter Schwierigkeiten, es sollte also auf die GCC-Version geachtet werden. Die weiteren Probleme sind Semaphoren unter Solaris und Threads unter Win32. Auf anderen Plattformen ist das Programm bisher nicht getestet – Hilfe ist willkommen.

Alle hier vorgestellten Projekte von Christian Christensen sind in C++ mit den GNU-Autotools programmiert und unterstehen der LGPL. Zu finden sind sie auf seiner C++-Seite.[7]

TUX&GNU@school

Abbildung 3: TUX&GNU@school ist ein Projekt, genauer eine Kolumne ähnlich der Brave GNU World, die regelmäßig über freie Lernsoftware oder Aktuelles aus dem schulischen Umfeld berichtet.

Gegen Ende dieser Ausgabe ist es mir persönlich eine große Freude, auf eine weitere besondere Kolumne hinzuweisen: Mario Fux, übrigens ein langjähriger aktiver Leser der Brave GNU World, hat im vergangenen Jahr damit begonnen, eine ähnliche Kolumne zu schreiben, die sich mit dem Thema freie Software in der Schule beschäftigt.

Derzeit gibt es bereits fünf Ausgaben seiner TUX&GNU@school-Kolumne in Deutsch und Englisch, die mittlerweile als Gastpublikation auf der Homepage der FSF Europe[17] ihr Zuhause gefunden hat. Ich wünsche Mario und natürlich auch Christian Selig und Kristian Rink, die ihn redaktionell 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.

6. Rahmenprogramm der EU

Wie in der Ausgabe 40[12] der Brave GNU World berichtet, hatte die FSF Europe[13] am 30. April 2002 eine Empfehlung an die Europäische Union gerichtet[14], in der – unterstützt von über 50 Parteien quer durch Europa – eine intensivere Förderung freier Software in Europa empfohlen wurde. Hintergrund der Empfehlung war, dass im letzten Jahr das 6. Rahmenprogramm[15] zur Forschungs- und Entwicklungsförderung beschlossen wurde. Die Programme laufen jeweils vier Jahre und erhalten den Löwenanteil europäischer Fördergelder für den wissenschaftlichen Bereich. Über die Forschungsförderung soll mittelbar auch die europäische Wirtschaft unterstützt werden.

Obwohl es bereits im 5. Rahmenprogramm erste Initiativen zu freier Software gab, hatte das 6. Rahmenprogramm ursprünglich nichts in dieser Richtung geplant. Daraufhin hatte die FSF Europe ihre Empfehlung ausgesprochen. Am 17. Dezember 2002 wurde nun das 6. Rahmenprogramm beschlossen – es scheint, dass die Empfehlung der FSF Gehör fand. Das “Information Society Technologies”-Arbeitsprogramm (IST), in dem die öffentliche Förderung der Informatik und Informationstechnologie behandelt wird, enthält nun eine Aussage, die freie Software bevorzugen könnte. Damit wurde das gesamte Budget des IST-Programms, für das immerhin 1,725 Milliarden Euro zur Verfügung stehen, auch für freie Software geöffnet. Das dürfte die größte Summe sein, die jemals für eine Förderung freier Software verfügbar war – wenn in diesem Fall auch 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, je ein freies Softwareprojekt 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 E-Democracy, E-Health oder E-Security können zum Teil maßgebliche Auswirkungen auf unsere Zukunft haben – und verlangen daher geradezu nach freier Software. Es erfordert zwar viel Zeit und Arbeit, diese Projekte aufzubauen, zu organisieren und mit der Verwaltung in Brüssel abzustimmen, doch die FSF Europe wird die gebotene Chance durch entsprechende Projekte nutzen.

Bis nächsten Monat

Damit genug der Brave GNU World für diesen Monat, wie üblich bitte ich um Fragen, Anregungen und Kommentare per E-Mail[1]. An diese Adresse sollten auch Projektvorschläge geschickt werden, wobei ich die Autoren dazu ermuntere, sich Zeit für die Darstellung 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 Bedeutung des eigenen Projekts. Tatsächlich ist mir bisher noch kein Projekt untergekommen, das so uninteressant gewesen wäre, dass sich nicht zumindest ein paar interessante Zeilen dazu schreiben ließen. In diesem Sinne, bis zum nächsten Monat. (fan)

Copyright © 2002 Linux New Media AG