Leading items

Apple's touch-screen patent

In March, 1988, Apple filed suit against Microsoft and HP, claiming that their new window-oriented interfaces violated Apple's copyrights on the Macintosh GUI. This suit drew widespread condemnation on the net and a boycott compaign by the Free Software Foundation, which refused to incorporate Macintosh support into its software for years. Apple eventually lost, but, in the process, it cast a cloud of uncertainty over graphical interfaces for some years.

More recently, Apple Chief Operating Officer Tim Cook was quoted in this way:

The saber which Apple is rattling here is widely thought to be patent #7,479,949, often referred to as "the multitouch patent." Multitouch interfaces are those which can respond to simultaneous operation of two or more pointing devices. These "devices" are normally fingers on a touch screen, but it need not be that way. Apple's iPhone and iPod Touch devices have made multitouch a core component of the interface, as typified by the "pinch" gesture used to change the zoom of the object displayed on the screen. At this particular time, multitouch typifies Apple devices in much the same way that a well-developed windows-icons-menus-pointer interface did in the late 1980's.

Incorporation of multitouch techniques into other products seems like it is only a matter of time - and not very much time at that. The upcoming Palm Pre device is one obvious example. The Android developers have also clearly been thinking about multitouch; current releases do not support it, but it turns out that the G1 hardware supports multitouch, much to the joy of the G1 hacking community. Whether that capability will ever be exploited by official Android releases remains to be seen, though. Google is clearly concerned about the issue, and developers have been asked not to discuss the patent on the Android lists.

Whenever one deals in patents, one must look at what has actually been claimed. The first claim for Apple's patent is illustrative (if painful):

Note that this claim does not address multitouch techniques at all. Some of the dependent claims do mention it, but in the specific context of using a two-thumb gesture to change the orientation of a web browser display. The iconic "pinch" technique does not appear anywhere in the claims for this patent, though it is mentioned several times in the descriptive text. Your editor is far, far removed from being a patent attorney, but he has a hard time seeing how this patent could be read against most multitouch techniques.

What does appear in this patent is a heuristic for suppressing horizontal scrolling if the user makes a sufficiently steep gesture on the touchscreen. This sort of heuristic can certainly be found in the Android interface, which does just that kind of vertical-only scrolling. In your editors (again, unqualified) reading, the scrolling claims present much more potential for trouble than multitouch.

If Apple were to prevail with claims based on this patent, the effects could be severe - at least, in the United States. Devices made by companies other than Apple could lose a number of important techniques which make touchscreen-based interfaces usable. Companies like Palm could conceivably license the patent from Apple (if Apple were willing), but that is almost certainly not an option for toolkits (like Android) which are based on free software. Linux World Domination for mobile devices could well suffer a major setback.

Arguably, this patent would have no effect on business conducted outside of the US. Fully-capable devices could be sold elsewhere, as long as they are developed entirely outside of the United States. American users could be stuck with iPhones or devices with inferior interfaces - with the lucky few carrying devices furtively imported from elsewhere. In practice, excluding the US would make it harder for any such product to succeed. And US-based platforms, including Android and Palm webOS, would be out of luck.

It may not come to that, though. Perhaps Apple does not intend to use its patents as an offensive weapon. After all, the company has done well enough by focusing on building great products, and the look-and-feel lawsuits of the 1980's did little to help Apple succeed. A new round of litigation would risk alienating developers worldwide and distracting Apple from the activities which truly benefit the company.

If Apple does take the offensive, it faces a couple of severe obstacles. One is the slowly-changing attitude in the US, where legislators and judges are (belatedly) figuring out that the patent system is out of control. The bar has been raised (though not by enough), making patent enforcement more difficult than it once was. Beyond that, there is also the issue of prior art. The best reference there would appear to be this extensive history of touch-based interfaces put together by Bill Buxton at Microsoft Research. Suffice to say that, as in most other areas of endeavor, there is little that is truly new with touchscreen interfaces.

(As an aside, it's also worth noting that Microsoft, by virtue of its own interest in mobile devices, could become an unlikely ally of the free software community in this particular battle, should it come to be fought.)

All of that will be little comfort, though, to anybody working with touchscreen-based products in the US now. Even if a company sued by Apple were to emerge victorious, that victory would come at the cost of millions of dollars spent, much time lost, and much uncertainty sown among others who are thinking about developing for that company's platform. So, for now, the patent system continues to inhibit the innovation that it was created to encourage.

Comments (33 posted)

PostgreSQL's review bottleneck, episode 3

As PostgreSQL gears up for its 8.4 release, contributors to the popular database project are debating on the pgsql-hackers mailing list how to handle two large patches. The immediate issue is whether to include the patches in the 8.4 or 8.5 release, but the larger issue is a review system that suffers from a shortage of peer reviewers and that has improved only marginally in the last two releases, despite concerns raised in 2007 and 2006. The current discussion offers a snapshot of the growing pains that large free software projects find themselves increasingly facing.

PostgreSQL development is based upon a series of CommitFests — periods in which patches are accepted and reviewed that are followed by development releases. Between CommitFests, no new patches are accepted. The trouble is that two patches in particular, SE-PostgreSQL, which adds Security Enhanced Linux's security model, and Hot Standby, which allows queries on databases during archival recoveries, have not been fully reviewed, and have prolonged the current CommitFest. Although developer Robert Haas suggests that at least three other patches may also be delaying the release cycle, most of the discussion has centered on SE-PostgreSQL and Hot Standby.

Part of the debate over the two patches concerns exactly what to do with them. As Bernd Helmle points out, with the current CommitFest already over three and a half months old, and the next one not due until May, "That means we're essentially closed to new patches for six months, which is a really long time. To put it another way, for every week the core team spends reworking the existing patches, it will be another week before someone can get feedback on any new patches submitted now."

Moreover, core team member Tom Lane says, prolonging the current CommitFest until the patches are ready means that the 8.4 release will not happen until the fall of 2009, rather than in late spring. Such a release date would mean that the next release will take almost a year to produce, which is unacceptably long in most contributors' views.

Given this situation, Lane says, community has to decide whether to delay the release of each of these patches to the 8.5 release, delay long enough for the patches to be properly handled, or else include only a limited feature set for each of them as a compromise solution.

In the case of SE-PostgreSQL, several contributors seem open to dropping it altogether. "To be brutally honest, I don't care about the feature at all: the only thing I ever do with SE Linux is turn it off," Haas says, and one or two others agree.

Unsurprisingly, this attitude sits poorly with KaiGai Kohei, the developer of SE-PostgreSQL. Demanding a rationale for the proposed rejection of his patch, Kohei notes that, given the growing popularity of cloud computing, database security is becoming increasingly important. "If we can include these features in a timely fashion," Kohei writes, "it makes PostgreSQL more attractive."

Kohei is supported by Dave Page, who is concerned that delaying or rejecting SE-PostgreSQL, which is sponsored by the Exploratory IT Human Resources Project "will send a fine message to those companies that have sponsored development work — that we will arbitrarily reject large patches that have been worked on following the procedures that we require." Page is concerned that "we will rapidly find that no company wants to sponsor features for PostgreSQL in the future."

In the same thread that these scheduling and content issues are being discussed, PostgreSQL contributors are also debating the reasons that the review system is not working as well as it should. Heikki Linnakangas suggests that the situation was to some extent inevitable because "big patches simply take a long time to mature."

Others suggested that the problem was that final approval of all patches must be given by the core team, and the work load has simply become too large. As Helmle says, "core developers are too busy with reviewing stuff during the CommitFest. Because of this, it's really hard to get the necessary time of somebody who is able to evaluate the architecture of a new feature and (more important) its side-effects on the whole system." Under these circumstances, Helmle questions whether delaying the acceptance of features will do anything to improve the release cycle.

A large part of the discussion of the review system centered on possible improvements to it. Haas raises the possibility of adding a "FeedbackFest" at the end of CommitFests to focus the entire project on patch reviews, and also a policy that, once a patch was rejected, it would be declared dead if a corrected version was not resubmitted within two weeks. In much the same vein, Jaime Casanova suggested a policy under which large patches submitted late in a CommitFest would not be guaranteed a review. "Maybe that will [encourage] authors to send patches more often and more early," Casanova writes.

Another possibility, raised by Riggs is to overlap releases, so that submitters of rejected patches could move their contributions to a later release and know when it was likely to be included. However, this idea was quickly shot down by Lane, who points out that "key committers are overstressed already." In fact, in Lane's view, overlapping releases would only add to the problem because, "everyone will find it more interesting/fun to work on new patches instead" of reviewing. "The current system at least gives non-committers developers some motivation to help with that stuff, because they know their patches won't be looked at until beta is over."

Much of the discussion about solutions was about a system that would automatically send reminders about the status of patches — a solution that everyone in the discussion seemed to agree would be more efficient than the present reliance on a wiki page for each CommitFest. Josh Berkus, who is co-lead for the present CommitFest agreed, writing that "My inability to systematically send reminder e-mails to submitters and reviewers — or, for that matter, even track when they were assigned or last updated — has been a significant drag on the effectiveness of the CommitFests. Some patches stalled, and I missed them."

Possible solutions for notification included Patchwork and Review Board. However, as the merits of different solutions were debated, Berkus notes that "our review/commit process is so peculiar to our project that using *any* prebuilt solution would require us to change our process to support the tool. And I can't imagine this group doing that." The possibility of writing a custom application was raised by Haas, but no decisions were made to start such a project.

At this point, discussion petered out into a discussion of what SE-PostgreSQL and Hot Standby required in order to be included in the 8.4 release. One possible stumbling block for SE-PostgreSQL may have been removed when Kohei explained that the security policy of the patch, which no project member apparently felt competent to review, didn't need review because it had already been tested by SE Linux, the upstream project.

A decision on what to do with the two patches should be made within a week, according to Berkus.

Until then, what is interesting about the discussion to outsiders is how it shows one project attempting to deal with growth. From the discussion, it seems that PostgreSQL has outgrown policies and procedures that once served it well, and is still adjusting to the change. Like many other free software projects these days, PostgreSQL is facing the challenge of its own success.

Comments (4 posted)

Aleutia E2: low power to the people

Green computing frequently makes the news either for its cost-saving potential to businesses, or as a way for eco-conscious consumers to reduce their environmental footprint. But UK-based Aleutia, Ltd takes a different approach, using green to produce ultra-low-power-consumption Linux PCs for classrooms and businesses in developing countries. The company's flagship product is the E2, a compact desktop system that consumes just 8 watts.

The E2 measures 115x115x35 millimeters, is fanless, and runs from Compact Flash storage. It sports a 500 MHz VIA processor, 1GB of RAM, and comes with VGA, Ethernet, PS/2, audio-in, audio-out, and three USB ports packed onto a ruggedized aluminum enclosure. The case has screw mounts designed to match the 10x10 centimeter VESA plate on the backs of most LCD monitors, allowing for an even smaller desktop footprint.

The company sent two Compact Flash cards with its review unit, one containing a standard Debian Etch installation, and the other Aleutia's customized version of Ubuntu 8.04 LTS. Other operating system choices are available, including Windows XP, although founder Michael Rosenberg says Ubuntu accounts for the overwhelming majority of customer selections.

The base model that I tested retails for £199; options adding a Mini PCIe WiFi module or hard disks are available at additional cost. If you opt for the WiFi model, be prepared to either load a binary blob or to work with NDISwrapper; the card included is a VIA VT6655, which is supported by VIA-built closed drivers only. Alternatively, the Mini PCIe slot is unused in the base E2 configuration, so any other card of your choice is an option. The graphics situation is better; the onboard video for all E2s is a 32MB VIA CX700, running the openChrome driver.

The Compact Flash card is ready to boot; no installation required. It uses the GNOME desktop environment and a customized suite of applications, including several not common to vanilla Ubuntu, such as the Mozilla-based Songbird audio player, Mozilla Seamonkey, and MPlayer, which Rosenberg says provided the best playback performance of the available free software video players. There are also applications from the proprietary world, such as Skype, Picasa, and Google Desktop. A local mirror of Wikipedia is included as a reference, containing 4,625 articles.

Apart from these supplementary applications, however, the system is a full-fledged Ubuntu installation, capable of downloading updates through the project's official APT repositories. Rosenberg explains that the company went with the 8.04 LTS release for stability's sake on behalf of the units in the field, and that his team continues to track Ubuntu development as well as other Linux variants.

Considering the E2's low power profile, I was surprised by some of the application selections, such the inclusion of OpenOffice over the much leaner Abiword, and Seamonkey over Firefox. Songbird is an interesting project in its own right and I find it impressive in a number of ways, but it consumes far more memory than many simpler music players. Google Desktop is a CPU drain that I have never found to be worth the trouble.

At 500MHz, the E2 will strain to perform some processor- or graphics-intensive tasks. I found video playback choppy, although audio playback and Skype were flawless. Saving files to flash storage is predictably slower than writing to a hard disk, but the difference is only discernible on multi-megabyte data like downloaded audio or video. The E2 is easily capable of handling Internet and office tasks like you would expect in the classroom or in an Internet cafe. The 8 watts of electricity it consumes is roughly five percent of the power drawn by a typical desktop computer; if you did not know it was specially-engineered to be green, you might well mistake its performance for a traditional PC one generation or so behind the curve.

Video performance and write speed are two particulars that the company is taking specific steps to improve as it continues to tweak the E2's system configuration. Many of the tweaks Aleutia incorporates to improve E2 performance originate with the ever-increasing pool of Linux netbook hackers. The platforms face similar issues: flash storage of limited capacity, low-speed (by desktop standards) CPUs and graphics processors, and limited RAM.

Rosenberg chronicles the effort on the corporate blog, noting changes such as the adoption of the lightweight Fluxbox window manager to replace GNOME's default Metacity, filesystem tuning, and accelerating Firefox by storing the browser cache in RAM instead of writing it to flash storage. The team has recently been experimenting with supplanting GNOME itself with LXDE, although Rosenberg confides that the system is not yet stable enough to ship to customers. It is a promising alternative, though, as Aleutia has demonstrated that an E2 running LXDE is capable of playing video smoothly at full-screen.

Speaking of netbooks....

Despite the E2's obvious benefits from a power consumption and space perspective, once you add on the cost of a display and I/O hardware, the E2 is also similar in price to a midrange netbook -- without the portability. Thus one might well ask how Aleutia sells the E2 as a better value. Rosenberg's answer is that the E2 is designed to outperform and outlast the expensive Dell and HP Windows boxes that dominate education channel sales in developing countries, particularly in Africa. In that context, of course, a netbook's small screen and keyboard are a disadvantage. Furthermore, the E2 is designed to be easily serviced by local resellers -- a problematic board can be pulled out and replaced in a matter of minutes, unlike the more complex beige boxes.

Still, considering Aleutia's stated goal of catering to underprivileged schools, comparisons to one other high-profile effort are inevitable: One Laptop Per Child (OLPC). Like OLPC, Aleutia is targeting its machines at schoolhouses in underdeveloped parts of the world -- but, unlike OLPC, Aleutia is attempting to stay profitable.

The company highlights two differences between itself and the OLPC project. First, it operates as an open-to-all manufacturer. OLPC's XO laptops are available only to national governments, through specially-negotiated contracts. Aleutia can and does sell E2s in any quantity to any buyer. Second, Aleutia warranties its devices for three years and offers support and repair services. When OLPC has offered XOs to the general public through "Give One Get One" programs in the past, the laptops came with a 30 day warranty and no support.

The company appears to be making its case to business and schools. It currently has resellers in six countries outside the UK, and has made sales to 37 others. Rosenberg says he just shipped a classroom set of E2s and LCD monitors to a school in Musoma, Tanzania, where they await clearing customs before they can be installed. At this point, he adds, the main hurdle Aleutia faces is marketing against the billions of dollars spent each year by the larger manufacturers.

"Typically, our customers find us through blogs or just searching on Google. Internet access is much more expensive in Africa so often it's a question of [expatriates] or volunteers finding us in the UK and then putting us in touch with prospective customers back in Africa." The Musoma sale was just such a case. "The headmistress had seen the pair of E2s at the school we have case study for, contacted our local reseller, and spent the bulk of her annual budget to set up this ICT lab."

The state of the art changes fast, and development continues on successors to the E2 hardware -- including the possibility of mesh networking and optical drives. Whatever the next model looks like, though, it will build on the E2's tradition of desktop performance at remarkably low power consumption, a feat that would not be possible on a closed system.

Right now, the E2 would not replace a typical Linux hacker's primary workstation, but for a less demanding usage scenario it is worth considering. The low profile, minimal power draw, and rugged construction make it viable in conditions beyond those suitable for a traditional PC. And as Linux continues to evolve on low-power platforms, you can be sure its advantages will only increase.

Comments (33 posted)

Much hot air over blinking cursors

...that the request for objections would yield few responses. What ensued instead was a lengthy discussion (to put it charitably) which made it clear that some users value their by-default blinking cursor far above any other considerations.

Blinking cursors have been targeted by developers concerned about power consumption for some time now. Every transition requires that the system wake up to make the cursor change, and wakeups increase power usage. Beyond that, though, Matthew has written a graphics driver patch that allows the system to put the graphics processor into a sleeping state as well - as long as the screen does not change. Once again, every cursor transition requires powering up the GPU; that is where much of the excess power usage comes from.

This power savings comes at "idle" times, so some detractors pointed out that, on most systems, the screen saver will quickly power down everything when the system is idle. But "idle" in this context means something different: it describes times when nothing is being drawn to the screen. Such periods of idleness come about, for example, during each of your editor's frequent pauses as he ponders what to write next, what to make for lunch, or whether it wouldn't be better to just drop everything and go for a bike ride. It is a different time scale than the screen saver operates on. Idle displays will not come about if frequently-updating applications are running, but, otherwise, it's a common occurrence even on systems which are nominally busy.

Accurate counts of Fedora installations are hard to come by, but most estimates seem to be in the millions. A two-watt power savings over millions of systems implies a total power savings in the megawatt range. Even if the power savings estimates are way off (and there are those who assert that this is the case), it seems like something worth reaching for. After all, it's a simple default change, and anybody who is truly attached to a blinking cursor can change it back - even if Fedora has helpfully hidden the toggle under Preferences/Hardware/Keyboard in the main menu.

Besides, your editor came to a thoroughly objective conclusion many years ago that blinking cursors are an annoying distraction and that any developer implementing such behavior should be sentenced to ten years of COBOL coding under a strobe light.

The arguments against this change seem to fall into two categories. One of those is that users are unable to find their cursor if it does not blink. For example:

The other argument seems to be along the lines of "but we've always had a blinking cursor." Example:

Numerous other developers have come out in favor of the change. This seems like one of those issues where a full consensus will never develop; so, if this change is to be made, somebody has to just do it despite the flames. It would appear that Matthew has done exactly that. One can only wonder how many more carbon emissions would have been avoided if he hadn't asked for objections first.

Comments (50 posted)

Page editor: Jonathan Corbet
Next page: Security>>