C Applikationen
Die Sammlung von Gründen, warum man keine C Applikationen ans Internet lassen sollte, geht weiter. Das Sicherheitloch des Tages hat OpenSSL und macht so ziemlich jeden SSL-fähigen Apache-Server mindestens für Denial-Of-Service Attacken anfällig, und vielleicht auch mehr. Wie üblich ein völlig unnöiger Fehler in der Speicherverwaltung...

Suse 9.0
Suse 9.0 würde diese Woche angekündigt und soll angeblich User Mode Linux unterstützen. Für mich wäre das ideal, weil ich so mehrere Instanzen von Knot auf einem Rechner laufen lassen könnte. Da Herry, mein P166 Hauptserver, seine neue Festplatte nicht mag und ich auf das bei EBay ersteigerte VIA Eden MoBo warten muss, werde ich mich wohl auch gleich zum 15. Oktober mit der Installation gedulden und bis dahin Knot ein wenig ruhen lassen.

KDE 4.0
Die Liste der APIs, die ich schreiben will, wird immer länger. Neben den bereits angesprochenen InputStream/OutputStreams und XmlReader/XmlWriter, gibt es noch eine Reihe weiterer Dinge die ich schon allein für Knot gerne hätte:

1. Ich habe die API fertig für eine Klasse KDE::IO::Console, die angenehmen Zugriff auf STDIN/STDOUT/STDERR ermöglicht. qDebug/kdDebug() gehen mir bei Komandozeilen-Applikationen wie knottool auf die Nerven
   
2. Ich bräuchte Input-/OutputStreams ähnlich QDataStream, die für das Lesen von Netzwerkdaten geschrieben wurden. Dass heisst, dass es ein paar mehr Sicherheitsmechanismen gibt (wie eine Begrenzung von String-Längen) und Unterstützung für diverse Dinge, die in binären Protokollen auftauchen, wie zB 24-bit und 48-bit Zahlen und verschiedene String-Formate. Ausserdem muss der Stream mit verschiedenen Endian-Konfigurationen klarkommen. Damit soll Knot's SLP Parser ersetzt werden.
   
3. Ich möchte einen Namespace KDE::Protocols, in den Protokollimplementationen kommen. Erster Kandidat wäre Knot's SLP Parser (KDE::Protocols::SLP), und zweiter HTTP
   
4. Ich spiele immer noch mit dem Gedanken, Knot's IPC Mechanismus durch D-Bus zu ersetzen. Dafür würde ich ich mit jenen Input/OutputStreams in KDE::Protocols::DBUS das D-Bus Protokoll implementieren (niemals werde ich für etwas so sicherheitsrelevantes die C Implementierung benutzen, siehe oben)
   
5. Einen vernüftiger Serialisierungsstream, der (ähnlich Java) auch komplexere Graphen von Objekten serialisieren kann, wäre schön, und notwendig für Punkt 6. Mit Hilfe meines SmartPtrs sollte das auch in C++ möglich sein.
   
6. Ich schiele immer relativ gierig auf Prevayler und ähnliche Systeme. Für meine erweiterten Knot-Pläne wäre das mehr als nützlich, zumal ich denke, dass man mit SmartPtr auch das Hauptproblem von Prevaler (den Speicherbedarf) recht einfach in den Griff bekommen könnte.
   
7. Was mich stört an C++ ist, dass man für jedes Programm immer noch die uralte int main(int argc, char** argv) Funktion implementieren muss. Sich das Ersparen zu können und für die Argumente eine QStringList zu bekommen, zusammen mit einfachen Zugriff auf Environment-Variablen und einer besseren Lösung f¨r POSIX-Signale, wäre hübsch. Aber gerade bei Signalen weiss ich derzeit nicht, wie eine solche Lösung aussehen könnte.
   

Nunja, mit einer Knot-Pause bis Mitte Oktober schaffe ich es vielleicht bis Punkt 3.

geschrieben um 23:43. (0 Kommentare, Direkter Link)

KDE 4.0
Schon seit längerer Zeit nervt mich die Komplexität von XML Parser APIs. Modelle wie DOM wurden erstellt für dokumenten-artige, relativ frei geformte Sprachen wie HTML und DocBook. Aber wenn man sie zum Lesen starrer XML Dokumente wie SOAP Nachrichten benutzt, schreibt man Unmengen von Code für die trivialsten Dinge. Die Krönung des Schwachsinns ist SAX. SAX führt nur bei recht wenigen Anwendungen zu kompaktem, erträglichem Code. Ein Pull-Parser ist SAX in wohl jedem Aspekt überlegen. Der verbreiteste Pull-Parser derzeit ist .Net's XmlReader, den ich auch vergleichweise nett finde. Das Hauptproblem beim Lesen starrer Dokumente aber bleibt: es gibt keine einfache Möglichkeit um Zahlen, Daten und andere Werte zu bekommen und dabei das Format zu überprüfen. Als ich Sonntag irgendwo den Begriff XML Serialisierung gelesen habe, fiel mir die Lösung ein: man überträgt einfach das gute, alte C++ Serialisierungprinzip (wie in QDataStream) auf XML. Das geht zwar nicht 1:1, weil mehr Meta-Daten gebraucht werden, aber es kommt zumindest halbwegs nahe und ist besser als alle anderen Parser. (Der Begriff "XML Serialisierung" wird von Microsoft für ihren Pull-Parser und eine entsprechende Klasse zum Schreiben von XML benutzt, hat aber mit den besonderen Features dieser API nichts weiter zu tun)
Ein Beispiel für ein relativ einfaches XML Dokument ist folgendes:

<x:person xmlns:x="urn:kde:person">
  <x:name order="firstlast">Joe Public</x:name>
  <x:size>185</x:size>
  <y:email xmlns:y="urn:kde:email-extension">joe@kde.org</y:email>
</x:person>

Dieses zu Parsen mit DOM ist die Hölle. Mit meiner API wird es etwa so aussehen:

XmlReader r(/* Initialize with InputStream or DOM tree */);
QString name, nameOrder, email;
int size;
r >> TNamespace("urn:kde:person") 
  >> TOpenElement("person")
    >> TReadElement("name", name)
    >> TReadAttribute("order", nameOrder)
    >> TReadElement("size", size)
    >> TNamespace("urn:kde:email-extension")
    >> TReadElement("email", email)
    >> TNamespace("urn:kde:person")
  >> TCloseElement();
if (r.error())
  // do something...

Das macht XML Parsen erträglich. Ich habe auch noch ein paar Lösungen für optionale oder sich wiederholende Elemente, und für andere Anwendungsfälle soll XmlReader auch noch eine 'traditionelle' Zugriffsfunktionen bekommen. Passend dazu gibt es einen XmlWriter, mit dem XML Dateien mit demselben Prinzip geschrieben werden können. Ich werde wohl noch das Wochenende und vieleicht dar¨ber hinaus damit beschäftigt sein, diese API zu schreiben, was meine Knot Pläne weiter verzögert. Aber ich brauche die API einfach....

XML
Beim Schreiben besagter API ist mir aufgefallen, wie sehr XML nervt. Das Problem sind dabei gar nicht die üblichen Punkte, wie etwa die "Attribut oder Element"-Frage, "Mixed-Content" und ähnliche Kritikpunkte. Das Problem sind die SGML-Altlasten, die in XML übernommen wurden und die Spezifikation verseuchen, obwohl sie einfach nur unnötig sind bzw durch XML Schema und ähnliche Mechanismen ersetzt wurden. Damit meine ich DTDs, 'Processing Instructions', 'Internal Entities' und 'CData'. Die meisten Leute kennen diese wahrscheinlich nicht einmal und kümmern sich nicht weiter darum. Wenn man aber eine API wie DOM sauber benutzen will, muss man es. Beispielsweise gibt es drei Nodes, die Text enthalten können (Text, EntityReference und CData), was gerade einfache Aufgaben, wie den Text eines Elementes zu lesen, unglaublich erschwert. Zumindest, wenn man sich nicht für sowas seine eigenen Helferklassen schreibt. XmlReader wird standardmössig diesen Kram ignorieren - es sei denn, man aktiviert es explizit.
geschrieben um 00:44. (0 Kommentare, Direkter Link)

Kampf gegen das Analoge
Nun hat auch Nokia digitale Bilderrahmen vorgestellt. Neben einem Modell mit relativ üblichen Features soll es auch eines mit eingebautem MMS-fähigen GSM-Modul geben. Wenn sie jetzt noch einen brauchbaren Preis hätten... Am originellsten aber ist das digitale Medallion. Ich glaube nicht, dass ich mit sowas herumlaufen würde, aber besser als ein analoges ist es auf jeden Fall.
geschrieben um 20:06. (0 Kommentare, Direkter Link)

C Applikationen
Diese Woche haben es sowohl OpenSSH als auch LSH geschafft, mit Root Exploits mein letztes Vertrauen in C Server zu zerstören. Mal ganz abgesehen von den üblichen Sendmail-Problemen, über die schon niemand mehr redet. Offensichtlich ist es nicht nicht möglich, einen komplexen Server in C zu programmieren ohne ein ernsthaftes Sicherheitsproblem pro Jahr. Deswegen sollten sie alle ersetzt werden. Ein guter Grund mehr, Server mit dem KDE Framework zu bauen. Dies könnte eine gute Alternative sein zwischen Scriptsprachen und Java, die sich nicht sonderlich gut ins System integrieren und Resourcen schlucken, und C mit seinen Sicherheitslücken.

Knot
Da nun auch noch mein Hauptserver bzw dessen Festplatte den Geist aufgegeben hat, bin ich nicht sehr viel weiter gekommen, weil ich einfach nicht testen kann. Die von mir geplante SLP Extension, um Services in allen Sprachen zu finden, habe ich nach einer kleinen Diskussion auf srvloc-discuss aufgegeben und stattdessen eine Lösung implementiert, die zusätzlich zur voreingestellten Sprache gleichzeitig in Englisch suchen kann. Das ist implementiert, aber auch nicht getestet. Zum Testen der KDE API fehlt mir auch noch ein Testprogramm, damit habe ich ein wenig angefangen, bin aber nicht sehr weit. Vielleicht mache ich dies heute.

KDE 4.0
Was ich vielleicht am meisten in Qt/KDE vermisse sind abstrakte Klassen für Byte Ströme wie InputStream und OutputStream. QIODevice ist kein wirklicher Ersatz, es ist zu komplex zu implementieren und entspricht mehr einem File Descriptor. Folge ist, dass viele APIs relativ unflexibel oder unkomfortabel gestaltet sind. Eine einfache Möglichkeit, grössere Datenmengen komfortabel zu verarbeiten fehlt, entweder haben die APIs umständliche eigene Methoden zum schreiben oder lesen oder sie nehmen nur ganze Files oder Speicherregionen als Ein- bzw Ausgabe. Daher habe ich gestern den halben Tag damit verbracht, eine Java-ähnliche API zu schreiben, inklusive Pendants zu Java Klassen wie dem BufferedOutputStream, dem ByteArrayOutputStream und Kompatibilität zu QIODevice mittels Adapterklassen. Ich halte meine API für schöner als die von Java, die Klassen sind simpler und vor allem habe ich meine Lieblingshelferklasse für Input/OutputStreams, Pipe, dabei. Pipe erlaubt es, synchron oder asynchron Daten von InputStreams in OutputStreams zu schreiben, womit man sich praktisch alle Schleifen zum Kopieren von Daten spart. Die Klassen existieren zur Zeit nur als Header-Dateien. Sobald ich sie brauche (und das wird wohl sein, wenn ich Knot's HTTP Interface schreibe), werde ich sie implementieren und auf KDE Developers vorstellen.
geschrieben um 15:46. (0 Kommentare, Direkter Link)

KDE 4.0
Auf kdedevelopers.org habe ich meine Pläne für KURL niedergeschrieben. Nebenbei arbeite ich ein wenig am Code, und werde die KDE::Net:: URI Klasse wohl auch in der Knot KDE API benutzen.
geschrieben um 22:36. (0 Kommentare, Direkter Link)

Geistiges Eigentum
Die NYT hat einen interessanten Artikel über die Parallelen zwischen File Sharing, Produktfälschungen und Studenten, die in ihre Arbeiten Auszüge aus dem Internet einfügen. Der Autor scheint zu dem Schluss zu kommen, dass Kopieren und Fälschen sich zunehmend verbeitet und oft Kopieren 'cooler' ist als das Original, vom fehlenden Unrechtsbewusstwein ganz zu schweigen. Was er nicht direkt erwähnt ist, wie zerbrechlich die Firmen dadurch werden. Wenn eine Firma nur noch auf geistigem Eigentum (urheberrechtlich geschützte Werke, Warenzeichen und Patenten) besteht und alle kostspieligen Prozesse in das billigere Ausland verlagert, ist es nur eine Frage der Zeit, bis eine Firma dort das gesammelte Wissen der Mitarbeiter nutzt, um mit der Ursprungsfirma zu konkurieren. Das betrifft Nike ebenso wie Softwarefirmen, die ihre Entwicklung auslagern. Anfangs können sie noch von ihrem bestehendem Bekanntheitsgrad, ihrem geistigen Eigentum oder Patenten leben, aber ein paar (Produkt-)Generationen weiter wird es nicht mehr helfen. Wenn nun auch der 'Wert', ein Original zu besitzen, geringer wird und Kopien zumindest gleichwertig aus Sicht des Konsumenten sind, wird es noch wesentlich schwieriger, eine rein auf geistigem Eigentum basierende Firma bestehen zu lassen. Stattdessen kommt es wieder vermehrt auf Kosteneffizienz und Qualität der Produktion an. Aber wenn diese ausgelagert wurde, bleibt in den Ursprungsländern nicht viel übrig. Letztenendes wird durch das Auslagern der Produktion auch ebenso der Wohlstand ausgelagert.

SAML
Das vorletzten Monat entdeckte SAML Protokol habe ich aus meinen Knot-Plänen entfernt, da leider RSA das Verfahren patentiert hat. Folge ist, dass ich einerseits wohl mein eigenes Protokoll benutzen muss (zumal auch PKI patentert ist), aber andererseits dadurch die gesamte Authentifizierung viel stärker auf P2P-Betrieb ausgelegt sein wird. Schon allein deswegen, weil es dort keine Patente oder auch nur wissenschaftliche Arbeiten zu geben scheint, während bei der zentralisierten Authentifizierung alles zugepfalstert ist mit Patenten. Mehr dazu irgendwann später...

Knot
Die Attribute List Extension ist implementiert, aber ich habe immer noch nicht meinen Testrechner. Das Suse 8.2 Installationsprogramm schafft es nicht, eine für meinen TFT-Monitor benutzbare Auflösung zu benutzen...

geschrieben um 14:59. (0 Kommentare, Direkter Link)

Kampf gegen das Analoge
Sieht so aus, als hätte ich meine zukünftige Set-Top Box gefunden. Bei einem geschlossenem System macht mir auch DRM nichts aus, der Preis ist annehmbar und wenn es auch noch Ogg Vorbis unterstützen würde, wäre es perfekt.
Nachtrag: ich habe mich komplett verlesen und die Modellnummern (200-350) mit dem Preis (1000-1500 EUR) verwechselt. Letzteres ist natürlich einfach nur krank und wird helfen, nicht mehr als 100 Stück davon zu verkaufen...
geschrieben um 15:31. (0 Kommentare, Direkter Link)

Freedesktop.org vs. the KDE platform
auf kdedevelopers.org (englisch).
geschrieben um 21:39. (0 Kommentare, Direkter Link)

Knot
Endlich habe ich mal so viel geschafft, wie ich mir vorgenommen habe. Das Resultat: die KDE API ist fertig, inklusive nativer Implementierung. Auch habe ich meine Liste kleinerer Aufgaben komplett abgearbeitet. Im nächsten Schritt werden die Attribute List und Sort&Select Erweiterungen implementiert, und eine kleine, Knot-eigene Erweiterung zum Suchen von Services in beliebigen Sprachen. Mehr zu letzterer Erweiterung später, wenn ich sie der SLP Mailing List vorgestellt habe. Bevor ich allerdings an den Erweiterungen arbeiten kann, muss ich mir erstmal einen Testrechner zusammenbauen, weil auf meinem kleinem Server zur Zeit OpenSLP läft und ich dies der Rückwärtkompatibilität wegen auch nicht ändern will.
geschrieben um 23:53. (0 Kommentare, Direkter Link)