The RISE co-op is the sole shareholder in the Social Enterprise Mark CIC and its members have been called to an Extraordinary General Meeting during the lunch break of next Tuesday s Knowing and Growing conference at UWE Bristol. The RISE board has proposed Four Special Resolutions that would dissolve the co-op and transfer all assets as windfalls to the SEM CIC and a trust, ignoring RISE Ltd s Memorandum of Association. software.coop is calling on other RISE members to attend the EGM and oppose this demutualisation attempt. Update: dissolved but not demutualised (see below) RISE is constituted as a common ownership co-op and its Memorandum of Association contains a clause that directs the assets to be transferred to another common ownership social enterprise organisation if the co-operative is dissolved. However, unlike the CIC asset lock, there is no independent regulator enforcing it and, unlike in many co-ops, there has been no requirement for new members to pledge to obey the RISE common ownership clause at an individual level and there has been no member education about common ownership in the last three years. This demutualisation is the wrong solution for RISE because:

• it has recieved much public money and money from members on the understanding that it would be kept in common ownership;
• there are common ownership social enterprises that could really benefit from the legacy assets at this time of budget cuts, but if those assets go to a CIC, they are lost from common ownership;
• the EGM is the day after the global launch of the United Nations International Year of Co-operatives, which is about promoting mutualism around the world and the RISE co-operative should support this;
• many RISE members are mutuals, including the world s largest consumer co-operative and demutualisation would be embarassing to them;
• demutualisation should be discussed seriously, through a proper democratic process before the regular Annual General Meeting, not sprung from the board to members in a short meeting during the lunch break of another event;
• the proposal has not been published on RISE s website or email newsletter;
• appointing the former directors of a dissolved co-op as trustees without member oversight seems unlikely to secure the assets in the long term.

software.coop will vote against the demutualisation, in favour of social enterprise, and calls on other RISE members to show solidarity with the co-operative and common ownership social enterprise movements. Update 2 November: rise has announced its dissolution but they ve got to give further consideration to where the assets go because the demutualisation resolutions were defeated. I fear that they ll still try some way to bail out the Social Enterprise Mark despite the rejection, but I hope they ll do the right thing and give the assets to good common ownership social enterprise like the RISE Memorandum of Association requires.

Currently Dick Smith is offering two dual-SIM mobile phones for sale in Australia. One is the LG T510 for $99, but it only supports GSM on each SIM. This might be a good phone for someone who needs to receive both work and personal calls and doesn t want to carry two phones, but the lack of 3G support is a major limit on what can be done with the phone. The other phone is the Huawei U8520 which supports 3G on one SIM and GSM on the other. It costs $249, runs Android 2.2, has a 320*480 display, and a 3.2 megapixel camera. For comparison the LG Optimus One is a single-SIM phone with similar specs that only costs $179 from TeleChoice, so there is a 40% price premium to pay for a dual-SIM phone. When I first heard about dual-SIM phones (before they were commonly and cheaply available in Australia) I had thought that it would be a good option for using a cheap 3G broadband SIM along with a SIM for voice calls from one of the cheaper pre-paid mobile companies. But the helpful guy at Dick Smith informed me that Amaysim offers good pre-paid deals for voice and data [1]. With 10G of data quota to be used in one year for $100 and reasonable rates on voice calls it should be easy to keep under $200 per annum if you don t use many calls. Rene Cunningham has described how to use a pre-paid data-only plan on the Optus network with VOIP for most outbound calls [2]. To do that he is paying $30 every 6 months to keep his old number for inbound calls for which he gets $30 of credit, with Amaysim you can pay $10 every 3 months to get the same result with $40 per annum call cost instead of $60. As Amaysim are on the Optus network the result should be the same as long as Amaysim have enough capacity for IP data transfer. Rene uses an iPhone but the same result can be achieved with an Android phone. If by using VOIP the cost of running a phone on Amaysim was reduced to something like $160 per annum (with a possibly optimistic aim of $20 per annum for outbound VOIP calls) then over two years that could save $376 over a $29 per month contract. A Virgin $29 contract includes a Sony Ericsson Xperia X10 which is a fairly nice phone if you can deal with the short battery life and the fact that it s locked to Android 2.1. An Xperia X10 can be bought on Ebay for less than $376 but the hassle of setting up VOIP and Amaysim will be more effort than it s worth to save $100 over two years. A couple of my relatives have phone contracts that are about to expire. I m not going to set them up on VOIP as it s too much effort for too little benefit and the dual-SIM phone really isn t an option. I will recommend Virgin contracts with Xperia X10 phones or Amaysim with their existing phones (2yo smart phones that are still quite usable).

• [1] https://www.amaysim.com.au/mobile-plans/amaysim-as-you-go.html
• [2] http://rene.bz/9-months-on-a-data-only-mobile-phone-plan/

After finalizing DOF Calc 0.1.0 yesterday, I've decided to push new version of GePeS as well. The update utilizes new Meego loader, so application should start much faster, add azimuth calculation for sun (set, rise and current) as well as compass is utilized for showing this azimuth. You can check all new features on screenshots page. New version is currently available in git and tarballs, binary version will be in Nokia store as soon it passes QA tests there.

Filed under: English Meego 0 comments Flattr this!

On a recent visit to my local e-waste disposal place I noticed an open PC on the top of the pile with a pair of DIMMs that were begging to be removed. I also noticed three PCI Ethernet cards that were stacked in a manner that made them convenient to grab possibly some nice person deliberately placed them so someone like me could take them. The DIMMs turned out to be 3G of DDR2-800 RAM and were regarded as good by Memtest86+ a nice upgrade for one of my test systems that previously only had 1G of RAM. If you have old hardware to dispose of then please try to take the RAM to your local computer users group meeting. In any such gathering there s always someone who wants old RAM, anything better than PC-133 will find good home unless it s very small (128M sticks of DDR-266 and 256M sticks of anything faster probably won t get any interest). RAM is small and light so you can carry it in your pocket without inconvenience. Ethernet cards of all vintages are in demand due to people reusing old desktop systems as routers and PCIe video cards are in great demand, PCI and PCIe cards are small enough that it s usually not a great inconvenience to transport them. Hard drives larger than about 100G are in demand as are ATX power supplies, these are really inconvenient to transport unless you travel by car. For computer systems, anything that can use DDR2-800 RAM will probably be of use to some member of a computer users group, if you offer it on the mailing list then you can expect that someone will want to collect it from you at your home or a meeting. There are organisations such as Computerbank that take donations of old hardware and make systems for disadvantaged people [1], it s worth considering them if you have hardware to dispose of. But for me the hardware I use every day is quite close to the minimum specs for donations that Computerbank will accept so there s no possibility of me discarding systems that are useful to them. I ve created a page listing hardware that I need, if anyone in my area has such hardware that they don t need then please let me know [2].

• [1] http://www.computerbank.org.au/recycle
• [2] http://etbe.coker.com.au/hardware-i-need/

I've been doing some updates to DOF Calc in last days and today I decided it's time to push new it to public. The application has been switched to dark theme (which seems to be preferred one) and got working settings module. This means you can now configure list of cameras, lenses and apertures it offers, so that only choices you really use will be show. New version is currently available in git and tarballs, binary version will be in Nokia store as soon it passes QA tests there. Besides that, application got new homepage with screenshots (what is true for GePeS as well).

Filed under: English Meego 0 comments Flattr this!

Review: Scrum and XP from the Trenches, by Henrik Kniberg

Publisher:	InfoQ
Copyright:	2007
ISBN:	1-4303-2264-0
Format:	Trade paperback
Pages:	127

For those not already familiar with it, Scrum is a project management methodology that's most often seen in the agile software development community. It attempts to do for project management what agile techniques do for software development (and, other than test-driven development, I think is more useful than most of agile). I'm not going to explain it here in detail, but if you do software development or project management of software-style projects (including integration and computing infrastructure), it's worth your attention. It provides some nice techniques for dealing with some of the banes of technical projects, particularly constantly changing requirements and the difficulties of estimates. Scrum and XP from the Trenches is subtitled "How we do Scrum" and is exactly what it says on the tin. It is a fairly detailed description of how Crisp (an agile Java development company in Sweden) does Scrum (with a little discussion of Extreme Programming). It doesn't explain what Scrum is, although it does provide a few pointers to resources if you've never heard of it (but this isn't the sort of book you'd be buying if you'd never heard of it). It also doesn't try to convince you that Scrum is wonderful, which is a nice trap to avoid. It gets right down to business and packs quite a bit of relentlessly practical content into a small number of pages. I've been doing Scrum for about a year, across two large projects, both times not entirely following the full Scrum model. Both times, most of the team was learning Scrum during the project. I've gone to some Scrum training and read a bit, largely on-line, but I haven't made an exhaustive study of it. I think I'm exactly the ideal audience for this book, although my guess is that people who have been doing Scrum for longer will also get something out of it. This is not an introduction; I don't think one is likely to get much benefit out of it without a couple of Scrum projects under one's belt so that one has a feel for the problems and failure modes. As Kniberg accurately points out, Scrum is a framework, not a precise rule set, and it can't be applied blindly in one situation using analysis from another. For that audience, though, this book is great. Kniberg has used Scrum in a variety of different situations and tried multiple solutions to many of its problems, so he can provide guidance not only on his preferred solutions but on the other solutions he's tried and why they don't work. I started taking extensive notes just a few pages in; it was exactly the book I needed to read for the full-project retrospective on how Scrum worked for a just-concluded work project, and for planning what changes we'll want to make for the next project. He goes through every step of the Scrum cycle and offers advice on each step, particularly for the sprint planning (which was extremely helpful). He then walks through release planning and advance estimation (one of the best parts of the book; I've seen the concept of a focus factor before, but this is one of the best and clearest explanations I've seen), talks about XP (Extreme Programming) techniques and testing, and then discusses how to coordinate multiple Scrum teams in a larger organization. The chapter on testing was the reason why I bought the book; the rest of the book lives up to it. As mentioned, my Scrum exposure is not broad, so Kniberg may just be following different orthodoxies. That said, he broke with the ones I was previously familiar with in some useful places. One is to attach a time unit to story points, something that I was told was close to anethema, but as presented here looks very useful. Another, not so much a break but an idea that I'd not encountered elsewhere, is downtime between sprints, an brilliant solution to a problem that I'd not even fully articulated but which had been plaguing our Scrum process. He also has some suggestions about communication that, while fairly obvious and common-sense stuff, still were things that hadn't occurred to me and that we should adopt. I paid for a hard-copy version of this book from Lulu because I like things like this on paper and am happy to support the author financially, but you can download a PDF file and read it for free from InfoQ and see whether it works as well for you as it did for me. If you're ramping up on Scrum, seeing some problems, and looking for good ideas on how to fix them, I highly recommend it. I'd love to read two or three more case studies like this to get some more perspectives on how to make Scrum work. The paper book will likely be making a circuit around our office to serve as fodder for our upcoming Scrum projects. Rating: 8 out of 10

Finally! Last Friday, after two years worth of work, I finally got the first box of books for the Construcci n Colaborativa del Conocimiento (Collaborative Knowledge Construction) project I worked on as a coordinator together with Alejandro Miranda (pooka), and together with a large group of 11 authors: Translating over from the back cover text (and this is just a quick translation from me It reads better in Spanish ;-) ):

What defines us as humans is our ability, on one side, to
create knowledge, and on the other, to share or communicate it with our neighbors. Both features have worked together over tens of thousands of years, and, working together, have led the knowledge to transcend the individual, avoiding the need to rediscovery or reinvention of is already known. Sharing knowledge is what has taken our species to the dominant role it occupies today. But knowledge creation and sharing has seen a deep transformation in recent decades, thanks to the quick evolution of telecommunications, specially the massification of Internet and cellular telephony. We are transiting towards the so desired and at the same time so feared knowledge society. In this book, eleven authors from very different disciplinary backgrounds and geographic origins ellaborate on how a hyper-connected world has modified the basic rules of interaction in areas as diverse as artistic creation, social organizations, computer code development, education or the productive sector. This book is the result of a year worth of work for in the "Collaborative Construction of Knowledge" seminar, during which we
used the same new forms of knowledge production we have studied. The videos of the sessions, electronic participations and the full contents of this book are available under a permisive license at
http://seminario.edusol.info/seco3/

We will soon have the book ready in IIEc's e-store (which is mostly meant for national requests). I am also uploading the book to the lulu.com self-publishing service, and we are working on a epub-like edition. Right now it is still not available, but it should be there in some days. I will keep you posted. Meanwhile, the full contents can be read online at http://seminario.edusol.info/seco3

There are six servers. They're meant to be used for the same purpose, and are mostly the same too, but not quite entirely. This being the case, mostly because of how they were maintained in the past: with cssh mostly, but it's inevitable that eventually there will be differences. So we're in the process of migrating them to puppet now. One of the things I need to do while doing that, however, is figure out what the differences are, and get rid of them where applicable. Differences such as, say, in the installed packages. Some of these servers have extra things installed, for a reason that isn't clear anymore, that others don't. So how does one figure out what the difference is? If this were two servers, I'd create a list of installed packages and use 'diff' on them. If there were three, I'd use 'diff3' instead. But if there are 6? Turns out that isn't too hard. First, of course, you need a list of packages installed on each individual host. Both rpm and dpkg can do this with a simple command line invocation. Assuming that's done, and the output is stored in files called installed-host1 through installed-host6, the procedure is:

$ comm -12 installed-host1 installed-host2 > installed-common
$ for i in $(seq 3 6)
> do
>   comm -12 installed-common installed-host$i > installed-tmp
>   mv installed-tmp installed-common
> done

And there, you now have a file "installed-common" containing everything which is installed everywhere. If you use "comm" or "diff" to compare that file against the installed-hostX files, you can easily see what the difference is. Granted, that doesn't give you the overview in just one file, but usually that's not really necessary. The 'installed-common' file contains the largest common denominator, which really is everything you need.

My dear MirBSD co-developer Benny did not only get his Doctor title but also recently married. There will be another post detailing this, including better photos of the two Doctors and the cake (with a D mon she made herself) on the wlog, but this is some fun beforehand: Apparently, it is forbidden in France to drive GPL cars. (Without safety valve but you have to admit the picture was fun. And we were like since the thing actually meant is LPG in German. Just like UTC is CUT (Coordinated Universal Time) in English, TUC (Temps Universel Coordonn ) in French )

It s been busy at our co-op but I m never too busy to support calls for the freedom to install debian (or any other Free and Open Source Software Operating System) so I ve signed the FSF-led public statement on so-called Secure Boot .

This could be a feature deserving of the name, as long as the user is able to authorize the programs she wants to use, so she can run free software written and modified by herself or people she trusts. However, we are concerned that Microsoft and hardware manufacturers will implement these boot restrictions in a way that will prevent users from booting anything other than Windows.

So please, read the full thing and consider signing it yourself. If you want to watch for further news on this topic, Matthew Garrett s Journal seems to be the bomb. Right, well, it s another busy week this week, so it might be the weekend before I find time to blog again, but posts will be a bit more frequent next week: watch this space!

As is natural for an LTS cycle, lots of people are thinking and talking about work focused on quality rather than features. With Canonical extending LTS support to five years on the desktop for 12.04, much of this is quite rightly focused on the desktop. I'm really not a desktop hacker in any way, shape, or form, though. I spent my first few years in Ubuntu working mainly on the installer - I still do, although I do some other things now too - and I used to say only half-jokingly that my job was done once X started. Of course there are plenty of bugs I can fix, but I wanted to see if I could do something with a bit more structure, so I got to thinking about projects we could work on at the foundations level that would make a big difference. Image build pipeline One difficulty we have is that quite a few of our bugs - especially installer bugs, although this goes for some other things too - are only really caught when people are doing coordinated image testing just before a milestone release. Now, it takes a while to do all the builds and then it takes a while to test them. The excellent work of the QA team has meant that testing is much quicker now than it used to be, and a certain amount of smoke-testing is automated (particularly for server images). On the other hand, the build phase has only got longer as we've added more flavours and architectures, particularly as some parts of the process are still serialised per architecture or subarchitecture so ARM builds in particular take a very long time indeed. Exact timings are a bit difficult to get for various reasons, but I think the minimum time between a developer uploading a fix and us having a full set of candidate images on all architectures including that fix is currently somewhere north of eight hours, and that's with people cutting corners and pulling strings which is a suboptimal thing to have to do around release time. This obviously makes us reluctant to respin for anything short of showstopper bugs. If we could get things down to something closer to two hours, respins would be a much less horrible proposition and so we might be able to fix a few bugs that are serious but not showstoppers, not to mention that the release team would feel less burned out. We discussed this problem at the release sprint, and came up with a laundry list of improvements; I've scheduled this for discussion at UDS in case we can think of any more. Please come along if you're interested! One thing in particular that I'm working on is refactoring Germinate, a tool which dates right back to our first meeting before Ubuntu was even called Ubuntu and whose job is to expand dependencies starting from our lists of "seed" packages; we use this, among other things, to generate Task fields in the archive and to decide which packages to copy into our images. This was acceptably quick in 2004, but now that we run it forty times (eight flavours multiplied by five architectures) at the end of every publisher run it's actually become rather a serious performance problem: cron.germinate takes about ten minutes, which is over a third of the typical publisher runtime. It parses Packages files eight times as often as it needs to, Sources files forty times as often as it needs to, and recalculates the dependency tree of the base system five times as often as it needs to. I am confident that we can significantly reduce the runtime here, and I think there's some hope that we might be able to move the publisher back to a 30-minute cycle, which would increase the velocity of Ubuntu development in general. Maintaining the development release Our release cycle always starts with syncing and merging packages from Debian unstable (or testing in the case of LTS cycles). The vast majority of packages in Ubuntu arrive this way, and generally speaking if we didn't do this we would fall behind in ways that would be difficult to recover from later. However, this does mean that we get a "big bang" of changes at the start of the cycle, and it takes a while for the archive to be usable again. Furthermore, even once we've taken care of this, we have a long-established rhythm where the first part of the cycle is mainly about feature development and the second part of the cycle is mainly about stabilisation. As a result, we've got used to the archive being fairly broken for the first few months, and we even tell people that they shouldn't expect things to work reliably until somewhere approaching beta. This makes some kind of sense from the inside. But how are you supposed to do feature development that relies on other things in the development release? In the first few years of Ubuntu, this question didn't matter very much. Nearly all the people doing serious feature development were themselves serious Ubuntu developers; they were capable of fixing problems in the development release as they went along, and while it got in their way a little bit it wasn't all that big a deal. Now, though, we have people focusing on things like Unity development, and we shouldn't assume that just because somebody is (say) an OpenGL expert or a window management expert that they should be able to recover from arbitrary failures in development release upgrades. One of the best things we could do to help the 12.04 desktop be more stable is to have the entire system be less unstable as we go along, so that developers further up the stack don't have to be distracted by things wobbling underneath them. Plus, it's just good software engineering to keep the basics working as you go along: it should always build, it should always install, it should always upgrade. Ubuntu is too big to do something like having everyone stop any time the build breaks, the way you might do in a smaller project, but we shouldn't let things slide for months either. I've been talking to Rick Spencer and the other Ubuntu engineering leads at Canonical about this. Canonical has a system of "rotations", where you can go off to another team for a while if you're in need of a change or want to branch out a bit; so I proposed that we allow our engineers to spend a month or two at a time on what I'm calling the +1 Maintenance Team, whose job is simply to keep the development release buildable, installable, and upgradeable at all times. Rick has been very receptive to this, and we're going to be running this as a trial throughout the 12.04 cycle, with probably about three people at a time. As well as being professional archive gardeners, these people will also work on developing infrastructure to help us keep better track of what we need to do. For instance, we could deploy better tools from Debian QA to help us track uninstallable packages, or we could enhance some of our many existing reports to have bug links and/or comment facilities, or we could spruce up the weather report; there are lots of things we could do to make our own lives easier. By 12.04, I would like, in no particular order:

• Precise to have been more or less continuously usable from Alpha 1 onward for people with reasonable general technical ability
• Canonical engineering teams outside Ubuntu (DX, Ubuntu One, Launchpad, etc.) to be comfortable with running the development release on at least one system from Alpha 2 onward
• Installability problems in daily image builds to be dealt with within one working day, or preferably before they even make it to daily builds
• The archive to be close to consistent as we start milestone preparation, rather than the release team having to scramble to make it so
• A very significant reduction in our long-term backlog of automatically-detected problems

Of course, this overlaps to a certain extent with the kinds of things that the MOTU team have been doing for years, not to mention with what all developers should be doing to keep their own houses in reasonable order, and I'd like us to work together on this; we're trying to provide some extra hands here to make Ubuntu better for everyone, not take over! I would love this to be an opportunity to re-energise MOTU and bring some new people on board. I've registered a couple of blueprints (priorities, infrastructure) for discussion at UDS. These are deliberately open-ended skeleton sessions, and I'll try to make sure they're scheduled fairly early in the week, so that we have time for break-out sessions later on. If you're interested, please come along and give your feedback!

Today I attended the Stop HRL demonstration [1]. The government plans to spend $100,000,000 of federal money and $50,000,000 of Victorian state money to build a new coal power station. The state government has imposed some unreasonable restrictions on renewable energy which includes allowing a single person who objects within 2Km of a wind turbine to block the project while also not allowing anyone to object to coal power plants or fracking (both of which have proven health implications). Today VCAT had a hearing about this issue, HRL wants to double the size of the proposed coal power plant while Environment Victoria, Doctors for the Environment Australia, local climate action group Locals Into Victoria s Environment Martin Shield from Climate Action Moreland are opposing the plan. What the government should be doing is permitting (if not encouraging) renewable energy production, particularly wind power which will drive down energy prices by undercutting the energy auctions due to it s almost zero marginal cost. The government should not be spending tax payer money on new coal projects due to climate change and air pollution in addition to the fact that coal is simply more expensive in the long term. As usual it s disappointing that the National party which supposedly represents farmers is supporting the government in such things. The pollution caused by coal power and fracking ends up damaging farmland. The Liberal party doesn t have a majority on it s own in either house of the state government, so this proposed coal power plant could be stopped immediately if the National party supported renewable power, or even if they merely opposed giving $50,000,000 of state tax money to HRL. The demonstration went reasonably well, there was about 80 people there when I arrived and by the time it ended there were more than 150 people. I took the above picture at the start and it missed many people who were off to the right. I think that s a good result for a demonstration that had little publicity and was held in business hours with really bad weather. Update: On Sunday the 13th of November at 13:00-14:30 there is a Going Backwards Under Baillieu demonstration at Parliament House. This is to mark the negative affects that the Liberal state government has had on the environment of Victoria.

• [1] http://www.stophrl.org/

Twenty-four hours ago I was in heaven. Or to more properly recapitulate and situate this, fourty-eight hours ago I was in hell. Now this requires some context. Earlier in the year, I had tweeted briefly about a Kurt Elling live concert still streaming on NPR, and truth be told, I have listened to Kurt Elling a whole lot ever since. The most recent album The Gate is fantastic, the Grammy-winner Dedicated to You (which retakes the very famous Coltrane/Hartman album) is beyond words, and The Messenger is worth it just for 'Nature Boy' and the funkiest-ever 'April in Paris'. I also saw him as part of a larger and otherwise rather neat tour. But I needed to see the man himself. So following what one can see from his touring calendar, I jotted down two October dates. Kurt Elling at the Green Mill. Fine. That was earlier in the summer. Summer has a tendency of evaporating quickly, so here we were in October. And getting going late on Friday, so by the time we got the Green Mill, a long line had formed and we ended up paying tribute to the line for fourty-five minutes with nothing to show. Sad. Home we went, and no live music. But somehow we mustered the energy to go again last night and thought we were early, arriving about 20 minutes before the show was to start. Ha! Others had appeared at 3pm, by 5pm all seats were gone. We were literally the last ones the get in after a short spell in a shorter line, and standing room-only it was. Oh, but what a treat we got. The set for these two days was Kurt Elling with the fourteen piece Kl vers Big Band from Denmark. They played for three marvellous sets, and well over four hours (with two 25 minute breaks). Pieces often alternated between big band arrangements and smaller pieces by Elling's standard rhythm band, and covered standards as well as Elling's catalogue. As I mentioned earlier on a short post (with pictures) on Google+, it is essentially impossible to not fall for Elling's stage presence when being so close to the stage. The man is just that good. Elling and the Kl vers Big Band will now play for six nights at Birdland in New York followed by a night each in Washington, DC, and Boston. If you're around, do yourself a favour and go out to see them.

There is a program that I love: bb. bb is a demo of the famous ASCII Art library, aalib.

     dT8  8Tb     
    dT 8  8 Tb    
   dT  8  8  Tb   
<PROJECT><PROJECT>
 dT    8  8    Tb 
dT     8  8     Tb

bb is a demo-scene-type program that shows how awesome automatic ASCII art is. The personalities of the people who made bb shine through. It's surely one of my favorite programs in Debian, up there with alpine. It's been in Debian since 1998. bb has a serious bug, however: BB's "graphics" freeze when music starts. Here's the issue.

• bb uses libmikmod to play sound.
• Back in the twentieth century, many of us thought it would be cool to have applications play sound through a system service called EsounD. To enable that, the libmikmod maintainers added the ability for libmikmod to send audio to that daemon.
• libmikmod detects if your system uses esound, and if so, sends sound there by default.
• libmikmod's esound support is broken, and bb half-crashes (as per #123150) when it gets used.
• Today, nearly everyone's sound output goes through pulseaudio, which supports ALSA as well as the old esound protocol for backwards-compatibility.

So if your system (like most GNU/Linux systems) uses pulseaudio for sound, then bb is broken. That means every Ubuntu user and most desktop Debian users can't use it. There are a few possible fixes, depending on where you'd want to solve the problem. If you just want bb to run on your own machine, without recompiling anything, you can adjust pulseaudio's configuration (in /etc/pulse/default.pa) to disable esound support. If you want to do that, just comment out this line:

 load-module module-esound-protocol-unix

We could also possibly patch bb so that it asks libmikmod not to use its esound "support." I think the smarter thing to do is to adjust libmikmod. Since its esound support seems to be just plain broken, it should be removed. At very least, it should not be the default when ALSA output is available. There is a new upstream release of libmikmod, maybe the esound output is fixed. In Debian, libmikmod is orphaned. When a package is orphaned, it means that a new person must step in and adopt the package. Debian packages need ongoing care and commitment to fix issues and make changes like this that benefit the users. In this case, you'd need to understand some C and be willing to maintain a shared library. Maintaining a library in Debian requires attention to detail, but it is quite doable. Since you would be adopting an existing package, most of the work is already done for you. I would also be quite willing to answer questions. If you're not a Debian developer, I would happily sponsor uploads of this package into Debian so that the fixes are part of the distribution. So: who will maintain libmikmod and fix bb? Could it be you? It would make a really great birthday present if the amazing bb program worked in the next Debian release. Leave a comment if you have questions or are interested! P.S. In a pinch, I can be convinced to maintain libmikmod myself, but I think this is a great opportunity for someone new to Debian to make a big difference.

There a many, many, e-book reader devices available these days, and they're quickly becoming pretty affordable. The currently cheapest device in Germany (that I know of) is the TrekStor eBook Reader 3.0, model number EBR30-a, at 59.- Euros via Weltbild or Hugendubel. The device has an 800x480 7" TFT (yep, no e-ink), 2100mAh battery, it can display PDFs, EPUB, and TXT files (and Adobe DRM crap, which I don't really care about), it has an accelerometer which allows for landscape/portrait switching, it can play MP3, OGG, WAV, and WMA audio files (headphone jack), it can display pictures (BMP, GIF, JPG, even PNG, though that's not mentioned in the vendor's specs), and it has 2GB internal storage for books/music/pictures. Uploading of (non-DRM) content is done by a simple file copy, it enumerates as a standard USB mass storage device with FAT filesystem. It's a relatively nice reader for the price, I've read a few PDFs (datasheets, presentations) on it in the subway/train while listening to music from the device and it's quite OK for my purposes. So much for the review part. However, I didn't really buy it for reading books on it, I was more interested in taking it apart, of course ;-) My hope was that it would turn out to be a really cheap device running Linux/U-Boot which would be perfect for playing around with embedded Linux stuff. Unfortunately, I wasn't so lucky (it seems). I've posted a few photos of the device and its hardware components on my flickr account and over at randomprojects.org, together with all the information I was able to find out so far. Here's a quick summary:

• Main CPU/SoC: FI E200 B6077BA 26P1
• RAM: MIRA P3S12D40ETP (512MBit / 64MByte DDR SDRAM, max. 200MHz)
• NAND flash: Samsung K9GAG08U0E (16GBit / 2GByte, x8, 3.3V)
• Battery management: KrossPower AXP199 A5004AB 36G
• RTC/clock/calender chip (I2C): H8563S
• Some accelerometer (to switch between landscape/portait mode), model unclear so far, maybe the chip labeled 605 132?

There are public datasheets for most of the hardware components (see randomprojects.org for links), but unfortunately the most important one (for the CPU) is not yet found/identified. I was told that the CPU/SoC is probably based on an ARM9 (ARM926EJ-S) core and the firmware running on it seems to be some uCos-based RTOS (not Linux, unfortunately). So far I was not able to find out the vendor name or website of the "FI E200" CPU/SoC (let alone any datasheets), any hints would be highly appreciated. I checked arm.com: Processor Licensees, but the only two companies whose name starts with "F" having licensed an ARM9 core are Fujitsu and Freescale, which doesn't fit, I think? I could (and probably will) check the PCB for RX/TX lines on an UART and/or JTAG pads (none are obviously labelled), and given that it's and ARM9 core there is a good chance that OpenOCD can be used and that a standard cross-gcc for ARM will work. However, that is all pretty pointless until it's clear which SoC exactly is used, and thus whether there is already Linux and/or U-Boot support for it and/or whether datasheets are available so that the respective code could be written. Without datasheets, this is going to be a pretty painful experience, not really worth investing much time, IMHO. If anyone knows more about the vendor/device and respective datasheets, please let me know. Thanks!

Valve's Portal game introduced an innovative teleporter system - where you basically can see through the teleporter and even walk seamlessly through it. Ever wondered how this is implemented? Check this Mini-Portal demo, along with its companion tutorials!

http://en.wikibooks.org/wiki/OpenGL_Programming/Mini-Portal

In this first part, we cover a basic working version that we will improve over the next few days. [Find more tutorials at the OpenGL wikibook.]

If you have been following Lintian s development closely, you will probably have noticed that I have not really done anything there for the past week. Instead I have turned my focus on our testing migration script, britney2. First, I have created a minimal test suite[1]. It started as 4 simple tests and by now it contains about 30 tests. The size of each test is rather small; the largest tests are about 1600 binary packages in total[2], but most are 2-20 binary packages in total. Thus the test suite is rather fast compared to a live data sample , which easily takes more than 10 minutes for a single run. Unfortunately, hand-crafting the test data is somewhat annoying and easy to get wrong. The test suite has a somewhat unfair focus on auto-hint [3] cases, so the current britney2 fails up to 14 tests. Some of these appears to fail because the auto-hinter (for some reason) receives incomplete information about the situation. To my knowledge we not been able to debug the situation, but Adam has a refactor branch that does not seem to have this issue. Personally I am hoping it will soon be merged into the master branch, especially because it seems to simplify a lot of common operations. Joachim Breitner (who has been working on a SAT-solver based britney) also contributed a couple of test cases[4]. Allegedly, SAT-britney does rather well on the test suite, failing only 2 tests as far as I can tell[5]. On the other hand, it does solve a some of the more interesting cases britney2 does not solve. On a more mathematical note, the britney2 implementation behaves like a function[6] with an attractive fixed point[7]. This is interesting, because for some cases it may take britney2 a couple of iterations to reach the right solution. This fixed point is somewhat simple to find by using the following steps (pseudo-code):

// Runtime complexity O(n * br * diff), where "n" is the number of iterations until
// a fixed point is reached, "br" is the complexity of "run_britney" and "diff" is
// the runtime of the "last != current" comparison.
function find_fixed_point(initial);
    last = run_britney(initial)
    current = run_britney(last)
    while last != current ; do
        last = current
        current = run_britney(last)
    od
    return current
end

This gives us a simple way to test if britney will eventually solve the issue herself (and when she will do it). Currently britney2 is automatically run twice a day, so for every 2 iterations (beyond the first) roughly translates to a 24-hours delay. So far the test suite does not have a lot of problems that requires more than one iteration. Personally I would be pleased if it turned out to stay that way as the test suite coverage grows. If you are interested in playing around with this, you can get sources from:

• britney2
  • Currently only works in stable (i.e. requires python2.5 and python-apt < 0.8 or so)
    • There some patches for this filed against release.debian.org.
  • See the INSTALL file for instructions
  • Adam s branch
    • use the p-u branch.
• SAT-britney
  • I haven t tested this one and I do not know the requirements here
• britney-tests
  • See the README file for instructions

Footnotes: [1] http://lists.debian.org/debian-release/2011/10/msg00178.html [2] These tests are auto-generated, so it is merely an up-scaled pattern . [3] Basically if two (or more) packages needs to migrate into testing at the exact same time, they need to be hinted in. [4] Not to mention all the copy-waste errors he pointed out in mine. Apparently, SAT-britney has stricter requirements to the data than britney2. [5] I assume the test called sat-britney-death (created by Joachim) was named that way for a reason. The second failure is caused by SAT britney not reading hints (yet?), so the approve tpu package test case should fail. [6] A function that maps an archive into another archive erh, I mean, it maps a set of packages into another set of packages [7] http://en.wikipedia.org/wiki/Fixed_point_%28mathematics%29 Assuming my claim to be true, the function will have more than one fixed point. The obtained fixed point depends on the initial state of testing. As an example:
y depends on x
x in testing has RC bugs If x is not in testing, it cannot migrate to testing (due to its RC bugs). If x is not in testing, then y cannot migrate into testing. But if x starts in testing, then y may be able to migrate. This can happen if x migrated to testing before an RC bug was filed against it. (Dis-)Proving my claim is an exercise left for the reader.

Even though some three months have passed since DebConf11 has successfully ended, I still wanted to give you just a glimpse on how some parts were played through the eyes of a lunatic (read: organizer). Of course, blog post can t come close near of explaining anything but at least it should give some insight and hopefully some pointers to the future DebConf organizers. If you don t feel like reading this much text you can listen to last episode of This Week In Debian podcast and after it just head to Beginning of the end part. DebConf11 First of all I d like to apologize if I offended or hurt anyone in this whole process as it wasn t my intention and during DebConf organization this is nothing irregular, for you to get hurt or you hurting somebody else. One thing that got stuck with me this whole time is when Mart n Ferrari approached me after I did bid proposal of Bosnia/Herzegovina for DebConf11 back on DebConf9 and told me you have no idea what you just got yourself into I played cool and said something along the line of coure I do and boy did I lie. During DebConf organization you re bound to make some of your decisions instantaneously in which you ll lose something, the most you can do is assess what s the thing you can cut the cord on, even though if that thing or a person for that matter might have meant something to you. You ll lose things, relationships, friendships, contacts at the times sense of humor and maybe even common logic. Some of it comes back to you, some the very next day and for some it may take longer. Some of it was lost irreversibly, but even in that case it wasn t lost and could even be traced to some other cause. One thing that I m thankful for is that I didn t lose, not lose but even get distanced from those close to me, and that I didn t lose guy who was with me in this from very first day, my right hand, my partner in crime Velimir ( aroundthfur ). It s not even losing I m talking about here, because even by losing you re gaining something and this is part of your everyday life, it s just that your life frame kinda gets stuck on fast forward button. So once the ride s over you may feel bit dizzy asking yourself what just happened. During this time I was also contacted by Google recruiter regrading software engineer internship but to make a long story short I didn t make it due to my heavy involvement and my lack of time (read: fail). But I don t find this as losing either, first time I was contacted by them, next time they ll be contacted by me maybe even for different position this time (project manager? . Even this DebConf wasn t our first bid we lost DebConf7 bid to Edinburgh, but it is perseverance that got us here. The moral I m trying to tell here is if you have a goal never back down from it. What I found to be our biggest problem and what I personally found as most painstaking in all of this was having and reporting to so many different sides and different groups while trying to keep them in same communication channel. Even my right hand (Velimir) was apart from me (Vienna), then place where two of us are coming from is not the place where DebConf is getting organized in. As in the end we ended up having all the parties separated and pulling to their own side, from Government of Republika Srpska to NGO to Debian to local team and to those who remained as undeclared . Option of cutting the cord in this case was missing as these were the components that DebCon11 was made of. Of course this meant you ll be missing workforce and there were days you d wake up driving >= 200 km/h (literally) with one hand on the wheel, other on the phone and your other right hand (Velimir) holding your RedBull. But you wouldn t do this just because you had to and there was no one else to do it, you d do it because you re responsible for the sake of the project and won t be just sitting there because by some unwritten hierarchy rules you re supposed to sit and supervise things. I d advise you do the same thing when you see there s no one else to do something, even if it means making coffee for one of the teams. I m not trying to scare you away from organizing your own DebConf, on the contrary after all I ve been through in past two years if someone asked me would I do it if I knew it was like this, without a doubt my answer would still be fsck yea . All the previous DebConf organizers told me about all of this, but why didn t I give up? For the same reason you won t give up and for the same reason why we believe in the same goal. If anything this is one of the stories you ll want to tell your kids about so When I was your age I used to sleep naked in the snow would turn to When I was your age I organized DebConf11 in Maybe this blog post wasn t even necessary and some things weren t supposed to be said, I guess sometimes I just can t shut up For those who were on DebConf11 I hope you enjoyed and had a great time, otherwise I m saying all of this in vein. As organizer all you see is problems and you miss most of the confrence, but by what I know there are 11 candidate bids for DebConf13 and for me hearing that tells me the results of our efforts. DebConf11 after effects I could write a whole novel about this, but to keep it as short as possible, for last two years as a side project I was working on an idea of Government or some of its institutions migrating to Linux. At first I was somewhat loud about it, then after Microsoft heard about it and after they tried stopping the idea by trying to scare me by trying to interfere with my private life; as that didn t work its lobbyist came even near of obstructing the whole conference within the Government. For the sake of the conference, I convinced the Government that by supporting DebConf it doesn t mean they need to move to Linux and publicly stopped talking about it. I also convinced them that our only goal was to have successful conference and promote alternative options and open ideas. I wasn t lying as I saw this as new opportunity of them concluding on their own why they should or shouldn t not move, the better conference was the more chances of success we had. That s why I tried pushing as many representatives from various companies as in this case we would use reverse psychology where basically no one or few know what Linux or Debian for that matter is, but everybody knows who Google is, so if you have participants from i.e: Google or Austrian E-Health care system talking about how they are using your technology is better way to explain what s it all about really. Eventually Microsoft even had their first ever conference in Bosnia/Herzegovina and you wanna take a wild guess where it was held? In the end we had a great conference, after the conference we were the ones that were approached by some big local companies interested in future co-operation and in the end a meeting with Mark Shuttleworth and President along with the core of Government was scheduled. Topic? Migration to Linux. For me personally this meeting went better then I could possibly even picture it, many topics were discussed and basically it was up to us/me to make a draft of the project plan and submit request for proposal to the Government. There was still some lobbying but it seemed as it all disappeared, runway was clear and open for the lift off. Necessary contacts with potential future partners were made and before any meetings were scheduled I announced I ll be taking a short break. I missed this years vacation, for matter of a fact I missed going to a vacation for last two years. I decided going to Dubrovnik for few days, just to recollect my thoughts, recompile my kernel and switch to lower gear as I was stuck in 6th gear for way too long. Beginning of the end Being on this vacation , even if it was only for few days this gave me an opportunity to look at it all from a different prospective, different angle and that s when it came to me. I realized that even before I was finished with one project without even realizing I was already involved with another one, one that would take much more time and one that might leave me wondering ~5 years later with question what if? After all if get involved with something I m not going to back out, it s either failure is not an option or I won t start doing it at all. Even if it brought me everything I wanted, how would you know if that s what you wanted if you haven t thought about it first? Having DebConf for the first time in this region already showed some (positive) results, but for seeing the actual results it may take a bit longer. We sowed the seeds now the best thing we can do is leave them as it is and see if anything grows out. Of course I could lean over them and protect them from any natural or any other type of hazards, this would also mean when I m not around it wouldn t know how to protect itself on its own. Besides all, interfering with natures way of doing things is rarely a good option. I consider myself to still be relatively young and threatening my well being over safe keeping some seeds and watching over if they grow into something or not doesn t really seem that attractive to me. Maybe one day I ll decide to leave the land, maybe I won t even get to see if anything grows out after all. Maybe some day someone will find this fruit, recognize its worth and claim it as it s own, maybe over time everybody forgets everything and even that this land once was a fertile ground. Maybe, maybe not. I m still a student, I was supposed to graduate last year but I took less classes last year so I wouldn t snap under all the pressure. That s why this year I have less classes and am supposed to graduate in May, that s less then a year until then and I just want to devote some time to myself, figure out what I want with me life, learn the things I want to learn, do the things I want to do. I want to turn back to working on Eclipse, I have some good plans for Eclipse and Android developers, lately I ve been slacking off way too much but I think I have a good excuse In the end, all I know is that I still want to change the world, whether it s doing that inside of Google or in my own company, or some third place; or I ll just be laughing at this statement only time will show. I m hoping that now with all of this out of me I can finally finish the DebConf11 chapter of my life.

Lindsay Holmwood has written about the benefits of a standing desk and how to buy one [1]. The case for avoiding sitting is strong, but I couldn t stand up all day. One thing that s been on my list of things to do if I had an unreasonably large amount of spare time or money is to make a reclining computer station. The idea would be to take a bed and mount a TFT display above it so that it can be viewed while lying down. Then a split keyboard would be required so that each hand can be used for half the keys (this would be difficult or expensive). If the keyboard halves were aligned correctly then it would reduce the carpal tunnel problems associated with computer use (which has been a big problem for me in the past and is something that I will probably never fully recover from [2]). As far as I am aware the risk of back problems is eliminated when lying down, so two of the major problems with regular computer desks would be avoided. I don t think that lying down all day would be that great and it wouldn t work for collaborative projects. But as monitors are so cheap nowadays it would be viable to have a second monitor at a desk connected to the same computer. Then I could spend about half my computer time lying down.

• [1] http://holmwood.id.au/~lindsay//2011/10/03/standing-desk-adventures/
• [2] http://etbe.coker.com.au/2010/06/16/carpal-tunnel-getting-better/