Your editor, being the grumpy, older sort that he is, must confess that he
has never quite understood the allure of services like Twitter.
140-Character broadcasts look an awful lot like a combination of the worst
features of cellular short messaging and Usenet; it's conversation via
bumper sticker. A local disaster recently pushed your editor to spend more
time on the site; what follows are some observations, somewhat
tenuously tied to the world of free software.
While grumpily working through the US Labor Day "holiday," your editor
noticed that the sky, as seen through the basement window, had turned a
rather sickly shade of orange; the smell of smoke followed shortly
thereafter. Drawn away from the keyboard for a quick look, your editor
could not miss the fact that a large fire was burning in
the hills to the west. While Colorado does not do forest fires on the
scale of places like California (actually, we don't do anything on a
Californian scale), wildfires are still a serious threat. When the sky
fills with smoke, it's natural to want to know what's going on.
What was going on is now known as the "Fourmile fire"; it burned something
like 6600 acres (2600 hectares) of heavily-populated foothills and
destroyed over 160 homes. Definitely worth knowing about.
Unsurprisingly, the local newspaper's web site was not particularly
illuminating. Neither were the television stations. In these situations,
TV can be counted on to show impressive videos of slurry bomber runs and
burning houses in the
evening, while the newspaper provides still photos from the same videos the
next morning. The local community radio
station was a bit more helpful, but, when disaster strikes in one's
neighborhood, it's hard to have too much information. In desperation, your
editor went to Twitter and typed in "boulder fire."
The results were interesting; the Twitterati were already well engaged in
conversation about this emergency. People were reporting their observations and
posting pictures from various locations. Evacuation orders were being
relayed through the site; given that the local "reverse-911" phone
notification mechanism failed outright, it's possible that some people
learned of the need to flee their houses via Twitter. A local journalism
professor was listening to police and fire radio traffic and posting the
interesting parts. Information on evacuation centers and shelters for
large animals (horses, for example) was broadcast. The destruction of a
fire truck was reported. All within the first hour or so.
In other words, Twitter was carrying a great deal of useful information
which was available nowhere else. It was enough to keep your editor
hitting that "NNN more tweets since you started searching" link over and
That said, this information was not as easy to get at as one
might like. The signal-to-noise ratio was quite low for a number of
reasons, the first of which appears to be an artifact of how "routing" is
handled in the Twitter environment. The "follower" relationships lead to a
strange topology made of vast numbers of one-way links; one can only
broadcast a message to those who have created inbound links. So Twitter
appears to have reinvented the old Usenet flood routing mechanism, but
without the "I've already seen this" feature. This mechanism, called
"retweeting," comes down to people continually rebroadcasting anything that
they found interesting.
The result is a huge amount of duplicated content, perhaps with a trivial
comment tacked on to the end. After a message has gone by 100 or more times
(literally), it just isn't quite as interesting as it was the first time.
But everybody somehow still feels the need to retweet it for the benefit of
those people who hadn't yet caught on to the
#boulderfire hash tag. This process goes on for a very long time;
messages which were only relevant to the early stages of the fire were
still circulating days later.
Beyond that, much of what was posted was not particularly useful. Quite a
few people felt the need to get into the limelight with "that #boulderfire sure
sucks" posts. Local construction companies wanted to be sure we all knew
that they are available for the rebuilding of destroyed houses. We were
all encouraged to send texts to various numbers to donate money which, they
promised, would go to fire victims. Local TV stations assured everybody
that they had the best slurry bomber videos. There was also a significant
traffic in posts about how all this demonstrated "the power of Twitter."
A community of this size - even this sort of temporary community - must
necessarily contain at least one troll and at least one nutcase; it's
written in the
laws of physics somewhere. The #boulderfire "channel" did not disappoint
on this score, though many of the participants were quaintly surprised by
the presence of these people. The troll was shouted down with impressive
efficiency. The nutcase, seemingly representing a local "news" outlet, was
able to sustain a regular stream of posts about discoveries of charred
bodies (there were actually no serious injuries) and said news outlet's
refusal to bow down to the "Twitter police."
Need it be said that all of this stuff was mercilessly retweeted dozens of
In summary, maybe one message in 50 was both original and
interesting. That reduces the value of the channel considerably. For
added fun, the journalism professor was blocked as a spammer, while the
actual spam continued, seemingly unimpeded.
Identi.ca is meant to be a
free-software-friendly alternative to Twitter. Naturally, your editor had
to wander over there to take a look. The good news is that the massive
"retweet" traffic was absent; the bad news is that most of the useful
traffic was absent
as well. Information was sparse at best, and, in general, it seemed
more heavily spam-laden than what was found on Twitter; one gets the sense
that there is a budding industry in setting up pages allegedly related to
breaking news and posting links to social networking sites. In summary:
identi.ca was not a useful resource for anybody who wanted to learn about
why they were breathing smoke thick enough to obscure the view of the
monitor from the desk chair.
One might argue that it is a matter of network effects; people post to
Twitter because that's where the readers are. Your editor would respond that
this situation is unsurprising: identi.ca looks an awful lot like a
taillight-following exercise. It may serve as a useful demonstration
platform for StatusNet, but it offers no real reason for Twitter users to
switch. "Source available" is not a compelling feature for most of these
users, and identi.ca lacks anything else which is sufficiently shiny to
motivate them to change. In this setting, at least, identi.ca was not able
to offer a competitive service.
That said, your editor is still not a Twitter user. The fire is mostly
controlled, so attention has returned to less noisy information sources -
linux-kernel, for example. The value of Twitter is a little more
clear, but what is really clear is this: there must be room to do broadcast
messaging in much better ways. High-quality information about unfolding
local disasters may be a bit of a limited use case - though it's one most
of us are likely to want at some point in our lives - but the simple
"what's going on?" question is more broadly applicable. If we, the free
software community, could come up with a messaging platform which was less
noisy, less subject to manipulation, not centrally controlled, and more
efficient in getting news to all interested listeners, we would have
something worth tweeting about.
Comments (53 posted)
Recent discussions on
the GCC mailing list have made it clear that Apple won't be assigning
copyright to the FSF on its work porting Objective-C 2.0 support to GCC
compiler. Apple has
published its changes, but has not assigned copyright to the Free Software
Foundation (FSF) or pushed its changes to the FSF server for some of its
work. We may be seeing the next steps in Apple's apparent plan to move
away from GCC and GPLv3-licensed software in general.
Apple has clearly been working to reduce its dependency on GCC. The
company has been sponsoring work on clang, a front-end for the LLVM Compiler Infrastructure that supports
(at the moment) C, C++, Objective C and Objective C++. The developer
preview of Xcode 4.0 seems to replace
GCC with LLVM and clang.
At one time, Apple was content to build on GCC for its developer tools
and assign copyright to the FSF. What has changed? Apple's use of GCC for
Mac OS X was compatible with the GNU GPLv2, even if the company didn't have
any particular love of the FSF's principles.
The launch of the iPhone and GPLv3, just a few hours apart, put
Apple at odds with the GNU Project. The FSF has noted
that the GPLv3 and iPhone are incompatible. Specifically, the requirement
for apps to be signed to run on the iPhone runs counter to section 6 of the
GPLv3, which says that signing measures cannot prevent apps from running on
a device merely because they've been modified. The FSF has also been
openly hostile to Apple's iPad launch and App Store
as of late. Justifiably so, perhaps, but it's still not the sort of
behavior that will
encourage Apple to be any more cooperative than it has to.
It would appear that Apple is being exactly as cooperative as it has
to. The code is being published under the appropriate license - GPLv2 or
later - but Apple isn't taking the next steps of pushing its changes
to the FSF or assigning copyright as required to be
shipped as part of an GNU project like GCC.
In theory, the GCC project could pluck the changes out of Apple's
sources and integrate them into GCC, but Apple employee and primary author
of LLVM Chris Lattner notes that this
would go against the FSF policy of requiring copyright assignment:
Be aware that none of the changes that haven't been committed to the
FSF trees are copyright-assigned to the FSF. In practice, since the
FSF cares about copyright assignment, this probably means that you can
probably merge whatever is in the apple branch on the FSF server, but
you can't take things out of llvm-gcc or the apple gcc tarballs that
get pushed out on opendarwin.
I'm not a lawyer, so this isn't legal advice, just my understanding
of FSF policies and the mechanics of how the copyright transfer
Richard Guenther points out that
some code in the GCC test suites is not FSF-owned, and that GCC/GJC uses libffi, which has Red Hat as the
copyright owner. Guenther suggests that the steering committee be asked for
an exception to merge the Apple-owned code. This is not, however, an apples
to apples comparison. Steven Bosscher notes that the
test suites and runtime libraries are not part of the compiler itself, and
that the policy has been different for non-compiler components. Further, he
says that the "risk of 'leakage'... would be too big," to
And is it really worth the effort anyway? It may be irritating to some
developers that Apple
will not assign copyright for its contributions to a project that it
benefits from, but is it really a major loss for the GCC project? Bosscher
suggests that it is not, saying that it may hurt the project more than it
helps. "GNU ObjC has so few users that it seems hardly worth the
effort to upgrade the GNU ObjC front end to ObjC 2.0." He also
points out that Objective-C 2.0 is not a documented language standard, and
that Apple's branches may not be the current Objective-C 2.0 that Apple is
shipping. Even if the GCC project were to merge the code, it would likely
be out of step with the most popular Objective-C 2.0 implementation and
chasing a small audience that may not be very interested.
The final word seems to be that Apple has no interest in contributing
the Objective-C changes back to GCC. When asked about a contact at Apple to
discuss assigning copyright to the FSF, Lattner responds that
"Apple does not have an internal process to assign code to the FSF
anymore. I would focus on the code that is already assigned to the
Whether that can be construed as "blocking" contributions to GCC is
another question. Apple's motives may not be pure, but it has published the
code under the license required and it's the FSF's own copyright assignment
policies that block the inclusion. The code is available and licensed
appropriately for the version of GCC that Apple adopted. It might be nice
if Apple took the further step of assigning copyright to the FSF, but the
GPLv3 was not part of the bargain that Apple agreed to when it first
started contributing to GCC.
Comments (18 posted)
Open source enthusiasts who have avoided the popular Dropbox file synchronization service now have one more alternative. The SparkleShare project released its first beta last week, initially for Linux users only, but with most of the feature set already in place. The result is not an exact clone of Dropbox, but it may prove to be more useful for many in the free and open source software circle.
The beta release was announced
on September 4th by lead developer Hylke Bons. SparkleShare comes in a
source code package only, and although Windows and Mac OS X front-ends are
said to be in the works, the code only runs on Linux at the moment. The application is split into two parts — a backend that handles file transfer and synchronization, and a front end that communicates with it over D-Bus. The current front-end is tied in to the GNOME desktop, including a panel icon, notification messages, and right-click context menu extensions for the Nautilus file manager.
The project's blog describes SparkleShare as a replacement for Dropbox, but considering the varied use cases that exist for Dropbox, such a description needs further examination. SparkleShare is specifically designed to enable teams of remote users to share and collaborate together on documents; it is not simply a single-user remote backup service. Nor does it handle concurrent editing; SparkleShare's model keeps a local copy of each shared folder on each team member's hard disk, and sends an updated version of each file to a central storage location when it is saved. It uses Git as its remote storage engine. The current release includes point-and-click support for Gitorious, GitHub, and the GNOME project's repository. An important side effect to note is that SparkleShare is not suitable for storing private data; all files synchronized through one of these public Git-hosting services is accessible to anyone.
The choice to use Git as a storage-and-synchronization service reveals something else about SparkleShare: although it is not intended to serve as a complete distributed version control system (DVCS), it is designed to coexist with one. Specifically, SparkleShare is designed to help user interface (UI), user experience (UX), and graphic design teams to collaborate remotely with each other, and to help them collaborate on projects with software developers. The concept grew out of GNOME's London UX Hackfest in March of 2010. The team is spread around the globe, and wanted an open source alternative to Dropbox — but one that would make it easier to merge their work with that of GNOME coders.
The beta release is designated 0.2 beta 1, and is provided as a tar archive for Linux desktops running GNOME. It is written primarily in Mono, a choice Bons tacitly admits may irritate some people (in the FAQ, he explains the use of Mono with "Because I hate freedom."). Other build dependencies also include NDesk development packages for DBus support, and Nautilus Python bindings. Runtime dependencies include Git itself and OpenSSH. Compilation is the standard ./configure, make, make install three-step.
Once installed, the SparkleShare service can be started from the command line (
sparkleshare start) or from the GNOME menu. When launched, SparkleShare adds a notification area icon to the GNOME panel that holds shortcuts to each configured shared folder and a "sync remote folder" button. At first run, it also creates a SparkleShare folder in $HOME.
Before SparkleShare can be used, however, you must connect it to one or more shared Git projects on one of the supported services. The first-run screen allows you to select the service you wish to use and specify the remote project name used; it identifies the user account associated with the service by auto-generating an SSH key in the background using the full name reported by the operating system for the active user account.
The online documentation provides step-by-step instructions for Gitorius and GitHub — presumably those using GNOME Git or their own public Git repository will be able to figure out the steps through extrapolation. If you do not already have one, you must register an account at GitHub or Gitorious through the services' web sites and set up a project. You must then find and copy the auto-generated SparkleShare SSH public key and paste it into the Git-hosting service's account settings page in order to authorize access. SparkleShare allows you to link each individual project that you set up to a separate folder within your local SparkleShare folder — so you can mix and match project folders from different services and you are not required to use SparkleShare for every project that you host at one of the supported sites.
As of today, setup is not entirely point-and-click. It would be nice to allow users to register new accounts at one of the supported Git-hosting sites from within the SparkleShare client; more importantly, it would be nice to simplify the SSH public key configuration process (which requires a terminal window) and to allow users to create a new Git project (shared folder) from within SparkleShare, as this is likely to be a repeated process.
Once configured, however, SparkleShare is simple to use. Files copied
to the ~/SparkleShare/someproject/ folder are preserved locally
and silently mirrored to the Git-hosting service in the background. You
can check the logs online to see timestamped commits and pushes, and when a
file is updated remotely by another share user, a notification bubble
announces it on the desktop, complete with the user's name and Gravatar
image. You can even open old revisions of a file by right-clicking it in
Nautilus; SparkleShare adds a "Get Earlier Version" menu that tags old revisions by who committed the last change.
0.2 is a small number
There are a few minor nuisances in SparkleShare, starting with its decision to bury its launcher in GNOME's hopelessly overcrowded "Internet" application menu. Partly this is the fault of the Freedesktop.org menu specification for creating such a generic catch-all category, but SparkleShare is a file-access tool, so it really belongs in GNOME's file access menu. GNOME's file access menu has its own problems; it is the logical choice for accessing the increasing number of online file services, including Ubuntu One, Dropbox, various cloud offerings, and so on, yet all are buried in different locations in the application menu hierarchy. Considering that GNOME also burdens its file access menu with the vague and awkward "Places" moniker (which will also prove confusing when Zeitgeist's geolocation support lands), it is understandable that no application installs a launcher there, but the end result is that users have to hunt around to find their online storage.
The interface for adding a project is also in need of some tweaking. SparkleShare works only with Git, which uses the terms "repository" and "project," both of which SparkleShare refers to as "folders." The goal of the application is to make the remote service function as a local folder inside Nautilus, but using different terminology — particularly in the setup process — is unnecessary user confusion.
Finally, although SparkleShare is designed to enable team collaboration,
you currently must manually change the ownership of a Gitorious project
folder to a "team" at Gitorious's web site, and add collaborators one at a
time via the web interface in order to share with other Gitorious or GitHub users. As with new account registration, rolling some of this functionality into the SparkleShare GUI would help, particularly for the non-developer target audience.
There is still a long way to go before SparkleShare reaches 1.0. Windows and Mac OS X binaries are already prominently advertised as part of the roadmap. In comment threads on his blog, Bons has discussed graphical KDE client support as well as supporting other DVCS options as possible new features. There are critics who argue that Git is a poor choice for sharing large binary files, to which Bons replies that all DVCSes are poor at that task. A stand-alone "SparkleShare server" has also been requested, which Bons says he is looking into.
Exactly what such a server would entail is not specified; presumably it involves a different feature set than a public Git repository's, but whether that means simpler remote access, private data, or something else, has not yet been explained. Along the same lines, simply providing instructions on setting up a compatible Git repository would be a helpful interim step — although "on my own server" is a setup option, it is not clear what configuration options are required.
As a collaboration tool for designers on technical projects, SparkleShare already offers all of the necessary functionality. A team working on a large GitHub- or Gitorious-hosted project can set up a folder for design work (images, vector graphics, documentation, etc.) and enable its designers to keep in sync with its software developers; that is a big win.
On the other hand, it needs to be understood that SparkleShare is not a
one-stop "Dropbox replacement." People use Dropbox for a
wide range of purposes (including remote backups, access to profile
information from multiple desktops, and even remote scripting), some of
which are a terrible fit for SparkleShare. Remember that all files stored in SparkleShare are world-readable through public Git repository services — not a good fit for your private keyring. It is also not designed to easily publish large files for public access; although GitHub and Gitorious allow HTTP access to any file, they do not offer a simple "share this" URL for emailing or microblogging a file to others. But do not let any of those use-case mismatches discourage you from trying SparkleShare for its intended purpose; it is already clearly a better option than the proprietary Dropbox for those who care about free software.
Comments (15 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Remotely wiping mobile phones; New vulnerabilities in Flash, couchdb, django, samba, webkitgtk, ...
- Kernel: Broadcom; Storage tree; Improving scheduler latency; Dynamic writeback throttling; Fast interprocess messaging.
- Distributions: An update on openSUSE's strategy search; Fedora defers systemd to F15; aptosid; OpenIndiana; articles on Ubuntu, Mint Debian, ...
- Development: CouchDB at CouchCamp; FMPS, GNU Radio maintainer, pgpool-II, ...
- Announcements: WordPress Foundation gets the trademark; new CEO for Nokia; lca miniconf cfp; articles from EFF, FSF, Garrett, ...