The script is public domain, meant to be run interactively and provided without any warranties or batteries. It may or may not do bad things to your house and your cat, but mostly it just updates Chromium.

So, after a quick look at the even more arcane options, I’m back with PyQt4. Took me a while to figure layouting in Qt Designer out, just to notice that I still can’t build a working distribution with py2app. I’m really looking forward to when everything will be 64bit and we don’t have this multilib/universal pile of crap anymore. Yuck.

My total whackjob of a solution right now is to mutilate a PyObjC-Cocoa Xcode template into running a Qt4 app. It’s not pretty and will probably break sometime in the future, but right now I just want to get some .app out there. Qt also gives me platform independence, which I like.

I’m currently working on having nagify save Nagios data into a local sqlite database so I can generate stats from it later. Those stats will then be used in a fullscreen view mode designed for large displays. At least that’s the plan.

The original purpose was to display Growl notifications for Nagios alerts, but nagify is designed to be very flexible and can be expanded to output notifications in pretty much any way.

Please report any bugs to the issue tracker at github.

Update: 1.0.1 is out, now also available via the Python Package Index.

<key>PBX-python-Icon</key>
<array>
<string>py</string>
</array>

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.

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>

pages = Page.objects.all()
[...]
  url(r"^pages/(?P<slug>.*)$", object_detail, { "queryset" : pages }),

from myapp.pages.models import Page

pages =  Page.objects.all()

def add_pages():
    return { "pages" : pages }

queryset = queryset._clone()

from django.db.models.signals import post_delete, post_save

class CachedQuerySetManager:
    """
    Manages a list of querysets that are automatically updated
    whenever an object is added to or deleted from one of them.
    """
    def __init__(self):
        self.querysets = {}

    def __getitem__(self, key):
        return self.querysets[key]["queryset"]
    
    def add(self, model, manager = "_default_manager"):
        self.querysets[model] = {
            "queryset" : getattr(model, manager).all(),
            "manager" : manager,
        }
        post_delete.connect(self.update, sender = model)
        post_save.connect(self.update, sender = model)
        
    def remove(self, model):
        post_delete.disconnect(self.update, sender = model)
        post_save.disconnect(self.update, sender = model)
        self.querysets.__delitem__(model)
    
    def update(self, sender, **kwargs):
        self.querysets[sender]["queryset"] = \
         getattr(sender, self.querysets[sender]["manager"]).all()

cached_querysets = CachedQuerySetManager()

from myapp.pages.models import Page
from myapp.util.query import cached_querysets

cached_querysets.add(Page)

def add_pages():
    return { "pages" : cached_querysets[Page] }