Willkommen bei Georg´s Brave GNU World. Diesen Monat beginne ich mit einem Nachzügler zum Thema GNU und Java, der durchaus zurecht eine gesonderte Darstellung erfährt.
gcj
Tom Tromey von Cygnus [5] hat sich an mich gewandt, um auf die Fortschritte von gcj [6] aufmerksam zu machen. Bei gcj handelt es sich um ein Java Frontend zum gcc [7], der vor einer Weile mit dem egcs verschmolzen wurde. Mit gcj können sowohl Java Sourcecodes als auch Bytecodes nativ verarbeitet werden und es besteht die Möglichkeit, neben ausführbaren Programmen auch Klassen-Files zu erzeugen.
Durch den gcj kann Java behandelt werden wie jede andere Programmiersprache und das Kompilieren führt zudem zu einer besseren Performance. Da in der Implementation kein Unterschied zwischen C++ und Java Objekten besteht, können diese nahtlos miteinander verwoben werden. Weitere Vorteile sind die extreme Portierbarkeit durch Basierung auf dem sehr Plattform-unabhängigen gcc und auch der GNU Debugger gdb wurde bereits angepasst, um damit gcj-Kompilate testen zu können.
Natürlich gibt es noch Schwachpunkte. Am eklatantesten ist vermutlich das Fehlen von AWT und Swing, dann werden komprimierte Klassen noch nicht unterstützt und auch die JDK 1.1 Erweiterungen sind noch nicht implementiert. Am dringlichsten ist zunächst die Anpassung an JDK 1.1 bzw. JDK 1.2 und dann die Einbindung von GUI-Toolkits. So gibt es zum Beispiel Gerüchte über ein GTK+ basiertes AWT.
Momentan arbeiten etwa fünf Entwickler von Cygnus und drei freiwillige Helfer an gcj. Dabei legte Tom Tromey übrigens großen Wert darauf, daß die freien Helfer wichtige Beiträge zu diesem Projekt geleistet haben; so hat einer von ihnen beispielsweise den Interpreter geschrieben.
Das nächste Projekt ist ebenfalls eher aus dem Entwickler-Bereich, könnte aber auch für den interessierten "Normaluser" lohnend sein.
GNU Pth
GNU Pth [8] von Ralf S. Engelschall steht für GNU Portable Threads und ist eine Library für nicht-preemptives prioritätsgesteuertes Multithreading auf UNIX-Systemen. Bisher krankte der Großteil der Implementationen daran, daß sie entweder nicht vollständig POSIX Thread konform waren oder aber sehr Plattform-spezifisch waren; oft sogar beides. Aus diesem Grund haben viele Entwickler auf die Verwendung von Threads verzichtet, um eine bessere Portabilität zu erreichen.
Die erste Priorität bei der Entwicklung von GNU Pth ist die Plattformunabhängigkeit. Dies wird erreicht, indem komplett auf Assembler-Lösungen oder Plattform-spezifische Tricks verzichtet wird. Zudem wurde die Auswahl der Funktionen bewußt auf solche beschränkt, die auf allen Unix-Derivaten zu finden sind, selbst Funktionen aus der Unix95/98 Spezifikation werden nicht vorausgesetzt. Die zweite Priorität ist Vollständigkeit. Der Großteil der Thread-Implementationen - so z.B. auch die Linuxthreads - sind leider nur unvollständige Umsetzungen des POSIX Thread Standards. Die Implementation durch GNU Pth ist mittlerweile vollständiger als die native FreeBSD Implementation uthread und auch die erweiterten Shared Memory Standards, welche bisher von noch keiner Implementation abgedeckt wurden, sollen in GNU Pth verwirklicht werden.
Für die Interessierten sei hier noch kurz erwähnt, daß GNU Pth vollständig auf ANSI-C aufbaut und ein echtes Userspace M:1 Mapping macht. Dies bedeutet, daß der Kernel nur einen normalen Prozeß sieht, auch wenn dieser eventuell aus 100 Threads besteht.
Mittlerweile hat GNU Pth in der Version 1.1 bereits etliche Leistungstests mit Bravour bestanden: So wurde Peter Erikssons Multithreaded-FTP Server pftpd erfolgreich aufgesetzt und eine experimentelle Apache Version (Apache/MPM) lief einwandfrei unter hoher Last. Durch GNU Pth ist Apache/MPM - MPM steht übrigens für "multi process model" - auf fast allen Plattformen einsetzbar, selbst wenn diese nativ keine POSIX Threads unterstützen.
Weiter geht es mit dem zweiten Projekt, welches Ralf S. Engelschall dieses Jahr dem GNU Projekt hinzugefügt hat.
GNU Shtool
Bei dem GNU Shell Tool [9] handelt es sich um eine Kompilation von kleinen, stabilen und sehr portablen Shellskripten in einem eingenständigen Shell Tool.
Für die automatische Anpassung und Installation von Softwarepaketen wird heutzutage gerne GNU Autoconf [10] bzw. GNU Automake eingesetzt. Dabei kommen spätestens bei der Installation etliche Shellskripte zur Anwendung, die meistens dazu dienen, bestimmte Funktionen zur Verfügung zu stellen, die auf manchen Plattformen fehlen. Nun sammelt sich mit der Zeit ein Zoo an solchen Skripten an, die dann zum Teil auch noch an unterschiedlichen Orten verwaltet werden. Die dadurch verbundenen Probleme der Pflege und Verteilung sucht GNU Shtool zu beseitigen. Letztendlich stellt es eine "black box" zur Verfügung, mit deren Hilfe viele Shell-Aufgaben in einem Quellcodebaum erledigt werden können. Damit ist es sozusagen das Gegenstück zum GNU Libtool [11], welches die Erzeugung von Shared Libraries vereinfacht.
Das nächste Projekt möchte ich gerne allen ans Herz legen, denn gerade Freie Software im Kryptographie-Bereich hat lange Zeit gefehlt.
GnuPG
Bereits seit einer ganzen Weile arbeitet Werner Koch am GNU Privacy Guard [12], einem freien Ersatz für PGP mit etlichen Vorteilen. Unterstützung hatte er dabei von Michael Roth, Rémi Guyomarch, Matthew Skala und vielen anderen. Anfang September war es nun soweit, die Version 1.0 wurde endlich freigegeben.
Doch warum sollte jemand auf GPG umsteigen? Zunächst einmal ist GPG in Deutschland entstanden und unterliegt damit nicht den U.S. Exportbeschränkungen, das umständliche und langsame Verschicken und Einscannen entfällt also. GnuPG hält sich an den Open PGP Standard (RFC2440) und verzichtet vollständig auf patentierte Algorithmen. Von Haus aus unterstützt GPG die public-key Algorithmen DSA und ElGamal, für symmetrische Verschlüsselung stehen 3DES, CAST5, Blowfish und Twofish zur Verfügung. Wem das nicht genügt, der kann sehr leicht eigene Krypto-Module dynamisch in GnuPG einbinden.
Der größte Vorteil ist jedoch, daß GnuPG Freie Software ist. Dies bedeutet nicht nur, daß auch Firmen kostenlos darauf zurückgreifen können, es bedeutet vielmehr, daß ein sehr viel höheres Vertrauen in das Programm gesetzt werden kann.
Doch auch im Umfeld von GPG hat sich bereits viel getan. Werner Koch selbst arbeitet an einer GNU Kryptographie-Library und der GNU Secure Transport Initiative, eines freien SSH v2 Ersatzes. Außerdem strebt er für die nächste Entwicklungsrunde von GPG das Auslagern der Private Keys in einen Daemon an, der bei Bedarf auch in Hardware-Token ausgelagert werden kann.
Brian Warner hat den Entropy Gathering Daemon (EGD) geschrieben, mit dem auch auf HP oder Solaris Workstations gute Zufallszahlen erzeugt werden können. Mit pgpgpg von Michael Roth existiert ein Programm, das PGP Kommandozeilenoptionen für GPG aufbereitet, damit auch alte Programme direkt mit GPG benutzt werden können. Außerdem arbeitet er an Privacy Guard Glue (PGG), einer high-level Library für GnuPG.
Ein Großteil der Mailprogramme unterstützt bereits GPG und auch GNOME, KDE und Tcl/Tk Frontends existieren bereits, daher sollte der Umstieg eigentlich keine großen Probleme bereiten. Übrigens steht zu hoffen, daß GnuPG nicht irgendwann durch die Politik torpediert wird, da das Deutsche BMWi erwägt, ein auf GnuPG basiertes Kryptographieprojekt zu fördern, da nur Freie Software Sicherheit bieten könne.
Doch nun zu einem Projekt aus dem Bereich der Mailinglisten-Manager.
Mailman
Bei Mailman [13] handelt es sich um einen Mailinglisten-Manager, der urpsrünglich von John Viega in Python geschrieben wurde. Mittlerweile hat sich der Entwicklerkreis jedoch auf die "Mailman Cabal" ausgeweitet, der neben John Viega auch Barry Warsaw, Harald Meland, Ken Manheimer und Scott Cotton angehören.
Obwohl es auf diesem Gebiet bereits einige altgediente Programme gibt, ist Mailman definitiv einen näheren Blick wert. Neben den normalen Fähigkeiten ist Mailman auch komplett über ein Web-Interface administrierbar, es verfügt über eine Spam-protection und ein integriertes News-Gateway. Zudem gibt es die Möglichkeiten, mehrere Administratoren und Moderatoren für eine Liste zuzulassen, und die bei manchen so beliebten Digests gibt es auf Wunsch auch im MIME Format. Allen Mailinglisten-geplagten Administratoren kann ich nur empfehlen, es sich mal anzuschauen.
Bevor ich nun zum Ende komme, hier noch ein paar kurze Bemerkungen in eigener Sache.
This is the end...
Zunächst einmal scheint es, daß es noch mehr Gründe für die Verwendung der GNU/Linux Nomenklatur gibt, denn Amiga hat angekündigt, ein auf dem Linux-Kernel basierendes Betriebssystem zu entwickeln, welches allem Anschein nach nicht frei sein wird. Unabhängig davon, daß ich dies für einen Rückschritt in der Evolution halte, bedeutet es, daß sich unser System auch namentlich deutlich davon abheben sollte, weshalb mir GNU/Linux noch mehr wie die beste Wahl erscheint.
Außerdem möchte ich mich gerne für die positiven Reaktionen bedanken, die ich nach der Einführung der "We run GNU" Initiative [4] erhalten habe. In der letzten Woche wurde diese Seite mindestens einmal pro Tag aktualisiert, da ein neues Bild eingeschickt wurde - so habe ich mir das vorgestellt. :-) Besonderer Dank geht diesmal an Stefan Kamphausen, von dem das obige Logo stammt.
Schließen möchte ich mit einer Bitte um Freiwillige. Im Oktober findet wieder einmal in München (Deutschland) die "Systems" statt, auf der diesmal ein großer "Linux-Park" vertreten sein wird. Ich selber werde voraussichtlich am Mittwoch dort einen Vortrag über das GNU Projekt halten. Im Augenblick fehlen jedoch noch Leute, die Lust und Zeit hätten, während der Woche eventuell einen gemischten GNU/Debian/GNOME Stand zu betreuuen.
Wer Lust und Zeit hat und natürlich alle anderen Bemerkungen, Kommentare, Anregungen und Ideen gehen wie immer an die unten angegebene E-mail Adresse [1].
Infos |
[1] Ideen, Anregungen, Kommentare an Brave GNU World:
column@gnu.org
|
Zurück zur vorherigen Ausgabe / Brave GNU World home page
Return to GNU's home page.
Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.
Please send comments on the Brave GNU World column to column@gnu.org, send comments on these web pages to webmasters@www.gnu.org, send other questions to gnu@gnu.org.
Copyright (C) 1999 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.
Last modified: Fri Oct 15 17:46:40 CEST 1999