In this age of bits and bytes, there are many virtual organizations and networks which produce all sorts of stuff we use on a daily basis. My two favorite institutions are Debian (not a surprise) and Wikipedia, not just because they oh-so-useful to me and many others, which they are, but because the social organizations behind these two entities are so (at times maddeningly) complex and full of nuance, they provide for endless analytical fascination. One of my friends, Joe Reagle, who has recently graduated from my home department, is presenting is work on Wikipedia and I thought some local New York geeks might be interested. Information below:

All welcome 4:30 - 6:00 PM, Tuesday February 17
206 Vanderbilt Hall, 40 Wash. Sq. So. Wikipedia: Nazis and Norms Joseph Reagle, NYU Department of Media, Culture, and Communication Abstract: In 1990 Mike Godwin coined his Law of Nazi Analogies to capture the common devolution of Usenet discourse into insulting comparisons with Nazis or Hitler. Eleven years later, Jimmy Wales wrote that it was important that the Wikipedia community preserve and extend our culture of co-operation, with all of us standing as firmly as possible against the culture of conflict embodied in Usenet. I argue Wikipedia is a realization even if flawed of a long-held vision for a universal encyclopedia: a technology inspired vision seeking to wed increased access to information with greater human accord. And I claim Wikipedia s collaborative culture is a big factor for this success: the norms of Neutral Point of View ensures that the scattered pieces of what we think we know can be joined and good faith facilitates the actual practice of fitting them together.

In this age of bits and bytes, there are many virtual organizations and networks which produce all sorts of stuff we use on a daily basis. My two favorite institutions are Debian (not a surprise) and Wikipedia, not just because they oh-so-useful to me and many others, which they are, but because the social organizations behind these two entities are so (at times maddeningly) complex and full of nuance, they provide for endless analytical fascination. One of my friends, Joe Reagle, who has recently graduated from my home department, is presenting is work on Wikipedia and I thought some local New York geeks might be interested. Information below:

All welcome 4:30 - 6:00 PM, Tuesday February 17
206 Vanderbilt Hall, 40 Wash. Sq. So. Wikipedia: Nazis and Norms Joseph Reagle, NYU Department of Media, Culture, and Communication Abstract: In 1990 Mike Godwin coined his Law of Nazi Analogies to capture the common devolution of Usenet discourse into insulting comparisons with Nazis or Hitler. Eleven years later, Jimmy Wales wrote that it was important that the Wikipedia community preserve and extend our culture of co-operation, with all of us standing as firmly as possible against the culture of conflict embodied in Usenet. I argue Wikipedia is a realization even if flawed of a long-held vision for a universal encyclopedia: a technology inspired vision seeking to wed increased access to information with greater human accord. And I claim Wikipedia s collaborative culture is a big factor for this success: the norms of Neutral Point of View ensures that the scattered pieces of what we think we know can be joined and good faith facilitates the actual practice of fitting them together.

Well, no, neither FOSDEM nor Debian are dead. But FOSDEM '09 is gone, over, and dealt with. It was a breeze, for the most part. I'm still not very happy with the booth; that needs to be done better next year. Help and suggestions in that area are more than welcome. One thing that more than deserves a follow-up is Lucas' post about FOSDEM:

On a more sad note, the worst talk of the week-end was without any possible doubt Frans Pop's release team bashing. Nobody is claiming that the release management of the lenny release cycle was perfect: there's always room for improvement. But given the context and the constraints, I think that they did a very good job. Frans' talk boiled down to: "The release team doesn't know what they are doing, I would have done much better because I'm so qualified."

As the person responsible for allowing Frans on the schedule in the first place, while being fully aware of the relationship between Frans and the release team (not at first, but certainly in time to kick him off if I'd have wanted to), I'd like to comment on that. First of all, I do not agree that the last statement in the above is true. Frans showed a few stories of things that went on in the release team, and gave his opinion on what he believed went wrong. He also explicitly said, at the beginning of the talk, that none of the talk was meant personally; that he wanted to offer some constructive criticism instead. I believe he did not fail in doing that, but of course YMMV. Secondly, and more importantly, I do not believe it is healthy for Debian (or any project, for that matter) to reject criticism. Indeed, nobody is claiming perfection. I do not believe any venue where talks can be had should be a good news show. People in a position of power not just the release team, but also, say, the DPL, ftp-masters, buildd maintainers and whatnot have received our trust to do what they need to do to the best of their abilities. If someone in the project would believe that I can significantly improve my work as buildd maintainer, it is not just their right, but indeed their duty to inform me of that fact. This is exactly what Frans was attempting to do, and there is nothing wrong with that. It is also not as if he's not tried reasoning with the release team first. He has made suggestions, which have gotten ignored. I feel that talking to more people about what he feels is right, to see whether they agree with him, is the next logical step to take, and that this it is exactly what Frans was attempting to do at FOSDEM. Having said that, I agree that finishing the talk late was a very bad thing. If anything, a talk on a subject like this should have more, not less, time for discussion. So while I do not agree that his intentions were wrong, I do agree that the execution could have been better. There, that was criticism too. Now, what's next? Oh yes, suggestions. If people have suggestions on how to improve the Debian presence at FOSDEM next year (especially, as above, ideas for creative use of the booth would be welcome), then please send me an email, making sure the subject contains the word 'FOSDEM', so my mailfilters know what to do with it. You'll preferably do so now, while FOSDEM is still somewhat fresh in your memory; I'll take notes and use those for doing better next year. Thanks,

Rumour has it that some types of spammer target the secondary MX servers. The concept is that some people have less control over the secondary MX server and less ability to implement anti-spam measures. Therefore if they accept all mail from the secoondary then a spammer will have more success if they attack the secondary server. True secondary servers are becoming increasingly uncommon, the lower priority servers listed in MX records tend to have the same configuration as the primary, so the benefit for the spammer in attacking the secondary server is probably minimal. But it would be good to know whether they do this. I decided to analyse the logs from a mail server that I run to see if I can find evidence of this. I chose a server that I run for a lient which has thousands of accounts and tens of thousands of messages delivered per day, my own server doesn t get enugh traffic to give good results. I analysed the logs for a week for the primary and secondary MX servers to see if the ratio of spam to ham differed. Now this does have some inherent inaccuracy, some spam will slip past the filters and occasionally a legitimate email will be rejected. But I believe that the accuracy required in a spam filter to avoid making the users scream is vastly greater than that which is required to give a noteworthy result. I produced totals of the number of messages delivered, the number rejected by SpamAssassin (which has a number of proprietary additions), the number of message delivery attempts that were prevented due to rate limiting (most of which will be due to spammers), and the number of attempts to deliver to unknown accounts (some of which will be due to spammers having bad addresses in their lists). For each of these rejection criteria I produced a ratio of the number of rejections to the number of delivered messages for each of the servers. The rate limit count didn t seem useful. While the primary server had a ratio of 0.75 messages rejected due to rate limiting to every message accepted the secondary had a ratio of 0.08. It seems that the secondary just didn t get enough traffic to trigger the limits very often. This is an indication that the more aggressive bots might not be targetting the secondary. The ratio of messages rejected by SpamAssassin to legitimate mail was 0.76:1 on the primary server and on the secondary server it was 1.24:1. The ratio of messages addressed to unknown users to successful deliveries was 3.05:1 on the primary and 7.00:1 on the secondary! This seems like strong evidence to show that some spammers are deliberately targetting the secondary server. In this case both the primary and secondary servers are in server rooms hosted by the same major ISP in the same region. The traceroute between the two mail servers is only 7 hops, and there is only one hop between the two server rooms. So it seems unlikely that there would be some connectivity issue that prevents spammers from connecting to the primary. One other factor that may be relevant is that the secondary server has been in service for some years while the primary is only a few months old. Spammers who store the server IP address with the email address (which happens - change the DNS records to send your mail to a different server and you will see some spam go to the old server) will be sending mail to what is now the secondary server. The difference in the rejected mail volume on the secondary server and the amount that would be rejected if it had the same ratio as the primary amounts to 7% of all mail rejected by SpamAssassin and 14% of all mail addressed to unknown users. I think it s unlikely that any significant fraction of that would be due to spammers caching the server IP address for months after the DNS records were changed. So therefore it seems most likely that something between 7% and 14% of spam is specifically targetted at the secondary server. While the ratio of spam to ham seems significantly worse on the secondary it is still a relatively small portion of the overall spam sent to the service. I had been considering setting up secondary mail servers with extra-strict anti-spam measures but the small portion of the overall spam that is targetted in such a way indicates to me that it is not going to be worth the effort. Another thing that has occurred to me (which I have not yet had time to investigate) is the possibility that some spammers will send the same messages to all MX servers. If that happens then the ratio of spam to ham would increase every time the number of MX servers is increased. In that case it would make sense to minimise the number of MX servers to reduce the amount of CPU power devoted to runing SpamAssassin. Note that I have intentionally not given any numbers for the amount of mail received by the service as it is a commercial secret. Update: One thing I realised after publishing this post is that the secondary MX server is also the main server for mail sent between local users. While the number of users who send mail to other users on the service is probably a small portion of the overall traffic (it s not a really big ISP) it will make a difference to the ratios. Therefore the ratio of spam to ham would be even worse on the secondary MX (assuming for the sake of discussion that local users aren t spamming each other).

No, Debian folks, not our former DPL...:-) My, by far, favourite skipper in the greatest race around the world (alone on a 60-feet boat without assistance), the Vend e Globe, arrived last night. I mean Samantha Davies, 34 y.o. female british skipper, who finished 3rd (or 4th, depending on Marc Guillemot's arrival time), who illuminated these weeks with her videos and messages always full of positive attitude and happiness....which is certainly harder to do when surfing in the southern latitudes over 20 knots and thousands of miles away from any land. I recommend those of you who never went on the VG web site to just navigate around the videos and spot those sent by Sam, to understand. She made it with a 9-year old boat (that completes its third VG), keeping up with performance while preserving the boat (probably the one in the best condition after arrival). and all Vend e Globe fans will always remember her constant smile. All this explains why I have even more admiration for Sam's performance than I have for Michel Desjoyaux (the winner) or Armel Le Cl ac'h (2nd), both among the world's top skippers (along with Lo ck Peyron, imho). The race is not over, far from this. Eight skippers still have to arrive. Three of them (Marc Guillemot, Brian Thompson and Dee Caffari) will arrive on Monday or so, while Arnaud Boissi res and Steve White wtill need one or two weeks and Rich Wilson, Rapha l Dinelli and Norbert Sedlacek still are in the southern Atlantic ocean. And kudos also have to go to the 21 skippers who couldn't complete the race, certainly the most difficult Vend e Globe ever. I wish I would live close to Sables d'Olonne to have a chance to see a VG arrival some day. Great race, great adventure. Sad that it happes only every 4 years..:-)

From tomorrow, if you start seeing bugs or getting email about your packages where the version string ends in em[0-9], or where dependencies mentioned by reportbug include such a version suffix, the user is running one of the two Emdebian distributions to be released alongside lenny (and based on lenny packages). You might also see Emdebian in the output of 'apt-cache policy' if your bug reports request or supply such data.

If there is any doubt that the bug is present in Debian, please immediately re-assign the bug to the buildd.emdebian.org pseudo-package in the BTS.

I'll be posting to d-d-a with more information on the releases and the em1 version suffix - just as soon as Lenny itself is released.

A patch for reportbug is being tested and I'll file the bug probably tomorrow. A large proportion of the development work to actually get Emdebian to the point of two releases only happened after the lenny freeze began. (Not the recent deep freeze, the initial toolchain freeze before DebConf8). (reportbug itself is not currently part of Emdebian for a variety of reasons.)

Emdebian only uses a small subset of Debian packages, so this principally involves the core packages in Debian, GTK+2.0 and dependencies, XFCE and GPE as well as a small number of applications like iceweasel, sylpheed, xchat-gnome and grisbi.

The two Emdebian distributions will be:

Emdebian Grip 1.0 (lenny)

A small Debian-compatible Emdebian installation

Full release title:

    Emdebian GNU/Linux Grip 1.0 (based on Debian GNU/Linux 5.0 "lenny"). 

Short release name: 

    Emdebian Grip 1.0 (lenny)

Common release names:

    Emdebian Grip or Grip (lenny)

Architectures: i386, amd64, powerpc, arm, armel, mips and mipsel

Emdebian Grip explicitly supports mixing Debian and Emdebian and that is how a Debian package could end up depending on a package from Emdebian Grip - this is not expected to be a problem because Grip packages are binary-compatible with the Debian version, just with some files removed from the package. (i.e. Grip is post-processed, not recompiled.) Grip typically comes in at ~600Mb for a full XFCE desktop and uses the Lenny debian-installer images. (Grip base system ~250Mb.) I'm currently running Emdebian Grip on my Acer Aspire1.

More information: http://www.emdebian.org/grip/

Emdebian Crush 1.0 (lenny)

The smallest Emdebian installation - cross-built from Debian sources.

Full release title:

    Emdebian GNU/Linux Crush 1.0 (based on Debian GNU/Linux 5.0 "lenny"). 

Short release name:

    Emdebian Crush 1.0 (lenny)

Common release names:

    Emdebian Crush or Crush (lenny) 

Architectures: arm only 

More information: http://www.emdebian.org/crush/

Crush is the cross-built distribution from Emdebian - significant functional changes exist compared to the Debian package, libraries have been recompiled with options turned off and functionality removed etc. and Crush has dropped support for python or perl, and uses a modified, more recent version of busybox instead of coreutils. Crush is the hardest distribution to install, maintain and update and requires extensive customisation for particular machines with the benefit that it is an ultimately flexible Debian where the base system (equivalent to a debootstrap in Debian) can fit into 24Mb installed and a GPE GUI in 75Mb. uClibc support is expected in Crush 2.0 (squeeze), allowing sizes to shrink by another 10Mb or so. I'm currently running Emdebian Crush on my balloon3.

I was at this event back in November and they ve just emailed me this week to point out the speeches and some recordings are now available online. The appointed Regional Development Agency is getting more powerful as our indirectly-elected South West Regional Assembly is phased out, so if you re based in SW England, you may find their current views affect a lot of your daily life over the next few years. After the meeting, I passed on a few comments about how Business Link is failing to support cooperatives and I was asked for numbers, but I don t think I have them yet. I m still following this up and will post about it again later.

I recently received an email from Sigma Xi with various news items. One of them mentioned a Hawking quote:

Science fiction is useful both for stimulating the imagination and for diffusing fear of the future. -- Stephen Hawking?

Now, Sigma Xi is generally a pretty reputable organization, but I wondered: is a scientific organization really encouraging fear of the future? Mind, I think a certain degree of concern about the future is healthy, both individually and societally, and there is a long tradition in science fiction of writing novels about terrifying futures. But Sigma Xi is usually upbeat about the wonders of science and technological progress. Besides, there's a real dissonance in that quote between becoming more creating and imaginative, and becoming more afraid of the future. Maybe it was intentional, but it seems very out-of-place. So, I started to wonder whether this was really what Hawking said. Typing a few key words into Google, I looked at where else this quote showed up. According to the NSF, Sigma Xi's quote is correct.

According to renowned physicist Stephen Hawking, "science fiction is useful both for stimulating the imagination and for diffusing fear of the future." Interest in science fiction may affect the way people think about or relate to science...

ERIC, which is some sort of database of internal government reports, agrees:

According to renowned physicist Stephen Hawking, "science fiction is useful both for stimulating the imagination and for diffusing fear of the future." Indeed, several studies suggest that using science fiction movies as a teaching aid can improve both motivation and achievement.

So, maybe Hawking really does encourage being afraid of the future? Well, here was the third and final reference to this quote that I found, from (of all places) an unofficial transcript of a Larry King Live interview:

HAWKING: I think science fiction is useful, both for stimulating the imagination and for defusing fear of the future. But science fact can be even more amazing. Science fiction never suggested anything as strange as black holes.

So, it looks like this quote comes from a live TV interview. I don't know whether the different interpretations come from different transcripts (this is the only one I can find); defused and diffused are similar enough that it would be easy for either one to be reasonable -- and IIRC, he speaks through some sort of speech-generating machine, which would just make it easier to misunderstand him. But given that Hawking is a crazy-science-guy, I suspect that he would rather defuse fear of the future than spread it around (even if it became more diffuse as it was spread), and that the transcript above is what he meant to say. In which case, I wonder about the versions of the quote that I found everywhere else. Didn't anyone do a double-take when they were typing up those papers, Web pages and news items? Of course, there is a third possibility, which I rather like: the quote could be a play on words, a sort of slant pun (a phrase that I just invented, which is the funnier cousin of a slant rhyme). What's particularly cool about this particular ambiguity is that (a) both sentences are sensible, (b) they have related but opposite meanings, and (c) somewhat oddly, I agree with both of them: science fiction is good at defusing unwarranted fear of the future, while also diffusing fear where it's entirely warranted. I doubt Hawking was going for the double meaning, but it's a nice thought.

---

And for the inevitable people who can't figure out what this blog entry is about, here's a hint: diffuse:

Verb

1. (transitive) To spread over or through as in air, water, or other matter, especially by fluid motion or passive means.
2. (intransitive) To be spread over or through as in air, water, or other matter, especially by fluid motion or passive means.

defuse:

Verb

1. To remove the fuse from a bomb, etc.
2. To make something less dangerous, tense, or hostile.

So, Biella already posted a reminder, and I m doing it again on my blog, here.

Attention New York City Debianistas,
The astrological confluence of 1234567890[0], the impending release of
Lenny[1], and the odd sighting of a horned mythical beast that
cryptozoologists are calling a 'new FTP-master-assistant/slave' being
sighted in the mist off the shores of the East River[2] will result in
all emacs users to transcend and all vim users to be transponded to
their respective motherships, which are scheduled for near-orbit on that
night.
You will only be taken if you have a sip of beer on the 13th, before
6:31:30pm at the Pacific Standard[3]. 
If you come late, you may suffer nano for all eternity.
Micah
ps. All nano users will be Left Behind  to tend to the servers that we
did not bring with us on the Rapture  rickshaw. 
ps. lets keep the the post-apocalyptic space editor battle that will
erupt between the S.S. Church of Emacs, and the H.R.H VIMperator
mothership for later, and drink with revelry together now.
0.  date -d '@1234567890' 
1. http://lists.debian.org/debian-devel-announce/2009/02/msg00000.html
2. http://lists.debian.org/debian-devel-announce/2009/01/msg00004.html
3. http://www.pacificstandardbrooklyn.com

Don t be late, it s at 1234567890!

Not so long ago, I was lamenting to some Debian developer about how LONG it took for me to write stuff, of any quality at least. And aside from my own slowish pace, the academic publishing process is slow as molasses. The two together make for a deadly combo. This friend reminded me that Debian took a heck of a long time to release and at the time, this reminder actually made me feel a lot better. Well, after years of toiling, updating, bug squashing, and lots of lots of arguing, Lenny is coming out and those of us in NYC are celebrating. Though this has been circulated on the Debina-nyc list, it never hurts to circulate a little wider, especially for this event.

Attention New York City Debianistas, The astrological confluence of 1234567890[0], the impending release of
Lenny[1], and the odd sighting of a horned mythical beast that
cryptozoologists are calling a new FTP-master-assistant/slave being
sighted in the mist off the shores of the East River[2] will result in
all emacs users to transcend and all vim users to be transponded to
their respective motherships, which are scheduled for near-orbit on that
night. You will only be taken if you have a sip of beer on the 13th, before
6:31:30pm at the Pacific Standard[3]. If you come late, you may suffer nano for all eternity. Micah ps. All nano users will be Left Behind to tend to the servers that we
did not bring with us on the Rapture rickshaw. ps. lets keep the the post-apocalyptic space editor battle that will
erupt between the S.S. Church of Emacs, and the H.R.H VIMperator
mothership for later, and drink with revelry together now. 0. date -d @1234567890
1. http://lists.debian.org/debian-devel-announce/2009/02/msg00000.html
2. http://lists.debian.org/debian-devel-announce/2009/01/msg00004.html
3. http://www.pacificstandardbrooklyn.com

Not so long ago, I was lamenting to some Debian developer about how LONG it took for me to write stuff, of any quality at least. And aside from my own slowish pace, the academic publishing process is slow as molasses. The two together make for a deadly combo. This friend reminded me that Debian took a heck of a long time to release and at the time, this reminder actually made me feel a lot better. Well, after years of toiling, updating, bug squashing, and lots of lots of arguing, Lenny is coming out and those of us in NYC are celebrating. Though this has been circulated on the Debina-nyc list, it never hurts to circulate a little wider, especially for this event.

Attention New York City Debianistas, The astrological confluence of 1234567890[0], the impending release of
Lenny[1], and the odd sighting of a horned mythical beast that
cryptozoologists are calling a new FTP-master-assistant/slave being
sighted in the mist off the shores of the East River[2] will result in
all emacs users to transcend and all vim users to be transponded to
their respective motherships, which are scheduled for near-orbit on that
night. You will only be taken if you have a sip of beer on the 13th, before
6:31:30pm at the Pacific Standard[3]. If you come late, you may suffer nano for all eternity. Micah ps. All nano users will be Left Behind to tend to the servers that we
did not bring with us on the Rapture rickshaw. ps. lets keep the the post-apocalyptic space editor battle that will
erupt between the S.S. Church of Emacs, and the H.R.H VIMperator
mothership for later, and drink with revelry together now. 0. date -d @1234567890
1. http://lists.debian.org/debian-devel-announce/2009/02/msg00000.html
2. http://lists.debian.org/debian-devel-announce/2009/01/msg00004.html
3. http://www.pacificstandardbrooklyn.com

I use Google Reader to manage most of the sites that I regularly read. Today it occurred to me that it would be very useful to have some functionality whereby feeds in a common folder could be read in one aggregated display, a bit like how planetplanet works. I then learned that Google Reader does exactly that already: It's fairly obvious to use in the normal reader, a little bit more subtle in the mobile version (you must click the folder once to load it up in a new page, then click it again to see the aggregated contents). That prompted me to try and tidy up my subscriptions and sort them in a way that took advantage of this feature. Deciding that the Google Reader interface was too primitive to properly organise all of my subscriptions (there are about 100 or so of them), I exported my subscriptions as OPML and imported them into liferea. I then dutifully pruned the list and sorted the remainder into a heirarchy of folders. In most cases I categorised things according to their topic: e.g., "computing", "friends", etc.; with two important exceptions: feeds that I track for debugging purposes but don't actually read (such as my own weblog) I put in a folder "don't read". Feeds that I have decided I need to read every post to (and there are very few of those) I moved into a top-level folder called "essential". I note that liferea 1.4.18 at least does not support the planet-style aggregation feature for folders that Google Reader does. On re-importing to Google Reader, I discovered another facet of it's behaviour that I'd neglected to pay attention to: it does not support heirarchical folders. (How could I use this software for so long and not really understand how it works?) In fact, folders are more like tags, with feeds existing in multiple folders. To make matters even more confusing, there is an entirely separate notion of tags, which applies to items inside subscriptions. Regarding the concept of an "essential" list. If you cut down your firehose consumption to just feeds which met the "essential" criteria, would you find yourself short on information, or just short on noise? Sometimes I read a book that for one reason or another (perhaps just one: excellent writing?) I cannot put down. I utterly devour the book and finish it much more quickly than average. Wouldn't it be nice if other information could be consumed so vociforously? When trying to read things such as academic papers or bid proposals, someone unused to them may find them very hard going. Someone with more practise might managed to "read" such a document much more quickly. Perhaps there is a point to all the firehose noise: maybe we need long immersion in the culture or context to train ourselves up so we can optimally consume the good stuff?

It's been announced at quite a few places, so you probably already heard about it: Miro 2.0, the new major release of the cross-platform Internet RSS audio/video aggregator and player has been released. Miro is available for Linux, Windows, and Mac OS X, the new release on Linux now features a "native" GTK+ widgets UI (instead of the Mozilla-based HTML widgets of earlier versions) and supports both a xine, as well as gstreamer renderer (for audio and video). I won't even attempt to list all the improvements and new features, please check the release notes and the feature list for details. Overall more than 670 issues have been fixed since the last 1.2.x series release. You can also watch this video (Ogg Theora, 10 MB) for a short introduction in Miro 2.0. Together with the software release, the getmiro.com website, as well as the online Miro Guide have been competely rewritten and are a lot more usable and better-looking than before. Finally, I have uploaded a new Miro 2.0 Debian package to unstable yesterday, by now it should be available from most mirrors. For Debian we're defaulting to xine at the moment, but please consult README.Debian if you want to switch to the gstreamer backend. Please test the new release extensively so the few remaining issues (if any) can be ironed out soon...

This takes the cake as most ludicrious hacker representation .. It is like Blue Man Group, gone arctic and hackish at the same time.

This takes the cake as most ludicrious hacker representation .. It is like Blue Man Group, gone arctic and hackish at the same time.

Getting started with a Free Software project and making it available to the community can be confusing for first-time software authors. However there are a couple of things worth knowing that will help you attract more users and increase the likelihood that your software will be part of a Free Software distribution like Debian.
Idea, Name and LicenseAt the core, a Free Software project starts with an idea. It's the reason why you wrote the software in the first place. Where this becomes interesting is when your think that your software could be useful to others. That's when you should think about sharing your code.

Of course, one of the very first decisions you'll need to make is to name your project. This is of course a very personal decision, but if you're struggling to find something exciting and trendy, consider choosing something that:

• is not already used,
• is easy to remember and
• gives an idea of what the project is about.

Another choice you will need to make before your first release is the license. While that topic may not be familiar or interesting to you, I highly recommend that you carefully consider your options since your license choice can influence the type of community that will form around your project.
Public ReleaseMaking your project publicly available can be as simple as dropping a tarball on a mailing list. However, if you want your project to reach all of the users for which it could be useful, there are a few other things you might want to do.

One of these things is to provide a digital home for your project. That homepage should provide access to all of the services related to your project. Such services usually include source control, bug tracking, mailing list and file areas. I've got some ideas about what that homepage should contain later but first things first, let's look at what that tarball should contain.
Tarball ContentsMost people downloading your source code will either be end-users or
distribution maintainers. Here's what they will be looking for:

• Complete source code along with the data files (if any) necessary to use your software.


• Installation instructions explaining how to compile and install your project on one of the supported platforms. This file is usually called INSTALL.


• Quick instructions on how to get started. This is usually contained in the README and it should provide new users all of the commands or instructions they need to get going within a minute or two.


• Full copy of the licensing terms, usually in a file named COPYING.


• Contact information for help or contributions. Small projects will often share the email address of the main author and a link to the project homepage if available. This is traditionally located in a file called AUTHORS or in the README directly.

This is pretty much the minimum that you need to provide in order for your code release to be useful to others and to be legally distributed by others. There are a few more things that you should think about if you would like to increase the likelihood that your software will be included in a Free Software distribution.

After putting all of this together, you should be ready for the initial public release of your project and will now be moving to the next phase: supporting your growing community.

In the next 11 months, I will be spending a significant amount of brain power and time writing a fairly long review article on digital media and ethnography which will assess the state of the literature and various trends. Since my expertise certainly lies in the west or global questions. I will be immersing myself in the literature that looks at various international, national, and regional contexts, which is exciting. It is nice to leave the well trodden path and venture into new lands. There is a handy new site related to this topic, which some of you might be interested in: New Media Practices in International Contexts Blog Series. The entries are less blog-like and more article-like but that is was makes them great resources.

In the next 11 months, I will be spending a significant amount of brain power and time writing a fairly long review article on digital media and ethnography which will assess the state of the literature and various trends. Since my expertise certainly lies in the west or global questions. I will be immersing myself in the literature that looks at various international, national, and regional contexts, which is exciting. It is nice to leave the well trodden path and venture into new lands. There is a handy new site related to this topic, which some of you might be interested in: New Media Practices in International Contexts Blog Series. The entries are less blog-like and more article-like but that is was makes them great resources.

We recently bought a Canon Vixia HG20 camcorder. The HG20 records in AVCHD format (MPEG-4 h.264) at up to 1920 1080. To get from the camcorder to a DVD (or something we can upload to the web), I need some sort of video editing software. This lets me trim out the boring bits, encode the video for DVD, etc. Background In addition to DVD creation and web uploading, I want the ability to burn high-definition video discs. 1920 1080 is significantly higher resolution than you get from a DVD. There are two main ways to go: a blu-ray format disc, or an AVCHD disc. A blu-ray disc has to be burned onto BD-R media, which costs about $5 each, using a blu-ray burner, which costs about $200. AVCHD discs use the same h.264 encoding that the camcorder does, meaning they have better compression and can be burned onto regular DVD+R media, fitting about 30 minutes onto a DVD. Moreover, it is possible to move AVCHD files directly from a camcorder to an AVCHD disc without re-encoding, resulting in higher quality and lower playing time. The nicer blu-ray players, such as the PS3, can play AVCHD discs. AVCHD seems pretty clearly the direction the industry is moving. Compared to the tape-based HDV, ACVHD has higher quality with lower bitrates, better resolution, and much greater convenience. Hard disk or SD-based AVCHD camcorders are pretty competitive in terms of price by now too, often cheaper than tape-based ones. The downside of AVCHD is that it takes more CPU power to process. Though as video tasks are often done in batch, that wouldn t have to be a huge downside. The bigger problem is that, though all the major video editing software claims to support AVCHD, nobody really supports it well yet. The Contenders Back when I got my first camcorder in about 2001 the one that I m replacing now you pretty much had to have a Mac to do any sort of reasonable consumer or prosumer-level video editing. We bought our first iMac back then to work with that, and it did work well with the MiniDV camera. Today, there s a lot more competition out there. The Mac software stack has not really maintained its lead some would even say that it s regressed and the extremely high cost of buying a Mac capable of working with AVCHD, plus Final Cut Express, makes that option completely out of the question for me. It would be roughly $2500. Nobody really supports AVCHD well yet, even on the Mac. Although most programs advertise support of smart rendering a technique that lets the software merely copy unchanged footage when outputting to the same format as the input none of them have smart rendering that actually works with AVCHD source material. Though this fact is never documented, though discussed on forums. Another annoyance, having used Final Cut Express in the past, is that with these programs you can t just go to the timeline and say delete everything between 1:35 and 3:52 ; you have to go in and split up clips, then select and delete them. They seem to be way too concerned about dealing with individual clips. I briefly used Cinelerra on Linux to do some video editing. It s a very powerful program, but geared at people that are far more immersed in video editing than I. For my needs, it didn t have enough automation and crashed too much and that was with MiniDV footage. It apparently does support AVCHD, but I haven t tried it. I ve tried three programs and considered trying a fourth. Here are my experiences: Ulead/Corel VideoStudio Pro X2 Commonly referenced as the go to program for video editing on Windows, I started with downloading the Free Trial of it from Corel. Corel claims that the free trial is full-featured all over on their website, but I could tell almost instantly that it wasn t. I wound up buying the full version, which came to about $65 after various discounts. I wanted to like this program. Its output options include AVCHD disc, Blu-ray disc, DVD+R, and the like. Its input options include MiniDV, AVCHD, ripping from DVD, ripping from Bluray, and just about every other format you can think of. And it heavily advertised proxy editing , designed to let you edit a scaled-down version of AVCHD video with a low-CPU machine, but refer back to the original high-quality footage for the output. It didn t pan out that way. The biggest problem was the constant crashing. I really do mean constant. It probably crashed on me two dozen times in an hour. If you are thinking that means that it crashes pretty much as soon as I can get it re-opened, you d be correct. Click the Play button and it hangs. Click a clip and it hangs. Do anything and it hangs. It did seem to work better with the parts of the source that had been converted to a low-res version with Smart Proxy, though it didn t eliminate the hangs, just reduced them. And every time I d have to End Task, it would forget what it had already converted via Smart Proxy even if I had recently saved the project and have to start over from scratch. I spent some time trying to figure out why it always thought my project was 720 480 even when it was 1920 1080, and why the project properties box didn t even have an option for 1920 1080. After some forum searching, it turns out that the project properties box is totally irrelevant to the program. Yay for good design, anyone? VideoStudio Pro X2 does have good output options, allowing combination of multiple source files onto a single DVD or AVCHD disc as separate titles. Unfortunately, its DVD/AVCHD rendering process also yes hangs more often than not. The documentation for VideoStudio Pro X2 is of the useless variety. It s the sort of thing that feels like it s saying The trim tool is for trimming your clips without telling you what trimming your clips means, or making it obvious how to remove material from the middle of a clip. The proxy editing feature isn t what it should be either. Instead of being something that just automatically happens and Works in the background, you have to manage its queue in the foreground and it forgets what it was doing whenever the program hangs. On the rare occasion when pressing Play did not cause a hang, the AVCHD footage played back at about 0.5fps far, far worse than PowerDirector manages on the same machine. Bits that had been rendered for proxy editing did appear to play at full framerate. I have applied for a refund for this purchase from Corel under their 30-day return policy, and have already uninstalled it from my disk. What a waste. CyberLink PowerDirector 7 Ultra This was the second program I tried, and the one I eventually bought. Its feature set is not quite as nice as Corel s, especially when it comes to versatility of output options. On the other hand, it feels done. It only crashed two or three times on me apparently that s GOOD on Windows? Things just worked. It appears to have proxy editing support, but it is completely transparent and plays back with a decent framerate even without it. It can output to AVCHD, Bluray, and DVD, though smart rendering doesn t work with AVCHD source material. Its weakness compared to the Corel package is that it doesn t have as many options for formatting these discs. You can have only one title on a disc, though you can have many chapters. You have some, but not much, control over compression parameters. The same goes for exporting files for upload to the web or saving on your disk. The documentation is polished and useful for the basics, though not extensive. Overall, this package works, supports all the basics I wanted from it, so I m using it for now. Adobe Premiere Elements 7 I downloaded the trial of this one too. I opened it up, and up popped a dialog box asking what resolution my project would be, interlacing settings, etc. I thought YES now that s the kind of program I want. As I tried out the interface, I kept thinking the same. This was a program not just for newbies, but for people that wanted a bit more control. Until it came to the question of output. Premiere Elements 7 was the only package I looked at that had no option to burn an AVCHD disc. DVD or Blu-ray only. That s a deal-breaker for me. There s no excuse for a program in this price range to not support the only affordable HD disc option out there. So I didn t investigate very much farther. Another annoying thing is that Adobe seems to treat all of their software as a commercial. I m a user, not an audience, dammit. I do not want to buy some photoshop.net subscription when I buy a video editing program. I do not want to see ads for stuff when I m reading PDFs. LEAVE ME ALONE, ADOBE. I just felt sleazy even giving them my email address, let alone installing the program on my system. I think I will feel like a better person once I reboot into Windows and wipe it off my system. Pinnacle Studio 12 Another program that comes highly rated. But I never installed it because its minimum system requirements state that it needs an Intel Core 2 Quad 2.66GHz or higher for 1920 1080 AVCHD editing. And I have only a Core 2 Duo 2.66GHz half the computing horsepower that it wants. And since they offer no free trial, I didn t bother even trying it, especially since PowerDirector got by fine with my CPU. Conclusions This seems to be a field where we can say all video editing software sucks; some just suck a little less. I m using PowerDirector for now, but all of the above programs should have new versions coming out this year, and I will be keeping a close eye to see if any of them stop being so bad.

From my sigfile:

> There really is no substitute for brute force.
Indeed - I must admit to being a disciple of blessed Saint Makita myself.
        -- Robert Sneddon and Tanuki, in the Monastery

Over the last couple of weeks, I've been teaching myself Erlang by solving the problems over at Project Euler. They're interesting problems, require a bit of math knowledge and logical reasoning (my skills in both have been getting rusty anyway), along with just enough coding on each problem to make it interesting. One of the things that I've found, though, is that algorithmic elegance is required far less often than I had expected. In several cases, I've sat down with the problem and gone, "well, I can brute-force it like this, (clickety click), but I'll bet it'll take forever to run. I'll set that going while I think about a bett... oh, it's done already." Part of this is that I've got a nice shiny-fast computer, and I'm writing the sort of code that Erlang does well at (and using it's sexy-powerful concurrent programming features to hammer away at all my CPU cores, with practically no extra coding effort on my part), but primarily the problem is that I don't have that good a "feel" for how long something's going to actually take to run. I suspect I'm not the only one, and that it's not something that experience is going to completely solve. My take away lesson from all this (apart from a working knowledge of the basics of Erlang), is one that has been said a million times before, but is so easily forgotten in the excitement of coding: premature optimisation is the root of all evil. In other words, first make it work, then make it fast.