Mi ankaŭ ŝatas uzi na “ri” kaŭ “gi”.

in my case I have a master and a slave with the same conf. with internal and external views. but my slave get it’s external zone files from the master’s internal cause I have only one interface and this one is in internal so the slave dns can only get zone files from internal view

Thanks

The tricky part about configuring a slave in this case is that the master-slave replication happens at the DNS-protocol level, so the views are not transfered. But, it is very simple to have an external slave, I’ve done, that just syncs out the external view, or an internal one that just syncs out the internal view.

When I did this kind of install, we didn’t care about the internal slave because if the master was dead, DNS was the less important of our problems.

Now, if you want to replicate both parts, I’d like into having a slave with views being internal and external, both slaves, replicating from the master’s internal and external IPs respectively. And again, I have done this a long time ago and I may be totally mistaken. If you have any specific error, just post it and I’ll try to analyze it.

Hope it helps.

and the problem now is how to configure the slave

Everything else though can safely be switched out without any penalty. Don’t like Django’s template engine? Import something else and use it - Django won’t get in your way, and you won’t find that other parts of Django you wanted to use stop working. Don’t like Django’s Atom feed support? It’s an optional extra: you can roll your own, and again you won’t be penalised for it.

Likewise, if you want to reuse parts of Django for desktop applications you can do so - just import the bits you need from the Django namespace and call django.conf.settings.configure to set any options that those components need.

Loose coupling of components has been a key design principle of Django since the very start, precisely because we knew that some problems we wanted to solve wouldn’t be best solved by the default Django pieces. Check out chapter 1 of the Django book for more on this.

Just keep the code as something.lisp and have a shell script pointing to clisp, cmucl, lush, whatever. I prefer clisp, mainly because it works nicely with SLIME.
You could install all the implementations in the Ubuntu repositories and not feel a twinge on today’s hard drives.
They’re not THAT big, and it’s not nearly as bad as the first time a KDE user installs a GNOME program!

Why package it into a binary if it’s going to be problematic (size or something else) unless you’re not giving up the code?

http://groups.google.com/group/universal-programming-language/