Tobi’s Blog

Mitte Mai 2009 hatte ich ja so ein kleines Problem mit meinen Backup-DVDs und habe seit dem ein wenig mit DVDs experimentiert. Um das Verhalten von CDs und DVDs über einen längeren Zeitraum zu dokumentieren habe ich damals verschiedene Rohlinge mit Daten beschrieben und sie alle paar Wochen geprüft.

Getesteter Bestand

Folgende Dinge werden für den Test verwendet:

Brenner/Lesegerät

Phillips DVDR 1648P1 P2.2

Brenngeschwindigkeit

1-fach

Rohlinge

CD Original

1x vom 29.11.1995, 1x vom 09.04.1996

CD-R, Tevion

2x 10.05.2006, 1x vom 12.05.2005 (die war mit 40x Geschwindigkeit gebrannt worden)

CD-R, BASF Ceram Guard

1x vom 05.10.1999

DVD-R, Octron 16x (HerstellerID: ritekf 1)

2x vom 17.05.2009, 1x vom 16.5.2009

DVD+R, Platinum 16x (HerstellerID: MBIPG101R05)

1x vom 28.03.2009, 1x vom 16.05.2009

DVD-RW, Verbatim 4x (HerstellerID: MCC 01 RW 4X)

1x vom 28.03.2009, 2x vom 16.05.2009

DVD+RW, Maxell 4x (HerstellerID: ritek 004)

2x vom 17.05.2009, 2x vom 20.09.2009

Bei den Tests gab es bisher noch keine Fehler. Leider ist bisher auch nur der Hauch einer Tendenz zu erkennen, und zwar bei einer einzigen DVD.

Bei dieser einen Octron DVD-R, die am 17.05.2009 gebrannt wurde, gibt es leichte Probleme beim Lesen des Anfangssektors und sporadisch auch mal im Endbereich.

Mit den Erkentnissen aus den vorherigen Kratzertests, nämlich dass Fehler die mit der Spur laufen gravierend sind und Fehler am Beginn der DVD den Datenträger unbrauchbar machen können, ist das schon alarmierend. Vor allem, da die DVD gerade mal ein halbes Jahr alt ist. Bei der besagten DVD braucht das Laufwerk auch einige Sekunden, bis es den Datenträger als solchen erkennt. Wird der Fehler stärker, wird die DVD nicht mehr lesbar sein und die Daten sind verloren.

Bei den getesteten CDs ist zu sehen, dass diese sich für dauerhafte und sichere Backups sehr gut eignen. Die 15 Jahre alten, gepressten original-CDs sind, wie zu erwarten war, noch wie neu.

Der 10 Jahre alte BASF-Rohling hat zwar eine etwas unruhige Kennlinie beim Auslesen, diese änderte sich aber in dem halben Jahr nicht.

Und selbst der fast 5 Jahre alte billig-Rohling von Tevion, immerhin nur mal nebenbei mit 40x Geschwindigkeit gebrannt, sieht nicht anders aus und änderte sein Verhalten auch nicht im Testzeitraum. Es ist also zu erwarten, dass die Dinger im Zweiffel auch noch in 20 Jahren laufen würden, wobei der Tod dort warscheinlich auch plötzlich und ohne Vorwarnung eintreten wird.

Fazit

CDs sind, wie erwartet, bewährt, haltbar und zu empfehlen. Da bei den DVDs bisher keinerlei Ungewöhnlichkeiten oder Probleme auszumachen waren, kann ich daraus noch keinen Schluss ziehen.

Da auf den DVDs meine eigenen Backups liegen, allerdings jeweils doppelt und zusätzlich noch auf einer Backup-HD, werd ich den Test weiter fortführen. Wenn meine Theorie stimmt, sollte innerhalb der nächsten anderthalb Jahre irgendwas gravierendes passieren. Hoffentlich diesmal ohne das Daten verloren gehen

Das Thema Spenden habe ich schon immer viel Skepsis betrachtet, da ich ja nicht nachprüfen konnte, was mit meinem Geld so passiert. Seit spätestens heute weiß ich, dass diese Vorsicht gut begründet ist, und zwar wegen dieser zwei Beispiele:

Erstens: eigene Erfahrung
In Wiesbadens Innenstadt lauern ja öfter mal Spendensammler, und beim “Bund deutscher Tierfreunde” hatte ich mich mal spaßeshalber eingetragen. Da die Leute am Stand mal abgesehen von herzzerreißenden Geschichten über Tierquälerei nichts weiter von sich geben, hab ich mich auf die 14 Tage Sonderkündigungsrecht gestützt und erst NACH der Unterschrift nachgeforscht. Unter Charitywatch.de bin ich zu dem Verein gleich mehrfach fündig geworden. Die Kündigung war kein Problem, aber ein gegen einen anderen Verein laufen gerade Ermittlungen wege Datenmissbrauch. D.h. meine Bankdaten währen dort ggf. schon weitergegeben worden.

Ich hab für mich entschieden, dass ich bei solchen “Anfixern” jetzt mal mindestens folgende Fragen stellen werde, bevor ich überhaupt nur daran denke was zu spenden:

• Haben Sie das Spendensiegel
• Wo kann ich die Bilanzen einsehen? (Spendensiegel-Vereine verpflichten sich zur Selbstauskunft)
• Wohin fließen die Gelder konkret. Mindestens 2 Projekte mit Ortsangaben und Geldbetrag
• Wo kann ich mir das ansehen? (Und wenn es in Timbuktu ist, wenigstens eine Adresse/Anschrift etc)

Zweitens: eine Recherche vom Deutschlandfunk
Im Deutschlandfunk gab es heute einen Bericht über Spenden bei der Tsunami-Katastrophe vor 5 Jahren. Zugegeben wohl eines der extremen Beispiele, aber sowohl der Aufwand auf Seiten des Betrügers als auch die Reaktion der zuständigen Staatsanwaltschaft kann man als extrem gering betrachten.

Der Betrüger konnte völlig unbehelligt noch einige Zeit in Deutschland leben und ist dann einfach ausgereist. Einen Haftbefehl, für immerhin 2,3 Millionen unterschlagene Euro und offensichtliche Urkundenfälschung, gibt es bis heute nicht. Wenn ich mal Geld brauche werd ich wohl kaum noch eine Bank überfallen. Diese Art ist viel einfacher, lukrativer und ist quasi straffrei >:)

Fazit

Spenden ist eine gefährliche Sache. Selbst wirklich großen Vereinen kann man nur bedingt vertrauen, denn auch da gibts z.B. bei Charitywatch Eintragungen die nichts gutes heißen. D.h.: erst Prüfen und unbequeme Fragen stellen und erst dann, wenn adequate Antworten kommen, Geld geben. Am besten natürlich: die Verwendung sicher nachprüfen (lassen).

Wer man mal wieder Lust hat, sich ein wenig die Zeit zu vertreiben, dem kann ich Continuitygame nur empfehlen. Ein kostenloses Flash-Spielchen und eine Mischung aus Jump’n'Run und einem Schiebefax mit 32 Leveln.

Es ist mal eine wirklich interessante Mischung von 2 “Genres”, die eigentlich so gar nichts miteinander zu tun haben und es sind einige Level dabei, bei denen man die grauen Zellen schon ein wenig Anstrengen muss. Eine Spielbeschreibung lohnt sich kaum, denn das Prinzip ist extrem simpel und intuitiv. Und Nebenbei: auch die Musikuntermalung ist wirklich nett gemacht.

Insgesamt hab hatte ich etwas unter 2 Stunden meinen Spaß mit dem Spiel. Die Level kann man auch überspringen, wodurch man das Spiel ganz entspannt über viele Tage verteilen kann.

Wer also auf Knobelspaß steht, sollte es einfach mal ausprobieren.

Als ich mal seit langem mal wieder ein Layout per CSS gestalten musste, kam die Frage auf, ob es nicht eine Alternative für die float-Angabe im CSS gibt, um Elemente dynamisch nebeneinander platzieren zu können. Denn mit folgenden Problemen hab ich bisher jedes mal zu kämpfen, wenn float im Spiel ist:

• Ein ein mal gesetztes Float kann nur durch ein Clear aufgehoben werden (oder mit hässlichen Hacks, die aber in verschiedenen Browsern verschiedene Probleme machen)
• Man kann immer nur ALLE floats (einer Richtung) aufheben. Also nicht nur das eine bestmmte, sondern im Zweiffel auch alle anderen, die man nicht erwischen wollte.
• In so ziemlich jeder unterschiedlichen IE-Version gibt es damit unterschiedliche Fehler.
• In allen Browsern brechen die “gefloeteten” Elemente aus ihrem umgebenden Container aus. Das muss man dann auch wieder mit Hacks irgendwie umgehen (und das ist, finde ich, das schlimmste Problem, weil am nervigsten)

Und wenn man es sich mal genau überlegt, wofür float eigentlich gedacht ist, ist es eigentlich klar, dass es so viele Probleme damit gibt. Ich denke es ist eben für Dinge wie ein Bild, was von Textblöckem umflossen wird und nicht um z.B. Navigationspunkte horizontal in einer Reihe anzuordnen oder ein 3-Spalten-Layout zu erstellen.

Und genau die zwei letztgenannten Anforderungen trieben mich dazu, mal in der Liste der CSS-Angaben zu suchen. Gefunden hab ich dort display: inline-block, was zwar auch nicht ohne Probleme ist, aber die sind örtlich begrenzt und eher handhabbar als ein außer Kontrolle geratenes Float.

Man definert mit dieser Angabe, dass sich das aktuelle Element nach “außen” wie ein inline-Element verhält, also keinen Umbruch hat und die Breite ggf. automatisch wählt, “innen” aber alles wie beim Block möglich ist. Also fixe Breitenangaben, wenn man denn will, margin und padding etc. Außerdem ist es extrem stressfrei, da es eben nur für genau dieses eine Element gilt und in dem umgebenden Block quasi eingesperrt bleibt. Also keine Nebenwirkungen außerhalb haben kann. Und will man den Elementfluss unterbrechen, um z.B. mehrere Zeilen zu haben, reicht ein einfaches <br/>.

Da das aber zu schön ist, gibts dann doch noch ein paar Probleme, nämlich folgende:

Whitespaces

Gibt es Zeichen zwischen den Elementen, z.B. Whitespaces, dann werden die, wie bei Fließtext auch, zwischen den Elementen dargestellt und erzeugen einen Abstand. Das kann man verhindern, in dem umgebeenden Block die Schriftgröße 0 zuteilt. Dazu muss es aber eben immer einen Umgebenden Block geben. Wenn man dann nicht für jedes enthaltene Element wieder definieren will, wie groß die Schrift dort wieder sein soll, muss man global eine absolute Schriftgröße angeben (* { font-size; 10pt; }). Alternativ kann man auch einfach keine Zeichen zwischen die Elemente setzen, auch keinen Zeilenumbruch, und braucht dann nicht mit den Schriftgrößen hantieren (der Quellcode ist dann aber unleserlich).

FireFox vor Version 2

Alle Versionen des FireFox vor Version 3 kennen die Angabe nicht. Allerdings gibt es dafür dort eine properitäre Angabe die genau das gleiche macht. Und die inline-block Angabe wird komplett ignoriert. Also kann man einfach VOR display:inline-block; die Angabe display:-moz-inline-box; setzen und alle FF sind glücklich

IE vor Version 8

Alle IE vor der Version 8 kennen die Angabe nicht. Allerdings ist display:inline; dort so fehlerhaft umgesetzt dass es sich exakt so wie display:inline-block verhält Dumm ist nur, dass man nicht so einfach vorgehen kann wie beim FF kleiner v3 da die unbekannten Angaben trotzdem verwendet werden (was auch immer er dann macht, aber es ist falsch). Hier kann man entweder ConditionalComments benutzen, worurch die Angaben aber voneinander getrennt abgelegt werden, oder folgende Hacks:

Für IE 6

* html MEINELEMENT { display: inline; }

Für IE 7

*+ html MEINELEMENT { display: inline; }

Leider muss man BEIDE Angaben einzeln machen, da der eine Hack für den IE7 den für den IE6 unbrauchbar macht.

Unterschiedliche Höhen

Die Elemente, die man nebeneinander platzieren möchte, sind ja nicht immer alle gleich groß. Der Trick, das am einfachsten und effektivsten ist, ist einfach alle per vertical-align:top an der oberen Kante ausrichten.

Damit lassen sich für folgende Browser alle Unzulänglichkeiten ausbügeln, die mir bisher aufgefallen sind und es sieht dort überall gleich aus:

• Opera seit mindestens v9.5
• IE seit v6
• FF seit mindestens v0.9

Hier mal ein Beispiel und der Code für eine Liste, deren Elemente nebeneinander stehen sollen und nach deren dritten Element eine zweite Zeile beginnen soll. Natürlich ist das für so ein einfaches beispiel viel einfacher per float umsetzbar, aber ich will gar nicht wissen, wie viele Zeilen CSS-Hacks ich schon geschrieben habe, um genau so einfache Sachen in größeren Layouts für den IE wieder gangbar zu machen.

Bsp: Display:inline-block in Aktion.


<style type="text/css">
/* solve whitespace-problem, part 1 */
* {
font-size: 12pt;
}
div#codeexdib {
/* solve whitespace-problem, part 2 */
font-size: 0;
/* only to show... */
border: solid 2px blue;
margin: 0;
padding: 0;
list-style: none;
}
div#codeexdib div {
/* FF before v3 solved */
display: -moz-inline-box;
display: inline-block;
/* force alignment */
vertical-align: top;
/* only to show... */
border: solid 2px red;
margin: 0;
padding: 1em;
}
/* IE6 solved */
* html div#codeexdib div {
display: inline;
}
/* IE7 solved */
*+ html div#codeexdib div {
display: inline;
}
</style>
<div id="codeexdib">
<div style="height:8em">Eins:1</div>
<div>Zwei:1</div>
<div style="width:4em">Drei:1</div>
<br/>
<div>Eins:2</div>
<div>Zwei:2</div>
</div>


Nachtrag: Ich hatte im Beispiel vormals UL und LI verwenden und darin ein BR, das funktioniert natürlich nicht weils nicht valide ist. Interessanterweise “mekern” nur alle IE (6 bis und verschieben das BR in das davor liegende LI um wieder validen Code zu haben.

Beim Installieren eines eigenen Wikis fiel die Wahl, wegen der einfachen Installation, auf Mediawiki. Schon beim Entpacken ist mir die Dateigröße unangenehm aufgefallen, nämlich ganze 43MB.

Da auf meinem Server das gesamte /var/www in einer RAM-Disk liegt und die natürlich nicht so sonderlich groß ist, musste eine Lösung her. Bei der Suche nach dem Schuldigen in Sachen Platzverbrauch kam das /languages/messages Verzeichis mit immerhin 31MB in Frage. 99% dieser Sprachen kann man, wenn man kein internationales Publikum auf seinem Wiki erwartet, entfernen. Folgendes muss getan werden, damit nur DE übrig bleibt und das gesamte Wiki damit auf 12MB zusammengeschrumft wird:

cd mediawiki/languages/messages

Ins Sprachverzeichnis wechseln

mkdir tmp

Ein Sammelverzeichnis anlegen

mv Messages* tmp

Erst mal alle Dateien beiseite schieben

mv tmp/MessagesDe_formal.php .;mv tmp/MessagesDe.php .;mv tmp/MessagesEn.php .

Die nötigen Sprachdateien wieder zurück verschieben

rm -rf tmp

Die anderen Sprachdateien entfernen

Jetzt stehen in der Konfiguration die anderen Sprachen aber noch zur Auswahl. Wenn man die jetzt wählt, ist das Wiki für den Benutzer leer und er kann die Sprache auch nciht wieder zurücksetzen. Das kann geändert werden, in dem man die Datei ediawiki/languages/Names.php editiert und alle Zeilen bis auf DE und EN mit // am Anfang auskommentiert (oder Blockweise per /* … */).

Aufgetretene Probleme:

• Die EN-Sprachdatei wird zwingend benötigt. Ohne sie gibt es einen Laufzeitfehler
• Die DE_formal-Sprachdatei scheint fix mit DE verknüpft zu sein. Fehlt sie, ist der Inhalt des Wiki komplett leer. Man kann “formal” in der Names auch auskommentieren und es taucht in der Auswahl trotzdem auf
• Benutzer, die eine andere Sprache ausgeewählt haben, können das Wiki nicht mehr benutzen. Deswege kann diese Methode nur bei der Installation oder wenn man sich seiner Sache ganz sicher ist angewandt werden

Nebenbei: bei der Suche und installation des Wiki ist mir mal wieder deutlich gezeigt worden, warum PHP bei solchen Projekten so beliebt ist. Ich hatte vorher Foswiki versucht zu installieren und das ist mäßig dokumentiert und die Abhängigkeiten, z.B. vom CPAN, sind mäßig leicht auflösbar. Beim Mediawiki lief es auf ein raufkopieren, aufrufen im Browser und DB-Benutzer anlegen hinaus. Leichter gehts kaum.

Warum könnend bei Perl-Projekten die benötigten CPAN-Module nicht einfach mitgeliefert werden und im Modulverzeichnis liegen? Das vereinfacht das Ganze doch erheblich.