A Look at Mozilla's BrowserID Project

View the original article here

Open Source Project Brings Android Apps to iOS with 'Hello World' Panache

Ever think you'd see Android applications executing natively within iOS? A project called "in-the-box" is working toward this goal, and it's hoping to provide developers an easy path for submitting their software to the App Store. This means Apple users could get a crack at exotic titles from Google's turf, all without jailbreaking their devices. The magic is performed by porting the Dalvik virtual machine and Gingerbread API's to iOS, which developers must bundle inside their applications -- something that's already resulted in a Java-based "Hello world" app (see it in action after the break).

View the original article here

Weekend Project: Setting up DNS Service Discovery

DNS Service Discovery (DNS-SD) is a component of Zeroconf networking, which allows servers and clients on an IP network to exchange their location and access details around the LAN without requiring any central configuration. Most Linux distributions supply the Avahi library for Zeroconf support, but not nearly as many users take advantage of it. Let's look at an easy-to-set-up use for DNS-SD: providing automatic bookmarks to services. All it takes is an Apache module and a Firefox extension.

The essence of DNS-SD is that Zeroconf-supporting applications or hardware devices broadcast a DNS SRV record (of the kind typically used in static DNS to point to a host and port number combo) advertising themselves, and everyone else on the network hears it and takes note. They make the broadcast over multicast-DNS (mDNS), which is a protocol derived from normal DNS, but using special, local-only "multicast" addresses and the reserved .local pseudo-domain.

The system is akin to Universal Plug-and-Play (UPnP), except that it handles more types of services, and builds more directly on top of DNS. The mDNS/DNS-SD pair's major backer is Apple, and UPnP's is Microsoft, so as you might guess, neither is likely to give up and start supporting the other. There is hope for a unifying IETF protocol in the future, but at the moment mDNS/DNS-SD is well-supported enough by the open source Avahi library that Linux users can start working with it today.

In the Apple world, printers and chat clients commonly use mDNS to advertise their availability. But there is a long list of application types that can advertise over the system, including VoIP clients and servers (such as Asterisk), closed-circuit video devices, even collaborative editors (such as Gobby). Essentially, any service that can be described in a SRV record can be advertised; it just needs to provide a service name, a transport protocol (TCP or UDP), and the port and hostname of the server where it can be reached. The mDNS .local domain allows participating devices to assign themselves reachable hostnames.

With the server properly configured, the DNS-SD stack on any client machines will catch and catalog the local services automatically, for use by applications on the system. On a Linux box, Avahi hears and notes the mDNS messages, and an interested client (say, a chat app) asks Avahi if there are any XMPP servers nearby to talk to. The connection is made, and voilà, you start chatting.

It's easy to imagine how DNS-SD could take the pain out of some typically hard-to-configure applications like VoIP, but if you are new to DNS-SD there are simpler places to start, such as with good old-fashioned HTTP web servers. If you're like me, your main Linux box is running a variety of web interfaces for local services: phpMyAdmin, CUPS administration, Webmin or another config tool (in my case, I also have an X10 home automation front-end and the MythWeb MythTV interface running). You may also have work-related services running, such as a Bugzilla instance or network administration workspace, or even a straightforward Intranet site.

The unifying principle is that these are all web services you might like to access from more than one machine on the LAN. You can manually enter the bookmarks on every machine, or use a synchronization tool like Firefox Sync or XMarks, but these strategies make you choose between repetitive work and potential security risks -- not to mention they require updating all of the client machines whenever there is a change. That is precisely the problem Zeroconf networking was designed to solve.

Developer Andrew Tunnell-Jones has written a small but highly useful extension that adds DNS-SD support to Firefox. The code is hosted at Github, but you can install the extension itself, "DNSSD for Firefox," through the addons.mozilla.org site. It requires Firefox 4.0 or later (no word yet on the just-released Firefox 5; it doesn't appear that anything relevant has changed in Firefox itself, but the add-ons system is notoriously pedantic about version numbers), and a working Zeroconf implementation. For Linux, Avahi works just fine, and Mac OS X users will already have Apple's Bonjour installed. Windows users can install the Apple-provided Bonjour-for-Windows package, which Tunnell-Jones links to from the extension page.

After you restart Firefox, the extension adds a menu labeled DNSSD to the Navigation toolbar (between the forward/back buttons and the URL bar) and to the Bookmarks menu. Click on it, and you will see a list of all of the local HTTP servers detected by your Avahi or Bonjour service: no configuration necessary. If you want to double-check the extension's list, you can run avahi-browse --all from the command line.

If you are running GNOME, you should also see a desktop notification pop up whenever the extension notices a new service (although for most services, this will just be at start-up time). That option is configurable in the preferences, which you can get to through the Add-ons Manager.

It works, and it is automatic, but there are a few quirks to be aware of. First, you don't (yet) have the option to choose where the DNSSD menu is displayed. Placing it in the navigation toolbar makes sense because that is the one toolbar almost guaranteed to be present, but putting it in the Bookmarks toolbar would seem to make more sense to me -- it seems like a natural complement to Firefox's automatic "Most Visited" and "Recently Added" bookmark folders. Second, although you can access the DNSSD menu through the Bookmarks menu, you cannot move it around in your bookmarks to a more convenient location. I asked Tunnell-Jones about both of these options, however, and it sounds like they are possibilities for future releases.

You can probably think of a handful of local web services you would like to automatically advertise around your office or home network, but the odds are that most of them do not advertise over mDNS out-of-the-box. In my case, the only running server that did provide a web interface over DNS-SD was the MT-DAAP audio server. To get your other services to announce themselves, you'll need mod_dnssd.

Mod_dnssd is an Apache module that adds simple mDNS/DNS-SD support to your Apache-hosted sites, with a minimum of configuration fuss. The latest release is 0.6, which supports Apache 2.2, although there are older releases for those still running Apache 2.0 for some reason.

The author, Lennart Poettering, is best know as the maintainer of PulseAudio (which, yes, uses mDNS/DNS-SD to locate other networked PulseAudio sources on the LAN). The docs on the site are a nice introduction, but Poettering has written a more extensive how-to on his blog. To get it working, you'll need to install the module (packages are available on the site, but most distributions offer it as well), and make sure that Apache loads it at startup (check your distro's documentation for details, or edit your /etc/apache2/apache2.conf if installing from source).

To use the module, you must first activate it by placing the DNSSDEnable on directive in the Global Environment section of apache2.conf. With that configuration alone, Apache will advertise all of the VirtualHosts over mDNS/DNS-SD -- however, clients will have trouble connecting to them if you do not label your VirtualHosts with fully-qualified domain names.

For a little more fine-grained control, you can add a DNSSDServiceName "Whatever You Want To Advertise It As" directive to each VirtualHost or Location block. The ServiceName you assign will be the user-visible label seen in the DNSSD menu offered by the Firefox extension, so you can give easy-to-remember, LAN-wide labels to your bug tracker, Apt-CacherNG control panel, or any other site. But remember to include the server's name if you are running multiple web servers on the LAN, lest your users get confused.

By default, mod_dnssd advertises Apache resources as HTTP services (i.e., using the _http._tcp SRV record). That makes sense for most web services, but you can also alter it to properly advertise other applications, such as WebDAV or RSS feeds. Simply add the DNSSDServiceTypes directive to your Apache configuration, followed by a space-separated list of the service types you wish to advertise -- either for the server as a whole, the VirtualHost, or the Location, depending on where you put the directive.

Obviously, the Apache plus Firefox combination only scratches the surface of what DNS-SD as a whole is capable of, but as an increasing number of services use HTTP, it is at least a useful place to start. You can save yourself some trouble by DNS-SD-enabling your Intranet sites and letting your users find them automatically. Of course, you do still need to take precautions to protect your services. The DNS-SD services will only be visible to LAN clients, but if you do not want that to include WiFi visitors, you should partition them off into a different subnet altogether -- and it goes without saying that your admin panels ought to be password-protected.

But there is another subtle condition imposed by this scheme: it requires changing Firefox, the client application. So although it's easy to imagine DNS-SD-advertised bookmarks being useful in a public environment (say, an Internet cafe), you still cannot expect visitors wandering in off the street to have the right extension installed. In my mind, DNS-SD, like Microformats, is a technology that Firefox really ought to support off-the-shelf. There is no reason not to, unless you make the security argument -- but honestly, a service at risk is not any better-protected just because it is un-advertised. Maybe Tunnell-Jones's extension will have a hand in raising awareness of the convenience offered by DNS-SD. At the very least, you can leverage that convenience yourself, and that's a pretty good start.

View the original article here

Weekend Project: Use Rapid Photo Downloader for Photo Management

Often the most impressive thing about the open source community is getting to watch someone step up to work on a task that's far from fun or glamorous in the traditional sense. A good example of that phenomenon is Damon Lynch's Rapid Photo Downloader (RPD), a utility that takes the pain out of what many projects overlook: getting your newly shot material off of the camera's memory card and into your computer. Despite the name, RPD handles both photos and video, and although its speed is impressive, how it really makes your life easier is by keeping you and your storage organized.

The root "problem" that RPD sets out to solve is what happens when you plug your digital camera or camera memory card into your Linux computer. The default behavior is for a desktop tool to pop up, usually a GNOME or KDE front-end to gPhoto2, the standard image-transfer library. The tool knows where in the flash memory hierarchy to find the actual image files (including the separate storage schemes for raw and JPEG images), and it copies them to the hard disk and optionally erases them from the card.

That sounds simple enough, but more often than not, Linux distributions don't use a file-manager tool to handle the task. Instead they hand it off to a full-featured photo management app, which takes considerably more time to step through the process, often filing images in its own internal database, making thumbnails, and other bookkeeping jobs. While that might be a tolerable overhead for a 1 or 2GB card, when you hit 16 or 32GB, it becomes agonizingly slow. If you're on notebook battery, it is even worse.

Compounding the problem, no two photo-management apps can agree on where to store things: ~/Photos, ~/Pictures, ~/MyPhotos, etc. Even if you're a good Linux citizen, every few releases the distros change their default app set, and you eventually find your photos scattered around a half-dozen locations. That makes images hard to find, easy to lose, and easy to forget when you're migrating computers or making backups.

You can download RPD from the project's Web site. The team has detailed instructions provided for Ubuntu, Fedora, Debian, Mandriva, and several other distributions. In most cases, there is either a prepackaged version of RPD available from the distro, or a simple-to-add repository. The latest release is version 0.4.1, a minor update from May of this year.

After you've installed RPD, you can launch it from the Applications menu or from a terminal with rapid-photo-downloader &. RPD is built on GTK+ and some GNOME underpinnings, but it runs just as well in KDE and other environments, since the only key dependency is Python. How you get RPD to actually launch automatically when you attach a camera or pop in a memory card varies, though. In GNOME, go to the "Removable Drives and Media" option in Preferences, and enter rapid-photo-downloader as the command to import photos when a device is connected. In KDE, the setting is found in "System Settings" -> "Device Options."

With RPD, you are in control of all of the options. The preferences dialog lets you choose any folders on your system as target directories (including separate settings for photos and videos), and optionally allows you to auto-create sub-folders to further structure your archives. RPD can offload media from multiple devices at once, so you can get the maximum performance our of your system by, for example, connecting your camera via USB cable while popping another memory card into the card reader slot.

In its simplest form, the sub-folder feature lets you split up your collection in sub-folders by year and month, which makes backing up to non-volatile media considerably simpler. But you can also configure sub-folders to split up images by their filetype (e.g., keeping raw and JPEGs separate), by automatically-gathered metadata (such as camera model), or by "job codes" that you define yourself ("work" and "personal" come immediately to mind).

A related feature is RPD's auto-file-renamer. If you have a naming scheme in mind, RPD lets you set up a renaming formula in "set it and forget it" mode, using the same options available as sub-folder choices. A big benefit to this technique is keeping more than one image source straight. Not every camera allows you to control the file name and file-numbering settings it applies to new material, and these days almost everyone has one "real" camera plus a cameraphone. RPD can massage the less-flexible filenames into the same format as the rest.

The RPD project makes a big deal out of its speed. On top of the name itself, the home page boasts of a 2.5x speedup over F-Spot and a 12.5x speedup over Shotwell. I don't think those numbers are scientific, but RPD is certainly faster. Even more so when you factor in offloading from two cards at once and the instantaneous file-rename feature, which saves an entire step.

Speaking of saving steps, in my mind one of RPD's signature features is the ability to automatically save backup copies of your media. As a member of the non-elite club of those who have had a laptop drive fail while on the road, I always carry a 2.5" external drive with me to save a second copy of any files I shoot (the first being on my laptop). RPD will write backup copies of each file to a directory you specify, and can even do so at the same time it saves the main copy. This assumes your bus bandwidth can keep up; if you are also doing multi-device offloading, you would probably be better off serializing some of your tasks...

As with the main file operations, you can specify separate settings for photos and videos, and RPD will automatically detect all removable storage media, so you can save backups in more than one place if you desire. RPD also allows you to configure some automated behavior, such as starting the offload (and backup) process as soon as the program launches, unmounting removable devices when offloads are completed, and so forth. A handy feature you are likely to only appreciate on rare occasions is how RPD handles name collisions — such as when two auto-renamed files somehow would end up with the same filename. Finally, RPD can automatically sanitize filenames and folder names to ensure compatibility with lesser, non-free operating systems.

For 90% of RPD's users, the basic offload and backup features are more than enough — well, assuming that they use backups, but then again, that is part of the point. RPD builds that easy-to-procrastinate task into the plug-and-play, normal operation. High-end users are more likely to appreciate the flexibility of subtle things like automatic file renaming and directory creation. After all, if you only take a few pictures or videos a year, opening up your Photos folder in Nautilus or Dolphin and browsing by thumbnails might be all the asset management you need. It's with hundreds that that method breaks down.

I'm a big proponent of the "let each tool focus on its own thing" approach. As such, I don't like it when a photo editor decides it knows better than I do where I want my images stored or how I want them organized. Ubuntu frequently changes which iPhoto clone is the preferred photo-management app, and honestly I don't find any of them to be particularly good, or particularly good at guessing what I want. It works far better to have a dedicated image offloader like RPD launch when I plug in a memory card. Thus, regardless of whether I choose to fire up Digikam, GIMP, Rawstudio, or a Flickr exporter, I know that my collection is in the same place. Oh, and I know that there's a backup copy on a removable drive, too — even if I forgot about it when I sat down at the keyboard.

View the original article here

Can Project Harmony Streamline Rules for Open Source Contributions?

According to the Project Harmony page: "Project Harmony is a community-centered group focused on contributor agreements for free and open source software (FOSS). As a group, we represent a diverse collection of perspectives, experiences, communities, projects, non-profit and for-profit entities. In that diversity, we share a common belief in the future of FOSS, and a common interest in using our skills (whether they're legal, organizational, editorial, technical, or otherwise) to the benefit of collaborative FOSS communities." The...

OStatic's open source theme of the day today is whether open source contributions are tracking with increases in open source usage, especially by businesses and organizations. In this post, we discussed how many organizations that now use open source aren't giving back at all. On this topic, one of the more interesting projects currently running isn't an open source software development project, but rather a coordinated effort to establish rules and guidelines for making contributions to open source. It's called Project Harmony, is heavily backed by Canonical, and on June 23 its first year of notable effort to establish rules for open source contributions will arrive.

According to the Project Harmony page:

"Project Harmony is a community-centered group focused on contributor agreements for free and open source software (FOSS). As a group, we represent a diverse collection of perspectives, experiences, communities, projects, non-profit and for-profit entities. In that diversity, we share a common belief in the future of FOSS, and a common interest in using our skills (whether they're legal, organizational, editorial, technical, or otherwise) to the benefit of collaborative FOSS communities."

View the original article here

Transforming GNOME Into A Linux-Only Project?

One of the mailing list messages making the rounds on the Internet today is concerning the GNOME project and whether they should no longer concern themselves with supporting non-Linux operating systems...

View the original article here

Weekend Project: Manage Bugs with Mantis

All kinds of organizations need bug trackers. Whether it's software developers, Web site developers, or just organizations with significant IT needs, bugs must be tracked. (And, you know, fixed.) To that end, there are plenty of bug tracking tools available, but none that are open source and as easy to install and manage as Mantis Bug Tracker. This weekend, get started tracking bugs with Mantis!

Since the installation of Mantis is such an easy (and well documented) task, I want to focus on the management and flow of the work done within the tool. This means managing projects as well as reporting and managing the flow of reported bugs. The only assumption made will be that Mantis is already up and running.

Before bugs can be reported, there must be a project to report bugs on. In order to manage projects log into Mantis as the administrative user and then click on the Manage link. From this new page (see Figure 1), click on the Manage Projects link.Obviously, all Mantis management is tackled from this page, so make sure whoever has the key to this kingdom knows what they are doing — or should, anyway.

From within the Manage Projects page all that is necessary is to click the Create New Project button. From within the new page, the following information is necessary:

Project Name: Human Readable name for project. This is the only field that is required.Status: Choose from development, release, stable, obsolete.View Status: Choose from public or private.Inherit Global Categories: On or off.Upload File Path: Path for file upload. This path must be readable and writable by the web server and does not (nor should) need to be within the document root or the Mantis directory.Description: Human readable description of project.

Below the Description there are other fields that can be filled out. Per-project categories can be created on this page. Per-project categories are very important and useful to make the flow of bugs easier to follow. Getting as granular as possible in the categorization will not only make it easier for developers and admins to follow the flow of information, it will also make it much easier for reporters to report bugs (and be more specific when doing so.) Use this only if there will be categories that are only related to this particular project. The main categories are global and can be used by all projects.

There is one small hiccup with creating the categories at this point. When a category is created, it's always smart to assign that category to a user. But if no users have been created, this isn't possible. To really make the most out of the system, each category should be assigned a lead so all notifications can be funneled to the proper person. So, instead of creating Categories next, migrate over to users and create the users that will serve as the heads of the various categories. Don't worry, the project can be modified later, after users have been created. Naturally, this won't be necessary on a Mantis installation that already contains the necessary users.

The managing of users is a fairly straight-forward task, but it's one that's quite important. When users are created they are assigned an access level which dictates their effective permissions within Mantis. So, it should go without saying, to pay close attention to the access level of a new user. To create said new user click on (from the Mantis home page) Manage > Manage Users. From the Manage Users page, click the Create New Account button and fill out the necessary information:

Username: The username the user will log in with.Real Name: The human readable name of the user.E-mail: E-mail address for the user.Access Level: Choose from viewer, reporter, updater, developer, manager, or administrator.Enabled: Check to enable to user. Uncheck to temporarily disable the user.Protected: When an account is protected its attributes can not be changed.

With the users created, now it's possible to assign categories to those users to further refine how Mantis is used.

Go back to the Manage Projects page. From this page it is possible to create Global Categories. As mentioned earlier, Global Categories are available to all projects, so do not create categories here that relate to a specific project. To create a category simply type the category name in the field to the left of the Add Category button and click Add Category. This will add the category, but will not assign the category to a user. In order to assign a category to a user click the Edit button associated with the category, which will open that category up for editing (see Figure 2).

 

At this point the category name can also be changed.

To assign the category to a user, just select the user from the drop-down and then click Update Category. With the project, categories, and users created it is now possible for users to report bugs against the project.

As crucial as categories are to the ability for reports and manages to work the flow of information, email alerts are, without a doubt, the single most important feature of Mantis for quick response to issues. These alerts make those who need to know aware when bugs are reported and/or have status changes. This feature, of course, requires a working SMTP server configured in the config_inc.php configuration file. With that in place, do the following:

Go to the Mantis main page.Click on the Manage link.Click on the Manage Configuration link.Click on the E-mail Notifications link.Configure Access Levels for each user type (See Figure 3.)Click Update Configuration.

Settings highlighted in green override all others. Settings in blue are project-specific.

The flow of bug tracking can range from the fairly simple to the very complex. This will be dictated on how detailed bugs become, how frequent bugs are reported, and how granularly those bugs are managed. Regardless of how complex your bug reporting can get, this is how Mantis manages the flow of bugs:

User logs onto Mantis site.User reports issue for a particular project, making sure to select either a Global or Project-specific category.Notification is sent to Project Manager (or whoever is configured to receive notifications.)Manager (or administrator) of project confirms bug and assigns bug to developer.Developer resolves bug and sets bug status to resolved.Manager (or administrator) can then close bug when resolution is confirmed.

As is shown in Figure 4, it is very easy to access quite a large amount of information about a bug. Each blue link is clickable and will reveal different aspects about an individual but, a category, a user, a project, and more.

 

In this example there are two projects with a bug attached, Mobuntu and WidgetOne.

A user with the correct permissions could click on any of the listed bugs and view, edit, promote, demote, assign, and much more. Bugs can even have their status changed in batches by checking off all the bugs to be changed and then selecting the new status from the drop-down (below the bug listing window). Once the new status is selected, click the OK button to update. Depending the change, a new window may be opened for user interaction (such as with an assigning of bugs.)

Different companies will use Mantis differently. Some will be able to function with just the very basics, whereas others will depend upon a highly detailed usage. Regardless of how it is used, it is important to know that Mantis Bug Tracker offers numerous ways to manage the flow of bugs in and out of the system.

View the original article here

Weekend Project: Pre-Loading Maps for Open Source Navigation Apps

Map-based navigation: it's one of the killer apps for any mobile platform. The only sticking point is getting the maps. Downloading map tiles on the fly is the default solution for most navigation apps, but pre-loading makes more sense when it's possible. Unfortunately, open source navigation apps have earned a reputation for clunky and awkward map-loading interfaces. This weekend, let's look at a simpler method, so you can get on the road quicker.

Sure, whenever you have solid data coverage and a cheap-but-fast mobile plan, you can stream maps on-demand — but even then your download speed can to a crawl at just the wrong moment. Plus, you can forget about streaming maps if you're traveling to the back woods or headed overseas with a pre-paid SIM. Pre-loading map sets bypasses the entire problem, plus for many apps it allows you to calculate routes while offline as well.

The problem is that the open source apps make pre-loading into a colossal pain. Some provide a pre-loading interface that falls flat — such as by requiring you to manually enter unformatted latitude and longitude coordinates for the corner points, by not allowing you to see which maps it already has stored, or by attempting to download every zoom level in the database. Others simply have no pre-loading interface at all, requiring manual configuration file editing to point the app towards the right storage directory.

If you had unlimited disk space, you could always grab the entire OpenStreetMap global data set, but for all practical purposes the way most people will operate is to keep a small set of maps on their device at any one time — home, the destination city for a particular trip, and so forth.

Complicating matters slightly is the fact that different navigation apps utilize different map sources. If you're hiking cross-country, you probably want a topographic map, so OSM's street map source isn't going to be any good, regardless of how easy it is to partition off the relevant boundary lines and download tiles. If you use more than one app then typically you double the amount of work involved, since most navigation apps have their own package format and directory structure — even when dealing with the same map source.

We can simplify the process by using the Java application Mobile Atlas Creator (or MOBAC for short). MOBAC includes a web map renderer on which you can select the region of which you're interested in generating an offline map source, plus controls that let you configure zoom level and other options. Whenever you have your "atlas" (which is MOBAC's term for each individual offline map bundle) configured, you can have MOBAC batch-download the tiles and properly configure them for the navigation device of your choice.

You can download MOBAC from the project's site on SourceForge.net. For most users, all you will need to do is grab the .jar package linked to under "Download" on the home page. It requires Java 1.6 or newer, which is standard fare for Linux. The developer recommends you also download the latest build of Java Advanced Imaging from Sun (or presumably, Oracle), although this is optional. A subset of mapping applications also require the Sqlite database; the Download section links to the appropriate Java library.

The current release of MOBAC is version 1.9 beta 5, which officially supports 28 different navigation and mapping apps. There are others that use a compatible format, but don't make the main list. Most are turn-by-turn mobile navigation aids like AndNav, OsmAnd, and Osmdroid, but off-road utilities like Mobile Trail Exporer, specialty apps like Nokia Sports Tracker, and GPS-logging apps are supported as well — including those for dedicated GPS hardware like Magellan and Garmin units.

After you've downloaded the requisite files, cd into the resulting directory and launch MOBAC with ./start.sh &. The left-hand window pane holds a series of expandable settings docks; click on the arrow in each dock's title bar to see its content. The right-hand pane is for GPX data, which is a different enough use case that we don't have time to discuss it. In the center is the map view widget.

The atlas-building process is a bit quirky, but you will soon get the hang of it. The "Map source" selection dock on the left lets you choose which map is displayed in the map view. "Atlas Content" further down displays the map components you have selected so far. By default, MOBAC starts a new atlas project named "Unnamed atlas" at startup. You can work on more than one at a time — use the "New" button to create one. Just keep an eye on which atlas project is selected as you work: every time you make a selection on the map view, you can click the "Add selection" button to add it to the currently chosen atlas project.

In the map view widget, the right mouse button acts as a "grab" controller, with which you can pan and scroll the map view. The left mouse button allows you to draw a selection rectangle onto the map. The scroll wheel zooms in and out. When you have selected the region you want to save, go to the "Zoom Levels" dock and check which levels you want to download. There is some trial-and-error involved, but if you're new you can learn a lot by visiting OSM's web renderer and watching the zoom level there. You probably don't need more than two or three levels; it simply depends on the detail level you want.

What makes MOBAC exceptionally useful, however, is that you don't have to stop at one selection rectangle or one map source. You can add multiple cities (at a high zoom level) and a large swatch of highway (at a lower zoom level) all to one atlas. You can also grab OSM street data and OSM public transport or hiking maps, and merge them all into a single atlas.

When you have all of your selections made, choose "Convert atlas format" from the "Atlas" menu. This dialog lets you select the output format of your maps. The README file (which is also accessible through the Help menu) describes which format is required for each of the supported apps. For other apps, you need to look online for documentation (Mappero, for example, uses the "OSMTracker tile storage" format, which seems to be popular among the open source apps, although AndNav has its own). If you installed the Java Advanced Imaging package mentioned earlier, you can select some custom tile processing options (such as reducing the color data to save space), but it's not required. When you're ready, click "Create atlas" and MOBAC will download all of the tiles in your atlas selections, convert them, and package them for use on your device.

At this point, all that remains is to copy your freshly-minted atlas to your mobile device. Here the process varies from app to app. Start by clicking the "Open Atlas Folder" button in MOBAC's "success" dialog. Each atlas project you've built will be saved in one location, so you can maintain a local library. Whether you can simply drag-and-drop an atlas folder from your hard disk to a USB-attached device, or whether you need to navigate inside it and drag the sub-folders independently depends on the app. Start by consulting the README file; if you don't find instructions there, go to the MOBAC wiki, which maintains pages on the subject — often linked to real-world how-to guides.

You may have noticed that there is a long list of map sources rambling down the sidebar of the MOBAC homepage, but that I have only discussed using OSM-based data sets. That is because Robert, MOBAC's lead developer, recently made a change to the application that disabled most of the commercial and proprietary map sources. As he explains on the forum, he did not do this because the map data was licensed in a manner incompatible with MOBAC's GPLv2 , but because the terms of use for a handful of the more litigious map providers explicitly forbid so-called "bulk" downloads through their APIs.

Whether your personal usage of MOBAC constitutes a "bulk" request depends on how much you select, but Robert did not feel like working it all out individually. Instead, he disabled the problematic services, and now says he will re-enable any of them for which a clearly-expressed deal can be reached. He is asking MOBAC users to contact map service providers rather than doing the deal-making himself.

I have grave doubts as to whether that third-party negotiation technique will work, but in the meantime I don't mind: OSM works everywhere I have traveled, and it is explicitly free. You can read more about the map source setup process in the same thread, including how to add map sources that are free but don't offer any TOS at all (or simply don't respond to inquiries). It's important to notice, however, that a web map source has to meet some technical requirements in order to function. The MOBAC site has a list of map sources that are incompatible, and a tool to help you determine if a new source meets the requirements.

It only takes a few seconds for MOBAC to download and convert hefty map collections if you have a reasonably fast Internet connection. Doing so once might be a slight convenience when compared to making a single custom map set, but what makes MOBAC worth keeping around is how it simplifies the process on a repeating basis.

As mentioned above, you can save your old atlases for later re-use; MOBAC can also be configured to freshen already-downloaded tiles so that updates to the map are added to your existing atlas. It also allows you to bookmark map views, so that you can quickly re-visit settings; this is especially useful as you are getting used to what your preferred zoom levels are for different types of transport. In addition, MOBAC excels because of its support for multiple map layers. How uninteresting would it be if you had to choose between street maps or public transport, but not both?

Open source navigation apps have come a long way in a short period of time, particularly on Android, but they all still have room to improve in the area of offline map support. It is an understandable afterthought if you are the developer, where offline and online maps are such very different features. Which is why it's such a good thing MOBAC is available to bridge the gap.

View the original article here

Debian Project at LinuxTag 2011

The Debian Project is happy to announce that it will be again represented at the LinuxTag event in Berlin, Germany, this year. At the booth members of the project will be available for questions and discussions.

View the original article here

Weekend Project: Extend GIMP with High-End Plugins

Most Linux users are familiar with the GIMP raster graphics editor, a versatile tool for photo and graphics work. What is often overlooked is that a significant chunk of GIMP's power comes not from its built-in functions, but from its extensibility. GIMP supports enhanced features through compiled plug-ins and scripts, for everything from automating difficult tasks to introducing whole new functionality. A basic set of plug-ins is supplied with your distro's version of GIMP, but if you're just sticking with that, you're missing out on many of the high-end features. This weekend, let's take a look at GIMP's plug-in power, through the lens of one of its most advanced add-ons, Resynthesizer.

To find out what your plug-in situation currently is, fire up GIMP and then go to the Help -> Plug-in Browser menu item. You will probably want to expand the window size for readability; for some reason only the first column is visible in the left-side pane, but there is much more. This browser lists all of the installed plug-ins, and for each one allows you to see where in the program's menu structure the added function appears, when it was last updated, what image types it operates on, and any additional information provided by the plug-in author — such as a URL.

The example plug-in we'll be looking at in this project is called Resynthesizer, and it is one you will definitely want to install. Resynthesizer performs "texture synthesis," which means healing and selection-fill-in functions in a picture based on the surrounding image itself. It is essentially the same features provided by Photoshop's "healing brush" and "content aware fill," but Resynthesizer was doing it half a decade ahead of Photoshop. The original author Paul Harrison developed the plug-in for his PhD research, but new maintainer Lloyd Konneker took over in 2010 and is producing binaries and packages for up-to-date GIMP releases.

The officially-sanctioned home for GIMP plug-ins and scripts is the GIMP Plugin Registry. It offers a variety of ways to access extensions, from browsing by popularity or update date, to sifting by category, to subscribing to the registry update RSS feed.

If you are completely new, try taking a look at the popularity-sorted page to get a feel for what other users find helpful. There you'll see support for extra image formats, layer effects, color separation, and entirely new functionality like wavelet-based denoising, adaptive edge-detection, liquid rescaling, and the ability to run native Photoshop plugins.

Despite its official status, not every plugin author makes regular use of the registry, so if you see a plugin that looks interesting but has a long-past "last update" date, be sure to read the comments and to click through to the plug-in's home page. Most are actively maintained, and the comments from other readers will often be a current source of information on the status.

You don't actually have to find plug-ins through the registry at all, of course. Many design blogs feature "five great GIMP plug-in"-style posts on a regular basis, often with an eye towards a particular use-case (design, photo editing, etc.). Start with the lists from MakeTechEasier and LightStalking to get a feel for the option.

Go ahead and close GIMP if you still have it open from the previous step. From a terminal window, type cd ~/.gimp-2.6/ and hit Enter to move to your GIMP configuration directory. An ls shows you the contents, which include directories for saving brushes, curves, gradients and other resources. The directories of interest to the plug-in shopper are plug-ins and scripts.

What's the difference between the two? For historical reasons, scripts (which you might think of as similar to "user macros" in other applications) go in their own directory, are written in a Scheme-like language and use the .scm file extension. Plug-ins can be compiled executables or Python code, and generally implement features that cannot be accomplished via scripting GIMP's existing internals.

On the Resynthesizer registry page, you can download a .tar.gz archive containing everything you will need to install on a 32-bit Linux system. You can also browse the source at Github, where you'll find a basic README. The archive contains two executables, resynthesizer and resynthesizer-gui, and eight Python scripts (one each for each new menu function provided). Extract them all to ~/.gimp-2.6/plug-ins/ and then type ls -l at the command line. That will show you the file permissions.

The newly extracted package will not have the executable "x bit" listed in the fourth column, so type chmod +x * to set it. In the future, other plugins you install may or may not require this step, depending on whether you install them through your distro package manager, download them manually, or perhaps compile them locally.

Resynthesizer uses binary and Python plug-ins only, but another package could include both plug-ins and scripts. If you are installing a script, though, the process is exactly the same except for the target directory: extract the script to ~/.gimp-2.6/scripts/ and use chmod to set the executable bit.

Now, when you re-open GIMP, the program will scan the plug-ins directory, pick up the new additions, and integrate their new menu entries directly into the interface. There is no separate "plug-in area" of the menus; that is part of why the Plug-in Browser we opened earlier is important. If you can't figure out whether or not a plug-in is being picked up by GIMP, you can search for it or try and locate it by name, but the listed names correspond to the new functions implemented, not the name of the package as a whole.

In Resynthesizer's case, you gain eight functions: "Enlarge & sharpen," "Sharpen by synthesis," "Heal selection," "Heal transparency," and "Uncrop" in the Filter -> Enhance menu, "Texture" in the Filter -> Render menu, "Fill with pattern seamless" in the Edit menu, and "Style" in the Filter -> Map menu.

If you've been using GIMP for a long time, you may have to worry about plug-ins and scripts from previous major releases. Note that the directory we've been using thus far is ~/.gimp-2.6/. Resources and extensions from the GIMP 2.4 series (if you still have any) are located in ~/.gimp-2.4/. However, it is a very bad idea to simply copy-and-paste objects between these two directories. Changes in the API might make them malfunction in ways that you can't predict, although this is primarily of concern to compiled binary plug-ins. Most plug-in authors keep up to date on GIMP's long release cycle — visit the registry or plug-in URL and see if there is a new version available.

So what about Resynthesizer itself? No, it's not a resurgence of 80's New Wave pop. Thankfully. Instead, the eight new functions it provides implement texture synthesis in very specific uses. The canonical example is cropping a distracting item out of a photograph: you can manually remove the object and paint over it using the clone tool, sampling from the surrounding area. Resynthesizer does this automatically, without risk of smudging up the result through choosing awkward sampling points.

This function is implemented in the "Heal selection" option. Make a selection, then choose is from the Filter -> Enhance menu. The new version of the plug-in lets you choose the size of the sampling area, whether to sample on all sides or just vertically/horizontally, and whether to fill in randomly, work from the inside-out, or the outside-in. What gives you the best result depends on the image.

Heal transparency does essentially the same thing, but for transparent regions of an image. The mysteriously-named Uncrop takes the process to a new level, adding a transparent border to the image, then automatically filling it in with texture generated from the neighboring region, including correctly preserving horizon lines and other features. Sharpen by synthesis and Enlarge & sharpen both work to reconstruct detail in a blurry image by synthesizing pixels. It's not as good as tech teams produce on TV, but it can save an otherwise scruffy-looking photo.

The Render Texture and "Fill with pattern seamless" options are different entirely. They deal with the Resynthesizer engine's ability to detect edges and seamlessly connect to them as it generates pixels. Render Texture uses the current image as a source and generates a reusable, randomized texture preserving visible features (optionally making it tile-able at the same time), while the Fill option takes an external image as a "source" and generates a random-but-natural-looking texture from it to fill in part of the image. The first might be of interest to those who generate textures for 3-D modeling or video game graphics, while the second is a genuine photo-editing tool (provided you don't pick an easily-recognizable source texture).

The last new function is original. Filter -> Map -> Style transfers the "color and texture" of one image into another, through sampling and texture synthesis. The result is that you can take a source image (such as a photograph) and map the "style" of a target image (such as a watercolor painting) onto it. The result ought to be a watercolor-like rendering of the photo.

To be honest, I haven't played around too much with the new functions. I'm happy enough to have the healing functionality of Resynthesizer return to GIMP after such a long absence.

When you've worked with Mozilla Firefox and Thunderbird for a while, the process for managing GIMP plugins seems quaint by default. Here's hoping a future version of the editor will automate more of the installation process, or perhaps even tie the registry directly into GIMP's Plug-in Browser so you don't have to switch to a web browser. But don't get too down on the GIMP's process — it'd be nicer if it was fully automatic, but it's fairly simple already. Most people just haven't tried it. In fact, you've probably got enough of your weekend left that you can check out some additional plug-ins, too. Here's a hint: if you like Resynthesizer, try G'MIC for extra credit.

Comments (1)
You must be logged in to post a comment. Please register if you do not have an account yet.

View the original article here

Weekend Project: Crash Course in Audio Recording With Ardour DAW

When you're ready to move up from simple audio recording applications like GNOME's Sound Recorder, take a look at the excellent Ardour digital audio workstation. Ardour is one of the shining jewels of FOSS, a robust professional-level multi-channel recorder, editor, and mixer. Follow along as we learn the basics by making a simple recording. You will need a computer with a sound card, even a cheapo on-board chip, and a microphone or instrument to plug in to your sound card.

JACK, the Jack Audio Connection Kit, is required to run Ardour. If you're going to use Linux for serious audio production then you must become well-acquainted with JACK. (In an amazing coincidence, my "Book of Audacity" has a chapter on using JACK.) JACK is a real-time low-latency audio router. With JACK you can fine-tune latency and throughput, connect software audio applications, and connect audio hardware in all different ways. A simple example is recording a single instrument, say a guitar, and using the wonderful Hydrogen software drumkit for a backing track. With JACK you can have Hydrogen playing and recording at the same time you play your guitar, and have individual control over routing all inputs, outputs, and monitoring channels.

When you install Ardour JACK should be a dependency. If it isn't with your distro, then install it separately. Fedora with the CCRMA packages is a great audio platform, and so is Ubuntu. I'm using Ubuntu Studio 10.04 LTS because everything works and I plan to keep it that way.

I am not a fan of Pulseaudio for audio production because it gets in my way. I rely on JACK and ALSA. ALSA provides sound card drivers and a basic mixer, and JACK does the routing. Pulseaudio is also an audio router, so it's redundant with JACK. JACK and Pulseaudio often clash, depending on your distro and how old it is. How use PulseAudio and JACK? will help you sort it out. Pulseaudio and Jackd has some good tips.

There are two ways to start Ardour. You can start JACK first and tweak the settings, or start Ardour and let it start JACK for you. Let's fire up Ardour without starting JACK first and see what happens:

What the heck do you do with that? Not much, really! First fill in the Name field; this is your project name, something clever and descriptive like "test". The Open Session tab is for opening existing projects. Don't change anything on the Audio Setup tab, with one exception: if you have more than one audio interface, for example an internal sound card and a USB audio interface, then pick the one you want to use from the Interface selector. Go back to the New Session tab, click New, and you should see something like Figure 2.

There you are, the default Ardour screen in a stylin' dark theme. See the Master bus? You will always have a Master bus. What is a bus, you ask? An audio bus, whether hardware or software, is for grouping tracks. You might put all backing vocals on one bus, or all bassoons, or alpenhorns, or what-have-you, and then apply edits to the whole group at once.

A bus is no good without some tracks, so let's add a single mono track. Click Session > Add Track/Bus, and then add one mono track in Normal mode. Now you have a Master bus and an Audio 1 track. I like to give tracks descriptive names, which you can do by clicking on the track name and typing a new one. I'll call mine "vocal". Buses can also have any name you want.

Next, click the red button on your new mono track to start the recording level monitor, and start making noise. If everything is set up correctly you'll see a tiny vertical volume meter on the right edge of the track panel, like in Figure 3.

A better way to monitor recording levels is to expose the Editor Mixer, so if it's not already visible click View > Show Editor Mixer. Now you have a decibel scale and other controls. Click on the track panel to make it the active panel, make noise, and you should see something like Figure 4.

All righty then, let's make a recording! There is a red button up on the Transport Menu, next to a green-lit button, which is the Stop Playback button. Click the red button, and it should start blinking. Now click the Play button to start recording. Click the Stop Playback button to stop recording. Figure 5 shows a recording session in action.

There is too much red in this image. The input level indicator on the Editor Mixer directly underneath the Solo button is red, and there are red marks in the waveform. This is because the recording level was too loud, which causes clipping, which creates distortion. Watch your recording levels because you do not want distortion. If you want to add some on purpose, do this later during editing when you can control it. With digital audio we have a very low noise floor, so it's not necessary to push recording levels right up to the line, and you can give yourself 8-12dB of headroom without worrying about noise.

This is often an adventure in Linux. I prefer to use audio hardware with actual knobs to twist because those always work, and it's faster than fumbling around trying to find the right software control. You can use alsamixer to control recording levels, and if nothing else make quieter or louder sounds. Which is not really the best way, but it's all right while we're testing and getting the hang of Ardour. alsamixer tip: if you have more than one audio interface, press F6 to select the one you want to control.

Naturally we want to hear our recording right away. Click the track panel to make sure it is selected, press the Home key to return the red marker to very beginning, and click the Play button. When you're finished listening click the Stop Playback button. Drag the red marker to start playback at a different location on the track. Create a playback region by clicking the little Select/Move Ranges button on the second toolbar, then select a region of your audio track with the cursor. Then click the Play range/selection button (top toolbar) to play only the selected region.

You can create multiple arbitrary regions on one track by holding down the Shift key when you make your selections. Then you can export just the selected regions into a single audio file, or into multiple separate files.

It's fine to listen to our recordings in Ardour, but usually the goal is to export to a portable audio format for playback on other devices. Click Session > Export, choose what to export (whole session or partial selections), and then choose your file format. If you accept the defaults you'll get a nice WAV file in the export directory of your project directory, which will play in any of your favorite software media players.

At export you'll get a gentle nag screen asking for donations. Nothing shows appreciation like cold hard cash; commercial equivalents to Ardour cost hundreds of dollars.

That concludes our Ardour crash course. This barely scratches the surface of what it can do. For more documentation and forums visit the Support page, and watch this space for more Ardour tutorials.

Comments (1)
You must be logged in to post a comment. Please register if you do not have an account yet.

View the original article here

The Tor Project Forks Firefox

Wednesday, 04 May 2011 00:00 LWN

The Tor project has announced that it is moving away from its Firefox extension and toward the maintenance of its own fork of the browser. "The Tor Browser bug [fixes] on the other hand are more directly usable by Firefox in its own Private Browsing Mode, which makes them more likely to merge quicker, and be maintained long-term. Also, because we are releasing our own Firefox-based browser, we will also have more control over experimenting with them and deploying these fixes to our users rapidly, as opposed to waiting for the next major Firefox release."

Comments (0)
You must be logged in to post a comment. Please register if you do not have an account yet.

View the original article here