darrell at grumblesmurf.net
Thu Oct 9 12:05:01 EDT 1997
David McNett <nugget at slacker.com> writes:
> If we were as concerned with source availibility as a method of
> security like you seem to think, do you really expect that we
> would have gone to the effort of retaining support for the V1
> clients? Let me remind you that the V1 client source code is
Let me remind you of your own post:
Subject: Re: Bunda?
Date: Thu, 02 Oct 1997 11:41:13 -0500
Let this be an example for anyone who has in the past argued that
we should release the source code to the V2 clients. This was a
massive spam of V1 blocks and has been pulled from the logs and
Which means you yourself have at least implied that this is the
> solution, however. One was fast, the other had better features, and
> neither was as stable as the third. This was a horribly confusing
> situation for both experienced crackers and potential crackers as well.
This is an organizational issue. There are dozens of programs of
far, far more importance that allow open development. Patches
are accumulated and made into releases by a core group of people.
BIND, INN, PostgreSQL, *BSD*. These groups have no problem with
co-ordinating unified releases with patches made my multiple
> team. May I politely point out that were it not for the cohesive
> and very talented coding team and the single code base, there is no
> way we would be able to have the divirsity of platform support that
> we have, nor a consistant versioning scheme. These are all Good Things
May I politely point out that if it were not for a closed and
un-communicative coding team, there are dozens of features that
people have been clamoring for that would have been added long
> Take a moment to imagine how confusing and less effective we would be
> now if there were four or five current clients for each platform, each
You're right that would be confusing, but there's *no* reason it
will be like that. It's really as simple as "Please email
patches to new-stuff at distributed.net," then the core developers
can look it over, decide whether or not use it, then integrate
and test it. It's not brain surgery.
> with a barely-portable and non-integrated code base. None of the
> platforms would have compatible buffer files, making the management of
> a mixed-platform site much more difficult. Some clients, of course,
Oh come on, that's just silly. Do you see ten different versions
of sendmail out there all using different queue formats? Are
there 4 different versions of BIND, each with different config
> and moved on to spend his time playing Ultima Online. There wouldn't
> even be a single distribution site, and keeping track of the current
> versions for all you machines would rely on combing web sites and
> following the mailing list traffic. This is exactly where we were headed
> (and fast) prior to the consolodation of the development effort.
Then you were poorly organized.
> Perhaps a better approach would have been to contact one of the coding
> team and expressing your interest in porting the client to Java.
When I sent e-mail about doing SPARC optimizations, I never got a
> o Your brash and baseless accusations are founded in the misconception
> that the source is not available. Feel free to download the V1 client
> source from our ftp site. We'll even help you figure it out if that
> is necessary.
I want personal proxy source. I would like to hack it to work
behind a firewall, since my firewall is unreliable. Ooops, can't
download that, can I?
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5