Cutlery has changed significantly, even in the 700 year period we were discussing:

Slate article

I'm not sure how it affects your argument, but perhaps you should try to find an example of something that hasn't changed significantly in the past 700 years.

Much less, I'd say.

https://www.youtube.com/watch?v=niJWmdnxEFc

Actually, we did have a look at PowerDNS. I did a project with it at my last job. PowerDNS is not perfect, but it has a few good things that we want to also have in BIND 10. The generic back-ends is one, the fact that the code can be understood and fixed by a skilled programmer within a few hours instead of a few days is another. I also like a few "nice" things from the command line tools - although of course some choices are a bit broken.

While administrators will have to choose the best DNS software to fit their needs, I don't actually view it as a competition. In fact, a diverse code base is good for the Internet ecosystem. It limits the impact of bugs, exploits, and general design artifacts.

But be sure to use BIND 10 when it's ready for production. ;)

[ disclaimer - I am the BIND 10 project manager ]

One of the ideas of BIND 10 is to allow modules to be added to an already running system. Also, we want administrator tools to be able to ask the modules themselves what functionality is available. This allows relatively simple administrative tools to work with changing systems.

In order to do this, we need to have a mechanism for modules to report their capabilities. So, for example "I have a command called 'notify' which can be used to send a notify to my secondary servers, and it takes the parameter 'domain' which specifies the domain to send it from, and an optional parameter 'secondaries' which you can use to limit to a set of secondary servers".

The test code here exercises this generic capability.

[ disclaimer - I am the BIND 10 project manager ]

http://tech.slashdot.org/comments.pl?sid=1589160&cid=31548122

The design for BIND 10 allows for generic back-ends. We implemented SQLite as the first one, simply because it was the easiest. One of our early goals for the second year of development is to support additional database back-ends (we call them "data sources"), including MySQL, PostgreSQL, and an in-memory 'database' (for performance-critical environments).

In the end we'll also support more exotic back-ends, like BDB, LDAP, directories, and possibly even the tinydns data format.

[ disclaimer - I am the BIND 10 project manager ]

Basically, someone once wrote a convincing text which says: Release Early, Release Often.

It's a release in the sense that we wanted to make it widely available for people to see what ideas we are playing with, and to get feedback and participation.

[ disclaimer - I am the BIND 10 project manager ]

Joel has a lot of followers, but you shouldn't take what he says as holy writ. In fact, this very article is all about how we should still be using the old Netscape browser and not have started this crazy Mozilla project... you know, the one that resulted in Firefox?

I view the BIND 10 project in some ways as the DNS version of the Mozilla project - it is an ambitious rewrite, and will take a while to reach maturity. Luckily BIND 9 is still an excellent piece of software, so we have the luxury of enough time to get there.

BIND 9 is 10 years old, and was designed and implemented when the computing and Internet worlds were different than they are today. The architecture of BIND 9 - a monolithic, multithreaded program - does not lend itself well to today's DNS needs. So a new architecture is needed.

Originally we had planned on reusing a lot of the BIND 9 code. After all, like Joel says, it has been field-tested and is known to be high-quality in handling real-world DNS needs. However, the BIND 9 code has very, very high coupling. In order to make a small change or use an excerpt of code, you need to use the BIND 9 memory management system, and the BIND 9 task model, and the BIND 9 socket library, and so on. One of the reasons that BIND 9 needs to be rewritten is to make it possible to use the parts of the software you need to solve your problems without having to understand the entire system.

My theory is that the architectural problems would have been resolved over the decade of active use for BIND 9, as users submitted their patches and the developers periodically refactored the code. Unfortunately the BIND 9 project does not have an active community, either as developers or users. There are lots of people using BIND 9 (surveys put BIND 9 at about 80% of DNS servers on the Internet), but they have no group identity as BIND 9 users, and the direction and development of the software comes almost entirely from within ISC. This means it is an open source project that has resources limited in ways similar to proprietary software. If there was a BIND 9 community, then I think the software would have evolved with the times and a rewrite would not have been necessary.

For BIND 10, we want it to be an actual open source project, not just open source software. We have tried hard to be open and transparent about how BIND 10 is developed, and are trying to make it easy to participate in BIND 10. Hopefully this will be the last time a major rewrite is necessary, and the code base can evolve in any direction it needs to in the future, by maintaining a good connection with the people who actually use it.

[ disclaimer - I am the BIND 10 project manager ]

There is no "BIND 10 committee", but we do have weekly conference calls. Minutes from these are published on our Trac site:

https://bind10.isc.org/wiki/WeeklyConferenceCalls

[ disclaimer: I am the BIND 10 project manager ]

The existing BIND 9 mechanism are not hard for your small domains that change rarely, but they don't work if you have tens or hundreds of thousands of domains that you manage, which change on a frequent basis. While this may not be interesting for you, there are many organizations for who this is a daily reality, and BIND 9 doesn't work well for them.

There are also organizations that have existing provisioning systems for large deployments, and would like their DNS to be better integrated... something today that usually means running Windows Active Directory or similar proprietary solutions.

There are also people running clusters of DNS servers, for increased performance, reduced network latency, and hardware redundancy. Managing "a few simple test [sic] based config files" across tens of computers distributed around the globe is a non-trivial task.

BIND 10 will continue to support text files for people who are comfortable with that, but will also have better mechanisms for people who prefer more modern ways.

[ disclaimer - I'm the BIND 10 project manager ]

The problem is that this is a shorthand phrase. in the US people mean 'take it off the table', where presumably it is already being considered. In her majesty's islands people mean 'put it on the table for future consideration'. The real problem is that verbing weirds language.

The problem with Scotland is that you'd have the locals constantly attacking all the scientists and giving them a damn good kickin'.

OTOH, we could hope for an ideal solution, where a black hole is formed, but then evaporates just after it has consumed the matter in a sphere extending to Hadrian's wall.

I'm not sure how Europe normally handles vaccine liability, but I'm sure a /.er can fill us in.

I have no idea how liability works here. Contrary to the US, it's not an important question.

This may be because our governments haven't been so badly owned by corporate interests. Although that's just a pet theory of mine. ;)

ext3 is also a journaling file system. Perhaps you meant ext2?

I'm not sure you want to run fsck on an unclean shutdown on your nice big database partition either. Maybe using a journaled file system isn't such a bad idea. Also, it can be much faster for certain workloads:

http://en.oreilly.com/oscon2009/public/schedule/detail/8432
http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide

Note that while sequential writes could be much slower with journaled file systems, random writes were typically much faster. This is what one would expect, given how journaled file systems work.