Actually, LCDs are refreshed one row at a time and controllers typically do not do buffering beyond two lines for double-buffered DAC inputs. The LCD controller selects the display line, loads one line (or segment) worth of data and drives the DACs' outputs to update the line. This is in many ways very similar to how CCDs and DRAM work.
The reason why LCDs are perfectly acceptable at 60Hz as far as flicker is concerned is that undriven LCD elements take hundreds of miliseconds to fade while CRT phosphors fade in ~10ms. The LCDs' long fade time is also one of the main factors that make fast pixel response times difficult to achieve, this is why manufacturers are experimenting with over-driving DACs and other fancy schemes. As for the virtual 75Hz refresh limit on LCDs, this is in large part a DAC, analog buffering and pixel driving limit. DACs have finite bandwidth - even more so if you want to settle under 1LSB, analog buffers have finite bandwidths and capture/drive delays, pixels are located several centimeters away from the controller chip. All these constraints put very real limits on what can be done. Going beyond these limits would (probably) cause vertical streaking very similar to the horizontal streaking I am used to see on CRTs and analog-input LCDs. The only work-around for this is to divide the display area into quadrants but this strategy has its own issues.
Moore's Law: transistor count doubles every ~18 months.
Up to about three years ago, this translated in a comparable increase in system performance. If you look at system performance now compared to back when Northwood/HT was introduced, the only thing that sort-of-doubled performance since then is dual-core. Add marginal clock increases and infrastructure upgrades and you get a ~3X boost over the last three years rather than 4X. They can keep doubling transistor count by doubling caches and core counts but beyond 2MB caches and quad-core, we're deep in the land of diminishing returns.
Now, it takes nearly triple the transistors to double performance, bringing the performance-doubling cycle closer to 24 months... and even longer in the not-so-distant future.
Apps do not need to support MP for MP to make a difference when the users' work load involves multiple independent CPU-bound tasks.
I like how my desktop P4/HT is generally more responsive... but I prefer my A64 laptop's widescreen LCD and how it is generally faster for single-tasking and light multi-tasking. Only problem with the A64 is that it tends to go near-death whenever I do heavy multitasking while my P4 remains reasonably responsive even under worse conditions. By the time I bring my P4 down to its knees, the A64 looks like it died.
I'm never going back to single-threaded single-core single-CPU systems ever again. My next PC/laptop will probably have something like an A64-X4 in it.
Just pull the wire from the feed, push it through your car's input and start the winder. If the feed is hose-like and the input is tube-like with the hose's nozzle fitting in it, the feeding process can be completely automated to have a very gasoline-like overall feel. The nozzle/hose could also have a vacuum pump to collect expended fuel and top off the water tank.
As others have said though, processing Mg and Al to locally generate H2 and O2 is pretty energy-intensive so it makes little to no sense unless there is excess hydro+wind+solar (clean) potential.
The reason why fluourescent lighting and CCFL look whiter than white is the same reason that adding blue when washing white clothes makes them look whiter. Human sight is least sensitive to blue so boosting the blueishness of whites make them appear whiter.
Cool-white and RGB are fine for general lighting but not where colour accuracy is desirable/necessary.
If your expropriated house's value went up, chances are that every other similar house you would move in afterwards would be similarly more expensive. If I bought a house for $100k, got thrown out 20 years later when the average comparable house is over $200k, I cannot afford another similar house again unless I get compensation for the current value plus the costs of moving. Anything less would be more like a net loss rather than a profit.
There is also the matter of inflation... 1985 dollars (purchase) are worth more than 2005 dollars (sale). At the very least, a forced sale at the purchase price would have to be inflation-indexed to achieve some semblance of break-even. Putting money in a 0.1% interest chequing account is like wasting money since the interests do not cover inflation... your balance might increase but your actual buying power is decreasing.
So, selling a house above the purchase price does not necessarily mean net profit.
If you have an RGB source with narrow-band 650nm red lighting a 600nm reflective red surface, it will be perceived as nearly black instead of the orange-ish tone under day-light.
If a given "white" light fails to reproduce the same perceivable colours, then it is not truly white for lighting purposes beyond locating things. "Narrow-band" white is suitable for convenience and security but not for decoration where it can completely skew the colour scheme.
Catastrophic failures in avionics cost hundreds of milions in financial compensation to survivors or their families, hundreds more in fines if design or maintenance flaws are found to be the cause and possibly hundred more in ground casualities/damage on top of the aircraft loss itself and substantial hikes in insurance fees.
The same thing more or less applies to medical equipment.
When we get down to cars, microcontrollers have been handling multiple systems all over the places for over a decade now. When this trend started, each microcontroller was dedicated to a single specific job. Manufacturers got comfortable with this and decided to do cost-cutting by making microcontrollers handle more than one job. As you said and many have noticed, this trend is starting to have visible side-effects.
Unfortunately for us, electronic and software failures in automotive applications are not considered as serious / mission-critical / life-support equipment. I am not looking forward to drive-by-wire where the manufacturers might decide to stop the car for every minor system failure... more service cash for them and the towing companies, more inconvenience for everyone else - I like the older stuff that keeps on going until you kill the engine instead of being at the mercy of (sometimes malfunctionning) safety switches and interlocks.
I know that some bacteria can live at ~120C... but there is no volcanic mud pits or geysers within hundreds of kilometers from most people's homes so, contamination by these is highly unlikely - assuming they can thrive under typical household conditions.
Just putting the pillows in a dryer would remove the pillows' moisture, shake oout some of the stuff that got in it and force organisms to die or at least shutdown from dehydration. Many people already do this to re-fluff pillows.
Depending on the type of pillow, soaking them can cause the material to permanently compact. For many synthetics, the dryer and oven might melt the material and end with a similar result though.
I'm just happy that I am not inconvenienced by whatever might be in my pillows.
Cotton can survive spending an hour at over 100C, fungi and germs cannot. Cover one oven tray with foil, put the second tray at the next lowest position and put your pillows on it. The foil should prevent the cotton from burning due to direct IR exposure.
Buy the mag, leave it open for a day and when you pick it up again on the following day, the ads' batteries are dead. No need to waste tape!
I would be far more interessed in a large-scale, high-resolution and low-power displays. Even if the response times are over 100ms, this would still be plenty good for reading stuff and display slow/static content.
What is annoying with many of these wonderful technologies is that ETAs are too optimistic and often slip towards infinity. Three or four years ago, 2006 was supposed to be the year of cheap large-scale OLED displays... but unless small miracle happens in the very near future, we might not even have the first-gen mass-produced OLED desktop/laptop units in 2006.
Still does not change the fact that this war started with unsubstantiated evidence of Saddam possessing WMD and sheltering terrorists. Pre-war and post-war inspections turned out absolutely zero WMD and most of the terrorists they got were locals.
In the end, more USA soldiers and bystanders got seriously injured or killed than actual terrorists captured or killed after the initial invasion.
Success? Not in my book.
Bush's war on terror is not going to prevent the next big thing. Terrorism (like nature) will find a way.
Replace the boulders by barrels or pots filled with lamp oil and cloth for wicking. Now, imagine that you are on a boat and got splashed by gallons of burning oil. Which is your priority? Soaking the deck and saving the ship or jump off the ship to save yourself? Try putting out burning oil with water... it does not work since the burning oil floats on top of water and keeps on burning there until it burns out or is snuffed out by other means.
Having the power is one thing, precision and the agility to track the target long enough to achieve ignition is another. Even with perfect aiming and a perfectly still target, it will still take a few seconds to have ignition, much longer if the wood is wet. On an actual sea, ships move allong all degrees of freedom thanks to waves, winds and oars, making accurate target tracking a major challenge. One would also need to have at least some ability to adjust focal length.
As for the people-holding-mirrors theory, try holding a ~1kg ~1m^2 sheet of perf-board with a laser pointer mounted in the center aimed inside a 10x10cm target that is 10m away... chances are that your aim will wander quite a bit even if you do not have anyone else's beam to get confused with.
"Dear invaders, please hold still while we re-aim our Death Ray's mirror array..."
There is no historic proof that "Archimedes' Death Ray" ever existed. All we know for sure is that the idea was documented and pinned on him post-mortem, unlike everything else we know for sure about him.
We have 150W CO2 lasers now, let's forget about hypothetical ancient death-rays!
The first catapults came along around 400BC, Archimedes came along about one century later.
Greek Fire and cotton are newer though... but I'm sure they had other suitable flammables. They certainly had other fabrics, woods, wax, lamp oil, etc., more than enough to still make decent fireballs.
There is also that matter of the "Death Ray" being his only "creation" that was not documented until long after his death. My guess is that he might have sketched it but never actually built it... or at least not in full-scale.
Trying to burn a distant moving target (even if it is only waves and wind) by using a huge mirror array is possible but not practical. Catapulting boulders wrapped in lit "Greek Fire"-soaked cotton is far more effective.
But there is a distinction between programming for life-support or similarly critical system and programming for set-top boxes, game consoles, PCs and the likes where a bug is simply inconvenient to some extent.
OSes and libraries have flaws, hardware combinations can cause conflicts, drivers can clash, compilers and linkers can generate incorrect code, etc. It is impossible to guarantee code quality for anything beyond the smallest designs... like ASM OS-less microcontroller firmware. As someone else said, a typical large-scale software system has way too many unknowns and as an engineer, I would never sign one off... at least not without the approval of a few test coverage engineers/scientists. For small projects, this would increase the cost by 100X and would be a total waste for non-critical software.
For complex systems like aircrafts, critical systems have multiple implementations and when all fly-by-wire fails, they still have the autopilot kill-switch and unassisted hydraulic backup. The best autopilot software in the world will never stop the majority of crashes... with the leading causes being maintenance negligeance or mistakes, mechanical or electrical failures, miscommunication and pilot error.
Intel already has a complete software model of their own CPUs to test their patent-pending improvements with. Intel has also invested milions if not bilions into custom synthesis and simulation software and models. Patent laws allow patenting improvements of existing patents and this is exactly what Intel is doing. If the components of the whole are individually patented, patenting the end-product is redundant... and useless since nobody is licensing Intel's patents to make copycat chips. Upstarts do not posses any of these luxuries. Patenting complete systems does not provide as much protection as patenting components but patenting specific configurations is usually easier.
Most of the open-source CPU cores are small-scale stuff designed to optimize performance-to-area ratio by taking advantage of the dual-ported nature of most modern FPGA's SRAM and buffers. For larger-scale CPU designs, dual-ported registers and SRAMs are not enough so, serious CPU research is mostly simulated until prototypes can be produced. A new branch predictor is useless on its own and in large part meaningless if implanted in an alien architecture running alien code since the collected data may not be representative of the target architecture and code base.
An FPGA prototype can be fairly expensive. To make a working modern CPU on an FPGA, you would need a couple of the largest FPGAs currently in existence and these cost around $15k each. Even there, it may not be possible or practical because register files and other internal memories are too massively multi-ported to be practical on FPGAs. Then you need $2000+ PCBs to fit those FPGAs, $100k in software licenses (PCB design, FPGA design, etc.) and over $1M in lab equipment to test/debug the setup.
Requiring a proof-of-concept sounds good but for some things, it is either impossible, impractical, very expensive, takes too long to the point of being obsolete by the time the demo is ready, etc.
Since eMail is just text data and manipulating text data is done by software, this really boils down to software patents. Now, that was a dumb idea and this story is just one more example of why.
Slashdot Mirror
Actually, LCDs are refreshed one row at a time and controllers typically do not do buffering beyond two lines for double-buffered DAC inputs. The LCD controller selects the display line, loads one line (or segment) worth of data and drives the DACs' outputs to update the line. This is in many ways very similar to how CCDs and DRAM work.
The reason why LCDs are perfectly acceptable at 60Hz as far as flicker is concerned is that undriven LCD elements take hundreds of miliseconds to fade while CRT phosphors fade in ~10ms. The LCDs' long fade time is also one of the main factors that make fast pixel response times difficult to achieve, this is why manufacturers are experimenting with over-driving DACs and other fancy schemes. As for the virtual 75Hz refresh limit on LCDs, this is in large part a DAC, analog buffering and pixel driving limit. DACs have finite bandwidth - even more so if you want to settle under 1LSB, analog buffers have finite bandwidths and capture/drive delays, pixels are located several centimeters away from the controller chip. All these constraints put very real limits on what can be done. Going beyond these limits would (probably) cause vertical streaking very similar to the horizontal streaking I am used to see on CRTs and analog-input LCDs. The only work-around for this is to divide the display area into quadrants but this strategy has its own issues.
Moore's Law: transistor count doubles every ~18 months.
Up to about three years ago, this translated in a comparable increase in system performance. If you look at system performance now compared to back when Northwood/HT was introduced, the only thing that sort-of-doubled performance since then is dual-core. Add marginal clock increases and infrastructure upgrades and you get a ~3X boost over the last three years rather than 4X. They can keep doubling transistor count by doubling caches and core counts but beyond 2MB caches and quad-core, we're deep in the land of diminishing returns.
Now, it takes nearly triple the transistors to double performance, bringing the performance-doubling cycle closer to 24 months... and even longer in the not-so-distant future.
Posting as an AC would have been ok too.
Apps do not need to support MP for MP to make a difference when the users' work load involves multiple independent CPU-bound tasks.
I like how my desktop P4/HT is generally more responsive... but I prefer my A64 laptop's widescreen LCD and how it is generally faster for single-tasking and light multi-tasking. Only problem with the A64 is that it tends to go near-death whenever I do heavy multitasking while my P4 remains reasonably responsive even under worse conditions. By the time I bring my P4 down to its knees, the A64 looks like it died.
I'm never going back to single-threaded single-core single-CPU systems ever again. My next PC/laptop will probably have something like an A64-X4 in it.
Who says one would have to swap spools?
Just pull the wire from the feed, push it through your car's input and start the winder. If the feed is hose-like and the input is tube-like with the hose's nozzle fitting in it, the feeding process can be completely automated to have a very gasoline-like overall feel. The nozzle/hose could also have a vacuum pump to collect expended fuel and top off the water tank.
As others have said though, processing Mg and Al to locally generate H2 and O2 is pretty energy-intensive so it makes little to no sense unless there is excess hydro+wind+solar (clean) potential.
This story was first posted back on March 2nd:/ 201216&tid=189&tid=102&tid=106
http://linux.slashdot.org/article.pl?sid=05/03/02
Human vision is skewed.
The reason why fluourescent lighting and CCFL look whiter than white is the same reason that adding blue when washing white clothes makes them look whiter. Human sight is least sensitive to blue so boosting the blueishness of whites make them appear whiter.
Cool-white and RGB are fine for general lighting but not where colour accuracy is desirable/necessary.
If your expropriated house's value went up, chances are that every other similar house you would move in afterwards would be similarly more expensive. If I bought a house for $100k, got thrown out 20 years later when the average comparable house is over $200k, I cannot afford another similar house again unless I get compensation for the current value plus the costs of moving. Anything less would be more like a net loss rather than a profit.
There is also the matter of inflation... 1985 dollars (purchase) are worth more than 2005 dollars (sale). At the very least, a forced sale at the purchase price would have to be inflation-indexed to achieve some semblance of break-even. Putting money in a 0.1% interest chequing account is like wasting money since the interests do not cover inflation... your balance might increase but your actual buying power is decreasing.
So, selling a house above the purchase price does not necessarily mean net profit.
If you have an RGB source with narrow-band 650nm red lighting a 600nm reflective red surface, it will be perceived as nearly black instead of the orange-ish tone under day-light.
If a given "white" light fails to reproduce the same perceivable colours, then it is not truly white for lighting purposes beyond locating things. "Narrow-band" white is suitable for convenience and security but not for decoration where it can completely skew the colour scheme.
Catastrophic failures in avionics cost hundreds of milions in financial compensation to survivors or their families, hundreds more in fines if design or maintenance flaws are found to be the cause and possibly hundred more in ground casualities/damage on top of the aircraft loss itself and substantial hikes in insurance fees.
The same thing more or less applies to medical equipment.
When we get down to cars, microcontrollers have been handling multiple systems all over the places for over a decade now. When this trend started, each microcontroller was dedicated to a single specific job. Manufacturers got comfortable with this and decided to do cost-cutting by making microcontrollers handle more than one job. As you said and many have noticed, this trend is starting to have visible side-effects.
Unfortunately for us, electronic and software failures in automotive applications are not considered as serious / mission-critical / life-support equipment. I am not looking forward to drive-by-wire where the manufacturers might decide to stop the car for every minor system failure... more service cash for them and the towing companies, more inconvenience for everyone else - I like the older stuff that keeps on going until you kill the engine instead of being at the mercy of (sometimes malfunctionning) safety switches and interlocks.
I did not say 'boil'... my oven can go up to 375C and I am guessing 140C would still be safe enough for most natural fibers.
I know that some bacteria can live at ~120C... but there is no volcanic mud pits or geysers within hundreds of kilometers from most people's homes so, contamination by these is highly unlikely - assuming they can thrive under typical household conditions.
Just putting the pillows in a dryer would remove the pillows' moisture, shake oout some of the stuff that got in it and force organisms to die or at least shutdown from dehydration. Many people already do this to re-fluff pillows.
Depending on the type of pillow, soaking them can cause the material to permanently compact. For many synthetics, the dryer and oven might melt the material and end with a similar result though.
I'm just happy that I am not inconvenienced by whatever might be in my pillows.
Break out the aluminium foil.
Cotton can survive spending an hour at over 100C, fungi and germs cannot. Cover one oven tray with foil, put the second tray at the next lowest position and put your pillows on it. The foil should prevent the cotton from burning due to direct IR exposure.
Buy the mag, leave it open for a day and when you pick it up again on the following day, the ads' batteries are dead. No need to waste tape!
I would be far more interessed in a large-scale, high-resolution and low-power displays. Even if the response times are over 100ms, this would still be plenty good for reading stuff and display slow/static content.
What is annoying with many of these wonderful technologies is that ETAs are too optimistic and often slip towards infinity. Three or four years ago, 2006 was supposed to be the year of cheap large-scale OLED displays... but unless small miracle happens in the very near future, we might not even have the first-gen mass-produced OLED desktop/laptop units in 2006.
That's an interesting idea... reading EULAs 3-4 squares at a time and put them litterally where most people figuratively put EULAs.
Sounds like a plausible business idea.
Still does not change the fact that this war started with unsubstantiated evidence of Saddam possessing WMD and sheltering terrorists. Pre-war and post-war inspections turned out absolutely zero WMD and most of the terrorists they got were locals.
In the end, more USA soldiers and bystanders got seriously injured or killed than actual terrorists captured or killed after the initial invasion.
Success? Not in my book.
Bush's war on terror is not going to prevent the next big thing. Terrorism (like nature) will find a way.
Replace the boulders by barrels or pots filled with lamp oil and cloth for wicking. Now, imagine that you are on a boat and got splashed by gallons of burning oil. Which is your priority? Soaking the deck and saving the ship or jump off the ship to save yourself? Try putting out burning oil with water... it does not work since the burning oil floats on top of water and keeps on burning there until it burns out or is snuffed out by other means.
Having the power is one thing, precision and the agility to track the target long enough to achieve ignition is another. Even with perfect aiming and a perfectly still target, it will still take a few seconds to have ignition, much longer if the wood is wet. On an actual sea, ships move allong all degrees of freedom thanks to waves, winds and oars, making accurate target tracking a major challenge. One would also need to have at least some ability to adjust focal length.
As for the people-holding-mirrors theory, try holding a ~1kg ~1m^2 sheet of perf-board with a laser pointer mounted in the center aimed inside a 10x10cm target that is 10m away... chances are that your aim will wander quite a bit even if you do not have anyone else's beam to get confused with.
"Dear invaders, please hold still while we re-aim our Death Ray's mirror array..."
There is no historic proof that "Archimedes' Death Ray" ever existed. All we know for sure is that the idea was documented and pinned on him post-mortem, unlike everything else we know for sure about him.
We have 150W CO2 lasers now, let's forget about hypothetical ancient death-rays!
The first catapults came along around 400BC, Archimedes came along about one century later.
Greek Fire and cotton are newer though... but I'm sure they had other suitable flammables. They certainly had other fabrics, woods, wax, lamp oil, etc., more than enough to still make decent fireballs.
There is also that matter of the "Death Ray" being his only "creation" that was not documented until long after his death. My guess is that he might have sketched it but never actually built it... or at least not in full-scale.
Trying to burn a distant moving target (even if it is only waves and wind) by using a huge mirror array is possible but not practical. Catapulting boulders wrapped in lit "Greek Fire"-soaked cotton is far more effective.
Next week on slashdot: "Uncyclopedia served a class-action suit due to Nano 200GB upgrade How-To."
No Orleans has some decent gags... at least for people who are mostly unaffected by what happened in the area.
"Due to its current location of mostly underwater, humidity in No Orleans often exceeds 100%."
True.
But there is a distinction between programming for life-support or similarly critical system and programming for set-top boxes, game consoles, PCs and the likes where a bug is simply inconvenient to some extent.
OSes and libraries have flaws, hardware combinations can cause conflicts, drivers can clash, compilers and linkers can generate incorrect code, etc. It is impossible to guarantee code quality for anything beyond the smallest designs... like ASM OS-less microcontroller firmware. As someone else said, a typical large-scale software system has way too many unknowns and as an engineer, I would never sign one off... at least not without the approval of a few test coverage engineers/scientists. For small projects, this would increase the cost by 100X and would be a total waste for non-critical software.
For complex systems like aircrafts, critical systems have multiple implementations and when all fly-by-wire fails, they still have the autopilot kill-switch and unassisted hydraulic backup. The best autopilot software in the world will never stop the majority of crashes... with the leading causes being maintenance negligeance or mistakes, mechanical or electrical failures, miscommunication and pilot error.
This is sort of odd... I tried previewing this post as plain-old-text after adding a link in it and the link was ok.
... previewing my post as plain-old-text worked... but maybe the 'submit' world works differently, let's see...
Just a test...
Intel already has a complete software model of their own CPUs to test their patent-pending improvements with. Intel has also invested milions if not bilions into custom synthesis and simulation software and models. Patent laws allow patenting improvements of existing patents and this is exactly what Intel is doing. If the components of the whole are individually patented, patenting the end-product is redundant... and useless since nobody is licensing Intel's patents to make copycat chips. Upstarts do not posses any of these luxuries. Patenting complete systems does not provide as much protection as patenting components but patenting specific configurations is usually easier.
Most of the open-source CPU cores are small-scale stuff designed to optimize performance-to-area ratio by taking advantage of the dual-ported nature of most modern FPGA's SRAM and buffers. For larger-scale CPU designs, dual-ported registers and SRAMs are not enough so, serious CPU research is mostly simulated until prototypes can be produced. A new branch predictor is useless on its own and in large part meaningless if implanted in an alien architecture running alien code since the collected data may not be representative of the target architecture and code base.
An FPGA prototype can be fairly expensive. To make a working modern CPU on an FPGA, you would need a couple of the largest FPGAs currently in existence and these cost around $15k each. Even there, it may not be possible or practical because register files and other internal memories are too massively multi-ported to be practical on FPGAs. Then you need $2000+ PCBs to fit those FPGAs, $100k in software licenses (PCB design, FPGA design, etc.) and over $1M in lab equipment to test/debug the setup.
Requiring a proof-of-concept sounds good but for some things, it is either impossible, impractical, very expensive, takes too long to the point of being obsolete by the time the demo is ready, etc.
Since eMail is just text data and manipulating text data is done by software, this really boils down to software patents. Now, that was a dumb idea and this story is just one more example of why.