Fall semester I did not teach any classes that covered digital media (in part because I was swimming in the stuff writing a review essay on the topic, which I am sending today to the journal, ending about 4 months of hell). On the other hand, spring semester will be all about digital media: hackers, free software, privacy, piracy, phone phreaking and more. I am excited. Here is my graduate syllabus on the commons and piracy and here is my undergraduate class on hacking. Both are still under development but pretty far along.

Fall semester I did not teach any classes that covered digital media (in part because I was swimming in the stuff writing a review essay on the topic, which I am sending today to the journal, ending about 4 months of hell). On the other hand, spring semester will be all about digital media: hackers, free software, privacy, piracy, phone phreaking and more. I am excited. Here is my graduate syllabus on the commons and piracy and here is my undergraduate class on hacking. Both are still under development but pretty far along.

If you ever tried to determine what patches other distributions apply to some package you are interested in, you might have come to the same conclusion as I: It is quite an impudence how those are presented. If you don't give up, you end up with programs or scripts to extract many propietary source package formats, more VCS systems installed than you think there should exist. Thats when you start to love the concept that every Debian mirror has next to each binary package the source in a format that you can extract the changes easily with only tools you find on every unixoid. And that's why I love the new (though in my eyes quite misnamed) "3.0 (quilt)" format, because that makes it even clearer and easier. Sadly one problem remained: How to generate and store those patches? While you can just use patches manually or use quilt to handle those patches and store the result in a vcs of your choice, the newfangled VCSes (especially git) became quite good at managing, moving and merging changes around, so it seems quite a waste to not be able to use this also to handle those patches easily. While one can either use git to handle a patchset, by storing it as a chain of commits and using the interactive rebase, or using git to store the history of your package, doing both at the same time is tricky and not resonably doable with git provided porcelain. Thus I wrote my own tool to faciliate git for both tasks at the same time. The idea is to have three branches: a branch storing the history of the your package, a branch storing your patches in a way suitable to submit them upstream or to create a debian/patches/ directory from, and an branch with the upstream contents. I've an implemenation which seems to already work, though I am sure there is still much to improve and many errors and pitfalls still to find. Thus if you also like to experiment with handling patches of a debian package in git, take a look at the manpage or the program at git://git.debian.org/~brlink/git-dpm.git
(WARNING: as stated above: alpha quality; also places are temporary and are likely to change in the future).

With the help of a couple of friends, we ve put a 4.5T RAID-5 machine on our network and I m trying to figure out how to share the storage with the rest of the hosts. In the past, I have used NFS and CIFS/Samba to provide access to remote hosts. This has generally worked okay so long as the server stays online. I don t know if the results are going to be much different, but I am now trying a different approach. I plan to run an iSCSI server, and I ve already configured AoE (ATA over Ethernet). I ve exported a block device on the network segment and mounted it on a remote host. This was pretty easy to configure. There is a bit of documentation on the internet already, but I ll give another quick overview. I gave the storage server the unoriginal name san0 . This host is running debian lenny. I am testing the configuration from my debian sid development host, which has the similarly unoriginal name dev0 . So, think server when you see san0 and client when you see dev0 . I assume that you ve already got an LVM volume group set up. Mine is called vg0 . Correct the following examples to account for any differences. You can use disk partitions instead of LVM logical volumes.

---

Create a logical volume to be exported: cjac@san0:~$ sudo lvcreate /dev/vg0 -n e0.1 -L 5G Load the AoE kernel module: cjac@san0:~$ sudo modprobe aoe Install the package containing the vblade block device export server: cjac@san0:~$ sudo apt-get install vblade Export the block device. Note that the ethernet bridge on which I export the device is called loc : cjac@san0:~$ sudo vbladed 0 1 loc /dev/vg0/e0.1 Install the AoE discovery tools on the client: cjac@dev0:~$ sudo apt-get install aoetools Load the AoE kernel module: cjac@dev0:~$ sudo modprobe aoe Probe for exported AoE devices: cjac@dev0:~$ sudo aoe-discover Verify that our exported device was discovered: cjac@dev0:~$ test -e /dev/etherd/e0.1 && echo "yep"
yep

---

You can now treat /dev/etherd/e0.1 as you would any other block device. You can format it directly, or partition it and format a partition, use it as a device in your software RAID array, use it as swap space (ha), or something completely different. Now to figure out this iSCSI stuff

Yes, aptitude can list packages by priority, but what I wanted was a simple list of just package names. I've got two ways of getting a bare list:

Updated with many thanks to Phil Hands.

$ aptitude search '~prequired' sed -ne 's/^i [ A] \([^ ]*\).*$/\1/p' tr '\n' ' ' sort -u fold -s ; echo

#!/bin/sh
# Licence: GPL-3+
FILE= find /var/lib/apt/lists/ -name '*unstable*Packages'
LIST= grep-dctrl -n -s Priority '' $FILE sort -u

for P in $LIST; do
[ "optional" != "$P" -a "extra" != "$P" ] continue
echo "Priority: $P"
grep-dctrl -n -s Package,Priority "$P" $FILE sed -ne '/^'$P'$/!h;/^'$P'$/ g;p ' tr '\n' ' ' fold -s
echo
done

The advantage with the script is that is lists all packages in all priorities except optional and extra and can be restricted to individual Packages files and therefore to individual repositories and components. (Change the find expression if you have more than one repository specifying unstable or adapt the script to accept a path to the relevant Packages file on the command line.)

I really ought to have used perl because pattern matching in perl is a
lot more natural to me than using sed or awk. I do tend to chain a
couple of sed commands, just so that it's easier to work out which bit
is broken when it breaks.

The final version of this script will end up in emdebian-grip-server,
converted to perl with POD content, translated and reading the Packages
files using Debian::Packages::Compare.

$ ~/scripts/list-priority
Priority: important
adduser apt-utils apt aptitude bsdmainutils libbz2-1.0 cpio cron libcwidget3
debian-archive-keyring dhcp3-client dhcp3-common dmidecode ed libgdbm3 gnupg
gpgv groff-base ifupdown iproute iptables iputils-ping logrotate libept0
libsigc++-2.0-0c2a libtasn1-3 libusb-0.1-4 man-db manpages module-init-tools
nano libncursesw5 net-tools netbase netcat-traditional libnewt0.52 whiptail
libssl0.9.8 libpopt0 libreadline5 libreadline6 readline-common rsyslog
tasksel-data tasksel libwrap0 info install-info traceroute udev vim-common
vim-tiny wget libxapian15
Priority: required
libacl1 libattr1 base-files base-passwd bash coreutils debconf-i18n debconf
debianutils diffutils dpkg e2fslibs e2fsprogs libcomerr2 libss2 libc-bin libc6
findutils gcc-4.3-base gcc-4.4-base libgcc1 libstdc++6 grep gzip hostname
lsb-base libdevmapper1.02.1 lzma liblocale-gettext-perl libselinux1 libsepol1
libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libunwind7 mawk
libncurses5 ncurses-base ncurses-bin libpam-modules libpam-runtime libpam0g
perl-base procps sed sensible-utils login passwd libslang2 initscripts sysv-rc
sysvinit-utils sysvinit tar tzdata bsdutils libblkid1 libuuid1 mount util-linux
zlib1g
Priority: standard
apt-listchanges at bash-completion bc dc bind9-host dnsutils libbind9-50
libdns53 libisc50 liblwres50 bsd-mailx libsasl2-2 libdb4.8 libdb4.5 libdb4.6
libdb4.7 debian-faq doc-debian doc-linux-text libc6-i386 locales exim4-base
exim4-config exim4-daemon-light exim4 file libmagic1 gettext-base libgnutls26
libgpm2 libkeyutils1 libgssapi-krb5-2 libgssrpc4 libk5crypto3 libkadm5clnt6
libkadm5srv6 libkdb5-4 libkrb5-3 libkrb5support0 less lsof libcap2 libedit2
libevent-1.4-2 libgc1c2 libgcrypt11 libgpg-error0 libgssglue1 libidn11
liblockfile1 libnfsidmap2 librpcsecgss3 libunwind7-dev libxml2 m4 mime-support
mlocate mutt ncurses-term ftp telnet nfs-common libldap-2.4-2 openssh-client
patch libpci3 pciutils libpcre3 perl-modules perl portmap procmail
python-central python-minimal python python2.5-minimal python2.5
python-reportbug reportbug wamerican libsqlite3-0 tcpd texinfo time ucf w3m
whois

Hmm, next step is to check the "Priority: standard" set for Emdebian - it looks far too large for what would be standard on an embedded device. LDAP will be dropped for one - and what is a -dev package doing in there? libunwind7-dev isn't even installed on my amd64 Debian desktop!

Probably check the important and required listings too, then tweak what we need to change via the archive overrides for Emdebian Grip.

Come to think of it, I might need a PHP version of this to read live data from the repository, documenting the changes.

Since about a week, I have a Nokia N900. They're not actually on sale in Belgium yet, but I managed to get hold of one through a grey market shop. The device is quite nice. I do have a few irks with the interface here and there, but Nokia has a public bugzilla that I'll surely use to file bugs whenever and wherever appropriate. And after using it for about a week, I thought of migrating this small application which I once wrote on half an afternoon using perl, postgres, and Gtk2, to the device. It's mainly a cataloguing system that I store my DVD collection in (which has gotten large enough that this is necessary), nothing earthshattering. The ideal candidate to get my feet wet in developing for the N900, so to speak. That effort got stopped dead in its tracks pretty quickly.

Nokia-N900-42-11:~# perl
use Gtk2;
Can't locate Gtk2.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.3 /usr/local/share/perl/5.8.3 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at - line 1.
BEGIN failed--compilation aborted at - line 1.
Nokia-N900-42-11:~# apt-cache search perl
perl - Larry Wall's Practical Extraction and Report Language.
libpcrecpp0 - Perl 5 Compatible Regular Expression Library - C++ runtime files
po4a - tools for helping translation of documentation
libpcre3 - Perl 5 Compatible Regular Expression Library - runtime files
libgdbm3 - GNU dbm database routines (runtime version)
perl-base - The Pathologically Eclectic Rubbish Lister.
liblocale-gettext-perl - Using libc functions for internationalization in Perl

Or, in other words: they only ship the perl bits needed to make dpkg run. Hrmpf. This would make stuff slightly more... involved. Oh well.

Time away from work and its been either raining or hot. So I've updated and released some software. It always seems to happen there is a lot of Free Software development during the breaks.

psmisc got a bunch of updates, including a new program called prtstat which formats the stat file in the procfs for a pid in (hopefully) a nice way. No sooner had I released the latest update when a bug report came in. It seems fuser -m -k is a little too happy about killing itself. The fix is in the CVS but anoying I missed that.

Next up was the Debian gw6c package. I was asked why it didn't get moved from unstable to testing. The problem is that while Linux has iproute, kfreebsd does not so the lack of a dependency was stopping it transitioning. To make matters worse the freebsd template was missing from their package. After some deb-substvars evilness to fix the dependencies and some dh_install overrides in the debian/rules file it should all be happy when its finished.

Finally, I miss having good random playlists. I'm too lazy to make them myself so I use some random thing which often gives me rubbish. A program called Gjay used to be in the Debian archive but got removed, mainly because the upstream stopped supporting it. I can write C (the programming language its written in) and I wanted to use it, so I fixed it. My version is 64-bit clean, so it works on my amd64 and it works with audacious not the old xmms which is great. More importantly, it compiles, it runs and it even works properly.
I'm just wondering if I want to release it out to the wider world or not.

Enigma is a great game, with a unique mixture of puzzles with mouse skills and action. If you know the discontinued game Oxyd originally on the Atari ST in the 90s (also on Amiga and one version on DOS), then you know the principle of Enigma. Except that it has tons of more levels and is Open Source.Some weeks ago, I uploaded a 1.10 pre-release (approximately milestone 5) to Debian experimental. This is the soon-to-be-released new version, using a new level file format (with a much extended API to make level development even easier, ~50% less code per level now), new levels (of course), updated graphics (including support for new graphics modes), ...Unstable still contains version 1.01; the reason is simple that I knew there would be another 1.01 maintainance release coming. However I believe it doesn't offer much against the current unstable version; it largely marks an upstream release containing patches already in the Debian package (since communication with upstream is really good).So I have now two choices: refreshing the Debian unstable package to the "probably last" 1.01 release upstream, or going straight for the 1.10 milestones to give enigma some extra testing.

Everyone seems to be familiar with ebooks these days. I own a Kindle 2, and of course we ve spent weeks hearing how great the Nook will be, then weeks hearing how terrible it turned out to be. But nobody seems to be casting an eye back towards paper, so I thought I d rectify that here, especially since paper books have some serious stability issues that are often overlooked! Before I begin, I feel it wise to offer this hint to the reader: this review should not be taken too literally. If you have an uncontrollable urge to heave a volume of the Oxford English Dictionary at me as if I am some European prime minister, please plant your tongue more firmly in your cheek and begin again. Today I picked up a paper book to read just for fun The Happiest Days of Our Lives by Wil Wheaton. Long-time (since this spring!) Kindle user that I am, I immediately noticed the dashing use of color on its front cover, but when I opened it, I was disappointed that I couldn t scale the font size down from the default. It seems that paper books have only one font option what are all these Kindle forum posters complaining about with its six sizes of a single font? On the very first page, I encountered a word I wasn t familiar with (Namaste). I thought I knew what it meant from the context clues, and even had the thought that on the Kindle, I could just highlight it and confirm my guess. But my paper dictionary was in the basement, so I didn t bother looking it up until I wrote this post. (My hunch was reasonably correct.) Interface-wise, the paper book is solid, and crashes, lockups, or other malfunctions are rare. I have, however, noted severe stability problems when attempting to read outdoors, especially when it s windy (which, since I live in Kansas, is pretty much always). Pages start turning themselves, even without me making the turn page gesture. Sometimes the book will even lose its memory of my last page read. This is rather annoying, and might even involve a lengthy search for a suitable temporary replacement bookmark. Also, I haven t tried it, but I suspect that the trick of putting a Kindle in a ziplock bag to read at the beach or in the tub without risk of getting it wet would be impractical with a paper book. Paper does have its advantages. For one, it s faster to flip rapidly through pages on paper than on an ebook reader. If you know roughly where in the book something was written, but not the precise wording, searching can be faster on paper. On the other had, if you are looking for a particular word or phrase, the ebook reader may win hands-down, especially if the paper book has no index. Paper is so stable that some would argue that the extreme impracticality of making good backups isn t really a problem at all. But on the other hand, paper books degrade slightly each time they are used, and this condition can be aggravated by placement in bags for transport. Eventually, they will wear out. If my Kindle wears out, I can always restore David Copperfield from my backup copy to a new one. If my printed edition (all two volumes) of it wear out, then I have to hope that the used bookstore will still sell me another one for $10. Otherwise I d have to either drive 45 miles to find one for sale, attempt to deal with the DRM for paper books at a library, or wait a couple of days for Amazon to get it to my door. A fire or flood could be devastating. Paper books also have some advantages for showing photos; no ebook reader is close to the size and resolution of glossy paper photos books in a reasonable price. The contrast on most paper books is better than that of my Kindle, but some older ones are actually worse, smell dusty, and suffer from occasional display corruption as bits of them actually break off of the book device. As to cost, it is a mixed bag. Out of copyright classics are free as ebooks from Project Gutenberg and the like, while still costing money on paper. I have found that the accuracy of some of these paper editions can be rather questionable people have sometimes manually removed important bits of the story to save on printing costs, rather than let Google Books OCR mangle it for them automatically. On the other hand, used paper editions of more current works can be found for a fraction of the cost of the new ebook edition though you are often limited in selection of these bargains. But you can usually browse a paper book for a few minutes before buying it, which is rarely available for an ebook. What s more, libraries might let you borrow paper books for free. But you often have to expel greenhouse gases to get to them, and then they enforce DRM on you you only get to read it a certain amount of time before they start adding fees. You could easily wind up paying $2 if you keep it a week longer than you should have. With ebooks, of course, there is no free borrowing (and the Nook feature it too limited to count.) And you of course know that most libraries are run by the government, so they have your address. Trying to circumvent a library s DRM could wind up involving the police, so you had best comply. Making copies of a paper book is expensive and requires specialized equipment, even if you just want a copy for backup. Compatibility problems with paper books are rare, and are usually found among readers with poor eyesight. A few works can be found in large font editions, but most can t, so those readers are left needing expensive specialty magnifiers. All in all, I prefer reading books on my Kindle, but still read on paper when that s how I have a book.

According to the man page, there are three ways to exclude files from being tracked by git.

Shared list of files to ignore The most well-known way of preventing files from being part of a git branch is to add such files in .gitignore. (This is analogous to CVS' .cvsignore files.)

Here's an example:

*.generated.html
/config.php

The above ignore list will prevent automatically generated HTML files from being committed by mistake to the repository. Because this is useful to all developers on the project, .gitignore is a good place for this.

The next line prevents the local configuration file from being tracked by git, something else that all developers will want to have.

One thing to note here is the use of a leading slash character with config.php. This is to specifically match the config file in the same directory as the .gitignore file (in this case, the root directory of the repository) but no other. Without this slash, the following files would also be ignored by git:

/app/config.php
/plugins/address/config.php
/module/config.php

Local list (specific to one project)For those custom files that you don't want version controlled but that others probably don't have or don't want to automatically ignore, git provides a second facility: .git/info/exclude

It works the same way as .gitignore but be aware that this list is only stored locally and only applies to the repository in which it lives.

(I can't think of a good example for when you'd want to use this one because I don't really use it. Feel free to leave a comment if you do use it though, I'm curious to know what others do with it.)

Local list (common to all projects)Should you wish to automatically ignore file patterns in all of your projects, you will need to use the third gitignore method: core.excludesfile

Put this line in your ~/.gitconfig:

[core]
excludesfile = /home/username/.gitexcludes

(you need to put the absolute path to your home directory, ~/ will not work here unless you use git 1.6.6 or later)

and then put the patterns to ignore in ~/.gitexcludes. For example, this will ignore the automatic backups made by emacs when you save a file:

*~

This is the ideal place to put anything that is generated by your development tools and that doesn't need to appear in your project repositories.

After a while playing around with the build system, with python 3.1 (which is required), etc., I finally got around to upload a Blender package for 2.50 alpha 0, just uploaded to experimental (hopefully) given python 3.1 is only available there. Potential users really want to read the NEWS file. One can also check the upstream release logs. For those wondering about the version number, it had to be >= 2.49, and upstream doesn t seem to be sure about the versioning, since it can be 2.5 on the website, 2.50 as SVN tag, etc. I m not going to introduce an epoch right now. ;) It certainly has some rough edges, but testing and reporting are more than welcome.

I usally find blog rants useless, but sometimes something is just so annoying one is sufficiently inspired. Today I went with my parents to buy them a Tivo at Harvey Norman, Norwest, Castle Hill, NSW, Australia. I am a big Tivo fan; the interface is good and it "just works". I don't mind paying for (or in this recommending paying for) good products. After selecting the Tivo model, I asked for a HDMI cable. The salesman made a series of questions about what sort of HD TV it was being plugged into; I quickly sensed this as a probe to see what sort of suckers we were, and requested just a "normal" cable. At this point, he insisted on a $130 (you guessed it) Monster cable, and had the audacity to say that we didn't need one of the really expensive cables because our TV wasn't good enough! I openly expressed my concern, but the annoying high-pressure sales pitch had just begun. The amount of, frankly, crap that he spewed about 4-bit this, 10-bit that, legislating of labels, DA signal levels, mythical customers who regretted buying the cheap cables and who knows what else was to the point of being comical if it weren't so insistent and said with such seeming authority. There is only one thing that matters - if the cable has passed the functional requirements for being certified to have the distinctive HDMI logo plastered on it. From the HDMI FAQ:

Q. What testing is required? Prior to mass producing or distributing any Licensed Product or component that claims compliance with the HDMI Specification (or allowing someone else to do such activities), each Adopter must test a representative sample for HDMI compliance. First, the Adopter must self test as specified in the then-current HDMI Compliance Test Specification. The HDMI Compliance Test Specification provides a suite of testing procedures, and establishes certain minimum requirements specifying how each HDMI Adopter should test Licensed Products for conformance to the HDMI Specification.

Now, I can understand that if you buy any old HDMI cable off Ebay for $1, it may be a knock-off that uses the HDMI logo illegally. But there is no way that the certified $50 Philips cable (still very over-priced, but at least not insane, and discounted to $35) performs any differently to some overpriced Monster model certified to exactly the same standard. The thing that annoyed me most was his analogy to buying a tyre. He stated that "if you walked up to a tyre salesman and I said don't want the Pirelli's, just put the cheap-o tires on my Ferrari" I'd be insane, and thus by extension of that logic I was insane for not buying a Monster cable for my great new Tivo. This analogy is completely flawed and really just dishonest. A Ferrari is much more powerful and goes much faster than a standard car. It is plausible it needs a better engineered tyre to perform adequately given the additional stresses it undergoes. A Tivo doesn't put out any more or any less bits than any other HDMI certified equipment, no matter what you do. If the cable is certified as getting all the bits to the other end under whatever environmental conditions specified by the HDMI people, then it's going to work for the 99% of people with normal requirements. Nobody wants to make a significant investment in a piece of audio-visual equipment and feel they are getting something that isn't optimal. Harvey Norman's use of this understandable consumer sentiment to sell ridiculously over-priced cables that do nothing is extremely disappointing. I'm sure the commissions on these things encourage this behaviour, so it is useless expecting the retailer or individual sales assistant to change their policy to reccommend reasonably priced cables. However, it is really Tivo and other manufactuers who get the raw end of this deal; a $130 cable is over 20% of the price the actual Tivo! That is surely affecting people's purchasing decisions. If Tivo and others included a certified HDMI cable with their device, as they do with component cables, and had "Certified HDMI 1.3 cable included" plastered on the box, it would be a harder sell to explain why the manufactuer would bother shipping a certified cable that is supposedly insufficient, and consumers would hopefully avoid the very distasteful high-pressure theatrics I was subjected to today.

Ten years ago, on December 21st, 1999, Thomas Lange announced the release of version 1.0 of FAI (Fully Automatic Installation).

FAI is a non-interactive system to install, customize and manage Linux systems and software configurations on computers as well as virtual machines and chroot environments, from small networks to large infrastructures and clusters.

It is a tool for mass unattended Linux installation. You can take one or more virgin systems, turn on the power, and after a few minutes, the systems are installed, and completely configured to your exact needs, without any interaction necessary.

The tool was developed at the University of Cologne, because the author was too lazy to install Debian on 16 hosts manually.FAI now also supports the installation of Ubuntu and RPM-based Linux distributions. It is used worldwide in very different environments; even installations on two zSeries z10 mainframes are reported.

A detailed report in German about the 10 years of the FAI project can be found at http://www.informatik.uni-koeln.de/fai/otherdocs/10jahre.html.

Contributed by: Thomas Lange

I am moving from my old Debian development system to a new one, changing architectures from i386 to amd64. So I need to do a fresh install, but basically I want to keep my package selection. Conventional wisdom is to use dpkg --get-selections and dpkg --set-selections to preserve the package selection. However, this does not keep the information about automatically installed packages. Instead, I used

aptitude search '?installed?not(?automatic)' -F %p > packages.txt

to dump the packages I installed manually. Installing these was a matter of running:

aptitude install  cat packages.txt 

In fact this was taking so long that I loaded the packages in batches using

cat packages.txt xargs -n 100 aptitude install --schedule-only; aptitude

While I was at it, it ran

aptitude remove '?obsolete'

on the original system, killing of a few hundred packages that accumulated since 2003.

There is a bit of a fluff online currently about the following clause in the "jsmin" code (whatever that is):

The software shall be used for good, not evil

This seems to have started when Google rejected a project based on that code due to its license being not free or open source according to their standards, and therefore not welcome anymore. The arguments then quickly degenerated into things like 'when did google stop being against evil'. But those are all besides the point. One of the most important properties of free and open source software is that anyone can use it for any purpose; there are no restrictions to using them. The DFSG (and hence, the OSD which was derived from the DFSG) encode this as follows:

No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

You may think "how is 'evil' a field of endeavor", but that is the wrong question. To "use software for evil" can mean any of a number of things, including "nuclear research", "weapons development", "abortion", or, heck "the cash register in a butchery shop", depending on the ethical and moral framework through which the person writing the license sees the world. The ability to give someone a CD or DVD with a bunch of software on there, being able to tell them that they can just use this in any which way they see fit, is a very strong and important feature of the free and open source community. Every time someone comes up with a clause like the above, however, this ability is diluted somewhat; and if it is readily accepted within the greater free and open source movement, then eventually everyone interested in using a piece of software must first check whether they're not trying to use software that forbids someone's pet evil, and we lose one of the greatest strenghts that does exist for free software, but not for proprietary software. The sad thing is, the jsmin author seems to agree. From a video/transcript on which he talks about his absurd license clause is the following quote:

Also about once a year, I get a letter from a lawyer, every year a different lawyer, at a company I don't want to embarrass the company by saying their name, so I'll just say their initials IBM
[laughter]
saying that they want to use something I wrote. Because I put this on everything I write, now. They want to use something that I wrote in something that they wrote, and they were pretty sure they weren't going to use it for evil, but they couldn't say for sure about their customers. So could I give them a special license for that? Of course. So I wrote back this happened literally two weeks ago "I give permission for IBM, its customers, partners, and minions, to use JSLint for evil."

Or, in other words, all you have to do if you want to use this software for evil is set up a second company, tell Douglas that this second company wants to sell software that uses his software to people who might use it for "evil", even though the first company won't, and you're in business. Because Douglas doesn't really oppose evildoers. So the question is, why is that clause in there in the first place? There are only two possibilities; either Douglas didn't really think about those issues, in which case I hope he will one day see the light and remove the clause; or he did, and decided to go ahead and put that clause there anyway. And that would be evil.

I haven t read of it, and it seems it has been around since a good time. Collecta is a search engine for things in real-time. It searchs on Twitter, Identi.ca, Youtube, Flickr, Blogs, Ustream and shows you what people is saying. It s like a meta-searcher, I guess using API s from those services. But it has it s own API so it will be great for someone that s into web2.x and wants information on real-time from everywhere with just one API. There s a lot of people doing this already and there s a gallery about their development. Maybe tomorrow I will get a little into it, it looks really nice. BTW, it s what powers search.identi.ca

Tutorials at the Garching Debian Stammtisch Munich traditionally used to have a lot of Debian Developers, but over the last couple of years quite a few of us who used to be students graduated and moved elsewhere or became very busy with their day jobs. We still meet for having a beer and a chat, but not as much as some years ago. We used to meet about once a month, but in 2009 we only managed to meet four times (however, we organized a Bug Squashing Party in November and had a special meeting as Lenny Release Party in February) As the meetings are really rather informal and not necessarily very Debian related, it is difficult to attract new people this way. So Johannes Wiedersich and I decided to try a more hands-on approach by having a second meeting in Garching, in the student-run bar on the campus of the Technische Universit t M nchen (TUM). The idea was to get more of the local science, mathematics and computer science students (as well as possibly interested faculty members) involved. We tried a first time about a year ago, but after two or three meeting in late 2008 and early 2009, we lost momentum. However, we began organizing the meetings again with the start of the winter term, and had two rather successful meetings so far. For the first meeting, we basically handed out some information on how to get involved locally (the Debian-Munich list, its subscription address, the wiki etc.) and discussed Debian in general and Debconf11 in Munich in particular. About half a dozen people showed up, and two of these attended the Bug Squashing Party later that month, and another one (a faculty member) got very active in Debconf11 organization. Thus, I was quite happy with the outcame of that meeting. Some days ago, we had another meeting, and this time I was doing a live-tutorial on Debian package building. As Johannes was ill, we did not manage to announce or publicize the meeting well in advance, so only three people showed up. Still, I think it went rather OK, and we will be doing another Debian package-building tutorial for the next meeting, and possibly other turorials/workshops afterwards (ideas so far include library maintenance, Debconf, how the Debian community is organized and how to get involved in it). As doing a live-tutorial on one notebook is a bit difficult if you both have to type on it and people should see what happens, we will either use some extra hardware next time, or move to some nearby seminar room with a projector, this will be announced in advance. So if you are on Garching campus or nearby and interested in Debian development (and Debian package-building in particular), come to the next meeting on January 13th! We decided to meet on the second Wednesday of each month, at 18h. Subscribe to the Debian-Munich list to get the invitation or watch out for the flyers on the campus.

As distributors we should not discourage upstreams that wish to generate binary packages themselves, rather we should cooperate with them, and ideally they will end up maintaining their stable release packages in our distributions.

-- Robert Collins I agree. Robert goes on to talk about the tendancy Debian (and apparently also Ubuntu) have to dislike upstream providing a debian directory. Funny thing is that we also like to say team maintenance is a good idea. An upstream who is doing packaging work is a readymade half of a team; if you write them telling them to rm -rf debian, you are turning away a team member. With a slap in the face. Worse, it's a team member who has demonstrated that they are capable of working in far more complex systems than a debian directory, since they wrote/maintain the software itself. BTW, for those who are skeptical of teams, on the basis that they dilute responsibility: A team consisting of an upstream developer and a distribution maintainer is inherently the more healthy sort of team, where each member has a well-defined area of expertise, but can also venture outside their area when needed. When I packaged FBReader for Debian, upstream already had their own packaging, and I worked with them to fix problems with it and make it something I could be happy maintaining. This was sometimes tricky, since upstream was also maintaining packages for maemo. Sometimes the tools were not ideal. It was still worth it. On the other side of the coin, d-i is an upstream for several distributions. If they told us we needed to rm -rf debian, we'd not have a lot of d-i left. tools I also agree with Robert that most of the trouble comes down to problems with tools. BTW, RPM does not have these problems, and in that world it's typical for upstream to provide a spec file. Much of the problem comes down to the crummyness of dpkg's source format, which cannot rename files, delete files, etc. That the source format directs us to 1970's source management (ie, tarballs and patches), instead of 21st century source management (ie, DVCS), doesn't help either. dpkg's 3.0 quilt source format tries to address the issue by removing any debian directory in upstream's tarball. I am not sure that this is at all the right approach; it makes it harder, not easier to work with upstream as a team. A better approach might be to consider anything that hardcodes the debian directory as having a bug. If upstream can easily package debs using a deb, or maemo, or ubuntu directory, you sidestep any potential conflict while still being able to work with them via a symlink. To put my time where my mouth is: Anytime debhelper prevents working with an upstream who wants to ship a debian directory; that is a bug. I will fix them. (Note that debhelper already provides a --ignore that can be used if upstream has provided a dehelper control file that you can't delete and don't want used.) Previously: Look who's packaging

gfcombinefs is a side project I did some work on a few weeks ago. It combines several "shares" of a secret file previously split using Shamir secret sharing, to produce the original secret, and presents it as a file in a FUSE filesystem. It uses libgfshare for the actual mathematics, and expects its input to have been split with the gfsplit tool shipped with libgfshare. At this stage of development, I suggest not trusting it with important data, like the GnuPG secret keyrings it's designed for. However, I hope that with some feedback from others I can get it into a state where it's ready to be released and packaged (perhaps I'm being unnecessarily conservative, but for something that deals with GnuPG keys, it seems wise to be careful). Source code is available in a git repository, and I'd welcome contributions, bug reports (other than the limitations that are already listed in the documentation) and in particular, a systematic code audit from someone (the good news is that there isn't very much code, so that shouldn't actually take long).