Search Results: "nate"

24 November 2006

Lars Wirzenius: Random thought: Bzr book outline

While cleaning up my hard disk, I found the beginning of an outline for a book on Bazaar (bzr), the version control system. I wrote it one weekend this summer, when I felt I had lots of free time. I don't, and won't, for the foreseeable future. Therefore I'll dump the outline here in my web log, so that perhaps someone will be inspired to write it for me. The Bazaar distributed version control system For most of the 1990s, the free software world relied on CVS for version control. It was the best free system for the purpose. During the early 2000s, a number of new systems started getting into public knowledge. One such system is Bazaar. This is the outline for a book to explain how Bazaar is used in different kinds of scenarios. The book is not a reference manual: the software's own documentation is best suitable for that; this avoids having to constantly update the book. The book is structured as a series of case studies of common scenarios, starting with the simplest one, and getting increasingly more complicated. This approach allows the reader to quickly learn the things they need for a particular kind of situation. Introduction This chapter explains what version control systems are, and gives a summary of their history so far. It explains various basic concepts, such as centralized versus distributed, but briefly; these will be expounded on later in the book. It compares Bazaar to other well-known systems. It explains the cumbersome naming history of Bazaar. It explains how to install Bazaar by referring to the website and to the package repositories of various Linux distributions. Quick overview This chapter is intended for those with some experience with other version control systems, such as Subversion. It gives a quick run-through of the central concepts of Bazaar, and how to do common tasks on the command line. The web page project This is the first case study chapter. It explains how to use Bazaar to keep track of changes to a web site. A web site only changes linearly: only one version exists at a time. My little program This chapter explains how to use Bazaar to maintain the source code for a one-person programming project. The program has a stable version, which gets bug fixes, but no new features. There is also a development version, which gets the new features. Sometimes a bug needs to be fixed in both, and Bazaar can help with this. Additionally, sometimes it is not clear whether a new feature can be implemented cleanly, or there are several possible approach to how it can be implemented. Thus, the chapter also explains these so called feature branches. Further topics for this chapter include making releases, and using repositories to avoid excessive disk usage. Tight teamwork This chapter explains how to use Bazaar when the one-person program becomes an internal project in a company, with a well-defined set of developers. Thus, we discuss how to set up a centralized branch in a way that all the developers can commit to it. Distributed free software development This chapter concentrates on a typical successful free software project, with contributors from all over the world, and the problems that this involves. Thus, we discuss how to publish a branch for anyone to see (but not change); how to share changes (patches/bundles) between developers; how to co-ordinate the development of the whole project (at least from the version control point of view). Switching a project to Bazaar That's it. If you write it, please send me a note when it's published so that I can get a copy. Thanks.

22 November 2006

Simon Richter: I do not think you have thought your cunning plan all the way through.

I can see that calling terminate on people who leave objects around with a reference count greater than zero is a good thing. Calling the one that you can't place a breakpoint on easily because its symbol is shadowed is a bit on the edge, though.

21 November 2006

Benjamin Mako Hill: Writing and Writing Code

Over the years, I've published some of the articles I am most proud of on Advogato. As you can imagine, I was sad to see demise of Advogato announced early September and thrilled to see that by the end of the month, Steve Rainwater had stepped up to save the site. For a belated welcome of Advogato back from the edge of the grave, I've published a short essay about the effectiveness of an analogy of software and writing on the site. In it, I introduce the analogy and argue that it is useful in advocating free software and programming education and in justifying the disproportionately large amount of programming related projects in the free software world. Here's the intro:
Advocates of free and open source software, myself included, like to talk about the "democratizing" effect of free software. Others, especially non-programmers, are quick to point out that the only technical people can take advantage of half of the enumerated freedoms in FOSS. The freedoms to modify and collaborate mean little if you don't know to program. Over time, I have come to the conclusion that the only good solution to this problem -- and one that I was initially quite opposed to -- is to teach everyone to program. In considering this position, the processes of reading and writing provide a useful analogy when considering the processes of using and creating computer software. Additionally, the analogy provides an powerful justification for the fact that FOSS programmers produce a disproportionately large amount of software that is primarily of interest to FOSS programmers.
Please check it out on Advogato and feel free to leave a comment on my blog if you don't have an Advogato account.

Christoph Berg: Spamassassin, RBLs, and Dialup

I'm using SMTP over dialup to my smarthost. Unfortunately that doesn't stop spamassassin to think I am a spammer: 
Received: from tesla.df7cb.de ([88.198.227.218] ident=postfix)
        by merkel.debian.org with esmtp (Exim 4.50) id 1Gm6h1-0001Fw-26
        for ???@qa.debian.org; Mon, 20 Nov 2006 03:48:03 -0700
Received: from volta.df7cb.de (dslb-084-058-218-241.pools.arcor-ip.net [84.58.218.241])
        by tesla.df7cb.de (Postfix) with ESMTP id 2F5364475D
        for <???@qa.debian.org>; Mon, 20 Nov 2006 11:48:24 +0100 (CET)
Received: by volta.df7cb.de (Postfix, from userid 1000)
        id BBABE18E95; Mon, 20 Nov 2006 11:49:32 +0100 (CET)
 0.1 FORGED_RCVD_HELO       Received: contains a forged HELO
 0.1 RCVD_IN_SORBS_DUL      RBL: SORBS: sent directly from dynamic IP address
                            [84.58.218.241 listed in dnsbl.sorbs.net]
 1.8 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
               [Blocked - see <http://www.spamcop.net/bl.shtml?70.103.162.29>]
 2.5 RCVD_IN_XBL            RBL: Received via a relay in Spamhaus XBL
                            [84.58.218.241 listed in sbl-xbl.spamhaus.org]
 1.7 RCVD_IN_NJABL_DUL      RBL: NJABL: dialup sender did non-local SMTP
                            [84.58.218.241 listed in combined.njabl.org]
My previous solution was to use an openvpn tunnel to the smarthost, but my current one (provided by codebreaker) is a vserver, so that doesn't work. Ganneff provided the workaround: make postfix drop the Received: header. 
[0] cb@tesla:~ $grep header /etc/postfix/main.cf
header_checks = pcre:/etc/postfix/header_checks
[0] cb@tesla:~ $cat /etc/postfix/header_checks
/^Received: from [a-z]*\.df7cb\.de \(dslb-[0-9.-]*\.pools\.arcor-ip\.net/ IGNORE
Received: from tesla.df7cb.de ([88.198.227.218] ident=postfix)
        by merkel.debian.org with esmtp (Exim 4.50) id 1GmX3t-0000Pw-4I
        for ???@qa.debian.org; Tue, 21 Nov 2006 07:57:27 -0700
Received: by volta.df7cb.de (Postfix, from userid 1000)
        id 69AB218EAC; Tue, 21 Nov 2006 15:58:57 +0100 (CET)
Of course this is a gross hack, but I'm happy with it :)

Joachim Breitner: Unicode Hack

(No, this is not security related. Some people call screensavers hacks . But I did get your attention, didn t I?) Whenever I happen to run gucharmap, I like to just browse and have a look at all those weird characters other people, especially asian, are using: A lot of them look really cool. So I thought: This would be a great screensaver.After some API digging I created that screensaver. It uses fontconfig to open the FreeSans and the DejaVu Sans fonts, selects a random glyph from these and display s it full screen. Below, the unicode code point and characer name are printed. After a few seconds, the next character is displayed nothing else, nothing hectic, quite relaxing.When you download the code, you will find a file uncode.c , which is the hack itself, a file unicode-names.h , which is taken from gucharmap and only slightly modified, as well as a buch of files from the xscreensaver distribution. To re-compile the binary, use the script compile , which runs gcc with flags I stole from the xscreensaver Makefile. I know this build system is everything but correct or sensible, but it works for me...Unfortunately I don t think it can be included in xscreensaver, as it depends on libfontconfig. If someone would rewrite it using only libX11, this might be possible, so if you like it, feel free to steal the idea.

Steve Langasek: midterm report

This is the first of my two formal reports to the Dunc-Tank board on the release management funding experiment. Although submitted to the board some time earlier, I've delayed publishing it to the wider community until a release update could be sent out with more concrete information on timeline adjustments as Debian developers are wont to demand.
I'm supposing that I don't need to give you any more specific details on what I've been working on than what's already been posted in my blog. There has certainly been plenty to keep me busy the past three weeks, including a lot of triage work on the state of bug reports in the BTS, managing the last of the major package transitions into testing for etch, removing packages and NMUing them, and it has indeed kept me busy. Busy enough that I've been lax when it comes to talking about it, either here or in my blog. :) Has the hard work paid off? Well, http://bugs.debian.org/release-critical/ shows a sharp decline in release critical bugs affecting testing over the same time period, following the peak resulting from Dunc Bank's successful campaign of identifying latent release-critical bugs in etch. Unfortunately, we have no statistics that track the number of RC bugs closed or opened over time, which makes it hard to judge how large of a dent my own work has made in the overall bug count. It's also totally guesswork to try to judge whether Dunc-Tank has encouraged others to help with the release overall, or discouraged them from doing so. What I can say is that, even though the past month coincides both with the tail-end of the Dunc Bank mass bug filings and multiple archive-wide rebuild efforts, the bug count is moving in the right direction, and I am seeing many maintainers being responsive to bugs in their packages and a number of active NMUers. If not for the buzz-kill of Lucas Nussbaum's latest round of build failure reports :), we would be down from over 300 RC bugs to less than 200 right now, which probably represents at least twice that many RC bugs closed. In terms of how the time I'm putting into this release compares with the sarge release, I'd say it's pretty comparable. That's actually quite a positive statement about Dunc Tank's role, IMHO; getting a Debian release out is uphill all the way, and whereas the sarge release came at a time when I was in a position to work more or less full time on it without compensation, my availability this time around would have been greatly reduced, and progress would have been much more heavily dependent on individual maintainers and semi-periodic bugsquashing parties, which I'm not sure is any longer enough to offset the rate at which new RC bugs are created in the distribution by uploaders. As it stands, I do find myself trying to consciously avoid a hero complex of needing to fix every bug personally, but there are after all only so many options for getting bugs fixed for release. A lot of maintainers respond positively to gentle nudging about their RC bugs, but there are still bugs that the maintainers can't or don't fix and that no NMUers take on, which does leave it more or less up to the release managers to address -- which is why one of my tasks for this week is to try get the count of RC bugs over 20 days old down from 90 to around 20-30, as these are the bugs that really do need more attention to get them resolved. So yes, Dunc-Tank is making a positive difference. Andi and I have reviewed the status, and while we don't think we'll be able to hit the Dec 4 deadline (even if we get the bug count down immediately we're waiting on the debian-installer to release, which needs at least one more release candidate with the 2.6.18 kernel), we do believe that a release before the end of the year is very possible and I'm looking forward to starting the full freeze in the next few weeks.

20 November 2006

Joey Hess: OpenID

I took some time today to learn about OpenID. Is it just me or are these newfangled web protocols both much harder to learn and much more poorly specified than traditional internet protocols? Alternately, perhaps I'm getting too old. :-) Anyway, it's seems to be Not Evil, and I look foward to being able to log into wikis and other sites without having to register separately on each one. Although I note that it punts the spam and abuse problem to some as-yet unimplemented policy layer. After all, there's no mapping between an OpenID and an actual person, just between an OpenID and a web page somewhere. Although there is the potential for someone to do something interesting with an OpenID server that only gives out OpenIDs to people with verified gpg keys. As my own little gesture toward spreading OpenID, I've added an openid plugin to ikiwiki. There's a $5000 bounty for implementing OpenID support in free software projects, but I don't think I can collect on it, since it's limited to projects that have tens of thousands of users, and with 30 registered ikiwiki users, my userbase is a few magnitudes too small. Oh well.. FWIW, my personal OpenID is http://joey.kitenet.net/.
Update after some more hacking: Even nicer, ikiwiki can now be set up to use only OpenID for authentication, and not mess with passwords at all. I also added support for the MyOpenID.com affiliate program, which lets users jump from the wiki to creating an OpenID, and back smoothly. My personal wiki is now configured like this.

19 November 2006

Piotr Roszatycki: YADA kills kitten ;-)

There was very funny thread about CDBS and kitten. I think any other solution is better than plain Makefile. Long time ago I adopted the YADA. It's wonderful tool for anybody who hates Makefiles. Yes, the project is still alive. Unfortunately I don't have too much time for promoting this project. Just one month ago some developer did NMU for my package (see Bug#391753). He wrote that YADA is quite unfriendly for NMUers. I really wonder, how it could be unfriendly as far as plain Makefile don't support even separate patch files... I think it would be much better if Debian had only one tool for packaging. The RPM's SPEC file as single source for package is more friendly for maintainer than thousands of separate debhelper's files. So the YADA came. But... I understand it is just an option. It is my choose how to package my packages. My own right to decide. I can live with Debian and CDBS, YADA or other packaging helpers.

17 November 2006

Joachim Breitner: Linux Gaming Tournament

To promote Linux with the students I held a gaming tournament tonight. The sixteen participants played two rounds of four-player-tetrinet-games, as well a single elimination bracket of Frozen Bubble. It was very chaotic, but in the end we had two winners: Elridge Nikki Gordon (tetrinet) and Beteab Gebreyesus (Frozen Bubble), and they got winner certificates (the names of course not printed but hand written). Unfortunately, we did not manage to pull through the Tuxracer competition, but it was still fun. For them at least, for me it was only stress. But the good kind of stress.

Steve Langasek: On setting and meeting goals, and statistical fun

While NMUing plays an important part in getting us to a release, as shown by the thousand or so fixed-in-NMU RC bugs that we recently cleaned up the BTS state on, it's evident after doing this whole release-managing thing for a while that there is a very high (non-linear) correlation between the age of an open RC bug and the likelihood that a release manager is going to have to touch it at some point in order to get it fixed. By and large, maintainers really do a good job of fixing their own packages, which is probably something we don't say enough - maybe 75% of all RC bugs, I'd guess, will (or would) get fixed by maintainers in the first week without anyone needing to poke them about it, and of the remainder, probably another 80-90% get taken care of by BSPers and serial-NMUers like bug-a-day mascot Steinar Gunderson. That's why I'm not bothered overly much by the idea of full-archive searches for hidden RC bugs, like Lucas's piuparts tests, affecting the release timeline, because I know that 95-98% of those bugs are going to be gone two weeks after they're filed anyway, especially when they're no-brainer fixes to maintainer scripts or dependencies. But then that leaves the other 2-5%, which are the ones nobody else has fixed. And why hasn't anyone fixed them? Because they're the hard ones, of course... So although I follow the debian-bugs-rc list and occasionally swat a few non-bugs closed to save the maintainers time, and also provide some nudges when it looks like a package is causing RC bugs to be filed on other packages, my goal for the last full week of my Dunc-Tank contract was to get the count of etch RC bugs unfixed in unstable that are 20 days old or older down from around 50 to under 30. This seemed a reasonable goal, since it had been at 80 the week before, and it would go a long way towards helping the real blockers on the release. Initially I was aiming to bring down the count of RC bugs unfixed in testing that are 20 days old or older to this number, but quickly realized that this wasn't going to be realistic because it depended too much on the autobuilders all operating optimally and there wasn't time to both help fix 20 of the hardest RC bugs and handhold 60 RC bugfixes into testing in one week. In the end, we did miss this lesser target by a day or two. Still not a bad week's work, given that I'm pretty sure I fixed about 20 of these bugs myself in that time period (through NMUs, removals, and analysis+downgrades) and they seem to average 3 hours of work for a fix. And we've been holding at or below 30 on this list of bugs since then, so we're successfully keeping up with new bugs aging past the 20-day mark, which is also a good sign. Unfortunately, I seem to have left myself to fix the alpha Xorg 7.1 bugs on my own time. :) By now the announcement has made the rounds that the release team doesn't think we can hit the Dec. 4 target date because more time is needed for a final release candidate of the installer. Does that mean that RC bugs were the wrong thing to be focusing on for the past weeks? Well, no; if you want one place in Debian where Brooks' Law holds, I think you'll find that getting a d-i release out is it, and we still have a hard road ahead to make sure we do get our other RC issues sorted out in the same time frame. The installer just happens to put a lower limit on a release date, we still have an opportunity to screw it up from there. ;) At least the statistics suggest that we're going in the right direction. Only 13% of RC bugs fall into the "20 days or older and unfixed" category. Half of all RC bugs over 10 days old have a fix of some kind in unstable, and 64% of all reported RC bugs are less than 10 days old. We'll see whether this graph backs me up on this in a couple more days.

Michael Janssen: I work hard, every day of my life

Most of my fitness transition plan has been focused on exercise. Get more exercise and eat the same as you did before, and you will lose weight. This has to be true, based simply on physics. Back when I was using the Hacker's Diet, it worked like a charm. Then it was all about eating less calories, because I wasn't really keen on doing exercise in my olden days. It worked for a while. Unfortunately I got stressed and stopped countign calories, and weighing every day. I've started the weighing again, and maybe I can actually fire up gnuplot again and produce some pretty graphs like the one on the left.


I've had an iPod for approximately 5 years now. That puts me a bit ahead of the curve. I still remember seeing the original iPod commercial, and looking literally seconds later for how much it was, and seeing how much I could sell my old player on eBay for. Having been in the mp3 scene for a while at that point, I knew that it would turn everything on it's head. I got it and replaced my normal player for walking to and from class and listening while coding. Now I have a new iPod video, and it is the chief entertainment while I'm in the exercise room. At first I was just listening to my fairly large music collection. Then I started listening to podcasts again - they are about the right length, and I enjoyed them. Now I've harnessed the power of the video iPod to kill two birds with one stone: I'm watching my large collection of Anime at an hour a day. This means about 3 episodes if I skip the openings and endings. I also watch Heroes on Tuesday nights, after I transfer it from the TiVo. The only problem I'm having with this setup is that the screen is small, so I need to hold it fairly close to my face in order to read the subtitles.

Today marks one month on the diet and exercise regimen. I started on the scale at 344 and this week's average was 337, 7 pounds lighter. I'm going a little slower than my goal of 2 pounds per week, but I seem to be hitting the right buttons at least.

This week (Nov 10 - Nov 16):
Minimum: 335.5 (-2.5) (Nov 14)
Maximum: 339.5 (-0.5) (Nov 16)
Average: 337.2 (-2.05) (137.2 to goal)
Exercise Calories: 2563 on 5 days
Average Calories per session: 512.16

16 November 2006

Gon ri Le Bouder: Debian Lenny?!

Like a lot of people who read Of Mice and Men. ‘’Lenny'’ call me up the famous character of the book: “Lennie Small”. This is his description from Wikipedia :
Lennie Small Travels with George. He is a giant of a man who is unaware of his own strength. His mental deficiency culminates in an obsession to stroke ’soft’ materials: this can be understood to represent his need for human contact, which is shown in his obsession with rabbits. George and Lennie are the only characters with both first and last names. There is irony in his last name, as it is “Small” while he is a very big man physically. Lennie is killed by George with a gun.
Please don’t call the next Debian, Lenny! This sux!

Michael Janssen: Quickie Hack: Online X-mas list

It's getting around that time of year when kids start singing little annoying songs and thinking of the toys that they will be getting in slightly more than a month. In my family, when everyone gathered for thanksgiving, the younguns were expected to have a list which could be disseminated throughout the family with everything they wanted. This avoided some of the more clich gifts such as sweaters and socks. But who's to say that grownups can't have a little fun as well? It's rather easy to use del.icio.us as a holder for your whole Christmas list. If you find something you want, just add it to your del.icio.us bookmarks with a special tag - I'm using “xmaslist2006”. Using del.icio.us gives you a few advantages over the traditional list: Things on the list need not be completely techie - if you're just looking for a nice sweater, you can add a general page or a representative item with a comment on it. Perhaps include your sizes as well, especially for items which come in a large number of sizes like pants. With any luck, you'll get just what you want this year.

Benjamin Mako Hill: Dare to DReaM?

I went to a talk today by Sun scientist Susan Landau on Sun's DReaM/Open Media Commons DRM system that I've mentioned in the past. Landau used a variant of these slides to do a rough overview of the Sun system and the problems that it is trying to solve. Halfway through her talk, Landau showed a slide titled, "Users Matter: Creative Commons." Elaborating, Landau mentioned that she had been talking to a number of people -- both at CC and outside -- about the possibility of using DReaM to enforce the terms of CC licenses. I interrupted Landau to point out that CC licenses had an anti-DRM clause that, as far I knew, would make her system unusable on CC content. The CC anti-DRM clause, plus the resistance of the CC and iCommons community to accept parallel distribution language, are why it's impossible to play CC-licensed works on an unmodified PlayStation or XBox (these systems only play signed disks) -- even if you include an unencumbered copy alongside! Landau reassured me that I must be mistaken and that she had talked about DReaM in depth with CC leadership, lawyers, and technical advisory board members and she was sure her system was at least possible. Puzzled, I shut up. For most of the rest of her talk, Landau talked about fair use and how a DRM system might go about respecting it. In his qualified endorsement of the DRM system, Lessig mentioned that DReaM, "would be implemented to allow individuals to assert 'fair use,' and unlock DRM'd content, with a tag to trace misuse." At the time, I had a hard time imagining how fair use could be built into such a system -- separating fair from unfair use is remarkably resistant to technical solutions. Even bright light cases like verbatim copies every page of the Encyclopedia Britannica might be fair use if I were to make them into a paper m ch bust of Johann Gutenburg or use them to wallpaper a gallery wall. Landau's acknowledged the trickiness around fair use and suggested a compromise:
By default, works might be encumbered in the ways and to the degrees that the copyright holder wish. However, users could petition for an unencumbered "fair use copy" by identifying themselves and then checking some boxes and explaining (briefly) why they think their use for the work qualifies as fair. Once they've done this, the system would present the user with an unencumbered, watermarked, and fully traceable piece of media.
Conceivably, requests would be subject to some sort of review (at the very least to prevent automated requests) and non-fair uses of watermarked goods would be strictly tracked. If a "fair use" copy is found in the wild, the watermark would be traced and the originator would be held liable. Of course, anonymous fair use becomes impossible but, as Simson Garfinkel pointed out at Landau's talk, users may have a right to anonymous speech and to fair use but not to anonymous fair use. "Fair" enough. It is perhaps important to point out that DReaM does not currently implement this "fair use" system and that, one can only assume, the vast majority of DReaM users (e.g., Hollywood movie studios and their ilk) would have no little interest in giving their users a blanket ability to make "fair use copies" and would in most cases choose not to enable such an option. But let's return to the issue of DRM enforcement of CC license terms. While I was initially quite confused by the idea of DRM enforcement of CC license terms, it made much more sense when I looked at the CC anti-DRM clause itself:
You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement.
The emphasis (mine) points to the crux of the issue. The CC anti-DRM clause only blocks technological measures that overstep the boundaries set in the rest of the licensee. For the free licenses, that's a wide boundary that leaves little room for DRM. But as I've pointed out before, CC is a lot more than just free licenses. Landau mentioned that her group was primarily interested in using the DReaM system to enforce attribution and non-derivative work clauses in CC licenses -- a wise choice as non-commercial use is hard enough for humans to discern. As a result, the DReaM system might be used to make it impossible to remove attribution from CC works or might block modification to works marked as "ND." The catch that led me to believe that CC license blocked all DRM was the fact that I didn't think it would be possible for a DRM system to respect fair use. After all, each CC license includes an explicit affirmation that, "nothing in this license is intended to reduce, limit, or restrict any rights arising from fair use." The question that the possibility of a CC DRM scheme like DReaM hangs on is: to what degree does Landau's suggestion live up to the fair use legal bargain? Landau pointed out that a number of lawyers including Pam Samuelson and CC's technical advisory board and legal staff have been generally positive about her fair use permission-asking compromise. Honestly and on CC's own terms, it's hard to see why they wouldn't be. The loss of anonymous fair use was only ever a right we enjoyed by a fortunate accident. Watermarks are only there to "keep honest people honest." If you are not doing anything wrong, what do you have to hide? But DReaM enforcement of CC licenses is a bad thing and the bad taste that it inevitably leaves in many commoners mouths is not hard to explain:
  • Many commoners are not comfortable with the idea of DRM because it shifts power over users' computing devices away from the users and makes computers obey the will of a copyright holder. That's true of DReaM just as much as as it is of Apple iTunes or Microsoft DRM.
  • Many commoners are not completely comfortable with all CC licenses, so the idea of technical protection measures enforcing these terms, even those allowing for fair use lines and in line with the will of the author, is seen as dangerous.
To solve the first issue, CC needs a more strongly worded anti-DRM clause -- ideally one tied to a parallel distribution clause. To solve the second, we will ultimately need a new banner under which only truly free cultural works will reside. Susan Landau doesn't have it easy but she does seem to have the genuine best interest of consumers and users at heart. That's more than I can say about the vast majority of people in the DRM business. She's trying to walk a fine line and she's almost certainly being abused and heckled by folks in the industry who call her "communist" and by folks like me who feel that she's sacrificing essential principles in an attempt to compromise. The one thing we all agree on is that the ground she's treading is mine field. Yet while I sympathize with her, I must speak out against both her and DReaM. A DRM compromise at this stage would be insanity. This is a fight we have to win.

Zak B. Elep: Ubuntu-PH Release Party for 6.10 (Edgy Eft)





Ubuntu-PH Release Party for 6.10 (Edgy Eft), originally uploaded by zakame.

Last night I called Ubunteros nearby Manila for the Edgy Eft (belated) release party at the Coffee Bean and Tea Leaf at Greenbelt 3. Little did I know that there will be a lot of folks coming from the just-concluded FOSS@work workshop joining in the fun, thanks to Yolynne Medina and Eric Pareja. Diane Gonzales and I got to the venue first, then followed by the FOSS@Work folks. Dominique Cimafranca, Migs Paraz, Ranulf Goss, Jopes Gallardo, and Joel Bryan Juliano were there too, and all in all we were easily the noisiest group in the coffee shop, seemingly occupying the entirety of the place. I originally planned to move the group to have dinner somewhere, but along the way everybody seemed to forgot dinner and we quite engaged in talking to everyone else. It was terrific. The 2 boxes of Edgy ,K,Ed Ubuntu CDs I brought were easily given away to everyone; we even had them exchanged and autographed (naks!) reminiscent of what Ealden and I did last February when Mark came here. As a finale, we had a group photo of everyone with their CDs; Dominique remarks that in his informal’ study, more and more women prefer Ubuntu (and I sure do think he’ll be blogging more about this soon. ;) Needless to say, the above photo doesn’t do great justice to what happened last night; it came from my elric which I didn’t get use much as a camera since I too was happily chatting away. That said, I expect RJ Ian will be posting his photos from his brand-spanking-new Kodak camera to the Ubuntu-PH site once he gets back to Mindanao with Yolynne and company. I also think the FOSS@Work folks also have their own photosite or wiki to post more photos, which we’ll be seeing sooner. Jerome Gotangco and Ealden Esca an, the guys whom we all owe Ubuntu-PH to, were unfortunately unable to attend last night, as Jerome was off to Cebu to participate in the ICT congress there, while Ealden was quite busy at work. Hopefully they (as well as last night’s attendees!) can attend the next Release Party for 7.04 (aka Feisty Fawn,) and hopefully it will be just as fun, and be more meaningful if more Ubuntu-PH folks get involved in its development! Update: Yolynne and RJ just posted pics fresh from their arrival to home. Expect more pics later, nicely tagged too…

Jeff Licquia: What Do We Want From Microsoft?

Jason Matusow of Microsoft wants to know:
That said, the real voice of the community is…well…from those of you I don’t know. I have to tell you that the issues with getting this covenant right are incredibly complex and there are real concerns on all sides. Our design goal is to get language in place that allows individual developers to keep developing.
(This is in response to the recent patent deal between Microsoft and Novell, and the poor reception it’s getting from the free software community.) Unfortunately, he got GrokLaw-ed, and his comment system isn’t taking the heat well. So, here’s my feedback; hopefully, he’s paying attention to views outside his comments. The big problem, if you ask me, is the distinction between “commercial” and “non-commercial” that Matusow (and everyone else I hear from Microsoft) is making. In our world, that distinction is a lot less important than the distinction between “proprietary” and “open”. For us, “commercial” is just another way software can be used, and restrictions on commercial use are like restrictions on use by women, or by people in Illinois, or by people who have ever picked their nose in public. Why are businessmen any less deserving of our software as a class than housewives, or Haitians, or other free software developers? Matusow claims not to be interested in any of this:
We are not interested in providing carte blanche clearance on patents to any commercial activity - that is a separate discussion to be had on a per-instance basis. As you comment, please keep in mind that we are talking about individuals, not .orgs, not .com, not non-profits, not…well, not anyone other than individual non-commercial coders.
Dialogue often means meeting the other person where they’re at, not where you want them to be. They would, presumably, not take us seriously if we insisted on a blanket patent license as a condition for any kind of conversation. Fair enough; but then why should we taken them seriously when they insist on us turning our backs on one of our bedrock principles? But does the conversation have to be either-or? I’m betting that Matusow’s blog post is evidence that it doesn’t. People at his level are not the types to waste time on wild goose chases. And is it all that strange to think there might be value in the conversation? There’s a mighty thin line between “proprietary” and “commercial”, so thin even we get them confused sometimes. Does Microsoft really care all that much about for-profit use and improvement of free and open tech? If so, they’re prominent members of a small and shrinking club. If not, then it seems to me that we have a lot of common ground for discussion.

15 November 2006

Jonathan McDowell: MPEG2 straight to the brane

I received a Freecom DVB-T stick last week (early wedding present). I've not actually played with DVB-T before, so I wasn't sure how much of a hassle it would be. My first act was to plug it into my laptop, with the aim of finding out the USB ID and thus which driver I'd need to compile up (I have a tendancy to build my own kernels with only drivers I think I'm likely to need). I did so and was greeted with: 
dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in cold state, will try to load a firmware
dvb-usb: did not find the firmware file. (dvb-usb-wt220u-02.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2)
usbcore: registered new driver dvb_usb_dtt200u
Interesting, think I. I'm more organised than I thought and have already compiled up all the various v4l bits I thought I might end up using. So I go looking for the firmware file, find a copy, dump it in /usr/lib/hotplug/firmware/. Replug the device. And get: 
dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in cold state, will try to load a firmware
dvb-usb: downloading firmware from file 'dvb-usb-wt220u-02.fw'
usb 1-4: USB disconnect, address 15
dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
usb 1-4: new high speed USB device using ehci_hcd and address 16
usb 1-4: configuration #1 chosen from 1 choice
dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in warm state.
dvb-usb: will use the device's hardware PID filter (table count: 15).
DVB: registering new adapter (WideView WT-220U PenType Receiver (Typhoon/Freecom)).
DVB: registering frontend 0 (WideView USB DVB-T)...
Rockin'. Now I need to tune it. I find Adam's DVB page which has the initial tuning file for the Tacolneston transmitter in Norfolk. I type scan uk-Tacolneston. It fails to find anything. I wonder if I'm using the wrong transmitter. I decide the supplied antenna is probably to blame and go to see about sorting out the one in the attic. I try again. I get a channels.conf containing 91 channels. Wooo. Copy this into ~/.mplayer/ and fire up mplayer dvb://. And have Freeview on my laptop. Nice. Unfortunately this requires me to have the loft aerial plugged into my laptop, which isn't very portable. Paddy tell me this will get better when the analogue transmitters get turned off and the digital power ramped up, so I look forward to that. Until then it should still prove useful to have a portable DVB-T stick - I intend to see if I can pick up BBC HD next time I'm staying in London, and check if Freeview coverage has made it to my parents' yet. Writing this all down makes it seem quite convoluted, but actually the process was a lot smoother than I expected; plug in stick, copy firmware, replug stick, scan for channels, watch tv. The issue that took most time to sort was the aerial. It's really quite cool to think about how easily you can get yourself an MPEG2 stream of TV to play with.

Wouter Verhelst: #include &lt;stdarg.h&gt;

The stdarg API, which allows you to use a variable number of arguments to a function in C, is pretty fun. However, it's also pretty limited in what it allows, to a degree that it invites people to try and find workarounds to things you can't do with the API as it is documented. Unfortunately, this almost always breaks when the software is compiled on hardware that happens to be not your own, as there is a reason why stdarg is implemented the way it is: portability. A (not so) recent discussion on #debian-devel on OFTC showed to me how this confuses many people. Don't worry—it confused me too, the first time I had to think about it. The problem is that in order for stdarg to be able to do what it does, it needs to read function arguments from whereever they are stored. Where that actually is depends on the operating system and the hardware you're using; it could be on the stack, but e.g., the SPARC architecture actually has a mechanism to pass parameters using processor registers (although those are most likely not used when stdarg is in use, since the number of parameters that can be passed that way is obviously pretty limited). If parameters are on the stack, then you may be able to just access the memory as you would access any random variable; but it could also be the case that you need to take some specific steps to access the stack, or perhaps your architecture or operating system has some protection for stack-based security attacks, which would make it impossible to directly access memory on the stack that is actually part of another subroutine. So if you try to do anything that isn't defined in the stdarg api (like trying to figure out the number of arguments by peeking inside the va_list data type, or passing a va_list to another function without using the C99 va_copy macro) will break. Yes. Very sorry.

14 November 2006

Joachim Breitner: Infoning in Ghana

I m running a computer club at the school in Ghana where am volunteering as a Free Software advocate at the moment (as you probably know already). At first I tried to spread a little bit of general hacker attitude by introducing an internal wiki and blog, and by explaining what Free Software is. Then some students indicated interest in a programming course, so I held python lessons in the club (Sessions 3, 4, 5, 6, 7, 8, 9 and 10). Unfortunately, interest was declining over time, and while the first lessons had over ten participants (not to speak of the 20 at the very first one), it soon fell to around four. There was also some fluctuation, students leaving, others joining (and then of course lacking the lessions from the earlier sessions).So today, with four students who only recently joined, I started something new: I introduced the game infon, by fellow entropianian Florian 'dividuum' Wesch. It is a networked battle area where bugs compete over food and fight each other. Suitable for the computer club makes it the fact that the bugs are not directly controlled, but the players write their intelligence (using the simple language lua) and only upload code to the server. They can even do this while the game is running and it was a very fun game to play at GPN5 in Karlsruhe. You can read my infon-tutorial, and it s mostly non-SOSHGIC specific.I got them far enough to type the code that I presented as an example, to get it running, and to extend it slightly. I am only hoping that they will dig in a little bit deeper until next week. I think that you can only be successful in learning programing or similar things if you spend some time doing it besides the classes, and I did not see that happening when I was doing python. Maybe I was going too fast or the text-only way of doing it was discouraging, but I did expect them to starting having their own ideas at least after we were programming a simple text-based maze in the club.

Steve McIntyre: aaargh! cdbs...

Steinar suggests that he doesn't like cdbs. He's not alone. cdbs may make life easy for the maintainer, but it can make it incredibly difficult for anybody trying to fix bugs and NMU a package. I've found this myself when doing RC bugfixes during the recent round of BSPs; I must admit that more than once I've started looking into a bug only to give up the moment I've seen it uses cdbs. Fixing packaging errors is much harder when all the details of the package build are hidden from you in a mass of variables and included Makefiles. Unfortunately, it seems quite a number of new inexperienced maintainers have been using cdbs with very little understanding of the magic it does behind the scenes. This doesn't bode well for the quality of their packages in my experience.

Next.

Previous.