ITBlog

Digital Rights Management (DRM) ist eine Methode Abspiel- und Kopier Möglichkeiten von Medien einzuschränken. Inhaltsanbieter sagen sie können damit günstigere Preise machen indem die Rechte auf ein vom Kunden benötigtes Maximum eingeschränkt werden. Kunden hingegen fühlen sich dadurch insbesondere mehrfach abgezockt. So oder so hat DRM große Probleme, weil dem Kunden (dem Käufer) einiges an Rechte weggenommen wird. Das kann dann so weit gehen, dass man gekaufte Songs nicht mehr abspielen kann, weil die DRM Server nicht erreichbar sind, oder keine Geräte mehr das Verfahren unterstützen. Microsoft hat den DRM Skeptikern einst versucht mit Ihrer "Plays for Shure" Campagne zu entgegnen. Ironischer weise schaltet Microsoft diesen Dienst jetzt ab, was dazu führt dass man die gekauften Medien nicht mehr von einem Gerät zum anderen übertragen kann (sondern nur noch auf den 5 registrierten Geräten). Wieder einmal zeigt sich, dass offene Formate eine sichere Zukunftsinvestition sind. Via Kris. Update: auch im Spiegel.

Wenn man bei Novell angibt den Username und das Passwort vergessen zu haben, so bekommt man einen Passwort Reminder, der neben dem Usernamen auch die Securityquestion enthält - und die Antwort (was soll das denn, da kann man ja gleich nen neues Passwort zusenden). Rotfl:

Die Nachfrage nach coolen oder aussagekräftigen Domain Namen ist ja weitgehend rückläufig (weil es keine mehr gibt), aber auch aus dem realen Leben kennt man Eitelkeitsaddressen (Microsoft Way 1). Aber ganz besonders amüsant fand ich diese Postanschrift:

Seagate Technology, 900 Disc Drive, Scotts Valley, CA 95066

Ob das auch gleich eine Telefonnummer ist?

Den Termin habe ich grade zufällig im Karlsruhe IT-Termine Kalender gefunden als ich ausprobiert habe ob Chandler den Google ICS Stream importieren kann (ja kann er): Dipl.-Inform. Peter Rösler (München): “Überraschungen aus der Welt der Software-Reviews” Verantalter: GI/ACM-Regionalgruppe Karlsruhe Termin: Mittwoch, 23.04.2008, 19:00 Uhr (Ende: ca. 20:30 Uhr) Ort: Universität Karlsruhe (TH), Fakultät für Informatik, Am Fasanengarten 5, Raum -101 Anmeldung: Zur besseren Planung wird um eine kurze Rückmeldung gebeten Ich hoffe ich kann mir das einrichten.

Die letzten paar Tage habe ich mit einem sehr interessanten und unterhaltsamen Buch verbracht. Es lag schon einige Zeit auf dem Todo Stapel, jetzt habe ich es in kürzester Zeit verschlungen. Es ist Scott Rosenberg's "Dreaming in Code". Rosenberg liefert in dem Buch einen Projekt Report ab. Dabei geht es um das Open Source Projekt Chandler, das von Mitch Kapor, einem Software Veteranen (und Investor) aufgebaut, finanziert und geleitet wird. Das Projekt hatte eigentlich idealer Voraussetzungen für einen Erfolg - steckt aber immer noch in den Kinderschuhen. Wie dies passieren konnte ist eines der Hauptthemen des Buches. Es ist kein Programmier Handbuch, sondern mehr eine Chronik des Software Industrie. Die unzähligen Verweise und Zitate aus bekannten und unbekannten Quellen ergeben ein erstaunliches Rundes Bild - fast als wäre das Chandler Projekt reine Fiktion. Das wird unterstützt durch den Roman Charakter des Buches - es ist spannend Kapitel für Kapitel der Arbeit der Protagonisten (und unserer Industrie) zu folgen. Ein gut geschriebenes Buch (die Englischen Texte sind zwar verständlich aber durchaus anspruchsvoll) das ich nur empfehlen kann. Auch wenn man sich mit den Grundlagen und Best Practises in der Softwarebranche auskennt erhält man doch einige Auffrischer, interessante Zitate oder Hintergrundinformationen. Wie man an den Amazon Bewertungen sehen kann, so ist nicht jeder dieser Ansicht. Es ist also sicherlich Hilfreich sich nicht für unfehlbar zu halten, sonst bringt einem das Buch keinen wirklichen Gewinn. (416 Seiten, Gebunden (oder Taschenbuch), Englisch, Crown Publishers Januar 2007).

Als eine Art Nachfolger des Linuxtages (der ja nicht mehr in Karlsruhe veranstaltet wird) scheint sich die Open Source Expo etablieren zu wollen. Der etwas breitere Themenschwerpunkt scheint eine gute Voraussetzung für eine erfolgreiche Veranstaltung zu sein. Kongresszentrum Karlsruhe, 25. und 26. Mai 2008 Ich bin mal gespannt, wie sich diese Veranstaltung so machen wird, und freue mich, dass weiterhin in Karlsruhe die interessanten Veranstaltungen der Community zu finden sind. Dahinter steht die S&S Media Group, die ja sehr stark im Bereich IT und OSS Media+Konferenzen tätig ist.

Wie schon im ersten Teil beschrieben, muss man trotz der Platform Unabhängikeit von Java etwas über die Zielsysteme wissen, um grobe Fehler zu vermeiden:

/** save data as UTF-8 string to file. */
saveFile(String data, File file) throws IOException, UnsupportedEncodingException {
  OutputStream out = null;
  bytes[] b = data.getBytes("UTF-8");
  try {
    out = new FileOutputStream(file);
    out.write(b);
  } catch(IOException ioe) {
    System.err.println("Cannot save data in UTF-8 to file " + file + ": " + ioe);
    throw ioe; // notify upper layer about problem
  } finally {
    silentClose(out); out = null;  // BANG, problem unterdrückt.
  }
}

silentClose(OutputStream out) {
  if (out != null)
    try { out.close(); } catch (Exception ignored) { }
}

In diesem Fall wird zwar richtigerweise im Fehlerfall der Output Stream geschlossen und die dabei eventuell auftretende Exception ignoriert, aber viel kritischer ist der Fall in dem im try block keine Exception aufgetreten ist, aber dafür dann das close() fehlschlägt. Es muss damit gerechnet werden dass im close() auf einem OutputStream eine IOException auftreten kann - sogar sehr häufig - der Grund dafür ist, dass zum einen der Stream einen flush() vor dem close() durchführen wird. Dazu kommt noch, dass die close() Methode der letzte Zeitpunkt ist, in dem ein IO Fehler gemeldet werden kann. Bei NFS ist es z.B. so, dass der client wartet bis der Server den Empfang bestätigt hat. Und dabei kann natürlich eine Menge schiefgehen. Auch quota Überschreitungen können zu einer IOException führen. Es hilft etwas als letztes Statement im try-block einen flush() durchzuführen, aber es besteht weiterhin ein Risiko dass close() fehlschlägt. Eine wichtige Regel lautet also: bei Streams in die geschrieben wird kann close() einen Fehler werfen, diese darf nicht ignoriert werden (sonst gehen Daten verloren)!

saveFile(String data, File file) throws IOException, UnsupportedEncodingException {
  OutputStream out = null;
  bytes[] b = data.getBytes("UTF-8");
  try {
    out = new FileOutputStream(file);
    out.write(b);
    out.close(); out = null;
  } catch(IOException ioe) {
    System.err.println("Cannot save data in UTF-8 to file " + file + ": " + ioe);
    throw ioe;
  } finally {
    silentClose(out); out = null;
  }
}

Im Falle von NFS ist obiger Code ausreichend. Nach dem close() ist es garantiert, dass die Daten permanent gespeichert sind. Bei lokalen Filesystemen wird diese Garantie von den gängigen Betriebsystemen NICHT gegeben. Die Daten können auch nach einem close() nur im lokalen Buffer Cache des Filesystems (RAM) liegen und erst nach einiger Zeit (typischerweise 5 Sekunden) an die Hardware Schicht übergeben werden. Dies ist zwar gut für die Performance, aber ein potentielles Fenster für Datenverlust - und eventuell Korruption des Anwendungszustandes. Wie dies zu vermeiden ist, betrachte ich im nächsten Teil (der kein Jahr auf sich warten lassen wird:)