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
I was advised by my bank manager that a lot of small businesses
without large profit margins do not understand how many people try the
"it didn't arrive" trick, and how many small businesses fail because
of this (he quoted numbers like 80% of business failing in the first 3
years, and much higher than that for new remote sales businesses). I'm
not running a traditional business to make loads of money, but I can't
afford to work for free, and lose money on missing stock.
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
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:
Oh, I thought all that was about calibrating a monitor, and not trying to establish a dictatorship.
Maybe you should just get a few beers and rethink what you are trying to
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:
If instead you had some way of "phoning home", you could find who has the
"stolen" device and contact them, telling them to give you your money back
or you will file charges (which will likely be successful). The downside is
it requires net connectivity which may be inconvenient for some uses, and
privacy concerns about phoning home.
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
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,
schematics and code are available, someone suitably motivated could create
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.
ColorHug itself looks like a very nice piece of hardware that fills a hole
for free desktops that the proprietary alternatives can't. We
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)
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 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
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
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
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.
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
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
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.
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)
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:
It would seem that Barnes and Noble is betraying the most sacred of
things in the open-source world, The General Public
License(GPL). As open source programmers we all use the GPL
daily. The GPL is what keeps Open-Source work like the Linux kernel
free, modifiable and re-distributable. I tried to compile the
sources provided by Barnes and Noble, but they are incomplete. They
will not compile.. I'm not the only one, others have tried and
failed as well.
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
It is certainly a reasonable thing for them to want; hackable
devices are, after all, far more interesting and valuable than the
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
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus
any associated interface definition files, plus the scripts used to
control compilation and installation of the executable.
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:
But since the signature is pointless unless you _use_ it for
something, and since the decision how to use the signature is
clearly outside of the scope of the kernel itself (and thus not a
"derived work" or anything like that), I have to convince myself
that not only is it clearly ok to act on the knowledge of whether
the kernel is signed or not, it's also outside of the scope of what
the GPL talks about, and thus irrelevant to the license.
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>>