Linux Conference Australia (Day 5)

Damian Conway: Keynote: Sex and Violence: Technical and Social Lessons from the Perl 6 Development Process

On long term projects it's very easy to get distracted from your goals. One way to keep people focused is to encode your goals in slogans. "Make hard things easy, and easy things trivial." or "Only Larry gets the colon" etc.
Ignore the theorists. On any project there are the people who have pet theories and will relentlessly promote them. You can't win by engaging them with rational discussion, just say "that's nice" and move on.
Don't diss project managers, they are important. Find a sucker that likes doing it and use them.
The single most important thing is to just "keep on keeping on". No matter what people say, no matter what percentage of people say they hate your project ... just keep working.

The 2.4 Linux kernel sucks at this, the 2.6 kernel is much better, especially 2.6.12+.
So long as both sides have increased their TCP buffer sizes (use the bandwidth delay product for appropriate sizing) everything else is controlled by the transmitting side.
Useful tool for calculating the theoretical maximum TCP transfer rate on a link (based on loss, latency, bandwidth etc).
NS2 is an open source network simulator which allows you to do throughput testing while tweaking latency or packet loss.

Seems to me it's probably worth waiting for MySQL 5.1 before deploying cluster.
You can use "mysql-test/mysql-test-run.pl" to easily setup a test cluster on a single server.
Data goes to different servers based on a hash on the primary key. The hash is most efficient if you have 2^N nodes.
Transactions are atomic across the entire cluster, however if a server fails in the middle of a transaction, the transaction fails.
You can do rolling upgrades, eg. stop one node, upgrade MySQL, restart and add it back to the cluster, take down the next node, etc.
You can use nbc_size.pl to examine an existing database and suggest DataMemory and IndexMemory requirements.
In 5.1 you will be able to replicate from one cluster to another cluster. Replication is done asynchronously so it's okay to have high latency links between your clusters (you could also replicate between a cluster and a single server for DR purposes though the cluster BACKUP command is what was recommended).

Still writing TCP stacks based on the memory restrictions which were present in Multics and forced the stack to exist in the kernel. Kinda silly when you consider that the memory restrictions which required that design choice in hasn't been relevant for a long time.
TCP windows are a legacy of the kernel based implementations. With kernel implementations the kernel has to track packets between the remote end and whether the local application has received the packets. This is much less stable and efficient.
Networks are now fast enough that it's moving from a communications medium to a backplane technology.
End-to-end principle is also important because it allows the net to scale. Since the edge scales with the networks growth, you don't overload your core.
You can make the changes required in three simple stages: first to the driver, then to the kernel and finally in the application. Each change can be made independently and each one results in significantly less CPU utilization.
This seems to be most applicable for routers trying to saturate huge links and for CPU constrained (embedded) devices.

Google has not been happy with Network Appliance, in fact their engineer had almost nothing to say that wasn't filled with poison.
Google are currently doing NFSv3 with Kerberos, they say it's cool. They are also eagerly awaiting NFSv4 due to the 16 group limitations in RPC.
The general consensus seems to be that "imaging" based server management tools are evil. People seem amazed that our rsync system works. However no one seem to be doing anything which is as functionally rich.
ISConf4 has been released by the infrastructures.org guys.