Tue 2008/Apr/22

• And now for a gratuitous baby picture.

  

Syndicated 2008-04-22 10:50:00 from Federico Mena-Quintero - Activity Log

Thu 2008/Apr/17

• Multiscreen hackfest for openSUSE

  </a>

  Here is a belated announcement for the multiscreen hackfest we are having at openSUSE this week and the next.

  Do you have multiple monitors connected to the same machine? A laptop and a projector or an external display? Do you get a lot of pain from trying to get it all to work?

  If so, be sure to participate in the multiscreen hackfest!

  Some work we are doing:

  • Integrate Søren Sandmann's, Bryce Harrington's, and James Westby's work for gnome-desktop, gnome-settings-daemon, and gnome-control-center so that the Display capplet will let you configure your multiple monitors easily.

  • Pay attention to all the bugs in X drivers that we run into while testing the configuration tools. Document any quirks that need to be set in xorg.conf by hand.

  • Fix all the bugs in applications when used in multiscreen mode ("I clicked on a button but the dialog appeared in the wrong monitor").

Syndicated 2008-04-17 15:26:00 from Federico Mena-Quintero - Activity Log

Tue 2008/Mar/25

• Projects for Summer of Code 2008

  This year I will mentor at most two of the following four projects:

  Making evolution-data-server's calendar smaller and faster (for GNOME). E-d-s was written in the very early days of Evolution, and it needs some profiling love. In this project you will profile the calendar part of e-d-s to make it use less memory, and be faster as well with an optimized query engine.

  Reducing memory fragmentation in GNOME (for GNOME). The GNOME platform libraries do many allocations of small objects. Your task will be to do an analysis of memory fragmentation, similar to what was done for Firefox 3.

  Making removable hard drives Just Work(tm) (for openSUSE). Currently, when you plug in a blank hard drive through USB, nothing happens. The device node gets created in /dev/sdb or whatever, but you don't see anything happen in your screen. Your task will be to improve things around HAL, PolicyKit, and gnome-volume-manager to detect this situation, and to make the right thing happen.

  Reliable unmounting of removable media (for openSUSE). When you want to unmount or eject a removable volume that is being used, you get a meaningless error message. There is no way to know which programs are still using the volume. Your task will be to make GNOME tell you which processes are using the volume, and give you a chance of killing them.

  If you are a student, please see GNOME's very nice page on information for students. This will be useful to you even if you choose one of the projects for openSUSE. Don't miss out on this great opportunity to become a well-recognized member of the free software community and win USD 4500!

Syndicated 2008-03-25 12:30:00 from Federico Mena-Quintero - Activity Log

Wed 2008/Mar/19

• Philip, you are looking at this from the viewpoint of email. Email, addressbooks, and calendars are pretty different beasts.

  Email has very particular access patterns, which are totally different from calendars and addressbooks.

  With email, the prevailing model is that you display a usually huge linear list of messages, and even the summarized information can be pretty big. Searching is Nontrivial(tm).

  In calendars, you almost always look at a subset of "events which occur in a certain range of dates", by virtue of the calendar's view (monthly/weekly/daily). Practically the only exception to this is when you want to do "show me events which contain $substring"; that's when you actually want to show a linear list of all the events that match.

  Evolution still doesn't get this right, by the way. If I'm thinking, "when did I meet with Joe?", I type "Joe" in the search box — but Evolution keeps showing the current monthly/weekly/daily view, and I have to manually fiddle with the date ranges to actually find which days contain the event I'm looking for. Substring searches should switch to the "list view" mode.

  Addressbooks are funny, because the access patterns for "my addressbook" and "my company's directory" are very different. Your addressbook contains at most a few hundred entries, and you may be able to deal with it comfortably by scrolling through a linear list, which is sorted by last name. You turn on searching when you don't remember a person's last name, so you type their first name in the search box.

  In contrast, your company's directory is potentially huge and you never want to show it as a linear list. You actually want to type a person's name in a search box, and then pick a match from a small list. (Something must be wrong somewhere, as people keep mailing me when they mean my colleague with the beautiful name).

  What does this have to do with evolution-data-server? E-d-s was always meant to be a local daemon to store your calendar and addressbook. It's the local Model in a Model/View split for all the processes which want to access your calendar/addressbook data. It was also meant to act as a local cache for remote calendars, which could be slow/huge/etc — that is, for stuff which is far away or not in the same scale as your own little appointments.

  I really don't know how much of that data gets duplicated in the daemon's clients, but if it is a lot, then the clients are doing something wrong. For example, a calendar event (VEVENT in iCalendar parlance) contains a lot of administrative crap: a UUID, a sequence number, a stringified timezone identifier, blah blah blah, in addition to the actual human-readable stuff that I can see in my calendar (summary, start/end times, alarms). Here's a complete VEVENT:

  BEGIN:VEVENT
  UID:20070925T174038Z-22251-100-1-25@cacharro
  DTSTAMP:20070925T174038Z
  DTSTART:20070926T160000Z
  DTEND:20070926T170000Z
  SEQUENCE:2
  SUMMARY:openSUSE project meeting #opensuse-project
  CLASS:PUBLIC
  TRANSP:OPAQUE
  CREATED:20070925T174109
  LAST-MODIFIED:20070925T174109
  BEGIN:VALARM
  X-EVOLUTION-ALARM-UID:20070925T174109Z-5309-100-1-13@cacharro
  DESCRIPTION:openSUSE project meeting #opensuse-project
  ACTION:DISPLAY
  TRIGGER;VALUE=DURATION;RELATED=START:-PT15M
  END:VALARM
  END:VEVENT
  

  That's 484 bytes of data, which is mostly fluff. These structures tend to explode in size when you parse them, but a neurotic calendar could keep the nice-and-small VEVENT string instead of a parsed structure, and re-parse it and re-generate it every time the event changes.

  And again: my local calendar, which goes back to 2001, only contains about 500 events, and is 670 KB in size. The craziest calendar I've seen is Michael's, which has a couple thousand events, but that's not even an order of magnitude larger than mine.

  Summary: there's no reason for e-d-s or calendar clients to have huge memory requirements; they are just doing something silly. You can keep a whole calendar, in memory, in less space than a fat JPEG from your digicam.

Syndicated 2008-03-19 13:30:00 from Federico Mena-Quintero - Activity Log

Tue 2008/Mar/18

• Ross posted about people wanting to write replacements for evolution-data-server, and I agree with him that doing so is a mistake.

  When we originally wrote Evolution, a lot of backend-ish things were left in a "we'll fix this later" state. It was more important to have a simple, working backend and a totally awesome frontend GUI, than to have a super-optimized backend and a shitty GUI.

  The code in e-d-s is a good example of something that could get a lot of easy love if people simply took the time to understand what is wrong with it in the first place.

  Some things that could be done to e-d-s reasonably easily:

  • Evolution-data-server has a reputation for becoming a very big process with a small resident size. On my box, pmap(1) says that e-d-s has a 14 MB heap with 12 MB resident. That's tiny by today's heap standards. However, there are 8 or so threads with an 8 MB stack each, which is of course not even used. An easy cure for people's fears of the total VM size would be to fix the size of the stack in the threads.

  • Avoid scanning the entire list of calendar events when someone makes a query. The most fundamental API in the e-d-s calendar is, "give me all the events that fall within $range_of_timestamps". For example, the Evolution calendar's week view will say, "give me all the events for the current week". E-d-s then goes and looks at all the events it knows about, sees if they intersect the specified time range (generating recurrences if needed), and builds a list of results. This makes each query run in O(num_events) time — nobody cleans up their old events, so this degrades pretty quickly over time!

    There are various ways to fix this. You could read the calendar.ics file into memory, but instead of storing a dumb linked list of events, you could store an interval tree based on the time range for events. An event that occurs only once has a range of [t1, t1 + duration]. An recurring event that repeats indefinitely has a range of [t1, ∞). If you are careful with the way you organize your data, you can avoid even looking at the memory pages for the event info, and just look at the pages where the interval tree is stored.

  • My calendar.ics file is 700 KB, and addressbook.db is 400 kb. So, why does e-d-s have a resident heap of 12 MB? "Use a database for the calendar" is total overkill, and less reliable than a simple text file. Someone needs to actually look at how much space e-d-s uses in memory for its various data structures, and then see why they become so big when loaded.

  When your bathroom becomes kind of dirty and gross, do you demolish it and build a new bathroom? No, you clean it up. It's a shame that software seems so easy to demolish and rebuild.

Syndicated 2008-03-18 14:38:00 from Federico Mena-Quintero - Activity Log