Have you ever needed to create a MySQL databases replication chain like A->B->C where B is slave of A and master of C? Me neither, until yesterday.

Since it took us about an afternoon to make it works (along with our DBAs, so we're not alone ;)) let's share some knowledge.

A very brief recap of how MySQL replication works:

1. slave I/O thread connects to the master, gets the new information from the binlog files and stores them in the relay log;
2. slave SQL thread reads the relay log and applies the changes to the slave database, without changing the slave binlog files.

Once again, there will be another round of the Summer School Advanced Scientific Programming in Python . This year in St. Andrews, UK. Quoting from the official announcement:

Scientists spend more and more time writing, maintaining, and debugging software. While techniques for doing this efficiently have evolved, only few scientists actually use them. As a result, instead of doing their research, they spend far too much time writing deficient code and reinventing the wheel. In this course we will present a selection of advanced programming techniques, incorporating theoretical lectures and practical exercises tailored to the needs of a programming scientist. New skills will be tested in a real programming project: we will team up to develop an entertaining scientific computer game. We use the Python programming language for the entire course. Python works as a simple programming language for beginners, but more importantly, it also works great in scientific simulations and data analysis. We show how clean language design, ease of extensibility, and the great wealth of open source libraries for scientific computing and data visualization are driving Python to become a standard tool for the programming scientist. This school is targeted at PhD students and Post-docs from all areas of science. Competence in Python or in another language such as Java, C/C++, MATLAB, or Mathematica is absolutely required. Basic knowledge of Python is assumed. Participants without any prior experience with Python should work through the proposed introductory
materials before the course.

You can apply on-line at http://python.g-node.org Applications must be submitted before May 29, 2011. Notifications of acceptance will be sent by June 19, 2011. No fee is charged but participants should take care of travel, living, and accommodation expenses. Candidates will be selected on the basis of their profile. Places are limited: acceptance rate in past editions was around 30%. Prerequisites: You are supposed to know the basics of Python to participate in the lectures. Please consult the website for a list of introductory material. If your re a scientist and interested in Python, I cannot recommend this summer school highly enough. The Summer School is always fun, the faculty members are very nice and always willing to help and answer questions. The balance between lectures and exercises is in my opinion very good, and you ll learn a lot about Python during the week. The highlight of every Python School is always the Pac Man tournament, where groups of students will implement their own Pac Man agent (in Python) and compete against the other agents in a tournament till the bitter end! The students of the previous editions were usually very happy during and after the School. Speaking of happiness, since no fee is charged for the Summer School, you ll have more money left over to invest into the excellent Scottish pubs!

I spend too much time writing Emacs Lisp code these days. Unfortunately, the more I do the more I find new useful tools to improve my work-flow and save time for doing more Lisp. D'oh. I did not work on any big thing these last weeks, so I'm thinking it's a good time to talk about the various code and patches I sent to multiple Emacs packages. el-get el-get, a fabulous tool that installs and handles all the external Emacs packages I use. A friendly war started on the development list about autoloads handling. The discussion was overall pointless, since we had a very hard time to communicate our ideas, and we did not understand each others several times. In the end, el-get now supports autoload correctly and do not load automatically all your packages, improving the startup time, and using the Emacs way to do things. Which is always better, obviously. git-commit-mode

I've started to use git-commit-mode some times ago. I usually use git-commit with the -v option to see what I'm committing. I though it would be useful to color the diff with diff-mode, so I wrote a patch just to do that, which was merged today by Florian. magit

Some weeks ago, I decided to give a try to magit, and loved it. I am not always using it, but for basic operations it is very useful. But I really soon found some things I did not like and therefore send patches to enhance it. First, I've added a patch to honor status.showUntrackedFiles which I use in my home directory. In the mean time, I've also added a patch to allow adding an arbitrary file. Yesterday, I sent another pull request, not closed for now, which adds the possibility to visit files in another window from a diff file, and the support for add-change-log-entry directly from the displayed diff. Useful for these old projects still using ChangeLog files but accessible through git (hi Emacs & Gnus!). Gnus

Nothing remarkable, but I write a couple of fixes and enhancements to the Sieve manage mode, to the Gravatar code and cleaned-up some very very old code. Also added the possibility to set list-identifier as a group parameter. Org-mode

I spent most of my time working on my jd/agenda-format branch, which is soon to be merged. I've also just got developer access to the Org-mode patch work and repository, so I'll be able to break things even more! ;-) ERC

I fixed the bug that annoyed me for a long time. Now erc-track does not reset the last channel status on window visibility changes not made by the user.

Another month and thus another issue of Flattr FOSS. Time flies but Flattr s usage seems to remain relatively strong. I was fearing that people get bored after some time but that does not seem be to the case, my Flattr income does not really drop (it doesn t take off either ). I get a bit less for dpkg than at the start but a bit more for my blog. Enough babbling, let s go straight to the 5 projects to flattr this month:

1. Linux Mint (Flattr link) is a Linux distribution based on Debian and Ubuntu that targets home desktop users. I have never tried it (I m too much of an hardcore Debianer) but I ve read several good reviews saying that it works well out of the box with good multimedia support. If you try it out, be sure to pick Linux Mint Debian Edition (LMDE).
2. Network Block Device (NBD) user-space support tools (Flattr link) is the set of tools to setup a block device whose content is really on a remote server. It requires support of NBD in the kernel of course. The user space tools are maintained by Debian developer Wouter Verhelst.
3. Tahoe LAFS (Flattr link) is a filesystem that implements a cloud storage. The data are distributed across multiple servers in such a way that it can continue to work even if one of the servers fails.
4. Gajim (Flattr link) is a full featured and easy to use Jabber client. If you don t need support of multiple instant messaging protocols, this Jabber client might be a good fit for you.
5. Aur lien Gateau (Flattr link) is a KDE developer who takes one day per week off his work to work on KDE. He seeks support from the community to compensate for the loss of revenue. Much like me, he has a support page with a complete history of the amount of donations received. I can only sympathize with people who try to live true to their passion good luck Aur lien!

This article is part of the Flattr FOSS project.

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

Wow, it's the last day of February and this is the first journal post I've made for the whole month. Needless to say, this month isn't working out quite the way that I'd intended at the start of year, although this is due to external forces that I hadn't been able to predict. The work project that I've been working on since last September or so (and in some sense since last June) hit the crunch, and I was pulled off of nearly everything else I was doing to work on that full time. I've been working 45-50 hours a week for the whole month, and probably will for a bit of March as well. The good part is that we're hitting our deadlines. We're going to push back by two weeks due to a design problem we missed until integration testing, but it looks like only two weeks. And given that we're picking up the entire complex account management system, teasing it apart from another major system that it's part of, and bringing it up in my group, along with reimplementing some bits around the edges and working on very old and fragile code, I'm very impressed. Unfortunately, that's also eaten my life. I'm trying to keep up with occasional things here and there, but projects like Debian got put almost entirely on hold. When I'm working this much during the week, I basically collapse on the weekends, rather than work on other projects like I normally do. I've been playing video games or just watching TV, and doing a bit of reading, but not working on free software or writing book reviews. I'm going to get a bit of time off at the end of this project, and hopefully will be able to rebalance my life again. This sort of huge push is quite unusual for work, which I like. I don't like working this way, and I've been occasionally rather unhappy with how little life outside of work I feel like I have (I can't imagine what working 60 hours a week regularly would be like). But there's only about a month or a month and a half left and then we'll be done and can go back to a more relaxed pace. I'm going to see if I can get a review finished tonight just because I hate going through a month without posting a book review. I've read five books (and three magazines) that I've not reviewed yet; sadly, the reviewing brain requires quite a bit more energy than the reading brain. Or perhaps not sadly, since it means I'm still reading. Expect posting to be minimal for the next month or so, and then it will hopefully pick up again.

This past weekend I've had the pleasure to join our friends from Valls, in the Camp de Tarragona, for our annual Cal otada in Picamoixon's countryside. This was the fourth time in a row I attend, and as always, it's been a blast, even if Enric and Clara weren't there, and the Valencian group was reduced to just 5 of us. Unfortunately I had my share of alcohol on Friday evening/night while partying with my workmates so when we got to Tarragona I was basically wasted. This made me not want to take a single sip of any kind of beverage not consisting of a 100% of water during the two days, but that didn't, of course, spoil a single moment of fun. Again, we've had the full traditional pack: prepare, cook and enjoy the delicious cal ots; our share of mayhem just after eating them, during the cal ot war, which this time resulted in a really filthy face and hair; our little walk around the area, including a visit to the chapel of the altar boy ; play in the metres tall mountains of gravel in the quarry and a brief visit to the ruins of an abandoned house, to discover none of its floors have colapsed yet.

A great finish for a great weekend is getting to visit Jordi and Anna, after 3 years of no luck, and finally meeting their lovely 2.5 years old daughter Martina. This weekend just rocks, and I'm already looking forward to next year's!

I've been out here for 6 months now. At the point in time I was coming out I was pointed at Andrew Pollock's On bootstrapping oneself in the US. I figure some extra data may be useful for anyone considering the same. I moved from the UK rather than Australia. Banking I sorted out my US banking long before I ever moved here; in fact I kicked the process off shortly after I accepted the move offer. Matthew had recommended the HSBC approach, so I did that. This meant when I arrived I had a credit card, debit card and check book. They also allow me to do really easy online transfers between my US and UK accounts. Mobile phone My mobile phone was something else that was dealt with before the move. I bought a Simple Mobile SIM off eBay. I thought I'd end up moving to a contract once I had a credit record here, but actually the $60/month unlimited tariff seems to be fairly reasonable. Their customer service leaves a lot to be desired, but I've sadly come to expect that from phone companies. I've got a Google Voice account which is the number I've been giving out, so it's easily for me to switch providers (or redirect things to a VOIP setup for when I'm back in the UK, but I've got a writeup to do for that at a later point in time). Finding somewhere to live One of my concerns was that it would be hard to find somewhere to live at short notice without any credit history or SSN. This turned out to be ill founded. Both of the managed apartment complexes I looked at were ok with the fact I'd just moved to the country and seemed used to such a setup. The place I went with is privately leased and was a bit more wary, but after a conversation with my US manager (who'd managed me even when I was in the UK) it was fine. Social Security Number AKA existing as an entity as far as the US is concern. I was told to wait at least 10 working days after entry before even applying for this, or I wouldn't be in the system and it could cause delays. I did so and the card turned up within about a week (I had been told up to 2 weeks). Which was good, because work were having problems figuring out how to pay me without one. You do seem to need the SSN for everything. The only times I can remember needing my National Insurance number in the UK is for new jobs and my E111 application. Driving licence I haven't ended up buying a car here; I pretty much don't need one most of the time and I've signed up to ZipCar for easy short term rentals - they're happy to take a UK licence for sign up. However I figured getting a licence here was a good idea in case I did decide to get a car, and even just for ID (I kept having to point people at the DOB on my UK licence - everywhere here seems to card). Applying for a licence ideally relies an SSN, so I did so a few days after I'd got that. I did the car + motorbike written tests and got my learner's permit. I applied for the car theory test the same day, but the first available slot was about 6 weeks later. During this period I did the CMSP basic RiderCourse, which meant that when I passed the car test I was also fully entitled to ride a motorbike here. Other useful notes As I live in the Bay Area I got myself a ClipperCard - it's like Oyster except without the clever discounts. Works on more agencies though and helps avoid having to sort out change. For broadband I went with Sonic.net - I'm in their ADSL2 coverage area so I'm getting a reasonable 17Mb/s connection. The other options were AT&T ADSL (slower) or Comcast cable (evil). I've had zero problems with Sonic; It Just Works. Also I sort of ended up with a trial run thanks to DebConf10 being in New York. Due to the way timings worked out this took place only a few weeks before my move to SF was scheduled. My banking and phone were already in place by this point, so it allowed me to check both were working ok. They were, and I didn't really expect them not to be, but it was a nice safety net to have for the move proper. Overall the main issue I had was that a lot of things were dependant on other things; get the SSN, get a learner's permit, apply for the practical test, wait for the licence to actually turn up etc. It probably took over 3 months for everything to actually happen and come through in the post. I can tell when I actually started to exist in the system because Capital One being junk mailing me about whether I want a credit card with them...

Australia s Department of Finance has mandated that the MS-Office document format should be the standard document format for all agencies [1]. Paul Wayper notes the fact that MS doesn t plan to support it s own standards and suggests ODF, also known as ISO/IEC standard 26300:2006. [2].Psychology Today has an interesting blog post by Marnia Robinson about scientific reasons for avoiding porn addiction [3]. Her post links to a number of other posts on the topic on Psychology Today.Psychology Today has an interesting post by Noam Shpancer titled What Doesn t Kill You Makes You Weaker [4]. It seems to me that the belief to the contrary is due to people rationalising bad things that happened to them, it s not all bad as it made me stronger .Psychology Today has an interesting article by Noam Shpancer about the soldier as hero myth [5]. He argues that soldiers are really just employees, the risk to American soldiers in war zones really isn t that great and that they are just pawns to the military-industrial complex.Anders Ynnerman gave an interesting TED talk about visualising medical data which includes many startling 3D pictures of humans and animals that are being scanned [6]. He describes how this is useful in forensic analysis by the police and in better understanding biological processes.Margarita Manterola gave an interesting Debconf talk titled Making Debian Rule, again , she has some interesting ideas for improving Debian [7]. She is most focussed on social problems and the questions and comments had some interesting ideas. The Center for Non-Violent Communication [8] was mentioned in the questions, apparently their success includes teaching better communication skills to violent criminals, so it seems that they can help with some big problems.Benjamin Mako Hill wrote an interesting article about the ratio of writers to readers on Wikipedia [9]. While he makes some good points I m wondering about the measure of an editor , there have been few months where I have made 5 edits, so I guess I m just a reader. I probably should take more care in logging in when I make changes though, I ve made more than a few small changes from random systems (client sites, Internet cafes, etc) without bothering to login. This would mess up the stats a bit.The Reid Report has an interesting article about Bush being limited in his international travel due to the fact that he has admitted being a war criminal [10].Understanding Prejudice is an interesting article that summarises a lot of psychological research [11]. It gives many ideas for anyone who wants to reduce prejudice.Robin Harris wrote an interesting ZD Net article about vibrations and the impact on disk performance [12]. Apparently it s very common to be able to get more performance from drive arrays if you dampen vibration, previously I believed that unless you had extreme vibration to cause catastrophic problems then nothing would go wrong. But it seems that even smaller amounts of vibration can cause a 30% performance loss or worse! There is work in progress on vibration-damping racks.In a story published in The Australian about the NSW ambulance service being shut down due to a virus, Professor Caelli cites SE Linux as an example of a technology to make computers more virus resistant [13]. Professor Caelli also states that there should be a legal requirement to have backup systems for computers that have such grave consequences if they crash.Sinclair Community College is offering a new class Fundamentals of Linux Security , it includes SE Linux [14].Slate has an interesting article about Pickpockets [15]. Apparently they are becoming extinct in the US as law enforcement has prevented the Fagins from training younger people, and it s only in Eastern Europe that the skills base remains.

• [1] http://www.itnews.com.au/News/245276,australia-mandates-microsofts-open-office-xml.aspx
• [2] http://www.mabula.net/tbfw/blosxom.cgi/2011/01/19#2011-01-19-minister-leigh-letter
• [3] http://www.psychologytoday.com/blog/cupids-poisoned-arrow/201007/not-all-warnings-about-porn-are-moralistic-or-unscientific
• [4] http://www.psychologytoday.com/blog/insight-therapy/201008/what-doesnt-kill-you-makes-you-weaker
• [5] http://www.psychologytoday.com/blog/insight-therapy/201101/soldier-hero
• [6] http://www.ted.com/talks/anders_ynnerman_visualizing_the_medical_data_explosion.html
• [7] http://penta.debconf.org/dc10_schedule/events/627.en.html
• [8] http://www.cnvc.org/
• [9] http://mako.cc/copyrighteous/20110206-00
• [10] http://blog.reidreport.com/2011/02/bush-cancels-geneva-and-other-consequences-of-torture/
• [11] http://www.understandingprejudice.org/apa/english/
• [12] http://www.zdnet.com/blog/storage/bad-bad-bad-vibrations/896
• [13] http://www.theaustralian.com.au/australian-it/world-focus-on-ambulance-system-failure/story-e6frgakx-1226005951185
• [14] http://www.sinclairclarion.com/home/campus/2011/02/07/new-linux-class-starting-in-spring-quarter/
• [15] http://www.slate.com/id/2286010/pagenum/all/

Everybody hates Xperia When I first got Sony Ericsson Xperia X10 it was running on Android Donut (1.6), my frustrations followed soon after mostly because it was greatly lagging with release of Android 2.1. Finally official 2.1 was released, but troubles didn t stop there, because everybody was waiting for multi-touch support I could go on like this for a very long time. However, to sum it up Sony has no plans of updating X10 anymore, they are releasing brand new phone (Arc) and they are hoping people will pay money to get it after X10 horrors. Even tho 2.1 isn t that old, (31.4% of overall Android users is using it on it), Sony changed its UI to make it look better, but all they actually did is make it look pretty bad + made it abnormally slow. Xperia ROMs From hardware aspect, it s a pretty awesome phone, but from software aspect it waste of nerves. It s obvious that Sony needs to hire more Linux people, because as it seems they have no idea what they are doing. There are of course, 2.2 Froyo and 2.3 Gingerbread straight from Google ROMs, but to be honest phone is only half usable with those. The feeling I get when using these is plain awkward. All these ROMs are stuck on 2.6.29, since as it seems Sony did a very good job protecting its bootloader, what I suggest is to use these for strictly development purposes, and have them dual boot with your working 2.1 2.2.1 Froyo (beta)
http://forum.xda-developers.com/showthread.php?t=917956 Gingerbread 2.3.1 (alpha)
http://forum.xda-developers.com/showthread.php?t=931934 So what is the best ROM? Out of all the ones I tried (and I tried many) it s definitely: kX10 Custom 2.1 SE ROM R2B001
http://forum.xda-developers.com/showthread.php?t=913610 My main argument on what this is the best ROM is because, everything is working, and it s working fast. Author stripped it to the minimum, and what I definitely suggest is that you go with the R2B001 Lite because the Full version comes with too much apps. with it, kinda making this great ROM feel bit bloated. I made a video for you to experience its speed: <iframe allowfullscreen="allowfullscreen" frameborder="0" height="390" src="http://www.youtube.com/embed/8xe0hUx2k28?rel=0" title="YouTube video player" width="480"></iframe> Modifications: Surprisingly I m getting much lower score Quadrant score, but also getting a much higher Linpack score: benchmark results of hacked Stock SE 2.1 ROM (2.0.2.A.0.24 root + JIT) Even though, the phone s much much faster. A couple of screenshots, including Linpack/Quadrant benchmark results. Nexus S This is how I m planning to live my remaining days on this phone, if it wasn t for this ROM, I would ve crashed my X10 long time ago. In meantime I m eagerly waiting to put my hands on Nexus S, whose official release we re still waiting for in Europe Google, please hurry up

As one of the Co-Maintainers of KVIrc, I'd like to give you a short outlook on what is planned for KVIrc in Debian in the near future or at least in the Wheezy release cycle.

• Upload of a 4.0.3 bug fix release to stable-proposed-updates as soon as upstream releases it.
• Packaging a new 4.1.1 snapshot every ten days (that is always after the previous one migrated to Testing) and make ready for 4.1.1 (maybe even 4.2?) in Wheezy.
• Rework the CMake build script of KVIrc to ensure minimal linking. At the moment KVIrc has CMake gather all B-Ds in the global CMakeLists.txt and adds those to all compiler/linker invocations. By pushing the include_directories() calls down to the respective modules and adding just the required variables to the target_link_libraries() invocations, we can improve the situation significantly.
• KVIrc uses a lot of reinvented-the-wheel code, some of this is due to its age (I think KVIrc is around since Qt2 and a lot of stuff wasn't available as an easy-to-use library then). But to be maintainable, KVIrc must move to leaner code base, which can be achieved by replacing such fragments of code with library calls. This is a big task and might not be completed in time for Wheezy, but the effort should be taken nonetheless.

Apart from what is listed above, we, the Debian Maintainers of KVIrc, strive to improve its packaging constantly.

I was going to make this a comment against Ritesh Raj Sarraf's post about patents and pharmaceuticals but the comment got way too long.

The basic problem is that patents on pharmaceuticals cannot be directly compared to patents on software and the explanation gets a bit involved. It's worse than apples and oranges, it's more like comparing an algorithm to a piece of DNA.

Patented pharmaceuticals must declare the precise chemical formula of the molecule (and a whole lot else besides) before the molecule can be brought to market but the company holding the patent is legally prevented from protecting themselves against slightly different molecules which are blatantly based on the protected molecule. All modification results in a new patentable product, legally separated from the original.

Therefore, the first company to patent a molecule from a new class is instantly joined in the field by other companies who are (obviously) watching the research news channels very carefully. (In their shoes, you would do the same or you go bust.) These companies simply add a flourine ion or change a hydrogen to a hydroxl group or any other number of minor, apparently inconsequential, changes. Changes which, in software, would be deemed a derivative work and would be roughly equivalent to changing a single local variable from a 16bit integer to a 32bit integer in a single function in a single file in the entire codebase. i.e. a trivial bug fix or even a typo.

A molecule with a couple of hundred atoms can have a change affecting one atom and be a completely new patentable item without any risk of the other company being sued for patent infringement, plagiarism, copyright violation (there is no copyright) or any other barrier. It's common to find that molecule foo is joined on the market by a desoxyfoo and a flourofoo etc. with a chlorofoo just around the corner, within months of the class-leader being launched. It can't be compared to software - effectively, every new release gets a new patent which covers the entirety of everything contained in that release, even if 99.999999999% of it is precisely the same as is covered under other several other patents held by extremely litigious competitors.

Modification is simply not prohibited - copying without making any changes whatsoever to the active molecule is prohibited. Changes to the inactive ingredients will be prosecuted - changes to the active ingredient will not. Comparing this with software is likely to drive you insane.

For example, the mere process of packaging an upstream release for a distribution would be patent infringement in pharmaceutical terms - UNLESS you deliberately patch the original source to make an utterly trivial and apparently pointless change. At that point, the upstream completely disown your entire release and you would have to fix every bug yourself - without the original upstream even telling you whether they fixed the same bug themselves, because they aren't ABLE to modify the upstream code without starting a whole new project and they won't tell you why or how they changed things. There is no such thing as an alpha-release of a molecule. Every release is final and no subsequent modification is possible - unless it only affects the inactive ingredients, e.g. by adding a slow release coating. These changes can affect the way that the molecule acts on the test subject / patient but must not change the active ingredient itself in any identifiable way. So the upstream can make a new wrapper (new packaging) but nobody else is allowed to do so until the patent expires. Once the patent expires, every one and their dog is allowed to make identical copies of the active ingredient in their own inactive packaging and these are called generics. Generics still need testing to ensure that the active ingredient truly is the same and that the generic behaves in the same way as the original but this process is cheaper than making a change to the active molecule.

A changed active molecule is an entirely new substance, it gets a new patent and it needs to go through largely the same amount of testing as the patented original but the new company still gets a head start on what the molecule is likely to do and what side-effects (by now noticeable with the class-leader product which is in large scale trials or even on the market) would be harmful to the future usefulness of their new, derivative, molecule. The new company simply jumps onto the bandwagon shouting "I want a piece of that action!" and there is absolutely nothing the original company can do about it, except try to show that their original molecule is better than the new competitors and to try and build a substantial market share before everyone switches to the new derivative. (Prescribers are human and tend therefore to be lazy, so unless there's a reason to change, the class leader will still have substantial share even after several derivatives exist.)

It's an arms race - each company tries to create as many of these potential "me-too" variants as possible in-house, put as many as can be (financially) supported through trials, keep pursuing those which don't have prohibitive side-effects / problems in tests and hope that, at the end, one of their versions will actually turn out to have better effectiveness or fewer side-effects. If not, they just have to market one as "as-effective-and-no-more-harmful-but-CHEAPER-than" the class leader. The majority of "me-too" molecules come under this category - even if the company concerned would try to point to infinitesimal differences in trial data to pretend otherwise. All this with the knowledge that the very hour that the patent expires, a dozen generic manufacturers will flood the market with copies which do not need to recover the massive costs of the original research and are therefore massively cheaper.

How much cheaper? patented molecules may cost 30 for 28 doses on Monday and one generic may cost 3p for 500, another may cost 40p for 10,000 on Tuesday, the day after the patent expiry. Generic houses only need to cover the actual costs of manufacture, not the costs of the original patent etc. and by the time the patent expires, the efforts of the patent holder to generate market share mean that economies of scale become evident. The absolute cheapest isn't necessarily the one who gets the contract either, these things all have expiry dates and all 10,000 have to be sold / supplied from a single location within that date to actually deliver the full savings. So then you get satellite generics who buy in quantities of a few million and pack down into 56 or less so that the total purchased quantity can sit on many shelves instead of just one. It's the same tablet in the end, with the same markings too. All that differs is the marking on the foil and the colour of the cardboard. (Oh and the same foil and colour cardboard can contain tablets with different markings from different manufacturers from one batch to the next, all within the branding of the same repackaging company.)

The original patent-holding company also has an interest in generating their own "me-too" derivatives, sometimes marketed under the name of a company which turns out to be solely owned by the parent of the original company. It can get horribly recursive.
Sometimes, the derivative from the sibling company hits the market before the "true" competitor from a different company - simply because all companies try to have many molecules in development at any one time (because most changed molecules fail in testing) and sometimes they get lucky and come up with two v.similar molecules and have to do something to justify the cost of developing both. That can turn out to be a poisoned chalice rather than two golden geese.

Sometimes, the company fails to get enough variants through testing and the company then gets bought out by a rival - who then gains their research and continues experimenting with other derivative molecules based on the ones already tested and dismissed. The limiting factor is the money.

At this point, I must now declare my cards. I used to be a pharmacist and although I am still entitled to call myself the holder of a Batchelor of Sciences degree in Pharmaceutical Sciences I am most definitely no longer a pharmacist. I therefore defer to my still-registered colleagues in case I've messed up any of the detail here. The above cannot be declared as the opinion of a pharmacist. I am an ex-pharmacist who voluntarily chose to resign his registration to take up full time work as a software developer rather than pay the exorbitant costs of maintaining such registration and all the "proof-of-competency" requirements which such registration requires.

Finally, before you ask, I am very happy to be an ex-pharmacist - my erstwhile colleagues have my ongoing sympathy but no matter how much some of them may beg, they all know that I will not be rejoining them on that side of the dispensary bench if I've got any choice in the matter.

Software is just better. It's all just recycled electrons.

Mosf of us would be well versed with the Patent system in general. We have patents in every sector - Technology, Agriculture, Pharmacy etc. Most readers in our profession must already be well versed of the Pros/Cons of the Patent system in Software/Technology. Patents in software are more like ammunition. The more you have, the stronger you are. We don't seem much cat fight in Software/Technology because not one organization own all the patents for a product. An IBM ThinkPad might be using a cool track pad feature which might be a patent of Dell. Since the finished product comprises of many patents from different owners in the same industry, it is better to play good with each other. You scratch my back, I scratch yours. But what about the Pharmaceutical Industry? There, one single patent could comprise the product. I was reading this document from Bruce Lehman which touches upon Patents and Pharmaceutical Industries, but couldn't find an answer to my question. read more

February has been again a busy month for me. Here s a quick summary of what I did: Multi-Arch work I have spent many days implementing and refining dpkg s Multi-Arch support with Guillem Jover (dpkg co-maintainer) and Steve Langasek (beta-tester of my code ). Early testers can try what s in my latest pu/multiarch/snapshot/* branch in my personal git repository. A Debian DVD shop I m always exploring new options to fund my Debian work (besides direct donations) and this month with the Debian Squeeze release I saw an opportunity in selling Debian DVD. Nobody provides DVD with included firmwares and quite a few people would like to avoid the SpaceFun theme. So I built unofficial Debian DVDs that integrate firmware and that install a system with the old theme (MoreBlue Orbit). Click here to learn more about my unofficial DVDs. On my blog In my People behind Debian series, I interviewed Mike Hommey (Iceweasel maintainer) and Maximiliam Attems (member of the kernel team). I started a Debian Cleanup Tip series and already published 4 installments:

• Debian Cleanup Tip #1: Get rid of useless configuration files
• Debian Cleanup Tip #2: Get rid of obsolete packages
• Debian Cleanup Tip #3: Get rid of third-party packages
• Debian Cleanup Tip #4: Find broken packages and reinstall them

For contributors, I wrote two articles: the first gives a set of (suggested) best practices for sponsoring Debian packages and adapted my article as a patch for the Developers Reference. In the second article, I shared some personal advice for people who are considering participating on Debian mailing list: 7 mistakes to avoid when participating to Debian mailing lists.

Click here to subscribe to my free newsletter and get my monthly analysis on what s going on in Debian and Ubuntu. Or just follow along via the RSS feed, Identi.ca, Twitter or Facebook.

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

Continuing my series about a desktop in a shell, today I will present you my mutt setup. I use mutt because it has no bugs and is a really good MUA for people loving consoles ;)First of all you have to know, that all my mail is forwarded to my server and sorted into Maildirs via maildrop, so I do not care about sorting on my desktop , which just fetches the mail via IMAP from the server ;)I m running mutt-patched from Debian Squeeze, so not all options may be available for you if you do not have the same patchset as I do.First, tell mutt to fetch mail from imap.die-welt.net via IMAP:

set imap_user=username
set imap_pass=password
set folder="imaps://imap.die-welt.net/INBOX"
set spoolfile="imaps://imap.die-welt.net/INBOX"

Now, enable IMAP-IDLE, list subscribed folders, reconnect to the server if needed and mark mail as read when you open it:

set imap_idle
set imap_check_subscribed
unset imap_passive
unset imap_peek

Let mutt save sent mail to the Sent directory on the IMAP server, and postponed mail to Drafts:

set record=+Sent
set postponed=+Drafts

Read mail should stay where it is:

set mbox="!"

We use IMAP-IDLE, thus check for new mail manually only every 90 seconds:

set mail_check=90

Instead timeout after 15 seconds if no user input is given:

set timeout=15

Set default mail from address to my default mail address:

set from=evgeni@golov.de

And send mail via mstmp (see below for mstmp configuration):

set sendmail="/usr/bin/msmtp"

Tell mutt which addresses I recieve mail to (danger, ugly regex!):

alternates (evgeni@(debian.org golov.(de eu)) sargentd@(die-welt sargentd).net evgeni.golov@uni-duesseldorf.de)

As mutt knows where I receive mail, let it set From accordingly:

set reverse_name

Let mutt cache some stuff and find its certificates:

set header_cache="~/.mutt/cache/headers"
set message_cachedir="~/.mutt/cache/bodies"
set certificate_file=~/.mutt/certificates
set ssl_ca_certificates_file=/etc/ssl/certs/ca-certificates.crt

Show only interesting headers in an useful order:

ignore headers *
unignore headers from to subject date cc
hdr_order from to cc subject date

Fix stupid MUAs behaviour (e.g. filenames like =?iso-8859-1?Q?file=5F=E4=5F991116=2Ezip?=):

set rfc2047_parameters

Beep on new mail, will generate a ! in the window name in screen:

set beep_new

mutt-patched has the great sidebar patch, assign ctrl-n, ctrl-p to select next, prev folder, ctrl-o to open selected folder:

bind index \Cp sidebar-prev
bind index \Cn sidebar-next
bind index \Co sidebar-open

And toggle sidebar visibility with ctrl-b:

macro index \Cb '<enter-command>toggle sidebar_visible<enter><refresh>'
macro pager \Cb '<enter-command>toggle sidebar_visible<enter><redraw-screen>'

Since 1.5.20-2, mutt patched contains my sidebar-dotted and sidebar-sorted patches.
Let mutt shorten the displayed path (e.g. debian-devel instead of INBOX.ml.debian-devel) and sort the folders (the are returned in random order when using imap_check_subscribed):

set sidebar_shortpath
set sidebar_sort

Now let s set some colors (that match the rest of my desktop ):

color sidebar_new yellow default
color normal white default
color hdrdefault brightcyan default
color signature green default
color attachment brightyellow default
color quoted green default
color quoted1 white default
color tilde blue default

And add some useful macros for marking new and old messages as read:

macro index .n "<tag-pattern>~N<enter><tag-prefix><clear-flag>N<clear-flag>*" "Catchup all new messages"
macro index .o "<tag-pattern>~O<enter><tag-prefix><clear-flag>O<clear-flag>*" "Catchup all old messages"

When forwarding mail, I like it to be forwarded as an attachment (YMMV):

set mime_forward=yes

I m using goobook in mutt to fetch my addressbook from Google. As there is no Debian package for goobook (yet), you have to install it yourself (via easy_install):

apt-get install python-argparse python-gdata python-simplejson python-keyring python-nose
easy_install goobook

Configuration is easy via ~/.goobookrc:

[DEFAULT]
# If not given here, email and password is taken from .netrc using
# machine google.com
email: me@gmail.com
password: password

And then add the following to your .muttrc:

set query_command="goobook query '%s'"
bind editor  complete-query
macro index,pager a "<pipe-message>goobook add<return>" "add the sender address to Google contacts"

That s all for mutt, but We are running mutt in a screen, so let s add the following to .screenrc to fix transparency and cut&paste (see http://wiki.mutt.org/?MuttFaq/Appearance):

 defbce on
 term screen-bce

And as mutt uses mstmp (yes, I know, mutt can handle SMTP itself ), this is my .msmtprc:

defaults
domain dorei.kerker.die-welt.net
tls on
account die-welt.net
host smtp.die-welt.net
from sargentd@die-welt.net
auth on
user username
password password
tls_starttls on
tls_certcheck off
# Set a default account
account default : die-welt.net

C est tout! That is my personal mutt configuration, you can download it as one file here: my .muttrc. And as everyone loves screenshots, here is one:Oh, the next chapter will be about irssi, but not before next Sunday (March 6th) as I ll be offline for a week, skiing in Austria :)

We have customers, which require a report about what we've done during maintenance windows. Usually this includes a report about upgrades, newly installed packages etc. and obviously everything we've done apart from that.
Till now we've prepared them manually. For a greater bunch of systems this is a big PITA, because to be somehow useful you have to collect the data for all systems and after that, prepare a report where you have:

• The upgrades done on all systems (e.g. a libc or kernel update)
  
  seperated from
  
• the updates specific to a certain system or system class

Its also error-prone because humans make mistakes.

Perl to the rescue!
At least the part about generating a report about installed/upgraded/removed packages could be automated, because dpkg writes a well-formed logfile in /var/log/dpkg.log. But I noticed that there appearently is no library specialised at parsing that file. Its not a big deal, because the format of that file is really simple, but a proper library would be nice anyway.
And so I wrote such a library.
It basically takes a logfile, reads it line by line and stores each line parameterized into a generic object.

Its features include:

• Parsing the logfile (obviously)
• Storing each line in a logfile as a DPKG::Log::Entry object that holds informations about the entry type (e.g. action or status update), the package associated (if any), timestamp, verbatim line, line number etc.

• Limiting the number of lines parsed to a time range specified by DateTime objects

Based on that, I wrote another library DPKG::Log::Analyse, which takes a log, parses it with DPKG::Log and then extracts the more relevant information such as installed packages, upgraded packages, removed packages etc.

This, in turn, features:
- Info about newly installed packages
- Info about removed packages
- Info about upgraded packages
- Info about packages which got installed and removed again
- Info about packages which stayed halfinstalled or halfconfigured at the end of the logfile (or defined reporting period)


These libraries are already uploaded to CPAN and packaged for Debian.
They passed the NEW queue very quickly and are therefore available for Sid:

http://packages.debian.org/sid/libdpkg-log-perl

As an example use (and for my own use case, as stated above), I wrote dpkg-report, which uses the module and a Template::Toolkit based template to generate a report about what happened in the given logfile.
It currently misses some documentation, but it works somehow like this:

Report for a single host over the full log:
dpkg-report

Report for a single host for the last two days:
dpkg-report --last-two-days

Report for multiple hosts (and logfiles):
The script expects that each log file has the name <systemname>.dpkg.log so that it can guess the hostname from the system and can grab all such log files from a directory if a directory is specified as log-file arguments:</systemname>

dpkg-report --log-file /path/to/logs

This will generate a report about all systems without any merging.

Report for multiple hosts with merging:
dpkg-report --log-file /path/to/logs --merge

This will do the following:

• Report packages which where installed/removed/etc. on all systems seperate from the upgrades only done on the specific systems
• If systems start with a common name and end on a number (e.g. mail1, mail2, mail3 etc.), report packages which where installed on all systems with that common name seperate from the upgrades only done on the specific systems
• For a specific system list only the changes on that particular system and nothing else.

A (fictive) report could look some what like this:

dpkg-Report for all:
------------------------
Newly Installed:
abc
Removed:
foo
Upgraded:
bar (0.99-12 - 1.00-1)

dpkg-Report for test*:
------------------------
Newly Installed:
blub

dpkg-Report for test1:
------------------------
Upgraded:
baz (1.0.0-1 -> 1.0.0-2)

dpkg-Report for test2:
------------------------
Upgraded:
zab (0.9.7 -> 0.9.8)

Currently this report generator is only included in the source package or in the git(hub) repository of the library. I wonder if it makes sense to let the source package build another binary package for it.
But its only a 238 lines perl script with a dependency on the perl library so I'm unsure if it warrants a new binary package. What do others think?

I have been packaging for Debian for a few years now. My first serious package was Wt back in 2007, but I had been backporting for Ubuntu for at least 2 years already, which means I have been doing .deb packaging for about 5 years (!). Last week I decided it was about time stop nagging my sponsors (Vincent Bernat, Thomas Girard and Sune Vuorela) every time I wanted to update the packages I maintain (witty, ace and libmsn), and I finally started the Debian New Maintainer process. The main reason I had not applied for Debian Maintainer yet was it requires some bureaucracy and, well, I d rather spend my time coding or packaging than doing paperwork I sent my Declaration of Intent and soon after, Thomas and Vincent replied and supported my application with very very nice and kind words. Thank you, guys! I m flattered! Had I known I would be buttered up so much, I would have certainly applied a long time ago! But you know what is the best part of this? It shows how open source projects take advantage of all the tools and communications channels we have (IRC, mailing lists, sprints, conferences, etc), and make distributed development work very well: here we have a 900-developers project in which two French guys are praising an Spanish guy they have never, ever met face-to-face (only e-mail, occasional IRC, and the most important of all: code review). Meritocracy at its full extent. Have you ever seen that in a traditional 100,000 workers company with hundreds of developers working in a single project?

...For the cases where, yes, you actually do want it. For the impatient assuming you're in a clean checkout on the tip of your current branch:

git merge -s ours ref-to-be-merged
git diff ref-to-be-merged   git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend

you can then double check that everything is as you expect with git diff ref-to-be-merged, which should be empty. The longer story It's noted from time to time that git does not have a -s theirs option to complement the -s ours strategy when merging (or, it did, but it was removed long ago, see below). For those not savvy the idea with git merge -s ours is to pretend as though a merge from some other branch has occurred, though the result remains the current branch's contents, unchanged. This is a neat trick that can be used to show that all changes in some branch have been superceded by the current branch, which can help ease merges further down the line as parallel devlopment continues. However, there is no corresponding -s theirs option, which would conversely say that "everything developed up to here is superceded by this other branch". This feature was discussed and discarded by one of the git authors, who instead advised a developer to throw away the previous work and start on a fresh branch:

One big problem "-s theirs" has, compared to the above "reset to origin, discarding or setting aside the failed history" is that your 'master' history that your further development is based on will keep your failed crap in it forever if you did "-s theirs". Hopefully you will become a better programmer over time, and you may eventually have something worth sharing with the world near the tip of your master branch. When that happens, however, you cannot offer your master branch to be pulled by the upstream, as the wider world will not be interested in your earlier mistakes at all.

In what would probably qualify as "most cases", he's right, but sometimes you do want to do this, and not because you have "crap" in your history, but perhaps because you want to change the baseline for development in a public repository where rebasing should be avoided. In debian, for example, it's pretty common for maintainers who use git-buildpackage to build debian packages from git to have two branches: an "upstream" branch and a "debianized" branch. The upstream branch will follow the changes from the upstream project (either by importing tarballs, or by pulling directly from the project's git repo if they also use git), while the debianized branch contains all the packaging related changes as well as any debian-specific changes to the code. In this context, if the upstream project uses git and rebases their history (out of your control), or if they shift development to a different branch, you might want to have a way to merge with their latest changes without rebasing/abandoning your current debian branch. Hence, a "theirs" merge. The author is totally right that the upstream project may be less interested in pulling from such a repository (since they would drag in the entire previous history), and if that's a problem you might need to splinter off the old branch and start a fresh branch instead. But at least for the projects with which I work, I find that it's more likely that pulling is pretty much one way upstream to debian, and that the patches flow back to the upstream project by way of bug trackers, git format-patch sendmail, or quilt patches sitting in the patch-tracker. And if it becomes a problem later you're no worse off, you can still split off a new branch or take some other action. So anyway, I asked Teh Internetz and found a few hits in the right direction, such as this guy at stack overflow, or this guy here. But from an aesthetic point of view I thought their solutions still left some room for improvement--they were both more complicated, involved setting up temporary branches, and I don't know, just weren't pretty on the eyes. So, ending where I started, this is the relatively clean and easy to follow 3 lines I conjured up, which I will give to teh internetz for posterity.

git merge -s ours ref-to-be-merged
git diff ref-to-be-merged   git apply -R --index
git commit -F .git/COMMIT_EDITMSG --amend

Alternatively, if you want to keep the local upstream branches fast-forwardable, a potential compromise is to work with the understanding that for sid/unstable, the upstream branch can from time to time be reset/rebased (based on events that are ultimately out of your control on the upstream project's side). This isn't a big deal and working with that assumption means that it's easy to keep the local upstream branch in a state where it only takes fast-forward updates. However, on the debian branch your less interested in the clean upstream development, and instead want to keep a sane history of the debianization work, so on this branch you still do something like a merge -s theirs (though in this case, you probably want to amend the previous version's ./debian dir back in post-merge). So applying the same approach as above with the slight modification, in practice (assuming you're on the clean tip of the debian unstable branch, that'd be):

git branch -m upstream-unstable upstream-unstable-save
git branch upstream-unstable upstream-remote/master
git merge -s ours upstream-unstable
git diff ref-to-be-merged   git apply -R --index --exclude="debian/*"
git commit -F .git/COMMIT_EDITMSG --amend

PS In spirit, this is a similar approach to what's done by the XSF team, though I would argue that with what I'm describing both the approach and the resulting history are a bit cleaner and easier to follow. Also, thanks to ron, mrvn, jcristau, and nthykier on #debian-devel for some quick reviewing of this.

You re eager to start contributing to Debian, your first action is to subscribe to some high-profile mailing lists (like debian-devel and debian-project) to get a feel of the community. You read the mails for a few days and then you find out that you could participate to the discussions, it s a simple first step after all. True enough. That said, it s not as easy as it looks like. There are many mistakes that you should avoid:

1. Don t fall in the trap where your mailing list participation is your sole contribution to Debian. If you want people to give credit to your messages, you should already be doing something else for Debian.
2. Don t participate more than once a day to a given thread. There are many people subscribed, you should leave room for other people to express their point of view. You can always follow up one day after and reply to several messages at once if you believe you still have something new to add to the discussion.
3. Don t reply to off-topic threads. Someone asked a simple question and someone else pointed out that his message was off-topic. Don t reply, or if you really need to, do it on the correct list or with a private response.
4. Don t ask questions unless it s useful to bring the discussion forward. Development lists are not here to fill the gaps in your knowledge. We already have debian-mentors for this. Furthermore there s no better way to learn than to find yourself the answers to your questions.
5. Don t believe your opinion is so important. We re all very opinionated and discussions that consist only of contradicting opinions tend to go nowhere. Thus don t give your opinion unless you can back it up with new facts or another experience.
6. Don t participate to all threads. There are surely some topics where you are more knowledgeable than others, participate where you add the most value and leave the others threads to the other experts (and learn by reading them).
7. Don t hide your identity. In Debian we like to know each other. Use your real name and not some anonymous nickname. You need to be able to stand up behind your words, otherwise you re not credible.

I have myself been guilty of several of those when I started I invite you to follow my recommendations to ensure our mailing lists remain pleasant to read and an effective discussion place.

You should follow me on Identi.ca, Twitter and Facebook. Or subscribe to this blog by RSS or by email.

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

One of the reasons I like Scotland is the fun that Scottish people have with language. I'm going to use two examples to illustrate my point:

• "Mind" is often used as "Remember"
• "How" is often used as "why".

The last one is particularly fun when you use questions such as "How no?" - meaning roughly "Why not?". Languages, and idioms, vary wildly in different parts of the world, even when you restrict yourself to English-speaking languages. I'll not even get started on Accents. The UK is tiny compared to many other countries, yet we have a wide array of accents - Australia, by contrast is huge, but I can think of only two accents across the country. (Rationally I expect that there are many accents in different parts of Australia, and I'm merely ignorant.) In conclusion languages are fun, and some places this is more evident than in others. I will most likely contintue to say "The shop is open from 9 while 4" rather than the more typical "From 9 til 4" - I'm allowed to do that, having grown up in Yorkshire!

(PS. PHP still sucks - Even if you post it upon a PHP-powered blog. ;)

ObQuote: "People take you for granted, you know. We gotta make people miss you." - Hancock

git-annex is a recent tool allowing to manage files with git without having theirs contents checked into git. I've been looking at it with some interest in the past few weeks in order to use it to handle my music collection on the various computers I use. My laptop just got a new SSD drive which is quite small and cannot handle the whole collection. By using git-annex, I'm now able to only check out part of my music collection and keeping it synchronized with all my others computers. Using git-annex is pretty trivial once you understand the concepts. I've set up a a git repository in my Music directory, like that:

% git init
Initialized empty Git repository in /home/jd/Music

Then I initialized git annex:

% git annex init "Music on keller"

So now I'm able to import all my date into git annex. git-annex offers several backends to store data. WORM is the default, but is not a good choice for file that could be modified, and music files can be, at least when editing the metadata. Therefore, I chose the slow but more reliable SHA1 backend.

% git annex add --backend=SHA1 .

That can be long, so you should be patient. Then you should commit the fact you annexed files:

% git commit -a -m "Imported my music collection"
[master 82d060f] Imported my music collection

Now, it's done. You can go on another computer and clone the repo:

% git clone ssh://keller/~/Music
% cd Music
% git annex get "Incubus - Light Grenades"

And then let the magic happens. It will retrieve the whole directory for you. Do not forgot to commit the fact that you got those album on that machine! The concept used by git-annex is quite simple. All files are replaced by symlinks pointing to .git-annex/SHA1:filechecksum.log. This file contains lines, whose format is:

retrieval-timestamp is-file-present uuid-of-the-repository

Indicating if the file is present in a repository. This logs file are commited into the repository, whereas the real content is stored in the .git/annex directory and therefore not commited. I recommend to take a look to the walkthrough page to get more idea and what you can and cannot do with git-annex.