Sadly, this is the norm I run into, and far too oft from people who are strongly OS-aligned; they can't keep their computer from breaking no matter what they run.
Some of us forget, computers are hard... Especially for the untrained. We didn't get "Computer Fun" degrees, after all. Although, that would be pretty sweet!
Too many people expect a "toaster" or "television" experience from a rather complicated piece of equipment. Heck, some of the folk I help with PC issues have toaster and television issues!
Any of us old engineering university types (with significant knowledge of OS and their inner workings) can point out the same failures in some situations for all OS.
The reason LINUX continues to fail in the eyes of those with a "plug it in and it works" level of expertise is that they want it to plug it in and have it work like the other OS they like. They all have their benefits. They all have their pitfalls. If you try to treat them as interchangeable items, disappointment will abound.
When pulling down even an easy to install distro like Ubuntu, it will have trouble if you're trying to add it to a "designed for Windows" computer. Some little piece, or a whole bunch of them, will have been chosen because of an available, sometimes proprietary driver, which suddenly makes it frustrating when trying to use something else.
Instead, try it on a computer with "standard" components and you'll probably have more success. Then it becomes an issue of interface preference (read, desktop), desired software availability (as in, pick your word processor), and external compatibility (e.g., document sharing). A little comfort, perhaps some training, and they all start to look the same, and work the same, and have perks and quirks.
I liken it to cars when talking to some of those engineering university types, or even dumber people; while they all function "the same," and all use "the same" technology, you accept that your make (and even model) of automobile has less than generic parts; why is that so hard to grasp for computers? Heck, this may even be a case of someone discounting an entire line of automobiles because one time they were in one that ran out of gas, therefore, that kind of auto must be teh sux0rz.
Additionally, since on-line gambling is illegal anyway, it will just serve as a gateway to grey-hat or black-hat ways around any kind of IP blocking, such as TOR or one of the many others.
I say, quit telling people what they can or cannot do to themselves, and let the gamblers gamble. If you, Minnesota, want to do something about on-line gambling, figure out a way to squeeze taxes in there and make it a revenue stream and not a cost-center.
Groovy is to Java as PERL is to C. Many similarities, plenty of points of comparison, some interactivity, arguably some interchangeability. It is not a "super set" or even an extension. It's a new language, written in another language. It's a scripting tool, written in Java, that optionally generates Java for execution not in a Groovy engine.
It doesn't give you "compiled Java" any more than Java gives you compiled Java, and other tools (like gjc) give you native executables from software written in Java.
It's got good. It's got bad. It's new. It leverages old. If you're going to use it, you've got to learn it.
Before we dig into the viability of such a service, consider a similar service that already exists. Surely you've heard of jukeboxes. They have them in diners and bars near you, I'm sure. I think most offer a small number of songs for a number of pennies each (three for a quarter, or whatever). You plunk in your change, pick from the limited list, wait for your turn in the queue, listen eventually to your song, and move on. Repeat as desired.
Moving on from whether or not the service may be viable, if YOU read the article, you'll see that you were wrong in your understanding of how it works.
The article at the first link says "For just 10 cents you'll be able to select a song to add to your Music Locker to play whenever you like." (I copied and pasted between the quotes...) Not per listen, as you suggest, but per song. In case you don't want to scour the whole article, it's the second sentence in the first paragraph...
If you follow the seekrit link and look at the "how it works," (link at the bottom) you'll see that in fact you can actually listen to any song for free, once (first question), not dropping the dime to see if you like the song. It also confirms that for your thin dime, you add the song to your list to listen to again any time you want (second question). Additionally, if you want to download the song to another device (iPod, for example), that dime counts towards the purchase of that song.
I had the opposite, but same idea. What if we could get sea-going cows? No, not manatee, but a whale-sized cow, that is made of beef, and isn't land-locked. Perhaps you corral them in lakes or bays, or let them "free range" in the ocean to harvest later. If the "cowhale" were as prolific as their land-based cousins, then we could have an abundance of ocean beef.
Sure, sure, now you pundits will point out that the thing that makes beef tasty is a diet of grass and corn. And there will be those who will point out that a new species of herbivore in the ocean, especially a prolific one, would have drastic environmental consequences, the least of which will be the decimation of ocean prairies and a new source of manure and methane.
I think my thoughts got a little jumbled there, and I meant the comparison conversationally, not quite as technically. I recall that a friend's old Beetles used electric heaters for the passenger compartments, not heated seats. It may have been aftermarket, or perhaps there was just an electric component (e.g., fan?) that made my friend proclaim the heat was electric...
I saw this on the television and thought it looked pretty cool, pun kind of intended.
Arguably one could compress one's own air in the garage with a wind or solar powered compressor and fuel the thing for "free." Certainly that would be an option for some (in windier areas) people and even filling stations. Otherwise, of course, we're just moving the pollution from the streets to the power plants that then have to power all of the compressors.
The thing that kicked the idea for me is that the car seems potentially impractical for those of us that live in temperate regions. For a large part of the year, our vehicles need to generate heat for the passenger compartment. In your typical gas-powered motorized vehicle, this is heat taken from the cooling system. Sure, the old VW Beetle had an electric heater in it, but anybody who had one in sub-zero climates can tell you that they don't always cut it. It's probably the case that the improvements in seat-based heating and technology in general will make the heaters more useful. Perhaps the size of the cabin will help. It also needs to be considered that the light-weight construction of the body may not allow for an awful lot of insulation.
Along the same lines, those tiny wheels wouldn't make it through the snow. A 75HP motor seems like enough to power some larger wheels, but what's the torque like, and how much impact is that larger drive-train gonna have? And once you start adding that bottom weight, how much is that going to force changes in the rest of the car, and will it spiral out of control such that the power plant is no longer sufficient?
In warmer areas, like I'd like to move to, it seems a very practical commuter vehicle. I have to imagine someone has thought of routing the exhaust through a cooling system, allowing the engine to cool the cabin without needing an environmentally unfriendly air conditioner. On good paved roads the tiny wheels might only be a hindrance to top speeds, where larger wheels might be needed for rougher roads, like those with cracks and potholes. (Yeah, I may have a thing against tiny wheels...)
There is also a safety factor. In places where everyone drives small cars, this will fit right in, but in the US, too many SUVs and large sedans compete for the same road as these. It'll probably be the same as with motorcycles; they're safer when you get a bunch of them together than individually ripping through traffic. Once there's a lot of them on the road, this should shift so that the small cars will dominate, and the larger ones will be the exceptions.
Heck, someone should suggest to "reverse" the HOV lanes and force the big vehicles over there, allowing the smaller vehicles to have the other lanes; which could probably be narrowed, and would be less congested as all of the vehicles would be shorter and everyone would be closer to their destination by the time the traffic jam started .
They're not mutually exclusive. Instead, think of them as the corners of a triangle. You call them "cheap," "fast," and "well" (because it makes better sense gramatically) but call them "cost," "speed," and "quality" respectively.
The general, and arguable, assumption is that customers are tied to cost, managers are tied to speed, and developers to quality. Usually the trouble comes from the priorty of each group. Customers tend to lean towards cost, speed, and quality. Managers tend towards speed, quality, and cost. Developers tend to go for quality, speed, cost.
This also aligns with the two-sided client-vendor cost equation; customers want to pay less and vendors want to make more.
Most people act as though they can only choose points only along the sides of the triangles, but this isn't really true. Sometimes it's just harder to recognize compromise to the gradients in the middle of the triangle. With this model, if you're on the line between "cost" and "speed", it appears as though you've completely sacrificed "quality."
In reality you pick from anywhere inside the triangle, including smack on one of the corners. You sacrifice as you move away from the corners, so in the middle you have to compromise all three cost, quality, and speed.
This is an often unrealized (and more often unrealistic) compromise.
If only there were another option; some kind of operating environment one could install on one's computer to do one's work. And maybe some other bits and pieces of software that could go with that environment that would still let one perform one's computer-centric duties.
If only there were some way we could get from beneath the crushing foot of this megacorporation and have the freedom to choose. To choose the programs that met our needs, our budgets, and our requirements.
They're trying to boot out the PDF format, which is nice, open and ubiquitous with their own format - and they're using their monopoly on the desktop operating system market to achieve this.
Consider also that the bulk of people looking to use Vista are probably already using Windows, and therefore probably already have some method of reading Word documents.
I understand the desire to review the propoganda on some other platform; really that's not hard to do with a Word document either.
And there's the brilliant use of space wherein pages with a header and footer only (see page labeled v), or a single two-line paragraph describe the following pages (see page labeled #9). Surely this could be formatted better to not waste paper, should one want to print the document. Electronically, whatever, printed, big waste.
I personally fear the day that a machine or algorithm can better determine the purpose for my keyword-based search than I can. Sure, there's a lot of improvement that can be done to make the searches more precice, but certainly in the end it'll be my decision what's important and what isn't.
What I really want to see is the search engine reduce the duplicated content to single entries (try Googling for a Java classname and you'll see how many Google-searched websites have the API on them), or order them by reoccurrance of the word or phrase giving the context more value than the popularity of the page.
Exactly. If something malicious was going to be added, it's too late once you read the message. The only reason to feel any degree of safety in ending your browser session and trying in a new one is the potential that the JVM that hosted the JavaScript bad tool has died. In a real bad scenario, some rootkit may be applied to the system and then you're completely hosed.
In the general, low-tech phishing scheme, though, you've just received an e-mail that looks like its legitimately from an organization with whom you do business, and they hope to steal your login and password, or name and SSN by directing you to a look-alike web site, which will give you a "password failed" message. Too late for you now.
I was outlining the not-gonna-happen scenario where one might believe an unwanted/unsolicited e-mail from what looks like an actual bank/other vendor and try to act on that information.
I personally feel a little safer not using Windows, which is the general target of most phishing, or IE when I do have to use Windows. I also have 4 PCs on my KVM, and would most likely follow-up on a separate system entirely...
This method of phish detection has its flaws, too. It'd be pretty easy for said phisher to set up a self-certified SSL site, that the phish would accept even if it weren't trusted third-party verified.
It's pretty easy to tell the phish from the non-phish, as I don't bank or shop at most of the places the phishers send my way. Also, should I receive an e-mail from my bank (which they already said they wouldn't send me--believing that snail mail is more secure and less likely to be abused), and I feel the need to get there to deal with whatever the message may be saying, I'm surely not going to click a link. Heck, I probably wouldn't even visit the bank during the same session for fear of some kind of redirect spyware that they tried to sneak into the session.
Looking at the URL and seeing "ebay.somewhere.ch" instead of "ebay.com" isn't secure enough anyway, as it's trivial to spoof the status bar with the hover-over text.
The only way to avoid being phished is to not trust any e-mail that has anything to do with anything related to money, savings, charge cards, or deals that are too good to be true--they are too good to be true. A good runner-up is to find a black-hole mail service (i.e., get your own domain name) and set up an account for each vendor you deal with, with a less-than-likely phishable address (e.g. nvrSp4mMy-ebay@mydomain.us). Then, never give your "real" e-mail address to any site you don't explicitly trust. Or even use the same black-hole method for sites you do trust--like slashdot@mydomain.us), instead opting for a black hole e-mail address; this also helps identify who compromised your identity.
While some software is sometimes better at recognizing these things than others (I seldom get phish-mail at my GMail account, as they're recognized and flagged by the other users first), we still can't rely on an automated method to stop these things. It is on the individual to be responsible with their own information.
"I am not who I seem to be," is the safest way to present yourself to the generally anonymous Internet. That's the way they're presenting themselves.
Let's not forget Savage and Unreal Tournament 2004 with their direct LINUX products, and the whole slew of things the kind folks at Loki port and work on.
Since J2SE1.5, sorry J2SE 5.0, the OS look and feel has been part of the runtime. Yes, the Java runtime does do native calls behind our backs, but that's what the VM is supposed to do. No, I don't want to use layers that limit where I can deploy my software. Perhaps you have the luxury (or would it be drawback?) to develop and deploy on the same OS with the same tools, but some of us have to actually write transportable code; develop on Windows or LINUX, deploy on Solaris, or whatever. Start mixing the real Java tools with the bits and pieces provided by others, especially when they aren't "pure" Java, and you're looking for trouble.
Eclipse is dandy. As I said, I use it almost daily. NetBeans is a fine platform, too, and shouldn't be discounted out-of-hand just because one is more familiar than the other. And using either one, or something different, shouldn't affect the code developed within their confines.
And I don't speak for Sun, nor do I have any particular information on their "nervousness"; these reflections are mine alone, shared for your entertainment.
Finally, to address some of the other comments; both NetBeans and Eclipse are "platforms" not strictly IDEs. As most commonly downloaded (I would imagine--I have no statistics--I'm basing this purely on the packages offered at their respective download web pages) they are Java IDEs. Both can be integrated with C compilers. Both have plug-ins for PERL and PHP and other stuff. Both are easy to extend, and both have solid foundations.
Plusses and minuses both. Fewer minuses for Eclipse, sure. Not as many as some would think for NetBeans.
Eclipse is not what you may think it is. Eclipse is the community front-end for the expensive IBM WSAD environment. Most of the places I've worked that use Eclipse do so because they see it as an alternative to the WSAD tools, and they're using WebSphere as the eventual platform; which is truly irrelevant if the software is written corectly.
NetBeans is much more like it looks. Formerly it was the community front-end for Sun's expensive Forte environment, but Sun has since abandoned that for truly the community-driven IDE, backing it with every visit to the JDK download page. And it works just fine with all of the Java application/servlet environments, whether Sun released them or not.
NetBeans is also pure Java, written on Swing, while Eclipse uses its proprietary SWT, which uses native calls to get its GUI work done. You can take the same archive of NetBeans to any J2SE-enabled desktop and it'll work. Not so with Eclipse. Because of this, it's easier to adopt new releases and plug-ins in NetBeans than it is for Eclipse. Many of the third-party add-ons for Eclipse assume or require Windows, and therefore don't work on LINUX, Solaris, Mac, or any of the other envornments. Not so with NetBeans; the plug-ins are also Java, so they work everywhere NetBeans does.
I was a long-time advocate of NetBeans before Eclipse came in to dominate the workplace. Eclipse does win some robustness categories, and its rapid-development bits are a little better (auto-complete/suggest kicks over NetBeans), but both are modular and extendable, and NetBeans has usually come with the tools needed to get the job done before Eclipse has (early GUI editor, and built-in Tomcat, Ant, JUnit...).
And, yes, I do most of my development in Eclipse, but I check out each release of NetBeans, and even try to continue to evangelize it.
Try not to be one who thinks that everyone should just join the "leader" as it often stifles competition, advances, and options. Someday Eclipse will catch up and have a GUI editor, BEPL and UML GUI tools, and some of the other flexibilites that NetBeans 5.5 has now.
I'm not using a stop-watch, but most hour-long TV shows in the US contain about 40-45 minutes of content when you block out the four two-to-five-minute long commercial breaks and the opening and end credits. Sometimes less if you skip the "previously" teasers. Looking quick at Wikipedia, and the article article seems to agree with my watch-less estimates.
We DVR all television that we want to watch and burn through a three-hour set of shows in about half that long, including rewinds for over-fast-forwarding over commercials and titles. The only "shows" we watch "live" are sporting events and the news, if we bother, 'cause you'd know the outcome the next day anyway if you bothered to DVR them.
Slashdot Mirror
Sadly, this is the norm I run into, and far too oft from people who are strongly OS-aligned; they can't keep their computer from breaking no matter what they run.
Some of us forget, computers are hard... Especially for the untrained. We didn't get "Computer Fun" degrees, after all. Although, that would be pretty sweet!
Too many people expect a "toaster" or "television" experience from a rather complicated piece of equipment. Heck, some of the folk I help with PC issues have toaster and television issues!
I thought that was the end of Die Hard.
Any of us old engineering university types (with significant knowledge of OS and their inner workings) can point out the same failures in some situations for all OS.
The reason LINUX continues to fail in the eyes of those with a "plug it in and it works" level of expertise is that they want it to plug it in and have it work like the other OS they like. They all have their benefits. They all have their pitfalls. If you try to treat them as interchangeable items, disappointment will abound.
When pulling down even an easy to install distro like Ubuntu, it will have trouble if you're trying to add it to a "designed for Windows" computer. Some little piece, or a whole bunch of them, will have been chosen because of an available, sometimes proprietary driver, which suddenly makes it frustrating when trying to use something else.
Instead, try it on a computer with "standard" components and you'll probably have more success. Then it becomes an issue of interface preference (read, desktop), desired software availability (as in, pick your word processor), and external compatibility (e.g., document sharing). A little comfort, perhaps some training, and they all start to look the same, and work the same, and have perks and quirks.
I liken it to cars when talking to some of those engineering university types, or even dumber people; while they all function "the same," and all use "the same" technology, you accept that your make (and even model) of automobile has less than generic parts; why is that so hard to grasp for computers? Heck, this may even be a case of someone discounting an entire line of automobiles because one time they were in one that ran out of gas, therefore, that kind of auto must be teh sux0rz.
I say, quit telling people what they can or cannot do to themselves, and let the gamblers gamble. If you, Minnesota, want to do something about on-line gambling, figure out a way to squeeze taxes in there and make it a revenue stream and not a cost-center.
Still funny.
Groovy is to Java as PERL is to C. Many similarities, plenty of points of comparison, some interactivity, arguably some interchangeability. It is not a "super set" or even an extension. It's a new language, written in another language. It's a scripting tool, written in Java, that optionally generates Java for execution not in a Groovy engine.
It doesn't give you "compiled Java" any more than Java gives you compiled Java, and other tools (like gjc) give you native executables from software written in Java.
It's got good. It's got bad. It's new. It leverages old. If you're going to use it, you've got to learn it.
No magic, just different.
Before we dig into the viability of such a service, consider a similar service that already exists. Surely you've heard of jukeboxes. They have them in diners and bars near you, I'm sure. I think most offer a small number of songs for a number of pennies each (three for a quarter, or whatever). You plunk in your change, pick from the limited list, wait for your turn in the queue, listen eventually to your song, and move on. Repeat as desired.
Moving on from whether or not the service may be viable, if YOU read the article, you'll see that you were wrong in your understanding of how it works.
The article at the first link says "For just 10 cents you'll be able to select a song to add to your Music Locker to play whenever you like." (I copied and pasted between the quotes...) Not per listen, as you suggest, but per song. In case you don't want to scour the whole article, it's the second sentence in the first paragraph...
If you follow the seekrit link and look at the "how it works," (link at the bottom) you'll see that in fact you can actually listen to any song for free, once (first question), not dropping the dime to see if you like the song. It also confirms that for your thin dime, you add the song to your list to listen to again any time you want (second question). Additionally, if you want to download the song to another device (iPod, for example), that dime counts towards the purchase of that song.
That all seems better than a diner jukebox to me.
This will work for some, if not many.
I didn't read the article, but at first glance thought the title was "racists might pass Turing test."
I had the opposite, but same idea. What if we could get sea-going cows? No, not manatee, but a whale-sized cow, that is made of beef, and isn't land-locked. Perhaps you corral them in lakes or bays, or let them "free range" in the ocean to harvest later. If the "cowhale" were as prolific as their land-based cousins, then we could have an abundance of ocean beef.
Sure, sure, now you pundits will point out that the thing that makes beef tasty is a diet of grass and corn. And there will be those who will point out that a new species of herbivore in the ocean, especially a prolific one, would have drastic environmental consequences, the least of which will be the decimation of ocean prairies and a new source of manure and methane.
I think my thoughts got a little jumbled there, and I meant the comparison conversationally, not quite as technically. I recall that a friend's old Beetles used electric heaters for the passenger compartments, not heated seats. It may have been aftermarket, or perhaps there was just an electric component (e.g., fan?) that made my friend proclaim the heat was electric...
I saw this on the television and thought it looked pretty cool, pun kind of intended.
Arguably one could compress one's own air in the garage with a wind or solar powered compressor and fuel the thing for "free." Certainly that would be an option for some (in windier areas) people and even filling stations. Otherwise, of course, we're just moving the pollution from the streets to the power plants that then have to power all of the compressors.
The thing that kicked the idea for me is that the car seems potentially impractical for those of us that live in temperate regions. For a large part of the year, our vehicles need to generate heat for the passenger compartment. In your typical gas-powered motorized vehicle, this is heat taken from the cooling system. Sure, the old VW Beetle had an electric heater in it, but anybody who had one in sub-zero climates can tell you that they don't always cut it. It's probably the case that the improvements in seat-based heating and technology in general will make the heaters more useful. Perhaps the size of the cabin will help. It also needs to be considered that the light-weight construction of the body may not allow for an awful lot of insulation.
Along the same lines, those tiny wheels wouldn't make it through the snow. A 75HP motor seems like enough to power some larger wheels, but what's the torque like, and how much impact is that larger drive-train gonna have? And once you start adding that bottom weight, how much is that going to force changes in the rest of the car, and will it spiral out of control such that the power plant is no longer sufficient?
In warmer areas, like I'd like to move to, it seems a very practical commuter vehicle. I have to imagine someone has thought of routing the exhaust through a cooling system, allowing the engine to cool the cabin without needing an environmentally unfriendly air conditioner. On good paved roads the tiny wheels might only be a hindrance to top speeds, where larger wheels might be needed for rougher roads, like those with cracks and potholes. (Yeah, I may have a thing against tiny wheels...)
There is also a safety factor. In places where everyone drives small cars, this will fit right in, but in the US, too many SUVs and large sedans compete for the same road as these. It'll probably be the same as with motorcycles; they're safer when you get a bunch of them together than individually ripping through traffic. Once there's a lot of them on the road, this should shift so that the small cars will dominate, and the larger ones will be the exceptions.
Heck, someone should suggest to "reverse" the HOV lanes and force the big vehicles over there, allowing the smaller vehicles to have the other lanes; which could probably be narrowed, and would be less congested as all of the vehicles would be shorter and everyone would be closer to their destination by the time the traffic jam started .
They're not mutually exclusive. Instead, think of them as the corners of a triangle. You call them "cheap," "fast," and "well" (because it makes better sense gramatically) but call them "cost," "speed," and "quality" respectively.
The general, and arguable, assumption is that customers are tied to cost, managers are tied to speed, and developers to quality. Usually the trouble comes from the priorty of each group. Customers tend to lean towards cost, speed, and quality. Managers tend towards speed, quality, and cost. Developers tend to go for quality, speed, cost.
This also aligns with the two-sided client-vendor cost equation; customers want to pay less and vendors want to make more.
Most people act as though they can only choose points only along the sides of the triangles, but this isn't really true. Sometimes it's just harder to recognize compromise to the gradients in the middle of the triangle. With this model, if you're on the line between "cost" and "speed", it appears as though you've completely sacrificed "quality."
In reality you pick from anywhere inside the triangle, including smack on one of the corners. You sacrifice as you move away from the corners, so in the middle you have to compromise all three cost, quality, and speed.
This is an often unrealized (and more often unrealistic) compromise.
I thought I'd share that I guffawed out loud as this caught me. If I had mod points... Funny +1
Kids these days. All their fancy electronics. Missed out on the great, imagination-driven, adventures.
Here.
If only there were another option; some kind of operating environment one could install on one's computer to do one's work. And maybe some other bits and pieces of software that could go with that environment that would still let one perform one's computer-centric duties.
If only there were some way we could get from beneath the crushing foot of this megacorporation and have the freedom to choose. To choose the programs that met our needs, our budgets, and our requirements.
Man, if only.
I always try to move my appointments out a week. It gives me time to get to the things I had to postpone from their original schedule to this week.
Consider also that the bulk of people looking to use Vista are probably already using Windows, and therefore probably already have some method of reading Word documents.
I understand the desire to review the propoganda on some other platform; really that's not hard to do with a Word document either.
And there's the brilliant use of space wherein pages with a header and footer only (see page labeled v), or a single two-line paragraph describe the following pages (see page labeled #9). Surely this could be formatted better to not waste paper, should one want to print the document. Electronically, whatever, printed, big waste.
What I really want to see is the search engine reduce the duplicated content to single entries (try Googling for a Java classname and you'll see how many Google-searched websites have the API on them), or order them by reoccurrance of the word or phrase giving the context more value than the popularity of the page.
In the general, low-tech phishing scheme, though, you've just received an e-mail that looks like its legitimately from an organization with whom you do business, and they hope to steal your login and password, or name and SSN by directing you to a look-alike web site, which will give you a "password failed" message. Too late for you now.
I was outlining the not-gonna-happen scenario where one might believe an unwanted/unsolicited e-mail from what looks like an actual bank/other vendor and try to act on that information.
I personally feel a little safer not using Windows, which is the general target of most phishing, or IE when I do have to use Windows. I also have 4 PCs on my KVM, and would most likely follow-up on a separate system entirely...
It's pretty easy to tell the phish from the non-phish, as I don't bank or shop at most of the places the phishers send my way. Also, should I receive an e-mail from my bank (which they already said they wouldn't send me--believing that snail mail is more secure and less likely to be abused), and I feel the need to get there to deal with whatever the message may be saying, I'm surely not going to click a link. Heck, I probably wouldn't even visit the bank during the same session for fear of some kind of redirect spyware that they tried to sneak into the session.
Looking at the URL and seeing "ebay.somewhere.ch" instead of "ebay.com" isn't secure enough anyway, as it's trivial to spoof the status bar with the hover-over text.
The only way to avoid being phished is to not trust any e-mail that has anything to do with anything related to money, savings, charge cards, or deals that are too good to be true--they are too good to be true. A good runner-up is to find a black-hole mail service (i.e., get your own domain name) and set up an account for each vendor you deal with, with a less-than-likely phishable address (e.g. nvrSp4mMy-ebay@mydomain.us). Then, never give your "real" e-mail address to any site you don't explicitly trust. Or even use the same black-hole method for sites you do trust--like slashdot@mydomain.us), instead opting for a black hole e-mail address; this also helps identify who compromised your identity.
While some software is sometimes better at recognizing these things than others (I seldom get phish-mail at my GMail account, as they're recognized and flagged by the other users first), we still can't rely on an automated method to stop these things. It is on the individual to be responsible with their own information.
"I am not who I seem to be," is the safest way to present yourself to the generally anonymous Internet. That's the way they're presenting themselves.
Let's not forget Savage and Unreal Tournament 2004 with their direct LINUX products, and the whole slew of things the kind folks at Loki port and work on.
Since J2SE1.5, sorry J2SE 5.0, the OS look and feel has been part of the runtime. Yes, the Java runtime does do native calls behind our backs, but that's what the VM is supposed to do. No, I don't want to use layers that limit where I can deploy my software. Perhaps you have the luxury (or would it be drawback?) to develop and deploy on the same OS with the same tools, but some of us have to actually write transportable code; develop on Windows or LINUX, deploy on Solaris, or whatever. Start mixing the real Java tools with the bits and pieces provided by others, especially when they aren't "pure" Java, and you're looking for trouble. Eclipse is dandy. As I said, I use it almost daily. NetBeans is a fine platform, too, and shouldn't be discounted out-of-hand just because one is more familiar than the other. And using either one, or something different, shouldn't affect the code developed within their confines. And I don't speak for Sun, nor do I have any particular information on their "nervousness"; these reflections are mine alone, shared for your entertainment. Finally, to address some of the other comments; both NetBeans and Eclipse are "platforms" not strictly IDEs. As most commonly downloaded (I would imagine--I have no statistics--I'm basing this purely on the packages offered at their respective download web pages) they are Java IDEs. Both can be integrated with C compilers. Both have plug-ins for PERL and PHP and other stuff. Both are easy to extend, and both have solid foundations. Plusses and minuses both. Fewer minuses for Eclipse, sure. Not as many as some would think for NetBeans.
Eclipse is not what you may think it is. Eclipse is the community front-end for the expensive IBM WSAD environment. Most of the places I've worked that use Eclipse do so because they see it as an alternative to the WSAD tools, and they're using WebSphere as the eventual platform; which is truly irrelevant if the software is written corectly.
NetBeans is much more like it looks. Formerly it was the community front-end for Sun's expensive Forte environment, but Sun has since abandoned that for truly the community-driven IDE, backing it with every visit to the JDK download page. And it works just fine with all of the Java application/servlet environments, whether Sun released them or not.
NetBeans is also pure Java, written on Swing, while Eclipse uses its proprietary SWT, which uses native calls to get its GUI work done. You can take the same archive of NetBeans to any J2SE-enabled desktop and it'll work. Not so with Eclipse. Because of this, it's easier to adopt new releases and plug-ins in NetBeans than it is for Eclipse. Many of the third-party add-ons for Eclipse assume or require Windows, and therefore don't work on LINUX, Solaris, Mac, or any of the other envornments. Not so with NetBeans; the plug-ins are also Java, so they work everywhere NetBeans does.
I was a long-time advocate of NetBeans before Eclipse came in to dominate the workplace. Eclipse does win some robustness categories, and its rapid-development bits are a little better (auto-complete/suggest kicks over NetBeans), but both are modular and extendable, and NetBeans has usually come with the tools needed to get the job done before Eclipse has (early GUI editor, and built-in Tomcat, Ant, JUnit...).
And, yes, I do most of my development in Eclipse, but I check out each release of NetBeans, and even try to continue to evangelize it.
Try not to be one who thinks that everyone should just join the "leader" as it often stifles competition, advances, and options. Someday Eclipse will catch up and have a GUI editor, BEPL and UML GUI tools, and some of the other flexibilites that NetBeans 5.5 has now.
We DVR all television that we want to watch and burn through a three-hour set of shows in about half that long, including rewinds for over-fast-forwarding over commercials and titles. The only "shows" we watch "live" are sporting events and the news, if we bother, 'cause you'd know the outcome the next day anyway if you bothered to DVR them.
That has nothing to do with the "preparation," but everything to do with the "H"...