My son's physics class was visited by 3 Chinese teachers. As they walked into the classroom, his Macbook Air crashed. He tells me he was in gmail at the time. His laptop has never had a kernel crash before or since.
Does this story prove anything? No. But it is conceivable that visiting teachers carry laptops that probe and spoof software such as gmail that the government has a keen interest in cracking. The teachers may be completely unaware of why their laptops seem to discharge batteries in a few hours even when the lids are closed.
Thirty years ago I was in the Propulsion & Thermodynamics group at Lockheed. One of the guys had a research project on spanwise rotor propulsion - his proof of concept used a beefed up cylindrical hair dryer rotor of the day. Yeah, you can get some net thrust, but at nowhere near the efficiency of conventional designs. There has to be a really strong reason to sacrifice all the extra fuel and weight and safety deficits when compared to better techniques. Perhaps there are niches where the tradeoffs are worth it, but that is not what I'd call "immense promise". Let's see what kind of thrust-to-weight, lift-to-drag, and thrust-specific-fuel-consumption their aircraft can produce first...
I've previously argued that High Frequency Trading algorithms can use collusion to reap systematic profits. If the self-learning algos 'learn' and 'express' intentions through patterns of queries, it is possible for them to do this without there being any prosecutable intent by a human. The programmers could claim that they never wrote a line of code that did any collusion.
If it is possible in theory for algos to develop trading collusion, then it is just a matter of time until they do. Since they evolve and learn very quickly, they probably already have.
ebay has Dr. Clark's copy from $250.
Amazon is $200 - $600.
The online availability of a $72 microfilm version from UMI has been terminated.
Only 2,000 copies were printed, and the Atlanta library system has zero.
If anyone has any ideas how I can get one, please email me directly at randy.j.parker@gmail.com
My dad is still lucid at 91, and would enjoy this for Christmas! During WWII he developed shaped charges for the Army with George Kistiakowsy in Pittsburgh, before Kistiakowsky got "drafted" by the Manhattan Project. Werner Von Braun used to live 2 doors down when I was a toddler, and his niece was a baby sitter for our family.
Please name the book & author. I grew up in Huntsville then and would like to get it for my PhD dad, who spent most of his career in rocket fuel oxidizers
Most of us spend money to get computers that don't "get in the way" of our work with irritating lag. We spend hundreds of dollars for faster CPUs and more memory to avoid breaking the flow.
Wireless mice and keyboards add annoying delays several times per hour. My anecdotal experience is that Bluetooth is significantly worse than proprietary RF. Is it the protocol, or the drivers? The original poster is right - there is no good survey of this problem, and no explanation from the vendors. I'd expect them to compete on reducing this problem, because it far exceeds the "break the flow" delays I suffer from any other part of my system (except for Comcast!)
I have a Microsoft 8000 Bluetooth keyboard / mouse on my Macbook Pro, and I'm pretty sure I'd be better off with a corded keyboard and Logitech proprietary wireless mouse.
My interest in wireless keys & mouse is eliminating some wire-plugging every time I move my laptop between home & office. Now I think a USB hub is a better solution.
Twitter was smart to use Rails to develop their business, and is also smart to move the performance-critical message queueing and posting portions to a higher performance technology when it got big and mature. The evolving parts are best left on Rails.
Rails remains the best way to develop solid and maintainable web apps. But it will not compete with C for speed. Once you understand your business process, and have developed a mature algorithm to make the business work, there is nothing wrong with writing the core infrastructure in C. There are lots of C libraries that do the core part of Twitter. But the company would have been idiotic to start with them, and would be foolish to move new development off Rails.
I worked on the SR-71 engine (the J-58, aka JT-11D) at Pratt & Whitney. The inlet unstart problem was not related to combustion instability, but to the difficulty of sealing the inlet spike shock to the nacelle lip as atmospheric conditions changed. You run into meteorological changes quickly when you're flying faster than a.50 caliber bullet. When the inlet shock did not meet the lip, some of the pressure behind the shock would "spill" out of the compressor and cause an engine flame-out. http://mobiledyne.com/about/j58
Yes. It is broadcast on The Weather Channel, distributed on weather.com, syndicated to lots of big media outlets like USA Today, and employed via RSS in ForecastFox. (the syndication customers pay)
It is called the Global Forecast Center (GFC), and it includes the use of a system called Dicast.
For the last 25 months, TWC has produced its own forecasts by doing pretty much what the parent suggests: using its own computers to compare the current forecasts of the 'first principal' weather simulations produced by government supercomputers. The GFC then weights the forecast of each model by its historical accuracy for the weather situation it is modeling at each location, and produces a 'meta-forecast' for that loc.
Dicast was produced largely through US Government funding, but TWC has also spent very large sums of its own money to finish it up. I beleive TWC is the only private company to help fund Dicast development.
TWC first implemented Dicast for on-air / web forecasts when you saw the new "Global Forecast Center" background on their studio TV set. That moniker was not some puffed-up marketing. The GFC (using Dicast) is a very big deal, and nobody else supplies forecasts from it. The shift from NWS forecasts to GFC forecasts took years to implement, and impacted dozens of TWC internal systems.
Here is the offical realese from 11/11/2002:
GFC Now Generating 36-hr. Text Forecasts
Early last week, we successfully executed a switch from a National Weather Service (NWS) generated 36-Hour Forecast to one prepared by the Global Forecast Center (GFC) on all legacy Star platforms of the core network. With the replacement of the NWS text forecast on the WEATHER STAR® III, 4000, and Jr., the entire suite of local weather forecast products is now prepared by the meteorological staff here at The Weather Channel. The official NWS watches, warnings, and advisories of all types will continue to display on all WEATHER STAR® units.
One additional change that has been implemented since that announcement is the deployment of the new IntelliStar® real-time television rendering systems in more than 1,000 locations around the USA. The IntelliStar uses heuristics to adapt the Local Forecast at each individual location to the actual weather situation. For example, the Radar loop is abbreviated if there is no rain to show. (TWC uses a variety of WeatherStar devices at almost 10,000 locations to produce the Local. No other television network does anything even remotely comparable. Developing, deploying, and maintaining 10,000 TV rendering systems scattered around the US ain't cheap!!)
TWC has roughly one hundred staff meteorologists that manually review and adjust the Dicast output, particularly when the 'first principal' models are prone to miss some physical discontinuity. (for example, most models can't simulate hurricanes at all)
The NWS has far more meteorogical staff in its field offices, and they continue to provide an invaluable service for the nation. Computers and private companies can't replace the expertise of the NWS Field Office meteorologists and their $820M budget(FY2004).
My point is that it is unfair and inaccurate to lump TWC in with 'the weather stenographers'. TWC really does spend a lot of effort and money to produce a value-added weather product. The folks here are more serious about accurate weather prediction than most outsiders would believe.
(This post is my personal understanding and view, not an official TWC release.)
I just corresponded with Jon, the developer of ForecastFox. I work as a contractor at The Weather Channel, and was surprised that they had objected to the name 'WeatherFox'. Jon explained that it was the owner of the domain name weatherfox.com that objected, not TWC.
TWC is actually a huge supporter of open source software, to the point of providing full time employment for a FreeBSD kernel developer. We've directly funded some other open source projects too, and try to give back in lots of ways.
The ideal booklight does not constrain your position, allowing you to roll from side to side without changing the page illumination. This means it has to be either mounted on the book, or your head. If it is on the book, it inevitably interferes with turning the pages, and it adds weight. So my vote is for a headlamp.
A headlamp should be not too bright, and provide uniform lighting across the page. This eliminates single LED lights.
The Black Diamond Ion weighs less than 1 oz, and has an easily adjusted wide elastic headband. In less than a minute, you forget you're wearing it. It has 2 LEDs, which provides a more uniform illumination than 1, but still projects bright spots on the page. (all LED lights do this, in my experience. I don't know why, or how much improvement can be expected in the near future). The battery is odd - a 6V that is a little bigger than the eraser on a pencil. It drives the light for far more than the rated 15-20 hours. My son lost his in the backyard the afternoon we went on a trip, and it was still going strong after we returned in the dark the next night. And he continues to use it reading in bed 30 min per night, several weeks later!!
I don't know if rechargeables are available in the required size.
The Ion costs less than $20. It is either on or off, not dimmable. It has no auto-shutoff timer. But it is widely available, practically waterproof, and withstands being dropped without a problem.
I just got an Infiniti G35, and it does have a "Sat" button on the head unit. (I've not yet dismantled the dashboard enough to see the available connectors on the back)
Are you saying that the satellite radio interface incorporates both a 12-pin J1850 connector cable for data and control, and a RCA connector for audio? Or is digital music sent directly as J1850 Class C (1 Mbit/s)?
Use of the in-dash and steering wheel switches to control the iPod is probably not possible anyway (or at least not simple). But if I can just plug the audio into an RCA plug, I'd have what I want... I'd just use the iPod controls manually.
I've emailed the outfits you mentioned, and they say they have nothing available. Crutchfield says "just use a mini-RCA to RCA adapter cable". Either the "advisor" is confused, or a regular AUX connector is part of the satellite radio interface. Do you know? If it is so simple, I'm surprised none of the specialty outfits told me! (the guy at go2pac.com even said he has a G35 himself)
Related techniques: Swarmcast, Typhoon, rmt, Fcast, mgpm, onionnetworks
Michael Luby and Amin Shokrollahi are CTO and Chief Scientist of Digital Fountain. They are a couple genuine experts on FEC (foward error correction). They have published academic papers on this topic. While at Berkeley's International Computer Science Institute, Processor Luby wrote "Benchmark Comparisons of Erasure Codes" (http://www.icsi.berkeley.edu/~luby ), and Accessing Multiple Mirror Sites in Parallel: Using Tornado Codes to Speed Up Downloads", "A Digital Fountain Approach to Reliable Data Distribution of Bulk Data" (a slideshow pitch - these last two are on digitalfountain.com/technology/library/papers ). Luby also wrote "The Use of Forward Error Correction in Reliable Multicast" (an Internet Engineering Task Force draft).
See also "Fcast multicast file distribution: Tune in, download, and drop out" from Jim Gemmell and Jim Gray of Microsoft, published in Dr. Dobbs.
Professor Luigi Rizzo from Universita a Pisa (poke around http://www.iet.unipi.it/~luigi )wrote a whole bunch of papers on Vandermonde matrix codes, including a downloadable sample program. Rizzo's work is the guts of several open-source FEC projects (most of which seem to have dried up).
All three of these guys (Luby, Rizzo, Gemmell) co-wrote "Asynchronous Layered Coding: A massively scalable reliable content delivery protocol" (another IETF draft from 7/20/2001).
My opinion is the Luby et al have improved Rizzo's FEC techniques by application of a great deal of mathematics. The Digital Fountain "LT" (Luby Transform) codes are (modest?) improvements on Tornado Codes. The Tornado Codes require less CPU than Rizzo's Vandermonde codes for gigantic erasure-code block sizes. But so what? I don't know what's so wrong with 1-k packet sizes. If the much simpler Reed-Soloman math serves well for modest block sizes, why not use modest block sizes? Complexity matters! Why write complicated code unless you really need something it alone can do? A professor may create a more optimal solution, but there are lots of examples of simple approaches that are more than good enough.
I do believe that FEC provides benefits far beyond what can be done with ftp. The issue of ack-latency and sliding window sizes is completely eliminated. You may transmit 50-300% more bytes to get the content, but at full network speed every time! And if you are transmitting the file to multiple receivers, they can join a multicast group and get the same stream without concern with where in the content they begin. As long as they get a certain fraction of the transmission, they can compute the original content. This means that tons of "dropped packets" and "data loss" can be tolerated without concern for data integrity. Specific data relating content expansion (50%? 200%?) vs data loss (bit error rate, correlated / uncorrelated packet loss), and CPU consumed by the algorithm **for code blocks of, say 100k-500k** is something I'm still trying to locate. Several of the big players try to obscure these comparisons for commercial reasons, and I don't blame them. They've spent years developing their algorithms. On the other hand, if their approaches are really much better than the simpler techniques, they have not convincingly demonstrated it. Or is there some advantage in choosing erasure code blocks of many megabytes? Why not just use Unix "split" on the file before encoding? Maybe that's what some of these other guys actually do, and maybe it works just fine.
Slashdot Mirror
My son's physics class was visited by 3 Chinese teachers. As they walked into the classroom, his Macbook Air crashed. He tells me he was in gmail at the time. His laptop has never had a kernel crash before or since. Does this story prove anything? No. But it is conceivable that visiting teachers carry laptops that probe and spoof software such as gmail that the government has a keen interest in cracking. The teachers may be completely unaware of why their laptops seem to discharge batteries in a few hours even when the lids are closed.
My Comcast modem is always warm - I'd guess 15W, to do the same job as a 1/2 W smartphone modem.
Thirty years ago I was in the Propulsion & Thermodynamics group at Lockheed. One of the guys had a research project on spanwise rotor propulsion - his proof of concept used a beefed up cylindrical hair dryer rotor of the day. Yeah, you can get some net thrust, but at nowhere near the efficiency of conventional designs. There has to be a really strong reason to sacrifice all the extra fuel and weight and safety deficits when compared to better techniques. Perhaps there are niches where the tradeoffs are worth it, but that is not what I'd call "immense promise". Let's see what kind of thrust-to-weight, lift-to-drag, and thrust-specific-fuel-consumption their aircraft can produce first...
I've previously argued that High Frequency Trading algorithms can use collusion to reap systematic profits. If the self-learning algos 'learn' and 'express' intentions through patterns of queries, it is possible for them to do this without there being any prosecutable intent by a human. The programmers could claim that they never wrote a line of code that did any collusion. If it is possible in theory for algos to develop trading collusion, then it is just a matter of time until they do. Since they evolve and learn very quickly, they probably already have.
Nexidia has been selling proprietary tech to do this for years
ebay has Dr. Clark's copy from $250. Amazon is $200 - $600. The online availability of a $72 microfilm version from UMI has been terminated. Only 2,000 copies were printed, and the Atlanta library system has zero. If anyone has any ideas how I can get one, please email me directly at randy.j.parker@gmail.com My dad is still lucid at 91, and would enjoy this for Christmas! During WWII he developed shaped charges for the Army with George Kistiakowsy in Pittsburgh, before Kistiakowsky got "drafted" by the Manhattan Project. Werner Von Braun used to live 2 doors down when I was a toddler, and his niece was a baby sitter for our family.
Please name the book & author. I grew up in Huntsville then and would like to get it for my PhD dad, who spent most of his career in rocket fuel oxidizers
Jan has a lot of worthwhile detail and commenting in his article: http://www.streaminglearningcenter.com/articles/flash-player-cpu-hog-or-hot-tamale-it-depends-.html
Wireless mice and keyboards add annoying delays several times per hour. My anecdotal experience is that Bluetooth is significantly worse than proprietary RF. Is it the protocol, or the drivers? The original poster is right - there is no good survey of this problem, and no explanation from the vendors. I'd expect them to compete on reducing this problem, because it far exceeds the "break the flow" delays I suffer from any other part of my system (except for Comcast!)
I have a Microsoft 8000 Bluetooth keyboard / mouse on my Macbook Pro, and I'm pretty sure I'd be better off with a corded keyboard and Logitech proprietary wireless mouse.
My interest in wireless keys & mouse is eliminating some wire-plugging every time I move my laptop between home & office. Now I think a USB hub is a better solution.
Rails remains the best way to develop solid and maintainable web apps. But it will not compete with C for speed. Once you understand your business process, and have developed a mature algorithm to make the business work, there is nothing wrong with writing the core infrastructure in C. There are lots of C libraries that do the core part of Twitter. But the company would have been idiotic to start with them, and would be foolish to move new development off Rails.
I worked on the SR-71 engine (the J-58, aka JT-11D) at Pratt & Whitney. The inlet unstart problem was not related to combustion instability, but to the difficulty of sealing the inlet spike shock to the nacelle lip as atmospheric conditions changed. You run into meteorological changes quickly when you're flying faster than a .50 caliber bullet. When the inlet shock did not meet the lip, some of the pressure behind the shock would "spill" out of the compressor and cause an engine flame-out. http://mobiledyne.com/about/j58
Yes. It is broadcast on The Weather Channel, distributed on weather.com, syndicated to lots of big media outlets like USA Today, and employed via RSS in ForecastFox. (the syndication customers pay)
For the last 25 months, TWC has produced its own forecasts by doing pretty much what the parent suggests: using its own computers to compare the current forecasts of the 'first principal' weather simulations produced by government supercomputers. The GFC then weights the forecast of each model by its historical accuracy for the weather situation it is modeling at each location, and produces a 'meta-forecast' for that loc.
Dicast was produced largely through US Government funding, but TWC has also spent very large sums of its own money to finish it up. I beleive TWC is the only private company to help fund Dicast development.
TWC first implemented Dicast for on-air / web forecasts when you saw the new "Global Forecast Center" background on their studio TV set. That moniker was not some puffed-up marketing. The GFC (using Dicast) is a very big deal, and nobody else supplies forecasts from it. The shift from NWS forecasts to GFC forecasts took years to implement, and impacted dozens of TWC internal systems. Here is the offical realese from 11/11/2002:
GFC Now Generating 36-hr. Text Forecasts
Early last week, we successfully executed a switch from a National Weather Service (NWS) generated 36-Hour Forecast to one prepared by the Global Forecast Center (GFC) on all legacy Star platforms of the core network. With the replacement of the NWS text forecast on the WEATHER STAR® III, 4000, and Jr., the entire suite of local weather forecast products is now prepared by the meteorological staff here at The Weather Channel. The official NWS watches, warnings, and advisories of all types will continue to display on all WEATHER STAR® units.
One additional change that has been implemented since that announcement is the deployment of the new IntelliStar® real-time television rendering systems in more than 1,000 locations around the USA. The IntelliStar uses heuristics to adapt the Local Forecast at each individual location to the actual weather situation. For example, the Radar loop is abbreviated if there is no rain to show. (TWC uses a variety of WeatherStar devices at almost 10,000 locations to produce the Local. No other television network does anything even remotely comparable. Developing, deploying, and maintaining 10,000 TV rendering systems scattered around the US ain't cheap!!)
TWC has roughly one hundred staff meteorologists that manually review and adjust the Dicast output, particularly when the 'first principal' models are prone to miss some physical discontinuity. (for example, most models can't simulate hurricanes at all)
The NWS has far more meteorogical staff in its field offices, and they continue to provide an invaluable service for the nation. Computers and private companies can't replace the expertise of the NWS Field Office meteorologists and their $820M budget(FY2004).
My point is that it is unfair and inaccurate to lump TWC in with 'the weather stenographers'. TWC really does spend a lot of effort and money to produce a value-added weather product. The folks here are more serious about accurate weather prediction than most outsiders would believe.
(This post is my personal understanding and view, not an official TWC release.)
TWC is actually a huge supporter of open source software, to the point of providing full time employment for a FreeBSD kernel developer. We've directly funded some other open source projects too, and try to give back in lots of ways.
FreeBSD. Not only is the entire distribution integrated, but all future updates of all pieces are integrated in the same way.
A headlamp should be not too bright, and provide uniform lighting across the page. This eliminates single LED lights.
The Black Diamond Ion weighs less than 1 oz, and has an easily adjusted wide elastic headband. In less than a minute, you forget you're wearing it. It has 2 LEDs, which provides a more uniform illumination than 1, but still projects bright spots on the page. (all LED lights do this, in my experience. I don't know why, or how much improvement can be expected in the near future). The battery is odd - a 6V that is a little bigger than the eraser on a pencil. It drives the light for far more than the rated 15-20 hours. My son lost his in the backyard the afternoon we went on a trip, and it was still going strong after we returned in the dark the next night. And he continues to use it reading in bed 30 min per night, several weeks later!! I don't know if rechargeables are available in the required size.
The Ion costs less than $20. It is either on or off, not dimmable. It has no auto-shutoff timer. But it is widely available, practically waterproof, and withstands being dropped without a problem.
See: http://www.backpackgeartest.org/reviews/Lighting
I just got an Infiniti G35, and it does have a "Sat" button on the head unit. (I've not yet dismantled the dashboard enough to see the available connectors on the back) Are you saying that the satellite radio interface incorporates both a 12-pin J1850 connector cable for data and control, and a RCA connector for audio? Or is digital music sent directly as J1850 Class C (1 Mbit/s)? Use of the in-dash and steering wheel switches to control the iPod is probably not possible anyway (or at least not simple). But if I can just plug the audio into an RCA plug, I'd have what I want... I'd just use the iPod controls manually. I've emailed the outfits you mentioned, and they say they have nothing available. Crutchfield says "just use a mini-RCA to RCA adapter cable". Either the "advisor" is confused, or a regular AUX connector is part of the satellite radio interface. Do you know? If it is so simple, I'm surprised none of the specialty outfits told me! (the guy at go2pac.com even said he has a G35 himself)
Related techniques: Swarmcast, Typhoon, rmt, Fcast, mgpm, onionnetworks
Michael Luby and Amin Shokrollahi are CTO and Chief Scientist of Digital Fountain. They are a couple genuine experts on FEC (foward error correction). They have published academic papers on this topic. While at Berkeley's International Computer Science Institute, Processor Luby wrote "Benchmark Comparisons of Erasure Codes" (http://www.icsi.berkeley.edu/~luby ), and Accessing Multiple Mirror Sites in Parallel: Using Tornado Codes to Speed Up Downloads", "A Digital Fountain Approach to Reliable Data Distribution of Bulk Data" (a slideshow pitch - these last two are on digitalfountain.com/technology/library/papers ). Luby also wrote "The Use of Forward Error Correction in Reliable Multicast" (an Internet Engineering Task Force draft).
See also "Fcast multicast file distribution: Tune in, download, and drop out" from Jim Gemmell and Jim Gray of Microsoft, published in Dr. Dobbs.
Professor Luigi Rizzo from Universita a Pisa (poke around http://www.iet.unipi.it/~luigi )wrote a whole bunch of papers on Vandermonde matrix codes, including a downloadable sample program. Rizzo's work is the guts of several open-source FEC projects (most of which seem to have dried up).
All three of these guys (Luby, Rizzo, Gemmell) co-wrote "Asynchronous Layered Coding: A massively scalable reliable content delivery protocol" (another IETF draft from 7/20/2001).
My opinion is the Luby et al have improved Rizzo's FEC techniques by application of a great deal of mathematics. The Digital Fountain "LT" (Luby Transform) codes are (modest?) improvements on Tornado Codes. The Tornado Codes require less CPU than Rizzo's Vandermonde codes for gigantic erasure-code block sizes. But so what? I don't know what's so wrong with 1-k packet sizes. If the much simpler Reed-Soloman math serves well for modest block sizes, why not use modest block sizes? Complexity matters! Why write complicated code unless you really need something it alone can do? A professor may create a more optimal solution, but there are lots of examples of simple approaches that are more than good enough.
I do believe that FEC provides benefits far beyond what can be done with ftp. The issue of ack-latency and sliding window sizes is completely eliminated. You may transmit 50-300% more bytes to get the content, but at full network speed every time! And if you are transmitting the file to multiple receivers, they can join a multicast group and get the same stream without concern with where in the content they begin. As long as they get a certain fraction of the transmission, they can compute the original content. This means that tons of "dropped packets" and "data loss" can be tolerated without concern for data integrity. Specific data relating content expansion (50%? 200%?) vs data loss (bit error rate, correlated / uncorrelated packet loss), and CPU consumed by the algorithm **for code blocks of, say 100k-500k** is something I'm still trying to locate. Several of the big players try to obscure these comparisons for commercial reasons, and I don't blame them. They've spent years developing their algorithms. On the other hand, if their approaches are really much better than the simpler techniques, they have not convincingly demonstrated it. Or is there some advantage in choosing erasure code blocks of many megabytes? Why not just use Unix "split" on the file before encoding? Maybe that's what some of these other guys actually do, and maybe it works just fine.
The algorithm complexity hierarchy looks like:
1) XOR
2) Vandermonde-based RSE (Reed Soloman Erasure)
3) Cauchy-based RSE
4) Tornado
5) LT