Oh dear, it happened Hundreds of developers seem to have switched to git (man, I want to be as famous as Linus) and finally the packaging helper for subversion is orphaned. Yeah, I know, this is just partly related if at all but at least the low interest in its further development seems to prove my point. Anyways, I m not going to fully give up on it. Eddy just copied the bug message to d-devel to arrest some attention and actually I m trying the same here. svn-buildpackage is still needed, let alone the entire texlive stuff which is maintained in subversion repositories and many packages in collab-maint. So, let s see if we can t get it somewhere. 0.6.24 - release soon As Eddy mentioned in the bug report there is a version 0.6.24 prepared in trunk. Looking at my working copies I seem to have fixes for #363003, #414564, #467614, #480684, and #506876 lying around which I didn t commit yet. They should be sent to the bug reports, though. If you consider working on a release of svn-bp please contact me (or just write to the bug reports, I m subscribed). 0.7 - do it right ;-) This is far away but maybe a worthy goal. Two months ago I started working on a rewrite of svn-bp in order to fix some long outstanding bugs which would need gross hacks in the current version or aren t even fixable by design. Find my first experiments in branches/0.7. But then let me be honest, I didn t do anything about it lately - partly because of the low interest, but majorly because of vcs-pkg. I hope to figure out during debconf9 (I hope I can attend) if it is a possible replacement of svn-bp. But that s still up in the air. Well, that s my two cents about the situation.

I finally found some time to work on planet phpMyAdmin. It now has same look as phpmyadmin.net website, links to feeds are more visible and the website links to it at some places. All templates and planet configuration are now stored in our SVN repository. Now let's hope that I will not be the only one who regularly posts there :-).

As the occasional thinker about open-source development practices, communities, and issues, I have been wondering for a while: What are the largest open-source projects? What projects have the most code, the most users, and the most issues to deal with, and how do they cope?

The Debian archive should provide some insights into the first one or two questions, as it contains a very large portion of all available and relevant open-source software and exposes them in a fairly standard form. In the old days one might have gotten out grep-dctrl to create some puzzling statistics, but nowadays this information is actually available in an SQL database: the Ultimate Debian Database (UDD). (And it's in PostgreSQL. And it comes with a postgresql_autodoc-generated schema documentation. Excellent.)

So here is a first question. Well, the zeroth question would have been, which source packages have the largest unpacked orig tarball, but that information doesn't seem to be available, either via UDD or via apt. So the first question anyway is, which source packages produce the largest installation size across all their binary packages:

udd=> SELECT source, sum(installed_size)/1024 AS mib FROM packages WHERE distribution = 'debian' AND release = 'sid' AND component = 'main' AND architecture IN ('all', 'i386') AND section 
 'debug' GROUP BY source, version ORDER BY mib DESC LIMIT 30;                                                                                   
     source         mib                                                                                                                                   
------------------+------                                                                                                                                 
openoffice.org      1797                                                                                                                                  
kde-l10n             648                                                                                                                                  
gcj-4.4              544                                                                                                                                  
vtk                  465                                                                                                                                  
linux-2.6            404                                                                                                                                  
openclipart          353                                                                                                                                  
vegastrike-data      311                                                                                                                                  
ghc6                 308                                                                                                                                  
gclcvs               303                                                                                                                                  
wesnoth              300                                                                                                                                  
fpc                  269                                                                                                                                  
axiom                256                                                                                                                                  
webkit               255                                                                                                                                  
gcc-snapshot         255                                                                                                                                  
lazarus              241                                                                                                                                  
kdebase-workspace    226                                                                                                                                  
plt-scheme           221                                                                                                                                  
torcs-data-tracks    219                                                                                                                                  
scilab               213
openscenegraph       211
eclipse              210
sagemath             201
insighttoolkit       198
acl2                 195
kdebindings          181
atlas                165
gcl                  163
trilinos             153
paraview             153
asterisk             144
(30 rows)
This produces a few well-known packages, but also a number of obscure ones.  If you look closer, many of them appear to be themed around scientific, numerical, visualization, Scheme, Lisp, that sort of thing.  Hmm.

Here is another idea.  Take a package's installation footprint and multiply it by its popularity contest installation count.  So you get some kind of maintenance effort score, either because the package is large or because you have a lot of users or both.
SELECT rank() OVER (ORDER BY score DESC), source, sum(installed_size::numeric * insts) AS score FROM packages JOIN popcon USING (package) WHERE distribution = 'debian' AND release = 'sid' AND component = 'main' AND architecture IN ('all', 'i386') GROUP BY source, version ORDER BY score DESC LIMIT 30;
rank             source                 score
-----+-----------------------------+-------------
   1   openoffice.org                12638492332
   2   mysql-dfsg-5.0                 3411344560
   3   eglibc                         3371485240
   4   perl                           3019183024
   5   evolution                      2669948000
   6   samba                          2308923872
   7   mesa                           1853902860
   8   texlive-base                   1684245516
   9   gcj-4.3                        1610495484
  10   foomatic-db-engine             1608178104
  11   foomatic-db                    1423947704
  12   inkscape                       1413910080
  13   qt4-x11                        1258220636
  14   gcc-4.3                        1248741312
  15   kdelibs                        1021058256
  16   gnome-applets                   998434136
  17   xulrunner                       958232688
  18   coreutils                       954766896
  19   openssl                         877067672
  20   ncurses                         827679424
  21   python2.5                       815826384
  22   aptitude                        808161380
  23   gimp                            786015124
  24   gnome-utils                     781756328
  25   nautilus                        774319690
  26   openoffice.org-dictionaries     761075576
  27   eclipse                         756072380
  28   dpkg                            736626200
  29   openclipart                     731244240
  30   wine                            707967500
(30 rows)
(Yeah, they run this thing on PostgreSQL 8.4 beta 1.)

I noticed linux-2.6 is suspiciously absent because of a low popcon score (?!?).

I don't want to dump the entire database into this blog post, but if you try this yourself you can look at about the first 200 to 300 places to find reasonably large and complex projects before it gets a bit more obscure.  A few highlights:
  51   gnupg                           455660464
  59   php5                            386417572
  60   mutt                            381148176
  83   icu                             258602756
  84   xorg-server                     255186332
 101   exim4                           224857700
 107   openssh                         215792828
 113   tar                             201520400
 114   postgresql-8.3                  196844584
 115   libx11                          195856564
 116   ruby1.8                         194681656
 272   emacs22                          62047476
This is obviously still biased in a lot of ways, but it does show the major projects.

The UDD is also an interesting use case that shows how you can deploy a PostgreSQL database as a semi-public service with direct access.  A great tool, and a great tool to build other great tools on top of.

I tried hard, but it seems impossible to find Python programmers for our start-up. I know, living in Pecs (Hungary) limits the choices, but I also tried in Budapest and I was unable to find anybody with a good knowledge of Python and Zope. For this reason, we finally decided with my business partner to experiment with telecommuting.

We are looking for talented Python programmers to join our team, based in Pecs and Budapest (Hungary) with a satellite office in Turin (Italy). You will be able to work from home, planning your time based on your schedule and goals. You will work on the development of a free (as in speech) CRM and marketing platform built on the Zope Toolkit (aka Zope 3).

About you:

• Willing to work in a young start-up;
• You love finding efficient solutions to challenging problems;
• You have a lot to teach and a lot to learn;
• One of your goals is to learn something new each day;
• You prefer quality over quantity;
• You love to get things done;
• You like working in team and having strong responsibilities.

Requirements:

• Strong background in Python and web application development;
• Excellent knowledge of HTML, CSS, JavaScript (Prototype);
• Experience in database design, performance tuning, SQL;
• Good knowledge of PostgreSQL;
• Deep knowledge of Linux, with a focus on performance monitoring and tuning;
• Unit Testing and Functional Testing shouldn't be alien to you;
• Strong communication / collaboration / problem solving skills;
• Willing to travel for real-life meetings and conferences.;
• A resume in a non-proprietary format.
  

Nice-to-haves:

• Knowledge of the Zope Toolkit (aka Zope 3);
• Contributions to open source projects.

If you are interested, drop me a line at kobold@debian.org.

Nir Aides, the author of the excellent winpdb debugger, sent me the following email on September 21, 2008, so I asked him if I can copy his email and reply in form of a blog post (so that other people can comment and join the discussion) and he agreed. It took me almost a year to reply, but I made it. :)

Hi Ondrej,

How are you?

I am about to publish a new free software project, a new simple PHP framework, and I am interested in your advice.

You started SymPy and were able to make other people join you and develop it with you.
How did you do it?
How did it happen?
Did you actively call for other people or they spontaneously showed interest and joined you?
Are the other major contributor people who were your friends before you started the project?
Did you need to create or manage the project in a particular way to make it attractive to other people?
Are there things you are aware of that promote collaboration or demote it?

I was never successful in doing the same with Winpdb, which while it became reasonably popular, no one has ever joined me to develop it, except for a notable tutorial contribution by Chris Lasher which was developed independently.

Now with the new project, I am wondering what are my chances of making other people try it and take it on. On the one hand it is a new and fresh code base in an interesting field, on the other hand, why would anyone bother to spend their energy on this new project when they have Symfony or Drupal?

What do you think?

BTW, Ohloh believes you have a median of 19,000 lines of changed code per month since the start of their log. Can this be true? Is this humanly possible? According to it SymPy has over 1,000,000 lines of code? I can't understand these numbers. Winpdb has about 25,000 lines after 3 years of development. And from my experience 1,000,000 lines of code projects need about 20-50 full time developers to work on for 2-5 years which is about 40-250 man years. And as if this is not enough you are listed as owner in a dozen other projects in Google code and have enough time to become an awarded scientist. How is this possible?

http://www.ohloh.net/p/sympy/contributors/

BTW2, do you still use Winpdb? If you find yourself using it less, can you say what are the reasons, or what it would take to make it more useful?

BTW3, How is SymPy doing?

Cheers,
Nir

So my most honest answer how to run a successful opensource project is: I don't know.

But nevertheless I tried to summarize some of my ideas and experience and some guidelines that I try to follow, maybe it will be useful to you Nir, or anyone else.

First of all, there has to be a public mailinglist (easily accessible), public bug tracker, nice webpage, easy to find downloads, frequent releases (once a month is good, but in the worst case at least 4 times a year) and a set of guidelines to follow in order to contribute. So that's a must, if the project doesn't have the above, it's almost impossible to become successful. However, that is just a start, just a playground. There are still many projects that have the above and yet they totally fail to attract developers.

So I think the most important principle is that I always think how to employ other people in what I do. If I have some plan in my head how to do something, e.g. how to move some things forward, I always create exact steps and put it to issues, or our mailinglist, so that each step can be done by someone who is completely new to sympy. So I try to look at things from other people's perspective and think -- ok, I quite like this SymPy project and I'd like to get this done (for example a new release, or something fixed, or implemented), but I have no idea how to start and what exactly needs to be done.

So what I try to do if someone comes to our list and asks for something, is that I create a new issue for it and think how I would fix it if I had time. Then write the necessary steps in the issue and invite the submitter to fix it and I offer help with explaining anything and guiding. Now there are two things that can happen. Either the submitter has time and a will to go forward and in this case he starts wrestling with it and whenever he has some code or a question, I need to find time, review it and offer some way out. Or the submitter is too busy, in which case the instructions simply rest in the issues and the next time someone asks for the feature, the instructions are already there. I don't have estimates how frequent either case is.

When I am working on something myself, I try not to code privately, but also put up issues first and put the steps needed in the issues, so that it's easy for other people to join in.

In general, the most precious value for me is the fact that someone else had to sit down at his computer and wrote the patch. So I do everything possible to get new (or more) people interested in the development. Some people think that only super programmers can do a decent job and it's useless to invest time in people that may just have started with Python. They are wrong. Among the SymPy developers (around 65 people total have contributed patches so far at the time of writing this post), we have all kinds of people. We have people from high school, we have a retired US army engineer, we have physicists, mathematicians, biologists, engineers, teachers, or just hobbyists, who do it for fun. Unfortunately, we do not have many women (I think no patch that made it into sympy was contributed by a woman, but I may be wrong), so if anyone has any ideas how to get more women involved, let me know (I know we have several women fans, so that's a good start:). We have people whose first open source project they ever contributed to was sympy and people who are new to Python.

Many times the first patch that a new potential developer submits is not perfect, usually it's faster for me to write it myself, than to help with the first patch, however my rule is to always help the submitter do that. Sometimes he sends a second patch, or a third, and usually it needs less and less work on my side and it already pays off, because he is then able to fix things himself, if he discovers a bug and sympy has just won a one more contributor.

So I came to the conclusion that all that is needed is an enthusiasm. You don't even have to know Python (as you can learn all these things on the way) and you can still do useful things for us and really spare our time.

To answer another question from Nir's email, SymPy has about 130000 lines of code and another about 20000 lines of tests, so I think those stats are wrong. Also the changed lines of code is in my opinion wrong, we usually have about 250 new patches per release (this depends how often we release and other things).

Yes, I am involved in couple other projects, e.g. Debian, Sage, ipython, scipy, hpfem.org (and couple more), basically everything that has to do with numeric simulation and Python, but my activity there varies. The most time consuming thing in the last couple years was definitely school, I was finishing my master in Theoretical Physics in Prague and then moved to the Nevada/Reno and I just finished my first semester here at PhD in Chemical Physics, and sometimes it was just crazy, e.g. I finished teaching at 7pm and instead of going home and sleep, I stayed in my office, fixed 10 sympy issues that were holding off a release, finished at 1am, went home (by bike, since I don't have a car yet), slept couple hours and then did just school again for a week, other people reviewed the issues in the meantime, and then I made the release (instead of sleeping again). In the last semester it was not unusual that I got home at 1am every week day, then slept most of Saturday to catch up, on Sunday I did some laundry and shopping, and the rest of time I did grading and homeworks for all my classes and teaching, no time for anything else (e.g. no friends, no girls, no rest, no hobby, no opensource stuff, nothing). So sometimes one has to work pretty hard to get through it, but fortunately it's behind me finally, if all goes well, I should be just doing research from now on and have a real life too. Also I am sorry I didn't manage to reply sooner. :)

To answer the other questions:

Are the other major contributor people who were your friends before you started the project?

No, not a single major contributor was my friend before I started the project. Every single one of them become a developer using the procedure I described above, e.g. first showed on the list or in the issues, and maybe even the very first patch was not a high quality one (and if I was stupid and arrogant, or didn't see the big potential, I would just ignore them). But when given a chance, they became extremely good developers and sympy would simply just not be here without them.

Did you actively call for other people or they spontaneously showed interest and joined you?

I very much encourage everyone to contribute, but the initial interest must be in them, e.g. they at least have to show around the mailinglist/issues, so that I know about them. But once I know they are interested in some issue, yes, I try to invite them to fix it, with my help.

One observation I made is that I have to always think in the spirit "how to earn new money, not how to spare the money I already have", e.g. when applied to sympy, how to get new developers, how to develop the new great things etc. Even if I am super busy as I was, I still have to think this way. Once I start thinking how to conserve and preserve what we already have, I am done, finished and that's the road to hell.

If I am open, positive, full of energy, I can see people joining me and we can do great things together. It probably sounds obvious, but it was not for me, when for example some people I worked with, started their own projects, when I got busy, and started to compete, instead of helping sympy out. And I felt betrayed, after so much work that I invested into it and started to become protective. And then I realised that's wrong. I can never stop other people do what they want to do. If they want to have their own project, they will have it. If they don't want to help sympy out, they won't (and what is more important, there is nothing wrong with either of that). It's that simple and being protective only makes things worse.

There is also a question of the license that you use for the project, e.g. one should basically only choose between BSD (maybe also MIT or Apache), LGPL and GPL (there are also several versions of the GPL licenses). Unfortunately the fact is, that there are people who will never contribute a code under a permissive BSD license (because it's not protecting their work enough) and there are also other people who really want to code to be BSD (or other permissive license) so they can sell it and they don't need to consult with lawyers what they are or aren't allowed to do and also so that they can combine it with any other code (opensource or not). It also depends if one wants to combine (and distribute) other codes together. So choosing a license is also important. I believe that for sympy BSD is the best and for other projects (like Sage) GPL is the best and one has to decide on a case by case basis. For Winpdb, I would make it BSD too, since you can get more people using it.

To conclude, SymPy is a little more than 2 years old, and it has been a great ride so far and more things are coming, e.g. this summer we have 5 Google Summer of Code students and people are starting it to use in their research and we plan to use it in our codes at our group here in Reno too, so things look promising. I am really glad, we managed to build such a community, so that when I am busy, as I was the last semester, other people help out with patches, reviews and other things, so that the project doesn't stall and when I got rid of my school duties now, we can move things forward a lot.

So maybe you can get inspired by some of the ideas above. I am also interested in any discussion about this (feel free to post a comment below, or send me an email, or just write to a sympy list about what you think).

This is going to be a fantastic and exciting Perl summer. During the last week, I received notification that the talk I've proposed for both YAPC::NA and YAPC::EU was accepted. I will be talking about Perl in the Time of Social Networks, which is mainly two broad things: how Perl can actively power a modern social networking site (I'll be releasing a free -as in speech- social network website, similar to Lovd or RailSpace, built with pure Catalyst); and about high-load applications dealing with social networks' APIs and users (a Moose-based universal social network distributor), with Twitter, Facebook, MySpace, Blogger, LastFM, and others. My current contractor has been sponsoring the development and research for this since almost two years now, and we believe it's ready to go public: there's a lot of work backing us up. I'll be presenting the talk in Pittsburgh, PA, on June 23rd at YAPC 10. If you are around the area, come and attend the talk! On YAPC::EU::2009, I will be presenting in Lisbon, Portugal, on August 4th, which is conveniently placed just after DebConf 9, which will happen in C ceres, Spain the week before (I will also be there).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256 Recently there has been some brouhaha about migrating away from SHA-1 digests as used in GnuPG and to this end I followed the procedure described by Daniel Kahn Gillmor and created a new key which I will get signed at the Debian NYC meetup tonight and use to replace my existing key for signing packages. The old key (which is still valid btw) is: pre. pub 1024D/EE6DC66A 1999-12-16
Key fingerprint = 48DF D000 3BE7 1FF8 D9C1 5832 DA46 0E47 EE6D C66A And the new key is: pre. pub 2048R/C4794DAF 2009-05-08
Key fingerprint = 37EF 5B02 19C3 0C6E 47B2 51D0 EAA6 38FA C479 4DAF You can fetch the new key from http://people.debian.org/~jaldhar/gpg.txt or from the public keyservers (I don't know if there is a lag in how quickly new keys are made available.) This message has been signed with both the old and new keys.
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBCAAGBQJKBLrsAAoJEOqmOPrEeU2vfzIH/A99fMg6fC30GEm6SavJY4lt
hNS7N95dAn8iSGWfWgRv7t3ePAwmiIAZrcsFsjFgpS5IlZOTj9cFjTTz9Tgj030V
s55BSiM8yVrwnsgmZOHoVcQitS7i3b/I4AD/7Nrgx711GEIKesi1/O7eY1h0NaBM
kKlgIxg4GW1BFWd6P6XGtquO5ERYKUAkWRuPpxwUThlLbkXt0AOkWD13pmVD6adw
ZZwTPbFHQ/xvdYLwwSCZWXoPsrmuYcxlTcCzGkWISBPof6wmOkVshUAO6flVqKJ/
lm6rhpDKVgC/M1dOyDR9yh+Na3rgBFP0lOrJZpjW93Wld19v/yY6DSyZdJZoIOE=
=mDg8
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoEuwsACgkQ2kYOR+5txmp31gCgjoG/Y5W0QMkVY9fafZPb5SUb
MzEAn253UwCq+8UbdyD+ls7ZAcSvSt4h
=/lhN
-----END PGP SIGNATURE-----

After years of being a dedicated KDE user it seems like it s finally time for me to go back to Gnome. I once tried KDE 4.x from the Debian experimental branch knowing that it s probably unstable and will require a lot of patience. But I was willing to report bugs and dive into new things. It didn t take long though to find out that graphics were extraordinarily slow with the new desktop effects . The worst was resizing a konsole (KDE terminal window). It took 25 seconds until the window was resized and redrawn! On the interweb I found KDE developers rant about NVidia who didn t support some special extension they needed. They suggested to get an ATI card instead. (No, thanks, I was struggling with the crappy radeon and fglrx drivers on my new work laptop and am sick of ATI for Xorg.) Or I could use a bare XTerm instead. Yeah, right. So I couldn t use the desktop effects. After all I used the non-free NVidia driver for years and it never let me down. I don t mind doing without eye candy. But the desktop effects were about the only serious way to switch between virtual desktops. Point the mouse into a corner or edge of the screen and get a zoom-out bird s view of the virtual desktops. Nice but quickly annoying. Besides you had to push the mouse pointer a few pixels into the edge (it s not sufficient to just hit the edge) which means that after 10 desktop switches I had to lift the mouse and set it back on the mousepad. Another annoying issue is that up to now I can t assign functionality to every key on my keyboard any more. I had a neat trick by having 3 3=9 virtual desktops and use my numpad keys 1 to 9 to page through them. 0 on the numpad opened a new shell window. + on the numpad maximized a window. But now I couldn t assign any of those numpad keys. I pressed the 1 but KDE didn t detect Numpad_1 but just 1 . Guess how useful it is to not be able to type the 1 any more. There is a low-priority bug report for KDE from users who want this fixed but it will likely not happen any time soon. So the only way to switch desktops was to poke on the tiny pager widget in my panel. Yuk. Not to mention that I couldn t put icons on the desktop any longer. There was just a sissy widget that I could use for that purpose but it didn t work like a conqueror or dolphin at all. It was pretty amusing when in KDE 4.2 there was suddenly a feature to re-enable the old behavior. Let me guess, KDE developers - I wasn t the only user you couldn t persuade of the new paradigm? Next evil thing was performance. KDE 4 takes ages to load. Simple window managers get me started within seconds. Even Gnome. But KDE takes 30 seconds until it s loaded plus some disk grinding in the background. And memory usage wasn t nice either. And what finally made me mad was stabilty - or rather lack thereof. Everytime the screen saver ran my kbluetooth module crashed. kmail crashed even more frequently than before. (I loved kmail for it s great customizability and feature set.) plasma (the actual window manager) died at least twice a day. Suddenly the panels were looking ugly or crashing. As a Debian developer I have to follow the unstable branch on my workstation. And there is no distinction between KDE 3 and KDE 4 any more so a dist-uprade inevitably gets all of my applications upgraded to KDE 4 (plus an hour of manual engineering in aptitude because half of my applications weren t upgraded automatically due to different application names and I had a mixed environment). So there I was with KDE 4.2. I really worked with it for a month. I tried hard to get acquainted to its bloatedness and instability. It s really a nice technological preview of what might be possible in the future. Everything is really automatic. Mounting external media. New ways to find programs (although I m not happy with the new K start menu). Funny effects and nice eye candy. But it s far from the rock solid desktop environment that I was used from KDE 3.5.8. So there I am on Gnome now. I was switching back and forth. One day working on KDE 4.2 and the other day using Gnome 2.26. And although it makes me feel sad I think it s finally time to say goodbye to KDE 4. I have invested a good amount of time and energy into it - even just from a user perspective. But it s not ready. And I finally need to get some work done. A number of projects suffered from my playfulness (my ispmail tutorial, screenshots.debian.net, debexpo, my kids) and it s time to get back to work. And Gnome was pretty surprising. With compiz I have the KDE desktop effects working (here they really do) and they are all customizable. I can assign keys properly again (even the numpad). Everything is pretty fast and stable. I have replaced kmail and its buggy shared calendar feature by Icedove (aka Thunderbird) with the Lightning plugin. Worked from the first minute and hasn t crashed in a week (just have to remember next time to install libstdc++5 to be able to use Lightning). With enigmail I finally have a proper simple working PGP key management that doesn t die and is buggy like hell like in kgpg. And there s the nice Nostalgy add-on that allows me to file emails into IMAP folder quickly again - a feature that just kmail seemed to support so far. Oh, and I see new mail instantly because Icedove supports the IDLE command while kmail has never learned that neat little trick. The Gnome file manager isn t really great for my taste but it s doing its job (dolphin is just much nicer). It s not as nice as KDE but I had to learn that working and stable weighs more than nice. The hard way. And many things I liked about KDE 4 (like starting a new program with Alt-F2 and having a smart application finder and simple calculator in one) are built into Gnome, too. So why bother. Thanks, KDE, for the years of fun and service. I ll surely miss you. Get back to me should you grow up one day.

It is curious to see that the eleventh movie in a series is the first to bear the series name with no adornment. It is apt, however: Star Trek is a clear attempt at rebooting the universe and basically forgetting most of the decades-heavy baggage. It seems to me that the reboot was fairly well done, too. The movie opens with the birth of James Tiberius Kirk, and follows his development into the Captain of the Enterprise. Along the way, we also see the growth of Spock from adolescence into Kirk s trusted sidekick and also into well. Despite the fact that the action plot macguffins are time travel and planet-killer weaponry, it is mainly a story of personal vengeance, personal tragedy, and personal growth. Curiously enough, although Kirk gets a lot of screen time, it is really the personal story of Spock. Besides Kirk and Spock, we also get to meet reimagined versions of Uhura (I like!), McCoy, Sulu, Chekov and Scott. And Christopher Pike, the first Captain of the Enterprise. The appearance of Leonard Nimoy as the pre-reboot Spock merits a special mention and a special thanks. I overheard someone say in the theatre, after the movie ended, that the movie was a ripoff and had nothing to do with anything that had gone before. I respectfully disagree. The old Star Trek continuum had been weighed down by all the history into being a 600-pound elderly man who is unable to leave the couch on his own. This movie provided a clearn reboot, ripping out most of the baggage, retaining the essence of classic Star Trek and giving a healthy, new platform for good new stories. One just hopes Paramount is wise enough not to foul it up again. It was worth it, I thought.

Adrian von Bidder raises an interesting discussion on why public health care is difficult. Basically, it comes back to the challenge:

How much money should be spent on this person's illness? which is a very, very bad question. We try to sidestep it by only taking about statistics etc., but no matter how you look at it, you either do 20'000  per week medications for 80 year old patients who will die soon anyway and get a system society can't pay, or you don't and you get a system where the rich are better off than the poor.

The problem is, the majority of health costs are in the last few years of a persons life: when the body is breaking down. If viewed from the problem of health-care funding vs. eg. education, you have an ethical dilemma: is it worth it ? Here there are no easy answers. Nick Bostrom wrote a very interesting and persuasive essay a while back, The fable of the Dragon Tyrant. In short, we are getting somewhere with regenerative medicine While cures are hard to come by at this stage, there is a growing realization in medicine that senesence, what we used to call "old age", is curable. But we have a lot of psychological defensive mechanisms to help us cope with the carnage of old age that make us deny the problem: if we look afresh at "old age" knowing it to be curable, any delay in doing so is abhorrent. From a public, societal perspective, we spend a fortune every year on health. But we do so in a very disjointed way: we pay colossal amounts for health care, but also for basic health science: in the US, for example, the budget for the National Institutes of Health is about 30 billion dollars. Nearly twice that of NASA. Similar figures are spent in Europe, but there is this strange gap in the middle: the drug companies and medical industry. We start the development of new drugs with public money, and we buy the drugs with public money, but the choice of what drugs and treatments are developed are left to private industry, that is, a profit motive. This results in many cases in expensive treatments to treat symptoms rather than necessarily cure the problem. Faced with the huge costs of geriatric medicine and senesence, the response should be co-ordinated: funding a cure will be expensive, but save a fortune (Think, instead of a pensioner slowly dying and 'being a drain on resources', of 'experienced citizen in the prime of their productive, tax-paying years'). Instead of funding the basic science alone, we should be funding the complete drug and treatment development publically, only farming out the actual manufacture to private industry. It is silly to spend a fortune to keep merely keep someone alive at the age of eighty or so, when we know for a larger investment (bigger than a private company can do), we can cure them properly. The solution to the dilemma, then, is to stop thinking of the elderly being a drain, but actually applying our public efforts in a co-ordinated manner to solving the carnage of old age. Tags politics, health

It looks like publishing fake journals was becoming closer to habit for Elsevir rather than a one-time exceptional mistake.

Scientific publishing giant Elsevier put out a total of six publications between 2000 and 2005 that were sponsored by unnamed pharmaceutical companies and looked like peer reviewed medical journals, but did not disclose sponsorship, the company has admitted. Elsevier is conducting an internal review of its publishing practices after allegations came to light that the company produced a pharmaceutical company-funded publication in the early 2000s without disclosing that the journal was corporate sponsored.

I really hope people use this an an opportunity to detach fully from them.

My desktop machine blew up, so I got a lovely fresh install of Jaunty. And, X and Gnome still disagreed by default about my actual screeen size... it was unreadably small with the default fonts. I've posted the following instructions before - these are basically unchanged except that the location of the fonts dialog has moved. Tip for folk that would like X to show fonts (i.e. the GDM log in screen) in the correct size: Teach X about the dpi setting! Step 1: run xdpyinfo and look for the dimensions: line. There will be something like this: dimensions: 1280x768 pixels (266x161 millimeters) resolution: 122x121 dots per inch Grab a ruler and measure the screen you have. If it matches the millimeters reported by X, then skip step 2. Step 2: edit /etc/X11/xorg.conf, and locate your Monitor section: Section "Monitor" Identifier "Generic Monitor" Option "DPMS" DisplaySize 265 160 EndSection Add in a DisplaySize like I have there. Now logout of your GUI and restart X - you can run /etc/init.d/ g,k dm restart from the console, or do what I do - just hit ctrl-alt-bkspace so it restarts. Your login screen should change appearance slightly - either the fonts and regions will get bigger if your dpi was set too low, or vice verca. Step 3: (For KDE users, someone please tell me what it should be, for GNOME read on)... Run xdpyinfo again and find the Resolution: line. Ignore the fact that it may not be square, grab one of the two numbers ( I suggest the higher).. Go to System, Preferences, Appearance, and the Font tab. Select 'Details'. There is a Resolution field there. Put in the single number you chose. Changes should take effect immediately. Applications I know of which benefit from having this set correctly: xpdf, gnome-* (panels are readable etc etc), firefox.

If you happen to be in the NYC area this Friday May 8th, come over to our get-together to have a few beers/club sodas at Pacific Standard in Park Slope, Brooklyn (at 8 pm, map here). We will also be holding a PGP/GPG key signing par-tay at 9 pm, so make sure you bring your government-issued ID and your printed keys. More information about it, here.

I have mentioned the flashrom utility in my blog in the past. This is a small command line tool which allows you to update your BIOS/coreboot/firmware chips without opening the computer and without any special boot procedures. Yesterday, flashrom 0.9 was finally released. Here's a short passage from the release announcement:

After nine years of development and constant improvement, we have added support for every BIOS flash ROM technology present on x86 mainboards and every flash ROM chip we ever saw in the wild. Highlights of flashrom include:

• Parallel, LPC, FWH and SPI flash interfaces.
• 157 flash chip families and half a dozen variants of each family.
• Flash chip package agnostic. DIP32, PLCC32, DIP8, SO8/SOIC8, TSOP32, TSOP40 and more have all been verified to work.
• 75 different chipsets, some with multiple flash controllers.
• Special mainboard enabling code for dozens of nonstandard mainboards.
• No physical access needed. root access is sufficient.
• No bootable floppy disk, bootable CD-ROM or other media needed.
• No keyboard or monitor needed. Simply reflash remotely via SSH.
• No instant reboot needed. Reflash your ROM in a running system, verify it, be happy. The new firmware will be present next time you boot.
• Crossflashing and hotflashing is possible as long as the flash chips are electrically and logically compatible (same protocol). Great for recovery.
• Scriptability. Reflash a whole pool of identical machines at the same time from the command line. It is recommended to check flashrom output and error codes.
• Speed. flashrom is much faster than vendor flash tools.
• Supports Linux, FreeBSD, DragonFly BSD, Solaris, Mac OS X. Please refer to the README for build instructions.

Please note that rewriting your flash chip can be dangerous and flashrom developers make no guarantees whatsoever. That said, many users have successfully replaced proprietary tools such as awdflash, amiflash and afudos with flashrom.

Download: flashrom-0.9.0.tar.gz
SVN: svn co svn://coreboot.org/flashrom/trunk flashrom
Debian: apt-get install flashrom Do yourself a favor and try flashrom next time you want to upgrade your BIOS. No more floppies or bootable CD-ROMs with DOS/Windows binaries or similar crap. Run flashrom conveniently from the Linux command line, or even via SSH or serial console if you want...

I finally managed to ask my hosting provider for a IPv6 addresses and it went surprisingly smoothly. So since today, all what is running on my server (for example Wammu website or phpMyAdmin wiki and demo) should be accessible natively over IPv6. And thanks to Sixxs guys for providing tunnel which I've been using up to now.

TIME: Monday, May 18, 7:00pm VENUE: Courant Institute
251 Mercer Street (Warren Weaver Hall)
Room 109 TITLE: The Struggle to Build a Digital Republic ABSTRACT: David Bollier will speak about the themes of his new book, Viral
Spiral: How the Commoners Built a Digital Republic of Their Own (New
Press). The book is the first comprehensive history of the free
culture movement and sharing economy that is empowering ordinary
people, disrupting markets and changing politics and culture. Bollier
will talk about the rise of free and open source software, Creative
Commons licenses, the new forms of non-market creativity (Wikipedia,
blogs, remix music, videos) as well as fascinating innovations in open
science, open education and open business models. More about the
book can be found at the website www.viralspiral.cc. More about
Bollier can be found at www.bollier.org. Bio
David Bollier is a leading American activist, author, blogger and
proponent of free culture on the Internet and the commons. He is an
editor of Onthecommons.org and Senior Fellow at the USC Annenberg
School for Communication. Bollier is also co-founder of Public
Knowledge, a Washington, D.C., organization that advocates for the
public s stake in the Internet and copyright law, and the author of
Silent Theft, Brand Name Bullies, and four other books. He lives in
Amherst, Massachusetts. VENUE: Courant Institute
251 Mercer Street (Warren Weaver Hall)
Room 109

Apparently Comcast is planning on axing its analog cables at some undetermined point in the future. That will make my MythTV setup more complicated, and no doubt require a more expensive cable plan and yet more equipment. My setup is already a tad ridiculous.

Providing city services only to users of specific proprietary software is bad public policy. I just discovered that New York City's 2009 Summer Youth Employment Program requires Internet Explorer in order to apply online. Even downloading the pdf version of the application to print out from the site is impossible under non-IE browsers because the actual pdf link is wrapped in some IE-only javascript. And even if you could download the PDF directly, any additional "online information to help you select a SYEP provider" is inaccessible for the same reason. I just called 311 and filed an official complaint against the NYC Dept. of Youth and Community Development (DYCD), who sponsor the program. I also called the number on the application page (1-800-246-4646), and spoke with "Karen" from the DYCD, who explained that the site was a New York City web site, and that it had been created by DoITT (the Department of Information Technology and Telecommunications) at the request of the DYCD, but that the DYCD didn't program it directly. She seemed to misunderstand the tech behind the situation, saying "we can't bring it to a higher level (like Firefox) because then it wouldn't work for everyone". I was happy that she understood that Firefox was a concern here, but the point is not to build the site "higher" to Firefox, but to use standard technology that all browsers can access for a public site. Karen also seemed to think the situation was acceptable because the city youth "can always use IE on local public library computers" to access the site. Note that the applications involve submitting very detailed information (SSN, health insurance, family income, criminal record, selective service registration #, etc), which are things that i would personally be unwilling to submit over a shared public computer if i had any other choice. Furthermore, this crappy implementation decision encourages the NYPL to continue to spend limited resources on proprietary software to an out-of-state monopolist to run their computer labs, which is money that could be better spent locally (or even spent on books or something similarly quaint and library-like). I'm frustrated. This is 2009. The application process for public services here should not require any proprietary technology, but it uses it gratuitously. This excludes legitimate citizens, and encourages Microsoft in its ongoing pursuit of monopoly status. Both of these are bad things. I submitted feedback on the DYCD customer survey web site, and submitted two 150-word-limited(!) complaints to Commissioner Mulgrav of the DYCD and Commissioner Cosgrave of DoITT. I'm sure they'd be interested in hearing from other people about this. Is this kind of proprietary lock-in what we should expect from a Mayor who cuts budgets city-wide except for IT? Where is all that money going? What is the city getting out of it?Tags: policy

There is a lot of madness when it comes to psychiatry. One recent example of madness perhaps insanity is this faux peer review journal. At least there seems to be a growing counter-current in medicine that wants to sever the umbilical cord between doctors and drug companies as well as a vibrant grass roots move to embrace a different politics in and of madness.