the feds could have provided the 5 million feet of oil boom for the LA coastline back when the Gov requested it on May 2nd.
LA and the other gulf states accepted environmental risk in return for economic benefit. (Others, like CA, did not and hence don't welcome offshore drilling.) When they accepted the risk, where did they file their contingency plans and supplies? The call lists? Delineation of responsibilities? Why is it the federal government's responsibility to make up for their lack of due diligence and general lack of clue? After all, isn't Jindal the same guy who said the federal government shouldn't monitor volcanoes? What's he doing now with his hat out?
It seems to matter not to law enforcement in general. The mere pretense that something is being done is good enough.
More that law enforcement throws everything imaginable at anyone suspicious to see what sticks, no matter how vague and remote an accusation may appear. The DA can always drop it later, and it can be used as a negotiating tool. Hence if you stumble you resisted arrest, if two officers give you conflicting instructions you refused to follow their direction, etc. They also do their best to make people incriminate themselves. When they look at you they don't ask themselves if you're guilty of something but whether they can ultimately get you convicted for it. This is because getting people convicted is the ultimate goal, it's what their performance is in the end rated by, not determining some sort of objective guilt or dispelling mathematical doubt. If someone gets convicted they're guilty by definition and the officer gets a gold star in their performance record.
Even if the physical presence of the phone doesn't fuck with the results, the power very well could. If they want to test this properly it would require multiple hives, and transmitters that bathed the area in the kind of energy you'd see from the actual network.
The test clearly was to determine whether cell phones - for whatever reason - can affect bees. If this experiment had shown no difference whatsoever it would have been fairly conclusive that cell phones don't affect bees. With some follow up studies this would have been case closed. However, instead they found some particular aspect of cell phones - which is yet to be determined - affects bees. Maybe it's the plastic casing, or it smells funny, or emits high pitched sounds, or whatever - but something about it clearly affects bees. Now further experiments and studies have something to follow up on. This is how science works.
The main effect of ionizing radiation that's of concern here is DNA damage; DNA damage often has no immediate effect at all, either because it is in genes that are not currently used, or because the cell compensates. Only if there is enough exposure so that all the alternative pathways and repair mechanisms are overwhelmed do you actually see an effect. Those effects often occur long after the initial exposure. For ionizing radiation, there is delay and there is no magic in it either.
Absolutely. And it's all additive - genetic damage simply adds up, from all sources be they chemical, ionizing, non-ionizing, or physical (e.g. asbestos). Also, an exposure to e.g. X rad (ionizing) for N days is the same as X/K rad for N*K days. It causes the same damage. I forget off hand, but figures for e.g. lung cancer seems to linger around 30k mutations before a cell goes bonkers. Most cells die, but the exposure is across a LOT of cells and the distribution is a bell curve. Different types of exposure tend to affect different tissues, but for a given cell it's cumulative. Typically carcinogens also have no lower threshold where they cause no damage - meaning there is no 'safe' exposure.
One thing often ignored is that cell phones don't transmit continuously, instead they burst a few watts for milliseconds. So it's more like a microwave spark. This might perhaps screw up bees, especially those close to the antenna. If there also is a lower threshold where genetic damage occurs from microwaves the same burstiness could conceivably overcome that.
How do you know that some of the differences (lacking certain block sizes, for example) are precisely to avoid certain patents?
Technically, the H.264 format has zero patents. The patents are all related to working on it and ways to generate it. That, however, is a non-trivial problem and reinventing the wheel is so costly and technically difficult even without infringing, that it's not really an option. If you start by the time the standard is adopted you won't have a product until it's obsolete. So the practical method is to simply license what you need and build on existing work. The $100k or whatever the licensing will cost doesn't buy a whole lot of engineering effort. Startups burn through $10-$20M in this field, for a team of 10-15 to work for a couple of years, usually on a limited production or consumption side component to fit in the chain. TO the rest, cost of licensing is really not a significant problem to anyone out there -- other than open source projects, obviously.
You would think it would be pretty easily for Amazon to find and shut down the attackers... why haven't they done so already?
Perhaps because the UDP source addresses are spoofed, and the goal of the attack is to trick AWS into shutting down legitimate paying customers' businesses?
"Within five years, I predict it will be the most popular form of PC sold in America. It will come with a full 640 KB of RAM which should be enough for anybody. We will continue to out-innovate Apple. Then we're going to fscking kill Google."
I worked on Unix kernels and networking stacks in the mid 90s when Gates insisted IP serves no purpose and the Internet is a fad. Back when Windows didn't even install TCP/IP by default, and the bundled one you could add yourself was horribly broken - I know, because I hacked our TCP implementation to get around many of its deficiencies. Overall, his track record when it comes to predicting trends is worthless, and most of his wealth isn't based either on vision or any technical leadership; it's solely based on business skills.
The price reflects an extreme niche market. First, it's a therapeutic device, which similar to a drug has to be proven it works better than a placebo before you can sell it as such. Which means you need to fund a study to demonstrate its efficacy. Second, it takes people with certain experience to build devices that integrate well with diagnostic procedures. Third, the medical and drug market isn't very open to newcomers. Fourth, and most important, the prices are all bogus. If you walk in off the street to a hospital, uninsured, and ask for a cholesterol test they will quote you about $750. This is the price the provider always begins their negotiations at; an insurance company negotiates a discount based on that (or if it's medicare they simply state what they're willing to pay, take it or leave it). An insurance company might pay $125 but you will pay $750 because the hospital isn't going to negotiate their prices with you. Same with a $4000 hearing aid. An insurance company might pay $800 for it (which is a reasonable price for such a niche product) and you have some deductible, say $250. The purpose of the ridiculous pricing scheme is to make you feel you're getting a $4000 device for $250, while the insurance company ends up paying $550. If you were told you got an $800 device for $250 you might wonder why you're paying for insurance. And this is the same reason you can't walk in and buy the device for $800 yourself - because helping the insurance companies sell insurance helps the hospital stay open.
If inputN is constrained to be {0..3} then I now have a test space of at least 2^100 in order to prove addend uniqueness.
Proof of correctness of implementation is virtually always by induction (see http://en.wikipedia.org/wiki/Mathematical_induction), and almost never black-box. BB testing is more useful for regression testing external interfaces. For something as simple as adding up a series, or similar (e.g. FIR filter) with no discontinuities, induction testing technically requires only one test point. In practice however you can just as well test on a few hundred sequences to verify that you haven't unintentionally created discontinuities. If you DO have discontinuities (such as input rejection) you'll obviously need additional tests the verify they work as intended. Sample input rejection is often also done in BB testing, mainly to detect regressions and to verify behavior (e.g. external signaling to indicate a fault).
One can only imagine how many data centers out there run some app that by today's standards is utterly trivial, on some leased z Series hardware. It might have started out on a row of 4341 or such and gradually gotten consolidated into a single low-end system. Today dozens if not hundreds of these apps could be hosted on a single system. They can provisioned as needed from a pool of servers, remotely by the admins who actually manage the apps (aka cloud).
A lot of boards these days are populated with FTDI FT232 chips or comparable. http://www.ftdichip.com/Products/FT232BM.htm Usually using a separate 'console' USB port separate from the host/device ports provided in addition. Pretty much every desktop system comes with FT232 drivers, so all that's needed is a cable, or possibly an INF file or similar if they use a nonstandard MID/PID. Eventually we'll probably see these on-chip on SoC devices that already have USB support. But RS232E is quite practical and easy to troubleshoot, and I don't know any embedded engineer or board designer who doesn't know how to wire that up. I agree TFTP and flashing from a USB stick is nice, but a console is great to figure out why that might be failing, to see kernel panics, etc. Of course, a JTAG adapter and debugger that can talk to it is a huge time saver when it comes to actually fixing boot loader, flashing, or kernel bugs...
Just last year they found a new oilfield off of Brazil bigger than anything found yet. Last year. After everyone said no new large fields would ever be found.
The Tupi field is estimated to hold 8b barrels of oil. Given our current global consumption that's a three month extension. It's the biggest field discovered in 30 years - which is pretty telling. Find ten of these and we've got a few extra years. Find only another one or two and it makes no difference. Meanwhile, when the global business cycle points up again our oil consumption is going to follow likewise - again. Prices will rocket, and economic growth will be choked. Oil is really a limited resource and the way we've built our entire economy around it is going to limit our capacity for global growth.
i like MIPS... in college, we had one semester of hands on lab work learning everything about a specific MIPS implementation, then another semester writing a compiler capable of compiling itself for the architecture.
once you can grasp the simplicity and understand exactly whats going on in the chip, features like HyperThreading seem almost stupid because of how much complexity and exceptions they add to the system.
Of course modern MIPS processors are threaded as well...
Just out of curiosity, while I've done some programming professionally, I haven't touched C or Assembly in well over 15 years, since I needed immediate results and haven't had bosses that allowed anything less, how much work is it to convert something from X86 to ARM? Assuming you didn't write it with the intention of every needing to do so, vs having planned for such a possibility.
Depends on the ARM CPU. ARM7/ARM9 are alignment sensitive. ARM Cortex has a bus/cache interface that allows arbitrary alignment. Porting to the former may be difficult depending on the software, or may simply be tedious, the latter is usually as easy as a recompile if the platform and toolchain is similar (e.g. Linux+gcc).
I can't fit my leg in domestic coach either, and it sucks to fly when there's no business class seating available. But I don't think something that affects 15% of the population is a normal variance that can be addressed by market forces. 15% of the market is substantial money, assuming the figure is correct. Disabilities are by definition so rare that the market incentive to address them is generally negative. This is the same reason obesity shouldn't be considered a disability - as this story shows the market can handle it just fine. I do agree SW screwed up in that when they got him an alternate flight on standby they didn't make sure they got him the two seats they had agreed to provide him when he paid. This probably just reflects it being a special case in their booking system; but they did apologize and offer him a voucher for a comparable flight so I fail to see the big deal. Except of course in this case the person was wealthy so doesn't care about money, and is famous, so is used to people pandering to their every wish. Whatever.
This also goes for the annoying people who insist on getting out of their seats by pulling back on the seat in front of them - instead of pushing up off their own seat. If any of you read this: 1. lean forward while still seated. 2. turn your torso toward the aisle you want to get to. 3. put your hand on the back of your own seat. 4. while leaning against your own seat, stand up, turning your pelvis toward the aisle a little as you do so. No need whatsoever to monkey climb on the seat in front.
The next big factor hinted at elsewhere is the domain knowledge. I can estimate better if I'm modifying my own code to do something similar. I estimate badly when it's a section of code I'm unfamiliar with or a large framework. This stuff, like the bug fixes, involves a lot of investigation, research, learning, etc. You can't easily estimate that stuff.
Then you need to start with something more easily estimated: a ramp up task. This can usually be estimated. It usually helps to make up a few goals, like 1) being able to create a debug build from scratch on your dev system, 2) understanding of the problem solved by the software, 3) understanding of external interfaces (black box behavior) and a broad understanding of the design, 4) scoping out which parts of the implementation are relevant to your changes, and 5) a broad idea of what changes you will have to make.
In the iteration after this you can then usually scope out the actual implementation task.
So at the very least, I'd expect flash videos to play smoothly and consistently without taxing my processors at 80 to 90 percent!
Flash is primarily a programming language, compiled to SWF. (But it has some other features as well, like a timeline and a notion of time-based actions.) Used well it produces nice, fast, very compact code - in fact, people use it to build software to run on embedded devices that would make your Mac look like a supercomputer. There are two performance culprits: 1) the VP6 codec still popularly in use; this has no hardware support (unlike H.264) and playback requires your main processors to decode. 2) poor code - the problem in this case is that people who aren't programmers use Flash to cobble together ads and other animated objects, usually with little or no QA before it goes out the door. You can't justify a comprehensive development process for something that is done by a non-programmer in an afternoon, has to be out in a few days, and shouldn't cost more than any other design work. Needless to say, this non-process produces garbage software, and when your browser loads a whole bunch of these it's no surprise it doesn't function well. ClickToFlash is your friend in the short term, but in the long term this needs to be addressed by ad providers (campaign managers).
What you are suggesting is akin to 'Bubble sorts are a great algorithm if you do them an a fast CPU'.
This is an interesting analogy, because the fastest possible way to sort 3 elements is bubble sort. It's a good example why reductionism often yields poor algorithms. It's also relevant to scalability of implementation versus scalability of architecture. The former is more about software design, running MT hot, clustering, db schemas, etc, while the latter is more about partitioning the problem and processes. Many business processes are much too big for any one person to comprehend in depth, and it's important to partition it so everyone can understand the overarching purpose and structure, but only have to be expert on one part. These can then further partitioned if big enough. Scalability of architecture in the really comes down to modularity and an ability to identify and eliminate bottlenecks - an implementation may have bottlenecks, but with a good architecture individual parts can be reimplemented or provisioned as needed to eliminate them. It's also common to architect for the biggest realistic scope but only implement what's actually needed; this guarantees that things like policy management goes in place early even if it's mostly a skeleton. Since policy needs to be managed at the highest abstract level it needs to be part of the architecture, and is one of those things that's virtually impossible to bolt on after the fact. Anyway, somehow I wanted to convey that good architecture can't be reduced to good implementation and while good implementation is important it's not actually essential. What's essential is that good implementation is possible. (This is also why if you can't design and implement software at high level of proficiency you can't architect, because you will invariably paint yourself into a corner.)
Slashdot Mirror
And those sad pelican shots weren't covered in oil, but merely whale poop.
It's the pelicans who chose to take an unauthorized swim in BP's crude.
the feds could have provided the 5 million feet of oil boom for the LA coastline back when the Gov requested it on May 2nd.
LA and the other gulf states accepted environmental risk in return for economic benefit. (Others, like CA, did not and hence don't welcome offshore drilling.) When they accepted the risk, where did they file their contingency plans and supplies? The call lists? Delineation of responsibilities? Why is it the federal government's responsibility to make up for their lack of due diligence and general lack of clue? After all, isn't Jindal the same guy who said the federal government shouldn't monitor volcanoes? What's he doing now with his hat out?
It seems to matter not to law enforcement in general. The mere pretense that something is being done is good enough.
More that law enforcement throws everything imaginable at anyone suspicious to see what sticks, no matter how vague and remote an accusation may appear. The DA can always drop it later, and it can be used as a negotiating tool. Hence if you stumble you resisted arrest, if two officers give you conflicting instructions you refused to follow their direction, etc. They also do their best to make people incriminate themselves. When they look at you they don't ask themselves if you're guilty of something but whether they can ultimately get you convicted for it. This is because getting people convicted is the ultimate goal, it's what their performance is in the end rated by, not determining some sort of objective guilt or dispelling mathematical doubt. If someone gets convicted they're guilty by definition and the officer gets a gold star in their performance record.
By the way, I agree that a sample of four hives is silly and negates the results. But it's worth following up IMO with a larger sample size.
Even if the physical presence of the phone doesn't fuck with the results, the power very well could. If they want to test this properly it would require multiple hives, and transmitters that bathed the area in the kind of energy you'd see from the actual network.
The test clearly was to determine whether cell phones - for whatever reason - can affect bees. If this experiment had shown no difference whatsoever it would have been fairly conclusive that cell phones don't affect bees. With some follow up studies this would have been case closed. However, instead they found some particular aspect of cell phones - which is yet to be determined - affects bees. Maybe it's the plastic casing, or it smells funny, or emits high pitched sounds, or whatever - but something about it clearly affects bees. Now further experiments and studies have something to follow up on. This is how science works.
The main effect of ionizing radiation that's of concern here is DNA damage; DNA damage often has no immediate effect at all, either because it is in genes that are not currently used, or because the cell compensates. Only if there is enough exposure so that all the alternative pathways and repair mechanisms are overwhelmed do you actually see an effect. Those effects often occur long after the initial exposure. For ionizing radiation, there is delay and there is no magic in it either.
Absolutely. And it's all additive - genetic damage simply adds up, from all sources be they chemical, ionizing, non-ionizing, or physical (e.g. asbestos). Also, an exposure to e.g. X rad (ionizing) for N days is the same as X/K rad for N*K days. It causes the same damage. I forget off hand, but figures for e.g. lung cancer seems to linger around 30k mutations before a cell goes bonkers. Most cells die, but the exposure is across a LOT of cells and the distribution is a bell curve. Different types of exposure tend to affect different tissues, but for a given cell it's cumulative. Typically carcinogens also have no lower threshold where they cause no damage - meaning there is no 'safe' exposure.
One thing often ignored is that cell phones don't transmit continuously, instead they burst a few watts for milliseconds. So it's more like a microwave spark. This might perhaps screw up bees, especially those close to the antenna. If there also is a lower threshold where genetic damage occurs from microwaves the same burstiness could conceivably overcome that.
How do you know that some of the differences (lacking certain block sizes, for example) are precisely to avoid certain patents?
Technically, the H.264 format has zero patents. The patents are all related to working on it and ways to generate it. That, however, is a non-trivial problem and reinventing the wheel is so costly and technically difficult even without infringing, that it's not really an option. If you start by the time the standard is adopted you won't have a product until it's obsolete. So the practical method is to simply license what you need and build on existing work. The $100k or whatever the licensing will cost doesn't buy a whole lot of engineering effort. Startups burn through $10-$20M in this field, for a team of 10-15 to work for a couple of years, usually on a limited production or consumption side component to fit in the chain. TO the rest, cost of licensing is really not a significant problem to anyone out there -- other than open source projects, obviously.
You would think it would be pretty easily for Amazon to find and shut down the attackers... why haven't they done so already?
Perhaps because the UDP source addresses are spoofed, and the goal of the attack is to trick AWS into shutting down legitimate paying customers' businesses?
"Within five years, I predict it will be the most popular form of PC sold in America. It will come with a full 640 KB of RAM which should be enough for anybody. We will continue to out-innovate Apple. Then we're going to fscking kill Google."
I worked on Unix kernels and networking stacks in the mid 90s when Gates insisted IP serves no purpose and the Internet is a fad. Back when Windows didn't even install TCP/IP by default, and the bundled one you could add yourself was horribly broken - I know, because I hacked our TCP implementation to get around many of its deficiencies. Overall, his track record when it comes to predicting trends is worthless, and most of his wealth isn't based either on vision or any technical leadership; it's solely based on business skills.
Jesse Schell, known mostly to his friends and colleagues as a game designer, spoke at "DICE"
Wow, known mostly to his friends and colleagues as a game designer! Such credentials!
The price reflects an extreme niche market. First, it's a therapeutic device, which similar to a drug has to be proven it works better than a placebo before you can sell it as such. Which means you need to fund a study to demonstrate its efficacy. Second, it takes people with certain experience to build devices that integrate well with diagnostic procedures. Third, the medical and drug market isn't very open to newcomers. Fourth, and most important, the prices are all bogus. If you walk in off the street to a hospital, uninsured, and ask for a cholesterol test they will quote you about $750. This is the price the provider always begins their negotiations at; an insurance company negotiates a discount based on that (or if it's medicare they simply state what they're willing to pay, take it or leave it). An insurance company might pay $125 but you will pay $750 because the hospital isn't going to negotiate their prices with you. Same with a $4000 hearing aid. An insurance company might pay $800 for it (which is a reasonable price for such a niche product) and you have some deductible, say $250. The purpose of the ridiculous pricing scheme is to make you feel you're getting a $4000 device for $250, while the insurance company ends up paying $550. If you were told you got an $800 device for $250 you might wonder why you're paying for insurance. And this is the same reason you can't walk in and buy the device for $800 yourself - because helping the insurance companies sell insurance helps the hospital stay open.
sum = input0 + input1 + ... + input400;
If inputN is constrained to be {0..3} then I now have a test space of at least 2^100 in order to prove addend uniqueness.
Proof of correctness of implementation is virtually always by induction (see http://en.wikipedia.org/wiki/Mathematical_induction), and almost never black-box. BB testing is more useful for regression testing external interfaces. For something as simple as adding up a series, or similar (e.g. FIR filter) with no discontinuities, induction testing technically requires only one test point. In practice however you can just as well test on a few hundred sequences to verify that you haven't unintentionally created discontinuities. If you DO have discontinuities (such as input rejection) you'll obviously need additional tests the verify they work as intended. Sample input rejection is often also done in BB testing, mainly to detect regressions and to verify behavior (e.g. external signaling to indicate a fault).
Which in turn is the same people who in 5-10 years will complain that they can't get a job because they're "too old".
One can only imagine how many data centers out there run some app that by today's standards is utterly trivial, on some leased z Series hardware. It might have started out on a row of 4341 or such and gradually gotten consolidated into a single low-end system. Today dozens if not hundreds of these apps could be hosted on a single system. They can provisioned as needed from a pool of servers, remotely by the admins who actually manage the apps (aka cloud).
A lot of boards these days are populated with FTDI FT232 chips or comparable. http://www.ftdichip.com/Products/FT232BM.htm Usually using a separate 'console' USB port separate from the host/device ports provided in addition. Pretty much every desktop system comes with FT232 drivers, so all that's needed is a cable, or possibly an INF file or similar if they use a nonstandard MID/PID. Eventually we'll probably see these on-chip on SoC devices that already have USB support. But RS232E is quite practical and easy to troubleshoot, and I don't know any embedded engineer or board designer who doesn't know how to wire that up. I agree TFTP and flashing from a USB stick is nice, but a console is great to figure out why that might be failing, to see kernel panics, etc. Of course, a JTAG adapter and debugger that can talk to it is a huge time saver when it comes to actually fixing boot loader, flashing, or kernel bugs...
Just last year they found a new oilfield off of Brazil bigger than anything found yet. Last year. After everyone said no new large fields would ever be found.
The Tupi field is estimated to hold 8b barrels of oil. Given our current global consumption that's a three month extension. It's the biggest field discovered in 30 years - which is pretty telling. Find ten of these and we've got a few extra years. Find only another one or two and it makes no difference. Meanwhile, when the global business cycle points up again our oil consumption is going to follow likewise - again. Prices will rocket, and economic growth will be choked. Oil is really a limited resource and the way we've built our entire economy around it is going to limit our capacity for global growth.
i like MIPS... in college, we had one semester of hands on lab work learning everything about a specific MIPS implementation, then another semester writing a compiler capable of compiling itself for the architecture.
once you can grasp the simplicity and understand exactly whats going on in the chip, features like HyperThreading seem almost stupid because of how much complexity and exceptions they add to the system.
Of course modern MIPS processors are threaded as well...
Just out of curiosity, while I've done some programming professionally, I haven't touched C or Assembly in well over 15 years, since I needed immediate results and haven't had bosses that allowed anything less, how much work is it to convert something from X86 to ARM? Assuming you didn't write it with the intention of every needing to do so, vs having planned for such a possibility.
Depends on the ARM CPU. ARM7/ARM9 are alignment sensitive. ARM Cortex has a bus/cache interface that allows arbitrary alignment. Porting to the former may be difficult depending on the software, or may simply be tedious, the latter is usually as easy as a recompile if the platform and toolchain is similar (e.g. Linux+gcc).
Oops! I obviously meant "But I do think..."
I can't fit my leg in domestic coach either, and it sucks to fly when there's no business class seating available. But I don't think something that affects 15% of the population is a normal variance that can be addressed by market forces. 15% of the market is substantial money, assuming the figure is correct. Disabilities are by definition so rare that the market incentive to address them is generally negative. This is the same reason obesity shouldn't be considered a disability - as this story shows the market can handle it just fine. I do agree SW screwed up in that when they got him an alternate flight on standby they didn't make sure they got him the two seats they had agreed to provide him when he paid. This probably just reflects it being a special case in their booking system; but they did apologize and offer him a voucher for a comparable flight so I fail to see the big deal. Except of course in this case the person was wealthy so doesn't care about money, and is famous, so is used to people pandering to their every wish. Whatever.
This also goes for the annoying people who insist on getting out of their seats by pulling back on the seat in front of them - instead of pushing up off their own seat. If any of you read this: 1. lean forward while still seated. 2. turn your torso toward the aisle you want to get to. 3. put your hand on the back of your own seat. 4. while leaning against your own seat, stand up, turning your pelvis toward the aisle a little as you do so. No need whatsoever to monkey climb on the seat in front.
I would rank it second to the smell of burnt mosquito, especially when it's the ONE bugger that's keeping me awake at 3am...
The next big factor hinted at elsewhere is the domain knowledge. I can estimate better if I'm modifying my own code to do something similar. I estimate badly when it's a section of code I'm unfamiliar with or a large framework. This stuff, like the bug fixes, involves a lot of investigation, research, learning, etc. You can't easily estimate that stuff.
Then you need to start with something more easily estimated: a ramp up task. This can usually be estimated. It usually helps to make up a few goals, like 1) being able to create a debug build from scratch on your dev system, 2) understanding of the problem solved by the software, 3) understanding of external interfaces (black box behavior) and a broad understanding of the design, 4) scoping out which parts of the implementation are relevant to your changes, and 5) a broad idea of what changes you will have to make.
In the iteration after this you can then usually scope out the actual implementation task.
So at the very least, I'd expect flash videos to play smoothly and consistently without taxing my processors at 80 to 90 percent!
Flash is primarily a programming language, compiled to SWF. (But it has some other features as well, like a timeline and a notion of time-based actions.) Used well it produces nice, fast, very compact code - in fact, people use it to build software to run on embedded devices that would make your Mac look like a supercomputer. There are two performance culprits: 1) the VP6 codec still popularly in use; this has no hardware support (unlike H.264) and playback requires your main processors to decode. 2) poor code - the problem in this case is that people who aren't programmers use Flash to cobble together ads and other animated objects, usually with little or no QA before it goes out the door. You can't justify a comprehensive development process for something that is done by a non-programmer in an afternoon, has to be out in a few days, and shouldn't cost more than any other design work. Needless to say, this non-process produces garbage software, and when your browser loads a whole bunch of these it's no surprise it doesn't function well. ClickToFlash is your friend in the short term, but in the long term this needs to be addressed by ad providers (campaign managers).
What you are suggesting is akin to 'Bubble sorts are a great algorithm if you do them an a fast CPU'.
This is an interesting analogy, because the fastest possible way to sort 3 elements is bubble sort. It's a good example why reductionism often yields poor algorithms. It's also relevant to scalability of implementation versus scalability of architecture. The former is more about software design, running MT hot, clustering, db schemas, etc, while the latter is more about partitioning the problem and processes. Many business processes are much too big for any one person to comprehend in depth, and it's important to partition it so everyone can understand the overarching purpose and structure, but only have to be expert on one part. These can then further partitioned if big enough. Scalability of architecture in the really comes down to modularity and an ability to identify and eliminate bottlenecks - an implementation may have bottlenecks, but with a good architecture individual parts can be reimplemented or provisioned as needed to eliminate them. It's also common to architect for the biggest realistic scope but only implement what's actually needed; this guarantees that things like policy management goes in place early even if it's mostly a skeleton. Since policy needs to be managed at the highest abstract level it needs to be part of the architecture, and is one of those things that's virtually impossible to bolt on after the fact. Anyway, somehow I wanted to convey that good architecture can't be reduced to good implementation and while good implementation is important it's not actually essential. What's essential is that good implementation is possible. (This is also why if you can't design and implement software at high level of proficiency you can't architect, because you will invariably paint yourself into a corner.)