Da ich bei einem Kunden bereits einen DAViCal-Server betreibe, dort allerdings die Performance nicht allzu berauschend ist, habe ich vor, in den nächsten zwei Wochen einen kleinen "Benchmark"-Test mit folgenden Kandidaten durchzuführen:

• Bedework
  
• Chandler
• Darwin Calendar Server
• DAViCal

Interessant finde ich dabei das Chandler Projekt und Bedework, da beide anscheinend auch einen Webclient mitbringen.

Näheres hoffentlich in zwei Wochen.

Kommentare (1) »

Ich habe mich bis jetzt davor drücken können, Safari zu installieren.

Seit MacOS X bin ich mir ja leider nicht sicher, ob dieses Betriebssystem bzw. diese Hardwareplattform zu empfehlen ist. Aus ganz einfachen Gründen ...

• die Drucker-Administration ist eine Katastrohpe
• man kann kann mittlerweile systemrelevante Daten löschen (ist das wirklich ein Unixderivat?)
• macbaooks|ibooks sind nach 3 Jahren unzuverlässig (ich schreibe diesen beitrag auf einem 5 Jahre alten IBM Thinkpad ;)

Mir fallen wahrscheinlich noch ein paar Gründe ein.

Aber um eines klar zu stellen: ICH BIN KEIN APPLE HASSER!

Ich bin nur skeptisch. Und das seit Jahren.

Wie auch immer!

Ich habe heute zum 1. Mal Safari unter Windows installiert.

Kommentare (0) »

Nun endlich ist es so weit. Die Kommentarfunktion ist online. Leider noch ohne OpenID-Authetifizierung, da es  mir momentan etwas an Zeit fehlt.

Aber es gibt immerhin noch einen interessanten Link zum Thema Spam-Schutz für Kommentare.

http://googleblog.blogspot.com/2005/01/preventing-comment-spam.html

Kommentare (2) »

Das neue NIN-Album "Ghosts I - IV" liegt zum Download bereit und das DRM-frei und gratis. Zumindest die ersten 9 Tracks. Für alle 36 Tracks plus PDF sind US$ 5,- zu zahlen. Weiters gibts es eine CD-Variante und zwei Edition Packages.

Näheres unter: http://ghosts.nin.com

Kommentare (1) »

Ein lang andauerndes Problem ist nun endlich gelöst!

Der Produktivbetrieb eines Servers mit Apache, mod_perl und mod_php lag mir seit längerem im Magen. Zunächst lief alles problemlos. Es waren einige Websites mit PHP und eine größere Applikation getrieben unter mod_perl im Betrieb. Doch eines Tages lief das error.log-File von Apache mit segfaults über. Immer wieder starb ein Child-Prozess, was verkürzt ca. so aussah:

...
child pid 18912 exit signal Segmentation fault (11)
child pid 20058 exit signal Segmentation fault (11)
child pid 19400 exit signal Segmentation fault (11)
child pid 20276 exit signal Segmentation fault (11)
...

Es gab leider keinerlei Hinweise oder Möglichkeiten, dieses Verhalten zu reproduzieren. Die Analyse der Coredumps mit gdb und das nächtelange Durchforsten aller möglichen Foren und Newsgroups haben auch nichts ergeben. Und ein Update von Apache, mod_perl, mod_php und anderem war ebenfalls sinnlos.

Doch dann letzten Donnerstag, wars soweit. Genervt von diesem Problem habe ich mich nochmals auf die Suche nach einer Lösung begeben.

mod_perl and PHP don't share the environment nicely

Ein "uralt"-Eintrag, den ich bisher anscheinend ignoriert oder nicht gefunden habe.

Bevor ich irgendwas an der bestehenden Konfiguration bzw. dem Code der installierten Applikationen geändert habe, hat mich natürlich der Abschnitt "Reproducing the problem" interessiert. Also auf die Schnelle kompiliert, ausgeführt und: Nichts. Kein Coredump, gar nichts.

Frustriert hab ichs trotzdem probiert. Nach putenv in den PHP-files gegrept und siehe da im Code eines Projektes fand ich zwei Zeilen. Die waren auch erst zu einem späteren Zeitpunkt hinzugefügt worden. Schnell putenv gegen apache_setenv() getauscht und siehe da keine segfaults mehr.

Perl und mod_perl neu zu kompilieren hab ich erst gar nicht versucht.

Kommentare (0) »

• vorherige Seite
• • 1
  • 2