First, GitHub isn’t that bad. I was tempted to go away from it completely, because of reasons I will explain below, but it does a simple job and does not screw up too much.

It’s fairly slow and unreliable, especially compared to my cheap server (Roubaix, while located in the Far North, is after all much closer to me than the United States). Yet, most of the time it does its job and does not bother me. Creating a new repository is annoying, though after years GitHub developers finally realized the page had to be accessible in more than one obscure way, compared to just pushing to my server (thanks to a Gitolite rule, it creates the repo automatically). git-daemon and cgit are fast, but GitHub sure would handle heavy load better than my server.

The fact that GitHub is insecure and use stupid frameworks isn’t the issue either. It’s hard to miss rogue commits since it means non-fast-forward push, and PGP signatures are the real solution for authentication. I don’t care if they have proper backups either, I have mine: I now push to my server directly, which then pushes to multiple mirrors (this is easy to do with gitolite).

The real issue is mostly GitHub refusing to acknowledge one size does not fit all, and a lot of obnoxious GitHub users.

My biggest issue is “pull requests”. The thing is, you can’t disable them. You can disable issues, wiki (and I do, since they pretty much lock you to GitHub; you don’t own the data anymore like you do with git), but not pull requests.
It already has been explained by other people ([1] and pretty much all other PRs, [2]), and probably better than I will. The reaction of GitHub developers was, roughly, “Linus is wrong“. I’m pretty sure the opinion of the creator of git, and the manager of one of the biggest software project ever, isn’t all that wrong.

As a manager, pull requests are annoying, because they require you to add a remote for every user sending a PR. Even for a 2 line patch from an user that will contribute once. The remote URL isn’t displayed straight on the PR, of course.
Actually, I learned you can get a patch by adding .patch to the URL, but it isn’t advertised anywhere. Maybe some GitHub developer actually has sense and snuck that feature in.
Or of course you can merge the commit from the web. Seriously, you can merge it, without even getting it on your machine (to, you know, test it, read it, etc.), from your web browser. That’s retarded, right? Well, it’s even worse: it makes a silly merge commit, even if it is fast-forward.

As a contributor (and this is the part that wasn’t covered by the other critics), pull requests are even more painful.
GitHub projects usually expect pull requests, and only them. So you
have to do it the GitHub way: “fork” it (from the web),
commit, push on your repo, and make the pull request (from the web). The web interfaces are, as most of them are, slow and annoying. Pull requests are from a branch to a branch, so you have to create a branch if you want to continue working on it without updating the PR automatically. Since I tend to do a lot of small contributions, it spend more time fighting with GitHub than actually altering the code.
On sane projects, you send a patch to an e-mail address. Two simple git commands, and you’re done. Oh, and there’s no way of attaching files to GitHub issues, so don’t think about it.

When the pull request is closed, you don’t receive anything. No notification, no mail. There is no way to list your past or pending PRs (or issues).

To sum up, GitHub restricts your workflow, while git is all about flexibility.

The last issue is GitHub users. It’s not much of a pain because it’s easy to ignore them, except being on GitHub could make you likened to them, like having a MySpace page kind of makes you lame too.

Poor commit messages, custom smileys (even in commits!) and “me too” trying to look good. A lot of projects seem to spend more time advertising themselves than actually trying to work. At least they’re publishing code?

Project forks and watchers mean nothing. Some people will “fork” projects before having done anything, and will likely never commit on it. Yet, it will get listed. Watchers do not mean potential contributors either, or even… users.

I heard some people actually pay that much for sub-par git hosting. I think it tells something about GitHub users.

GitHub could listen to the critics of pull requests, or just acknowledge other ways of contributing, but I doubt it will happen.

If there is something I always forget, it is to update serial numbers of DNS zones.

Serial numbers is the only source used for zones transfers, so if you forget to update them, the secondary NS will keep serving the old zone.
When you use a fancy DNS server, which has a database backend for intance, it can compute the serial number automatically (which is usually in the YYYYMMDDxx format). In my case, it is much simpler to rely on BIND-style zone files.

My first solution was adding at the top of my zone files:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; DO NOT FORGET TO UPDATE THE SERIAL NUMBER ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

However, it still required me to update the serial number manually, which is pretty annoying.

Then I discovered the dnstouch tool from ndu (that tool does not require BIND). When you run it on a zone file, it updates the serial number with the current date, and even handles the last two digits (a simple counter).

This inspired me to automate even the part of starting dnstouch. Now, I simply run make and the serial numbers are updated, only if required.

Here is the Makefile:

.SUFFIXES: .zone .zonetouch
 
zones := $(patsubst %.zone,%.zonetouch,$(wildcard *.zone))
 
all: $(zones)
 
.zone.zonetouch:
	dnstouch $< && touch -r $< $@

What does it do:

• Declare that *.zone and *.zonetouch are generic actions
• Find out what the *.zone files are, and deduce the .zonetouch files that should be updated or generated
• Declare the default action is to generate all the .zonetouch files
• Declare the action to generate a .zonetouch file from a .zone file. If the .zonetouch is outdated, the commands will be ran. If not, make runs dnstouch, and then creates or updates the .zonetouch file, with the same modification time.

While the Seinfeld calendar greatly helped me to get the habit of doing something productive, the service I used has its flaws. First, it’s restricted to GitHub. Also, since it only counts commits, and not the fact that I can work without any finished product, it made me prefer short work and postpone doing stuff I wasn’t sure I would finish before 00:00 (the fact I start late does not help either). The notion of a day is also wrong — committing at 00:30 should not be counted for the current day but the previous one.

The basic idea is to start a server without any central configuration to maintain, and no need for any root access, hence generic virtual hosts features of Apache or lighttpd are not complete alternatives, as they at least require editing /etc/hosts.

It uses the FastCGI backend (or “SAPI”) and can by default handle 3 concurrent requests, which is more than enough for development. On the production side, I only use symfttpd to generate the rewrite rules (since lighttpd is also my production server of choice). If you have an opcode cache installed (for instance APC or xcache), it will be used, as fastcgi processes are seldom restarted (by default every 100 requests, I use a higher number on production though). It also does not rely on any hacks to simulate a web request in the CLI: you are doing real requests using a real PHP HTTP backend.

One of the future improvements could be using FPM instead of FastCGI.

Symfttpd can optionality use the fork function to provide two nice features: automatically restart when rewriting rules change, and display the access and error log. However, if you do not have fork support compiled in (it is enabled by default in at least Gentoo, Debian and Ubuntu), it does not mean only one request can be answered at a time (lighttpd does not need fork() by the way, which is one of the reasons it is very fast).

I don’t like to listen to stuff loud. People usually listen loud because their setups are bad and it compensates somewhat. Well, I’d like to preserve my hearing — already imperfect — as much as possible. With my current IEMs, the outside noise is actually louder than when I wear them and play music. In a way, it’s even better for my hearing!

The issue is that nowadays, pretty much all portable players are crap. They rarely support interesting formats. Their amplifier stages are tuned for loudness and sacrifice the dynamic range. Their interfaces are animated and shiny, yet don’t get shit done.

The most popular remedy to bad amplifiers is to use an Apple device, as the proprietary connector provides line out, which is an unamplified signal, and to use an external amplifier. Some other devices provide line out, but are much harder to find. The recommended choice is an iPod 5.5th generation or below, as their DACs are of reasonable quality, but mostly because they are not as locked down as the new ones.

Hopefully, you can replace Apple’s horrible software by Rockbox, an open source alternative that will allow you to get rid of the iTunes dependency or support open and high-quality formats such as FLAC and Ogg Vorbis. One of the perks I get with it is the speaking menus — you can more or less control the device without looking at it, which is not easy to do when there are no buttons but only the ergonomic absurdity that is the “clickwheel”. It can also announce the battery status. The ReplayGain feature prevents me from having to adjust the volume between albums.

Another issue with iPods is the usage of an hard drive. While cheaper than Flash memory, it is much more unreliable and requires more power. You can however replace the hard drive by a CompactFlash card.

My current setup consists of an iPod 5.5g 30gb, with the hard drive replaced by a 32 GB flash drive (it wasn’t much of a choice, given the horrible noise the drive was making). It uses a SendStation Line Out and Micro USB adapter (no need to use a proprietary cable!), which is then hooked to an iBasso T4 amplifier. The amplifier provides me with an hardware volume potentiometer which for that reason alone is worth it. The final stage is handled by the Future Sonics Atrio M5.

Am I happy with it? Well, the sound quality is more than enough. I doubt I could enjoy my music more by upgrading to something else. However, I have a lot of unrelated complaints:

I spent 80€ on the iPod yet much more to make it suck less. And it still sucks. The build quality is shoddy, I frequently have to open it to reconnect components. It powers itself on even when the “lock” switch is activated, draining the battery needlessly. The clickwheel is a pain to use and I can sense it dying. The screen is shiny and obviously unreadable under the sun. Dust is getting inside. It is very slow to power on. The battery isn’t in a good shape, but the Flash memory and usage of an external amplifier compensate for now.

iTunes wasn’t able to restore the iPod properly when I changed the drive, so I had to mirror the drive exactly to the CompactFlash card (losing the additional 2 GB of space), contrarily to what was stated on the adapter’s website. Since I’m probably not the only one with the same issue out there, here is a raw copy of the drive with Rockbox installed as the only OS. It also was a bitch to open, even for an Apple product.

Uploading files to the iPod is slow as hell, and sometimes fails. It seems it doesn’t like writing more than a few gigabytes in a row. And the dock adapter has a tendency to come out.

To sum up, I’m using an iPod but discarding its software, and half its hardware.

The iBasso T4 uses a proprietary cable to recharge. Other than that, it caught many shocks but still works flawlessly. And it can be opened with a screwdriver.

As for the Atrio, for 100€, they were a solid choice. Now that they cost twice as much (and still are the same product) there probably are better options. I use Comply T100 foam tips, and they are generally compatible with Shure eartips (which motivated my choice since I have a bunch of them in stock). One nice touch is that the user’s manual recommends against any artificial bass enhancements: you know you’re not dealing with crappy phones.

So, what would I recommend instead? Well, I’d probably get a FiiO E7 or another iBasso model. But for the media player, I’m stuck. Hence the title.

There might be some hope on the side of the PDMI connector, though.

You can now use genconf without linking or copying it inside the project. It also makes the usage of mksymlinks more or less optional if you just want to use spawn.

Not much else too see apart from small bug fixes and documentation improvements.

Download symfttpd 1.1.1.
More information on GitHub.

There is also a adaptation of the current code for usage with Symfony2. However, it removes support of 1.x versions; a multiple-application update of symfttpd is coming soon.

This version brings one huge usability change: you don’t have to restart spawn anymore when a file is added in the web/ directory root. Enjoy being truly lazy!

Along with some miscellaneous enhancements, the output of the tools is now colored, and you can display lighttpd’s logs in the terminal with the -t option.

As always, suggestions and contributions are welcome.

Download symfttpd 1.1.0.
More information on GitHub.

If the activity of my blog leaves you frustrated and demanding for more, rejoice! I am also writing on my employer’s blog.

I have grown very fond of Symfony 1.4. It’s pretty much Symfony 1.2 with all the quicks ironed out. It showed me how much polish is important in a software project.

It’s almost all I have been doing in my own little project after the main features were implemented, symfttpd: making it less annoying to use, less unpredictable, etc. And I must say, the current stable version has at least one very annoying quirk (but if it’s documented, does it count as a feature?).

Sometimes, the code looks good, but it doesn’t mean that the whole project in itself is good.

First, a project should be simple to install. The install documentation should exist and always be up to date. I encounter too many projects where “inside knowledge” is required to install the application, and you don’t know if it doesn’t work because you didn’t install it right or it just doesn’t work. There should be a single command (makefiles or shell scripts are here for that) for a single task. It should not require weird system settings (this is very annoying with PHP when a lot of the language is customizable through php.ini).

On a similar note, the architecture should be simple to comprehend. When it feels too much like “magic”, when a simple action has too many unsaid consequences, something is wrong. There should not be hundreds of classes and inheritances when an option would be enough (this is an idea found at least in Python and Symfony 1.4 that I quite like). Names should be readable and short, not everyone has or likes using auto-completion.

I’m not sure what creates this kind of WTF. Inexperienced but talented programmers? Programmers who think too high of themselves? Programmers that are not lazy enough?