overall, your argument is just a recapitulation of DJB's old favourite "your way of doing things is completely wrong, you must throw it all away and change to my One True Way". that may be enough to convince DJB groupies, but it's not enough to convince me. in fact, it pisses me off and makes me extremely reluctant to even experiment with his software.
feel free to dismiss all of the following as "just a question of habit" because i'm absolutely certain that none of it will make any impression on you. On Wed, Nov 20, 2002 at 01:51:16PM -0200, Adriano Nagelschmidt Rodrigues wrote: > Craig Sanders writes: > > if djb actually gave a damn about providing a viable replacement for > > bind then he'd climb down off his pedestal and implement native > > support for bind-style configuration and zone files in djbdns. not > > a translator, not a converter, but native support for the existing > > files. > > I think the idea here is to have a file format that can be easily > updated by scripts. For example, a script can monitor a cluster of web > servers and change '+' to '-' in the record of a server that is down. > > Besides, I don't think bind's file format has anything special per se. > Maybe it's just a question of habit? what's wrong with habit? there are benefits to habit - the better you know something, the less likely you are to make a mistake with it. it's also a question of documentation. Bind's format is well documented, with numerous books and HOWTOs published over the years. this documentation makes it easier to train new staff. while there's nothing "special"(*) about bind's zonefile format, there's also nothing wrong with it. there was no need to throw it out and re-invent it....especially when the re-invention is no easier to manipulate with scripts and is much harder for a human to read. (*) actually, the "special" thing about it is that it has existed for years, it is the de-facto standard, and that there are thousands of bind servers out there which use the format. these things are important, whether djb thinks they are or not. > > nobody with more than a handful of domains is going to throw everything > > away and convert to a new nameserver program that they know nothing > > about...and haven't been able to test adequately because it can't > > (won't!) read their hundreds or thousands of existing zone files. > > You can use zone transfers to convert the bind data to djbdns format. Eg: > > tcpclient dns1.panic.mil 53 axfr-get panic.mil zone-panic zone-panic.tmp > > This can be easily automated for thousands of zones. > > > i'd love him to do this. i've been wanting a replacement for bind for > > years. > > It's there already! You just have to adopt a more flexible stance. Ideas > evolve, new ways of solving problems arrive. no, it is NOT there already! i don't want to convert hundreds of zonefiles, i want to use my existing ones. i've already got tools and procedures in place for managing DNS updates, i have no intention of throwing everything away and starting from scratch. djb never wants to understand this point, but this is crucially important. existing procedures and tools have value. this is exactly the same problem as with qmail - if you want to switch from, say, sendmail to qmail, you have to throw away the entire configuration of your mail server and start again from scratch. that is why qmail failed as a viable replacement for sendmail, and that is why djbdns is failing as a replacment for bind. (postfix succeeded where qmail failed because it provided a migration path). > > unfortunately, it's the qmail problem all over again - djb sees no > > benefit at all in backwards compatibility so, IMO, djbdns is doomed > > to the same role as qmail - a good example showing the way forward > > but ultimately destined to be superceded by another program which > > learns from its successes (and mistakes!) and also provides > > backwards-compatibility. > > I question the need for obligatory sendmail backward compatibility, as > long as RFCs are respected. You are not forced to change, after all. precisely my point. i wasn't forced to change, so i didn't - i waited until a program (vmailer aka postfix) came along that provided all the benefits (and more) of qmail, that also had backwards compatibility with my old sendmail stuff. i experimented with qmail for over a year before postfix came along, and i even installed it on several mail servers (new systems on small internet gateway boxes that had no legacy config to worry about), but i had no intention of changing my existing mail servers to qmail - i couldn't afford the downtime and i couldn't afford the risk of disaster. when postfix came out, though, i switched them all (including the qmail boxes) over to postfix within 6 months....and i was able to do this because postfix provided a migration path that allowed me to do a staged transition with backwards compatibility and minimal downtime AND (most importantly!) the ability to easily revert back to sendmail if anything went wrong. first i installed postfix as a (faster, more secure) bare replacment for sendmail, without using any of it's extra features...when that proved successful, i was able to start using more and more of postfix's features. i intend to do exactly the same with dns, i'll wait until there's a decent replacement for bind that has native support for my existing zonefiles. if dbjdns implements that, then djbdns may well be that program. if not, then i'll have to wait longer for a replacement. the point here is that evolutionary change via a staged migration path is far safer and far more likely to succeed than revolutionary change that requires throwing out the old and starting from scratch. > > the successor program will also be free software, with a real free > > software license rather than djb's non-free license. > > You have a point about the license. I understand DJB's worry, though: change > the license and suddenly there will be n incompatible versions of the same > software. It would be nice to have a Unix Standard Base ;-) the many thousands of free software packages which don't have that problem would seem to prove him wrong. > You can find the reasoning at > > http://cr.yp.to/compatibility.html (actually, that's his reasoning for his weird configuration style, not for his license. his reasoning for his license quirks is even more specious) yes, i've read it. i think he's wrong. he claims that it's more important for the configuration and directory structure of programs to be 100% identical from one system to another than it is for programs on the same system to conform to the same policy. he's obviously not a systems integrator. most people couldn't care less about the configuration details of systems that they don't even use - they just want all the software on *their* system to operate in a consistent manner. > > it would also help in testing and/or migrating to djb's software if he > > tossed out his bizarre systems administration ideas and used plain-text > > config files like everyone/everything else rather than magic filenames > > inside a hard-coded directory tree to configure things. IMO, he's a > > good programmer but a lousy systems admin. > > But he uses plain text config files. And at some point, you'll need a hard > coded path. he also uses magic filenames within directories, and he uses them extensively. > > he should toss out the crappy ucspi-tcp and daemontools too - he may > > like them, but they're basically just a needless reinvention of > > inetd & tcpwrappers that provide no advantages but are significantly > > uglier to configure and use. > > You're letting old habits get the better of you. no, i just don't like djb's needless re-inventions of the wheel and i'm not particularly keen on change merely for the sake of change. i've changed the software i use many times over the years, but only when the benefits of changing significantly outweigh the disadvantages. there aren't any significant benefits of daemontools or ucspi-tcp over inetd and tcpwrappers. > inetd, xinetd and syslog are known for having security, performance and > reliability problems. > > He designed better tools and factored out common code. IMHO, the /service > scheme and supervised daemons are a better solution than the init.d > scripts. > > Once you are accustomed to it, you won't want to go back to the > traditional way of doing things. i did get used to it. i know how it works and i know how to configure it, but i still loathe it and i will use anything else in preference to it. e.g. i got rid of bind and ran djbdns for several months as a caching-only server on my home gateway box...i switched to maradns shortly after discovering its existence (after testing that it worked). i also ran djbdns for months on several web servers and mail servers to speed up resolving IP addresses in log files and to speed up RBL checks etc - i switched them to maradns too. both maradns and dbdns make reasonable caching-only servers. for me, maradns wins because of it's license and it's lack of djb weirdness. maradns isn't particularly good software, but a) it's GPL, b) it doesn't have djb's weird configuration style and c) it's adequate for the task i want to use it for. i still won't use it as an authoritative server because it isn't backwards compatible with bind zonefiles and its CSV1 zonefile format sucks. > > it's as if he reinvents stuff that works perfectly well just to make > > people conform to his strange ideas about how systems should be > > configured - throw everything out and implement DJB's One True the. > > Only the original programs he reinvented don't work perfectly well. > Far, far from it. > > We're talking about sendmail, bind, inetd, syslog, etc. aside from bind, there are replacements for all of those programs which solve their problems while still providing backwards compatibility. hopefully, bind will have a backwards compatible replacement too one day. craig -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
