Introduction

Mercurial

Mercurial is a great distributed version control system written in Python. It is a "fast, lightweight source control management system designed for efficient handling of very large distributed projects".¹ It is used by such projects as Aptitude, Mozilla, OpenJDK, OpenSolaris, Python, and Xen, among many others.² However, I have always found that hosting Mercurial repositories is painful. There are many options, including CGI/FastCGI and SSH based approaches. But none easily provided what I was looking for: anonymous cloning and use of the web interface, with HTTP authorization required for pushing.

hg serve

hg serve is a Mercurial command that starts a lightweight, built-in Web server. However, it provides no authentication.

Nginx

Nginx is a lightweight, fast web server and proxy. It powers WordPress.com, Hulu, Github, and Ohloh, among others³, and is the fifth most popular server on the web today.⁴ It was already in heavy use on my server, so I decided to find a way to solve my Mercurial hosting problems with it.

Configuring Nginx

The first step is to configure Nginx.

server {
    listen      80;
    server_name <your-server-name>;
    access_log  /path/to/access/log;
    error_log   /path/to/error/log;

    location / {
        limit_except GET {
            auth_basic           "Restricted";
            auth_basic_user_file /path/to/htpasswd/file;
            proxy_pass           http://localhost:8080;
        }
    proxy_pass http://localhost:8080;
    }
}

The first line simply starts a server directive, inside which configuration for that server is defined. The next lines are standard directives for any server block. The limit_except block says to do the following for all requests except GETs: set the authentication realm to "Restricted", (or whatever you want to call it), use the specified htpasswd file for authentication (created in the next section), and then proxy to port 8080 on localhost if authentication succeeds. Since clones and web interface views are GETs, this means you will not have to be authorized for them. The proxy_pass directive simply needs to point at whatever port you have hg serve running on.

Configuring htpasswd

htpasswd is a utility used to manage flat files that store usernames and passwords for basic HTTP authentication. It is most likely provided in whatever package in your distribution provides the Apache server. To use it, cd into the directory you specified for auth_basic_user_file directive, and run htpasswd -c [file-name] [username] and enter a password. This creates (-c) an htpasswd file with the specified file name, with a user identified by the provided password. If you need to add another user, simply cd back to that directory and run htpasswd [file-name] [new-username].

Configuring Mercurial

The final step is to configure Mercurial. cd into the root of where you want your repositories to be served from, and create the hgweb.config file as discussed here. Then, inside each repository, modify /.hg/hgrc to contain the following in the [web] section:

push_ssl = false
allow_push = *

This disables SSL, and turns off the Mercurial repository trying to authenticate, since Nginx is taking care of that.

Launch

Now, in the directory where your repositories are stored and your hgweb.config is, run hg serve --webdir-conf hgweb.config (the -d option, which daemonizes the process, is also useful). If all went well, you should be able to browse your repositories via the web interface and clone repositories with no authentication, but when it comes time to push you will need a username and password from the htpasswd file.

Caveats

There are drawbacks to this approach. First, authentication is done over HTTP, not HTTPS. For me, hosting personal projects, this isn't a big deal. Second, authentication is done site wide, so once someone has push privileges to one repository they have them to all. This is easily worked around by creating a location /[repo-name] block for each repository, and point auth_basic_user_file to a different htpasswd file for each repository.

Sources

1. http://www.selenic.com/mercurial/wiki/
2. http://mercurial.selenic.com/wiki/ProjectsUsingMercurial
3. http://wiki.nginx.org/Main
4. http://news.netcraft.com/archives/2009/07/28/july_2009_web_server_survey.html

Are there times of the night that you find yourself adjusting your screen brightness lower, either to help your eyes or not bother someone else? It can be annoying have to tweak brightness settings all of the time. We'll show you how to set your brightness automatically during the night. Read on.

To start, you need to have a laptop or a display that supports software brightness configuration. You'll also need to make sure that your GNOME brightness settings are working. (KDE fan? Submit a relevant article.) Also, take note that if your system is not on when brightness settings change, they will not be updated.

Now, pop open a terminal to edit your crontab:

crontab -e

Now you'll want to add some time and brightness settings. Use this as a template:

0 22 * * * gconftool-2 --type int --set /apps/gnome-power-manager/backlight/brightness_ac 10
0 7 * * * gconftool-2 --type int --set /apps/gnome-power-manager/backlight/brightness_ac 100

The first line will set the brightness value to 10% at 22:00; the second sets it to full brightness at 07:00. Note that these are not hardware brightness values, but power manager values that scale from 0 to 100. You can add as many lines as you want. If you're proficient in your crontab syntax, then you can even use settings that only apply on weekends or weekdays.

We’ve all heard the rants: Mono has patents, Microsoft releases community promise, community ignores, flamewars continue. Enough to make any developer want to stop programming out of sheer annoyance. Mono is an excellent language and platform; there’s nothing anybody can do to change that. People will continue to develop C# apps, and those that continue to hate Mono will continue to complain.

There was always one thing about Mono/C# that I wondered: why does it have to use a JIT or a runtime? It seems like the sort of language that you could just compile and forget about. Perhaps I was a little naïve; Mono provides a lot of benefits like managed memory.

And then here comes Vala. Saunters into the room like it owns the place. Claims to be that magical language that translates C#-ish code to C with a little help from GLib and GObject. What?! Skeptical, over the past couple of months I decided to give this fancy language a try.

And I am left stunned. Vala code is very easy to write, and compiles without a complaint. It feels a lot like C#. Being a Python programmer, actually writing in this language felt really new, yet somehow familiar. Time to summarize!

The Good

It’s a runtime without a runtime. Vala, true to its word, converts the source to C and compiles it. Memory and variables are all managed using GObject. Opened files and resources are closed automatically. Less and less do I have to worry about a leaky application. Sure, it requires the GLib library, but that is almost as ubiquitous as the standard C library on free software desktops.

The bindings! This is the real sweet spot. Since Vala code appears as C to the target machine, that means that almost all existing libraries can be made compatible. Vala bindings can be as simple as a single file. 200 lines is all it takes to bind to WebKit. On top of that, it was automatically generated! Thanks to GObject introspection, bindings for many GObject-based libraries can be entirely automatic. That’s smart.

It has nice error messages, unlike GCC. This alone might be a compelling reason to switch. ;-)

The bad

There are cases when Vala doesn’t quite hit the target. Granted, it’s still under active development and hasn’t hit a 1.0 release yet. While it is pretty good at catching potential programming issues, there are cases where some errors might slip by and you are left with debugging C source. This is mostly when you have a stray reference or unowned variable that goes berserk.

Speaking of C sources… they aren’t very pretty. _tmp_ variables are thrown all over the place, and the memory management code seems to take up a bulk of the source.

If you’re looking for documentation on Vala, well… you might be looking for a while. There is a constantly updated tutorial and a plethora of examples, but I wasn’t able to find anything that really went in-depth. Installing Devhelp and looking through C documentation helped out. The fact that the bindings’ VAPIs are fairly readable makes them a good place to look for function definitions, but explanations might be hard to find. If you’ve a C# or Mono programmer, Vala shouldn’t be much of an issue. Someone like myself who hasn’t worked with a C#-like language might be baffled for a few moments understanding how things work. Again, since Vala is constantly changing, it could be difficult to keep documentation up-to-date. But it would certainly be a nice thing to have.

All in all, Vala is a pretty sweet language. If you’ve ever had an interest in C#, I highly suggest you check it out.