|
|
|
|
|
|
Aktueller Überblick über freie Software und ihre MacherProjektekücheMartin Loschwitz |
|
Die Programmiersprache Basic ist im Mai 40 Jahre alt geworden. Zwar steht sie nicht direkt in Verbindung mit Linux, demonstriert aber sehr deutlich, wie ein anfänglich wenig beliebtes Softwareprodukt im Laufe der Zeit große Erfolge feiern kann. Anfänglich galt Basic nämlich als stark beschränkt. Tatsächlich aber wurde die Sprache schnell bekannt und diente sogar als Grundlage bei der Gründung von Microsoft.
Das als besonders sicher geltende Betriebssystem OpenBSD[1] ist seit kurzem in der neuen Version 3.5 verfügbar. Im Gegensatz zur Vorgängerversion gibt es bei OpenBSD 3.5 nicht viel Spektakuläres für Benutzer von x86-Rechnern. Damals sorgte vor allem die Einführung von W^X als Schutz vor Buffer Overflows für Aufsehen (siehe[2]).
Wirklich interessant ist in der neuen Version 3.5 vor allem der AMD-64-Port, mit dem OpenBSD nun auch auf AMDs Athlon-64- und Opteron-Prozessoren läuft. Da die Opterons allerdings ausschließlich im Mehrprozessor-Betrieb arbeiten (SMP), macht OpenBSD auf diesen Systemen wenig Sinn, denn es unterstützt kein SMP. Doch an der Implementierung dieses Features arbeiten die Entwickler bereits seit längerer Zeit.
Mit der neuen Version unterstützt OpenBSD auch die Cats-Architektur. Dieser Port auf die ARM-basierten Chips soll als Grundlage für die weitere Unterstützung von ARM-Prozessoren dienen. Der Code für den Port stammt aus NetBSD. Aus diesem Grund wird es vermutlich in Zukunft möglich sein, den eigenen PDA mit OpenBSD auszustatten, so wie es Linux schon mit den I-Paqs von HP vorgemacht hat.
Die Entwickler haben auch an den Gerätetreibern gearbeitet. Der Wi-Treiber für WLAN-Karten mit Prism-Chipsatz ist deutlich stabiler und der Host-AP-Modus versteckt nun optional den so genannten Service Set Identifier (SSID), was zum Schutz vor Angreifern recht nützlich ist. Ansonsten gibt es Verbesserungen bei der Unterstützung der Intel- PRO/1000-Gigabit-Ethernet-Karte, bei SCSI-Treibern, ATA/SATA und beim Powermanagement per APM.
Doch auch für Endanwender hat sich etwas getan. Einige Programme, die ursprünglich aus dem GNU-Projekt stammen, haben die Entwickler gegen gleichwertige Pendants unter der BSD-Lizenz ersetzt. Die PTY-Devices (die Pseudo-Terminal-Schnittstellen) erstellt OpenBSD nun dynamisch und es gibt die neue Schnittstelle »/dev/ptm«. Mit ihr ist es möglich, ein PTY ohne Root-Rechte zu öffnen. Bisher mussten Applikationen wie Xterm als SUID-Root laufen, um ein PTY zu öffnen.
Neue Programme in Version 3.5 sind unter anderem der BGP-4-Daemon Bgpd, Sensorsd (zum Auslesen von Hardware-Informationen) und PXEBoot (um über ein Netzwerk zu booten). Natürlich enthält OpenBSD 3.5 auch sicherheitsrelevante Fixes sowie eine aktuelle Version von OpenSSH. Die mitgelieferte Software ist sehr aktuell: XFree86 4.4 (in einer abgeänderten Version wegen des kürzlichen Lizenzwechsels[3]), Perl 5.8.2, GCC 2.95.3 und 3.3.2, Apache 1.3.29 und Bind 9.2.3.
Obwohl die neue Version keine bahnbrechenden neuen Features enthält, winkt sie doch mit einigen Leckerbissen. Wer sich die neue Release installieren will, findet sie im FTP-Archiv[4]. Die Upgrade-Mini-FAQ[5] hilft beim Aktualisieren bestehender Installationen.
Die meiste freie Software ist die Leistung einer ganzen Gruppe von Programmierern. Um ihre Arbeit zentral zu koordinieren und zu verwalten, benutzen viele Projekte Versionskontrollsysteme wie CVS[6] oder das modernere Subversion[7]. Doch diese Systeme verwalten nicht nur Sourcecode, sondern eignen sich für alle Arten von Dateien. So könnten Mitarbeiter in Firmen Dokumente ihren Kollegen (oder einem festgelegten Kreis von Mitarbeitern) zur Verfügung stellen und gemeinsam daran arbeiten.
Damit auch die weniger versierten Anwender in den Genuss derartiger Systeme kommen, bedarf es einer passenden Benutzeroberfläche. Bei Programmierern ist das in der Regel kein großes Problem, sie sind den Umgang mit den Kommandozeilentools von CVS und Subversion gewohnt. Jene, deren Domäne allerdings die Büroarbeit ist, tun sich häufig schwer. Für sie lohnt sich ein Blick auf RapidSVN[8].
Das Programm ist eine Erweiterung zum Dateiverwaltungssystem Subversion mit einem grafischen Frontend. Es basiert auf dem Widget-Set WX-Windows, das auf vielen Betriebssystemen läuft. Ursprünglich war RapidSVN für Microsoft Windows geplant, aber da WX-Windows auch in einer Linux-Version vorliegt, funktioniert es dort ebenfalls.
RapidSVN bietet grafische Elemente für alle Basisfunktionen von Subversion, das Aussehen ist dem des Windows Explorers sehr ähnlich. Wichtige Funktionen sind über Icons direkt auf der Oberfläche des Programms zu erreichen, was die Verwendung auch für ungeübte Benutzer möglich macht, erfahrene erreichen über das Interface auch fortgeschrittene Funktionen sehr effizient.
Das Projekt steht nicht unter der GPL, sondern unter der Apache Software License. In der Readme-Datei[9] weisen die Entwickler auf einige Besonderheiten des Programms hin. Dort ist unter anderem die Rede von Problemen beim Betrieb unter Linux. Zwar lässt sich RapidSVN problemlos kompilieren, zur Laufzeit muss der Anwender allerdings einige Unzulänglichkeiten umgehen. Eine kleine Anmerkung weist außerdem darauf hin, dass RapidSVN vermutlich auch mit anderen Unix-Derivaten wie Mac OS X funktioniert.
RapidSVN gibt es auf der Homepage[8] als Binärpaket für Debian Woody, Red Hat und Windows. Wer sich unter Windows lieber den Sourcecode selber kompilieren will, benötigt dazu das MS-Platform-SDK, das mit einer Größe von zirka 400 MByte beim Download nicht gerade klein ist. Die Quellen von RapidSVN gibt es als Tar.gz-Archiv und die aktuelle Entwicklungsversion in einem SVN-Repository. Informationen finden sich in der bereits erwähnten Readme-Datei[9].
Wie in der letzten Projekteküche beschrieben[10] stellt sich bei Hardwareherstellern ein Trend zur Linux-Unterstützung ein. Das klingt im ersten Moment sehr vernünftig, stellt sich bei genauerer Betrachtung aber oft als Ente heraus. Die Programmierer erstellen nämlich häufig einen freien Treiber, machen diesen aber gleichzeitig abhängig von Zusatzmodulen, die nur in Binärform vorhanden sind. Die Treiber können das Prädikat "frei" in solchen Fällen, wenn überhaupt, nur begrenzt für sich beanspruchen.
Eine Diskussion innerhalb des Debian-Projekts zeigt das Problem dieser Software auf: Oftmals liegt die Schwierigkeit nicht darin, dass Teile des Treibers nicht frei sind, sondern vielmehr darin, die nicht freien Teile zu isolieren. Handelt es sich um Treiber wie die bekannten Nvidia-Module, ist die Unterscheidung leicht, denn Nvidia liefert keine einzige Zeile Quellcode aus. Kompliziert wird es erst dann, wenn Sourcen und Binärdateien gemischt sind, wie es bei einigen Treibern für die so genannten Win-Modems der Fall ist. Auch der Mad-Wifi-Treiber aus der letzten Ausgabe der Projekteküche, der Binär-Firmware benötigt, ist ein gutes Beispiel.
Fiel die Unterscheidung früher leicht, verkompliziert sich die Angelegenheit in letzter Zeit durch die oben angesprochenen angeblichen Open-Source-Strategien der Hardwarehersteller zunehmend. Es gibt sogar Treiber, bei denen die binäre Firmware im Quellcode einkodiert ist (siehe Abbildung 4). Die jüngste Aktion von Herbert Xu, Debian-Maintainer eines Großteils der Kernelpakete, hat nun für beträchtliches Aufsehen gesorgt. Er entfernte kurzerhand alle Kernelmodule aus den Debian-Paketen, die binäre Firmware verwenden.
Daher fehlen Anwendern jetzt Module wie der TG3-Treiber für Gigabit-Netzwerkkarten von Broadcom oder der QLA2xxx-Treiber für QLogics SCSI-Adapter. Auch die DRM-Treiber für R128- und Radeon-Chipsätze sind nicht mehr in den Kernelpaketen enthalten.
Auf der Mailingliste [debian-devel] sorgte Xus Vorgehen für heftige Reaktionen. Bei Redaktionsschluss war die Diskussion zwar immer noch in vollem Gange, doch ist bereits zu sehen, dass sich zwei Gruppen herausbilden. Auf der einen Seite stehen jene, die mit Herbert Xu übereinstimmen und meinen, dass proprietäre Firmware nicht mit den Debian Free Software Guidelines[11] zu vereinbaren ist. Daher verstoße eine Integration dieser Software in den »main«-Bereich von Debian gegen den Gesellschaftsvertrag[11].
Das andere Lager argumentiert mit der Benutzerfreundlichkeit. Anwender, die derartige Treiber brauchen, müssten viel Arbeit aufwenden, um sie sich unabhängig von Debian zu besorgen. Es ist ihnen nicht zuzumuten, Updates aus dem Netzwerk nicht laden zu können, weil ihre Netzwerkkarte ohne den TG3-Treiber nicht funktioniert. Interessanterweise ziehen auch die Pragmatiker den Gesellschaftsvertrag heran. Denn er schreibt zwar in Paragraf 1 vor, dass Debian GNU/Linux nur aus freier Software bestehen darf, Paragraf 4 jedoch bekräftigt die Orientierung Debians an den Anwender-Bedürfnissen.
Debian-Entwickler Erich Schubert brachte einen neuen Aspekt in der Diskussion. Er erklärte, dass seiner Meinung nach Firmware-Dateien lediglich Daten enthalten, wie jede andere Software auch. Er fordert deswegen eine gründliche Lösung des Problems, wie mit allen Arten von Daten in Bezug auf freie Software umzugehen sei. Für ihn bringt die Unterscheidung von verschiedenen Datentypen viele Probleme mit sich. So fragte er zum Beispiel in seiner Mail, wie im Zweifelsfalle eine Schriftart zu bewerten sei.
Herbert Xu entfernte derweil munter weitere Treiber aus den Kernelpaketen. Auch die Maintainer anderer Pakete wie XFree86 haben begonnen, Sourcecode-Teile für ihre Debian-Pakete zu entfernen. Bei XFree86 hielten sich die Effekte noch in Grenzen; die alten Firmware-Dateien werden kaum für eine halbwegs aktuelle Grafikkarte benötigt.
Als Lösung schlugen einige Entwickler vor, die Hotplug-Architektur aktueller Kernel zu verwenden, um die unfreien Binärdateien bei Bedarf dynamisch nachzuladen. Viele Treiber benötigen die Firmware in den Quelldateien nämlich nur sehr selten und nur für spezielle Hardware. Eine Trennung von Firmware und Treiber wäre problemlos möglich, der Firmware-Teil könnte dann im »non-free«-Teil von Debian verbleiben, der Treiber selbst in »main«.
Dieser Vorschlag scheint auch bereits Wirkung zu zeigen. Auf der Linux-Kernel-Mailingliste kursiert ein Patch, das den TG3-Treiber von der enthaltenen Firmware abtrennt. Einige Benutzer testeten das Patch und berichteten, dass ihr TG3-Chipsatz damit auch weiterhin funktioniere. Jeff Garzik, der für diesen Treiber verantwortlich ist, lehnte das Patch aber ab. Er berief sich darauf, einen ähnlichen Mechanismus in naher Zukunft mit Hilfe des Hotplug-Systems im Kernel schaffen zu wollen.
Wie sich die Debianer entscheiden werden, ist noch unklar. Kernel und Firmware zu trennen hätte zwar Vorteile, würde aber auch die Integration des »non-free«-Teils in das neue Installationssystem, den Debian-Installer, notwendig machen. Das bloße Entfernen von Treibern aus dem Kernel ist aber auch keine Alternative, weil die Benutzer damit vor schier unlösbaren Problemen stehen.
Im Übrigen scheint Herbert Xu bei dem Entfernen entsprechender Treiber nicht allzu konsequent vorzugehen: Nachdem er die DRM-Treiber für Grafikkarten mit R128- und Radeon-Chipsatz aus dem Kernel entfernt hatte, gingen derart viele Bugreports und Beschwerden ein, dass Xu die Treiber wieder einfügte.
Die Debianer beschäftigt zurzeit noch eine weitere gravierende Änderung in Debian: die des Gesellschaftsvertrags. Er ist eines der wichtigsten Dokumente für das Projekt. Die erste Version verfasste Bruce Perens im Jahr 1997. Nach Meinung einiger Entwickler wies der Vertrag Mängel bei der Formulierung auf. Einer der Reformer ist Andrew Suffield, der in einer so genannten General Resolution die Änderung des Gesellschaftsvertrags beantragte.
Der Titel des Vorschlags[12] lautet "Redaktionelle Änderung". Die von Suffield vorgeschlagenen Änderungen machten nicht den Eindruck, als seien sie gravierend, daher stimmten die meisten Entwickler in einer anberaumten Wahl zu. Kurz nach der Änderung des Vertrags bemerkte der Release-Manager Anthony Towns allerdings, wie gravierend diese Entscheidung war.
In der Änderung des Gesellschaftsvertrags ging es darum, den Begriff "Software" durch "Werke" zu ersetzen, um den Vertrag auf alle Debian-Bestandteile anwenden zu können (siehe "Brave GNU World" in diesem Heft). Diese Formulierung kollidiert allerdings mit einigen Regeln, die Anthony Towns für die Release der nächsten Debian-Version 3.1 - alias Sarge - festgelegt hat.
Um das Problem genau zu erklären, ist es vielleicht nötig, ein wenig in der Geschichte zu stöbern: Die GNU Free Documentation License, kurz GFDL, sollte ursprünglich eine Lizenz für Texte und andere Dokumente sein, die nicht einwandfrei unter den Begriff Software fallen. Weil sie aber einen strittigen Absatz enthält, haben die Debian-Entwickler entschieden, dass die GFDL einige der in den Debian Free Software Guidelines festgelegten Bedingungen nicht erfüllt. Software, die unter der GFDL lizenziert ist, gilt damit für Debian als nicht frei.
Ein Großteil der Dokumentation, die mit offiziellen GNU-Paketen kommt, ist mittlerweile unter der GFDL lizenziert. Sie zu entfernen hieße im ersten Schritt nicht nur, dass Bibliotheken wie die Glibc, GCC oder Emacs im Hauptteil von Debian ohne Dokumentation wären. Der Aufwand, der zum Entfernen der GFDL-Dokumentationen nötig wäre, könnte die Release von Debian GNU/Linux 3.1 auf ungewisse Zeit verzögern. Genau dies gilt es aber unter allen Umständen zu verhindern.
Vor demselben Problem steht übrigens auch die bereits oben erwähnte Binärfirmware von Treibern. Sie unterliegt zurzeit, wie auch die Dokumentation, der GFDL im Hauptteil der Distribution, verträgt sich aber nicht mit den Debian-Richtlinien für freie Software.
Um diese Probleme nicht vor der Sarge-Release lösen zu müssen, griff Anthony Towns kurzerhand zu einem Trick: Weil im Gesellschaftsvertrag nur von Software die Rede war, sagte er, dass Dokumente und zuletzt auch Firmware, die im Hauptteil der Distribution zu finden ist, keine Software sind. Er nutzte quasi eine Lücke im Gesellschaftsvertrag. Die Dateien blieben damit zwar unfrei, das Problem und die Lösung hätte aber auf die Zeit nach der Sarge-Release verschoben werden können.
Da im Gesellschaftsvertrag nach der kürzlichen Änderung aber nun von Werken die Rede ist, erklärte Towns in einer Mail an die Entwickler[13], dass seine provisorische Lösung nicht mehr funktioniere. Der Begriff Werke deckt nämlich auch Dokumente und Firmware ab. Die alternative Interpretation des Begriffs Software fällt damit weg.
Anthony Towns äußert sich daher sehr pessimistisch über die geplante Sarge-Release und meint, dass es durchaus möglich sei, dass Sarge dieses Jahr nicht mehr erscheint. Die Änderungen, die der neue Gesellschaftsvertrag an der Distribution erzwingt, wären extrem umfangreich. Eine davon ist zum Beispiel die Anpassung des Debian-Installers zur Unterstützung des »non-free«-Zweigs.
Towns' Vorhersage, dass unter diesen Umständen Sarge dieses Jahr nicht mehr zu veröffentlichen sei, schlug wie eine Bombe ein, bei Entwicklern und Benutzern gleichermaßen. Einige sprachen gar vom Selbstmord Debians, andere machten sich daran, eine Lösung zu erarbeiten. Wenige Stunden nach dem Erscheinen von Towns' Mail gab es bereits neue Vorschläge für eine General Resolution, die die Änderungen dauerhaft oder zeitlich befristet widerrufen sollen.
Steve Langasek, der mittlerweile offiziell den Posten des Release Assistant innehat, schlug vor, die Änderungen des Gesellschaftsvertrags außer Kraft zu setzen und erst ab 01.09.2004 gültig werden zu lassen. Duncan Findlays Vorschlag ist dem von Langasek sehr ähnlich, legt aber keinen Zeitpunkt fest, sondern spricht lediglich von "unverzüglich nach der Sarge-Release". Colin Watson schlägt einen Zusatz zum Gesellschaftsvertrag vor, in dem er ganz ausführlich erklärt, dass zwar Debian GNU/Linux 3.1 die Bestimmungen des Vertrags nicht erfüllt, die Nachfolgeversion dieses Problem aber beheben werde. Dieser Zusatz im Gesellschaftsvertrag könnte danach wieder wegfallen.
Der vierte Vorschlag, diesmal von Craig Sanders, ist ganz einfach: Alle in der letzten General Resolution vorgenommenen Änderungen ersatzlos streichen. Alle Vorschläge haben die nötige Zahl an Befürwortern gefunden und stehen zum Redaktionsschluss noch zur Diskussion. Das Ergebnis der Abstimmung ist ab 31. Mai unter[14] zu finden.
Zutaten: 250 g Spirelli-Nudeln, 750 g mageres Rindfleisch, Salz, Pfeffer, ein Teelöffel Paprikapulver, Tabasco, zwei Zwiebeln, eine Möhre, eine kleine Dose Tomatenmark, 100 g Lauch, 200 g Maiskörner, drei Esslöffel Öl, eine Dose rote Bohnen, gekörnte Brühe.
Zubereitung: Öl in einem großen Topf erhitzen, Tomatenmark zugeben und darin die klein gehackten Zwiebeln anschwitzen. Fleisch in kleine Würfel schneiden und in den Topf geben. Dann Paprikapulver über das Fleisch streuen und in den Topf geben. Mit zwei Litern Wasser aufgießen und eineinhalb Stunden kochen lassen.
Möhren und Lauch klein schneiden und mit den roten Bohnen und dem Mais sowie den Nudeln in den Topf geben. Alles zirka 20 Minuten ziehen lassen. Die Mischung mit Salz und Pfeffer und nach eigenem Geschmack eventuell mit gekörnter Brühe würzen und abschmecken. Der Bohnentopf kann beispielsweise mit Stangenbrot serviert werden.
Während die Nudeln im Topf scharf werden, hier der obligatorische Aufruf: Wer ein Tool schätzt oder entwickelt hat und es an dieser Stelle vorgestellt sehen möchte, schickt eine E-Mail an[15]. Alle Hinweise sind willkommen. (mwe)
| Infos |
|
[1] OpenBSD: [http://www.openbsd.org/] [2] Martin Loschwitz, "Projekteküche": Linux-Magazin 01/04, S. 74 [3] Martin Loschwitz, "Projekteküche": Linux-Magazin 05/04, S. 90 [4] FTP-Archiv von OpenBSD: [ftp://ftp.openbsd.org/] [5] OpenBSD Upgrade Mini-FAQ: [http://openbsd.org/faq/upgrade-minifaq.html] [6] CVS: [http://www.cvshome.org] [7] Subversion: [http://subversion.tigris.org/] [8] RapidSVN: [http://rapidsvn.sourceforge.net/] [9] RapidSVN Readme: [http://rapidsvn.sourceforge.net/README.txt] [10] Martin Loschwitz, "Projekteküche": Linux-Magazin 06/04, S. 92 [11] Gesellschaftsvertrag und DFSG: [http://www.debian.org/social_contract] [12] Vorschlag von Andrew Suffield: [http://www.debian.org/vote/2004/vote_003] [13] Mail von Anthony Towns: [http://lists.debian.org/debian-devel/2004/debian-devel-200404/msg06588.html] [14] Wahlseite zur Gesellschaftsvertrags- Abstimmung: [http://www.debian.org/vote/2004/vote_004] [15] Hinweise und Vorschläge: [projektekueche@linux-magazin.de] |
| Der Autor |
|
Martin Loschwitz ist Schüler aus Niederkrüchten und hilft in seiner Freizeit dabei, die Debian GNU/Linux-Distribution weiterzuentwickeln. Momentan arbeitet er am Debian-Desktop-Projekt. |