On Tue, Oct 19, 2004 at 04:59:37PM -0700, Josh Triplett wrote:
> Wesley W. Terpstra wrote:
> > True enough, but as processors get faster, so does bandwidth.
> > I expect that ultimately, it will always need to be as fast as possible.
>
> Possibly; however, I think bandwidth grows far slower than CPU speed and
> overall system power. I do understand your concern, though.
Others have taken this up, but suffice to say: I wouldn't be so sure,
unless you have concrete numbers.
The main limiting factors on pushing bits these days are the price of
lines (fiber is dropping that drastically, for various reasons, at least
for long-haul) and the price of hardware that can push the bits at a high
enough speed.
I can't quote you numbers offhand, but having worked for 10+ years as a
network engineer (up to and including senior engineer for an ISP covering 4
states), I can tell you what the budget looked like and why.
> > Put the normal gcc version rsgt in main where the i386 deb has:
> > Recommends: rsgt-icc
>
> You cannot put a Recommends from main to non-main; the strongest
> relationship you can declare is Suggests.
>
> > rsgt-icc sits in contrib, completely built by icc (not just some .o s)
> >
> > Conflicts: rsgt
> > Provides: rsgt
> > Replaces: rsgt
>
> Right.
>
> > If an i386 user (with contrib sourced) runs 'apt-get install rsgt'
> > will that make apt install rsgt-icc? That's what I hope to accomplish.
>
> No, I don't believe it will. That's why when packages change names, it
> is common to still produce a binary package with the old name, which
> does nothing except depend on the new package. That doesn't help you in
> this case, of course. I think all you can do is add the Suggests:
> rsgt-icc to rsgt, have both packages Conflict/Replace/Provide the other,
> and provide a brief explanation in the README.Debian of both packages.
Or have rsgt-icc and rsgt-dfsg, and have a package rsgt with:
Depends: rsgt-dfsg | rsgt-icc
Since the dependancy can be met only with items available from main,
this is allowed (at least, as established in prior discussions), and is
far more obvious to most people, I think, than a Suggests on the same
package that one also has a Replaces/Provides/Conflicts.
(In particular, 'Conflicts' and 'Suggests' together is likely to cause a
great deal of brainache to the package install tools...)
On a sidenote, the ability to "tune into" a stream of (potentially
multicast) UDP packets at an arbitrary point, collect enough that you
have >= the size of the file, and know that you can recover the file is
something with *serious* potential from the network world point of view.
My one question, as an operator, is whether that sequence of packets has to
be sequential (it sounds like it doesn't, especially with the 20% packet
loss problem description). If not, something like this could have *very*
far-reaching impacts; if one turned on checksumming (available for UDP
packets natively, or one could do it in the protocol) to avoid bitrot, this
opens up a huge path to potentially simplifying a large set of problems
(and no, they're more or less nothing like the ones par can solve, as for
reasons discussed earlier by the author).
--
Joel Baker <fenton@debian.org> ,''`.
: :' :
`. `'
`-
Attachment:
signature.asc
Description: Digital signature