Which is better? Why?
I know yum is the official update mechanism here and in Fedora Core, but that doesn't make yum better than up2date any more than Windows NT was better than OS/2.
Let's try to keep the discussion objective:-)
I'm asking, hoping for some insights into why RH might (apparently) be moving to yum in preference to up2date (yum is now used within Anaconda).
Other than general discussion, I'd also like to know what I'd muss by using up2date on CentOS.
I'll start with this: What has yum that provides this functionality: up2date -d -u
On Wed, 2006-09-06 at 08:35 +0800, John Summerfied wrote:
Which is better? Why?
I know yum is the official update mechanism here and in Fedora Core, but that doesn't make yum better than up2date any more than Windows NT was better than OS/2.
Let's try to keep the discussion objective:-)
I'm asking, hoping for some insights into why RH might (apparently) be moving to yum in preference to up2date (yum is now used within Anaconda).
Other than general discussion, I'd also like to know what I'd muss by using up2date on CentOS.
I'll start with this: What has yum that provides this functionality: up2date -d -u
The up2date that is used in CentOS is not like the up2date for RHN ... it is in fact a bastardized version of old (2.0.x) yum repos. There are backend repos that are not nearly as polished as RHN for yum and repomd in up2date. The up2date for RHN is as good as yum ... however the up2date using yum repos is not nearly as good. For example, obsoletes did not work until we fixed it in the 4.4 update.
I am currently working on the yum-plugin-downloadonly to address that specific issue.
Up2date also can not use the mirrorlist option which provides 10 GeoIP based mirrors that failover based on (if you install the fastestmirror plugin) speed.
Up2date does not have protectbase or priorities capability.
Up2date does not have a GUI capability like yumex.
yum is MUCH better than up2date for CentOS.
Thanks, Johnny Hughes
Johnny Hughes wrote:
On Wed, 2006-09-06 at 08:35 +0800, John Summerfied wrote:
Which is better? Why?
I know yum is the official update mechanism here and in Fedora Core, but that doesn't make yum better than up2date any more than Windows NT was better than OS/2.
Let's try to keep the discussion objective:-)
I'm asking, hoping for some insights into why RH might (apparently) be moving to yum in preference to up2date (yum is now used within Anaconda).
Other than general discussion, I'd also like to know what I'd muss by using up2date on CentOS.
I'll start with this: What has yum that provides this functionality: up2date -d -u
The up2date that is used in CentOS is not like the up2date for RHN ... it is in fact a bastardized version of old (2.0.x) yum repos. There are backend repos that are not nearly as polished as RHN for yum and repomd in up2date. The up2date for RHN is as good as yum ... however the up2date using yum repos is not nearly as good. For example, obsoletes did not work until we fixed it in the 4.4 update.
Where does the up2date in Fedora Core 3 sit in this?
I am currently working on the yum-plugin-downloadonly to address that specific issue.
Does it get source too? That's about third on the list of things I like to do.
Up2date also can not use the mirrorlist option which provides 10 GeoIP based mirrors that failover based on (if you install the fastestmirror plugin) speed.
I really don't like the mirror list I've seen in Fedora Core. It pulls stuff from all over, Europe, Middle East - mostly, it seems, about as far away from Western Australia as possible.
I prefer the Debian approach; I choose a mirror. In Australia, IAPs commonly have a peering arrangement; content from within the peer network isn't charge against download limits. While (AFAIK) all members of WAIX (the local peer network) are in WA, not all IAPs in WA are members.
Up2date does not have protectbase or priorities capability.
Up2date does not have a GUI capability like yumex.
I've never used yumex, do I can't tell whether up2date's GUI capability is like yumex's.
yum is MUCH better than up2date for CentOS.
As I mentioned elsewhere, installed 4.3 just before 4.4 came out. I'd uch rather have downloaded the packages overnight (triggered by cron) than type the commands in through my modem line.
GUIs aren't very good through modems.
On Wed, 2006-09-06 at 13:34 +0800, John Summerfied wrote:
Johnny Hughes wrote:
On Wed, 2006-09-06 at 08:35 +0800, John Summerfied wrote:
Which is better? Why?
I know yum is the official update mechanism here and in Fedora Core, but that doesn't make yum better than up2date any more than Windows NT was better than OS/2.
Let's try to keep the discussion objective:-)
I'm asking, hoping for some insights into why RH might (apparently) be moving to yum in preference to up2date (yum is now used within Anaconda).
Other than general discussion, I'd also like to know what I'd muss by using up2date on CentOS.
I'll start with this: What has yum that provides this functionality: up2date -d -u
The up2date that is used in CentOS is not like the up2date for RHN ... it is in fact a bastardized version of old (2.0.x) yum repos. There are backend repos that are not nearly as polished as RHN for yum and repomd in up2date. The up2date for RHN is as good as yum ... however the up2date using yum repos is not nearly as good. For example, obsoletes did not work until we fixed it in the 4.4 update.
Where does the up2date in Fedora Core 3 sit in this?
FC3 is past end of life, does it matter :)
however, the obsoletes code in up2date for either the yum type repo or repomd type repo is broken there as well.
I am currently working on the yum-plugin-downloadonly to address that specific issue.
Does it get source too? That's about third on the list of things I like to do.
No ... but in the centos repos, neither will up2date do that.
In order for that to work (in up2date or yum), the SRPMS need to be inside the $ARCH directory. In CentOS they are one level higher than that.
Starting with 4.4, we have linked the centosplus SRPMS directory down one level for x86_64 and i386 so that it can be included in the metadata generation. Try testing things from there, as SRPMS should be available. Right now, the best I can tell, yum does not do anything with SRPMS.
We need a plugin for that ... can someone figure out a plugin that will take the rpm and figure out the SRPM, and download it. We would need to also include where the downloaded SRPMS go (maybe a location defined in the plugin.conf file).
Up2date also can not use the mirrorlist option which provides 10 GeoIP based mirrors that failover based on (if you install the fastestmirror plugin) speed.
I really don't like the mirror list I've seen in Fedora Core. It pulls stuff from all over, Europe, Middle East - mostly, it seems, about as far away from Western Australia as possible.
CentOS shared our mirrorlist program with the Fedora Developers. Fedora is reworking (or just reworked) their mirrorlist select program to include GeoIP data. Their new program is not DIRECTLY based on ours (and I think theirs is python ... ours is perl), however our design and concept did influence it.
That is why I stressed GeoIP and the fastestmirror plugin. You will get close mirrors and they will be timed so you get the one that responds the fastest to your individual computer the day that you run it.
To see the Australia mirrors, do this:
http://mirrorlist.centos.org/?release=4&arch=i386&cc=au&repo=upd...
You do not have to specify cc= as it will be based on the IP Address of the connecting computer, but if you do specify it, it will override the default detection.
I prefer the Debian approach; I choose a mirror. In Australia, IAPs commonly have a peering arrangement; content from within the peer network isn't charge against download limits. While (AFAIK) all members of WAIX (the local peer network) are in WA, not all IAPs in WA are members.
Well ... what if that mirror is not updated yet. The other advantage of the mirrorlist system is that only UPDATED mirrors are shown. If a mirror does not get updates, it will not show up on the list. When it does not have the same content as master, it is removed and mirrors are checked at least once an hour.
Up2date does not have protectbase or priorities capability.
You didn't mention these ... and they allow you to add 3rd party repos and still protect your base so you don't update items in core ... but you can update other stuff.
Up2date does not have a GUI capability like yumex.
I've never used yumex, do I can't tell whether up2date's GUI capability is like yumex's.
yum is MUCH better than up2date for CentOS.
As I mentioned elsewhere, installed 4.3 just before 4.4 came out. I'd uch rather have downloaded the packages overnight (triggered by cron) than type the commands in through my modem line.
Run yum via cron ... it can be turned on to do just that via this command:
chkconfig yum on
GUIs aren't very good through modems.
Lastly ... in RHEL5Beta1 ... there is no up2date ... there is yum-2.9.x.
Johnny Hughes wrote:
On Wed, 2006-09-06 at 13:34 +0800, John Summerfied wrote:
FC3 is past end of life, does it matter :)
FC3 is a) The version of FC3 I know best b) What RHEL4 is based on c) Supported by Fedora Legacy
OTOH FC5 is basically broken and I'm thinking of replacing it with Suse 10.1 on at least one system:-)
On Thu, 2006-09-07 at 09:07 +0800, John Summerfied wrote:
Johnny Hughes wrote:
On Wed, 2006-09-06 at 13:34 +0800, John Summerfied wrote:
FC3 is past end of life, does it matter :)
FC3 is a) The version of FC3 I know best b) What RHEL4 is based on c) Supported by Fedora Legacy
OTOH FC5 is basically broken and I'm thinking of replacing it with Suse 10.1 on at least one system:-)
FC5 broken? Funny I use it every day as a desktop.
SUSE 10.1 every install I've tried won't update correctly without manual intervention to get the updater working. ::SIGH:: Maybe 10.2 will be worth looking at.
Paul
Paul wrote:
On Thu, 2006-09-07 at 09:07 +0800, John Summerfied wrote:
FC5 broken? Funny I use it every day as a desktop.
I run twelve virtual consoles, and often work through ssh even when in the same room.
I want mount points created when I plug in a USB disk. I don't want it mounted, and I especially don't want it open on the desktop (which I might not be looking at).
Even if I'm looking at the desktop, I don't want rewritable media mounted, it makes it hard to rewrite them.
Imagine; I'm downloading RHEL5 beta1 on my Centos box at work (I am). I plug in my USB2 notebook disk to copy RHEL5 beta 1 plus Etch (Debian testing) to it.
My desktop box doesn't have a screen (really, it doesn't) though I could actually have a GUI desktop running.
I want to connect via ssh, and run these commands: mount /media/usbdisk mv $(find ~/downloads ~/ISOs) /media/usbdisk umount /media/usbdisk
It works in Centos4. It won't work in FC5; if there's noone logged in locally, the mountpoint won't get created, and if someone's logged in locally, the default operation is for all partitions to bemounted and opened on the desktop.
It's worse for optical media (but SUSE has that wrong too). on Windows, a CD or DVD is always d: or e: or whatever for that particular configuration. Until recently, on Linux it was always /cdrom (Debian) or /mnt/cdrom (RHL) or similar, then /media/cdrom. Now it's /media/<columelabel>.
I don't see any way that's better than /media/cdrom, or what the mount point's got to do wuth the representation on the user's desktop.
On Thu, 2006-09-07 at 10:35 +0800, John Summerfied wrote:
Paul wrote:
FC5 broken? Funny I use it every day as a desktop.
I run twelve virtual consoles, and often work through ssh even when in the same room.
I want mount points created when I plug in a USB disk. I don't want it mounted, and I especially don't want it open on the desktop (which I might not be looking at).
<SNIP>
It's worse for optical media (but SUSE has that wrong too). on Windows, a CD or DVD is always d: or e: or whatever for that particular configuration. Until recently, on Linux it was always /cdrom (Debian) or /mnt/cdrom (RHL) or similar, then /media/cdrom. Now it's /media/<columelabel>.
I don't see any way that's better than /media/cdrom, or what the mount point's got to do wuth the representation on the user's desktop.
OK I see where your coming from, though I would not say it's "broken", it is a change of behavior from what went before. I think FC3 had that behavior also and I expect RHEL5 will probably also have it. It was a design decision to reflect what new desktop users coming from Windows/Mac would expect.
It would be nice if it could be configured to act differently, there may be a way to configure it to do what you expect.
Regards, Paul
Paul wrote:
On Thu, 2006-09-07 at 10:35 +0800, John Summerfied wrote:
Paul wrote:
FC5 broken? Funny I use it every day as a desktop.
I run twelve virtual consoles, and often work through ssh even when in the same room.
I want mount points created when I plug in a USB disk. I don't want it mounted, and I especially don't want it open on the desktop (which I might not be looking at).
<SNIP>
It's worse for optical media (but SUSE has that wrong too). on Windows, a CD or DVD is always d: or e: or whatever for that particular configuration. Until recently, on Linux it was always /cdrom (Debian) or /mnt/cdrom (RHL) or similar, then /media/cdrom. Now it's /media/<columelabel>.
I don't see any way that's better than /media/cdrom, or what the mount point's got to do wuth the representation on the user's desktop.
OK I see where your coming from, though I would not say it's "broken", it is a change of behavior from what went before. I think FC3 had that behavior also and I expect RHEL5 will probably also have it. It was a design decision to reflect what new desktop users coming from Windows/Mac would expect.
I use Windows and Macs too. What matters to the desktop user is the desktop label, not where the thing's mounted. Mostly, I use those because I'm paid to; I think Apple's got it wrong too, but I'd rather use Linux.
FC3 could be twisted into shape, I did so. It (like Centos4) creates the mount point; FC5 does not. On CentOS4 I have to use sudo (because I'm not local), but at least the mount point's consistent.
I just read on another list that .{gov,mil} sites are forbidden to run X unless they're serving X. I don't see why, turning off desktops on Windows and Macs isn't trivial, but if that's right perhaps my problem will be fixed.
It would be nice if it could be configured to act differently, there may be a way to configure it to do what you expect.
Yeah, edit d-bus rules. I'm not sure I want to be non-standard, better to find a standard that works for me, not against me.
Johnny Hughes wrote:
We need a plugin for that ... can someone figure out a plugin that will take the rpm and figure out the SRPM, and download it. We would need to also include where the downloaded SRPMS go (maybe a location defined in the plugin.conf file).
If you have the actual rpm, finding the source is trivial. If not, you can't unless the metadata has the info.
Up2date also can not use the mirrorlist option which provides 10 GeoIP based mirrors that failover based on (if you install the fastestmirror plugin) speed.
I really don't like the mirror list I've seen in Fedora Core. It pulls stuff from all over, Europe, Middle East - mostly, it seems, about as far away from Western Australia as possible.
CentOS shared our mirrorlist program with the Fedora Developers. Fedora is reworking (or just reworked) their mirrorlist select program to include GeoIP data. Their new program is not DIRECTLY based on ours (and I think theirs is python ... ours is perl), however our design and concept did influence it.
That is why I stressed GeoIP and the fastestmirror plugin. You will get
I don't see how "fastest mirror" can be evaluated usefully. If you have a gigabit Internet connexion, and I have 1500 ADSL or (worse) 256 ADSL or (worse again) a modem (Telstra doesn't do ADSL to my house), I don't see how software could determine that I should use poledra.it.net.au (should it be one of your mirrors) which it really should; it's local, it's on WAIX (as is my IAP), even if it's slower.
close mirrors and they will be timed so you get the one that responds the fastest to your individual computer the day that you run it.
If I use scp to copy a file across my LAN, the speed varies for no reason I can see, and that has no more than four switches and a router in the path, none very busy.
I'm sceptical that a 30-second test means anything all in the context of downloading a DVD.
To see the Australia mirrors, do this:
http://mirrorlist.centos.org/?release=4&arch=i386&cc=au&repo=upd...
Charming!
I'm in Perth. Here's what I see: http://mirror.pacific.net.au/linux/CentOS/4.4/updates/i386/ http://ftp.monash.edu.au/pub/linux/CentOS/4.4/updates/i386/ ftp://ftp.oss.eznetsols.org/linux/centos/4.4/updates/i386/ http://mirror.averse.net/centos/4.4/updates/i386/ http://centost.centos.org/centos/4.4/updates/i386/ http://centosh.centos.org/centos/4.4/updates/i386/ http://centose.centos.org/centos/4.4/updates/i386/ http://centosf.centos.org/centos/4.4/updates/i386/ http://centosl.centos.org/centos/4.4/updates/i386/ http://centosq.centos.org/centos/4.4/updates/i386/
I'm in Perth. Pacific's in Melbourne. Monash is Melbourne, I used to live nearish it. eznetsols I've not heard of so it's likely over east. No, I checked, it's Singapore. Ditto Eversnet.
As for those centos{x} names, qui sais? If you could agree on names that mean something to users, or use cnames
Just for the hell of it, I'm testing some: I have Netherlands, Clifton Park NY, Washington DC, and some others that timed out or are obviously US.
Not one that's obviously good.
A bit of geography for you: Perth is the most isolated major city in the world, the nearest other major city is Adelaide, and that's hours by air, days by road or rail. I think the next closest cities are in Singaport, Malaysia and Indonesia. Certainly, Jakarta is closer than Melbourne or Sydney.
Maps don't convey some information well; we have Poms arrive in Australia who didn't comprehend our distances until they arrive. Western Australia is similar in size to Europe: a same-scale map of WA overlaid on Europe takes in London and Moscow.
A mirror not in Perth isn't local. So far as our wallets go, none of those mirrors is good.
And, planetmirror which I do use, though it's in Brisbane (it's my fallback when what I want's not local) does have Centos and is not listed.
You do not have to specify cc= as it will be based on the IP Address of the connecting computer, but if you do specify it, it will override the default detection.
I prefer the Debian approach; I choose a mirror. In Australia, IAPs commonly have a peering arrangement; content from within the peer network isn't charge against download limits. While (AFAIK) all members of WAIX (the local peer network) are in WA, not all IAPs in WA are members.
Well ... what if that mirror is not updated yet. The other advantage of the mirrorlist system is that only UPDATED mirrors are shown. If a mirror does not get updates, it will not show up on the list. When it does not have the same content as master, it is removed and mirrors are checked at least once an hour.
It's a while since I checked ADSL plans here, but it used to be the case that if one overran one's download limit, there was a $60-$120 surcharge per gigabyte. Alternatively, one's speed is throttled from 1500 (or more with ADSL2) to 64K. Or less.
I'd rather a less current mirror.
Up2date does not have protectbase or priorities capability.
You didn't mention these ... and they allow you to add 3rd party repos and still protect your base so you don't update items in core ... but you can update other stuff.
It's not a feature that seems important to _me_. More likely, I'll want the source.
As I mentioned elsewhere, installed 4.3 just before 4.4 came out. I'd uch rather have downloaded the packages overnight (triggered by cron) than type the commands in through my modem line.
Run yum via cron ... it can be turned on to do just that via this command:
chkconfig yum on
The best I can figure is that downloads and applies updates. That's not what I want; the idea of surrendering control of my system to you bothers me.
It looks to me that that upgrade procedure could have produced the recent yum/sqllite problem.
I want to know what updates are to be applied, and I want them ready to apply. In Debian, I have this with apt-get, which downloads from a mirror I chose when I installed it, lists the updated available, and its run at a time of my choosing.
If I choose, I can exclude and update, and because I see the list before it happens, I know what's changed and when.
Unless I have a "senior moment," but that's another matter.
GUIs aren't very good through modems.
Lastly ... in RHEL5Beta1 ... there is no up2date ... there is yum-2.9.x.
I guess the battle's over then; I'm downloading that atm (at work), so I'll see what Centos5 might have.
---- Sorry for top posting ----
OK ... never mind
Please use SuSE or Debian ...
Thanks, Johnny Hughes CentOS-4 Lead Developer
Johnny Hughes wrote:
---- Sorry for top posting ----
OK ... never mind
Please use SuSE or Debian ...
I do.
Does this mean you don't wish to create a workable mirror system?
On Thu, 7 Sep 2006, John Summerfield wrote:
Johnny Hughes wrote:
---- Sorry for top posting ---- OK ... never mind
Please use SuSE or Debian ...
I do.
Does this mean you don't wish to create a workable mirror system?
We do have a workable mirror system - in use by an estimated 1.5 million users.
Regards Lance
-- uklinux.net - The ISP of choice for the discerning Linux user.
Jim Perrin wrote:
Does this mean you don't wish to create a workable mirror system?
Just because it doesn't fit into how you think it should work doesn't mean it's not workable. Stop trolling.
I'm not trolling, I pointed out a serious problem with it and suggest how it could be improved.
I repeat, mirrors in Europe & the US are not local to Western Australia, and while Singapore is relatively close, still data crosses national boundaries; while I don't understand the implications of that, I am sure it doesn't have the same costs & rules that data-flows within Austealia have.
The fact that users get their data doesn't mean the mirror system is working well from their perspectice.
I also made the point that speed measurements from users' machines don't mean much in terms of the distance, or of the performance of the download over time. Since I wrote, a download that I started this morning at 100 KBytes/sec has since slowed to 12 Kbytes/sec or so.
I've just done a quick check, there is actually a Centos mirror here in Perth: it's on WAIX, but you don't list it. it's even got 4.4 in it. Not only, but including: lftp ftp.iinet.net.au:/pub/centos/4.4> dir os/s390x/ ---> PASV <--- 227 Entering Passive Mode (203,59,27,132,191,167). ---- Connecting data socket to (203.59.27.132) port 49063 ---> LIST os/s390x/ <--- 150 Opening ASCII mode data connection for file list ---- Closing data socket drwxr-xr-x 4 0 root 4096 Mar 26 10:46 CentOS <--- 226-Transfer complete. <--- 226 Quotas off -rw-r--r-- 2 0 root 18009 Jul 7 2005 GPL -rw-r--r-- 1 0 root 192 Mar 24 17:52 RELEASE-NOTES -rw-r--r-- 4 0 root 1795 Jul 7 2005 RPM-GPG-KEY -rw-r--r-- 4 0 root 1795 Jul 7 2005 RPM-GPG-KEY-centos4 drwxr-xr-x 2 0 root 4096 Oct 8 2005 SRPMS -rw-r--r-- 1 0 root 112 Mar 24 21:15 generic.ins drwxr-xr-x 2 0 root 61440 May 8 17:24 headers drwxr-xr-x 2 0 root 4096 Mar 26 10:46 images drwxr-xr-x 2 0 root 4096 Mar 26 10:46 repodata -rw-r--r-- 2 0 root 537152 Mar 24 17:07 yumgroups.xml lftp ftp.iinet.net.au:/pub/centos/4.4>
I think it's also accessible by rsync (I've been getting some Debian from there by rsync) and http.
John Summerfield wrote:
Jim Perrin wrote:
Does this mean you don't wish to create a workable mirror system?
Just because it doesn't fit into how you think it should work doesn't mean it's not workable. Stop trolling.
I'm not trolling, I pointed out a serious problem with it and suggest how it could be improved.
I repeat, mirrors in Europe & the US are not local to Western Australia, and while Singapore is relatively close, still data crosses national boundaries; while I don't understand the implications of that, I am sure it doesn't have the same costs & rules that data-flows within Austealia have.
Who cares? When I think of "local" in terms of an update mirror, all I care about is latency (less so) and bandwidth (more so)...the fact that a particular host is located in Perth or Ulan Bator or Los Angeles really isn't important to me. Getting the bits from point A to point B in the quickest and most reliable fashion IS important. I don't understand why you're so hung up on server location as physical geography is becoming less and less relevant as the world becomes more and more wired.
Cheers,
chrism@imntv.com wrote:
John Summerfield wrote:
Who cares? When I think of "local" in terms of an update mirror, all I care about is latency (less so) and bandwidth (more so)...the fact that a particular host is located in Perth or Ulan Bator or Los Angeles really isn't important to me. Getting the bits from point A to point B in the quickest and most reliable fashion IS important. I don't understand why you're so hung up on server location as physical geography is becoming less and less relevant as the world becomes more and more wired.
If you read my earlier posts, you might have noticed terms like "download limits."
Most users don't have "all you can eat" plans, and if they exceed their quota they can be charged extra ($60-120 per gigabyte) or br throttled back to modemesque speeds.
Okay, the minimum charge gor overuns seems to have come down since last I looked (I can't have ADSL here), but the top charge is pretty steep. See here for a sample of what people in other places have:
http://bc.whirlpool.net.au/bc-plan.cfm?state=wa&class=0&type=res&...
"shaped" means "throttled back severely."
This rabbit looks like a wounded bull!! http://bc.whirlpool.net.au/isp.cfm/Rabbit-Net-ADSL/678-1.html?p=7610
That is why geographic locality is important. And it's not just so for Western Australian, similar rules apply in at least some European countries.
I'm downloading at work (adsl there); while the boss knows, he will not be happy if he gets a Big Bill, or if the school gets "shaped."
John Summerfield wrote:
chrism@imntv.com wrote:
John Summerfield wrote:
Who cares? When I think of "local" in terms of an update mirror, all I care about is latency (less so) and bandwidth (more so)...the fact that a particular host is located in Perth or Ulan Bator or Los Angeles really isn't important to me. Getting the bits from point A to point B in the quickest and most reliable fashion IS important. I don't understand why you're so hung up on server location as physical geography is becoming less and less relevant as the world becomes more and more wired.
If you read my earlier posts, you might have noticed terms like "download limits."
Most users don't have "all you can eat" plans, and if they exceed their quota they can be charged extra ($60-120 per gigabyte) or br throttled back to modemesque speeds.
What on Earth does that have to do with anything? You've got poor connectivity or expensive connectivity or both in the "last mile" part of your link to the Internet. How is changing the mirroring system going to help you or others like you?
What on Earth does that have to do with anything? You've got poor connectivity or expensive connectivity or both in the "last mile" part of your link to the Internet. How is changing the mirroring system going to help you or others like you?
Faulty question. Changing the mirror system would help him. This is why he wants it done. The question more appropriately (in my mind at least) is "Should centos get into the business of tweaking the mirror so that it suits the special case last mile users?"
The current mirror system is a vast improvement over the previous design.
There's some parental pride which will be resistant to change over the current script, although if it's a worthwhile improvement, I'm sure reason will prevail.
I believe that we provide a general service, and that to some extent, it's up to individual users to tweak to suit their unique needs. I don't think CentOS should get involved with "last mile" efforts, as most other distros do not, (or do so only by accident as with debian picking a mirror close to you).
There's nothing stopping people from changing the repo file to suit their needs, and indeed from another thread on the centos-devel list it seems that many do this to point to custom/local/tested repositories of their own creation.
Jim Perrin wrote:
Faulty question. Changing the mirror system would help him. This is why he wants it done. The question more appropriately (in my mind at least) is "Should centos get into the business of tweaking the mirror so that it suits the special case last mile users?"
There are more than us in Western Australia or even Australia; I seem to recall that UK and Germany have similar plans.
The current mirror system is a vast improvement over the previous design.
There's some parental pride which will be resistant to change over the current script, although if it's a worthwhile improvement, I'm sure reason will prevail.
I believe that we provide a general service, and that to some extent, it's up to individual users to tweak to suit their unique needs. I don't think CentOS should get involved with "last mile" efforts, as most other distros do not, (or do so only by accident as with debian picking a mirror close to you).
Debian recommends asks where the user is, and asks for a choice.
There's nothing stopping people from changing the repo file to suit
There's the small point that most users don't know they should, and unless they're prompted to confirm the choice, they won't go looking.
their needs, and indeed from another thread on the centos-devel list it seems that many do this to point to custom/local/tested repositories of their own creation.
But those are more competent than my wife (Ubuntu), my youngest daughter (RHL 5.x and more recently Ubuntu) or my boss (who pays me to look after his RHL 7.3 system).
The fact that the Fedora Project, Ubuntu and others do it badly doesn't excuse us.
Most of the people on these lists are fairly competent, and could make a sane choice given the opportuntity.
Debian recommends asks where the user is, and asks for a choice.
Yes, and that would be interesting to look at for future development within centos. The problem with this is that if that mirror becomes outdated or they withdraw the donation (has happened in the past) then you're stuck with no mirror. A while ago we had problems with stale mirrors. Even with this last update, it's taken a while for some of the mirrors to sync up properly. This is why we moved to the mirrorlist approach.
There's nothing stopping people from changing the repo file to suit
There's the small point that most users don't know they should, and unless they're prompted to confirm the choice, they won't go looking.
Valid point. This information may make its way into Ralph's hands for the wiki, but I'm not sure about creating a choice option, or shoe-horning something like that into firstboot. How would this be upgraded when changes to yum are made? There are some fundamental differences here between the debian mindset and the centos/yum mindset that will require much planning if this is undertaken.
But those are more competent than my wife (Ubuntu), my youngest daughter (RHL 5.x and more recently Ubuntu) or my boss (who pays me to look after his RHL 7.3 system).
This will be mostly opinion here, and is NOT to be taken as a view of the project itself. Consider the idea behind centos. It's a rebuild of RHEL, aimed at business servers, workstations, and other more industrialized settings. The primary goal of RHEL isn't really a home desktop type system, as that's what RH has fedora for. CentOS does make a good stable desktop, and I use it as such on a daily basis, however in my mind the parent roots carry down, and I do expect a higher level of competency from centos users vs ubuntu/fedora users. Debian doesn't really distinguish between classes of users. RMS would probably consider that facist and wrong.
The fact that the Fedora Project, Ubuntu and others do it badly doesn't excuse us.
Indeed, however one also can't look to them to provide a milestone for centos for all things.
Most of the people on these lists are fairly competent, and could make a sane choice given the opportuntity.
Yes, and I'm not trying to argue the point, just clarifying the position. They've always had the opportunity. The choice was simply never forced on them.
John Summerfield wrote:
Jim Perrin wrote:
Faulty question. Changing the mirror system would help him. This is why he wants it done. The question more appropriately (in my mind at least) is "Should centos get into the business of tweaking the mirror so that it suits the special case last mile users?"
There are more than us in Western Australia or even Australia; I seem to recall that UK and Germany have similar plans.
You're wrong in regard to Germany. Or I don't understand you, which might also be the case. But most people here with broadband access have flat rates.
Cheers,
Ralph
On Thu, 2006-09-07 at 12:10 -0400, Jim Perrin wrote:
<snip>
I believe that we provide a general service, and that to some extent, it's up to individual users to tweak to suit their unique needs. I don't think CentOS should get involved with "last mile" efforts, as most other distros do not, (or do so only by accident as with debian picking a mirror close to you).
Of course this argument has validity only if the avowed goal of being as much like a certain major North American vendor ... "warts and all" holds. Since the move to yum is itself a move away in search of "excellence" (if I may be permitted), and the mirror system is also in support of that, it seems that there is "wiggle room". Without a exhibition of a slavish devotion towards "cloning" the major vendor, it is reasonable to consider improvements of various kinds from various quarters.
E.g. can a mirror definition be provided that supports "local addenda" that take precedence? This might be through a config file parameter. It could even allow one to suppress or continue processin of the "standard mirrors" if the locals fail.
<snip>
-- Bill
William L. Maltby wrote:
E.g. can a mirror definition be provided that supports "local addenda" that take precedence? This might be through a config file parameter. It could even allow one to suppress or continue processin of the "standard mirrors" if the locals fail.
I get
| [ralph@logout ~]$ wget -O - | "http://mirrorlist.centos.org/?release=4&arch=i386&repo=os&cc=de" | http://ftp.hosteurope.de/mirror/centos.org/4.4/os/i386/ | http://centos.intergenia.de/4.4/os/i386/ | http://centos-mirror.financial.com/4.4/os/i386/ | http://wftp.tu-chemnitz.de/pub/linux/centos/4.4/os/i386/ | http://ftp.belnet.be/packages/centos/4.4/os/i386/ | http://centos.mirrors.skynet.be/pub/centos/4.4/os/i386/ | http://mirrors.ircam.fr/pub/CentOS/4.4/os/i386/ | http://centos.crazyfrogs.org/4.4/os/i386/ | http://ftp.nluug.nl/ftp/pub/os/Linux/distr/CentOS/4.4/os/i386/ | http://centos.mirror.rokscom.nl/4.4/os/i386/
which are mirrors *in* Germany or in neighbour countries. I can assume that those are pretty fast, also.
The problem is: There might be more mirrors in my vicinity - but how is CentOS supposed to know that they are there? Do those mirrors report back to CentOS or do they just mirror it from somewhere else?
http://www.centos.org/modules/tinycontent/index.php?id=13 - those are the official ones. If you know of other mirrors close to you, then get *them* to report to CentOS.
We can't just probe every available ftp server and look if they mirror centos content.
Regards,
Ralph
On Thu, 2006-09-07 at 22:54 +0200, Ralph Angenendt wrote:
William L. Maltby wrote:
E.g. can a mirror definition be provided that supports "local addenda" that take precedence? This might be through a config file parameter. It could even allow one to suppress or continue processin of the "standard mirrors" if the locals fail.
I get
<snip>
We can't just probe every available ftp server and look if they mirror centos content.
Which is why I said <quote> This might be through a config file parameter. It could even allow one to suppress or continue processin of the "standard mirrors" if the locals fail. </quote>
I may be ignorant (in the dictionary sense:-) but I have some sense.
OK. Assuming that you read carefully and I did not express myself sufficiently.
What I was thinking (one of many possibilities) was along the lines of "include" directives similar to... e.g. xinetd or many other packages. Might want a slightly different name. Regardless, it would cause inclusion of a file of mirrors, maybe hand generated by the user, that would be tried before the list normally returned by the current mirroring functionality.
In conjunction with that, a "flag" that says yes/no: try the "standard" mirrors if the special list fails or not.
It may be a dumb idea, but not as dumb as the one you (apparently) implied I suggested.
I have no complaints about how it works now. I posted my $0.25 only in the nature of contributing something I did not see suggested. I really don't give a darn how it turns out.
Summerfiled chose to be "grating". He might fit right in here. :-D
<snip sig stuff>
-- Bill
On Thu, 7 Sep 2006, William L. Maltby wrote:
What I was thinking (one of many possibilities) was along the lines of "include" directives similar to... e.g. xinetd or many other packages. Might want a slightly different name. Regardless, it would cause inclusion of a file of mirrors, maybe hand generated by the user, that would be tried before the list normally returned by the current mirroring functionality.
I suggest that you may take this suggestion to the yum mailing list - it is beyond what we would expect to do - we just configure the thing.
Lance
-- uklinux.net - The ISP of choice for the discerning Linux user.
On Thu, 2006-09-07 at 22:12 +0100, Lance Davis wrote:
On Thu, 7 Sep 2006, William L. Maltby wrote:
What I was thinking (one of many possibilities) was along the lines of "include" directives similar to... e.g. xinetd or many other packages.
<snip>
I suggest that you may take this suggestion to the yum mailing list - it is beyond what we would expect to do - we just configure the thing.
With CentOS folks working on various things (including yum plugins IIUC), it's hard to tell sometimes what's OT here. NP.
<snip>
William L. Maltby wrote:
What I was thinking (one of many possibilities) was along the lines of "include" directives similar to... e.g. xinetd or many other packages. Might want a slightly different name. Regardless, it would cause inclusion of a file of mirrors, maybe hand generated by the user, that would be tried before the list normally returned by the current mirroring functionality.
rtfm, this is presently possible. feel tree to mod you .repo to suit.
Karanbir Singh wrote:
William L. Maltby wrote:
What I was thinking (one of many possibilities) was along the lines of "include" directives similar to... e.g. xinetd or many other packages. Might want a slightly different name. Regardless, it would cause inclusion of a file of mirrors, maybe hand generated by the user, that would be tried before the list normally returned by the current mirroring functionality.
rtfm, this is presently possible. feel tree to mod you .repo to suit.
while you could grow a tree, i suggest we do a s/tree/free/ on that one line.
On Thu, 2006-09-07 at 23:42 +0100, Karanbir Singh wrote:
William L. Maltby wrote:
What I was thinking (one of many possibilities) was along the lines of "include" directives similar to... e.g. xinetd or many other packages. Might want a slightly different name. Regardless, it would cause inclusion of a file of mirrors, maybe hand generated by the user, that would be tried before the list normally returned by the current mirroring functionality.
rtfm, this is presently possible. feel tree to mod you .repo to suit.
I give up. I try to read as much as fast as I can to fill in my admitted newness to this stuff. I know I can custom build repos lists, etc. I use fastest mirror plugin and I use your mirror list. If there is a way for me to use the *standard* issued stuff and just add a single line that says augment that with local stuff first and then use (or don't use the standard stuff) if that fails, I missed it.
As Lance pointed out, this is OT here anyway, so I was done.
As I pointed out, it was no concern to me.
Jim Perrin wrote:
What on Earth does that have to do with anything? You've got poor connectivity or expensive connectivity or both in the "last mile" part of your link to the Internet. How is changing the mirroring system going to help you or others like you?
Faulty question. Changing the mirror system would help him. This is why he wants it done. The question more appropriately (in my mind at least) is "Should centos get into the business of tweaking the mirror so that it suits the special case last mile users?"
[snip] There's nothing stopping people from changing the repo file to suit their needs, and indeed from another thread on the centos-devel list it seems that many do this to point to custom/local/tested repositories of their own creation.
I guess that is a better wording of my point. Thanks! :) I think the current system is workable for the vast majority of folks and that an end user already has the ability to season their mirror list to taste if they want/need to. Perhaps Mr. Summerfield can help find someone willing to host a public mirror in Perth. :)
Cheers,
On Thu, 2006-09-07 at 12:10 -0400, Jim Perrin wrote:
What on Earth does that have to do with anything? You've got poor connectivity or expensive connectivity or both in the "last mile" part of your link to the Internet. How is changing the mirroring system going to help you or others like you?
Faulty question. Changing the mirror system would help him. This is why he wants it done. The question more appropriately (in my mind at least) is "Should centos get into the business of tweaking the mirror so that it suits the special case last mile users?"
You should at least try to understand how it goes wrong and make sure that isn't true for the general case.
The current mirror system is a vast improvement over the previous design.
I have to disagree. Many machines here run through the same caching proxy and the current system rarely has a cache hit, while the earlier version almost always had hits after the first machine had done an update. Or maybe I'm comparing the centos3 scheme to centos4. I don't really know what has changed, but centos4 is as bad as fedora at defeating what caching proxies are intended to do. Whatever you are doing to choose an appropriate mirror is not at all consistent from a given location so every subsequent request ends up pulling from a different url. If what you are doing is correct, shouldn't it be repeatable from the same location (i.e. through the same proxy)?
There's some parental pride which will be resistant to change over the current script, although if it's a worthwhile improvement, I'm sure reason will prevail.
Maybe those claimed 1.5 million users are really a few users or locations with a lot of machines... Letting proxies work as designed would make sense to me.
I believe that we provide a general service, and that to some extent, it's up to individual users to tweak to suit their unique needs.
Users that are behind a common proxy generally know that, or the proxy may intercept transparently. There's no particular reason to think that this set of users know anything else about each other, or what OS distribution the others might be using.
On Thu, 7 Sep 2006, Les Mikesell wrote:
I have to disagree. Many machines here run through the same caching proxy and the current system rarely has a cache hit, while the earlier version almost always had hits after the first machine had done an update. Or maybe I'm comparing the centos3 scheme to centos4. I don't really know what has changed, but centos4 is as bad as fedora at defeating what caching proxies are intended to do. Whatever you are doing to choose an appropriate mirror is not at all consistent from a given location so every subsequent request ends up pulling from a different url. If what you are doing is correct, shouldn't it be repeatable from the same location (i.e. through the same proxy)?
If you are using fastestmirror plugin then it should always pick the same mirror, although it will retes at intervals and use a faster one if it finds it.
Assuming the proxy works by url then that should find the requested files.
If you arent using fastestmirror then it may use a sequence of mirrors in the list, and the 2nd server wouldnt necessarily use the same one as the first.
The best soluton for you would probably be to look at which mirrors are seen to be the fastest in the mirrorlist results and hard code those into your repos configuration for all your servers. Listing one or two should give you fallback.
CentOS 3 wont have the same issue because all updates are referenced via a round robin set of mirror.centos.org, which will always be seen as the same url by the proxy.
One way to do what you want would be to use round robin geoip enabled dns for the mirrors , but then all the mirrors would have to respond to a subdomain of centos.org - which probably isnt going to happen ...
There's some parental pride which will be resistant to change over the current script, although if it's a worthwhile improvement, I'm sure reason will prevail.
Maybe those claimed 1.5 million users are really a few users or locations with a lot of machines... Letting proxies work as designed would make sense to me.
Well the issue is that you want a proxy to always hit the same mirror - (which you can configure) whereas we want to spread the load between the mirrors ...
Regards Lance
-- uklinux.net - The ISP of choice for the discerning Linux user.
On Thu, 2006-09-07 at 18:08 +0100, Lance Davis wrote:
CentOS 3 wont have the same issue because all updates are referenced via a round robin set of mirror.centos.org, which will always be seen as the same url by the proxy.
What's the problem with that scheme? It's hundreds of times faster on my second and subsequent machines - and would be for anyone else going through a proxy configured to cache large objects.
Maybe those claimed 1.5 million users are really a few users or locations with a lot of machines... Letting proxies work as designed would make sense to me.
Well the issue is that you want a proxy to always hit the same mirror - (which you can configure) whereas we want to spread the load between the mirrors ...
What I want is for the default install to work using standard cache techniques. The 'you can configure' concept only works if you know everyone else sharing the same proxy and can pre-arrange every file download with all of them which is pretty unlikely in any organization large enough to even have a proxy. A scheme that uses the same URL for the same file will always work automatically. If you do this, spreading the load won't be an issue since there will actually only be one download. If you can't use the same set of mirrors as centos3, there has to be some way to make this happen based on some computation that would be repeatable - perhaps a server-side check that can see the requester's public source address and give back the best mirror URL or a sorted list that would always be the same for that source IP.
On Thu, 2006-09-07 at 12:47 -0500, Les Mikesell wrote:
On Thu, 2006-09-07 at 18:08 +0100, Lance Davis wrote:
CentOS 3 wont have the same issue because all updates are referenced via a round robin set of mirror.centos.org, which will always be seen as the same url by the proxy.
What's the problem with that scheme? It's hundreds of times faster on my second and subsequent machines - and would be for anyone else going through a proxy configured to cache large objects.
What is wrong with that scheme is that only 1 mirror is listed ... if you loose the connection, if it gets overloaded in the middle of your transfer, etc. then there is no failover.
Maybe those claimed 1.5 million users are really a few users or locations with a lot of machines... Letting proxies work as designed would make sense to me.
Well the issue is that you want a proxy to always hit the same mirror - (which you can configure) whereas we want to spread the load between the mirrors ...
What I want is for the default install to work using standard cache techniques. The 'you can configure' concept only works if you know everyone else sharing the same proxy and can pre-arrange every file download with all of them which is pretty unlikely in any organization large enough to even have a proxy. A scheme that uses the same URL for the same file will always work automatically. If you do this, spreading the load won't be an issue since there will actually only be one download. If you can't use the same set of mirrors as centos3, there has to be some way to make this happen based on some computation that would be repeatable - perhaps a server-side check that can see the requester's public source address and give back the best mirror URL or a sorted list that would always be the same for that source IP.
If you have alot of machines doing the same updates from the same place (and so are behind a proxy server) then hosting the updates yourself on a local mirror would be much easier and you would not have to worry about any of these issues.
On Thu, 2006-09-07 at 13:08 -0500, Johnny Hughes wrote:
CentOS 3 wont have the same issue because all updates are referenced via a round robin set of mirror.centos.org, which will always be seen as the same url by the proxy.
What's the problem with that scheme? It's hundreds of times faster on my second and subsequent machines - and would be for anyone else going through a proxy configured to cache large objects.
What is wrong with that scheme is that only 1 mirror is listed ... if you loose the connection, if it gets overloaded in the middle of your transfer, etc. then there is no failover.
Doesn't your geo-ip enabled DNS service drop non-responding servers? It has been much less trouble in practice from my locations than the fedora or centos4 repositories.
What I want is for the default install to work using standard cache techniques. The 'you can configure' concept only works if you know everyone else sharing the same proxy and can pre-arrange every file download with all of them which is pretty unlikely in any organization large enough to even have a proxy. A scheme that uses the same URL for the same file will always work automatically. If you do this, spreading the load won't be an issue since there will actually only be one download. If you can't use the same set of mirrors as centos3, there has to be some way to make this happen based on some computation that would be repeatable - perhaps a server-side check that can see the requester's public source address and give back the best mirror URL or a sorted list that would always be the same for that source IP.
If you have alot of machines doing the same updates from the same place (and so are behind a proxy server) then hosting the updates yourself on a local mirror would be much easier and you would not have to worry about any of these issues.
I don't see how that helps with different people who don't spend all their time coordinating file downloads with each other. And you'd have to repeat the work for every distribution and every repository and for every installed machine - and at every location. I don't see the 'much easier' part anywhere in this picture. How is anything 'much easier' than having the default system work the way caches have been designed for at least a decade?
On Thu, 2006-09-07 at 13:27 -0500, Les Mikesell wrote:
On Thu, 2006-09-07 at 13:08 -0500, Johnny Hughes wrote:
CentOS 3 wont have the same issue because all updates are referenced via a round robin set of mirror.centos.org, which will always be seen as the same url by the proxy.
What's the problem with that scheme? It's hundreds of times faster on my second and subsequent machines - and would be for anyone else going through a proxy configured to cache large objects.
What is wrong with that scheme is that only 1 mirror is listed ... if you loose the connection, if it gets overloaded in the middle of your transfer, etc. then there is no failover.
Doesn't your geo-ip enabled DNS service drop non-responding servers? It has been much less trouble in practice from my locations than the fedora or centos4 repositories.
Yes ... but you didn't understand. let me try again.
mirror.centos.org is something that we own. There are 10 total servers. We pass out 1 address (because rrdns does not work correctly with python) ... that address is based on your IP and geoip relevant.
So ... you get 1 (and only 1 ) address to connect to.
If in the middle of you 100 packages, you have a glitch and loose your ability to connect to the server (it is overloaded, a router 3 hops down dies, etc. ... whatever) then that download fails and you drop out of yum.
If you are using a mirrorlist, there are 9 other urls to try if that happens.
NEXT REASON:
10 internal servers can not serve all the updates required ... 127 mirrors can. Those 127 mirrors are not named the same thing, nor are the paths the same. We can't pass them out as mirror.centos.org ... the mirror operators have chosen different paths that work for them, etc.
What we have done it built a system that will test them, pass to you 10 active, close and geoip relevant IPs in real time. If a mirror is out of date, it goes away.
For your situation, you can pick one mirror, use it in all your config files, then it will work perfectly for you in your cache.
Unless 127 people want to donate machines to CentOS.org to put under our control, then we can name them all mirror.centos.org and control their paths.
Have you ever tried to develop a mirror system that can provide updates to 1.5 million clients?
On Thu, 2006-09-07 at 13:49 -0500, Johnny Hughes wrote:
Yes ... but you didn't understand. let me try again.
mirror.centos.org is something that we own. There are 10 total servers. We pass out 1 address (because rrdns does not work correctly with python) ...
OK - so that's the real problem. I have always wondered why people liked python... Is this something that could be fixed? Can we shame them by pointing out that even IE does something fairly intelligent when handed multiple IP addresses some of which don't work?
that address is based on your IP and geoip relevant. So ... you get 1 (and only 1 ) address to connect to.
And that's the application's fault, not a technical requirement.
If in the middle of you 100 packages, you have a glitch and loose your ability to connect to the server (it is overloaded, a router 3 hops down dies, etc. ... whatever) then that download fails and you drop out of yum.
Application problem again, but still not particularly fatal as long as none of the packages from the run have been installed. Just run it again later.
If you are using a mirrorlist, there are 9 other urls to try if that happens.
I mostly get 'metadata out of sync' errors when that happens. It hasn't been as pretty as you suggest. And it often takes a 'yum clean' to fix, which is even worse than just picking up where you left off when your internet is working again.
NEXT REASON:
10 internal servers can not serve all the updates required ... 127 mirrors can. Those 127 mirrors are not named the same thing, nor are the paths the same. We can't pass them out as mirror.centos.org ... the mirror operators have chosen different paths that work for them, etc.
You could pass out any IP's you want as mirror.centos.org. It might be inconvenient for the sites to map a standard URL into their server layout so there might be some issues. Anyone running apache with named vhosts could do it if they wanted.
What we have done it built a system that will test them, pass to you 10 active, close and geoip relevant IPs in real time. If a mirror is out of date, it goes away.
That would also be fine if it always gave the same list in the same order when asked through the same proxy - if the client walks the list in order. Or if the URL to get this list was always the same and it is marked cachable for some time. There would be the possibility of a bad, stale copy but somewhat offset by having several alternatives.
For your situation, you can pick one mirror, use it in all your config files, then it will work perfectly for you in your cache.
People behind the proxies don't coordinate their choices of distributions or repositories, let alone which mirror to use of each repository. Besides, didn't you point out the problem of just using one IP already? How can you suggest that as a solution now?
Unless 127 people want to donate machines to CentOS.org to put under our control, then we can name them all mirror.centos.org and control their paths.
You don't have to control a machine to give out it's IP in a DNS response. You only have to arrange for it accept the name as a vhost and map the document root to the top of your mirror tree. That still may be a lot to ask but it is a very different question.
Have you ever tried to develop a mirror system that can provide updates to 1.5 million clients?
No, I deal with a few hundred machines spewing perhaps a hundred Mbs to the internet and my servers are all on the same continent but even at that scale the last thing I'd want to do is defeat anyone's local caching scheme and I go out of my way to give multiple IPs for the same URL for site redundancy instead of letting clients see different URLs.
The nature of your product is such that the odds are good that vast numbers of those boxes are located in some small number of places that would only pull one copy of an update if you didn't go out of your way to force each machine to get its own.
On Thu, 7 Sep 2006, Les Mikesell wrote:
That would also be fine if it always gave the same list in the same order when asked through the same proxy -
It will until it next checks the mirrors - which happen approx hourly - and then the mirrors within a cc are used randomly so as not to overload any particular mirror with al the traffic.
if the client walks the list in order.
It does - unless you use fastestmirror plugin
Or if the URL to get this list was always the same and it is marked cachable for some time.
It is always the same - mabe it needs marking as cachable ??
You don't have to control a machine to give out it's IP in a DNS response. You only have to arrange for it accept the name as a vhost and map the document root to the top of your mirror tree. That still may be a lot to ask but it is a very different question.
It is more than most mirrors will do - especially when they have varying format urls
The nature of your product is such that the odds are good that vast numbers of those boxes are located in some small number of places that would only pull one copy of an update if you didn't go out of your way to force each machine to get its own.
But at least we get to see how many machines are out there :)
Regards Lance
-- uklinux.net - The ISP of choice for the discerning Linux user.
On Thu, 2006-09-07 at 22:52 +0100, Lance Davis wrote:
That would also be fine if it always gave the same list in the same order when asked through the same proxy -
It will until it next checks the mirrors - which happen approx hourly - and then the mirrors within a cc are used randomly so as not to overload any particular mirror with al the traffic.
if the client walks the list in order.
It does - unless you use fastestmirror plugin
Or if the URL to get this list was always the same and it is marked cachable for some time.
It is always the same - mabe it needs marking as cachable ??
Hmmm, I think the default squid config excludes caching urls with ? argument lists - which usually makes sense. Could you, instead of randomizing the list at time intervals, construct 10 versions in differently sorted orders every time with a technique that will make each always the same unless the valid servers change, then return one of these versions based on a hash of the requesting IP address to make the distribution random but always give the same file version to the same requester? Then that file should always have the same first choice unless your probe took it out of the list.
You don't have to control a machine to give out it's IP in a DNS response. You only have to arrange for it accept the name as a vhost and map the document root to the top of your mirror tree. That still may be a lot to ask but it is a very different question.
It is more than most mirrors will do - especially when they have varying format urls
Agreed - I suspect you could find volunteers that would do it if you asked for a 'virtual' server instead of hardware, but intelligent mirror list management is probably better all around.
The nature of your product is such that the odds are good that vast numbers of those boxes are located in some small number of places that would only pull one copy of an update if you didn't go out of your way to force each machine to get its own.
But at least we get to see how many machines are out there :)
If you don't make the mirrorlist cachable you'll still get a good count of requests although you probably can't distinguish machines behind proxies. Making it (usually) return the same first choice to the same proxy requester will fix the rest.
Les Mikesell wrote:
On Thu, 2006-09-07 at 13:08 -0500, Johnny Hughes wrote:
What's the problem with that scheme? It's hundreds of times faster on my second and subsequent machines - and would be for anyone else going through a proxy configured to cache large objects.
What is wrong with that scheme is that only 1 mirror is listed ... if you loose the connection, if it gets overloaded in the middle of your transfer, etc. then there is no failover.
Doesn't your geo-ip enabled DNS service drop non-responding servers? It has been much less trouble in practice from my locations than the fedora or centos4 repositories.
But there is no geo-IP in Centos3 ...
Ralph
On Thu, 7 Sep 2006, Ralph Angenendt wrote:
Les Mikesell wrote:
On Thu, 2006-09-07 at 13:08 -0500, Johnny Hughes wrote:
What's the problem with that scheme? It's hundreds of times faster on my second and subsequent machines - and would be for anyone else going through a proxy configured to cache large objects.
What is wrong with that scheme is that only 1 mirror is listed ... if you loose the connection, if it gets overloaded in the middle of your transfer, etc. then there is no failover.
Doesn't your geo-ip enabled DNS service drop non-responding servers? It has been much less trouble in practice from my locations than the fedora or centos4 repositories.
But there is no geo-IP in Centos3 ...
Actually we do use geo-IP in the backend dns for mirror.centos.org - using powerdns and some custom perl.
That looks at the users location and will give a relevant mirror - however as we only have mirror servers in the us and eu it is prety moot for .au
We use that because it can give out one of a random list oif mirrors and thus spreads the load, whereas previously both yum and up2date hit only one of the set of mirrors in rrdns - due to a bug in the python libraries, and so all the load was taken by one server.
Lance
-- uklinux.net - The ISP of choice for the discerning Linux user.
Les Mikesell spake the following on 9/7/2006 10:47 AM:
On Thu, 2006-09-07 at 18:08 +0100, Lance Davis wrote:
CentOS 3 wont have the same issue because all updates are referenced via a round robin set of mirror.centos.org, which will always be seen as the same url by the proxy.
What's the problem with that scheme? It's hundreds of times faster on my second and subsequent machines - and would be for anyone else going through a proxy configured to cache large objects.
Maybe those claimed 1.5 million users are really a few users or locations with a lot of machines... Letting proxies work as designed would make sense to me.
Well the issue is that you want a proxy to always hit the same mirror - (which you can configure) whereas we want to spread the load between the mirrors ...
What I want is for the default install to work using standard cache techniques. The 'you can configure' concept only works if you know everyone else sharing the same proxy and can pre-arrange every file download with all of them which is pretty unlikely in any organization large enough to even have a proxy. A scheme that uses the same URL for the same file will always work automatically. If you do this, spreading the load won't be an issue since there will actually only be one download. If you can't use the same set of mirrors as centos3, there has to be some way to make this happen based on some computation that would be repeatable - perhaps a server-side check that can see the requester's public source address and give back the best mirror URL or a sorted list that would always be the same for that source IP.
If you are hoping for updates to hit a single cache, why not rsync over to a server and then yum-update from there. Better than a cache because you can control when the packages are there. Don't want to update today? Don't rsync over. Then you can have your other servers and workstations running yum in cron, and don't have to manually run yum-update on them. You will only have updates when you decide to mirror over from an official mirror.
chrism@imntv.com wrote:
If you read my earlier posts, you might have noticed terms like "download limits."
Most users don't have "all you can eat" plans, and if they exceed their quota they can be charged extra ($60-120 per gigabyte) or br throttled back to modemesque speeds.
What on Earth does that have to do with anything? You've got poor connectivity or expensive connectivity or both in the "last mile" part of your link to the Internet. How is changing the mirroring system going to help you or others like you?
You haven't shown how the mirroring system find a good mirror, and the evidence Johnny gave shows it doesn't.
There _are_ good mirrors, I wasted some time perusing broadband plans and found another (only has I32 and AMD-64, but finding zSeries was a surprise).
Your mirror system doesn't show them to users, and that's a problem to those users whom it costs.
_I_ think Debian handles mirrors pretty well, it lets me specify country and gives me a choice, and the names I see mean something.
Those Centos names might mean something to someone, but from here they just looked like someone chose random (or maybe consecutive) letters to differentiate their names. When I believed they are Australian, I tried to match them to Australian localities, but failed.
On Fri, Sep 08, 2006 at 12:18:28AM +0800, John Summerfield enlightened us:
chrism@imntv.com wrote:
If you read my earlier posts, you might have noticed terms like "download limits."
Most users don't have "all you can eat" plans, and if they exceed their quota they can be charged extra ($60-120 per gigabyte) or br throttled back to modemesque speeds.
What on Earth does that have to do with anything? You've got poor connectivity or expensive connectivity or both in the "last mile" part of your link to the Internet. How is changing the mirroring system going to help you or others like you?
You haven't shown how the mirroring system find a good mirror, and the evidence Johnny gave shows it doesn't.
IT seems to me your definition of "good" and everyone else's is not the same. You seem to think good means local to you - everyone else who doesn't have last mile cost considerations (probably a majority of non-AU users) just want to get their stuff the fastest - hence the fastest-mirror plugin.
I think that's pretty good evidence that for the majority of CentOS users, that's a good system.
There _are_ good mirrors, I wasted some time perusing broadband plans and found another (only has I32 and AMD-64, but finding zSeries was a surprise).
Your mirror system doesn't show them to users, and that's a problem to those users whom it costs.
We can't show them to users if we don't know about them. We aren't mind readers, contrary to popular belief.
_I_ think Debian handles mirrors pretty well, it lets me specify country and gives me a choice, and the names I see mean something.
http://www.centos.org/modules/tinycontent/index.php?id=13
Those Centos names might mean something to someone, but from here they just looked like someone chose random (or maybe consecutive) letters to differentiate their names. When I believed they are Australian, I tried to match them to Australian localities, but failed.
There may be a valid point here. I don't help manage the centosX servers, so I am unaware if they frequently change locations, etc. If they are relatively static, then perhaps a naming scheme that indicates country or continent of origin would be useful. But again - I don't think most people care. If a server half a world away is faster, I'm going to use that one.
Matt
Matt Hyclak wrote:
<snip>
There may be a valid point here. I don't help manage the centosX servers, so I am unaware if they frequently change locations, etc. If they are relatively static, then perhaps a naming scheme that indicates country or continent of origin would be useful. But again - I don't think most people care. If a server half a world away is faster, I'm going to use that one.
Matt
AAMOF, it hasn't been that many years ago that I would purposely choose a mirror halfway around the world to avoid connection limits and the slowdown that usually takes place before the absolute fixed limit is reached.
On Thu, 7 Sep 2006, Matt Hyclak wrote:
There may be a valid point here. I don't help manage the centosX servers, so I am unaware if they frequently change locations, etc. If they are relatively static, then perhaps a naming scheme that indicates country or continent of origin would be useful. But again - I don't think most people care. If a server half a world away is faster, I'm going to use that one.
The point is that those CentOS servers are not meant to be used - they are only there as a fallback , so given them descriptive locational names would not be helpful.
We try to make sure that enough external mirrors have the centos payload before we announce release, but to prevent yum hanging during release we populate the mirrorlist with centosx servers if there arent enough local mirrors.
That is a policy which we will now review.
Lance
-- uklinux.net - The ISP of choice for the discerning Linux user.
OK ... obviously I should explain how this works.
There are official CentOS public mirrors, there are listed here:
http://www.centos.org/modules/tinycontent/index.php?id=13
(There are 127 mirrors now, 112 of which are up2date and shown in the list)
There are also internal CentOS servers that are not published to general public ... they are used to update the public mirrors.
Mirrors get to be mirrors because they have asked to be listed. These public mirrors (and SOME of our internal centos mirrors) are the universe of mirrors that are available to our mirror system.
Some ISP mirror (who is not official) that one might know about is NOT part of our update system.
When someone asks for the mirrorlist, they are given all the local mirrors (that is, the ones inside and close to their country). As in the example given before ... Australia (au) there are 3 listed mirrors ... 2 of the 3 were passed in the mirrorlist (planetmirror has some content wrapping it that causes issues with our mirrorlist system).
Also included as close is Singapore (2 mirrors listed).
Since you have 4 listed mirrors, we backfill with 6 CentOS mirrors to make the total 10 (in other countries, there will be no back filled centos mirrors). The backfilled CentOS mirrors should not be first on mirrorlist (if fastestmirror is used) as the other mirrors should be closer.
fastestmirror works by making a socket connection to each mirror and timing the connection ... then ordered by time (fastest listed first).
This means that you have 10 mirror failover, and should have the closest mirrors (again, from the above link) to your individual PC.
If a mirror becomes outdated, it is removed from the list.
This allows us to use the public mirrors for updates, which means that there is enough bandwidth for everyone ... and it scales as we add mirrors.
The centosa -> centosc2 are not public mirrors, they are used as filler mirrors only. In the case of au, they would only be used if they were faster to you ... not likely unless the 4 mirrors that are closer are overloaded. In that case they would be used.
On Fri, 8 Sep 2006, John Summerfield wrote:
chrism@imntv.com wrote:
You haven't shown how the mirroring system find a good mirror, and the evidence Johnny gave shows it doesn't.
Ehhh ???
There _are_ good mirrors, I wasted some time perusing broadband plans and found another (only has I32 and AMD-64, but finding zSeries was a surprise).
Your mirror system doesn't show them to users, and that's a problem to those users whom it costs.
John, I am sorry but you are talking rubbish.
We only list mirrors that tell us they want to be listed. We are not about to go searching the net to find other ones.
And then we also check that they are up2date before listing them ...
If you know of mirrors that are not listed that have CentOS then maybe you could ask them to get in touch with us in order to be listed. Contact details are on the CentOS website.
_I_ think Debian handles mirrors pretty well, it lets me specify country and gives me a choice, and the names I see mean something.
As has already been mentioned in this thread - use Debian ...
Those Centos names might mean something to someone, but from here they just looked like someone chose random (or maybe consecutive) letters to differentiate their names. When I believed they are Australian, I tried to match them to Australian localities, but failed.
I dont know what CentOS names you are talking about - if you mean centosa->centosc2 then they are internal centos servers that will be pushd out to the mirrorlists if there are no other current mirrors. That will happen when we have just released - and is done as a service to users so they can pull stuff when mirrors dont have it.
As we have no servers donated to us in .au , none of them will be located there , but if you want to spend some time getting us some dedicated servers donated in .au then we would be very grateful.
Regards Lance >
-- uklinux.net - The ISP of choice for the discerning Linux user.
Lance Davis wrote:
On Fri, 8 Sep 2006, John Summerfield wrote:
chrism@imntv.com wrote:
You haven't shown how the mirroring system find a good mirror, and the evidence Johnny gave shows it doesn't.
Ehhh ???
The shortest "wire" was thousands of kilometres long. From a networking POV, that's not good.
There _are_ good mirrors, I wasted some time perusing broadband plans and found another (only has I32 and AMD-64, but finding zSeries was a surprise).
Your mirror system doesn't show them to users, and that's a problem to those users whom it costs.
John, I am sorry but you are talking rubbish.
We only list mirrors that tell us they want to be listed. We are not about to go searching the net to find other ones.
I'm only an ignorant user, I don't know how the Centos organisation works or how you found the systems you do list.
And then we also check that they are up2date before listing them ...
If you know of mirrors that are not listed that have CentOS then maybe you could ask them to get in touch with us in order to be listed. Contact details are on the CentOS website.
I'll ask the two I've found.
_I_ think Debian handles mirrors pretty well, it lets me specify country and gives me a choice, and the names I see mean something.
As has already been mentioned in this thread - use Debian ...
As I already said in this thread, I do.
Those Centos names might mean something to someone, but from here they just looked like someone chose random (or maybe consecutive) letters to differentiate their names. When I believed they are Australian, I tried to match them to Australian localities, but failed.
I dont know what CentOS names you are talking about - if you mean
They're in this thread.
centosa->centosc2 then they are internal centos servers that will be pushd out to the mirrorlists if there are no other current mirrors. That
I've been using the Internet for quite a few years; when I was learning its ins & outs, I read that one should choose a mirror that is relatively local (as measured by the wire).
There aren't that many wires out of Perth, and they're very long ones, so from our perspective geographic locality and topological locality are pretty much the same.
Use of mirrors on the opposite side of the globe when there's a nearer choice just goes to tie up bandwidth needlessly, increasing costs for all. It's a bad idea.
I don't know the current position wrt international data flow, but I'm thinking Australia pays for incoming data. There was a big fuss years ago, the US wanted to charge Australia for data from US to Oz, but not pay us for data Oz to US.
will happen when we have just released - and is done as a service to users so they can pull stuff when mirrors dont have it.
There were several other mirrors listed, so there were other mirrors available.
As we have no servers donated to us in .au , none of them will be located there , but if you want to spend some time getting us some dedicated servers donated in .au then we would be very grateful.
It wasn't apparent to me that any of the mirrors I saw in the list was dedicsted to CentOS, and I suspect some are shared with other mirrors.
On Sep 7, 2006, at 1:10 PM, John Summerfield wrote:
If you know of mirrors that are not listed that have CentOS then maybe you could ask them to get in touch with us in order to be listed. Contact details are on the CentOS website.
I'll ask the two I've found.
you may want to direct them to the "CentOS Mirroring HOWTO" page:
http://www.centos.org/modules/tinycontent/index.php?id=22
In a nutshell, it seems that your primary complaint with the mirror system concerns its inability to direct you to mirrors of which it is unaware. Fair enough; I imagine if you can persuade admins of local mirrors to register themselves with the CentOS team, the mirror system will direct you to them.
-steve
-- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
On Fri, 8 Sep 2006, John Summerfield wrote:
Lance Davis wrote:
On Fri, 8 Sep 2006, John Summerfield wrote:
chrism@imntv.com wrote:
You haven't shown how the mirroring system find a good mirror, and the evidence Johnny gave shows it doesn't.
Ehhh ???
The shortest "wire" was thousands of kilometres long. From a networking POV, that's not good.
All the mirror system knows is that your ip is in .au , it then gives a list of mirrors that are firstly in .au , then in adjacent countries eg .nz and then in countries slightly further afield. You should not get offered mirrors in .us or .eu if you are in .au .
Then it will fill the list to 10 entries with centos internal mirrors that are not designated to be in any particular location.
As an example
http://mirrorlist.centos.org/?cc=au&release=4&arch=i386&repo=upd...
gives
http://ftp.monash.edu.au/pub/linux/CentOS/4.4/updates/i386/ http://mirror.pacific.net.au/linux/CentOS/4.4/updates/i386/ http://mirror.averse.net/centos/4.4/updates/i386/ ftp://ftp.oss.eznetsols.org/linux/centos/4.4/updates/i386/ http://centose.centos.org/centos/4.4/updates/i386/ http://centosw.centos.org/centos/4.4/updates/i386/ http://centosi.centos.org/centos/4.4/updates/i386/ http://centosh.centos.org/centos/4.4/updates/i386/ http://centosg.centos.org/centos/4.4/updates/i386/ http://centosk.centos.org/centos/4.4/updates/i386/
That shows 2 current mirrors in au - that yum will use first (it does use these in order)
The status of all of our mirrors is shown at
http://mirror-status.centos.org/
That does show another .au mirror , but the mirrors are checked at approx hourly intervals - the repo checksum and timestamp are tested and if they are not contactable or do not give the correct data then they are not included in the list.
As we have no servers donated to us in .au , none of them will be located there , but if you want to spend some time getting us some dedicated servers donated in .au then we would be very grateful.
It wasn't apparent to me that any of the mirrors I saw in the list was dedicsted to CentOS, and I suspect some are shared with other mirrors.
All of the centosx where x is a -> c2 are servers donated to centos. These are also tested for currency before being included in the lists.
The real issue seems to be that there are not enough mirrors in .au - cf the us where the list would give you :-
http://mirrorlist.centos.org/?cc=us&release=4&arch=i386&repo=upd...
http://mirrors.jtlnet.com/centos/4.4/updates/i386/ http://altruistic.lbl.gov/mirrors/centos/4.4/updates/i386/ http://mirror.stanford.edu/yum/pub/centos/4.4/updates/i386/ http://mirrors.easynews.com//linux/centos/4.4/updates/i386/ http://aniani.ifa.hawaii.edu/CENTOS/4.4/updates/i386/ http://mirrors.tummy.com/mirrors/CentOS/4.4/updates/i386/ http://styx.biochem.wfubmc.edu/mirror/CentOS/4.4/updates/i386/ http://ftp.osuosl.org/pub/centos/4.4/updates/i386/ http://mirrors.kernel.org/centos/4.4/updates/i386/ http://wuarchive.wustl.edu/pub/linux/distributions/centos/4.4/updates/i386/
and there are still another 22 current mirrors that have not been listed - the list is (as I said above) regenerated approx hourly - and firstly gives a random set of up to 10 current local mirrors.
Regards Lance
-- uklinux.net - The ISP of choice for the discerning Linux user.
John Summerfield wrote:
Lance Davis wrote:
On Fri, 8 Sep 2006, John Summerfield wrote:
You haven't shown how the mirroring system find a good mirror, and the evidence Johnny gave shows it doesn't.
Ehhh ???
The shortest "wire" was thousands of kilometres long. From a networking POV, that's not good.
I know about Coriolis being different down under, but speed of light also?
Your mirror system doesn't show them to users, and that's a problem to those users whom it costs.
We only list mirrors that tell us they want to be listed. We are not about to go searching the net to find other ones.
I'm only an ignorant user, I don't know how the Centos organisation works or how you found the systems you do list.
Well, then *think*.
I've been using the Internet for quite a few years; when I was learning its ins & outs, I read that one should choose a mirror that is relatively local (as measured by the wire).
Yeah, that latency can get annoying if you go around the earth ~7 times.
There aren't that many wires out of Perth, and they're very long ones, so from our perspective geographic locality and topological locality are pretty much the same.
Use of mirrors on the opposite side of the globe when there's a nearer choice just goes to tie up bandwidth needlessly, increasing costs for all. It's a bad idea.
Then CentOS has to *KNOW* about these mirrors. If we don't - how do you expect those mirrors to get listed? By probing each ftp server world wide?
There were several other mirrors listed, so there were other mirrors available.
Yes. Mirrors which the CentOS team *knew* about.
Ralph
John Summerfield wrote:
You haven't shown how the mirroring system find a good mirror, and the evidence Johnny gave shows it doesn't.
There _are_ good mirrors, I wasted some time perusing broadband plans and found another (only has I32 and AMD-64, but finding zSeries was a surprise).
Your mirror system doesn't show them to users, and that's a problem to those users whom it costs.
But does CentOS *know* about those mirrors? Or are they mirroring it from somewhere without telling CentOS that they do so?
I don't see a possibility to query every ftp server and see if they mirror centos.
Ralph
John Summerfield spake the following on 9/7/2006 8:32 AM:
chrism@imntv.com wrote:
John Summerfield wrote:
Who cares? When I think of "local" in terms of an update mirror, all I care about is latency (less so) and bandwidth (more so)...the fact that a particular host is located in Perth or Ulan Bator or Los Angeles really isn't important to me. Getting the bits from point A to point B in the quickest and most reliable fashion IS important. I don't understand why you're so hung up on server location as physical geography is becoming less and less relevant as the world becomes more and more wired.
If you read my earlier posts, you might have noticed terms like "download limits."
Most users don't have "all you can eat" plans, and if they exceed their quota they can be charged extra ($60-120 per gigabyte) or br throttled back to modemesque speeds.
Okay, the minimum charge gor overuns seems to have come down since last I looked (I can't have ADSL here), but the top charge is pretty steep. See here for a sample of what people in other places have:
http://bc.whirlpool.net.au/bc-plan.cfm?state=wa&class=0&type=res&...
"shaped" means "throttled back severely."
This rabbit looks like a wounded bull!! http://bc.whirlpool.net.au/isp.cfm/Rabbit-Net-ADSL/678-1.html?p=7610
That is why geographic locality is important. And it's not just so for Western Australian, similar rules apply in at least some European countries.
I'm downloading at work (adsl there); while the boss knows, he will not be happy if he gets a Big Bill, or if the school gets "shaped."
It seems that the only mirror that would benefit you would be if your neighbor has a copy of what you want and a CD burner. I can understand the costs associated with quotas, but does the ISP care where you get the data? It seems as if 100GB from the US would cost just as much as 100 GB from Perth. It still crosses your "last mile".
On 9/7/06, John Summerfield debian@herakles.homelinux.org wrote:
Jim Perrin wrote:
Does this mean you don't wish to create a workable mirror system?
Just because it doesn't fit into how you think it should work doesn't mean it's not workable. Stop trolling.
I'm not trolling, I pointed out a serious problem with it and suggest how it could be improved.
The above comment I references is a passive-aggressive troll. If you do not wish it to be identified as such, then don't phrase it that way. There are a hundred different ways to get your point across without resorting to such things. Same thing for you comment about the naming scheme for centos[a-z] machines. Just because you don't know the meaning behind it doesn't mean there isn't one. If you wish people to be more receptive to your ideas, it's best not to antagonize them. The whole bees with honey vs vinegar bit.
I repeat, mirrors in Europe & the US are not local to Western Australia, and while Singapore is relatively close, still data crosses national boundaries; while I don't understand the implications of that, I am sure it doesn't have the same costs & rules that data-flows within Austealia have.
The mirrorlist script fills in 10 mirrors. If western Australia doesn't have 10 current repositories, then others get filled in. If you want more local mirrors listed, then get more people from western australia to contribute mirrors,and let us know that the mirrors are publicly available.
The fact that users get their data doesn't mean the mirror system is working well from their perspectice.
I also made the point that speed measurements from users' machines don't mean much in terms of the distance, or of the performance of the download over time. Since I wrote, a download that I started this morning at 100 KBytes/sec has since slowed to 12 Kbytes/sec or so.
The mirror system is a general shotgun approach to getting the best service to users. It works well for most of the million+ users as 99% of the feedback about it has been positive. There's no law that says you have to use the default file. If it doesn't work for you, then change the repo file to point to a mirror of your choosing and quit bitching about it.
I've just done a quick check, there is actually a Centos mirror here in Perth: it's on WAIX, but you don't list it. it's even got 4.4 in it. Not only, but including: lftp ftp.iinet.net.au:/pub/centos/4.4> dir os/s390x/ ---> PASV
I think it's also accessible by rsync (I've been getting some Debian from there by rsync) and http.
So comment out the mirrorlist and change the baseurl line to point to this mirror. Presto, you're now using a mirror local to you.
We're so far off the original post topic now it's not even funny.
Jim Perrin wrote:
On 9/7/06, John Summerfield debian@herakles.homelinux.org wrote:
Jim Perrin wrote:
Does this mean you don't wish to create a workable mirror system?
Just because it doesn't fit into how you think it should work doesn't mean it's not workable. Stop trolling.
I'm not trolling, I pointed out a serious problem with it and suggest how it could be improved.
The above comment I references is a passive-aggressive troll. If you
In contrast, I found Johnny's response pretty disappointing.
I'm not going to all this trouble to cause grief, I want something that works properly _for the user_, not that just seems to work.
Cheers John
-- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
Please do not reply off-list
On Fri, 2006-09-08 at 00:24 +0800, John Summerfield wrote:
Jim Perrin wrote:
On 9/7/06, John Summerfield debian@herakles.homelinux.org wrote:
Jim Perrin wrote:
<snip>
I'm not going to all this trouble to cause grief, I want something that works properly _for the user_, not that just seems to work.
I'm a user. It WFM. If you said "for additional users", I don't think anyone would see that as objectionable.
<snip> -- Bill
John Summerfield spake the following on 9/7/2006 9:24 AM:
Jim Perrin wrote:
On 9/7/06, John Summerfield debian@herakles.homelinux.org wrote:
Jim Perrin wrote:
Does this mean you don't wish to create a workable mirror system?
Just because it doesn't fit into how you think it should work doesn't mean it's not workable. Stop trolling.
I'm not trolling, I pointed out a serious problem with it and suggest how it could be improved.
The above comment I references is a passive-aggressive troll. If you
In contrast, I found Johnny's response pretty disappointing.
I'm not going to all this trouble to cause grief, I want something that works properly _for the user_, not that just seems to work.
It works properly for a great majority of the users. There is no way to make a system that works for "every user" without having the user pick a mirror and hope it works. That is what Debian does. It asks you to make a decision on what mirrors "you" want to use. It does not determine if those servers are serving on 100MBit lines or a 1.5 MBit T1. You pick from a list and hope they are fast and current. The CentOS system makes sure that only current servers that are geographically close "as possible" are given to you. You wouldn't want the server next door given to you if it hasn't fully synced with the master mirrors, because you would have lots of speed and no data to get.
Thread death. The last 30+ messages have had nothing to do with up2date vs yum. We're passing the 60 message mark. Let this thread die.
John Summerfied wrote:
Which is better? Why?
ever try deleting a package with up2date ?
I'll start with this: What has yum that provides this functionality: up2date -d -u
lftp http://url; mget *;
Karanbir Singh wrote:
John Summerfied wrote:
Which is better? Why?
ever try deleting a package with up2date ?
I'll start with this: What has yum that provides this functionality: up2date -d -u
lftp http://url; mget *;
That downloads stuff I don't have or want.
besides, it's not yum. I can write a script that does better, I did so before RHN, but it's not yum.
John Summerfied wrote:
What has yum that provides this functionality: up2date -d -u
lftp http://url; mget *;
That downloads stuff I don't have or want.
yum update; answer 'n' to the question, after the downloads are done :) look in /var/cache/yum/*
-
chrism＠imntv.com -
Jim Perrin -
John Summerfied -
John Summerfield
-
Johnny Hughes -
Karanbir Singh -
Lance Davis -
Lance Davis -
Les Mikesell -
Matt Hyclak -
Paul -
Ralph Angenendt -
Robert -
Scott Silva -
Steve Huff -
William L. Maltby