So with the GPLv3 and LGPLv3 finally out (hurray!) it’s time to actually pay attention to the practical consequences of an upgrade to the world’s premier copyleft licenses. One of the things I hadn’t noticed, though I should have, is that the LGPLv3 is not compatible with the GPLv2 – that is, GPLv2 programs that used LGPLv2 libraries cannot make use of new versions of those libraries released under the LGPLv3 without also updating their license to GPLv3 (or “GPLv2 or above”, or LGPLv2 or LGPLv3 or something similar). Fortunately one of the major LGPLv2 libraries out there – glibc – is reportedly going to remain available under the LGPL v2.1 but for other libraries, it could become a problem, and it’s something GPLv2 authors will need to pay attention to. Also fortunately the opposite problem – GPLv3 apps using LGPLv2 libraries isn’t a problem, because the LGPLv2 explicitly allows redistribution and modification under the terms of GPLv2 or later, so you can take an LGPLv2 library and incorporate it in a GPLv3 application and just release the whole thing under the GPLv3. Unfortunately, the LGPLv3 doesn’t have a similar clause, so when the GPLv4 comes out, if it ever does, we could easily find the GPLv4 apps can’t use LGPLv3 libraries, and GPLv3 apps can’t use LGPLv4 libraries. Really these are side-effects of a fundamental change: up until now, almost everything we’ve distributed – and certainly all the low level stuff: the kernel, the C library, the compiler, the shell and basic tools – have all been under a GPLv2 compatible license. Some of them have been more flexible than that, due to being under a BSD or MIT license, or being under the LGPL or having a “GPLv2 or later” clause, but we’ve been essentially able to ignore all that and just treat everything as GPLv2. There are a few exceptions that we have to deal with – the occassional app that’s not GPL compatible doesn’t cause much of a problem, because things that depend on it don’t usually create copyleft issues, which just leaves checking that it doesn’t use any GPL-only libs, such as gnutls or libreadline. Openssl is a nuisance, in that it’s a popular, GPL-incompatible library, but it’s also reasonably easy to deal with on a case by case basis. But with the GPLv3, that changes: as GPLv3 apps and LGPLv3 libraries get uploaded, the assumption that more or less everything is GPLv2 compatible goes out the window, and while some things are GPLv2 only (such as the kernel!) we also can’t assume everything is GPLv3 compatible. Fortunately, both the GPLv2 and GPLv3 have what is known as the “system library” exception, which allows you to not bother distributing the source to your C compiler or C library or kernel with your app, because everyone’s assumed to have one of those already. Unfortunately, the GPLv2 version of that exception includes the phrase “unless that component itself accompanies the executable”, so Debian has always cautiously assumed the exception doesn’t apply to us, because everything we distribute in main “accompanies” everything else in main – kernel, C library, C compiler, etc. Equally unfortunately, while the GPLv3 avoids that problem, but ends up with a clause that’s not terribly comprehensible, despite a couple of rewrites during the drafting process. What’s all that mean? The big thing is that it means Debian’s going to have to put a bit more attention into the system library exception, both for GPLv2 and GPLv3 apps, because our current policy of trying to avoid needing it is probably not going to be sustainable. I’m not sure how in depth we’ll need to go for that; we’ve already contacted the FSF licensing folks for an explanation of the GPLv2 clause in relation to the CDDL, but it’s possible the FSF might prefer to be ambiguous in responding so as to keep their options open for defending or enforcing the GPL later, in which case we might need to get legal advice of our own as to what we should do. The second thing is that in reviewing our understanding of the system library exception, we might be in a position to have a Debian GNU/OpenSolaris port, making use of the exception for the CDDL-licensed OpenSolaris kernel and libc, as Nexenta do. That seems to me to be almost certainly possible for GPLv3 (or “GPLv2 or above”) applications, and probably possible for GPLv2 apps as well. If so, that’ll let us expand Debian to supporting four kernels in the near future: Linux, Hurd, FreeBSD and OpenSolaris, which will be pretty fun, in my book. The downside, is that if we find an interpretation of the system library exception that lets us mix and match licenses comfortably, that same interpretation might be able to be used to let propietary software vendors mix and match GPLed software with non-free software, rather than just free software with different copyleft licenses – and thus defeat the entire point of copyleft. What’s worse, is that by following Debian’s lead, they’d have some moral authority in doing that, beyond just having a legal argument as to why it’s okay. And that’s the rub. (My thoughts on the license texts as posted to -legal are here, here, here and here.)

Yesterday was pretty much a long day of preparation and presenting. The day started with no internet, possibly for the entire island of Kos, I wasn't really every that clear on the whole of it. Apparently there are 2 underwater lines coming to Kos island and both had been severed or put out of service by someone. This was a bad thing, because I had intended to finish some final experiments and do some statistics on results, and Excel wasn't working. I suspect it is because I hadn't installed the updating tool of Office 2004 for Mac. Anyway I could do what I needed to do with R or Gnumeric, but they were both not installed yet. No internet = no new applications.

I finished the experiments and data gathering and the internet came back on just in time for me to download Gnumeric and get some of the stats working correctly. The final presentation didn't change that much, only changing on one slide and adding one small table, but the added result was significant enough to justify all of the work that it entailed. Indeed, it proved that the entire premise of the paper and simulation was valid. That made me feel all warm and fuzzy inside.

The talk was at 3:30, the first in a session which was mostly unrelated papers. I don't feel as bad because many of the other papers were kind of a hodge-podge as well, and we were probably all placed in the session because we didn't really fit anywhere else. I met a nice researcher who was chairing the session because the actual chair was presenting in another session (something we had worked out with software in the ICRA2006 schedule, but apparently wasn't taken into account here). The actual presentation went well, and Nikos lent me his laser pointer which added a little to the presentation I believe. Nikos said the talk was good, but I also got a comment that it was well-presented later in the day from a unrelated researcher. I was so-so about the presentation until I got the unsolicited comment.

After the talk I called up Diana on Skype and chatted for a while, but the network was too flaky at the conference, so she called my cell phone. Using Skype is one of the things that I have done more in this trip than I have done before ever. It is really a wonderful program and network for people who are far away from each other, and it actually has much more impact when you consider the costs of calling home with other methods. I estimate I saved about $200 in just three days of Skype calling instead of regular calling, even with calling to cell phones in the US every once in a while, and with Diana calling my Hellenic cell phone when my network was flaky as well. It is much more of a disruptive technology in the non-US world where every call isn't already paid for.

The banquet was next. Usually I don't like going to banquets, but this was set up different than the normal ones that accompany these conferences. Instead of a large service crew bringing out fancy food to a large set of tables, it was setup in a buffet with a large selection of Greek food so you could pick and choose your favorites and even go back for more food if you liked. I ended up trying a large variety of foods and discovering some new tastes that I hadn't had before. It was throughly enjoyable especially when listening to the others at my table of which three or four were Greek.

Then it was back to the hotel by bus, and an early bedtime in order to stock up on sleep for the long hours in the next day. Today I plan on just relaxing, sleeping a bit when I get tired, and maybe trying out some local snacks. I've already arranged for a Taxi. The last installment will be written from the Athens airport tomorrow.

Comments: (0) Trackbacks: (0)

Comments

1. No comments

Trackbacks

1. No Trackbacks

I've been spending some time on the #bittorrent channel on Freenode, to see if I could get any good information from other bittorrent client developers. After some poor initial contact, I did get some good suggestions, as well as some tidbits of information I wasn't aware of. One of the tidbits was that most of the bittorrent client developers frowned on the use of selective downloading for torrents, to the point where some refuse to implement it in their clients (apparently the latest mainline client doesn't even have it, though I haven't checked due to license issues). This concerned me, as the DebTorrent client I'm working on will rely heavily on selective downloading to only download packages to be installed by the user. It's not clear to me that it would be an issue though. I'm sure it will make it more difficult to find a rare package in a large swarm of peers, but that's to be expected, and is nicely solved by using an HTTP download from a backup mirror. This backup downloading could become extreme though, making the bittorrent-like download (peer-to-peer) mostly just an HTTP download (client-server). To see if it will be a problem, I conducted a simulation of different sized swarms to determine the amount of unnecessary HTTP downloading that will occur. First, some assumptions to make the simulation easier:

• peers join and download sequentially and one at a time
• peers never leave
• peers download all the packages for their system at once (i.e. all fresh installs, no upgrades)
• peers are all interested in the same version and architecture of packages
• there are N total peers, and each can make C connections to other peers

With these assumptions, the simulation becomes quite simple. I used the popcon data to assign packages appropriately to the N peers. The peers download their assigned packages from the C previous peers, if possible, or otherwise by HTTP. I ran this multiple times, varying N and C, and calculating each time how much was downloaded through the debtorrent protocol, and how much through HTTP. This graph shows the percentage of the total download that used HTTP from a mirror. The optimal line shows the minimum possible (i.e. all peers are connected), which corresponds to only one copy (the first) of every package being downloaded using HTTP. This verifies my previous thinking, which is that fracturing the download population into multiple small swarms results in lots of inefficiencies, and lots of HTTP downloading. All efforts will need to be taken to keep the downloading populations together. (This is especially difficult for unstable, when a new swarm could be created twice a day due to archive updates.) Swarms of 1,000 peers or more seem to be sufficient to minimize the HTTP downloading. This graph shows the amount of unnecessary HTTP downloading that occurred, which is just the difference of each line from the optimal one in the previous plot. This shows the danger of selective downloading, as all of this unnecessary HTTP downloading occurs because the swarm is too big to find peers that have the desired package (they do exist). Fortunately, this unnecessary downloading seems to approach a maximum as the swarm size increases. For the large swarm sizes needed to make the downloading efficient, and assuming a reasonable number of connections of 100 (bittorrent defaults to maintaining at least 40, and large swarms usually means a large number of connections), we can expect to be using HTTP for about 4% of the download. This number is surprisingly low due to the popularity distribution of packages (only rare ones are hard to find, but they aren't downloaded very often). I think 4% is manageable in our situation, given that there is a backup method to find the rare packages, though it does show the need to have that backup method available. This is probably more of a problem for regular bittorrent clients, in which there is no backup method.

A comment on my previous post about my Linux Jobs Blog suggested that I shouldn’t fragment the information. However I believe that fragmenting the information is ideal due to the ability of RSS syndication to drive the cost of coalescing the information to almost zero! Currently there is a Linux job web site run by Linux Australia. It doesn’t have many adverts and isn’t even linked from the main Linux Australia web site. I believe that we can do better for the people who want Linux jobs and the people who have such jobs to advertise. If you have a central site the jobs have to be moderated (which takes work and delays listing), the larger the area that the site covers the greater the work is to do this. The solution is to have a distributed system with different people running listings for various regions and a syndication service to aggregate them. To start this I have created a blog which will have categories for the states and territories of Australia. Someone who is only interested in one region can visit the category for that region. Then recruiting agencies and companies which regularly hire Linux people can start their own RSS feeds to be syndicated in a planet instance for each state and territory. This gives a faster and more efficient response (adverts will appear quickly, can be changed or removed at any time, and less effort for moderation. I expect that recruiting agencies will occasionally post off-topic entries - but when their feed gets removed from the Planet installation they will probably make a commitment to do the right thing in future. Planet installations can syndicate other Planet installations, so we can easily have a Linux jobs Planet for Australia (possibly run by Linux Australia) that syndicates the feeds from each state and territory. In the long term I think that the best way of running this is to have Linux Australia run the central Planet instance and a LUG in each region run the local site. I started running it myself because I didn’t get a positive response when suggesting it to the relevant people in Linux Australia and LUV. That didn’t deter me, so I decided to set it up myself. If the idea takes off and if Linux Australia and the LUGs want to take it over I’ll be happy to use HTTP redirects to send the traffic to them - and help them with the sys-admin work if asked. Also there is nothing specific to Australia in this idea. I am only interested in Australia because if I was to attempt to do it in a larger area (such as the EU) then I could spend all my time on it without gaining a critical mass in any region. If you are interested in running this in your region then you need to set up a blog (for adverts that are sent to you via email) and a Planet installation that feeds from your blog and any other Linux job advert blogs in your region. If your country doesn’t already have a central Planet for jobs then creating a separate Planet installation for your country would be a good idea too. I will be happy to run a Planet installation for world-wide Linux job adverts (at least until I can convince an organization such as Linux International to run it) if this idea takes off in other countries. Some people have asked what the benefit of a Planet is over a mailing list. You have to subscribe to a mailing list while with a Planet you can immediately visit it if you suddenly decide to find a new job. Subscribing to mailing lists for jobs from all countries would never work, but visiting a Planet for Linux jobs world-wide and then visiting a sub-planet for regional jobs would be quick and easy.

Share This

Just a couple years ago, music and technology companies would advertise their DRM schemes. While these technologies only served to prevent users of computers and consumer electronics devices from doing things, the media and technologies companies tried to spin it positively. Think of all the wonderful media that the music, film, and publishing industries will be willing to distribute to you at the click of a button, they said. All they asked for in return is the keys to your computer and the legal right to attack and sue you if you try to take control. As everyone who purchased iTunes music and made the mistake of buying a non-Apple DAP incapable of reading Apple DRMed music knows, DRM is a bad deal for consumers. Users are always better off with an unencumbered media file. In all the excitement over major label content, some consumers didn't see this immediately. With time though, the inconvenience of a computer that does the Apple and the RIAA wants over what you want hit home. This, combined with activist projects like the FSF's Defective By Design, have turned the tide. The DRM label that used to be a badge of honor is now a stigma that smart companies are going out of their way to avoid. This past weekend, I saw this flier from Calabash Music in the crepe store across the street: The store served a general, non-technical audience. DRM-FREE, it turns out, is a good way to sell music. Not just to geeks but to any consumer who has been stymied unfairly by DRM or knows someone who has. That, it turns out, is a whole lot people. Consumers know what DRM is and they know don't like it. As consumers learn more about DRM, they want to avoid it. Seeing this, the companies that produce DRM are looking for ways to escape. The Apple/EMI deal seems to be an attempt to protect market share that the use of DRM is threatening. Others, like HBO's Bob Zitter, are disingenuously attempting to escape the stigma of DRM by simply rebranding the technology. Of course, DRM suffers from a much more fundemental problem than bad branding. The problem with DRM is that consumers don't like what it does and are only sometimes willing to suffer through it when not given the choice. Increasingly often, as with in the example of the flier I found, consumers have a choice. Things don't look good for DRM. For DRM opponents, the self-defeating nature of the technology is our greatest ally.

Last weekend, I was at the Amsterdam Lindy Exchange. Both my first trip to Amsterdam (A crazy place, I think you can get high just from walking the streets because of the smoke clouds coming out of the Coffee Shops... And I really wouldn't have thought the prostitutes are even in their windows on Sunday and Monday mornings ...) and my first Lindy Exchange [wikipedia].A lindy exchange is

a gathering of lindy hop dancers in one city for several days to experience the dance venues and styles of that local community, and to dance with visitors and locals alike

And it was fun. I didn't get a glimpse of 'typical' Amsterdam night life, because the evenings were already filled with dance events. We did a boat trip on sunday however, so I did do something typical for Amsterdam, too.Going to a different city to meet other dancers is a great thing to do. If you're a dancer, you should definitely do that. If you're not a dancer, you should become one. :-)My next lindy exchange will be in September: the Munich Lindy-Exchange, where I actually ended up in the organization crew. We're really trying hard to make that a great event. We'll be having some great parties. And we'll be going to Oktoberfest (aka "Munich beer festival") with you. And yes, we'll probably end up dancing there, too.

Just graduated… and now what? Well, I had the opportunity to choose among several options: a PhD position at the TU/e, a PhD position at Heriot-Watt University in Edinburgh, or pursue a job at Google. After much consideration, I have chosen the first option. I found it to be impossible to decide based on the research assignment or the people I would work with, so I looked at more personal and practical reasons which led me to my current decision. I will start my job on August 1, 2007 and hope to finish the PhD in 2011. My research will involve working on project MoCaP, Models of Computation: Automata and Process, in which we try to achieve a better integration of the concurrency theory with the classical theory of automata. The thought behind the project is to make undergraduate computer scientists more aware of concurrency theory.

Ben Green writes:

"All welcome to demo or watch, or get stuck in. 10am-4pm at the Trinity Centre Radio Studio BS2 0NW this Sunday 8th July. Please bring laptops and pluggable linux compatible sound kit. Small sets of speakers an headphones also good. We'll have access to 3 AMD64 machines with 64Studio installed. Please ask if you have any question, contact me through email or call Bristol Wireless to get other contact details, such as my mobile number. Entrance to the trinity will be through the back door, please be patient once you have rung as it's a long way from the radio studio to the back door. Ooo, and it's free. Cheers all, see you there."

(Seen on BBLUG)

With the development of rebuildd and the fact that several people are interested in re-using my scripts, I feel the need to explain how this stuff works. Grid’5000 First, Grid’5000 is a research platform used to study computer grids. It’s not really a grid (it doesn’t use all the classic grid middleware such as Globus). Grid’5000 is composed of 9 sites, each hosting from 1 to 3 clusters. Inside clusters, nodes are usually connected using gigabit ethernet, and sometimes another high speed network (Myrinet, Infiniband, etc). Clusters are connected using a dedicated 1OG ethernet network. Grid’5000 is in a big private network (you access it through special gateways), and one can access each node from any other node directly (no need for complex tunnelling). Using Grid’5000 nodes When you want to use some nodes on Grid’5000, you have to use a resource manager to say “I’d like to use 50 nodes for 10 hours”. Then your job starts. At that point, you can use a tool called KaDeploy to install your own system on all the nodes (think of it as “FAI for large clusters”). When KaDeploy finishes, the nodes are rebooted in your environment, and you can connect as root. At that point, you can basically break the nodes the way you want, since they will be restored at the end of your job. Running Debian QA tasks on Grid’5000 None of that was Debian-specific. I will now try to explain how QA tasks are run on Grid’5000. The scripts mentioned below are in the debcluster directory of the collab-qa SVN repository. When the nodes are ready, the first node is chosen to play a special role (it’s called the master node from now on). A script is run on the master node to prepare it. This consists in mounting a shared NFS directory, and run another script located on this shared NFS directory to install a few packages, configure some stuff, and start a script (masternode.rb) that will schedule the tasks on all the other nodes. masternode.rb is also responsible for preparing the other nodes. Which consists in mounting the same shared NFS directory, and executing a script (preparenode.rb) that installs a few packages and configures some stuff. After the nodes have been prepared, they are ready to execute tasks. To execute a task, masternode.rb connects to the node using ssh and executes a script in the shared directory. Those scripts are basically wrappers around lower-level tools. Examples are buildpackage.rb, and piuparts.rb. Now, some specific details:

• masternode.rb schedules tasks, not builds. Tasks are commands. So it is possible, in a single Grid’5000 job, to mix a piuparts test on Ubuntu and an archive rebuild on Debian. When another QA task is created, I just have to write another wrapper.
• Tasks are scheduled using “longest job first”. This doesn’t matter with piuparts tests (which are usually quite short) but is important for archive rebuilds: some packages take a very long time to build. If I want to rebuild all packages in about 10 hours, openoffice.org has to be the first build to start, since building openoffice.org takes about 10 hours itself… So one node will only build openoffice.org, and the other nodes will build the other packages.
• I use sbuild to build packages, not pbuilder. pbuilder’s algorithm to resolve build-dependencies is a bit broken (#141888, #215065). sbuild’s is broken as well (#395271, #422879, #272955, #403246), but at least it’s broken in the same way as the buildds’, so something that doesn’t build on sbuild won’t build on the buildds, and you can file bugs.
• I use schroot with “file” chroots. The tarballs are stored on the NFS directory. Which looks ineffective, but actually works very well and is very flexible. A tarball of a build environment is not that big, and this allows for a lot of flexibility and garantees that my build environment is always clean. If I want to build with a different dpkg-dev, I just have to:
  • cp sid32.tgz sid32-new.tgz
  • add the chroot to schroot.conf
  • tell buildpackage.rb to use sid32-new instead of sid32
• Logs and (if needed) resulting packages are written to the NFS directory.

Comments and questions welcomed :)

My mother-in-law just passed last night. During the 25 years I knew her, she became my "other mother" so you'll understand that I just feel like a huge hammer felt on my head. My Debian work will probably continue the same way, as a way to escape from the overall sadness and crying that will come during the next days and the support I'll try to bring to Elizabeth, my wife.

I have seen my life in the company of my GF, and is not bright, looking from my Debian work PoV.

Some early conclusions:

1. do whatever you can to have two computers in the house, otherwise yours will be arrested
2. using any spare moment will not gain your GF's simpathy
3. if there is slacking, it should happen with your GF, you can't affort slacking on your own
4. if you are, by nature, less needy for sleep, you should use those extra minutes you can get for free
   
5. it would be sooooo cool to get her hooked into "FLOSS" ;-)
   

Looked two third parts of movies this weeks. Started off with "Ocean's Thirteen". Was pretty nice and funny, including the usual strange dialogues between Danny and Rusty. The style of some parts of it was a bit too 70ties and psychadelic for me, though. Pretty worth watching anyway.
The second third part had been "Shrek the Third". Was quite worth it, and the way they picked on the King Arthur story and some other fairy tales was well done, too. Now I'm just looking forward to yet another third movie; though that one was originally planed and not done just because the previous ones were a success: The Bourne Ultimatum—I hope it will let me enjoy the evening, too. :)

We celebrated Leif's dedication a couple weekends ago on June 17th at the Unitarian Church of Montr al. I got permission from Diane Rollert, our minister, to post the text of it.

(LJ-cut used to keep it from being too long)


Dedication of Leif Alexander Bailey, June 17, 2007

To the Child:
Leif Alexander Bailey, you have come with stardust in your hair, with the rush of planets in your blood, your heart beating out the seasons of eternity, with a shining in your eyes like the sunlight.

Your parents have brought you here to be dedicated, to celebrate the joy they have and to count themselves blessed that you are a part of their family.

As you grow, may you come to love what it is that your parents and this community of Unitarian Universalists value. May you learn to count the number of your days, to weigh their meaning, to gather into your mind the wisdom of your ancestors, to know why we call one thing right and another wrong, and to treasure beauty, mercy and justice in the deepest places of your being.

To the Congregation:
A dedication in the Unitarian Universalist tradition is one of the few sacred rituals we share together as a community. It is a covenant, a promise of love and care, that the entire community bestows upon a child.
Although Leif and his parents are leaving us to pursue new lives in San Francisco, they have chosen to dedicate Leif here in this church that has meant so much to them. Their travels may take them far away, but in this act of dedication today, we will covenant to continue to hold a place of care and concern in our hearts for Leif as he grows. Do you, as this religious community called the Unitarian Church of Montreal, take upon yourselves the privilege and the responsibility of helping to nurture the character and spirit of this child even at a distance?

Congregational Response:
We who are members of this congregation rejoice with this family in the promise of this child. We pledge him now the love and care of this community.

To the Parents:
Angie and Jeff, parents of Leif, please repeat after me this pledge. Leif, we pledge to help you to realize the best that is in you. We will seek, to the best of our ability, to instruct you by our teaching and by our example. We promise to love you with an unselfish love.

To the Child:
Leif, I dedicate you to the service of goodness, beauty and truth. I touch you with this water, which is a symbol of purity, and with this rose which is a symbol of your unfolding life, on your brow, your eyes, your lips, your heart and your hands, that your thoughts, your vision, your speech, your love and your generosity may be dedicated to the care of the earth and its people. We dedicate you that the transcending power of all that is divine may be present in you all your life long.


Closing Prayer:
Spirit of Life and Transcending Source of Love that connects us all, bless this beautiful child Leif this day and all the days of his life. As we rejoice in the promise of Leif s life that stretches out before him, let us remember those no longer with us, especially Leif s grandmother Glennis Bailey who left this earth too soon to meet her grandson, but whose memory and spirit will continue on through him. May Leif continue to serve with strength as his life unfolds so that the richness and wonder of life may be abundantly his. May peace dwell in his heart,and understanding in his mind. May courage strengthen his will and may the love of truth forever guide him.

gimp-plugin-registry updated During the last days I've upgraded the gimp-plugin-registry package. Version 0.2-1 does not only fix a few smaller bugs, but also contains the following new plugins/scripts:

• Black and White Film Simulation:
  Converts the selected layer into Black and White using the channel mixer. Tries to produce results resembling tonal qualities of film.
• DBP:
  David's Batch Processor is a simple batch processing plugin for The Gimp - it allows the user to automatically perform operations (such as resize) on a collection of image files.
• Extended Borders:
  This script allows you to add double borders, add copyright notice and title, as well as decide fonts, font-sizes and positions of the title and copyright notice. Support for blurring the copyright and title is also included.

Please note that not all plugins will work with gimp 2.3 from experimental, therefore my next plan is to create a branch for experimental, which will not only include the proper changes for 2.3, but also include plugins which need the new gimp version to build/work. For example:

• Save for web
• Separate+

As usual, I'm searching for good plugins which should be added to the package - suggestions are welcome!

My wife was very excited to hear that debian will be celebrating the 10th anniversary of the Social Contract with a virtual pancake party. She could care less about the social contract, she's just happy to have an excuse to have me make her pancakes again. In any case, I thought I'd share my favorite recipe for pancake batter:

Oatmeal Pancakes	
2 eggs
4 T. veg. oil
1 3/4 cup buttermilk
1 cup all-purpose flour
1 cup rolled oats
3 Tbl. brown sugar
1/2  tsp. cinnamon
2 tsp. baking powder
1/2 tsp. baking soda
1/2 tsp. salt
Beat eggs in medium-sized bowl.  Beat in vegetable oil until well mixed, then stir in buttermilk.  Add remaining ingredients and stir to blend. 

It seems to me that we need to have syndicated feeds for Linux job adverts. To start this I have created a new blog for Linux job adverts, it will have categories for the states and territories of Australia (with a feed for each category) and I will also create Planet installations that take feeds from the blog as well as any other Linux jobs RSS feeds. I will create the Planet installations when I have feeds to add. If your company regularly advertises Linux jobs in Australia then please create an RSS feed of the adverts and I will syndicate it. If your company occasionally advertises Linux jobs then you can email them to me. As of this moment there are no positions advertised, but I hope that to change soon.

Share This

Here's how you use a Sierra Wireless 595U USB modem to connect to wireless Internet service with Sprint:

Insert the modem into the USB slot. lsusb should show:

Bus 001 Device 005: ID 1199:0120 Sierra Wireless, Inc.

rmmod usbserial

Then:

modprobe usbserial vendor=0x1199 product=0x0120

You should see /dev/ttyUSB0, ttyUSB1, and ttyUSB2 appear. See also instructions for automating this with a similar card (modify vendor and product to above settings).

Now you will need to configure PPP for this. On Debian, run pppconfig. Your settings will be:

Phone number: #777
Username: 1234567890@sprintpcs.com (replace 1234567890 with your data card's "phone number", no dashes)
Password: your sprint password
Speed (BPS): 921600 (use lower numbers such as 115200 if you have trouble with this)
Port: /dev/ttyUSB0
Init string: ATZ

Here are some other helpful pages:

Verizon EVDO
Sprint and Linux
Cingular AT&T UMTS
Sierra's Linux page

Five years ago, I started work on OfflineIMAP. I couldn't find any mail reader that offered good IMAP support and a good feature set. Rather than write my own mail reader, I simply wrote OfflineIMAP and used it with mutt. OfflineIMAP does a bi-directional sync between an IMAP server and local mailboxes. This lets you work offline, and also speeds up reading since each new message doesn't have to be downloaded from the network on the spot.

I kept hoping that OfflineIMAP would become obsolete soon, as mail readers got better. Back in 2004, two years after writing OfflineIMAP, I looked at mail readers. In 2005, after some more frustrations with mail readers, I wrote a comparison. I wound up sticking with mutt and OfflineIMAP each time.

I've gone out looking at mail readers again. Here's what I've found.

KMail
Overall a nice reader, KMail has almost every feature and setting I want. It has "disconnected IMAP" folders, which download every new message in folders to the local disk as part of the routine mail checking. It then caches local changes and syncs them to the remote on the next mail check. This boosts interactive performance and permits offline operation -- very similar to OfflineIMAP. KMail has keyboard shortcuts for most things, and keyboard shortcuts can be added or changed for most other things as well.

KMail also integrates with the KDE calendar and addressbook, which I already use. That's nice, too.

I have two big gripes about it though.

Back in 2004, I noticed that KMail crashes a lot. By 2005, it was worse. Sadly, KMail still has a tendency to crash. I've seen an average of 1-2 crashes per day, due to SIGFPE, SIGSEGV, and I think also SIGILL. This doesn't make me happy at all. Especially to see that it's no better on that in three years. Just don't try emptying trash while your mailbox is being synced, for one thing....

Gripe #2 is that there is absolutely no way to select a different alternative in a multipart message without using the mouse. Simply no way using the keyboard. It's also cumbersome, though possible, to view attachments using the keyboard -- you have to press Enter to open the message in its own window, then tab to the attachment.

KMail also sometimes works a bit sluggishly -- for instance, when you delete a message, you first see strikethrough through it, then it disappears. It doesn't feel very "snappy".

Evolution
Evolution has a decent core. It is easy to get set up and has an extensive set of keyboard shortcuts. It does IMAP downloading and syncing like Kmail, and it does it by default. It doesn't offer all that much flexibility in configuration, but probably enough.

Here's my gripe. There is no way for it to show a total message count next to each folder in the folder list. It will show an unread message count, but not a total message count. You have to click on each folder individually to see a total message count. I can't figure out why this is missing from Evolution. It's one of the main benefits to switching from mutt, and so I didn't bother looking at Evolution any more past there.

Thunderbird / Icedove
By default, it isn't all that capable of a mail reader. There aren't that many configuration options, and the keyboard shortcuts -- while existing for most things -- are cumbersome.

The Nostalgy extension helps with the keyboard shortcuts significantly. You still can't change some of them (Ctrl-L for forward, anyone) -- at least not without an extremely cumbersome process involving editing text files.

Thunderbird can do automatic IMAP downloading and syncing like KMail and Evolution, but for some inexplicible reason, only for your INBOX. In fact, Thunderbird won't even check for mail in folders other than INBOX unless you set an undocumented configuration option. It seems to assume that nobody does server-side mail filtering.

If you want IMAP downloading for offline use or performance, you have to manually invoke a download operation. There is a Sync on Arrival extension, but it isn't compatible with Thunderbird 2.0. From reading comments online, there are a lot of people frustrated about that.

So Thunderbird strikes out as well.

mutt + OfflineIMAP
The good thing about this combination is performace. mutt is extremely fast, and OfflineIMAP works faster than anything else for IMAP downloading. mutt is also far more configurable than anything else.

There are some annoyances about mutt.

#1 on that list is the lack of a folder list. There is just no way to see a list of folders along with new or total message counts. You can press c, Enter to go to the next folder with unread mail, which is something, but not enough. There have been numerous abortive projects over the years to address this, but for whatever reason, mutt itself doesn't have this yet. Probably the most promising current project is this one.

#2 is HTML mail. I don't mind the lack of default support for HTML mail. That's to be expected. There are some things that do bug me involving viewing HTML mail. First off, sometimes people attach graphics to messages that also have an HTML component. Viewing these graphics doesn't represent a security risk, but mutt doesn't make them available to a browser for viewing -- you have to manually save them if you want to view them. Also, you normally don't want to load graphics from the Internet for HTML mail. The only way to accomplish that with mutt is to set your browser to lynx or something; just using Firefox to view a HTML component will load all of that.

#3 is handling of embedded URLs. xterms can pass mouse clicks, and it would be nice if mutt made URLs clickable like other mail readers do.

#4 is the IMAP support. No support for caching, fragile, etc. That's why I use OfflineIMAP. That works, but it's a hassle.

#5 is printing. Printouts from mutt just spew the text of the message at the printer. No page numbers, formatting, nothing. muttprint makes that situation a bit better, but the integration is flaky and weird.

Conclusions
I'm not sure what I'll do. None of these are really where I want them to be, though mutt and KMail are probably the closest.

Arnaud and I finally managed to release Ruby D-Bus “Almost live from DebConf 7” 0.2.0. The release was planned for DebConf 7. However, I didn’t manage to get it ready in between all the talks, meetings, and other social stuff. Ruby D-Bus is an implementation of the D-Bus protocol in pure Ruby. After starting the development in February, it soon became apparent that several other projects were out there with about the same goal, such as Pure Ruby DBUS and R-Bus. Our approach is to have an API that is close to the old Ruby D-Bus bindings. While the other, similar projects seem to have a slightly different goal, we still invite them to come to some sort of merging so that no duplicate effort is put into three or four separate projects with almost the same result. The 0.2.0 release is our first real public release. We have a large subset of the features working and documented. The main focus of this release was to improve the API documentation and the tutorial. The 0.2.0 release is a release for exploratory purposes. We invite everyone interested to have a look at the API and inner works and provide us with feedback and/or patches. This means that the API can still change a bit over time based on feedback and tweaks performed by ourselves. So don’t built a big application on it just yet if you’re not willing to make some changes later on. For more information, see our project (Trac) page.

I've generated a springgraph of the DebConf7 keysigning keyring after refreshing the keys today. Thumbnails are available now. Click the thumbnail to see the full image. I've tried to correlate the thumbnails so that the overall area is similar.

For some reason, the images don't show via my blog.

For comparison, the springgraph before DebConf:

http://gnupg.neil.williamsleesmill.me.uk/ksp-spring.png
(The main image is much larger - may be best to wget it and view it locally.)


http://gnupg.neil.williamsleesmill.me.uk/ksp-spring-thumb.png

The change after DebConf:

http://gnupg.neil.williamsleesmill.me.uk/afterksp.png

http://gnupg.neil.williamsleesmill.me.uk/afterksp-thumb.png

(a much smaller final image).