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

[James Blackwell]

[long snip]

Here's where I start throwing wrenches into your well oiled machinery.


Tom Lord:
> 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.)
>

You are overestimating the abilities of the next generation of arch
users. What you see now are early adoptors. The arch user today is
generally well educated and motivated to learn how to properly use
tools. The next generation won't be so bad either. 

But the generation after that? Now you're dealing with the sort of crowd
that needs warnings on knives that the edges are sharp. The same end user
that spends three days burning out his processor by trying to gain a 20%
gain by overclocking it, that spends three weeks getting the theme for 
kdome 'just right', that spends four days compiling X because his tree
is two months out of date, is the same user that is going to use arch
to follow the latest-greatest anything. 

Did you ever see 'Night of the Living Dead'? Thats the one where a bunch
of people get stuck in a house all night long while slow shuffling
zombies try and get in through the doors and windows. The same thing is
going to happen here. The masses are coming. They're going to beat on
the windows with "arch should do this" and bang down the doors with
"make this easier for me".

Here, you're probably saying "yeah, but look at Bind. That's managed to
scrape by for a couple decades without a big problem. Sure. But there's
a reason for that -- dns is *transparent* to the user. The reason that
DNS is safe from this problem is that to the end user it Just Works.
That wouldn't be the case if everybody was running DNS servers. 

A better example is X. Look at the mess they have to deal with. People
set up huge desktops with alpha this and animated stuff, then turn
around and say (I kid you not) "X-Windows is bloated". The backpressure
from the users is so high that you repeatedly see temporary X come and
go like quantum particles appear and dissapear in vacuums. 


Tom Lord:
> 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.

Before I say this, I want to make it clear that I'm against authoritive
centralization as well. 

There's one big reason, and its not technical -- its political. There's
a perceived need for some sort of centralization. As more people come on
board, you're going to see the same arguments for arch centralization
that you see for rewriting X. History bears out what happens with this --
consistantly, ideas don't win out based on some sort of good/bad
scenario, but from a popular/unpopular one.

Yes, arch needs some sort of centralization because if we don't do it
right, someone else will do it wrong.

So how do we do this right? We give them something that looks like
centralization, looks like centralization and feels like centralization,
but isn't really centralization. 

There is a p2p app that you may not be familiar with called bittorrent.
They have solved a similiar problem. The way that they handle it is
that they have built in a centralization concept called that they call a
"tracker". These trackers, which are easy to set up by most people, are 
used to track files that are shared by the general purpose users. 

By making these trackers so simple to implement, they have hit upon a
new concept -- decentralized centralization (!). Sure, there's
superservers, but there's so many of them, that nobody is in control.

What bittorrent has to teach us is that the problem isn't centralized
servers. The problem to avoid is having a centralized server that is too
expensive for most to run.

Thats where grab plays into things. Anybody can set up a grab server,
and start serving archive name to location mapping. Mostly what's needed
is some polish -- fix up grab and distribute some cgi scripts that do
some magic, and bada-bing, you've got a centralized server that
*anybody* can run. 

Yeah, yeah. Its something I should get around to finishing.

Tom Lord:
> 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.

Thats because there isn't going to be contentions for names. Who's going
to make a valid claim that they're address@hidden other than you? Even
*if* somebody made that claim, and I believed them, you could trivially
route around the problem by saying "Hey James, call my archive
address@hidden". 

People don't care about the names of the archives. They care about
what's in them.

Tom Lord:
> 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.
>

I think this is common. I've done it and I think others have done it.
Its usually the very next step after "Is it listed at
mirrors.gnuarch.org".

-- 
James Blackwell          Please do not send me carbon copies of mailing
Smile more!              list posts. Such mail is unsolicited. Thank you!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400