The problem, in my opinion anyway, isn't bandwidth throttling per say. It's *selective* throttling of certain protocols. That's tantamount to censorship.
What they should do, providing they don't actually have enough capacity to guarantee the bandwidths they sell, is clearly specify a minimum guaranteed bandwidth (in absence of equipment failure) and a percentage of time that the rated bandwidth is typically available. E.g. "10 Mbps connection (min 2Mbps, full 10Mbps available 90% of the time)". It would be preferable that these items were shown up front and not buried deep in the TOS. This would probably require government intervention of some kind, however. (And, IMNSHO, that's EXACTLY what a government should be doing - regulations that protect consumers and increase competition through transparency of offers.)
Regardless of how often throttling is done, it should always be protocol-neutral and user-specific basis. I.e. no throttling Bittorrent traffic on your backbone just because that's the easiest thing to do. No, you need to throttle each consumer individually (neutrally), basically giving them a slower connection for a (hopefully short) while.
Oh, and throttling ISN'T done by faking packets! That's fraud and should result in heads rolling, even though sending people to prison for wire fraud over it is *probably* overkill.
And, no, LEDs are not fluorescent. Fluorescent bulbs stimulate mercury to emit UV light. The UV light hits the phosphorus which makes it fluoresce and produce visible light. LEDs work by jumping electrons across a band gap and a photon is emitted when it jumps back down. The high efficiency comes into play because it doesn't take much more energy than that of the band gap to make an electron jump.
*White* LEDs don't work that way. You might assume that white LEDs are simply three (or more) normal LEDs combined in a single package. While it is possible to make white LEDs this way, it's not the method usually used (for several reasons, including "color integrity").
Instead, white LEDs are typically made by coating a BLUE indium-gallium-nitride (InGaN) LED with phosphorous. This is not all that different from a fluorescent bulb, which is what the GP postulated.
Different color temperatures can be achieved by varying the phosphorous coverage. Lower coverage lets more blue through (cooler temperature), whereas higher coverage causes more blue to be absorbed and thus more of the phosphorous emission spectrum to be emitted. The dominant line in the most commonly used phosphorous for LEDs is around 580nm (yellow).
It's also possible to get white LEDs that are made by coating a near ultra-violet LED with phosphorous (thus getting even closer to the fluorescent bulb of the GP).
This might change in the future, with serious work being conducted in the field to improve on reliability, efficiency and color characteristics. To the best of my knowledge, however, none of the new methods (go search for yourself) are commercially available and as we all know, many things that seem promising in the lab never make it to market for any number of reasons.
For reference, red diodes emit at ~ 630nm, blue diodes at 470nm, green at 530nm. The exact wavelength of the emitted light depends on the materials used in the LED, of course.
It's difficult to spot shifting vote numbers once the numbers get higher, which is why we need UN election oversight. This is a measure we insist on in other countries but yet refuse in our own.
I realize ragging on the election system in the US, any part of it really, is popular, but this argument - in and of itself - is completely ludicrous.
"we insist on in other countries.."
Not in any WESTERN country. I can't think of a single Western, "1st world", country that has UN oversight of its elections.... and, to be honest, I can't think of a single one that would even remotely consider it.
Now, you *could* argue that the US system is so utterly broken or whatnot that UN oversight is required, but the "we insist on it in other countries" argument is just stupid.
Why do you want to do that in HTML when HTTP already includes a number of authentication options, including digest passwords and more complex schemes?
By that logic, why even have a password type at all?
The answer, of course, is that everyone uses it, because it integrates well with page designs.
You can either be stubborn and admonish everyone else from your high horse... or you can actually go about trying to make things work for people. On all the sites I've made, I'm already securing passwords. Random salt is generated for EVERY user and a hash is made of the users password + the salt. Only the hash (and unique salt) is stored, never the password.
But considering the number of sites that allow you to get a copy of your password emailed, I can tell I'm among the few who do it this way. So instead of sticking my head in the sand (yeah, I'm mixing metaphors - wanna make something of it?!), I propose a solution that everyone can easily use.
What we would replace it with that could explain all of the observations that GR predicts I don't personally know, but it's a good day in physics when a theory is proved wrong because it means that we've done our job.
Not only does it mean we've done our job, it's also a whole lot of fun. Suddenly there's a whole new theory (or even better, lack of one) to test. Lots of new experiments to do. More hours to spend in basement labs...
What the browser sends to the server IS the effective password.
If the user types 'secrit' and the browser sends hash('secrit'+'salt') to the server, then that hash effectively -is- the password.
I'm well aware of how this works. The advantage, as I tried to point out, is that only THAT PARTICULAR server is then compromised. So if you got hold of Regular Joe's football fantasy message board password, you would only be able to log in to that one server... and not all the others where Joe used the same username and password.
The REUSE of passwords is the problem that is solved here.
Referring to my initial post, only the HASH of the supersecretpassword is revealed to the site (and anyone who gets hold of the passwords from it), not the supersecretpassword itself.
That would be a HUGE step up in security from where we are now.
My greatest wish in HTML5 is a new password element. One that uses a standard hashing-algorithm with server-supplied salt (optional local pepper could be provided) and prevents the receiving site from ever getting the password that the user actually typed in. E.g.
Here the contents are of the above handled completely by the browser, without the possibility of the site to get access to the contents or record keystrokes (via event handlers like onChange) while in focus. The *submitted* password would then be a hash, with salt provided by the server, of the supersecretpassword.
While not foolproof, it would help immeasurably with password security on the web. Even if no local pepper were added, anyone who gained access to the password database of the server (e.g. the owners), it would force a brute-force attack on the password.
No longer would anyone with access to a password database from a random web server (e.g. forum) be able to access pretty much every other site the users are registered on - because we all know that only rarely does Regular Joe use anything but his one-and-only password. This is especially bad when financial sites are included, but even if it's just gmail/yahoo/hotmail/whatever, that's still plenty bad.
if it's going to be the "photoshop competitor" every FOSS advocate claims it is (instead of, say, the Paintshop Pro competitor that it actually is
GIMP *is* competing primarily with Photoshop. This isn't a matter of which commercial application's feature set it most closely resembles. It's a matter of what users actually USE.
Photoshop is the default application for doing any kind of drawing or photo editing. It might be total overkill, it might not be the best choice or whatever, but that's irrelevant. Ask yourself this instead: How many people do you think PAY hundreds of dollars for Adobe Photoshop for their own personal at-home use?
Face it, Photoshop is the standard because it's pirated so much. This isn't a question of "lost sales", since 90% of Photoshop pirates (and I'm extrapolating from people I know of, so flame away) wouldn't DREAM of laying down that amount of cash. If they were forced to go legal, they would probably buy Paintshop Pro - an application that probably suits their needs much better anyway. (So if anyone is losing sales when Photoshop is pirated, it's probably Corel).
To summarize: GIMP competes primarily with *illegitimate* Photoshop users.
Not being sure if this is meant to be funny or not, I'll provide a little math:
"Watercode" (a high density 2D barcode) is rated at 440 bytes/cm2 (Microsoft has a color 2D barcode which has maybe a 25% higher data density).
Disregarding the fact that you'd probably be storing the data on drums of paper, and not sheets, what follows is a calculation of the number of A4 sheets required to store a movie in original format.
A4 is 210x197 mm2 = 413.7 cm2. At 440 bytes/cm2, that's 440*413.7 bytes/A4 = 182028 bytes/A4 ~ 0.2 MB / A4 (with very generous rounding up, so it covers the MS color barcode as well).
At several TB for a digitally shot movie master, that's... well... a lot. More than 5 million sheets of A4 paper per TB, in fact.
I'm not going to get into the whole weight or storage space issue here, let's just agree that's an unmanageable amount of paper...
Feel free to argue that modern laser printers have whatever high resolution you feel like using.... but there's a reason no commercially available barcode has that kind of data density. If you feel the job can be done much better, I suggest heading down to the patent office...
The point simply being that there are almost certainly circumstances under which ANY browser leaks memory. The circumstances likely aren't the same, of course, which is part of the problem and why different people have different experiences.
In the end, those who claim that a given browser leaks memory really need to provide DETAILS. Not just "running it for any significant time" or some such BS. Real details of pages visited and actions taken on those pages. If there's a leak, it'll be reproducible. So log your visits (hey, "history") and try figuring out which ones are causing the problem.
To see if the leaking is related to Javascript, try turning it off once you have found a reproducible case (which might be a huge list of sites of which only one might be the actual offender).
How come my 700MHz Duron with 384MB memory ran Firefox perfectly? Never had any problems. At least none that were memory-related. I'm convinced that 99% of all the memory issues people THINK they have is because Firefox keeps allocating memory as long as the system allows it to... which is the right thing to do! If you buy gigs of memory and the system isn't using them, why shouldn't firefox (or any other application) keep gobbling them up? Firefox releases the memory nicely again if the system wants it (e.g. you start up Open Office).
Maybe it's your extensions or plugins that are causing the problems, if in fact you are experiencing problems?
That's not to say that there are NO leaks. Of course there are. I've used IE many, many times where it simply stopped responding and had to be stopped. I've experienced the same thing with Opera, although far less frequently. The only times I've had to shut down Firefox has been due to plugins or extensions. Again, not saying there aren't real leaks and maybe you just happen to visit sites that cause these cases to occur, I don't know, but it seems quite clear that 99% of the problems people report aren't real (it's just a memory usage number, which is useless in many, many ways).
One of the most important lessons students can learn pre-college is, in my opinion, source criticism (a term which is unfortunately used mainly in a biblical context, which is NOT my usage here).
"A critical mind is a questioning mind" is a good lesson and should be taught at every level of education.
Virtually all sources are biased, in one way or another, and students need to be aware of this and treat the information in a manner befitting the source.
Wikipedia is just another source (not a primary one, of course, with a few exceptions) and should be treated like every other secondary source - with skepticism. The fortunate thing about Wikipedia - and one that makes it a much better secondary source than most others - is that there are abundant links to other sources (although not necessarily primary sources, which would be preferable).
Additionally, Wikipedia enables one to view the version history and a discussion of the article in question. This discussion can often be used to discern if there are any particular points of contention that one should be aware of. This shouldn't replace ones critical view of "accepted facts", of course.
In practice, we are inundated with such an overwhelming amount of "news", "facts" or interpretations of same, that we cannot possibly be highly critical of every single item. Instead we rely on the reputation of the source. It is important, however, that we routinely question the reputation of the source.
For teachers to ignore Wikipedia does not seem particularly insightful and one has to wonder whether the teachers in question are the same authoritarian breed of teachers that can wreck havoc on a young mind.
While he didn't technically call your post an astroturf, I can see why you would take offense at that. However, he attacked your ARGUMENT (with reasons) and called that LINE OF ARGUMENTATION a "classic astroturf technique".
As I said before, however, I think his interpretation of your argument was overly broad and likely untenable. Just because you are offended (personally) by something does not make it a personal attack.
The GP (ozmanjusri) criticized your argument and although you might disagree with his criticism, it is most certainly not an ad hominem attack. I'm as much in favor of tossing in latin phrases ad libitum, but there was no *personal attack* here. Sure, the criticism was overly broad and not particularly poignant... Cetera desunt
> Nothing else matters (esp. new features) until they've fixed those.
>> Ah, another classic astroturf technique. Firefox doesn't do X, ergo no Firefox for anyone, anywhere!
No, bookmarks are now stored in a database. This is possibly the most important change in FF3 for me. The old method was SLOW and subject to corruption. A proper database also opens up possibilities for (much) better searching.
to the best of my knowledge EISA was never used on video cards unless it was highly specialized.
You are incorrect.
I remember back when I got my first post-ISA graphics card - in order to get better kick my neighbors ass in Descent, IIRC.
Anyway, I distinctly remember having to chose between EISA and VLB (VESA). For whatever reason, I wound up going with a Tseng Labs ET4000 EISA card sporting 1MB of VRAM.
I also recall the salesman's shock at my asking what the speed was of the memory chips. He'd never had anyone ask that before... which was actually a bit surprising since the performance difference between the slow and fast memory chips was quite substantial.
Ok, I noticed that the amazon link now has some updated (color) maps. NOTE: These are offset from the old (b/w) maps, so you need to look around for identifying landmarks to pinpoint the same location.
For example, my best bet a hit was:
38.1309, -119.462
The plane-shape is still there in the new color maps, but the contrast is lower (so it's probably a plane-shaped clearing or rock). The new coordinates, however, are:
38.127, -119.461
or about 1450 feet offset.
This offset fits perfectly with the landmarks in the area (which are also offset by that amount).
Dude, I don't see anything at all that looks like a plane or crashed plane in your images. I mean, nothing even close. Did you muck up the copy/paste of the right coords?
Hey, I'm not an expert, but I do see plane-shaped bright areas of roughly the right dimensions (18-30 feet) at all three coordinates. The first is by far the fuzziest, but I uploaded images of the other two here:
Maybe there's a problem with the coordinates in Google Earth? I'm using Google Earth 4.2 for Linux (64bit Ubuntu Feisty). I'd hate to think things are being missed because of a bug...
The offset isn't constant, sadly. In some places it is the aforementioned 640feet North, in other places 640feet NE, in other places only a 100feet or so.
Note that the old maps are offset around 640feet to the North, compared to the new maps. Lakes and peaks show that pretty conclusively.
All that said, I've found several plane-shaped bright images (of roughly the right size) that were not in the old map data, but where do I alert someone to the coordinates? This was not done through the Amazon thingie, but directly in Google Earth...
Ok, so what do we do if we find a plane just browsing in Google Earth? (way more efficient than refreshing the webpage).
38 7'34.00"N, 11929'4.81"W
Much more fuzzy than the AC plane, so this is probably nothing, but the size and shape is about right (a bit shorter, but of the plane is angled, it could easily show up shorter).
Slashdot Mirror
I'm surprised this hasn't been slapped with the "whatcouldpossiblygowrong" tag yet.... seems like most stories are, pretty much regardless of content.
The problem, in my opinion anyway, isn't bandwidth throttling per say. It's *selective* throttling of certain protocols. That's tantamount to censorship.
What they should do, providing they don't actually have enough capacity to guarantee the bandwidths they sell, is clearly specify a minimum guaranteed bandwidth (in absence of equipment failure) and a percentage of time that the rated bandwidth is typically available. E.g. "10 Mbps connection (min 2Mbps, full 10Mbps available 90% of the time)". It would be preferable that these items were shown up front and not buried deep in the TOS. This would probably require government intervention of some kind, however. (And, IMNSHO, that's EXACTLY what a government should be doing - regulations that protect consumers and increase competition through transparency of offers.)
Regardless of how often throttling is done, it should always be protocol-neutral and user-specific basis. I.e. no throttling Bittorrent traffic on your backbone just because that's the easiest thing to do. No, you need to throttle each consumer individually (neutrally), basically giving them a slower connection for a (hopefully short) while.
Oh, and throttling ISN'T done by faking packets! That's fraud and should result in heads rolling, even though sending people to prison for wire fraud over it is *probably* overkill.
*White* LEDs don't work that way. You might assume that white LEDs are simply three (or more) normal LEDs combined in a single package. While it is possible to make white LEDs this way, it's not the method usually used (for several reasons, including "color integrity").
Instead, white LEDs are typically made by coating a BLUE indium-gallium-nitride (InGaN) LED with phosphorous. This is not all that different from a fluorescent bulb, which is what the GP postulated.
Different color temperatures can be achieved by varying the phosphorous coverage. Lower coverage lets more blue through (cooler temperature), whereas higher coverage causes more blue to be absorbed and thus more of the phosphorous emission spectrum to be emitted. The dominant line in the most commonly used phosphorous for LEDs is around 580nm (yellow).
It's also possible to get white LEDs that are made by coating a near ultra-violet LED with phosphorous (thus getting even closer to the fluorescent bulb of the GP).
This might change in the future, with serious work being conducted in the field to improve on reliability, efficiency and color characteristics. To the best of my knowledge, however, none of the new methods (go search for yourself) are commercially available and as we all know, many things that seem promising in the lab never make it to market for any number of reasons.
For reference, red diodes emit at ~ 630nm, blue diodes at 470nm, green at 530nm. The exact wavelength of the emitted light depends on the materials used in the LED, of course.
Now that old standard user complaint might actually become true!
Power is equal to the voltage multiplied by the current, so if the current stays the same and the voltage drops to 1/3, well, so does the power.
(Yes, I'm well aware that's only ohmic power, so shoot me.)
I realize ragging on the election system in the US, any part of it really, is popular, but this argument - in and of itself - is completely ludicrous.
"we insist on in other countries.."
Not in any WESTERN country. I can't think of a single Western, "1st world", country that has UN oversight of its elections.... and, to be honest, I can't think of a single one that would even remotely consider it.
Now, you *could* argue that the US system is so utterly broken or whatnot that UN oversight is required, but the "we insist on it in other countries" argument is just stupid.
By that logic, why even have a password type at all?
The answer, of course, is that everyone uses it, because it integrates well with page designs.
You can either be stubborn and admonish everyone else from your high horse... or you can actually go about trying to make things work for people. On all the sites I've made, I'm already securing passwords. Random salt is generated for EVERY user and a hash is made of the users password + the salt. Only the hash (and unique salt) is stored, never the password.
But considering the number of sites that allow you to get a copy of your password emailed, I can tell I'm among the few who do it this way. So instead of sticking my head in the sand (yeah, I'm mixing metaphors - wanna make something of it?!), I propose a solution that everyone can easily use.
Not only does it mean we've done our job, it's also a whole lot of fun. Suddenly there's a whole new theory (or even better, lack of one) to test. Lots of new experiments to do. More hours to spend in basement labs...
ID'ers just don't know the fun they're missing.
Nononono... the standard "really tiny" analogy in popular media is "fraction of a human hair", e.g. "one thousands of the width of a human hair".
(completely disregarding that the width of human hair varies by at least an order of magnitude from person to person).
I'm well aware of how this works. The advantage, as I tried to point out, is that only THAT PARTICULAR server is then compromised. So if you got hold of Regular Joe's football fantasy message board password, you would only be able to log in to that one server... and not all the others where Joe used the same username and password.
The REUSE of passwords is the problem that is solved here.
Referring to my initial post, only the HASH of the supersecretpassword is revealed to the site (and anyone who gets hold of the passwords from it), not the supersecretpassword itself.
That would be a HUGE step up in security from where we are now.
My greatest wish in HTML5 is a new password element. One that uses a standard hashing-algorithm with server-supplied salt (optional local pepper could be provided) and prevents the receiving site from ever getting the password that the user actually typed in. E.g.
Here the contents are of the above handled completely by the browser, without the possibility of the site to get access to the contents or record keystrokes (via event handlers like onChange) while in focus. The *submitted* password would then be a hash, with salt provided by the server, of the supersecretpassword.
While not foolproof, it would help immeasurably with password security on the web. Even if no local pepper were added, anyone who gained access to the password database of the server (e.g. the owners), it would force a brute-force attack on the password.
No longer would anyone with access to a password database from a random web server (e.g. forum) be able to access pretty much every other site the users are registered on - because we all know that only rarely does Regular Joe use anything but his one-and-only password. This is especially bad when financial sites are included, but even if it's just gmail/yahoo/hotmail/whatever, that's still plenty bad.
GIMP *is* competing primarily with Photoshop. This isn't a matter of which commercial application's feature set it most closely resembles. It's a matter of what users actually USE.
Photoshop is the default application for doing any kind of drawing or photo editing. It might be total overkill, it might not be the best choice or whatever, but that's irrelevant. Ask yourself this instead: How many people do you think PAY hundreds of dollars for Adobe Photoshop for their own personal at-home use?
Face it, Photoshop is the standard because it's pirated so much. This isn't a question of "lost sales", since 90% of Photoshop pirates (and I'm extrapolating from people I know of, so flame away) wouldn't DREAM of laying down that amount of cash. If they were forced to go legal, they would probably buy Paintshop Pro - an application that probably suits their needs much better anyway. (So if anyone is losing sales when Photoshop is pirated, it's probably Corel).
To summarize: GIMP competes primarily with *illegitimate* Photoshop users.
Not being sure if this is meant to be funny or not, I'll provide a little math:
"Watercode" (a high density 2D barcode) is rated at 440 bytes/cm2 (Microsoft has a color 2D barcode which has maybe a 25% higher data density).
Disregarding the fact that you'd probably be storing the data on drums of paper, and not sheets, what follows is a calculation of the number of A4 sheets required to store a movie in original format.
A4 is 210x197 mm2 = 413.7 cm2.
At 440 bytes/cm2, that's 440*413.7 bytes/A4 = 182028 bytes/A4 ~ 0.2 MB / A4 (with very generous rounding up, so it covers the MS color barcode as well).
At several TB for a digitally shot movie master, that's... well... a lot. More than 5 million sheets of A4 paper per TB, in fact.
I'm not going to get into the whole weight or storage space issue here, let's just agree that's an unmanageable amount of paper...
Feel free to argue that modern laser printers have whatever high resolution you feel like using.... but there's a reason no commercially available barcode has that kind of data density. If you feel the job can be done much better, I suggest heading down to the patent office...
Just for all those who think that IE doesn't leak memory:
"It's possible to set up a ciricular reference that prevents cleanup, and this leaks memory in IE."
http://channel9.msdn.com/ShowPost.aspx?PostID=9204
The point simply being that there are almost certainly circumstances under which ANY browser leaks memory. The circumstances likely aren't the same, of course, which is part of the problem and why different people have different experiences.
In the end, those who claim that a given browser leaks memory really need to provide DETAILS. Not just "running it for any significant time" or some such BS. Real details of pages visited and actions taken on those pages. If there's a leak, it'll be reproducible. So log your visits (hey, "history") and try figuring out which ones are causing the problem.
To see if the leaking is related to Javascript, try turning it off once you have found a reproducible case (which might be a huge list of sites of which only one might be the actual offender).
How come my 700MHz Duron with 384MB memory ran Firefox perfectly? Never had any problems. At least none that were memory-related. I'm convinced that 99% of all the memory issues people THINK they have is because Firefox keeps allocating memory as long as the system allows it to... which is the right thing to do! If you buy gigs of memory and the system isn't using them, why shouldn't firefox (or any other application) keep gobbling them up? Firefox releases the memory nicely again if the system wants it (e.g. you start up Open Office).
Maybe it's your extensions or plugins that are causing the problems, if in fact you are experiencing problems?
That's not to say that there are NO leaks. Of course there are. I've used IE many, many times where it simply stopped responding and had to be stopped. I've experienced the same thing with Opera, although far less frequently. The only times I've had to shut down Firefox has been due to plugins or extensions. Again, not saying there aren't real leaks and maybe you just happen to visit sites that cause these cases to occur, I don't know, but it seems quite clear that 99% of the problems people report aren't real (it's just a memory usage number, which is useless in many, many ways).
One of the most important lessons students can learn pre-college is, in my opinion, source criticism (a term which is unfortunately used mainly in a biblical context, which is NOT my usage here).
"A critical mind is a questioning mind" is a good lesson and should be taught at every level of education.
Virtually all sources are biased, in one way or another, and students need to be aware of this and treat the information in a manner befitting the source.
Wikipedia is just another source (not a primary one, of course, with a few exceptions) and should be treated like every other secondary source - with skepticism. The fortunate thing about Wikipedia - and one that makes it a much better secondary source than most others - is that there are abundant links to other sources (although not necessarily primary sources, which would be preferable).
Additionally, Wikipedia enables one to view the version history and a discussion of the article in question. This discussion can often be used to discern if there are any particular points of contention that one should be aware of. This shouldn't replace ones critical view of "accepted facts", of course.
In practice, we are inundated with such an overwhelming amount of "news", "facts" or interpretations of same, that we cannot possibly be highly critical of every single item. Instead we rely on the reputation of the source. It is important, however, that we routinely question the reputation of the source.
For teachers to ignore Wikipedia does not seem particularly insightful and one has to wonder whether the teachers in question are the same authoritarian breed of teachers that can wreck havoc on a young mind.
While he didn't technically call your post an astroturf, I can see why you would take offense at that. However, he attacked your ARGUMENT (with reasons) and called that LINE OF ARGUMENTATION a "classic astroturf technique".
As I said before, however, I think his interpretation of your argument was overly broad and likely untenable. Just because you are offended (personally) by something does not make it a personal attack.
The GP (ozmanjusri) criticized your argument and although you might disagree with his criticism, it is most certainly not an ad hominem attack. I'm as much in favor of tossing in latin phrases ad libitum, but there was no *personal attack* here. Sure, the criticism was overly broad and not particularly poignant... Cetera desunt
No, bookmarks are now stored in a database. This is possibly the most important change in FF3 for me. The old method was SLOW and subject to corruption. A proper database also opens up possibilities for (much) better searching.
You are incorrect.
I remember back when I got my first post-ISA graphics card - in order to get better kick my neighbors ass in Descent, IIRC.
Anyway, I distinctly remember having to chose between EISA and VLB (VESA). For whatever reason, I wound up going with a Tseng Labs ET4000 EISA card sporting 1MB of VRAM.
I also recall the salesman's shock at my asking what the speed was of the memory chips. He'd never had anyone ask that before... which was actually a bit surprising since the performance difference between the slow and fast memory chips was quite substantial.
Wikipedia's article on the ET4000 card even mentions an EISA version!
And here is a link to a specific ET4000 EISA card, although not the one I owned (and probably still have in a box in the basement).
Ok, I noticed that the amazon link now has some updated (color) maps. NOTE: These are offset from the old (b/w) maps, so you need to look around for identifying landmarks to pinpoint the same location.
For example, my best bet a hit was:
38.1309, -119.462
The plane-shape is still there in the new color maps, but the contrast is lower (so it's probably a plane-shaped clearing or rock). The new coordinates, however, are:
38.127, -119.461
or about 1450 feet offset.
This offset fits perfectly with the landmarks in the area (which are also offset by that amount).
Hey, I'm not an expert, but I do see plane-shaped bright areas of roughly the right dimensions (18-30 feet) at all three coordinates. The first is by far the fuzziest, but I uploaded images of the other two here:
http://i57.photobucket.com/albums/g221/fyodor_/p lane3.png
http://i57.photobucket.com/albums/g221/fyodor_/p lane2.png
On the other hand, in yours, there is ABSOLUTELY nothing that looks like a plane... I mean, nothing even close ;-). Check the image below:
http://i57.photobucket.com/albums/g221/fyodor_/w hatshere.png
Maybe there's a problem with the coordinates in Google Earth? I'm using Google Earth 4.2 for Linux (64bit Ubuntu Feisty). I'd hate to think things are being missed because of a bug...
The offset isn't constant, sadly. In some places it is the aforementioned 640feet North, in other places 640feet NE, in other places only a 100feet or so.
Meanwhile, here are three candidates.
38 19'12.87"N, 119 16'56.30"W
38 7'51.26"N, 119 27'41.67"W
38 7'34.00"N, 119 29'4.81"W
All are a bit fuzzy, but "plane shaped" and the right size. #2 is by far the sharpest.
I was unable to find either of these in the original google earth maps. (I did find a few others that WERE in the old maps, so they're discarded).
Note that the old maps are offset around 640feet to the North, compared to the new maps. Lakes and peaks show that pretty conclusively.
All that said, I've found several plane-shaped bright images (of roughly the right size) that were not in the old map data, but where do I alert someone to the coordinates? This was not done through the Amazon thingie, but directly in Google Earth...
Ok, so what do we do if we find a plane just browsing in Google Earth? (way more efficient than refreshing the webpage).
38 7'34.00"N, 11929'4.81"W
Much more fuzzy than the AC plane, so this is probably nothing, but the size and shape is about right (a bit shorter, but of the plane is angled, it could easily show up shorter).