Black Shades: Wolfire picked up the icculus.org port of Black Shades and made an iPhone port! Go take a peek at it. Call of Duty: World at War: I forgot to mention this before. There's a Linux dedicated server. You'll need a retail copy of the game for the data (your Steam install should work), and this package, which patches any version of the game into a 1.3 Linux server: http://treefort.icculus.org/cod/codwaw-lnxded-1.3-03052009.tar.bz2 icculus.org: CVS, your days are numbered! We are pulling the plug on cvs.icculus.org on March 31st! http://icculus.org/news/news.php?id=4508 I'm thinking that I should give up on the offload server thing. It would be good to find a way to have everything be nice and automated like it currently is with mod_offload, but instead use something like Amazon Cloudfront for the actual offloading. It'll scale way better and not have to rely on the kindness of strangers (and, frankly, it's probably the cheapest alternative when you are willing to put money out for it). I've been ripping up some software recently: Bugzilla doesn't look like crap anymore, and ezmlm (good riddance!) has been replaced with GNU Mailman. I'll be writing more about this later. Other stuff: I have a small history of bitching about things GNU and Linux do just because It's The Unix Way, even when doing so is suboptimal. I already listed some things that GNU/Linux should outright steal from Mac OS X, and here was me whining about ports below 1024. I wanted to add something to that list today. Why are we using hidden files in $HOME for application configuration data? My workstation has 233 files/directories that start with a '.' in my home directory. They all have names like: .dbus .dbus-keyrings .subversion .gnome .gnome2 .gnome2_private .gnome_private .update-manager .update-manager-core .update-notifier Most of these aren't meant to be mucked around in, and some that might be human-readable, I would fear to wade into anyhow. It isn't always clear where things came from, either. I guess if you have a ".cpan" directory, you probably know what CPAN is, but honestly, where did this ".dmrc" file come from? Could we have picked a better name? I suspect there is a historic reason for this. User convenience, perhaps. Some of them did make good sense: after all, I'm editing ~/.plan right now. But here are my complaints with the current system: - Their specific purpose isn't clear in many cases. - It's not clear what application wrote and needs this information. - It's not clear if several files are all part of the same application. - They're cluttering up my home directory, even if a historic quirk of Unix happens to hide this fact. - Hiding them helps with the clutter, but we really shouldn't be hiding them at all. A better way: - Have one config directory in $HOME, with one subdirectory for each app, where it can write all it wants. So I might find I have a tree like this: /home/icculus/Configs/Subversion /home/icculus/Configs/DBUS/Config /home/icculus/Configs/DBUS/Keyring /home/icculus/Configs/Mozilla Thunderbird/Address Book /home/icculus/Configs/Mozilla Thunderbird/Extensions We can call it "Configs" or whatever, but it should probably be user-visible (that is, without a prepended '.'), be standardized, and allow apps all the space they want in their own folder under this root. The good news about this idea is that, when completely ignored, nothing breaks. We don't have nearly the pain that Windows suffered in trying to get apps from 1995 to stop writing to their installation directory. Basic Unix goodness: systems with multiple users that needed unique configs and had no write permission to the app's directory removed the need to ever shake out that painful problem. This is much less painful; if we wanted to change where we write app data, and everything gets updated except that Loki game from 1999, all your apps keep working well enough. Instead of a technical problem, you are left with some apps that are just "badly behaved" at worst. The other good news: we have the luxury of keeping things simple. I haven't checked MSDN, but there seem to be several places where user config data goes. Any could be correct, I suppose. There are system APIs for this, but I swear I end up searching several folders with Explorer when I need to find them. Mac OS X sort of overengineered something like I'm describing (and there are still holy wars that match the vi vs. emacs thing about whether your program should put crap in "~/Library/Application Support" or perhaps "~/Library/Preferences" instead. A new solution can just pick one place. And one last piece of good news: everything you care deeply about is open source. All the legacy apps can be updated, leaving only a handful of binary-only apps writing in your home directory, where they'll continue to work. To do this properly, though, we're going to have to fix a LOT of legacy code. My proposal looks like this: add a library that tells apps where to store config data. This could, in theory, be added to glibc, but for the sake of compatibility with existing systems, it works better to make it external. The library, in its entirety, looks like a less naïve version of this: char *get_pref_path(const char *appname, char *buf, const size_t len) { if (snprintf(buf, len, "%s/Config/%s/", getenv("HOME"), appname) >= len) return NULL; return buf; } This lets us offset localization issues to a system component, and future-proofs us, in case we want to make this something else later (hey, maybe Apple _was_ on to something with all those subdirs...). And an app that wants to use it looks like this, but with error checking: char buf[PATH_MAX]; get_pref_path("MyApplicationName", buf, sizeof (buf)); strcat(buf, "Preferences"); /* yeah, yeah... */ FILE *io = fopen("Preferences", "rb"); /* now use (io) like you would if you opened ~/.appname, like before. */ Bonus points if you dlopen() the library and resort to ~/.appname if it fails to load. Existing apps would need to be updated, and there are a lot of patches to be made, but the patch to any given app is easy enough. Extra credit for wrapping legacy binary-only apps in something that catches the open() call to the wrong file and redirects it, so Rune thinks it is writing in the ~/.loki/rune directory, but in fact it's writing into ~/Config/Rune instead. What do you think? Is this a silly idea?