Apart from a brief, but nevertheless instructive, flirtation with Emacs¹ I have been a consistent Vim user over the last three or four years. Like most Vim users, I have made some progress over that time in spite of Vim’s notorious learning curve and have now reached the point where, belatedly, I think I understand it just enough to really grasp how little I actually know. It’s a milestone that speaks more to necessity than gratification, granted.

In any event, as part of confronting my Vim shortcomings (no golfing for me), I have been able to land on the features of Vim that I require to be enabled so that I am moderately productive (in my own, admittedly cloistered, working environment). That, you will probably not be surprised to read, does not include needing support for Arabic or Farsi to be built into Vim.

Part of the beauty of Vim is that, unlike it’s operating system counterpart Emacs, you can choose how much functionality you wish to enable at compile-time. You do want support for Farsi? Then the --with-features=big option is what you are looking for. If, on the other hand, you just want the barest of bones, editor-wise, you could opt for the austere minimalism that is --with-features=tiny and find yourself happily transported back in time to Bill Joy’s lab in 1976.

You can peruse all of the various features available to Vim using the :help version command.² There is also this table where the various features are listed against the respective feature flags (tiny, small, normal, big & huge).

After this bug report late last year, the default Arch PKGBUILD ships with huge as the feature set. Make what you will of that, but for my purposes it is overkill. With all the magic of ABS and makepkg, however, it is simple enough to build a Vim package that is tailored to exactly your requirements. For me, that means this set of simplified configure options:

1
2
3
4
5
6
7
8
9
10
11

  ./configure \
    --prefix=/usr \
    --localstatedir=/var/lib/vim \
    --with-features=normal \
    --with-compiledby=Arch:jwr \
    --with-x=yes \
    --enable-acl \
    --disable-gui \
    --disable-signs \
    --disable-netbeans \
    --enable-multibyte

With these options, I have the minimum amount of functionality I comfortably require (including the ability to access the system clipboard, --with-x=yes) but without the other bloat.

In addition to these changes to the config options, I also strip out all of the gvim-related stuff from the PKGBUILD as I do not require it. Even though it is a split package, just building vim still includes options superfluous to my needs. As a result, I get Vim with just the features I need, without the dependencies of ruby and lua and god knows what else.

I’m not operating under any illusions about the fact that this is really saving a huge amount of space or, for that matter, drastically reducing the number of dependencies I have installed. It is partly about understanding how Vim works at another level while also catering for the obsessive-compulsive drive to micro-control what is and isn’t installed on my systems. If you want to scratch either of the same itches, you can see the full PKGBUILD in Bitbucket.

Notes

1. Still visible in some of my early Arch screenshots on Flickr…
2. The official documentation for the features is also online.

I have posted about using dropbox quite a few times over the last couple of years; it is one of those utilities that quickly insinuates itself into an indispensable niche in your workflow and, consequently, can be very difficult to dislodge. Perhaps because it has started to glue together so much of the way I work, I have been wondering when I would find a replacement that would deliver all, or much, of the functionality, without the standard cloud security issues, that seem to bedevil these services.¹

When I saw that BitTorrent had release a distributed synching app called—appropriately— Sync, I signed up for the Alpha and have been running it in lieu of dropbox for the past three weeks. My initial reaction is, that for a first release, it is very impressive.

Essentially, Sync uses the bittorrent peer-to-peer protocol and encryption (AES 256 using a private key based on the secret generated for each shared folder) to sync files between your machines—or anyone with whom you share the secret for a particular directory. This has several advantages over dropbox, from my perspective. First and foremost, you are not relying on some third party for security², storage and uptime. Secondly, all of the traffic between your devices is encrypted. And finally, it is free (sadly, only as in beer).

Positives

So what does it do well? It is ridiculously easy to setup. You download the binary, start the app and then (on Linux) use the web interface to setup your first synching folder by generating a secret and then nominating a folder to share. On your next machine, enter the secret and select or create the shared folder and your files will be synched. Done.

On a headless machine, there is a config file that you can create:

1

syncapp --dump-sample-config > syncapp.conf

Edit it to suit your requirements, and then start syncapp with that configuration:

1

syncapp --config /path/to/syncapp.conf

and you are away, happily synching.

Like other applications that use the bittorrent protocol, it can take a minute or two for the synching to begin, but once it does I found it—over the Internet as well as my LAN to be much faster than dropbox. Another plus.

Areas for improvement

It is Alpha software so there are some areas where you can expect to see improvements with subsequent release. For me, that includes:

• Better command line tools; the current limited set are servicable, but could do with more flexibility and options
• The ability to create your own secret, rather than rely on generated ones
• A less fragile config file; it is written in JSON and the simplest errors will break it
• More Linux love; the other platforms have a much more sophisticated UI

A comparison with dropbox is not entirely fair; there are some things that dropbox does—like versioning—that Sync can/will not do. Dropbox also allows you to host public files and folders, meaning that you can setup a basic webpage or share a photo album. Sync clearly isn’t designed for this.

However, in some other respects, like architectures for example, Sync is already a better choice. The ARMv6 port means that I am able to run it on my Raspberry Pi, and that I have been able to update my IRC notification system to use Sync rather than dropbox and it is working perfectly well.

There is one area, though, where I wish the BitTorrent team would be a lot more forthcoming. There has been an unanswered question on the Sync forums for over three weeks now asking will Syncapp be open sourced? Aside from the issue of whether or not the source will be made available (and I am guessing that given their reticence to answer the question on their boards the prognosis is not promising) people using the application now should know under what terms they are using it.

In the absence of any definitive licensing, I can only assume that the application is covered by BitTorrent’s default EULA. That ambiguity means that I am happy to participate in the trial and provide feedback, but I won’t be using the app for any remotely sensitive data and I am unlikely to do so until that issue is clarified.

I’ll install Sparkleshare and give that a shot instead…

Notes

1. Naturally, there are more issues at play here than just their (in)security policies.
2. Assuming, of course, you trust what BitTorrent pack into the binary…

Over the last couple of months there have been a number of discussions on the Arch boards about the forum policy of only providing support for Arch Linux, culminating in this long thread about Archbang users (login required) being denied support and having their threads summarily closed. As it emerged in the discussion, there seem to be two separate issues at play here; the question of Arch-derivatives using the Arch brand (logo, colours and even the forum style sheets), and how the wider community of GNU/Linux distributions are treated on our boards.

The first issue is relatively simple to address. Allowing derivative distributions to use the Arch brand is, in my view, a mistake. It dilutes the value of the Arch “brand” and—as can be seen when people show up having installed a derivative and thinking they are running Arch—just confuses people.

For some of these derivatives, like Archbang, there is an argument to be made that once they have completed the installation process, they are in fact running Arch, albeit an off-the-shelf version. I find this argument to be specious. All of the derivatives that I have come across, in addition to “simplifying”¹ the installation process and including X and some sort of desktop or window manager by default, also make a number of other system changes that invalidate their claim to being Arch by another name.

See this scathing review of Manjaro or Allan’s roundup of the Arch Spin-Offs for the details on the decisions these developers make that mean it is not practicable to support them on the Arch boards, nor desirable to do so in future. As a distro, Arch is essentially vanilla packages, pacman and rolling release, and a base on which you build your preferred system. Changing two of those three means that you are not running Arch…

That leads in to the second point, which is I’ll paraphrase as “well, we are all Linux users, so everyone should be welcome to ask for support from Arch users.” It is a fine sentiment, but one that is neither historically accurate, nor in the long term interests of Arch. I have harped on in the past about help vampires and last year I came across the perfect illustration of the unchecked effects of this phenomena:

Right now I'd say the bug queues are flooded with bugs that you can't really act on… It's a strain on the project that there are so many users that don't really get it.

Your bugtracker becomes essentially unusable. Your forums end up the same way. No-one ends up getting much in the way of assistance at all, let alone anything approaching informed help. That may be an inevitable consequence of the collision between considerable but still finite resources and a philosophy of being the OS of the masses; Arch has nothing like that in terms of resources, and a very different philosophy.

That philosophy doesn’t include anything about shortcuts or commoditized images for a mass user base. It doesn’t mention making the installation and maintenance of your system completely idiot-proof so as to facilitate a relentless march to the very top of whatever spurious distro popularity ranking system you subscribe to. And it certainly doesn’t say anything about your entitlement to immediate and courteous support from the Arch community in the face of your own inability to reach a minimum level of understanding of what it is that you have installed on your hard drive.

If you think that you can just skip the whole tiresome RTFM thing by downloading a derivative and installing that, how exactly do you expect to be able to run a rolling release distro that has, on average, a couple of significant changes every year?

Sooner or later you are going to have to come to terms with the responsibility that is an integral part of this type of rolling release and, if you have installed it yourself, you will be much better placed to be able to build on that understanding and broaden and deepen your knowledge of your system.

That is ultimately far more satisfying for you, and much more beneficial for the rest of the community as it means that you will be more able and likely to contribute back in whatever way that you can; reporting bugs to a functioning bug tracker, editing the fine Wiki, maintaining packages in the AUR, submitting patches, etc. Doing all the things that will sustain Arch and continue to make it an attractive distribution for competent GNU/Linux users and those that are willing to invest the time to become so.

Notes

1. If you have used the Arch install scripts, you would appreciate that it is not really possible to provide a simpler installation process.

Creative Commons licensed image on Flickr by pietroizzo