cat /dev/braindump

Amazon.de war mir bis jetzt immer als Onlinehändler mit außergewöhnlich gutem Service in Erinnerung. Bis jetzt. Wäre da nicht der Fall meines Motorola Milestone gewesen, das in der Blüte seiner Jugend bereits vorzeitige Alterserscheinungen in Form eines Wackelkonakts am Kopfhöreranschluss entwickelte.

Ein klarer Gewährleistungsfall - das sieht auch Amazon.de so -, den man allerdings gerne mittels eines speziellen Service-Dienstleisters, der Firma w-support, abwickeln möchte. Dorthin solle ich mein Telefon zur Reparatur einschicken, teilt man mir per E-Mail mit. Von einem zuvor am Telefon avisierten Vorabaustausch möchte man plötzlich nichts mehr wissen. Nun gut, ich kann ja verstehen, dass auch Amazon den Gesetzen der Betriebswirtschaft unterliegt und kosteneffizient arbeiten möchte, also rufe ich vorab bei w-support an und erkundige mich nach der zu erwartenden Reparaturdauer: Eine Auskunft auf meine Frage habe ich dort leider nicht erhalten. Man repariere nämlich gar keine Motorola-Geräte mehr (bzw. dürfe das nicht mehr - das war nur zwischen den Zeilen herauszuhören), sondern könne das Gerät nur an einen weiteren Service-Partner weiterleiten. Auf die Frage, ob es denn Erfahrungen mit der zu erwartenden Reparaturdauer gebe, reagierte man sehr ausweichend, obwohl ich mehrfach erwähnte, dass es mir lediglich um einen Erfahrungswert und nicht um eine garantierte Bearbeitungsdauer gehe. Man mahne den Dienstleister allerdings nach zwei Wochen Bearbeitungsdauer an, verplapperte sich der Mitarbeiter in einer Tonlage, die darauf schließen lässt, dass dies häufiger nötig ist. Kein Wunder, wenn man sich so die zu erwartende Reparaturdauer bei Motorola-Geräten (wegen des gleichen Defekts) betrachtet, die laut meinen Recherchen in einschlägigen Foren auch gerne mal länger als fünf Wochen in Anspruch nehmen.

Tja, schade eigentlich, Amazon. Fünf Wochen (and counting) für ein Gerät, für das ich 460 EUR bezahlt habe und das ich bis 31. Januar problemlos und ohne Begründung ihm Rahmen der Rücknahmegarantie hätte zurückschicken können, das halte ich für deutlich zu lang.

So werde ich zwar in den sauren Apfel beißen müssen, um wieder an ein funktionsfähiges Gerät zu gelangen, werde mir aber in Zukunft wohl sehr genau überlegen, wo ich meine Elektronikartikel kaufe. Amazon ist jedenfalls ein ganzes Stück in der Rangliste nach unten gerutscht.

Update: Es geht weiter: Teil 2, Teil 3

Guess what language the invoicing solution that printed the invoice shown above has been written in…

Lately, I have been playing around a lot with Ruby on Rails and am currently finishing my first full-fledged application. While I am using WEBrick directly launched from my Eclipse development IDE in my development environment the production site is currently using Apache + mod_fcgi to run the application. This is where all the problems started. ;-)

The application sends out e-mail notifications (using ActionMailer) for various state transitions, which worked flawlessly on the development machine. In the production setting, however, sending mails failed complaining that it cannot find the associated mail template:

ActionView::MissingTemplate (Missing template event_mailer/approval_requested_notification.erb in view path app/views): app/models/event_observer.rb:3:in `after_enter_awaiting_approval' /usr/lib/ruby/1.8/observer.rb:185:in `notify_observers' /usr/lib/ruby/1.8/observer.rb:184:in `each' /usr/lib/ruby/1.8/observer.rb:184:in `notify_observers' (eval):10:in `create_or_update_without_callbacks' app/controllers/event_controller.rb:71:in `request_approval' public/dispatch.fcgi:24

Well, after putting some thought into possible differences between development and production and ruling out any relevant configuration differences in config/* all that remained was the fact that dev uses WEBrick while production uses mod_fcgi. One thought lead to another and it turned out that WEBrick sets the application root as the current working directory during startup while mod_fcgi does not.

So, the workaround is simple: Set the current working directory to the application root in config/environment.rb, such as:

Dir.chdir(File.dirname(__FILE__) << '/../')

Da stand ich und richtete meinen Blick nach oben. Lauter kleine funkelnde Sterne. Millionen von Lichtjahren entfernt. Doch irgendetwas stimmte nicht. Ich wusste nur noch nicht, was. Sonderbar grün waren sie alle. Das hatte ich so noch nicht gesehen. Langsam wurde mir klar: Das ist nicht der Sternenhimmel, den du da siehst. Das ist dein neuer Monitor!

Für’s Protokoll: Mein neuer 24-Zöller, ein HP LP2475w, hat zwei tote rote Subpixel (einen am unteren Bildschirmrand, einen in der Mitte) und geht damit postwendend an den Händler zurück.

Und nun hoffe ich, dass ich ein Montagsgerät erwischt habe und das nächste Exemplar Pixelfehler-frei ist. Bis auf die Pixelfehlerproblematik konnte der Monitor auf den ersten Blick nämlich durchaus überzeugen.

Auf der Petitionsseite des Deutschen Bundestags läuft seit heute eine Petition gegen den Einsatz von Ganzkörperscannern auf deutschen Flughäfen. Zur Mitzeichnung geht es hier.

As a happy long-term user of the Password Hasher extension for Mozilla Firefox I got used to being able to use different secure passwords per web site without having to take the burden of remembering them all.

When I recently bought an Android-based smartphone I was missing most of that convenience while surfing the Internet from my smartphone as Password Hasher was not available natively on that platform.

Hash It!, an application for the Android platform I developed, is there to bridge this gap: It eases using unique passwords per web site without overloading your brain by generating site-specific passwords derived from a secret master key. It maintains compatibility with the Password Hasher Firefox extension.

Hash It! is free (as in speech) open source software released under the GPLv3 with the source code being available on GitHub.

Further details on how to download it to your mobile phone are available at: http://android.ginkel.com/

Enjoy!

At 26C3 there were a couple of pretty interesting talks dealing with GSM security and how it can be easily broken through active (IMSI catching) and passive (rainbow table attacks on the A5/1 cipher) attacks.

Now, researcher’s are pushing to phase out GSM’s A5/1 cipher replacing it with modern, non-proprietary cryptography as countermeasure to the weaknesses facilitating A5/1’s susceptibility to passive eavesdropping. While this is certainly not a bad idea, it will end up with all but secure GSM calls considering that for GSM calls only the wireless interface benefits from the encryption. It will prevent John Doe from listening to your GSM calls using a wiretapping device placed in front of your apartment, but by no means will it lead to end-to-end security for GSM calls.

So, instead of attacking the wireless interface a malicious hacker would have to turn to the (fixed) telephone network to get hold of your calls.

In the end, only end-to-end encryption of calls will be able to prevent such attacks, so this is IMHO what we should be striving for in the long run.

…wähnt man sich, wenn so elementare Dinge wie GSM nicht mehr funktionieren. So seit gestern in Heidelberg der Fall, wo nach meiner unmaßgeblichen Meinung die E-Plus-Basisstation in der Humboldtstraße ausgefallen sein dürfte. Mal schauen, wie lange Simyo (mein Vertragspartner) bzw. E-Plus brauchen, um das Problem zu beheben. Ich hoffe allerdings, dass sie nicht erst einen Techniker aus China einfliegen müssen. ;-)