[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hybrid 7 OFTC IRC Daemon - experimental package



Dear Mr. Stone:

Please stop being a jerk. This isn't a "let's shit on anything related
to Freenode" mailing list.  Andrew Suffield has put a lot of work into the
IRC daemon currently used by OPN, and from my perspective as a user of
OPN, he has been doing an excellent job.

I would enjoy it if you could stick to reasoned debate, leave the name
calling and slurs at home, and discuss the respective merits of these
IRC daemons on a more appropriate mailing list.

Jonathan

On Sat, Oct 26, 2002 at 01:07:29PM +1000, Daniel Stone wrote:
On Fri, Oct 25, 2002 at 10:14:40AM +0100, Andrew Suffield scrawled:
Which was, 99% of the time, hopelessly out of date; it took me *three
weeks* to get the message across that the umode -o issue had been
fixed; in the end I had to edit the private MOTD to embed the notion
into people. On average, such bugs were actually fixed within hours of
their being reported (which could be as much as a week after they were
discovered, thanks to some people who would rather complain on IRC
than send mail), the various staff channels just didn't stay abrest of
current status.

What about UNKLINE? That stayed unfixed for absolutely ages, and then
there was the huge configuration propagation thing that caused you to
roll back to ircu in the first place ... my point is that you considered
that release-quality code, so I doubt dancer's *current*
"release-quality" code is going to be a hell of a lot better.

As for johnson, surely you had access to change the topic, no?

My point is that I fear for people using this on other networks. Not
only is its code of questionable quality (it started off as hybrid6, and
then went rapidly downhill from there), but you're rarely forthcoming on
anything. If OPN staff can't even communicate with you to find out
what's going on (like when you rolled back to ircu), how the hell are
people from *different* IRC networks going to do so?

Plus, commands which could only be accessed by privileged users are
not serious issues, so they didn't get audited before release.

Not to mention: real software has bugs, deal with it. Especially when
there's no decent way to test it (hybrid, in all forms, resists unit
testing).

I regard any bug that takes down several leaves and a hub as pretty
serious. If you don't, then that just proves my point.

> Most IRC daemons have been proven to work; dancer has been proven to
> fail.

FUD != proof.

I present OPN/Freenode/whatever it's called this week's severe issues in
transition to dancer-ircd, especially with things like UNKLINE, umode
-o, OPERWALL, and more as proof. Oh, and that really funny bug where the
entire /map was exposed to absolutely anyone because you left out a line
in a change (or was it a typo? Can't remember), and didn't bother to
test it; that was really funny.

Since I actually *do* analyse such matters to identify stability
issues and fix them before they become serious, I know that dancer 1.0
on OPN, even with the kludges to work around hybrid-6 braindamage, now
(for the past 6 months or so) gets better connection and server uptime
than either a) the old ircu-dancer on OPN that it was created to
replace, or b) hybrid-6 on efnet.

dancer-ircd has certainly improved since then, thank god. As you say,
"FUD != proof", or do different standards of proof apply here?

--
Daniel Stone 	     <daniel@raging.dropbear.id.au>             <dstone@kde.org>
Developer - http://kopete.kde.org, http://www.kde.org
Proof BitMover are community-focussed:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103384262016750&w=2



--
                    Geek House Productions, Ltd.

 Providing Unix & Internet Contracting and Consulting,
 QA Testing, Technical Documentation, Systems Design & Implementation,
 General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2

Attachment: pgpBVySmzlWH6.pgp
Description: PGP signature


Reply to: