While I appreciate the research and legal commentary over at Groklaw, the tendency of PJ and the regular posters to imagine vast conspiracies makes me more than a little uneasy. Yesterday I came across a truly jaw-dropping example that would be offensive if it wasn't so laughable; and since I happen to know more about the situation, I felt I should comment on it:

I have some questions about this group, BELUG, who did the article, I gather. There is no info on the site to be more informed. Anyone in the Seattle LUG know anything about this new group in Bellevue, 5 mins. from Bill Gates' house?

...

I don't like to be a cynic, and maybe they are a Linux user group, but if so, maybe the Seattle LUG can give them a hand.

Of course, we all know that the Microsoft corporate campus has an enormous mind-control ray mounted on Building 1 that turns everyone living on the Eastside of Seattle into mindless Gates-worshipping zombies. Part of Bill's personal security plan, dontchaknow. That's why BELUG starts every meeting with a round of "All Hail Gates, Lord of All That Is Electrified".


She goes on to complain about "major confusion" in their description of free software. At a quick read, I can only see two glaring problems with this page: first, they describe free software as being both "free in a monetary sense" and able to be sold (which is actually true but sounds like a contradiction without more explanation that they don't provide); later, there's some weird wooly-headed stuff about revolutionizing entire economies and societies. I don't know what they're talking about, but they certainly can't be accused of lacking enthusiasm.

Finally, she quotes a section of the FAQ that suggests that Microsoft professionals should learn Linux and vice versa, since the world is heterogenous and getting more so. I don't think that's controversial, so I think she must be referring to this question:

Q: Why does BELUG dislike Microsoft?

A: That is a complete misunderstanding. BELUG does not dislike Microsoft. Microsoft is our neighbor, and many of our friends and relatives work there. Both Microsoft's headquarters and Bill Gates' house are located just minutes away, and Microsoft's world sales headquarters is currently under construction nearly adjacent to BELUG's meeting location. BELUG merely believes in friendly competition and that competition can benefit everyone, including Microsoft. This is what a free market economy and the American system is (supposed to be) all about, and this is what has helped make the U.S. a great country.

The statement that Microsoft is nearby is nothing but geographical fact (I could walk about fifteen minutes from my apartment and be on the MS campus; does that make me an MS mole?).

As for the rest, I really don't see anything to complain about. I know some people like to rhetorically shred Microsoft at every opportunity, but if you're trying to attract members in Microsoft's hometown, it's wise to keep your comments polite. It's also true that Microsoft benefits from competition (even if they don't see it that way); I don't think it's a coincidence that their products started sucking drastically less as OSX and Linux became reasonable alternatives to Windows. And the fact that we can have friendly competition (as opposed to the cut-throat, take-no-prisoners style that's popular in some quarters) is exactly one of things I like about Linux. You will notice, however, that the Q&A carefully doesn't mention what sort of competition Microsoft engages in. I think anyone who knows anything about the company knows the answer to that one.


Here's the kicker, though: I actually attended a BELUG meeting a few months ago. It seemed pretty much like what I'd expect from a small group of volunteers: one guy gave a talk about hooking ALSA up to a digital audio receiver, another guy showed off a Unix kernel he had written for classic MacOS (it ran as a user process and presented a Unix-like interface to the Mac), someone passed around cookies, and people talked a bit about using Linux and so on.

The poor quality of the Web site and the lack of a mailing list probably reflect the fact that there are a handful of people organizing the thing who all have day jobs and other committments, not some vast Microsoft conspiracy to undermine Linux from the inside by setting up fake LUGs. PJ never said they were fakes outright, but it was a clear subtext of her comment, and the Groklaw regulars who replied knew exactly what she was getting at. If she really thinks they might be fakes, then I think she needs to take a break from watching SCO (which could make anyone paranoid and suspicious) and enjoy the holiday season instead.

Last Friday, Mark Shuttleworth posted a big troll he also sent to the OpenSuSE mailing list. While the Novell/Microsoft deal has raised many legitimate concerns, I really think the Canonical leader should take the mote (in France, that would be a beam) out of his own eye first. As expected, the reactions from OpenSuSE developers were strong. But I was really shocked by two of them. According to JP Rosevear, Mark Shuttleworth is, among other things, preventing the Debian GNOME maintainer from updating GNOME packages until after Ubuntu LSO had shipped because [he has] hired him, and trying to simultaneously supplant Debian's community with "Ubuntu" while relying heavily on the Debian community to be successful. According to David Canar, Ubuntu's anti-community practices are well-known. Yes, I was shocked to see these reactions. Not because of their strength, as they are perfectly justified. I was shocked to see that developers in the OpenSuSE community seem to be better informed than Debian developers about Canonical's dealings. When talking with random fellow developers, I see many of them who truly believe Mark Shuttleworth when he says he's just doing the best for Debian, despite everyday's proof of the opposite in Canonical's employees actions. Shouldn't we be concerned at all about Ubuntu sucking the blood out of the Debian project? It strikes me that OpenSuSE developers care more about it than ourselves.

This is the shortest debian/rules file I've ever written:

#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk

Yes, that is the complete debian build file. CDBS can very clearly say "nothing special in this package". Everything else in this package is handled by debhelper defaults. Granted, this is a very simple package. But thats what I like about CDBS: don't waste my time (or the time by someone reading the debian/rules file) when it is standard stuff.

A few months ago I finished Play Money by Julian Dibbel and like his My Tiny Life before it, the writing style is simple yet sumptuous, or I guess just simply sumptuous. Like the travel writings that pre-figured anthropological writing, Dibbel takes us to a far-away exotic land (but only a click or two away) that are populated by a motley crew of wizard (or is lizard)? slayers, gold-diggers, money-makers, and virtual-world-builders. For many, these MMOGsare no strange-lands but are becoming weaved firmly and intimately into the fabric of everyday life, whether as entertainment, sociality, and or for a cadre of folks, as a source of income generation. I think the book has gotten enough coverage that I don’t need to rehearse its content in any detail but the basic story is that Julian embarks on a real world quest in the virtual land of quests to try to make enough money (to be specific make a little more than his monthly salary as a freelance writer) from trading and selling a slew of virtual objects and gold. In taking us along, he gives a compelling entry into the imaginative and morally complex world of these games. And better is that whether you know nothing about them or are a seasoned player, the book has much to offer. One of the reasons I respect Julian Dibbel is because he takes his sweeeet time to churn out a book-length manuscript. In a day and age when there is so much pressure to release quick and often, especially when writing about anything in the so-called virtual plane of existence, he waited nearly 8 years from the publication of his last book on gaming, My Tiny Life before publishing on a considerably higher-tech phenomenon. Following him on his most recent adventure, you learn that he threw himself into a variety of gaming environments persistently and consistently and did at least 3 years of research and writing (at one point in the book he confesses how excruciating writing for him, which is hard to believe as the words slip so nicely off the paper but whatever the extent of his writing angst is, he clearly spends a lot of care in crafting his sentences). And I am starting to think that if more people followed this ethic of long-term immersion, coupled with slow-brewed productive sparsity, we would get higher quality products (Yes, kinda like the Debian release cyclce). Like any good ethnographer, he gives an intimate portrait of life in these worlds of copious play where various types of real world economies have mushroomed apace with new technological developments. That is, he gives us a taste of what it is like, as he cleverly puts it to own unreality. Couched within tales of gaming gone real world economic, are hearty reflections on the place of play in social and economic life, the close resemblance and conceptual affinity between computers and games (and not just computer games, and here he does a fantastic job at explaining the Turing Test), self-doubts about writing in general and in particular about this topic, commodity fetishism, and the changing nature of capitalism in a world of ever-greater abstractions. All of this makes for an enjoyable read that if used in the classroom (which like A Tiny Life, I am sure will become standard for courses on Virtual Worlds) allows you to bring in some good supplemental material whether Edward Castranova’s Synthetic Worlds, Greg Lastowka and Dan Hunter’s The Laws of Virtual Worlds and or older heavy-hitters like Max Weber and Karl Marx. The only topic I think I would have liked to seen included is that of capitalist finance, because there are, I think, some real affinities, phenomenologically and conceptually, between finance capitalism and gaming the virtual game. Otherwise some of my favorite sections were on hackers and the object of the computer, but of course, I am biased that way. So here I leave you with a tasty morsel of something that was sumptuous to ingest: It is this endlessly repeatable collusion of freedom and determinism-the warp and woof of fixed rules and free play, of running code and variable input that sets both games and computers apart, together from the larger universe of information technologies they inhabit…. But only games share the universal machine’s game’s thoroughgoing commitment to the principle of recursion: the chained repetition of simple operations, each building on both the input of the moment and the outcomes of preceding steps. And only games, therefore, come close to capturing that precise mi of unpredictability and inevitability that makes the computer such a powerful simulator of our lived experience of the world. p. 104

I think there's a certain special sloth that Americans get to experience on the day after Thanksgiving that we don't get on other parts of the year. Something about the combination of gluttony and wholesomeness makes Black Friday a very mellow, enjoyable time. Maybe it's the fact that it's officially now The Holiday Season, but the stressful tasklist of December hasn't started yet. Or maybe just that it's a day off of work for no good reason except it just is. Maybe it's the fridge full of leftovers that still taste kind of good. I dunno. We had a good Thanksgiving dinner yesterday evening. Maj, Amita June and I had planned to go visit family in New Brunswick (New Jersey) for the holiday, which was really nice to do last year. But our visas are running out in December, and although we're (probably) not going to have a problem renewing them, our lawyer said it was a bad time to leave the country. So, we stayed in Montreal for Thanksgiving. Canadians have their own Thanksgiving, of course, on the 2nd Monday of October, but not having grown up with that day as Thanksgiving, and with most of our family celebrating in November, it's hard to get motivated around Canadian Thanksgiving. And it's just not that big a deal in Quebec, anyways. So we had a good dinner here; John Usher, Niko, Jeff Waye, Meg and Patti all came over and had a good time of it. I cooked my first Thanksgiving dinner -- a big salmon, potatoes and sweet potatoes, roasted broccoli and wax beans, a great big salad. Every family has a Thanksgiving dish tradition -- one of the Prodromous' is a big pot of macaroni and cheese. So I made that, too. We all ate pretty well, drank some wine, talked about the future of music and how fun it is to play hockey. Unfortunately, I managed to miss my Blinky Hockey practice last night -- I tried to put the (overtired) baby to bed at 10PM and ended up falling asleep myself. All in all a good TG, even though far from family. tags: thanksgiving family montreal black friday dinner canada

Speaking of home All of Canada is abuzz right now about a recently-proposed bill by the ruling Conservative Party in Parliament to declare the Quebecois to be a nation within Canada. Sovereignty of Quebec has been an extremely contentious issue in Canada over the last 50 years (two sovereignist parties are major players at the federal and provincial level), and this form of recognition is an interesting step. The whole thing began with Michael Ignatieff, a candidate for the leadership of the opposition Liberal Party. He has stated publicly that Quebec is indeed a nation, and his followers are pushing to have that be part of the Liberal Party platform. The sovereignist Bloc Quebecois tried to steal their thunder by introducing a bill in parliament to the same effect. Their thunder was in turn stolen by the Government with the latest bill, which now has the support of all the parties and will almost definitely pass. The wording of the bill is interesting. First, it calls the Quebecois a nation -- the people themselves, not Quebec qua territory or government. Although the government has stated that this includes all people in Quebec, it's still pretty obviously targeted towards recognition of an ethnic group, French-speaking Quebecois, more than everybody who's living inside the borders. Second, it recognizes this group as a nation within Canada -- deflating the suggestion that it may become an independent state. I have to admit that the ambiguous nature of Quebec's status is one of the things I find fascinating about living in Montreal. As far as I can tell, few sovereignists hope for anything like a total split with Canada, but instead are looking for some sort of autonomous status. On the other side, even the staunchest federalists have seemed comfortable with granting Quebec more of an international profile, such as giving Quebec a formal role in UNESCO. My guess is that the nature of Quebec's relationship with Canada will change gradually until it reaches some stable point where everyone's comfortable. I don't know where that stable point is, but I think it'll be interesting to find out. At the turn of the 20th century, if you had told people that the British, Austrian, Turkish and Russian Empires would be dissolved and almost forgotten within 100 years, they would have scoffed. But in that short span of time, the idea of empire, spheres of influence, and Great Powers has passed from the world stage. We simply don't think in terms of Empire any more, but in terms of nation-states. My guess is that the 21st century will see a similar change in the idea of nation-state. With pressure from supranational organizations like the UN, EU, GATT and the International Criminal Court, as well as pressure from unrecognized nations like Quebec and Catalunya and Wales, I think the firm borders of the nation-state are going to loosen up a lot. What it will mean is anyone's guess, but I think if we're lucky we'll have a richer tapestry of nations and people participating in global politics and culture. And I think Quebec will be an important part of those changes. tags: quebec nation autonomy nation-state

Thanks, Biella! I'm glad to see that Biella is going to give us the goods on PR. Our Wikitravel 2007 Get-together is going to be on the island of Puerto Rico, and Biella's from there, so she's going to make up a list of good places to check out. Great news! tags: thanks biella coleman puerto rico wikitravel

About 18 months or so ago I released the first version of XmlIndexer, a general purpose XML indexing web service based on Mono and Lucene.Net.I'm happy to announce now version 0.4 of this software which, thanks to improvements in Lucene.Net and patches from the Beagle hackers, is a lot more stable. Previous versions had some nasty locking issues that could kill the server quite dead.XmlIndexer is a simple indexer. Given a rulefile that maps XPaths to Lucene keys, it can be taught to index any XML file you should care to give it. I use it to provide search functionality to legacy applications, which then need only to expose their data as XML and call a few simple web services to perform a search.Of related interest is the new Apache Incubator Solr project, which provides a fancy search server based on Lucene, doing the same as my indexer, and much more.XmlIndexer requires Lucene.Net version 1.9.1. For extra points, apply the locking patches from Beagle to Lucene.Net before building. As a courtesy I include a Lucene.Net DLL I made this way in the download.Download: searchxml-0.4.tar.gz

There has been an interesting thread on the debian-isp mailing list talking about control panel software for virtual hosting. I’m biased against several of the available control panels, but there are certainly times when I wish there were a simple solution or two which I could try that didn’t involve throwing away all my current setup and migrating all at once mail, web, etc. I’ve ruled out several systems due to :

• Lack of roadmap.
• No support for software I like
  • exim4, for example.
  • No simple way to customise modules enabled on a per-domain basis. (PHP is icky and I don’t want it.)
• No real predictable support, or development activity
• Security issues
• PHP issues.

Every now and again I think about updating my hosting scripts such that they could be driven by a graphical control panel. But each time I get this thought I decide against it because:

• I too mandate certain software and that might not sit well with potential users.
• Most of the hard parts of a control panel are the GUI/presentation
  • I suck at making “pretty” interfaces/sites.

The other reason not to do it is that I have a system which is portable, well understood (by myself at least!) and isn’t hard to migrate away from if I wished in a piecemeal basis.

Wow...This time I'm truly amazed. A spam just hit my debian-devel mailbox. That's sadly not strange at all, I know. Only that I started reading it. It says:

Spammers don't seem to target us for their random alias generation
tools, or        maybe they haven't got to the letter 'o' yet. com
for subsequent posts, but that whole barn door thing comes to mind.
In so doing, values are overlooked often and mistakes are made. Maybe
Microsoft will let me        change my alias.
Maybe some of it would actually be useful to me. For whatever reason, my
Microsoft email address didn't ever get        spam.

Then it goes on talking nonsense splattered with all kinds of garbage talk, some news (or whatever) about stock options of a China Health thing, and goes on throwing nonsense blabber.
Sorry, I'm not linking to it (I'll probably later update this entry), it's still not available in the Web archive of debian-devel.">

There has been a lot of interest recently in the VFX VoIP service launched by WorldXchange (WXC), no doubt partly driven by the fact that there is no monthly charge until April 2007. I had a spare Linksys PAP2T so I thought I would try the service out to see how it performed. The signup process didn’t go anywhere near as smoothly as it did when I signed up for my WXC DSL connection. The online signup form tried to force me to select a new WXC DSL Plan (I don’t want to do that, I want to keep my old plan with free National traffic). Despite trying several times and making sure that the only checkbox ticked was VFX each time, it refused to let me go any further. Giving up on the web form, I rang the WXC helpdesk who answered promptly. It is easy to see why WXC won the 2006 award for best call centre. Every time I deal with them over the phone it is a pleasant experience. This time was no exception. The CSR I was talking to explained that the webform was dying because I tried to use a VFX username that differed from my WXC DSL username. There was no mention of this restriction on the website! Anyway, 15 minutes later, with my MAC address taken down and my voice recording completed, I was told we were all done and that I would receive my welcome email and account details with 2 working days! 24 hours later I received the email with the details, followed promptly by a phone call from WXC CSR who was ready to talk me through the process of setting up my PAP2. Configuring the PAP2 was a simple procedure, I had to copy and paste a URL into the Provisioning Rule field of the web interface and reboot the device. It then downloads configuration information directly from WXC (based off the device MAC adddress) and configures itself. I was up and running with dial-tone about 2 minutes after receiving the email. Very smooth. I understand that the process is even easier if you purchase a pre-configured PAP2. The downside to the whole scheme is that in trying to make the process as simple as possible WXC has locked the entire system down very tightly and remove a lot of the flexibility that I would desire. In particular my PAP is now completely locked, I can’t access any of the web interfaces, and even the dial-in prompt on the PAP2 replies with a curt “cancelled” before hanging up. There is no way for me to configure the second line of the device to talk to a second SIP provider. Apparently WXC will create a custom configuration for me so that I can still use the second line, but I imagine this requires giving them all my account details for my second SIP provider, which I’m not sure I’m comfortable doing. It also appears that WXC has an arrangement with Linksys such that every PAP2 now sold in New Zealand comes pre-configured to be used with WXC. I haven’t had a chance to look at one of these PAP2s yet, but if it were to turn out that I had to contact WXC to remove the locking on my PAP2 before I was able to use it with another VoIP provider I would be fairly annoyed. The MyVFX portal is very underwhelming. It insists on opening itself in a new browser window, and isn’t integrated with the rest of the WXC/VFX website. From what I can make out it’s just a branded frontend on to the management system that WXC has purchased. The user interface is reminiscent of the design of the 1990s. I think there is a lot of potential for WXC to improve the experience in this area and I doubt that the average user would be comfortable updating settings via MyVFX in its present state. On the technical side of things the VFX service seems to be fairly well designed and secured. The devices are provisioned and configured using the Linksys/Sipura provisioning tools, which appear to encrypt all conversations with the device. The setup process downloaded two configuration files and a firmware file (v 3.1.10) to my PAP2. Both of the configuration files were binary and appear to be encrypted. Interestingly it appears that WXC downgraded the firmware from 5.1.1 to 3.1.1 during the provisioning process. The MyVFX portal and SIP server appear to be using some sort of BroadWorks device. The device fetches it’s configuration file from the WXC server every time it is powered on, so it will be easy for WXC to push out updates and configuration changes as they desire. The VoIP side of things is performed using SIP, which appears to be using standard HTTP Digest authentication. The username and passsword for this being hidden inside the encrypted configuration files which are downloaded to the device. The voice data uses the G.729 codec inside an RTP stream, and from a few short calls seems to be relatively good quality. Conclusion
Overall, VFX seems like a very easy to use and simple service. Simple being the keyword. By locking down the devices so securely and preventing people from using softphones and devices other than Linksys equipment I imagine many people like myself are excluded from the potential market. I can’t see myself keeping the service after I have to start paying money for it. But I would definitely recommend it to friends and family who are looking for a simple, easy to use VoIP system.

Debian Jr. development revived Recently there has been some lively discussion on the Debian Jr. list about how to arrange an account for a child of 1 to 3 years of age. Suggestions included using set-top box software like Freevo, tailoring DEs with panels and large buttons, using simpler WMs like fvwm, or using an “activity centre” app like Gcompris. Now, I respect those parents who hold that a child this young should interact more with the “real world”. While I wouldn’t go so far as to outright prohibit my young ones from computer use, I can see the wisdom in keeping it to a minimum. But, for better or worse, our family is one of several who have some experience helping our youngest members use our Debian systems. We would like to share what we’ve learned through the Debian Jr. project. Getting started with live.debian.net To that end, last week I was inspired to follow the Debian Live ISO Howto to produce my first rough draft of a Debian Jr. live CD built from scratch on Etch. For the final product, we’ll want to use a local partial Debian archive mirror, as it not only optimizes fetching packages for several build iterations, but also can be kept stable, which is important as we near release. But for this draft, I ran into trouble building the complete package list to populate the partial mirror, as cdebootstrap, which make-live uses, has no handy --print-debs switch like debootstrap does. So for now, I rely on approx to cache packages for optimization only. A straightforward process to create a working live CD The rest of the process was straightforward: using live-package, I created a package list¹ containing Gnome and the Debian Jr. metapackages, I configured /etc/make-live.conf to point at my proxy, and then I ran the make-live script on the package list. The end result was ./debian-live/binary.iso, which successfully booted under qemu. At this stage, there is not much to show. To be truly useful, the live CD needs to be set up so that children and their guides can immediately find and use the material intended for them. We will need not only one live CD user, but four, varying in age range and role. (More about this in a future article.) However, it is an encouraging start, and shows that we may be able to produce something usable by the time Etch releases.

¹ For this exercise, I simply combined /usr/share/make-live/lists/gnome with the junior-* metapackages in Etch, and added mozilla-firefox-gnome-support to satisfy Gnome’s web browser dependency and cut down on redundancy, resulting in the following list.

junior-art
junior-doc
junior-games-card
junior-games-gl
junior-games-net
junior-games-sim
junior-games-text
junior-gnome
junior-internet
junior-kde
junior-math
junior-programming
junior-puzzle
junior-sound
junior-system
junior-toys
junior-typing
junior-writing
mozilla-firefox-gnome-support
eject sudo
console-common locales
gdm gdm-themes gnome-desktop-environment gnome-cups-manager gnome-screensaver
gnome-themes-extras
rhythmbox synaptic
x-window-system-core

According to this article, also referred on Slashdot, an European Union project has been developed aimed to check if streets free of any traffic signal or other rules are viable. Seven cities and regions are involved, no one of them in Spain. And I hope things to stay as now. Perhaps this can work in those civilized cultures in which people try to respect others rights. But I am 100% comfident that this won't work in Spain. If people does not respect signal even if they are there and can be fined for not following them, I don't want to imagine what will people make if there are no signals and no rules. The most used motto will be: "And who the ***** are you to tell me that I can not do this?". yay!

Steinar H. Gunderson wrote about CDBS once again, and I couldn’t agree more. CDBS introduces a lot of complexity for non-trivial packages, and it especially is basically undocumented. So what is CDBS’s value? For non-trivial packages, it is hard to use, since you basically need to decipher the CDBS code. For trivial packages however, it doesn’t add much value over dh_make. That’s actually sad: I like the general idea behind CDBS, but it is implemented badly IMHO. What it should do, if implemented right is to automate anything you want done on an easy package while providing and documenting (which includes consistently named hooks and options) all the interfaces needed to maintain non-trivial packages. Ideally, this would even include packages which need multiple build runs (like providing two differently configured versions of the same binary in two packages). But as said: It would need consistent names and proper documentation, and CDBS fails both currently. I however hope this improves in the future. Don’t ask me to work on this however, since personally, I’m quite happy using debhelper on my packages, since it is removing complexity (not typing work or lines of code) from debian/rules while keeping it obvious from that file what is done during a build. I would really like to see the reasoning from Erich on why he thinks CDBS is NMU-friendly, since I don’t get why he thinks so from his blog post.

Dear Lazyweb,

Today I had a philosophy class and we discussed hermeneutics. But I didn't understand a thing. Not that I ever understand much of what my philosophy teacher says, but I just don't get hermeneutics.

Yes, I've looked it up on Wikipedia, and I've read about it in a book. But I still don't understand. The language used to describe hermeneutics is complicated and weird, and just doesn't make any sense to me.

What I've grasped so far is this: Hermeneutics is a methodology and/or epistemology used in the humanities and, to some extent, the social sciences. Hermeneutics is about interpreting texts. A text can be a literary text or something else (like a film, painting, or perhaps even reality). When you read a text, you need to read it several times and perform "close reading" of the parts. A text consists of the parts and the whole, and somehow they relate to each other, and you need to understand the parts to understand the whole and vice versa (I have no idea what this means). Hermeneutics is also some kind of way of describing reality (epistemology) which differs from the natural science in that it seeks to understand things rather than explain them. In the natural sciences, or the logical positivist tradition, knowledge is sought by explaining cause and effect (at least that's what my teacher says). Proponents of hermeneutics argue that this method does not apply to the humanities. Hermeneutics also employ something called the "hermeneutic circle", which means that you understand a text better the more you read it.

But I don't understand this method. What's so special about reading a text several times? What's the deal with close reading, why is it that good? What kind of knowledge is gained by this method? How does it differ from simply reading a text any number of times and then write an essay about what you think and feel about it? The parts I understand about hermeneutics are only trivialities. Also, there seems to be some kind of rules when you read the text. Like, you need to observe the characters one time, and the plot the second time, etc. Who decided that? Why is it necessary to follow these particular rules, if they exist?

Most importantly, exactly why is hermeneutics a scientific method? To me it looks merely as a practice of reading texts and writing essays about them. These essays are of course subjective; they don't generate any objective knowledge in the natural scientific sense. I'm not saying that it's wrong to write about literature, I just don't understand why a certain method of doing it is considered more scientific than any arbitrary method. In the natural sciences, there are criteria of intersubjectivity, independent testability, verifiability, falsifiability, etc. I see nothing of the like in hermeneutics; I don't know any of its scientific criteria. Apparently you need to refer to specific parts of the text in order to justify your statements (opinions? theories?), but it is a rather vague criterion, and I don't understand the rationale for it.

Another thing is the epistemological side of it. Somehow, hermeneutics is a general theory of knowledge. How that could be I don't know. Why would, for example, a close reading of a text give us the answer to questions like the distance to a particular star or human effect on global warming? Maybe that's not what hermeneutics is intended for. But if it is claimed to be a general theory of knowledge, it should be able to answer those questions in some way.

Maybe all this is just me being stupid or zealous. Or maybe I'm not thinking clearly -- I'm suspecting that I've not been thinking clearly lately. Perhaps I'm refusing to understand out of mere distaste or frustration. My classmates suggested something in the line of that. Perhaps it's because I've read physicist Alan Sokal's brilliant satirical article "Transgressing the Boundaries: Toward a Transformative Hermeneutics of Quantum Gravity", and I am now allergic to the language used by academics in the humanities.

If someone could enlighten me on these issues, that would be much appreciated.

Steinar H. Gunderson even threatens kittens because of it, and Steve McIntyre ranted against using CDBS for packaging, claiming that it's much harder to fix bugs in packages that use CDBS. I have to disagree. More than once I've given up on fixing a bug in a package because I couldn't decrypt the huge makefiles used for building the package. For private packages I often switch over packages to CDBS then, so I don't have to fiddle around with a build system noone except the original maintainer understands. And every now and then I fix a bug in Debian, but don't upload it because I replaced the "magic" build system with CDBS magic... While CDBS does a lot of "black magic" to build packages, it usually does quite a good job. If it doesn't, it maybe even is a bug in CDBS, that happens. debian/rules files that use CDBS are usually quite easy to read, even easier than traditional debhelper template-based scripts. And that is why I think that CDBS is a good thing: it does a good job at separating package-specific and package-independendant build scripting. Maybe all we need is more documentation on how to properly fix common issues in CDBS, starting with misplaced or misnamed files etc. CDBS has a lot of hooks, but it's not obvious which hooks to use for which fixes. (Note that sometimes the fix should maybe be done in the upstream makefile instead.) On the long run, Debian could use a more unified way of packaging. Debhelper has already unified package building a lot, and CDBS maybe goes one step too far, but ideally we would all be able to understand each others debian/rules.

Ian Rawlings wrote in an article in uk.comp.os.linux that:

"There was a legal precedent set in the UK a little less than a year ago, in which the company's name and contact details in an email signature were taken as sufficient identification of the company for the contents of the email to be acceptable as a contract [...]"

and then helpfully provided some references about it. The headline on Disclaimers could make emails into contracts [The Register] seems a bit off. Even the article ends:

"The end result of this could be that people who include a signature and disclaimer at the bottom of their emails might actually be making themselves more liable than people who just send one line emails."

Note the might there. It's quite a leap, isn't it? Mehta v J Pereira Fernandes SA [2006] EWHC 813 (Ch) (07 April 2006) appears to have ruled that headers were not a sufficient signature, rather than that a plain text signature block (sig) is sufficient. Have I missed a key point here? AFAICS, the ruling contains the following key general points:

"28. I have no doubt that if a party creates and sends an electronically created document then he will be treated as having signed it to the same extent that he would in law be treated as having signed a hard copy of the same document. [...]"

"30. [...] if a party or a party's agent sending an e mail types his or her or his or her principal's name to the extent required or permitted by existing case law in the body of an e mail, then in my view that would be a sufficient signature for the purposes of Section 4. [...]"

I doubt that a sig is quite the same as a hand signature, as it doesn't necessarily 'serve as a method of authentication' as required by the Digital Signature Directive ( 1999/93/EC, Electronic Signatures Regulations 2002), but there are times when it could bind one to things. Essentially, using a sig is like using headed paper, not like hand-signing. Parts of the ruling (para.19) seem to argue that automatic insertions make things carry less weight AFAICT - does that hint at how futile those forced stupid disclaimers would be if relied upon in court? Does the same automatic-or-decision point also mean that using a electronic signature tool (gpg or whatever) selectively helps it carry more weight than signing everything automatically? I don't agree it ... signs death warrant for Digital Signatures [Financial Cryptography] Interesting questions. Anyone know if the answers are decided yet?

(For the grammar Nazis out there: no, that apostrophe is not misplaced)

---

There are times when a connectionless protocol almost doesn't seem worth the hassle. Take, for instance, the troubles of a round-trip communication, using UDP, where the initial request is sent to a secondary IP address on an interface. Your code, on the server, might look like this:

 s = UDPSocket.new
 s.bind('', 12345)
 loop   data, remote = s.recvfrom(65535); s.send(data, 0, remote[3], remote[1]  

This is a pretty simple Ruby fragment which just reflects your UDP packets back at you. It really doesn't get much simpler than that. Connect to this thing from somewhere else (using nc -u remoteip 12345) and you can reflect packets back and forth to your heart's content. Or so you'd think... When talking to a regular IP address, your packets probably look something like this (when viewed using tethereal):

 192.168.0.1 -> 192.168.0.2 UDP Source port: 35716 Destination port: 12345
 192.168.0.2 -> 192.168.0.1 UDP Source port: 12345 Destination port: 35716

Fantastic -- I send a packet, and get one back. In netcat, you see whatever you typed printed back out again. But, what if I add a secondary IP address to the server's interface (ifconfig eth0:1 192.168.0.5, for instance) and try sending packets to that IP address (with nc -u 192.168.0.5 12345)? I get this insanity:

 192.168.0.1 -> 192.168.0.5 UDP Source port: 35772 Destination port: 12345
 192.168.0.2 -> 192.168.0.1 UDP Source port: 12345 Destination port: 35772

And of course, no self-respecting network stack is going to accept a packet back from a totally different IP address, even if it did manage to get the ports right. Hence, the client never sees the return packets, and thinks that the server is snubbing it. What's happening here seems insane, but it's actually just a regular artifact of a connecntionless protocol like UDP. You see, we've bound our socket to the "any" address (the empty string in the call to #bind tells UDPSocket to bind to the "any" address -- no, I don't know why either, it's not a particularly intuitive interface). When we get the packet into our app via #recvfrom, we get no information on what address the packet was actually sent to, only that the OS decided that the packet was for us (yay for encapsulation). The only information we get is where the packet was coming from -- and due to the fact that the kernel keeps no connection-related information around for the socket (the kernel figures it'll hold us to our connectionless pledge), when the time comes for us to send a packet back, we have to explicitly say where we want that packet to go -- that's the remote[3], remote[1] arguments in the #send call. The brain-leakage starts when we work out where to say the packet is coming from. When we send the packet, a source address needs to calculated -- again, the kernel keeps no information on source or destination because we're connectionless. Because our socket is bound to the "any" interface, the OS thinks it has carte blanche to set whatever source address it likes. In Linux, the behaviour appears to be to pick the IP address set on the primary alias for the interface that will be used to send the packet out on. So for the common case (one IP address per physical interface) everything is fine. But those corner cases, gee, they're awfully sharp and pointy... The solution, of course, is to send the packet out through a socket that is bound to the particular address you want to use as the source address -- then the kernel knows what source address you want, and there's no confusion. Seems pretty trivial, right? Surely every sensible network application does that already, right? So obviously Ruby's UDPSocket implementation just sucks. That's what I thought, and I don't blame you if you think so too. But before you raise pitchforks and storm the gem-covered castle, try repeating our little experiment with some other widely-used UDP-based applications, such as net-snmpd or your ntp server. (The NTP server is a little different, in that to trigger the problem you need to start it and then setup the interface alias, for reasons I'll explain later). Both net-snmpd and ntpd exhibit the same behaviour as our trivial UDP echo service -- at least, the versions present in Ubuntu Breezy do, although I can't imagine everyone's suddenly cottoned onto this problem in the last 12 months or so and come out with a rash of fixes. So, basically, everyone seems to be suffering from the same malady. For values of "everyone" that equal "some UDP servers". There's some services that don't seem to have such troubles with alias interfaces -- the Bind DNS server comes immediately to mind, and ntpd works fine if you start the NTP server after you setup the interfaces. Why the difference? These services are clever and bind to each IP address on the system separately, like so:

 $ netstat -lun  grep :53
 udp        0      0 192.168.0.1:53          0.0.0.0:*                          
 udp        0      0 192.168.0.5:53          0.0.0.0:*                          
 udp        0      0 127.0.0.1:53            0.0.0.0:*                          

This is very cool, and solves the problem, except that if you add another interface after you start Bind, it doesn't pick up the new address, and you're boned until you restart the daemon. It also increases code complexity a bit, since you need add a select into your request handling loop (instead of just blocking on the #recvfrom call, like I've been doing thus far). Whilst I'm never happy about unnecessary complexity, I'll deal with it where I have to, but the real killer for this application is the "you can't change your interfaces after starting the daemon" rule -- my particular need is to make requests to a virtual service IP address, and restarting my service after each IP address change is going to suck hard. I mentioned ntpd earlier because it has some extra trickery at work. It's list of bound interfaces looks like this:

udp        0      0 10.6.66.6:123           0.0.0.0:*                          
udp        0      0 192.168.250.6:123       0.0.0.0:*                          
udp        0      0 172.14.16.6:123         0.0.0.0:*                          
udp        0      0 172.31.62.1:123         0.0.0.0:*                          
udp        0      0 192.168.37.179:123      0.0.0.0:*                          
udp        0      0 10.64.64.64:123         0.0.0.0:*                          
udp        0      0 127.0.0.1:123           0.0.0.0:*                          
udp        0      0 0.0.0.0:123             0.0.0.0:*                          

It listens to every IP address explicitly plus the "any" interface. I'm not quite sure why, either -- just listening to the specific addresses works for Bind, and if you add an interface alias after starting ntpd, it exhibits exactly the same problem as the trivial UDP echo service, so I don't think that listening on "any" is really gaining it anything. Listening on "any" does make ntpd behave differently to Bind: with Bind, if you send packets to an interface that wasn't available when Bind was started, it just completely ignores you (because it lacks a socket listening for packets to that address), while with ntpd the packets hit the "any" socket and suffer from the wrong-source-address bug. At the moment, my best chance of a solution appears to be to follow Bind and ntpd's lead and hook onto every address, but with the extra twist inspired by ntpd -- listen on the "any" address as well as all of the specific addresses. If I use any packets that arrive on the "any" socket as a trigger to rescan the available addresses (to add any new addresses that have been created since the last scan), that should solve all my problems. Now I only need to make it work (and deal with the insanities that will no doubt result). Wish me luck. The screams of pain and frustration you hear (no matter where you are in the world) are probably mine.

I've decided it's been enough. Rock has been running 2.6.12 for ages. Not because I didn't want to upgrade, but since 2.6.12 was the last Debian-packaged kernel that would actually boot on rock. You see, this machine is a rather old SMP system, and there seems to be something wrong with its interrupt system. It would boot if I used a uniprocessor kernel instead, but then it's pretty silly to have a box with two processors, and only use one of them... At first I ignored it, assuming it would get fixed some time soon. Unfortunately, that didn't happen. And since we're at 2.6.18 right now, and the kernel team has done away with uniprocessor or SMP-only kernels, that means I can't even upgrade to the latest kernel anymore, even if I'd want to. I've been using git-bisect for the last few days in an attempt to find the issue, so that I can report it... only today I realized that I did remember 2.6.13 not to work, but that perhaps it failed for reasons not related to my current problem. Downloading that package from snapshot.debian.net and verifying showed that this is, indeed, the case. Grmbl. So I had to start all over again... Not fun. After starting that, I suddenly found out that make-kpkg didn't want to be friends anymore:

LC_ALL=C make-kpkg --initrd --config oldconfig --rootcmd fakeroot kernel-image
exec debian/rules  DEBIAN_REVISION=2.6.13-10.00.Custom  INITRD=YES  ROOT_CMD=fakeroot  kernel-image 
debian/ruleset/targets/source.mk:34: *** target pattern contains no  %'.  Stop.
wouter@rock:/usr/src/linux-2.6$ 

Hate. Grmbl.