-
Murray talks about why showing /tmp in file dialogs is evil. The file chooser appearing in /tmp is a special case of the more general navigation problems that we have: programs have different policies for which directory to show initially in the file chooser, and so file dialogs end up being completely unpredictable.
-
Via Robert, Phishing Tips and Techniques. Or, why the user interfaces for security are terrible. This is seven years after the classic Why Johnny Can't Encrypt, or why the unusability of security apps keeps people from sending secure mail.
-
... And Zack has a follow-up to his Qt vs. Cairo article. Thanks to Ben Meyer for the link.
-
Wooo, gconf-diff! We can finally use this to clean up a really old ~/.gconf. I certainly have a cluttered one, from carrying over the same $HOME since GNOME 1.x.
-
Hans Petter digs into the International Republican Institute, which seems to have provided the PAN (the political party of the Mexican catholic right) with know-how on how to pull a Florida.
-
Do you have a Thinkpad with a Hidden Protected Area in the hard drive, and the laptop resumes from suspend-to-RAM with IDE errors? There's a kernel bug about HPA needing to be reset after suspend/resume, with a patch.
-
Dave: you will enjoy reading A Pattern Language, by Christopher Alexander (that site is just a summary of all the patterns; you really want the book, which gives you detailed explanations and rationales for each pattern). Some patterns that will interest you: Work Community, Street Café, Traveller's Inn.
-
Speaking of architectural patterns, Oralia and I are using that book as a guide to expand our house, which is currently a small one-floor home overflowing with books and trinkets. The book explains a beautiful philosophy of building and living in general: it's not just about one's house, but about how to design good neighborhoods, good towns, good offices, and good infrastructures for society in general. For matters of construction, we are using the Handbook of the Barefoot Architect, by Johan Van Lengen. This is an incredible book about building comfortable houses and small buildings using unsophisticated materials and processes, all centered around sustainable development.
-
Our house is in the middle of a sprawling suburb which fortunately still has a few green areas. The sprawl is getting populated quickly, and the infrastructure for potable water has had trouble keeping up.
Last week, on Friday, a water main was damaged during the construction of (yet another) road near where we live. They cut off the water supply and haven't fully restored it yet; it goes on and off. Our neighborhood (Jacarandas) wasn't as unlucky as the one next to it (Bugambilias), where there is still no water. Two days ago we went to help the people there carry water from a water truck to their homes, using buckets and whatever containers they had available.
It's ironic (or simply terrible planning) that it rains a lot where we live, and the water infrastructure cannot keep up with the population. So, our next project is to build an underground cistern that will collect rainwater for our home.
-
Dear Lazyweb,
On this green earth I am the last human being that doesn't own a cell phone. I am in the perilous and angst-inducing situation of having to get one.
What's a phone with these indispensable features:
- Good reception.
- No protruding parts such as antennas. Think "convex shape". This rules out clamshells.
- Doesn't feel like it will disintegrate if I drop it on the floor.
- Good user interface. This includes a good keypad.
Features that would be nice, but won't rule out a phone if it doesn't have them:
- Good battery life.
- Will send/receive SMS to/from Mexico if I'm traveling abroad.
- Nokia. Then I can share chargers with Oralia.
- Comes with a stock ringtone that resembles an old-style mechanical phone, not some shitty music that makes me think of a Commodore 64.
Stuff which I don't care about:
- Camera.
- Bluetooth [or should I care? Is there anything intersting you can do with it and that won't take more than 5 seconds of configuring anything?]
- Java / mp3 / games / blahblah.
-
Google maps now has enough resolution to show our house. On the south-west of our house there's some undeveloped land (the green part in that map) where cows and donkeys graze happily (this is much better than our old rental apartment, which was in the noisiest intersection in the world. Hans Petter, not far from our house, is surrounded by an old coffee plantation. (Thanks to HPJ for the coordinates!)
-
A logging infrastructure for Nautilus
Now that SLED 10 is out and our customers are using it, we are getting a steady stream of bug reports. I've been dealing with bugs in Nautilus.
Nautilus is a big, complex beast and like any file manager, it gets abused in all sorts of ways. Sometimes it crashes and that's really bad, since Nautilus is the main shell through which users interact with their files. It makes people nervous to see that the thing which manages their precious data keeps crashing.
I've been getting bug reports for some crashes that are really hard or just impossible to reproduce, either by me or by the customer. They'll say, "I was browsing many SMB shares and then it crashed". By now the basic code paths have been exercised well enough that the cause for crashes is totally non-obvious. Not being able to reproduce bugs leads to voodoo patches, such as "there's this patch upstream which is peripherally related to the code in which you crashed" — but that's not trustworthy at all, since you didn't have a series of actions to make the bug happen at will anyway. Thus, there's no way to ensure that the patch actually fixes the bug.
So, I've started adding a logging mechanism for Nautilus. It is based on the ideas from the paper "Using Ring Buffer Logging to Help Find Bugs", by testing guru Brian Marick. Now, a ring buffer is pretty trivial (even the Linux kernel uses one for its log messages). The interesting thing about the paper is that it tells you what to log and where to add different kinds of log messages.
You log user actions, since they give you the best chance of being able to reproduce the bug — users never really remember exactly the sequence of steps they took to do something.
Then, you log interface crossings. Individual modules are usually well-debugged, but it is the interactions between them that tend to be flaky: gnome-vfs passes stuff to the Nautilus async layer, which passes stuff to the views, which request more info from the async layer... So, you log when there are important crossing points between modules: the beginning and end of operations, important callbacks, etc. You also add various levels of logging so that you can get a short but useful log initially, and request a more detailed log as you dig into a particular bug.
One final idea from the paper: you let the user dump the log at will, so he'll do it whenever he spots that something is wrong with the program. You also dump the log automatically whenever the program detects an error, such as an assertion failure, crash, exception, etc.
My first cut of the logging patch is here. I have a slightly newer version which I'll post soon.
I wonder if we should polish this and push it down to Glib. There's g_log() and friends already, but somehow I feel that they need a little more work to be really convenient for users. In any case, it's not the logging infrastructure that is interesting; the good stuff is the actual points in the code where stuff gets logged, and also the ease with which end users can get logs sent to bugzilla at the right time.
-
Vlad plays with graphing Mozilla performance automatically. This is pretty cool; we could probably adapt some of his charts to various hotspots in GNOME, and the tinderboxes would run the tests.