Re: [Gnu-arch-users] New feature at the mirror + request for help

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>

    >     Tom> What I would very much like to preserve, however, is:

    >     Tom>           ~ flexibility
    >     Tom>         ~ user choice
    >     Tom>         ~ no fixed authority game

    > These three don't scale indefinitely.  As you point out, DNS has to
    > have root servers because it's supposed to scale as far as
    > possible.

    > Today, with arch being a means of cooperation among hackers, it's
    > unlikely that the "world" of arch users would expand to that point,
    > and even more unlikely (given the nature of hackers) that arch users
    > will demand more than local consistency in their region---they'll just
    > work out any boundary conflicts by renaming.
    > 
    > However, if arch is going to become part of the general distribution
    > infrastructure (and in a more and more free software world with better
    > build systems and config management, you can see good reasons for
    > this), it will have to scale beyond local consistency.  Users will be
    > willing to give up choice, flexibility, or free entry for authorities
    > in return for global consistency.
    > 
    > I wonder in the end you'll have to make a choice between central
    > authorities (possibly a self-selecting backbone cabal) for arch
    > registry.  Dunno if that's worth worrying about.  I note that the fact
    > that it's unlikely that there would be another "address@hidden"
    > out there depends already on the DNS centralization.  Maybe it can all
    > be pushed off on that, although increasing the importance of DNS for
    > global coordination might not be a great idea....

That's just about the right analysis.

It's one thing to set up globally unique rendezvous points which serve
as leverage points for arch naming authorities.  DNS is certainly one
option for creating such a pivot point (and certainly not the only
option).

It's another thing to modify core arch in such a way that a particular
pivot point or contentious method for determining the pivot point is
presumed.  There is no need for a unique arch root in the core
functionality of arch.

There is no _technical_ need for a unique DNS root either.  There's a
_social_ and _economic_ need for a DNS root.  A social need because
DNS names are used globally, often by people who don't understand the
magic of how they're resolved or how to control that magic.  An
economic need because nearly always the names are used in ways that
require transparent agreement about their resolutions by systems which
are in disjoint administrative territories.

A subset of technically knowledgable users running a narrow range of
applications very well could set up a parallel DNS, ignoring ICANN
entirely.  No doubt people do, from time to time, both on and
alongside the Internet itself.  One good reason to do such a thing
would be to perform some operations for which naming is needed, but
for which integration with the official global namespace would be a
nuisance.

Barring "exotic" applications layered on _top_ of arch, we can expect
arch users to be of the technically knowledgable sort.  They are quite
capable of configuring name resolution at their end nodes.  They will
not need intermediate node systems to agree about their naming choices
and, when they do, they can build such intermediate nodes for
themselves.  (One wouldn't expect, anytime soon, for, say, routers or
email gateways to know anything about arch archive names.)

Moreover, there is no good reason to preclude having multiple "exotic"
applications layered on arch, each using a quite different naming
authority.

Consequently, the social and economic reasons for making a DNS root
are simply absent for arch.  There is no reason to build the
assumption of one into the core of arch.

In some bright shiny future where arch is used in a majority of free
software and open source projects, where arch is the basis of process
automation that spans organizational boundaries -- then, yes, at that
time, there will be "exotic" applications layered on _top_ of arch
that have some notion of centralized naming authority.  Jblack has
built one the first prototypes of such a thing.  But our discussion
here is about what assumptions should hold within the core of arch and
no reasons are likely to come up that suggest arch should assume a
singular naming authority.

One could argue that Jblack's super mirror, by not having designed-in
support for graceful handling of contentious archive names, is
self-limited  --- but that argument would have to show that there will
be demand for a generic supermirror-ilke functionality among a user
community that is, in fact, using a non-consistent namespace of
archives.   We can only guess, but my betting money is elsewhere.


    >     Tom> If you got silly about it, there'd be some heavy sighs and
    >     Tom> somebody else would put up a new supermirror.  We'd just
    >     Tom> recall our proxy.

    > This hasn't worked for Microsoft yet.  Monopolies have their limits,
    > but they can extract a lot of rent, and worse, exclude a lot of users,
    > before reaching them.

Perhaps.  I don't see how that much genuine leverage can be gained in
this specific case.  I sure this won't stop some people from trying
anyway.


    >     Tom> in the back room, start to work out a revenue model.

    > You really think Sourceforge and Savannah will allow that?  Not that
    > their managers have any designs on you and jblack personally, but if
    > arch gets to that point, don't you think they'll offer arch hosting?
    > Once they do, why would a user, either the developer or the client, be
    > willing to pay?  (Well, timely list mail delivery might be one reason.
    > ;-)

Both of those systems are paid for and neither is paid for by the
developers or clients, at least not directly.

    > Or how about Google---since arch is decentralized, doesn't it seem
    > likely that something like Google would make it possible to search for
    > arch archives, and that supermirrors would be unnecessary?

It's interesting that Google has not made a significant dent on the
project hosts.  It is a fairly rare event that I decide to find some
package I'm looking for by searching on Google.

-t