Venkatesh Hariharan recently wrote an article on Indias traditions of knowledge and how Open Source meshes with them. Now having met him at foss.in and knowing of his work, I am 100% convinced he is on the side of the angels and their is no malice in what he wrote. However, his interpretation (really not his, but the conventional wisdom amongst the Indian elite.) of Indian history and culture is so monumentally wrong it bears correction. While I admit my hackles were raised by the cultural and theological mistakes made, there are implications for Open Source advocacy in India and the world at large too. He starts by giving the example of Nalanda, supposedly "the first university in the world." but more accurately a Buddhist vihara (monastery.) Its' very name indicated sharing. I use the past tense because Nalanda doesn't exist anymore. In fact except in a few border areas influenced by Tibet or Burma, Buddhism itself is so thoroughly extinct in the land of its birth, the place where it flourished for over 1500 years, that the only reason people like Hariharan or myself only know that there ever was such a thing due to the work of 19th century Western Indologists. How could this be? One theory is that a resurgent Hinduism coopted or persecuted the Buddhists into oblivion. However this is unsatisfactory. It does not explain why Jainism (a religion as old as Buddhism and equally heretical for exactly the same reasons from the Hindu point of view) still survives to this day and it doesn't explain how it could have happened for even the most advanced genocidal regimes of the 20th century have been unable to "disappear" undesirables to the extent which Buddhism disappeared. A more plausible explanation revolves around the fact that, as I mentioned before, places like Nalanda were Viharas. This doesn't mean that they can't have university-like properties too; after all the great academic institutions of Europe also had religious foundations but the monastic nature of a vihara is salient. A monastery is not a place you go to engage the world, its a place you go to escape it. To mix metaphors a bit, the viharas were cathedrals not bazaars. While there may have been a lively intellectual life within its walls, there is no evidence that Nalanda and its denizens interacted much with the surrounding culture. An economically unproductive institution of such vast size (15,000 monks at its peak) could only survive by the patronage of kings and other rich people. When that patronage dried up as for example when the medieval Muslim invasions swept away the old royalty, Nalanda and its sisters couldn't survive. Just as when a proprietary software company dies, its "intellectual property" often dies with it, when centralized Buddhism died, Buddhist ideas died with it. (Luckily Buddhism had spread to other countries by then and developed new, less monolithic forms so it was not lost to the world altogether.) In contrast Hinduism (and for that matter Jainism) while having all due respect for monks were and are primarily lay movements. The pursuit of morality (Dharma), wealth (artha) and pleasure (kama) in this world are equally valid human goals alongside liberation from the world (moksha.) and this manifested as the much maligned institution of caste. Hariharan quotes the conventional view probably familiar to Westerners from Anthropology 101, a lock-step hierarchy of four classes (varna is the Sanskrt word) with fixed occupations, with knowledge and privilege on top and ignorance and oppression at the bottom. The thing is, this view bears no relationship whatsoever with social reality in India now or historically. There is another Sanskrit word, jati, which can be translated as caste. There are thousands of these jatis and while Indian thinkers have periodically attempted to try and shoehorn them into the varna framework, they have had little success and varna is for all practical purposes just a theory. And this is not just a fall from some putative golden age (Like the canard that once caste was flexible and merit based and only later became rigid.) but the state of affairs throughout recorded history.

A jati consists of people who share a common (or fictive) kinship, who have particular food and ritual choices, and marry endogamously. While many jatis are associated with a particular occupation, many others are not. This is what caste means to a typical Indian (it is also the social organization prevalent amongst Jains, Sikhs, Muslims and Christians even if they don't accept its theological basis.) Yes, hierarchy and concommitantly oppression, are in some cases a byproduct of casteist thinking but they are hardly its raison d'etre. A comparison can be made to the Western nuclear family system. Some people think it is superior to any other form of social organization. Most people wouldn't go that far but go along with it as "the way it is." Some of those of a liberal persuasion might want tweaks of certain aspects of it. A very small fringe think it is nothing more than a nefarious plot to spread patriarchy, subjugation and racism etc. They are mostly considered kooks by the other groups. (Unfortunately when India and caste are concerned, the kooks are ruling the roost.) The diversity of jatis like the diversity of open source creates a certain resistence to disruption that a monoculture cannot. Thus though Hinduism also suffered grievously from invasions, it was able to hold on where Indian Buddhism could not. Brahmin (sic. That's an English mispronounciation.) is also misinterpreted as one who knows Brahma (masculine noun. The Creator God.) instead of Brahman (neuter noun. The supreme spirit pervading the Universe.) though even then it would be wrong because Brahmin, Brahma, and Brahman all come from a common root word brhati (feminine noun. Sacred speech.) as any Sanskrit dictionary will attest. Hariharan cites the example of the sacred scriptures (Sic. He means the Vedas) and the notorious statement of the Manusmrti saying that an unqualified person who hears them should have molten lead poured into their ears as examples of the proprietarization of knowledge. Now the long-suffering untouchables may have been afraid of many things but having lead earplugs was not one of them. There is no historical evidence that any such action was ever attempted. You can criticize the Manusmrti for even saying such a thing but that is a far cry from using it as evidence of historical attitudes. You see, the Manusmrti is not even in the most orthodox conception Hindu Sharia and the Vedas are not "Sacred Scriptures" in the sense that the Bible or Koran are. Rather they are part of a wide range of significant literary works respected in Hinduism of which other important examples are the two Epics the Mahabharata (which includes the Bhagavadgita), and the Ramayana, and the vast compendia of geneologies, philosophy, lore and legend called the Puranas. Hariharan actually missed a good chance to make his point here because while the Vedas are indeed "proprietary" the other works I mentioned are not and have in fact permeated all over India and even beyond its borders. Many Indian languages owe their literary existence to translation of the epics or Puranas. For instance one of the earliest monuments of Hindi literature is the Ramacharitamanasa, Saint Tulsidas's translation of the Ramayana. When he wrote it in the 16th century, he did face some opposition from those who didn't think such an august work should be rendered into a "vulgar" tongue, he also received encouragement from equally orthodox people (including those who believed the Vedas should be restricted to Brahmins) Today it is by many accounts the most popular Hindu holy book in existence. So really the whole idea that the Hindu canon shows a fall from open grace to rigidly controlled private property is just bogus. To those who have slogged their way though all this verbiage wondering what it has do with Linux and Open Source, let me assure you I am getting to the point :-) It's bad enough from my point of view as a devout Hindu that my religion would be misrepresented this way but from my point of view as a supporter of Free Software ideals, it is catastrophic. Linux and Open Source in India has spread, as in most parts of the world, primararily as a hobby amongst computer enthusiasts and for a hobby it's doing ok. However if you think of it as more than that, as a tool to enhance society and empower peoples lives, that is not nearly good enough. But how can one serve a society if one apparently has no clue about that societies history and mores? The developing world is littered with failed projects that were carried out with the purest of motives but no regard to what the putative clients actually wanted. Do we want Linux and Open Source deployments to go the same way? For a couple of years now I've been trying to get Indian and NRI programmers to get involved in localization in debian-installer and elsewhere but even with the small minority that are sympathetic to Open Source (a scandal in itself.) it is like pulling teeth. To their credit, Red Hat India pays people to work on such things but volunteerism is the heart of the Open Source movement as we all know so the apathy of Indian IT professionals is deeply troubling. Hariharan is trying to increase interest by appealing to the Indians' sense of cultural pride which is a good tactic--it has been successfuly applied by many non-western or minority cultures--but he is not going to be very successful if the vision of Indian culture he is presenting is as alien as Eskimo culture to the vast majority of the people. Western Open Source advocates also run into difficulties due to being tone-deaf in their understanding of how third-world cultures actually operate. When India declined to participate in the One Laptop Per Child (OLPC) project, some commentators on places like Slashdot were perplexed. Wouldn't a poor country want an inexpensive yet efficient pc using free software instead of high-priced imports? The thing they missed is that while people in India may be poor, thanks to a more-or-less democratic polity and more-or-less open communications, their frame of reference is no longer their village. Their trends are increasingly set in Mumbai, New York, Paris, and London. The forward-thinking amongst them know that computers are the key to the future. They also know Bill Gates is the richest man in the world thanks to something called "Windows" knowing which can get you a green card and your own chance of becoming rich. So if Linux comes along, presented as a cheap alternative which is "just as good", the fake Gucci handbag of IT if you will, it is not going to impress. Thinkpads and Dells appeal to the upwardly-mobile persons vanity, a third-world hand-cranked laptop does not. (This incidently is what is behind the "Nalanda university" meme too. Monasteries are yesterday. Universities are the in thing so we have to have some in our past and not just any but by golly, the first university in the world.) When they venture from pure technology into the realm of culture, Open Source advocates need to be a lot more sophisticated, not to mention accurate, in their arguments lest they fall on deaf ears. Platitudes and sentimentality about "spiritual" versus "material" culture aren't enough. There must be concrete demonstrations of the benefits of why the Open Source approach to knowledge is better. They must be more sensitive in their presentation to avoid needlessly antagonizing people who might otherwise be natural allies. I believe the Open Source ideal is good for India and the whole world, not just in software but for society at large and I wish Venkatesh Hariharan and all the others on the frontlines of the fight for openness the best of luck. But good intentions cannot excuse sloppy thinking.

In response to Home video hub on a shoestring, Justin asked, “Why not just stream the media over cifs/nfs/sshfs?” Why indeed? Well, as my fellow amateur Internet broadcaster Justin Zeigler (coincidentally of the same first name) observed, “some people mistake the unix way as doing things the oldest way possible.” There are niceties streaming video solutions provide that are much better suited to solving my particular problem. Streaming puts the burden of handling different codecs and providing material at a bitrate the client systems can handle on the server. Remember, I said my client system is underpowered and the network I’m delivering across is wireless B. These constraints make streaming video the ideal solution. Now, if I only wanted to stream the music videos and other material designed to deliver over the Internet, I’d be fine with a remote filesystem. But DVDs and mythtv recordings are too demanding on my little laptop’s resources to work at all. But, just to make sure, I tried both sshfs and nfs today. Sure enough, I could stream a Quicktime music video from sshfs just fine. However, neither sshfs nor nfs could deliver the material from a mythtv recording fast enough for the client to keep up. I tried both vlc and mplayer, and both were so stuttery they were unplayable. I gave mplayer a larger buffer (32K) which cleaned up the first few seconds of play while the player read from the buffer, but after that, it started stuttering again. And this was with only one floor of separation between the WAP and the laptop, to make sure I had a solid connection. Clearly, Videolan’s ability to transcode on the fly and stream over the network is a great convenience to me. I suppose I could do a file-to-file transcode and then read the resulting file from sshfs, but I don’t find that nearly as handy as the streaming solution. So I’m sticking with Videolan, as I find it the easiest to use, most elegant solution to delivering a broad range of video material from our powerful hub system to our less powerful client system.

Hecl is a weakly typed programming language, which, for a scripting language is often an advantage. Instead of cluttering your code with lots of (casts) or performing.to_s all the time, things "just work" depending on the context (and assuming that you've verified your data or have error handling for when things go wrong). I've been pondering a weakness of this model that Tcl doesn't adequately solve, discussed here: http://sourceforge.net/mailarchive/message.php?msg_id=37354848 The summary is that if anything can and will be converted to a string at some point in its lifetime, GC'ing "complex objects" (things that can't be represented by a string) gets difficult. In order to be able to go back to an object from a string, you have to maintain a hash table with string handles that point at the actual objects in whatever language you are using, and that in turn requires that you somehow keep track of the lifetime of those objects. Doing GC in Hecl itself is something I'd hoped to avoid - up until now, we have managed to get by ok with Java's GC. The 'best' solution seems to be Salvatore's, discussed here: http://wiki.tcl.tk/13847 But even that is relatively complex, and at least initially, involves a couple of tours through the entire string-space of the running program. Unfortunately, I don't think there's really a clever way around the problem, though... what the weak typing giveth, the weak typing taketh away (or something along those lines). I am not sure what this means for Hecl at this point, whether we simply say "clean up after your own objects", introduce some sort of string typing, or something else entirely...

Edit: to be fair to the GCC crew, it seems the guy who closed me the bug to the face was not very representative of'em. Thanks to them to their very good compilation suite btw ! a bit of history I've been bitten today by a problem due to the fact that I use the gcc __attribute__((nonull(...))) as a hint in my C headers to say to the programmer that it's up to him to check if what it pass to my function is NULL, or not. I had written (erouneously) that bit of code:

/* in the .h */
__attribute__((nonnull(1)))
char *m_strrtrim(char *s);
/* in the .c */
char *m_strrtrim(char *s)
 
    ssize_t len = s ? strlen(s) : 0;
    while (len > 1 && isspace((unsigned char)s[len - 1]))
        len--;
    return s + len;
 

I've added the __attribute__((nonnull)) by mistake, and indeed sometimes used m_strrtrim on strings that I knew to be NULL. The point is, gcc is able to use the nonnull attribute to optimize code, and that's very legitimate. In my case, it optimized the s ? strlen(s) : 0 into strlen(s). And without surprise, it caused segfaults. I had a hard time finding that bug, because I've never thought that it could come from the header. As it could not come from the m_strrtrim function, I've looked very hard for stack overwrite and so on in the caller, but even valgrind did not catched anything interesting (except an invalid read size of 1 in strlen). It's when (in order to see if it was a gcc optimization bug) I've generated the preprocessed source that I saw the damn prototype in the preprocessor output, and that was suddently obvious to me why it segfaulted. the wishlist bug Since it was quite an unusual problem, that can make you loose a lot of time, because the bug lies very far from where it's revealed, I've opened a wishlist bug in gcc to ask for a warning when you test some pointer against NULL that you should already know to be non-NULL. like the warning about always true (or always false) comparisons for e.g.:

size_t len;
// ...
if (len >= 0)   ... // always true
if (len < 0)   ... // always false

That's gcc bug#30043. Or I should say was. My bugreport has indeed be closed a first time as INVALID, because the reader thought I said the gcc optimization was not legitimate (*sigh*). I reopened it explaining more precisely that I only begged for a warning, not for anything else, and that YES I DID READ THE DOC. The bug has just been closed as WONTFIX this time, with an explanation that still makes me stare at it with a blank look:

I don't think a warning is the right thing in this case because the developer should have read the documention [ ]

WTF !? If reading the documentation can make you a perfect programmer that never do any mistake, then god, I must be a super-mega-coder that always write perfect code ! Sadly, reading the doc do not prevent you to avoid cuts (aka segfaults) when you juggle with razorblades (aka code in C). I can understand that it's hard to do in the present state of GCC, and that's it's not an urgent feature, given how peculiar that request is. But I'm completely stunned to see that a guy that is in the compiler business just consider that a warning is useless, and that the documentation is the key answer. I use an over-long compilation line in my projects ^{[1] [2]} especially because a compiler is really better than me to catch many kind of errors. And it's vital to do so. I've seen too many people that only compile with gcc -g -O2 and optionnally with -Wall when they don't forget it. But from a guy in the compiler business, well, that's just yet-another-illusion that collapses.

It’s now possible to dynamically link web data into Google spreadsheets. For example, stock information can be pulled in via the simple formula GoogleFinance(ticker, attribute), where attribute can be any number of metrics from market capitalization to P/E ratio. Not much to choose from yet—at this point, there’s only GoogleFinance and GoogleLookup, which seems more novelty than useful, and I’d love to see more than just the obvious metrics available for GoogleFinance, things like cash per share, revenue growth over the past m years, number of insider purchases over the past n months, etc. However, it’s a great start, and it’s pretty easy to see where they’re going with this—after all, most spreadsheets are inherently linked to external data sources, though I’d wager a majority of them are “linked” via copy and paste. I look forward to the day when you can pull in all manner of structured information into a spreadsheet via similar formulas. To me, this is the real value of “Office 2.0″. To compete, the office challengers have to go beyond just copying Microsoft Office on the web—success will come from exploiting the new platform, not cloning the old model. Pretty easy to see something like this grow into a platform all its own too. With a few more financial metrics, a slightly more powerful macro language, and the ability to connect to more arbitrary data sources (say, Google Base or the CSV files my bank makes available to me), I could track my finances on the web in a Google spreadsheet and give Quicken the boot (for what I want to do, Quicken is like driving a nail with a sledgehammer). Update: Google spreadsheets has an API now too.

I read The @ Book by Patrik Sneyd from ascii64 last Wednesday. It tells the story of the @ (at-sign) and elaborates on all kinds of (sometimes seemingly un)related topics such as spam, software patents, Michelangelo, morse code, etc. using either symbolic images or short texts. This booklet with a really nice layout is a refreshing read during a break. @:)

According to today’s BNA Internet Law News:

12 STUDENTS EXPELLED AFTER FIGHT PLANNED ON MYSPACE
A dozen high school students were expelled for an on-campus brawl over who got invited to a party, a fight school officials said was arranged on the social-networking hub MySpace.com. The school board in a St. Louis suburb voted unanimously to expel the students through the end of the school year for the Nov. 9 melee.
http://www.siliconvalley.com/mld/siliconvalley/news/editorial/16123433.htm

If Fight Club were made today, Tyler Durden could perhaps have saved himself a lot of trips.

Scripting a gui tester for Tuxpaint with xautomation was fun and quite useful too, but really only appeals to developers. Today I found use for xautomation that will appeal to sys admins and users: hacking around a user interface that refuses to work the way it ought to. I wanted to add another mythgame player, this time for the pcsx-df Playstation emulator. Unfortunately, I couldn’t pass it a CD image from the command line. It seems to know only how to do two things: run a game file, or run a real CD. My best guess is that it doesn’t know its plugins until the GUI starts, so it is unaware that it ought to be able to use the cdrmooby plugin to load the specified image when it is parsing the command line. After a brief and fruitless grep through the source, it dawned on me that I could put xautomation to work for me to do the job in much less time. Here is the resulting startpcsx script, which sucessfully operates as my pcsx mythgame player.

#!/bin/bash
slowtype ()  
   echo "$@"   sed -re 's/(.)/\"str \1\"\n\"usleep 15\"\n/g'
 
pcsx &
xte "sleep 2" "keydown Control_R" "key o" "keyup Control_R" "sleep 1" 
slowtype "$@"   xargs xte
xte "key Return" 

The hard part was that pcsx is afflicted by one of my pet peeves, a typeahead find that cannot be disabled. As a result, if you make xte type at full speed into the open file dialog, the filepath comes out all jumbled up. This happens because the filepath is constantly being redrawn as xte types characters, so the cursor isn’t always at the end of the line. The usleep 15 allows the cursor to reach the end of the line before typing the next character. Of course, this is truly a hack, subject to variations in timing between systems, so if you use it, you may have to tweak the sleep and usleep values. But it works well enough as a workaround until pcsx-df is fixed to accept a CD image on the command line.

One of my tasks for today was to upgrade to the new versions of the JanRain OpenID libraries for Wikitravel. However, since those libraries implement the draft OpenID 2.0 standard, which includes support for i-names, I had to do some i-names playing today. i-names is a distributed system, with different "i-brokers" (yes, they're really called that) providing naming services. Unfortunately, the service that I used for registering my i-name, 2idi, isn't compatible with the JanRain Open Source libraries I'm using. JanRain's implementation depends on the very latest version of the OpenID 2.0 draft, and 2idi doesn't support it yet. So testing with my current i-name, =evan.prodromou, doesn't work. So, I had to register a new i-name with an i-broker that supports the new draft standard, which, y'know, it's the whole point of this stuff not to have to register all over the place. But whatever. JanRain folks in #openid, the OpenID channel, let me know that i-brokers that use EZ iBroker, a kind of i-broker-in-a-box package, would work with their library. The best one I could come up with is LinkSafe, which works OK. Now, rather than spend another US$20 and register a variant on my given name, I decided to spend the US$55 get an organizational i-name so I could make as many different testing names as I needed. And rather than register an i-name for a real organization, I registered just a bogus one, @gratis, so I could give them away to whoever wanted an i-name. My new i-name, @gratis*evan.prodromou, works great. If you'd like an i-name to play around with, please drop me a line using the Web form at @gratis, and I'll set one up for you. I've toyed around with it, and it seems to work for sites that support i-names. tags: i-names 2idi janrain openid ibroker linksafe gratis

La ka I met my friend Nicolas Ritoux at La ka, the wireless-enabled lounge on St. Laurent. We hung out at the bar and had a beer or so, which was a nice way to spend the early evening -- of course, it was an hour after dark when I met him, but just 5PM... We talked a lot about his projects working on a new version of Hyst rie, the classic Quebec Web zine, formerly hand-coded in HTML but soon to be implemented in a CMS. He's using SPIP, a cool-looking French jobby that seems to have a lot of features. He's really getting into the XHTML+CSS aspect of it... a sure sign of madness. I like La ka, but it didn't dawn on me until today that it's named after Laika, the Soviet cosmo-dog that was the first living thing intentionally launched into space by humans. Good dog! tags: laika niko montreal

Movie night I had to rush back to the house pretty quick, though -- our friends Patti and Meg offered to babysit Amita tonight so Maj and I could go see a movie. Awww! Of course, given that opportunity to have a romantic evening with my beautiful wife, what did I decide to go see? Borat, of course. We were pretty worried about the baby -- she's been kind of feverish and cranky for the last few days -- but when we came home, she and Meg and Patti were dancing and twirling around the room. Good girl! tags: amitajune meg patti borat movie night

C default str* functions have very poor semantics, and a whole lot of consistency problems. That's a fact, a well known one. For those who still don't know them, and only to cite a few:

• strlen returns a size_t but *printf functions returns int's;
• str* cpy,cat returns a pointer to the destination, which is useless;
• strncat can returns things that are not strings (because not NUL-terminated);
• ...

A good string API MUST treat any string as a buffer + its allocated size (not len, I said size, meaning including the terminating NUL). Moreover, it should return informations that avoid the stupid problem of strcat that has to compute the destination length again and again. There is one function of the usual C string API that has it right, if you forget about the int return type problem: snprintf^[1]. Why ? because:

1. it prevents most buffer overflows because you always pass the buffer size;
2. unlike strncpy the resulting buffer contains a true NUL-terminated string;
3. it returns the size the string could have had if there was enough space in the buffer, so that a correct reallocation can work with reduced programatical costs;
4. if you support negative buffer sizes, you can chain as many of those calls, and be safe !

and if you want a proof that it makes code more concise, just go read that patch. EDIT: Here m_strcpy is a function that respects the 4 previous points: m_strcpy(dest, dlen, src) copies src into dest like its brother strcat, but in a buffer of size dlen, and returns in fact, src length, la snprintf. And if you do m_strcpy(dest, -1, src) it does not breaks, so that I can use it without needing to check if my virtual result length overflowed or not. With those functions it's just obvious how to build new ones with exactly the same semantics. For those who wonder, yes I've forked mutt the hard way, and am trying to deobfuscate its code (I was shocked to see how bad it was given how I like mutt as a MUA). And here what you see is that this string API semantics is very easy to use, is safe, and extendable. For example, in that patch, rfc822_write_address and rfc822_write_address_single that did had the bad property to truncate the result without any way for the caller to know that now use the usual snprintf semantics for no pain at all. with those API no need to care about the ending '\0', or about off-by-ones, you always speak of buffer sizes, and when your current virtual write position in the buffer is pos, you just need to call pos += your_strXXX(buf + pos, buflen - pos, ...) and you'll be safe. If you want to know if a realloc is needed, you just have to verify if pos >= buflen, the same as what you have to do for snprintf. I really wonder why such API are not common in the C world, I see way to much code using the usual C string functions that just are a PITA.

As previously announced, I plan to have an open house on these days. If you happen to be in Munich at the time and, as Matthew puts it so well, if I haven't wished you dead in the last three months, you are invited. There is going to be infrastructure as can be found in a typical home, such as space, electricity, network, a shower and a kitchen. I have a few mattresses as well, but the usual sleeping gear is probably a good thing to bring anyway. I plan on stocking up on noodles and tomato sauce before the event, and there is a Chinese restaurant with an all-you-can-eat offer just downstairs, so I believe food is not going to be an issue either. I expect the entire event to be mostly geeky in nature, given the people who are invited. I think some might see it as an opportunity for another bug-squashing party, while others see it as an excuse to devote a full day to their pet project. If you're planning on not bringing a computer and just generally hanging out and socialising, that's fine with me, too. My personal plan for the weekend revolves around a bunch of software and hardware projects, most of which being related to cool hardware. I have a soldering iron here (25W only, but it works), so you are welcome to bring a hardware project as well. If you plan to come, it would be nice if you could drop me a short message so I won't be off to the video rental store when you arrive, plus I can tell you more details then, like where exactly. Also please tell me whether you prefer sitting on the floor/some mattress or on a seat with a chair, as it allows me to allocate the space accordingly in advance so that we don't have to move people around. The fine print: this is a non-smoking flat (and the wind conditions do not allow smoking out of the windows), we're on the 6th floor and it's the beginning of winter. While it is certainly possible to smoke outside, it might be something to consider.

I attended the Cooperatives SW annual meeting in Taunton on Monday 27 November because it covers the new home of Turo Technology. Sadly, headline speaker Dame Pauline Green was unable to attend, but someone else from Cooperatives UK (I think it was John Goodman, but I can't find a name in my notes) gave the keynote presentation about the current state of the cooperatives and current trends. Among the figures, there was the pretty astonishing Global 300 which lists the biggest 300 cooperatives and mutuals in the world. The list contains some names I didn't expect and also some names in different positions than I expected. Some things are less surprising: almost every country has agricultural cooperatives and the UK (with mutual insurers, building societies and credit unions) and France are particularly strong in financial cooperatives. Apparently, the Global 300 will be updated as and when results are published, so watch that space. More items from the Cooperatives SW meeting soon.

David Nusinov says:

when a prominent DD gets busy in his personal life, we don't say that his personal life is trying to kill Debian. Similarly, when a prominent DD gets hired somewhere and gets very busy and he doesn't have as much time for Debian, we don't say that the employer is trying to kill Debian.

Going to work for on a Debian derivative is a bit different from going away from Debian to spend time as a new father/mother, or working as a MSCE, or whatever. If things are done right (by the employee, by Debian, by the employer), work spent on Debian derivatives can benefit both Debian and the derivative. I believe this even happens in many cases. One other point: Looking at the whole Dunc Tank debate, I guess hiring some people to work on Debian directly (which is just what I might do if I had spare cash in large amounts) wouldn't necessarily improve matters a lot, it'd just shift the debate (ah, he's trying to buy Debian...). Myself, I'm not entirely sure if the existence of Ubuntu is good or bad for Debian. More attention to .deb-based distributions is a good thing, certainly (I was astonished to see in a local bookshop that Ubuntu and SuSE were the only boxed Linux versions you can buy. No Fedora, nor Mandrake, nor Xandros or any of the others.) OTOH it would certainly be nice if more people would use (and then report bugs and start to help fixing them) Debian itself. But I can't see this happening anytime soon with our community as it is now. And then there's the 'it's good enough for us' and 'we don't want no steenking newbies' lines of thought. While I don't agree with the first one, I admit that finding a compromise between a newbie-friendly and gadget filled system for desktop use and a rock-stable professional tool is not easy. Two different sets of install CDs might be worth a try.

Argos are a total pain. Their web site is unnecessarily complicated. If you want to do the basic action of buying something then you need to have a browser with all the trimmings and relaxed security, but even then, you might not be able to find what you want where you want to buy it. When will people wake up to the fact that Sometimes amateurish websites just put you off entirely... [Digital-Scurf Ramblings] Odeon seem to have finally got its act together - I don't agree with their priorities, as the extra investment in the web site seems to have been balanced by reducing newspaper advertising, but I can finally find film information with any browser I've tried so far. Does that leave Argos as Britain's Biggest Bad Online Retailer?

Rob Myers commented:

"Since all CC licences allow NC copying and distribution, any DRM that limits copying in any way is a breach. Or any DRM as it is also known. And since the CC licenses all support fair use and DreAm (an oxymoronic idea that I thought had died of lack of interest) restricts it, that's another problem. Not to mention how harmful electronic enforcement of CC licenses would be."

That's an argument I've heard from several CC supporters, but I don't accept it: fair use is inconsistent globally. What is fair use in the USA might not be fair dealing in England, or the other way around. As to whether any DRM is possible under CC licences, there's the small matter of Lessig's "praise for better DRM" which seems to acknowledge the existance of TPMs that restrict in a CC-OK way. Rob continues:

"Mako's arguments are a rehash of ones that were considered in depth when the debate was happening. Terry covered most of them [in an article on a magazine web site]"

Maybe the points Mako presents were considered, maybe they weren't, but it's very hard to tell from the limited transparency of CC. I think the points are clear, direct and difficult to argue against - that may be why it's so hard to get a good debate with CC about this. What's more, Terry Hancock's article is a rehash of his old list posts. I think Terry's points were all covered in mailing list discussions and they don't even try to make a case for the TPM-ban in CC-BY. I like recycling, but it's disappointing to see people use the press to recycle old threads. Also, I don't find it particularly surprising if someone writing for a magazine web site isn't entirely comfortable with some forms of redistribution. Rob finishes with:

"And I would add that, as someone who has installed GNU/Linux on my iPod, who has recently read the Yellow Dog Linux announcement for the PS3, who uses their PS2 as a CD and DVD player, and whose son seems to get MP3s, images and movies onto his PSP OK, I do not understand the argument that the best way of "helping" users is to help third parties trap them under DRM regimes rather than assisting users in installing and using free software."

Maybe that's not understandable because it's not an argument that's used, except as a straw man by pro-format-discriminators? Personally, I think it's a pretty poor show that you have an iPod, PSP and so on - weren't Apple's and Sony's DRM-mania well-known when they were bought? Which brings me on to why I feel locked-media distribution is worthwhile: educating people to make better device choices next time. I bought an Ogg player this time - hearing Cory Doctorow's talks as MP3 was partly why. If CC 2.0 had had an aggressive-patent ban similar to CC 3.0's TPM ban, maybe that wouldn't have happened.

Have you ever had a need for a large number of "real" network interfaces on a Linux box? For security reasons, you don't just want to hook everyone up to a single switch and use virtual interfaces (because it's too easy for one of the connected devices to play silly buggers with his neighbours). Up to a certain point, you can stuff more NICs into a box, and when it fills up you can switch to those outrageously expensive 2- and 4-port NICs. But eventually you're going to run out of space[1] or money. At that point, you need something more interesting. For me, this week, that "more interesting" has been Ethernet VLANs. Linux Journal has a good intro to the technical aspects of how to setup VLANs and Linux. VLANs are some crazy stuff. They're implemented by wrapping a little number around every Ethernet frame indicating which VLAN the packet is "on", and the switch (you need a higher-end device, appropriately configured) makes sure that packets don't roam onto ports they're not meant to be on. For a single switch, this isn't very interesting, and you don't really need an IEEE standard to make it work -- just a lot of little jumpers. However, VLANs are mostly useful on larger networks, which tend to use more than one switch. So you need a way for your VLANs to roam amongst your switches -- hence the packet tagging. You stick the tag onto the packets and fling them off to another switch, and packets coming in with the tag are corraled into their VLAN. Naturally, you don't want end-user devices whacking their own VLAN tags onto packets (untrusted data, and all that), so you define most of your ports as being "untagged". Packets that come in on these ports are treated as regular ethernet frames and tagged with the appropriate VLAN ID, and packets that go out have their VLAN IDs stripped before being sent. (This implies that you can tunnel VLANs in VLANs, and I'm pretty sure that is doable in most switches, modulo some nasty problems that can, and probably will, occur). The ports that aren't designated "untagged" spit out tagged packets -- and this is where my interest lies. Like most every other computer-related standard, Linux can decipher and work with VLAN tags (the 8021q module is what you're looking for). You just load up the module, hook your NIC into the appropriate port on your very expensive switch, define your VLAN tags with vconfig, and suddenly you've got vlanN interfaces, which map to real RJ-45 ports, and you can hang network devices off these and get lots and lots of "real" network interfaces on your Linux router. It's all so simple, right? Nothing ever is, of course. The trials and tribulations I've had over the past two days have included:

• Not being able to talk to the switch via serial console (so I can configure the damned thing). Turns out the cable I had wasn't a null modem cable, and the switch needed one (the documentation was contradictory on this point, so we started off with the regular kind and a gender-bender -- which should have been my first clue). So Jaycar got ten more of the company's dollars for the proper cable. After that, all was well, and I could find out that...
• The console interface is horrendous on the switch I've got, at least for defining VLANs. I just enabled the (slightly less hideous) web interface, and used that instead. It still sucked, but it sucked less.
• Once everything was configured and the test rig all wired up, I spent about 20 minutes plugging cables into various ports on the switch and watching a distinct lack of packets flowing. It turns out that new VLAN trunks (the technical term for "a port that gets all VLANs, with tags still attached") on this switch get configured as "disabled". Yes, of course that's what I want -- it's overwhelmingly likely that I won't want to use that new trunk I just configured. Sheesh.
• The first NIC I used as the VLAN interface on the server (a Tulip-based home brand thing) didn't play nicely with the VLAN packets. As you'd expect, the extra bytes for the VLAN ID need to be a part of the packet -- and that size is normally limited to 1514 bytes (1500 bytes of payload plus a 14 byte Ethernet header). Adding the VLAN tags increases this by 4 bytes. Although some NICs comprehend the utility of supporting VLANs, and will handle these oversized 1518 byte frames, others don't. This NIC just didn't want to handle it. The symptoms were large pings just disappearing (they didn't show up in tcpdump on the destination interface). As I've had to track down MTU problems in the past, and it's always painful, I wasn't keen on introducing a known one right at the start, so this had to be rectified.
• The next NIC I tried (a Netgear FA311 -- uses the natsemi driver) had a fantastic failure mode. Packets arrived having had their VLAN tag stripped -- so the 8021q module didn't know it was a VLAN packet, and couldn't drop it into the appropriate vlanN interface. I know everything was otherwise alright, because ARP packets were tagged to the VLAN fine, but the ICMP packets that followed weren't tagged. Scratch that one off the list.
• The third NIC was an RTL8139D. The driver didn't even recognise this card, which confused the hell out of me. It turns out that this particular card (PCI ID 1904:8139) isn't a real RTL8139 (despite having RTL8139D and the RealTek crab printed on the chip) but is rather a dodgy knockoff (some might say "as opposed to the dodgy original?"). Why anyone would bother to knock-off the world's cheapest ethernet chipset, I have no idea -- if I were an electronics counterfeiter, I'd go after something expensive, like a 3Com card. Far more profit.
• The fourth NIC, a real RTL8139D, worked like a charm. I know it isn't exactly the most fantastic NIC on the market today, but I don't have any 3x59x or eepro cards around, so this'll have to do for now.

Thankfully, once all those dramas were done, the whole thing just kind of fell into place, and now I've got a machine which has up to 2048(ish) network interfaces (with huge, glaring caveats on that upper bound, of course). With a bit of luck, the live installation in a couple of days will go smoothly. You can stop sniggering now.

---

1. In this case, there wasn't a lot of space to begin with, as it's a 1RU box I'm working on, and the 4-port NIC didn't want to place nice with me for some reason anyway.

In our family, we have centralized all our best entertainment technology in a single system, a white box amd64 with PVR, 3D graphics, 1G, a 21” monitor, DVD burner and VCR. A number of older, far less capable systems have always surrounded this “hub”. A K6-2/400 with a less-than wonderful ATI Rage IIc graphics card presently serves as my wife’s system, and my PII/300 laptop roams the house on wireless B. This has always been the model for our home network, dating back to the late 90’s when the hub in our cramped apartment was a P/100 delivering sound through a $30 pawn-shop stereo to two main rooms, and the satellite node in the family room was a DEC VT-420 on a long serial cable. So, house-wide delivery of sound has always been possible. But doing the same for video remained unsolved until just this weekend. Kudos to the Videolan team for making it possible. A number of years ago, I recognized their vlc player was ideal for playing DVDs on my K6-2, handling the job with less CPU and less frame drop than other alternatives at the time. Not too long afterwards, though, we upgraded our hardware so saving CPU cycles was no longer an issue, and switched to other players to take advantage of features they offered over vlc. But a recent email from a friend brought me back. This friend asked if I had seen a certain Linux documentary video he had found. I hadn’t, and was intrigued. But since the hub was tied up by the kids at that moment, I figured I’d try watching on the old PII laptop. I didn’t really think it would work, but remembering how well vlc did on my other old hardware, I gave it a try. It worked! No frame drop at all. Buoyed by that victory, I recalled that I had downloaded the Debconf 6 DVD ISOs some days ago, but had not yet been able to watch them. You probably can guess why … yup, the single hub system, the only one really capable of doing a good job displaying video, was pretty much always tied up by various other family members. Now, I knew there was no way I could get those DVDs onto the laptop, as it has no drive and only a 4G hdd. Nor was I willing to go to the bother of ripping individual tracks to transcode and send over one at a time. But I then recalled that vlc, as well as being an excellent standalone player, is primarily the client for a streaming video system. So I set out to learn how to stream video. Back when I was first introduced to Videolan, I knew there was a server program, vls. I had a quick look at that and was overwhelmed by the wide variety of possible MRLs and codecs, and a bit mystified as to which magic spells were needed to make it stream to the laptop. It then occurred to me I had probably plunged in too quickly, and should back off and go look for more docs than just the man pages. Sure enough, they have plenty of excellent docs, leading to the discovery that the vlc gui itself has easy to use Wizard and Open dialogs to set up streaming. With that sorted out, I was streaming in no time. At this point, I was delighted to discover that I could successfully stream a 1024 kbps mp4 stream across wireless B form the basement to any other room of our two-story semi. And ever since then, I’ve been having great fun with the family, trying a wide variety of other video sources lying around: music videos, home videos made by friends, TV shows recorded from the PVR, DVDs direct from disc, and yes, finally, those Debconf 6 ISOs. I tell you, it’s like Christmas come early! Thanks, Videolan. You’ve made my week.

I spent a while on IRC today, rare for me, and one of the repeatable topics of conversation was showing mugshots of people in chat. I wrote a trivial /showface command for irssi which just spawned mozilla to show a hackergotchi from planet.debian.org and that was neat. However it suffers from the problem that you cannot spawn a graphical application from inside Screen easily. So I came up with a cunning alternative: using the DBUS notification deamon. So now I have face.c which uses wget to download an image, then dbus to display it. Compile it like this:

apt-get install libnotify1 notification-daemon dbus
apt-get install libgtk2.0-dev libglib2.0-dev libnotify-dev
	
gcc  pkg-config --cflags gtk+-2.0  \
     pkg-config --cflags glib-2.0  \
 face.c -lnotify -o face
	

Now copy the face script to drive it and you can run /showface skx and it will show you my image. Neat hack. (I suspect it will fail if I logout of X and restart - then reattach to screen since my DBUS identifier/session will be different. But I’m still pleased that I didn’t have to quit the currently open screen session and I can make graphics appear from within it) Update: now with caching and error detection. It will also disable itself for channels not matching ^#debian*

On big IRC channels, it'd be easier to remember people if it would be possible to attach a picture to the nick. Something like this would make a possible implementation without changing the IRC protocol: one could define a URL pattern for each network and channel, and the client would look up the picture using the pattern. So for #debian-devel, I could have a pattern http://planet.debian.org/%s.png, and then the hackergotchis would be used, if they existed. (Later, perhaps, a http://mugshots.debian.net/%s could be created, for all Debian people.) I've no idea how to present the pictures in the UI properly, without making the text lines too sparse. I'll leave that for someone else to figure out.