Something that's bothered me and Emdebian in general for months is that it should be simple to compare two repositories and work out which packages need to migrate, which are behind etc. using perl. apt-cross has had rough support for this for some time but it isn't general - it relies on the apt perl bindings.

Recently, the shell scripts for Emdebian Grip became too complex to maintain long term - and far too slow. The main reason was the difficulty in getting all the relevant repository data into memory within a shell scripts. So, I turned to perl and the result is the tenth package to be derived from emdebian-tools source: libdebian-packages-compare-perl - Debian::Packages::Compare - emdebian repository comparison support. So far, it is meant to run on the server because various elements of meta-data need to be read from the repository configuration and that means relying on reprepro. In time, I hope to extend it so that this meta-data can be set arbitrarily so that the module only requires a pair of Packages files - at which point it can be extended to handle a Packages.gz file too (it already looks for and handles the Sources.gz file). The module includes bespoke handling for Emdebian TDebs and the locale root layout.

It reads the Packages file, create a hash of Package and version - once per arch, one per suite, one pair per repo. The underlying libparse-debian-packages-perl is a very simple module, there probably isn't any point putting extra data into the comparison hashes, get the data necessary and load the full Packages data separately using get_single_package.

This module is currently tied to the repository layout used by reprepro in order to identify the architecture list and various other pieces of meta-data. In time, functions can be added to provide such lists.

The module expects to find all repositories beneath a single base directory:

$base/$repo_name/conf/distributions

If $base is undefined or if the repository directories cannot be found, subsequent functions each return undef.

etc.

Example code:

use Debian::Packages::Compare;

my $base = '/path/to/repositories/'
&set_base($base);

my $debu = &read_packages ('unstable', 'filter');
my $gripu = &read_packages ('unstable', 'grip');
my %debianunstable = %$debu if (defined $debu);
my %gripunstable = %$gripu if (defined $gripu);
foreach my $pkg (sort keys %debianunstable)

if ($debianunstable $pkg 'source' ne $gripunstable $pkg 'source' )

# $pkg is either not in grip repository or is a different version




The main features for subsequent versions will involve more verbose error handling.

Currently just in Emdebian SVN, I'll be releasing to Emdebian fairly soon. If there's interest, I could put it into experimental but I think it needs that meta-data handling code first.

Debian::Packages::Compare.pm.

So the failings of the GR result in just what everyone didn't need - a restarted discussion about the firmware issue without first releasing Lenny. Come on people, leave it alone and get Lenny done. Anthony, Thomas and Theodore (also in his blog) all seem to be missing the point(s):

• We had the GR and despite all the manifold failings of the GR itself, Further Discussion FAILED as did the option to delay Lenny ad infinitum (Option 1 on the vote).


• Everyone seems hung up on firmware as something that requires source code, when the real point is that firmware isn't necessarily like other content in Debian and in some (many?) situations, there is no, nor can be any, human-readable form - it really can be nothing more than a series of initialisation flags, not instructions that are specific to that chip or would not make any sense to any CPU.

To me, it's more like data for the chips - it's saying "this is who you are, this is what you do and this is how to understand all subsequent instructions". Software is what follows - the instructions themselves.

We have a very good understanding of the separation between software and data in userspace - we all recognise that unless the output of a program consists to a large extent of modified versions of already licensed code (e.g. code generators), then the data created by your free software GPL-3+ text editor (or blogging client) cannot be deemed to be under the GPL-3+ or any other licence until such a statement is made by the copyright holder and that the copyright holder is the user of the software, not the author of the software. I could quite easily put this blog under a Microsoft-style EULA or even NDA if I wanted to be obtuse, despite it being created using a free software stack. The point remains - I am the copyright holder of the content created using the free software on my machines and I am free to publish that data as I see fit. The authors of the software itself have no rights to dictate what I do with the content I create using the software, just as I - as a user - cannot dictate whether the authors of my editor choose to migrate from GPL-2+ to GPL-3+ or even BSD.

Where firmware can have source code, let it have source code - we have such packages in Debian already. Even then, much of the code may be simply calculations or conditionals to select the right combination of binary flags for specific situations. This isn't about Nvidia kernel drivers that do real runtime calculations during the entire runtime of the machine, this is about tiny bits of initialisation data that are set once and not touched again. Can we not accept that some firmware is derived from a process that does not involve source code? How about experimentation and calculation? We know the voltage on pins 5 and 19, we know the state of register A and that for this specific case, it needs to be toggled to match the state of register E because otherwise another chip on the same board gets confused, so setup the chip to do that by setting a firmware datum point to initialise A? Where's the source code in that process? There is none - it is a piece of data, an item in the design notes (or more likely the errata). Yes, maybe the chip should know how to set this datum itself but for whatever reason (probably financial), it doesn't.

Source code could be used to calculate the datum point for a range of chips and chipsets according to a range of data inputs but the creative effort is then in the calculation not the data. The chip doesn't want the calculation, it cannot perform a calculation in this uninitialised state, it needs the datum point. Once it has the registers set, it can then understand subsequent instructions - the software itself. The datum point itself is just a raw piece of initialisation junk for the chip, it has no source code, it is determined by a physical process. It is a reference point - a fixed value that is determined during the design of the chip and/or chipset.

It's like saying you want the source code that determines whether there are one hundred cents in a Euro so that you could modify it to create a thousand or just ten or maybe turn the Euro into a hexadecimal currency. Weird. The fact that the Euro has one hundred sub-divisions is not up for negotiation, it isn't a modifiable value - changing the value unilaterally is not going to magically make everyone use the new value. It is a fixed reference point - a single datum point that initialises all subsequent behaviour of all software utilising such a currency. Even if there was source code (gee, what could that be, do you think? "%.2i" ?) it would be meaningless to insist on being able to modify it.

Few people can make the judgement about whether particular firmware can or cannot have source code - in most cases it comes down to the hardware design of either just the chip or how the chip is utilised for a particular board.

At some point, Debian has to accept that we cannot know if source code was used to create a particular blob. We simply have to ensure that maintainers ask upstream, elucidate as much information as possible about how the firmware was created and document that in debian/copyright. If that information is proved to be incorrect, then we have to deal with it as best we can - on a package-by-package basis. The assumption has to be that firmware does not necessarily have any source code.

In the end, I think the GR came up with the right result, despite all the failings - Option 5, assume that firmware is compliant with the GPL unless there is evidence to the contrary.

Sometimes, there simply is no source code - sometimes all you have is data.

Debian cannot insist on source code for data that is not generated from source code and it is the difficulty in deciding whether one set of figures is initialisation data or a set of compiled instructions that will defeat all debate on a general solution for the firmware debate. It is comparing apples and oranges - we can insist on source code where source code was used but we also have to accept that some firmware is identified, not programmed. In the end, Debian will have to trust the maintainer and the maintainer will have to trust upstream. Documenting that in debian/copyright seems to be the only sane option.

Now can we all just shut up and release Lenny? Please?

Given the recent brouhaha in Debian, and General Resolution regarding Lenny s Release policy as it relates to Firmware and Debian s Social Contract, which has led to the resignation of Manoj Srivastava from the position of Secretary for the Debian Project, I m reminded of the following passage from Gordon Dickson s Tactics of Mistakes (part of Dickson s Childe Cycle, in which he tells the story of the rise of the Dorsai):

No, said Cletus. I m trying to explain to you why I d never make an Exotic. In your calmness in the face of possible torture and the need to kill yourself, you were showing a particular form of ruthlessness. It was ruthlessness toward yourself but that s only the back side of the coin. You Exotics are essentially ruthless toward all men, because you re philosophers, and by and large, philosophers are ruthless people. Cletus! Mondar shook his head. Do you realize what you re saying? Of course, said Cletus, quietly. And you realize it as well as I do. The immediate teaching of philosophers may be gentle, but the theory behind their teaching is without compunction and that s why so much bloodshed and misery has always attended the paths of their followers, who claim to live by those teachings. More blood s been spilled by the militant adherents of prophets of change than by any other group of people down through the history of man.

The conflict between idealism and pragmatism is a very old one in the Free and Open Source Software Movement. At one end of the spectrum stands Richard Stallman, who has never compromised on issues regarding his vision of Software Freedom. Standing at various distances from this idealistic pole are various members of the Open Source Community. For example, in the mid-1990 s, I used to give presentations about Linux using Microsoft Powerpoint. There were those in the audience that would give me grief about using a non-free program such as MS Powerpoint, but my response was that I saw no difference between driving a car which had non-free firmware and using a non-free slide presentation program. I would prefer to use free office suite, but at the time, nothing approached the usability of Powerpoint, and while dual-booting into Windows was a pain, I could do a better job using Powerpoint than other tools, and I refused to handcap myself just to salve the sensibilities of those who felt very strongly about Free Software and who viewed the use of all non-Free Software as an ultimate evil that must be stamped out at all costs. It is the notion of Free Software as a philosophy, with no compromises, which has been the source of many of the disputes inside Debian. Consider, if you will, the first clause of the Debian Social Contract:

Debian will remain 100% free We provide the guidelines that we use to determine if a work is free in the document entitled The Debian Free Software Guidelines. We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component.

This clause has in it no room for compromise. Note the use of words such as 100% free and never make the system require the use of a non-free component (emphasis mine). In addition, the Debian Social Contract tends to be interpreted by Computer Programmers, who view such imperatives as constraints that must never be violated, under any circumstances. Unfortunately, the real world is rarely so cut-and-dried. Even the most basic injunctions, such as Thou shalt not kill have exceptions. Few people might agree with claims made by the U.S. Republican Party that the war in Iraq qualified as a Just War as defined by Thomas Aquinas, but rather more people might agree that the July 20, 1944 plot to assassinate Hitler would be considered justifiable. And most people would probably agree most of the actions undertaken by the Allied Soldiers on World War II battlefields that involved killing other soldiers would be considered a valid exception to the moral (and for those in the Judeo-Christian tradition, biblical) injunction, Thou shalt not kill . As another example, consider the novel and musical Les Mis rables, by Victor Hugo. One of the key themes of this story is whether or not Thou shalt not steal is an absolute or not. Ultimately, the police inspector Javert, who lived his whole life asserting that law (untempered by mercy, or any other human considerations) was more important than all else, drowns himself in the Seine when he realizes that his life s fundamental organizing principle was at odds with what was ultimately the Right Thing To Do. So if even the sixth and eighth commandments admit to exceptions, why is it that some Debian developers approach the first clause of the Debian Social Contract with a take-no-prisoners, no-exceptions policy? Especially given the fourth clause of the Debian Social contract:

Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system.

This clause does not have the same sort of absolutist words as the first clause, so many Debian Developers have held that the needs of the users is defined by 100% free software . Others have not agreed with this interpretation but regardless of how needs of the users should be interpreted, the fact of the matter is, injuctions such as Thou shalt not kill are just as absolute and yet in the real world, we recognize that there are exceptions to such absolutes, apparently unyielding claims on our behavior. I personally believe that 100% free software is a wonderful aspirational goal, but in particular with regards to standards documents and firmware, there are other considerations that should be taken into account. People of good will may disagree about what those exceptions should be, but I think one thing that we should consider as even higher priority and with a greater claim on how we behave is the needs of our users and fellow developers as people. For those who claim Christianity as their religious tradition, Jesus once stated,

Thou shalt love the Lord thy God with all thy heart, and with all thy soul, and with all thy mind. This is the first and great commandment. And the second is like unto it: Thou shalt love thy neighbour as thyself. On these two commandments hang all the law and the prophets.

Even for those who do not claim Christianity as their religious tradition, most moral and ethical frameworks have some variant on the Golden Rule: Do unto others as you would have them do unto you . I would consider, for example, that the Golden Rule is at least a high priority claim on my behavior as the notion of free speech, and in many cases, it would be a higher priority claim. The recent controversy surrounding Josselin Mouette was started precisely because Joss has taken a something which is a good thing, namely Free Speech, and relegated it to a principle more important than all else, and claiming that any restraint on such a notion was equivalent to censorship. I think the same thing is true for free software, although it is a subtler trap. Philosophical claims than 100% free software as most important consideration is dangerously close to treating Free Software as the Object of Ultimate Concern or in religious terms, idolotry. For those who are religious, it s clear why this is a bad thing; for those who aren t if you are unwilling to worship a supernatural being, you may want to very carefully consider whether you are willing to take a philosophical construct and raise it to a position of commanding your highest allegiance to all else, including how you treat other people. Ultimately, I consider people to be more important than computers, hardware or software. So over time, while I may have had some disagreements with how Mark Shuttleworth has run Canonical Software and Ubuntu (but hey, he s the multimillionaire, and I m not), I have to give him props for Ubuntu s Code of Conduct. If Debian Developer took the some kind of Code of Conduct at least as seriously as the Social Contract, I think interactions between Debian Developers would be far more efficient, and in the end the project would be far more successful. This may, however, require lessening the importance of philosophical constructs such as Free Speech and Free Software, and perhaps becoming more pragmatic and more considerate towards one another.

For various reasons (which in the end boil down to lack of manpower), we are quite late in the process of packaging GNOME 2.24. (This is almost finished now, I ll keep you informed.) Which is why I may sound coming a bit late on noticing this one, but I was really speechless. The problem: session management has flaws Currently, a session manager uses XSMP (the X Session Management Protocol) to talk to applications. What it means is that for applications supporting this protocol, it is able to do more than simply starting and killing them: it will also remember their state, and offer them a way to shut down gracefully. However, XSMP is really a shitty protocol I won t explain why here, you will find tons of better explanations on the intarweb. The gnome-session developers, being quite aware of this issue, did what anyone interested enough would have done: they designed a new protocol, based on D-Bus, and implemented it. The new protocol is not considered stable yet, but it is simple, efficient and above all, reliable that s a giant leap forward. For this reason, I was very excited to see what gnome-session 2.24 would look like, since it brings major cleanups in the code. The solution: remove session management! When I first started it, it did not restore my saved session. I simply supposed that the format of the saved session had changed, and that writing a conversion tool would be in order. Wrong. Let s bring the session preferences: The UI of this dialog hasn t changed since 2.22. However, I do not resist the urge to show you the code behind the Remember Currently Running Applications button:

static void
on_save_session_clicked (GtkWidget           *widget,
                         GsmPropertiesDialog *dialog)
 
        g_debug ("Session saving is not implemented yet!");
 

As for the check box on top of it, it sets a GConf value that is never read anywhere. If you know the long term plans for GNOME, it makes sense: when gnome-shell replaces the panel and the window manager, it will also be responsible for starting the visible applications, while gnome-session will deal with what s happening behind the scenes. But gnome-shell is still far from ready, and you need something in the meantime for the basic requirements of a session manager! Backwards compawhat? The surprises don t stop here. I also noticed that logout was much faster instantaneous instead of the usual 2-3 seconds. The reason why logging out is this long currently is not because it takes long to kill applications; it s because the session manager kindly requests applications supporting XSMP to shut down before killing them. If a document isn t saved, an application will be able to prevent the logout process. Guess what? Now gnome-session completely ignores XSMP applications. Since it doesn t need them to register for saving the session, it also saves the time to ask them to close cleanly. The result is that you will see a lot of such dialogs: It s very nice to replace a flawed protocol ; and really, the new protocol goes in the correct direction. But let s be realistic, it s impossible to immediately port hundreds of applications to a new protocol without having a transition time during which both protocols are supported. You also need to consider your protocol as stable before asking other developers to port their applications. And to get it accepted, you need to standardize it; freedesktop.org would have been the correct body. (Currently, the protocol lies in the org.gnome namespace, not org.freedesktop.) Release management at its best Wait aren t there some distributions out there which already released stable versions with GNOME 2.24? The answer is yes. At least Ubuntu Intrepid and Fedora Core 10 ship with a session manager that:

• is unable to restore applications;
• kills applications without letting you save your work.

It s good to see such improvements on the session manager coming, and I m really thankful to the gnome-session developers to work on it. What I wonder is:

• How could it slip into a stable GNOME release?
• How could two major distributions let it slip into a so-called stable release?

It definitely looks like we re not the only ones who could improve our release management processes. So what? This is a very good example of a lack of big picture thinking. On one side, there is a brilliant design and its good implementation. On the other side, two major regressions from the user s point of view the kind of regressions that make people fly away. If there s one thing that I ve learned from working in IT, it s that you must often keep your brilliant designs as long-term goals. In the short term, you will run a bastardized version of your brilliant design that will make you cry; but it will work. When you need to talk to shitty applications or with shitty protocols, you need to write shitty code.

I unsubscribed from -devel and -vote the other day, as the pain/gain ratio was just not worth it anymore (and -project is very much pending). Sadly, I still could not escape from what I wanted to escape from, as some people bring up those discussions and "their style" on planet.

Please show some fscking respect to your peers! Debian is not about freedom (whether you like it or not, and no matter how you define freedom), it's not about freedom of speech or being open minded, it's just about creating the greatest free operating system. The free operating system, that's why we are here.

I for one, disagree with many debian contributors ideas and believes, whether (those ideas are) Debian related or not. To give one example, I think religion is hillarious and believing in (a) higher being(s) is a sure sign of an ill (or weak, or both, or whatever) mind. (Quite similar to smoking btw, and for those who don't know, I do smoke.) But I'm not shoving this down all the time to anybody who makes a religious reference in Debian (nor in real life). Quite the contrary, I do admire quite some people who take motivation out of their religious believes to do things they think are good. I belive this is quite common the other way round too, eg when religious and human-rights motivated groups work together to help immigrants. They dont share (all) the same beliefs, and in some they have huge disagreements (eg. I think religion is the root and a means^wcontributor to many of the worlds evils) but they choose to respectfully disagree on these views to be able to work together on the common goal they share: help immigrants.

And in the same way I (try to) (dis)agree with my fellow Debian peers about their insane or great ideas. I try to respectfully disagree (or respectfully agree). And I do acknowledge that I sometimes fail, eg the above words about religion might have hurt some peoples feelings. I do give a damn about having hurt those people (so I ment to say sorry with that in cheek damn joke), even though I dont give a damn about religion. And I think the last sentence might have been too sharp to be respectful while I belive the above paragraph is fine. I also think its fine to be disrespectful (in or outside Debian) once in a while, since we are all humans and make mistakes once in a while, but I dont think it's fine to have those people in Debian who fail all the time (or too often), be it because they are incompetent to treat fellow peers with respect or because they dont care (or because they think they do something good with their kindergarten rhetoric).

Contributing to Debian is not a human right (and suppressing some voices (and esp. noise) in Debian is not censorship, for fucks sake!). We are only here, because we are standing on the shoulders of giants (except for the very few giants among us) and because we want to create/improve a great operating system. And thats why I think it's perfectly acceptable and desirable to not allow those messages here, which are distracting and/or blocking of from reaching this goal. An occasional outburst (and be that a 2-4 weeks long or a single big outburst) doesnt qualify in my book for being kicked out, no matter how harsh or unreasonable it was. Constant disruption IMO is. Where to draw the line is tricky (and I'm convinced there can't be a single written "line" covering everything in Debian), but not to draw any lines will result in only the vocal and thick-skin minorities to stay.

And with nice, respectful communities (which have policies quite a lot like the DFSG) like fedora and ubuntu available, failing to be(come again) a respectfull community might really contribute a lot to the end or slow decline of Debian. Sure, "the end of Debian!11" is a somewhat constant meme, but it is (sadly) not like Debian is undestroyable. Debian is very certainly much easier to destroy than to rebuild.

We need to take measures to prevent some peoples ideas of freedom from harming or destroying the project. And I don't mean some peoples ideas of Debian police state or Debian teletubby county - I'm very confident those ideas will not win here. But sadly I can see the results of poisonous people, or rather, their behaviour win.

And undoubtfully I also can see many great people in Debian making sure this will not happen.

The future is unwritten and I wish we show our fellows the respect they deserve. Debian wasn't made by you, more than 99,99999% of it was made by other people. And if you have to, attack ideas, not people. And usually it's also unneeded to _attack_ an idea (merely challanging it is usually enough), because usually the Debian person proposing it is not so stupid not to take your criticism into consideration.

That's why I'm still in favor of a social committee, even though I see very much the dangers of power abuse and the cultural norms in a world wide project. But I see much more danger in not stopping unrespectful assholes from urinating into our living rooms and work benches, using the waiver of "free speech" and "we all have different standards of whats acceptable."

Simpler said: either you respect the community or this community shall not be yours.

That said, I wish you all a very merry xmas, whether you celebrate and believe, or one of the two, or none. Be happy and let it be. And may we have a great 2009, despite we'll release lenny that late! ;-)
P.S.: I'll post this to -project as well, so you can reply more easily.

And there it is. We now can have Planet Debian in other languages than english. The first one is Spanish but the framework allows for any number. In case you do want to have Planet Debian in a different language, follow this steps: (2LETTER means the 2char ISO Code of your language. Like es for the spanish one, de for a german, etc.)

• Checkout svn://svn.debian.org/planet-debian/trunk/config and look at the config.ini.tmpl
• Rename it to config.ini.$2LETTER
• Edit the values in it that are marked to be edited. Feel free to translate the footext variables, they are used in the html template.
• Send this file to the Debian Planet Maintainers. No need to commit yet, it wont get automatically activated, we do have to take two steps on the host planet runs on before that happens.

You need to have 10 feeds ready and filled in in the file you send us. All the feeds should provide a category that has entries with only the language for this new instance. (Otherwise it won t make sense to create a Planet instance for a language ) Planet now features a link section called Planet I18N right above the Subscriptions. That will always list the currently active other language Planets. The various planets share the common files like CSS, graphics and all the hackergotchis.

---

It was a bit of work to get to the point where we are able to add multiple planets to the system. First I had to upgrade the code behind it to a newer one, Planet Venus instead of Planet Planet. Main advantage being that it uses multi-threading to fetch the feeds, greatly speeding up that part. And this weekend I had to rewrite all the templates, going away from old (and simple) htmltmpl format to one based on Django. Htmltmpl simply has no way to deal with our Planet now anymore, especially as it has no way to access all config file values. Which I need for the translated strings, or I would need one template per language. Which would be insane. Various other things in Django also make Django templates a way easier thing to deal with, for example simply saying

  % firstof var1 var2 var3 "nothing" % 

instead of having a huge if-then-elsif-elsif-lalala chain. And we do have that multiple times.

I have been positively surprised to find out that some people are taking seriously the fact that some people are being put off from actively participating in Debian s discussions because doing so would lead to offensive behaviour and personal attacks, and to try to find a solution to the fact that a very vocal minority is dominating the silent majority. Of course, some people are happy with the statu quo and strongly opposes to changing anything in that direction, not very surprisingly. The part about I m really starting to think that this Project could do a lot better without some people is crystal clear and needs no comments. I m not really sure that the current social environment can be fixed just with technical measures. Another proposal talks about some mailing lists extracted from the official ones but with the offending comments filtered out. I must confess that I find this idea very interesting and that I might think about rejoining such a list. Of course, technical details on how to properly and effectively implement any of this methods, or even a mixed one, can be very tricky.

Dell chose to ship Linux on the Mini 9, and so they were not required to plaster Windows stickers all over the case. They made up for this sticker deficit with a useless sticker that reads just "Inspiron M series" (or something approximating that). My mind boggles at the decision process behind that. Removing this sticker, I scratched the case of my new laptop. I also spent about 20 minutes scrubbing off the evil glue they used, which spread everywhere.

---

I had hoped the white power LED on this laptop would be less eye-searingly painful than the blue leds that were trendy before. It is, but it's also right on the front of the laptop, which is often in a direct line of site to the screen. In any dim enviroment, the LED is still brighter than the screen. I fixed this by applying some electrician's sticky tape to the case. Obviously, I can't win.

I'm pleased to make Emdebian Grip unstable available - a smaller, binary-compatible, Debian without manpages, without unwanted translation files (uses Emdebian TDebs) and without package documentation. The current packages will be migrated into Emdebian Grip testing in due course and then be released alongside Lenny.
Emdebian now has two flavours with Grip taking the intermediate position in terms of size whilst retaining full compatibility with Debian. Grip "cherry-picks" packages from Debian but retains the unchanged Debian sources - the main binary and library packages will exist but -dev, -doc and -dbg packages may well be missing, as well as some of the more unusual OR dependencies).
I've just converted my Acer Aspire1 (i386) - running XFCE - from Debian Lenny to Emdebian Grip:
607 upgraded, 1 newly installed, 2 to remove and 0 not upgraded.
Need to get 184MB of archives.
After this operation, 278MB disk space will be freed.
Yes, update 600 packages and have nearly 300Mb more free space - that's a 400Kb space saving per package, on average. Gaining 90Mb more free space than the total size of the download is nice too. Comparisons are after using 'sudo apt-get clean' to remove downloaded archives:
Debian Lenny:
/dev/sda1 7.1G 1.2G 5.6G 17% /
Emdebian Grip (unstable)
/dev/sda1 7.1G 919M 5.8G 14% /
I make that about 25% smaller and not all packages installed on the machine have been "gripped" - (about 100 remain, many of which I should probably remove anyway).
Method: See http://www.emdebian.org/grip/index.html.
Add the Grip source to /etc/apt/sources.list.d/
deb http://buildd.emdebian.org/grip/ unstable main
$ sudo apt-get update
$ sudo apt-get install grip-config
This is a very important stage - Emdebian Grip is still in development and with the Lenny freeze, a few wrappers and helpers are needed to allow smooth migrations between Debian and Emdebian - grip-config is Architecture:all and contains the relevant scripts. (grip-config is Priority: required so debootstrap picks it up by default - this also means that grip-config cannot be part of Debian.) grip-config also includes the same key as the emdebian-archive-keyring package used by all Emdebian repositories.
Only after grip-config is installed should you use:
$ sudo apt-get dist-upgrade
Note that this is a complete replacement, including libc6, apt, coreutils, dpkg and (on i386) the stock kernel. As such, it can take a while to complete the installation once the download is complete. (As ever, if the kernel is updated, ensure you reboot before you next suspend to disk - even the minimal "gripping" changes to the kernel package may confuse grub when deciding whether to use the suspended image.)
A few packages are currently behind Debian Sid (notably ncurses) and I'm working on the scripts to enable full update automation.
One other problem is that /usr/share/locale/locale.alias has also disappeared which compromises localisation support right now but that's fairly easy to fix. (langupdate is also missing so there is no effective localisation support right now - I need to cross-build langupdate for the grip architectures.)
Note that this test install adds the Emdebian Grip repository to the existing Debian sources and relies on the em[0-9] version suffix to implement the upgrade - packages that are behind Debian get left at the Debian versions, you can also use normal pinning.
$ apt-cache policy
Package files:
100 /var/lib/dpkg/status
release a=now
500 http://buildd.emdebian.org unstable/main Packages
release v=0.1,o=Debian,a=sid,l=EmdebianGrip,c=main
origin buildd.emdebian.org
500 http://ftp.uk.debian.org sid/main Packages
release o=Debian,a=unstable,l=Debian,c=main
origin ftp.uk.debian.org
Pinned packages:
I've done some testing with debootstrap and a chroot works too - it should be possible to ally these packages with the normal Debian installer because there is no point "gripping" udebs that are already v.small and the packages that actually get installed are dictated by your choice of mirror. debian-live should be gaining support for Emdebian Grip in due course.
If someone fancies trying a test installation by choosing http://buildd.emdebian.org/grip as their mirror in d-i, let me know.
(Installing Grip is likely to result in further size gains as the Grip repository data does not support Recommends, so you don't have to try and get d-i to not use recommended packages).
Emdebian Grip (unstable) is now available for 7 architectures:
i386, amd64, arm, armel, mips, mipsel and powerpc.
(amd64 is only supported for debugging purposes, most of my development machines are amd64.)
Please report any and all bugs to the buildd.emdebian.org pseudo-package in the Debian BTS.
If you want more packages added, set up a Debian machine or chroot with all the packages you need (and only the ones you need) and send the
complete output of 'dpkg --get-selections' to the debian-embedded mailing list. Alternatively, file RFP bugs against buildd.emdebian.org at wishlist severity.
To see the current list of packages, use the search support
Headline packages:
coreutils, perl, python, apt, dpkg, grip-config, XFCE, debhelper, make, devscripts, sylpheed, iceweasel, drivel, xchat-gnome, gpe-tetris,
totem-gstreamer, liferea, thunar, evince, seahorse, gthumb, libsqlite3, pilot-link, python-gnome2, lua, tcl, gcc-4.3, binutils, libmysqlclient15off.
Currently, very few -dev packages exist in Grip. I'll make the emdebian-grip package available on Grip itself in due course so that new and bespoke packages can also be "gripped".
I'm migrating the current packages to Emdebian Grip testing soon and I'll be making a release of Emdebian Grip 1.0 (based on Debian 5.0 "Lenny") as well as Emdebian Crush 1.0 (based on Debian 5.0 "Lenny"), alongside the main Lenny release.
Finally, note that Grip is binary compatible with Debian - indeed, the binaries themselves are untouched - but bugs that appear in Emdebian Grip must only be filed against the buildd.emdebian.org pseudo-package. Right now, reportbug is not part of Emdebian Grip because I need a way of telling reportbug to only use the pseudo-package.
The main usability improvements will come in the development of Emdebian 2.0 (based on Debian 6.0 "Squeeze") - please consider Emdebian 1.0 as a "developer release", think back to what things were like with Slackware 1.0 or Debian buzz, rex or bo.
P.S. there is no concept of a release-critical bug in Emdebian Grip (at least, not yet) - the 1.0 release will happen as soon as Grip testing is in sync with the released Lenny (no matter what). Please do not file any bugs against buildd.emdebian.org with higher severity than important, it will just annoy people trying to fix RC bugs in Lenny.
If you are a maintainer in Debian and you inadvertently receive a bug report listed as 'found' in a version that ends in em[0-9], please reassign to buildd.emdebian.org, at severity no higher than important. Thanks.

Once again Debian is close to release. And once again we're trying to find ways to avoid doing so. Using a technique we've employed before; firmware.
Social Contract #4 states that "Our priorities are our users and free software". The hard liners believe that it's in our users' best interests that we ensure Debian is 100% Free, whether that be regarding software, documentation or firmware. In the long run I think they're right. Access to firmware source (assuming that there's also access to
suitable tools for building it and producing an image the hardware will accept, which is a fairly big assumption) enables us to continue supporting and improving hardware support long after a manufacturer has discontinued a device. It enables us to understand the behaviour of a new device better (allowing better support which makes it a more attractive purchase). It potentially lets us appropriate a device for new and exciting purposes the manufacturer never imagined (which may again increase the sales of the device). Access to firmware source is a good thing in the long term, for the consumer, the driver author and the manufacturer.
In the short term we I think we need to be pragmatic. We can say that we won't release until all non-free firmware is purged, but who knows how long that will take, and once we've done so how much hardware will we actually be able to support out of the box? What benefit is it to our users if we ship them a distribution that doesn't support their hardware and is already out of date because we spent so long removing that support? Wouldn't we be better to say "We're aware of some firmware issues. We're going to keep working on spliting such blobs out to their own easily installable packages that live outside main. We promise to continue improving the situation for each release (as we have already done since etch), but in the interests of our users we will not hold up a release at this stage of the process." Obviously plenty of people disagree with that, but I don't believe that pragmatism is against the Social Contract and I'd like to think that even our users who are fervently against firmware blobs would accept that there's a tradeoff to be had against release dates.
Anyway. I doubt I've changed anyones mind with the above, so I'm going to go and destack the dishwasher and reply to the latest mail from my NM.

Ingo blogs about the current vote, and wonders whether we did not have enough time in two years to do something about the fact that there were firmware blobs in the kernel. Well, we did, and we did. It's just that in two years, several new kernel releases came out, and that also resulted in some new firmware blobs entering the kernel. This, in a way, is a relatively new issue. Having said that, I do agree with his sentiment; even if they're new issues, they could and should have been fixed ages ago. As I said in my 'no more hitting' post, too. Speaking of which, Jorg did not understand why that post did not show up, either. So I've just moved it into /en/computer/debian (where it belongs, really); perhaps that will fix it. Having been the maintainer of Planet Grep for a few years, I know now that this kind of strange behaviour would not be beyond planetplanet...

A while back, I wrote about this GObject-based Object/Relational mapper that I wrote, which is called 'GNoDbify'. It isn't complete yet, but parts of the library work; I use it for a project that I'm supposed to commercially support. For those who don't know what that is: an O/R mapper builds objects out of database tuples; so I can run a 'lookup' function on the object class and get one (or more) objects representing data from the database, then perform some modifications on that object, and store it back in the database; my O/R mapper does all the SQL magic. Last week, I've been working on another object that takes an array of GNoDbify objects, and presents them using the GtkTreeModel interface, for easy viewing in a GtkTreeView:

my @customers = Vpbs::Db::Customer->get_all();
my $model = GNoDbify::ListStore->new_from_array(@customers);
my $view = Gtk2::TreeView->new_with_model($model);
my $renderer = Gtk2::CellRendererText->new();
my $column = Gtk2::TreeViewColumn->new_with_attributes("Name", $renderer, "text", $model->get_column("name"));
$view->append_column($column);

And there you have it: a treeview showing all the names of all the customers in the database. On the classical approach, one would have to use DBI or some such to fetch data from the database, create a GtkListStore or something similar, and then append the data one row at a time to that. Of course that still happens here, in a manner of speaking, but it all happens behind the scenes. It also means that in an application which wants to show a load of data, I don't have to do the same thing all the time. The magic happens in the second line, and in the second-to-last line. GNoDbify::ListStore->new_from_array is pretty much self-explanatory, really. It takes an array of GNoDbify objects, and returns a GNoDbify::ListStore. The second-to-last line shows how to add a column to a GtkTreeView. With GtkListStore and GtkTreeStore you basically define yourself what column gets what number; however, with GNoDbify, that isn't as easy (it depends on the implementation of the GNoDbify subclass), so the ->get_column returns the number of a column as represented by the model, and wants the name of the field that you want the column of. Everything else is really the same. It won't stop here, though. The original plan for GNoDbify was that it could detect changes in the database, and update the tree model accordingly. Most of that has already been implemented in GNoDbify (though not yet in the ListStore thing), but just needs some debugging. The fun thing is, the above six lines of code would not have to change at all for that. Of course all this juicyness comes at a price. In order to generalize this much, I had to do a lot of extra stuff; so there's some performance loss. Especially in perl; most of GNoDbify is written in C, and converting perl arrays to and from C arrays is a process that can only be done by looping over the perl array (or the C array) and creating the other side of the equation. Obviously, that's a costly approach, performance-wise; an obvious optimization of the above example could be to have a subroutine that returns Customer objects already in a GtkTreeView in one API call. We'll see.

I just updated the Software behind Planet Debian to Planet Venus, away from PlanetPlanet. The major benefit right now is the threading, we are now using 15 threads to download the various feeds instead of just one. For all the rest it is currently the same as the old PlanetPlanet, as we use the same templates. But we might switch to something different, we now have the option. The reason for that switch, beside a little more recent code, was the faster updates which was driven by a request we got recently. Language based Planet Debian, ie. a spanish, a german, one. This is now doable without trashing the machine it runs on and will be there soon. I m not yet sure what the exact rules for the language planets will be, but I guess something along the following will do (have to discuss with the other Planet maintainers, this is just my 2 on it):

• Same content as you would put on planet.debian.org, ie. mostly Debian related.
• Special feed with only the language for this planet.
• At least 10 feeds have to be there before a new language gets added.
• Language planets will appear as planet.debian.org/$LANGUAGE, where $LANGUAGE will be the two-letter code for it.

While I was doing this I also went and disabled a large number of non-working feed entries in our Planet config. A diff is available, if you find yourself in it, feel free to reactivate our entry as soon as it is reachable again. [Update] Planet now also features an Atom feed, in case you prefer that.

Michael Arrington of Techcrunch comments on the US vs Europe in terms of startups: Joie De Vivre: The Europeans Are Out To Lunch It's a pretty rough and coarse-grained view of things, but there's a grain of truth there. I've written about this a little bit before. It's something that I feel qualified to talk about, having lived and worked in both the US and Europe (Italy and Austria to be precise), and in that time, generally gravitated towards startups. Here's my quick take on a list of what's good and bad about each. Please note that these are of course not true for everyone, that things are changing, but are still things I think are generally true, even when I could think of several counterexamples for some of them myself. Also, it's very important to keep in mind how diverse "Europe" is, so most of what I write is really about Italy, and to a much smaller degree, Austria. I'd be very curious to hear your own experiences in the comments. Europe Bad

• Less of a startup culture and mentality. It's more typical to get a "job for life" and hang on to it for all you're worth. Many Italians are tremendously creative, industrious, inventive people, but are going to find it more difficult to express that in some form of business.
• The side effects of this mean that there are fewer people to talk with, and network with, fewer potential employees willing to risk a startup, and so on. For instance, people are at times more suspicious of a new company - both clients and suppliers.
• As I mentioned in my other article, it takes a lot more money to get started in many European countries - something like 10,000 Euro in Italy. Other places like the UK are cheaper, and apparently Germany is introducing some legislation to ease the burden on new companies. I really hope this changes in Europe because it's such an easy change to make: don't extract money from companies until they're making it.
• More bureaucracy. I think that higher taxes, once you are profitable, might be worth paying for the social system you get in Europe, but the cost of sorting out paperwork falls inordinately on smaller, newer companies. Big, established firms can hire people to deal with all the rules and regulations, and probably have contacts in the government that can help them out in some cases. Smaller firms are the ones whose time is really going to be wasted running around to different offices trying to figure out what they have to do.
• Smaller, fragmented markets. Localization is not a lot of fun in some ways, and trying to translate everything into all the languages of the European Union is a huge undertaking. In the US, you get a huge market with just English and the US Dollar. Even beyond language issues, the culture changes less in the US from place to place, meaning that you have a more homogeneous target.
• Lack of acceptance of failure, both culturally and institutionally. If you go bankrupt in Italy, it's a very serious problem. Apparently (although this is second hand, I'm not 100% sure of it - maybe someone can confirm whether it's actually true?), you can even lose the right to vote. Plenty of people in the US try several times before they get it right.

Good

• Even if your undertaking fails, you still have health care. Likewise, there are other bits and pieces of social support (that change from country to country) that mean you're probably not going to land quite so hard on your rear if things go wrong.
• Lots of smart, educated people. I never lacked for plenty of smart people to talk shop with in Padova, and didn't miss the California bay area at all from that point of view. Open source is really big in Europe - perhaps, in part, because for many people it's a better avenue for their talents than creating a business, when doing so is difficult and less common.
• Work/life balance. Sorry Mike, but the amount of people who are truly going to strike it rich is pretty small. If they want to work hard, great, but it's nice to have some other options, in terms of good, lasting friendships (rather than everything revolving around work), knowing plenty of people from outside your field, people living in and belonging to a community (how many people spend their whole lives in the bay area?). When I moved from San Francisco to Padova in 2000, I went from a world gone mad with money and the dot com craze to one where there were rich and poor, families, young people, old people, and many people who were not working for some dot com. That's not to say that people don't work quite hard in Italy - two hour lunches are a thing of the past for most anyone I know.
• Smaller fragmented markets can be an advantage, too. By the time some valley-based startup finally gets around to noticing that languages other than English exist, it's possible to capture a smaller market. Ok, so you won't be the next Google that way, but there's good money to be had in doing so.
• In some ways, the staid, established, don't rock the boat way of doing things in some industries may present big opportunities for outsiders to come in and pull the carpet out from under everyone. This is especially true of internet/web companies that can get started quickly and cheaply.

US Bad

• If you're not careful, you can get completely sucked in to work - your life revolves around it, your friends are mostly work friends, and if something happens to your job, a lot of that goes poof. This is especially true in places like the bay area, where so many people are 'transients' - just there for a few years, without any real roots in the area. This is ok if you'll potentially make a big pile of money, but long term it's unhealthy.
• Less of a sense of building for the long term. Personally, I don't want a "job for life", but I think there is some value in loyalty (the genuine sort, not the sort created by legally not being able to lose a job) between employer and employee that has been lost in the US. Being able to count on someone growing with your company, and as an employee, knowing that your company will do what it can to help you out even in tough times are things that capture some value. The US seems to be heading towards a "Coasian" world where everyone is a freelancer, and while that efficiency is hard to deny, I wonder what is lost in the process.
• The competition is tough. Sure, it is in Europe too, but in Europe everyone may compete quite hard during the year, but still all take that one month vacation (although that is becoming a bit less common, especially amongst people my age), whereas in the US almost no one gets that kind of benefit - even if you wanted to take unpaid time off, people would look askance at that kind of behavior. That said, if you need to stay open in, say, August, in Italy, to compete, you are in big trouble, because for many businesses it's simply impossible because it's a chain reaction: all your suppliers and clients shut down, so you really have no choice.

Good

• There are certainly bureaucratic obstacles in the US, but are much more maneageable, and don't hit smaller/newer companies quite so badly.
• It's cheap to get started. As per my other article, the actual state filing fee in Oregon for an LLC is $55, and that's all you really need.
• The culture is definitely there, especially in the right places like the Bay Area, but even in plenty of others.
• You aren't bound to employees for life, and it's easy to find freelancers. I know I'm contradicting myself, but I think it's actually a complex issue, and there are definite advantages to not having people who expect or at least want to find that job for life.
• A large target market. Go online in one state, and you can, for the most part, deal with customers all over the US, in one language.
• Things turn around faster. I have more of a sense that when there are problems, they get fixed. Companies (the debacle of the automakers notwithstanding) are more often allowed to fail, or at least put in Chapter 11. Sometimes this means that when things are bad, they get really bad, but also turn around and get better sooner.

Conclusions An interesting example of all this from my own experience was Linuxcare. The company was, culturally, a Bay Area startup, with the headquarters in San Francisco, founded by very startup oriented guys (one of whom, Dave Sifry, went on to do technorati, and is currently working on yet another venture). However, most of the actual open source talent was in our satellite offices, in Australia, Italy and Canada, places where, perhaps, people were not so distracted by the prospect of "make money fast!!! hurry!!!" that they had time to work, learn, and create some really great open source code. To be honest, I find myself torn. Business-wise, I prefer the US. However, outside of that, there's a lot to be said for Europe. I also think that some of what's good about business in the US is coming to Europe, albeit slowly in some cases, in Europe. People my age here can see what's going on elsewhere, and try and copy what they like. A lot of what's good about Europe, though, might be more difficult to import into the US, especially the livability of the cities. In any case, I can conclude that it's a complex, difficult topic best discussed over a glass of wine.

---

Mike Hommey blogged today about Per-process namespaces.
That reminded me to blog about switchsh, a very useful program (now in sid) to help workaround those programs that believe that /bin/sh is always /bin/bash, in other words: it bind-mounts bash as /bin/sh.

Package description follows:

Small program to bind-mount bash as /bin/sh for its child processes.

It can be used when bash is not the default shell interpreter but a given
program makes use of bashisms (features not required by Policy for sh) and one
wants to run it without changing (or can not change) the default sh.

Let's take a look at how switchsh can help us:

$ cat evil_script.sh
#!/bin/sh
echo -ne "Hello!\nPlease enter your name: "
read
echo "So, you are $REPLY, right?"

$ readlink /bin/sh
dash
$ ./evil_script.sh
-ne Hello!
Please enter your name:
read: 4: arg count
So, you are , right?
$ switchsh ./evil_script.sh
Hello!
Please enter your name: Raphael
So, you are Raphael, right?

But lets consider the following case:

$ cat evil_script.pl
#!/usr/bin/perl -W
my $res =  git gc &>/dev/null ;
if ($? eq 0)  
    print "Done\n";
  else  
    print STDERR "bang! something went wrong\n";
 

$ ./evil_script.pl
fatal: Not a git repository
Done
$ switchsh ./evil_script.pl
bang! something went wrong

But what happens when bashisms are used on a binary object? Say in OpenOffice.org, in X.org, Wine, or any other large project that take not less than a couple of hours to build in a "normal" machine? you really want to have switchsh in those cases (and file a bug as soon as you notice that running a program with and without switchsh makes it behave differently).

I received a new laptop, a Dell Latitude E4300. I was a bit anxious with its level of support on Linux, because it only recently started being shipping, and it s full of recent Intel hardware. Also, with lenny being frozen for 5 months, we are currently a bit behind regarding hardware support. I installed lenny on it, as I usually run testing+APT pinning. What I m describing here is what is unsupported in lenny out of the box. Wireless:
Needs a 2.6.27 kernel (iwlagn driver), Lenny only has 2.6.26. Downloaded from the kernel team s unofficial repo. Firmware isn t packaged in Debian (firmware-iwlwifi needs an update). Needed to download it from Intel. Graphics:
Intel device, unsupported with lenny s driver (but vesa works surprisingly well, oI only noticed that I was using vesa when I tried to play a video and found out I had no xv support).
Works with experimental s Xorg and the experimental intel driver, but that Xorg needs some polishing. The evdev driver now handles all inputs, so the keymap has to be configured differently (as usual, #debian-x people were very helpful). Suspend/Resume:
Works out of the box using pm-utils. No need for quirks. All in all, it was easier than I expected, and support will probably be perfect for lenny+1/2 ;)

There is again some ongoing debate about Ruy gems and how to integrate them cleanly into the operating system. Let s put aside the fact such tools are useful on Windows and MacOS which don t have decent packaging systems. This is not a reason to dictate stupid requirements for other operating systems. Still, even without that, gems, eggs and the like are great tools for development; tools that developers can t work without today. They allow to easily setup a development environment with everything needed, at the latest versions. However they were not meant for integration and production environments, and will never be suitable for them. We re living in another world indeed: a world where servers must be up 24/7, where security issues flood your inbox every day, where you need dozens of servers running the very same software. This world is the Earth. Python eggs and Ruby gems were designed for the same target audience and with similar requirements; as such, they share the same deficiencies when it comes to other audiences:

1. They replace the operating system s packaging tool. This is very nice to not wait for the packagers when you want the latest development version, but you lose track of what is actually installed. In production, you need to know exactly what s installed and at what version. You also need to know what you will need to update in case of a security issue.
2. They install packages automatically on the system. This is really the biggest WTF; there are some reasons to do that to begin with, but they are all wrong.
3. They use a specific file format. This requirement comes mostly from the Windows world, and it really makes no sense on Unix. It makes it much harder to integrate complex applications using components in different languages.
4. They ship all files at the same place, happily violating the FHS and making it even harder to integrate with other things.

Python tools (setuptools and easy_install) have shifted their philosophy and brought a few small improvements which allow us to easily work around issues 1-3. These tools now include all you need to build a development environment in any directory that will not have an impact on the system packaging, making a clear distinction between the two targets. Furthermore, the metadata is shipped separately and can safely be included in a distribution package. Similarly, modules will not be installed automatically on your system. I have yet to see such a move from Ruby developers. However, what we are still missing is something along the lines of dh_make_perl: starting from a CPAN module, it will generate a clean and working Debian package in a few minutes. There have been some similar attempts for Python, but nothing as efficient. And I am certainly guilty of not having done something in this area, as one of the most knowledgeable of issues we encounter while packaging Python modules. As a note, I should add the underlying issue behind all of this is still the same: the NIH syndrome. Developers are reinventing the wheel, engine and transmission. Which is not that bad per se, but by not looking at existing solutions for the problem of making a car move, they are inventing a square wheel, a steam-powered engine and a superconductor-powered magnetic transmission. For example, while trying to fix the 4th of items listed earlier and they are really willing to fix it and several more general issues, setuptools developers forgot to look at the existing solutions:

• API versioning in /usr/include/package-X.Y
• ABI versioning of libraries
• Build/install-time requirements gathering using an extensible format with pkg-config
• Automated generation of config.h containing all system-specific macros (including paths), with autoconf
• The Mono Global assembly cache which solves some of the specific issues of interpreted languages

Certainly, the existing tools are everything but perfect, and not necessarily suitable for Ruby and Python, but some of the design ideas behind them are clearly the good solutions to some of the issues of software development and integration. Adapting these ideas to radically different languages is going to take more time than just throwing other layers of symlink farms.

I have not sat behind the helm of teaching for very long but I already have a few tricks up my sleeve. One of them is that I assign some of my favorite readings at the end of the semester so as to counter the downtrodden and tepid spirit and mood (not to mention attention) of my students, which drops precipitously with each passing day. Let’s face it post Thanksgiving, we are all a little tired and I try to find the readings, which uplift, intrigue, and challenge cherished assumptions about marriage and sex. So far it seems to pay off and I often can tell because the conversational pitch and excitement in class is high and the student writings are good, great, even exceptional, which, again, is hard to produce/induce this late in the semester. Readers of this blog would probably be most interested in one of these lively readings, Ben Nugent’s American Nerd (and it might be interesting to hear how the European Nerd story would diverge or converge with this one). One of my students, an audio geek and Free Culture President/Free Software junkie, by the name of John Randall produced a very nice little response (not research) paper on the Nugent reading as well as a short piece by Sarah Seltzer from Bitch Magazine
The(Girl) Geek Stands Alone (and thanks to Joe> for cluing me into this piece). Seltzer piece basically argues, in her own words, the following:

Imagine this scene from a comedy: a group of female friends sit around smoking a bowl and working on the Wikipedia page for Lord of the Rings. Their fashion sense is decidedly iconoclastic and several sport thick-rimmed glasses. Without a trace of self-consciousness, they have a hilariously ribald discussion on the relative traits of elves and orcs.
Awesome as it is, you’ll never see this scene onscreen. No mainstream movie or TV series would dare group so many female nerds together, or celebrate them so unabashedly

So John’s whole response paper is here and here is the pdf. In the paper, he makes a number of excellent points but what I loved most about it was his very geeky move at the end of the paper to prove Sarah (somewhat wrong) by listing all the girl geeks that do and have appeared in mainstream (and not-so mainstream) entertainment venues/shows, etc. They are as follows and in his own words:

I will now showcase my own geekiness through my knowledge of geeky female characters. Why? Because I can. But also because I want to demonstrate that if you look hard enough for representations of female geekyiness in pop culture, you will find plenty. Moreover, if you pick the right ones, you can make them support your argument about gender relations, whatever that argument might be. Some of these charters and personalities are hardly gendered, some are hyper-sexual. Some are incredibly attractive but completely asexual. Some undergo a transformation into/out of geekiness, while others to not. Some are powerful, while some are powerless. Some (most?) celebrate their geekiness, others are tortured by it. They are all geeks take your pick: Aeon Flux, a sexy geek who’s technological gadgets give her super powers (Comic drawings then Charlize TheronAeon Flux) Wonder Woman, attractive pilot of an invisible plane Lara Croft, a female Indiana Jones in short shorts, wielding guns and cracking computer codes (CGI and then Angelina Jolie in Tomb Raider) She-Ra, who was way smarter than He-Man (Masters of the Universe cartoons) Gadget Hackwrench, beautiful chipmonk technician for Chip and Dale (Rescue Rangers cartoon) Velma, featuring eyeglasses, awkwardness and brains (Scooby Doo), Hermonie Granger, a geek who is temporarily rejected because she is a geek, remains a geek, and finds love and happiness (Harry Potter) Barbarella, who, through comic strips and a 1968 film, helped introduce science fiction and sex to young women (Barbarella) La Femme Nikita, a skillful, savvy, and very feminine girl who doubles as a covert spy Kate Libby, aka ‘Acid Burn’, uber-sexualized hacker (played by Angelina Jolie in Hackers) Kathryn Janeway, smart and powerful captain of the USS Voyager (Star Trek Voyager) Starbuck (Battlestar Galactica), Dana Scully, FBI agent with encyclopedic media knowledge. The bizzare subtex of non-realized sexual tension was part of the magic The X-Files. Willow Rosenberg, geeky sidekick turned geeky supervillian (Alyson Hannigan in buffy the Vampire Slayer) Michelle Flaherty, hyper-sexual band geek (Alyson Hannigan in American Pie series) Dr Ellie Sattler, heroniene scientist (Jurrasic Park) Ellie, scientis hero (played by both Jenna Malone and Jodi Foster in Carl Sagan’s Contact) Dawn Wiener (Heather Matarazzo in Welcome to the Dollhouse Enid and Rebecca (Thora Birch and Scarlett Johanson in Ghost World) just about every charater ever played by Jenna Malone (Donie Darko, The Dangerous Lives of Altar Boys, The United States of Leland, Saved!, etc) half of the charaters played within the last decade by Jodi Foster (Panic Room, The Dangerous Lives of Altar Boys, Flightplan, The Addams Family half of the charaters played by Christina Ricci (Mermaids, The Addams Family, Little Red Riding Hood, The Ice Storm, Buffalo ‘66, Prozac Nation, Pumpkin, Speed Racer) half of the characters played by Natalie Portman (The Professional, Mars Attacks!, Star Wars, V for Vendette, The Darjeeling Limited, Mr. Magorium’s Wonder Emporium, Garden State) Molly Ringwald. characters played by Molly Ringwald. Rock musician Ani DiFranco and geeky Riot Grrls everywhere. Sarah Vowell, NPR commentator celebrating her geeky life. Voiceover for geeky cartoon characters. Rachel Maddow, for being Rachel Maddow.

First, awesome list, though he forgot a few (like one of my favorites, Bionic Woman and a more recent one, Juno) and it is nice to have it in one compact place. But, I have to say, I still agree to some degree with Sarah Setlzer, though I also agree with John. On the one hand there are representations and it is as important just to strut this stuff publicly as it is to claim that there is not enough female geeky representations in mainstream media. This is what John has done quite nicely. One the other hand, as he himself says ” if you look hard enough for representations of female geekyiness in pop culture, you will find plenty.” I think those words, “if you look hard enough” also speaks volumes of the continued disparity that does exist. One should not have to look “hard,” and the only blockbusters, so to speak, which feature a female geek, is Tomb Raider, which for being so hyper-sexualized is not so geeky to me, no matter how good she is with the gadgets. That said, what I find so important, and have emphasized in different contexts, is the need for what I think of simultaneous positive and negative form of critique, the former being about pointing to already exisitng examples to get people jazzed and excited and to put things in perspective. The later form of critique, negative critique, identifies a lack, a void to fill, just the type of excellent commentary in the Seltzer piece… But now for the most important question, who has John overlooked?