Search Results: "cas"

17 April 2011

Russell Coker: More about the Xperia X10

I ve now had a Sony Ericsson Xperia X10 for almost two months (here is a link for my first review) [1]. This is a phone that people seem to really dislike because the battery life is poor and Sony doesn t allow replacing the kernel. I m happy with mine, happy enough that after buying one for my wife and trying it out I bought one for myself. I knew about it s problems in advance and wanted a relatively cheap phone with a large high resolution screen, and the Xperia X10 was the best match for my criteria.ChargingThere has been a recent trend towards using USB for charging devices. Sony provides a tiny wall-wart PSU which has a USB socket and a short (1m) USB cable that can be used to charge the phone from it s PSU or from a PC. The size is really convenient, as the phone has a short battery life I ll probably want to take the PSU to more places than I would for other phones I ve owned.The short USB cable saves weight and tangle when travelling, but can be inconvenient. I m currently working on the phone while it s plugged into my laptop, that works well and I can make calls while it s connected. If the phone was connected to a USB port on a tower computer that was on the ground then the cable could be too short to make a call, if it was charging on a power point near the floor then I wouldn t even be able to use the computer functionality let alone make calls without kneeling. My Viewty has a 175cm charging cable which alleviates these problems. I ve got a 50cm USB extension cable that I use for charging my phone while I m in bed that is just long enough to allow me to check my email without getting out of bed!The socket for connecting the USB cable is protected by a plastic lid that is connected by a strip of rubber. For a socket that will be used at least twice a day this isn t a good mechanical design. The plastic slide on the LG U990 Viewty seems like a much better design.As an aside it s a pity that they aren t designing cars with USB charging sockets built in. Some new cars have a socket for one USB flash drive to be attached to the radio, but really they need at least one USB charging port per seat. It would also be nice if they made power points with USB charging sockets built in, I d buy a few of those if they made them.Preserving the BatteryI ve been running Juice Defender to reduce the battery use, at the moment it is claiming to have extended battery life by 69%. That combined with turning off things that aren t needed (such as WiFi) has made the phone reasonably usable. I can survive more than 12 hours during which I use the phone a lot without charging it.XperiaX10.net has an interesting review of replacement batteries [5]. I m not going to buy them because the largest battery requires a replacement back case which prevents using an external case to prevent damage and the smaller one doesn t provide enough of a benefit and the design of the phone makes it difficult to change batteries so carrying a spare battery isn t a good option.Cursor Control KeysThe HP/Compaq iPaQs that I own from ~10 years ago have a single button that can be moved up/down/left/right to act as a cursor, it can also be pressed inwards to act as an ENTER key (or whatever the application might want for a fifth function). Having some sort of hardware cursor control is really handy, I often end up deleting several characters when I want to replace one because getting the cursor onto the desired character is too difficult.Adding more hardware keys would require making the phone bigger, but that would be fine by me. As described in my previous post about phone cameras I d like to have a phone that s thicker to have a better camera with a greater focal distance for a larger lens [2].Core Phone FunctionalityI really miss having separate green and red buttons for making/answering calls and for rejecting/ending calls.A really common operation is to call back the last person who called. To do this on my LG U990 Viewty I press the green button twice on my home screen which took less than a second. On the Xperia this involves selecting the phone icon from the home screen, then the call log icon, then the call that is desired, then the Call user line. That is four presses in different parts of the screen compared to pressing the same hardware button twice. I m investigating dialer applets right now, the Dialler One applet has a good interface for calling people who have called or been called recently but it still requires two presses on different parts of the screen. With my old Viewty I could call back the last person by feel without even looking at the phone!In the last 6 years the standard functionality of phones has been to include multiple profiles for noises. My Viewty has profiles named Normal , Silent , Vibrate only , Outdoor , Headset (automatically selected when a headset is connected), and three customised ones. The Xperia has only one setting, and that is three icon presses away from the home screen. It does allow changing the volume by hardware switches on the side which includes going to vibrate-only and silent mode. While this is useful, it s not the best way that two precious hardware keys could be used. It also doesn t allow control over all the different notifications, I d like to be able to activate a noise profile and have every application respond to it in an appropriate manner. This is a deficiency in Android 2.1 not in the phone itself.In many ways this phone has the worst phone functionality of any mobile phone I ve ever owned, I think that this is more the fault of the Android designers than Sony Ericsson.Android UpdatesSony had previously claimed that they wouldn t support Android later than 2.1. Now Sony has announced that they will support Gingerbread Android 2.3 [3]. So one of the major complaints about the Xperia will soon be addressed.TetheringThe build of Android that the Xperia runs at the moment doesn t support Wifi tethering. I m currently using with Easy Tether for USB tethering [4]. It s not free software and requires it s own code to run as root on your Linux system that is being tethered (which is easily locked down with SE Linux), but it basically works. The down-side with Easy Tether is that it proxies all the connections so you can t run traceroute etc and in the free version you can t use UDP.K9 MailK9 Mail fixes some of the problems in the default Android email program that I described in my previous post. It allows selection of SSL with a default port of 993 for IMAPs. It uses mail.example.com as the mail server address for an email address of user@example.com (so I ll add a mail CNAME to the domains I run). When I connected initially it told me that the SSL key was not signed by a CA and asked if I wanted to save it or reject it this is the correct and desired functionality. It also correctly parses URLs from the email (or at least has fixed the bug that I discovered in the default email app).One problem I ve found with K9 is that it seems to timeout on large folders. This is probably partly the fault of Virgin Mobile being slow for IP access, but I wonder whether K9 doesn t pipeline IMAP commands as Virgin can do bulk transfer at reasonable speeds (80KB/s) and it mainly fails on latency (900ms being typical). The result is that a folder with more than 500 messages that need to be copied to the phone will never get synchronised. When I started reading mail on my phone I had to move mail from some of the bigger folders into other folders to avoid timeouts. As an aside the amount of time I ve saved by reading email on the go has already paid for the phone.MediascapeThe Sony Mediascape software is used for categorising photos. One function of this is to assign names to photos, the names come from the contact list so if you photograph someone who you can t phone then you need to add a contact list entry for them. This also means that you couldn t conveniently add names to non-humans, I guess I could have added a contact list entry Mr Crash Dump for photos of system crash logs. But a bigger problem is that it decides what is a picture of a person, a picture of someone who is not centered in the photo or a profile picture can be regarded as not a photo of a person and therefore not subject to being associated with a contact list. Finally when selecting a name for a picture it displays the entire contacts list in a small font instead of displaying favorites, I have the phone numbers of many clients in my contacts list who I will never photograph Mediascape just isn t much good. If I feel the need to do something serious in this regard I ll search the app store for something free that s better.ProtectionFor $15 each I bought one grey and one clear Gel Case from J2K. This case covers the sides and back of the phone with a firm rubber layer that will hopefully allow it to bounce rather than break. It also extends slightly higher than the screen which should stop the screen being scratched if the phone is left face-down on a hard surface on the vibrate setting.One problem with the Gel Case is that by it s design it has to cover the buttons on the sides, due to a design or manufacturing problem the clear case that my wife uses can press slightly on the shutter button which disables the three main buttons on the front. So when the menu or back button stops working she has to slightly move the Gel Case out from the side. I m thinking of just cutting out a section of the Gel Case there, that will make it difficult to press the shutter button, but you can use the touch screen to take photos and there doesn t seem to be any other use for the shutter button so this shouldn t be a problem. The clear and grey cases have different designs, the grey one has a hole over the raised Sony logo which makes it fit a little better as well as not having the shutter problem, so it seems to be a later design I don t know whether all clear cases have the same problem but I recommend that someone who only has one Xperia X10 get the grey case just in case.Web BrowsingI m experimenting with using my own web proxy to compress the data sent to the phone. Unfortunately the Android settings for a web proxy only apply to the main web browser, not to all the other applications that use web services. Also the built-in web browser requires pressing the settings hardware button followed by at least two touch-screen presses to change between windows or close a window and it doesn t seem to support making the short-press action be to open a link in a new window. So I will have to find another web browser to use.Bandwidth UseThe 3G Watchdog applet is really good for tracking the data transfer and optionally cutting off 3G access before the quota is exceeded. Unfortunately Virgin has already sent me a bill with $234 in extra charges for bandwidth use because I used 1.6G instead of my 1.5G quota. A Virgin representative had told me over the phone that the billing period would be based on the end of the month, so while every calendar month has had less than 1.5G used because I used more than average in the end of March and the start of April that counts as excess data in the 14th March to 13th April period.I m going to appeal this to the Telecommunications Industry Ombudsman, I don t think that it s reasonable that I should be billed almost 7* the normal bill for exceeding the quota by 7.4% based on following the instructions of a Virgin employee. While I could have read the previous bill that they sent me to discover the end of billing period dates, I don t think that I should be expected to distrust everything that a Virgin employee says. If they billed me an extra $20 then I d just pay it, but $234 is unreasonable.ConclusionSince using the phone I ve found significant benefits in web browsing and reading email with the major limitation being the small screen (relative to a Netbook or Laptop). So if I was to buy another phone I would probably consider a Dell Streak which seems to be the largest Android phone on the market at the moment.Given the amount of use that I ve got I would be happy to spend more money and therefore consider a more expensive phone. But I don t regret the decision to save money by getting an Xperia X10.Finally when a telco tries to stick me with a $234 excess charge it really detracts from the value of having a phone contract. If I end up having to pay that then it s half the value of a smart-phone lost in one telco scam. This is enough to make a contract with Virgin a bad option, after this contract expires I may use VOIP and a pre-paid SIM from Telstra NextG if their network is still the best. Another possibility is to just use a small tablet and skip having a mobile phone, email and Jabber plus SMS from the people who lack net access will probably do.

Jonathan McDowell: Why Linux? (Part 7: Support)

(This is part of a series of posts on Why Linux?) This is probably a non-obvious reason to run Linux to most people. One of the complaints I've heard in the past is the lack of support for Linux. It's not really relevant to running it on a work desktop (where support is presumably from some central IT organisation), but I believe it's a red herring. Support in the Free software world can exceed that in the proprietary by an impressive margin. And that can turn out to be useful at work, even if you do suppose the existence of central IT. The support I've received for Linux and applications under it has been, on numerous occasions, excellent in a way I feel I could never expect from the commercial software world. And when it isn't, I have the choice of whomever I want to try and fix my problems, rather than being stuck with no options. I have found that if I am polite, and provide useful information, and patient, I can talk directly to the developers who make the software I use. If I have a patch they will often take it from me, or use it as a basis for the final fix. If they are no longer available, or too busy, then because I have the source I can find someone else to look at the problem, or do so myself. The chances of most large proprietary software companies giving me the time of day is low. I don't understand why small businesses think that Windows is a safer choice due to being able to get support from Microsoft. Again using experience gained at Black Cat, at one point we had a problem with IPv6 routes being updated. Signs pointed to Quagga, Simon collected relevant information and got in contact with the Quagga devs. They investigated, realised it wasn't a problem with their code, and then proceeded to find the issue in the Linux kernel, produce the fix and pass it upstream. Within hours of us reporting the problem. I'll accept that's an exceptional response that can be matched within the proprietary software world, but not without a hefty support contract and I doubt you would have got a response other than "Not our fault, talk to the other supplier", or maybe a workaround at best. More recently, I had a conversation about Linux and discard support, with one of the people who'd worked on it. Very interesting from my PoV, useful to my work (I ended up fixing something in our code base that led to the Linux support Just Working with our product) and I believe was useful to that developer too, in terms of providing some insight to the other side of the problem. I don't get that kind of access to proprietary software developers - while it could be argued that I know a lot of Free software people, I also know a lot of other programmers and they're just not able to be so open about things, so both sides lose out. Or my new laptop's ethernet wasn't supported by the kernel in squeeze. I filed a bug requesting the driver be added (and pointing to the patch). The week I wrote the first draft of this article I saw confirmation that this had been done, and will be part of the final squeeze release. I think that's pretty impressive. (Thanks, Ben.)

Jonathan McDowell: Why Linux? (Part 7: Support)

(This is part of a series of posts on Why Linux?) This is probably a non-obvious reason to run Linux to most people. One of the complaints I've heard in the past is the lack of support for Linux. It's not really relevant to running it on a work desktop (where support is presumably from some central IT organisation), but I believe it's a red herring. Support in the Free software world can exceed that in the proprietary by an impressive margin. And that can turn out to be useful at work, even if you do suppose the existence of central IT. The support I've received for Linux and applications under it has been, on numerous occasions, excellent in a way I feel I could never expect from the commercial software world. And when it isn't, I have the choice of whomever I want to try and fix my problems, rather than being stuck with no options. I have found that if I am polite, and provide useful information, and patient, I can talk directly to the developers who make the software I use. If I have a patch they will often take it from me, or use it as a basis for the final fix. If they are no longer available, or too busy, then because I have the source I can find someone else to look at the problem, or do so myself. The chances of most large proprietary software companies giving me the time of day is low. I don't understand why small businesses think that Windows is a safer choice due to being able to get support from Microsoft. Again using experience gained at Black Cat, at one point we had a problem with IPv6 routes being updated. Signs pointed to Quagga, Simon collected relevant information and got in contact with the Quagga devs. They investigated, realised it wasn't a problem with their code, and then proceeded to find the issue in the Linux kernel, produce the fix and pass it upstream. Within hours of us reporting the problem. I'll accept that's an exceptional response that can be matched within the proprietary software world, but not without a hefty support contract and I doubt you would have got a response other than "Not our fault, talk to the other supplier", or maybe a workaround at best. More recently, I had a conversation about Linux and discard support, with one of the people who'd worked on it. Very interesting from my PoV, useful to my work (I ended up fixing something in our code base that led to the Linux support Just Working with our product) and I believe was useful to that developer too, in terms of providing some insight to the other side of the problem. I don't get that kind of access to proprietary software developers - while it could be argued that I know a lot of Free software people, I also know a lot of other programmers and they're just not able to be so open about things, so both sides lose out. Or my new laptop's ethernet wasn't supported by the kernel in squeeze. I filed a bug requesting the driver be added (and pointing to the patch). The week I wrote the first draft of this article I saw confirmation that this had been done, and will be part of the final squeeze release. I think that's pretty impressive. (Thanks, Ben.)

16 April 2011

Wouter Verhelst: Loadays 2011

Went to loadays, where I did a talk on "Single sign-on with Kerberos and LDAP". Or, at least, that was the intention when I found out that there was going to be a tutorial on LDAP the next day, I decided to focus my talk mostly on kerberos, only lightly touching LDAP. As it turned out, that was a great decision I could easily fill a whole hour on Kerberos, anyway, and though doing a kerberos setup without doing ldap too is fairly silly, doing it properly would have required more time than was assigned to me. Instead, I managed to talk the audience through most of the important theory about kerberos (things like "what is a principal", "what is a ticket", etc), and did a live demo in which I configured a kerberos realm on a virtual machine, and then used SSH to connect passwordless to that machine from a second virtual machine on the same virtual network. While I would've loved to make it even better by throwing in a kerberized HTTP configuration, I couldn't do much more than just mention the fact that it can be done as is the case for sasl-enabled protocols (imap, ldap, smtp, etc) and some other things. The talk seems to have been a success with the audience, too; the room itself was full, nobody actually left (which usually is a good sign in and of itself), and I got only positive feedback from the people who were there; one person even went so far as to say that he considerd it the best talk he'd seen thus far, today. Which I think is pretty high praise, considering how my talk was in the penultimate time slot. All in all, a good day.

Iustin Pop: Sysadmins and auto-configuration

I've read bits and pieces of the recent "Network Manager as default" thread on debian-devel. I have a strong personal preference towards one side, but that's not the point of this post (and I hope I can keep the tone neutral, hence why I didn't get into the mailing list discussion). I think this discussion is just a proxy flame-war to a bigger issue that lurks behind the scenes. That is, what is the most efficient way to configure systems. On one side, we have the sysadmins, with their toolbox, and who desire the most reliable way to configure systems. In the other corner, we have people whose problem is how to configure systems with the least amount of human involvement. Whether it's ifupdown versus NetworkManger, or explicit groups versus things like PolicyKit, it's basically the same thing: do we want to have an OS that is slimmer, more customisable and more stable, but needs hand-holding, or do we accept some degradation in flexibility/customisation in exchange for decreasing the cost of administration? I have personal preferences to one side, and practical preferences to another side. I'm not sure which is best in 2011, and it depends on many factors, but looking forward in 20 years: I don't think we will afford to hand-hold a Linux machine as mach as we were doing it 10 years or even 5 years ago. Presuming that software capabilities advance, it should be possible to hand-over responsibility of autoconfiguration to software, rather than hand-configuring config files (doing it via configuration management systems is beside the point, as it is a mixed setting; I'm discussing only the extremes). So in any case, we'll have to accept that at one point we will have to rely on automated stuff for some parts of the system. The question is when we as sysadmins will be ready to do that, and when the software will be mature enough to bear that kind of responsibility. And then there's my next gripe: what is good for a few systems (dpkg/apt-get) might not be good for many. I find lately that relying on dpkg plus a configuration management tool to keep many machines in sync is not the best way. Keeping with the time means changes, whether we want it or not. PS: for the record, not even my laptop(s) run NetworkManager :)

15 April 2011

Patrick Schoenfeld: Last time I've used network-manager..

Theres an ongoing thread on the Debian mailing lists about making network-manager installed by default on new Debian installations. I won't say much about the thread. Its just a prototype example for Debian project discussions: Discuss everything to death and if its dead discuss a little more. And - very important - always restate the same arguments as often as you can. Or if its not your own argument you restate, restate the arguments of others. Ending with 100 times stated the same argument. Even if its already disproved.

I don't have a strong opinion about the topic in itself. However there is something I find kinda funny. A statement brought up by the people who strongly oppose network-manager as a default.
A statetement I've heard so often that I can't count it anymore.

The last time I've tried network-manager it sucked.
It often comes in different masquerades, like:

But it basically boils down to that basic essence of the sentence I've written above. Sometimes I ask people who express this opinion a simple question:

When did you test network-manager the last time?
The answers are different but again the basic essence of the answers is mostly the same (even if people would never say it that way):

A long time ago. Must have been around Etch.
And guess what: There was a time when I had a similar opinion. Must have been around Etch.
During the life cycle of network-manager between Etch and now a lot has happened. I restarted using network-manager at some point of the Lenny development.
My daily driver for the management of my network connections on my notebook. Yes, together with ifupdown because, yes, network-manager does not support every possible network-setup with all of the special cases possible. But it supports auto-configuring of wired and wireless devices. Connecting to a new encrypted network, either in a WLAN or in a 802.1x LAN, using UMTS devices, using tethering with a smart phone. And everything: on a few mouse-clicks.

Yes, it had some rough edges in that life cycle. Yes, it had that nasty upgrade bug, which was very annoying.
But face it: It developed a lot. Here are some numbers:

Diffstat between the etch version and the lenny version:
362 files changed, 36589 insertions(+), 36684 deletions(-)

Diffstat between the Lenny version and the current version in sid:
763 files changed, 112713 insertions(+), 56361 deletions(-)

The upgrade bug has been solved recently. Late. But better late then never.

So what does that mean? It means that, if your last network-manager experience was made with Lenny or even worse around Etch, you should better give it another try, if you are interested in knowing what you talk about. For now it seems that a lot of people do not know. Not even in a distance.

14 April 2011

Jon Dowland: sortpaper

sortpaper
I stumbled across this file whilst sorting through some old backups. It's a "sortpaper": a wallpaper designed to aid people with sorting out files on their desktops. I thought I would share it in case anybody thought the concept was interesting: The size/aspect of the picture probably make it less practically useful today than whenever I first made it.

Lars Wirzenius: Project Harmony

It seems that Project Harmony has finally taken itself public. From the website:
Project Harmony is a community-centered group focused on contributor agreements for free and open source software (FOSS).
In reality, this seems to be a closed group that in no way represents the community in general and mainly acts in the interest of various corporations. Their goal is to create a bunch of templates for contracts to make participating in free software projects even more complicated than it already is. Look, we have a bunch of copyright licenses. They're not always easy to understand, and there's enough details and corner cases and interactions with the real world to make your head hurt. My head as well. (They're still easier, and more standardized, than contracts for proprietary software.) Contributing to a free software project is easy enough, in most cases. You make a patch, and if the project accepts it, yay. Your patch will be licensed the same way as all the other code. These Harmony agreements aim at making you give up your copyright to someone else, usually a corporate sponsor of the project. That's a bad thing. If the corporation owns the copyright, or you give them a license to do anything they wish with the project, they can do all sorts of evil things with it. For example, they can release it under a non-free license, or enter into complicated patent agreement with someone else that will require you to pay protection money later on, or something else. There is no end to the evil corporations invent, when given the chance. If, however, you refuse to give the corporation any ownership, or special powers, then their ability to do evil lessens, or at least you aren't helping them do that. It might be possible to use the Harmony agreements, as they are currently written, in ways that do not directly allow evil. However, why bother? By sticking to well-known, court-tested free software free software licenses, there is no need for the Harmony licenses. You get to keep the corporations honest, without having to read piles more legalese. Another way of looking at this: here's a bunch of corporations that want you to start using complicated legal documents for their benefit. Ask yourself, in what scenario is this going to be a good idea for you? Just say no to copyright assignments.

13 April 2011

Dirk Eddelbuettel: Rcpp 0.9.4, and a paper in the Journal of Statistical Software

A brand new 0.9.4 release of Rcpp is now on CRAN and Debian. This version contains an improvement to loading and initialization of Rcpp modules, a bug fix for vectors of factors, another build issue fix as well as (per common practice with JSS) citation information for the article Rcpp: Seamless R and C++ Integration which is now Volume 40, Issue 8 in the Journal of Statistical Software (or JSS for short). The complete NEWS entry is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.
0.9.4   2011-04-12
    o   New R function "loadRcppModules" to load Rcpp modules automatically
        from a package. This function must be called from the .onLoad function
        and works with the "RcppModules" field of the package's DESCRIPTION file
    o   The Modules example wrapped the STL std::vector received some editing
        to disambiguate some symbols the newer compilers did not like
    o   Coercing of vectors of factors is now done with an explicit callback
        to R's "as.character()" as Rf_coerceVector no longer plays along
    o   A CITATION file for the published JSS paper has been added, and 
        references were added to Rcpp-package.Rd and the different vignettes
Thanks to CRANberries, there is also a diff to the previous release 0.9.3:
Diff between Rcpp versions 0.9.3 dated 2011-04-05 and 0.9.4 dated 2011-04-12
 Rcpp-0.9.3/Rcpp/build                                              only
 Rcpp-0.9.3/Rcpp/inst/skeleton/yada.Rd                              only
 Rcpp-0.9.3/Rcpp/inst/unitTests/testRcppModule/R/Modules.R          only
 Rcpp-0.9.3/Rcpp/inst/unitTests/testRcppModule/man/yada.Rd          only
 Rcpp-0.9.4/Rcpp/ChangeLog                                             55 
 Rcpp-0.9.4/Rcpp/DESCRIPTION                                           10 
 Rcpp-0.9.4/Rcpp/NAMESPACE                                             29 
 Rcpp-0.9.4/Rcpp/R/Rcpp.package.skeleton.R                             11 
 Rcpp-0.9.4/Rcpp/R/loadRcppModules.R                                only
 Rcpp-0.9.4/Rcpp/inst/CITATION                                      only
 Rcpp-0.9.4/Rcpp/inst/NEWS                                             17 
 Rcpp-0.9.4/Rcpp/inst/doc/Makefile                                      2 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-FAQ.pdf                              binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-FAQ/Rcpp-FAQ.Rnw                       153 +-
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-extending.pdf                        binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-extending/Rcpp-extending.Rnw             2 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-introduction.Rnw                       734 ++++------
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-introduction.pdf                     binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-modules.pdf                          binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-modules/Rcpp-modules.Rnw                36 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-package.pdf                          binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-package/Rcpp-package.Rnw                 4 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-quickref.pdf                         binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-quickref/Rcpp-quickref.Rnw              34 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-sugar.pdf                            binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-sugar/Rcpp-sugar.Rnw                     2 
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp-unitTests.pdf                        binary
 Rcpp-0.9.4/Rcpp/inst/doc/Rcpp.bib                                     73 
 Rcpp-0.9.4/Rcpp/inst/doc/unitTests-results/Rcpp-unitTests.html        18 
 Rcpp-0.9.4/Rcpp/inst/doc/unitTests-results/Rcpp-unitTests.txt         40 
 Rcpp-0.9.4/Rcpp/inst/include/Rcpp/config.h                             2 
 Rcpp-0.9.4/Rcpp/inst/skeleton/zzz.R                                   11 
 Rcpp-0.9.4/Rcpp/inst/unitTests/runit.Module.client.package.R          27 
 Rcpp-0.9.4/Rcpp/inst/unitTests/runit.Vector.R                         18 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/DESCRIPTION              2 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/NAMESPACE                3 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/R/zzz.R              only
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/src/rcpp_module.cpp      6 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/src/stdVector.cpp       18 
 Rcpp-0.9.4/Rcpp/inst/unitTests/testRcppModule/tests/modules.R         21 
 Rcpp-0.9.4/Rcpp/man/Rcpp-package.Rd                                    6 
 Rcpp-0.9.4/Rcpp/man/loadRcppModules.Rd                             only
 Rcpp-0.9.4/Rcpp/src/r_cast.cpp                                         9 
 43 files changed, 647 insertions(+), 696 deletions(-)
As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

12 April 2011

Dirk Eddelbuettel: The new R compiler package in R 2.13.0: Some first experiments

R 2.13.0 will be released tomorrow. It contains a new package by R Core member Luke Tierney: compiler. What a simple and straightforward name, and something that Luke has been working on for several years. The NEWS file says
    o Package compiler is now provided as a standard package.  See
      ?compiler::compile for information on how to use the compiler.
      This package implements a byte code compiler for R: by default
      the compiler is not used in this release.  See the 'R
      Installation and Administration Manual' for how to compile the
      base and recommended packages.
so the compiler is not yet used for R's own base and recommended packages. While working on my slides for the upcoming Rcpp workshop preceding R/Finance 2011, I thought of a nice test example to illustrate the compiler. Last summer and fall, Radford Neal had sent a very nice, long and detailed list of possible patches for R performance improvements to the development list. Some patches were integrated and some more discussion ensued. One strand was on the difference in parsing between normal parens and curly braces. In isolation, these seem too large, but (as I recall) this is due some things 'deep down' in the parser. However, some folks really harped on this topic. And it just doesn't die as a post from last week demonstrated once more. Last year, Christian Robert had whittled it down to a set of functions, and I made a somewhat sarcastic post argueing that I'd rather use Rcpp to get 80-fold speed increase than spend my time argueing over ten percent changes in code that could be made faster so easily. So let us now examine what the compiler package can do for us. The starting point is the same as last year: five variants of computing 1/(1+x) for a scalar x inside an explicit for loop. Real code would never do it this way as vectorisation comes to the rescue. But for (Christian's) argument's sake, it is useful to highlight differences in the parser. We once again use the nice rbenchmark package to run, time and summarise alternatives:
> ## cf http://dirk.eddelbuettel.com/blog/2010/09/07#straight_curly_or_compiled
> f <- function(n, x=1) for (i in 1:n) x=1/(1+x)
> g <- function(n, x=1) for (i in 1:n) x=(1/(1+x))
> h <- function(n, x=1) for (i in 1:n) x=(1+x)^(-1)
> j <- function(n, x=1) for (i in 1:n) x= 1/ 1+x 
> k <- function(n, x=1) for (i in 1:n) x=1/ 1+x 
> ## now load some tools
> library(rbenchmark)
> ## now run the benchmark
> N <- 1e6
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
     test replications elapsed relative
5 k(N, 1)           10   9.764  1.00000
1 f(N, 1)           10   9.998  1.02397
4 j(N, 1)           10  11.019  1.12853
2 g(N, 1)           10  11.822  1.21077
3 h(N, 1)           10  14.560  1.49119
This replicates Christian's result. We find that function k() is the fastest using curlies, and that explicit exponentiation in function h() is the slowest with a relative penalty of 49%, or an absolute difference of almost five seconds between the 9.7 for the winner and 14.6 for the worst variant. On the other hand, function f(), the normal way of writing things, does pretty well. So what happens when we throw the compiler into the mix? Let's first create compiled variants using the new cmpfun() function and then try again:
> ## R 2.13.0 brings this toy
> library(compiler)
> lf <- cmpfun(f)
> lg <- cmpfun(g)
> lh <- cmpfun(h)
> lj <- cmpfun(j)
> lk <- cmpfun(k)
> # now run the benchmark
> N <- 1e6
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           lf(N,1), lg(N,1), lh(N,1), lj(N,1), lk(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
       test replications elapsed relative
9  lj(N, 1)           10   2.971  1.00000
10 lk(N, 1)           10   2.980  1.00303
6  lf(N, 1)           10   2.998  1.00909
7  lg(N, 1)           10   3.007  1.01212
8  lh(N, 1)           10   4.024  1.35443
1   f(N, 1)           10   9.479  3.19051
5   k(N, 1)           10   9.526  3.20633
4   j(N, 1)           10  10.775  3.62673
2   g(N, 1)           10  11.299  3.80310
3   h(N, 1)           10  14.049  4.72871
Now things have gotten interesting and substantially faster, for very little cost. Usage is straightforward: take your function and compile it, and reap more than a threefold speed gain. Not bad at all. Also of note, the difference between the different expressions essentially vanishes. The explicit exponentiation is still the loser, but there may be an additional explicit function call involved. So we do see the new compiler as a potentially very useful addition. I am sure more folks will jump on this and run more tests to find clearer corner cases. To finish, we have to of course once more go back to Rcpp for some <emph>real</emph> gains, and some comparison between compiled and byte code compiled code.
> ## now with Rcpp and C++
> library(inline)
> ## and define our version in C++
> src <- 'int n = as<int>(ns);
+         double x = as<double>(xs);
+         for (int i=0; i<n; i++) x=1/(1+x);
+         return wrap(x); '
> l <- cxxfunction(signature(ns="integer",
+                            xs="numeric"),
+                  body=src, plugin="Rcpp")
> ## now run the benchmark again
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           l(N,1),
+           lf(N,1), lg(N,1), lh(N,1), lj(N,1), lk(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
       test replications elapsed relative
6   l(N, 1)           10   0.120   1.0000
11 lk(N, 1)           10   2.961  24.6750
7  lf(N, 1)           10   3.128  26.0667
8  lg(N, 1)           10   3.140  26.1667
10 lj(N, 1)           10   3.161  26.3417
9  lh(N, 1)           10   4.212  35.1000
5   k(N, 1)           10   9.500  79.1667
1   f(N, 1)           10   9.621  80.1750
4   j(N, 1)           10  10.868  90.5667
2   g(N, 1)           10  11.409  95.0750
3   h(N, 1)           10  14.077 117.3083
Rcpp still shoots the lights out by a factor of 80 (or even almost 120 to the worst manual implementation) relative to interpreted code. Relative to the compiled byte code, the speed difference is about 25-fold. Now, these are of course entirely unrealistic code examples that are in no way, shape or form representative of real R work. Effective speed gains will be smaller for both the (pretty exciting new) compiler package and also for our C++ integration package Rcpp. Before I close, two more public service announcements. First, if you use Ubuntu see this post by Michael on r-sig-debian announcing his implementation of a suggestion of mine: we now have R alpha/beta/rc builds via his Launchpad PPA. Last Friday, I had the current R-rc snapshot of R 2.13.0 on my Ubuntu box only about six hours after I (as Debian maintainer for R) uploaded the underlying new R-rc package build to Debian unstable. This will be nice for testing of upcoming releases. Second, as I mentioned, the Rcpp workshop on April 28 preceding R/Finance 2011 on April 29 and 30 still has a few slots available, as has the conference itself.

11 April 2011

Dominique Dumont: Changing e-mail in package control file is now easy

I often see on debian-perl IRC changelog related to e-mail changes. For instance, when a Debian contributor becomes a Debian developer, he often wants to change his old e-mail address in his brand new debian e-mail address. This change is mostly done while updating packages to fix bugs or ship a new upstream releases. Since this change is trivial and mostly boring, forgetting about it is likely. Well, at least, that s true for the author of this blog who did have to change he e-mail address recently. The last version Config::Model Perl module (and its Dpkg model) offers a way to automatically perform this boring update task for you while you work on more interesting problems. Dpkg model now provides a bunch of meta Dpkg parameters. These Meta parameters are used to customize the behavior of the Dpkg editor tool to suit your needs. Among these parameters, the email-updates meta parameters enable you to specify which email address to update and how. Here s a screenshot of config-edit GUI invoked on a package (with config-edit -application dpkg): GUI to set up e-mail replacement In this case, all occurrences of the dominique.dumont email will be replaced with the new domi.dumont email in the control and in the copyright file. You can change or add new addresses using the GUI. When the package data (i.e. control, copyright and source) is saved, all meta information is also saved. Meta dpkg data is saved in its own file, so the email change will be applied to all packages you will be working on: E-mail address changes can also be specified in a command line:
$ config-edit -application dpkg \
  'meta email-updates:"domi@old.fr"="dod@new.fr"' \
 -ui none -save
Note: this command must be run in a source package directory. This new address change is stored in ~/.local/share/.dpkg-meta.yml or ~/.local/share/.dpkg-meta.yml:
---
email-updates:
  domi@old.fr: dod@new.fr
From now on, anytime you run config-edit -application dpkg (and save the data) while you work on a package, all occurrences of your old e-mail adress in debian.control will be changed with the new email address. All the best

Rapha&#235;l Hertzog: Journey of a new GNOME 3 Debian packager

With all the buzz around GNOME 3, I really wanted to try it out for real on my main laptop. It usually runs Debian Unstable but that s not enough in this case, GNOME 3 is not fully packaged yet and it s only in experimental for now. I asked Josselin Mouette (of the pkg-gnome team) when he expected it to be available and he could not really answer because there s lots of work left. Instead Roland Mas gently answered me Sooner if you help . :-) First steps as a GNOME packager This is pretty common in free software and for once I followed the advice, I spent most of sunday helping out with GNOME 3 packaging. I have no prior experience with GNOME packaging but I m fairly proficient in Debian packaging in general so when I showed up on #debian-gnome (irc.debian.org) on sunday morning, Josselin quickly added me to the team on alioth.debian.org. Still being a pkg-gnome rookie, I started by reading the documentation on pkg-gnome.alioth.debian.org. This is enough to know where to find the code in the SVN repository, and how to do releases, but it doesn t contain much information about what you need to know to be a good GNOME packager. It would have been great to have some words on introspection and what it changes in terms of packaging for instance. Josselin suggested me to start with one of the modules that was not yet updated at all (most packages have a pre-release version usually 2.91 in experimental, but some are still at 2.30). Packages updated and problems encountered (You can skip this section if you re not into GNOME packaging) So I picked up totem. I quickly updated totem-pl-parser as a required build-dependency and made my first mistake by uploading it to unstable (it turns out it s not a problem for this specific package). Totem itself was more complicated even if some preliminary work was already in the subversion repository. It introduces a new library which required a new package and I spent a long time debugging why the package would not build in a minimalistic build environment. Indeed while the package was building fine in my experimental chroot, I took care to build my test packages like the auto-builders would do with sbuild (in sid environment + the required build-dependencies from experimental) and there it was failing. In fact it turns out pkg-config was failing because libquvi-dev was missing (and it was required by totem-pl-parser.pc) but this did not leave any error message in config.log. Next, I decided to take care of gnome-screensaver as it was not working for me (I could not unlock the screen once it was activated). When built in my experimental chroot, it was fine but when built in the minimalistic environment it was failing. Turns out /usr/lib/gnome-screensaver/gnome-screensaver-dialog was loading both libgtk2 and libgtk3 at the same time and was crashing. It s not linked against libgtk2 but it was linked against the unstable version of libgnomekbdui which is still using libgtk2. Bumping the build-dependency on libgnomekbd-dev fixed the problem. In the evening, I took care of mutter and gnome-shell, and did some preliminary work on gnome-menus. Help is still welcome There s still lots of work to do, you re welcome to do like me and join to help. Come on #debian-gnome on irc.debian.org, read the documentation and try to update a package (and ask questions when you don t know). Installation of GNOME 3 from Debian experimental You can also try GNOME 3 on your Debian machine, but at this point I would advise to do it only if you re ready to invest some time in understanding the remaining problems. It s difficult to cherry-pick just the required packages from experimental, I tried it and at the start I ended up with a bad user experience (important packages like gnome-themes-standard or gnome-icon-theme not installed/updated and similar issues). To help you out with this, here s a file that you can put in /etc/apt/preferences.d/gnome to allow APT to upgrade the most important GNOME 3 packages from experimental:
Package: gnome gnome-desktop-environment gnome-core alacarte brasero cheese ekiga empathy gdm3 gcalctool gconf-editor gnome-backgrounds gnome-bluetooth gnome-media gnome-netstatus-applet gnome-nettool gnome-system-monitor gnome-system-tools gnome-user-share baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-system-log gstreamer0.10-tools gucharmap gvfs-bin hamster-applet nautilus-sendto seahorse seahorse-plugins sound-juicer totem-plugins remmina vino gksu xdg-user-dirs-gtk gnome-shell gnome-panel dmz-cursor-theme eog epiphany-browser evince evolution evolution-data-server file-roller gedit gnome-about gnome-applets gnome-control-center gnome-disk-utility gnome-icon-theme gnome-keyring gnome-menus gnome-panel gnome-power-manager gnome-screensaver gnome-session gnome-settings-daemon gnome-terminal gnome-themes gnome-user-guide gvfs gvfs-backends metacity mutter nautilus policykit-1-gnome totem yelp gnome-themes-extras gnome-games libpam-gnome-keyring rhythmbox-plugins banshee rhythmbox-plugin-cdrecorder system-config-printer totem-mozilla epiphany-extensions gedit-plugins evolution-plugins evolution-exchange evolution-webcal gnome-codec-install transmission-gtk avahi-daemon tomboy network-manager-gnome gnome-games-extra-data gnome-office update-notifier shotwell liferea epiphany-browser-data empathy-common nautilus-sendto-empathy brasero-common
Pin: release experimental
Pin-Priority: 500
Package: *
Pin: release experimental
Pin-Priority: 150
The list might not be exhaustive and sometimes you will have to give supplementary hints to apt for the upgrade to succeed, but it s better than nothing. I hope you find this useful. I m enjoying my shiny new GNOME 3 desktop and it s off for a good start. My main complaint is that hamster-applet (time tracker) has not yet been integrated in the shell.

21 comments Liked this article? Click here. My blog is Flattr-enabled.

Cyril Brulebois: Debian XSF News #10

This is the tenth Debian XSF News issue. It is basically meant to be a follow-up to DXN#9.
  1. I completed the addition of the Sinhala language, and also dealt with big changes on the xkb-data (a.k.a. xkeyboard-config) side, as explained by Sergey Udaltsov. Protocol:
    • [KiBi] x11proto-core: the upload to experimental was a bit overcautious, so upload again unstable.
    Data: Library:
    • [KiBi] libx11: new upstream release, adding support for Sinhala unstable.
  2. The Graphical Installer started receiving improved portability. There were a few patches floating around adding udebs for generic drivers for non-Linux architectures. I cleaned them up a bit (especially on the vesa side, getting rid of libdrm entirely), got them test-built on a kfreebsd-amd64 box, while Samuel Thibault was doing the same on a hurd-i386 box. I raised the topic on debian-boot@, debian-bsd@, and debian-hurd@, mentioning the remaining steps. Drivers (all accepted by ftpmasters after a tiny trip to the NEW queue):
  3. Here are some other packages which got updated. Applications: Library:
    • [Chris,Julien,KiBi] mesa 7.10.1: long-awaited upload, finally checked, built, and uploaded experimental.
  4. Finally, let s mention migration to testing (from now on I ll use testing instead of wheezy so that it s clear it s about week after week migrations to the testing distribution, rather than our final plans for the next stable release). After a while, and thanks to some hand-holding from our nice release managers (hi, Adam!), linux-2.6, libdrm, mesa, xorg-server, and several dozen drivers migrated to testing. Yay!
  5. As a consequence, some other packages got updated shortly after the successful britney run (because they were prepared right before, just in case). Libraries:
    • [KiBi] libdrm: replace 2.4.23 with 2.4.24 (which was in experimental previously) unstable.
    • [KiBi] mesa: new stable release, 7.10.2 supersedes both 7.10 in unstable and 7.10.1 in experimental (see above) unstable.
    • [KiBi] pixman: new development snapshot, 0.21.6 comes from experimental and supersedes 0.21.4 unstable.
    Drivers:

10 April 2011

Cyril Brulebois: Getting replaced by scripts

As already blogged by Riku, getting replaced by script is really great! Until now, I ve had a crontab fetching my supporting-very-big-mails (up to 100MB or so) mailbox every few minutes, and looking into my =incoming-buildd/ maildir on a very regular fashion. With some simple mutt maildir hooks, replying to a Successful log would trigger extracting the changes file from there, setting some options, like PGP inline signing, and the mail would be ready to go back to the buildd. That part was just about being a GPG-signing monkey, so really not a funny part. Since we no longer have to worry about this boring and time-consuming task, I ve switched to a crontab firing up 4 times a day, and I try to deal with all incoming mails at once. Coupled with the new filters (e.g. on out-of-date packages on the buildd status page), I started using my time to file FTBFS bugs again, so that maintainers notice their packages fail to build without having to wait for a non-happening testing migration. After 10 days, the following mutt filter in =debian-bts/ lists 69 bugs:
~s "Bug#.*FTBFS" ~P ~d 01/04/2011-
(Subject contains Bug#.*FTBFS, mails from me, starting from 01/04/2011.) Figuring out whether that s due to another package s bug, an outdated chroot, a temporary glitch, etc. might take some time; that s why it s a bit hard to stay on top of things; and when the backlog grows up, motivation to go through this tedious task can be pretty low, especially when one sees repeated mistakes. I hope the amount of (possible) use cases for #620686 will decrease over time; instead, I d be very happy if maintainers could at least check what s mentioned in configure.ac/configure.in. Keeping an eye on its diff between upstream versions should be easy enough. ;)

Niels Thykier: More fun with cross package checks

About a week ago, I wrote about doing cross package checks in Lintian. At that time I had only played with looking up manpages in direct dependencies, which I hope will greatly improve the current binary-without-manpage stats (around 677 packages and 2750ish tags incl. overrides). Today, I decided to take on another challenge. Detection of circular dependencies between binary packages (created from the same source). We already have a little library for building dependency relationships; however I ended up not using it, since it has an important limitation. It cannot tell how the circular dependencies relate to each other. Let me demonstrate what I mean with an example. Suppose we have a couple packages that depend on each other like this:
pkg-core => pkg-A, pkg-D
# circle 1: A, B, C
pkg-A => pkg-B
pkg-B => pkg-C
pkg-C => pkg-A
# circle 2: D, E, F
pkg-D => pkg-E
pkg-E => pkg-F
pkg-F => pkg-D
In this case, our current tool will be able to tell that all packages (possibly except root I did not check) are in a circular relationship. However, we can find better results by pretending we are trying to find Strongly Connected Components (actually that is exactly what we are trying to do here). So today, I implemented Tarjan s algorithm in Perl to solve this particular issue and committed it to my Lintian branch. If this branch is merged into the Lintian master branch, we can close #316283.

Steve McIntyre: Naming and shaming spammers, #2 in an occasional series

Spammer Number 2:Tata Technologies (aka myigetit.com) via Streamsend Again, it looks like Streamsend are being spamming bastards. Guilty of: spamming lots of Debian mailing lists. They claim to offer "Online Self-Paced Training for Engineers". I guess that's training in "how to be obnoxious to people on the internet" then. It looks like it's a good idea to simply drop all connections from machines in the mailengine1.com domain. Following up through whois, that's another domain owned by EZ Publishing, the same folks who own streamsend.com. Spamming bastards all over...

Christian Perrier: [life] [running] 2nd step of my wspring challenge done

At about 12:45 today, I completed my third Paris Marathon and my 7th marathon overall (incl. 2 unofficial ones, ran alone). As I wrote earlier, the challenge this year was not breaking a record. I wanted to complete two long races in only two week, as a gift for my birthday that happened between both. So, after Paris Paris Ecotrail 55km race, I ran my beloved Paris Marathon. So, I ended up in 3h54'37", 5 minutes more than last year and 14 minutes more than my personal best The heat was the ennemy, today. A wonderful sun was shining over Paris, which is nice....but brings the temperature up to 23 C. So, the solution had to be "drink, drink, drink". I think I drank something like 4 liters, today. I was planning to start around 5'25/km but finally ended up with about 5'20", which I sustained up to km 25 and the terrible Louvre tunnel (1km in a tunnel on the right bank speedway, under Quai du Louvre). That one was a killer this year and many runners blew up in it. I then decided to use the opportunity to walk a little bit, eat my mid-marathon glucides and slow down slightly later on for the upcoming tunnels (two more...though less long). That was in some way the famous 30km wall, which, for me, was moved to km28..:-) Later on, as usual, courage enters the game and I roughly managed to keep a 5'30"-5'45" pace up to the end of the race. Cramps signs appeared around km 35 but, here again, a wise slowdown and some walking, a lot of drinking helped me in controlling them. Finally, the result is about what I intended to do. Over 4h, I would have been disappointed even if happy to finish (as everybody tells me that my challenge was kinda crazy). Abandoning would have been the real defeat. I did not..:-) And, thanks, of course, to my beloved Elizabeth who again managed to deal with his "Kiki" logistics, includiung waking up at 6am on a Sunday. Now, my running schedule will slow down a little with only training for 5 weeks. Next race: Trail des Cerfs, a 35km trail in Rambouillet Forest close to home. I may again schedule a solo marathon, at training pace, end of May, in Versailles Castle park. Next marathon: Berlin, Sept 25th. Here, the goal is breaking the personal best and head up to 3h35.

8 April 2011

Michal &#268;iha&#345;: Bits from GSoC applications

Reading GSoC applications is sometimes funny. This year I've decided to be active only in phpMyAdmin projects, but this still gives enough interesting texts. Some people definitely did not even care about looking at our name and think phpMyAdmin is written in C:
I assume this project would require C/C++ programming and, of course, SQL.
We ask people to tell us a little about their real life, in most cases this includes information where did the student study and so on, but sometimes it is just:
I'm a fairly standard guy.
In some cases people rather use some random file sharing service to post their CV and I'm too impatient to wait for several minutes till free download is available and I'm definitely not going to pay to download it. PS: As usual, the last day we receive most incomplete proposals over the time. Generally I think that the best proposals arrive at beginning and the quality lowers. This is probably heavily influenced by our requirements for students to know the code before and advertising GSoC early, so that the really interested ones are ready to submit proposals as soon as the interface is open, while others trying to catch train later.

Filed under: English Phpmyadmin 1 comments Flattr this!

7 April 2011

Rapha&#235;l Hertzog: People behind Debian: Adam D. Barratt, release manager

Adam D. Barratt is a Debian developer since 2008, in just a few years he got heavily involved to the point of being now Release manager , a high responsibility role within the community. He worked hard with the other members of the release team to make Squeeze happen. You could expect the release managers to have some rest after a big release, but it s not really the case. With the long freeze, loads of transitions have accumulated and they are now busy to get all those updated packages in the new testing (wheezy). Despite this Adam took some time to answer my questions. He shares with us his impression on the Squeeze release, his opinion on time-based freezes (regular/predictable freeze) and much more. Read on. My questions are in bold, the rest is by Adam. Who are you? I m a 31 year old software developer and part-time sysadmin for a software and IT services company based in the south of England. I have no children, no pets and a long-suffering partner who puts up with me spending far too much time tinkering with things and people making fun of her Macbook during Debconf. As well as being on the release team, I m a member of the maintainer teams for devscripts and lintian. Can you describe your journey in Debian and in the release team? I was introduced to Debian as part of an infrastructure upgrade at work, moving from a set of Red Hat and Solaris-based systems. As part of that, we submitted some bugs for issues we found during the upgrade and for small patches we included in some software to add extra functionality we wanted. From that starting point I became more interested in Debian in general and began following some of the mailing lists and IRC channels. When Julian Gilbey asked for help with the maintenance of devscripts, I submitted some patches for some of the outstanding bug reports and was invited to join the team which was being created to handle maintenance for the package. One of the then Release Managers was also on the team and asked if I d be interested in working on a couple of updates they wanted to the scripts which generate the proposed-updates overview pages. I added the new functionality which was merged in to the live scripts and a little while later I was invited to join the team, shortly before Debconf 9. As most readers will be aware, we unfortunately reached a point during last year where we didn t have anyone filling the Release Manager role. During that period, I became more active in handling transitions and requests for updates to stable and as time went on more people started to suggest that I should put myself forward for the position, or refer to me as already being RM. I procrastinated over the decision for some time but after discussions during Debconf 10 I came round to the idea that we should have the RM role filled again and agreed to take it on, together with Neil. The rest, as they say How much time do you usually spend working for the release team ? I ve been trying to work out how to usefully answer this question. My initial answer was approximately two hours each day , but the longer I thought about it the more I started debating exactly what I should include under the umbrella of release work; after some to-and-fro I ve decided to stick with my initial answer. During periods when Debian is frozen and particularly in the lead up to the release that time commitment increases significantly, particularly over weekends. I m reliably informed that at that point the correct answer to the question is too much time . :-) What s your own retrospective of the Squeeze release? What went well and what needs to be improved? Overall, I believe the release went well and that we should all be proud of the Squeeze release. The parts of the release cycle which highlighted the need for improvement all share, imo, a single root cause communication, particularly around freeze-related plans. We worked hard during the freeze itself to improve our communication with the rest of the project and want to continue in that vein during the Wheezy cycle. One thing that I personally found quite difficult at times before the freeze was keeping track of the transitions which were still waiting for a place in the queue; it s also something that we could improve on at this early stage of the Wheezy cycle. In order to help us keep a clear overview of requests for transitions, stable updates and binNMUs, it would be helpful if they could be filed as appropriately user-tagged bugs. This not only allows us to easily get an overview of the status of requests from the BTS but also aids transparency by allowing anyone else to do so; as a useful additional feature, it means that we can use the BTS s blocking functionality to indicate reasons why a request cannot be fulfilled right now. Are you in favor of time based freeze? I think there s merit in having a time frame that we can work towards in order to achieve the goals which we set ourselves for the release, as individual maintainers, maintenance teams and a project. I do have concerns that even with such a time frame in place there will still be uploads made very close to the proposed freeze point and transitions which may be unfinished, for example because of an unforeseen entanglement with or reliance on the transition of another package. One thing I m interested in is how exact and specific that time frame should be and the balance between predictability and being able to achieve everything we want for a great release; this is something we can cover in the debate on this subject which I know many people have strong opinions about. What are your plans for Debian Wheezy? The Wheezy to-do list I started before the final Squeeze release begins multiarch, multiarch, multiarch . It looks like we re finally going to get that achieved during this release cycle, thanks to a great deal of hard work from various people. I m also interested in seeing the C.UTF-8 locale standardised throughout Debian and continuing to work on our tools and processes to make tracking of transitions and stable updates simpler (or at least appearing to be so :-) and more transparent. With my package maintenance hats on, I d like to help ensure that both devscripts and lintian are able to keep pace with changes in the development landscape in Debian (e.g. more useful package diffing for source format v3 packages) and continue to be tools that are an integral part of package development in Debian. Some people (including me) would like a rolling distribution constantly usable by end-users. Do you think that the release process currently geared towards producing stable can be accommodated to support this? I m not yet convinced that the concept of a rolling, constantly usable distribution can be easily integrated in to the workflow that exists around preparing stable releases in Debian. The testing distribution was created as, and continues to be used as, a tool to enable the release team to create the next stable release that it happens to be something that people can use every day for much of the time is mostly a happy side-effect of the fact that we don t gratuitously break it, but is by no means guaranteed to be the case early in the release cycle or during large, disruptive, transitions. It s been suggested that testing and rolling could be basically the same for most of the cycle, with rolling then continuing to be updated when testing is frozen. This would essentially mean an extra suite which is only used for a few months every couple of years or so, which is one of the things that testing was intended to avoid (i.e. the old frozen suite) and seems like a lot of overhead to introduce in order to reduce disruption to some users during the freeze. The early part of the release cycle also tends to include a number of larger transitions which often require packages to either be removed from testing or broken as part of migrating the transition, if they are not able to be successfully updated in time. What s the biggest problem of Debian? The thing that I ve been noticing myself becoming frustrated by recently is a tendency to debate the minor details of proposals, rather than concentrating on getting the key points right to begin with. Clearly for some projects such as multiarch the details may be as important as the big picture, but in most cases the people working on a development should be allowed to look after the smaller details themselves. That s not meant to imply that feedback from other parts of the project should not be welcomed, simply that if we consider Debian to be a do-ocracy then we need to permit people the freedom to do . Is there someone in Debian that you admire for their contributions? All previous release managers, for making the job look much easier than it seems when you re in the hot seat . :-) Outside of the release team, Joey Hess for his contributions to various parts of the Debian development environment over the years, such as debhelper and debian-installer, and Colin Watson for his enviable willingness to tackle a wide variety of different projects within Debian.
Thank you to Adam for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Lars Wirzenius: cliapp, a Python command line app framework

Whenever I develop a little command line tool, I end up writing some boilerplate code. For example:
import optparse
p = optparse.OptionParser()
p.add_option('--output', metavar='FILE', help='write output to FILE')
...
Option parsing is one of those things that is easy to do, but doing it over and over again gets tedious. There's a bunch of things that pretty much all of my command line tools end up needing to do, even if they're throwaways: A while ago I decided that it was silly of me to write that code repeatedly, or to copy-paste things from project to project. Instead, I decided, I would write a framework that does things for me, and requires minimal setup code from me. cliapp is the result. Its API seems to now be stabilizing, so I thought I'd mention it publically, in case others might find it useful, too. So far, I've found it quite liberating to be able to crank out small scripts more easily than before. My threshold for switching from shell to Python is now quite a bit lower. I have one example online, to give flavor. The README has some explanation of what's going on. There's a Debian package on my code hosting site; see link from cliapp's home page. I'd welcome any feedback.

Next.

Previous.