- I missed having an icon for Python files in TextMate, so I made one with a Python Logo on it:
You can add it to your TextMate by downloading this file and putting it unter Contents/Resources/File Icons/ within your TextMate.app folder (to open that folder in the Finder, go to Applications, right-click TextMate and choose “Show Package Contents”).
Then open the file Bindings.plist (located in the same folder where you put the .tiff) in your favorite text editor and add this anywhere directly after a “</array>”:<key>PBX-python-Icon</key> <array> <string>py</string> </array>
That’s it! Restart TextMate and you’re done.
If you’re looking for better folder icons, there’s a blog post for that, too. With the recent debate about the deletion practices in the german Wikipedia, a fork has been brought up as an option a couple of times. Right now, Wikipedia has a huge monopoly when it comes to online knowledge and a fork may be able to decentralize things a bit. While the content is under a free license, the policy governing it is not that flexible.
One of the problems is that Wikipedia is supposed to be an encyclopedia, not a system to store any and all knowledge. I wonder if it would be feasible to implement a Really Friggin Big Wiki where anyone can write about any topic. The only restriction would be that the article has to state facts in a neutral manner (citing the most dubious sources is ok, as long as it’s clear that the text in question is just the possibly biased opinion or completely insane claims of the source). No restrictions should be imposed when it comes to relevance or target audience.
Such a Really Friggin Big Wiki (maybe I should trademark that) could then be forked into an encyclopedia, a sysadmin wiki, a cookbook, … anything. Edits should be made by the general public in the RFBW and can then find their way into the subwikis where stronger moderation is imposed.
This leads to an interesting set of problems. On the technical side, people are already experimenting with converting MediaWiki XML dumps into a git repository. The problem that remains is making that data available again for web-based editing. I’ve experimented with this in the past and created a very rudimentary wiki system that used git as a backend for both read and write operations. The code sucked, but I think in principle it is the right way to go about this.
Another problem is namespacing and categorizing the data, using “John_Smith” as identifier for an article will no longer be sufficient – the disambiguation pages would be interesting.I’m looking forward to what the community will come up with and how we’ll organize knowledge in ten years. Just too bad rfbw.org is already taken. Dammit.
I’ve spent a lot of time at work tinkering around with the BCFG2 configuration management system. Here’s a neat stunt you can pull off in your bcfg2 repo to achieve great flexibility when it comes to templating.
First off, all my bundles are defined in SGenshi. Now you can obviously use <ConfigFile> and point to a TGenshi template. But you might run into a problem here: A TGenshi template always has a static owner/group/perms tuple set in the info.xml file (which is bad if you need multiple instances of the template that belong to different users). I tried working around this via an extra <Permissions>, but the default info from <ConfigFile> seems to have a higher priority (see BCFG2 bug #627).
My next shot was to use <BoundConfigFile>, which lets you inline the template in the bundle file. However, this method has a number of problems as it tends to clutter your bundle files and forces you to use XML templating for text files.
So here’s my ingenious solution: Genshi allows the use of XInclude in XML templates, but with a special twist: You can tell Genshi to parse the referenced file as a text template! So here we go:
<BoundConfigFile name="/foo/bar" owner="${owner}" group="${group}" perms="0644"> <xi:include parse="text" href="templates/foo/bar.newtxt" /> </BoundConfigFile>Remember to include the xi namespace reference in your <Bundle>.


