I'm still browsing around (Google doesn't want you to google for such things, but "search", remember?) for a laptop to buy next, when my thinkpad finally dies (or I need to be mobile again, which might be in some weeks). I've found another wishlist candidate: the Panasonic Toughbook T4. It's small and tiny, extremely solid, it needs no fan, has a touchscreen (and you can carry it book-like, since it's light and comes with a hand strap) and extreme battery life. Apparently it does actually run over 9 hours in third party benchmarks. But it also has some drawbacks:
There are next to no reviews, especially no information on Linux compatibility (which shouldn't be an issue, embedded Intel graphics, and very little hardware in it, but e.g. the touchscreen might or might not work) - and it's not very widely used or known. It's also very expensive (Thinkpad X60 1500 Euro, Toughbook T4: 2500 Euro with the two big plusses for me being better battery life and the touchscreen, thats too much) and said to be quite ugly. I sent an inquiry if there will be a successor with maybe a Core CPU - I don't know if there is an ultra low voltage core - or if there will be a version without windows (it's expensive enough, I'm going to use Linux, I don't want to pay 200 Euros for Windows). I got a quick reply - that my questions will be answered when a certain colleque is back from vacation... This probably means that despite me loving the idea of being able to read papers on the laptop just like with a real book (with a pen, and as mobile), another candidate has dropped off my list... Guess I won't be buying a new laptop until my old one is completely dead and then I'll be going for something used and cheap as "temporary" solution... I guess I'll browse the web for the HP tc4400 and Toshiba M400 next. I didn't actually intend to go for a tablet PC, but apparently these are more designed for weight and power consumption than regular notebooks with their nvidia and ATI power wasters. P.S. Yes, I am aware of Thinkpads. But they are either to heavy for my liking, have too bad battery performance or have too low screen resolution (X series).

This blog should serve both as a reminder of the planned BSPs around the world the upcoming weekends and as a proposal for some tasks to tackle then. At this point there are two “real-life” BSPs planned for this weekend, 08th-10th September in Vienna (Austria) and Z rich (Switzerland) and another two BSPs planned for the weekend 15th-17th September in J lich (Germany) and San Cristoba (Venezula). If you would like to attend one of these parties, you can find additional links regarding these events here. First a few necessary words on coordination: #debian-bugs on irc.debian.org will be the main channel for overall coordination. Do not hesitate to ask there before tackling any task; there will certainly be people available that can advise against tackling problematic tasks or tasks already worked on, and give general advice. When working on specific bugs, please claim them or let a DD claim them for you. See also here for list of claims. Tasks that can not be expressed by a claim but are big enough to warrant a notice for others should be noted on http://wiki.debian.org/OngoingBSP or pages linked from there. There should be plenty of bugs for all levels of complexity, programming language or legal skills and time requirements. So if you never attended to a BSP before and want to help, now is the right time to start. The RC Bug Squashing HOWTO by Steve Langasek gives a good introduction and is probably a must-read for beginners. But don’t hesitate to ask questions in #debian-bugs, we will be eager to help you to do some work. Non-DDs can also easily contribute by creating patches and/or testing existing ones. Just send them to the related bug report, a DD can easily pick it up from there. See also the end of this mail for a list of useful links. Procedures:
During the BSPs we should use a 0-Day NMU policy again, that means uploads that fix RC bugs that are more than a week old can be uploaded directly. If you feel unsure about a patch and/or if the patch is rather invasive, please consider asking on #debian-bugs for review and/or giving the maintainer some time to react by uploading to the DELAYED queue. If you are unsure whether your package upload might break an ongoing transition, PLEASE speak up on #debian-release and ask for advice there. Help Etch forward:

• RC-Bugfixing. One way to help is fixing release critical bugs. Here you can find a list of RC bugs affecting Etch.
• Test the installer. d-i beta3 was just released recently and should be tested by many people to help the people working on it judge whether it is a worthy release candidate (they sure hope it is See the Debian Installer Website for more information on how to get it, known issues, etc.
• Test Sarge->Etch upgrades. This is particularly useful with “real” systems since you might notice problems that will never occur in more or less clean chroots (hint: there is no one saying you can’t use a copy of your real system
• Verify Release Goals. As one of our major release goals is pervasive IPv6 support, all network related applications should be able to work with both, IPv4 and IPv6. If you have the possibility to do so, please test IPv6 integration in all packages you use and report bugs to the BTS or even better, fix them.
• Translate. There are quite a few .pot files out there waiting for you. Debian’s l10n website is a good starting point. (If you’re new to l10n and/or new to l10n in Debian, try to find someone at your BSP or on IRC to guide you through the first steps. This helps avoid wasted effort and frustration.)
• Fix bugs in orphaned packages. In the list of packages maintained by the QA Group you can find all bugs in orphaned packages, free to be squashed by anyone.
• Fix bugs tagged “help”. This this list.
• Fix bugs in your own packages and in packages you often use. Also help on reproducing bugs, if there are unreproducible.

I personally will attend the BSP in J lich and hope to see many of you during that weekend there or on IRC. Community

Some Debian developers have finally decided that it's time to get things done and solve the trouble around cdrecord. They've taken the last version that was released really free and used it as basis for their own forked project. For years there has been discussions with the author of cdrecord and current upstream maintainer of the cdrtools package that lead to nowhere. Debian's stance on software in main is that the software and its build system, which usually contains of scripts written in different languages (shell, perl, make), need to be sufficiently free (i.e. compliant with the DFSG). Introducing a build system released under a license which is said to be not compatible with the GNU GPL and which Debian developers consider problematic with regards to the DFSG was not exactly helpful. Other GNU/Linux distributions also had problems with recent versions of cdrtools, some of them were still using older versions to bypass avoid problems. In the end this new project seems to be the only path out of this dilemma of disagreements over licenses. Hopefully, other vendors will join the effort so that they can benefit from the fork earlier and more easily, and also contribute code on their own. Whether or not it'll be accepted and used, the future will tell.

Last Friday, a long chapter ended in my family's history: The last person of the immigrant generation, my great-aunt Tere, passed away, 99 years old.
My family is fully made from immigrants. From my mother's side, Polish. From my father's, Austro-hungarian. Tere, sister of my grandfather was born in December 1906 in Felszoviso, M ramaros, Transilvania (then Hungary, today Romania). Most of her family had spread over different countries by 1925 (I know my grandfather chose to become a Czechoslowak to continue his studies in Stakcin, while she and her parents moved to Budapest) left Europe by 1930 - My grandfather lived for some years in Monterrey, northern Mexico, where he met my grandmother. My great-aunt's husband had a good, stable job as a lawyer in Hungary, so she stayed in Budapest, even during the war, under Horthy's regime. She worked carrying false documents and information to help partisans and other resistence people communicate and move in the Nazi-occupied territory. She always downplayed her work during those years, but we all know she often put her life at risk for this. Her husband was detained and later killed in a concentration camp, but she was able to hide her parents.
In 1947 she was approved to get a Mexican visa, and -after 18 years of having little contact, and almost 10 years of having no contact at all- she came to Mexico, together with her parents and her second husband (who died shortly later, because of the wounds he got at another German detention center).
Anyway... My great-aunt never had any children (we all refered to her as "la t a", the aunt), but she was up to now the thread that kept together a small but very disperse family. She lived in Mexico City, as an independent woman until she was 82 years old. She moved to Cuernavaca, first as my father's neighbour, and then to the Eishel old-age home, where her brother and sister lived - and lived in Eishel for over 15 years. She didn't die of any specific illness, but as we know, living too much is bad for your health. She was a talkative woman until very recently, always very lucid. In mid April, however, she got an infection which had to be treated by strong antibiotics - the antibiotics didn't help much, and keeping them on for too long would only make it more painful. In early May, my father and his cousins decided the antibiotics should be stopped - and to let nature work. Four months later, she went away, closing a very long chapter in the family.

I spent some time this weekend reading Free as in Freedom: Richard Stallman's Crusade for Free Software, and found it quite enjoyable. It is anecdotal, much of it reminding me of folklore.org. Regardless of what you think of RMS, it's worth a read, and might just change your mind. (Full text is available here.)

When looking at 372148, I found out that my maintainer scripts diagrams had the same bug that Policy currently has. Also, these diagrams used to document a bug in dpkg, regarding the state a package was left when removed or purged; which was fixed long ago, but I had never had the time to update them accordingly. Tonight, finally, I've updated them. And I've also made my test-suite package much more tidy, so that now I can publish it for anyone to grab it, and use it to test which maintainer scripts are called in some particular case. The dia sources, the png images, and the packages I used for the tests are all available here.

On 21 August, Don Armstrong, a Debian developer, accepted my offer to serve as my delegate in handling trademark issues vis-à-vis the DCCA. As an employee of a DCCA member company, I found it wise to avoid the perception of a conflict of interest. I should stress that any such perception would merely have been conjectural, however; at no point have I been asked by anyone to put my thumb on the scales, as it were, and deal with the DCCA or any of its member organizations in a preferential way. It is widely understood within the Debian Project that our existing trademark policy, originally formulated in 1998, is too vague, and has not scaled well to suit Debian's much greater degree of success and market penetration (on its own, and in the form of derivatives) seven years later. However, grappling with the issue has proven challenging for Debian's membership. I believe this is mainly because the Free Software hackers that comprise our organization have tended to self-educate to a far greater extent on copyright law, and even patent law, than they have on trademark law. Recently (within the past year or so), Debian gained access via its U.S.-affiliated charitable organization, Software in the Public Interest, Inc. to a pro bono legal counsel who understands the Free Software culture. Debian's difficulty with trademark management is not unique — we have been on the other side of this problem when dealing with the Firefox and AbiWord trademarks, since we customize the codebases of these software projects in our GNU/Linux distribution, but ship them with their names (and logos) intact. It so happens in these cases that the originators of the software (who hold the trademarks) approve of our modifications. One of the essential pillars of software freedom, however, is the user's right to make modifications that the authors or rights-holders in the software may not agree with. Free Software hackers can feel, with some justification, that it is misleading to uphold the freedom of a work on the one hand (by using a copyright license such as the GNU GPL), and take it away with the other (by asserting a trademark on some essential aspect of the work, such as its name). It is true that a work can be renamed, or descriptive text changed, to identify itself as distinct from an "official" version of the work, but this in turn, it is feared, can damage perceptions of the work through at least two mechanisms. Firstly, disclaimers about unofficial status may be unnerving to users who aren't schooled in the vagaries of trademark law, in which — at least in the United States — you are expected to aggressively defend your mark lest you lose a future infringement case you bring against a well-heeled defendant. Users may mistake strident proclamations of unofficial, unendorsed status in a piece of software as a warning that it is unsuitable for use, or has known severe flaws. Secondly, aggressive use of trademarks, or even just the tension observed above between giving with a copyright license and taking away with a trademark license, may lead some distributors to rename a work, obscuring its origins to the casual user. This can happen pre-emptively, before a distributor even knows whether the modifications they have made (or think they might make in the future) have met with any objection from the trademark holders in that work. The "freedom to fork" (i.e., make a derived version unendorsed by the original author) is an essential part of Free Software, and while Free Software hackers' sense of community generally leads them to eschew forking in favor of compromise and consensus, occasionally a fork ends up growing the userbase or improving the overall quality of the Free Software landscape. A hacker may fear that brash trademark assertions by an author constitute mere lip service towards the freedom to modify the work without changing its name, and may be tempted to fork it, leaving the trademark encumbrance behind. Even among those who do not guard their software freedoms quite so jealously, the fear can exist that a simple difference of opinion over some technical programming detail, such as choice of sorting algorithm or graphical toolkit, will escalate to the point where the trademark license on the work (implicit or otherwise) is withdrawn. This is the inverse of the previous situation — instead of a modifier choosing to fork a work, the original author of a work (or, at any rate, the holder of the trademark associated with it), can force the modifier to fork. The dilemma this imposes upon the people creating the modified versions — revert your existing change or be legally compelled to make an additional one — can rub people the wrong way. When forking occurs, for whatever reason, and even in the relatively benign case of "rebranding" to remove legally protected marks, the threat exists that the competitive strength of the corresponding software will be diluted. Imagine if each of four major GNU/Linux distributors rebranded their version of Mozilla Firefox, calling it instead things like "Lizardfox", "Hatfox", "Swirlfox", and "Hearstfox". How many users would deduce that the web browsers in question were all "really" Mozilla Firefox, each one with a fig leaf placed delicately over it so that the legally-minded types at the Mozilla Foundation and the distributors could wink at each other? Even the somewhat savvy GNU/Linux user may be more confused than one might expect, given that other names used for Mozilla's suite of applications include Sunbird and Thunderbird, yet there is an independent Free Software project called Firebird, which was established prior to the Mozilla Foundation's adoption of its product naming scheme. "What's in a name?", you may ask. They're important because they are simple labels we can use to refer to Free Software success stories. There's a lot of Free Software to talk about; the phenomenon of copyleft does much to ensure a competitive culture. It's difficult to achieve an unnatural monopoly in this environment, because anyone who steers a software project in a direction the users don't want to go has to cope with the prospect of seeing a group of those users organize their own community based around a derived version that does what they want. The hypothetical hydra-headed Firefox situation described above, however, is an example of false competition, because the distributors were compelled to distinguish their Web browsers for legal, rather than technical, reasons. In actuality, Mozilla Firefox is a good example of what's right about Free Software, not just because of its licensing but because a web browser is a familiar concept to nearly every computer user today. Free Software's early successes were more esoteric — GNU Make, the GNU Compiler Collection, the GNU C Library, GNU Emacs, and even the Linux kernel are not pieces of software that the general user can easily conceptualize. It is beneficial — to say nothing of convenient — to refer to the leading freely-licensed web browser as "Mozilla Firefox" rather than "a suite of mostly-compatible, similarly-named Web browsers shipped by the various GNU/Linux distributors". Those who seek to foment confusion and FUD about Free Software would doubtless capitalize on such a situation. These issues are challenging but not insuperable. A coherent policy will enable the community to establish a set of common practices, whereas now there are few conventions in the trademark arena. Ultimately, it is my hope that Debian will be able to promulgate a trademark policy that not only satisfies our needs, but serves as a model for others. To establish a successful policy, I suspect we need to build one up from basic concepts, and formulate explicit answers to fundamental questions.

• Why even have a trademark? Let's understand what protections the law affords and determine which, if any, are applicable to our endeavors. In the U.S., trademarks are managed by the federal government (rather than the states), and regulated by Title 15, Chapter 22 of the United States Code. International treaties result in trademark law being roughly similar across most jurisdictions in the developed nations, but there could exist important differences that we should learn about.
• What level of Debian involvement should be necessary for an "outside" organization to use our mark without a fuss from us? Should there be any situations where people essentially have an automatic trademark license, or should we use trademark law as an instrument to encourage (or compel) anyone trading in our name to contact us? We need to consider small-scale garage-based redistributors who simply move physical copies of our official ISO images as well as commercial derivative distributions.
• Is it feasible to apply the copyleft concept to trademarks? That is, is there some way we can turn the restrictive aspects of trademark law into a kind of compact that upholds the freedoms of a sharing community, while penalizing the activities of those who would prey upon that community?

Originally published 2005-09-14.
Updated 2005-10-15 to add licensing in comments.

Courtesy of FindLaw Legal News: WASHINGTON-President George W. Bush said Wednesday that Harriet Miers' religious beliefs figured into her nomination to the Supreme Court as a top-ranking Democrat warned against any "wink and a nod" campaign for confirmation. "People are interested to know why I picked Harriet Miers," Bush told reporters at the White House. "They want to know Harriet Miers' background. They want to know as much as they possibly can before they form opinions. And part of Harriet Miers' life is her religion." Courtesy of the United States Constitution, Article VI: ...all executive and judicial Officers, both of the United States and of the several States, shall be bound by Oath or Affirmation, to support this Constitution; but no religious Test shall ever be required as a Qualification to any Office or public Trust under the United States. Oh, well, just so long as it's a criterion, not a test. I mean, it's only essential, not a qualification or something, right?

Since I got back from the Oldenburg Linux Developers' conference, I've had my attention on our security infrastructure. Despite only being there for one and a half days thanks to a badly delayed trans-Atlantic flight, I found the conversations and collaborative spirit heartening. The bad news is that what I had planned for a writeup got rendered obsolete soon after I returned to the United States. Things have been changing rapidly, but mostly for the better. We've got three machines in the DNS rotation for security.debian.org now, which is superior to the one we had before (you can use the command dig security.debian.org to inspect the DNS record). My thanks go to our security and system administration teams for recovering from the recent overload problem provoked by an xfree86 package security update. Being somewhat familiar with that package, I can understand how its large size combined with Debian's ever-growing userbase starved the security host of bandwidth. Secondly, while I was in Oldenburg, Joey Schulze gave me a lot of insight into what a challenge one particular package is — the thing sucks up at least half of his time, dwarfing all other stable security update efforts. You've probably guessed that this package is the Linux kernel. Due in part to its success, and in part due to OS kernels being inherently attractive exploitation targets, the Linux kernel is getting a significant amount of scrutiny from a security perspective. Taking Red Hat Enterprise Linux as an example, we can see two advisories in the past two weeks: one on 28 September and one on 5 October. The one on 28 September addressed eighteen (18) different vulnerabilities as catalogued by MITRE's CVE project, and the one on 5 October — that's one week later — addressed fourteen (14) vulnerabilities, of which eight (8) were distinct from the previous advisory. (There was some overlap because the earlier advisory was for Red Hat's Linux 2.4.x kernel series, and the latter was for the 2.6.x series.) Those Debian developers who have ever handled a security vulnerability in one of their own packages can likely imagine the labor burden this is. Then reflect that Debian ships and supports a lot more Linux kernel trees than Red Hat does — this only magnifies the problem. The good news is that a team of developers focused on stable kernel security updates has been established. One of its members said to me today that he has seen a "very positive increase in kernel-related security activity". It is too soon to declare this problem resolved, but I perceive no lack of talent or dedication on the part of our developers. I am there to assist them in resolving the organizational and workflow issues so that our users can see the fruits of their energy directly. Similarly, I'm interested to see how the security.debian.org round-robin arrangement holds up after a reasonable period of real-world loads, particularly since I expect kernel package updates to sock the machines about as badly as an X Window System update. These issues are not over and done with, so an announcement declaring these problems vanquished would be premature. At the same time, the developers and users at large need to know whether or not people have their attention on them. I am wary of leaders or managers who declare issues resolved too soon, or proclaim optimism that later turns out to be unfounded, and have sought to avoid this vice. I apologize if I have tacked too far in the opposite direction. I perceive progress in this area. Let me know what you think, what you need to see, and by what metrics you measure progress and accomplishment on the security front. You can reach me at leader@debian.org (the address is already blitzed with so much spam there seems little sense in obfuscating it). (After getting some feedback on this entry, it's my intention to post it with any applicable revisions to the debian-devel-announce mailing list; please take this opportunity to "patch" this "beta", if you're so inclined.)

Planet Debian readers, please accept my apologies for the re-post of the old entries on Lynndie England and Lester Crawford. Lars Wirzenius and Mark Brown helped me figure out that having spaces in my directory names (for categorizing entries) was a bad idea because PyBlosxom doesn't have sense enough to perform proper escaping of the contents of link elements in the RSS it generates. No doubt this confuses aggregators the one used by the Planet, which seems to more or less muddle through. Anyway, I changed the spaces to underscores, and while the timestamps of the files within the directory didn't change, that was enough to make all the entries contained in it look new again. A quick glance at PyBlosxom's source leads me to believe it's pretty crude about escaping and substitution issues generally. Anyone wanna go over it with a fine-toothed comb and make it better? ;-) (Then too, I could upgrade to PyBlosxom 1.3, which claims to fix bugs, but the version available in Sid is still 1.2.1.)

Courtesy of the Wikipedia's Current Events page: Lester Crawford, U.S. Food and Drug Administration Commissioner resigns, citing old age. Critics accuse Crawford of incompetence regarding Vioxx, cloned beef, approval of malfunctioning heart devices, and alleged corruption. He served two months in office.

My previous entry about a fellow developer's GPG key causing nasty spew from gpg on my system provoked an unhappy response. I had hoped to instead stimulate a discussion^* of the problem — whether a bug in GPG, a bug in the key servers, or both. From Alexander's explanation, it looks like it's the latter. If a hunk of your key gets corrupted and then submitted to the public key servers, ever, then there's apparently no in-band way of signaling that to those key servers. Apparently you have to contact the humans who administrate the key server and arrange for something approaching divine intervention (in the sense that any large database that has many simultaneous reads and writes going on at all times via defined interfaces really should not have people mucking around with its innards in an ad hoc fashion). Just off the top of my head, it seems like one should be able to submit a GPG-signed copy of one's own entire keyring to the key servers, and have any key signatures within that be regarded as "authoritative", only capable of supersession by another signature bundled in a keyring signed by the keyring's owner. The handling of signatures not in that signed keyring would not change. (It does occur to me, though, that this means that the key servers are susceptible to an annoying attack wherein people can deliberately add corrupt signatures to other people's keys and promptly upload those keys to the public key servers. It would also be easy to automate such an attack. Oy vey. Consequently, it might be worth considering a key-owner-only update model for keyrings on the key servers.) Debian relies heavily on its web of trust, and on the GPG application specifically, and it seems a shame that this problem hasn't been addressed by now. Do we need a new protocol for communicating with key servers? Is my suggestion above completely crack-addled? If you didn't get the chance to flame me for my previous entry, don't miss your opportunity this time around. ;-) Another possibility would be to change GPG so it doesn't complain about the sorts of problems it found in my message, but that seems suboptimal. Well, okay — I'll say it — grody. Errors in any large collection of data, such as the keyrings in the OpenPGP global web of trust, are inevitable. Corrupt data is corrupt data, should be reported as such, should be susceptible to rectification, and that rectification should be able to be propagated. It seems the PGP key servers — the ones I and many other Debian developers use, anyway — are not entirely succeeding on the last front. What can we Debian geeks, as prominent contributors to the global web of trust, do to resolve the problem? Alexander: I'm sorry I gave offense, if inadvertently and only temporarily. There are certainly no hard feelings on my part. I don't really know how to constructively reply to Matthew, given his patient explanation to me at DebConf 5 that the entire purpose of that specific blog of his is to serve as a vent for his spleen — he has another for the serious stuff. Since it seems to be necessary to state this for the record, I don't regard damaged packets in a person's GPG keyring to be evidence of flaws in the owner's character or personality, or as anything to be ashamed of, but I must admit that I didn't consider that others might do so. I see a technical challenge to be surmounted (noisy spew from the gpg program that seemingly can't be eliminated without improving the way GPG clients and key servers communicate), and that's about it. I welcome people's ideas on resolving it — is there a Public Key Server Corrigendum Protocol in our future, perhaps? ^*Being relatively new to blogging, it's certainly possible I have in mind a meaning of "discussion" in mind that is excessively mundane, and not the norm. I can easily conceive that people who use their blogs primarily as megaphones to air their grievances (and there are many — one of my favorites is Billmon) are more likely to assume others apply their blogs to the same end. I'll need to give that conception more weight in the future.

Last night at the "formal dinner"^* at DebConf 5, Anand Kumria presented me with a nice little tote bag that says "Debian: 10 years, 100 countries, 1000 developers, 10000 packages". It's a couple of years out of date now, but still pretty cool. Anand suggested that we give it away as a sort of prize. Since I was sitting across the table from former DPL Wichert Akkerman and we had two other former DPLs in attendance, Bdale Garbee and Ian Jackson, I thought I'd sweeten the item's collectibility by having all of us autograph it. This was swiftly done. After much dithering among my tablemates and I, and many ideas that fizzled regarding closed bugs or frequency of usage of the term "cabal" on the mailing lists, we ultimately settled on a method that was reasonably fair, if boring: the old game of "guess the unsigned 16-bit integer". We went outside and proceeded by binary search, disqualifying half the group at a time. The ultimate winner was Frank Lichtenheld, who guessed that the number was between 20k and 24k. ^*Fortunately, the dress code was not formal — the formality was that we ate from plates instead of cafeteria trays. ;-).

A while back, we started tracking security issues across the various security-supported packages in svn. We're slowly refining the format, but it seems to be working pretty well. In my at-the-parents-for-the-holidays-boredom, I wrote a script to create a summary page. It still needs some smarts about dealing with the linux-2.6 package, and needs a post-commit hook to auto-regenerate. Hopefully I'll have it active by next week.

http://sourceforge.net/projects/modestraier is one project of Summer Dojo 2005 (similar event as Google's Summer of Code, running by Free Software Initiative of Japan). The objective of this project is to develop apache module using Hyper Estraier as search engine, so that all html pages through the apache server will be automatically registered in Hyper Estraier's node server. Thus, you can search from html pages once you browsed ago. I intend to package this as libapache2-mod-estraier (Bug#320625) and put preliminary version on http://people.debian.org/~ukai/hyperestraier/ .

Last night, I worked a bit on the Debian package for darcs. darcs is an advanced revision control system, "two senses in which it is supposed to be advanced: 1) each copy of the source is a fully functional branch, and 2) underlying darcs is a consistent and powerful theory of patches.". Darcs is also written in Haskell, which makes it even more cool. When I did my first big group project in college, I started using CVS and completely loved it. I tried subversion for a while last year, and at home and work I'm currently using arch / tla. I'm excited about these two distributed revision control systems, tla and darcs. Keeping packages in VC: Since the author of darcs, David Roundy, is apparently a Debian user (and a skillful one at that), I expect this package to be a joy to take care of. At his suggestion, I'm going to keep my changes in darcs itself, and I figure that while I'm at it, I'll keep all my packages in darcs. I'm debating a bit about how to go about this, though. I could keep just the "debian" directory in version control, but then if I have to change the upstream sources (like the Makefile), then I couldn't track that. On the other hand, if I keep all the upstream sources in VC, then I'd have to sorta pound on the repository whenever there's a new release, with a bunch of big changes. Not too bad, I guess. What do those of you who keep packages in version control do? I was very pleased to see Colin's blog entry yesterday about Intel support of its Centrino chipset for Linux. I've been sending mail to them every couple of weeks for the last 8 months or so.

I'm off to ICFP, the International Conference on Functional Programming this week. I'm giving two talks at workshops as I mentioned. Yay! My talks suffer from a severe lack of Greek letters. I'm just a Haskell programmer. My review of Brute Force: Cracking the Data Encryption Standard got posted to Slashdot on Sept. 8th. And for some perverse reason, it's like 3rd on the list if I Google for the word brute. The link says something about RSS, so maybe it's just because so many RSS aggregatos are watching Slashdot? Doesn't the internet have anything better to do? I admit that I dragged my team from work to "Salvador Molly's: Pirate Food" for lunch today in honor of the holiday.

First, Evan has a host of interesting articles about Haskell, and I found his lazy big-O article particulary interesting.

Next, Eric Warmenhoven has recently taken up Haskell and posted some Haskell questions on his blog. Eric, here are some answers for you.

First, regarding shared libraries. While Haskell can be compiled to machine code, and GHC is a popular way to do that, a standard C way of representing information about a library (.h and .so files) is not really rich enough for Haskell. Consider, for instance, that functions may accept arguments of a wide range of types (or even things such as lists of any type). Haskell also performs type checking, and thus must know the type of arguments a function expects, as well as its return type, at compile time. So you do not generally compile Haskell code directly to .so files, but rather use the compiler's module or package support to do that. See Cabal for more information on packages. Through the FFI (Foreign Function Interface), it is possible to both call into C and be called from C with Haskell code, if that's where you want to go. It is actually easier in Haskell than in any other high-level language I've dealt with before.

Regarding circular module deps -- I've never used them and can't really comment. I can say, though, that the .boot files are internal files created by GHC.

Regarding practical stuff in tutorials -- I share your complaint there. I have found a few that are better than the others: Yet Another Haskell Tutorial, and Haskell: The Craft of Functional Programming, 2nd ed., by Simon Thompson. Several of us are working intermittently on a project called Haskell V8 -- take a look and darcs send me patches! I would say that Haskell's I/O system is the most powerful I've seen in many ways -- especially with regard to laziness -- and in the upcoming GHC 6.6 release, it will be both lazy *and* blazingly fast. Very nice.

There isn't much Debian-specific documentation, but there is a draft policy and a mailing list (link to it is in the policy doc).

Hope this helps!

The new wpa_supplicant packages have removed the /etc/wpa_supplicant.conf file. Wireless LAN is now configured via special commands from /etc/network/interfaces, which looks like an elegant Debian way to do things. While setting this up, I have learned the following:

• an ESSID starting with “+” is not accepted
• You don’t enter the passphrase verbatim into /e/n/i, you use wpa_passphrase to hash it
• wpa_supplicant debugs surprisingly well

Well done, maintainers! Thanks! Next time I’ll figure out how to configure wpa_supplicant to automatically associate to the correct wireless LAN regardless of location

Anthony Towns will be Debian’s next project leader. I am not happy with that outcome at all. With just a tiny margin, aj has won over Steve. Steve was not my favorite candidate as well, but he’d be better than aj, who in my opinion stands for the cabal that is running Debian from their positions of power for years now. Only 421 DDs have cast their vote, which is 43.3128% of all possible votes. Voter participation has thus been lower than the historic low Germany’s state Sachsen-Anhalt recently had in its Landtag election. More than half of the DDs do not seem to be interested in who makes Debian’s external policy and who represents the project to the outside. On the other hand, debian-vote sees a number of people who are not currently allowed to vote, but regularly contribute to Debian. It looks like the people who could vote don’t, while people who do good things to Debian are not allowed to vote. Bad. But, IMNSHO, the really bad thing is the new DPL itself. I think he has won the election with saying that he will increase Debian’s speed. On the other hand, he is member of ftpmaster, the team that might be one of the biggest causes for Debian’s slow speed. He is generally regarded to be close to the “Cabal”, which of course does not exist. I don’t see how the speed increase is can be accomplished giving this background. However, the vote can easily be interpreted as a vote of confidence in the Cabal, which in itself is a good thing. It shows that even the voting DD’s are comfortable to be ruled by the secret club of most senior DDs. I don’t have to like it, but I’ll have to live with it. aj is also one of the founders of #debian-tech, an IRC channel which has been created as a “nice” channel for technical discussions. The channel has a very strict code of conduct, and people are being removed from the channel if they do not comply. I am really really really afraid of this “be nice or else” attitude being extended to other Debian communications media during aj’s term. Being robbed of the right to speak one’s mind might adversely affect many people’s motivation to spend time with Debian in the future. In a nutshell: This is a sad day for Debian. But, otoh, every project gets the leadership it deserves. And it looks like Debian didn’t deserve any of the better candidates. jftr, I voted 63571824 Be warned: I have a bad history of mis-judging new DPLs just after their election. A year ago, I was quite happy about Branden being elected, and was convinced that things would change during his first term of DPLship. I really believed that he could remove the Cabal from the power, and that Debian would change to a more co-operative environment. I surely hope that I am as wrong this time as I was a year ago. It’ll be more positive this time.