Wer sich auf diese Seite verirrt hat und vielleicht sogar den RSS-Feed nutzt, hat es vermutlich schon bemerkt: Hier herrscht schon seit einer ganzen Weile Funkstille. Da mir der Aufwand für neue Einträge momentan zu hoch ist, habe ich mich entschlossen das Blog zu schließen und stattdessen auf www.krausmueller.de nur noch meine TYPO3 Extension jk_poll vorzustellen und über neue Versionen zu informieren. Die alten Einträge sind weiterhin unter dem Menüpunkt "Blog" in der Navigation zu finden. Es werden jedoch keine neuen hinzukommen.

Ich glaube der Verlust hält sich in Grenzen, allzu viele Leser hatte ich vermutlich eh nicht ;).

Um eine VMware Umgebung auch mit Features wie VMotion in VMware Workstation zu testen braucht man Storage, auf den alle ESX Sever zugreifen können. Bisher habe ich dafür immer eine weitere VM, wie z.B. diese oder diese, genutzt und dann per iSCSI an die ESX Server angebunden. Der Nachteil dabei ist, dass die eh schon knappen Ressourcen mit einer weiteren VM geteilt werden müssen. Es geht jedoch auch anders. In diesem Blogpost wird beschrieben wie eine virtuelle Festplatte mehreren ESX Servern ohne zusätzliche VM zur Verfügung gestellt und dann für VMotion, HA und DRS verwendet werden kann. Funktioniert und ich spare mir den RAM für eine zusätzliche VM.

Beim Suchen auf der VMware Seite im Bereich VMmark habe ich eine Entdeckung gemacht. In einem Test, der mit VMware ESX v4.0 durchgeführt wurde (z.B. dieser), ist als "Virtualization Software Availability Date" der 30. Juni 2009 aufgeführt.

Es wird sich zeigen ob diese Datum wirklich stimmt ;-).

UPDATE: Na gut, vSphere ist jetzt doch schon am 20. Mai erschienen ;-). Hier lässt sich eine Testversion herunterladen.

UPDATE 2: Mit dieser Evaluation hat sich VMware aber mal richtig Mühe gemacht. Unter dem Punkt "Guided Evaluation" gibt es viele Videos, die z.B. die Installation der einzelnen Komponenten zeigen. Einige Videos fehlen zwar noch, aber die kommen bestimmt bald. Demnächst kann ich dann hoffentlich von meinen Erfahrungen mit der neuen Version berichten ;-)

Übersetzungen für verschiedene Sprachen werden in Frontend-Extensions im Normalfall in der Datei pi1/locallang.php definiert. Ist für die gewünschte Sprache noch keine Übesetzung vorhanden, sollte diese natürlich dem Maintainer der Extension geschickt werde, der sie dann hoffentlich einbaut. Wird die Datei selbst editiert, gehen die Veränderungen beim nächsten Update der Extension verloren (es sei denn die Sprache ist in dem Update neu hinzugekommen). Bevor man jetzt also die locallang.php editiert und auch in anderen Fällen kann es sinnvoll sein die Sprache in TypoScript zu definieren bzw. bereits definierte Übersetzungen zu überschreiben. Am Beispiel von jk_poll kann dies so aussehen:

plugin.tx_jkpoll_pi1 {
 _LOCAL_LANG.de {
  submit_button = beliebiger Text
  votes_total = anderer Text
 }
 _LOCAL_LANG.en {
  submit_button = some text
  votes_total = another text
 }
}

Ich denke das Prinzip wird deutlich. Für andere Extensions müsste der Extension-Key (in diesem Fall "tx_jkpoll_pi1") angepasst und natürlich die richtigen Labels (in der locallang.php zu finden) genutzt werden. Die Sprache wird im Beispiel durch "_LOCAL_LANG.de" bzw. "_LOCAL_LANG.en" definiert.

Es ist doch faszinierend wie Sachen aus dem Zusammenhang gerissen werden. Heute abend wurde bei Planetopia die Sicherheitslücke von TYPO3 vom 10.02.09 so dargestellt, als ob sie erst letzte Wochen ausgenutzt wurde. Bekanntlich wurden ja "damals" die Seiten von Schalke 04 und dem Bundesinnenminister Wolfgang Schäuble durch die Lücke "gehackt" und die Inhalte verändert. Im Falle von Schalke 04 wurde berichtet das Kevin Kuranyi freigestellt worden sei. Planetopia formuliert das wie folgt: "Turbulente Tage auf Schalke. Beim Traditionsverein im Revier zählen Treffer auf dem Platz. Doch die landen immer öfter im Abseits. Erst der Rausschmiss des Managers, dann der Abschuss des Trainers – und Stürmerstar Kuranyi entlassen." (Zitat). Die Entlassung des Managers und Trainers fallen nur zeitlich gar nicht mit der Falschmeldung über Kuranyi zusammen. Aber wahrscheinlich lässt es sich so einfach besser verkaufen. Andere Formulierungen im Bericht machen explizit Open-Source als Problem aus: "Doch wie können die Hacker Homepages so verunstalten? Das Problem ist die Gratis-Software. Mit ihr werden Hunderttausende von Seiten gebaut." (Zitat). Mögliche Vorteile oder auch die Tatsache das nicht jeder der sich nicht um die Software kümmern (Updates einspielen) kann oder will, sie einsetzen sollte werden nicht erwähnt.

Interessantes Detail am Rande: Die Produktionsfirma von Planetopia,

News and Pictures Fernsehen GmbH &amp; Co. KG</a>, nutzt selbst TYPO3 als Content-Management-System. Ob die Seite auch sicher ist ;-)?</p>