There should be a board meeting at 1900 UTC in #spi on irc.oftc.net, according to the last meeting. There’s no announcement or agenda online at the time of writing. (If only you’d elected me…) Hopefully, a meeting will decide on issuing a statement in support of the campaign against Software Patents and supporting FACIL taking on the Quebec proprietary software problem. Update: The agenda appeared between the time of writing and the time of posting.

Lucy Bridges writes:

“Saturday 20th September is Software Freedom Day [1]. As many of you will know, this is a worldwide event designed to promote software freedom. I am proud to announce that Manchester Free Software (like many other groups across the country and the world) will be hosting an event to celebrate.” (original)

I don’t know of any events in the Bristol or Somerset areas, but I wish the Manchester event all the best.

When I was in Montreal in August, I got to spend some time with Simon Law, one of the first Free Software/Debian developers I met in full flesh and blood back in 2002. In August he was a bit worn but there was a definite sparkle in his eye. He was working at a new company doing some interesting development but he could not reveal just what had been up to. Just recently he clued me into what he was spending his night, days, and dreams working on. I have to admit, I am at once intrigued, puzzled, and surprised by this new reality based game, which won’t fully come out until 2009 but they are accepting beta testers. As you can read here, Akoha it is a social reality game which uses real world, mobile, and web technologies to engage people in game, play, and do-good type activities. As many others have written about, games are not just about play but they are economically lucrative enterprises. But economies are not only built around finances, money, and gold but can be moral economies based on reputation and also doing good. Akoha is thus directing the energies of fun and play in a combined digital and non-digital environment to build up just this playful moral economy. I look forward to seeing its path develop once it is finally released. If you are still confused as to what Akoha is, this video will shed some additional light on this social experiment.

Only four days are left and these languages, as well as Amharic, Northern Sami, Slovenian, Albanian, Tagalog are in very high danger of being disabled in Debian Installer. For Bengali, I still have some hope as someone volunteered to fill in the gap left. Catalan is still missing its 5 miserable strings but I guess I won't have the guts to disable it just because it is missing strings that warn users that the translation could be incomplete (feel free to laugh at this paradox but if you think this is stupid, just also feel free to come and fix that bug or complete the damn translation). I can now confess that we will reach a point where we will have less translations for the installer in Lenny than we had in Etch. I don't see any reason for this to change in four days. And, yes, I call this sad news as we (particularly Frans) did a lot of improvement in D-I to lower down the requirements. PS: for those who wonder why I mention only 7 languages in that post's title, I indeed picked up those I still have a small hope I can wake up someone to complete the work in these last four days.

Last week I wondered how much space a complete git conversion would actually need—and I was quite surprised:

$ du -hs webwml*
325M    webwml
416M    webwml.git
819M    webwml.svn

The first line is the regular CVS checkout. The third line is the SVN checkout that's available from alioth. You can see that the size is not really something one would want, especially since the real gain is extremely little: besides offline diff you rather have disadvantages with not being able to do much offline because anything history wise requires you to be online. In CVS you at least knew that revision 1.12 of a file is three commits above revision 1.9 of the same file; while in SVN you have no chance offline to know how many commits to a file happened between revision 512 and 1024, if any at all. The conversion to git took me quite a long time, practically almost three days of (non-constant) running git-cvsimport on my laptop. The time did not completely surprise me, at least when I noticed in the end that it were well over 83 thousand commits in well over 10 years, reaching back to July 1998. My first own commit was in July 2001, which wasn't too hard to find out with git neither, and required no online operation. git gives you complete offline access to the history. This is actually something that the build process can be based on. There propably will be some speed drawback with not being able to do simple-math for revision difference like in CVS, but that actually will have to be checked. I'm still convinced being able to do all the stuff offline without any strange hacks or needing to be online all the time is something worthwhile. Things left to do and which I propably won't find the time in the too near future because of ... erm, you know? Lenny? That we want to release? But anyway, to not have the list of things get lost, here is a (not complete) list of things in case you are bored and want to play around a bit:

• Adapt the various scripts to not check CVS revisions but use the sha1 sums.
• Adjust translation-check translation="" value for all files to use sha1 sums.
• Check wether a full website build would work after that changes.
• Try out how submodules work and wether they might be reasonable to use for language subdirectories to allow translators partial checkouts.
• ... other things I've forgotten but that could be added to the WebsiteVCSEvalutaion wiki page.

Playing around a bit? Well, you don't have to do the whole git-cvsimport on yourself: I've pushed my webwml.git repository to alioth: "git clone ssh://git.debian.org/git/users/alfie/webwml.git" should get you started. Please notice to play around in a seperate branch and not directly in origin to be able to pull further and update from time to time.

The most commonly installed software for aggregating RSS feeds seems to be Planet and Venus (two forks of the same code base). The operation is that a cron job runs the Python program which syndicates a list of RSS feeds and generates a static web page. Of course the problems start if you have many feeds as polling each of them (even the ones that typically get updated at most once a week) can take a while. My experience with adding moderate numbers of feeds (such as all the feeds used by Planet Debian [1]) is that it can take as much as 30 minutes to poll them all - which will be a problem if you want frequent updates. Frequent polling is not always desired, it means more network load and a greater incidence of transient failures. Any error in updating a feed is (in a default configuration) going to result in an error message being displayed by Planet, which in a default configuration will result in cron sending an email to the sysadmin. Even with an RSS feed being checked every four hours (which is what I do for my personal Planet installations) it can still be annoying to get the email when someone’s feed is offline for a day. Now while there is usually no benefit in polling every 15 minutes (the most frequent poll time that is commonly used) there is one good reason for doing it if you can only poll. The fact that some people want to click reload on the Planet web page every 10 minutes to look for new posts is not a good reason (it’s like looking in the fridge every few minutes and hoping that something tasty will appear). The good reason for polling frequently is to allow timely retraction of posts. It’s not uncommon for bloggers to fail to adequately consider the privacy implications of their posts (let’s face it - professional journalists have a written code of ethics about this, formal training, an editorial board, and they still get it wrong on occasion - it’s not easy). So when a mistake is made about what personal data should be published in a blog post it’s best for everyone if the post can be amended quickly. The design of Planet is that when a post disappears from the RSS feed then it also disappears from the Planet web page, I believe that this was deliberately done for the purpose of removing such posts. The correct solution to the problem of amending or removing posts is to use the “Update Services” part of the blog server configuration to have it send an XML RPC to the syndication service. That can give an update rapidly (in a matter of seconds) without any polling. I believe that a cron job is simply the wrong design for a modern RSS syndication service. This is no criticism of Planet (which has been working well for years for many people) but is due to the more recent requirements of more blogs, more frequent posting, and greater importance attached to blogs. I believe that the first requirement for a public syndication service is that every blogger gets to specify the URL of their own feed to save the sysadmin the effort of doing routine URL changes. It should be an option to have the server act on HTTP 301 codes and record the new URL in the database. Then the sysadmin would only have to manage adding new bloggers (approving them after they have created an account through a web-based interface) and removing bloggers. The problem of polling frequency can be mostly solved by using RPC pings to inform the server of new posts if the RPC mechanism supports removing posts. If removing posts is not supported by the RPC then every blog which has an active post would have to be polled frequently. This would reduce the amount of polling considerably, for example there are 319 blogs that are currently syndicated on Planet Debian, there are 60 posts in the feed, and those posts were written by 41 different people. So if the frequent polling to detect article removal was performed for active articles, given the fact that you poll the bloggers feed URL not the article that would only mean 41 polls instead of 319 - reducing the polling by a factor of more than 7! Now even with support for RPC pings there is still a need to poll feeds. One issue is that feeds may experience temporary technical difficulty in sending the RPC as we don’t want to compel the authors of blog software to try and make the ping as reliable a process as sending email (if that was the requirement then a ping via email might be the best solution). The polling frequency could be implemented on a per-blog basis based on the request of the blogger and the blog availability and posting frequency. Someone who’s blog has been down for a day (which is not uncommon when considering a population of 300 bloggers) could have their blog polled on a daily basis. Apart from that the polling frequency could be based on the time since the last post. It seems to be a general pattern that hobby bloggers (who comprise the vast majority of bloggers syndicated in Planet installations) often go for weeks at a time with no posts and then release a series of posts when they feel inspired. In terms of software which meats these requirements, the nearest option seems to be the the Advogato software mod_virgule [2]. Advogato [3] supports managing accounts with attached RSS feeds and also supports ranking blogs for a personalised view. A minor modification of that code to limit who gets to have their blog archived, and fixing it so that a modified post only has the latest version stored (not both versions as Advogato does) would satisfy some of these requirements. One problem is that Advogato’s method of syndicating blogs is to keep an entire copy of each blog (and all revisions). This goes against the demands of many bloggers who demand that Planet installations not keep copies of their content for a long period and not have any permanent archives. Among other things if there are two copies of a blog post then Google might get the wrong idea as to which is the original. Does anyone know of a system which does better than Advogato in meeting these design criteria?

• [1] http://planet.debian.org/


• [2] http://www.advogato.org/proj/mod_virgule/


• [3] http://www.advogato.org/

Share This

All the recent moves of Mozilla make me feel that they are really taking the XFree86 path. Reading the Launchpad bug log about the EULA shows that most of the posters agree on who is on the wrong side, and favor switching to IceWeasel or Epiphany+Webkit. Even if Mozilla is apparently going to back off on the EULA story, it looks like the harm was done. If they want to fix that, they will have to start listening to other players in the Free Software community. Or just watch Webkit eat their market share. Since Ubuntu leaders are apparently talking to Mozilla about that, I really hope that they are aiming for a solution that will help the Free Software community as a whole, and are not looking for a work-around that will “fix” the problem for Ubuntu. There has been a lot of noise about the lack of “giving back” to the community by Ubuntu. Using Ubuntu user base to weight in and solve such issues in a way that benefit the whole community would probably be seen as a much more valuable contribution than another bunch of patches.

I concentrated on work after my return to the keyboard last week and then spent much of the weekend reroofing a shed, so today was my first day catching up with the news. Here’s what I noticed:-

• One of my former sponsorees Adriaan Peeters was announced as a debian developer.
• Koha roles for the 3.2 release window were decided at a meeting last Friday - I’ve one public and one private task to do, which I’ll try to start today.
• PAYG iPhone will be an iWatering 400 - see Why I don’t want an iSomething for a view similar to mine. I’m using an old Sony Ericsson 3G phone rather than something like a Freerunner because I don’t have a good mobile telco yet and I don’t plan to start small device software hacking again yet - I tried once before and found it much harder than internet software.
• Tim Berners-Lee Announces World Wide Web Foundation - well, I guess we don’t know yet whether it will be fairer than the pay-to-play consortium.
• Facebook imposes site facelift which makes my fan run all the time (inefficient Javascript?), while LinkedIn launches advertising network - I’m looking for exit strategies from both of these now, but network effects keep sucking me back in.
• The Mozilla Corporation took another step in developing their obnoxious
  “Free Software” EULA which is actually enforced by their very-non-free trademark and logo copyright licensing. It really does show that Debian Iceweasel and GNU Icecat are necessary. Ubuntu get punished for breaking ranks and accepting MozCorp’s non-free terms - Some day, it comes back in your face indeed. And I know it’s juvenile, but the suggestion on the bug report that they rename it “firecox” just to spite MozCorp made me laugh. I’m pretty angry that Mark Shuttleworth incorrectly claims that debian calls it Iceweasel “to belittle or demean” Mozilla, though. “Weasel” was posted here as a simple alternative to “rabbit”. rabbits have bad connotations in many cultures, as tricksters, cowards, disease-carriers, sex-maniacs, bringers of bad luck and so on, while weasels symbolise resurrection and bravery - except in US politics (”weasel words”) and Dilbert, oddly enough.

Ubuntu is now being forced to show a EULA before letting users run Firefox, on pain of losing the rights to the Firefox trademark. (You know, End User License Agreements: those pop-ups Windows and Mac users have to put up with all the time, with the big “I Accept” button at the bottom.) Mark Shuttleworth, Ubuntu top dog, weighs in on the bug:

Please feel free to make constructive suggestions as to how we can meet Mozilla’s requirements while improving the user experience. It’s not constructive to say “WTF?”, nor is it constructive to rant and rave in allcaps. Your software freedoms are built on legal grounds, as are Mozilla’s rights in the Firefox trademark. To act as though your rights are being infringed misses the point of free software by a mile.

This is a bit surprising, and a bit disappointing. Both the decision itself, and Mark’s take on it, are quite wrong. One of the most important benefits of free software is the legal agreement you work in. You don’t have to agree to some long contract every time you need to do something new on your system, or sometimes even when you get a “critical update” to something you’re already doing. You don’t have to read pages of legalese, or go through some long process with your company’s legal department, or just click the “make it go away” button with this vague unease that you’ve just signed your first-born child away to the Devil. Most importantly, you feel like you actually own your computer when you run free software on it. When you enter a situation where you always have to ask permission to do things, and have to be constantly reminded of the rules, you don’t feel comfortable. Clearly, the thing in front of you is not yours, whatever your credit card bill might say; if it were, there wouldn’t be all this stress over you doing something the real owners don’t like. Free software returns your computer to you, by guaranteeing that you don’t have to enter into all these contracts before you can use it. Well, unless that “free” software is Firefox 3.0.2 or later, it seems. It’s “free” by a technical definition (you can strip the Firefox trademark rather easily, and get rid of the EULA as well). But when users fire up Ubuntu, and decide to do some browsing, and get confronted with pages of legal garbage and ALL CAPS, they will ask: “What’s so different about this open source stuff? I thought I was getting rid of all this legal crap.” And, suddenly, they’re slogging through the same drudgery they had to endure with every Windows service pack, and they wonder what they’ve gained. Perhaps there is a price we should be willing to pay to help Mozilla preserve their trademarks, but this price is too great. Mozilla should never have asked this of us, and Ubuntu should never have decided, on our behalf, that this price was acceptable. Debian has already turned its back on Firefox, and I have yet to have a problem with Iceweasel (the branding Debian chose for its Firefox-alike) that was caused by the branding change. But I’m tempted to bring it back, in Debian’s “non-free” software repository. Perhaps we could provide Firefox, complete with nasty EULA, but launch Iceweasel instead of Firefox if the user clicks “No”. There are probably all kinds of reasons why this is a bad idea, but I’m still drawn to the idea of illustrating how silly and useless click-through EULAs are. But it would be much more productive for Mozilla to back down, and not ask us to sacrifice such a large part of our identity on the altar of their sacred mark. UPDATE: First, I notice I was remiss in not giving a hat tip to Slashdot. Second, Mark has posted another comment on the bug. I encourage people to read the whole comment, but here’s a telling part:

For example, at the moment, we’re in detailed negotiations with a
company that makes a lot of popular hardware to release their drivers as
free software - they are currently proprietary. It would not be possible
to hold those negotiations if every step of the way turned into a public
discussion. And yet, engaging with that company both to make sure Ubuntu
works with its hardware and also to move them towards open source
drivers would seem to be precisely in keeping with our community values. In this case, we have been holding extensive, sensitive and complex
conversations with Mozilla. We strongly want to support their brand
(don’t forget this is one of the few companies that has successfully
taken free software to the dragons lair) and come to a reasonable
agreement. We want to do that in a way which is aligned with Ubuntu’s
values, and we have senior representatives of the project participating
in the dialogue and examining options for the implementation of those
agreements. Me. Matt Zimmerman. Colin Watson. Those people have earned
our trust.

On the one hand, yes, I believe that the Canonical people have earned our trust, and I do appreciate the utility of quiet persuasion with a proprietary software company that doesn’t understand our community. On the other hand, I had been under the impression that Mozilla was not a proprietary software company, and didn’t need persuasion and secret negotiations to see our point of view. Is Mozilla still a free software company, or not? UPDATE 2: Cautious optimism is appropriate, I think. Mitchell Baker, Mozilla chair:

We (meaning Mozilla) have shot ourselves in the foot here given the old, wrong content. So I hope we can have a discussion on this point, but I doubt we ll have a good one until we fix the other problems.

The actual changes aren’t available yet, and I wonder how much of this had been communicated to Canonical beforehand. Still, it’s a good sign.

In a comment on my Not All Opinions Are Equal [1] post AlphaG said “Anonymous comments = free software, no intrinsic value as you got it for nothing”. After considering the matter I came to the conclusion that almost all software has no intrinsic value (unless you count not being sued for copyright infringement as intrinsic value). When you buy software you generally don’t get a physical item (maybe a CD or DVD), to increase profit margins manuals aren’t printed for most software (it used to be that hefty manuals were shipped to give an impression that you were buying a physical object). Software usually can’t be resold (both due to EULA provisions and sites such as EBay not wanting to accept software for sale) and recently MS has introduced technical measures that prevent even using it on a different computer (which force legitimate customers to purchase more copies of Windows when they buy new hardware but doesn’t stop pirates from using it without paying). Even when software could be legally resold there were always new versions coming out which reduced the sale price to almost zero in a small amount of time. The difference between free software and proprietary software in terms of value is that when you pay for free software you are paying for support. This therefore compels the vendor to provide good support that is worth the money. Vendors of proprietary software have no incentive to provide good support - at least not unless they are getting paid a significant amount of money on top of the license fees. This is why Red Hat keeps winning in the CIO Vendor Value Studies from CIO Insight [2]. Providing value is essential to the revenue of Red Hat, they need to provide enough value in RHEL support that customers will forgo the opportunity to use CentOS for free. Thinking of software as having intrinsic value leads to the error of thinking of software purchases as investments. Software is usually outdated in a few years, as is the hardware that is used to run it. Money spent on software and hardware should be considered as being a tax on doing business. This doesn’t mean that purchases should be reduced to the absolute minimum (if systems run slowly they directly decrease productivity and also cause a loss of morale). But it does mean that hardware purchases should not be considered as investments - the hardware will at best be on sale cheap at an auction site in 3-5 years, and purchases of proprietary software are nothing but a tax.

• [1] http://etbe.coker.com.au/2008/09/13/not-all-opinions-are-equal/


• [2] http://www.redhat.com/promo/vendor/

Share This

A couple of years ago Debian had to change the name of Firefox to Iceweasel because Mozilla Corp. was using their trademark to impose conditions on the software that were not restricted by the license. Now the problem is brought again to life for Ubuntu, with Mozilla forcing them to show an EULA before letting users start Firefox. Jeff Licquia explains the situation quite well, in any case. At first glance, having to add an EULA seems a small price to pay, but underneath the obvious there might be something really serious happening. Software licenses seems to be just one of the possible ways of restricting users’ freedom. We’ve already seen some companies trying to use different methods to restrict it: via software patents, tivoization, etc. It seems we might want to add the usage of trademarks to the list. According to the Free Software Definition, there are four types of freedom that users need to have to consider a program as Free Software:

• To run the program, for any purpose (freedom 0)
• To study how the program works, and adapt it to your needs (freedom 1)
• To redistribute copies (freedom 2)
• To improve the program, and release your improvements (freedom 3)

In any case, nowhere is said that those freedoms must be given just to end users. Distributions and such must also have these freedoms, including the freedom to modify the program and adapt it to their needs, and their users’ needs. While it makes sense that you cannot call a program Firefox just because it includes 10 lines from its source code, it also doesn’t seem tolerable to try to use trademark to prevent you from adapting the program to your needs and keep calling it free. Is it valid that an organization or company tries to restrict that freedom for you by using their trademark rights? Should a clause preventing that be added to GPL4? In any case, the final reason for the discussion seems to be much ado about nothing, as the EULA does not, and cannot, add any restriction to the usage of the program. First freedom (to run the program, for any purpose), remember?

As I crawl through the social science literature a very painful endeavour, believe me it fills me with disgust to see how much bullshit is being spread as authors randomly insert citations into their text to back up some claim they need to argue their case. Often, the claim is something in which I am interested, so I go out and seek the reference they cite only to find that the referenced authors say nothing even remotely related to the claim for which they were cited. It is happening all over the place, and even in articles that appeared in renowned journals. If we ever get to the point where all academic articles are properly interlinked so that references can be automatically checked and I don t mean just checked for correctness of the reference data, but for actual correctness of the reference then the population of academics will probably shrink to single-digit percentages, at least for the social sciences; I don t recall it being much different when I was researching artificial intelligence a few years ago though. Until then, I am compiling a list. Whether I ll publish it and point journal editors at, or just send it to the journals depends on my mood at the time. NP: Guns n Roses: Appetite for Destruction

One thing that's annoying about the Debian installer on the NSLU2, as Joey Hess pointed out a few months ago when he reinstalled his NSLU2, is that you have to manually select some installer modules. The reason for this is that the NSLU2 only has 32 MB of RAM and thus Debian installer runs in lowmem mode in which less functionality is enabled by default. As a result of this, you have to select partman-auto, partman-ext3 and usb-storage-modules from a list of additional installer modules to load so the installer will recognize your USB disk, offer guided partitioning and format the disk with ext3. When Joey submitted his installation report, Frans Pop suggested that we could put a list of installer modules we want to have installed automatically in /var/cache/anna/include. I finally got around to playing around with this yesterday and while this specific solution won't work on lowmem systems we can use anna-install to automatically queue installer modules for installation. Since anna-install works, I put some functionality into the installer today to automatically load required installer modules on the Linksys NSLU2 and on Cobalt machines. This change is good for users because they don't have to select some modules during the installation. I'm a little bit worried that existing users of the installer on the NSLU2 will be confused when they don't see the modules in the list anymore, but I'll update the documentation accordingly.

New testing version of Gammu was just born. It brings quite a lot of fixes. Also the Windows binary should be again a bit more stable. Full list of changes:

• Fixed Windows binary (define properly MSVCRT to use) (bug #683).
• Fixed compilation with CURL on Windows.
• Windows binary now has only MySQL and CURL support (bug #683).
• Fill in timezone information (bug #696).
• Detect reserver message type (bug #691).
• Increase timeout for switching to OBEX (bug #690).
• Disable postal address for Nokia 2600 (bug #659).
• Encode phone number only with phones which need it (bug #654).
• Increase timeout for writing memory entry (bug #654).
• Handle properly when phoned does not tell SMSC (bug #616).
• Initial support for waiting calls in AT engine (bug #551).
• Fixed dialing on some AT phones (bug #471).
• Support for skipping location when reading (bug #467).
• Improved detection of serial port Bluetooth channel.
• SMSD reconnects to MySQL (thanks to Wouter D'Haeseleer).
• SMSD stores signal and battery state in MySQL (thanks to Wouter D'Haeseleer).
• Initial support for reading messages in simple text mode.
• Report if monitor failed because of an error.
• Handle not found errors on OBEX connect (bug #705).

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon. PS: I still have about 50 unread mails about Gammu, so please be patient.

Having already done some Debian packages of OCaml libraries, I wish to share my experience on what are the most common problems. The intent is to help people releasing OCaml libraries to have a good interaction with (Debian) packager. I think most of the tips should also apply to other distributions as well. I consider the use of findlib mandatory for this task as described in the Debian OCaml packaging policy. Problems listed here are common, and I have encountered them for my libraries... In fact, most of the time when I finished building a personnal OCaml library I package it for my own and to test that everything is fine. Being a packager and an upstream author is really a different job. "Upstream author" is used for people developing and releasing OCaml libraries and "packager" for people doing packages for a distribution. Here is the list of the most common problems and their solutions:

• Missing the "static link clause" in COPYING/LICENSE

Libraries are linked statically in OCaml. It is an advantage and a problem. But upstream author should remember that the LGPL license doesn't support static link directly. If you link an executable with the library statically, the executable is contaminated by the license. This error is probably the most problematic, because it requires to go through the whole project fixing license header for explaining that there is an exception to the LGPL. There is no way for a packager to fix this problem. Packager are not allowed to change the license. Library having this problem can be still packaged but complicate the legal aspect of building application using this library. Good example of this can be found in OCaml LICENSE itself :

As a special exception to the GNU Library General Public License, you
may link, statically or dynamically, a "work that uses the Library"
with a publicly distributed version of the Library to produce an
executable file containing portions of the Library, and distribute
that executable file under terms of your choice, without any of the
additional requirements listed in clause 6 of the GNU Library General
Public License.  By "a publicly distributed version of the Library",
we mean either the unmodified Library as distributed by INRIA, or a
modified version of the Library that is distributed under the
conditions defined in clause 2 of the GNU Library General Public
License.  This exception does not however invalidate any other reasons
why the executable file might be covered by the GNU Library General
Public License.

Followed by the text of the LGPL. Each file header looks like:

This file is distributed under the terms of the GNU Library General
Public License, with the special exception on linking described in 
file ../LICENSE.

• Forget that some architecture doesn't have an ocamlopt compiler

By far this is the most common error I have seen. Upstream author consider that you are able to build a native and byte version of their library. Unfortunately this is not the case for most architectures. This error is pretty simple to fix by separating byte and opt targets in Makefile. The ultimate test is to rename /usr/bin/ocamlopt and /usr/bin/ocamlopt.opt to something different and try to rebuild the library from scratch.

• Missing or incomplete META file

META file is the base of everything in findlib. This is very important to provide good META file because it helps other people to easily build thing over OCaml library. Each library should provide its own META file. Until now, Debian packager was used to write this missing META file and contribute it to upstream author. I think that now findlib has become a standard in OCaml developement, so upstream should take into consideration this file. A good test for META file is to install it and:

~$ ocaml
        Objective Caml version 3.10.1
# #use "topfind";;
- : unit = ()
Findlib has been successfully loaded. Additional directives:
  #require "package";;      to load a package
  #list;;                   to list the available packages
  #camlp4o;;                to load camlp4 (standard syntax)
  #camlp4r;;                to load camlp4 (revised syntax)
  #predicates "p,q,...";;   to set these predicates
  Topfind.reset();;         to force that packages will be reloaded
  #thread;;                 to enable threads
- : unit = ()
# #require "ZZZ";;

If you are able to load your library in ocaml toplevel, this is a good point.

• Doesn't use ocamlfind to install library

ocamlfind allow to install library. Using it is the best way to install your ocaml library. Moreovoer, you should use the most simple way to install. For pure OCaml library this is straightforward and allow Debian packager to override destination directory by using environment variable OCAMLFIND_DESTDIR.

install:
      ocamlfind install toto META toto.mli toto.cmi toto.cmxa toto.cma toto.cmx

For non-pure library, you could add a OCAMLFINDFLAGS variable to allow Debian packager add "-ldconf ignore":

install:
      ocamlfind install $(OCAMLFINDFLAGS) toto META toto.mli toto.cmi toto.cmxa toto.cma toto.cmx

• Doesn't distribute .mli files

".mli" files is the human-readable interface to the library. Even if most OCaml programmers use the ocamldoc HTML API of the library, it is best to distribute these files. In particular, Debian packager use it to automatically generate up-to-date HTML API documentation directly.

• Doesn't distribute .cmx files

".cmx" files contain more informations than ".cmxa". Distributing these files allow application based on the library to be more optimized.

• Forget about other OS files

This one comes from my "Windows experiment". Most of the time upstream author doesn't forget about "*.a" but doesn't add "*.lib" (yes is this windows counterpart of ".a" file).

• Use bad wildcard for file to distribute

This one is not very OCaml specific. In Makefile and sh you have the same wildcard "*.mli". But if the wildcard is not expanded into sh, it just stay as is. It will make the executable called looked for a file "*.mli" literally. Mixing Makefile wildcard and sh is the best option here:

install:
     ocamlfind install $(OCAMLFINDFLAGS) toto META $(wildcard *.mli *.cmi toto.cmxa toto.cma *.cmx)

This way you test and expand to only existing files.

• Use a custom build system

This is more or less a problem. In fact, if everything is fine, there is no problem and you should just forget about this point. If the custom build system is complex and if there is an error in it: it becomes a big problem. I must confess that I have myself done this kind of mistake a lot of time. But looking back, I think that most of the time I should have used directly OCamlMakefile. I think relying on ocamlfind for library installation, simple Makefile, OCamlMakefile, OMake or ocamlbuild, is just enough.

• Missing BTS

This point is a problem for upstream author and communication with packagers (from Debian and other distributions). A bug tracking system is a way to publish, comment, work on and find solution of bugs. If you have a single problem in a library having the bug public helps people to show you what is wrong. Of course, Debian (and Fedora, FreeBSD...) has its own bug tracking system and upstream author can use it directly. This is less work for upstream but tends to make the bug "distribution specific". Having an upstream author BTS helps to track the bug across distributions. If upstream author doesn't like maintaining their own BTS, he/she should consider hosting part of the project on a forge like OCamlCore.org. Even if they don't host the source code, this is still a good idea. That's all. If you have other common problems, feel free to comment, i will add it to the list.

I am often asked for advice about purchasing TVs and consumer electronics. Not that I am any great expert in those areas, but my general experience in specifying and purchasing electronics goods in related to my computer work does translate to other areas (and I know where to find advice on the net). As part of this I get to closely observe what happens when people install new home entertainment systems. I have not observed anyone who uses anywhere near the full function of their system, even using the bare minimum functionality in all areas is very rare. I believe that the first problem with this is the input devices. A remote control is designed around the idea of one button for each high-level command, this can be compared to languages such as Chinese and Japanese which have one character per word. In terms of language evolution it seems that the benefits of having multiple characters became apparent and widely accepted thousands of years ago. Now for a simple input device having one button for each high-level operation makes sense. For the basic functions of a VCR you have PLAY, STOP, Fast-Forward, Rewind, Record, and Eject - 6 buttons is quite reasonable. But then you want slightly advanced features such as “record from 8PM to 9PM on channel A and then record from 10PM to 11PM on channel B” and things become unreasonably difficult. More than 10 years ago I was recommending that people just buy 5 hour tapes and press record before leaving home, getting the full functionality out of a VCR was just too hard. Jokes are often made about people who leave their VCR flashing 12:00 (because it’s too difficult to set the time), I only set the time on a VCR to stop the flashing (flashing lights annoy me). Since programmable VCRs became popular things have only continued to develop. Now it’s not uncommon to have separate remote controls for the TV, VCR, DVD player, and the Cable TV box - a total of four remote controls! This is obviously a problem, and the solution that some people are adopting is to have a single more complex remote control - this is an example of problems not being solved by the same type of thinking that caused them. One of the attempts to solve this is to have everything controlled by a PVR [1]. This means that you have one device recording content (maybe from multiple sources or multiple channels), playing recorded content or live content, and maybe playing DVDs and CDs. Of course then you have a complex remote control for that device which just shifts the problem. To solve these problems we need to consider the entire problem space from a high-level. We start with the signal that is displayed by the TV, it can come from cable TV, digital TV, analogue TV, VCR, or DVD - these input sources have names such as “Composite”, “RCA1″, “RCA2″, “RCA3″, “DTV”, and “ATV”. Often people have written instructions near their TV to map these names to what they do. Obviously the TV needs to be able to be programmed with human friendly names, and as these names are not of much use on their own it should be possible to use compound names and abbreviations. If I want to watch ABC (the Australian Government sponsored TV channel) then I would rather type “ABC” on a keyboard and then have the entertainment system determine whether that maps to “cable:abc”, “dtv:abc”, or “atv:abc” depending on what options are available. The current process of choosing an input source (such as RCA1 mapping to cable TV) and then choosing a channel (102 mapping to ABC) means among other things that it is essentially impossible for a guest to control the TV. A further problem is the lack of available output. While it might seem that a large-screen HDTV has adequate output available, it’s often the case that you don’t want to stop watching one show while trying to find another. When something of wide interest is happening (another war or an election) it’s common for several people in one room to want to watch the news. Having everyone stop watching while someone goes through menus to find a different news channel is not well accepted. It seems to me that we need a separate output mechanism for controlling the entire system from that which is used for the main display. This of course requires integration between all parts of the entertainment system, which shouldn’t be that difficult given the complexity of all the components (every one of which has more compute power than a typical server of 20 years ago). It is currently quite common for PVRs and DVD players to support playing videos from USB and SD devices, so the next logical step is to get an Ethernet port in each device (and maybe have Ethernet switches built in to some of the high-end entertainment hardware). Then XML transferred over HTTP could be used for controlling the different components from a single web server which provides a web-based GUI. While a random guest would not get much functionality out of my TV configuration (or that of most homes where I have assisted in the configuration of new hardware), they shuold be able to use a web-based GUI with ease. For controlling the entire system a NetBook [2] computer such as the EeePC should do well. As high-end TVs cost over $5,000 an EeePC which costs $500 (list price - surely less in bulk) could easily be bundled without much impact on the overall price in the same way that companies selling computers in the $1,000,000 price range used to bundle $10,000 workstations to manage them. An EeePC has abut the same size and mass as four remote controls (so it wouldn’t be inconvenient to use). Also the built-in wifi could be used for the remote control (wires are inconvenient and Infra-Red has limited bandwidth so probably wouldn’t provide a good web based GUI). Also someone who wanted to save some money could instead choose to use an old laptop on a coffee table (any web browser would do). I have deployed Linux desktop machines for some people who had no trouble using it, but who then had trouble using TVs that I configured for them - so I conclude that a modern Linux distribution is significantly more user friendly than the equipment that you find in a modern lounge room. Cable TV companies all seem to be ISPs and often provide compelling value as an ISP service if you want to use the TV service. So it seems that the “Cable Modem” could be built in to the Cable TV box for added savings in hardware purchase and less boxes to manage in the home. This of course would increase the value of a NetBook [2] as a remote control as it could also be used for general Internet access at the same time. TV shows often promote their web sites to their customers and TV advertising also often includes a URL. If the URLs were distributed by VideoText then that would provide more information for the viewers, a better reach for advertisers and people who create the TV shows, and it when it became popular it would save us fom those stupid scrolling news tickers that appear on the bottom of most cable new shows! Some of these benefits are currently achieved by people running MythTV. The first problem with Myth is that it is still largely stuck to the bad old UI paradigm (which of course can be fixed as it’s free software). The next problem is that getting a result of comparable quality to the dedicated hardware is expensive, difficult, or both. A regular PC makes more noise than you desire in your lounge room and configuring a Myth machine for your choice of DTV hardware and the frequencies used in your location is a pain. You can buy a preconfigured machine which solves these problems, but it will be more expensive. For most lounge rooms the cheap Chinese hardware is what will be used. Ultimately I believe that TV will be killed by the Internet. The range of content on the net is increasing and the rate of acceleration is also increasing. TV seems to have not made any significant changes since the introduction of cable and satellite TV (both of which happened a long time ago and were not significant changes). But I don’t expect it to happen soon. I predict another 10 years of the current TV business model. I believe that better integration of home entertainment hardware so that it can obey simpler commands from the user in a more friendly manner while not getting in the way of the main purpose (displaying the TV picture) has the potential to extend the life of the current TV business model. Not that I care whether the TV industry dies sooner or later. I just want to escape from having to provide phone-support to people who can’t get their TV to work correctly!

• [1] http://en.wikipedia.org/wiki/Digital_video_recorder


• [2] http://en.wikipedia.org/wiki/Netbook

Share This

Generating missing tangogps tiles TangoGPS is nice, but it wants to download tiles. However, I already have a working mapnik setup, so why bother the OpenStreetMap servers with tile requests?

1. Set up a mapnik environment like I explained with gpsdrive, but use the -m switch to osb2pgsql.
2. svn co http://svn.openstreetmap.org/applications/rendering/mapnik/
3. Edit set-mapnik-env to configure it. Make sure that MAPNIK_TILE_DIR points to Maps/OSM as used by TangoGPS.
4. ./set-mapnik-env ./customize-mapnik-map > osm.xml
5. Edit generate_tiles.py to customise the area that you want to generate. Make sure that when setting bbox the first latitude is smaller than the second latitude, and the same for longitude.
6. Run ./set-mapnik-env ./generate_tiles.py and watch it paint your tiles. Note that if a tile has already been downloaded, it will not download it again.

The primary change in this version is some sorting-out of the Unicode support. Thank you very much to H. Merijn Brand and Juerd Waalboer for their patient explanations of the Perl core test suite failures and how Perl Unicode support is supposed to work. As of this version, Unicode support in pod2man and Pod::Man will not work properly unless the POD input properly declares =encoding utf-8. This is required, and always has been required, by the POD specification. Without this setting, some Unicode settings of Perl will result in doubled encoding. Proper encoding is now tested in the test suite. This version also adds a --stderr option to pod2man and pod2text and a corresponding setting to Pod::Text and Pod::Man which sends errors in the POD to stderr instead of to a POD ERRORS section in the generated file. This may be preferrable, since the POD errors aren't of interest to the end-user and errors may be more visible during the build. There are some additional fixes to the documentation and the spelling checks, thanks primarily to Niko Tyni. You can get the latest version from the podlators distribution page.