LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DevelopmentDVCS-autosyncDropbox is a fantastic concept, but it has some major flaws — namely that the software is proprietary, and that users must entrust their files to a third party. Unfortunately, Linux users have few alternatives to Dropbox — and even fewer that are free software and mature enough for daily use. While not quite mature, DVCS-Autosync is looking like an interesting alternative for file synchronization between Linux systems. One other option is SparkleShare, an attempt to provide a multi-platform, git-based replacement for Dropbox. However, SparkleShare is still in early development, and is somewhat ambitious — it attempts to replicate not only Dropbox's main feature (synchronizing files seamlessly) but also to provide collaboration tools and an easy to use GUI frontend for viewing file revisions. SparkleShare also puts off some potential users because of the project's technology choices — namely that SparkleShare is written in Mono and uses git rather than another Distributed Version Control System (DVCS). Many users simply want a tool that will synchronize files, and have no need for collaboration features, multiplatform support, or a GUI to manage all of it. For those users who don't find SparkleShare appealing, DVCS-Autosync is a Python-based alternative that is not as full-featured — but it does get the job done. René Mayrhofer announced DVCS-Autosync on March 10th of this year, though the tool has actually been around for quite a while before that. Mayrhofer says that the script started life before SparkleShare was announced, as part of managing his home directory using SVN and then git. Mayrhofer says he lacks time to try to contribute to SparkleShare, but was "pleased to see others go into the same direction" and that he wanted to publish what he had so far. All about DVCS-AutosyncSo what is DVCS-Autosync? It's a Python script to keep DVCS repositories in sync when files are added, changed, or removed by automatically committing and pushing or pulling the files to the server and clients. It does this by watching one directory for changes, using inotify and communicating between clients using XMPP (Jabber). Thus, when changes are made clients receive a message over XMPP to notify them of the change and to initiate a pull from the git repository. DVCS-Autosync has been based around (and tested with) git, but it's been written to allow use with other distributed version control systems — so if a user has a strong loyalty to Mercurial, they would be able to configure DVCS-Autosync to use Mercurial or another DVCS instead by editing the commands used for various DVCS-Autosync operations. For example, users could replace the default pull and push commands ("git pull" and "git push," respectively) with the appropriate pull and push commands for another DVCS.
Setting up and Using DVCS-AutosyncRight now, DVCS-Autosync is not yet packaged for most distributions, excepting Arch. Packages for Debian/Ubuntu are on the way but for now if you want to use DVCS-Autosync it requires grabbing the source off of Gitorious and installing the necessary dependencies. Users will need Python 2.6 or later (2.7 seems to work just fine), Pyinotify, and xmpppy (packaged as python-jabberbot on Ubuntu). Of course git or your favorite DVCS is also required. Because the utility uses Jabber/XMPP to communicate between clients, you'll also need a Jabber account that you can use for its notifications. The installation instructions on the DVCS-Autosync page seem to be a bit
outdated. There's no "autosync.py" included with the source, the
dvcs-autosync script is now what you're looking for. Also you can install
DVCS-Autosync using " The next step is to initialize a git repository on a central server, and to then clone that repository on each client that will be using DVCS-Autosync. Each client also requires a config file (included as .autosync-example in the source, under the main directory) that needs to be customized to add Jabber account information. After that, run dvcs-autosync and, if all is configured properly, it should just go. As long as dvcs-autosync is running, it will automatically commit files after they're added to the directory or changed, and synchronize files to the other clients after they've been checked in. Users do not need (or have the ability to) manually make commits with dvcs-autosync. Note that it will not operate quietly, however. The application is set up to display desktop notifications for each change. This is similar to Dropbox's default behavior — but seems utterly unnecessary past the first few hours when one might wish to ensure that the script is actually working. Mayrhofer says that the devel branch now allows users to configure notifications to go to the desktop, XMPP, both, or turn them off entirely. Users can recover older versions of files, or view commit logs, using the standard git utilities — but dvcs-autosync doesn't have any special tools for that, either. In short, it is currently a single-purpose utility that syncs files between machines. Looking ahead for DVCS-AutosyncDVCS-Autosync is an interesting alternative to Dropbox and SparkleShare, but it still has some room for improvement and a few missing features that may be problematic for some users. First and foremost, DVCS-Autosync is missing encryption. While Dropbox's encryption is significantly compromised by the fact that the company can decrypt its users files without the users' permission or knowledge, it does at least offer the feature. DVCS-Autosync, on the other hand, makes no provision for encryption at all. Mayrhofer says that he "definitely" plans to implement encryption at some point — but for now it's assumed that the repository is trusted. Mayrhofer is undecided how to implement encryption but may look at using git-annex, which has gained support for encrypted backends recently. Using git-annex might help with another weakness in the current implementation: if you're using DVCS-Autosync for syncing large files that change often, you may be looking at a fairly large repository after a while because it will store the entire file for each change. However, this is a known problem and DVCS-Autosync contributor Dieter Plaetinck has suggested using git-annex to handle large files as a way around the current problem. Moving directories gracefully, and providing a single commit entry for multiple file events (such as moving a directory, or uncompressing a tarball within the synced directory) are also on the list of bugs to handle soon. Longer term, Mayrhofer has indicated that he'd like to add context to commit messages (such as which applications are open at the time), and a way to specify commit messages via a traybar icon or popup rather than the general commit messages that are generated by DVCS-Autosync currently. In its current state, DVCS-Autosync has a few kinks to be worked out before it can reliably replace Dropbox for most users. However, there seems to be some strong interest in the application already, and it could quickly become reliable enough to become a staple for Linux users who just want a simple file synchronization tool that requires little attention.
Brief items Quotes of the week
To a first approximation, when someone says "Lightweight" what they
mean is "I don't understand the problems that the alternative
solves".
-- Matthew Garrett
It's obvious to anyone with any sense of orthogonality that the
Perl 5 smart match operator is anything but smart. It is clever,
but not smart. And it's obvious to anyone who's actually tried to
use given that it is at best an incredibly awkward graft onto Perl
5, offering false hope of simplification but actually being more of
a lateral arabesque to a different kind of complexity.
-- Chip Salzenberg
This is a huge reason why so many people dislike GNOME 3. Instead
of getting used to how it works, they complain that it's not
exactly how they're used to using it. Many people have approached
it with an open mind and, for the most part, enjoy it very much. If
we enjoy it, then GNOME Shell has to be at least somewhat good,
yes? Just because you do not see it as so does not make it bad.
-- Ryan Peters
The future of GNOME is as a Linux based OS. It is harmful to
pretend that you are writing the OS core to work on any number of
different kernels, user space subsystem combinations, and core
libraries.... Kernels just aren't that interesting. Linux isn't
an OS. Now it is our job to try to build one - finally. Let's do
it. I think the time has come for GNOME to embrace Linux a bit
more boldly.
-- William Jon McCann
I'll call it Josselin's law: "As an online discussion grows
longer, the probability of a comparison involving Ulrich Drepper
approaches 1.".
-- Lennart Poettering
A Linux system running over JavaScriptFabrice Bellard has posted an x86 emulator written entirely in JavaScript which enables one to boot a Linux system inside a web browser. There are some technical details available for those who want to know how it works. "The CPU is close to a 486 compatible x86 without FPU. The lack of FPU is not a problem when running Linux as Operating System because it contains a FPU emulator. In order to be able to run Linux, a complete MMU is implemented."
NumPy 1.6.0 releasedRelease 1.6.0 of the NumPy numeric Python module is out. New features include a 16-bit floating-point type, a new and improved iterator, more polynomial types, and more.
Perl 5.14.0 releasedThe Perl 5.14.0 release is out. Changes in this release include Unicode 6.0 support, better IPv6 support, some regular expression enhancements, performance improvements, and more. See the 5.14.0 perldelta page for lots of details.
GNU SIP Witch 1.0 releasedGNU SIP Witch is a SIP protocol provisioning and call server; it is a part of the GNU Free Call project. The 1.0 release is now available. "In conjunction with this release, the GNU Free Call project is distributing an initial release of our technological assistance package for common computing platforms by providing our switchview desktop client for use with GNU SIP Witch on your local machine. In the future TAP will enable multi-platform personal encryption, include further support for desktop and mobile secure calling, and provide other basic and common computing services missing on some platforms."
Announcing TermKitSteven Wittens has written a lengthy weblog entry describing TermKit, a terminal emulator built on WebKit. "So while I agree that having a flexible toolbox is great, in my opinion, those pieces could be built a lot better. I don't want the computer equivalent of a screwdriver and a hammer, I want a tricorder and a laser saw. TermKit is my attempt at making these better tools and addresses a couple of major pain points. I see TermKit as an extension of what Apple did with OS X, in particular the system tools like Disk Utility and Activity Monitor. Tech stuff doesn't have to look like it comes from the Matrix." Source is available on Github.
De Icaza: Announcing XamarinOn his blog, Miguel de Icaza has announced Xamarin, which is a new company formed to create Mono-based products, specifically for iOS and Android. The company is made up of the Mono team that was recently laid off by Attachmate, and will also continue development of the free software Mono and Moonlight platforms. "The new versions of .NET for the iPhone and Android will be source compatible with MonoTouch and Mono for Android. Like those versions, they will be commercial products, built on top of the open core Mono. [...] In addition, we are going to provide support and custom development of Mono. A company that provides International Mono Support, if you will."
GNOME release-team-lurkers: for people who can read and not respondThe GNOME release-team mailing list is intended for private discussions between release team members. However, for those would like to follow along, the release-team-lurkers list has been set up for a trial run. "If you wanted to follow and can *refrain* from taking part in discussions, subscribe to above list and you'll get a copy of all release-team emails."
Newsletters and articles Development newsletters from the last week
What Every C Programmer Should Know About Undefined Behavior #1/3The LLVM project blog has the beginning of a three-part series on undefined behavior in C. "Undefined behavior exists in C-based languages because the designers of C wanted it to be an extremely efficient low-level programming language. In contrast, languages like Java have eschewed undefined behavior because they want safe and reproducible behavior across implementations, and willing to sacrifice performance to get it. While neither is 'the right goal to aim for,' if you're a C programmer you really should understand what undefined behavior is."
What every C Programmer should know about undefined behavior #2/3The second installment in the series on undefined behavior in C has been posted to the LLVM blog. "The end result of this is that we have lots of tools in the toolbox to find some bugs, but no good way to prove that an application is free of undefined behavior. Given that there are lots of bugs in real world applications and that C is used for a broad range of critical applications, this is pretty scary."
Poettering: systemd for developers ILennart Poettering has started a new series of systemd articles; this set is aimed at developers. "As you can see this code is actually much shorter then the original. This of course comes at the price that our little service with this change will no longer work in a non-socket-activation environment. With minimal changes we can adapt our example to work nicely both with and without socket activation..."
Page editor: Jonathan Corbet |
|||||||||||||