More and more “stuff” uses my hardware and my internet connection to call home. Often without asking for permission. I am one of those surfing the web with Noscript. I also run a local DNS server and do a few other things to stay safe online. Nevertheless, with every new generation of operating systems and software, integration with the Internet becomes more pervasive. I want to integrate on my terms, for example to exercise parental control.
I am reviewing my computing infrastructure, and the next step is to run every operating system in a sandbox: A VirtualBox guest inside a secured Linux distribution. The host’s firewall should be an inclusive firewall, block everything except traffic that is specifically allowed.
So far I found some material about people using IPcop in one VirtualBox to firewall another VirtualBox, but this seem a big redundancy to me. Why not running IPcop as host system? Of course the host system would have no other purpose other than firewalling the virtual boxes, so even Ubuntu would run inside a VirtualBox. Am I missing something? Research continues, hints and help are welcome.
If you read this blog, chances are that you contribute to Open Source one way or another. This paper is the most detailed study I found on the net about Open Source contributors like us and their motivation.
Just as I was laying out the current status with regards to binary distributions, Allard Katan released a Windows binary installer of 2009.2.0 and uploaded it to the project’s Sourceforge page. I quickly fired up my ailing Windows XP partition to test it.
It is still based on the old 0.7.0 installer that I wrote more than two years ago. My verdict upfront: not official release quality if you ask me. The devil lies in the details.
The most serious issue is Enblend/Enfuse. Because Windows does not have a package manager, the Hugin installer must ship runtime dependencies with the actual Hugin binary. Enblend/Enfuse is a mandated runtime dependency, and a moving target. Compare the images on the right.
The first one are six layers, simulating six images to be blended into a 360°x180° full spherical panorama.
The second one is the blend by Enblend-3.2 as shipped with this installer. The third one is the blend by Enblend’s pre-release 4.0. All using default settings. This installer ships with an outdated version of Enblend.
Unlike Enblend/Enfuse which is a mandated dependency, a control point generator is not mandatory.
Ippei Ukai has introduced an elegant modular plug-in solution for control point detectors for 0.8.0 on OSX, and the Windows version should be updated to a similar mechanism. It’s only a few lines in the installer. But it requires understanding for the process.
There are good reasons not to include control point detectors with Hugin binary distributions: Patents. U.S.-based Linux distributions such as Fedora/Red Hat and Debian steer away from distributing Autopano-SIFT-C because of the patents. And the SURF algorithm, used by Panomatic is restricted by a European patent. I personally would have not uploaded a binary installer with control point detectors to Sourceforge.
Last but not least: the release notes are unclean. They are simply copy & pasted from the source code release notes. To me this is a warning about the quality of the installer. This shortcut may not be critical, but how many other corners have been cut? In my opinion this installer’s quality is closer to an unofficial snapshot than to an official, long term supported release. There are plenty of such snapshots around the net, some of them linked from the download page of this blog. It’s the beauty of the GPL: the code is set free and others can do almost all they want with it.
I do not endorse this installer. But if it makes other users happy, let it be. When I wrote the community charter, I meant it. My opinion on the Windows installer is unimportant. I am anyway not using Hugin on Windows. Even if I disagree with Allard, I gave him full access rights so that he can go ahead and do what he thinks is right with the Windows installer. And I don’t regret it. I wrote the installer when I had an interest to understand the process of building an installer for Windows, and even if I am the original author of the installer, it does not belong to me. I’m happy if you like it as-is. Just don’t complain that it does not match up to the binaries on OSX or on Linux, it is a known bug and limitation.
With the increased pace of development, added features, and improved stability, Hugin has become more visible and has got more attention and love from potential users, and of course they have needs and wishes.
One recurring user request is: “why don’t you make binaries available?”John Riley argues for a “concerted effort to create binaries”, saying that Hugin “deserves a much wider audience than those who are willing and/or able to build it from source” and that “making it more accessible would increase its visibility, which could get more people interested in contributing”.
No doubts that binary distributions would be nice. How do they fit in the plan? What is the status of the project? Of the binaries? What are the priorities?
The Plan
Most contributors to Hugin are volunteers. The rule number one is that there is no master plan. Well, I do have my plan, but I can not impose it on others; and others can’t impose their plan on me. Each contributor decides what is right for him, set his own priorities and contributes what he wants. If the contribution makes sense other contributors will adopt, follow, join, contribute.
I like to think of contributors as a free-flowing fluid on the project, like water on Earth. The fluid is naturally attracted to valleys where it forms rivers and lakes. Its passage shapes the landscape.
Controlling the fluids would need expensive barrages. Most often not a practical proposition. Project administrators only decide what is on Sourceforge and even this is not control: The software is Free. No barrier can prevent the fluids from flowing in an alternate direction and if that direction is more attractive, others will follow. It’s purely meritocratic.
Status
Hugin is undergoing major change. Growth has exposed the limits of the previous structures, and we had to adapt to the new dynamic.
When I first got involved with Hugin three years ago, I found the learning curve extremely steep. We needed to make it more attractive to contributors. In response to the difficulties encountered by the Google Summer of Code students the project reacted with SDK and documentation. Hugin has become more accessible for contributors. We see the result with new contributors coming on board almost every month (and without the incentive of a Google internship). Their contributions pose new challenges.
Last year we integrated four major contributed features: celeste; fast preview; batch processor; and new projections.The integration resulted in a development freeze for much of 2009, until the 0.8.0 release last July.
In the meantime, the queue of new contributed features waiting for integration had doubled:
GPU-stitching (to use modern hardware for faster stitching, integrated in 2009.2.0);
lens calibration (to develop a better mathematical model for the lens geometry, integrated in 2009.4.0 but not ready for practical use);
deghosting for enfuse (to reduce ghosts when merging stacks of images with enfuse, integrated in trunk and scheduled for release after 2009.4.0);
CPclean (to prune bad control points by statistical method, integrated in 2009.4.0);
Auto-crop (to reduce the blank areas around the image);
New layout mode (to improve the handling of exposure stacks);
XYZ-transform (to improve geometric positioning when the images are not taken from precisly the same no-parallax-point);
Masking in GUI (a Google Summer of Code 2008 project that we’re still studying how to integrate).
And there are plenty of small incremental improvements here and there that would not have happened if we were in a freeze.
Extrapolating the past, we’d be frozen until 2011. This would effectively kill the project. I introduced parallel development to solve the bottleneck, and I hope we can work through most of the back log before the end of the winter.
There is a cost to parallel development: desynchronization. And the less glamorous areas of the project suffer particularly. Building binaries for distribution is such an area.
Binaries
The Hugin project is committed to release source code that builds on a wide variety of platforms. The creation and distribution of binaries is left to the users’ communities. Of course we are users ourselves, and we do build binaries, mostly for testing purposes and only on our respective platforms. Our contribution to the distribution process is mostly documentation, because building for self-use and building for distribution are two completely different things, despite a common set of underlying steps.
We stop at the source code for many reasons. Primarily: limited access to all the platforms; limited resources; limited time. Building for distribution requires extra care (quality assurance) and extra steps that are critically important to make the difference between a good distribution and a dysfunctional one. Starting from a fresh source tree is strongly recommended to build a proper distribution. A developer’s source tree is seldom fresh. It contains the traces of the developers work, and this has the potential to contaminate the build process.
One of my activities over the past three months, as I took charge of our release process, was to liaise with downstream distributors to help them produce better distribution in the hope that new versions of Hugin will trickle faster down the distribution channel to the end users. The result:
The Hugin FreeBSD port is now easier to maintain and maintainer Vasil Dimov tracks recent releases closely.
The Hugin Gentoo Linux ebuild is kept up to date by Thomas Pani, Gentoo maintainer.
Coordination with Andreas Metzler and the maintainers team at Debian resulted in the clean up of some outstanding issues and better support of that plattform and its derivates, including Ubuntu. Unfortunately Hugin 2009.2.0 did not make the cut for Ubuntu 9.10, which has Hugin-0.8.0 available through it’s package manager.
Of course this is of little interest for people who do not use FreeBSD, Gentoo, Debian, Ubuntu. And the reality is that the majority of users are still on Windows. Systems without package managers (Windows and OSX) add additional effort / complexity to the build and distribution of binaries. Nevertheless, Harry van der Wolf, supported by some other Mac users, provides unofficial OSX binaries on a regular basis. And for Windows, I have recently guided a few users through parts of the build process. Unfortunately none of the resulting Windows binaries is stable enough to be declared official.
Priorities
Given all the back-log of features to integrate, and the consequent knowledge that the current release of Hugin is short lived and a newer, better one is just around the corner, why put the effort to produce a Windows installer that will be obsolete soon? Of course ideally the installer should track closely the development, but it seems to be too much effort at the moment. At some point, the gap between the installer and the code will be deep enough to attract more attention, and somebody may be motivated to provide a Windows installer.
Yesterday my son and wife got inoculated. I don’t know whether it will be helpful. Statistics show it is the less harmful option.
We were relatively lucky – TV reports showed people waiting in line for five to eight hours to get the shot. Quite a shame for a developed country. We missed it by ten minutes yesterday evening and so we lost half the afternoon today.
I hope the governments are taking notes of how things are going and will improve for next time. A few observations:
Large crowds of people waiting in line outside in the cold. Favorable to disease transmission. The logistics aren’t easy, but could definitely be done better, as is shown by a small region where people can set their appointment for inoculation on the net at https://www.csssmariachapdelaine.com/vaccination.php or via the phone. The “vouchers” introduced in other regions are bogus. In theory they should state the hour at which it is your turn so you can go away for a while. In practice it was required for at least one person in the party to stay in line. Not very practical for the single mothers interviewed on TV.
There are two governments here: federal (Canada) and provincial (Quebec). And they don’t seem to agree on who’s competence this is. So we get double the paper and the marketing. What a waste of public money.
The propaganda in the media was deafening loud. If the government intended to create a sense of urgency, it succeeded very well. It was nearly panic.
Canada bought 100 million doses of the vaccine. It has a very short shelf life. There are 33.5 millions people living on the territory. Current recommendations are one shot for adults and two for infants (we’ll have to go through the process again in three weeks). The math is simple: the Canadian government has ordered more than double what it needed. It would not surprise me if in a few months the stock of expired vaccine will be shippedas “foreign aid” to some developing country.
The issue has been already politicized – Canada has a minority government at the moment and every excuse is good for some fighting. As if the opposition parties would have done better.
Canada has placed the order for the vaccine later than other developed countries. The vaccine is slowly tricking down the distribution channel, so there are logical priorities. Health worker first. Then toddlers and infants to five years, which is where we come in. Parents are allocated one shot with the infant. Some families with two or more kids tricked the system, registering separately each kid so that both parents could get the shot. I don’t blame them. By the time the vaccination campaign will get to the general population the wave of flu may be already through. We only have one toddler. But he’ll have to go twice. I’ll go with him the second time and maybe I’ll have my shot. Or maybe I’ll just sit it out. The statistics show that this one is less lethal than seasonal flu. I still recall ma last flu. Six years ago. Just before coming to Canada.
We just came back from dinner at friends. A good evening. Wife and kid quickly hit the pillow. I could not sleep right away. The wine has been too good (and for somebody who is seldom drinking, maybe a bit too much too). So I went on the computer and checked the emails. There was this interesting feature request. I thought I could use it too. I hacked a patch. Now I’m ready to hit the pillow.
When I found out last month that the Automattic crew was going to be in the area, I knew I had to do it. I wanted to give them something back as a token of gratitude for the beautiful code they set Free (as in Free speech) under the GPL; and the excellent service with outstanding support that they give for free (as in free beer) to lazy people like me who do not bother to run their own WordPress.org install (actually I used to, but WordPress.com is too convenient). So I offered them a Free (as in speech and as in beer) little planet photo shooting. They accepted! They kindly made a little time slot in their busy schedule and off we went.
This was one of the best photo shooting days I had this year. In fact, it was one of the best photo shooting days ever. I enjoyed every single minute of it. A crowd of smart, articulate and interesting people with a varied and interesting international background. Stimulating company. Too little time.
In the same spirit as WordPress, the result of that hour is Free. Pending clearance of the model release forms (which are somewhere in the mail), the images on this post will be released under a Creative Commons Attribution Sharealike (CC-BY-SA) license. Exactly like WordPress, they are Free. You can make what you want with: coffee mugs, T-shirts, screensavers, WordPress themes, wall clocks (requires a modern browser to display). And you can also sell them: CC-BY-SA, like the GPL, is a commerce friendly license. It just restricts downstream distributors with the “copyleft” clause that forbids taking things private.
If you distribute a derivative of these images, you must attribute them to “Yuval Levy http://www.photopla.net/“ and you must release your derivative works under the same conditions, i.e. make them Freely available to the public. Which does not mean you can’t charge for them. It only means that you have to give your sources and allow unlimited copying.
The first image is the one that has been chosen by the Automattic crew. It is also the “official” little planet. Click to enlarge.
The next one is Matt at work, directing his crew to stand for a more traditional group picture. Can you see Matt on the Southern hemisphere? At seven o’clock. In the interactive version you can pan to the point of interest with the mouse and zoom in and out of i twith the SHIFT and CTRL keys.
And the last planet is my favorite. The Automattic crew all lined up for an official group photo. Difficult to keep opened eyes and a relaxed smile against the sun, but that’s the direction of the slope and the crew is growing. I understand it is an Automattic tradition to take a group picture at every meet up and to hang it in the corporate lounge. How will they solve this in the next years, as the company goes the traditional hockey stick slope of successful startups?
Hugin is the solution! There is plenty of space in the picture below, about three times wider than traditional wide angle lenses can capture. It’s a Panini view, extracted from the same equirectangular that was used to produce the above little planet. Have I lost you with all of these technical terms? Check out some Hugin tutorials. Or feel free to ask.
It’s been a while since I installed Canon Digital Photo Professional on Ubuntu / Wine. In the meantime, there have been upgrades to Ubuntu, Wine, and Digital Photo Professional. The good news is that the installed v.3.2 no longer shows the background quirks.
I’ve tried to upgrade to the most recent DPP update (v.3.7.2) as well as the last one supporting Windows 2000 (v.3.4.1) on Ubuntu 9.10 / Wine 1.1.26.You can see the error message above. Given the popularity of my previous post on this topic, I expected it to be known, and I found the bug report in Wine’s bug tracker. Go to the bug report and vote for it to be fixed!
Ever since my youngest age I was fascinated by motion. At least once a year my father would drive for two hours to take us to the Museum of Transport and I would wander around and dream. Dream of cars, trains, planes. And of space and telecommunication. Space was my favorite. So many good memories.
Almost everything alive needs a motor. No motives, no action. No learning without emotions. And projects need a motor to move forward as well.
Most motors known to me have cycles. Whether it is the four strokes cycle of the arguably most common engine out there – or the magnetic inversion of electric motors, most of them are powered by cycles, even seemingly continuous jet engines.
And Open Source projects have a motor too, and it need to be taken care of. There is a striking resemblance to the four strokes of the internal combustion engine: Intake, Compression, Power, Exhaust.
Intake
Powered by the starter or by the end of the previous cycle, a fresh charge of vaporized fuel/air mixture gets into the cylinder. Similarly, drawn by the dynamics of the project, new feature requests and potential improvement gets on the radar screen of the developers.
Compression
The piston rises, compressing the vaporized fuel/air mixture. Similarly, as the features start to develop in the code repository, the pressure rises from the public for a release with the new potential improvements.
Power
At the top of the compression stroke, the spark plug fires, igniting the compressed fuel. As the fuel burns it expands, driving the piston downward. Similarly, the difference between the current repository status and the previous release is so intense that it sparks activity – bug fixes and clean up driving a release.
Exhaust
At the end of the cycle exhausted fuel is pushed out of the cylinder to make space for the next fresh charge of vaporized fuel/air mixture. Similarly, at the end of the cycle the software is released and the project get back in neutral state, ready for the next cycle.
And again…
Being aware of these phases, and knowing where one’s skills can contribute, is paramount to successfully integrate and understand an Open Source community. Developers looking for a challenge enjoy particularly the Intake stage – that’s when dreaming is allowed. Early adopters will feel the pressure of the compression stage earlier, and will contribute bug reports and improvement requests. A spark is needed to transform the mixture into power; and to call bug fixers, translators, builders, writers into action. A project has no power without them. Last but not least, everybody is happy when the pressure is released; when the tarball is uploaded on Sourceforge; when they can relax and tap on each other’s back for a job well done.
Hugin-2009.4 has stalled. I will release the third release candidate soon, but we need some more power to fix at least one serious bug. Some more bug fixing. Maybe I was pushing forward too hard. I also had to meet another, private deadline November 2. It seems to have worked. I hope I’ll have a bit more time for Hugin in the coming weeks.
To install it you will most likely have to build it from source. Major Linux distribution such as Fedora and Debian do not carry binaries of Autopano-SIFT-C because it is tainted by a patent in some jurisdictions.
Hugin does not yet have its own, patent-free control points generator. Some building blocks have been contributed during Google Summer of Code 2007 and 2008, but more work needs to be done.
Ever since my youngest age I was fascinated by motion. At least once a year my father would drive for two hours to take us to the 
