Try 1 or 11 instead. 7 is only 5mhz offset from 6. You're still sharing 77% of the spectrum with your neighbor and killing about 10% of anyone nearby who may be trying to use channel 11.
(Actually, pathological layouts probably exist to make a 1/4/7/11 plan better, but by far most layouts are adequately served with 1/6/11...), but this is infeasible. So sometimes, having control over only your own AP, channel 3/4 or 8/9 is really the best you can do.
1/4/7/11 still have some fringe overlap for edge sub-channels (especially between 1 and 4), don't expect full speed w/ lots of neighbors.
Using 3/4 or 8/9 may help your problem (or at least afford you some lower data rates), but in an apartment complex or other high-density independent deployment, it only contributes to the overall problem, making channel dodging that much more difficult.
This argument is akin to an approx 71.5 foot (mhz) wide freeway with with 3 twenty-five foot wide lanes (1/6/11@22mhz wide + 2.75mhz spacing between 1/6 and 6/11). By design, you're driving your hypothetically 22 ft wide car down the center of the lane. There's up to 1.4 ft on each side in the center lane between you and the lane edge.
You can try to drive between lanes, but you're still going to "interfere" with traffic nearby. Condensing the lanes into four now creates significant overlap between traffic (approx 10-25%).
Now in reality, an OFDM (802.11a/g) wireless signal is made up of 48 sub-channels equally spaced across its 22mhz "channel". Instead of completely wiping out your signal, some of your sub-channels would be interference-prone, effectively reducing your data-rate. So, you can choose channels besides 1/6/11 (or 1,5,9,13 in the EU), but you must understand the consequences to yourself and your neighbors.
Or just go 802.11a/n on 5ghz and call it a day. 2.4gz is becoming far too crowded in highly dense deployments anyway.
Typical AP power is closer to 50-75mW (17-19dBm) - only low power WiFi sharing devices like MiFi would be as low as 20mW. Also worth remembering that your NIC will typically transmit back at a similar power if able.
Try changing the channel in your wireless router. Most set to channel 6 by default.
Remember, when choosing a channel, only 1, 6, and 11 are non-overlapping with each other - anything in between steps on the channel space of 1 and 6, or 6 and 11. Also, many (but not all) microwaves will impact the channel space between 6 and 11+, generally making 1 a better choice.
Try doing a "survey" using your wireless driver's built-in tools (most Broadcom adapters have some sort of rudimentary tool - Intel should as well). Even just a list of nearest neighbors will help you identify what channels are nearby and at what strengths. Out of 1, 6, or 11, pick something that is within the least occupied space (least number of APs or weakest AP). If your nearest neighbors are using 1 and 6, and another particularly ignorant/rude neighbor is using 3, your only real choice is 11. Now if it's 1, 6, and 9, you're kinda hosed, and you'll have to hope the channel 1 AP is furthest away because the guy using 9 is impacting 1 and 6 (just as the guy using 3 is impacting 1 and 6).
Google search turns up tons of results, but hopefully this paints a reasonable picture:
Unfortunately your NIC doesn't do 802.11a/n - otherwise I'd suggest looking into a dual-band 802.11n router. Tons of non-overlapping channels to pick from, but the range won't be quite as good (and you'll still have to steer clear of the 5.8ghz cordless phones).
If it's really bad, have your neighbors help pitch in for a WiSpy 2.4x (~$200) which could be used to pin-point the culprit. When you're done, sell it on eBay to recoup most of the cost. Probably cheaper than having a wireless survey team coming "onsite" to validate w/ their pricey Cisco Spectrum Expert device. They'd be able to tell pretty quickly if you're dealing w/ someone who loves their microwave popcorn, a wireless video streaming device, some sort of Zigbee (though those are usually pretty low power compared to Wi-Fi and narrow-band in comparison), frequency hopping device (cordless phone, etc).
One of the great features of TrueCrypt is the whole alternate partition/segment idea. One password gives access to real data, while another (a duress password) would give some other access to an alternate segment. Put some benign documents in the alternate partition, and then under threat of water boarding, hand out the duress password. Assuming this all works, they find nothing, you go home.
Granted, I'm not encouraging this idea for criminal activity, but rather for truly sensitive data that shouldn't fall into the wrong hands.
A curious question, that. You're asking what it is worth to the user of a site to justify the demands placed upon the operator of the site. You pose it as "demands upon the server", yet simply visiting a site creates demands upon the server. More people, more demands.
How is asking for HTTPS different from asking for "reasonable page load times", or "video feeds without compression artifacts"? On the user's side, one has little to no influence over (or even knowledge of) OTHER traffic to the site. The answer for the user is, "MY demand on the server is small, what's the problem?".
The only answers on the operator's side are "I want your traffic", or "I don't want your traffic".
The loads on the web server are a bit higher for HTTPS encryption than just passing fat content created by a developer without any common sense of bandwidth consumption.
Now if you're referring to server-side generated content contributing to page load times, then HTTPS isn't helping that provided the same server that is generating is the one doing the encryption.
1. For classic shared hosting solutions using name based hosting, I can almost guarantee if you hit https:///, you're going to hit someone else's virtual host. Many cheap hosting providers w/ limited public IPs will load up domain names on a single IP/Port, but still provide secure hosting to one domain name (on the same port) for shopping cart checkout under a different domain name. Using such a plugin in this use case would not work so well. Then again, would most "smaller sites" really be worthy of encryption in the first place?
2. Not every site is designed w/ the same content root in http vs https. Switching from http to https may completely break if the file structures under the two virtual hosts (potentially entirely separate in Apache) aren't identical (i.e. pointing to the same directory). I'm not touting that this is a best practice, but would be completely feasable if you wanted to keep specific content from being accessed via http and didn't want to bother with mod_rewrite or equivalent.
To the poster above who says there's little CPU penalty for SSL, SSL may not be taxing on the client, but hundreds or thousands of sessions on a server (especially one hosting an app, DB, and Apache) may be another story. Why is someone's assumed paranoid that someone will see that they're reading about cars or home theater equipment on a forum worth requiring a service owner to scale his hardware to the next level to maintain acceptable performance (assuming this phenomenon is multiplied hundred-fold)?
Exactly what I run at home, in RAID-1 configuration. It's very quiet, and could be stashed in a closet provided the ventilation was reasonable. DNS-323 runs quiet, is fairly low power, still offers GigE, and combined w/ WD green drives, runs reasonably cool and quiet. Set it to sleep after 15 minutes and noise/heat are almost non-existent when not in use.
That being said, for the OP, even with JBOD and 2TB drives (4TB raw max), they could easily run out of space unless they were running several of these in parallel. There comes a point when this simply won't scale (try to remember which NAS you stored your file on?), or noise and heat will become apparent.
My Mitsubishi DLP TV (WD65734) uses a 6-color wheel, adding yellow, magenta and cyan sub-primaries to the typical RGB + clear. Granted, Sharp's addition of Yellow is a first for LCD TVs, but it's old hat for some DLP engined systems.
This addition is supposed to create "truer" color rendition.
Some random thoughts - I'm a Systems Admin/Engineer by trade, but have spent some time in the Manager's chair as well. Here's some thoughts that would have helped me for my first real job (i.e. why didn't someone tell me):
Don't act like a know-it-all, but don't be afraid to offer a concise answer if solicited. Us nerds tend to LOVE to elaborate to "make an impression". The only impression is "Thanks, now how do I shut this guy up?".
Don't be afraid to challenge your peers when your approach may be better, but know when to back down when you're out-numbered.
In a cubical farm, your voice or other odd noises carry much further than you think. Same applies for the office restroom.
Speakerphone is a privilege reserved those with an office and a closed door. (Ab)using speakerphone (esp. loudly) in a cubicle will earn many more enemies than friends. Consider a headset if you're going to be on the phone a lot and need to type or do other things with your hands.
Learn and understand your company's core values. Chances are, you hold some of these yourself or you wouldn't have been hired (at least by any competent manager). These values will help guide your management team's decisions, just in case you question their motives.
If you lied on your interview, you'll be quickly found out the moment you submit your first program. If it's a serious lie that you can't lie your way out of again, don't even bother showing up for your first day.
Learn how to comment your code, but don't do it so much that stripping them out strips 75% of the file.
Use sane variables that someone else can maintain. "a, b, foo and bar" are not sane.
Be willing to learn - always. This may involve learning OUTSIDE of your job as well.
You will be required to understand the business to a degree that helps you develop useful code. Don't be surprised if your first few weeks on the job involve training that seems initially pointless (stocking shelves, packing boxes, etc.). It will all make sense in the end, and may even help start the creative flow of "I could do that better".
Innovate or get out of the way. Complacency often gets you fired.
For some companies, continuous improvement is expected. For others, they prefer the tried and true. Don't be afraid to ride the middle if you aren't sure which one you're dealing with at first. Someone will set you straight.
Make sure your line of communication with your manager is wide open. Understand his/her expectations and deliver on what's asked. However, if the expectations are completely unreasonable, have a backbone and ensure they know why you can't rewrite Linux in a day.
This is hard at first, but employees who perform well need little management. Those who don't can expect constant management. Then again, some managers like to micro-manage anyway, especially their under-performers.
There's nothing worse than a hotel that provides "free access", but it's been installed by a bunch of ameteurs. I've seen one or more of the followng:
AP placement is all wrong (no survey, just hap-hazardly placed) which leads to poor coverage in some rooms
There's no roaming configured, each AP has it's own SSID). This makes choosing the best AP for the room less than ideal for users who don't have decent wireless suites that display stronger and weaker SSIDs
APs are set to non-standard channels (i.e. 3, 9, 7, etc.) because the installer thinks they're completely unique or isolated (only 1, 6, and 11 are truly usable w/o overlap)
The installation is very prone to interference (i.e. extended stay hotel full of microwave ovens). This makes access SUPER slow or causes connections to drop completely.
Hotspot Captive portal is misconfigured requiring re-authorization every 2 hours - this is extremely disruptive to VPN connections.
Even when free, it's times like this that I'll break out the 3G card. When it's really bad, though is when the 3G card connects at 1.5 or 2G speeds (way out in the middle of nowhere).
So was I - the amount of internal theft way before things hit retail shelves at some companies is astounding. Equally so is the ways these thieves attempt to get things out the door (in body parts, lunch boxes, inside laptop DVD-ROM drives, through the garbage, etc.).
For those who work in an electronics store (or it's distribution centers), this will be a loss prevention nightmare for your tiny chips (like MicroSD).
"Oh, just a wad of change? No problem sir! Go on ahead..."
On the other hand, if I accidentally put it through the Coke machine on the way out of Fry's, I think I'd have what's coming to me.;-)
What a better way to break in some law or pre-law students than to represent this case. Backing down benefits nobody but AIME and future precedent for online coursework.
Best part about a computer lab was being the tech. Whenever a student needed programming or word help, you were the one to respond. Total bonus points if the student was of the opposite sex and you got a phone number in the end. How else is a geek to get laid?
To add to this - even if your plane can burn regular unleaded, it likely (and legally) not straight pump gas from most of your metropolitan fueling stations. Most STCs (supplemental type certificates) that permit burning auto gas in aircraft engines only allow a specific type of auto gas - that which does not contain ethanol as an oxygenate. This is usually only found in areas that don't require "reformulated" fuels for emissions reasons. AOPA has published a procedure to test for ethanol in the fuel that involves intentionally mixing water in a fuel sample to check for absorption.
Ethanol as a fuel additive is more volatile and has the ability to absorb water (unlike straight AvGas), both of which are bad at high altitudes (vapor lock and/or freezing lines are both really bad in-flight).
That being said, Lycoming is already working on certifying most of their lower compression O-360 and IO-360 engines to run on non-oxygenated premium unleaded auto gas in response to rising fuel costs and the ultimate demise of 100LL.
...This is why generators last so long but car engines generally don't... Most medium-large generators (i.e. 200kW) also loaf along at 1200 or 1800 RPM. Lower RPM = longevity.
When our local CompUSA was going under last year or so, I found Vista Ultimate Upgrade discounted to $150. I decided to buy it at that point simply to know what I'd be supporting in a year or so. Still running the 64-bit iteration on my primary machine (tri-booting w/ XP Home and FC 9). Other than old hardware driver challenges and a healthy diet for RAM, I have had little other to complain about. If I thought my kids' machine could handle it, I'd probably spend the $50 for the family upgrade there too.
On the flip side, the OEM copy that came on my wife's Dell Inspiron on the other hand has been a ton of trouble. Rebooting instead of sleeping (thanks, SP1) seems to be the biggest issue.
So anecdotally, for applications where Vista was purchased on purpose, users are likely having a better experience than those who received it bundled with hardware!
Speaking of GPS vs. altimeter discrepancy - I've discovered even a WAAS enabled Garmin GPSMap 296 doesn't always agree w/ the airplane's altimeter. Unfortunately, at higher altitudes, the GPS errored several hundred feet on the high side (could possibly steer you into terrain in some cases if you were relying on it to keep you XXX feet above terrain) compared to the plane's altimeter, which was generally set to the nearest airport or whatever ATC provided. On the ground, however, they did agree. I was inclined to believe the altimeter, as the pressure altitude given by the Mode C transponder (which is always set to 29.92, then corrected by ATC to current barometer) was the same when ATC reported my altitude to other aircraft. Fortunately, it's a VFR (i.e. not in the clouds) only GPS (and wasn't mine, but borrowed), so I wouldn't be betting my life on it for terrain avoidance. In reality, it may have been a differing altimeter setting used on both ends that caused that discrepency. W/o a radar altimeter (which only works for a few thousand feet AGL), one will never know.
However, it gave me some "insight" into how GPS may not be 100% accurate for altitude (especially when the altimeter setting may provide different results than true altitude. Compound that with the possibility of a WAAS outage, and radar might seem like a nice alternative.
Since ADS-B is GPS based, I'd hope that ultimately, all planes and ATC agreed on what altitude they're at vs. what they're assigned to. While ADS-B will greatly reduce workload and may improve safety, I'd hate to see it completely supplant radar, even if radar is a backup only.
Slashdot Mirror
Try 1 or 11 instead. 7 is only 5mhz offset from 6. You're still sharing 77% of the spectrum with your neighbor and killing about 10% of anyone nearby who may be trying to use channel 11.
(Actually, pathological layouts probably exist to make a 1/4/7/11 plan better, but by far most layouts are adequately served with 1/6/11...), but this is infeasible. So sometimes, having control over only your own AP, channel 3/4 or 8/9 is really the best you can do.
1/4/7/11 still have some fringe overlap for edge sub-channels (especially between 1 and 4), don't expect full speed w/ lots of neighbors.
Using 3/4 or 8/9 may help your problem (or at least afford you some lower data rates), but in an apartment complex or other high-density independent deployment, it only contributes to the overall problem, making channel dodging that much more difficult.
This argument is akin to an approx 71.5 foot (mhz) wide freeway with with 3 twenty-five foot wide lanes (1/6/11@22mhz wide + 2.75mhz spacing between 1/6 and 6/11). By design, you're driving your hypothetically 22 ft wide car down the center of the lane. There's up to 1.4 ft on each side in the center lane between you and the lane edge.
You can try to drive between lanes, but you're still going to "interfere" with traffic nearby. Condensing the lanes into four now creates significant overlap between traffic (approx 10-25%).
Now in reality, an OFDM (802.11a/g) wireless signal is made up of 48 sub-channels equally spaced across its 22mhz "channel". Instead of completely wiping out your signal, some of your sub-channels would be interference-prone, effectively reducing your data-rate. So, you can choose channels besides 1/6/11 (or 1,5,9,13 in the EU), but you must understand the consequences to yourself and your neighbors.
Or just go 802.11a/n on 5ghz and call it a day. 2.4gz is becoming far too crowded in highly dense deployments anyway.
Typical WiFi operates at 20mW @ 2.4Ghz.
Typical AP power is closer to 50-75mW (17-19dBm) - only low power WiFi sharing devices like MiFi would be as low as 20mW. Also worth remembering that your NIC will typically transmit back at a similar power if able.
Try changing the channel in your wireless router. Most set to channel 6 by default.
Remember, when choosing a channel, only 1, 6, and 11 are non-overlapping with each other - anything in between steps on the channel space of 1 and 6, or 6 and 11. Also, many (but not all) microwaves will impact the channel space between 6 and 11+, generally making 1 a better choice.
Try doing a "survey" using your wireless driver's built-in tools (most Broadcom adapters have some sort of rudimentary tool - Intel should as well). Even just a list of nearest neighbors will help you identify what channels are nearby and at what strengths. Out of 1, 6, or 11, pick something that is within the least occupied space (least number of APs or weakest AP). If your nearest neighbors are using 1 and 6, and another particularly ignorant/rude neighbor is using 3, your only real choice is 11. Now if it's 1, 6, and 9, you're kinda hosed, and you'll have to hope the channel 1 AP is furthest away because the guy using 9 is impacting 1 and 6 (just as the guy using 3 is impacting 1 and 6).
Google search turns up tons of results, but hopefully this paints a reasonable picture:
http://bridgingthelayers.org/channel_overlap.html
Unfortunately your NIC doesn't do 802.11a/n - otherwise I'd suggest looking into a dual-band 802.11n router. Tons of non-overlapping channels to pick from, but the range won't be quite as good (and you'll still have to steer clear of the 5.8ghz cordless phones).
If it's really bad, have your neighbors help pitch in for a WiSpy 2.4x (~$200) which could be used to pin-point the culprit. When you're done, sell it on eBay to recoup most of the cost. Probably cheaper than having a wireless survey team coming "onsite" to validate w/ their pricey Cisco Spectrum Expert device. They'd be able to tell pretty quickly if you're dealing w/ someone who loves their microwave popcorn, a wireless video streaming device, some sort of Zigbee (though those are usually pretty low power compared to Wi-Fi and narrow-band in comparison), frequency hopping device (cordless phone, etc).
One of the great features of TrueCrypt is the whole alternate partition/segment idea. One password gives access to real data, while another (a duress password) would give some other access to an alternate segment. Put some benign documents in the alternate partition, and then under threat of water boarding, hand out the duress password. Assuming this all works, they find nothing, you go home.
Granted, I'm not encouraging this idea for criminal activity, but rather for truly sensitive data that shouldn't fall into the wrong hands.
A curious question, that. You're asking what it is worth to the user of a site to justify the demands placed upon the operator of the site. You pose it as "demands upon the server", yet simply visiting a site creates demands upon the server. More people, more demands.
How is asking for HTTPS different from asking for "reasonable page load times", or "video feeds without compression artifacts"? On the user's side, one has little to no influence over (or even knowledge of) OTHER traffic to the site. The answer for the user is, "MY demand on the server is small, what's the problem?".
The only answers on the operator's side are "I want your traffic", or "I don't want your traffic".
The loads on the web server are a bit higher for HTTPS encryption than just passing fat content created by a developer without any common sense of bandwidth consumption.
Now if you're referring to server-side generated content contributing to page load times, then HTTPS isn't helping that provided the same server that is generating is the one doing the encryption.
How on earth is correcting a formatting/display issue in your own comment Offtopic?!
I wondered the same thing... Though now it is OT.
Woops, that should be https://www.[my lame site].com
1. For classic shared hosting solutions using name based hosting, I can almost guarantee if you hit https:///, you're going to hit someone else's virtual host. Many cheap hosting providers w/ limited public IPs will load up domain names on a single IP/Port, but still provide secure hosting to one domain name (on the same port) for shopping cart checkout under a different domain name. Using such a plugin in this use case would not work so well. Then again, would most "smaller sites" really be worthy of encryption in the first place?
2. Not every site is designed w/ the same content root in http vs https. Switching from http to https may completely break if the file structures under the two virtual hosts (potentially entirely separate in Apache) aren't identical (i.e. pointing to the same directory). I'm not touting that this is a best practice, but would be completely feasable if you wanted to keep specific content from being accessed via http and didn't want to bother with mod_rewrite or equivalent.
To the poster above who says there's little CPU penalty for SSL, SSL may not be taxing on the client, but hundreds or thousands of sessions on a server (especially one hosting an app, DB, and Apache) may be another story. Why is someone's assumed paranoid that someone will see that they're reading about cars or home theater equipment on a forum worth requiring a service owner to scale his hardware to the next level to maintain acceptable performance (assuming this phenomenon is multiplied hundred-fold)?
Exactly what I run at home, in RAID-1 configuration. It's very quiet, and could be stashed in a closet provided the ventilation was reasonable. DNS-323 runs quiet, is fairly low power, still offers GigE, and combined w/ WD green drives, runs reasonably cool and quiet. Set it to sleep after 15 minutes and noise/heat are almost non-existent when not in use.
That being said, for the OP, even with JBOD and 2TB drives (4TB raw max), they could easily run out of space unless they were running several of these in parallel. There comes a point when this simply won't scale (try to remember which NAS you stored your file on?), or noise and heat will become apparent.
My Mitsubishi DLP TV (WD65734) uses a 6-color wheel, adding yellow, magenta and cyan sub-primaries to the typical RGB + clear. Granted, Sharp's addition of Yellow is a first for LCD TVs, but it's old hat for some DLP engined systems.
This addition is supposed to create "truer" color rendition.
Some random thoughts - I'm a Systems Admin/Engineer by trade, but have spent some time in the Manager's chair as well. Here's some thoughts that would have helped me for my first real job (i.e. why didn't someone tell me):
Don't act like a know-it-all, but don't be afraid to offer a concise answer if solicited. Us nerds tend to LOVE to elaborate to "make an impression". The only impression is "Thanks, now how do I shut this guy up?".
Don't be afraid to challenge your peers when your approach may be better, but know when to back down when you're out-numbered.
In a cubical farm, your voice or other odd noises carry much further than you think. Same applies for the office restroom.
Speakerphone is a privilege reserved those with an office and a closed door. (Ab)using speakerphone (esp. loudly) in a cubicle will earn many more enemies than friends. Consider a headset if you're going to be on the phone a lot and need to type or do other things with your hands.
Learn and understand your company's core values. Chances are, you hold some of these yourself or you wouldn't have been hired (at least by any competent manager). These values will help guide your management team's decisions, just in case you question their motives.
If you lied on your interview, you'll be quickly found out the moment you submit your first program. If it's a serious lie that you can't lie your way out of again, don't even bother showing up for your first day.
Learn how to comment your code, but don't do it so much that stripping them out strips 75% of the file.
Use sane variables that someone else can maintain. "a, b, foo and bar" are not sane.
Be willing to learn - always. This may involve learning OUTSIDE of your job as well.
You will be required to understand the business to a degree that helps you develop useful code. Don't be surprised if your first few weeks on the job involve training that seems initially pointless (stocking shelves, packing boxes, etc.). It will all make sense in the end, and may even help start the creative flow of "I could do that better".
Innovate or get out of the way. Complacency often gets you fired.
For some companies, continuous improvement is expected. For others, they prefer the tried and true. Don't be afraid to ride the middle if you aren't sure which one you're dealing with at first. Someone will set you straight.
Make sure your line of communication with your manager is wide open. Understand his/her expectations and deliver on what's asked. However, if the expectations are completely unreasonable, have a backbone and ensure they know why you can't rewrite Linux in a day.
This is hard at first, but employees who perform well need little management. Those who don't can expect constant management. Then again, some managers like to micro-manage anyway, especially their under-performers.
Even when free, it's times like this that I'll break out the 3G card. When it's really bad, though is when the 3G card connects at 1.5 or 2G speeds (way out in the middle of nowhere).
So was I - the amount of internal theft way before things hit retail shelves at some companies is astounding. Equally so is the ways these thieves attempt to get things out the door (in body parts, lunch boxes, inside laptop DVD-ROM drives, through the garbage, etc.).
For those who work in an electronics store (or it's distribution centers), this will be a loss prevention nightmare for your tiny chips (like MicroSD).
"Oh, just a wad of change? No problem sir! Go on ahead..."
On the other hand, if I accidentally put it through the Coke machine on the way out of Fry's, I think I'd have what's coming to me. ;-)
What a better way to break in some law or pre-law students than to represent this case. Backing down benefits nobody but AIME and future precedent for online coursework.
Can this be addressed by the BIOS/GRUB/kernel at boot time?
Best part about a computer lab was being the tech. Whenever a student needed programming or word help, you were the one to respond. Total bonus points if the student was of the opposite sex and you got a phone number in the end. How else is a geek to get laid?
This is where running 240V to your PC may benefit.
It's going to take a substantial UPS to support that much power hungry RAM. Anyone else going to see their lights dim when they fire this system up?
Which is technically 9AM PDT and 12PM EDT.
Or you could move to Arizona where it's always MST and people always ask "what time is it there?".
To add to this - even if your plane can burn regular unleaded, it likely (and legally) not straight pump gas from most of your metropolitan fueling stations. Most STCs (supplemental type certificates) that permit burning auto gas in aircraft engines only allow a specific type of auto gas - that which does not contain ethanol as an oxygenate. This is usually only found in areas that don't require "reformulated" fuels for emissions reasons. AOPA has published a procedure to test for ethanol in the fuel that involves intentionally mixing water in a fuel sample to check for absorption.
Ethanol as a fuel additive is more volatile and has the ability to absorb water (unlike straight AvGas), both of which are bad at high altitudes (vapor lock and/or freezing lines are both really bad in-flight).
That being said, Lycoming is already working on certifying most of their lower compression O-360 and IO-360 engines to run on non-oxygenated premium unleaded auto gas in response to rising fuel costs and the ultimate demise of 100LL.
...This is why generators last so long but car engines generally don't... Most medium-large generators (i.e. 200kW) also loaf along at 1200 or 1800 RPM. Lower RPM = longevity.When our local CompUSA was going under last year or so, I found Vista Ultimate Upgrade discounted to $150. I decided to buy it at that point simply to know what I'd be supporting in a year or so. Still running the 64-bit iteration on my primary machine (tri-booting w/ XP Home and FC 9). Other than old hardware driver challenges and a healthy diet for RAM, I have had little other to complain about. If I thought my kids' machine could handle it, I'd probably spend the $50 for the family upgrade there too.
On the flip side, the OEM copy that came on my wife's Dell Inspiron on the other hand has been a ton of trouble. Rebooting instead of sleeping (thanks, SP1) seems to be the biggest issue.
So anecdotally, for applications where Vista was purchased on purpose, users are likely having a better experience than those who received it bundled with hardware!
Speaking of GPS vs. altimeter discrepancy - I've discovered even a WAAS enabled Garmin GPSMap 296 doesn't always agree w/ the airplane's altimeter. Unfortunately, at higher altitudes, the GPS errored several hundred feet on the high side (could possibly steer you into terrain in some cases if you were relying on it to keep you XXX feet above terrain) compared to the plane's altimeter, which was generally set to the nearest airport or whatever ATC provided. On the ground, however, they did agree. I was inclined to believe the altimeter, as the pressure altitude given by the Mode C transponder (which is always set to 29.92, then corrected by ATC to current barometer) was the same when ATC reported my altitude to other aircraft. Fortunately, it's a VFR (i.e. not in the clouds) only GPS (and wasn't mine, but borrowed), so I wouldn't be betting my life on it for terrain avoidance. In reality, it may have been a differing altimeter setting used on both ends that caused that discrepency. W/o a radar altimeter (which only works for a few thousand feet AGL), one will never know.
However, it gave me some "insight" into how GPS may not be 100% accurate for altitude (especially when the altimeter setting may provide different results than true altitude. Compound that with the possibility of a WAAS outage, and radar might seem like a nice alternative.
Since ADS-B is GPS based, I'd hope that ultimately, all planes and ATC agreed on what altitude they're at vs. what they're assigned to. While ADS-B will greatly reduce workload and may improve safety, I'd hate to see it completely supplant radar, even if radar is a backup only.