Recently we have seen a small series of articles (example
in the press suggesting that contributions to open source projects are in
decline. If that were truly the case, it would certainly be a cause for
concern; our community lives or dies based on contributions of code,
artwork, documentation, and more. If the stream of contributions is
falling off, our future is in doubt. The good news is that the rumors of
the death of our community are somewhat exaggerated.
The source for much of this speculation would appear to be the
results of a survey of the Eclipse community published in June. This
survey led to a number of interesting conclusions; for the curious, the
results are available as a
report [PDF] or in
an ODS spreadsheet. One can learn a lot about the Eclipse user
community there; some of its members, evidently, still develop in RPG. Most of
them, though, have moved on to more current technology.
Among the conclusions drawn from this survey were that developers are
increasingly using Linux as their desktop system, openJDK adoption is on
the increase, git usage is on the increase (to a massive 7%; 58% of
respondents still use subversion), and that open source participation
"seems to be stalled." The reasoning behind that last
In the survey, we asked a question about the corporate policies
towards open source participation. In 2009 48% claimed they could
contribute back to OSS but in 2010 only 35.4% claim they could
contribute back. Conversely, 41% in 2010 claimed they use open
source software but do not contribute back but in 2009 it was
27.1%. Obviously not a trend any open source community would like
Poking holes in this conclusion is not a particularly difficult task. The
survey covered Eclipse users, not the open source community or the
corporate space as a whole. It asked about policies, but the respondents
were mostly developers and designers who may not know what the company's
policies really are. Less than 1,500 people responded to the 2009 survey,
while nearly 2,000 responded to the 2010 survey, so they are not comparing the
same group of people. 41% of the responses came from France and Germany, a
proportion which might (or might not) be representative of the Eclipse user
base, but which certainly is not representative of the community as a
whole. And so on.
Looking at the survey, one could easily conclude that the Eclipse user
community is growing; as it grows, it attracts companies that are
relatively new to free software. These companies will naturally contribute
less than those which have been comfortable with free software for some
time. That conclusion is, of course, an exercise in hand waving, but it
somehow seems more plausible than the idea of a wave of anti-free-software
policies - not seen elsewhere - taking over the corporate world.
As a whole, our community does not appear to be in decline. We have no
shortage of healthy projects with active contributor bases. Once upon a
time, creating a single full-featured web browser looked like a nearly
insurmountable challenge; now we have several of them. One can look at
compilers, desktop suites, database managers, or point of sale systems; we
have multiple vigorous competing projects in each. Sites like github can spring from nowhere and find
themselves hosting millions of repositories in just a few years. In a
community with this much activity, coming up with any good understanding of
changes in participation rates will be hard. But one does not have to look
for long to realize that things can't be in any particularly bad shape.
In this context, it is interesting to look at the last couple of press
releases from the Linux Foundation; the LF has announced that LexisNexis
have become members - Toyota as a Gold member. LexisNexis also released its high-performance clustering system
as free software. Neither of these new members can be thought of as a
traditional information technology company, but both have found it in their
interest to support the development of Linux.
That looks like the future of open source participation. Software
companies have, for the most part, been working with our community for some
years now. Most computing-related hardware companies are also
contributing; there are signs that at least one of the big remaining
holdouts will announce a change of policy before the end of the year.
Companies like Volkswagen started contributing
to Linux as far back as 2007. Increasingly, we are seeing interest
from financial service companies, traditional manufacturers, and beyond.
Being part of the free software community is not just for software
companies anymore, and that is a good thing; it suggests that we'll not see
a real decline in participation anytime soon.
Comments (5 posted)
There was a period of time when it seemed that Internet Explorer was set to
be the only web browser with any significant presence; Linux users looked
to be doomed to a barely-supported web life using niche browsers. The
success of Firefox saved us from that fate; for a while, it seemed that
Firefox was set to take over. But the situation is more complicated than
that; now the press is talking about the rapid rise of Google's "Chrome"
browser. Your editor, having not seriously messed with Chrome/Chromium for some
time, decided to experiment with using it full-time for a while. The end
result: Chromium is a capable tool with only a few annoying glitches.
Discussions of Chrome tend to run into confusion based on the fact that
there are actually two related browsers. Chromium is an open-source
(BSD-licensed) project, while Chrome
is a binary-only program available for free download. Chromium is the
upstream for Chrome; they differ in that Google adds a bunch of proprietary
stuff (Flash player, PDF viewer, codecs), an automatic update system, and a
more colorful logo to Chrome. Both browsers are available for a number of
Linux distributions. Anybody wanting a fully-free system will naturally
stick to Chromium.
For a user moving to Chromium from Firefox, there is, at the outset, little
in the way of culture shock in store. The Chromium developers seem to have
put a great deal of work into making that transition easy. Chromium will
pick up a lot of information from an existing Firefox installation,
including bookmarks, browsing history, passwords, and more. (As an aside,
it's worth noting just how easily Chromium can get its hands on the Firefox
password store; any other program can do the same). The appearance
is quite similar, and many of the keyboard shortcuts are the same. After a
while one begins to notice little things that are missing (the combination
of shift and the scroll wheel to move through the history is at the top of
your editor's list), but it mostly just works.
Firefox makes a huge variety of configuration options available to users;
Chromium has a rather smaller set. Most of the important things are there,
but, once again, anybody who has made extensive use of Firefox's
configurability will run into annoying gaps. At the top of the "pet peeve"
list here is the lack of any ability to control animated images. Your editor is
an easily distracted type; text is much harder to read when there are
images jumping around on the screen. The "animate once" option in Firefox
has always seemed like an ideal compromise; it enables viewing of kitten
animations sent by one's daughter while filtering out ongoing
obnoxiousness. Chromium users have no such feature.
Also missing is any sort of mechanism for associating "helper" programs
with content types. There appears to be no way, for example, to tell the
browser to pass a PDF file to evince or an m3u file to the user's choice of
media player. As a result, Chromium, out of the box, is totally unable to
deal with PDF files; one must install an extension to be able to view them
at all. (Chrome has a PDF viewer built into it). This behavior seems to
be driven by the ChromeOS use case, where the concept of applications
outside the browser is deemed suspicious at best. For a full desktop
system, though, it is limiting.
Extensions for Chromium are not in short supply. AdBlock is there, for
those who want it. On the other hand, the lack of NoScript hurts; the
"NotScript" extension tries to fill that gap, but it's not the same.
NotScript setup is bizarre, requiring the user to hand-edit a file named
and insert a password which, seemingly, is never used again. NotScript
seems to break more sites than NoScript does; the Red Hat bugzilla site,
for example, simply refreshes forever with scripts disabled.
NotScript also breaks Chrome's PDF
viewer unless scripts are enabled for the site hosting the PDF file. There
is (it must be said) no direct equivalent to the Firemacs extension
providing Emacs keybindings; a similar extension failed to work.
Many of these features are apparently harder to implement in Chromium than
they are in Firefox; it seems likely that Chromium's emphasis on sandboxing
and security, along with an attempt to make extensions portable across
releases, may be to blame here.
Various glitches notwithstanding, Chromium is a capable and full-featured
browser. It does appear to be quite fast, though Firefox's speed has
rarely been a problem in recent times. Having done the work to switch over
to this browser and integrate it into his workflow, your editor does not
feel any immediate need to switch back to Firefox.
Chromium is promoted as an open source project, but the community has
learned that Google often sees "open source" in its own unique way. It
would appear, though, that Chromium is actually run like a real open-source
project. The project's code repository contains commits from some 759
developers, most of whom have been active in the last year. Developers
tend to use @chromium.org email addresses, making it hard to tell how many
of them come from outside Google. The project does give commit privileges
to outside developers, though - they are not limited to the
submission of patches. Google must certainly maintain a certain degree of
control over the direction of the project, but Chromium does truly seem to
have a development community of its own.
Despite its free license and growing adoption, Chromium tends to be
supported reluctantly by many
distributors. The project's release cycles are unclear at best,
and its practice of forking and bundling libraries does not sit well with
distributors; see this
posting from Tom Callaway for a long discussion on the disconnect
between Chromium and distributors. Chromium has an
open bug tracker entry on making the project more
distributor-friendly, but it seems to have more cobwebs than
contributions. For reasons that have been extensively discussed over the
years, web browser projects seem to have a
hard time fitting into the distributor ecosystem.
Even so, there are repositories
for a number of common distributions. Some work better than others; the
Fedora repository does not support Rawhide, for example. But just about
anybody wanting to run Chromium without building it (a daunting process
which requires a 64-bit machine just to have the address space to do the
link) on Linux can do so. That said, it's probably a fair guess that an
awful lot of Linux users are running the proprietary Chrome releases. One
should never underestimate the allure of a working YouTube. For those who
would like to take that path, there are a number of "release
channels" with varying distances from the bleeding edge.
To conclude: Chromium is a capable tool which has brought an interesting
new level of competition to the browser space. The project's emphasis on
speed and security are certainly welcome, as is the relatively open (for
Google) nature of the project itself. On the down side, one might well
wonder whether it is wise to put yet another piece of web infrastructure
into a single company's hands. Google's intentions seem to be good now,
but, as we've often seen, companies can change alignment overnight. So
while Chromium is a welcome option to have, it might be best if it does not
take over. The continued existence and success of strong competitors in
the free software community can only be a good thing.
Comments (126 posted)
Chances are, you know someone who has lost a laptop or smartphone, or
had one stolen outright. Although preventing the theft itself would be the
most satisfying outcome, there is little a software developer can do on
that front (although one might consider proximity-monitoring over Bluetooth
to be a step in the right direction). Full-disk encryption and
password-protection for the BIOS are common strategies, but another
approach — device tracking — has never enjoyed a high level of popularity in open source. The Prey project offers one open source device tracking solution, with a small range of options — including self-hosting or using the company's online monitoring service.
Device tracking options
All software-based device tracking systems share one common element: they periodically record data about the machine and its surroundings, including location, IP address, and network settings, or perhaps even a photo taken with an on-board camera. Where they differ is in how and when that information is transmitted to the device owner, and how the application detects whether or not it has been lost or stolen. Some upload their periodically-collected data sets to a remote server on every run, others simply "phone home" to perform a status check, and only record and report information if they get the appropriate signal.
Proprietary solutions like GadgetTrak or LoJack for Laptops tend to rely on a central server run by the software provider, who waits for the device owner to report the loss or theft. The first widely-deployed open source device tracker was Adeona, which took a different approach: it uploaded its reports to a remote storage location at every snapshot period. That eliminated the need to maintain a central database of tracked devices, which is what the proprietary companies charged their recurring fees to maintain. Sadly, Adeona is currently offline, as the storage service used, OpenDHT, has been deactivated.
Prey operates more like the proprietary services. The default behavior
is for the Prey script to wake up periodically and make an HTTP request to
a preconfigured URL. The response code sent tells the script what to do next:
a 200 (the "OK" status code) will shut the script down normally. Only a
404 "Not Found" code (which requires making a successful connection to the
web server) will trigger the script's theft response. Prey can be
configured only to send reports about its status and whereabouts, or to
trigger local actions, such as an audible alarm, flashing an alert
notification on screen, or locking the system.
Fork Ltd., the company behind Prey's development, offers two administration options. Users can configure Prey to use the "Prey Control Panel" site as the pre-shared URL, or to run in standalone mode. Control Panel users can configure device-reporting settings and actions through the web site, as well as mark a device as missing (which removes the URL requested by the script's heartbeat-checking routine) and view any reports it sends. Standalone users must manually edit the Prey configuration file, supplying their own heartbeat URL, and provide valid SMTP and email configuration details — in standalone mode, the script emails its reports rather than posting them to the Control Panel server. Fork recently started offering paid "Pro" accounts, which allow simultaneous tracking of more devices and additional configuration options, but says it will always offer free accounts.
The current release of Prey is version 0.5.3, and is available for Linux, Mac OS X,
Windows, and Android. An iPhone/iPad version is presently in private
beta testing. On Linux, the application itself is a collection of Bash
scripts and support files (such as the audio file played as an alarm). The
source bundle can be installed on any modern distribution, requiring only
the set up of a cron job to run the main script at the desired interval.
It depends on cURL to make its HTTP requests, the streamer utility from xawtv to capture webcam
images, and Python to run a small GUI configuration tool. There is also a
Debian package available on the download page, which is compatible with Debian and Ubuntu distributions.
The actual setup process is simple, but the Prey project's web site
suffers from severe documentation drought. There are no step-by-step
guides suitable for new users (much less for configuring Prey in standalone
mode): the necessary information is split up between the README file in the
code bundle, the FAQ page, the "Knowledgebase," and the mailing
list. If all you are interested in doing is signing up for the free
Control Panel service, you will probably muddle through without too many
hiccups, but I found it difficult to track down the answers to many of the
questions I would want to know before I embarked on installing it.
For example, the site's splash page, FAQ, and README all discuss adding a "valid web URL" as the means of enabling Prey in standalone mode, but the example they give is a URL on one's own domain or blog. In the prey configuration file, there are no client-side settings to control the actions (alarm, lock, etc.) performed or the data gathered when Prey sends a report — all of which are settings exposed on the Prey-hosted Control Panel site. If you read through the mailing list archives, though, you discover that the URL Prey checks for is intended not merely to return a valid HTTP response code, but to serve up an XML configuration file. There is still no documentation for the syntax and options of the file, but evidently if one first sets up an account with the Prey service, one can download and save the file to then use later in standalone mode.
I would also like to see more thorough disclosure of what machine information Prey sends to the Control Panel server. Because the Prey script makes an HTTP request, presumably a fair portion of the information could simply be gathered from the request headers, but any time an application "phones home" I prefer to see what it is going to say before I install it the first time. After initially adding a device, the Control Panel has a detailed hardware information section disclosing more about the system configuration than I generally like strangers to be able to access. For non-Pro accounts, the connection to the Control panel site is not sent over SSL, which makes it vulnerable to eavesdropping. There are scattered references to Prey using Amazon S3 to store its webcam report snapshots, rather than sending them directly to the Prey site, but here again the documentation is sparse.
From a user standpoint, though, Prey works quite well. On Linux, the
Bash scripts run with root privileges, which might concern those of a
high-security mindset. Prey can gather an impressive set of information about your machine for the reports it sends back if the machine goes missing. In addition to webcam snapshots and the standard geolocation and WiFi-triangulation options, it can complete a traceroute, capture a desktop screenshot, log any recently-modified files, and log running applications.
The Control Panel interface is easy to understand, with newbie-friendly
explanations of the various settings and options. Even the setup tool does
a good job of outlining the difference between Control Panel and standalone
mode. I am not sold on the value of playing an MP3 alarm file, but the
ability to lock down the currently-running session (with
password-protection) is a necessity when dealing with theft. The Prey team
also deserves kudos for explaining the value of encrypting the hard disk
and password-protecting the BIOS; those measures may be the only means to prevent attackers from wiping a machine entirely.
If you are not patient enough to wait until someone steals your laptop, you can dry-run Prey by running the /usr/share/prey/prey.sh script with the --check option. This will test the network connection, the crontab entry, and the validity of the API key and device ID for your hardware. Testing actual report generation is harder; for non-pro accounts the only option appears to be marking your device as "missing" in the Control panel interface.
Prey forward technologies
Taking a look at the configuration file (which on Linux systems is installed at /usr/share/prey/config), there are some tantalizing options that do not yet seem to be active in the 0.5.3 code, including SSH tunneling and SCP/SFTP file transfer, both with support for RSA key-based authentication instead of passwords. There are also some experimental options for modifying the HTTP request in order to get around firewalls and other attempts to block Prey. Here, too, my hope is that we will see further details documented on the site, rather than have them buried in the comments of the configuration file alone.
One final concern for potential Prey users is whether the three-device
limit imposed on non-Pro accounts is genuinely enough. Even a single
individual is likely to hit the three-device limit these days, and although
each member of a family could set up his or her own Control panel account,
I suspect that in most families a single family member will end up bearing
the burden of keeping tabs on the portable electronics. The limit will, of
course, help sell Pro subscriptions — or push users into setting up
their own standalone server.
To me, that makes the need for better documentation of standalone mode configuration all the more important. While an enterprising developer could craft a homemade equivalent to the Prey Control Panel and serve up a valid XML file to clients, all indications are that the Prey project wants to operate as a true open source citizen — the source code is available on GitHub and the mailing list is public. It just has a little bit further to go.
If you are looking for an open source alternative to the proprietary device tracking products on the market, Prey is worth examining. Because it is based on standard Linux system tools, it ought to run on any distribution — perhaps even including Maemo and MeeGo handsets, although they do not have Bash installed by default. You just might have some hoops to jump through if you are intent on running your own device-tracking server.
Comments (22 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: A decline in email spam?; New vulnerabilities in bind, NetworkManager, qemu-kvm, xen, ...
- Kernel: poll(); Seccomp filters: No clear path; CMA and ARM; Deferred driver probing.
- Distributions: DoudouLinux: You know, for kids; ConnochaetOS, Ubuntu, ...
- Development: Gawk 4.0.0; Open hardware license, Mercurial, Notmuch, systemd, ...
- Announcements: Project Harmony 1.0, Nortel's patent pile, ESA SOCIS, lca CfP, ...