First, WebKit does not power “nearly every relevant browser and engine used today”. WebKit does have the mobile space locked up: Android, iOS and WebOS all use WebKit for their mobile browsers. Windows Phone 7 does not. However, on the desktop, WebKit is a distant third. Trident (the IE rendering engine), and Gecko (the Firefox rendering engine) both have a larger share of users than WebKit. Matt’s statement is misleading at best.

Secondly, there was no mention at all of where WebKit came from. It was not born in Cupertino. WebKit was forked from KHTML and KJS, part of the KDE project (yes kids that’s linux). Matt linked to the first changeset in the WebKit repo, here’s the 4^th changeset, with a pile of KHTML code.

There is no doubt that WebKit is the best open source rendering engine out there, and Apple did most of the work to make it that way. Here’s my nod to the KDE project for getting that all started, since neither Drance or Gruber gave any props.

$ sudo aptitude install ia32-libs lib32asound2 lib32gcc1 lib32ncurses5 lib32stdc++6 lib32z1 libc6 libc6-i386

I have only tested this on Jaunty, so I can’t promise it works on earlier releases, but it’s lots easier than the manual unpacking stuff on Adobe’s page.

1. Get Python setuptools if you don’t have it already. Zenoss Plugins requires setuptools in order to run.
2. Download Zenoss Plugins from SourceForge and put them on your OpenBSD machine.
3. Extract the files. You’ll have a Zenoss-Plugins-2.0.4 directory.
4. Download openbsd4.py and put it in the Zenoss-Plugins-2.0.4/zenoss/plugins directory.
5. Run sudo python setup.py install
6. Test it out by running zenplugin.py cpu
This OpenBSD plugin supports the following commands:

$ zenplugin.py cpu
$ zenplugin.py mem
$ zenplugin.py disk [mount_point]
$ zenplugin.py intf [network_interface]

I have taken the liberty of assigning the copyright for this script to Zenoss, Inc. in hopes that they will include it in the next release of Zenoss Plugins.
Happy monitoring.

First, get the necessary development packages installed:

$ sudo apt-get install build-essential cmake kdebase-dev kdelibs5-dev libplasma-dev kdebase-workspace-dev subversion

There is quite a bit of stuff to download and install here, so it’s gonna take a few minutes. After it’s done, get cloudcity out of subversion:

$ svn co https://cloudcity.svn.sourceforge.net/svnroot/cloudcity

This will make a directory called `cloudcity` wherever you are.

$ cd cloudcity
$ bash configure

Yes the configure script needs bash….. it will likely break if you just do `./configure`

$ cd build
$ make

It will compile, and you’ll see lots of warnings.

$ sudo make install

Now you can go to System Settings and Bespin will be a choice for window decorations and widget styles.

Enjoy.

class Person < ActiveResource::Base
site = http://api.example.com
end

Three lines of code makes a proxy class for a remote service, ActiveResource dynamically figures everything else out.
I needed some Java code that could consume RESTful resources in a Rails application. I looked around to see if I could find any code that would do this for me. I found Restlet, which looks like a pretty good server side framework for writing and publishing restful services, but I need the client side of that. So I decided to start a new project called jactiveresource, which is a port of ActiveResource to java. Because java is statically typed it won't be quite as easy as it is in ruby, but I think we can get close. This weekend I stood up a site to host it, and got the first bits of code working. Stay tuned....

Be output format agnostic

Template engines are most commonly used to produce SGML and it’s derivitives, XML and HTML. However, most applications of any substantial size have a need to generate other forms of output, like email messages, or SMS messages, CSS, JavaScript, or (heaven forbid) dynamic SQL. if your template engine is based on XML tags, it makes it kinda hard to generate other kinds of output. So why not use two template engines, one for SGML/XML/HTML and one for other stuff? Genshi is one of the better examples of this approach. They have a single engine that can support two different template syntaxes; one based on XML, one that isn’t. But isn’t it smarter to have a single template syntax that can gracefully handle any kind of output?

Looks

How it looks matters. The templates should be pretty, and the output should be pretty, and the template should look similar to the output. For example, HAML is pretty, and the output is pretty, but the template doesn’t look much like the output. Velocity templates look OK, the output looks similar to the template, but the output is ugly, it’s darn near impossible to have a nicely indented template and nicely indented output.

Speed

The engine has to be fast. It doesn’t make much sense for your application to spend a huge percentage of it’s time rendering a display. That should be the easy part of your application. I know that CPU and RAM are cheaper than they have ever been, and I believe in horizontal scalability, but I also believe in clean, fast code. XSLT is great at a lot of things, but it is _so_ slow.

Code does not belong in templates

We are talking about a template engine, not a compiler. You should not be able to put “code” in your template. This is one of the things I hate about PHP, JSP and ERB. Even though you shouldn’t, you can put any hunk of code you want into your template. PHP is a fairly robust object oriented programming language, but at it’s roots, it was a template tool, and I can put any chunk of code I want into my “template”. If your template language can handle exceptions, or has the notion of subclassing, then it isn’t a template, it’s a programming language.

Logic does belong in templates

There is a place in a template engine for making decisions, just not complicated ones. Looping constructs, conditional statements and variable assignment are all perfectly acceptable things to do in a template. Lots of template engines have this right, with just the right number and function of their template commands. ClearSilver, Velocity and Smarty are good examples of the proper scope of implementation.

Allow definition and calling of macros

I am a firm believer in not repeating myself. The template language should let me define macro’s or snippets or whatever you want to call your reusable hunks of template. The engine should allow for some kind of include directive, so that my commonly used macros can live in a separate file and be accessed from a number of different templates. JSP tag libraries are exactly the right idea, although perhaps carried a bit far.

Can be processed to an intermediate representation for effeciency purposes

We would call this compiling your template, but that would make people think that you can put code in your template. And that is wrong. But there is nothing wrong with making it fast. Cheetah does this, and so does Smarty. Cheetah’s way is better, because processing to an intermediate representation for effeciency purposes (compiling) is a development activity, not a run-time activity. In some languages the interpreter is the compiler (Python and Ruby), but that’s no excuse to do something dumb like compiling at run-time. On a related side note, optimizing runtime performance is a worthwhile and encouraged activity (say what you want about Java, but the HotSpot Virtual Machine is dang cool), and yes, I’m aware that these are essentially the same activities.

Support layouts

And don’t be backwards. Include != layout. Rails has a very nice layout facility. It essentially let you “include” the changing content, instead of “including” the static content. The genshi method works, but isn’t quite as elegant; XML is too verbose to really be elegant.

I assume you already have a working dhcpd configuration for your single server, if you don’t, then you can get a basic DHCP configuration from the OpenBSD FAQ.

You need ISC’s DHCP server (at least version 3), to do DHCP failover. As of OpenBSD 4.1, they ship version 2 by default. You can get version 3 out of the packages tree by installing isc-dhcp-server-3.0.4p0.tgz. It installs itself into /usr/local, so if you want to view the man pages, you have to do something like:

export MANPATH=/usr/share/man:/usr/local/man

otherwise, you won’t see the new man pages for the config files.
Once you have it installed, you need to get it configured to run at startup. I did it by adding the following lines to my /etc/rc.conf.local file:

# turn on dhcpd3
dhcpd3=YES
dhcpd3_flags="-pf /var/run/dhcpd.pid"

I then added some stuff to my /etc/rc.local file:

# ISC dhcpd3 with failover configured
if [ X"${dhcpd3}" == X"YES" -a -x /usr/local/sbin/dhcpd -a -f /etc/dhcpd.conf ]; then
  touch /var/db/dhcpd.leases
  if [ -f /etc/dhcpd.interfaces ]; then
    dhcpd_ifs=`stripcom /etc/dhcpd.interfaces`
  fi
  echo -n ' dhcpd'
  /usr/local/sbin/dhcpd ${dhcpd3_flags} ${dhcpd_ifs}
fi

This will get the new version of DHCP started at boot time. You ought to remember to disable the other dhcpd by putting this line in your rc.conf.local:

dhcpd_flags=NO          # for normal use: ""

No that you are already to start it up, we need to get the /etc/dhcpd.conf file ready. You probably already have one configured and working. If so then just do something like:

# mv /etc/dhcpd.conf /etc/dhcpd.master

and then create a new dhcpd.conf file for your primary node that looks like this:

#
# dhcpd configuration
#
# failover definition
failover peer "dhcp-failover" {
  primary; # declare ourselves primary
  address 192.168.13.6;
  port 520;
  peer address 192.168.13.7;
  peer port 520;
  max-response-delay 10;
  max-unacked-updates 10;
  load balance max seconds 3;
  mclt 1800;
  split 128;
}
# include the rest.  This allows us to copy dhcpd.master
# between the two machines safely
include "/etc/dhcpd.master";

The method to my madness is simple. The contents of /etc/dhcpd.master can be exactly replicated between you two dhcp servers. This is where you will have all your subnets, ranges, mac addresses, etc.etc. Use your favorite method to keep them synched. The contents of /etc/dhcpd.conf are different on the primary dhcp server and the secondary. You obviously wouldn’t want to be copying them all over the place.
Some comments on the new dhcpd.conf file. The “dhcp-failover” string in the

failover peer "dhcp-failover" {

line can be whatever you want, but we’re going to use it in several other places, and it has to be the same in all of those places. You would of course replace the appropriate address and peer address IP addresses with the ones of the two servers you will be balancing.
The /etc/dhcpd.conf file on the secondary server looks like this:

#
# dhcpd configuration
#
# failover definition
failover peer "dhcp-failover" {
  secondary; # declare ourselves secondary
  address 192.168.13.7;
  port 520;
  peer address 192.168.13.6;
  peer port 520;
  max-response-delay 10;
  max-unacked-updates 10;
  load balance max seconds 3;
}
# include the rest.  This allows us to copy dhcpd.master
# between the two machines safely
include "/etc/dhcpd.master";

Notice the changes from the primary config file. The addresses and peer addresses are swapped, and there a couple of missing config lines, that must not be present..
The final step is to modify our /etc/dhcpd.master file so that it knows that it should be failing over. Here is a small snippet from mine:

subnet 192.168.13.0 netmask 255.255.255.0 {
  option routers 192.168.13.1;
  option broadcast-address 192.168.13.255;
  pool {
    failover peer "dhcp-failover";
    deny dynamic bootp clients;
    range 192.168.13.32 192.168.13.47;
  }
}

The only new thing here is the failover peer line. The string there needs to be the same one that we used in our /etc/dhcpd.conf file.
That’s it. Now to test it out.
You can fire up the server and prevent if from forking and logging to standard out by doing something like:

# /usr/local/sbin/dhcpd -pf /var/run/dhcpd.pid -d -f xl0

You would of course replace “xl0″ with the interface on your machine you want the server to listen on. Look for error messages, etc. If things are going right, you should see something like this:

Internet Systems Consortium DHCP Server V3.0.4
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Wrote 0 deleted host decls to leases file.
Wrote 0 new dynamic host decls to leases file.
Wrote 8 leases to leases file.
Multiple interfaces match the same subnet: xl0 carp0
Multiple interfaces match the same shared network: xl0 carp0
Multiple interfaces match the same subnet: xl0 carp2
Multiple interfaces match the same shared network: xl0 carp2
Multiple interfaces match the same subnet: xl0 carp3
Multiple interfaces match the same shared network: xl0 carp3
Listening on BPF/xl0/00:01:03:d6:82:a1/192.168.13/24
Sending on   BPF/xl0/00:01:03:d6:82:a1/192.168.13/24
Sending on   Socket/fallback/fallback-net
failover peer dhcp-failover: I move from normal to startup
failover peer dhcp-failover: peer moves from normal to communications-interrupted
failover peer dhcp-failover: I move from startup to normal
failover peer dhcp-failover: peer moves from communications-interrupted to normal
pool 80f93200 192.168.15/24 total 16  free 16  backup 0  lts -8
pool 80f93100 192.168.13/24 total 16  free 8  backup 7  lts 0
pool 80f93200 192.168.15/24  total 16  free 16  backup 0  lts 8

Now you can try to get a client on your network to request an address, and you should see it happen. If that all works right, then you should try rebooting your machines, making sure that everything comes up propertly on startup. You can now experiment with taking one or the other server down, and you should still be able to DHCP properly.

First, get the xntpd package for OpenBSD from your favorite mirror. OpenNTPD is fine, but the lack of the ntpq command is enough for me to not use it. Once you have xntpd installed, we need to get it set up so it will run when you boot.

Add the following lines to /etc/rc.conf.local:

# flags to get xntpd started
xntpd=YES
xntpdate_flags="pool.ntp.org"

Then add the following to /etc/rc.local:

# xntpd stuff
# run ntpdate prior to ntpd
if [ $securelevel -le 1 -a X"${xntpdate_flags}" != X"NO" \
-a -x /usr/local/sbin/ntpdate ]; then
echo -n ' ntpdate'
/usr/local/sbin/ntpdate -b ${xntpdate_flags} >/dev/null
fi
if [ X"${xntpd}" == X"YES" -a -x /usr/local/sbin/ntpd \
-a -e /etc/ntp.conf ]; then
xntpd_flags="-p /var/run/ntpd.pid"
if [ $securelevel -ge 1 ]; then
xntpd_flags="${xntpd_flags} -x"
fi
echo -n ' ntpd'; /usr/local/sbin/ntpd ${xntpd_flags}
fi

Now that it will start and run, we just need a config file. OpenNTPD uses /etc/ntpd.conf as it’s configuration file, xntpd uses /etc/ntp.conf. Here’s my ntp.conf file from one of the machines in the cluster:

# /etc/ntp.conf:  Configuration file for ntpd.
#
logfile         /var/log/ntpd.log
driftfile       /etc/ntp.drift
keys            /etc/ntp.keys
# set up our keys for run time modification
requestkey 137
controlkey 137
trustedkey 137
#enable auth
# time servers
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
# use local system clock if all else fails
server 127.127.1.0 iburst
fudge 127.127.1.0 stratum 11
# restrict who can get time from us
restrict 127.0.0.1
restrict 192.168.13.0 mask 255.255.255.0
restrict default nomodify nopeer

Note how I am using pool.ntp.org as my time servers. This gets me a randomly assigned time server each time I boot the machine. The config file on the other machine in the cluster is exactly the same, except that I am not using the ntp pool. I found several restricted time servers, and have acquired permission to utilize their services. This means that I will be sure and have different time sources on each of my time servers.
Notice also how I have the:

# use local system clock if all else fails
server 127.127.1.0 iburst
fudge 127.127.1.0 stratum 11

section in the file. This makes it so that if I lose internet connectivity, this time server will look at the local clock for a time source, so at least all the machines on my network will drift time together. The other machine in the cluster has it’s local clock set to stratum 10, so there will only be one “master” local clock.

All the clients on my network now have a simple configuration file to use these two new time servers. It looks like this:

# /etc/ntp.conf:  Configuration file for ntpd.
#
logfile         /var/log/ntpd.log
driftfile       /etc/ntp.drift
keys            /etc/ntp.keys
# set up our keys for run time modification
requestkey 137
controlkey 137
trustedkey 137
#enable auth
# time servers
server tick.kotfu.net iburst
server tock.kotfu.net iburst
# use local system clock if all else fails
server 127.127.1.0 iburst
fudge 127.127.1.0 stratum 13
# restrict who can get time from us
restrict 127.0.0.1
restrict 192.168.13.0 mask 255.255.255.0
restrict default nomodify nopeer noquery noserve

Now I have my own redundant, reliable time services for my home network.