Obey Arthur Liu: Google Summer of Code at Debian: Update, need mentors!
A quick update before the big one about the 2009 Google Summer of Code.
I believe we had a great recruitment drive this year and we have a very good set of proposals to work with. We d like to thank everyone involved for their help. We re now ranking out student applications.
I promised elsewhere that I ll send out our shortlist of projects once Google sends us our preliminary slot allocation today but I misread the thread on the -mentors list and that count will only happen on Thursday, so we ll have to wait a bit more. That shortlist would only include projects, but not individual students. The idea is to give a heads up to everyone before committing to a group of projects and students. It is very important to inform the community as it increases visibility of the students work, giving them more help and support (and also avoids duplicating existing not yet publicized work!).
As far as mentors go, we should have all of our approximately 14 planned projects covered, except for 2. I m posting them here in case you could mentor or help find mentors for those projects. (The wiki pages are not really up to date, so please come on IRC and ask clarifications, see below)
Finish Petr Rockai s Adept 3.0 and bring a Qt4 Package Manager to Debian, with a different interface paradigm than Aptitude-gtk.Petr said he would provide help with the existing codebase but can t mentor. Sune Vuorela from Debian KDE is ready to help with Qt4 related issues. Build Debian tools to create Debian images for Amazon EC2 and the free Eucalyptus implementation. Packaging of the Eucalyptus hosting framework is also possible.
For this project, we already have on board to help: Charles Plessy from Debian Med, Eric Hammond, developer of the existing vmbuilder Ubuntu tool for EC2 and Chris Grzegorczyk and Rich Wolski, from the Eucalyptus team. Plenty of people to get help from. Mentoring is a great experience! See this for what it entails. If we still can t find a mentor by the end of the week, I ll blast an announcement over at debian-devel@l.d.o along with the project shortlist. In the meantime, don t forget to idle on #debian-soc on irc.debian.org.


My patch for initial kernel support for the QNAP TS-119 and TS-219
Turbo NAS got accepted and will be in 2.6.30. I can run Debian on
a USB disk without any problems but there are some issues left (some
severe, some cosmetic):
This weekend, I was going to go to an acquaintance so that we could
edit the material which we had filmed at the concert. Yes, we did use
DVswitch, but due to me being somewhat late in proposing a video team,
there was no team, and hence nobody switched anything. So instead we'll
have to edit stuff now.
Since I'd never done anything of the sort before, I guess it's fair
to say that I'm not exactly the expert. As such, I installed samba,
plugged the (LVM2/ext3 formatted) external hard disk containing the
movie files to my laptop, and served them over a gigE link to his; the
idea being that we could then do the editing on his system, using the
software which he knew.
After having copied those files (one 22G DV file, one 15G one, and a
few much smaller ones), he loaded them into the editing software. Which
promptly sat on its ass, making us wait, as it 'analyzed' the movie
clip. This of course took ages.
As said, I don't really know a lot about movie editing. However, in
preparation to this, I had been playing with
In a Java framework I'm working on, 'pairs' arise everywhere. Unfortunately in
contrast to e.g. C++, Java doesn't include a predefined 'pair' class.
C++ templates are really nice because of the way they are complied and
optimized (in particular they also handle what Java calls 'native datatypes');
Java generics aren't up to par with that. (But yes, Java offers other benefits,
such as being much easier to parse and thus refactor). Anyway, this is not
going to be a rant on Generics.So I have this interface in Java called Pair<FIRST,SECOND>
along with two implementations SimplePair<FIRST,SECOND> and
ComparablePair<FIRST extends Comparable<FIRST>,SECOND extends Comparable<SECOND>>.For performance reasons, SimplePair is declared 'final', and
so is ComparablePair. It's written everywhere that making classes
final can make a large difference in Java, and since these objects will be used
in a lot of places, it seems reasonable to care about this here.However, it would often be nice to have better readable code, that is assuming
I'm using SimplePair<Monkey,Banana>, it would then be nice to
make a derived class BananaPreference extends
SimplePair<Monkey,Banana>, with added methods getMonkey()
and getPreferredbanana() to make the resulting code more readable.Having readable code is also often quite as important as having performant
code, after all ...If someone with solid experience in Java optimization has some ideas to share,
please do so! Email: erich AT debian DOT org - no comments in blog.Right now, I have one idea on how it could be possible to achieve both
(seriously, I could use some feedback from Java Gurus on that): make
SimplePair and ComparablePair abstract, all methods there final, then derive
final classes as needed. Does that combine the benefits?[Update: I received from Joachim Sauer the following helpful link:

Two days ago I read about the
...
and now for something completely different...
sometimes in a shell script you need to do stuff that modifies
the positional parameters (
My experience with LapStore's used-ThinkPad warranty repair
service
My ThinkPad T40 arrived back from warranty repair today
(well, actually
yesterday, but I had to run off to the
I live in the USA. Our government issues many grants to scientists for research via the 