|
|
|
|
|
|
Aktueller Überblick über freie Software und ihre MacherProjektekücheMartin Loschwitz |
|
Am 6. und 7. März findet an der technischen Universität in Chemnitz der sechste Chemnitzer Linuxtag[1] statt. Anders als der Name suggeriert, steht diese Veranstaltung nicht in Konkurrenz zum Linuxtag in Karlsruhe, sondern soll eigene Akzente setzen und die Menschen in Chemnitz und Umgebung für Linux begeistern. Das Programm ist voll gepackt mit Vorträgen und Workshops (siehe Abbildung 1).
Viele Internetuser ziehen die Kommunikation über Internet Relay Chat (IRC) der E-Mail vor, da IRC einen schnelleren und zeitnäheren Austausch von Informationen ermöglicht. Das von Jarkko Oikarinen im Jahr 1988 entwickelte IRC beschreibt ein Protokoll, das es vielen Clients ermöglicht, über einen Server direkt miteinander zu kommunizieren. Neben fünf Requests for Comment (RFC) gibt es heute unzählige Servervarianten mit sehr unterschiedlichem Funktionsumfang.
Noch im Jahr 1990 waren die bekanntesten IRC-Server zu einem losen Netzwerk ohne festgelegte Struktur verbunden. Dieses Netzwerk war unter dem Namen Anarchie-Net oder kurz A-Net bekannt. Auf 38 Server kamen im Schnitt zwölf Benutzer. In jenem Jahr entstand noch ein weiteres Netzwerk, das ausschließlich Tests des neuen IRCd in Version 2.6 diente und aus 25 Servern bestand. Im August 1990 schlossen einige Admins dann einen offenen Server an das A-Net an. Dieser Server erlaubte es auch Außenstehenden, ihre IRC-Daemons in das Netzwerk zu integrieren. Sein Hostname war »eris.berkeley.edu«. Da Eris wegen seiner Offenheit heftige Diskussionen unter den Netzbetreibern auslöste, entstand als Alternative wenig später das eigenständige EF-Net[2] (Eris Free Net), heute eines der größten IRC-Netzwerke der Welt.
Da das EF-Net sehr schnell wuchs, waren die Leitungen oft überlastet und es kam zu Netsplits, was bedeutet, dass ein Server die Verbindung zu einem anderen Server verliert. Das machten sich findige IRC-User zunutze: In IRC-Netzen gibt es einen Channel auf jedem der angeschlossenen Server. Verliert ein Rechner nun die Verbindung zum Netzwerk, existiert der Channel sowohl auf diesem Rechner als auch im Netzwerk weiter. Betritt ein Angreifer den Channel auf einem der beteiligten Server und ist dieser Kanal dort leer, dann erhält er automatisch Operator-Rechte.
Bei der erneuten Zusammenführung der Channels behielt früher der Angreifer seine Privilegien und konnte die Kontrolle über den Channel als Chanop übernehmen. Diese Sicherheitslücke missfiel den Benutzern und Serverbetreibern. Der IRCd von damals musste also erweitert werden, um das Problem zu beheben. 1992 entstand ein weiteres Testnetzwerk, das aber kurze Zeit später auch normale Anwender nutzten. Das Undernet[3] war geboren.
Ziel der Undernet-IRCd-Entwickler war es, das Netzwerk gegen Missbrauch abzusichern. Dazu integrierten sie Timestamp-Funktionen, die dafür sorgten, dass Benutzern der Operator-Status wieder entzogen wird, falls sie während eines Splits einen Kanal betreten. Die Programmierer implementierten außerdem den ersten so genannten C-Service, der es Benutzern erlaubte, einen Kanal zu registrieren. Sie hatten damit die Möglichkeit, immer Operator-Status in diesem Kanal zu erhalten.
Im Sommer 1994 entstand als weiteres IRC-Netzwerk das DAL-Net[4], benannt nach dem Nickname seines Gründers Dalvenjah. Als Daemon kam der IRCd aus dem Undernet zum Einsatz. Neu beim DAL-Net war unter anderem, dass Nicknames mehr als neun Zeichen enthalten durften. Außerdem erlaubte es der DAL-Net-IRCd, Benutzer netzwerkweit auszuschließen. Zum C-Service, der im DAL-Net Chanserv hieß, gesellte sich der Nickserv, der es ermöglichte, Nicknames zu registrieren.
Der letzte große Split in der IRC-Welt fand im Jahr 1996 statt. Die Betreiber des EF-Net waren sich uneinig, wie sie das Netzwerk bei Netsplits am besten vor Angriffen schützen sollten. Die EF-Net-Admins aus Europa starteten daraufhin kurzerhand das IRC-Net[5]. Das EF-Net-USA-Netz behielt seinen Namen.
Das Quakenet[6] wurde 1997 aus dem Boden gestampft. Es richtet sich besonders an Spieler und ist seit seinem Bestehen explosionsartig gewachsen, es besitzt sogar seine eigene Serversoftware. Ein Jahr nach dem Quakenet entstand das Open Projects Network, heute Freenode[7]. Es dient als Kommunikationsplattform für Projekte, die sich mit freier Software beschäftigen. Zur Zeit nutzen es rund 13000 User.
Die heutzutage eingesetzte Serversoftware ist so unterschiedlich wie die Netzwerke selbst. Das IRC-Net setzt immer noch auf den Ur-Server IRCd[8]. Er ist aber sehr rudimentär, vom ursprünglichen Code seines Erfinders Jarkko Oikarinen ist kaum noch etwas übrig. Christophe Kalt ist maßgeblich an der Weiterentwicklung von IRCd beteiligt. Services wie den Chanserv oder Nickserv sucht man im IRCd vergebens.
Das EF-Net verwendet heute den eigens entwickelten Hybrid[9], der auf dem originalen IRCd aufbaut. Einer der Hauptunterschiede zwischen Hybrid und IRCd ist das System für den Schutz bei Netsplits. Hybrid ermöglicht aber auch Services[10] und hat Neuerungen gebracht, die sogar in den originalen IRCd eingeflossen sind. Dazu gehören die Channel-Modi »+I« und »+e«, mit denen ein Benutzer oder Host von Bans ausgeschlossen wird.
Gelegentlich trifft man im EF-Net auch auf den Ratbox-IRCd[11], einen Fork von Hybrid, der vollständig kompatibel zu Hybrid ist. Ein weiterer Hybrid-Fork ist Bahamut[12], der heute im DAL-Net zum Einsatz kommt und einige interessante Features bietet. Er verhindert beispielsweise die Verbreitung von Viren und Würmern, indem er entsprechende DCC-Verbindungen abfängt.
Im Undernet werkelt fast seit dem Bestehen des Netzwerks Ircu[13], der auf dem originalen IRCd basiert. Auf Ircu wiederum basiert Asuka[14] aus dem Quakenet. Freenode setzt auf eine Modifikation von Hybrid mit dem Namen Dancer[15]. Er ermöglicht die zentrale Administration des Netzwerks.
Mittlerweile hat das seit Jahrzehnten gewachsene IRC Konkurrenz bekommen: einige Instant-Messaging-Protokolle wie ICQ, AIM sowie SILC[16], das nach außen hin ähnlich funktioniert wie IRC, aber SSL integriert. Immer mehr Benutzer setzen für die direkte Kommunikation auf diese Alternativen. Die Zukunft wird zeigen, ob sich IRC gegen diese Konkurrenz durchsetzen kann.
Portable Mini-MP3-Player kosten mittlerweile unter 100 Euro. Doch der niedrige Preis bringt nicht nur Vorteile, denn die Soundqualität ist oft minderwertig. Beim I-Pod hingegen kann von billig keine Rede sein. Hersteller Apple lässt sich seinen handlichen Musikplayer teuer bezahlen, rund 350 Euro fallen für den I-Pod an. Dafür bekommt der Käufer aber auch anständigen Sound und ein gut verarbeitetes, schönes Gerät. Obendrein enthält es eine Festplatte mit maximal 40 GByte Speicherplatz.
Mittlerweile gibt es auch für Linux Programme, um Musik auf das Gerät zu laden, sie zu ordnen und Playlisten zu erstellen. Als Erstes sollten I-Pod-Besitzer sich überlegen, ob sie nicht das ab Werk installierte Dateisystem HFS+ von Apple durch VFAT ersetzen sollten. Linux unterstützt zwar HFS+, der Treiber ist aber fehleranfällig. Der VFAT-Treiber ist wesentlich stabiler und der I-Pod arbeitet mit VFAT absolut problemlos zusammen. Unter[17] gibt es eine Anleitung zur Formatierung der Festplatte.
Das Tool Gtkpod[18] und die Gnupod-Skriptsammlung[19] erlauben die komfortable Verwaltung der Musik auf dem I-Pod. Gtkpod benutzt eine GTK-2-Oberfläche, die Gnupod-Tools sind reine Konsolenprogramme, weshalb Gtkpod wohl in den meisten Fällen die komfortablere Lösung ist. Dort hat der Anwender die Möglichkeit, lokale Verzeichnisse mit dem I-Pod zu synchronisieren, Playlisten zu erstellen und Musikstücke zu sortieren. Gtkpod lässt den Benutzer auch Stücke bewerten und sortiert sie dann in einer Rangliste.
Wem es allerdings noch nicht genügt, den I-Pod mit Linux zu synchronisieren, der installiert sich das Betriebssystem direkt auf das Gerät. Das I-Pod-Linux-Projekt[20] macht genau dies seit einiger Zeit möglich. Auf der Website des Projekts finden sich die nötigen Tools sowie eine Anleitung, wie man sie installiert und richtig konfiguriert. Als Beweis gibt es auf der Website ein Foto, das den I-Pod mit Meldungen des Linux-Kernels im Display zeigt.
Alles in allem ist der I-Pod sehr Linux-freundlich. Gtkpod macht die Verwaltung der Musik einfach und wer schon immer mal das Tux-Framebuffer-Logo im LCD betrachten wollte, hat dank I-Pod-Linux auch dazu die Möglichkeit.
Prozessoren mit 64 Bit erobern den Massenmarkt. Zwar gelang Intel mit dem Itanium und dem Itanium II noch nicht der große Wurf. Erzfeind AMD aber scheint mit seiner 64-Bit-Plattform bereits jetzt erfolgreich zu sein: Der Opteron lässt als Prozessor speziell für Server fast jede 32-Bit-Maschine problemlos hinter sich. Im Desktop-Segment behauptet sich AMD zurzeit mit dem Athlon 64, der auf der AMD-64-Architektur basiert. Microsoft Windows unterstützt diese Architektur noch nicht stabil.
Bei Linux-Distributionen wäre die Athlon-64-Unterstützung theoretisch kein Problem, da der Kernel diese Plattform schon lange kennt. In der Theorie braucht man nur einen 64-Bit-Kernel und den passenden Compiler zum Bauen der Programme. Suse reagierte am schnellsten und bot als erster Distributor Linux für AMD-64-Prozessoren an. Red Hat zog kurze Zeit später nach.
Natürlich müssen sich auch die Debian-Entwickler früher oder später damit beschäftigen, wie sie Support für den Athlon 64 in die Distribution einbeziehen. Die Überlegungen darüber begannen vor einiger Zeit, als sich auf dem Debian- Sourceforge-Pendant [alioth.debian.org] eine Entwicklergruppe formierte, die sich Debian x86-64 nannte. Schon der Name sorgte für Diskussionsstoff, denn er war vielen Entwicklern schlichtweg zu lang. Gegenwärtig scheint der gemeinhin akzeptierte Name für das Projekt AMD 64 zu sein.
Viel wichtiger als die Diskussion über den Namen ist aber die Frage, wie man die technischen Probleme löst. Mancher mag sich die Frage stellen, warum AMD 64 nicht einfach so gehandhabt wird, wie Intels 64-Bit-Serverarchitektur, nämlich mit einem völlig eigenständigen Architekturzweig. 32-Bit-Programme auf dem Itanium oder Itanium II ausführen macht nämlich wenig Sinn, da die Performance dann absolut miserabel ist. Bei AMD 64 ist das anders. Dank der eingebauten 32-Bit-Emulation lassen sich 32-Bit-Anwendungen ohne große Performanceverluste einsetzen.
Deswegen werden sich Anwender wohl in vielen Situationen wünschen, ein System auf Basis von 64-Bit-Dateien zu verwenden und trotzdem die Möglichkeit zu haben, auch 32-Bit-Programme auszuführen. Mit einer solchen Situation kann der Paketmanager »dpkg« zur Zeit aber nicht umgehen. Deswegen sind hier zuvor umfangreiche Umstrukturierungen notwendig.
Diese Probleme möchte das AMD-64-Projekt auf Alioth nun Schritt für Schritt untersuchen und lösen. Goswin von Brederlow schrieb an die [debian-devel]-Mailingliste kürzlich eine E-Mail[21], in der er eine Vorgehensweise vorschlug. Er erläutert das Problem in seiner Mail sehr ausführlich: Um auf einem System sowohl Binaries ausführen zu können, die kompatibel zu x86 sind, als auch solche, die für AMD 64 kompiliert wurden, müssen für beide Architekturen die wichtigsten Bibliotheken vorhanden sein. Eine mögliche Lösung dafür wäre es, die AMD-64-Bibliotheken in eigenen Paketen zu verteilen, die ihre Dateien in Verzeichnisse wie »/lib64« entpacken. Diese Lösung erscheint aber nur auf den ersten Blick durchsetzbar. Bei genauerem Hinsehen stellt man fest, dass für diese Methode so gut wie jedes Paket im Archiv angepasst werden müsste (um beispielsweise mit veränderten Abhängigkeiten umzugehen).
Daher schlägt Goswin von Brederlow eine andere Lösung vor: Er möchte Dpkg so modifizieren, dass das Programm zwei unterschiedliche Pakete gleichen Namens gleichzeitig installieren kann. Zusätzlich sollen Pakete, die ein spezielles Application Binary Interface (ABI) anbieten und somit Architektur-abhängig sind, um eine zusätzliche Zeile in der »control«-Datei erweitert werden.
Die Zeile für solche Pakete hieße dann »ABI: strict«. Außerdem müssten die Entwickler in der »status«-Datei von Dpkg zu jedem Paket eintragen, für welche Architektur sie es kompiliert haben. Schließlich müssten die Pakete mit den wichtigsten Bibliotheken noch ihre Dateien in »/lib64« ablegen. So wäre es möglich, dass zwei Pakete unter dem gleichen Namen auf einem System installiert sind.
Von Brederlows Vorschlag löste auf der [debian-devel]-Liste eine heftige Diskussion aus. Der Debian-Release-Manager Anthony Towns mahnte an, dass dieser Vorschlag gegen sämtliche Standards verstoße, die Debian im Laufe der Zeit gesetzt hat. Steve Langasek warf ein, dass keinerlei elementare Änderungen für ihn vor der Release von Debian GNU/Linux 3.1 alias Sarge in Frage kämen. Von Brederlow hatte angekündigt, zumindest die Änderungen an der »status«-Datei von Dpkg noch vor Sarge integrieren zu wollen.
Ob diese Vorschläge dazu führen, dass in absehbarer Zeit Debian auch die AMD-64-Architektur unterstützt, bleibt abzuwarten. Tatsache ist jedoch, dass Debian es sich kaum leisten kann, die Unterstützung für die neue Architektur noch viel länger hinauszuzögern.
Zutaten für vier bis sechs Personen: Vier Esslöffel Olivenöl, 400 g braune, in dicke Scheiben geschnittene Champignons, 120 g Pancetta oder durchwachsener Speck (gewürfelt), eine große, fein gehackte Zwiebel, zwei fein gehackte Knoblauchzehen, 350 g Arborio- oder Carnaroli-Reis, 1,2 Liter Hühnerbrühe, zwei Esslöffel frisch gehackte glatte Petersilie, Salz, Pfeffer, 80 g frisch geriebener Parmesan, ein wenig zusätzlicher Parmesan zum Bestreuen.
Zwei Esslöffel Öl in einer Pfanne stark erhitzen. Die Champignons dazu geben und zwei bis drei Minuten goldbraun und leicht knusprig anbraten. Zwischendurch umrühren, danach beiseite legen. Den Speck in die Pfanne geben und etwa zwei Minuten lang knusprig braun braten. Zwischendurch häufig umrühren. Den Speck danach zu den Pilzen legen. Das restliche Öl in einem Topf bei mittlerer Hitze erwärmen. Die Zwiebelstücke hinzufügen und zwei Minuten dünsten, bis sie weich werden. Knoblauch und Reis zugeben und zwei Minuten unter häufigem Rühren glasig dünsten.
Langsam die köchelnde Hühnerbrühe in den Reis einrühren, dann Pilze und Speck zufügen. Mit Estragon oder Petersilie, Salz und Pfeffer würzen und kurz aufkochen.
Den Backofen auf 180¡C vorheizen. Den Reis vom Herd nehmen und in eine ofenfeste Form füllen. Die Oberfläche glatt streichen. Den Deckel auflegen und etwa 20 Minuten backen, bis der Reis fast gar ist und die meiste Flüssigkeit aufgenommen hat. Den Deckel abnehmen und den Parmesan einrühren. Weitere 15 Minuten backen, bis der Reis gar, aber noch bissfest ist. Sofort servieren. Parmesan zum Bestreuen separat reichen.
Während der Reis im Ofen gart, kommt hier noch der übliche Aufruf: Wer ein Tool schätzt oder entwickelt hat und es an dieser Stelle vorgestellt sehen möchte, schickt eine E-Mail an[22]. Jeder Hinweis ist willkommen. (mwe)
| 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. |