Weniger ist mehr: IceWM

KDE ist die fortschrittlichste Desktop-Umgebung, die es für Unix-artige Betriebssysteme gibt. Gerade eben wurde die Version 3.3 veröffentlicht, sogar eine Umsetzung für Windows ist verfügbar. Mit anderen Worten: Höchste Zeit, umzusteigen - auf IceWM. Es ist nicht so, dass ich mit dem KDE generell unzufrieden wäre, aber die Zeit zwischen dem Login und der tatsächlichen Verfügbarkeit des Desktops nervt. Bei IceWM sind das vielleicht 2 Sekunden, das ist erträglich; beim KDE eher schon 10-15, das ist für meinen Geschmack zuviel. Zwar braucht KMail (das ich vorerst weiter verwende) dann entsprechend länger zum Starten, aber das nervt schon viel weniger, weil ich während dessen ja schon was anderes machen kann. Abgesehen davon kommt es meiner Denk- und Arbeitsweise entgegen, dass man beim IceWM Menüs und Toolbar über leicht zu findende, leicht zu ändernde Konfigurationsdateien anpasst, statt sich durch Menüs und noch mehr Menüs und Kontrollzentrum und Kontextmenüs usw. durchzuklicken. Hmmm... wenn ich nochmal auf Windows zurücksteigen sollte, dann werde ich mal schauen, wie viel man mit regedit einstellen kann, um sich Menüs und noch mehr Menüs und Kontrollzentrum und Kontextmenüs usw. zu ersparen. BTW: Die Start-Zeiten des KDE sind nervig... aber die NT4- und W2K-Kisten bei uns sind noch viel schlimmer, da vergehen Minuten zwischen Anmeldung und Verfügbarkeit.

Mono und dotgnu, Teil 2

Keine Ahnung warum, aber als ich heute nochmals einen Versuch mit Mono machte, erschien doch ein Teil der Oberfläche und sogar ein Eingabefeld. Wenn das in den nächsten Tagen so weitergeht, habe ich spätestens am Dienstag meine erste Maske vollständig auf dem Bildschirm. Erfreulich ist jedenfalls, dass die Kommunikation mit dem Server im Hintergrund offensichtlich geklappt hat.
Mir ist noch schleierhaft, warum es eigentlich die zwei Projekte Mono und dotGnu gibt, die doch letztlich das gleiche erreichen wollen. Im allgemeinen finde ich Konkurrenz ja gut und schön, wenn dadurch verschiedene Konzepte realisiert werden und der Wettbewerbsdruck die Leute zu immer neuen innovativen Ideen anregt. Also nichts gegen KDE vs. Gnome oder BSD vs. Linux. Aber was bringt es, zwei Projekte zu machen, die beide die gleiche Spezifikation implementieren?
Immerhin hat die Sache ein gutes: Da (sowohl bei mono als auch bei dotgnu) die Compiler funktionieren und auch die von mir benötigten Bibliotheken da sind, kann ich die Programme unter Linux schreiben und übersetzen, sodass ich erst mal alle Fehler rauskriege, die der Compiler findet. Erst zum Testen muss ich mich an die Windows-Kiste setzen. Vielleicht finde ich ja noch raus, warum System.Windows.Forms von dotgnu bei meinem Programm nicht funzt - die mitgelieferten Beispiele funktionieren nämlich gut - und wie man diesen Teil von dotgnu mit der System.Xml-Bibliothek von Mono kombinieren kann (die System.xml-Implementierung von Mono ist vollständiger als die von dotgnu).
Noch zwei "eh klar, ich hätte es mir eh' denken können":
1. Ein für .net compact framework compiliertes Programm funktioniert nicht unter normalen .net (also auf einem Windows-PC). Wie tröstlich ;-)
2. Wenn ein C#-Programm unter Mono mit einer NullPointer-Exception abbricht und unter dotgnu auch, dann sollte man die Möglichkeit in Betracht ziehen, dass es _wirklich_ einen Fehler enthält, der zu einer Nullpointer Exception führt.

Wieviele Profile hätten's denn gerne?

Kurzer Stromausfall. Für meinen Notebook kein Problem, so schlecht ist der Akku noch nicht. Der PC, den ich als X-Terminal missbrauche, ist natürlich weg. Nach dem Neustart und der Neuanmeldung will ich Firefox (Webbrowser) und Thunderbird (Mail-Client) wieder starten - geht natürlich nicht, die Default-Profile sind ja angeblich noch in Verwendung. Lässt sich leicht beheben, man muss nur im zweiten bzw. dritten Unterverzeichnis unterhalb eines versteckten Verzeichnisses eine Datei mit dem Namen "lock" löschen.
Für mich kein Problem, aber ein Normalbenutzer? Der würde wahrscheinlich bei dieser Gelegenheit ein neues Profil anlegen. Und beim nächsten Mal noch eines. Ein Glück, dass hierzulande der Strom nur selten ausfällt.

mono, dotgnu und System.Windows.Forms

Seit einiger Zeit arbeiten einige meiner Kollegen daran, Programme für mobile Handterminals, die unter dem Betriebssystem WindowsCE.net laufen, zu schreiben. Ab und zu helfe ich auch ein bisschen mit, C# ist ja eine ganz nette Sprache und der Umstieg für Leute mit Java-Kenntnissen ganz leicht.
Für mich als Linuxer wäre es wünschenswert, diese C#-Programme auch unter Linux testen zu können.
Und da es gleich zwei Projekte gibt, die .net für Linux und andere Betriebssysteme umsetzen wollen,
habe ich mir die mal angeschaut. Die Ergebnisse meiner Tests waren aber ernüchternd. Insbesondere die Umsetzung der System.Windows.Forms-Bibliothek haut bei unserem Programm noch so gut wie überhaupt nicht hin, und wir dabei machen wir nur ganz simple Masken mit ein paar Labels, Eingabefeldern und Buttons. Wobei ich im Fall von Mono sagen muss, dass ich die SuSE9.0-RPM-Pakete auf meine Mandrake 9.2-Installation gnadenlos draufgeknallt habe, das dürfte bei der Mono-Implementierung von System.Windows.Forms, die auf Wine basiert, keine so tolle Idee sein. Dotgnu habe ich hingegen frisch aus den Sourcen compiliert. Langer Rede kurzer Sinn, bei Mono werden die Fenster mit 100% Transparenz dargestellt (und auch sonst tut sich wenig); bei dotgnu werden nur rechteckige Flächen ohne Beschriftung gerendert.

Meine Hoffnungen, dass es die freien Nachbauten in nächster Zeit schaffen, dass man beliebige, für Windows geschriebene .net-Programme unter Linux ausführen kann und damit vergleichbar plattformunabhängig ist wie z.B. mit Java und Swing, habe ich damit wieder hinten angestellt. Ich denke, man wird letztlich auf das Nievau von Wine kommen. Problemlose Plattformunabhängigkeit bleibt den dafür vorgesehenen Toolkits (Java, QT, GTK, WX etc.) vorbehalten.

die CD brennt!

Mein Lieblingsneffe will eine Audio-CD kopiert haben. Als ehrlicher Mensch weiss ich gar nicht, wie man das macht... K3B? Habe ich nicht eingerichtet, würde mich wundern wenn das aus dem Stand funzt. Naja, für solche Fälle habe ich mir die Windows98-Partition aufgehoben, da gibt's "Nero", ausserdem will ich eh' mal wieder schauen, ob Windows noch geht. Nun ja, Windows bootet noch (welch' Wunder), aber die Maus tut nix mehr. Liegt's daran, dass Windows eine neue Hardware (USB-Hub) gefunden hat, für die es jetzt einen extra Treiber braucht? Oder daran, dass ich eine neue Maus habe? Manche Rätsel werden wohl für immer ungelöst bleiben.
Also zurück zu Linux und zur Kommandozeile. Das Lesen mittels cdparanoida habe ich schon in meinem CD-zu-mp3-Script drinnen, fehlt also noch das Brennen mittels cdrecord.
Im Jahr 2001 schrieb die Zeitschrift LinuxUser: "Solche Buffer Underruns, die zur Zerstörung des Rohlings führen, sind aber unter Linux recht unwahrscheinlich, da das Betriebssystem über ein gutes Multitasking verfügt.".
http://www.linux-user.de/ausgabe/2001/05/015-cdrecord/cdrecord.html
Drei Jahre und zwei Rohlinge später habe ich gelernt, dass man nicht alles glauben soll, was so behauptet wird.

cl penibler als gcc?

In meinem Job schreibe ich unter anderem C-Programme, die sowohl unter Unix-artigen Betriebssystemen als auch unter Windows funktionieren. Das liegt daran, dass ein Teil unserer Kunden Windows-Server verwendet und andere wiederum AIX, Linux, Solaris usw.
Diese Programme schreibe und teste ich natürlich unter Linux und spiele sie dann bei Bedarf auf meine Windows-Kiste, um sie dort für Windows zu compilieren und meinen Kollegen zum Testen zu geben.
Heute war wieder so ein Fall, lässt sich unter Linux ohne Fehlermeldung compilieren; der CL (das ist der Kommandozeilen-Compiler des VisualStudio, ich verwende natürlich die Kommandozeilentools CL und NMAKE) lieferte hingegen eine Warnung - und hatte sogar recht. Eine Funktion, die als "int sonstwas()" deklariert ist, bei der aber das return-Statement fehlt. (Hatte wenig Auswirkungen, ist mir deshalb noch gar nicht aufgefallen). Bei anderer Gelegenheit bin ich heute draufgekommen, dass der Oracle SQL*C-Präprozessor gar nicht so streng ist, wie ich bisher angenommen habe: Wenn man beim Fetch mehr Hostvariablen angibt, als das zugehörige Select-Statement Werte liefert, wird das weder beim Compilieren noch zur Laufzeit als Fehler angemeckert. Na sowas. Das sind dann die Fehler, die man lange sucht (ein Select-Statement, das 28 Elemente liefern soll, aber nur 27 liefert, weil das 26. Element in der Select-Liste fehlt...)

Auftrag ausgeführt.

So, mit Nummer 124 sind alle Fotos eingescannt. Eigentlich schade, dass ich erst beim 93. Foto draufgekommen bin, wofür der "Lamda-Korrektur"-Regler da ist. Naja, es wird doch hoffentlich auch unter Windows Grafikprogramme geben, mit dem die Empfängerin der Bilder das für die ersten 92 (relativ dunklen) Bilder nachziehen kann ;-)

Ich habe nicht mitgezählt, aber ca. alle 15 Scanvorgänge musste ich dem Scanner durch "Stecker raus-Stecker rein" einen Reset verpassen. Wäre mir das unter Windows98 auch passiert? Wenn ja, wem hätte ich die Schuld gegeben? Der Hardware, dem Treiber oder dem Betriebssystem? Muss ich beim nächsten Mal glatt ausprobieren. Obwohl ich froh bin, wenn es nicht so bald ein nächstes Mal gibt, denn bei 3+ Minuten pro Scan ist das alles andere als lustig.

Der Flachbettscanner.

Manchmal wünsche ich mir, die Hardware-Unterstützung von Linux wäre noch nicht so vollständig. Zum Beispiel heute, als mir meine Nichte ein dickes Fotoalbum in die Hand drückte, mit dem Auftrag, all die Fotos einzuscannen. Nun ist es so, dass der Flachbettscanner (Canon FB620P) schon lange herumsteht und verstaubt. Früher einmal hatte ich ihn schon unter Linux zum Laufen gebracht, aber dazwischen habe ich schon längst eine neue Distro auf den Rechner geknallt, also heisst es: Von vorne einrichten. Auf dem Rechner läuft Mandrake 9.1. Also werfe ich mal das "Kontrollzentrum" an, wähle "Hardware" und siehe, da, es gibt einen eigen Punkt "Scannerdrake", mit dem man Scanner einrichten kann. Natürlich findet das System den Scanner nicht automatisch (das geht bei Parallelportscannern nicht), aber im Punkt "manuelle Auwahl" findet sich mein Gerät. Also auswählen, "OK" und schon verspricht das Programm, dass man ab jetzt mit "Xsane" scannen könnte. Denkste. Xsane findet den Scanner nicht. Vom letzten Mal habe ich noch in Erinnerung, dass man bei meinem Gerät den saned (Sane-Dämon) braucht, der mit root-Rechten auf den Parallelport zugreifen darf, und xsane über einen Netzwerkport mit dem Dämon kommuniziert. Also mal sehen, was der Scannerdrake so eingerichtet hat... Sieht ganz gut aus, nur blöderweise ist /dev/parport0 (die Gerätedatei für den Parallelport) nicht vorhanden. 30 Minuten Google, einmal Knoppix-Booten und einmal "mknod parport0 c 99 0" (hätte das ein Otto Normaluser auch erraten?) später ist die Gerätedatei da, und siehe da, wundersamerweise funzt auch xsane (halbwegs). Hat zwar noch Macken, aber es geht. Ab und zu mal den Scanner neu starten (Stecker raus-rein) und notfalls den Rechner rebooten... Und jetzt scanne ich gerade Bild 31 von 150.

Einführung.

Eifrige Leser der Futurezone oder von golem.de wissen natürlich, dass ich privat wie beruflich auf Linux setze. Mittlerweile sind meine Rechner schon so lange praktisch Windows-frei, dass ich kaum noch relevante Kritik an Windows anbringen kann (wen interessieren heute noch meine Probleme mit NT4?). Wie das Leben mit Linux statt Windows so verläuft, auf welche Probleme man stösst und welche Überraschungen man erlebt, soll das Thema dieses Blogs sein. Wobei ich gleich anmerken möchte, dass ich beruflich noch ab und zu mit Windows zu tun habe; wie es mir dabei ergeht, davon werde ich bei Gelegenheit auch berichten.

Vorwort

Jeder normale Webbürger führt heutzutage ein Blog, da kann ich mich natürlich nicht ausschliessen. Ursprünglich wollte ich mein Blog in der ORF-Visitenkarte führen, aber das ist doch zu beschränkt und unleserlich. Also steige ich auf Blogger um...