Today the SquirrelMail plugin avelsieve happened to be released with version 1.9.8. Thanks and kudos to Alexandros who after so long time still was in the mood to put things together. The new features promise to be amazing: a new user interface, much code rewriting, and an entirely new SPAM handling. Unfortunately after installing it my SquirrelMail installation went badly down somehow. While everything alse is delivered properly by apache2, SquirrelMail now runs into one timeout after another. I need to figure out what s actually going on there. The error.log is quiet so far Anyways, for all you people who are looking forward to see this new fancy and shiny version in sid, I have to ask for patience. I think the package is ready but before testing no uploading! Until then you can (if you re brave) test the package by installing it from http://downloads.jhr-online.de/avelsieve_1.9.8-1_all.deb And all you others just have a look at the changelog that s probably (hopefully) hitting sid in a few days:

  * New upstream release
     + A large part of the code has been rewritten.
     + A new-style SPAM rule has been implemented.
     + A new, global Whitelist rule has been implemented, for
       the SPAM rules to take advantage of.
     + New, "Custom Sieve Code" rule has been implemented; this allows users
       to enter directly Sieve code snippets as a rule. (experimental)
     + Miscellaneous code movement and restructuring.
     + UI: The "Add New Rule" buttons are now links, and are displayed
       both at the top and at the bottom of the rule table.
     + UI: Major rework in the UI of both the Rules Table and the Add New
       Rule / Edit Rule pages.
     + UI: If a vacation rule is active, then display a notice in the
       rules table page and upon logging in to Squirrelmail, that reminds
       the user.
     + UI: Vacation options have been aligned properly; text has been
       changed accordingly.
     + Sieve: Vacation Subject is now supported.
     + New functionality: "Insert New Rule Here"
     + New functionality: "Move Rule to Position" (requires Javascript)
     + Avelsieve now highly recommends the use of javascript_libs plugin
       for some visual effects / UI improvements.
     + UI: Added new icons and used different ones, to improve usability.
       Icons are provided by Mark James' famfamfam.com.
     + UI: Added new icon "theme" based also on famfamfam.com. This theme
       is the default from now on.
     + UI: Removed unnecessary text / clutter from rules table page.
     + UI: The notify action options have been aligned in a table.
     + Added an LDAP Sieve storage backend, compatible with Sun Messaging
       Server's Sieve features.
     + The DO_Sieve_* backends should have a separate retrieve() method
       for retrieving the raw Sieve script. Currently, only the Managesieve
       backend has it.

If your dpkg runs seem to take a long time in the reading database step, try this: Step One: Clear the available file dpkg --clear-avail Step Two: Forget old unavailable packages dpkg --forget-old-unavail Step Three: If you use grep-available or other tools that rely on a useful available file, update the available file using sync-available (in the dctrl-tools package). The few times I ve tried it (all situations where the reading database step seemed to take ages), it has always sped the process up dramatically. There probably are situations where it won t make much difference, but I haven t run into them.

Just got home from a wonderful concert by Brad Mehldau at the CSO. This was long overdue as I kept reading about Mehldau. And even though he performs quite regularly around here, I had never seen him. Big mistake. The first set was performed as a (strictly acoustic) trio with Larry Grenadier on bass and Jeff Ballard on drums. After several compositions by Mehldau and a brazilian samba piece, the first set closed with a rendition of 'Holland' from Sufjan Stevens' album Michigan which was truly beautiful. The second set had Mehldau performing solo, again with several compositions of his own as well as one from Neil Young's classic 'The Needle and the Damage Done' leading two two pieces from the Sound of Music including an amazing, yet really different 'My favourite things' that just hushed a piece of the central melody along with a strond rhythmic element. Lovely. And then to cap it all off, four encores. Highly recommended.

Trying out simpleopal again, since my bug was closed. It was January the last time I tried using iax, and things were in a miserable state.

I ve been using Manoj s new kernel-package for some weeks now, and used it to compile two kernels (a reconfigured 2.6.29.1 and the new 2.6.29.2). Both times I ve had trouble with initrd. As the documentation says, kernel-package kernel packages no longer do their own initramfs generation. One must copy the example scripts at /usr/share/doc/kernel-package/examples/etc.kernel/postinst.d/initramfs and /usr/share/doc/kernel-package/examples/etc.kernel/postrm.d/initramfs to the appropriate subdirectories of /etc/kernel/. However, this is not enough. My /etc/kernel-img.conf file had the usual posthook and prehook lines calling update-grub. Unfortunately, those hooks are called before the postinst.d hooks, and so update-grub never saw my initramfs images. Fix? I removed those lines from /etc/kernel-img.conf and created a very simple postinst.d and postrm.d script:

#!/bin/sh
update-grub

I call the script zzz-grub-local, to ensure that it runs last.

Call for papers: JITP-2010
The Politics of Open Source
May 6-7, 2010 - Amherst, Massachusetts Full Paper Submission Due Date: January 10, 2010 Approach
Free/Libre and Open Source Software (FOSS) has made significant advances, both technically and organizationally, since its emergence in the mid-1980s. Over the last decade, it has moved from a software development approach involving mostly volunteers to a more complex ecology where firms, nonprofit organizations, government agencies and volunteers may be involved. Moreover, the production paradigm continues to expand to other areas of digital content (e.g., Creative Commons, Wikipedia, Connexions, etc.). In this conference we use the phrase open source to capture this broader phenomenon. The Program Committee encourages disciplinary and interdisciplinary approaches to the study of open source, broadly defined. Politics in the conference title, can have many interpretations. Political issues closely tied to the free and open source software movement(s) include: national government policies related to the adoption of open source technologies or questions related to interoperability and open standards, software patents, vendor lock-in, and copyright. These are central themes we expect may be discussed in this forum. In this context, we welcome international submissions since differences in the political perspective appear in international contexts. However, topics related to how the concept of openness has led to various interpretations, adaptations, and applications of open source in other domains, and political issues that surround these broader innovations, are also welcome. Specific topics might include, but are not limited to: General topics related to the politics of open source:
+ How open source software or its principles are changing politics
+ Emerging transparencies in software, systems and society
+ Open source in the developing world and other international contexts
+ The political economy of open source
+ Digital divides and open source Open source and the public sector:
+ Open source software and transparency in government
+ Government policies toward open source and open standards
+ Regulation and open source Open source and democracy:
+ Open source and democratic engagement
+ Open source voting systems
+ Activism, political mobilization and open source The expansion of open source into other domains:
+ Understanding how open source collaboration works and how it can be extended into other areas of collective action
+ Policy areas, such as the effects of free textbooks on education policy or the politics of One Laptop Per Child
+ The political implications of open source in other cultural domains Keynote Speakers
We are pleased to confirm Eric von Hippel (MIT) and Clay Johnson (Sunlight Labs) as the daily keynote speakers for JITP-2010. Paper Submissions
Authors are invited to prepare and submit to JITP a manuscript following one of the six submission formats by January 10, 2010. These formats include research papers, policy viewpoints, workbench notes, review essays, book reviews, and papers on teaching innovation. The goal is to produce a special issue, or double issue, of JITP with a wide variety of approaches to the broad theme of The Politics of Open Source.

How to Submit
Everything you need to know about how to prepare and submit a strong JITP paper is documented at http://www.jitp.net/. Papers will be put through an expedited blind peer review process by the Program Committee, and authors will be notified about a decision by March 10, 2010. A small number of papers will be accepted for presentation at the conference. Other paper authors will be invited to present a poster during the Friday evening reception. All posters must include a YouTube version of their research findings. Best Paper and Poster Cash Prizes
The author (or authors) of the best research paper will receive a single $1,000 prize. The creator (or creators) of the best poster/research presentation will also receive a single prize of $1,000. Program Committee
M.V. Lee Badgett, University of Massachusetts Amherst
Paul M.A. Baker, Georgia Institute of Technology
Deborah Bryant, Oregon State University Open Source Lab
Andrea Calderaro, European University Institute
Mark Cassell, Kent State University
Edward Cherlin, Earth Treasury
Gabriella Coleman, New York University
Doug Downham, University of Massachusetts Amherst
Robert English, Daystar Computing & University of Massachusetts Amherst
Joseph Feller, University College Cork
Jelena Karanovic, Rutgers University
Dave Karpf, University of Pennsylvania/Miller Center for Public Affairs
Jeremy Hunsinger, Virginia Tech
Andrea Kavanaugh, Virginia Tech
Jose Marichal, California Lutheran University
Jens Hardings Perl, Pontificia Universidad Cat lica de Chile
Charlie Schweik, University of Massachusetts Amherst, co-chair
Stuart Shulman, University of Massachusetts Amherst, co-chair
Megan Squire, Elon University
Krishna Ravi Srinivas, Research Information System For Developing Nations
Louis Suarez-Potts, Sun Microsystems, Inc. & OpenOffice.org
Anas Tawileh, Cardiff University & Meedan.net

Call for papers: JITP-2010
The Politics of Open Source
May 6-7, 2010 - Amherst, Massachusetts Full Paper Submission Due Date: January 10, 2010 Approach
Free/Libre and Open Source Software (FOSS) has made significant advances, both technically and organizationally, since its emergence in the mid-1980s. Over the last decade, it has moved from a software development approach involving mostly volunteers to a more complex ecology where firms, nonprofit organizations, government agencies and volunteers may be involved. Moreover, the production paradigm continues to expand to other areas of digital content (e.g., Creative Commons, Wikipedia, Connexions, etc.). In this conference we use the phrase open source to capture this broader phenomenon. The Program Committee encourages disciplinary and interdisciplinary approaches to the study of open source, broadly defined. Politics in the conference title, can have many interpretations. Political issues closely tied to the free and open source software movement(s) include: national government policies related to the adoption of open source technologies or questions related to interoperability and open standards, software patents, vendor lock-in, and copyright. These are central themes we expect may be discussed in this forum. In this context, we welcome international submissions since differences in the political perspective appear in international contexts. However, topics related to how the concept of openness has led to various interpretations, adaptations, and applications of open source in other domains, and political issues that surround these broader innovations, are also welcome. Specific topics might include, but are not limited to: General topics related to the politics of open source:
+ How open source software or its principles are changing politics
+ Emerging transparencies in software, systems and society
+ Open source in the developing world and other international contexts
+ The political economy of open source
+ Digital divides and open source Open source and the public sector:
+ Open source software and transparency in government
+ Government policies toward open source and open standards
+ Regulation and open source Open source and democracy:
+ Open source and democratic engagement
+ Open source voting systems
+ Activism, political mobilization and open source The expansion of open source into other domains:
+ Understanding how open source collaboration works and how it can be extended into other areas of collective action
+ Policy areas, such as the effects of free textbooks on education policy or the politics of One Laptop Per Child
+ The political implications of open source in other cultural domains Keynote Speakers
We are pleased to confirm Eric von Hippel (MIT) and Clay Johnson (Sunlight Labs) as the daily keynote speakers for JITP-2010. Paper Submissions
Authors are invited to prepare and submit to JITP a manuscript following one of the six submission formats by January 10, 2010. These formats include research papers, policy viewpoints, workbench notes, review essays, book reviews, and papers on teaching innovation. The goal is to produce a special issue, or double issue, of JITP with a wide variety of approaches to the broad theme of The Politics of Open Source.

How to Submit
Everything you need to know about how to prepare and submit a strong JITP paper is documented at http://www.jitp.net/. Papers will be put through an expedited blind peer review process by the Program Committee, and authors will be notified about a decision by March 10, 2010. A small number of papers will be accepted for presentation at the conference. Other paper authors will be invited to present a poster during the Friday evening reception. All posters must include a YouTube version of their research findings. Best Paper and Poster Cash Prizes
The author (or authors) of the best research paper will receive a single $1,000 prize. The creator (or creators) of the best poster/research presentation will also receive a single prize of $1,000. Program Committee
M.V. Lee Badgett, University of Massachusetts Amherst
Paul M.A. Baker, Georgia Institute of Technology
Deborah Bryant, Oregon State University Open Source Lab
Andrea Calderaro, European University Institute
Mark Cassell, Kent State University
Edward Cherlin, Earth Treasury
Gabriella Coleman, New York University
Doug Downham, University of Massachusetts Amherst
Robert English, Daystar Computing & University of Massachusetts Amherst
Joseph Feller, University College Cork
Jelena Karanovic, Rutgers University
Dave Karpf, University of Pennsylvania/Miller Center for Public Affairs
Jeremy Hunsinger, Virginia Tech
Andrea Kavanaugh, Virginia Tech
Jose Marichal, California Lutheran University
Jens Hardings Perl, Pontificia Universidad Cat lica de Chile
Charlie Schweik, University of Massachusetts Amherst, co-chair
Stuart Shulman, University of Massachusetts Amherst, co-chair
Megan Squire, Elon University
Krishna Ravi Srinivas, Research Information System For Developing Nations
Louis Suarez-Potts, Sun Microsystems, Inc. & OpenOffice.org
Anas Tawileh, Cardiff University & Meedan.net

So, we are still mostly able to keep our release each two weeks promise. For this release we have two big additions to the support side of the project: translations support, and gtk-doc support. The former is made of the usual makefile rules used by gettext-enabled projects with a rework to fit in the non-recursive build process of WebKitGTK+. The later is not as well integrated yet, so you have to go manually to WebKit/gtk/docs and type make, but not before editing WebKit/gtk/webkit/webkitprivate.cpp and adding a call to g_thread_init(NULL); to webkit_init(). You get the idea, we need help in polishing this one. As for code, Xan Lopez has been doing some serious work on accessibility support, using ATK. After the a11y hackfest he landed a number of patches moving forward in this direction. It looks like we will be able to meet the requirements for becoming blessed for use by GNOME. We also got a nice printing API, that allows applications to stop using the nasty hack that would send a print() call through javascript. They are also able to control/monitor the print process, or automate it, so that no print dialog is shown, if they wish. That s it, come join the party =D. Now, for 1.1.6, I m hoping Diego finishes the spelling check patch, and it would be awesome to have Jan s proper error reporting!

I've started to develop awesome more than 18 months ago, and somehow I feel it's time to stop a bit and think where we come from and where we are going to. The motivation I never though I'd be written a window manager one day. That seems kinda stupid when you see how many window manager there's around. As many people, I've tested and have been using tons of window manager: Window Maker, Fluxbox, etc. In August 2007, I was using fvwm since 2004 and was quite happy with it. I used the famous fvwm-crystalhttp://www.fvwm-crystal... as a configuration starter and then rewrote lots of stuff. Digging into fvwm configuration files was boring, and since I'm lazy, I never really configured it to fit entirely my needs. The thing is that, in July 2007, my workstation died. I bought a new one based on the amd64 architecture. Too bad, with this new box, fvwm decided that it will not longer runs and was segfaulting almost every time I logged in. I was really upset. Another failure in the window manager world. So I decided to get the yearly ride of testing many window managers. I went on the no more developed stuff like the *boxes, ion3, etc but well, I did not like them, there were not powerful enough, too bugged or upstream was insane. Then I found xmonad. The Haskell configuration file format made my cry. I did not want to learn Haskell, it seemed too obfuscated to me. At that time it was even not packaged for Debian, so I gave up. But I found dwm in the meantime, and I loved it. It was simple, and the source code was almost understandable and easy to hack. I subscribed to the dwm mailing-list, in order to participate to its development, etc But I got really disappointed. No patch were welcome and the development seemed to be almost finish in this sight. People patches were lying around, but no one really care. Each user was managing its own set of patches. That's not what I learnt and what I love in free software. So, as many users, I began to maintain my patches in my corner. But I began to have more ideas The jdwm I just added a 'j' in front of dwm and started to hack it days and nights to add many feature I missed, like multi-head, etc On 5th September 2007, I created a git repository to host my code. That's gonna be awesome. Five days later, on 10th September, I finally found a name for my new pet: awesome, borrowed from Barney Stinson who heavily uses and abuses this word. The 1.x branch The first releases until December were noted 1.x. It was just a better dwm with a simple flat configuration file.. The configuration file used libconfig, but it was a very poor choice. And I was not able to put in into Debian because of name clash. The 2.x branch The 2.x branch came in January 2008 with a brand new configuration file format based on libconfuse, which was a bit more powerful. Many concepts and features that have been added in this branch are still used in the current 3.x branch. At this time, between December 2007 and April 2008, the community was growing smoothly. But as I said, awesome 2 was based on a flat configuration file. That raised a problem very soon: users expectation were growing and the development team (me and a couple of regular contributors) was unable to cope with them. One of the event that started to change my mind was the support for titlebars. When I've added titlebar support, it was minimal. It was on top of a window, with the window title. Dot. Then I've started to add a lot of options, like the application icon drawing, the position (left, right, bottom) etc. And then users started to ask for more, like: "add titlebar on windows only when the window is floating". That's ok, but that's complicated: that's again another option to do some stuff conditionally. And then, why don't add titlebar on windows when <insert random events here>? The 3.x branch Why At that time, around April 2008, I'd totally stopped development. I was trying to find a solution which was simple and powerful. But after 2 weeks of thinking, I was not able to find anything else than: use a real language for configuration. So, I've started prototyping awesome 3 using Lua. The choice was not obvious, and despite the problem Lua might suffer, it's one of the easiest language to integrate into an existing application. There's still a video of a first version here. But, let's go a little back: in January 2008, Arnaud Fontaine contacted me because he was interested to use awesome as one of its school project. He decided to port awesome from Xlib to XCB, a modern asynchronous X library. His work took some time, but in May 2008, Arnaud did finished to port git master version of awesome to use XCB. Consequently, I decided to start a new major branch, using XCB instead of Xlib (no change for users in this regard) and Lua instead of our previous flat configuration file format. Development It took me a while to get from here to there, but in September 2008, it was ready. We had a simple Lua API, and the XCB port was working perfectly. It took us some time to release and have something totally working, because we had to work on XCB and contribute back to the project. It was really not ready to use by an application, but we did great work in this area and it's now really fine. We're still here Releases continue to happens, 3.1 around December 2008, and 3.2 around March 2009. 3.3 should be here in June. One of the drawback we had, is that we moved many stuff from C to Lua. Why? Because writing things in Lua is quicker and easier to maintain than C, and makes thing more configurable for the user. For example, the layout algorithm used to organize window were written in C until 3.2 came out. At that time, users had no choice than using a set of predefined layout to organize their windows. Starting with 3.2, if they have minimal knowledge about geometry, they can start writing a layout function organising windows on the screen. But this kind of API changes was a bit rough for users, since they had to port some part of their configuration file to the new API. The thing is that the project was still a teenager at that time, not really knowing were it will go. But I'm happy to announce that API breakage are more and more rare (so far only one minor between 3.2 and 3.3), and anyway always for the Good. But I admit that it built a bad reputation around awesome 3.x during its first month of existence. Future direction I am currently working on 3.3 development. We have still many things to do. Time passing, we get more idea, and more users. And more users bring more ideas. We also have many more contributors, and some guys are even taking maintainer-ship of some code area. Conclusion My post title is "Taking the other direction" because I feel this way. I've got that feeling that some approaches in projects like GNOME are sometimes bad. Please don't misread me, I know we are not playing in the same yard. When adding a key shortcut for starting an application makes you dig into gconf, I wonder how this is a win for the user. Well, it's probably a win for the end-user, but I surely am not one of them. And I don't intend to target them with my software, anyway. And now, when I hear things like GNOME 3.0 and the "desktop shell" approach, that makes me smile. Guys, it was time, but have luck. What I see from here, is that any desktop control interface is wrong somehow, and that there's no approach that can fulfill all users wishes. I think that we, the awesome development team (no pun intended) took the direction of building a frame-work window manager rather than a solution written in marble. We (partially) solved the issue of UI ergonomic by not writing one and allowing the user to write his own. I don't say that's easy to do for most of users, but it's doable. And I think it's worth it: I use window managers since I use Linux, around 1998. If something like awesome came 5 years ago, I'd be using it so far, because you can write Fluxbox or WindowMaker using awesome in a hundred of Lua code. And you can write your own version of it. And it starts in less than 3 seconds, supporting almost all standard desktop specification (ICCCM, EWMH, XDG, system tray, message notification, D-Bus, etc), whereas many of the window mangers do not. You can even write and play space invaders. Finally, I'm happy about the the road we took so far, and hope we will continue into that direction. The rants I read about our project are not that big, compared to the kudos we received.

I've started to develop awesome more than 18 months ago, and somehow I feel it's time to stop a bit and think where we come from and where we are going to. The motivation I never though I'd be written a window manager one day. That seems kinda stupid when you see how many window manager there's around. As many people, I've tested and have been using tons of window manager: Window Maker, Fluxbox, etc. In August 2007, I was using fvwm since 2004 and was quite happy with it. I used the famous fvwm crystal as a configuration starter and then rewrote lots of stuff. Digging into fvwm configuration files was boring, and since I'm lazy, I never really configured it to fit entirely my needs. The thing is that, in July 2007, my workstation died. I bought a new one based on the amd64 architecture. Too bad, with this new box, fvwm decided that it will not longer runs and was segfaulting almost every time I logged in. I was really upset. Another failure in the window manager world. So I decided to get the yearly ride of testing many window managers. I went on the no more developed stuff like the *boxes, ion3, etc but well, I did not like them, there were not powerful enough, too bugged or upstream was insane. Then I found xmonad. The Haskell configuration file format made my cry. I did not want to learn Haskell, it seemed too obfuscated to me. At that time it was even not packaged for Debian, so I gave up. But I found dwm in the meantime, and I loved it. It was simple, and the source code was almost understandable and easy to hack. I subscribed to the dwm mailing-list, in order to participate to its development, etc But I got really disappointed. No patch were welcome and the development seemed to be almost finish in this sight. People patches were lying around, but no one really care. Each user was managing its own set of patches. That's not what I learnt and what I love in free software. So, as many users, I began to maintain my patches in my corner. But I began to have more ideas The jdwm I just added a 'j' in front of dwm and started to hack it days and nights to add many feature I missed, like multi-head, etc On 5th September 2007, I created a git repository to host my code. That's gonna be awesome. Five days later, on 10th September, I finally found a name for my new pet: awesome, borrowed from Barney Stinson who heavily uses and abuses this word. The 1.x branch The first releases until December were noted 1.x. It was just a better dwm with a simple flat configuration file.. The configuration file used libconfig, but it was a very poor choice. And I was not able to put in into Debian because of name clash. The 2.x branch The 2.x branch came in January 2008 with a brand new configuration file format based on libconfuse, which was a bit more powerful. Many concepts and features that have been added in this branch are still used in the current 3.x branch. At this time, between December 2007 and April 2008, the community was growing smoothly. But as I said, awesome 2 was based on a flat configuration file. That raised a problem very soon: users expectation were growing and the development team (me and a couple of regular contributors) was unable to cope with them. One of the event that started to change my mind was the support for titlebars. When I've added titlebar support, it was minimal. It was on top of a window, with the window title. Dot. Then I've started to add a lot of options, like the application icon drawing, the position (left, right, bottom) etc. And then users started to ask for more, like: "add titlebar on windows only when the window is floating". That's ok, but that's complicated: that's again another option to do some stuff conditionally. And then, why don't add titlebar on windows when <insert random events here>? The 3.x branch Why At that time, around April 2008, I'd totally stopped development. I was trying to find a solution which was simple and powerful. But after 2 weeks of thinking, I was not able to find anything else than: use a real language for configuration. So, I've started prototyping awesome 3 using Lua. The choice was not obvious, and despite the problem Lua might suffer, it's one of the easiest language to integrate into an existing application. There's still a video of a first version here. But, let's go a little back: in January 2008, Arnaud Fontaine contacted me because he was interested to use awesome as one of its school project. He decided to port awesome from Xlib to XCB, a modern asynchronous X library. His work took some time, but in May 2008, Arnaud did finished to port git master version of awesome to use XCB. Consequently, I decided to start a new major branch, using XCB instead of Xlib (no change for users in this regard) and Lua instead of our previous flat configuration file format. Development It took me a while to get from here to there, but in September 2008, it was ready. We had a simple Lua API, and the XCB port was working perfectly. It took us some time to release and have something totally working, because we had to work on XCB and contribute back to the project. It was really not ready to use by an application, but we did great work in this area and it's now really fine. We're still here Releases continue to happens, 3.1 around December 2008, and 3.2 around March 2009. 3.3 should be here in June. One of the drawback we had, is that we moved many stuff from C to Lua. Why? Because writing things in Lua is quicker and easier to maintain than C, and makes thing more configurable for the user. For example, the layout algorithm used to organize window were written in C until 3.2 came out. At that time, users had no choice than using a set of predefined layout to organize their windows. Starting with 3.2, if they have minimal knowledge about geometry, they can start writing a layout function organising windows on the screen. But this kind of API changes was a bit rough for users, since they had to port some part of their configuration file to the new API. The thing is that the project was still a teenager at that time, not really knowing were it will go. But I'm happy to announce that API breakage are more and more rare (so far only one minor between 3.2 and 3.3), and anyway always for the Good. But I admit that it built a bad reputation around awesome 3.x during its first month of existence. Future direction I am currently working on 3.3 development. We have still many things to do. Time passing, we get more idea, and more users. And more users bring more ideas. We also have many more contributors, and some guys are even taking maintainer-ship of some code area. Conclusion My post title is "Taking the other direction" because I feel this way. I've got that feeling that some approaches in projects like GNOME are sometimes bad. Please don't misread me, I know we are not playing in the same yard. When adding a key shortcut for starting an application makes you dig into gconf, I wonder how this is a win for the user. Well, it's probably a win for the end-user, but I surely am not one of them. And I don't intend to target them with my software, anyway. And now, when I hear things like GNOME 3.0 and the "desktop shell" approach, that makes me smile. Guys, it was time, but have luck. What I see from here, is that any desktop control interface is wrong somehow, and that there's no approach that can fulfill all users wishes. I think that we, the awesome development team (no pun intended) took the direction of building a frame-work window manager rather than a solution written in marble. We (partially) solved the issue of UI ergonomic by not writing one and allowing the user to write his own. I don't say that's easy to do for most of users, but it's doable. And I think it's worth it: I use window managers since I use Linux, around 1998. If something like awesome came 5 years ago, I'd be using it so far, because you can write Fluxbox or WindowMaker using awesome in a hundred of Lua code. And you can write your own version of it. And it starts in less than 3 seconds, supporting almost all standard desktop specification (ICCCM, EWMH, XDG, system tray, message notification, D-Bus, etc), whereas many of the window mangers do not. You can even write and play space invaders. Finally, I'm happy about the the road we took so far, and hope we will continue into that direction. The rants I read about our project are not that big, compared to the kudos we received.

django-dumpslow is a reusable Django application that logs requests that take a long time to execute and provides an tool to summarise the resulting data. Modelled on mysqldumpslow, django-dumpslow is intended as a tool to determine which parts of a project might benefit most from optimisation and to provide valuable empirical data. The tool groups requests that are similar by exploiting Django's ability to reverse URLs - requests that use the same view are not counted distinctly. Views can then be grouped by the total accumulated time spent by that view or simply by their raw frequency in the logs. An example output is:

$ ./manage.py dumpslow
View                                         Accumulated time
=============================================================
example.views.slow                                     92.88
/unknown (unreversible url)                            16.84

If the log entries contain timestamps then django-dumpslow can optionally limit queries by a user-defined interval. This can be useful for generating regular reports of slow pages, perhaps by regularly emailing the "top 10 worst pages" to a development mailing list. Source, tarballs, etc. Patches welcome.

... turns out to be slightly over 31 and a half years. According to the text of my birth certificate, I was born at 13:20. So, with that, we can make the following calculation:

wouter@celtic:~$ date -d '1978-05-06 + 13 hours + 20 minutes + 1000000000 seconds'
Tue Jan 12 15:06:40 CET 2010

Since I missed my 10000 days, and I was sortof unhappy about that, I guess this one is a good substitute. Unfortunately the 12th of January is a tuesday, but I guess I can throw a party during the weekend...

Possibly the cutest pictures and story of the decade?!

Possibly the cutest pictures and story of the decade?!

It's been a long long time since I last posted anything at all, so this is a post to warn of impending doom. I've switched from a static html website (well, it was statically generated when I edited source files I then ran a bash script that fired off a perl script several times...) to a fully dynamic, django 1.0 backed website - this might mean that I manage to update things more often! I've also taken the opportunity to convert the previous content in to ReST, so it's actually easier to edit too. There's still work to do - but it's now "good enough" to be used, and I'll split the code out in to better chunks later on. So, anyways - that's what I've done with my day - so I expect all the aggregators to now break on the new feeds...

It's been a long long time since I last posted anything at all, so this is a post to warn of impending doom. I've switched from a static html website (well, it was statically generated when I edited source files I then ran a bash script that fired off a perl script several times...) to a fully dynamic, django 1.0 backed website - this might mean that I manage to update things more often! I've also taken the opportunity to convert the previous content in to ReST, so it's actually easier to edit too. There's still work to do - but it's now "good enough" to be used, and I'll split the code out in to better chunks later on. So, anyways - that's what I've done with my day - so I expect all the aggregators to now break on the new feeds...

I really like the 3.0 plan. There are two extra areas in particular that i d like to see us attack: Firstly (the smaller of the two) i d like to see a revamping of the Evolution client libraries, ECal & EBook, in particular ECalComponent is horrible. The work that Chris and I have been doing on libjana is showing some of the direction that such a library for accessing calendaring could go. This requires an ABI & API break to do this effectively (hence being a 3.0 thing.) Ross has also been doing sterling work on the server side of things by migrating the eds-dbus fork into the mainline. This is now basically just waiting on the migration to git and a double review of the calendaring code. The second and more significant thing that I care about is that I think we need to bring web services closer into the desktop. I ve been persuaded that desktop applications are not dead but I think we need compelling, transparent and easy ways to integrate with cloud services. In particular we are entering an age of almost always on connectivity. Many people already find little use for their computers if they are not connected to the Internet. However since the omnipresent and omni-reliable 3G/wireless/wimax utopia is not yet with us we live in a world where we get connectivity in bursts as we travel, socialise and live. Our platform should cunningly pull down interesting content when the user is on cheap and reliable connectivity which they can then peruse when offline or on an expensive and unreliable connection. A project that Ross and I have been working on at Intel to bring social networks to the desktop/mobile is called Mojito. I ll cover this in more detail soon.

Our hero: Ross Burton

The Crisis of Credit Visualized from Jonathan Jarvis on Vimeo.

As my Institute's sysadmin, I was appointed as the responsible for my Institute's certificate handling for today's voting session for the Universitary Council (Consejo Universitario). UNAM, Mexico's largest University, is moving towards an e-voting platform. I talked about this with our (sole) candidate for the Council, and she told me this has been used a couple of times already - And, as expected, it has led to having to repeat voting sessions, due in part to e-voting's inherent lackings: It is impossible to act on any kind of impugnation. The only thing we have is an electronic vote trail, no way to recount or to make sure that all votes got in. Besides, we had a perfectly antinatural and inadequate identification system, which means voter's identity have no way to be trusted. Besides, we still have all the traditional Universitary bureaucratic paper flow, which completely obscures any positive points this e-voting system might have had. Before going any further, if you are interested: There is a so-called security audit certificate for this system. In Spanish, yes. Take a look at it if you understand the language and want to crack some laughs. I will not make a detailed review of (what I could gather about) the setup. But to make things short: I had to go to the central administrative offices to get a CD-ROM with the monitoring station's SSL certificate. This certificate is tied to an IP address, so only one computer was able to be set up as a monitoring station. So far, so good. But, what is the monitoring station's real role? You will probably laugh. The voting session (at my Institute - Each dependency can specify its own opening and closing times) was from 10:00 and until 18:00. We were instructed to place this computer at a public location, from where:

• Shortly before 10:00, we had to check the booth's status was set to closed and that zero votes were received.
• During the votation period, the computer would continuously display the number of received votes, refreshing the page twice a minute1
• During the day, anybody could go to the computer and check the number of total votes received. Its main function is, I think, to show that no votes are substracted precisely when a person is staring at it.
• Shortly before 18:00, we had to check the booth's status was still set to open, and wait until 18:00 to witness the booth is now closed.
• Get the needed data from the system and hand it over to the proper bodies. I'll get back to this point later on.

So, what is strange here? That there is a tremendous apparatus providing supposed security to... Information that is completely worthless. Just protecting a number that is, for all purposes, public. Oh, and the opening and closing of the booth - Of course, the system could have flaws during the process, or inject spurious votes along the way, or flip-flop the votes cast whichever way. But, did I mention votes? So far I have not mentioned how people are supposed to vote. Together with our last paycheck, we got a piece of paper with all of the needed information: A randomly generated, 10-character-long-with-mixed-case-and-symbols password, and the link to a web page2. This paper was folded, yes, but it was in no way secured - So, whoever wanted to have all of our passwords could just go through the bunch of papers and get them. Now, contrasting to the strong perception of physical security surrounding the oh-so-important monitoring stations, how can a person vote? Oh, sure, just fire up your favorite browser and go to https://www.jornadaelectoral.unam.mx/, produce your student number if you are a student or your full RFC3, select via checkboxes4, click on "submit", and voil , you have voted. From any location, from any machine. Yes, the University's population is largely itinerant, many people will be voting from abroad and all. It is good to give them a voice. But... At what price? Lets see... The security audit mentions the system is free from any malicious routine that can automatically alter the results and it has the minimum needed validations against spurious data injections from the most common Web browsers. However, if I am interested in modifying the results... I could put a trojan in a Faculty's laboratories, which modifies the votes sent by their users (students vote as well). Yes, I'd have to know how the system works, but lets accept security through obscurity does not work, and that this is a well-known system (as it has been used for over 3 years and is at version 3.5). PHP-based, for further points. Oh, and (if I recall correctly) a voter does not even get feedback as for which formula did he vote for, so no way of knowing if the computer really sent the information I requested. And given the low security for the password handling, I would not bet on it being worth much. Besides, this system was partly established to allow people voting from abroad - as long as they picked up their March 10 paycheck. That excludes anybody who has spent over three weeks away! Many other things can be said. Last detail: e-voting's main selling point is that the results are known instantaneously, and (if no paper trail exists) no tedious re-counting is ever done, right? Meet universitary bureaucracy. Technology changes, but processes don't. The Local Electoral Surveillance Commission has the responsability to enter once again the system after the vote has finished, and ask the server for the preliminary results. This consists of a tarball with the tally sheet (from the voters, who voted and who didn't), the total votes for each formula, and... one more file I don't remember. They also have to generate the signed legal documents where they testify to the received information. And then, ahem, they have to burn those files5 onto a CD-ROM, print them, and physically take them to the central administrative offices. Yes, take something from the server and get it to the server. For us it is not terrible (1.5Km can be readily done), but this same procedure must be done by people in other cities where there are University campii holding elections. How Nice! Anyway... Worst of both worlds. The inefficacies of a paper-based ellection, together with the unaccountability of an e-voting ellection, sprinkled with fake sense of security here and there. Bah.

1. 1. Except that it didn't. I guess they didn't stress-test the server, so every couple of minutes it returned a connection error. Of course, the page would no longer self-update. And after noticing that, I (and nobody else but me) had to go and give the password and certificate for the system to continue to operate.
2. 2. which is http://www.dgae-siae.unam.mx/ - The Schooling Administration General Direction (DGAE), an universitary body which has no relation with electoral issues. DGAE made available a poster detailing how to vote... But, again, lets ignore that fact for now
3. 3. A nationwide ID number, largely derived from name and birth date data - Both numbers are often widely known, they cannot be considered private in any way.
4. 4. Oh, for goodness sake... The "ballot" has 1..n options, and each has a checkbox, not a radio button. That means, you can select multiple options, which is of course invalid. Why? Because the electoral rules indicate that selecting more than one option in a ballot makes the ballot invalid, and thus, a way for making it invalid must be provided. Isn't logic beautiful?!
5. 5. Want some more insight on what needs to be done? Take a look at the instructions. Don't forget paying attention to the lexicon used - We are still asked to count the votes, an impossible feat given the vote is 100% system-based - Quote: Los miembros de la CLVE realizar n, con base en el reporte del sistema, el c mputo de los votos depositados en la urna a favor de cada una de las f rmulas, declarando nulos los votos que procedan.

FLOSS Manuals is proud to announce a three day book sprint for the Pure
Data FLOSS Manual. This sprint will take place simultaneously in New
York City and Berlin from Saturday 4 April to Monday 6 April. The Pure Data FLOSS Manual: http://en.flossmanuals.net/puredata There are possibilities to participate in person by coming to one of the
locations below, or remotely via the IRC interface built into the FLOSS
Manuals editing interface. Video conferencing may take place between the
venues as well. To participate, create a login at the PD FLOSS Manuals page: http://en.flossmanuals.net/bin/login/TWiki/WebHome?origurl=/bin/view/PureData/Introduction&skin=floss2 Discussion may also take place in the Pure Data mailing list: http://lists.puredata.info/listinfo/pd-list If you are in New York or Berlin, please join us at these locations! NEW YORK CITY * Contact: Hans-Christoph Steiner: hans@eds.org 718 360 4872 * Location (bring ID, you ll need to sign in): ITP/NYU Conference Room
721 Broadway, 4th Floor
NY, NY, USA
email me or call in case you can get past security: 718 360 4872 * Schedule:
Saturday: noon-midnight
Sunday: 10am-midnight
Monday: 9am-5:30pm (if we go later, we ll be in a different room) BERLIN * Contacts Derek Holzer: derek@umatic.nl +49 176 2812 5845
Adam Hyde: adam@flossmanuals.net +49 15 2230 54563 NK
ElsenStr. 52 (2.Hof)
Berlin, Germany
+49 176 20626386
http://www.myspace.com/enka52 * Schedule:
Saturday: noon-late
Sunday: noon-late
Monday: noon-late
SOME BASIC GUIDELINES: * This manual should address the widest possible user-base. Therefore,
objects which are cross-platform and in Pd Extended should have priority
over other solutions.
* Tone should be neutral and informative. Remember that humor doesn t
always translate well!
* Our readers are assumed to have little to no background in either
computer programming or digital signal processing, which much of the
existing documentation takes for granted. That s why this manual is
necessary! Please keep this in mind when explaining things.
* Please use existing the Audio Tutorials, Installing and Getting
Started chapters as a style guide.
* Keep the chapters small and self-contained. Ideally, chapters from
this manual could even be remixed into other FLOSS Manuals.
* Explain any jargon or technical terminology in-line the first time you
use it, and direct the reader to appropriate other chapters/manuals when
necessary.
* Please enter any new technical terms in the Glossary (we need to agree
on global format for glossary terms!).
* Screenshots:
Resolution? (Adam and I will work on this on Monday)
Please upload any complex patches, and make sure to label screenshot
with appropriate filename (see Audio Tutorials for examples)
Please keep explanatory text in the manual rather than only in the
screenshot, so that it can be text-searched by readers.
Please use anti-aliased fonts!
* All the chapters are moderated by Derek Holzer & Adam Hyde. Your
contributions will only be visible in the editing section until they
meet these guidelines, and after that they can be published to the main
page. Please let us know when your chapter(s) are ready for publishing
and we ll look them over. EXISTING CHAPTERS WHICH NEED HELP: # DataflowTutorials this section needs a lot of help in terms of style and content!!!!!
Tone is very informal, which doesn t help convey the information.
give titles to screenshots so that readers can tell which patches
match which images (some do this, some don t )
Math : examples/discussion of [expr]???
Order of connecting and [trigger] : explain the patches in-line,
rather than only in comments in screenshots (so that text is searchable,
copy/pasteable..)
Luka s screencaps are very aliased, to the point where you can t read
the ~ in the object names. Should they be redone at new resolution or
with antialiasing?
Possible janitors: Derek Holzer, Adam Hyde # PureGlossary format of object names = [italics in square brackets], must be
formatted correctly
format of glossary words in general text: we don t have one yet. Bold
on first use in chapter maybe? Needs formatting all through text. # ListofObjects incomplete, please add more libs
maybe more discussion of externals needed as well
formatting of object names? # PureLinks always welcome MORE CHAPTERS/SECTIONS TO DO (+ suggestions?): * GEM (in order of importance)(Derek can provide example patches for
much of this)
Basic VJ mixer (2 x
[gemhead]-[pix_film]-[alpha]-[colorRGB]-[pix_texture]-[rectangle] with
an alpha-crossfader)(+ platform specific codec info)
Live camera input (same as VJ mixer but with [pix_video], with
platform specific info on USB/firewire inputs what works & what doesn t)
VJ effects (using the various pix objects)
Basic 3D (that actually does something interesting, rather than just
show a sphere or a cube)
Basic movement tracking w/ [pix_blob]
GEM/video optimization/troubleshooting tips (see Troubleshooting
section of existing Pd FLOSS Manual) * MIDI tutorial
hardware:keyboards, sliders, etc,
objects: all MIDI objects
routing: input + output to/from devices or other programs * Patching strategies
Reusable abstractions ($0 etc)
GoP + other GUI creation strategies
Preset saving systems (Frank?) * Audiofile manipulation (Derek can provide examples, possibly also work
with www.pd-tutorial.com with permission?)
sfread, readsf, sfplay, etc
tables + tabplay, tabread, etc
oneshot playback without/with pitch shifting
looping without/with pitchshifting
granulation without/with pitchshifting
Extended objects ([xplay~], [xgroove~] are these stable? In my
experience, no ) * Realtime audio effects tutorial
delays: single tap, multitap, pitch-shifting, tuned comb filter, etc
filters: [hip~], [lop~], [bp~], [moog~], IEM lib filters
[vcf~]/[bp],[hp],[lp], difference between audio signal and message
controlled, building with ggee objects [bandpass],[llowpass],[highpass]
or [biquad~] (resources for coefficients?) * Sensor tutorial (HC?)
[hid]/[hidin]/[pduino]
simple circuit diagrams + photos (voltage divider examples:
potentiometer, photoresistor, etc)(hacked gamepads) * Networked data
netsend/netreceive
OSC
flash server
shell
python externals
others? * PDP/PiDiP
configuration info for OSX (+ poor performance disclaimer!)
basic VJ
networked streaming etc * Procedural Audio tutorial? (Andy?) * RJDJ tutorial? (Frank and the gang?)