[DE |
EN |
FR |
JA |
ES]
Willkommen zur 13. Ausgabe von Georg's Brave GNU World. Diesmal wird es
wieder recht technisch, doch ich hoffe, daß für jeden etwas
Informatives oder Interessantes dabei sein wird.
Bei Gcompte von Fabien Marchewka handelt es sich um eines dieser kleinen GNU GPL lizensierten Projekte, denen ich immer gerne ein Forum biete.
In diesem Fall ist es ein Programm zur Verwaltung der privaten Finanzen, welches deutlich kleiner und einfacher ist als verwandte Projekte wie GNUcash. Gerade wer eigentlich nur ein persönliches Konto führen möchte und denkt, daß bisherige Programme zu umfangreich oder zu langsam sind, wird an Gcompte seine Freude haben. Auch in den verwendeten Fileformaten ist Gcompte durchaus attraktiv, da intern standard XML verwendet wird und die Ausgabe in HTML oder LaTeX möglich ist.
Da es sich bei Gcompte noch um ein recht junges Projekt handelt - es steht momentan bei Version 0.3.8 - sind viele Dinge bisher nur angedacht. Dazu gehören beispielsweise der Import von "Quicken" Files, Graphen und autmatisierte Operationen. Da die Installation dank GNU Autoconf/Automake problemlos verläuft, sollten sich interessierte Anwender jedoch nicht davon abhalten lassen, mal einen Blick auf die Homepage [5] zu werfen.
Damit wende ich mich dem nächsten Thema zu, daß ebenfalls von allgemeinem Interesse sein dürfte.
Der "Scheme Constraints Window Manager" (Scwm) [6] ist ein erweiterbarer Window Manager, der sogar den Turing Test bestanden hat. Ursprünglich ins Leben gerufen wurde er von Maciej Stachoviak, doch im Moment liegt die Hauptarbeit bei Greg J. Badros.
Als Erweiterungs- und Konfigurationssprache dient Guile Scheme und es wird ein ausgereifter "constraint solver" unterstützt, der eine interaktive Festlegung der Rahmenparameter für Fenster- Größen und -Positionen erlaubt. Zusätzlich hierzu ist es möglich, C und - über einen speziellen Adapter - Fvwm2 Module dynamisch einzubinden, da Scwm ursprünglich auf dem Fvwm2 Sourcecode basiert. Am Rande sei bemerkt, daß sich der Scwm auch gut dafür eignet, Scheme zu lernen und mit den "constraints" herumzuexperimentieren.
Zu den eher normalen Merkmalen des Scwm zählen die Theme-Fähigkeit, ein integriertes Interaktions- und Dokumentations-System, GNOME Kompatibilität, ein Graphisches Interface für die Konfiguration und ein "proplist" Modul, mit dem WindowMaker proplists integriert werden können. Wirklich bemerkenswert ist jedoch z.B. die Möglichkeit, synthetische X-Tastatur-Events zu erzeugen. Da dies vielen Leuten kein Begriff sein wird sollte ich es wohl ein bisschen erklären. Die X Oberfläche ist im Wesentlichen "ereignisorientiert" oder auch "differentiell." Anstatt permanent alles abfragen - und damit auch übertragen - zu müssen, wird vorher vereinbart, welche Ereignisse von Interesse sind und mitgeteilt werden sollen. Ein Ereignis könnte dabei z.B. sein, daß ein Teil des Schirms neu gezeichnet werden muß, daß die Maus ein Fenster betritt oder verläßt, oder eben auch, daß eine Taste gedrückt bzw. losgelassen wurde. Die Möglichkeit, synthetische Tastatur-Events zu erzeugen bedeutet daher, daß man z.B. Netscape mitteilen kann, ein bestimmter Link sei angeklickt worden - auch wenn die Maus in Wahrheit nicht berührt wurde. Erwähne ich nun noch, daß unter x86 GNU/Linux auch die IBM ViaVoice Spracherkennungssoftware eingebunden werden kann, so bin ich sicher, daß ich eurer Phantasie nicht weiter auf die Sprünge helfen muß.
Es gibt noch mehr bemerkenswerte Features, doch auf diese näher einzugehen würde den Rahmen sprengen, daher seien hier nur kurz die "guile-gtk widget bindings", "extensible window manager hooks" im Zusammenhang mit Plazierungsprozeduren und das XTest Modul für echte Events erwähnt. Wem das nichts sagt, dem sei versichert, daß der Scwm problemlos auch ohne diese verwendet werden kann.
Doch natürlich sind auch hier noch ungelöste Probleme zu verzeichnen. Das größte ist laut Greg der langsame Startup, der leicht um die 20 Sekunden dauern kann. Glücklicherweise ist ein Neustart im normalen Betrieb nur außerordentlich selten notwendig, da Änderungen in der Konfiguration dynamisch übernommen werden. Pläne für die Zukunft beinhalten ein Redesign des Event Handling Mechanismus; eventuell auf Basis des Guile Object Oriented Programming System (GOOPS). Dann soll an der Dekoration der Fenster gearbeitet werden, um eine noch bessere und robustere Konfigurierbarkeit zu gewährleisten.
Fast alles am Scwm unterliegt der GNU General Public License, ist also Freie Software. Einziger Wermutstropfen in diesem Zusammenhang ist der "Cassowary constraint solver," der eine Lizenz hat, die ihn lediglich für Forschungszwecke freigibt.
Weiter geht es mit einem Projekt, welches man ohne Probleme der "Church of Emacs" zuordnen kann.
Als ich zum ersten Mal mit eev [7] von Eduardo Ochs konfrontiert wurde, empfand ich die Beschreibungen als sehr vage und konnte mir nur wenig darunter vorstellen. Das eev-Manifest [8] hat sicherlich geholfen, aber wirklich klar wurde mir die Sache erst, als ich damit herumexperimentiert habe. Ich hoffe, Euch den Einstieg einfacher gestalten zu können.
Bei eev handelt es sich um eine Emacs-LISP Library, die normal in den Emacs eingebunden werden kann. Sobald eev installiert ist, kann man damit die sogenannten e-scripts interpretieren. Diese sind reine ASCII Files, in denen man - genau wie in normalen Skripten - Kommandofolgen eingeben kann. Wirklich interessant wird die Sache erst, wenn man davon ausgeht, daß diese Skripte nicht einfach eine Aufgabe lösen sollen. Ihr Zweck besteht vielmehr darin, einem anderen User zu zeigen, wie bestimmte Aufgaben unter Unix gelöst werden können. Dabei enthält ein e-script oft mehrere Lösungen eines Problems oder auch die Lösungen zu mehreren Problemen - es ist also selten zweckmäßig, diese im Ganzen zu interpretieren.
Praktisch stellt sich das so dar, daß ein e-script mit dem Emacs geladen wird und der Benutzer die ihn interessierende Stelle markiert. Dann wird über das "eev" Kommando dieser Teil interpretiert und ein echtes Shellskript erzeugt, welches die im markierten Bereich vorhandenen Kommandos enthält. Über den Shell-Mode wird dann das Shellskript aufgerufen, die Ausgabe kann im Emacs angesehen werden. Eev ist also in gewisser Weise ein Ansammlung mehrerer Shellskripte in einem e-script, wobei der User diese Shellskripte ganz oder auch nur teilweise ausführen kann.
Besonders interessant ist nun die Idee, die LISP-Fähigkeit des Emacs zu benutzen, um die e-Skripte zu dokumentieren. Anstatt ganze Teile aus Man-, Info- oder Webpages in das Skript zu kopieren, werden LISP Ausdrücke eingefügt, die beispielsweise eine Manpage aufrufen oder in einem Infofile an einen bestimmten Punkt springen. Diese Ausdrücke können im Emacs über "C-x C-e" interpretiert werden, woraufhin der Emacs die spezifizierte Dokumentation anspringt. Es wird quasi eine Art "Hyperlink" über LISP realisiert. Auch Sourcecode-Referenzen können auf diese Weise leicht implementiert werden. Anhand eines e-scripts kann also nicht nur die Lösung eines Problems verstanden werden, es wird auch der Weg dorthin schnell und effizient dokumentiert.
Im Grunde handelt es sich also um eine naheliegende Vorgehensweise. Sie ermöglicht es auch, Lösungen für Standardprobleme in einer Datenbank zu sammeln und bietet prinzipiell die Möglichkeit, vielen Benutzern den Einstieg in Unix zu erleichern. Folgerichtig ist das Ziel, eev zunächst zu einem festen Bestandteil der Emacs Distribution zu machen und festzustellen, wie eev auch in anderen Editoren - wie z.B. "vi" - realisiert werden kann. Was die Datenbank von e-Skripten angeht, so ist diese bereits im Aufbau und Eduardo plant, demnächst Skripte zur Installation, Benutzung und Fehlerbehebung für Debian GNU/HURD zu erzeugen sowie auch andere Debian Pakete mit e-Skripten auszustatten.
Das nächste Projekt wurde von einem Leser an mich herangetragen, der meinte, es klänge alles sehr interessant, aber er verstünde nicht, worum es eigentlich geht und ich solle mich doch bitte einlesen und dann darüber schreiben.
Bei Pliant [9] von Hubert Tonneau handelt es sich um ein außerordentlich ehrgeiziges Projekt unter der GNU General Public License Version 2, an dessen Design er mittlerweile seit 15 Jahren arbeitet. Doch was ist Pliant?
Zunächst einmal ist Pliant eine Programmiersprache, die die Trennung zwischen den maschinennahen Sprachen wie C und Hochsprachen wie Java oder LISP aufheben will. Um dies zu erreichen arbeitet Pliant auf zwei Ebenen. Zunächst einmal ist da die "Expression" Ebene, in der Pliant sehr stark LISP ähnelt und vor allem auch über eine "eval" Semantik verfügt. Die zweite Ebene ist die "Instruction" Ebene, die eine sehr maschinennahe Struktur hat und in gewisser Art und Weise einer Untermenge von C ähnelt. Das Konzept von Pliant besagt, daß compilieren nichts anderes ist, als ein Programm von der "Expression" auf die "Instruction" Ebene zu bringen. Dies geschieht mit Hilfe eines dynamischen Compilers aber auch optional durch "Metafunktionen," welche vom Programm oder Libraries zur Verfügung gestellt werden. Durch die Maschinennähe der "Instruction" Ebene sind Pliant Programme dann prinzipiell so schnell wie Programme, die in C geschrieben wurden.
Durch Pliant fallen auch die Probleme mit kryptischen Konfigurationsfiles weg, da diese ebenfalls dynamisch als Pliant Code interpretiert werden. Dies bedeutet, daß Konfigurationsfiles auch über das volle Spektrum an Conditionals, Includes usw. verfügen können. Zudem haben alle Konfigurationsfiles nur noch eine Syntax: Pliant.
Doch um dies nutzen zu können, muß natürlich auch die Applikation in Pliant geschrieben sein, daher ist Pliant auch ein Set von Standardprogrammen, die die traditionelle Funktionalität bieten. Es gibt davon bereits HTTP, FTP, SMTP und POP3 Server. Übrigens enthält Pliant auch ein TCP, HTTP, FTP und SMTP File System, URLs können so wie normale Files behandelt werden.
Wie leicht zu ersehen ist, verwischt Pliant die Grenze zwischen Konfiguration und Programmierung, was bedeutet, die Hürde zur Programmierung wird deutlich gesenkt, da ein Benutzer nicht mehr eine neue Sprache erlernen muß, er verwendet direkt die Sprache, in der er vorher auch schon seine Konfigurationen erstellt hat.
Und schließlich ist Pliant auch ein "high-level" Betriebssystem. Dabei läuft Pliant direkt auf einem Linux Kernel oder auf einem standard Posix oder Windows System. Pliant ist dann der einzige User-Space Prozess und kann auf große Teile Glue-Code und Altlasten verzichten. Da auf einem Webserver dann beispielsweise nur der HTTP Server läuft, ist das System potentiell extrem stabil.
Alle diese Aspekte sind Pliant; damit zum aktuellen Stand.
Die Hauptprobleme liegen momentan darin, daß der standard Code-Generator keine aktuellen Optimierungen besitzt und nur Code für i386 Prozessoren erzeugt - allerdings erlaubt der "Posix" Code-Generator, Pliant auf mehreren Betriebssystemen zu verwenden (einschließlich GNU/HURD). Hieraus folgen auch direkt die Pläne für die Zukunft. Zunächst einmal sucht Hubert nach jemand, der Lust hat, sich den Code-Generator für die Intel-Chips vorzunehmen bzw. einen Port auf den Alpha machen möchte. Er selbst arbeitet im Augenblick an einem Datenbank-System und plant zudem, ein graphisches Toolkit zu schreiben, welches dann die Basis für die Pliant Textverarbeitung sein wird. Eine Tabellenkalkulation sollte eigentlich irgendwann zwischen der Fertigstellung des Toolkits und der Textverarbeitung verfügbar sein, da dies in Pliant sehr leicht zu implementieren sein wird.
Auch wenn dies wohl im Augenblick eher für Insider interessant ist, so hoffe ich doch, daß ich auch dem Rest diese interessante Idee ein wenig näher bringen konnte.
Schließen möchte ich mit einem Projekt, daß nicht direkt mit Computern zu tun hat sondern eher in die "Freie Wissenschaft" Richtung geht.
Jean-Marc Vanel hat mir die Adresse seiner Homepage zur "Worldwide Botanical Database" [10] geschickt. Momentan ist das Wissen über die Flora unseres Planeten verteilt auf Bibliotheken und Herbarien, was Wissenschaftler dazu zwingt Reisen zu unternehmen, um an die Informationen zu kommen. Dadurch werden neue wissenschaftliche Erkenntnisse verzögert oder sogar verhindert.
Um die Arten unseres Planeten wirksam schützen zu können, ist es jedoch wichtig, zunächst über sie bescheid zu wissen. Darum ist das Ziel, eine vollständige botanische Datenbank zu schaffen, die von jeder Pflanze auf diesem Planeten die Beschreibung, Bilder und die geographische Verteilung enthält. Obwohl es bereits ein ähnliches Projekt gibt, scheint dieses jedoch nicht voran zu kommen, da die Mittel eher in Biotechnologien fließen.
Leider fehlt Biologen zumeist das Wissen über die technische Umsetzung während den Informatikern der biologische Hintergrund abgeht. Aus diesem Grund bittet Jean-Marc Vanel alle Interessenten aus Informatik und Biologie, sich mit ihm in Verbindung zu setzen, um dieses Projekt durchführen zu können.
Damit komme ich wieder einmal zu den letzten Worten. Zunächst gibt es eine traurige Nachricht aus Norwegen. Für seine Bemühungen, rechtmäßig erworbene DVDs auch unter GNU/Linux abspielbar zu machen, wurde Jon Johansen von der norwegischen Regierung angeklagt. Angesichts der Fortschritte, die z.B. die Regierung in Frankreich gerade gemacht hat, ist es wirklich bedauerlich, jemanden für die Entwicklung Freier Software strafrechtlich zu verfolgen. Ich hoffe sehr, daß zum Zeitpunkt des Erscheinens dieser Kolumne die Sache bereits beigelegt sein wird. Sollte dem jedoch nicht so sein, so schaut Euch bitte auf dem Netz nach Protestaktionen um und beteiligt Euch daran. Im Zweifelsfall werde ich auf der Brave GNU World oder meiner privaten GNU Homepage zumindest einen Link plazieren.
Doch es gibt auch erfreuliche Nachrichten. Ein großes Dankeschön geht an Denis Bodor vom Linux Magazine France, der mir bei der Linux Expo/Linux World in Paris einen Stapel mit allen Ausgaben seit der Ersterscheinung des Magazins in die Hand gedrückt hat. Endlich habe ich den handfesten Beweis, daß die Kolumne dort abgedruckt wird.
So, damit soll es nun aber wirklich genug sein, bitte scheut Euch nicht, Euch an mich zu wenden [1], wenn ihr Fragen, Anregungen und Kommentare haben solltet.
Infos |
[1] Ideen, Anregungen, Kommentare an die Brave GNU World:
column@gnu.org
|
Please send FSF & GNU inquiries & questions to
gnu@gnu.org.
There are also other ways to contact the FSF.
Please send comments on Georg's Brave GNU World (in English or German) to
column@gnu.org,
send comments on these web pages to
webmasters@www.gnu.org,
send other questions to
gnu@gnu.org.
Copyright (C) 2000 Georg C. F. Greve
Permission is granted to make and distribute verbatim copies of this transcript as long as the copyright and this permission notice appear.
Last modified: Thu Apr 13 16:36:04 CEST 2000