Pekka Pietikainen wrote:
I think a reasonable assumption would be that to use patch rpms you need the original FC<x> media (low-bandwidth users should have >
these around), and just have patch rpm for every errata.
Is providing a low bandwidth solution to updates really worth the extra testing and the extra mirroring..the extra drain on development and building resources. Are we saying that low bandwidth people are going to have to choose between rpmdiff packages and being able to use custom packages or Fedora Alternatives or 3rd party alternative rpms safely and effectively?
And you will have to require official mirrors to carry them...i really dont think optional carrying of this is going to really be all that useful. And i'm not going to step into the mirroring politics side of that argument. If official mirror maintainers see potential problems with carrying the rpmdiffs...their expert opinions need to be taking with grave attention.
-jef
On Thursday 08 January 2004 01:54 pm, Jef Spaleta wrote:
Is providing a low bandwidth solution to updates really worth the extra testing and the extra mirroring..the extra drain on development and building resources. Are we saying that low bandwidth people are going to have to choose between rpmdiff packages and being able to use custom packages or Fedora Alternatives or 3rd party alternative rpms safely and effectively?
When updates exceed 100MB _ALL_ users are low bandwidth, and dialup users are locked completely out. So they don't update at all, get hacked, and blame Linux.
that argument. If official mirror maintainers see potential problems with carrying the rpmdiffs...their expert opinions need to be taking with grave attention.
Absolutely. I would think mirror operators would love to reduce the load on their servers, which this would as I've envisioned it. And their bandwidth bill might even go down.
On Thu, 2004-01-08 at 20:17, Lamar Owen wrote:
On Thursday 08 January 2004 01:54 pm, Jef Spaleta wrote:
Is providing a low bandwidth solution to updates really worth the extra testing and the extra mirroring..the extra drain on development and building resources. Are we saying that low bandwidth people are going to have to choose between rpmdiff packages and being able to use custom packages or Fedora Alternatives or 3rd party alternative rpms safely and effectively?
When updates exceed 100MB _ALL_ users are low bandwidth, and dialup users are locked completely out. So they don't update at all, get hacked, and blame Linux.
I'm going to be a bit of a snob and say the following:
When the updates exceed 100MB I'm _still_ not a low bandwidth user.
If you want to spend this time more effectively do the following. write the code to take librsync and rpmlib so you can sync up two dirs of rpms with entirely different file names to one, current set.
so if you have foo-1.1-1.i386.rpm on one end and foo-1.2-1.i386.rpm on the other end - an rpm-aware rsync would be able to know that foo is one package and those files should be diff'd against each other to take the bits from foo-1.1-1.i386.rpm to make foo-1.2-1.i386.rpm
This would help mirror operators quite a bit. Thereby increasing the number of mirrors and hopefully helping out the low bandwidth users by there being more mirrors.
that argument. If official mirror maintainers see potential problems with carrying the rpmdiffs...their expert opinions need to be taking with grave attention.
Absolutely. I would think mirror operators would love to reduce the load on their servers, which this would as I've envisioned it. And their bandwidth bill might even go down.
A fair number of the mirror operators don't get bandwidth bills. A lot are at universities. And the mirror operators I've run into wouldn't like a system of hundreds upon hundreds of patches let's say 2 for every potential released errata for any package. It would eat up more time on rsync and in general be a pain to deal with.
-sv
On Thursday 08 January 2004 10:39 pm, seth vidal wrote:
On Thu, 2004-01-08 at 20:17, Lamar Owen wrote:
When updates exceed 100MB _ALL_ users are low bandwidth, and dialup users are locked completely out. So they don't update at all, get hacked, and blame Linux.
I'm going to be a bit of a snob and say the following:
Yes you are being a snob. Devilish snob at that.
When the updates exceed 100MB I'm _still_ not a low bandwidth user.
Well, neither am I for that matter, but not everyone has an OC-3 or better lighting their glass.
so if you have foo-1.1-1.i386.rpm on one end and foo-1.2-1.i386.rpm on the other end - an rpm-aware rsync would be able to know that foo is one package and those files should be diff'd against each other to take the bits from foo-1.1-1.i386.rpm to make foo-1.2-1.i386.rpm
This would help mirror operators quite a bit. Thereby increasing the number of mirrors and hopefully helping out the low bandwidth users by there being more mirrors.
So the end user still has to download many megabytes? It's a waste of bandwidth. It's a waste of time. And there are dialup users.
Absolutely. I would think mirror operators would love to reduce the load on their servers, which this would as I've envisioned it. And their bandwidth bill might even go down.
A fair number of the mirror operators don't get bandwidth bills. A lot are at universities.
And the universities (of which I am a part) still have to pay their bills for that OC-12 or 48 they have, which costs megabucks. I have numbers; I make those sorts of decisions here.
Somebody is footing the bill.
And the mirror operators I've run into wouldn't like a system of hundreds upon hundreds of patches let's say 2 for every potential released errata for any package. It would eat up more time on rsync and in general be a pain to deal with.
You still do not seem to understand that you would only have to have a single patch at any given instant. You would have the same number of files. They would be smaller.
You still do not seem to understand that you would only have to have a single patch at any given instant. You would have the same number of files. They would be smaller.
You do not seem to understand that it WOULDN'T WORK that way. People wouldn't have the next to last thing. And you'd have to keep N copies around.
I've read this entire thread and I've not yet seen a convincing answer to: user X has a version they pulled from test3 not the final fc release but they've applied most of the other patches up to the final fc. How do they get there. So you have to keep patches available or just end up back at square one. So not only am I keeping the original I'm ALSO keeping some patches on my mirror.
You're right, in the best of possible worlds it would work but I'm arguing for the bad cases b/c I'm not pangloss and you're not candide.
-sv
On Thursday 08 January 2004 11:04 pm, seth vidal wrote:
You still do not seem to understand that you would only have to have a single patch at any given instant. You would have the same number of files. They would be smaller.
You do not seem to understand that it WOULDN'T WORK that way. People wouldn't have the next to last thing. And you'd have to keep N copies around.
They would have to have whatever is considered the baseline, which, IMO, would be the last ISO respin package. Every patch would be relative to this baseline, not relative to the previous patch. If the patch gets too big, maybe you need to plop a full update and make it the new baseline.
I've read this entire thread and I've not yet seen a convincing answer to: user X has a version they pulled from test3 not the final fc release but they've applied most of the other patches up to the final fc. How do they get there.
A _user_ is not going to run test3. At least, hopefully they won't. But, I need to answer your question. If a user doesn't have as their local baseline package the same package as the one that is the current Official baseline, then that user will download the current Official baseline and the patch. Then keep the Official baseline somewhere locally, much like apt keeps everything you've ever downloaded in /var/cache/apt/archive (unless you clean it out). Download baseline RPMs as needed if the user can't provide a matching local baseline (and you check using MD5 or SHA sums). This situation would hopefully be pretty rare.
For the testing phase full-up updates are probably better; but upgrades aren't really supported from test releases anyway, right? (I still remember the wet noodle.)
So you have to keep patches available or just end up back at square one. So not only am I keeping the original I'm ALSO keeping some patches on my mirror.
You keep the baseline (which you are already mirroring as part of the OS distribution) and one patch for each erratum (if there are more than one errata for a package, like the kernel sometimes has, you keep a patch per errata). The baseline would be the last respin; if the package the user has as his local baseline doesn't match the crypto sum of the current official baseline, they have to download the current baseline. I should consistently use the word baseline instead of originals, yes?
You're right, in the best of possible worlds it would work but I'm arguing for the bad cases b/c I'm not pangloss and you're not candide.
I too am arguing for the bad cases, but, in my case, I'm arguing for the 'bandwidth-impaired.' Google for this topic; it gets thousands of hits of forum messages asking 'why can't Red Hat do this.'
This issue is solvable. And your replies are exactly why I requested comments, because thinking about how to answer your valid queries has helped me solidify my position.
Once upon a time, Lamar Owen lowen@pari.edu said:
Absolutely. I would think mirror operators would love to reduce the load on their servers, which this would as I've envisioned it. And their bandwidth bill might even go down.
I'll chime in with seth here: most mirrors probably don't result in bandwidth bills.
Is bandwidth paid for? Yes. However, if my mirror resulted in higher bandwidth bills, it'd be shut off immediately. We pay for several pipes (unmetered connections), and it just so happens that we use more inbound traffic on those pipes than outbound. My mirror just uses available outbound bandwidth (I'm working on a way for it to dynamically use nearly _all_ available outbound bandwidth, without impacting normal outbound traffic, but I'm not quite done yet). When we have a link go down, the first thing I do is throttle back the mirror bandwidth.
The only thing this mirror has ever cost the company is for a little bit of power and cooling, some rack space (which we have extra), and some of my time (but not much of that during work hours either). I'd like to upgrade it some, but I can't really; it is screwball hardware that I can't find RAM for anymore (anyone got 128MB SIMMs for an Intergraph 625R?).
On Thursday 08 January 2004 11:55 pm, Chris Adams wrote:
I'll chime in with seth here: most mirrors probably don't result in bandwidth bills.
That is a two-edged sword. While on one hand it's nice that mirrors don't necessarily cost much to operate, which means there are more mirrors; on the other hand if mirrors had to pay metered rates they would be more receptive to user bandwidth concerns. But that's not the main point. It seems that the people who can do something about the user problem don't care to do so. Ok.
In my case, I am careful with my bandwidth due to the stipulations on the grants that paid for it.
upgrade it some, but I can't really; it is screwball hardware that I can't find RAM for anymore (anyone got 128MB SIMMs for an Intergraph 625R?).
If I had any I'd be glad to send them your way.