So, now, here it is. As of tomorrow, all of our three "kids" will have their own apartment. Indeed, Magali will now live (during weeks) in her own (10 square meters) room in Paris (close to Pigalle, oh la la) to make her life easier and save her from 4 hours commuting every day. Another page is turning...

#593401

Web Video and Global Innovation Chris Anderson (the curator of TED) gave an insightful TED talk about Web Video and Global Innovation [1]. Probably most people who have used the Internet seriously have an intuitive knowledge of the basic points of this talk, Chris had the insight to package it together in a clear manner. He describes how the printing press decreased the importance of verbal communication skills and services such as Youtube have caused a resurgence in the popularity and importance of speeches. He has some interesting theories on how this can be leveraged to improve education and society. Lectures for Developers vs Users Now how can we use these principles to advance the development of Free Software? It seems to me that a good lecture about Free Software achieve will achieve some of the following goals:

1. Promoting projects to new developers.
2. Teaching developers some new aspects of software development related to the system.
3. Promoting projects to new users.
4. Teaching users (and prospective users) how to use the software.

The talks aimed at developers need to be given by technical experts, but talks aimed at users don t need to be given by experts on the technology and someone who has less knowledge of the software but better public speaking skills could probably do a better job when speaking to users. Would it do some good to encourage people to join Free Software projects for the purpose of teaching users? It seems that there are already some people doing such work, but there seems little evidence of people being actively recruited for such work which is a stark contrast to the effort that is sometimes put in to recruiting developers. One problem in regard to separating the user-training and developer-training parts of Free Software advocacy and education is that most conferences seem to appeal to developers and the more Geeky users. Talks for such conferences tend to be given by developers but the audience is a mix of developers and users. Would it be better to have streams in conferences for developers and users with different requirements for getting a talk accepted for each stream? Publishing Videos It has become a standard feature of Free Software related conferences to release videos of all the talks so anyone anywhere in the world can watch them, but it seems that this isn t used as much as we would like. The incidence of Free Software developers citing TED talks in blog posts appears to exceed the incidence of them citing lectures by their peers, while TED talks are world leading in terms of presentation quality the talks by peers are more relevant to the typical Free Software developer who blogs. This seems to be an indication that there is a problem in getting the videos of talks to the audience. Would it help this to make it a standard feature to allow comments (and comments that are rated by other readers) on every video? Would having a central repository (or multiple repositories) of links to Free Software related talks help? Would it help to have a service such as Youtube or Blip.tv used as a separate repository for such talks? Instead of having each conference just use it s own servers if multiple conferences uploaded talks to Youtube (or one of it s competitors) then users could search for relevant talks (including conference content and videos made by individuals not associated with conferences). What about video replies ? What if after each conference there was an RSS feed of links to videos that had one video featured per day in a similar manner to the way TED dribbles the talks out. If you publish 40 videos of 45 minute lectures in one week you can be sure that almost no-one will watch them all and very few people will watch even half of them. But if you had an RSS feed that gave a summary of one talk per day for 6 weeks then maybe many people would watch half of them. Defining Success Chris cites as an example of the success of online video the competition by amateur dancers to create videos of their work and the way that this was used in selecting dancers for The LXD (Legion of eXtraordinary Dancers) [2]. I think that we need a similar culture in our community. Apart from people who give lectures at conferences and some of the larger user group meetings there are very few people giving public video talks related to Free Software. There is also a great lack of instructional videos. This is something that anyone could start doing at home, the basic video mixing that you need can be done with ffmpeg (it s not very good for that purpose, but for short videos it s probably adequate) and Istanbul is good for making videos of X sessions. If we had hundreds of Free Software users making videos of what they were doing then I m sure that the quality would increase rapidly. I expect that some people who made such videos would find themselves invited to speak at major conferences even if they hadn t previously considered themself capable of doing so (the major conferences can be a bit intimidating). How do we Start? Publishing videos requires some significant bandwidth, a cheap VPS has a bandwidth quota of 200GB per month, if short videos are used with an average size of 30MB (which seems about typical for Youtube videos) then that allows more than 6000 video views per month which is OK but as my blog averages about 2000 visits per day (according to Webalizer) it seems that 6000 views per month isn t enough for any serious vlogging. Not to mention the fact that videos in higher resolution or a sudden spike in popularity can drive the usage a lot higher. It seems that a site like Youtube or blip.tv is necessary, which one is best? There are lots of things that can be changed along the way, but a hosting service is difficult to change when people link to it. Conclusion I don t claim to have many answers to these questions. I m planning to start vlogging soon so I will probably learn along the way. I would appreciate any suggestions. Also if anyone has a long suggestion then a blog post will be best (I ll link to any posts that reference this one). If anyone has a long suggestion that is worthy of a blog post but they don t have a blog then I would be happy to post it on my blog.

• [1] http://www.ted.com/talks/chris_anderson_how_web_video_powers_global_innovation.html
• [2] http://thelxd.com/

The bug webinterface of the Universal Debian Database currently knows about the following release critical bugs:

In Total:	744
Affecting Squeeze:	358
Squeeze only:	76
Remaining to be fixed in Squeeze:	282

Of these 282 bugs, the following tags are set:

Pending in Squeeze:	19
Patched in Squeeze:	44
Duplicates in Squeeze:	28
Can be fixed in a security Update:	28
Contrib or non-free in Squeeze:	11
Otherwise fixed in Squeeze:	29

Ignoring all the above (multiple tags possible), 161 bugs need to be fixed by Debian Contributors to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 218 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

BSP Paris 2010, during mini-DebConf The first mini-DebConf in Paris, France is just a few weeks away and about 150 persons have signed up as attendees (wow!). The days of the conference (October 30th-31st, 2010) will most likely see the Debian Squeeze release in its deepest possible freeze, fighting with the very very very few remaining RC bugs (right? right!). What's the most useful thing that a crowd of Debian hackers can do that close to a release?
A Bug Squashing Party, of course! Therefore please welcome: We now need to arrange a room for the BSP, in parallel with the talk rooms of the conference. Hence please sign-up on the wiki page if you plan to attend the BSP. Please do so even if you're already signed up as a conference attendee, as the rooms will be different.

My phone contract ends in a few months, so I m looking at getting a new Android phone. I want a big Android phone (in both physical size and resolution) that has a physical keyboard, a digital compass, A-GPS and at least a 5MP camera with geo-tagging. I want to be able to read PDF files and run ssh sessions, so a big screen is required and a physical keyboard avoids wasting screen space for a soft-keyboard. My pockets will fit something about 10.5cm wide by 17cm high but I don t expect anyone to manufacture such a large phone. High resolution is a good thing too, it seems that the best available at the moment is 854*480 (with 800*480 being reasonably common). I want Wifi and all the 3G and GSM data transfer standards. It would be ideal to have a phone with the dual networking stack needed to do both voice and data at the same time. I m not interested in anything that runs a version of Android older than 2.2 as native tethering is important. An option to upgrade to post 2.2 would be a really good thing. Here are the nearest options I could find:

Phone	Resolution	Screen Size (inches)	Camera Resolution	Notes
Motorola Milestone	854*480	3.7	5MP
Motorola Droid	854*480	3.7	5MP
LG VS 740	800*480	3.2	3.2MP	no GPS or compass
Lenovo LePhone	800*480	3.7	3MP	no GPS or compass

It seems that Motorola makes the phones that best suit my needs, does anyone know of any better options?

In the last two cases where I created FAI configurations for different systems I needed to install packages which are not part of the Debian repositories.
Unfortunately FAI does not provide a standard way to supply the installation with custom packages so I need to figure out a way on my own.

I have the following requirements in the solution:

• Packages can be configured in package_config files as usual
• Packages will be installed during the normal package installation, no crude hack (like 'dpkg -i' and 'apt-get -f install' after usual package installation)

It would be easy if a repository reachable by the installed system would already exist. Unfortunately it does not. But.. aha! So here is the idea:

1. In the FAI configuration space add a new directory
   'packages'
2. We will use reprepro for the repositiory. You should install it where ever you prepare the configuration space. It would also be an option to install it into the NFSROOT and run it from there, but I decided to pre-prepare it (but this would be a clean solution if one of the FAI developers decided to implement a standard way, I guess).
3. Create a directory packages/conf and therein a file distribution with this content:
   

   Origin: Debian
   Label: Debian-All
   Suite: stable
   Codename: lenny
   Version: 5.0
   Architectures: i386 amd64
   Components: main
   Description: Debian Lenny

   Obviously you should adapt at least the Architectures line to whatever you need. Otherwise adapt what you need.
   
4. Now you can add packages, with reprepro includedeb lenny /path/to/debfile from within that directory, so cd to it, before.
   The result is, that the packages directory becomes a full-fledged Debian APT repository which can be used with apt by creating a line similar to the following:
   

   deb file:/var/lib/fai/config/packages lenny main contrib non-free

6. And thats what we'll do. In order to make this happen before any software gets installed, we create a hook. It needs to be called instsoft.CLASS where CLASS is a class that is used for the fai install we are working on. It basically needs to contain something like (+ the usual shell script stuff):
   
   

   $ROOTCMD ainsl /etc/apt/sources.list "deb file:/var/lib/fai/config/packages lenny main contrib non-free"
   $ROOTCMD apt-get update

   This should add the repository the sources.list in the /target and run apt-get update.
   

Thats it. This should be all to make the repo available to the usual installation. That means if your package_config files contain packages which are only part of the custom repo they will now be able to be installed.

(This might probably not be a copy and paste howto. It just describes the rough steps needed to do and might contain errors. So don't blame me if it doesn't work 100% this way. ;-)

I've been mostly working on GnuCash the past few evenings. I added more info and a test case to Bug #593856, so that should fall into place soon. I turned my attention to ettercap this evening, and Bug #521857 - another easy one, just applying the updated patch. Except when I ran "lintian -F", I got:

lintian -F /var/cache/pbuilder/result/ettercap_0.7.3-2.1_amd64.changes 
E: ettercap: binary-or-shlib-defines-rpath ./usr/sbin/ettercap /usr/lib
E: ettercap-gtk: binary-or-shlib-defines-rpath ./usr/sbin/ettercap /usr/lib

This led me to a Jan 2008 email from Raphael Geissert about packages defining RPATH on amd64. For now, I've rebuilt in an i386 chroot - I'd need some help making a full lintian run on amd64 if I were going to propose a mass bug-filing.

Debian 6.0 squeeze will be the first GNU/Linux distribution release ever to offer comprehensive support for magnetic resonance imaging (MRI) based neuroimaging research. It comes with up-to-date software for structural image analysis (e.g. ants), diffusion imaging and tractography (e.g. mrtrix), stimulus delivery (e.g. psychopy), MRI sequence development (e.g. odin), as well as a number of versatile data processing and analysis suites (e.g. nipype). Moreover, this release will have built-in support for all major neuroimaging data formats.

Please see the Debian Science and Debian Med task pages for a comprehensive list of included software and the NeuroDebian webpage for further information.

NeuroDebian at the Society for Neuroscience meeting 2010

The NeuroDebian team will run a Debian booth at the Society for Neuroscience meeting (SfN2010) that will take place November 13-17 in San Diego, USA. The annual meeting of the Society for Neuroscience is one of the largest neuroscience conferences in the world, with over 30,000 attendees. Researchers, clinicians, and leading experts discuss the latest findings about the brain, nervous system, and related disorders.

If you are a Debian enthusiast (developer, contributor, evangelist) and reside near San Diego (or have time and funds for travel/lounge), or already planing to attend SfN 2010, please help us to make the Debian booth at SfN shine. Please contact the NeuroDebian team at team@neuro.debian.net

If you are going to SfN2010, come talk to us at booth #3815.

Contributed by: Michael Hanke and Yaroslav Halchenko

Dear Julien; After using notmuch for a while, I came to the conclusion that tags are mostly irelevant. What is a game changer for me is fast global search. And yes, I changed from using dovecot search, so I mean much faster than that. Actually I remember that from the Human Computer Interface course that I took in the early Neolithic era that speed of response has been measured as a key factor in interfaces, so maybe it isn't just me. Of course there are tradeoffs, some of which you mention. David

A conffile is a configuration file managed by dpkg, I m sure you remember the introductory article about conffiles. When your package stops providing a conffile, the file stays on disk and it s recorded as obsolete by the package manager. It s only removed during purge. If you want the file to go away, you have to remove it yourself within your package s configuration scripts. You will now learn how to do this right. When is that needed? dpkg errs on the side of safety by not removing the file until purge but in most cases it s best to remove it sooner so as to not confuse the user. In some cases, it s even required because keeping the file could break the software (for example if the file is in a .d configuration directory, and if it contains directives that are either no longer supported by the new version or in conflict with other new configuration files). What s complicated in rm ? So you want to remove the conffile. Adding an rm command in debian/postinst sounds easy. Except it s not the right thing to do. The conffile might contain customizations made by the administrator and you don t want to wipe those. Instead you want to keep the file around so that he can get his changes back and do whatever is required with those. The correct action is thus to move the file away in the prerm, to ensure it doesn t disturb the new version. At the same time, you need to verify whether the conffile has been modified by the administrator and remember it for later. In the postinst, you need to remove the file if it s unmodified, or keep it under a different name that doesn t interfere with the software. In many cases adding a simple .dpkg-bak suffix is enough. For instance, run-parts ignore files that contain a dot, and many other software are configured to only include files with a certain extension say *.conf. In the postrm, you have to remove the obsolete conffiles that were kept due to local changes and you should also restore the original conffile in case the upgrade obsoleting the conffile is aborted. Automating everything with dpkg-maintscript-helper Phewww that s a lot of things to do for a seemingly simple task. Fortunately everything can be automated with dpkg-maintscript-helper. Let s assume you want to remove /etc/foo/conf.d/bar because it s obsolete and you re going to prepare a new version 1.2-1 with the appropriate code to remove the file on upgrade. You just have to put this snippet in the 3 relevant scripts (preinst, postinst, postrm):

if dpkg-maintscript-helper supports rm_conffile 2>/dev/null; then
    dpkg-maintscript-helper rm_conffile /etc/foo/conf.d/bar 1.2-1 -- "$@"
fi

You can avoid the preliminary test if you pre-depend on dpkg (>= 1.15.7.2) or if enough time has passed to assume that everybody has a newer version anyway. You can learn all the details in dpkg-maintscript-helper s manual page. I hope you found this article helpful. You can follow me on Identi.ca, Twitter and Facebook. 5 comments Support my work

I've recently got a mail from one of my faithful reader, asking why not considering notmuch. Actually, I think notmuch already exists in a better way, and that's called IMAP and Sieve. What notmuch does, is tagging your mail with tags (obviously), based on filtering rules you write. The big downside is that you have to tag all your mails on your computer. And if you use several computers, you'll have to tag several times your mails. And you'll have to find a way to maintain your rules to be identical on all your computers. That does not scale. Using Sieve for mail filtering, one can do already that actually, and much more. A notmuch rule like:

notmuch tag +intel from:intel.com and not tag:intel

Can be written as a Sieve rule like:

if address :all :contains "From" "intel.com"  
        addflag "intel";
 

The flags extension for Sieve is explained in RFC5232. The Sieve based solution has the advantage of being treated server side, and therefore not subject to multiple or different MUA usages. It's also fast, if you use a good IMAP server like Dovecot, which has indexing, etc. Furthermore, Sieve can obviously do a lot more than tagging, like splitting into different mailboxes, filtering with regexp usage, vacation, etc. And if you want to fetch your mail locally, you can synchronize the IMAP box entirely with any software able to (like OfflineIMAP). Now, what's probably missing, is a correct support for IMAP flags on various MUA around. But that's not something notmuch helps to solve either. :-)

More than year ago, I've generated mysel new PGP key (4096 bit RSA), with intention to migrate to it sooner or later. Being little pushed by Bits from keyring-maint, I've decided the right time is about now. As I was giving the key for signing in past more than year, it already has quite a lot of signatures (actually more than the old key). You might notice that the old key has signed far more keys. This is mostly caused by simple fact that I did use both keys for signing, while only giving new one to be signed. So if you're among these people who signed the old one (0x36E75604), please check the transition document and consider signing my new key (0x42B7511D).

Filed under: Debian 0 comments

Roland Mas writes an interesting article about decentralized naming, in which he says:

Monkeysphere aims at adding a web of trust to the SSL certificates system, but the CA chain problem seems to persist (although I must admit I'm not up to speed with the actual details).

Since i'm one of the Monkeysphere developers, i figure i should respond! Let me clarify that Monkeysphere doesn't just work in places where X.509 (the SSL certificate system) works. It works in other places too (like SSH connections). And I don't think that the CA chain problem that remains in Monkeysphere is anything like the dangerous mess that common X.509 usage has given us. I do think that at some level, people need to think about who is introducing them to other people -- visual or human-comprehensible representations of public key material are notoriously difficult to make unspoofable. On the subject of distributed naming: OpenPGP already allows distributed naming: every participant in the WoT is allowed to assert that any given key maps to any given identity. Duplicates and disagreements can exist just fine. How an entity decides to certify another entity's ID without a consensus global namespace is a tough one, though. If i've always been known as "John Smith" to my friends, and someone else has also been known as "John Smith" to his friends, our friends aren't actually disagreeing or in conflict -- it's just that neither of us has a unique name. The trouble comes when someone new wants to find "John Smith" -- which of us should they treat as the "correct" one? I think the right answer probably has to do with who they're actually looking for, which has to do with why they're looking for someone named "John Smith". If they're looking for John Smith because the word on the street is that John Smith is a good knitter and they need a pair of socks, they can just examine what information we each publish about ourselves, and decide on a sock-by-sock basis which of us best suits their needs. But if they're looking for "John Smith" because their cousin said "hey, i know this guy John Smith. I think you would like to argue politics over a beer with him", then what matters is the introduction. And OpenPGP handles that just fine -- if their cousin has only ever met a single John Smith, that's the right one. If their cousin has met several John Smiths, then the searcher would do well to ask their cousin some variant of "hey, do you mean John Smith or John Smith ", or even "do you mean the John Smith who Molly has met, or the one who Charles has met?" (assuming that Molly and Charles have each only certified one John Smith in common with the cousin, and not the same one as each other), or to get a real-time introduction to a particular John Smith, where his specific key is somehow recordable by the searcher for future conversations (or beer drinking). This is what we do in the real world anyway. We currently lack good UIs for doing this over the network, but the certification infrastructure is in place already. What we're lacking in infrastructure, though, is a way to have a distributed addressing. Roland's proposal was to publish addresses corresponding to cryptographic identities within some DNS zone, or in freenet or gnutella. Another approach (piggybacking on existing infrastructure) would be to include IP address information in the OpenPGP self-certification, so the holder of the name could claim exactly their own IP address. This could be distributed through the keyserver network, just like other updates are today, and it could be done simply and immediately with a well-defined OpenPGP notation. I'd be happy to talk to interested people about how to specify such a notation, and what possible corner cases we might run into. Drop a note here, or mail the Monkeysphere mailing list or hop onto #monkeysphere on irc.oftc.netTags: authentication, distributed naming, identity, monkeysphere

What's the best way to run PHP in Debian in a shared environment? Years ago May First/People Link switched from the old reliable modphp to suPHP because modphp ran all php scripts as the same user, meaning (among other things) that any site could access the database configurations of any other site. suPHP was great, however, after several years we've decided to replace it because:

• As our members increasingly use Drupal and Drupal sites grow increasingly more complex, suPHP's performance has become a problem.
• suPHP executes with the permissions of the owner of the file it is executing. From a zero-conf perspective, this features makes suPHP very easy to setup. However, from a security perspective, it forces you to run your php script with the permission to delete itself. Not optimal.

We first turned to fcgid. We tried it out on a couple individual web sites (fcgid can run alongside suPHP), and, after a week without much problems, we implemented it on an entire server. Out of the box, on a shared server with several dozen web sites, the most notable resource utilization difference between fcgid and suPHP is the increase in memory usage. Unlike suPHP which dies after each requests, fcgid gains a performance boost by sticking around (with either 2 or 3 processes living on) to server future requests. If you have several dozen web sites that aren't high traffic sites, it means they may each have up to the three processes staking out memory that would otherwise be free with suPHP. We addressed the memory problem by adding the following to /etc/apache2/mods-available/fcgid.conf:

DefaultMinClassProcessCount 0
IdleTimeout 60
IdleScanInterval 60

These directions tell fcgid to kill processes that have been idle for more than 60 seconds. That means we still get the performance gain from a site getting more than one page view per minute, but otherwise we re-claim the memory. Before switching our remaining servers we decided to do more extensive testing to ensure we would be getting the performance and resource gains we were hoping. Also, we decided to consider mpm-itk, which is a variation of mpm-prefork that runs each virtual host with a per-vhost configured user and group (like suexec, but for the entire virtual host). Since it's a variation of mpm-prefork, it's safe to run it with the more resource friendly mod_php. We used the apache benchmarking tool ab. And we tested on a virtual machine (running on my laptop) with 1GB of RAM. The test web site we used was a copy of the May First/People Link site (we used the home page for the test), which is running Drupal 6. It's a relatively simple Drupal site, however, we turned Drupal caching off to better simulate PHP processing usage likely to be found on our members' sites. We ran tests against the following configurations:

• Plain mpm-prefork with mod_php and apc (as a standard to strive for)
• Both mpm-worker with suPHP and mpm-prefork with suPHP (how much of a difference does worker vs prefork make with a Drupal site?)
• mpm-worker/fcgid/suexec
• mpm-itk with mod_php

The tests were run with:

• 1 request (in the results, this test is labelled 1:1)
• 20 requests, 5 concurrent (20:5)
• 50 requests, 10 concurrent (50:10)
• 70 requests, 10 concurrent (70:10)

We originally tried, for the last test, 100 requests/25 concurrent but it caused ab to time out on the mpm-worker/fcgid/suexec configuration. We then lowered it to 75/15. Still timed out (load on our test server went way up). The tests paused 120 seconds between testing each environment to give the server load a chance to settle down. And we paused 30 seconds between each test (not enough time for the fcgid processes to be killed, but enough time for all the processes to hopefully complete their requests). The tests are scripted and the full results are available. You can also see the various vhost configurations (test.mouse, test.mouse.itk, test.mouse.suexec.fcgid), and the fcgid.conf. To summarize the report ... if you are running one web site on a server, there's little argument for using anything other than mod_php and mpm-prefork - the performance of this combination far exceeds any other combination. I'm scratching my head over the the vastly different conclusions reached by 2bits. They didn't publish their tests so I'm not sure exactly how to compare. Maybe they have a lot more static content? Or - maybe there's a mistake in our tests? Open to ideas. suPHP seems to be left in the dust compared with either fcgid/suexec or mpm-itk. Given that it's also less flexible, there's not much going for it. And lastly... fcgid/suexec and mpm-itk seem comparable. That was a surprise. We were expecting mpm-itk to perform better because it's running mod_php. Given the similarity in performance, fcgid/mpm-worker seems like a much more well-tested and well-supported approach for a shared server. One side note... originally, out of laziness, we tested against the default Drupal install.php page. Less static content and much less PHP processing. In these tests, with low loads, the results provide different numbers, but the comparisons between environment were similar ... except with the last test. With the 70 requests/10 concurrent test, fcgid/suexec dramatically out-performed everyone (by a factor or more than 2). That's probably because no new cgi processes had to be spawned and the effect of mod_php using APC was reduced because there was very little php code to process.

Review: Thinking in Java, by Bruce Eckel

Publisher:	Prentice Hall
Copyright:	2006
Printing:	October 2009
ISBN:	0-13-187248-6
Format:	Trade paperback
Pages:	1461

Thinking in Java has gone through multiple editions. This review is of the 4th edition, which is targetted at Java 5 (with some minor updates for Java 6, released as it was going to press). Prior to reading this book, I'd never written code from scratch in Java and had never learned anything about Java in a structured fashion. My CS degrees come before the era of ubiquitous Java; the most I'd ever done with the language was look over and make some minor fixes to code other people had written, using general programming knowledge. I choose this book as my introduction because I was looking for a ground-up introduction with good reviews and was avoiding books that contained a printed version of the Java library documentation. I can get that myself on-line. I kept a set of notes on my impressions of the Java language itself separately and will not get into that here. This is, instead, a review of Thinking in Java as a book and as a training tool for someone who wants to pick up the language. First off, this is a remarkably well-titled book, much more so than the typical programming language book. Eckel is not just teaching Java as one programming language among many. He tries hard to teach the reader to think in Java, with a lot of attention to idiomatic use of the language and natural ways to use its expressiveness. This is exactly what I was looking for I don't want to just write C or Perl in Java syntax and I was very satisfied with the result. The book is also very heavy on source code examples; this is much of the reason why it's 1,461 pages. Eckel illustrates everything with Java code, generally complete functioning short programs. Even exploratory musings and experiments are implemented as Java code. I don't think there's any significant thought in this book that isn't shown in both text and in explained Java code. Eckel has also clearly put significant effort into choosing good examples and designing his sample programs. I have some past (mild) experience with object-oriented design, and a lot of experience with higher-level system design, and I was satisfied and occasionally intrigued by the object structures and design tips that Eckel provides. He uses design pattern language heavily, but not in a confusing way, and he takes some time to explain typical design patterns and illustrate them repeatedly. This is a solid introduction to good object-oriented program design as well as an introduction to Java. One oddity of this book, though, is that Eckel introduces the language from the ground up, starting with syntax and basic types, and is very careful not to use any concepts before he introduces them. The result is a very thorough introduction to the Java language, but it means that it takes 900 pages (!) before Eckel introduces I/O and the possibility of writing a useful program based on just the information in the book. This is for entirely sound conceptual reasons: I/O in Java relies on lots of concepts, like exceptions and generics, that require extensive introduction and discussion. However, it does mean that through well more than half of a monumental tome the reader is learning the language through rather artificial programs. I have extensive prior programming background and a high tolerance for more abstract examples (I have a master's degree in software theory), so I could deal with this, but even with that background I was starting to feel like my head was getting too full and too crowded with concepts without being able to make them concrete. It probably would have helped to work through some of the exercises, but I dislike exercises that aren't grounded in some problem I personally want to solve. If you're someone who only learns languages through practical application, this approach to teaching the language may drive you nuts, and you may want to look for another book that compromises conceptual progression to get you started faster. Related to this, Thinking in Java is not about the standard library. It's about the language, and the vast majority of this book is focused directly on the language level: inheritance, information hiding, generics, exceptions, introspection, concurrency, annotations, serialization, and so forth. The only parts of the standard library that Eckel covers in depth are the container classes, I/O, and a somewhat odd and misplaced final chapter on Swing. There is nothing about databases, essentially nothing about web applications or containers, no network programming, and very little in the way of practical, applied problems. As you might guess from the combination of that limitation of scope and the length of this book, that means it is extremely comprehensive; I doubt there are many corners of the basic language semantics, including around generics, that Eckel leaves unexplored. This is exactly what I wanted (I know how to read library documentation myself and all language core libraries start looking mostly the same after you've programmed in five or six languages), but it's very different from the typical approach of a programming language book. Don't be surprised. This biggest problem with Thinking in Java from my perspective is that it defers many interesting topics to Eckel's web pages and to free companion books and material that is supposedly found there, to the point of advertising that on the cover. This is a good way to allow the reader to explore extra topics that are of specific interest while skipping others, provided that one actually delivers on that promise. However, Eckel's web site is dire. The first time I looked at it earlier this year I was unable to find most of the supplemental material the book promises is there, and now www.mindview.net doesn't resolve in DNS. I've found copies of some of that material hosted elsewhere in Google searches, but this is a rather frustrating experience if one was relying on that supplemental material to fill in the gaps. And the book is clearly written expecting people to go look at the web materials; Eckel refers to them probably a hundred times over the course of the book. Less of a serious problem, and more of a quirk, is the closing chapter on Swing. This chapter really doesn't fit much with the book. I suppose Eckel felt obligated to put in at least one chapter on some concrete applied topic (I personally would have preferred databases be that topic, but oh well), and it does serve a useful purpose in showing how concurrency, inner classes, inheritance, and introspection all work together in a significant Java library. But it's not presented as just an example, and it fits in oddly with the rest of the book. It also has an inexplicable middle section about Flash programming. I ended up mostly skimming this. But this isn't much of a flaw in the book; if one ignores 100 pages out of 1,450, that's not much of a loss. Eckel comes from a C++ background (he was a founding member of the C++ standardization committee), which shows up most prominantly in the generics chapter. It's a solid, thorough introduction to Java generics, but it also has an extensive exploration of all the problems with the Java erasure model and many, many examples of the things that one would find intuitive from C++ that don't work the same way in Java. If you come from a C++ background, this is quite possibly useful; if, like me, you don't care about C++, it's at best mildly interesting and gets a touch tedious. There are a few other places where Eckel pokes surprisingly sharp sticks at the Java designers, but taken in context I think this is a quirk of the book's conversational style (which is otherwise a feature). Eckel's love of Python is also somewhat entertaining (particularly the long advertisement for Python in the introductory chapters of a book on Java), but has little impact on the book. I think the largest drawback of it is that all the examples in this book are tested using a Python framework, which isn't so much a problem with them as a lost opportunity. They're annotated with metadata used by Eckel's Python test framework, and in a Java book I would have been much more interested in a good Java test framework built on top of something like JUnit. Oh well. Overall, this is a very solid book which, despite being enormous, does not feel pointlessly padded. It's thorough and exhaustive on its topic, but there's a point to nearly everything in here. It was also exactly the Java book I wanted: an introduction to the language, built on a firm foundation of object-oriented program design, with discussion and pointers on how to think idiomatically in the language and use it to its fullest potential, and without mindlessly reproducing the standard library documentation. If that's also what you're looking for in a Java book, I recommend it highly. Just know going in what sort of book you're getting, since its pacing and order of presentation may frustrate some learning styles. Rating: 8 out of 10

Last night, I released xen-tools 4.2 and also uploaded it to Debian Unstable. It also should become part of the upcoming Debian stable release called Squeeze. (Thanks, Mehdi!) For those who are missing xen-tools in Ubuntu 10.04 Lucid Lynx or Ubuntu 10.10 Maverick Meerkat, there s now a xen-tools PPA containing the current stable package for both Ubuntu releases. Major changes since the 4.2 release candidate 1:

• Tons of documentation improvements
• Preliminary support for Ubuntu 11.04 Natty Narwhal and Debian 7.0 Wheezy (Closes #597521)
• More robustness on exotic combinations of command-line options

Major changes since 4.2 beta 1:

• Uses GeoIP for Debian mirrors: Default Debian mirror is now cdn.debian.net
• Uses apt-config to parse Dom0 s apt.conf. (Closes #560011)
• With --verbose, the output of commands called by xen-tools (e.g. debootstrap) is not only logged, but also printed to STDOUT. (Closes #513126)
• Adds btrfs support.

New Team Member I d also like to welcome St phane Jourdois as member of the xen-tools development team who contributed quite a lot of the new code in 4.2. See GitHub s Impact Graph or Ohloh s List of Contributors. Roadmap If there s no need for a bug fix release, the next release will be 5.0 and will be the result of some heavy refactoring. Our aim is:

• less code duplication
• more modularity
• more consistency over all included scripts and hooks

We will probably also use Perl::Critic to improve the code consistency and quality further. (Thanks Ren e for the idea!)

As a follow up on my report from last month about bidi status in openoffice.org 3.3, today was a very good day for bidi in openoffice.org. The short story: two important bugs were fixed for 3.3, and we now have the bidi keyword for IssueZilla system. It began with the fix to a cosmetic bug in the openoffice.org main screen which caused the icons to repaint improperly. While this isn t critical at all, it just looks really bad to have it on the main screen. And I don t want people to get the wrong impression. Thanks you Philipp Lohmann for fixing #97556. The second bug was that AutoFilter isn t working for RTL sheets (regards whether the UI is LTR or RTL). This issue was reported yesterday and got fixed in 24 hours. Thank you Niklas Nebel for fixing #114944. It took us longer to isolate the bug than to get a patch for it. I wish this will happen more (: For closing, and in response to the bidi meta issue, a new keyword was created in the issuezilla: bidi. Till now, there was a bidi sub component in the UI, but this isn t always helpful as sometimes it s better to report against the actual component. The keyword will help us to better tag the issues for easy listing. The thank you list is long, as there were more than a few people behind the scenes today. I ll only mention Netanel, my partner to the Hebrew l10n team.
Filed under: Israeli Community, LibreOffice, Openoffice.org Tagged: bidi, openoffice

I've just uploaded git-dpm 0.3.0-1 packages to experimental. Apart from many bugfixes (which I will also take a look if I can make an 0.2.1 version targeting squeeze, though the freeze requirements tend to get tighter and tighter, so I may already be too late), the biggest improvement is the newly added git-dpm dch command to spawn dch and then extracts something to be used for the git commit message (I prefer to have more control over debian/changelog, so I prefer this way over the other direction).

I'm in hospital, taking an enforced rest from work and normal life.with much too much time to think. Luckily I have relatively slow 'Net access.

I've just spent about three weeks in a specialist orthopaedic hospital which is also a centre of excellence, a research and teaching hospital. Some lessons for FLOSS:

Research methods matter: open communication matters more

The hospital was apparently doing various research projects, some minor, some major: whether cooling a knee joint in surgery improved recovery and aftercare, whether complete pain relief and comprehensive analgesia stimulated recovery, trying to standardise on a pain score to measure subjective pain - " On a scale of 1-10 how does it feel?"

The knee joint research was being written up and would be shared worldwide - if it proved worthwhile, hundreds of patients could benefit. If it wasn't worthwhile, it would still be written up just as comprehensively with testing methodology, evidence from double-blind trials or whatever as appropriate to save someone else from having to re-invent the wheel.

The analgesia study sounded just like the application of a doctor or nurse's intuitive commn sense and experience - but it was being carried out scientifically and measured. also answering supplementary questions like "If pain is sometimes a helpful indicator of problems, how should you guage reactions when all pain is dulled?" Additionally, the ward had dispensations to use different and more flexible drug regimes to include the use of oral morphine derivatives. Again, everything was being noted, measured and shared.