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

[Tom Lord]

    A>>> Careful, it's deliberately non-authoritative (unlike, say,
    A>>> DNS); everything stems from the root archive list in the
    A>>> user's ~, and is trivially overridden.

    T>> That's a property of your perl program -- not a property of the hook.

    T>> The next thing that happens if, say, I add the hook and maybe
    T>> put the perl program in a contrib directory, is that someone
    T>> modifies the perl program to hit up a server and someone else
    T>> 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].

You misunderstand.  The goal here is not to try to prevent people from
ever implementing naming authority support for anything arch-related
(it not only seems inevitable but desirable to do so).

Rather, the goal is (a) that the core remains agnostic about how the
archive name to location mapping is computed, leaving the decision to
individual users (your patch preserves that property) and (b) that the
core does not encourage naming authorities keyed solely on archive
names (your patch breaks that property) and (c) that the core does not
encourage a single way to compute location mappings for the entire
namespace of archives (your patch breaks that property).

I prefer to leave the archive name to location mapping exposed and
simple-minded, in order to keep users aware of it, encourage inclusive
solutions to it, and encourage solutions which do not give rise to
"who can accumulate the most authority over archive names" games.

What I don't see here is any advantage for your purposes (your perl
program) to adding that hook.  Before the hook can do any good, the
user has to update a local file of location mappings.   Why can't that
update step also do registrations?  Why must registrations be done
later, on demand from tla?

    A>>> In more practical terms, I can think of no way to take an
    A>>> archive name and figure out the owner, short of consulting an
    A>>> arbitrary list. They just don't embed anything else that's
    A>>> useful.

    T>> Right, and that's deliberate.  My thinking is that, for
    T>> example, Linus could quit the OSDL in a huff and then it would
    T>> be the larger community, not he or his employer, who decide
    T>> the "ownership" of the archive names he was using (if there
    T>> was contention over them).  Among the possible ways that
    T>> decision could come out are "no clear owner -- that name
    T>> denotes a part of the arch namespace which is no longer
    T>> coherent across the entire community".  (For development
    T>> purposes, it's unlikely there'd be any good reason for
    T>> namespace contention -- for other purposes, such as automated
    T>> source distribution, there may be very good reasons.  E.g., as
    T>> Linus walks out the door, does he say to distribution managers
    T>> "I think those guys are going down an unacceptable path --
    T>> please disconnect your mirrors from osdl sources and I will
    T>> set up a new source on savannah.")

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

The analogy to trademarks and your assertion that there are no good
solutions are interesting.

Yes, perhaps it is in some sense "the same problem" that trademarks
aim to solve.   Yes, I agree, there are no good solutions.

Yes, "force fit" solutions, based on centralized power, are
characteristic of armies and brutish corporations.

Yes, therefore, the tla core does its part, in a small corner of the
world, by saying "For these identifiers, at least, in this program, at
least, no footing is provided for those who would falsely solve the
problem by erecting a contentious and centralized point of power that
would surely be claimed by a power who does not need consent to
govern.  As far as the core of tla is concerned, maintaining power
over some region of the arch namespace requires the continuous and
active consent of the governed, acting as individulas."

We already have one centralized authority (albeit with delgation) on
the net: DNS.  That is ample mechanism to preserve the infrastructure.
There is room, carved out by submitting to that authority, for users
and communities to have democratic control over supplementary
namespaces.  The archive namespace, as seen from the tla core, is an
example of such.

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

It is within my power to not personally help to make the problem
worse.


    > 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.

None of which requires the hook you proposed in archive.c


    >> 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.

There are two orthogonal problems:

1) the undue authority problem

2) the "names for higher-order things than just individual archives"
   problem.

We can't "win" problem (1) but we can avoid making it worse.

We _can_ (2) without making (1) worse.

    > 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.

I only prefer ways to make it easier to make _better_ choices.

There's plenty of ways to make something as convenient as what you've
proposed without sacrificing principle.


-t