In many areas of the USA, the data is abysmal because TIGER is flawed in some areas, plus the OSM importer made some bad assumptions about whether roads are one-way or not during the TIGER import.
Unfortunately, it's a lot easier to put in correct road data manually from scratch than it is to correct a botched TIGER import - I gave up on trying to fix the highway in my area.
Yeah. In terms of safety, Chernobyl is like taking a Yugo, removing the swaybar, clipping the emergency brake cable, severing the brake hydraulic lines, removing shock absorbers, installing racing slicks, and going for a joyride in the snow. (Disclaimer - Yugos might not have some of those items in the first place, but hopefully you get the idea.)
TMI would be like taking an old Dodge Aries out for a drive.
Modern nuclear plants would be like driving an AWD vehicle with ABS and stability control.
Problem is, in the business world a Ph. D. can potentially be at a disadvantage for hiring.
Businesses see it as "Ph. D. is more expensive than an M.S. but an M.S. can do the work." for the majority of jobs.
Also, someone evaluating candidates for hire is probably also thinking, "Ph. D. and M.S. are equally disadvantaged by simply being new to the company." At any given company, it takes a lot of time to learn the local process, lingo, and the product/program you're working on.
By getting a Ph. D. you open up access to a very small job pool (those that only a Ph. D. could do), but in the process close off access to a MUCH larger one (nearly all of those positions that can be performed by someone with an M.S.)
I am an RF engineer and it is realistic, BUT extremely difficult. Not, IMO, realistic for a hobbyist, even a sophisticated one.
Note that with proper postprocessing and lots of measurements, the GPS system can achieve accuracy close to this ("close" being a single order of magnitude at around 1 cm), and that's on a global scale. With precisely positioned antennas, you can probably do 1mm accuracy over short ranges.
BUT: 1) You're going to need millimeter-precision manufacturing AND positioning of all antennas. Barely within the range of a sophisticated hobbyist. 2) You're going to need some pretty decent signal processing to resolve wavelength integer ambiguities (the same reason achieving centimeter-accuracy GPS requires 1-2 hours of continuous data from a static reference and lots of processing typically.) 3) Multipath is going to kick your ass accuracy-wise anywhere outside of an RF anechoic chamber. Even in an anechoic chamber, you have to deal with multipath and antenna pattern distortion issues due to the subject whose motion you're trying to capture.
If he were making the same claims for an ultrasonic-based system it would be a lot more believable.
When I posted that, I completely forgot one important fact:
On netbooks at least, the chipset and not the CPU consumes the bulk of the power. Something like 2.5W TDP for an Atom at full tilt and 22W TDP for the chipset (11W or so for new 945GSE chipsets like in the 1000HE). So running the CPU full tilt doesn't hurt you much at all.
I was able to encode to standard definition H.264 video + AAC audio and get 6+ hours of battery life on playback with my 1000HE. The key being: 1) Dim the display 2) Downclock the FSB to drop that chipset power consumption - even when underclocked, the CPU can handle SD H.264 in most cases (not all).
By definition, if it isn't a Nehalem die, it's not Nehalem, even if it's just a "tock" variant (die shrunk - see Intel's "tick/tock" roadmap) of Nehalem it's still a different chip design.
In this case, the CPU has significant design differences from a Nehalem CPU. There's a lot more than just removing some pins from the package. The CPU had to be changed significantly (one DDR channel removed, QPI replaced with DMI) in order to allow those pins to be removed.
The removal of QPI in favor of DMI (much slower but simpler/cheaper) is a *significant* difference.
Depending on your video chipset, you might trade off optical drive power for CPU power usage if you use Handbrake. Some vid chipsets accelerate MPEG-2 very efficiently but not MPEG-4 ASP or AVC.
Is it one of the new "Super Hybrid Engine" Eees like the 1000HE?
You need to figure out how to underclock your FSB - that's really all that Super Hybrid Engine does on XP. Ubuntu's power management doesn't touch the FSB by default.
I haven't gotten around to doing this on my 1000HE yet.
There are very few modern models where battery life is given as different from XP. In those cases the difference is rather small (not like what the article poster is experiencing). In at least one of those cases, the Linux hardware configuration is different than the XP hardware configuration. (Different flash drive size, there may be other changes such as a different WLAN card. For example, the Dells that have Ubuntu preinstalled have a different hardware configuration than non-Ubuntu Dells of the exact same model number.)
For example: 1101HA is given as being available with either XP or Linux. Only two battery life numbers are given, one for each possible battery configuration.
The 1002H is XP-only and seems to be one of the worst performers in the 10" class (5 hours)
In my experience, the most common causes of lower battery life under Linux: NVidia chipsets. The power management in their driver is one of their lowest priorities. If you want games, you're going to have to sacrifice battery life. Sometimes the "ondemand" cpu speed governor can be a little flaky and step to high speed way too quickly.
Keep in mind that's Asus's own Linux distro which most people regard as not being that hot. It may be missing some power tweaks available to other users. With the exception of Nvidia-graphics based laptops, I've usually been able to get much better real-world battery life on a machine with Linux than Windows. (Exception being that I haven't gotten FSB clock changing working on the Ubuntu partition of my Eee 1000HE yet - downclocking the FSB is the core component of Asus's "Super Hybrid Engine" power management scheme.)
Knowing Verizon: That "Crazy shit" you speak of will be 6-9 months behind when other carriers release similar phones.
In the case of phones that Sprint also releases, the Verizon version will be crippled significantly compared to the Sprint one in addition to being behind schedule due to "network certification issues". (Translation - "we're not done crippling it yet")
See: Palm Treo 650 (Bluetooth DUN crippled on Verizon version, and was 9 months after Sprint) Verizon XV6800 (An HTC device, had a diff name on Sprint - PPC-6800 maybe?) - 6+ months behind on Verizon compared to sprint for "network certification issues". I don't know what they crippled, after seeing that phrase I went to AT&T because my VZW contract was up. By the time the 6800 was released by Verizon, AT&T released the Tilt (aka HTC TyTn II) which was a generation ahead.
"Actually, T-Mobile G1 has free roaming on the AT&T"
False. T-Mo's AT&T roaming agreement breaks frequently and for months at a time.
For 2-3 months my ex had a T-Mo phone that in theory roamed for free on AT&T.
In reality, it would lose coverage once she passed exit 67 or so on NY State Route 17. No coverage whatsoever anywhere west of that, while my AT&T phone worked perfectly.
As an experiment I once put her T-Mo SIM into my unlocked AT&T phone (AT&T Tilt). It didn't work, and even after putting my SIM back in, my phone's IMEI was blacklisted by the tower for 15-20 minutes - no coverage even with my AT&T SIM for that period!
When you need to make serious power, tubes are still the way to go. Transistors have a significant reliability benefit.
Also, for 99% of applications, transistors are better. For the other 1%, you have very application-specific tube designs such as TWTs and magnetrons, which rearrange the tubes in such a manner as to negate its usual disadvantage (large size USUALLY translates to nasty frequency limits - TWTs and magnetrons are exceptions that use various Neat Tricks to allow microwave operation from a large device.)
BTW, one of the other common microwave tubes (magnetrons), while it is a "niche" device, it is a VERY widely deployed niche - basically all microwave ovens use magnetron tubes.
No, the compression ratio contributes little to engine braking. Yes, you have to compress the air in the cylinders, but then the piston moves back down, so the net work is very little.
The primary mechanism behind engine braking is the fact that gasoline engines have a throttle plate that restricts air into the engine (since running lean will damage a gasoline engine typically - the direct injection used by diesel engines lets them just throttle by adjusting fuel w/o adjusting air.). When this plate is closed, the engine has to work against the vacuum in the intake manifold (but the exhaust still has atmospheric backpressure at the very least). This leads to pumping losses that increase with engine speed. These losses are why gasoline engines are so inefficient when not at full power.
Diesels don't have these pumping losses so are more efficient at partial power and won't engine brake well unless the exhaust or intake is artificially restricted, or valve timing is altered.
Actually, it's just the opposite - due to the fact that they throttle simply by adjusting fuel supply to the cylinders and typically do not have a throttle plate, diesel engines are FAR more efficient at reduced power levels than gasoline engines are.
As a result, one of the two main hybrid advantages (running the engine at peak efficiency) is negated. On the other hand, due to the high compression ratio, diesels are simply more efficient.
The other big hybrid advantage (regenerative braking) is still quite applicable to diesel, and in fact may be far easier to apply to diesels than to gasoline, since "ghetto hybrid" approaches like belt alternator-starter and flywheel alternator-starter can still provide great benefit. (Downshift to rev the engine and get the electric to spin - in a gas engine this will result in engine braking. Diesels don't, and in fact can't without special tricks, engine brake, so having an electric generator tied directly to the engine would still be quite effective.)
US emissions restrictions are different from Europe. Not necessarily stricter, but different.
As I understand it, US emissions regulations are very strict about particulates and NOx emissions (both drawbacks for diesel. Particulates is easy to solve and has been solved, NOx is much harder.)
Euro emissions regulations are very strict about unburned hydrocarbons IIRC, which is good for diesel but bad for gasoline. They are far less strict about NOx.
If done right, almost any FPS should be portable from console to PC, and be FAR better on PC. (Mouse + keyboard is a superior control mechanism for FPS games.)
Most RPGs aren't too bad either, especially if you plug in a joypad to the PC.
Of course, frequently ports are NOT done right - the PC port of Final Fantasy VII is a notorious example of a port being done so lazily as to break compatibility very rapidly within about a generation of hardware releases. Nowadays it's often easier to get the PSX version running in an emulator than to get the PC port working.
Pretty much the way they do it where I work. Machine's network names are their serial number/asset tag. Identification of system owner is what the asset management system is for.
I've never seen BIOS features password-protected from the factory. I have seen it FREQUENTLY done with corporate laptops (for example, the T42s I have for network testing have WLAN cards in them, but have been disabled in password-protected BIOS sections.)
Until Windows 7, 90%+ of consumers had no reason to use VT extensions, and for those, VT was only a potential security hole. Hence disabling by default made sense until very recently.
Eventually, software becomes complex enough that a bug won't get exposed except by random bad luck.
I recall dealing with an Ethernet driver that had a very low-level (I'm talking "need to fully understand the datasheet for the MAC to understand the bug" low-level) bug that would cause the whole driver to freeze.
In normal usage, it would fail only once every week or two, and the conditions leading to failure were effectively random.
Eventually a test case was produced that could induce failure within 15-30 seconds, but still "random" within that period. Even slight tweaks to said test case would drop the probability of failure significantly.
If you check the link associated with the submitter's username, it will quickly lead to a Fedora-hosted project that seems actively maintained, although last maintenance was 6/26 - author could be on vacation.
I think that's the modified version there, which references the original version on its SF page.
Based on http://git.fedorahosted.org/git/pam_krb5.git/ it was last updated 6/26. Article poster doesn't give too much detail of the timeline, i.e. how long the original developer was unresponsive.
It took very little Googling to find that the maintainer of pam_krb5 is an active Twitter user, among other things. Either the OP didn't even remotely try to get in touch with him, the original maintainer is on vacation, or there's more to this story such as the OP's patch being something that really can't be merged into the primary repository cleanly.
Slashdot Mirror
In many areas of the USA, the data is abysmal because TIGER is flawed in some areas, plus the OSM importer made some bad assumptions about whether roads are one-way or not during the TIGER import.
Unfortunately, it's a lot easier to put in correct road data manually from scratch than it is to correct a botched TIGER import - I gave up on trying to fix the highway in my area.
For the same reason they use the el-cheapo GPS?
Yeah. In terms of safety, Chernobyl is like taking a Yugo, removing the swaybar, clipping the emergency brake cable, severing the brake hydraulic lines, removing shock absorbers, installing racing slicks, and going for a joyride in the snow. (Disclaimer - Yugos might not have some of those items in the first place, but hopefully you get the idea.)
TMI would be like taking an old Dodge Aries out for a drive.
Modern nuclear plants would be like driving an AWD vehicle with ABS and stability control.
Problem is, in the business world a Ph. D. can potentially be at a disadvantage for hiring.
Businesses see it as "Ph. D. is more expensive than an M.S. but an M.S. can do the work." for the majority of jobs.
Also, someone evaluating candidates for hire is probably also thinking, "Ph. D. and M.S. are equally disadvantaged by simply being new to the company." At any given company, it takes a lot of time to learn the local process, lingo, and the product/program you're working on.
By getting a Ph. D. you open up access to a very small job pool (those that only a Ph. D. could do), but in the process close off access to a MUCH larger one (nearly all of those positions that can be performed by someone with an M.S.)
I am an RF engineer and it is realistic, BUT extremely difficult. Not, IMO, realistic for a hobbyist, even a sophisticated one.
Note that with proper postprocessing and lots of measurements, the GPS system can achieve accuracy close to this ("close" being a single order of magnitude at around 1 cm), and that's on a global scale. With precisely positioned antennas, you can probably do 1mm accuracy over short ranges.
BUT:
1) You're going to need millimeter-precision manufacturing AND positioning of all antennas. Barely within the range of a sophisticated hobbyist.
2) You're going to need some pretty decent signal processing to resolve wavelength integer ambiguities (the same reason achieving centimeter-accuracy GPS requires 1-2 hours of continuous data from a static reference and lots of processing typically.)
3) Multipath is going to kick your ass accuracy-wise anywhere outside of an RF anechoic chamber. Even in an anechoic chamber, you have to deal with multipath and antenna pattern distortion issues due to the subject whose motion you're trying to capture.
If he were making the same claims for an ultrasonic-based system it would be a lot more believable.
I found the solution prior to vacation. I believe it was eee_control - http://greg.geekmind.org/eee-control/
(I can't check the website at my current location for various reasons as it's "uncategorized".)
When I posted that, I completely forgot one important fact:
On netbooks at least, the chipset and not the CPU consumes the bulk of the power. Something like 2.5W TDP for an Atom at full tilt and 22W TDP for the chipset (11W or so for new 945GSE chipsets like in the 1000HE). So running the CPU full tilt doesn't hurt you much at all.
I was able to encode to standard definition H.264 video + AAC audio and get 6+ hours of battery life on playback with my 1000HE. The key being:
1) Dim the display
2) Downclock the FSB to drop that chipset power consumption - even when underclocked, the CPU can handle SD H.264 in most cases (not all).
By definition, if it isn't a Nehalem die, it's not Nehalem, even if it's just a "tock" variant (die shrunk - see Intel's "tick/tock" roadmap) of Nehalem it's still a different chip design.
In this case, the CPU has significant design differences from a Nehalem CPU. There's a lot more than just removing some pins from the package. The CPU had to be changed significantly (one DDR channel removed, QPI replaced with DMI) in order to allow those pins to be removed.
The removal of QPI in favor of DMI (much slower but simpler/cheaper) is a *significant* difference.
Handbrake can't do a straight VOB rip.
Depending on your video chipset, you might trade off optical drive power for CPU power usage if you use Handbrake. Some vid chipsets accelerate MPEG-2 very efficiently but not MPEG-4 ASP or AVC.
Is it one of the new "Super Hybrid Engine" Eees like the 1000HE?
You need to figure out how to underclock your FSB - that's really all that Super Hybrid Engine does on XP. Ubuntu's power management doesn't touch the FSB by default.
I haven't gotten around to doing this on my 1000HE yet.
There are very few modern models where battery life is given as different from XP. In those cases the difference is rather small (not like what the article poster is experiencing). In at least one of those cases, the Linux hardware configuration is different than the XP hardware configuration. (Different flash drive size, there may be other changes such as a different WLAN card. For example, the Dells that have Ubuntu preinstalled have a different hardware configuration than non-Ubuntu Dells of the exact same model number.)
For example:
1101HA is given as being available with either XP or Linux. Only two battery life numbers are given, one for each possible battery configuration.
The 1002H is XP-only and seems to be one of the worst performers in the 10" class (5 hours)
In my experience, the most common causes of lower battery life under Linux:
NVidia chipsets. The power management in their driver is one of their lowest priorities. If you want games, you're going to have to sacrifice battery life.
Sometimes the "ondemand" cpu speed governor can be a little flaky and step to high speed way too quickly.
Keep in mind that's Asus's own Linux distro which most people regard as not being that hot. It may be missing some power tweaks available to other users. With the exception of Nvidia-graphics based laptops, I've usually been able to get much better real-world battery life on a machine with Linux than Windows. (Exception being that I haven't gotten FSB clock changing working on the Ubuntu partition of my Eee 1000HE yet - downclocking the FSB is the core component of Asus's "Super Hybrid Engine" power management scheme.)
Knowing Verizon:
That "Crazy shit" you speak of will be 6-9 months behind when other carriers release similar phones.
In the case of phones that Sprint also releases, the Verizon version will be crippled significantly compared to the Sprint one in addition to being behind schedule due to "network certification issues". (Translation - "we're not done crippling it yet")
See:
Palm Treo 650 (Bluetooth DUN crippled on Verizon version, and was 9 months after Sprint)
Verizon XV6800 (An HTC device, had a diff name on Sprint - PPC-6800 maybe?) - 6+ months behind on Verizon compared to sprint for "network certification issues". I don't know what they crippled, after seeing that phrase I went to AT&T because my VZW contract was up. By the time the 6800 was released by Verizon, AT&T released the Tilt (aka HTC TyTn II) which was a generation ahead.
"Actually, T-Mobile G1 has free roaming on the AT&T"
False. T-Mo's AT&T roaming agreement breaks frequently and for months at a time.
For 2-3 months my ex had a T-Mo phone that in theory roamed for free on AT&T.
In reality, it would lose coverage once she passed exit 67 or so on NY State Route 17. No coverage whatsoever anywhere west of that, while my AT&T phone worked perfectly.
As an experiment I once put her T-Mo SIM into my unlocked AT&T phone (AT&T Tilt). It didn't work, and even after putting my SIM back in, my phone's IMEI was blacklisted by the tower for 15-20 minutes - no coverage even with my AT&T SIM for that period!
When you need to make serious power, tubes are still the way to go. Transistors have a significant reliability benefit.
Also, for 99% of applications, transistors are better. For the other 1%, you have very application-specific tube designs such as TWTs and magnetrons, which rearrange the tubes in such a manner as to negate its usual disadvantage (large size USUALLY translates to nasty frequency limits - TWTs and magnetrons are exceptions that use various Neat Tricks to allow microwave operation from a large device.)
BTW, one of the other common microwave tubes (magnetrons), while it is a "niche" device, it is a VERY widely deployed niche - basically all microwave ovens use magnetron tubes.
No, the compression ratio contributes little to engine braking. Yes, you have to compress the air in the cylinders, but then the piston moves back down, so the net work is very little.
The primary mechanism behind engine braking is the fact that gasoline engines have a throttle plate that restricts air into the engine (since running lean will damage a gasoline engine typically - the direct injection used by diesel engines lets them just throttle by adjusting fuel w/o adjusting air.). When this plate is closed, the engine has to work against the vacuum in the intake manifold (but the exhaust still has atmospheric backpressure at the very least). This leads to pumping losses that increase with engine speed. These losses are why gasoline engines are so inefficient when not at full power.
Diesels don't have these pumping losses so are more efficient at partial power and won't engine brake well unless the exhaust or intake is artificially restricted, or valve timing is altered.
http://en.wikipedia.org/wiki/Jake_brake - alters valve timing to achieve engine braking
http://en.wikipedia.org/wiki/Exhaust_brake - restricts exhaust
No.
You, my friend, haven't been in a major battle in EVE if the node lasted for 30 minutes before crashing...
Based on the description, it sounds like they took the Insight drivetrain (proper hybrid) and replaced the gasoline engine with a diesel engine.
Actually, it's just the opposite - due to the fact that they throttle simply by adjusting fuel supply to the cylinders and typically do not have a throttle plate, diesel engines are FAR more efficient at reduced power levels than gasoline engines are.
As a result, one of the two main hybrid advantages (running the engine at peak efficiency) is negated. On the other hand, due to the high compression ratio, diesels are simply more efficient.
The other big hybrid advantage (regenerative braking) is still quite applicable to diesel, and in fact may be far easier to apply to diesels than to gasoline, since "ghetto hybrid" approaches like belt alternator-starter and flywheel alternator-starter can still provide great benefit. (Downshift to rev the engine and get the electric to spin - in a gas engine this will result in engine braking. Diesels don't, and in fact can't without special tricks, engine brake, so having an electric generator tied directly to the engine would still be quite effective.)
The main reason is the EPA.
US emissions restrictions are different from Europe. Not necessarily stricter, but different.
As I understand it, US emissions regulations are very strict about particulates and NOx emissions (both drawbacks for diesel. Particulates is easy to solve and has been solved, NOx is much harder.)
Euro emissions regulations are very strict about unburned hydrocarbons IIRC, which is good for diesel but bad for gasoline. They are far less strict about NOx.
If done right, almost any FPS should be portable from console to PC, and be FAR better on PC. (Mouse + keyboard is a superior control mechanism for FPS games.)
Most RPGs aren't too bad either, especially if you plug in a joypad to the PC.
Of course, frequently ports are NOT done right - the PC port of Final Fantasy VII is a notorious example of a port being done so lazily as to break compatibility very rapidly within about a generation of hardware releases. Nowadays it's often easier to get the PSX version running in an emulator than to get the PC port working.
Pretty much the way they do it where I work. Machine's network names are their serial number/asset tag. Identification of system owner is what the asset management system is for.
I've never seen BIOS features password-protected from the factory. I have seen it FREQUENTLY done with corporate laptops (for example, the T42s I have for network testing have WLAN cards in them, but have been disabled in password-protected BIOS sections.)
Until Windows 7, 90%+ of consumers had no reason to use VT extensions, and for those, VT was only a potential security hole. Hence disabling by default made sense until very recently.
Eventually, software becomes complex enough that a bug won't get exposed except by random bad luck.
I recall dealing with an Ethernet driver that had a very low-level (I'm talking "need to fully understand the datasheet for the MAC to understand the bug" low-level) bug that would cause the whole driver to freeze.
In normal usage, it would fail only once every week or two, and the conditions leading to failure were effectively random.
Eventually a test case was produced that could induce failure within 15-30 seconds, but still "random" within that period. Even slight tweaks to said test case would drop the probability of failure significantly.
If you check the link associated with the submitter's username, it will quickly lead to a Fedora-hosted project that seems actively maintained, although last maintenance was 6/26 - author could be on vacation.
I think that's the modified version there, which references the original version on its SF page.
Based on http://git.fedorahosted.org/git/pam_krb5.git/ it was last updated 6/26. Article poster doesn't give too much detail of the timeline, i.e. how long the original developer was unresponsive.
It took very little Googling to find that the maintainer of pam_krb5 is an active Twitter user, among other things. Either the OP didn't even remotely try to get in touch with him, the original maintainer is on vacation, or there's more to this story such as the OP's patch being something that really can't be merged into the primary repository cleanly.