AK's weblog

Poah, wenn ich sowas lese, dann muss ich kotzen:

Stallman sagte, auch der Kernel enthalte nicht freie Bestandteile. Torvalds persönlich bezeichnete der GNU-Gründer als "einen Studenten, der einen Kernel geschrieben hat".Stallman wirft Torvalds vor, nicht für freie Software einzustehen sondern vielmehr den Spaß am Programmieren im Vordergrund zu sehen.

Ich sage nur: was RMS mittlerweile so von sich gibt, ist völlig überbewertet. Wenn RMS Linus Torvalds vorwirft, den Spaß an der Programmierung hochzustellen, dann ist das im Grunde genommen der Vorwurf, dass Linus Torvalds ein Hacker (im ursprünglichen Sinne) ist.

Meiner Meinung nach zeigt das doch wieder einmal, wie verbohrt RMS mittlerweile "seine" Ideologie bewirbt. Auch nion meint, dass RMS nur noch zu seinesgleichen predigt. Und dann noch sowas:

Vor allem kommt es laut Stallman darauf an, dass Schulen "allein freie Software unterrichten und einsetzen". Damit könnten sie zum einen Geld sparen. Frei heiße zwar nicht unbedingt kostenlos. Aber gerade für Ausbildungsstätten sei die Freiheit wichtig, "Programme weiter zu verbreiten".

Ich sage: man darf Fundamentalisten wie RMS nicht die Deutungshoheit über den Freiheitsbegriff kampflos überlassen.

Der Richtungsstreit zum Freiheitsbegriff im Kontext Software führt ja im wesentlichen in zwei Richtungen, und zwar einerseits die individuelle Freiheit, und andererseits die kollektive Freiheit. Während GNU-Fundis wie RMS ausschließlich kollektive Freiheit fordern, und dabei individuelle Freiheiten ziemlich zugrunde richten, ist die Gegenbewegung um keinen Deut besser, nämlich die BSD-Fundis, die es zwar OK finden, dass ihre Arbeit von kommerziellen Firmen en masse gerippt wird, aber sich daran stößt, wenn sich BSD-Sourcecode in GPL-lizenzierter Software wiederfindet: individuelle Freiheit über alles, aber kollektive Freiheit wird aktiv bekämpft. Ein dringend nötiger Ausgleich zwischen den beiden fundamentalistischen Position ist dringendst notwendig, aber leider nicht in Sicht. Klar ist aber, dass diese Art von Fundamentalismus in einem Themenkomplex wie Softwarelizenzierung mittel- bis langfristig äußerst schädlich ist.

Und zu guter Letzt möchte ich noch betonen: zur wahren Freiheit gehört auch dazu, die Freiheit zu haben, zwischen Freier Software/Open Source und proprietärer Software wählen zu können.

Nachdem das Ranten über GNU so schön ist, hier noch ein kleiner Nachschlag. Wieder fast jeder, der schon mal Software unter Linux selbst compiled hat, weiß, muss man vor dem Übersetzen meist noch ./configure aufrufen, welches dann ein paar systemspezifische Konfigurationsinformationen sammelt und ein Makefile generiert.

Zum Erstellen dieses configure-Skripts gibt es ein Tool namens autoconf. Dieses generiert aus einem configure.in bzw. configure.ac File das configure-Skript. Das configure.ac wiederum kann man sich aus dem bestehenden Sourcetree generieren lassen und dann händisch anpassen. Das Makefile, das man dann zum Compilieren benötigt, wird übrigens vom configure-Skript i.A. aus dem Makefile.in erzeugt, wobei hierbei Platzhalter durch die entsprechenden ermittelten bzw. gesetzten Werte (./configure lässt sich ja relativ gut durch Commandline-Switches steuern) ersetzt werde. Makefile.in's schreiben sich ähnlich wie Makefiles. Und weil das Schreiben von Makefile.in's sooo schwer ist, gibt es auch gleich noch ein weiteres Tool, automake, mit dem man sich das Makefile.in aus einem Makefile.am erzeugen lassen kann.

Durch einen jahrelangen Reifungsprozess sind autoconf und automake schon so gut integriert, dass sie fast eine Symbiose bilden. Diese Symbiose ist so gut, dass es vom GNU-Projekt keine Dokumentation gibt, wie man autoconf ohne automake verwendet. Das heisst, jeder enthusiastische Programmierer, der auf die Vorteile von autoconf zurückgreifen will, und sich das selbst anhand der Doku aneignet, wird auch automake verwenden. Am Ende der Integration von autoconf und automake ins eigene Sourcepaket bleiben dann ein ca. 200 kB grosses configure-Skript und ein 50 kB grosses Makefile.in übrig, sowie noch 50 - 100 kB andere Dateien wie z.B. diverse Helper-Shellskripte. Das ist natürlich sehr toll, wenn das eigene, selbstgeschriebene Tool aus vielleicht 15 kB Sourcen besteht.

Aber trotzdem gibt es Mittel und Wege, um ohne automake auszukommen, was die Gesamtgröße der generierten Dateien um einiges herabsetzt. Wie das im Detail geht, wäre jetzt zuviel des guten, jedoch nur ein kurzer Tipp: wer Makefiles schreiben kann, und /usr/local durch _prefix und gcc durch _CC ersetzen kann, der kann Makefile.in's schreiben, und braucht kein automake.

Hier noch mal die Erklärung: autoconf sorgt für das configure-Skript, das Systemkonfiguration sammelt und das Makefile erzeugt, und automake sorgt für das Makefile.in-Template, sodass der Programmierer sich um weniger Makefile-Details kümmern muss (muhahahaha). Eigentlich eine gute Trennung. Theoretisch. Wie sieht es praktisch aus? Nun, das Dokumentationsproblem habe ich schon erwähnt, aber etwas wesentlich perfideres hab ich heute wieder mal entdecken müssen: autoconf ist ja m4-basiert, und bringt einige fertige m4-Makros zum Testen auf bestimmte Konfigurationen mit. Allerdings gibt es noch wesentlich mehr Makros. Zum Beispiel bei automake. Bei automake sind wirklich jede Menge m4-Makros dabei, die wesentlich mehr können, und die einfach eingebunden werden können. Welche Möglichkeiten hat Joe Average Programmer hier? Entweder er kopiert die m4-Makros aus dem automake-Paket in seinen eigenen Sourcetree, oder aber integriert einfach automake in sein eigenes Buildsystem.

Warum GNU diese Makros nicht zu autoconf dazugepackt hat? Nun, das weiß nur Gott ("Gott? welcher Gott?"). Auf jeden Fall haben diese Beobachtungen bei mir den schalen Nachgeschmack hinterlassen, GNU will möglichst viele Programmierer mit autoconf und automake "zwangsbeglücken". Mittlerweile ist es ja fast nicht mehr möglich, ohne das Konfigurieren des Sourcetrees auf Systemeigenheiten noch portable Programme zu schreiben, die "out of the box" unter einem Allerwelts-Unix wie Linux, *BSD und Solaris compilieren und linken. GNU hat sicherlich seines dazu beigetragen, und bringt gleichzeitig ein "Wundermittel" mit, das halt zu 300 kB Scheisse in jedem Sourcepaket führt. Leider sind autoconf und automake als de-facto-Standard etabliert, andere Buildsysteme dagegen finden kaum Beachtung oder Einsatz.

Manchmal könnte man die GNU-Leute so richtig schön verprügeln. Weil die linke Hand nicht weiß, was die rechte tut. Konkret ärgere ich mich derzeit wegen iconv(), der SuSv3-standardisierten Funktion zum Konvertieren zwischen verschiedenen Zeichensätzen, bzw. der Signatur ebendieser.

SuSv3 schreibt vor:

die glibc hat:
die dietlibc hat:
GNU libiconv hat (wenn das System keine iconv-Implementierung hat):
und NetBSD hat diesen Bloedsinn gleich nachgemacht:
Wer immer auf diese hirnrissige Idee gekommen ist, gehört einmal ordentlich verprügelt. Standards aren't there for no reason. Und falls sich jemand denkt, "ach, das macht doch nichts, char ** ist sowieso auf const char ** zuweisungskompatibel", der hat sich geschnitten. Noch dazu bin ich völlig unmotiviert, für kaputte Systeme Workarounds zu basteln. Oder anders ausgedrückt: glibc und dietlibc gut, GNU libiconv und *BSD böse.

Soweit ich übrigens rausfinden konnte, liefern FreeBSD und OpenBSD keine eigene iconv-Implementierung mit, sondern es gibt lediglich die GNU libiconv in den Ports. Was ich übrigens nicht verstehen kann, eine rudimentäre iconv-Implementierung, die UTF-8, UTF-16[bl]e, ISO-8859-x, und die gängigsten Codepages unterstützt, ist in einer Woche gebastelt. Nur halt nicht von mir.

Update: ich hab den Grund für die Diskrepanzen gefunden. Und zwar ist das const in der SuSv2-Definition drinnen, in der SuSv3-Definition jedoch nicht mehr. *gna*