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 conclusion was:
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 and Toyota 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.
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 development 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.
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.
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.
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.
Page editor: Jonathan Corbet
Next page: Security>>
Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds