Hello Don,
Friday, September 29, 2000, 6:46:07 PM, you wrote:
The big problem: Mandrake team simply reply (when they want reply
:-))) ): "Cooker" is developement version"... and upload some big
package many times a day :(
You are right, the mirror does not follow any "standard" and are not
in sync !!!
I don't know where is the main archive, but I don't think that on this
archive there is : XFree86-..21mdk,22mdk,23mdk or cups and kde
6mdk,7mdk... :-))))
Now I have to download about 200Mb because of a disaster coming from
changed timestamps! But this is not possible because of this
"uncontrolled" package upload.
Yesterday I have completed 70% of the job.. but now:
ftp://sunsite.uio.no have many undeleted old packages
ftp://ftp.sunet.se have many old rpm
ftp://rpmfind.net is to slow for me
ftp.proxad.net does not have rsync and does not allow recurse with
fmirror
Someone must fix this!! :-))
Please, stop the continuous upload and find some way to have a working
mirrors.
Again, I think that this trouble can come from the same problem I have
with "savage updates" :-))) Files appears and disappears in one
second and hardware,software,people can't manage this:-)))
>> For distributing the stable distribution I
>> agree that a large list of mirrors is needed.
>> The content on these mirrors doesn't change
>> that much (security updates) and only a large
>> event takes a lot of BW (release of a new
>> product).
>>
>> Maybe it's possible to put up some quality
>> criteria to which a mirror must conform if it
>> wants to carry the cooker distro? A larger
>> list of primary mirrors might also help.
DH> I think Mandrake has hit some more growing pains
DH> (actually, I think they've been facing them for
DH> a while now).
DH> As Mandrake is a small Linux company (but a
DH> hugely successful distro), they don't have the
DH> money for multiple/redundant high-speed
DH> connections for distribution purposes, and
DH> therefore depend on the kindness of mirrors to
DH> pick up the workload. I see *nothing* wrong with
DH> this, I think it is a perfect example of
DH> businesses, schools, individual users, and ISPs
DH> working with, and for, the Linux community.
DH> --
DH> I think Mandrake's current problem is with
DH> co-ordination of the mirrors. I outline a number
DH> of possible changes below:
DH> (1.)
DH> There appears to be no standard when it comes to
DH> mirroring hierarchy. Now, I know that each
DH> mirror does things a little different, but there
DH> needs to be some type of basic Mandrake base
DH> hierarchy that should be followed. There's a
DH> number of separate Mandrake trees that need to be
DH> considered, and some organizational thought put
DH> into them. Below is something that is very
DH> similar to what already exists, and what some
DH> mirrors already do, but not all, and it should
DH> therefore be made a rule. The number of versions
DH> that a mirror actuallly mirrors is up to them, I
DH> just listed a few versions to make this e-mail
DH> longer than it needed to be:
DH> (Most mirrors could/would/should/may create an
DH> upper-level Mandrake directory to house all these
DH> trees.)
DH> I've left of Mandrake-crypto, as I feel it's
DH> going to disappear soon, am I correct? If not,
DH> it should follow the same tree structure as
DH> Mandrake-updates.
DH> Notice how all of the above flow exactly the same
DH> (what a concept, flow!)? Easy to follow, easy to
DH> mirror. From site to site, this hierarchy (1)
DH> makes sense, and (2) makes it easy to tell where
DH> things are going to be. This makes writing
DH> rsync scripts a lot easier, too.
DH> (2.)
DH> Next, a minimum refresh (rsync) time needs to be
DH> implemented and enforced. Daily,
DH> every-other-day, whatever. Something needs to be
DH> set in stone so that we aren't faced with mirrors
DH> who are way behind on the times. Being an
DH> official Mandrake mirror is a privilage, not a
DH> right. If you're offering Mandrake some space
DH> and bandwidth for a mirror, you have the
DH> responsibility of making sure its not being
DH> wasted on out-of-date content. This kinda goes
DH> with the item below.
DH> (3.)
DH> Lastly, a mirror co-ordinator needs to be
DH> appointed, and given the time to do his job, and
DH> do it right. I must say that Mandrake made an
DH> excellent move when they appointed Vincent Danen
DH> the security guy. IMHO, Mandrake has gone from
DH> last to first in security response. Can they do
DH> the same for distribution/mirroring?
DH> This person needs to be in constant contact with
DH> all the mirrors, notified of planned outages at
DH> the mirrors, and needs to be in charge of keeping
DH> the mirror list up to date.
DH> A change also needs to be made to this list, to
DH> reflect a lot more information. For example, Red
DH> Hat's mirror list shows which mirrors provide
DH> which architectures. What's even better is a
DH> list that shows both which architectures are
DH> available, as well as which mirrors offer ISO
DH> images. Something like this (imagine it's in
DH> HTML)(Warning, bad ASCII art follows):
DH> Now, I'm not going to try and tell Mandrake or
DH> its mirrors how to run their business/do their
DH> job. I am just trying to propose a fix to the
DH> problem that has plagued Mandrake for far too
DH> long.
DH> If someone believes all of these things are being
DH> done, I'm sorry to say they're not. If it's your
DH> job, this is an e-mail to you informing you that
DH> the process currently in place isn't working
DH> properly. This is in no way a flame, if nothing
DH> else, it's a formal notification (bug report?)
DH> from a Mandrake user to you.
DH> Don Head [[EMAIL PROTECTED]]
DH> Linux Mentor, LCA, Network+ [1 314 692-1942]
DH> Wave Technologies, Inc. [1 800 826-4640 x1942]
DH> [AIM - Don Wave][ICQ - 18804935][Yahoo - Don_Wave]
--
Best regards,
allx mailto:[EMAIL PROTECTED]
