Chimera is now available in the new 0.6.0 version. A very nice and fast browser based on Mozilla but with a Cocoa interface. Every Mac OS X user should take a look at it. Especially with large forms (e.g. the news list in Radio Userland), it handles things significantly faster than other browsers. However, the text edit field is a bit slow; the cursor lags a bit during input. Strange, but they'll probably get that under control too.
Found at VersionTracker.com - Mac OS X.
Compile Nightly, Run Faster - well. Nice idea, but for me it's a clear indication that it's high time today's programmers learned a bit more about their craft. After all, the idea of putting bytecode compilation into "the evening hours" is pretty silly - I still prefer to keep compilation using tried and tested methods on a normal developer machine.
Just-in-Time compilers are a nice thing for languages that build on bytecode and where the target platform isn't clear beforehand, so compilation is better done on the user's machine at the time of use. But if you're already planning a batch compile run on the server machine (which can only compile for that server machine anyway, so it addresses quite different issues than a JIT), then for heaven's sake do it where it belongs, namely on the developer's machine.
Strange. Java really does spoil one's sense of programming. And something like this on advogato - well, at least the author didn't know the "locate" command either ...
Found on Advogato.
What no one from Münster could imagine seems to be happening after all. Following the now beginning investigations against Jürgen Möllemann and the discussion about party expulsion proceedings, the political comeback kid might finally experience a landing from which he doesn't bounce back. Well, maybe he still has an extra parachute in his luggage. Oh no, don't say that ...
Found at tagesschau im Internet.
Found at tagesschau im Internet.
On photo.net is an (English) review of the Hasselblad H1 by Michael Reichmann (operator of Luminous Landscape). Michael's tests are always quite refreshing because, unlike many other reviewers, he doesn't focus on features and specifications, but instead engages more with proper photography. Real user reports, basically.
Squid annoyed me. Again. I had the experience that Squid pings servers even though it shouldn't do. Ok, annoying, but you can cope with that (although it produces timeouts from time to time).
I can live with squid sending out requests two or more times even though there really isn't a need to - looks like it's internal GET processing get's fucked up when some timeout on browser-side occurs.
But what really did it for me was it's stupid HEAD handling. It caches HEAD requests. Yeah, stupid idea, they were originally invented for bandwidth saving requests. They are supposed to go out and check the server, and not be cached, because if the document didn't change the client won't need to fetch it, but it needs to know wether it changed at all.
Ok, set up an acl rule for HEAD methods and set it no_cache (actually what braindead idiot invented the "no cache deny ACL" syntax with ACL describing pages that should actually not be cached? This is arse backwards two times!). Should work. Doesn't work. If there was a GET or POST request before, a HEAD will deliver data from the cache, even though it was set no cache. Stupid. Bad. Ugly.
So now I had to come up with an additional rule to suppress only those GET requests that may lead to bad HEAD requests (luckily this was possible because I was having Problems with AmphetaDesk and it's updates, and AmphetaDesk fills in the Browser name). So now I don't cache HEAD requests and don't cache results for AmphetaDesk. Does it work? Not really, if there are still documents in the cache of squid, it delivers HEAD from those documents, regardless of configuration. Damn.
So I had to remove them. That's what the PURGE method is for, right? Wrong. PURGE only purges Documents, not cached headers. So you first have to GET the document, than to PURGE it, to remove it's cached HEAD requests. Oh-my-god.
And now I still have some TCP MEM HIT in the log, although it shouldn't cache. Looks like it handles memory caching different than disc caching. Oh, and this is reproduceable with 2.2 and 2.4. Damn. Sucker.
Couldn't live be made actually easier for sysadmins? Please?