Chimera gibt es jetzt in der neuen 0.6.0-Version. Ein sehr schöner und schneller Browser auf der Basis von Mozilla aber mit einem Cocoa-Interface. Jeder Mac OS X User sollte sich den mal anschauen. Speziell mit grossen Formularen (z.B. der News-Liste in Radio Userland) kommt der deutlich fixer klar als anderer Browser. Allerdings ist das Textedit-Feld etwas lahm, der Cursor hinkt bei der Eingabe etwas nach. Komisch, aber das kriegen die wohl auch noch in den Griff.
Gefunden bei VersionTracker.com - Mac OS X.
Compile Nightly, Run Faster - tja. Nette Idee, aber für mich der klare Hinweis darauf das es dringend Zeit wird das heutige Programmierer mal ein bischen etwas über ihr Handwerk lernen. Immerhin ist die Idee den Compile von Bytecodes in "die Abendstunden" zu legen ziemlich albern - ich halte immer noch mehr davon den Compile mit altbewährten Mitteln auf einer normalen Entwicklermaschine zu halten.
Just-in-Time-Compiler sind eine nette Sache für Sprachen, die auf Bytecode aufbauen und bei denen die Zielplattform vorher nicht klar ist und deshalb der Compile besser auf der Maschine des Benutzers zum Zeitpunkt der Benutzung geschieht. Aber wenn man schon einen Batch-Compile-Lauf auf der Servermaschine einplant (der ja nur für die Servermanschine kompilieren kann, von daher auch ganz andere Themen als eine JIT adressiert), dann bitte verdammt noch mal da wo er hingehört, nämlich auf die Maschine des Entwicklers.
Strange. Java verdirbt wirklich den Sinn für die Programmierung. Und sowas auf advogato - naja, immerhin kannte der Schreiber auch den "locate" Befehl nicht ...
Gefunden bei Advogato.
Was sich kein Münsteraner vorstellen konnte, es kommt scheinbar doch dazu. Nach den jetzt beginnenden Ermittlungen gegen Jürgen Möllemann und der Diskussion um ein Parteiausschlussverfahren könnte es doch glatt für das Stehaufmännchen der Politik doch mal eine Landung geben, nach der er sich nicht berappelt. Naja, vielleicht hat er jetzt noch einen Zusatzfallschirm im Gepäck. Och nö, nicht nötigt ...
Gefunde bei der tagesschau im Internet.
Gefunden bei tagesschau im Internet.
Auf photo.net ist ein (englischer) Review der Hasselblad H1 von Michael Reichmann (Betreiber von Luminous Landscape). Michaels Tests sind immer recht erfrischend, weil er sich nicht wie viele andere Tester auf Features und Daten stürzt, sondern statt dessen sich mehr mit dem richtigen Fotografieren beschäftig. Halt echte User-Reports.
Squid hat mich wieder geärgert. Wieder einmal. Ich hatte das Erlebnis, dass Squid Server pingt, obwohl es das nicht tun sollte. Ok, ärgerlich, aber man kann damit leben (obwohl es von Zeit zu Zeit Timeouts verursacht).
Ich kann damit leben, dass Squid Anfragen zwei- oder mehrmals sendet, obwohl es wirklich keinen Grund dafür gibt - es scheint, als ob die interne GET-Verarbeitung durcheinander kommt, wenn auf der Browser-Seite ein Timeout auftritt.
Aber was mich wirklich auf die Palme gebracht hat, war die dumme HEAD-Handhabung. Es cached HEAD-Anfragen. Ja, dumme Idee, sie wurden ursprünglich für bandbreiten sparende Anfragen erfunden. Sie sollen rausgehen und den Server überprüfen und nicht gecached werden, weil wenn das Dokument sich nicht geändert hat, der Client es nicht abrufen muss, aber es muss wissen, ob es sich geändert hat.
Ok, richte eine ACL-Regel für HEAD-Methoden ein und setze sie auf no_cache (eigentlich, was für ein hirnloser Idiot hat die "no cache deny ACL"-Syntax mit ACLs erfunden, die Seiten beschreiben, die tatsächlich nicht gecached werden sollen? Das ist zweimal rückwärts!). Sollte funktionieren. Funktioniert nicht. Wenn es vorher eine GET- oder POST-Anfrage gab, liefert ein HEAD Daten aus dem Cache, obwohl es auf no_cache gesetzt wurde. Dumm. Schlecht. Hässlich.
Also musste ich eine zusätzliche Regel einführen, um nur die GET-Anfragen zu unterdrücken, die zu schlechten HEAD-Anfragen führen könnten (glücklicherweise war dies möglich, weil ich Probleme mit AmphetaDesk und seinen Updates hatte und AmphetaDesk den Browsernamen ausfüllt). Also cache ich jetzt keine HEAD-Anfragen und keine Ergebnisse für AmphetaDesk. Funktioniert es? Nicht wirklich, wenn es noch Dokumente im Cache von Squid gibt, liefert es HEAD von diesen Dokumenten, unabhängig von der Konfiguration. Verdammt.
Also musste ich sie entfernen. Dafür ist doch die PURGE-Methode da, oder? Falsch. PURGE löscht nur Dokumente, nicht gecachte Header. Also muss man zuerst das Dokument abrufen, dann es löschen, um seine gecachten HEAD-Anfragen zu entfernen. Oh-mein-Gott.
Und jetzt habe ich immer noch einige TCP MEM HIT im Log, obwohl es nicht cachen sollte. Es scheint, als ob es das Memory-Caching anders als das Disc-Caching handelt. Oh, und dies ist reproduzierbar mit 2.2 und 2.4. Verdammt. Mistkerl.
Könnte das Leben nicht eigentlich einfacher für Sysadmins gemacht werden? Bitte?
