gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Re: Automatic archive discovery, take 1


From: Andrew Suffield
Subject: Re: [Gnu-arch-users] Re: Automatic archive discovery, take 1
Date: Mon, 15 Dec 2003 17:18:52 +0000
User-agent: Mutt/1.5.4i

On Mon, Dec 15, 2003 at 07:52:06AM -0800, Tom Lord wrote:
>     > From: Andrew Suffield <address@hidden>
> 
>     >> I think it aimed to make a kind of built-in-rdist but instead hit the
>     >> target of poorly-designed-name-authority-for-archives.
> 
>     > Careful, it's deliberately non-authoritative (unlike, say, DNS);
>     > everything stems from the root archive list in the user's ~, and is
>     > trivially overridden.
> 
> That's a property of your perl program -- not a property of the hook.
> 
> The next thing that happens if, say, I add the hook and maybe put the
> perl program in a contrib directory, is that someone modifies the perl
> program to hit up a server and someone else sets up a web page with
> some "official list of archives".

That's unavoidable. It's always possible that somebody could replace
any scheme you can come up with, with one that provides a central
authority, and then get people to use it. The only even remotely
effective barrier to this is something like palladium, that
cryptographically prevents the use of unauthorised clients. That's
generally considered to be not worth the price, and it's just a
different variation on the ultimate result of authoritarianism
anyway[0].

All you can do is offer people other choices. The one thing you can do
that is guaranteed to lead to the scenario you describe later is to
offer them no other choices.

> The patch to archive.c looks just like a call-out (via an hook) to a
> naming authority (albeit one that can be locally overriden with
> register-archive and one that locally memoizes resolutions until the
> user explicitly removes them).   The naming authority it implies is
> keyed on archive names which, as you note, is a mistake:
> 
> 
>     > In more practical terms, I can think of no way to take an
>     > archive name and figure out the owner, short of consulting an
>     > arbitrary list. They just don't embed anything else that's
>     > useful.
> 
> Right, and that's deliberate.   My thinking is that, for example,
> Linus could quit the OSDL in a huff and then it would be the larger
> community, not he or his employer, who decide the "ownership" of the
> archive names he was using (if there was contention over them).  Among
> the possible ways that decision could come out are "no clear owner --
> that name denotes a part of the arch namespace which is no longer
> coherent across the entire community".  (For development purposes,
> it's unlikely there'd be any good reason for namespace contention --
> for other purposes, such as automated source distribution, there may
> be very good reasons.  E.g., as Linus walks out the door, does he say
> to distribution managers "I think those guys are going down an
> unacceptable path -- please disconnect your mirrors from osdl sources
> and I will set up a new source on savannah.")

That's a thinly veiled variation on the problem trademarks are
supposed to solve (but don't). I've never heard of an even theoretical
solution to it; it's a problem of conflicting authority. Military
organisations go to great lengths to ensure that it never happens,
corporations usually just screw people over, and software developers
usually have futile arguments whenever they think it occurs (in free
software, it is frequently thought to occur and rarely does; people
have strange notions of what constitutes "authority").

I'm not sure what you expect to accomplish regarding it. It is not
within your power to avoid the problem.

What we *can* do is to make sure that the process of shifting the
aforementioned mirrors to a new source is as simple as possible. One
effective way to accomplish this would be to have an archive-list file
on a server controlled by Torvalds that they reference, and which
points to the current location - assuming that Torvalds is the
authority which they want to follow.

> Although I don't like the details of Walters' "meta-archive" proposal
> as it stands, one abstract aspect of it that I do like is that it
> attempts to make a higher-order namespace for naming some _thing_ that
> is more general than just a specific archive name.

Can't win that game. You'll ultimately have to start from somewhere,
and that starting point can always be corrupted. Some problems can't
be solved by adding more layers of abstraction.

Also, it's conceptually equivalent to prefix matches in archive-list
files (which serves to highlight how you run right back into the same
problem at the next level).

>     > Certainly a system like DNS is useless here. What I've thrown
>     > together isn't great, but it's simple and works and easy to
>     > extend; I figure it's as good a starting point as any (in the
>     > same sense that /etc/hosts is a good starting point for host
>     > resolution). Better ideas are invited.
> 
> Can you live without that modification to archive.c?

*Can* I? Yeah, easily, been doing it for months. *Should* we? I can't
see why - it's a trivial and obvious optimisation of the user
interface, and somebody is going to make it. I don't really care
enough to press the issue, but somebody is going to at some level, so
why not just include it? If you don't, it's pretty certain that
somebody else eventually will - and when that happens, it's pretty
likely that the result will be less favourable and really will lead to
the problems you suggest.

> The `grab' command illustrates the principle of at least requiring a
> user to explicitly ask for the records for a specific project from a
> specific authority location (rather than implicitly and automatically
> looking up everything, on demand, from a single source).  Granted, it
> doesn't automate away a registration-step -- but it does let you sum
> up multiple registration steps in a single command.  (It also
> illustrates the principle of using higher-order names.)

You can't stop people from arranging tla on their system such that it
will behave in a manner equivalent to that which I described[1]. All
you can do is make it easy for people to make their own choices.

[0] "Everything not compulsory is forbidden" and
    "Everything not forbidden is compulsory"

[1] Put a small wrapper around tla that fishes out archive names from
    the command and invokes the lookup program.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]