Software

Seit gestern läuft Windows 7 (RC) auf meinem Notebook – statt XP mit OpenSolaris im Multiboot. Um meinen gelegentlichen Bedarf für eine Unix-artige Umgebung zu decken, ist Debian in einer Virtualbox installiert.

Windows Live Mail mag die coreboot Mailingliste, mit ihren OpenPGP-Mail-Schreibern immer noch nicht, aber Windows Live Writer scheint gut zu funktionieren – siehe diesen Eintrag.

Insgesamt macht das System einen sehr runden Eindruck. Wenn ich jetzt noch schaffe, eine coreboot Toolchain mit MinGW aufzubauen (SUA macht traditionell Probleme, Cygwin ist lahm, Virtualbox sollte nicht für die tägliche Arbeit notwendig sein), bleibe ich wohl bei dem System. Mal schauen, was die Lizenzen am Ende wirklich kosten.

Zum Hack des Tages: Der Nvidia-Treiber hat die unangenehme Eigenschaft, bei Aero den “Secure Desktop” vom UAC mit ~5 Sekunden Verzögerung darzustellen. Dazwischen ist das Bild schwarz und “hängt”. Das kann behoben werden, indem man die Skalierungsfunktion für das Display deaktiviert. Solange der Chipsatz selbst skaliert, ist diese Funktion eh überflüssig.

… und wenn ich mir den HTML Code so ansehe, den Live Writer hier generiert, bin ich sehr angenehm überrascht.

Für ein Projekt muss ich eine MySQL Datenbank von der Shell aus betanken. Ich könnte natürlich den Umweg über PHP gehen, aber ich hatte eigentlich vor, PHP ausschließlich für die Webseitenelemente des Projekts zu nutzen.

Das ist ja an sich auch kein Problem, da es ein CLI Werkzeug gibt. Einzig, dass ich unstrukturierte Daten "von außen" einbauen muss, bereitete mir etwas Kopfzerbrechen.

Die Lösung war dann aber doch einfach genug:

printf "x'"; od -An -tx1 -v $1 |tr -d ' \t\n'; printf "'"

Wobei $1 der Name der Datei ist, die abgelegt werden soll.

Ohne Gewährleistung auf Funktionalität oder irgendwas, aber nachdem mir heute jemand gesagt hat, dass er einfach strdupa mit strdup #defined, dachte ich mir, suche ich lieber mal fix nach einer leak-freien Lösung.

#define strdupa(x) (char*)strcpy((char*)alloca(strlen((const char*)x)+1),(const char*)x)

Es benötigt natürlich die entsprechenden Header, lt. Dragonfly BSD sind das stdlib.h und string.h

Lizenz: ISC/MIT/X11/libpng, Copyright (C) 2009 Patrick Georgi <patrick.georgi@coresystems.de> 

“The idea with Perl 6 is you start with a standard language and you can mutate it. As long as you follow that refinement process there isn't the problem of ambiguity. There is the problem of multiple dialects, but that will always be a problem.”

(Larry Wall in der Computerworld Australia)

Klingt wie Forth (oder Rebol)...

Ich bin gerade dabei, meinen Server neu zu installieren (auf dem unter anderem dieses Blog läuft). Das ganze geschieht auf einer zweiten Festplatte, die dann, sobald alles übertragen ist, die aktuelle Systemfestplatte ersetzt. Die aktuelle Festplatte wird dann die Backup/Mirror-Platte.

Dabei bin ich auf ein Problem gestoßen: Die brandneue Solaris 10u6 DVD booted nicht in meinem Installationssystem. Auf dem Laptop und in Virtual PC komme ich problemlos zum GRUB-Menü, aber auf diesem System bekomme ich lediglich den freundlichen Hinweis, dass das Medium nicht bootfähig sei.

Das Problem gab es schon einige Male mit OpenSolaris, und es liegt daran, dass der Eltorito-Standard, der bootfähige CDs auf x86 beschreibt, unterschiedlich implementiert wird. Wenn der Bootblock eine bestimmte Grenze auf dem Medium überschreitet, kommen manche BIOSse nicht mehr mit - zum Beispiel das in meinem Installationssystem.

Meine Lösung sah wie folgt aus:

• Alte Solaris DVD booten (im Prinzip tuts jede Boot-CD auf GRUB-Basis, die ihren Bootblock am richtigen Fleck hat)
• Im GRUB-Menü abbrechen und zur Shell gehen (<Esc>)
• Solaris 10u6 DVD einlegen
• configfile (cd)/boot/grub/menu.lst eingeben
• Booten

> You are completely right. I don't try to mean that it is a sort of DRM by 
> itself. My concern is rather about making it too easy to implement DRM on the 
> top of GRUB. For example, if the logic is present, it is very straightforward 
> to get a key from somewhere else but an user input (e.g. by using a BIOS 
> call), and hide it from the user. I can think of many nasty ways to hide the 
> key, even if GRUB is free.

TC/DRM proponents tend to mix legitimate security features with their
handcuffware in order to confuse the public.

Quelle: (grub-devel mailing list)

So kann mans natürlich auch sehen. In diesem Falls war es eher so, dass die "TC/DRM opponents" (wie die zitierten) die Dinge vermischten. Diese Diskussion kam auf, weil jemand eine Cryptolibrary für GRUB2 zusammengestellt hat - kein DRM, nur "ich würde gern meine crypto-partition ordentlich booten können".

Naja, das ist wohl mal wieder ein Fall vom Kind und dem Badewasser..

Das ist auch nicht das erste Mal, dass solche Diskussionen geführt werden - daher auch der Titel. Das letzte Mal wollte man doch bitte den Source zu den "binary blobs" im SHA1 code - reine Datentabellen, zu denen es keinen Source gibt.

Ein Freund von mir hatte kürzlich die Partitionierung auf einer externen Festplatte ändern wollen, da diese ab Werk mit mehreren Partitionen ausgeliefert wird (warum auch immer). Leider kam das Programm auf die Idee, dass die NTFS-Partition "C:" nie und nimmer richtig sein könnte, und die dringend reparieren musste, obwohl es dort nichts zu tun hatte (warum auch immer). Naja, aus "reparieren" wurde dann "kaputt-reparieren", weil es mit Vista-NTFS nicht klar kam.

Zum Glück gibt es ein Backup, aber einige Daten waren halt doch erst kürzlich verändert worden, und da stellte sich die Frage, ob diese einzelnen Dateien nicht doch rekonstruiert werden könnten, um die Arbeit nicht noch einmal machen zu müssen.

Nach etwas suchen (Warum gibt es so viele Dateisystemreparaturprogramme, die $50 kosten? Die meisten Benutzer wollen mal eine Datei oder zwei reparieren, aber allein die Bezahlung der Programme via Paypal o.ä. ist meist aufwendiger, als die Dateien neu anzulegen) fand sich dann auch ein kostenloses Werkzeug, dass wirklich gute Arbeit geleistet hat: "PC Inspector File Recovery".

Vielen Dank an dessen Hersteller!

(Und kein Dankeschön an Symantec, die momentan das Programm vertreiben, das kein Vista-NTFS mag)

Mal wieder ein Mail mit Anhang, die OpenPGP-verschlüsselt war. Mal wieder die Fehlermeldung, dass diese Mail zu groß für IMAP und Enigmail sei ("IMAP-Nachricht ist zu gross für die Entschlüsselung bzw. Überprüfung"). Die Lösung ist dabei recht einfach: Im Menü "OpenPGP - Einstellungen", "Erweitert", "Anhänge nur herunterladen, wenn diese geöffnet werden sollen (nur bei IMAP)" - dort muss der Haken weg.

Ich rege mich ja gern über Apple und deren Produkte auf. Eins bekommt man dort aber gut hin: Integration - sowohl APIs, als auch Services.

Bei Services ist Netzwerk wohl das eindrücklichste Beispiel (wobei, das bekommt sogar Windows halbwegs hin - bloß das "Netzwerk-Betriebssystem" UNIX, von dem der ganze Kram stammt, nicht): Auf Solaris gibts "Network Autoconfig Magic" und klassische Konfiguration. Das fällt auch jedem Nutzer von OpenSolaris 2008.05 (alias "Indiana") auf, es ist eins der häufigsten genannten Probleme im #opensolaris Chat in der letzten Zeit.

Auf Linux gibt es neuerdings den "NetworkManager", eine mehrteilige Architektur mit Backenddaemon und Frontend-Tools (GUI und CLI). Soweit, so gut. Es gibt aber auch weiterhin den Direktzugriff auf, beispielweise wpa_supplicant/wpa_cli - oder Konfigurationsdateien in /etc, die unabhängig am Netzwerk rumkonfigurieren. Und die Frontends werden unabhängig vom Backend entwickelt. Es könnte also passieren, dass das GNOME-Frontend andere Funktionen bietet, als das KDE-Frontend. Und wer will, kann sich via D-BUS direkt am Backend austoben.

Bei Apple werden alle Tools am Stück entwickelt. Zwar auch mehrteilig, aber "aus einem Guss". Irgendwelche Daemons, die im Hintergrund die Arbeit leisten (auf Linux etwa wpa_supplicant) werden dabei so gut es geht mit einem Frontend im Backend versehen.

Mit APIs ist es ähnlich: die String-Klasse hat direkt Möglichkeiten, mit der URL-Klasse ("Highlevel Networking") zu interagieren. Bei vielen Linux/UNIX-APIs muss man sich dann erst einmal die Typen in das jeweilige Äquivalent der anderen Library (separat zu beziehen, separater Entwicklungszyklus, andere Handhabung von so nervigen Geschichten wie API-Stabilität, ...) konvertieren.

Linux (oder Solaris, oder *BSD), gut und schön. Apple hats begriffen: Das System basiert auf einem UNIX-artigen Unterbau, und bietet den auch an, wenn man ihn haben will (etwa im Terminal, wo er gute Dienste leistet). Desktop-Anwendungen kommen aber fast ohne UNIX aus, und müssen sich dementsprechend nicht damit rumschlagen, dass man es 1970 sinnvoll fand, Zeichenketten mit "0" abzuschließen.

Diese Freiheit, "UNIX" auch mal links liegen zu lassen, und "UNIX-Prinzipien" auch mal zu hinterfragen (ach übrigens: "Everything is a file" stimmt seit der Einführung von BSD Sockets nicht mehr - oder wie öffnet man einen Socket per fopen?), fehlt mir im Linux/UNIX-Umfeld..

Ich hab die "Gratissoftware" zum Focus Money Heft "Steuersparen" installiert und wollte mal schauen, ob es Updates gibt. Fehlanzeige: "Versionsinformation fehlt. Bitte neu installieren" oder sowas..

Scheint ein bekanntes Problem zu sein, mit "Lösung" auf der eurowin Webseite (bzw dem Google Cache, das Original wurde wohl schon wieder beseitigt). Und falls der Cache das bald auch nicht mehr hat, hier die Lösung in ebenso kurzer Form, wie auf der eurowin-Seite: Patch herunterladen und installieren.

Update: Damit auch alles funktionierte, waren einige Extraschritte notwendig: Software installieren, Patch ausführen, Software deinstallieren und neu installieren. Dann funktionierte alles. Eventuell ist der Patch auch ohne Installation ausführbar, womit man sich eine Installation und Deinstallation sparen würde... Die Installation nach Patch-Anwendung war jedenfalls arg fehlerhaft, da sie anscheinend von anderen Datenbanken ausging als denen in der Focus-Version.

Nun ist es endlich soweit: Der Monolith Linux bekommt seine Grafikkartentreiber endlich in den Kernelspace. Zwar bin ich grundsätzlich ein Freund von Microkernelstrukturen und der Verschiebung von Features in den Userspace (Filesysteme, Netzwerkprotokolle), aber die Krücke XFree86 (oder Xorg) mit ihrem eingebauten Root-Hole, um an die Grafikhardware zu kommen, ist doch etwas arg schmerzhaft.

KGI hatte das Problem schon 1998 angegangen, aber damals wollte Linus Grafiktreiber nur "über seine Leiche" (oder so) im Kernel sehen - er fürchtete wohl die Komplexität. Das Design wurde vereinfacht, aber leider weiterhin nicht integriert.

Aber nun kommt ein prinzipiell identischer Ansatz aus der Xorg-Ecke, und wird von Torvalds Brötchengeber gestützt, so dass das endlich mal was wird.

Fehlt nur noch der nächste Schritt: Entkoppelung der Userspace-Teile der Treiber vom X11-Protokoll. Aber da werden vermutlich einige andere Entwickler ihre Leiche als Hindernis anbieten wollen..

Heute habe ich zum ersten Mal einen Sektor eines in QEmu emulierten USB Mass Storage Devices in GRUB2 gelesen, Yay!

Leider hat QEmu von einigem eine andere Meinung als die USB Specs, so dass der Treiber momentan vermutlich nur in QEmu funktioniert. Aber gut, als nächstes wird der Treiber an GRUB2 angebunden, so dass man auch Dateisysteme lesen kann und überhaupt was sinnvolles mit so nem Gerät anstellen kann.

Mal schauen, vielleicht korrigiere ich den Kram in QEmu mal und versuche, ob ich diesmal einen Patch reinbekomme - es wird allemal leichter sein als bei den GNU-Projekten.

Ich frage mich ja, ob sich der Aufwand lohnt... OS X zu patchen, damit es auf Nicht-Apple Rechnern läuft, bei jedem Apple-Update befürchten müssen, dass es irgendwas kaputt macht, Treiber irgendwoher zaubern für die Hardware..

Wäre es da nicht ziemlich bald effektiver, den Kram einfach nachzubauen? Klar, das "Artwork" 1:1 übernehmen ist damit nicht möglich, und es ist auch einiger Aufwand (siehe Haiku oder ReactOS) - aber im Gegensatz zu den beiden Systemen wäre das Basissystem (Darwin) ja schon vorhanden, für den Highlevelkram könnte man bei GNUstep oder Cocotron abkupfern und sich die Sachen dann zurechtbiegen, dass sie ihren Gegenstücken in OS X entsprechen...

Und vielleicht könnte so ein Projekt dann auch eine einheitliche GUI bereitstellen (wieviele Themes hat Apple momentan im aktiven Gebrauch? Mindestens drei: Aqua, Brushed Metal und das farbneutrale Profi-Theme)

Textkritik wird eine Serie, in der ich Pro und Contra diverser Programmiersprachen (aus meiner Sicht) beleuchte. Und damit das auch nur ein wenig glaubwürdig bleibt, fange ich am besten mit meinem "dokumentierten Favoriten" an, Forth. Da es nicht bloß eine C-Variation ist, ist eine Beschreibung der Eigenschaften wohl gerechtfertigt.

Forth ist eine Sprache, die sich in den frühen 70ern entwickelt hat, und zur Klasse der "Concatenative Languages" gehört (die erst später definiert wurde). Das bedeutet, man kann den Programmfluss an (fast) jeder Stelle aufteilen in neue Funktionen ("Worte" in Forthterminologie), die man dann zusammensetzt, ohne dass sich das Verhalten ändert - eine sehr schöne Eigenschaft für Refactoring. (Zum Vergleich: "int a; a=5*rand();" einfach aufzuteilen würde scheitern: "int a;" "a=5*rand();" verliert die Deklaration im zweiten Teil, "int a; a=5" "*rand()" ist kompletter Murks)

Die Sprache ist entstanden zu einer Zeit, als es noch keine riesige Betriebssystem- und Bibliotheksinfrastruktur gab. Entsprechend bietet Forth seine eigene Systemabstraktion, auch wenn diese sehr dünn ausfällt. Darauf aufbauend besitzt ein typisches Forth ein Interpreter/Compiler-Gespann, dass sich die Bälle zuspielt: Es startet üblicherweise im Interpreter (sofern man nicht direkt in ein anderes Programm springen will), der bei Bedarf den Compiler aktiviert. Entwicklung ist dadurch "live", die meisten Befehlssequenzen lassen sich erst am Interpreter testen und bei Erfolg zu Worten (=Funktionen) compilen, die in der weiteren Entwicklung verwendet werden können. Auf diese Weise kann gerade Hardwarezugriff sehr schön experimentell getestet werden.

Die Übergabe von Argumenten findet über einen Stack statt - ein Wort hat also keine Definition "soviele Argumente nehme ich (vom Typ X), und soviel gebe ich zurück", es wird stattdessen eine globale Datenstruktur eingesetzt.

Womit ich bei den Problemen wäre:

• (zur Syntax: ": foo ( n -- n | n n) bar baz ;" definiert ein Wort "foo", dass der Ausführung von "bar" und "baz" entspricht. "( n -- n n)" ist ein optionaler Kommentar, der üblicherweise angibt, dass foo ein Element auf dem Stack verbraucht und eins oder zwei zurückgibt.)
• Die Anzahl der Rückgabe-Elemente ist also nicht eindeutig festgelegt, ebensowenig wie die Eingabemenge, was sehr sinnvoll genutzt werden kann (und wird!), wodurch die Einarbeitung in fremden Code aber recht spannend sein kann.
• : send-packet ( len data -- result true | false )
0 0 2 PKT_DATA send-phy-packet ;
  Was bedeutet das? So wirklich überschaubar ist der Datenfluss nicht (in diesem Fall sieht es wohl so aus, dass send-packet im Prinzip ein Wrapper um send-phy-packet ist, der einige konstante Parameter hinzufügt, und dessen Ergebnis einfach durchreicht). Was zum zweiten Problem führt:
• Datenstrukturen sind bei Forth nicht sonderlich üblich. Daten werden auf dem Stack übergeben. Und wenn 6 Elemente benötigt werden, um eine Situation zu beschreiben, liegen halt 6 (anonyme) Elemente auf dem Stack. Und das ist manchmal eine ziemlich aufwendige Datenschieberei, um an die einzelnen Elemente zu kommen (idealerweise arbeitet man die von hinten nach vorn ab, bzw. ordnet die Daten so an, dass das möglich ist).
  In anderen Sprachen wäre hier vermutlich schon eine Datenstruktur zum Einsatz gekommen, die dem ganzen die richtigen Namen gibt.

Natürlich lässt sich das auch in Forth namentlich erledigen, etwa indem Worte konstruiert werden, die einem einen "sinnvollen" Zugriff auf Stackelemente geben (": pkt.len 5 pick ;" - also "wähle das 5-letzte Element vom Stack und kopiere es oben auf den Stack"), was allerdings zu Lasten der Effizienz gehen kann - also eine Abwägung zwischen Effizienz und Lesbarkeit.

Eine andere Möglichkeit wäre, derartige Datenstrukturen außerhalb des Stacks vorzuhalten. Das wiederum bedeutet, jedes Element explizit anzufordern, auf dem Stack zu bearbeiten und in die Datenstruktur zurückzuschreiben, was weder die Effizienz, noch die Lesbarkeit fördert.

Möglichkeit Nummer 3 ist schließlich, solche Datenkolosse gar nicht erst aufkommen zu lassen - was nicht immer möglich ist, zum Beispiel wenn man vorhandene Hardware ansteuern soll (das obige Beispiel ist eine Adaption aus einem USB-Treiber).

Nachdem www.coreboot.org heute nachmittag unter Last zusammengebrochen ist (Sekundäres Slashdotting, 3 Webcrawler), habe ich mich mal daran gemacht, die Konfiguration zu optimieren.

Auf dem System läuft (neben diversem anderen) ein Apache2, der unter anderem ein Mediawiki, trac, viewvc und das mailman-Webinterface bereitstellt. Auffällig waren die sehr großen, zahlreichen und ständig neuen apache2-prefork-Prozesse. Wie sich herausstellt, wurde prefork gewählt, weil php5 weiterhin nicht thread-safe ist (bzw. die eine oder andere Library, die eingesetzt wird). Für trac und viewvc wurde mod_python verwendet.

Leider habe einige mod_python-Versionen das Problem, dass sie leaken - und so wirklich gut scheint man das nicht im Griff zu haben. Von daher war die Planung, php5 "irgendwie" threadsafe zu bekommen und mod_python zu eliminieren.

Trac lässt sich per fastcgi einsetzen, php5 ebenso. Also wurde beides auf mod_fcgid portiert, so dass PHP5-Threadsafety nun kein Problem des Apachen mehr ist, und statt prefork nun worker verwendet werden kann. Weniger Forks, weniger Stress für den Server.

Viewvc hat kein Fastcgi-Interface, daher läuft es momentan als normales CGI, also ein neuer Prozess pro Request, aber es ist relativ klein und schnell, daher macht das nicht so sehr viel aus.

Mal schauen, wie sich der Server nun weiter benimmt.

Nachtrag 24.4.: Heute Nacht haben auch die Apache2-worker angefangen zu leaken - ein Restart vom Apachen gab 1GB freies RAM. Squid war auch total lahmgelegt. Es geht also weiter mit der Fehlersuche...