Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-chat-digest V5 #701

0 views

Skip to first unread message

owner-freebs...@freebsd.org

unread,

Feb 12, 2003, 7:02:57 AM2/12/03

freebsd-chat-digest Wednesday, February 12 2003 Volume 05 : Number 701

In this issue:
Re: Modelling complexity (was: Re: matthew dillon)
Re: Email push and pull (was Re: matthew dillon)
Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-)
Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-)
Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-)
Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-)
Re: matthew dillon
Re: Email push and pull (was Re: matthew dillon)
Re: Email push and pull (was Re: matthew dillon)
Re: Email push and pull (was Re: matthew dillon)
Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-)
Re: Modelling complexity (was: Re: matthew dillon)
Re: Bugzilla? (was Re: Okay, I think I need some serious introduction;-)
Re: Email push and pull (was Re: matthew dillon)
Re: Email push and pull (was Re: matthew dillon)
Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-)
Re: Modelling complexity (was: Re: matthew dillon)
Re: matthew dillon
Re: Email push and pull (was Re: matthew dillon)

----------------------------------------------------------------------

Date: Tue, 11 Feb 2003 15:11:05 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Modelling complexity (was: Re: matthew dillon)

Dave Hayes wrote:
> Terry Lambert <tlam...@mindspring.com> writes:
> > Dave Hayes wrote:
> > [ ... Blah blah blah ... ]
>
> No wonder you have problems debating. I've said none of the above that
> you've attributed. Obviously you are unable to read what I wrote
> and meaningfully duplicate it in your head. =)

I had a long message prepared to send, which refuted the naieve
assertions in your previous message, but I did not send it.

> > [ huge list of books ]
>
> Thank you.

That's not a "huge list of books", that's "two weeks worth of
reading, four if you insist on going through all the math yourself".

> >> > The technology used dictates the permissable behaviours of
> >> > the people using it;
> >>
> >> This is obviously false, since people constantly behave otherwise.
> >> Regardless, this should never be true, since technology is a servant,
> >> not a master.
> >
> > Tell that to gravity.
>
> You are telling me gravity is a technology?

No, I'm telling you the constraints of the technology available
for use have the same effect on its application as the laws of
physics have on people.

For example, if all mail servers will only accept 5 messages
per hour, and you are constrained to send outbound messages
through your ISP's mail server, then no matter what kind of mail
client you have, the maximum number of messages you will ever be
able to send is 5 per hour, period. It might as well be a law of
physics, as far as you are concerned.

- -- Terry

------------------------------

Date: Tue, 11 Feb 2003 15:16:23 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Email push and pull (was Re: matthew dillon)

Rahul Siddharthan wrote:
> But I can now block known spammers from even trying to connect,
> because they can no longer relay their mail and thus can't hide their
> tracks.
>
> Equally important, the law can catch up with the spammers because they
> can't hide their tracks.
[ ... ]

If the intent is to stop SPAM'mers, then there are easier, less
intrusive protocol modifications available, that can work, even
if some people never update their mail servers.

- -- Terry

------------------------------

Date: Tue, 11 Feb 2003 15:21:54 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-)

"Gary W. Swearingen" wrote:
> The Hermit Hacker <scr...@hub.org> writes:
> > What needs to be done is various 'cut off points' need to somehow be
> > established ... for instance, anything dealing pre-4.x should be closed
> > ...
>
> How about putting "policies" in the PR Guidelines something like this:

[ ... time-based, committer interest-based policies ... ]

> The numbers might be too small.

The problem with this approach is that it's possible to ignore
a PR to make it go away, without the underlying problem being
repaired/acknowledged.

- -- Terry

------------------------------

Date: Tue, 11 Feb 2003 21:06:14 +0200
From: Giorgos Keramidas <kera...@freebsd.org>
Subject: Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-)

## Redirected to bugbusters, the PR handling team.
## Please honor the Mail-Followup-To and Reply-To headers.

On 2003-02-11 10:28, "Gary W. Swearingen" <sw...@attbi.com> wrote:
> How about putting "policies" in the PR Guidelines something like this:
>
> PRs older than 2 years shall be marked "suspended", where "older" is
> measured from the last PR log activity which a committer deems to
> indicate that the PR might still be valid for any OS version.
>
> (This allows PRs to be "refreshed".)
>
> PRs older than 4 years shall be marked "closed" if 10 minutes of
> research by a committer does not convince him that any of the PR's
> problems is, more likely than not, a problem in a recent release,
> where "older" is measured from the creation date of the PR.

Interesting stuff. I've been toying around with the idea of an
automated ``close and send a gentle reply to the originator'' script
for feedback PRs that are more than 3-4 months old and no activity has
appeared in the audit trail since the last transition to feedback.
If 3-4 months seems too short, we can change it to 1 year or more.

The reasoning behind an automated close of the PR is that if the
originator of the PR has falled off the face of the earth, lost net
connectivity and nobody else picked up the problem report, then it's
probably something nobody cares about so we shouldn't waste time on it.

Then all it would take for PRs to slowly rot and close would be that
committers set the already open PRs to the feedback state if they seem
to be too old to be relevant to current and supported releases. Does
this look any good as an idea?

- - Giorgos

------------------------------

Date: Tue, 11 Feb 2003 21:18:02 -0400 (AST)
From: "Marc G. Fournier" <scr...@hub.org>
Subject: Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-)

On Tue, 11 Feb 2003, Terry Lambert wrote:

> "Gary W. Swearingen" wrote:
> > The Hermit Hacker <scr...@hub.org> writes:
> > > What needs to be done is various 'cut off points' need to somehow be
> > > established ... for instance, anything dealing pre-4.x should be closed
> > > ...
> >
> > How about putting "policies" in the PR Guidelines something like this:
>
> [ ... time-based, committer interest-based policies ... ]
>
> > The numbers might be too small.
>
> The problem with this approach is that it's possible to ignore
> a PR to make it go away, without the underlying problem being
> repaired/acknowledged.

And that is different then now, leaving it open? How many PRs right now
contain patches that ppl have 'ignored' and, as a result, are no longer
even relevant to the code?

------------------------------

Date: 11 Feb 2003 18:13:45 -0800
From: sw...@attbi.com (Gary W. Swearingen)
Subject: Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-)

Terry Lambert <tlam...@mindspring.com> writes:

> The problem with this approach is that it's possible to ignore
> a PR to make it go away, without the underlying problem being
> repaired/acknowledged.

No, the approach was purposely designed to avoid that. It takes either
a violation of the policy or at least 10 minutes of a committer's
attention and a manual "close" action to make a PR go away.

The approach will no-doubt result in some good PRs being sent away,
because there will be some 10-minute closers who do it carelessly,
or just don't have enough time, but that would be considered an
acceptable cost for the benefit of not having so many old PRs that
people tend to just ignore them all.

Any automatic scheme is too likely to see too many good PRs go away;
some kind of review and decision should be required. (Some kind of
rating system might be even better, in theory, but seems less likely to
be used well.) You also want a new scheme that defaults to the current
scheme if people don't support the new scheme.

------------------------------

Date: Wed, 12 Feb 2003 02:02:57 +0100
From: Brad Knowles <brad.k...@skynet.be>
Subject: Re: matthew dillon

At 4:48 AM -0800 2003/02/11, Dave Hayes wrote:

>> Before you can force everyone to use your fair allocation
>> system,
>
> The notion of "force" is misleading when dealing with the internet.

That's my point.

> No one is forcing anyone to do anything. Incentivizing, now that's
> different.

You can create all the incentives you want to try to keep people
from making assassination attempts on the president, but you'll never
completely stop them. You may be able to reduce the probability and
the frequency of actual known attempts, but that's the best you can
hope for.

> Not for me. That would be something to get off the freeway about. ;)
> A better use of the energy, wouldn't you agree?

Nope. I've got a right to be there, too.

- --
Brad Knowles, <brad.k...@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

------------------------------

Date: Wed, 12 Feb 2003 02:13:01 +0100
From: Brad Knowles <brad.k...@skynet.be>
Subject: Re: Email push and pull (was Re: matthew dillon)

At 9:40 AM -0500 2003/02/11, Rahul Siddharthan wrote:

> But I can now block known spammers from even trying to connect,
> because they can no longer relay their mail and thus can't hide their
> tracks.

Not true. They could create messages to be picked up anywhere in
the world, and then bombard you with notices every second.

There has to be an additional level of authentication built into
that system which is not typically present in mail systems today.
Moreover, not only do you need to have virtually unbreakable proof
between the client and the system, you also need to have virtually
unbreakable proof between the system and the recipient. Both are
easily subverted.

Moreover, if we had this level of authentication built into the
existing mail system, we could improve a lot more things a lot faster
than by trying to completely change how e-mail works across the
entire Internet.

> Equally important, the law can catch up with the spammers because they
> can't hide their tracks.

Again, not true. See above. This proposal *may* create a
situation where this sort of thing might exist, but there's a lot
more that would need to be added before you could be virtually
certain.

> One way to transition to a new system would be for mailservers to
> support both systems for a while, and indicate their support by their
> HELO greeting. Perhaps some indication can also be put in the MX
> records.

Synchronous meta-data updates are the #1 kill for most mail
systems today. You don't improve this situation by making the
messages/notices smaller, more frequent, and then tacking on a
secondary transmission channel.

I would have thought people would have learned their lesson with ftp.

> Once a new system is in place, and supported by the big guys (sendmail
> and Microsoft would be enough), I suspect transition would be pretty
> fast.

Not true. First off, Microsoft would never support the same
standard as everyone else, unless everyone else adopted the Microsoft
standard.

Thinking about this some more, you're basically talking about
single-instance message store, a topic that Nick and I discussed in
depth for my talk at LISA 2000. This is fundamentally unscalable,
and places many orders of magnitude more requirements for reliability
on the system than are in place today.

> Look how quickly the world got rid of open relays: back in 1996
> nearly every mail server was an open relay, now the spammers have a
> hard time finding one.

Not at all. The number of open relays may be going down, but
spammers can still easily find enough to do the damage, and that's
for the people that actually subscribe to the appropriate open-relay
blacklists.

- --
Brad Knowles, <brad.k...@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

------------------------------

Date: Wed, 12 Feb 2003 02:24:06 +0100
From: Brad Knowles <brad.k...@skynet.be>
Subject: Re: Email push and pull (was Re: matthew dillon)

At 3:04 PM -0800 2003/02/11, Terry Lambert wrote:

>> There are lots and lots of really big questions that haven't been
>> answered about this kind of solution. This list (from the bottom of
>> this page) is just beginning to think about scratching the surface:
>
> [ ... list ... ]
>
> These are all "doable" today, with existing infrastructure, no
> changes necessary, if you accept that the messages being sent
> are minimally the RFC822 headers, just without the normal body
> contents.

Isn't e-mail unreliable and slow enough that we don't really want
to make this situation an order of magnitude worse, because now we
have to send many smaller notices about a message we have waiting for
one or more recipients, and then we have to wait for them to come
pick it up?

Why not just give everyone in the world an IMAP account on your
mail server and make everyone use shared folders?

>> Indeed, I'd be interested to know if there is a single analog
>> anywhere in the world for this kind of system.
>
> 1) Lotus Notes.

No, not really. Besides, we all know how poorly LAN e-mail
packages scale. Been there, done that.

> 2) Usenet, with cryptographically protected messages
> that can only be read by their intended recipient(s).

Again, not really. Nice idea, but the OP said that the messages
themselves were never sent, only notices -- the message bodies would
then be retrieved via a pull mechanism.

- --
Brad Knowles, <brad.k...@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

------------------------------

Date: Wed, 12 Feb 2003 02:20:38 +0100
From: Brad Knowles <brad.k...@skynet.be>
Subject: Re: Email push and pull (was Re: matthew dillon)

At 3:04 PM -0800 2003/02/11, Terry Lambert wrote:

> 2) Messages are stored once, instead of messages being
> stored multiple times. This would be useful, for
> example, for an mail server where a large attachment is
> sent to multiple recipients, such that the recipients
> were not all listed on a single message instance (if
> they were a single instance, the server could coelesce
> them anyway, and store only a single copy).

In practice, as we scale up the system, this really isn't that useful.

See
<http://www.shub-internet.org/brad/papers/dihses/lisa2000/sld086.htm>
and
<http://www.shub-internet.org/brad/papers/dihses/lisa2000/sld087.htm>.

Moreover, do you know how painful it is to lose a cc:Mail, Lotus
Notes, Microsoft Mail, or Microsoft Exchange database? You can
instantly toast all mail for all users on that post office. Of
course, you can only support about ~150 users per post office, but
then you have to manage a great many more post offices and your TCO
goes way, way up.

How else do you think that Oracle can pitch their "Make Exchange
Unbreakable" solution, where as damn bloody expensive as the hardware
is that they base their solution on, the freakin' Oracle software
licenses are actually more expensive, and yet still make the sale?
They do it on TCO, and they do actually get the sales....

- --
Brad Knowles, <brad.k...@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

------------------------------

Date: Tue, 11 Feb 2003 18:35:04 -0800
From: David Schultz <dsch...@uclink.Berkeley.EDU>
Subject: Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-)

Thus spake Gary W. Swearingen <sw...@attbi.com>:
> The Hermit Hacker <scr...@hub.org> writes:
>
> > What needs to be done is various 'cut off points' need to somehow be
> > established ... for instance, anything dealing pre-4.x should be closed
> > ...
>
> How about putting "policies" in the PR Guidelines something like this:
>
> PRs older than 2 years shall be marked "suspended", where "older" is
> measured from the last PR log activity which a committer deems to
> indicate that the PR might still be valid for any OS version.
>
> (This allows PRs to be "refreshed".)
>
> PRs older than 4 years shall be marked "closed" if 10 minutes of
> research by a committer does not convince him that any of the PR's
> problems is, more likely than not, a problem in a recent release,
> where "older" is measured from the creation date of the PR.
>
> (This allows old PRs to be closed, even if recently "refreshed".)
>
> The numbers might be too small.

I dislike the idea of making PR expiry automated in any way. A PR
should be closed because the problem has been solved, or after an
excuse is given as to why the problem will not be solved. If you
start closing them and the best reason you can give is ``this
problem has been around for too long'', people will get quite
pissed off. Moreover, you're going to have to do a pretty darn
good job of closing PRs to make the PR database any more
navigable; a better approach to solving that problem is using a
better database, like Bugzilla.

------------------------------

Date: Tue, 11 Feb 2003 19:22:05 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Modelling complexity (was: Re: matthew dillon)

Dave Hayes wrote:
> Terry Lambert <tlam...@mindspring.com> writes:
> > I had a long message prepared to send, which refuted the naieve
> > assertions in your previous message, but I did not send it.
>
> Given you didn't understand me in the first place, I appreciate
> your restraint. =)

Your hubris is incredible. I understood you perfectly. To fail
to agree with you is not always a result of a failure to understand
you.

> > No, I'm telling you the constraints of the technology available
> > for use have the same effect on its application as the laws of
> > physics have on people.
>
> Most people can't get around the laws of physics and run into them
> headlong when trying, in any case you can accept the notion that no
> one has provably done so. Many people can get around the "constraints"
> of electronic communications technology and do so daily, examples of
> this abound...as I'm sure you are aware.

No, they do not.

> The difference is in what we both mean by "constraints", which of
> course you will assert should be the same for both of us.

Yes, I do.

> The notion of "permitted behavior" has never stopped some people
> from behaving otherwise; it is this notion in fact which _causes_
> unpermitted behavior to exist. There's no law of physics here,
> people can and will misbehave. The question is not whether they
> should or will, but if you are prepared for it.

It is not about permission, it is about possibility, for any given
situation.

By designing the situation, you design the constraints, and therefore
you limit the possibilities for behaviour.

You are talking about "rules". "Rules" are meaningless, in that
compliance with "rules" is always voluntary upon the complying
person, unless the rules constitute a subset of natural law.

For example, one can break the "rule" that you are not allowed to
spit on the sidewalk, because the laws of physics do not prohibit
the act. But a "rule" which states "objects must not fall up, in
a gravitational field" may not be disobeyed, even by the most
willful child: that "rule" is enforced by the laws of physics.

> > For example, if all mail servers will only accept 5 messages
> > per hour, and you are constrained to send outbound messages
> > through your ISP's mail server, then no matter what kind of mail
> > client you have, the maximum number of messages you will ever be
> > able to send is 5 per hour, period. It might as well be a law of
> > physics, as far as you are concerned.
>
> Not if you find some hackable server on another ISP and set up your
> email spam machine there. =)

What part of "all" didn't you understand?

- -- Terry

------------------------------

Date: Tue, 11 Feb 2003 19:32:21 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Bugzilla? (was Re: Okay, I think I need some serious introduction;-)

[ ... redirected to 'bugbusters' ... ]

"Marc G. Fournier" wrote:
> On Tue, 11 Feb 2003, Terry Lambert wrote:
> > The problem with this approach is that it's possible to ignore
> > a PR to make it go away, without the underlying problem being
> > repaired/acknowledged.
>
> And that is different then now, leaving it open?

The information is not destroyed that the bug was never in fact
actually resolved.

If you want to have a "I can't fit it" or "I won't fix it" status
for the bug, fine, but do not claim it is resolved when it can not
be proven, via a regression test, that it is, in fact, resolved.

> How many PRs right now contain patches that ppl have 'ignored'

All open ones with patches attached, of course.

> and, as a result, are no longer even relevant to the code?

You probably really mean "the code is no longer relevent to the patch",
since the patch has not changed in the interim; from the patch's point
of view, that translates to one of:

o that the code was changed by someone who did not properly
maintain the patch

o that the code was changed by someone who did not properly
check for a patch

o that the current process failed to "lock" the section of
code that the patch applied to, because the current process
has a bug

- -- Terry

------------------------------

Date: Tue, 11 Feb 2003 19:42:52 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Email push and pull (was Re: matthew dillon)

Brad Knowles wrote:

[ ... single instance message stores ... ]

> In practice, as we scale up the system, this really isn't that useful.
>
> See
> <http://www.shub-internet.org/brad/papers/dihses/lisa2000/sld086.htm>
> and
> <http://www.shub-internet.org/brad/papers/dihses/lisa2000/sld087.htm>.

Actually, I disagree with this presentation. There is an assumption
of "sufficient storage" there in the first place, when in practice,
sufficient storage is commonly a prime economic issue. If people
were satisfied with the job "the big providers" were doing, there
would be no little providers.

As to the metadata updates: I'm not positive this is the case,
though it is certainly the case in "sendmail" and certain other
MTAs. It's really implementation dependent, I think, and the
slide assumes a particular implementation.

> Moreover, do you know how painful it is to lose a cc:Mail, Lotus
> Notes, Microsoft Mail, or Microsoft Exchange database? You can
> instantly toast all mail for all users on that post office. Of
> course, you can only support about ~150 users per post office, but
> then you have to manage a great many more post offices and your TCO
> goes way, way up.

The scaling issue at 150 is an implementation detail specific to
the implementations you are referencing. My advice is "get some
real software". 8-). You can scale something like this from
Open Source components and about 3 months of concentrated coding
to at least 50,000 per indivisible component cluster, and then
throw hardware at it.

The normal implementation to avoid single point of failure is
replication of the data. At that point, the replication
protocol itself becomes (essentially) a transport. The worst
case failure mechanism, in that case, is a previously deleted
message reappears.

> How else do you think that Oracle can pitch their "Make Exchange
> Unbreakable" solution, where as damn bloody expensive as the hardware
> is that they base their solution on, the freakin' Oracle software
> licenses are actually more expensive, and yet still make the sale?
> They do it on TCO, and they do actually get the sales....

I think they do it on the basis of their name, and on the basis
of the idea that "you can put any SQL server behind MS Exchange,
so use ours, it's better than Microsoft's".

I agree that, in one narrow view, this can translate to TCO, but
it's not the major view that most people who are making the Buy
Decision are coming from. Even coming from that point of view,
you see mistakes made (e.g. Oracle vs. California).

- -- Terry

------------------------------

Date: Tue, 11 Feb 2003 19:49:08 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Email push and pull (was Re: matthew dillon)

Brad Knowles wrote:
> At 3:04 PM -0800 2003/02/11, Terry Lambert wrote:
> >> There are lots and lots of really big questions that haven't been
> >> answered about this kind of solution. This list (from the bottom of
> >> this page) is just beginning to think about scratching the surface:
> >
> > [ ... list ... ]
> >
> > These are all "doable" today, with existing infrastructure, no
> > changes necessary, if you accept that the messages being sent
> > are minimally the RFC822 headers, just without the normal body
> > contents.
>
> Isn't e-mail unreliable and slow enough that we don't really want
> to make this situation an order of magnitude worse, because now we
> have to send many smaller notices about a message we have waiting for
> one or more recipients, and then we have to wait for them to come
> pick it up?

Why did you cut out my arguments against actually doing it, in your
reply?

8-) 8-).

> Why not just give everyone in the world an IMAP account on your
> mail server and make everyone use shared folders?

Security. Privacy. Concurrent access. Storage. Backup.

You can actually get around all but "storage" and "backup", and
those can be brute-forced. But you have to be willing to change
IMAP4 semantics, slightly.

> >> Indeed, I'd be interested to know if there is a single analog
> >> anywhere in the world for this kind of system.
> >
> > 1) Lotus Notes.
>
> No, not really. Besides, we all know how poorly LAN e-mail
> packages scale. Been there, done that.

Just because the code you are familiar with was written by idiots,
doesn't tar all code with the same brush. 8-).

> > 2) Usenet, with cryptographically protected messages
> > that can only be read by their intended recipient(s).
>
> Again, not really. Nice idea, but the OP said that the messages
> themselves were never sent, only notices -- the message bodies would
> then be retrieved via a pull mechanism.

From a flood-filled, replicated store. I didn't say that the nodes
containing the message replicas had to be local to the recipient. The
usenet model is a good flood-fill replicated transport model.

- -- Terry

------------------------------

Date: Wed, 12 Feb 2003 07:59:04 +0000
From: Mark Murray <ma...@grondar.org>
Subject: Re: Bugzilla? (was Re: Okay, I think I need some serious introduction ;-)

PLEASE REMOVE ME FROM THE CC!!

"Marc G. Fournier" writes:
> On Tue, 11 Feb 2003, Terry Lambert wrote:
>
> > "Gary W. Swearingen" wrote:
> > > The Hermit Hacker <scr...@hub.org> writes:
> > > > What needs to be done is various 'cut off points' need to somehow be
> > > > established ... for instance, anything dealing pre-4.x should be closed
> > > > ...
> > >
> > > How about putting "policies" in the PR Guidelines something like this:
> >
> > [ ... time-based, committer interest-based policies ... ]
> >
> > > The numbers might be too small.
> >
> > The problem with this approach is that it's possible to ignore
> > a PR to make it go away, without the underlying problem being
> > repaired/acknowledged.
>
> And that is different then now, leaving it open? How many PRs right now
> contain patches that ppl have 'ignored' and, as a result, are no longer
> even relevant to the code?
>
- --
Mark Murray
iumop ap!sdn w,I idlaH

------------------------------

Date: Wed, 12 Feb 2003 01:21:38 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Modelling complexity (was: Re: matthew dillon)

Dave Hayes wrote:
> > I understood you perfectly.
>
> Then why did you paraphrase what I said incorrectly?

I paraphrased the *consequences* of what you said, were less than
100% of us to adopt your world view. We all have to choose to
play the game by your rules, or the consequences of adopting your
rules is a system which does not remain in steady state. You
hypothesize that all behaviour is tolerable, and should be tolerated
(if only by ignoring it).

Why don't you take your simple system, and posit a strange attractor
of a willful disrupter, and see if your system maintains itself in
some acceptable range +/- some small value, independent of the amount
of force driving the occilations? I'd like to see your graphs, and
your equations, demonstrating that the resulting damped, driven
harmonic oscillator doesn't end up overdriven, with no sigma to
multiply damping.

> > To fail to agree with you is not always a result of a failure to
> > understand you.
>
> Granted. However, some of your disagreement does rest in the inability
> (or unwillingness) to understand.
>
> BTW, you cannot prove that you understood what I said and neither
> can I. We might agree that you understand, but the possibility
> would still exist that you do not.

And how is that relevent? If you want to be a Solipsist, then you
aren't really going to be useful to anyone else, because your going
to act like everyone else is a figment of your imagination anyway.
Where is *our* utility in *you* acting like that? What's our economic
incentive for listening to or continuing to consent to interact with
you?

> > It is not about permission, it is about possibility, for any given
> > situation.
>
> Maybe -I'm- not understanding -you-. ;) Isn't one of your positions
> based on permission to behave in certain manners?

No. Permission is an artifact of authority, and no authority can
be absolute for an indefinite period. It's not a metastable state.

> > By designing the situation, you design the constraints, and therefore
> > you limit the possibilities for behaviour.
>
> Now you know why I don't take most of your analogies seriously. =)

I have no idea. Is it just that you can't follow the mathematics
behind emergent properties of chaotic systems, or is it just that
you disagree that the chaotic systems can be constrained in such a
way as to have a particular desirable set of emergent properties?

> > You are talking about "rules". "Rules" are meaningless, in that
> > compliance with "rules" is always voluntary upon the complying
> > person, unless the rules constitute a subset of natural law.
> >
> > For example, one can break the "rule" that you are not allowed to
> > spit on the sidewalk, because the laws of physics do not prohibit
> > the act. But a "rule" which states "objects must not fall up, in
> > a gravitational field" may not be disobeyed, even by the most
> > willful child: that "rule" is enforced by the laws of physics.
>
> I think you are using the world "rule" inaccurately here. Perhaps
> a "rule" should be used to denote man made barriers, and a "law"
> should be used to denote environmental ones?

No. You are mistaking my use of the word "law" for the common use
of the word "rule", as in "some arbitrary value whose compliance is
enforced by a larger society". A "law" is "the way things are". For
example, it is a "law" on the Internet that you can only send packets
with certain protocol number values (IP, IPv6, ICMP, etc.). This is
"the law", because no matter how hard you try to send packets with
protocol numbers other than that, they will not get from point A to
point B over an arbitrary segment of the Internet reliably, because
the core routers will simply discard, not forward, them. That's
"just the way things work": it is a law. Like gravity.

> >> Not if you find some hackable server on another ISP and set up your
> >> email spam machine there. =)
> >
> > What part of "all" didn't you understand?
>
> The part that says that you can't mold software to do mostly whatever
> you want to, in spite of "constraints" which are imposed by humans.

This is a nonsequitur. Did you not mean to use the phrase "due to"
instead of "in spite of" or the word "can" instead of "can't", or
both?

In any case, there are two interpretations of my statement that
would attempt to take a relativist stance on my use of the word
"all". If you meant one of those, I suggest you fire up your
favorite search engine and search for the following phrase:

"von Neumann complete"

I'll give you a hint: it has to do with information theory, and
the fact that you are wrong XOR John von Neumann is wrong... and
I know which way I'd personally bet on that one. 8-).

- -- Terry

------------------------------

Date: Wed, 12 Feb 2003 12:33:10 +0100
From: Brad Knowles <brad.k...@skynet.be>
Subject: Re: matthew dillon

At 6:50 PM -0800 2003/02/11, Dave Hayes wrote:

> The incentive that works is the lack of credible, intelligent,
> honorable, sane, and humble replacements. ;)

Nope. History has proven that.

> I contend that focusing on altering someone else's behavior is
> generally a waste of time. It is far more productive to focus on
> altering your own behavior.

Well, if you want to crawl back into a shell every time someone
says or does something you don't like, that's your perogative.

- --
Brad Knowles, <brad.k...@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

------------------------------

Date: Wed, 12 Feb 2003 12:50:53 +0100
From: Brad Knowles <brad.k...@skynet.be>
Subject: Re: Email push and pull (was Re: matthew dillon)

At 7:42 PM -0800 2003/02/11, Terry Lambert wrote:

> Actually, I disagree with this presentation. There is an assumption
> of "sufficient storage" there in the first place, when in practice,
> sufficient storage is commonly a prime economic issue. If people
> were satisfied with the job "the big providers" were doing, there
> would be no little providers.

In practice, the sole limiting factor of mail systems is
synchronous meta-data update latency and related I/O throughput.
You're far, far better off getting large numbers of smaller disks and
putting them in a RAID 1+0 environment (or even RAID 1+0+0), with a
large enough stripe size that almost all transactions can be taken
care of as one logical operation.

This is very much like running a large-scale USENET news server.
The total quantity of disk space is meaningless, if you don't have
enough heads working for you in parallel.

So, to solve the disk space issue, you just buy some slightly larger disks.

Been there, done that. We learned this lesson a long time ago at
AOL. Doing single-instance-store is a false economy, and indeed is
one of the key limiting factors for LAN e-mail packages like cc:Mail,
Lotus Notes, Microsoft Mail, or Microsoft Exchange. This is one of
the primary reasons why they don't scale.

> As to the metadata updates: I'm not positive this is the case,
> though it is certainly the case in "sendmail" and certain other
> MTAs. It's really implementation dependent, I think, and the
> slide assumes a particular implementation.

These slides have absolutely nothing whatsoever to do with the
MTA. They have to do with the mailbox, mailbox delivery, mailbox
access, etc.... You need message locking in some fashion, you may
need mailbox locking, and most schemes for handling mailboxes involve
either re-writing the mailbox file, or changing file names of
individual messages (or changing their location), etc.... These are
all synchronous meta-data operations.

See
<http://www.shub-internet.org/brad/papers/dihses/lisa2000/sld062.htm>
through
<http://www.shub-internet.org/brad/papers/dihses/lisa2000/sld081.htm>.
Then ask yourself how these issues relate to the operation of
UW-IMAP, Courier-IMAP, and Cyrus.

If you want a detailed discussion of these points, I'll be more
than happy to get into this.

However, keep in mind that I've already had a deep discussion of
these points with Nick Christenson (author of the book _Sendmail
Performance Tuning_, as well as the classic paper "A Highly Scalable
Electronic Mail Service Using Open Systems" at
<http://www.jetcafe.org/~npc/doc/mail_arch.html>, among others) and
other large-scale Internet e-mail experts, and I don't think that
we're likely to add much to this topic here.

> The scaling issue at 150 is an implementation detail specific to
> the implementations you are referencing. My advice is "get some
> real software". 8-). You can scale something like this from
> Open Source components and about 3 months of concentrated coding
> to at least 50,000 per indivisible component cluster, and then
> throw hardware at it.

Concentrated coding? Open source? Where? What specific pieces
of software are you envisioning? Who would be doing the coding? If
it's that simple, then why hasn't this code already been written?

I'm trying to build a LAN e-mail system today using open source
software because certain constraints have been put on this project
(e.g., they have literally $0 to spend on new hardware, mailboxes
must be stored on NFS, the old multi-purpose machines must be
replaced and a new mail system must be able to gradually take over),
and I was painted into a corner before I ever became a member of this
project.

I've done the best I can in the circumstances available, but I am
still very, very concerned that given the best available solutions I
can find for each of the components involved, the replacement still
is not going to perform well enough to be considered anything other
than "b0rken".

> The normal implementation to avoid single point of failure is
> replication of the data. At that point, the replication
> protocol itself becomes (essentially) a transport. The worst
> case failure mechanism, in that case, is a previously deleted
> message reappears.

Correct, in theory. Where's the practice?

> I think they do it on the basis of their name, and on the basis
> of the idea that "you can put any SQL server behind MS Exchange,
> so use ours, it's better than Microsoft's".

Uh, no. Take a closer look at the pitch. They are completely
and totally replacing Exchange. There are no Microsoft components
left. The architecture is totally unlike Exchange. The only thing
they're doing is pitching a solution that is compatible with Exchange
at the highest protocol levels, enough to fool Outlook.

- --
Brad Knowles, <brad.k...@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

------------------------------

End of freebsd-chat-digest V5 #701
**********************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-chat-digest in the body of the message

0 new messages