Running ownCloud3 On Nginx (LEMP) On Debian Squeeze/Ubuntu 11.10

This tutorial shows how you can install and run ownCloud3 on a Debian Squeeze or Ubuntu 11.10 system that has nginx installed instead of Apache (LEMP = Linux + nginx (pronounced "engine x") + MySQL + PHP). ownCloud enables universal access...

This tutorial shows how you can install and run ownCloud3 on a Debian Squeeze or Ubuntu 11.10 system that has nginx installed instead of Apache (LEMP = Linux + nginx (pronounced "engine x") + MySQL + PHP). ownCloud enables universal access to files through the widely implemented WebDAV standard, providing a platform to easily view and sync contacts, calendars and bookmarks across devices while supporting sharing, viewing and editing via the web interface. It offers the ease-of-use of Dropbox and box.net without vendor lock in. ownCloud users can run its file sync and share services on their own hardware. nginx is a HTTP server that uses much less resources than Apache and delivers pages a lot of faster, especially static files.

Read more at HowtoForge]]>

Weekend project: Zap Your Coworkers' Minds with Multi-Pointer X

Care to rethink your desktop user experience? It may be simpler than you think. Chances are you own more than one pointing device, but for years you've never been able to take full advantage of that hardware, because whenever you plugged in a second hardware mouse, it simply shared control of the same cursor. But with X, it doesn't have to: you can have any many distinct, independent cursors on screen as you have devices to control them. So grab a spare from the parts box in the closet, and get ready for the ol' one-two punch.

Care to rethink your desktop user experience? It may be simpler than you think. Chances are you own more than one pointing device, but for years you've never been able to take full advantage of that hardware, because whenever you plugged in a second hardware mouse, it simply shared control of the same cursor. But with X, it doesn't have to: you can have any many distinct, independent cursors on screen as you have devices to control them. So grab a spare from the parts box in the closet, and get ready for the ol' one-two punch.

What, you don't have a spare mouse? There a good chance you do have a second pointing device, though — even if it's a mouse and the built-in trackpad on your laptop. But this process will work for any pointing hardware recognized by X, including a trackball and a mouse, or even a mouse and a pen tablet. To X, they are all the same. You will need to ensure that you are running the X.org X server 1.7 or later to use the feature in questions, Multi-Pointer X (MPX). You almost certainly already are — X.org 1.7 was finalized in 2009, and all mainstream distributions follow X.org closely. Bring up your distribution's package manager and install the libxi and libxcursor development packages as well; they will come in handy later.

What is MPX?

So why don't we use MPX all the time? For starters, most of the time one cursor on screen is all that we need, because there are very few applications that benefit from multiple pointers. But there are several. The simplest use case is for multi-head setups, where two or more separate login sessions run on the same machine, using different video outputs and separate keyboard/mouse combinations. You often see this type of configuration in classrooms and computer labs.

But the more unusual and intriguing alternative is running multiple pointers in a single session, which can simplify tasks that involve lots of manipulating on-screen objects. If you paint with a pressure-sensitive tablet using Krita or MyPaint, for example, a second cursor might allow you to keep your tablet pen on the canvas and alter paint settings or brush dynamics without hopping back-and-forth constantly. The same goes for other creative jobs like animation and 3D modeling: the more control, the easier it gets. Plus, let's be frank, there's always the wow factor — experimenting and showing off what Linux can do that lesser OSes cannot.

The basics

MPX is implemented in the XInput2 extension, which handles keyboards and pointing devices. The package is a core requirement for all desktop systems, but most users don't know that it comes with a handy command-line tool to inspect and alter the X session's input settings. The tool is named xinput, and if you run xinput list, it will print out a nested list of all of your system's active input devices. Mine looks like this:

 

⎡ Virtual core pointer id=2[master pointer (3)]⎜ ↳ Virtual core XTEST pointer id=4[slave pointer (2)]⎜ ↳ Microsoft Microsoft Trackball Explorer®id=9[slave pointer (2)]⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ Power Button id=6[slave keyboard (3)] ↳ Power Button id=7[slave keyboard (3)] ↳ Mitsumi Electric Goldtouch USB Keyboard id=8[slave keyboard (3)]

 

As you can see, I have one "virtual" core pointer and a corresponding "virtual" core keyboard, both of which are "master" devices to which the real hardware (the trackball and USB keyboard) are attached as slaves. Normally, whenever you attach a new input device, X attaches it as another slave to the existing (and only) master, so that all of your mice control the same pointer. In order to use them separately, we need to create a second virtual pointer device, then attach our new hardware and assign it as a slave to the second virtual pointer.

From a console, run xinput create-master Secondary to create another virtual device. The command as written will name it "Secondary" but you can choose any name you wish. Now plug in your second pointing device (unless it is already plugged in, of course), and run xinput list again. I plugged in my Wacom tablet, which added three lines to the list:

 

⎜ ↳ Wacom Graphire3 6x8 eraser id=16[slave pointer (2)]⎜ ↳ Wacom Graphire3 6x8 cursor id=17[slave pointer (2)]⎜ ↳ Wacom Graphire3 6x8 stylus id=18[slave pointer (2)]

 

The new virtual device also shows up, as a matched pointer/keyboard pair:

⎡ Secondary pointer id=10[master pointer (11)]⎜ ↳ Secondary XTEST pointer id=12[slave pointer (10)]⎣ Secondary keyboard id=11[master keyboard (10)] ↳ Secondary XTEST keyboard id=15[slave keyboard (11)]

 

That's because so far, X does not know whether we're interested in the keyboard or the pointer. You'll also note that every entry has a unique id, including the new hardware and the new virtual devices. The "cursor" entry for the Wacom tablet is the only one of the three we care about, and its id is 17. Running xinput reattach 17 "Secondary pointer" assigns it as a slave to the Secondary virtual pointer device, and voila — a second cursor appears on screen immediately.

You can start to use both pointers immediately (provided that your hand-eye coordination is up to the task). Grab two icons on the desktop at once, rearrange your windows with both hands, click on menus in two running applications at once.

Cursors, Foiled Again

What you'll soon find out, though, is that life on the bleeding edge comes with some complications. First of all, your mouse cursors look exactly the same, which can be confusing. Secondly, although GTK+3 itself is fully aware of XInput2 and can cope with MPX, individual applications may not be. That means you can uncover a lot of bugs simply by using both pointers at once.

You can tackle the indistinguishable-cursors issue by assigning a different X cursor theme to the second pointer. The normal desktop environments don't support this in their GUI preferences tools, but developer Antonio Ospite wrote a quick utility called xicursorset that fills in the gap. Compiling it requires the libxi and libxcursor development packages mentioned earlier, but it does not require any heavy dependencies, nor do you even need to install it as root — it runs quite happily in your home directory.

To assign a theme to your new cursor, simply run ./xicursorset 10 left_ptr some-cursor-theme-name. In this call, 10 is the id of our "Secondary pointer" entry from above, and left_ptr is the default cursor shape (X changes the cursor to a text-insertion point, resize-tool, and "wait" symbol, among other options, as needed). X.org cursor theme packages are provided by every Linux distribution; the "DMZ" theme is GNOME's default and uses a white arrow.

The simplest option might be to use the DMZ-Black variant: ./xicursorset 10 left_ptr DMZ-Black, but there are far more, including multi-color options. I personally grabbed the DMZ-Red theme from gnome-look.org's X cursor section, to make the auxiliary cursor stand out more.

One thing you will notice about these instructions is that they do not persist between reboots or login sessions. Currently there is no way to configure X.org to remember your wild and crazy cursor setups. I asked MPX author Peter Hutterer what the reasoning was, and he said it simply hadn't been asked for yet. Because MPX usage is limited to a few applications and usage scenarios, most people only use it in a dynamic sense — plugging in a second device when they need it for a particular task.

On the other hand, one of Ospite's readers (an MPX user named Vicente) wrote a small Bash script to automate the process; if you use MPX a lot, it could save you some keystrokes.

Multi-Tasking

But, as Hutterer said, apps with explicit support for MPX are pretty limited at this stage. There is a multi-cursor painting application included with Vinput, and the popular multiplayer game World Of Goo can use MPX to enable simultaneous play. There was a dedicated standalone painting application called mpx-paint hosted at GitHub, but the developer's account appears to have shut down.

Mainstream applications have been slower to pick up on MPX support. Inkscape is a likely candidate, where manipulating two or more control points at once would open up new possibilities. Developer Jon Cruz says it is "on the short list" alongside Inkscape's growing support for extended input devices. Whenever the application completes its port to GTK+3, the MPX support will follow.

Blender has also discussed MPX, but so far the project's main focus has been on six-axis 3D controllers (which are understandably a higher priority). However, for broader adoption we may have to wait. Hutterer himself worked on bringing MPX support to the Compiz window manager, but said that the real sticking point is tackling the "unsolved questions" about window management — which is something the desktop environment will need to tackle. Luckily, the latest X.org release includes multi-touch support — a related technology useful for gestures. As Linux on tablets continues to grow, gestures become an increasingly in-demand option. As applications are adapted to support multi-touch gestures, MPX support should grow as well.

The implications are interesting for a number of tasks, including the gaming and creative applications already discussed. When you throw in the possibility of multiple keyboards, the possibilities get even broader. After all, thanks to network-aware text editors like Gobby and Etherpad, we are getting more comfortable with multiple edit points in our document editors. Imagine what you could do with an IDE that allowed you to edit the code in one window while you interacted with the runtime simultaneously. In can be hard to grasp the implications — but you don't have to dream them all up; with MPX you can experiment today.

]]>

Comming Up:


Asbestos death rates are on the rise, learn what you need to lookout for when it comes to asbestos and mesothelioma.

Weekend project: Zap Your Coworkers' Minds with Multi-Pointer X

Care to rethink your desktop user experience? It may be simpler than you think. Chances are you own more than one pointing device, but for years you've never been able to take full advantage of that hardware, because whenever you plugged in a second hardware mouse, it simply shared control of the same cursor. But with X, it doesn't have to: you can have any many distinct, independent cursors on screen as you have devices to control them. So grab a spare from the parts box in the closet, and get ready for the ol' one-two punch.

What, you don't have a spare mouse? There a good chance you do have a second pointing device, though — even if it's a mouse and the built-in trackpad on your laptop. But this process will work for any pointing hardware recognized by X, including a trackball and a mouse, or even a mouse and a pen tablet. To X, they are all the same. You will need to ensure that you are running the X.org X server 1.7 or later to use the feature in questions, Multi-Pointer X (MPX). You almost certainly already are — X.org 1.7 was finalized in 2009, and all mainstream distributions follow X.org closely. Bring up your distribution's package manager and install the libxi and libxcursor development packages as well; they will come in handy later.

What is MPX?

So why don't we use MPX all the time? For starters, most of the time one cursor on screen is all that we need, because there are very few applications that benefit from multiple pointers. But there are several. The simplest use case is for multi-head setups, where two or more separate login sessions run on the same machine, using different video outputs and separate keyboard/mouse combinations. You often see this type of configuration in classrooms and computer labs.

But the more unusual and intriguing alternative is running multiple pointers in a single session, which can simplify tasks that involve lots of manipulating on-screen objects. If you paint with a pressure-sensitive tablet using Krita or MyPaint, for example, a second cursor might allow you to keep your tablet pen on the canvas and alter paint settings or brush dynamics without hopping back-and-forth constantly. The same goes for other creative jobs like animation and 3D modeling: the more control, the easier it gets. Plus, let's be frank, there's always the wow factor — experimenting and showing off what Linux can do that lesser OSes cannot.

The basics

MPX is implemented in the XInput2 extension, which handles keyboards and pointing devices. The package is a core requirement for all desktop systems, but most users don't know that it comes with a handy command-line tool to inspect and alter the X session's input settings. The tool is named xinput, and if you run xinput list, it will print out a nested list of all of your system's active input devices. Mine looks like this:

⎡ Virtual core pointer id=2 [master pointer (3)]⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]⎜ ↳ Microsoft Microsoft Trackball Explorer® id=9 [slave pointer (2)]⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Power Button id=7 [slave keyboard (3)] ↳ Mitsumi Electric Goldtouch USB Keyboard id=8 [slave keyboard (3)]

As you can see, I have one "virtual" core pointer and a corresponding "virtual" core keyboard, both of which are "master" devices to which the real hardware (the trackball and USB keyboard) are attached as slaves. Normally, whenever you attach a new input device, X attaches it as another slave to the existing (and only) master, so that all of your mice control the same pointer. In order to use them separately, we need to create a second virtual pointer device, then attach our new hardware and assign it as a slave to the second virtual pointer.

From a console, run xinput create-master Secondary to create another virtual device. The command as written will name it "Secondary" but you can choose any name you wish. Now plug in your second pointing device (unless it is already plugged in, of course), and run xinput list again. I plugged in my Wacom tablet, which added three lines to the list:

⎜ ↳ Wacom Graphire3 6x8 eraser id=16 [slave pointer (2)]⎜ ↳ Wacom Graphire3 6x8 cursor id=17 [slave pointer (2)]⎜ ↳ Wacom Graphire3 6x8 stylus id=18 [slave pointer (2)]

The new virtual device also shows up, as a matched pointer/keyboard pair:

⎡ Secondary pointer id=10 [master pointer (11)]⎜ ↳ Secondary XTEST pointer id=12 [slave pointer (10)]⎣ Secondary keyboard id=11 [master keyboard (10)] ↳ Secondary XTEST keyboard id=15 [slave keyboard (11)]

That's because so far, X does not know whether we're interested in the keyboard or the pointer. You'll also note that every entry has a unique id, including the new hardware and the new virtual devices. The "cursor" entry for the Wacom tablet is the only one of the three we care about, and its id is 17. Running xinput reattach 17 "Secondary pointer" assigns it as a slave to the Secondary virtual pointer device, and voila — a second cursor appears on screen immediately.

You can start to use both pointers immediately (provided that your hand-eye coordination is up to the task). Grab two icons on the desktop at once, rearrange your windows with both hands, click on menus in two running applications at once.

Cursors, Foiled Again

What you'll soon find out, though, is that life on the bleeding edge comes with some complications. First of all, your mouse cursors look exactly the same, which can be confusing. Secondly, although GTK+3 itself is fully aware of XInput2 and can cope with MPX, individual applications may not be. That means you can uncover a lot of bugs simply by using both pointers at once.

You can tackle the indistinguishable-cursors issue by assigning a different X cursor theme to the second pointer. The normal desktop environments don't support this in their GUI preferences tools, but developer Antonio Ospite wrote a quick utility called xicursorset that fills in the gap. Compiling it requires the libxi and libxcursor development packages mentioned earlier, but it does not require any heavy dependencies, nor do you even need to install it as root — it runs quite happily in your home directory.

To assign a theme to your new cursor, simply run ./xicursorset 10 left_ptr some-cursor-theme-name. In this call, 10 is the id of our "Secondary pointer" entry from above, and left_ptr is the default cursor shape (X changes the cursor to a text-insertion point, resize-tool, and "wait" symbol, among other options, as needed). X.org cursor theme packages are provided by every Linux distribution; the "DMZ" theme is GNOME's default and uses a white arrow.

The simplest option might be to use the DMZ-Black variant: ./xicursorset 10 left_ptr DMZ-Black, but there are far more, including multi-color options. I personally grabbed the DMZ-Red theme from gnome-look.org's X cursor section, to make the auxiliary cursor stand out more.

One thing you will notice about these instructions is that they do not persist between reboots or login sessions. Currently there is no way to configure X.org to remember your wild and crazy cursor setups. I asked MPX author Peter Hutterer what the reasoning was, and he said it simply hadn't been asked for yet. Because MPX usage is limited to a few applications and usage scenarios, most people only use it in a dynamic sense — plugging in a second device when they need it for a particular task.

On the other hand, one of Ospite's readers (an MPX user named Vicente) wrote a small Bash script to automate the process; if you use MPX a lot, it could save you some keystrokes.

Multi-Tasking

But, as Hutterer said, apps with explicit support for MPX are pretty limited at this stage. There is a multi-cursor painting application included with Vinput, and the popular multiplayer game World Of Goo can use MPX to enable simultaneous play. There was a dedicated standalone painting application called mpx-paint hosted at GitHub, but the developer's account appears to have shut down.

Mainstream applications have been slower to pick up on MPX support. Inkscape is a likely candidate, where manipulating two or more control points at once would open up new possibilities. Developer Jon Cruz says it is "on the short list" alongside Inkscape's growing support for extended input devices. Whenever the application completes its port to GTK+3, the MPX support will follow.

Blender has also discussed MPX, but so far the project's main focus has been on six-axis 3D controllers (which are understandably a higher priority). However, for broader adoption we may have to wait. Hutterer himself worked on bringing MPX support to the Compiz window manager, but said that the real sticking point is tackling the "unsolved questions" about window management — which is something the desktop environment will need to tackle. Luckily, the latest X.org release includes multi-touch support — a related technology useful for gestures. As Linux on tablets continues to grow, gestures become an increasingly in-demand option. As applications are adapted to support multi-touch gestures, MPX support should grow as well.

The implications are interesting for a number of tasks, including the gaming and creative applications already discussed. When you throw in the possibility of multiple keyboards, the possibilities get even broader. After all, thanks to network-aware text editors like Gobby and Etherpad, we are getting more comfortable with multiple edit points in our document editors. Imagine what you could do with an IDE that allowed you to edit the code in one window while you interacted with the runtime simultaneously. In can be hard to grasp the implications — but you don't have to dream them all up; with MPX you can experiment today.

Subscribe to this comment's feed

Show/hide comments

Show/hide comment form

Get Your Embedded Linux On: Join Me at Yocto Project Developer Day

Building an embedded Linux distribution can be a daunting task. From the Board Support Package (BSP) to Kernel configuration, root file system setup and the selection many additional software package there are many choices to make and taking the wrong turn can easily lead to a dead end and many hours of wasted time.

The Yocto Project greatly simplifies this process with a set of proven tools and recipes allowing you to build you own custom Linux distribution tailored to your requirements.

During The Linux Foundation's Embedded Linux Conference at the Hotel Sofitel San Francisco Bay in Redwood Shores from February 15 through 17, you have the unique opportunity to build your competence in embedded Linux and Yocto.

On the day before the conference, February 14, the first-ever Yocto Project Developer Day you will have the opportunity to meet the Yocto Project's supporting organizations and many experts who will be presenting sessions and labs.

Stay a little longer and right after the conference on Saturday/Sunday February 18/19, you can deepen your Yocto knowledge with a 2-day crash course offered by The Linux Foundation.

Join me for two days of hands-on learning fun, building Linux system images to boot in an emulator and on a Beagleboard. First you will get an introduction into the Yocto Project and OpenEmbedded and how they relate. Then we will dive into the Poky Build Process, the core of the Yocto Project, and the Bitbake build orchestrator. You will learn about metadata layers, recipes and classes and how to use them to customize your distribution built by Yocoto.

What will you need? You know your way around on a Linux system and are not afraid of a commnad shell. You can use any of the standard text editors such as vi or emacs. You understand the basics of compiling and linking programs and constructing Makefile.

What to bring? Tag along your laptop with Ubuntu 10.04 LTS 32-bit installed on it. Or alternatively, have VirtualBox 4.1.8 installed on your system. We can provide you with an appliance ready to be imported in VirtualBox.

I am looking forward to seeing you soon in Redwood Shores!

A Look At Mozilla's Enterprise Plans for Firefox and Thunderbird

When Mozilla adopted its six-week rapid development cycle in early 2011, backlash came from a number of angles — but the heaviest was from enterprise IT departments. In October, the browser maker formed a working group in order to sit down with corporate users and hash out a suitable support plan. The result is the Mozilla Extended Support Release (ESR) program, which is now up and running for Firefox, and is due to debut shortly for Thunderbird a well.

When Mozilla adopted its six-week rapid development cycle in early 2011, backlash came from a number of angles — but the heaviest was from enterprise IT departments. In October, the browser maker formed a working group in order to sit down with corporate users and hash out a suitable support plan. The result is the Mozilla Extended Support Release (ESR) program, which is now up and running for Firefox, and is due to debut shortly for Thunderbird a well.

Rapid is Bad?

If the backlash comes as a surprises to you, you may simply work in a computing environment that does fall into the problematic territory that Mozilla ESR is intended to serve. One of the most important ways that enterprises manage the task of supporting hundreds or thousands of users is by locking down updates, and putting all new releases through a rigorous security and compatibility testing process before deploying them across the company — which ensures both stability and uniformity. Being asked to push out eight Firefox updates a year is bad enough, but along with the new release schedule Mozilla announced it was also discontinuing security updates for "older" releases.

To many in the industry, that pace made it virtually impossible for corporate IT departments to keep up with Firefox — a situation exacerbated when Mozilla's Aza Dotzler publicly opined that the enterprise "has never been (and I'll argue, shouldn't be)" Mozilla's focus. The Mozilla Enterprise User Working Group was formed a month later to help Mozilla and enterprise customers and come up with a solution together.

The working group holds monthly phone meetings — the minutes of which are publicly available on the Mozilla wiki — and has a Bugzilla category for issue tracking and a moderated mailing list to which interested parties must send a request in order to join. The meetings were evidently fruitful, resulting in a number of bugs and blueprints for Firefox deployment tools (including the Windows MSI installer used by most IT departments and the group policy objects (GPOs) used to manage security) and in proposals for creating a manageable security fix "support tail."

Eventually the group wrote a comprehensive extended-support proposal for Firefox, which was published on the wiki in early December. On January 10, 2012, Mozilla announced that the proposal had been officially approved as an action plan.

Firefox ESR

The plan establishes Firefox ESR as a separate product tailored for use by enterprises, universities, public institutions, and other large-scale deployments that rely on centrally-managed IT.

ESR releases will be supported for 54 weeks (or nine releases of Firefox's rapid-development cycle), a schedule that provides a balanced lifespan between the new rapid-release schedule of Firefox and the long-term support expectations of enterprise users. During the 54-week time-frame, high-impact security fixes will be provided, but updates that alter browser functionality or change add-on compatibility will not be pushed out.

ESR releases will be scheduled so that the new release is delivered 12 weeks before the end-of-lifetime date of its predecessor, to allow for enterprise testing and qualification. Mozilla will also continue to support all platforms and locales included in the ESR release for the ESR's lifetime, even if platform or locale support is dropped from rapid-release Firefox in the interim. That means that even if Firefox deprecates an older platform (say, Mac OS X 10.4) halfway through the 54-week lifespan of the ESR, Mozilla will continue to provide security fixes for 10.4 up until the end of the 54th week.

The first ESR release will be Firefox 10, scheduled for January 31. Subsequent releases over the 54-week lifetime will be numbered as Firefox ESR 10.0.1, 10.0.2, and so forth. In order to avert any potential end-user confusion, however, the ESR releases will only be announced and marketed through the Enterprise wiki page, although the packages themselves will be delivered through the usual Mozilla staging servers. When Firefox ESR 10 reaches end-of-life, it will be replaced by the then-current build of upstream Firefox, Firefox 17.

Finally, it is important to note that the ESR plan does not cover Firefox Mobile, and that organizations that choose to deploy Firefox ESR are warned that they may experience compatibility problems as the releases age, and that only urgent security fixes are guaranteed. The risk profile of ESR compared to normal rapid-release Firefox must be determined by the organization.

Thunderbird ESR

The original Firefox ESR plan made a point of noting that Thunderbird was not covered by the proposal. Shortly after the Firefox plan was publicized, however, the project began drafting a Thunderbird ESR plan to accompany it. On January 12, the official Thunderbird blog carried the announcement that Thunderbird would be adopting the same schedule.

Because Thunderbird's plan is to keep in step with Firefox ESR, is does not yet have a separate incarnation of the plan on the wiki. However, as the announcement and mailing list thread make clear, the details are the same: Thunderbird ESR releases will be made once every 54 weeks, and will receive critical security updates, but no changes that alter the functionality of the application or affect the compatibility of add-ons.

When Mozilla adopted the rapid-development cycle, it intentionally synchronized the version numbers used by Firefox, Thunderbird, and the Gecko layout engine common to both applications — thus keeping all three on the same footing, making updates easier to manage. As a result, Thunderbird 10 will also be the first Thunderbird ESR release, and will receive security updates for one year. As with Firefox, the next scheduled ESR release will be version 17, in early 2013.

Like Firefox, Thunderbird is covered by the Enterprise User Working Group, but the project maintains a separate presence on the Mozilla wiki.

The wiki provides several other resources of use to enterprises deploying Thunderbird ESR, most notably a guide to managing upgrades with large-volume IMAP servers and a guide to keeping enterprise-related preferences synchronized. In both instances, the amount of email that accumulates in a modern mailbox between upgrades is the problematic factor, a concern Firefox ESR does not share.

T-Minus-Zero

The Firefox ESR and Thunderbird ESR plans have been in discussion for more than six months, and Mozilla has assembled the engineering resources to implement both. However, this is only the first round, and 54 weeks is a long time in software terms; it is always possible that there will be adjustments to the plan between now and the first ESR end-of-life.

Nevertheless, the important fact is that the project was able to successfully sit down with enterprise IT users and arrange a schedule beneficial to both. The shift to a six-week development cycle has not been an easy one, and there are still other concerns (from other groups, such as extension authors and Linux distributions) that have yet to be completely resolved, but the ESR action plans offer hope that all will be well in the long run.

]]>

Interview: Jaisen Mathai of OpenPhoto

I met Jaisen Mathai at SCALE10x after seeing his UpSCALE talk in which he introduced the OpenPhoto project with 20 slides in five-minutes. In this interview, Mathai explains what inspired the ambitious project and his vision for where it will be by the end of the year.

Last June, Mathai wrote a blog post, The state of online photo sharing and what’s next, introducing his idea for OpenPhoto. A few busy months later, on January 30, 2012, OpenPhoto 1.3.2 was released. OpenPhoto is being developed with the help of several open source technologies, including PHP, Python, Ruby, MySql, Linux, ImageMagick, and GraphicsMagick. Mathai says the OpenPhoto software runs on other operating systems, but it runs best on Linux.

Linux.com: What inspired you to start the OpenPhoto project?

Jaisen Mathai: I wanted to make sure I'll be able to sit down with my one-year-old son in 18 years and show him photos of his childhood. A decade or two ago, we had film and shoeboxes. While inefficient, they worked really well. Most of us have photos of our childhood.

Today we've got a fantastic replacement for film – SD cards or the memory in our phones – but now we have shoebox chaos. Multiple shoeboxes with duplicate photos across multiple services, all of which make it difficult to get your photos back. In this regard, technology has failed us. We take an order of magnitude more photos than we did in the past but our options to archive them are decades old.

Linux.com: Who else helps you with the project?

Jaisen Mathai: We've had over 40 contributors from the community. I'm the only full-time person on the project, and Patrick Santana will be joining me full time in March. It's completely bootstrapped at the moment.

We raised the $25k on Kickstarter, and Mozilla accepted us into their WebFWD program and provides technical, marketing and funding advice.

Linux.com: What have been the biggest challenges on the project?

Jaisen Mathai: Keeping up with the community. I knew right away that a lot of people were interested in the idea for the same reasons I was building it. I didn't, however, expect so many people to get engaged the way they did. It's a wonderful problem to have, but for a month or two 75 percent of my time was spent communicating with users. Since then, someone from the community has taken on the role as a community manager and she's doing an amazing job.

Funding for the project has also been something we're spending a bit of time on. What we're doing is no small task. We need an engaged community as well as people dedicated and committed to building everything on our roadmap. We're going up against some formidable opponents, but our growth has been entirely organic so we know we're striking a chord with users.

Lastly, being an open source project and building elegant and easy-to-use software isn't easy. We're heavily focused on design, UI and UX. There are several amazing pixel pushers in our community, and our recent iPhone app is a testament to that. It looks as good – if not better – than other photo apps.

Linux.com: How does OpenPhoto compare to other photo sharing sites?

Jaisen Mathai: When you upload a photo to Flickr or Picasa, the photo gets stored on Yahoo or Google's servers. You can only access your photos using the tools they provide for you, some of which make it difficult to impossible to get your photos out.

With OpenPhoto, you have the option of telling the software exactly where your photos, tags, and comments are to be stored. You grant the OpenPhoto access to your photos, not the other way around. It's a subtle difference but the implications are immense.

Linux.com: Are there features other sites offer that you'd like to add to OpenPhoto?

Jaisen Mathai: Our goal is to get quasi-feature parity with sites like Flickr and SmugMug. We're getting really close to having the important features implemented, including mobile.

Facebook has people tagging and Flickr has geo-fencing. These are awesome features and I know they'll make their way into OpenPhoto. The beauty of being open source is that if the community wants it, they'll build it. We've already seen that in play for the iPhone app, WordPress plugin, and language bindings – Ruby, Python, Java.

Linux.com: How can members of the open source community help you with the project?

Jaisen Mathai: We need programmers, designers, copywriters, translators, and more. The best place to start is http://theopenphotoproject.org/contribute, where we also list ways to contact us.

Linux.com: Where do you hope to be on the project by the end of the year?

Jaisen Mathai: We already have our web application released. By the end of February, we'll have an iPhone app publicly available followed by an Android app. Other major features are tools to help users aggregate their photos from multiple sites into one location, handling RAW photos and video support. Supporting video has been one of the biggest feature requests, and it makes a lot of sense but we're not rushing into anything.

Linux.com: What other events do you plan to attend this year?

Jaisen Mathai: I'm speaking at several user groups in the bay area and am considering speaking at the LinuxFest Northwest.

Thanks to Jaisen for answering our questions. To find out more about OpenPhoto, visit the OpenPhoto homepage, its GitHub repository and/or follow @openphoto on Twitter.

Subscribe to this comment's feed

Show/hide comments

Show/hide comment form

A Look At Mozilla's Enterprise Plans for Firefox and Thunderbird

When Mozilla adopted its six-week rapid development cycle in early 2011, backlash came from a number of angles — but the heaviest was from enterprise IT departments. In October, the browser maker formed a working group in order to sit down with corporate users and hash out a suitable support plan. The result is the Mozilla Extended Support Release (ESR) program, which is now up and running for Firefox, and is due to debut shortly for Thunderbird a well.

Rapid is Bad?

If the backlash comes as a surprises to you, you may simply work in a computing environment that does fall into the problematic territory that Mozilla ESR is intended to serve. One of the most important ways that enterprises manage the task of supporting hundreds or thousands of users is by locking down updates, and putting all new releases through a rigorous security and compatibility testing process before deploying them across the company — which ensures both stability and uniformity. Being asked to push out eight Firefox updates a year is bad enough, but along with the new release schedule Mozilla announced it was also discontinuing security updates for "older" releases.

To many in the industry, that pace made it virtually impossible for corporate IT departments to keep up with Firefox — a situation exacerbated when Mozilla's Aza Dotzler publicly opined that the enterprise "has never been (and I'll argue, shouldn't be)" Mozilla's focus. The Mozilla Enterprise User Working Group was formed a month later to help Mozilla and enterprise customers and come up with a solution together.

The working group holds monthly phone meetings — the minutes of which are publicly available on the Mozilla wiki — and has a Bugzilla category for issue tracking and a moderated mailing list to which interested parties must send a request in order to join. The meetings were evidently fruitful, resulting in a number of bugs and blueprints for Firefox deployment tools (including the Windows MSI installer used by most IT departments and the group policy objects (GPOs) used to manage security) and in proposals for creating a manageable security fix "support tail."

Eventually the group wrote a comprehensive extended-support proposal for Firefox, which was published on the wiki in early December. On January 10, 2012, Mozilla announced that the proposal had been officially approved as an action plan.

Firefox ESR

The plan establishes Firefox ESR as a separate product tailored for use by enterprises, universities, public institutions, and other large-scale deployments that rely on centrally-managed IT.

ESR releases will be supported for 54 weeks (or nine releases of Firefox's rapid-development cycle), a schedule that provides a balanced lifespan between the new rapid-release schedule of Firefox and the long-term support expectations of enterprise users. During the 54-week time-frame, high-impact security fixes will be provided, but updates that alter browser functionality or change add-on compatibility will not be pushed out.

ESR releases will be scheduled so that the new release is delivered 12 weeks before the end-of-lifetime date of its predecessor, to allow for enterprise testing and qualification. Mozilla will also continue to support all platforms and locales included in the ESR release for the ESR's lifetime, even if platform or locale support is dropped from rapid-release Firefox in the interim. That means that even if Firefox deprecates an older platform (say, Mac OS X 10.4) halfway through the 54-week lifespan of the ESR, Mozilla will continue to provide security fixes for 10.4 up until the end of the 54th week.

The first ESR release will be Firefox 10, scheduled for January 31. Subsequent releases over the 54-week lifetime will be numbered as Firefox ESR 10.0.1, 10.0.2, and so forth. In order to avert any potential end-user confusion, however, the ESR releases will only be announced and marketed through the Enterprise wiki page, although the packages themselves will be delivered through the usual Mozilla staging servers. When Firefox ESR 10 reaches end-of-life, it will be replaced by the then-current build of upstream Firefox, Firefox 17.

Finally, it is important to note that the ESR plan does not cover Firefox Mobile, and that organizations that choose to deploy Firefox ESR are warned that they may experience compatibility problems as the releases age, and that only urgent security fixes are guaranteed. The risk profile of ESR compared to normal rapid-release Firefox must be determined by the organization.

Thunderbird ESR

The original Firefox ESR plan made a point of noting that Thunderbird was not covered by the proposal. Shortly after the Firefox plan was publicized, however, the project began drafting a Thunderbird ESR plan to accompany it. On January 12, the official Thunderbird blog carried the announcement that Thunderbird would be adopting the same schedule.

Because Thunderbird's plan is to keep in step with Firefox ESR, is does not yet have a separate incarnation of the plan on the wiki. However, as the announcement and mailing list thread make clear, the details are the same: Thunderbird ESR releases will be made once every 54 weeks, and will receive critical security updates, but no changes that alter the functionality of the application or affect the compatibility of add-ons.

When Mozilla adopted the rapid-development cycle, it intentionally synchronized the version numbers used by Firefox, Thunderbird, and the Gecko layout engine common to both applications — thus keeping all three on the same footing, making updates easier to manage. As a result, Thunderbird 10 will also be the first Thunderbird ESR release, and will receive security updates for one year. As with Firefox, the next scheduled ESR release will be version 17, in early 2013.

Like Firefox, Thunderbird is covered by the Enterprise User Working Group, but the project maintains a separate presence on the Mozilla wiki.

The wiki provides several other resources of use to enterprises deploying Thunderbird ESR, most notably a guide to managing upgrades with large-volume IMAP servers and a guide to keeping enterprise-related preferences synchronized. In both instances, the amount of email that accumulates in a modern mailbox between upgrades is the problematic factor, a concern Firefox ESR does not share.

T-Minus-Zero

The Firefox ESR and Thunderbird ESR plans have been in discussion for more than six months, and Mozilla has assembled the engineering resources to implement both. However, this is only the first round, and 54 weeks is a long time in software terms; it is always possible that there will be adjustments to the plan between now and the first ESR end-of-life.

Nevertheless, the important fact is that the project was able to successfully sit down with enterprise IT users and arrange a schedule beneficial to both. The shift to a six-week development cycle has not been an easy one, and there are still other concerns (from other groups, such as extension authors and Linux distributions) that have yet to be completely resolved, but the ESR action plans offer hope that all will be well in the long run.

Subscribe to this comment's feed

Show/hide comments

Show/hide comment form

The Ever-Changing Linux Filesystems: Merging Directoris into /usr

If you don't like change, working in IT has to be a harrowing experience. That's particularly true in open source, where few stand on tradition and things move at breakneck pace. The latest change that has a few folks excited? Fedora's proposal to "move all to /usr." On the face, this might seem like a shocking departure from standards – but look a bit deeper and it seems to make sense.

The proposal for Fedora comes from Harald Hoyer and Kay Sievers. The long-term plan is to "clean up the mess and confusion the current split of / vs. /usr has created. All tools will move back to /usr where they belong, and the rootfs will only contain compat-symlinks into /usr. Almost the entire system installed by packages will reside in /usr."

But wait, isn't the split there for a reason? Yes, but the reasons that /usr has been split off are rooted in the history of Unix and the limitations of the tiny (space-wise) hard drives that the original UNIX equipment came with. On the BusyBox list, Rob Landley noted that the /usr split came about when "the operating system grew too big to fit on the first RK05 disk pack (their root filesystem)" it was allowed to "leak out" on to the second one "which is where all the user home directories lived (which is why the mount was called /usr).

"They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!)."

Landley goes on to say that the /usr split "stopped making any sense before Linux was ever invented" for several reasons. The early system startup is dealt with by initrd and initramfs. Shared libraries mean that you can't upgrade /lib and /usr/bin independently anymore.

The size issue? Well, hard drives weren't exactly huge when Linux was invented, but users had a lot more room to work by the time Linus Torvalds started working on Linux. These days? Even embedded devices have a lot more room than the dinky hard drives the early Unix guys had to work with. Now, when I say "dinky" I only mean storage capacity. Those things were huge, but they couldn't even hold a copy of Dark Side of the Moon as a 128KB MP3. (Not least of which because the album wasn't recorded until after the /usr split, and MP3 hadn't been invented – but you get the idea.)

The Proposal

So the proposal in front of Fedora is to move directories /bin, /sbin, /lib, and /lib64 under /usr.

This will improve compatibility with other *nix type systems. Solaris started this some time ago, and Lennart Poettering notes that it was completed in Solaris 11.

Poettering also says that it will make porting packages much easier, and be more compatible with upstream development.

It also reduces complexity of the existing filesystem hierarchy, and makes sharing the /usr partition easier with multiple guest OSes or over NFS.

The transition is expected to start in Fedora 17. Users can test it out via a Yum update while testing Fedora 17 if they're feeling brave.

Panic?

These types of things tend to be met with stiff resistance. Some folks see no reason to change, others feel concerned that system changes are going to lead to horrible system problems.

It's entirely possible that there will be some glitches on the way to making the change, but overall it seems to be well thought-out and unlikely to lead to major catastrophes. Fedora may be the first to do this, but it isn't going to be the last. I'd suspect that in a few years' time, all of the major distros will have unified on the /usr merge.

Check out the freedesktop.org page with "myths and facts" too. There may be some slightly alarmist stuff out there about the merge, but be sure to check all the facts before getting worried.