Umm, you, sir, are mistaken. The tivo stores all video content as mpeg2 data. The tools on the tivo simply read blocks from the drive and transmit them to something on the network. The problem comes from the exact format of that MPEG data -- very few mpeg players can understand the "broadcast" format of the data. (People looking at the mpeg bits were befuddled in seeing the packets with the size set to zero. That's perfectly legal and actually necessary for a live broadcast stream -- you don't know how big the packet is until you've generated it.)
The only possible exception is the DTivo where the data is scrambled on the way to/from the disk. But the data being scrambled is MPEG.
I'm a very big supporter of a firewire port for archiving recordings. I don't care if they scramble it so only the original tivo can play it back. USB is far too slow.
It has to do with routing logic rules... the most specific route is prefered./24 is more specific than/16. Traffic will not be balanced unless both providers announce the/24. (Yes, it's a mess, but only a small one.)
It was for memory. I was there. The "rule" existed before that little snafu, however, Sprint hadn't deployed the filter globally. (your sub-/19 network would work within Sprint but not leave their network.) There are other reasons for the limits, but memory is why Sprint actually did it. There's a limit to the amount of memory one can put in a Cisco 7000 (yes, seven zero zero zero... the 68040 powered pack-mule of the internet past) When it runs out of memory, very bad things start happening.
For an example, check 64.243.14.0/24 from various route servers... I know there are many more, but that's the first one I could find. Both the provider and "backup" MUST announce the specific/24 as it is more specific than the/20 summary announcement. But, yes, anyone ignoring the/24 would always head towards the/20 and would be unable to connect should that link break.
Actually, it happens all the time. We have five (5) sub-deligations from UUNET (3/21's, 2/22's) that are "ours" (as long as we have a link with UUNet) to announce as we want. I've not actually tested this, but I would assume we could stop announcing them to UUNet. Digex (I know, not the brightest bulb on the tree) once screwed things up -- removed a static route and refused to put it back -- and we had to announce our piece of the their address space back to them.
We have customers bringing other people's address space to us and carrying our space to others. On the whole, it's rare.
Correction: the suits were always ignoring the network; the network could be literally in fire 3 days a week as long as no customers complained about it.
As others have stated, "down-sizing" and "restructuring" are the biggest players. The people who knew what they were doing and cared about the network are either not there or no longer in a position to maintain what they created. There may very well be capable, qualified people in charge, but it takes time to learn the "how and why" of an any network's configuration. It's hard to fix problems you don't know are there; and no one in their right mind is going to screw with it if they think everything is working. (or no one should)
While that used to be true -- Sprint wouldn't accept anything longer than/19 because their routers didn't have the memory for it, it's not true anymore as modern routers can hold a great deal of memory. The generally accepted rule is not to do BGP for anything less than a/24. Anything less than/20 is not guaranteed to be globally routable but generally is.
As I point out to (stupid) customers: Anything smaller than a/20 may not be globally routable; Do not complain to me if there are places on the net to which you cannot connect.
And point-of-fact, the BGP routing spew from SAVVIS has things as small as/29's in it. *sigh*
Win2K pro is one damn good product... as long as you run it on sound hardware with no (unsigned) 3rd party drivers and never ever let the unwashed masses of the Internet near it. NT 4.0 is the same way.
I have a w2k-pro system that works great when it works. However, it has a slightly buggy VIA chipset and a gfx card that can draw slightly more power than the system is designed to feed to the slot, so when it crashes, it really crashes... I have to power it down (true power down) for a few seconds to get everything to come back up correctly.
Vs. my Sony Viao laptop runnng XP (home/pro doesn't matter which) that tends to reboot instead of wake-up about 40% of the time. And I have to disable (via. regedit) the AMD processor driver to keep it from freezing 4 or 5 times a day. (there's nothing wrong with the hardware, btw.)
I have two of those key generators. They both spit out a very short list of unique keys. And every one of them is invalid -- pre- and post- SP1. ('tho, the list of ones collected by someone at some Best Buy/CompUSA has very few that don't work.)
[jfbeam:pts/0]gir:~/[10:54pm]:host download-2.rhn.redhat.com download-2.rhn.redhat.c om is an alias for rhn.redhat.com.edgesuite.net. rhn.redhat.com.edge suite.net is an alias for a198.g.akamai.net. a198.g.akamai.net has address 216.187.223.229 a198.g.akamai.net has address 216.187.223.230
That would be one of the local co-lo'd akamai cache servers. And the traffic load to those servers hasn't changed.
Makes me wonder why so many people are getting 3k/s downloads.
First, Akamai will not cache files that large. RH9 would consume nearly 10% of one remote caching node's storage and the time taken to download the file would clog-up the server.
Second, Akamai doesn't cache crap for free. And those people hosting caches (free for the hoster, free for Akamai) would be less than pleased to see their local cache servers monopolized by Redhat CDs.
Lastly, Redhat will never be able to buy enough bandwidth to serve the user base. Mirrors are good, but Redhat has gone way downhill with respect to mirrors over the years. (speaking as a former mirror admin) However, most people don't use the mirrors because they are so scattered and random... finding a fast server or one local to you (network proximity has nothing at all to do with physical proximity) that actually carries what you're looking for is often fruitless.
Heh, I started at 270 days:-) It completed in under an hour. I'm now uploading at 1.2MB/s (yes, BYTES) -- dropped to 700kB/s while opening the "reply to window":-) I don't have enough RAM to cache 1.7GB.
Leach all you want people, but my laptop is coming home with me when I leave in few hours. (If I feel generous, I'll fire up bt on gir (linux/x86) or seamonkey (solaris/sparc) and hide the traffic graphs:-))
Small correction... Ringer Equivalence is a measure of power for a phone. POTS phones are line powered and there's only so much power available.
The phone company cannot simply measure the power draw and know exactly how many phones you have. They can get an idea, but not an exact number. They can confirm what you have registered with them
I've always used a "pulse" phone. F***in' Bellsouth changed $0.25/month for 30 years for the priviledge to use touch tone. (How many hundred million did that pad their pockets?) Counting pulses is very difficult for modern phone switches -- your average 10 year old can build a tone decoder with little more than duct tape and fruit loops.
Both of my grand mothers (and one great grand mother) had those ancient ("antique") AT&T phones until AT&T came to collect them. Back then, there were no jacks... the phone was wired to a block nailed to the wall.
ISDN is expensive entirely because PUCs allowed it to be tariffed higher. At the time, there really was a substantial cost to providing ISDN as most of the switching systems were analog. This goes hand-in-hand with that stupid f***ing $0.25 Bellsouth charged per month for "touch tone service" for over 20 YEARS -- they stoped a few years ago. The PUCs allowed the charge to recover some of the costs of upgrading switching equipment to include tone decoders. (I have, of course, always used a Radio Shack pulse phone... it's very hard on a "modern" switch to deal with pulse dialing these days. And sometimes, it simply gets it wrong.)
If telcos had any sense, they'd offer packet switched voice and data services via ISDN. One can oversell the shit out of packet switched networks (eg. Frame Relay.)
Oh, and ISDN isn't expensive everywhere... TN seems to have been awake when Bell walked in with their tariff proposal. I do beleive TN has the cheapest ISDN offering on the planet.
No ammount of hocus-pocus is going to speed up the 64k channel of a POTS line... 8000 PCM codes per second -- if you're lucky, the modem will be able to use 6 bits per code.
Stac compression within PPP has been around for a decade. Why is this suddenly something I have to pay for? Bellsouth.Net intentionally disables software compression to "reduce the time it takes to connect." Obviously, the time it takes to negotiate CCP -- some almost unmeasurable fraction of a second -- is very important; those are bytes of pr0n you could've downloaded. I have an ISDN line; it takes 3 seconds to login... all 3 of those seconds are spent waiting for an IP address (IPCP). Calling into work takes less than a second and it's bonding both channels and negotiating several other options bellsouth will never enable.
The important part...
on
8.6 GB Internet?
·
· Score: 2, Insightful
The demonstrations used a 10 Gbps link...
So, stop making it sound like one can turn a 28.8 modem into a cable modem. Parallel downloading is nothing new (rate limited ftp servers have been around for years.)
They have a history of successfully digesting acquired companies...
Tell that to Telebit. Cisco bought them, took the Mica Modem technology (dsp based modems), and cast everything else aside. Telebit had (has?) the best terminal server platform to have ever existed in the history of mankind: a 386dx40, 4M RAM, running completely from a single 1.44M floppy (and the disk isn't full), hosting 192 PPP sessions. (and yes, the system is a standard 386 PC with a telebit BIOS. With a small amount of work, one can get "fred" to load on any PC.) IOS is f***ing horrible as a terminal server. And the cpu+memory requirements of modern systems couldn't be worse if they were java based.
You mean "to the employees still there." Cisco has laidoff a good many people and changed almost every aspect of how they do business...
All that hardware they "gave" to companies that went out of business is in the hands of the highest bidder -- Cisco getting nearly nothing in return -- and now being sold on the used hardware markets (again, Cisco gets zero income. And if you can buy it used, why pay Cisco 10x more for new?) It used to be, you could put a support contract on anything with a Cisco logo on it. Not true today -- in fact, you can run into problems covering hardware purchased directly from cisco if you leave it off support too long.
Slashdot Mirror
Umm, you, sir, are mistaken. The tivo stores all video content as mpeg2 data. The tools on the tivo simply read blocks from the drive and transmit them to something on the network. The problem comes from the exact format of that MPEG data -- very few mpeg players can understand the "broadcast" format of the data. (People looking at the mpeg bits were befuddled in seeing the packets with the size set to zero. That's perfectly legal and actually necessary for a live broadcast stream -- you don't know how big the packet is until you've generated it.)
The only possible exception is the DTivo where the data is scrambled on the way to/from the disk. But the data being scrambled is MPEG.
I'm a very big supporter of a firewire port for archiving recordings. I don't care if they scramble it so only the original tivo can play it back. USB is far too slow.
It has to do with routing logic rules... the most specific route is prefered. /24 is more specific than /16. Traffic will not be balanced unless both providers announce the /24. (Yes, it's a mess, but only a small one.)
It was for memory. I was there. The "rule" existed before that little snafu, however, Sprint hadn't deployed the filter globally. (your sub-/19 network would work within Sprint but not leave their network.) There are other reasons for the limits, but memory is why Sprint actually did it. There's a limit to the amount of memory one can put in a Cisco 7000 (yes, seven zero zero zero... the 68040 powered pack-mule of the internet past) When it runs out of memory, very bad things start happening.
/24 as it is more specific than the /20 summary announcement. But, yes, anyone ignoring the /24 would always head towards the /20 and would be unable to connect should that link break.
For an example, check 64.243.14.0/24 from various route servers... I know there are many more, but that's the first one I could find. Both the provider and "backup" MUST announce the specific
Actually, it happens all the time. We have five (5) sub-deligations from UUNET (3 /21's, 2 /22's) that are "ours" (as long as we have a link with UUNet) to announce as we want. I've not actually tested this, but I would assume we could stop announcing them to UUNet. Digex (I know, not the brightest bulb on the tree) once screwed things up -- removed a static route and refused to put it back -- and we had to announce our piece of the their address space back to them.
We have customers bringing other people's address space to us and carrying our space to others. On the whole, it's rare.
Correction: the suits were always ignoring the network; the network could be literally in fire 3 days a week as long as no customers complained about it.
As others have stated, "down-sizing" and "restructuring" are the biggest players. The people who knew what they were doing and cared about the network are either not there or no longer in a position to maintain what they created. There may very well be capable, qualified people in charge, but it takes time to learn the "how and why" of an any network's configuration. It's hard to fix problems you don't know are there; and no one in their right mind is going to screw with it if they think everything is working. (or no one should)
While that used to be true -- Sprint wouldn't accept anything longer than /19 because their routers didn't have the memory for it, it's not true anymore as modern routers can hold a great deal of memory. The generally accepted rule is not to do BGP for anything less than a /24. Anything less than /20 is not guaranteed to be globally routable but generally is.
/20 may not be globally routable; Do not complain to me if there are places on the net to which you cannot connect.
/29's in it. *sigh*
As I point out to (stupid) customers: Anything smaller than a
And point-of-fact, the BGP routing spew from SAVVIS has things as small as
Win2K pro is one damn good product... as long as you run it on sound hardware with no (unsigned) 3rd party drivers and never ever let the unwashed masses of the Internet near it. NT 4.0 is the same way.
I have a w2k-pro system that works great when it works. However, it has a slightly buggy VIA chipset and a gfx card that can draw slightly more power than the system is designed to feed to the slot, so when it crashes, it really crashes... I have to power it down (true power down) for a few seconds to get everything to come back up correctly.
Vs. my Sony Viao laptop runnng XP (home/pro doesn't matter which) that tends to reboot instead of wake-up about 40% of the time. And I have to disable (via. regedit) the AMD processor driver to keep it from freezing 4 or 5 times a day. (there's nothing wrong with the hardware, btw.)
... and no one suggested saving all that cash by turning off HT? (Most BIOSes can do that.)
I have two of those key generators. They both spit out a very short list of unique keys. And every one of them is invalid -- pre- and post- SP1. ('tho, the list of ones collected by someone at some Best Buy/CompUSA has very few that don't work.)
(And no, neither keygen is virus.)
better quality porn ads
Is there such a thing?
No, TiVo does not own and/or operate the AVS Forum.
Well, that makes it easier to steal... It's not hard to save two copies of your work and carry one of the home with you.
... and upon inspection, the address space is within the domain of RIPE which is odd for hardware inside the US. But, looking at the records...
...
inetnum: 80.15.249.0 - 80.15.249.239
netname: AKAMAI-FT-US
descr: Akamai Technologies - US machines connected to FT AS5511
country: US
source: RIPE
That depends on who's nameserver you ask :-)
c om is an alias for rhn.redhat.com.edgesuite.net.e suite.net is an alias for a198.g.akamai.net.
[jfbeam:pts/0]gir:~/[10:54pm]:host download-2.rhn.redhat.com
download-2.rhn.redhat.
rhn.redhat.com.edg
a198.g.akamai.net has address 216.187.223.229
a198.g.akamai.net has address 216.187.223.230
That would be one of the local co-lo'd akamai cache servers. And the traffic load to those servers hasn't changed.
Makes me wonder why so many people are getting 3k/s downloads.
First, Akamai will not cache files that large. RH9 would consume nearly 10% of one remote caching node's storage and the time taken to download the file would clog-up the server.
Second, Akamai doesn't cache crap for free. And those people hosting caches (free for the hoster, free for Akamai) would be less than pleased to see their local cache servers monopolized by Redhat CDs.
Lastly, Redhat will never be able to buy enough bandwidth to serve the user base. Mirrors are good, but Redhat has gone way downhill with respect to mirrors over the years. (speaking as a former mirror admin) However, most people don't use the mirrors because they are so scattered and random... finding a fast server or one local to you (network proximity has nothing at all to do with physical proximity) that actually carries what you're looking for is often fruitless.
Heh, I started at 270 days :-) It completed in under an hour. I'm now uploading at 1.2MB/s (yes, BYTES) -- dropped to 700kB/s while opening the "reply to window" :-) I don't have enough RAM to cache 1.7GB.
:-))
Leach all you want people, but my laptop is coming home with me when I leave in few hours. (If I feel generous, I'll fire up bt on gir (linux/x86) or seamonkey (solaris/sparc) and hide the traffic graphs
People are stupid, but they aren't that f***ing dumb.
Small correction... Ringer Equivalence is a measure of power for a phone. POTS phones are line powered and there's only so much power available.
The phone company cannot simply measure the power draw and know exactly how many phones you have. They can get an idea, but not an exact number. They can confirm what you have registered with them
/me raises his hand
I've always used a "pulse" phone. F***in' Bellsouth changed $0.25/month for 30 years for the priviledge to use touch tone. (How many hundred million did that pad their pockets?) Counting pulses is very difficult for modern phone switches -- your average 10 year old can build a tone decoder with little more than duct tape and fruit loops.
Both of my grand mothers (and one great grand mother) had those ancient ("antique") AT&T phones until AT&T came to collect them. Back then, there were no jacks... the phone was wired to a block nailed to the wall.
"because they can" -- basicly.
ISDN is expensive entirely because PUCs allowed it to be tariffed higher. At the time, there really was a substantial cost to providing ISDN as most of the switching systems were analog. This goes hand-in-hand with that stupid f***ing $0.25 Bellsouth charged per month for "touch tone service" for over 20 YEARS -- they stoped a few years ago. The PUCs allowed the charge to recover some of the costs of upgrading switching equipment to include tone decoders. (I have, of course, always used a Radio Shack pulse phone... it's very hard on a "modern" switch to deal with pulse dialing these days. And sometimes, it simply gets it wrong.)
If telcos had any sense, they'd offer packet switched voice and data services via ISDN. One can oversell the shit out of packet switched networks (eg. Frame Relay.)
Oh, and ISDN isn't expensive everywhere... TN seems to have been awake when Bell walked in with their tariff proposal. I do beleive TN has the cheapest ISDN offering on the planet.
V.42 and MNP5 (or is it 4) have been around for a decade (+/-) Ascend and Stac data compression have been around just as long.
No ammount of hocus-pocus is going to speed up the 64k channel of a POTS line... 8000 PCM codes per second -- if you're lucky, the modem will be able to use 6 bits per code.
Stac compression within PPP has been around for a decade. Why is this suddenly something I have to pay for? Bellsouth.Net intentionally disables software compression to "reduce the time it takes to connect." Obviously, the time it takes to negotiate CCP -- some almost unmeasurable fraction of a second -- is very important; those are bytes of pr0n you could've downloaded. I have an ISDN line; it takes 3 seconds to login... all 3 of those seconds are spent waiting for an IP address (IPCP). Calling into work takes less than a second and it's bonding both channels and negotiating several other options bellsouth will never enable.
The demonstrations used a 10 Gbps link...
So, stop making it sound like one can turn a 28.8 modem into a cable modem. Parallel downloading is nothing new (rate limited ftp servers have been around for years.)
- They have a history of successfully digesting acquired companies...
Tell that to Telebit. Cisco bought them, took the Mica Modem technology (dsp based modems), and cast everything else aside. Telebit had (has?) the best terminal server platform to have ever existed in the history of mankind: a 386dx40, 4M RAM, running completely from a single 1.44M floppy (and the disk isn't full), hosting 192 PPP sessions. (and yes, the system is a standard 386 PC with a telebit BIOS. With a small amount of work, one can get "fred" to load on any PC.) IOS is f***ing horrible as a terminal server. And the cpu+memory requirements of modern systems couldn't be worse if they were java based.You mean "to the employees still there." Cisco has laidoff a good many people and changed almost every aspect of how they do business...
All that hardware they "gave" to companies that went out of business is in the hands of the highest bidder -- Cisco getting nearly nothing in return -- and now being sold on the used hardware markets (again, Cisco gets zero income. And if you can buy it used, why pay Cisco 10x more for new?) It used to be, you could put a support contract on anything with a Cisco logo on it. Not true today -- in fact, you can run into problems covering hardware purchased directly from cisco if you leave it off support too long.