Is your product in the 98th percentile of the software industry in profitability/unit counts sold?
How big is your development team compared to the 4 band members + a producer? It's probably larger than 5. (Sure, there's manufacturing, and other infrastructure at both places, but customer support is not as big a cost for record labels as your software gig, I'd think).
Still, if you take over the user's session after the user has authenticated, OR pop up a trojan dialog asking the user to type in his PIN, the fact that a nice fancy hardware token has been used doesn't matter anymore.
Token authentication is used to try and clean up all kinds of security problems that it doesn't address well-- problems with the client computer being owned, or using unencrypted transport (which is vulnerable to sequence prediction or sniffing to hijack the session, even if the password itself is not replayable).
Re:But wait, now what would you pay?
on
HDTV via GNU Radio
·
· Score: 2, Informative
You don't really need a $1299 A/D board if you want to start playing with GNU Radio, unless you want to decode a high bandwidth signal like HDTV.
For a couple hundred bucks, you can get an A/D board up to a couple hundred kilohertz, and then hook it up to the IF of any cheap old radio you have sitting around.
If you met all the conditions, yes that would be safe under the DMCA. This might include doing other things the copyright holder is using to control access-- like region coding. This is unclear from the law.
HOWEVER, please note that the original version of the CSS code was a theft of trade secrets from reverse engineering in violation of a clickthrough license.. and for that reason knowledge that is "tainted" by that reverse engineering has been ruled illegal as well.
And this is redundant why? I see nothing similar in posts above. And this is a time-honored trick that intelligence agencies use to get around limitations in their charters.
Would you feel the same way if the object of the game was to crash a plane into a US city?
To be honest, playing the original Microsoft Flight Simulator at age 6, I thought the purpose -was- to crash a plane into the Sears Tower.
BUILDING CRASH
As to this-- look, there's tons of North Korean and Iraqi movies about the downfall of America in various ways. Every side spins things the way they will, and I like playing games with conflicts/weapons I can relate to. And killing a lot of Russians in Operation Flashpoint doesn't mean I hate Russians.
At best multiple encryption makes it take longer to brute force the keyspace. It doesn't add security. Period.
When we're talking about block ciphers, using multiple encryption adds rounds. And generally with increased numbers of rounds an algorithm's strength against cryptanalysis increases. Just about every block cipher uses rounds, which could be viewed as a form of "multiple encryption". Obviously care has to be taken to be sure that you're not inadvertently undoing some of the encryption by reusing the key (e.g. encrypting twice with a XOR-based stream cipher would obviously return the original data). In effect, additional encryptions with the same key serve to diffuse the original data even better in many cases.
One of the key metrics of a cipher's strength is how strong it is in comparison to its key size. 256 bit ciphers, if brute force is the best attack, are immune to brute force with any imaginable technology (it is hard to imagine building a machine with matter that can count to 2^256, let alone try and brute force a cipher).
Making the key huge just makes the other potential sources of compromise (compromise by bad key generation or distribution) easier. If you want a huge keystream, you might as well use a large one time pad.
I don't really see what the point is of this encryption scheme.
Unless you're talking about the brand-spanking-new (and really cool, but stil unshipped) technology from Vivato, this isn't the way things work. There's only so much spectrum, and you can only fit so much data onto that spectrum. Adjacent access points need to be on different channels in most circumstances for this reason. There's only so much spectrum and you can only fit so much data onto it.
Vivato uses "packetsteering" (phased array technology) to receive different signals from different directions simultaneously. But existing 802.11b doesn't allocate a seperate 11mbps to each user. In fact, if you have just 1 802.11b user and 1 802.11g user, the 802.11g user will only get like 15-16mbps of throughput.
The thing is, intercepting an orbit is also very very expensive in propellant (in fact, if it involves a significant change to the orbit's inclination, it's basically impossible). So it's not like you could launch multiple of these "backpacks" from one launch.
Even though satellites are very expensive due to the (over)engineering involved, they have limited design lifetimes. And when a launch is going to cost you $50M, you're better off just replacing whatever you have with something that meets your current needs-- and something that sets the component failure lifetime clock over again.
This doesn't even mention the difficulty of trying to hook up to the satellite's power bus, etc.
When we're talking about geosynchronous satellites, or near-geosynchronous satellites, the orbital period is going to be remarkably close to 24 hours.
The answer: Maybe, but probably not. Usually the satellites have control computers and bringing them back up after they've been powered off can be difficult. It also depends on how the satellite's power system is arranged.
It's also important to note that the closer it gets to midnight, the closer to the horizon (and thus, the harder to listen to) a satellite has to be to be in sunlight-- and there's not likely to be as many geosynchronous satellites over unpopulated latitudes.
The fact that stabilization coils and reaction wheels go offline when the satellite's battery discharges means the satellite might very well begin tumbling and thus not get so much useful power when it returns to daylight-- and also not know its exact attitude to begin to recover.
Finally, the failure mode of the battery is important. If the battery fails "closed", or shorted, it might connect the negative sides of the power bus to the positive and not allow the panel to generate any useful power.
Basically, when power systems start to fail on a satellite, even when it's a temporary problem (e.g. an accidental discharge of the batteries because of an orientation problem), it can be pretty hard to recover from-- if it's possible at all.
I don't think we should completely abandon manned space missions, but the ISS is going to cost $100B over its lifetime-- figuring that the cost of a 4 year university education is $100k, we could create a million more scientists on earth-- and think how much that could do to solve the autonomous control and robotics problems that currently limit unmanned missions.
Right now, basically 2 of the 3 members of the ISS crew are dedicated to doing things to keep the ISS running. Surely with $100B we could get as much real space science done as that one individual who's concentrating on science on the ISS over these next 10 years can, right?
Let's learn what we can now cheaply, and regroup in 10-25 years and go to Mars, or form a colony on the moon, or do something else really radical that broadens the future for mankind.
Most older communications satelites have what are called "transponders"-- they take everything that comes in on a certain band of frequencies and plays it out on another set.
Because usually relatively high-bandwidth analog signals with high quality requirements are sent through these transponders, and the satelites have a relatively small amount of output power, high gain antennas (big satelite dishes) are required to recover the signal, which must be very precisely pointed.
By using digital signals and audio compression technology, suddenly the signals can be narrower bandwidth. Noise is proportional to bandwidth, and since the signal is narrower, signal/noise ratio is improved. This means high-gain antennas may no longer be strictly necessary, and thus the position of the satelite becomes less critical as the orbit decays.
Note that this does not lock us in to a proprietary standard-- if the spectrum is allocated for this purpose, smarter digital transmitters can be put into space for the same purpose later.
Still important is attitude control-- the satelite's antenna must be pointed down and the solar panels pointed in a useful direction. But this often uses gyroscopes, reaction wheels, and magnetic systems-- which do not use propellant.
Finally, battery life is a question. No communications satelite is constantly receiving solar power, so if the satelite is operated while not in view of the sun, batteries on the satelite discharge. Satelites can withstand a limited number of charge cycles before they fail, and this is likely to form the true upper bound on satelite lifetime.
In all, it's a good idea. I imagine we'll see lots of clever ways to emerge on how to use legacy hardware we've put in space, as launch costs remain so expensive.
Lots of people are posting on how this is potentially a bad idea. Sure, it's not likely to be as mature as other compiler environments. There's all kinds of small shops where this could simplify build infrastructure, though. Maintaining different build servers for all the platform variation a company chooses to support can be costly to build, especially with the infrastructure to do revision control and fire off simultaneous builds and package things together. If a company just needs to produce command line tools or simple DLL's to accelerate code in a scripting language, this might be a good choice.
Probably the largest win is allowing developers to unit test application logic on their local Windows desktop, if they prefer that environment, before doing final unit test, integration test, and deployment on top of *nix/Linux.
It probably doesn't because there's probably good known plaintext that's only encrypted by the 40 bit encryption, like the boot blocks. In this case, your statement is true.
But if it was all encrypted in AES, and then in DES with a completely different key-- I don't see how you can say that the DES doesn't provide proportionally more strength by the relative keylengths. Just like TEMK doesn't provide 2* 2^56, but more like 2^112 of brute force complexity.
I think it's important to note that in the real world, besides having great diversity in species, we still have diseases. I agree that having a small amount of immunity can slow down an emerging worm. But RDBMS's are not exactly plentiful on the internet compared to many other software categories, and yet we see a successful worm. Apparently the density of vulnerable hosts can be fairly low to have a nearly instantaneous effect-- computer worms spread a lot faster than viruses in the real world because the diameter of the network (the shortest "direct" path between nodes) is effectively 1.
The highest estimate I've seen of compromised hosts (which should closely match the number of vulnerable hosts in this case, because every exposed IP on the internet was receiving these packets) is about 22000. That equates to a density of.00000588 vulnerable hosts per valid-looking IP address. That's a really low number to be the base for your exponential growth curve (even Webstar, the #10 webserver with a 0.51% share, has 4x this density. You'd need more than 800 implementations of webservers with equal share to get below the density of MS SQL Server on the net). Basically it appears every vulnerable host on the internet was compromised within a few minutes.
At only 2500PPS, that's 1 infection per infected host per minute in the early phases of the worm; e.g. the number of infected hosts should be close to 2^t, where t is the time in minutes, at that packet rate. Needless to say, this gets big fast. Halving the vulnerability rate would make this 2^(t/2), which would still make it spread pretty fast compared to the cleanup and response rate. And that assumes that the worm uses a purely random spread method like this one does. Even in a truely heterogenous internet, it's likely that similar hosts will clump together and be able to send each other packets faster, so there are better spread methods available.
It's really difficult to configure routers, especially core routers, to block unusual traffic patterns. The lack of aggressive filtering, IMO, is why we have these problems.
Standards are imperfect. Software implementations of the standards, too, are imperfect, for a variety of reasons (deliberate and accidental). Even working to develop software within one company, with specs that are designed to guarantee interoperability can result in surprises. Do we really need a hundred general-purpose RDBMS's in the world? And the resultant specialization in knowledge that will result from different practices in tuning, etc? And the difficulty in keeping all those different kinds of servers patched in real-world operational practice? I don't think so.
I don't see how avoiding the monoculture makes things safer. Running the numbers, having more kinds of web servers out there makes the internet more dangerous for denial of service-- both as a byproduct of a worm or deliberately. All having more kinds out there does is simplifies the scope of the cleanup operation when the catastrophic does happen-- improves the worst case at the cost of having it occur more often.
I think it's unrealistic and counter to the overall goal to interoperability of the internet to have so many implementations, and such variance in what implementations that are used, that no one has greater than a 15% share.
As to MS SQL creating a larger share of vulnerable installations-- yes, I had thought of that. Products aimed at low-end installations certainly need more hardening. Of course, you could also argue that the average MS SQL server installation has a lot less bandwidth to throw around than the average Oracle deployment.
One can also make the argument that the earth is flat. Neither of those two arguments, however, stands up to reality.
It really doesn't take a whole lot of penetrated systems to perpetuate a targeted DDoS. The ratio of size between common small pipes (1.5mbit/sec) and large pipes (1gbit/sec) isn't that great; and when you're talking about something like specifically attacking the root servers (which this attack didn't do), one can make use of traffic amplification inherent in the attacked protocol (e.g. asking for information that is larger than the DNS request sent). If you're talking about a large market (How many well-connected RDBMS's are there out on the internet?) it doesn't take a very high market share for a vulnerability to be a dangerous one.
Twin engine piston airplanes have a higher accident rate due to engine failure than single engine airplanes. While there are a lot of complicated reasons for this phenomenon, one of them is that twins are twice as likely to suffer an engine failure, and twins are not always able to climb with one engine out.
I'd rather have 5-6 well-supported software packages out there than hundreds of fairly-supported ones-- both from an interoperability standpoint and a resiliency point of view.
All packet streams with a constant frequency are malicious?
What crack are you smoking? Streaming media is malicious, then?. Traffic that is latency-constrained on the window (e.g. bandwidth * delay > window) is also periodic-- I assume it's malicious as well? Not to mention my little ping monitor watching my colo box to be sure it's up.
I don't think it's fair to say this is due to a software monoculture. MS SQL Server only has a 18-19% RDBMS marketshare (38% or so of the Windows database market).
The argument could be made that with more different types of software, there is a greater risk of DDoS that could cripple the net (although cleanup will be easier in that case, too).
720 horizontal pixels * 480 vertical pixels * 32 bits per pixel * 29.97 frames per second = 331MBytes/second.
32bit, 33MHz PCI is 105MBytes/second. Most PCs have this, which is not capable of even supporting one uncompressed card. Of course, for this reason, TV cards do compression.
DVD quality video is 9 Mbit/sec. Assuming the encoder on the card is not as good, you can get plenty good video at 10-12mbit/sec. And you can fit pretty much as many of those onto a PCI bus as you have slots, I'd think, if the software is decently efficient and supports it. Likewise, this is pretty slow compared to typical disk I/O rates, assuming you do some buffering to allow decent-sized writes to occur and aren't seeking all the time.
Slashdot Mirror
Is your product in the 98th percentile of the software industry in profitability/unit counts sold?
How big is your development team compared to the 4 band members + a producer? It's probably larger than 5. (Sure, there's manufacturing, and other infrastructure at both places, but customer support is not as big a cost for record labels as your software gig, I'd think).
Still, if you take over the user's session after the user has authenticated, OR pop up a trojan dialog asking the user to type in his PIN, the fact that a nice fancy hardware token has been used doesn't matter anymore.
Token authentication is used to try and clean up all kinds of security problems that it doesn't address well-- problems with the client computer being owned, or using unencrypted transport (which is vulnerable to sequence prediction or sniffing to hijack the session, even if the password itself is not replayable).
You don't really need a $1299 A/D board if you want to start playing with GNU Radio, unless you want to decode a high bandwidth signal like HDTV.
For a couple hundred bucks, you can get an A/D board up to a couple hundred kilohertz, and then hook it up to the IF of any cheap old radio you have sitting around.
Note the OR.
If you met all the conditions, yes that would be safe under the DMCA. This might include doing other things the copyright holder is using to control access-- like region coding. This is unclear from the law.
HOWEVER, please note that the original version of the CSS code was a theft of trade secrets from reverse engineering in violation of a clickthrough license.. and for that reason knowledge that is "tainted" by that reverse engineering has been ruled illegal as well.
And this is redundant why? I see nothing similar in posts above. And this is a time-honored trick that intelligence agencies use to get around limitations in their charters.
Would you feel the same way if the object of the game was to crash a plane into a US city?
To be honest, playing the original Microsoft Flight Simulator at age 6, I thought the purpose -was- to crash a plane into the Sears Tower.
BUILDING CRASH
As to this-- look, there's tons of North Korean and Iraqi movies about the downfall of America in various ways. Every side spins things the way they will, and I like playing games with conflicts/weapons I can relate to. And killing a lot of Russians in Operation Flashpoint doesn't mean I hate Russians.
I agree with this for the most part, except:
At best multiple encryption makes it take longer to brute force the keyspace. It doesn't add security. Period.
When we're talking about block ciphers, using multiple encryption adds rounds. And generally with increased numbers of rounds an algorithm's strength against cryptanalysis increases. Just about every block cipher uses rounds, which could be viewed as a form of "multiple encryption". Obviously care has to be taken to be sure that you're not inadvertently undoing some of the encryption by reusing the key (e.g. encrypting twice with a XOR-based stream cipher would obviously return the original data). In effect, additional encryptions with the same key serve to diffuse the original data even better in many cases.
One of the key metrics of a cipher's strength is how strong it is in comparison to its key size. 256 bit ciphers, if brute force is the best attack, are immune to brute force with any imaginable technology (it is hard to imagine building a machine with matter that can count to 2^256, let alone try and brute force a cipher).
Making the key huge just makes the other potential sources of compromise (compromise by bad key generation or distribution) easier. If you want a huge keystream, you might as well use a large one time pad.
I don't really see what the point is of this encryption scheme.
One tidbit. Birthday paradox-- if there's 23 peopple in a room, chances are two share a birthday.
I think you mean for there to be a high probability of a collision, there needs to be more than 256 hosts on the network (this is very close to p=.5)
Think about it, there are 256*255 pairings of hosts then- or 65280.
Unless you're talking about the brand-spanking-new (and really cool, but stil unshipped) technology from Vivato, this isn't the way things work. There's only so much spectrum, and you can only fit so much data onto that spectrum. Adjacent access points need to be on different channels in most circumstances for this reason. There's only so much spectrum and you can only fit so much data onto it.
Vivato uses "packetsteering" (phased array technology) to receive different signals from different directions simultaneously. But existing 802.11b doesn't allocate a seperate 11mbps to each user. In fact, if you have just 1 802.11b user and 1 802.11g user, the 802.11g user will only get like 15-16mbps of throughput.
Final note-- you mean mb/s, not MB/s.
The thing is, intercepting an orbit is also very very expensive in propellant (in fact, if it involves a significant change to the orbit's inclination, it's basically impossible). So it's not like you could launch multiple of these "backpacks" from one launch.
Even though satellites are very expensive due to the (over)engineering involved, they have limited design lifetimes. And when a launch is going to cost you $50M, you're better off just replacing whatever you have with something that meets your current needs-- and something that sets the component failure lifetime clock over again.
This doesn't even mention the difficulty of trying to hook up to the satellite's power bus, etc.
When we're talking about geosynchronous satellites, or near-geosynchronous satellites, the orbital period is going to be remarkably close to 24 hours.
The answer: Maybe, but probably not. Usually the satellites have control computers and bringing them back up after they've been powered off can be difficult. It also depends on how the satellite's power system is arranged.
It's also important to note that the closer it gets to midnight, the closer to the horizon (and thus, the harder to listen to) a satellite has to be to be in sunlight-- and there's not likely to be as many geosynchronous satellites over unpopulated latitudes.
The fact that stabilization coils and reaction wheels go offline when the satellite's battery discharges means the satellite might very well begin tumbling and thus not get so much useful power when it returns to daylight-- and also not know its exact attitude to begin to recover.
Finally, the failure mode of the battery is important. If the battery fails "closed", or shorted, it might connect the negative sides of the power bus to the positive and not allow the panel to generate any useful power.
Basically, when power systems start to fail on a satellite, even when it's a temporary problem (e.g. an accidental discharge of the batteries because of an orientation problem), it can be pretty hard to recover from-- if it's possible at all.
Things in geosynchronous orbit effectively stay up there forever. This isn't a small low-earth orbit satelite 150 miles up- this is 22000 miles up.
No orbits are "permenant" in the real world-- but some are close enough. The earth isn't gonna fall into the sun tomorrow.
Honestly, I really hope so.
I don't think we should completely abandon manned space missions, but the ISS is going to cost $100B over its lifetime-- figuring that the cost of a 4 year university education is $100k, we could create a million more scientists on earth-- and think how much that could do to solve the autonomous control and robotics problems that currently limit unmanned missions.
Right now, basically 2 of the 3 members of the ISS crew are dedicated to doing things to keep the ISS running. Surely with $100B we could get as much real space science done as that one individual who's concentrating on science on the ISS over these next 10 years can, right?
Let's learn what we can now cheaply, and regroup in 10-25 years and go to Mars, or form a colony on the moon, or do something else really radical that broadens the future for mankind.
Most older communications satelites have what are called "transponders"-- they take everything that comes in on a certain band of frequencies and plays it out on another set.
Because usually relatively high-bandwidth analog signals with high quality requirements are sent through these transponders, and the satelites have a relatively small amount of output power, high gain antennas (big satelite dishes) are required to recover the signal, which must be very precisely pointed.
By using digital signals and audio compression technology, suddenly the signals can be narrower bandwidth. Noise is proportional to bandwidth, and since the signal is narrower, signal/noise ratio is improved. This means high-gain antennas may no longer be strictly necessary, and thus the position of the satelite becomes less critical as the orbit decays.
Note that this does not lock us in to a proprietary standard-- if the spectrum is allocated for this purpose, smarter digital transmitters can be put into space for the same purpose later.
Still important is attitude control-- the satelite's antenna must be pointed down and the solar panels pointed in a useful direction. But this often uses gyroscopes, reaction wheels, and magnetic systems-- which do not use propellant.
Finally, battery life is a question. No communications satelite is constantly receiving solar power, so if the satelite is operated while not in view of the sun, batteries on the satelite discharge. Satelites can withstand a limited number of charge cycles before they fail, and this is likely to form the true upper bound on satelite lifetime.
In all, it's a good idea. I imagine we'll see lots of clever ways to emerge on how to use legacy hardware we've put in space, as launch costs remain so expensive.
I wasn't aware that Intel's Preboot eXecution Environment(original pdf) was closed...
Lots of people are posting on how this is potentially a bad idea. Sure, it's not likely to be as mature as other compiler environments. There's all kinds of small shops where this could simplify build infrastructure, though. Maintaining different build servers for all the platform variation a company chooses to support can be costly to build, especially with the infrastructure to do revision control and fire off simultaneous builds and package things together. If a company just needs to produce command line tools or simple DLL's to accelerate code in a scripting language, this might be a good choice.
Probably the largest win is allowing developers to unit test application logic on their local Windows desktop, if they prefer that environment, before doing final unit test, integration test, and deployment on top of *nix/Linux.
This really depends.
It probably doesn't because there's probably good known plaintext that's only encrypted by the 40 bit encryption, like the boot blocks. In this case, your statement is true.
But if it was all encrypted in AES, and then in DES with a completely different key-- I don't see how you can say that the DES doesn't provide proportionally more strength by the relative keylengths. Just like TEMK doesn't provide 2* 2^56, but more like 2^112 of brute force complexity.
we have been writing ARM code for palmos way before the pubic devices were available
Just when did the pubic devices become available?
I think it's important to note that in the real world, besides having great diversity in species, we still have diseases. I agree that having a small amount of immunity can slow down an emerging worm. But RDBMS's are not exactly plentiful on the internet compared to many other software categories, and yet we see a successful worm. Apparently the density of vulnerable hosts can be fairly low to have a nearly instantaneous effect-- computer worms spread a lot faster than viruses in the real world because the diameter of the network (the shortest "direct" path between nodes) is effectively 1.
.00000588 vulnerable hosts per valid-looking IP address. That's a really low number to be the base for your exponential growth curve (even Webstar, the #10 webserver with a 0.51% share, has 4x this density. You'd need more than 800 implementations of webservers with equal share to get below the density of MS SQL Server on the net). Basically it appears every vulnerable host on the internet was compromised within a few minutes.
The highest estimate I've seen of compromised hosts (which should closely match the number of vulnerable hosts in this case, because every exposed IP on the internet was receiving these packets) is about 22000. That equates to a density of
At only 2500PPS, that's 1 infection per infected host per minute in the early phases of the worm; e.g. the number of infected hosts should be close to 2^t, where t is the time in minutes, at that packet rate. Needless to say, this gets big fast. Halving the vulnerability rate would make this 2^(t/2), which would still make it spread pretty fast compared to the cleanup and response rate. And that assumes that the worm uses a purely random spread method like this one does. Even in a truely heterogenous internet, it's likely that similar hosts will clump together and be able to send each other packets faster, so there are better spread methods available.
It's really difficult to configure routers, especially core routers, to block unusual traffic patterns. The lack of aggressive filtering, IMO, is why we have these problems.
Standards are imperfect. Software implementations of the standards, too, are imperfect, for a variety of reasons (deliberate and accidental). Even working to develop software within one company, with specs that are designed to guarantee interoperability can result in surprises. Do we really need a hundred general-purpose RDBMS's in the world? And the resultant specialization in knowledge that will result from different practices in tuning, etc? And the difficulty in keeping all those different kinds of servers patched in real-world operational practice? I don't think so.
I don't see how avoiding the monoculture makes things safer. Running the numbers, having more kinds of web servers out there makes the internet more dangerous for denial of service-- both as a byproduct of a worm or deliberately. All having more kinds out there does is simplifies the scope of the cleanup operation when the catastrophic does happen-- improves the worst case at the cost of having it occur more often.
It's not really a rectangular prism.. it has this curved extrusion out of it to carry it by.
As to MS SQL creating a larger share of vulnerable installations-- yes, I had thought of that. Products aimed at low-end installations certainly need more hardening. Of course, you could also argue that the average MS SQL server installation has a lot less bandwidth to throw around than the average Oracle deployment.
One can also make the argument that the earth is flat. Neither of those two arguments, however, stands up to reality.
It really doesn't take a whole lot of penetrated systems to perpetuate a targeted DDoS. The ratio of size between common small pipes (1.5mbit/sec) and large pipes (1gbit/sec) isn't that great; and when you're talking about something like specifically attacking the root servers (which this attack didn't do), one can make use of traffic amplification inherent in the attacked protocol (e.g. asking for information that is larger than the DNS request sent). If you're talking about a large market (How many well-connected RDBMS's are there out on the internet?) it doesn't take a very high market share for a vulnerability to be a dangerous one.
Twin engine piston airplanes have a higher accident rate due to engine failure than single engine airplanes. While there are a lot of complicated reasons for this phenomenon, one of them is that twins are twice as likely to suffer an engine failure, and twins are not always able to climb with one engine out.
I'd rather have 5-6 well-supported software packages out there than hundreds of fairly-supported ones-- both from an interoperability standpoint and a resiliency point of view.
All packet streams with a constant frequency are malicious?
What crack are you smoking? Streaming media is malicious, then?. Traffic that is latency-constrained on the window (e.g. bandwidth * delay > window) is also periodic-- I assume it's malicious as well? Not to mention my little ping monitor watching my colo box to be sure it's up.
The argument could be made that with more different types of software, there is a greater risk of DDoS that could cripple the net (although cleanup will be easier in that case, too).
720 horizontal pixels * 480 vertical pixels * 32 bits per pixel * 29.97 frames per second = 331MBytes/second.
32bit, 33MHz PCI is 105MBytes/second. Most PCs have this, which is not capable of even supporting one uncompressed card. Of course, for this reason, TV cards do compression.
DVD quality video is 9 Mbit/sec. Assuming the encoder on the card is not as good, you can get plenty good video at 10-12mbit/sec. And you can fit pretty much as many of those onto a PCI bus as you have slots, I'd think, if the software is decently efficient and supports it. Likewise, this is pretty slow compared to typical disk I/O rates, assuming you do some buffering to allow decent-sized writes to occur and aren't seeking all the time.