I have been thinking about ways to speed multiple remote git on the same hosts. My starting point is mr, which does the job, but is a bit slow. I am thinking about giving up some generality for some speed. In particular it seems like it ought to be possible to optimize for the two following use cases:

• many repos are on the same host
• mostly nothing needs updating.

For my needs, mr is almost fast enough, but I can see it getting annoying as I add repos (I currently have 11, and mr update takes about 5 seconds; I am already running ssh multiplexing). I am also thinking about the needs of the Debian Perl Modules Team, which would have over 900 git repos if the current setup was converted to one git repo per module. My first attempt, using perl module Net::SSH::Expect to keep an ssh channel open can be scientifically classified as "utter fail", since Net::SSH::Expect takes about 1 second to round trip "/bin/true". Initial experiments using IPC::PerlSSH are more promising. The following script grabs the head commit in 11 repos in about 0.5 seconds. Of course, it still doesn't do anything useful, but I thought I would toss this out there in case there already exists a solution to this problem I don't know about.

 
#!/usr/bin/perl
use IPC::PerlSSH;
use Getopt::Std;
use File::Slurp;
my %config; 
eval( "\%config=(".read_file(shift(@ARGV)).")");
die "reading configuration failed: $@" if $@;
my $ips= IPC::PerlSSH->new(Host=>$config host );
$ips->eval("use Git");
$ips->store( "ls_remote", q my $repo=shift;
                       return Git::command_oneline('ls-remote',$repo,'HEAD');
                            );
foreach $repo (@ $config repos ) 
    print $ips->call("ls_remote",$repo);
 

P.S. If you google for "mr joey hess", you will find a Kiss tribute band called Mr. Speed, started by Joe Hess" P.P.S. Hello planet debian!

In a previous post I complained that mr was too slow. madduck pointed me to the "-j" flag, which runs updates in parallel. With -j 5, my 11 repos update in 1.2s, so this is probably good enough to put this project on the back burner until I get annoyed again. I have the feeling that the "right solution" (TM) involves running either git-daemon or something like it on the remote host. The concept would be to set up a pair of file descriptors connected via ssh to the remote git-daemon, and have your local git commands talk to that pair of file descriptors instead of a socket. Alas, that looks like a bit of work to do, if it is even possible.

Leaving Doc Watson early, I headed up State St. in a hurry, taking the sidewalk to avoid the crowd in the road. But I had to stop to listen to a few classics from a five-piece string band, sitting under the awning of Uncle Sam's Loan Office, in front of the display of old stereos and swords. Bunch of real old-timers. Pulled myself away only to pass by an even better, six-piece band in the entrance to The Gold Man pawn shop. The fiddle was played by a girl who couldn't be older than ten. I wanted to listen to them some more, but I managed to pull myself away in time to get into the Paramount and get a good seat for the Red Stick Ramblers. Conclusion: This town needs more pawn shops. And it's Rhythm and Roots time in Bristol. Best bands so far: Mike Marshall's trio, Cephas and Wiggins, Larry Keel and Natural Bridge, Chatham County Line.

After releasing a new Free Software project to the world, you may be interested to see it included by the main Linux or Free Software distributions. After all this is the easiest way for end-users to download and install your software.

Here are a couple of technical details that will increase the chances that your project will be picked up by a distribution.
Can I distribute this software?The first question that a distribution maintainer will need to answer is this one: can my distribution legally distribute this piece of software?

There are two ways you can help here:

• Make your chosen license clearly visible (normally in a file called COPYING or LICENSE).


• Include a clear copyright statement in your documentation (inside README for example).

Once your software has past this check, the next question will be of course: does it actually work?
Will it work on my distro?To answer this question, the maintainer will have to install the software and figure out all of the external dependencies that need to be installed at the same time.

Therefore, your tarball should include:

• all of the steps (and exact commands) that are necessary to install your software on a standard Free Software distribution


• a list of the external libraries and tools that your software requires to run

What's changed?Another element that can make life easier for the maintainers of your software in downstream distributions is to include indications of what changes from one release to the next.

One important detail is to use a sane versioning system. In a nutshell, this means:

• Version numbers should always be increasing (e.g. in normal ASCII sorting, 1.0pre1 comes after 1.0).


• Any change to the contents of the tarball should trigger a version bump.


• The difference in version numbers from one version to the next should give an indication of the magnitude (minor v. major) of the change.

Another thing that you should include is a changelog (normally in a file called Changes or ChangeLog). This document will be used by maintainers to decide when to upgrade to a new version and to figure out which bugs may be fixed by the new version. It should contain:

• release date
• version number
• summary of the changes since the last version

Finally, to make sure that distro maintainers don't miss new releases of your software, make sure you sign your project up on Freshmeat and announce new releases there.
Proposing your Package to DistrosOn Debian, the main way that users and upstream developers can suggest packages for inclusion in the archive is through the Debian Bug Tracking system. Bugs are filled against the special wnpp (Work-needed and Prospective Packages) pseudo-package and are titled something like RFP: superfoo -- bringing more foo to the desktop where RFP stands for "Request For Package".

Alternatively, if you are a Debian/Ubuntu user, you may also want to build and maintain the package yourself. In which case, you will need to find a sponsor.

Other distributions have different procedures. Feel free to leave a comment explaining what these may be.

More detailed information on getting packaged for Debian is available on the Debian wiki.

The IMSc recently installed a desktop machine for me that is powerful enough to run Xen virtualised domU's. (My previous desktop machine was removed at my request; explanations at a later date!) One task was to get Fedora Core running under this Debian Etch machine. Since the information required for this task was rather difficult to find (rant later!), here is a quick 2-paise tip (to borrow a phrase from the linux gazette) on how to get Fedora Core running under a Debian Xen machine. The helpful packages under Debian are xen-tools and rinse.¹ Since the latter is only available with "lenny", this requires an schroot installation about which I have written elsewhere. So let me assume that we have a lenny chroot inside the dom0 in which xen-tools and rinse have been installed. One can either bind mount /etc/xen from the dom0 into the lenny chroot or one can just create this directory to hold the configuration file for the domU to be created. Creating the domU is as simple as:

xen-create-image --ip=192.168.17.71 --hostname=fedora \
  	--arch=amd64 --lvm vg0 --install-method rinse \
  	--dist fedora-core-8

   

with ip address, hostname, lvm volume group and arch chosen appropriately. (Be careful and choose a hostname that does not match a hostname that you have already used in the same Xen system). This will create the logical volumes /dev/vg0/fedora-disk and /dev/vg0/fedora-swap containing the appropriate images for use with the Fedora domU. Before you can boot into this domU there are some minor issues you need to fix; see #499476. The fixes are to create /etc/shadow and /etc/gshadow and set a usable password as follows. Mount /dev/vg0/fedora-disk somewhere and chroot to it. Then run the following commands:

  pwconv
  grpconv
  passwd root

   

Then exit the chroot and unmount /dev/vg0/fedora-disk and then exit the lenny chroot. If necessary, copy the file etc/xen/fedora.cfg from within the lenny chroot to /etc/xen/ in the dom0. You should now be ready to boot your Fedora Core 8 domU with

  xm create fedora.cfg

   

It would be nice if one could install Fedora Core 9 the same way; see #499477.

Within the last couple of days, I've started using xmonad, a tiling window manager, instead of KDE. Tiling window managers automatically position most windows on your screen, freeing you from having to move, rearrange, and resize them all the time. It sounds scary at first, but it turns out to be incredibly nice and efficient. There are some nice videos and testimonials at the xmonad homepage.

I've switched all the devices I use frequently to xmonad. That includes everything from my 9.1" Eee (1024x600) to my 24" workstation at work (1920x1200). I've only been using it for 2 days, but already I feel more productive. Also my wrist feels happier because I have almost completely eliminated the need to use a mouse.

xmonad simultaneously feels shiny and modern, and old school. It is perfectly usable as your main interface. Mod-p brings up a dmenu-based quick program launcher, keyboard-oriented of course. No more opening up terminals to launch programs, or worse, having to use the mouse to navigate a menu for them.

There's a lot of documentation available for xmonad, including an "about xmonad" document, a guided tour, and a step-by-step guide to configuring xmonad that I wrote up.

I've been using KDE for at least 8 years now, if not more. WindowMaker, fvwm2, fvwm, etc. before that. This is my first step with tiling window managers, and I like it. You can, of course, use xmonad with KDE. Or you can go "old school" and set up a status bar and tray yourself, as I've done. KDE seems quite superfluous when xmonad is in use. I think I've replaced a gig of KDE software with a 2MB window manager. Whee!

Take a look at xmonad. If you like the keyboard or the shell, you'll be hooked.

A few days ago I was awarded official Debian Developer status. Many thanks to:

• Thomas Viehmann
• Ana Beatriz Guerrero L pez
• Daniel Baumann
• Christoph Berg
• Thomas Bushnell, BSG
• Stephen Gran
• Steve McIntye
• Neil McGovern
• Cyril Brulebois
• Matthew Johnson
• Sune Vuorela
• Peter Palfrader
• Jonathan McDowell
• Tim Retout

For posterity, my first experience with the Debian development process was with #400550. Never underestimate the importance of giving credit in changelog entries.

A research conducted by Noel A. Card at the Universities of North Carolina and Kansas, that appears in the September / October issue of journal Child Development, challenges the popular misconception that indirect aggression is a female form of aggression. The meta-analysis is based on 148 studies of aggression in children and adolescents in schools, involving on the whole about 74,000 children and adolescents. Direct aggression is what we might call physical aggression, and indirect aggression includes covert behaviour designed to damage another individual’s social standing in his or her peer group. Based on the analysis, the researchers suggest that children who carry out one form of aggression may be inclined to carry out the other form. This is seen more in boys than in girls. The popular myth that girls are more likely to be socially aggressive has been proven wrong by this analysis, even though it has persisted among teachers, parents, and even among researchers, probably because of social expectations and recent movies and books portraying girls as mean and socially aggressive. They also found ties between both forms of aggression and adjustment problems. Direct aggression is related to problems like delinquency and ADHD-type symptoms, poor relationships with peers, and low prosocial behaviour such as helping and sharing, while indirect aggression is related to problems like depression and low self-esteem, as well as higher prosocial behaviour (perhaps because a child must use prosocial skills to encourage peers to exclude or gossip about others).

Sitting next to the fire after heating up fajitas for dinner. Making sure that no hot coals make it over to the canvas topped yurt. Maybe I should have made the fire further off. I've gotten 1/3 of the way through Anathem, and Neal Stephenson has thoroughly hooked me now. I know I won't have enough battery power to read all I'd like to tonight. But for now, I've been enjoying the evening, which has been unusually long today. Maybe it's a remnant of Hurricane Ike that's led to such a cool, cloudy day, but it's seemed to be on the verge of dusk for hours. Someone asked if the yurt has wifi. Nope, but I measured the distance today, and at 400 feet it's too far for cat 5 ethernet w/o a repeater. Anyway, I seem to be in a very good frame of mind for starting Anathem, and am enjoying its take on the Long Now. Out at the falls this weekend I kept imagining how they'd change in geologic time, tracking where the water seemed to have fallen earler, downstream. And sitting up under the overhang of the falls, was briefly nervous about it coming down (as it will in oh, a few thousand years perhaps), before getting back into the present moment.

I was watching So You Think You Can Dance [1] and thinking about the benefits that it provides to the dancing industry. The increase in public appreciation for the sport will increase the amount of money that is available to professionals, and getting more people interested in dancing as a profession will increase the level of skill in the entire industry. While the show hasn’t interested me much (I prefer to watch dancing in the context of music videos and avoid the reality TV aspect) I appreciate what it is doing. On a more general note I think that anything which promotes interest in the arts is a good thing. I have been wondering whether similar benefits can be provided to the IT industry through competitions. There are some well established programming contests aimed at university level students and computer conferences often have contests. But the down-side of them in terms of audience interest is that they are either performed in exam conditions or performed over the course of days - neither of which makes for good viewing. The audience interaction is generally limited to the award ceremony and maybe some blog posts by the winners explaining their work. There are a number of real-world coding tasks that can be performed in a moderate amount of time. One example is debugging certain classes of bugs, this includes memory leaks, SEGVs, and certain types of performance and reliability problems. Another is fixing man pages. A way of running such a contest might be to have a dozen contestants on stage with their laptops connected to a KVM switch. They could choose tasks from the bug list of their favorite distribution, and when they completed a task (built a deb or rpm package with the bug fixed and updated the bug report with a patch) they could request to have their port on the KVM switch and their microphone enabled so that they could explain to the audience what they did. Points would be awarded based on the apparent difficulty of the bug and the clarify of the explanation to the audience. A major aim of such an exercise would be to encourage members of the audience to spend some of their spare time fixing bugs! Basically it would be a public Bug Squashing Party (BSP) but with points awarded and some minor prizes (it would be best to avoid significant prizes as that can lead to hostility).

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

Share This

Siva Vaidhyanathan has written a short piece for the Chronicle of Higher Education that make a simple but very important move: he demystifies the idea that most youth in the US, much less the world, are part a tech-savvy generation. The point should be made as there are a slew of not only journalists (who let’s face it, exaggerate and simplify and well, there is not much we can do about it) but academics making making and circulating claims. These not only don’t hold much water, but also hide some serious disparities out there when it comes to access and also hides the fact that the phenomena people extend to wide swaths of the population are usually far more circumscribed and cultural in their orientation. I think his point hit home recently because my class on an uber-techie subject, hackers, is primarily composed of students who have never started a blog, don’t read blogs, have never used much less heard of RSS feed etc. I am not saying this either to disparage this fact (I am envious of these students in fact) but just to say note that those who are quite intimate with technology (and there is a small cluster of students in my class who represent such groups) are in fact a slice of the pie. This is an interesting slice and one that I study and one that I find really really interesting and can be used to track some braoder shifts and changes but in a far more limited register. But I think we should be suspect of any move that takes the slice to stand in for the whole pie. This rhetorical embellishment is one that I have come to expect form journalists (for better or for worse) but I am less forgiving of the academics who partake in this problematic form of puffery, in what is a leap over people’s everyday reality and into the realm of imagination, which is better left to fiction.

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

We got a lot of (>= 10) new Debian developers recently. I’m really happy to see that the bottlenecks in the New Maintainer process were (at least partially) solved. My first NM (actually my second, my first one is on hold) also became a DD today. So, how long does it take to become a DD ? Let’s take 2 examples. Both are very active and skilled new contributors, that probably were quite close from being the faster you can be through NM:

Name	Applied	AM assigned	Approved by AM	Account created
Chris Lamb	2008-05-01	2008-06-12	2008-07-22	2008-09-16
Sandro Tosi	2008-03-24	2008-05-06	2008-06-22	2008-09-16

We have the proof: provided you have all the required skills, you can become a DD in less than 6 months! Of course, some things are not perfect yet:

• A lot of very good contributors are waiting for an AM, because not enough DDs volunteer to be AMs.
• Some NMs still take too long to answer questions, using AMs that could probably mentor faster NMs. If your AM is waiting for you, feel guilty now!
• Front Desk and DAM are still managed by a small set of very active (and very busy elsewhere) DDs. Many of the new DDs were FD-approved and DAM-approved by the same person, which is not so great if we want to keep this two-steps check.

Amaya writes about the fact that the political process in many countries is extremely flawed and is failing their citizens [1] (although she doesn’t actually express it in that way). She asks how a revolution can be done right. If we look at the historical record, after the French Revolution came the Reign of Terror [2], after the English Civil War Oliver Cromwell [3] took power - his actions are widely regarded as genocidal, and as for the Chinese and Russian revolutions - it seems that the majority of the population didn’t benefit much (if at all) from them. Generally it seems that the only times that a revolution seems to give a good result is when the situation was really bad before AND when the government failed basic measures such as ensuring food supplies. The independence for the Indian sub-continent which derived from Ghandi’s work can be used as a counter-example. However the ongoing low-level warfare between India and Pakistan is due to a failure of the process. It seems to me that the required first step towards changing a rotten political system with a minimum of bloodshed is to improve communications. If the majority of the citizens know what is really happening in their own country, how their standards of living compare with those in other countries, and what deals are made between their government and the governments of other countries then they can attempt to work out the best way to improve things. The free software community is already doing a good job of facilitating communications. The key areas are to have computers that act on behalf of their users (not using proprietary implementations and Digital Restrictions Management to make them act on behalf of corporations and the state), to support strong encryption with public implementations, to be generally as secure as possible, and to run on the cheapest possible hardware so that everyone gets access.

• [1] http://amayita.livejournal.com/187581.html


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


• [3] http://en.wikipedia.org/wiki/Oliver_Cromwell

Share This

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

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.

Interesting conditions today for the 2008 edition of the Chicago Half Marathon, a race I have now done in 2003, 2004, 2005, 2006, and 2007 which is a personal record in itself. While the weather story of the weekend is obviously the aftermath of hurricane Ike in Texas and neighbouring states were millions of people are still without power, we were also hit in a surprisingly hard way here in northwestern Illinois. According to the Tribune all of Chicago had a rain record day and the Chicago River crested causing evacuations. Not pretty. The new race organisers (who had acquired the race since the 2007 event) were standing steadfast and guaranteeing the race 'come rain or shine'. Participation looked decent -- word was of a record turnout of sixteen thousand runners though I am sure some stayed home given yesterday's rain and the forecast for today. Given all that, it turned out to be not that bad. While we had steady rain the whole, it rarely rained that hard. Shoes and socks did get wet towards the end, but it was tolerable overall. I had been worried about the gross humidity we had yesterday --- but today was much better with temperatures in the sixties and little wind. As for the race, I went out somewhat fast but managed to hang on. The Garmin had every mile split below 7:00 min/mile, and I came in at a new personal record of 1:30:51.52. My GPS, an old Garmin 201, also showed the course long at 13.4 miles; a few other runners I talked to had it as correct or long by a lesser amount. The leaves the pace at 6:56 min/mile (or, for Christian, at 4:19 min/km :-) if the half marathon course length was in fact correct, and at 6:47 min/mile (4:13 min/km) if my Garmin had it right. And from now on it's all tapering for the the next big one in two weeks!

Linpus Lite (or maybe just aspire one mail) is only going to last a few more days on this aspire1, it's beginning to annoy me:
Update
sylpheed has now replaced aspire mail. OK, I still use aspire mail for calendar and addressbook stuff (for now), but sylpheed is a much better email client.

1. aspire one mail has no GnuPG support


2. aspire one mail has no non-HTML composition support. No, really, it doesn't even send plain text alongside the HTML. email sent from the aspire to myself comes in as an attachment in other email clients! (i.e. spam)

So, I would have to investigate a different email client but then there are niggles with Linpus itself:

1. the aspire default kernel build lacks the pl2303 kernel module so that I can't use the aspire to control my balloon3 board over usb serial


2. intermittent problem with network manager forgetting WPA passphrases

Testing continues - probably resulting in installing Lenny at the end of this week. Some of these things might be fixable using pages like taoofmac and Reg Hardware.
Unfortunately, the problem with usbserial means that I'll have to take two laptops if I want to demonstrate the balloon3 board in places.
I also don't seem to be able to locate any copyright files which makes me nervous. Maybe it's just a lack of knowledge of Fedora (at least not since FC5).

Upstream just announced the release of Xfce 4.6 Alpha (codenamed “Pinkie”). I've already prepared some packages, which I won't upload to experimental yet, because the packaging is not yet ready for upload (mainly copyright stuff) and because it's alpha quality, and as we are in testing freeze period, and about (:) to release Lenny, I don't want to mess with that. So, in case you'd like to test them, they are available from my personal repository. As usual, be advised there won't be any official support for those packages. Don't report bugs on Debian BTS, and report software bugs on Xfce bugzilla. Feel free to pass on #debian-xfce on freenode if you need some help, but be prepared to front problems :) Basically there are some new packages:

• xfconf (configuration framework)
• xfce4-settings (xsettings and internal settings daemon)
• libxfce4menu (menu library)

Use apt-get dist-upgrade after updating your apt sources, It'll remove part of Xfce 4.4.2 (and especially xfce-mcs-manager, replaced by xfconf/xfce4-settings) and upgrade another part. Some packages may stay, like libxfce4mcs for example, which is still needed if you use notification-daemon-xfce. This one will be replaced by xfnotifyd at some point in the future (maybe for beta 1). It's advised to do the upgrade from outside of Xfce 4.4.2, just in case. Most settings will be migrated at first run. Look at the new announce for links to know issues, bug reports etc. Happy testing, and remember: don't do that on production boxes.