I attempted to try doing some edits, but it's so broken as to be next to impossible to fix.
It seems that once a street has a directionality applied to it, you can't remove it.
Also, so far it seems next to impossible to take two roads that are connected and say, "these roads are NOT actually connected" and split them.
Let's not forget the fact that frequently the editor decides that for whatever reason, it can't undo something and you have to scrap your entire editing session...
Obsolescence. Many of the parts used in those old designs are no longer available, and it would cost far more to try and get those production lines spooled up (probably 3/4 of the production lines used to make electronic components for the old Apollo series computers are now EPA Superfund sites...) than to create a completely new design.
Remember Ariane 5? It blew up because the flight computers were all the exact same design and running the same software. Having your triply redundant flight computers come from different design teams fed with the exact same requirements helps a lot to avoid that kind of failure.
That said, this approach to redundancy does NOT scale up to multiple launch vehicle designs with the same goals... That would be stupid, since if one LV fails, people are still dead.
"OSM didn't break the map, the feds (Census) really do have that down as a two-way street, but nobody in your area (you) has fixed it in OSM yet. So if it's wrong, it's your fault for not fixing it."
You seem to have failed to understand what I said. The Census data *does not have turn restriction data of any sort*. (this includes one-way street markings). The Feds didn't say anything about whether it was one-way or two-way. Before the OSM import of TIGER data even happened, NavTeq and TeleAtlas added this information themselves. So in terms of who has done "more" with the Census TIGER data, NavTeq and TeleAtlas clearly have.
In terms of the directionality info of 17 and 434, that wasn't wrong in the TIGER data either. IT WASN'T THERE. IT ISN'T THERE FOR ANY ROAD. The OSM importer apparently tries to guess directionality for some roads, and in this case, it *guessed wrong* and made the data *worse*.
Yeah, this was my first reaction as an NYS resident.
If given a choice between collecting tax and booting all affiliates within a given state, why has Amazon chosen "boot affiliates" in NC and RI, but "collect tax" in NY?
For some purchases it's actually cheaper for me to ship to my parents' in NJ and then drive down there.
Not enough details, but I'm guessing that since the USB Battery Charging Specification is now out, they'll follow that.
Prior to release of that spec (long after many of the "de facto" dumb charging conventions were out), methods for indicating a dumb charger to a USB device were not standardized. Pulling more than 100 mA from a dumb charger without some way of identifying it as such is forbidden by the USB specification. Since "dumb charger" signaling wasn't standardized until way too late in the game (at least for mini-USB), we wound up with lots of different methods of signaling "dumb chargers".
Drawing more than 100 mA without negotiating a host connection is verboten by USB Drawing more than 500 mA from a USB host is verboten
So "dumb chargers" that supply 100 mA to a device need some method of signaling this. Unfortunately, the USB Battery Charging Specification was released way too late in the game, after a number of "de facto" standards (most based on using pin 4 of the mini-USB connector) cropped up, with the typical difference being resistor values.
Motorola/BlackBerry: 220k or 440k to ground depending on charger current rating HTC: Dead short to ground Garmin: 17k to ground for 1A, dead short for 500 mA
And for dumb chargers, the USB Battery Charging Specification was released so late in the game that there were already "de facto" standards for signaling a dumb charger to a device.
Apple does it with funky resistors between the data and power lines, allowing it to be done without any extra pins.
Motorola, BlackBerry, Garmin, HTC, and probably TomTom all do it using pin 4 of the mini-USB connector (which is defined as not connected).
Moto/BB use, if I recall correctly, a 220k resistor to ground for "fast" chargers and 440k for "slow" (but faster than a host) chargers Garmin uses 17k for "fast" chargers (1A) and a direct short to ground for "slow" chargers (500 mA) HTC just shorts to ground for any dumb charger
No DRM, no "funky chip", and it's not done to sell chargers - it's done because drawing over 100 mA without a host negotiation or signaling of a dumb charger and over 500 mA without somehow determining the presence of a "dumb charger" is verboten.
Newer devices tie the two data lines to each other with a 200 ohm resistor on the charging end (USB battery charging specificiation) - Most likely all of the micro-USB devices do it this way, partly because pin 4 actually has meaning for micro-USB connectors (part of the USB OTG standard).
Not enough detail in the article, but most likely by following the USB Battery Charging Specification. (Which was, unfortunately, released long after numerous "de facto" standards for signaling dumb chargers became prolific, most of which involve tying mini-USB pin 4 to ground with varying amounts of resistance. This can't be done in micro-USB, as micro-USB has specified meaning for pin 4.)
Does your Pre draw 1000 mA from a computer, or from a "dumb charger" that signals itself as such?
OSM appears to have botched the TIGER import so badly (merging lanes of a divided highway into one, incorrectly marking an adjacent road as being a lane in that divided highway) that fixing the OSM data would be incredibly difficult.
Also, OSM has done NOTHING with that dataset. They did a straight import that appears to have tried to cleanup/simplify maps and in the process broke them.
For example: Lake Street in Owego, NY, USA is a one-way street. TeleAtlas and NavTeq know this, OSM does not (as the source data set does not contain turn restrictions data) The OSM importer seems to have taken NY State Route 17 and turned it into single lane of a divided highway. NY State Route 434 (which parallels 17) is shown as the "paired" lane to 17. This is WRONG. NYS 17 has two one-way subroads (divided highway), and 434 is a standard two-way road. OSM shows these three strips of pavement as two with completely bogus directionality info. The autoimporter clearly guessed at what the direction restrictions here should have been, and guessed blatantly wrong.
It's a proper GPS. The A-GPS application in this case is not the "classic" tower-based A-GPS, but is what is often refered to as "QuickFix" or "HotFix" or "InstantFix" depending on manufacturer.
The idea is that even with a good signal, satellite ephemerides take a minimum of 30 seconds to download from a GPS satellite. Even with good pseudorange data, without ephemerides a satellite is unusable for a navigation fix.
Most of the current "A-GPS" approaches involve preloading approximately a weeks' worth of ephemerides into a receiver, so that a position fix can be obtained as soon as pseudorange data becomes available.
Huge difference from the original meaning of Assisted GPS, where the handset collected pseudorange data and passed it to the tower for E911 purposes. This was needed back when handsets didn't have much CPU power. Nowadays basically any handset has enough CPU to calculate a position fix on its own.
While the TomTom units run Linux, all of the "useful" functions are in the highly proprietary NavCore application. Despite being Linux-based, they're not really "hackable". There are some hacks, but they still depend on cooperation with NavCore.
The Windows CE devices tend to be quite hackable, such as the 4.3" and 5" WinCE + SiRF Atlas-III devices at dealextreme.com. I have one such unit on order and am looking forward to receiving it.
In general, there are few open source mapping applications for portable devices, and not a single one that I know of that does turn-by-turn due to lack of turn restriction data in publically available data sets. For example, any of the "open source" street datasets in the United States are descended from the US Census Bureau TIGER dataset. This dataset does not (or at least did not, as of 2005-2006) contain any turn restriction data, e.g. one way roads and intersections that don't allow certain types of turns. The end result is that any attempt to do routing with these datasets will have odd results (namely, high chance of illegal turns and going the wrong way on a one way road.)
Two lengths of Cat 5 is probably cheaper than one of Cat 3 and one of Cat 6, plus it's guaranteed to get the job done even if the cat has an extra life.
"Google wants to see reference specs that include options for bare motherboards to slide right into your basic 42 unit rack with IO, disk and power all pulled out to the raw basics so Google can decide how to manage the bits rather than having stock OEM boards with such limited options."
Many of the new CPUs DO have huge performance gains when running multimedia applications (video encoding/decoding, and especially 3D gaming).
Maybe they just aren't as good for Facebook's systems, which probably don't do much floating point, if at all. Similarly, almost nothing FB does (except for possibly resizing images when they are uploaded by users) can take advantage of SIMD instructions such as SSE4 (which delivered huge performance gains for some relatively common desktop multimedia apps but isn't going to help an HTTP server or database server.)
Looks like it is not where the serious barebone laptop builder does their shopping.
Not a single one of the three "barebones" notebooks Newegg offers is something I would base a system on. All have either Intel integrated graphics or ATI graphics, no NVidia-based options. Every time I've dealt with ATI's drivers (last was on my ex's Dell Inspiron 600M) it's been a nightmare.
Does he cover the sterility issue with algae? Based on the literature I've read so far, one of the primary challenges with algae-based biofuels is that the algae species that are good for biofuel production are at a competitive disadvantage to other algae species that basically suck for the purposes of biofuel production.
Thus it's really easy for a bioreactor to get contaminated and stop producing anything useful.
"and somewhat more exotic approaches(like bubbling the stuff through algae farms) aren't too far outside the realm of the currently possible."
That's an interesting observation. As I understand what I've read so far, one of the biggest challenges to large-scale algae farming has been keeping the medium sterile. The most efficient species at generating biodiesel are NOT the dominant ones if other algae species or organisms enter. As a result, most pilot projects have been using power plant exhaust directly, as it is fundamentally sterile by nature of the fact that it had recently been superheated.
One would assume that these "synthetic trees" would produce pure sterile CO2, which might allow these algae farms to be located separately from power plants.
Either the firewall I'm behind doesn't like HWB, or the storm has moved there too.
Re:Any recommendations for a digital point-n-shoot
on
Kodak Kills Kodachrome
·
· Score: 1
RAW support?
Probably not out of the box.
CHDK + one of the PowerShot A series is probably your best bet.
RAW without manual controls is not the most ideal combination, so except for the SD990 + CHDK, the Elphs are out. The SD990 is above your budget range.
While digital is doing a pretty good job displacing film for the majority of 35mm photography and below, the barriers to entry for medium format digital are so high that film is still going strong there.
Slashdot Mirror
I attempted to try doing some edits, but it's so broken as to be next to impossible to fix.
It seems that once a street has a directionality applied to it, you can't remove it.
Also, so far it seems next to impossible to take two roads that are connected and say, "these roads are NOT actually connected" and split them.
Let's not forget the fact that frequently the editor decides that for whatever reason, it can't undo something and you have to scrap your entire editing session...
Obsolescence. Many of the parts used in those old designs are no longer available, and it would cost far more to try and get those production lines spooled up (probably 3/4 of the production lines used to make electronic components for the old Apollo series computers are now EPA Superfund sites...) than to create a completely new design.
To some degree, (at the subsystem level), it is.
Remember Ariane 5? It blew up because the flight computers were all the exact same design and running the same software. Having your triply redundant flight computers come from different design teams fed with the exact same requirements helps a lot to avoid that kind of failure.
That said, this approach to redundancy does NOT scale up to multiple launch vehicle designs with the same goals... That would be stupid, since if one LV fails, people are still dead.
"OSM didn't break the map, the feds (Census) really do have that down as a two-way street, but nobody in your area (you) has fixed it in OSM yet. So if it's wrong, it's your fault for not fixing it."
You seem to have failed to understand what I said. The Census data *does not have turn restriction data of any sort*. (this includes one-way street markings). The Feds didn't say anything about whether it was one-way or two-way. Before the OSM import of TIGER data even happened, NavTeq and TeleAtlas added this information themselves. So in terms of who has done "more" with the Census TIGER data, NavTeq and TeleAtlas clearly have.
In terms of the directionality info of 17 and 434, that wasn't wrong in the TIGER data either. IT WASN'T THERE. IT ISN'T THERE FOR ANY ROAD. The OSM importer apparently tries to guess directionality for some roads, and in this case, it *guessed wrong* and made the data *worse*.
Yeah, this was my first reaction as an NYS resident.
If given a choice between collecting tax and booting all affiliates within a given state, why has Amazon chosen "boot affiliates" in NC and RI, but "collect tax" in NY?
For some purchases it's actually cheaper for me to ship to my parents' in NJ and then drive down there.
Not enough details, but I'm guessing that since the USB Battery Charging Specification is now out, they'll follow that.
Prior to release of that spec (long after many of the "de facto" dumb charging conventions were out), methods for indicating a dumb charger to a USB device were not standardized. Pulling more than 100 mA from a dumb charger without some way of identifying it as such is forbidden by the USB specification. Since "dumb charger" signaling wasn't standardized until way too late in the game (at least for mini-USB), we wound up with lots of different methods of signaling "dumb chargers".
Any signs of corrosion?
While AL has the humidity, depending on your proximity to the local roads, road salt could be a factor?
Not really Motorola's fault.
Drawing more than 100 mA without negotiating a host connection is verboten by USB
Drawing more than 500 mA from a USB host is verboten
So "dumb chargers" that supply 100 mA to a device need some method of signaling this. Unfortunately, the USB Battery Charging Specification was released way too late in the game, after a number of "de facto" standards (most based on using pin 4 of the mini-USB connector) cropped up, with the typical difference being resistor values.
Motorola/BlackBerry: 220k or 440k to ground depending on charger current rating
HTC: Dead short to ground
Garmin: 17k to ground for 1A, dead short for 500 mA
And for dumb chargers, the USB Battery Charging Specification was released so late in the game that there were already "de facto" standards for signaling a dumb charger to a device.
Apple does it with funky resistors between the data and power lines, allowing it to be done without any extra pins.
Motorola, BlackBerry, Garmin, HTC, and probably TomTom all do it using pin 4 of the mini-USB connector (which is defined as not connected).
Moto/BB use, if I recall correctly, a 220k resistor to ground for "fast" chargers and 440k for "slow" (but faster than a host) chargers
Garmin uses 17k for "fast" chargers (1A) and a direct short to ground for "slow" chargers (500 mA)
HTC just shorts to ground for any dumb charger
No DRM, no "funky chip", and it's not done to sell chargers - it's done because drawing over 100 mA without a host negotiation or signaling of a dumb charger and over 500 mA without somehow determining the presence of a "dumb charger" is verboten.
Newer devices tie the two data lines to each other with a 200 ohm resistor on the charging end (USB battery charging specificiation) - Most likely all of the micro-USB devices do it this way, partly because pin 4 actually has meaning for micro-USB connectors (part of the USB OTG standard).
Not enough detail in the article, but most likely by following the USB Battery Charging Specification. (Which was, unfortunately, released long after numerous "de facto" standards for signaling dumb chargers became prolific, most of which involve tying mini-USB pin 4 to ground with varying amounts of resistance. This can't be done in micro-USB, as micro-USB has specified meaning for pin 4.)
Does your Pre draw 1000 mA from a computer, or from a "dumb charger" that signals itself as such?
OSM appears to have botched the TIGER import so badly (merging lanes of a divided highway into one, incorrectly marking an adjacent road as being a lane in that divided highway) that fixing the OSM data would be incredibly difficult.
How is that doing more with the data?
POIs are not in the TIGER dataset.
Also, OSM has done NOTHING with that dataset. They did a straight import that appears to have tried to cleanup/simplify maps and in the process broke them.
For example:
Lake Street in Owego, NY, USA is a one-way street. TeleAtlas and NavTeq know this, OSM does not (as the source data set does not contain turn restrictions data)
The OSM importer seems to have taken NY State Route 17 and turned it into single lane of a divided highway. NY State Route 434 (which parallels 17) is shown as the "paired" lane to 17. This is WRONG. NYS 17 has two one-way subroads (divided highway), and 434 is a standard two-way road. OSM shows these three strips of pavement as two with completely bogus directionality info. The autoimporter clearly guessed at what the direction restrictions here should have been, and guessed blatantly wrong.
It's a proper GPS. The A-GPS application in this case is not the "classic" tower-based A-GPS, but is what is often refered to as "QuickFix" or "HotFix" or "InstantFix" depending on manufacturer.
The idea is that even with a good signal, satellite ephemerides take a minimum of 30 seconds to download from a GPS satellite. Even with good pseudorange data, without ephemerides a satellite is unusable for a navigation fix.
Most of the current "A-GPS" approaches involve preloading approximately a weeks' worth of ephemerides into a receiver, so that a position fix can be obtained as soon as pseudorange data becomes available.
Huge difference from the original meaning of Assisted GPS, where the handset collected pseudorange data and passed it to the tower for E911 purposes. This was needed back when handsets didn't have much CPU power. Nowadays basically any handset has enough CPU to calculate a position fix on its own.
Most newer ones do support SDHC cards.
I know the DealExtreme ones do.
While the TomTom units run Linux, all of the "useful" functions are in the highly proprietary NavCore application. Despite being Linux-based, they're not really "hackable". There are some hacks, but they still depend on cooperation with NavCore.
The Windows CE devices tend to be quite hackable, such as the 4.3" and 5" WinCE + SiRF Atlas-III devices at dealextreme.com. I have one such unit on order and am looking forward to receiving it.
In general, there are few open source mapping applications for portable devices, and not a single one that I know of that does turn-by-turn due to lack of turn restriction data in publically available data sets. For example, any of the "open source" street datasets in the United States are descended from the US Census Bureau TIGER dataset. This dataset does not (or at least did not, as of 2005-2006) contain any turn restriction data, e.g. one way roads and intersections that don't allow certain types of turns. The end result is that any attempt to do routing with these datasets will have odd results (namely, high chance of illegal turns and going the wrong way on a one way road.)
Two lengths of Cat 5 is probably cheaper than one of Cat 3 and one of Cat 6, plus it's guaranteed to get the job done even if the cat has an extra life.
"Google wants to see reference specs that include options for bare motherboards to slide right into your basic 42 unit rack with IO, disk and power all pulled out to the raw basics so Google can decide how to manage the bits rather than having stock OEM boards with such limited options."
Sounds a lot like a VME backplane...
One thing I wonder:
Many of the new CPUs DO have huge performance gains when running multimedia applications (video encoding/decoding, and especially 3D gaming).
Maybe they just aren't as good for Facebook's systems, which probably don't do much floating point, if at all. Similarly, almost nothing FB does (except for possibly resizing images when they are uploaded by users) can take advantage of SIMD instructions such as SSE4 (which delivered huge performance gains for some relatively common desktop multimedia apps but isn't going to help an HTTP server or database server.)
Looks like it is not where the serious barebone laptop builder does their shopping.
Not a single one of the three "barebones" notebooks Newegg offers is something I would base a system on. All have either Intel integrated graphics or ATI graphics, no NVidia-based options. Every time I've dealt with ATI's drivers (last was on my ex's Dell Inspiron 600M) it's been a nightmare.
TFA is now Slashdotted, so:
Does he cover the sterility issue with algae? Based on the literature I've read so far, one of the primary challenges with algae-based biofuels is that the algae species that are good for biofuel production are at a competitive disadvantage to other algae species that basically suck for the purposes of biofuel production.
Thus it's really easy for a bioreactor to get contaminated and stop producing anything useful.
"and somewhat more exotic approaches(like bubbling the stuff through algae farms) aren't too far outside the realm of the currently possible."
That's an interesting observation. As I understand what I've read so far, one of the biggest challenges to large-scale algae farming has been keeping the medium sterile. The most efficient species at generating biodiesel are NOT the dominant ones if other algae species or organisms enter. As a result, most pilot projects have been using power plant exhaust directly, as it is fundamentally sterile by nature of the fact that it had recently been superheated.
One would assume that these "synthetic trees" would produce pure sterile CO2, which might allow these algae farms to be located separately from power plants.
In addition to my other comment -
Actually, after reading back up a bit:
You say it's been demonstrated in a number of posts but don't provide a link. Please link to the complete results and procedure for the experiment.
It would stop sublimating into gas (fizzing and producing bubbles), but did they demonstrate that a year later the dry ice was still there?
It might not be producing bubbles, but might slowly transition to dissolved gas in the water.
Either the firewall I'm behind doesn't like HWB, or the storm has moved there too.
RAW support?
Probably not out of the box.
CHDK + one of the PowerShot A series is probably your best bet.
RAW without manual controls is not the most ideal combination, so except for the SD990 + CHDK, the Elphs are out. The SD990 is above your budget range.
Unless you go used, maybe a G9?
Yeah. http://en.wikipedia.org/wiki/Velvia pretty much credits Velvia, not digital, with the death of Kodachrome.
While digital is doing a pretty good job displacing film for the majority of 35mm photography and below, the barriers to entry for medium format digital are so high that film is still going strong there.
And LF digital? Forget it for a LONG time...