Death of irrtoolset?

Jonathan Day imipak at yahoo.com
Sat Oct 10 23:46:54 UTC 2009


--- On Fri, 10/9/09, Nick Hilliard <nick at inex.ie> wrote:

> From: Nick Hilliard <nick at inex.ie>
> Subject: Re: Death of irrtoolset?
> To: "Faidon Liambotis" <paravoid at debian.org>
> Cc: irrtoolset at lists.isc.org
> Date: Friday, October 9, 2009, 11:02 AM
> On 09/10/2009 16:38, Faidon Liambotis
> wrote:
> > All in all, I don't understand this sudden change of
> heart.
> > Could you please give more details about your plans,
> especially
> > regarding ISC's position on this?
> 
> Please excuse the melodrama in that talk.  It was the
> first talk of the day after a well-attended social from the
> night before, and I deliberately set out to provide a
> modicum of entertainment, so perhaps it would be useful to
> explain my position.  It is this:
> 
> The code is unmaintainable.  Completely and utterly
> unmaintainable.
(snip)

Ok, so maintaining the existing codebase is impossible. Where does that leave us?

Rewriting the entire toolset from scratch is going to be hard work and I sincerely doubt that there'd be a whole lot of funding for it. The "if it works, don't fix it" mindset is superbly honed in the minds of bursars and CFOs when it comes to asking for funds for such projects.

On the other hand, is there an actual need to replace the entire toolset in one go? So long as none of the applications is completely broken, it would seem to make sense to roll gradually from what's there now to irrtoolset-the-next-generation.

One option would be to start by writing placeholder apps with the interfaces you want that initially do nothing more than call the existing apps and regurgitate the output. It doesn't matter that some tools will use the old, unmaintained code and some tools use the newer code, because as long as the old code works, there shouldn't be any huge difference. Let the code naturally roll over from the old to the new via user-contributed patches.

A second option is to spec out the APIs, library structure, etc, and do an ISC "winter of code" (as a play on Google's "summer of code"). Consider this - more students are looking for final-year projects and Masters material to use over Fall/Winter/Spring than are looking over summer. And undergraduates are essentially free. (The only thing you're paying for is your time to check to see if their code is usable.)

A third option would be see if you can get help on this. Ubuntu and Red Hat have coders aplenty and serious financial muscle. OpenBSD needs network tools that are bulletproof, and irrtoolset (as it stands) is clearly not that. The US Government is pushing cybersecurity, but you can't have that if fundamental tools aren't secure. Japanese ISPs were major sponsors of IPv6 development - for code and cash, perhaps they'd be willing to provide some help with this. Sweden is also highly connected and must therefore have a need for good backbone support tools.

The shortage would not appear to be in the number of options you can shoot for, the shortage would seem to be in what you can do without calling in the heavies.

Jonathan Day



      



More information about the irrtoolset mailing list