January 15th, 2008
Since I started playing with Javascript about a year ago I became aware of a pretty large number of Javascript libraries that offer additional functions or even widgets for a nicer user interface. I had started with prototype/script.aculo.us because it was included by Pylons. But when I found out that I’m not really bound to it I started looking around in my usual pointless search for “the perfect tool” ™. Finally I stranded with jQuery and I fell in love with it quickly. Give me results quickly and I’m willing to dig into the more subtle parts of something.
Sure, other people told me that jQuery is lame and Dojo is it or YUI (the Yahoo UI library) or even ExtJS. ExtJS? Yes, I looked at that before. Very impressive demos like the “Web Desktop”. I didn’t want to write anything like that though so I enjoyed it as a proof-of-concept and was done with it. But somehow one of my current projects requires a “grid” - that is a table that acts as a paginator (you get shown chunks of data and can navigate back and forth) but allows you to select rows and run actions. Perhaps I would also need a tree view. ExtJS supported all that so I dumped jQuery for a moment and created a (Mercurial) branch of my project to try out ExtJS.
There were instantly a few things I didn’t like. The whole Javascript was 500 KB large. Hardly something I could use on a production web site. Imagine a >500 KB start page. I also had to throw away my CSS for a moment and use their stylesheet - with 850 not-documented classes. Anyway - I surrendered to that and started playing with ExtJS. Strangely loading the page took 10 seconds in Firefox. After some research I found out that there was a bug in FireBug (a Firefox extension that web developers can hardly live without) with large Javascript files. Yes, 500 KB is large. Finally I found a hacked version of it that disabled a few features just to work better with ExtJS.
So finally my application loaded the Ext-all.js (the documented order and list of files I had to include was wrong) and could copy/paste a grid example into my application. One day later it worked. I had defined Stores, Proxies, ColumnModels, Actions, GridPanels and PagingToolbars and after 150 lines of Javascript I finally loaded JSON data from my web service (running on Pylons) and had the grid fill with it. I better hadn’t looked into the generated HTML - made me dizzy looking at all the nested DIVs and TABLEs. My Pylons code was just 5-10 lines though. It was an adventure of surfing through the API documentation of ExtJS that is complete but unusable to me. It defines all possible parameters and options but those are inherited from one another, some aren’t documented because they are “common” and you hardly get an impression on what they mean or how to use them. There were nice examples and everything they did was well documented. But that didn’t help me do more than that. Even doing server-side sorting of the JSON data meant firing up FireBug and watching the parameters - I had expected that to be documented somewhere.
Finally I decided not to work with ExtJS any more. If my application consists of 90-95% Javascript and 5-10% Python/Pylons then I’m not spending my time as intended. Using ExtJS basically means surrendering to it. Just use their library and style sheet and change as little as possible. 500 KB Javascript and 850 CSS styles are pure bloat. And while their license is basically the LGPL they have some weird additional clauses in their license like you can’t use their theme graphics and styles outside of the ExtJS context. I understand that a library of such a quality can’t be maintained by a handful of volunteers. So I see that they want to make money with it if others start making money with it. But somehow it was too much legal stuff for me. I prefer software that is just free. MIT or BSD. Or even GPL - I don’t mind. (Everytime you complain about the complicated licensing you are pointed to their license consultants to convince you.
).
It’s a great library. It has great widgets. It even creates HTML that is strictly valid in all browsers I could find. But I was not ready to surrender my application to ExtJS. I wanted a grid to support my application. Fortunately I didn’t have to reinvent the wheel because Matt Knight has recently published his Ingrid grid plugin for jQuery serving me well. And another (ridiculous) point for jQuery: it has mailing lists. ExtJS has a web forum. I hate web forums. Some people say mailing lists are archaic. But I can delete threads or blacklist people or reply properly in a text format. Morale: the flashiest isn’t always the best - neither for the user nor for the developer.
Posted in Work, Open-Source, Pylons, Programming | 1 Comment »
December 30th, 2007
My wife is a pretty good paintress and for Xmas painted a Debian logo at the wall of my basement terminal room. Now that’s comfy. 
Posted in Debian, House | 6 Comments »
December 22nd, 2007
Just wanted to drop a tip on you about the Firefox keyword search feature. I use it to quickly access packages.debian.org on package information or to retrieve the BTS page for a bug number. With it you can use “bts 123456″ instead of “http://bugs.debian.org/123456″. May not appear much shorter but I like it anyway. Here an example on how to add a search keyword for packages.debian.org:
- Locate a search form (like on packages.debian.org), set all the select options like you want (e.g. only package in “unstable” and from “main”) and then right-click on the actual text field where you enter the search query and select “add a keyword for this search”:

- Give the bookmark a name (does not matter) and the keyword (should be short):

- Now you can use that keyword in the location bar (where you normally type the URL you want to surf to) and add the word that you search for:

- You will be redirected to http://packages.debian.org/search?searchon=contents&keywords=cream&mode=path&suite=stable&arch=any
So basically getting the package page for this “cream” package means pressing Ctrl-L to highlight the location bar and just enter “pdo cream” and pressing Enter.
For me that was the second most valuable tip when using Firefox. The best tip would probably be how to make that monster take less than 10 seconds to react to mouse clicks on the menus when you have 20 tabs open simultaneously and to consume less than ridiculous 500 MB RAM or freeze up every minute when you use flashy sites like youtube. I really wish 3.x will finally fix that.
P.S. I wonder why wordpress shrinks all my images. I hope you can still guess what I meant.
Posted in Work, Debian, Open-Source, Find | 3 Comments »
December 17th, 2007
Now this has really been a waste of time. Months ago I convinced myself that NIS isn’t really a modern way to keep my user accounts network-wide - be it even only my home network. So I tried libnss-ldap and read wiki.debian.org on LDAP and literally found dozens of documents that describe how to do LDAP authentication for your users with NSS. Unfortunately most of them didn’t work for me. But finally I managed to get it working (after a few days) and was happy.
And then came the day that I decided to install Etch’s security updates and upgraded libnss-ldap 251-7.5 to 251-7.5etch1 in the process. Everything seemed to work well and I could log in. Just that Postfix somehow refused to deliver mails locally any more. The “local” daemon died repeatedly. After some careful Postfix debugging I found that I get a traceback that ended with “0×404841d8 in ?? () from /lib/libnss_ldap.so.2″. To cut a long story short: the upgrade set a “binddn” in the “libnss-ldap.conf” but no “bindpw”. But what really seemed to get Postfix mad was that the “libnss-ldap.conf” wasn’t readable for all any more (0600). Apparently the current libnss-ldap package in Sid sets that permissions right but on Etch that has really broken things. Recommendation from #postfix: “dont you never ever let debconf manage LDAP”. Not good.
No idea how that happened as I’m pretty new to nss and ldap but I wished I could have spent that evening differently. So in case anyone else happens to encounter “postfix/qmgr[10043]: warning: premature end-of-input on private/local socket while reading input attribute name” then try to “chmod a+r /etc/libnss-ldap.conf”. Just check that you don’t have a bind password in there.
Once I fully understand that I’ll check if I can contribute to the Debian wiki article or was just too dumb. If I were sure what’s going on I’d file a bug report, too.
Posted in Debian | 2 Comments »
December 2nd, 2007
Time and again I find myself in a hot discussion with others who claim that security by obscurity is a bad thing. SbO means gaining safety by hiding things. Don’t get me wrong - I love open-source software and although I have never taken a look at the Linux or Firefox source code I trust it way more than Windows and the Internet Explorer (that are even less functional). But it’s with no doubt harder to find security bugs in something that you can’t look into. Playing around with different HTML pages thus finding ways to exploit the application is surely harder with the IE than by analysing Firefox’ source code. And what about your password? You are hiding your password from me. Does it make your data safe? Or the PIN code of your credit card? Or why do people run a knockd to protect access to their servers? Those are just various degrees of security gained by keeping information to yourself. I don’t think there is much difference in whether the secret is a password or some piece of code.
In my humble opinion there are hardly any cases where security is not gained by obscurity. With PGP for example. I believe in mathematical one-way functions. My passwords are way safer in a PGP-encrypted file than by putting them into a file at /usr/lib/nobodyfindsme.so.3. And even with PGP you could argue that it’s just knowledge that someone else does not have that protects your information. But my PGP passphrase is way more complicated than my usual account password. And the private key it protects is insanely large. So I consider these to be an acceptable security measure.
The discussion arised when I received complaints that the source code of the CGIs used for mentors.debian.net was not made public. When I tidied up the code and published it finally I suddenly found a secret password in the code and quickly removed it.
mentors.debian.net hasn’t been hacked in years but now that the sources are publicly available I fear for that a tiny bit. The next projects that will be made open-source will be available publicly right from the start so that people may rather help me close security bugs. It would at least make me feel better.
There is but one argument that I would agree upon: it’s silly to rely on SbO.
Posted in Open-Source, Programming, Security | No Comments »