Geef ons Volkswapens?

Paul Beliën zal ongetwijfeld achter deze amper verholen oproep tot zelfverdedigings-geweld staan, maar ik vind deze reclame voor de nieuwe Volkswagen Tiguan nogal … zum kotzen:

En wat zouden de “ventielterroristen” van Les Flagadas er van vinden dat de slogan quasi letterlijk uit een oud Humo-interview met enkele van hun activisten lijkt te komen:

De 4×4, dat is een uiting van pure arrogantie. Zo van: ‘De stad is een jungle, hier kom ik met mijn tank, allemaal opzij.’ Wij willen dat de stad aan de mensen wordt teruggeven.

Remove Facebook like buttons with NoScript

If you don’t like Facebook’s omnipresent Like widgets (there were already plenty of reasons why not to like them and last week’s cookie-debacle only added to that conclusion) and if you already use NoScript so you don’t want to install another plugin (like Ghostery, which reports any tracking activity and allows you to block it), you can put this in NoScript’s ABE user ruleset (NoScript Options -> advanced -> ABE);
# Allow Facebook scripts and objects to be included only
# from Facebook pages
Site .facebook.com .fbcdn.net .facebook.net
Accept from .facebook.com .fbcdn.net .facebook.net
Deny INCLUSION(SCRIPT, OBJ, SUBDOC)

This tells NoScript to allow Facebook scripts (you know, to visit facebook.com), but to stop them from being included in other sites. I guess with NoScript’s surrogate scripts one might even be able to replace Facebook’s Like-widget with one that just shows the old-fashioned (and harmless)  share-button. Now wouldn’t that be fun?

As found on the web (October 5th)

generic (feed #49)
generic (feed #50)
generic (feed #50)
generic (feed #50)
generic (feed #49)
generic (feed #49)
generic (feed #49)
generic (feed #49)
frank posted Introducing Aurora 9.
blog (feed #46)
youtube (feed #51)
generic (feed #49)
frank posted Improving app cache.
generic (feed #49)
frank posted Adobe buys Nitobi.

Ranting & Raving at Drupal Summit 2011

I attended Drupal Summit in Genk a couple of days ago and amidst the general “Drupal is the best thing since sliced bread” atmosphere, there were some interesting discussions about the platform’s maturity. Especially the presentations of Peter Van Den Broeck (for VRT) and Wouter Mertens (for competitor VMMA) seemed to be on opposite sides, with VMMA having multiple successful Drupal-sites in production and VRT struggling to get their projects finished, telling Captain Buytaert “Dries, we’re not there yet“. But underneath the surface and despite the differences (a dedicated team of sysadmins & developers at VMMA vs fixed price, project-based external development for VRT), both were talking about the same problems on a technical level; modules & performance.
The Drupal module community is a great bunch of enthusiastic developers, building an impressive number of modules that cover almost any feature one would want to have in a website. But module quality, support & compatibility varies enormously. Some modules seem to be true Rube Goldberg machines, providing tons of functionality that only few people need but which makes the the UI a usability-hell and the code complex, error-prone and possibly a real performance-hog.
And while we’re on the subject; performance doesn’t come out of the box and Drupal as such does not scale very well. Install it with a bunch of modules, generate a reasonable amount of page requests and you have a CPU-intensive system that generates a crapload of database-connections. Adding memcache between your Drupal & MySQL helps, as most requests will be handled from cache. And putting a caching reverse proxy (Varnish, Squid or even Apache’s mod_proxy+mod_cache if you insist) in front of your Drupal does miracles, serving visitors the same content without the need for Drupal to bootstrap. So sure, you can build a scalable solution that provides great performance, but one could say this is despite Drupal, not because of it. After all, when using Memcache & Varnish almost any CMS will have great performance, won’t it?
So yeah, Drupal can be a nice solution to your problem, but it does require more than just a superficial knowledge of how to install it together with some modules and a theme. Make sure there are smart people on your team or project, that have a profound knowledge of modules & module development and who know a lot about MySQL (and clustering, mirroring or master/slave setups), Memcache and Varnish (or Squid, forget about mod_cache if you can). You’re bound to run into some problems, as Peter Van Den Broeck confirmed, but with the right people and architecture your Drupal-project can indeed be the best thing since sliced bread.

As found on the web (September 28th)

generic (feed #49)
generic (feed #49)
generic (feed #49)
generic (feed #50)
blog (feed #46)
generic (feed #49)
youtube (feed #51)
blog (feed #46)
generic (feed #49)

Schotse electro oorwurm: Catharine van Rudi Zygadlo

Ik ben een ouwe lul, ik ben niet meer ècht mee en iedereen mag dat weten. Weet ik veel wat 2-step is. Of dubstep. Of post-dubstep. Maar nieuwe goeie muziek, dat lukt wel nog, soms. Zo hoorde ik in de aflevering van Gilles Peterson Worldwide die StuBru op 18 september uitzond, zo rond eerste half uur, vlak voor PJ Harvey, een ietwat bevreemdend nummer waarvan flarden bijzonder hard in m’n hoofd bleven hangen.
Het was wat zoeken naar de playlist, maar de Duisters van Radio X hadden die -in tegenstelling tot StuBru en Gilles Peterson zelf- wel online staan en m’n oorwurm bleek van ene Rudi Zygadlo te zijn. Die jonge Schot fabriceert dansbare electro in één of ander genre waarvan ik de naam al lang niet meer probeer te onthouden, maar die op z’n recente EP “Achtung!” met “Catharine” wel een héél sterke song neerzet. Grillig, dat ook, en met prachtige blazers-arrangementen (populair blijkbaar, zie ook “The Daily Mail” van Radiohead)!
Soit, “Catharine”, die klinkt zo:

Rudi Zygadlo - Catharine

Meer info over Rudi Zygadlo:

Learning from my mistakes about TLS, certificates and browsers

Well, I guess that, for those who read my previous post about SSL/TLS error messages on Mac OS X browsers, it’s abundantly clear that I don’t really know SSL/ TLS and the way browsers handle the certificates. But hey, I blog to learn from my mistakes and Philip and Peter helped me understand a bit about TLS with their useful comments.
The summary for TLS-dummies like me:

  • According to the TLS spec the server should not only provide it’s own certificate, but also any intermediate certificate between it’s own & the CA’s root
  • Browsers (or the OS’es key stores that some browsers depend upon) don’t ship with any intermediate certificate, but can and in some cases will store (cache) them when they come across them. In Firefox, cached intermediate certificates are listed as being part of the “software security device”, whereas root certificates are in the “builtin object token”.

All in all, this means that whenever you’re implementing TLS (or SSL, if you’re old-fashioned) you have  to configure your webserver to provide all intermediate certificates in a “chainfile” as (for example) per Apache’s SSLCertificateChainFile directive.

As found on the web (September 21st)

blog (feed #46)
youtube (feed #51)
generic (feed #49)
youtube (feed #51)
frank liked DJ CAM – Swim.
generic (feed #49)
blog (feed #46)
generic (feed #49)
frank posted Acid3 2011 Update.
generic (feed #49)
youtube (feed #51)
blog (feed #46)

How to fix SSL errors in Mac OS X browsers

So you know about SSL (or rather TLS) and you prefer things secure, so you request and pay for an officially signed certificate and configure your Apache to use it. The next days you’re feeling very Kevin Mitnicky, until some nitwit on Twitter trashes you for the ugly error-message he sees when trying to visit your supposedly “secure” site that is. What’s up with that?
Well, chances are that your disgruntled visitor was using a browser you didn’t test on, like Chrome on Mac for example? Because there is a small issue you have to take into account when “doing https”; both Chrome and Safari (but not Firefox) on Mac use OS X’s keychain, which does not have some of the intermediate certificates needed to establish the trust relationship between your signed certificate and the certificate authority’s root certificate.
As you can’t expect Apple to add intermediate certificates to their keychain by default (which Firefox does a pretty good job though) and you can’t ask all your OS X users to add the intermediate certificate by hand either,  you’ll have to solve this yourself. A good thing Apache can help you in that department with it’s SSLCertificateChainFile directive, which

sets the optional all-in-one file where you can assemble the certificates of Certification Authorities (CA) which form the certificate chain of the server certificate. This starts with the issuing CA certificate of the server certificate and can range up to the root CA certificate.

If there’s only one intermediate certificate missing between your’s and the CA’s, you can export it in good old Firefox (as a pem-file), place it in the same directory as the actual certificate and use SSLCertificateChainFile to tell Apache where to find it and that should solve the nasty errors those Twittering Mac-heads get.