Captains Log

Pidgin, das umbenannte Gaim, gehört ganz offenbar nicht dazu. Unter Solaris läßt es sich irgendwie mal so garnicht starten. Weder mit einem gcc, noch mit dem Sun Compiler kommt was lauffähiges dabei heraus:

Pidgin has segfaulted and attempted to dump a core file.
This is a bug in the software and has happened through
no fault of your own.

If you can reproduce the crash, please notify the developers
by reporting a bug at:
http://developer.pidgin.im/newticket/

Please make sure to specify what you were doing at the time
and post the backtrace from the core file. If you do not know
how to get the backtrace, please read the instructions at
http://developer.pidgin.im/wiki/GetABacktrace

If you need further assistance, please IM either SeanEgn or
LSchiere (via AIM). Contact information for Sean and Luke
on other protocols is at
http://developer.pidgin.im/wiki/DeveloperPages

Super.

Und vorher, beim kompilieren, das hier:

1. Versuch: gcc

cc1: error: invalid option `t'

Was ist denn das? Hm, na mal schauen. Ich finde einen Thread, der Antwort bietet:

I don't know where the -mt is coming from. There is a -mt option for
the ia64 targeted compiler, but you seem to be using i386-solaris.

Nein, ich bin nicht auf i386, ich bin auf Sparc. Ja, es gibt Prozessoren aus nicht Wintel-kompatiblen Architekturen. Ey boah ey!

Also alle Makefiles editiert, -mt rausgeworfen. Führt aber zu obigem Absturz.

2. Versuch: SUNWspro

Beim Kompilieren erhalte ich die folgenden Fehlermeldungen:


../../../libtool: line 96: gcc: command not found
../../../libtool: line 97: gcc: command not found
sed: -e expression #1, char 0: no previous regular expression
sed: -e expression #1, char 0: no previous regular expression
sed: -e expression #1, char 0: no previous regular expression
sed: -e expression #1, char 0: no previous regular expression


Schon recht, ich habe auch keinen gcc definiert, sondern will den cc von Sun verwenden. Was steht denn in libtool drin?


90 # A language-specific compiler.
91 CC="cc"
92
93 # Is the compiler the GNU C compiler?
94 with_gcc=
95
96 gcc_dir=`gcc -print-file-name=. | sed 's,/\.$,,'`
97 gcc_ver=`gcc -dumpversion`


Na sowas... Sieht so aus, als hätte libtool rausgefunden, dass man keinen gcc verwendet. Nur um zwei Zeilen später sich dann Details vom nicht vorhandenen Compiler holen zu wollen. Das kann echt nicht wahr sein. *kopfschüttel*
Ich gehe jetzt einen ordentlichen IM suchen...

Das war schon eine lange Zeit, die ich jetzt mit Linux gearbeitet habe, es müssen so über zehn Jahre sein. Als ich damit anfing war noch keine Rede von, sich ganze CD- oder DVD-Images aus dem Netz zu laden und zu brennen, damals gab es noch Distributionen auf Diskette, wenn auch nicht unbedingt aus dem Linux-Lager.
SuSE kam noch in einer schlichten Mehrfach CD-Box daher, "Linux aktuell" genannt, und YaST war noch ein einfaches Admintool, mit dem die grundlegenden Dinge eingestellt wurden.
WindowManager konnte man noch von grundauf konfigurieren, ich benutzte damals CTWM und hatte eine über 35KB große ctwmrc. Da mehrere User auf meinem System arbeiten konnten, hieß sie sinnigerweise system.ctwmrc, so dass auch alle was davon hatten.
Nach einem Update kam YaST dann auf die Idee, diese Datei selbst zu überzeugen, mein erstes größeres Desaster, denn natürlich hatte ich kein aktuelles Backup gehabt.
Kurz Zeit später wechselte ich auf Debian, SuSE wurde einfach zu fett, machte alles alleine, worauf ich keinen Nerv hatte.
Irgendwann wechselte ich von PCs auf Macs, und fing auch dort mit Debian Linux an. War anfangs noch alles in Ordnung, gab es dann später, und die Situation besteht bis heute, eine Uneinigkeit zwischen den x86- und PPC-Entwicklern.
Der Linux-Kernel ist so dermaßen fett und unflexibel, das Änderungen im PPC-Teil den x86-Baum beeinflußen können. Das Ende vom Lied war, das die PPC-Architektur teilweise über ganze Kernel-Releases hinweg nicht ohne weiteres nutzbar war, weil Patches und Updates nicht in den Hauptbaum integriert wurden.
Das machte mich schon arg unzufrieden... Und dann kam Linus in der Diskussion um die Art und Weise, wie Kernel und Treiber entwickelt werden und meinte, die Linux-Treiber würden auf den Level "Gut genug" gehoben.
Was bitteschön heißt denn das? Gut genug bedeutet, dass ein Treiber in 80% der Fälle funktioniert, bei einigen weiteren Prozenten muß irgendwie gepatcht und gehackt werden, weil es ansonsten zu vielfältigen Problemen kommen kann. Und in allen anderen Kombinationen funktioniert ein Treiber nicht.
Danke Linus, Du bist mein Held! Es ist nicht ehrenvoll für Kernel-Entwickler, immer mehr Treiber zu integrieren, wenn sich Linux-User, auch oder vor allem die im Business-Umfeld, nicht drauf verlassen können, dass ein Treiber für die von ihnen gekaufte Hardware auch läuft.
Bei BSD ist das anders: Hier werden Treiber eher ruhen gelassen oder nicht eingebaut, solange klar ist, dass irgendwas nicht funktioniert. Wenn ich ein Stück Hardware brauche, das eine bestimmte Funktionalität erfüllt (Bluetooth-Stick, WLAN und Co.) schaue ich einfach in die Kompatibilitätsliste, und kaufe mir dann ein Modul oder eine Karte, die einen unterstützten Chipsatz enthält.
Einbauen, Kernelmodul laden, fertig.
Unter Linux? Kaufen, Treiber laden, und beten. Und nicht genug gibt es genug Konfigurationen, in denen Hardware nicht funktioniert, wenn z.B. Karte A nicht mit B zusammen arbeiten. Es gibt genug schlechte "Designed for Windows Schlagmichtot"-Hardware da draußen, bei denen die mitglieferten Treiber Unzulänglichkeiten der Hardware ausbügeln müssen. Sowas kann man unterstützen, muß man aber nicht, vor allem wenn sowieso nicht sichergestellt ist, dass es funktioniert.
Jetzt, wo ich durch meine Abteilung einen tieferen Einblick in klassische Unixe bekommen haben, attestiere ich Linux auch gerne eine Konzeptlosigkeit: Es wird programmiert, ohne viel vorher drüber nachzudenken, Hauptsache ein Problem ist behoben oder eine Funktionalität ist implementiert. Ob dabei neue Kernelfunktionen eingeführt werden, die vielleicht unnötig sind, weil man vielleicht vorhandene hätte ausbauen können, spielt dabei keine Rolle, und auch nicht der Gedanke, ob man sich in der Zukunft dadurch etwas verkompliziert.
Eigentlich ist es schon Schizophren: Auf der einen Seite freuen sich viele Leute, das Linux auf allen möglichen Geräten läuft, angefangen vom kleinen PDA bis hin zum großeren Server, aber umgekehrt bekommt dieses so hoch gelobte Feature nicht die Aufmerksamkeit, die es braucht. Ganz im Gegenteil überlegen doch einige Kernelentwickler, die Entwicklung von x86 zu forcieren und die Kompatibilität mit den anderen Plattformen zu brechen.

Auch auf Anwendungsebene gibt es viel Gemurkse und gegenseitige Beeinflußung, ich erinnere mich mit Grausen an die Zeit, wo gpm nicht laufen durfte, wenn man X hochfuhr. BSD kommt mit einem default moused, der auch von X genutzt werden. Herzlichen Glückwunsch...

Wenn man sich im Gegensatz dazu mal BSD anschaut, so sieht man hier schnell andere Konzepte, die sich wie ein roter Faden durchs ganze System ziehen, und die Arbeit zur Freude machen, wie z.B. die generischen Compilereinstellungen in /etc/make.conf, die Daemon-Konfiguration in /etc/rc.conf und dem Bootloader kann ich in seiner Konfiguration mitteilen, welche Kernelmodule ich gerne automatisch geladen hätte.
Um PCMCIA/Cardbus-Karten oder USB-Devices wie Bluetooth-Sticks zu konfigurieren, brauche ich kein großartiges Cold- und Hotplugging-Gedöhnse, wie das unter Linux gelöst wurde, und ich kann, man höre und staune, meine Anwendungen unabhängig vom Basissystem updaten, oder auch umgekehrt.
Ja, die ganzen Sourcen, die das Basissystem ausmachen liegen zentral unter /usr/src und können dort mit einem make buildworld neu übersetzt werden, z.B. nach einer Aktualisierung via CVS Checkout.
Technisch sind die BSDs auch allesamt ausgereifter, es gibt z.B. eine neue Funktionalität namens "GJournaling" im FreeBSD, die es praktisch erlaubt, ein Journal auf jedes beliebige Filesystem zu schreiben, und wenn es sich dabei um eine 3,5" DOS-Diskette handelt.

Nachdem FreeBSD 6.1 seit einigen Wochen stabil auf meinem Laptop läuft, habe ich vorgestern mal ausprobiert, was mein Server davon hält, und selbst die IT-RAID Karte, an der meine 200GB-Platte hängt, wurde anstandslos erkannt (unter Linux mußte ich dafür einen eigenen Kernel bauen).
Es gibt für mich keinen Grund mehr bei Linux zu bleiben, Donnerstag werden die Daten vom Server ausgelagert, dann wird neu installiert.
In meinem Urlaub kommt dann eine OpenBSD-betriebene Firewall ins Haus.

Ein Jahr lang hat die Produktion des animierten Kurzfilms An Elephant Dream gedauert. Jetzt ist er fertig und kann unter orange.blender.org in den Formaten AVI (MPEG4) und Quicktime (H.264) heruntergeladen mit werden. Unterschiedliche Auflösungen stehen auch zur Verfügung, inkl. einer HDTV-konformen.
Das besondere an dem Film: Er wurde mit dem Open Source-Tool Blender erstellt, unter eine Creative Commons-Lizenz gestellt, und darf deshalb frei kopiert werden. Außerdem haben die Beteiligten alle Production Files freigegeben, d.h. man kann sich alle verwendeten Modells, Texturen und Scenes herunterladen. Auch der Soundtrack kann, inkl. eines Covers, frei von der Homepage geladen werden.
Es gibt auch eine Doppel DVD-Box, auf der neben dem Film auch alle anderen Features und Files enthalten sind.

Ich konnte mir den Film gerade nur ausschnittsweise ansehen, aber das, was ich gesehen habe, hat mich überzeugt. Er führt in eine surreale, technisierte Welt, in der Maschinen ein Eigenleben führen, und das von der Stimmung und einigen Anspielungen an Matrix erinnert.

Mein Tipp: Herunterladen, ansehen, und die DVD kaufen. :-)