Leading items

The ColorHug adds a remote disable "feature"

The ColorHug is an open hardware and software colorimeter that can be used to calibrate monitor screens for color matching purposes. It is the brainchild of GNOME and Red Hat hacker Richard Hughes, who has put in a rather large investment of time and money to get the project off the ground. It was announced back in November and the first 50 units have rolled off the "assembly line", but Hughes is concerned that fraudsters may cause him to lose money by claiming they didn't receive ColorHugs that he shipped. To combat that, he turned to a technique that many may find surprising: the capability to remotely disable ColorHugs that were reported lost in shipping.

According to Hughes, it was his bank manager that alerted him to the problem of people who order things over the internet and then fraudulently claim that they never received them. Due to a UK "distance selling" law from 2000, Hughes's company is on the hook to refund the £48 selling price even if it has reason to believe that the device actually was delivered. Given that he is funding the company out of his own pocket (and sweat), Hughes wanted some way to deter would-be fraudsters.

What he came up with is a way to remotely disable ColorHugs. If the user runs the GUI firmware update application, it will send the serial number of the ColorHug to a server, which will check it against a blacklist of serial numbers for ColorHugs that were reported lost. If the serial number is on that list, no firmware update will be provided and the ColorHug device will be disabled by setting a flag in the firmware; it will become a free brick, rather than the free colorimeter the scammer thought they were getting.

One might guess that the number of scammers interested in free colorimeters is low, and Hughes essentially agrees, noting that he will likely never use the feature. But he does believe it will act as a deterrent that protects him. The bank painted a fairly stark picture that clearly has him worried:

But, the existence of a remote kill switch—even in the hands of a longtime free software developer who can be trusted not to abuse it—makes some people uncomfortable. It's also unclear that it actually serves as much of a deterrent. It is fairly simple to avoid using the GUI tool, get a copy of the updated firmware from somewhere (like the ColorHug download page), and use the command-line tools to update the firmware. Even a "bricked" ColorHug can be restored by flashing a new bootloader (something any "moderately clever geek" could do, Hughes said). One could also set the serial number to a non-blacklisted value (unlike many other blacklists, the ColorHug blacklist is available for inspection).

One of the obvious choices that would seem to avoid the entire problem is to require ColorHug purchasers to pay for some form of tracked shipping (e.g. FedEx, UPS, or DHL), though even that may be insufficient. There are, evidently, folks out there who will sign for a package using someone else's name then claim the package never arrived. In addition, tracked shipping from Hughes's UK location to other countries can be expensive, on the order of £8-9, which represents a 20% surcharge on the device. It also means that all of the honest customers (presumably the overwhelmingly vast majority) have to pay more to protect against the unscrupulous minority.

For those reasons, Hughes added the remote disable. When he mentioned it on the ColorHug Google+ page, reactions were mixed, which seemed to take Hughes somewhat by surprise. Simo Sorce said "Remote deactivation is a really nasty feature, but beyond that is going to be a major headache to maintain." Kay Sievers was even more blunt:

Others were more understanding. Paweł T. Jochym points out that Hughes is the one with something to lose: "He is working in real world and had to invest his own coin. The risk is his not yours." The deterrence rests on the understanding that the device will be disabled if it is "lost" in the mail, in much the same way that anti-theft signs at houses work, John Tamplin said. He continued with some ideas for more active tracking, but did note the negatives:

Phoning home is not going to be a very popular feature with privacy-conscious users, as Tamplin notes. One might also guess that scammers who actually want to use the device will find ways around the "feature".

There is a real question whether the deterrence will truly be effective. It's not at all clear that casual scammers will even notice the disablement feature; anyone who truly wants a free colorimeter is likely to have the minimal technical skills required to circumvent the problem. In the end analysis, colorimeters are not likely to be ultra-popular much-sought-after devices—we aren't talking about music players, tablets, or phone handsets after all—the resale market will be vanishingly small, so what's the business model for the scammer?

There is also the logistical overhead of tracking serial numbers, ensuring that only the right one(s) get on the blacklist, and so on. The remote disable is not completely risk-free either, and could lead to unhappy customers if something goes awry. Overall, it seems like a very large hammer for a fairly small problem. But, as Jochym noted, it is Hughes's money that is at risk, thus it is his decision to make.

Things like remote disable are generally considered to be "anti-features" that proprietary companies bake into their products, so it's not surprising that some open source proponents would find it to be less-than-welcome on an otherwise open device. But, since the schematics and code are available, someone suitably motivated could create different firmware without remote disable and/or build their own ColorHugs and even market those. Given that Hughes doesn't seem to have a huge profit motive behind this effort, he might just welcome someone else taking on the burden.

Plenty of other devices are sent from the UK without a remote disable feature; many are likely to be in more popular device categories where fraud is a bigger problem than it is in the colorimeter realm. Presumably, those companies are pricing their products with this fraud factor in mind, but Hughes is reluctant to do so because it puts the device "out of the reach of many students" and may push others toward the proprietary colorimeters due to the price.

While it may be tempting to take Hughes to task over this (and some are), it is hard to argue that he should take risks he is unwilling to take—even if those risks seem fairly miniscule from the outside. Those who would like a colorimeter, but are unhappy with remote disable, can either hack the firmware or the GUI tool—or decide not to buy one. The ColorHug itself looks like a very nice piece of hardware that fills a hole for free desktops that the proprietary alternatives can't. We plan to review it once we can get our hands on one—the first 50 flew off the "shelves" before we could do so. Given the overall openness of the device, and the ability to hack around the remote disable "problem" in various ways, it is really more of an annoyance than anything else—though one that many would argue could and should have been avoided.

Comments (57 posted)

Cinnamon and Razor-qt: A tale of alternative desktops

Despite how often we hear about "the post-PC era," the Linux desktop environment is certainly an active space, churning with more competing projects than ever. Two recent additions to that space are Cinnamon and Razor-qt, which could be described as "alternative DEs" breaking away from the more established GNOME and KDE offerings, respectively. The relationships between the projects are not quite that simple, however, as Cinnamon has plans for retaining GNOME compatibility, while Razor-qt is more interested in producing a lightweight, stripped-down environment.

Cinnamon

Cinnamon is the brainchild of Linux Mint's Clement Lefebvre. The Mint distribution is derived from Ubuntu, but it has set the goal for itself of supporting multiple DEs in parallel. In November 2011, Lefebvre blogged about the upcoming release of Mint 12 and outlined two alternatives that Mint users could expect to see in place of the GNOME Shell environment. One was MATE, a third-party revival of the GNOME 2.x desktop. MATE was started by an Arch Linux developer, but Lefebvre serves as the project's release manager.

The second alternative was the Mint GNOME Shell Extensions (MGSE), which as the name makes clear is a suite of extensions for GNOME 3.2's GNOME Shell. Individually the extensions implement several desktop conventions not available in vanilla GNOME Shell (such as a bottom panel, a window list, and an "applications menu"), and alter some individual pieces of GNOME Shell's behavior, such as window switching.

Although using MGSE restores multiple desktop components that GNOME Shell's critics said they missed from GNOME 2.x, it remains GNOME Shell underneath. In late December 2011, Lefebvre unveiled Cinnamon, which takes the MGSE concept further by replacing GNOME Shell outright. The latest release of Cinnamon is version 1.1.3, from January 2. At the moment the code is officially available as 32- or 64-bit Debian packages (in addition to source hosted at the Linux Mint GitHub site), while third-party RPM packages have been contributed for openSUSE and Fedora.

1.1.3 picks up where MGSE left off, not only providing the bottom panel, applications menu, and window list features, but beginning the process of removing GNOME Shell components that the project considers unsatisfactory. The GNOME Shell "Applications View," which is the search-based interface to a system's installed applications, is the first to go. The Applications View is one of the two overlay modes triggered by activating GNOME Shell's "Activities" screen; since Cinnamon provides menu-driven access to applications, the Applications View is redundant.

On the other hand, at present Cinnamon retains the Activities screen's other mode, the "Windows" switcher, although it makes several alterations. The tab key cycles between individual windows rather than applications (which only results in different behavior for multi-window applications), and each window is stamped with its application icon. Cinnamon also adds a "Themes" overlay mode to the Activities screen, which allows the user to switch between any Cinnamon themes stored in ~/.themes. However, the entire Activities screen can be disabled by editing a dconf key.

The bottom panel is similar to GNOME 2.x's, though it uses GNOME 3 technology to provide easier right-click editing of launchers (such as the "Add to panel" option found in GNOME Shell). The applications menu, though, is a departure from upstream GNOME 2.x, and reflects the customized, multi-column main menu offered by earlier Mint releases. There are also a number of smaller changes, such as tweaks to the placement and duration of notification messages, a smaller default font size, and miscellaneous changes to the behavior of some default panel applets. Cinnamon supports multi-monitor setups, but like GNOME Shell, it has some kinks to be worked out (as users are reporting on the Mint forum).

The rationale stated for developing Cinnamon includes a number of factors: making the computer "work for you," making things "not hidden away but easy to access," and making you "feel at home ... thus giving you the ability to change the way the desktop works, looks and behave." Of course, several of those factors are uniquely personal, so it is hard to quantify what they mean in a general sense. As a result, the other way most people describe Cinnamon is that it re-implements the GNOME 2.x desktop using GNOME 3 technology. When you consider the changes to the applications menu and panel applets, that is not quite true — in fact, what Cinnamon re-implements is Mint's customized version of GNOME 2.x. If you are an Ubuntu or Fedora user, you may find that it requires some getting used to.

A bigger problem is that since the release of GNOME 3.2, a lot of GNOME Shell extensions have starting popping up, as has an "official" extensions web site. But as of today, Cinnamon is not compatible with other GNOME Shell extensions, which is probably not too surprising. A developer on the forum cites Lefebvre as saying he wants to make Cinnamon configurable without the need for extensions; nevertheless there are users who are clearly interested in using add-ons that originate elsewhere. That lack could hurt Cinnamon's adoption among non-Mint users. Another risk is what Jonathan Corbet described in his predictions for 2012: between MATE, MGSE, and Cinnamon, Linux Mint is taking on a lot of development work for a small distribution — it may fare well, but it may also hit the wall.

Razor-qt

While Cinnamon is only attempting to replace GNOME Shell (leaving other GNOME platform components untouched), Razor-qt is an attempt to build a new DE entirely, providing a lightweight computing environment based on the Qt framework. In that sense, Razor-qt is analogous to Xfce or LXDE, which build on GTK+ but do not use most GNOME platform technologies. Razor-qt provides a basic DE without depending on KDE libraries — most notably the Plasma engine on which KDE's desktop, panel, and widget system are based.

Razor-qt was started in 2010, but development picked up after the project migrated from SourceForge to Github in July 2011. The latest release is version 0.4, which dropped on December 12. In addition to the sources available through Github, there are package repositories provided for Ubuntu, Fedora, OpenSUSE, Arch Linux, and Agilia, along with ebuilds for Gentoo. The dependencies are few, including Qt4 (no more specific notes as to which version), X, libudev, and libmagick.

The Razor-qt environment is lightweight, perhaps even spartan, but slick. It provides a panel (configurable for either top or bottom placement), a system menu, and a collection of essential panel applets (clock, window list, system tray, etc.). It does not include a window manager, but it is capable of cooperating with "any modern WM from fwwm2 to KWin" — although the project developers recommend Openbox. The project also recommends an assortment of Qt-based applications to flesh out the system, all of which also come without KDE dependencies.

At first launch, Razor-qt asks the user which window manager to use. Razor-qt relies on other components for things like drawing the desktop background and desktop icons, so some of the desktop look will depend on which window and file managers are being used. If GTK+ options are chosen, those tools may not quite match the Qt look-and-feel of the rest of the environment. The 0.4 release advertises its support for Freedesktop.org's "XDG" cross-desktop standards (which it implements in a reusable qtxdg library). It seems to observe the XDG base directory, menu, cursor theme, icon theme, and .desktop launcher specifications — through the window manager it also picks up support for other useful specifications, such as drag-and-drop.

The result is a desktop environment that is more-or-less usable for everyday tasks, although there are still missing and incomplete features. For example, there is a screensaver plug-in, but it only supports locking the screen by clicking on a panel button; there is no automatic time-out. Settings are divided up between two applications, one for the desktop and one for the session, but neither contains font preferences, widget themes, or several other categories one might expect. Still, the set of bundled utilities continues to grow — it now includes a clipboard, keyboard manager, and battery status applet, all of which are still listed as third-party add-ons on the applications wiki page.

Razor-qt works with multiple monitors. As it does not implement the "overlay" effect that GNOME Shell, Unity, and Cinnamon use to bring up the window switcher or application search functions, there are fewer bugs reported in relation to its multi-monitor support. Current support is basic, but there are feature requests asking for enhancements.

Razor-qt is also commendable for providing API documentation, even at such an early stage in its development. The documentation includes references for the DE's XDG implementations and for its original desktop environment and session classes. That will no doubt come in handy for attracting new contributors.

It is hard to go into much more detail about Razor-qt's environment, because it is (quite intentionally) so simple. The project's home page gives "simplicity, speed, and an intuitive interface" as its goals, along with the ability to run on "weak machines." It does the job without fanfare. The GTK+-based lightweight DEs offer a more complete package at the moment, but they have a considerable head start as well. The Qt framework encompasses more than GTK+ does, so as the project progresses, it is reasonable to expect it to catch up, without piling on too many additional dependencies or custom libraries.

Conclusion

There seems to be an implicit "should we switch?" question behind most of the blog reviews published about Cinnamon, Razor-qt, and other alternative desktop projects. The short answer is "no," of course: both are still very wet behind the ears, which means missing pieces and instabilities. The more interesting question is what each of the projects means for the Linux desktop ecosystem. Neither has a firm roadmap published, but there are potentially interesting implications to both projects.

First, with the arrival of Cinnamon, hopefully it is clear at this point that GNOME users' criticisms about GNOME Shell cannot all be dismissed solely as "fear of change." The extensions community and all-out forks like Cinnamon implement specific feature changes (application menus, window lists, relocation of the clock and notifications) unavailable when GNOME Shell debuted, and hopefully they will be accepted (even if not adopted as defaults) by the upstream developers. The usability concerns about "large screen" desktops versus "small screen" tablets are not quite as easily solved, but if no one tries then no progress is possible. Cinnamon's existence clarifies that someone can like GNOME 3 technology, but still make a valid argument that there is more than one way to implement a usable desktop with it.

Razor-qt, for its part, offers application developers the tantalizing possibility of clarifying the distinction between KDE and Qt, which are too often confused by users. Simply providing users with another choice — and in this case, a substantially different one than Xfce and LXDE — is empowering to those users, but it can also serve to push the Qt project ahead. The qtxdg library is one example, and probably will not be the last. On top of that, additional platforms equal more testing, and as Qt makes a play for embedded devices, the more diverse its ecosystem, the better it will do.

Comments (13 posted)

The Nook Tablet and the GPL

Recently, certain corners of the net have carried the claim that Barnes & Noble is refusing to release the source for the kernel shipped in its "Nook Tablet" book reader device. That, of course, would be a violation of the kernel's licensing. GPL violations are far from unheard of in the mobile electronics market, but B&N is a company with a high-enough profile to attract special attention. A look at what is going on suggests that there is less to the story than meets the eye - but it still merits a look.

The big fuss was made on the XDA developers forum, where many Android-related conversations are hosted. There, Adam Outler claimed:

He also claims that B&N has been deleting requests for the source from its own forum sites.

In truth, B&N has made the kernel source for its Nook devices available - though some prodding from Matthew Garrett was required to get that to happen. One can find it by scrolling down on the Nook "terms of service" page. Matthew believes that source distribution to be complete - or something very close to it. His position is that B&N appears to be living up to its obligations under the GPL at this time. Some XDA developers still disagree with this assessment for one simple reason: it is not actually possible to build a replacement kernel for the Nook (specifically, the "Nook Tablet" variant) using the source provided. Like many consumer electronics devices, the Nook Tablet is locked down and will refuse to boot a kernel that lacks a signature that it recognizes. What the XDA developers want is a signing key that will allow them to build kernels that are actually bootable on the device. Without that key, they say, the kernel sources are incomplete and useless.

It is certainly a reasonable thing for them to want; hackable devices are, after all, far more interesting and valuable than the locked-down variety. There is a difference, though, between wanting something and claiming that somebody is obligated to provide it to you. Whether B&N is obligated to provide that key is far from clear. The relevant GPLv2 language is this:

Many developers have, over the years, claimed that a signing key qualifies as one of the "scripts" referred to in §3 of the GPL. Even if the license does not explicitly say that it must be possible to build and install an executable that the hardware will actually deign to boot, that requirement is arguably within the intent of the license.

Version 3 of the GPL added language to make this expectation explicit; in most cases, it is not possible to use GPLv3-licensed code in a device if that code cannot be updated by the user. But the Linux kernel is not covered by GPLv3, and, more to the point, the discussion around GPLv3 made it clear that a significant portion of the kernel development community does not wish to limit the use of their code in this way. The "kernel developers' position on GPLv3" document posted in 2006 was explicit on that point. Linus Torvalds made his position clear on the issue well before the GPLv3 process even started:

Of course, the actual meaning of the language in the GPL is not determined by Linus or any specific group of kernel developers. That, in the end, can only be definitively done in a court, and, even then, clarity can be hard to come by. So it is conceivable that, someday, some developer could pursue a case against a company like B&N and prevail, forcing either the release of the signing key or the removal of the product from the market. Such an outcome, needless to say, would cause a number of manufacturers to reevaluate their use of Linux in their products.

That outcome seems unlikely, though, for one simple reason: Linus and a number of other high-profile developers have, through their statements and rejection of GPLv3, made it clear that they see locked-down systems as a permissible use of the kernel and in full compliance with its license. Such signals carry a lot of weight in arguments before a judge, who will be reluctant to rule that a vendor cannot do what the developers of the kernel explicitly said was allowed. Anybody seeking such a ruling will be fighting an uphill battle from the outset.

Saying that the license allows certain behavior is not a statement that such behavior is a good thing. But that is the nature of free software: it is not truly free if it cannot be used to do something the author disagrees with. Once code is released under a free license, it can be used for any number of distasteful things, including running criminal organ-harvesting rings, controlling land mines, tracking people the government doesn't like, or sending "join my social network" email. It can also be used to implement unpleasant DRM schemes on a locked-down ebook reader. That is simply part of the loss of control that comes with making software free.

In some parts of the market, it has become clear that an open platform is a competitive advantage; see HTC's policy of not locking down the boot loaders on its handsets, for example. Barnes & Noble is engaged in a difficult fight against companies like Amazon; as Charlie Stross so clearly stated last year, an insistence on using DRM is just making that fight harder. The push for DRM seemingly comes mainly from the publishers, but pushback from retailers like B&N could force some change there. So one could easily argue that B&N should stop locking down its readers, not because of licensing problems, but because it makes more commercial sense not to.

Comments (76 posted)

Page editor: Jonathan Corbet
Next page: Security>>