Mcdonalds workers are underpaid. No business which depends for existence on paying less than living wages to its workers has any right to continue in this country
When my kids get their first part-time job as a teenager, I'm not expecting them to earn enough to live on. It should give them spending money, help them pay for car insurance, etc. And more importantly, the job should give them some experience working -- dealing with managers, coworkers, and customers who they may not like, showing up to work whether they feel like it or not, and doing what needs to be done even if it's not precisely in their job description. And it should probably be unpleasant enough to motivate them to do more with their life. An entry-level job at McDonalds might not be my first choice, but it would fit these requirements just fine.
If my kids are still working at McDonalds 10 years later, then I'm not going to be complaining that McDonalds doesn't pay them enough to live -- I'm going to tell my kids to do something with their life and get a real job that requires real skills. And that job will be worth a living wage.
>> What better way to rank a page's relevancy than by determining which links are chosen by the searchers for a given keyword or set of keywords?
> bad side effect...
> page 1 & 2 search results will firmly become engrained there by this method as everyone clicks on the top few results normally
That could be a problem if the results fed directly into the page rank. But it would seem more logical to use this to cull bad links from the top 10. If people consistenly ignore the first link for a particular search, but instead click on the second or third links, it would be a good indication that the top link isn't very good and should be moved down the list, which could in turn allow a new link to bubble up to the top 10.
Disclaimer: I haven't actually used XForms, although I have done some reading on it.
It seems to me that this is actually one of the advantages of XForms. With XForms you specify the validation rules along with your form. Now a smart client can use these rules to validate the form before bothering to send it to the server.
But the server can use those SAME rules to validate the data on the server as well. This is necessary both for working with clients that might not support all of the validation functionality, as well as to prevent people from trying to intentionally bypass validation.
This probably requires a bit of extra work from the "shoddy web programmer", but it should certainly be simpler than implementing all of the validation rules twice (once for the client and once for the server), and especially keeping those rules in sync.
The client doesn't control the Future of Java
on
The Future of Java?
·
· Score: 5, Interesting
I think people make a bigger deal of MS shipping Java than they should. Java on the client has been in pretty sad shape for a long time, yet Java's popularity has grown. It's used a lot for server-side applications, and apparently in embedded applications as well (although I'm not as familiar with that side of things). Whether or not MS ships a decent JVM on Windows doesn't change this -- Java will continue to be used just as it is today.
Does it make a difference for Java on the client? Maybe. Although most of my Java work has been on the server side of things, I have written a couple of Java client apps as well. But those were for use inside the intranet, so it wasn't a big deal to require users to install a JVM. It certainly won't solve all of Java's client-side problems. Performance is much less of a problem than it was in the early JVMs, but most Java clients are still slower than their native counterparts. Perhaps more importantly, there are quite a few bugs in the GUI libraries (both Swing and AWT) that make it difficult to write highly polished applications. And with Swing you get problems with the look-and-feel not matching the native platform, which is a problem for some. But I think that part of the reason why these are still problems is because Java on the client hasn't really taken off -- maybe more of these issues will get solved if people start looking at Java as a valid client platform (because MS is shipping it with Windows) and start writing more client apps.
But regardless of whether it makes a difference, I think the ruling does make sense. MS had a contract to provide a compatible JVM, and they didn't hold up their end of the contract. (At least that's my understanding -- I don't know the complete details of the contract.) Therefore they should have to make ammends -- maybe it is too late to "save Java" on the client, but it shouldn't hurt.
Let's assume for a moment that a VM could provide the behavior you describe. (As another poster mentioned, this would be quite slow as you end up with lots of task switching overhead.)
Now what if you run on a system with two processors? Ideally, you would want each of your two threads to run on a separate processor so you get maximum concurrency. But if they are running concurrently, two operations could be executed simultaneously. So now you might get a mix of a's and b's, instead of strict alternation:
a = 0 b = 0 b = 1 a = 1 b = 2 a = 2
This of course assumes that both processors would stay exactly in sync with each other -- probably not the case.
Now what if there were three threads running on two processors? Now there is no way to keep the three threads running in parallel while keeping both processors busy and achieving the output you suggest.
And this is ignoring the fact that in nearly all cases your program isn't the only thing running on the system -- there are usually some number of operating system processes/threads and other programs running.
So in summary, even if the behavior you described is possible, it isn't going to be practical -- you would end up loosing the ability to run on multiple processors, which eliminates much of the use of your parallel algorithm.
Yep, a platform-independent C/C++ environment would have been great. Except it wouldn't have been platform-independent. C/C++ depend too much on being close to the hardware. Pointer arithmetic, and endian-dependent code come to mind. Use of this type of functionality introduces dependencies on the platform the code is running on.
Of course, they could have put in some special checks to allow the program to determine what the standards are for the particular platform the program is running on. But C/C++ already does this (#ifdefs) and it is gross. Yes, you can write platform-independent C/C++ code, but you have to be careful to avoid certain language features, and the code tends to be a bit difficult to maintain.
Instead, Sun chose to start with a C/C++ish base, and take out a lot of the error-prone constructs (including those which cause platform dependencies). I have found that these constructs are rarely needed: occasionally it would be nice to use some of the "missing" features (I'd be especially happy to have enums back), but in nearly all cases, thinking about the problem for an additional 5 minutes will result in a solution that works just as well, and in most cases the code comes out a bit cleaner in the process.
I'm not saying that Sun did a perfect job coming up with Java. But I will say that for platform independence, Java is much better than C/C++. I'm not just talking about the basic language constructs either: JDBC (for cross-platform, multi-database SQL), Servlets (for cross-platform, multi-web-server CGI-type programs), and other APIs greatly simplify development for server-side applications. I won't speak on the client-side, since I haven't worked as much on that end of things (although the work I have done tells me that I would much rather develop a GUI in Java than some other language, especially if it has to be cross-platform).
Hmmm...reminds me of a program I was working with at work a year or two ago. It was a Java program accessing a database through JDBC, and worked just fine with the database we were using. Then we tried running to an MS SQL Server database instead. Run into a couple of bugs in various MS components (most notably their JDBC driver). After reducing it to a simple test case, we wrote a bug report to MS.
A month or so later we finally got a reply from MS which said that they received our report, but that the problem was in compliance with the spec, and not a bug in their driver. So I replied with a direct quote from the spec that showed that they were indeed doing it wrong.
Another month or so went by, and I got another reply from them. This time they conceded that they didn't match the spec, and assured me that this "feature" would be added in the next version.
Don't know if it ever got fixed...by this time we had given up on it and moved on to other things.
But you're forgetting an additional use of this "innovation". What happens when one of those 1,000 people decides to email his 999 coworkers the latest copy of his 50MB Word file. Now you've got about 50GB of data out on the network, all copies of this single file, which will probably never be modified by those 999 people.
As I understand it, this technique would use just a single copy of the file, saving a bunch of disk space.
Disclaimer: I haven't actually worked on Mozilla, although I've tried it out from time to time, and I keep an eye on the status.
Why is Mozilla taking so long? Is it because it is Open Source? I don't think so.
I think it is taking so long because it is a huge project. A typical piece of software (Open Source or otherwise) would generally start out small, and in future versions would have increased functionality, performance, etc. And this is how the original Netscape started. If Mozilla was trying to recreate Netscape 1.0, they could have been done long ago.
But developing Netscape 1.0 wouldn't be sufficient. Netscape and Mozilla are trying to compete with IE, which has been around for awhile. The original version of IE pretty much stunk. It took a couple of years after the first version to whip it into shape.
Unfortunately, Mozilla can't really follow the "release v1.0 and then improve from there". Because if the world tried the browser and saw all of its limitations, most would give up on Netscape/Mozilla and decide that it would never be up to the competition. Not only would user support drop, but developer support would drop as well. The comments for this article are evidence with this -- many people have given up on Mozilla being able to produce a good browser, and it hasn't even been released yet. Just imagine the comments if the current Mozilla was labeled "v1.0" instead of "alpha".
So when Mozilla is released, it has to be able to compete with browsers that have been around for a few years...including the old Netscape and IE. Yes, Mozilla was able to build off of the old Netscape source, but the developers decided (correctly in my opinion) that now (or rather, near the beginning of the project) would be the best time to remove all of the junk that had accumulated over the years, and redesign the browser so that it could be more useful, more easily maintained, and more easily extended.
So why is it taking so long? Because the Mozilla developers are trying to write a world-class browser that implements technology that has been developed over a period of years in as little time as possible. Not an easy task.
Oh, and BTW, how do you like that crappy little calculator that does come with windows? I use it all the time, but I sure wish there was an exponential function, etc, etc.
I hate that calculator too, but it is more powerful than it would first appear. Go to the "View" menu, and select "Scientific". You'll get a bunch more buttons to use.
I realize that price discrimination doesn't happen when there is enough competition. Ideally, there would be more competition in this market, and that would drive down the prices further and spark more advancements as the various producers compete for marketshare.
But that's not how it is today. We've got Intel, AMD, and maybe a couple other smaller companies. That's not going to change in the immediate future, so for now we can just consider what would work best given the current market.
Option 1: Intel leaves SMP enabled the Celeron. This creates a relatively narrow difference between the "low-end" Celeron chips and the "high-end" PIII/Xeon. Many buyers (primarily companies) realize that an SMP Celeron setup is sufficient for their needs. Sales of Celeron go up. Sales of PIII/Xeon go down. In order to maintain maximum profitability, Intel must make price of Celeron relatively higher. (The price may still go down as costs decrease, but it would be higher than it would be with less demand.)
Option 2: Intel makes SMP an important difference between Celeron and PIII/Xeon by disabling it in Celeron. Celeron is now aimed at the low-end market (where it was originally intended for). It is no longer competing with Intel's high-end chips, and therefore can be priced lower without hurting profits. Less demand for the chip (since it is aimed at a smaller portion of the market) will also help keep prices down.
Either way, competition is still the major force keeping the prices down. The more competition, the better. But with the low number of competitors, it is better to have multiple differentiated products at different price levels than essentially one product at one price.
I'm not a big Intel fan, and I hope that they do continue to allow SMP on the Celeron. However, it would seem perfectly reasonable for them not to, and could actually (possibly) be a good thing.
It's been a few years since my economics courses, but most of it is common sense anyway. A business can maximize their profit by selling everything at the highest cost a consumer is willing to pay. Of course, this cost is different for each consumer, making this goal very hard to achieve. The airlines have come about the closest. Everybody else generally has to aim for finding the price that will attract a sufficient number of consumers with a significant enough profit margin.
One way to help increase the number of consumers willing to buy your product without lowering profit margins too far is to offer multiple similar products with different feature levels. For example, when buying a car, there are usually a few variations on the same model (e.g. Honda Accord DX, LX, EX) at different prices. This allows the company to sell their product at three different prices, hoping that the additional features of the more expensive variations will encourage people to buy them, while the cheaper versions will attract those consumers who do not want to spend a lot of money on their car, and are willing to sacrifice some features.
Intel is doing the same thing. They have several chips, all with the basic function of executing x86 instructions. They know that some people are willing to spend several hundred dollars for a chip that will execute the instructions, while other people are only willing to spend less than $100. If they sold all of their chips at the sub-$100 price, they couldn't afford to develop or include some of the features of the more advanced chips. But if they sold all of their chips at the several hundred dollar range, they would lose a lot of business from customers who are not willing to spend that much.
Thus, Intel offers several chips with different features. Now their goal is to balance price with features to get as many customers buying their chips for as much as possible. The introduction of the Celeron was aimed to help do this, by providing a good performing processor for a relatively low cost. Intel's competitors were having a significant impact in this area of the customer base. However, Intel did not want the introduction of the Celeron to impact sales in the server market, where they had little competition.
Well, the Celeron turned out to be a bit too powerful. Intel found that a lot of people were content with the Celeron for higher-end machines, at a much cheaper price (and therefore, less money for Intel). Disabling SMP is a way that Intel can continue to offer this cheaper processor while providing incentive for customers to use the more expensive PII/PIII/Xeon chips for their server machines.
This is not entirely bad for the consumer. It (potentially) allows Intel to keep the Celeron cheaper in order to compete without drawing business away from their other chips. And it may even (potentially) allow Intel to keep the higher-end chips cheaper because of increased demand for those processors. Whether these potential savings become real probably depends a lot on AMD, since competition will be the major driving force in keeping prices low.
Anyway, that's my 2 cents. I don't care a whole lot, since my next machine will probably be an AMD.
Nope, the slot-loading ones are no good. A few weeks ago I was helping a coworker set up Linux on a box with a slot-loading CD drive. We were making a boot disk, and he reached down to put the disk in. Accidentally missed the floppy drive and stuck it in the CD drive instead. Then we got to spend the next half hour trying to get the floppy back out without ruining anything.:)
I don't mean to bash Java the language, I just really would have liked to have seen it go from being Sun's Java to a Useful Java.
I'd be curious to hear what shortcomings you find that prevents Java from being "Useful". I wouldn't be surprised to hear some, but I've been using Java for a couple years now, and other than the seemingly long time it takes for an API to go from specification to being on the average person's system, I have few real complaints.
JDBC, while not perfect, is certainly the easiest database programming I've done. Last week I helped somebody with a quick program to dump an Oracle database on Solaris out to an AS/400 database....not something I'd want to do using vendor-specific APIs.
Currently I'm in the middle of a rather large servlet (currently on the order of 10,000 LOC). While I'm sure it could have been done just as well in Perl, I don't think it would be nearly as maintainable or flexible....which is important since the requirements for the project often change a couple times per week.
I've also done a fair amount of GUI programming in Java. (The largest project has about 12,000 lines of GUI code, and 10,000 lines of DB and processing code to give the GUI something to display.) Swing certainly provides the easiest and most flexible GUI programming I've done. Unfortunately, it's still got a fair number of bugs and runs rather slowly, but that's been improving over the past few months, and should continue.
Having said all that, I should mention that I certainly don't believe that Java is the solution to all the world's problems. I still use Perl for a lot of utility programs. Since my job is Java, I don't do much with C/C++ these days, but they certainly have their place to. (Although perhaps I should start an effort to rewrite the Linux kernel in Java.):)
On a more relevant note, Visual Age is pretty good IDE. I've been using it for development of that servlet. It would be nice if vi could be embedded as the editor, but nothing's perfect. My biggest complaint is that it requires so much RAM to run. But it is one of the few IDEs I've used that really seems to offer more than I already get with a text editor and command-line compiler.
Likewise, picking your field is important. If you choose incorrectly, you will be forced to work your butt off learning things that just don't interest you. Don't be afraid to change fields once you have already enrolled; it's better to lose a year than to stick with something you don't like and lose four years. It will still be worth it.
To take this one step further (and assuming you want to go into CS), it can be important to know which college the CS department is associated with. If it is with engineering and all you want to do is program, you're probably going to end up with a bunch of classes you don't want to take. At my school, CS was part of the college of science, which made them rather independent, since CS has few practical similarities with the other sciences.
Personally, I thought school was quite worthwhile. The classes were okay....sometimes I learned something useful, and other times I didn't really learn anything at all. There were a few things (mostly computer theory) I thought I would never use, and since then have found some of these things quite useful. I would have been happy to skip some of the non-computer classes, but many of them turned out to be rather helpful as well.
But the most worthwhile part of college was the things outside of class. I think college teaches you a lot about people, and yourself, that you don't get nearly as easily from the workplace.
As somebody else already mentioned, you can't expect school to make you a good programmer. They can teach you the techniques, but they can't give you the desire or talent necessary, just like no amount of art school could possibly make me an artist. Programming is an art of its own.
You'll have (hopefully) 40 years to make big bucks in the workplace....taking 4-5 years for college won't hurt. And (if you're going to the right school, etc) it will be some of the most enjoyable years you have.
Finger works fine -- unless the person you are looking for happens to be on a Windows box or another machine that isn't running a finger server, or a machine running a finger server but doesn't actually give any useful information (which seems to be the trend these days).
ytalk works fine -- assuming the person is on a machine with a talk client (and server? I can't remember). And (as you mentioned) is computer literate (or, more precisely, UNIX/command-line literate).
Instant messaging has its place, as do IRC, talk, etc. It is especially convenient for running in the background while doing other work. Instant messaging doesn't replace these programs...it fills a slightly different need.
Slashdot Mirror
Mcdonalds workers are underpaid. No business which depends for existence on paying less than living wages to its workers has any right to continue in this country
When my kids get their first part-time job as a teenager, I'm not expecting them to earn enough to live on. It should give them spending money, help them pay for car insurance, etc. And more importantly, the job should give them some experience working -- dealing with managers, coworkers, and customers who they may not like, showing up to work whether they feel like it or not, and doing what needs to be done even if it's not precisely in their job description. And it should probably be unpleasant enough to motivate them to do more with their life. An entry-level job at McDonalds might not be my first choice, but it would fit these requirements just fine.
If my kids are still working at McDonalds 10 years later, then I'm not going to be complaining that McDonalds doesn't pay them enough to live -- I'm going to tell my kids to do something with their life and get a real job that requires real skills. And that job will be worth a living wage.
>> What better way to rank a page's relevancy than by determining which links are chosen by the searchers for a given keyword or set of keywords?
> bad side effect...
> page 1 & 2 search results will firmly become engrained there by this method as everyone clicks on the top few results normally
That could be a problem if the results fed directly into the page rank. But it would seem more logical to use this to cull bad links from the top 10. If people consistenly ignore the first link for a particular search, but instead click on the second or third links, it would be a good indication that the top link isn't very good and should be moved down the list, which could in turn allow a new link to bubble up to the top 10.
Disclaimer: I haven't actually used XForms, although I have done some reading on it.
It seems to me that this is actually one of the advantages of XForms. With XForms you specify the validation rules along with your form. Now a smart client can use these rules to validate the form before bothering to send it to the server.
But the server can use those SAME rules to validate the data on the server as well. This is necessary both for working with clients that might not support all of the validation functionality, as well as to prevent people from trying to intentionally bypass validation.
This probably requires a bit of extra work from the "shoddy web programmer", but it should certainly be simpler than implementing all of the validation rules twice (once for the client and once for the server), and especially keeping those rules in sync.
I keep this link in my bookmarks for times like this: Apples and Oranges -- A comparison
I think people make a bigger deal of MS shipping Java than they should. Java on the client has been in pretty sad shape for a long time, yet Java's popularity has grown. It's used a lot for server-side applications, and apparently in embedded applications as well (although I'm not as familiar with that side of things). Whether or not MS ships a decent JVM on Windows doesn't change this -- Java will continue to be used just as it is today.
Does it make a difference for Java on the client? Maybe. Although most of my Java work has been on the server side of things, I have written a couple of Java client apps as well. But those were for use inside the intranet, so it wasn't a big deal to require users to install a JVM. It certainly won't solve all of Java's client-side problems. Performance is much less of a problem than it was in the early JVMs, but most Java clients are still slower than their native counterparts. Perhaps more importantly, there are quite a few bugs in the GUI libraries (both Swing and AWT) that make it difficult to write highly polished applications. And with Swing you get problems with the look-and-feel not matching the native platform, which is a problem for some. But I think that part of the reason why these are still problems is because Java on the client hasn't really taken off -- maybe more of these issues will get solved if people start looking at Java as a valid client platform (because MS is shipping it with Windows) and start writing more client apps.
But regardless of whether it makes a difference, I think the ruling does make sense. MS had a contract to provide a compatible JVM, and they didn't hold up their end of the contract. (At least that's my understanding -- I don't know the complete details of the contract.) Therefore they should have to make ammends -- maybe it is too late to "save Java" on the client, but it shouldn't hurt.
Let's assume for a moment that a VM could provide the behavior you describe. (As another poster mentioned, this would be quite slow as you end up with lots of task switching overhead.)
Now what if you run on a system with two processors? Ideally, you would want each of your two threads to run on a separate processor so you get maximum concurrency. But if they are running concurrently, two operations could be executed simultaneously. So now you might get a mix of a's and b's, instead of strict alternation:
a = 0
b = 0
b = 1
a = 1
b = 2
a = 2
This of course assumes that both processors would stay exactly in sync with each other -- probably not the case.
Now what if there were three threads running on two processors? Now there is no way to keep the three threads running in parallel while keeping both processors busy and achieving the output you suggest.
And this is ignoring the fact that in nearly all cases your program isn't the only thing running on the system -- there are usually some number of operating system processes/threads and other programs running.
So in summary, even if the behavior you described is possible, it isn't going to be practical -- you would end up loosing the ability to run on multiple processors, which eliminates much of the use of your parallel algorithm.
Yep, a platform-independent C/C++ environment would have been great. Except it wouldn't have been platform-independent. C/C++ depend too much on being close to the hardware. Pointer arithmetic, and endian-dependent code come to mind. Use of this type of functionality introduces dependencies on the platform the code is running on.
Of course, they could have put in some special checks to allow the program to determine what the standards are for the particular platform the program is running on. But C/C++ already does this (#ifdefs) and it is gross. Yes, you can write platform-independent C/C++ code, but you have to be careful to avoid certain language features, and the code tends to be a bit difficult to maintain.
Instead, Sun chose to start with a C/C++ish base, and take out a lot of the error-prone constructs (including those which cause platform dependencies). I have found that these constructs are rarely needed: occasionally it would be nice to use some of the "missing" features (I'd be especially happy to have enums back), but in nearly all cases, thinking about the problem for an additional 5 minutes will result in a solution that works just as well, and in most cases the code comes out a bit cleaner in the process.
I'm not saying that Sun did a perfect job coming up with Java. But I will say that for platform independence, Java is much better than C/C++. I'm not just talking about the basic language constructs either: JDBC (for cross-platform, multi-database SQL), Servlets (for cross-platform, multi-web-server CGI-type programs), and other APIs greatly simplify development for server-side applications. I won't speak on the client-side, since I haven't worked as much on that end of things (although the work I have done tells me that I would much rather develop a GUI in Java than some other language, especially if it has to be cross-platform).
Hmmm...reminds me of a program I was working with at work a year or two ago. It was a Java program accessing a database through JDBC, and worked just fine with the database we were using. Then we tried running to an MS SQL Server database instead. Run into a couple of bugs in various MS components (most notably their JDBC driver). After reducing it to a simple test case, we wrote a bug report to MS.
A month or so later we finally got a reply from MS which said that they received our report, but that the problem was in compliance with the spec, and not a bug in their driver. So I replied with a direct quote from the spec that showed that they were indeed doing it wrong.
Another month or so went by, and I got another reply from them. This time they conceded that they didn't match the spec, and assured me that this "feature" would be added in the next version.
Don't know if it ever got fixed...by this time we had given up on it and moved on to other things.
But you're forgetting an additional use of this "innovation". What happens when one of those 1,000 people decides to email his 999 coworkers the latest copy of his 50MB Word file. Now you've got about 50GB of data out on the network, all copies of this single file, which will probably never be modified by those 999 people.
As I understand it, this technique would use just a single copy of the file, saving a bunch of disk space.
Disclaimer: I haven't actually worked on Mozilla, although I've tried it out from time to time, and I keep an eye on the status.
Why is Mozilla taking so long? Is it because it is Open Source? I don't think so.
I think it is taking so long because it is a huge project. A typical piece of software (Open Source or otherwise) would generally start out small, and in future versions would have increased functionality, performance, etc. And this is how the original Netscape started. If Mozilla was trying to recreate Netscape 1.0, they could have been done long ago.
But developing Netscape 1.0 wouldn't be sufficient. Netscape and Mozilla are trying to compete with IE, which has been around for awhile. The original version of IE pretty much stunk. It took a couple of years after the first version to whip it into shape.
Unfortunately, Mozilla can't really follow the "release v1.0 and then improve from there". Because if the world tried the browser and saw all of its limitations, most would give up on Netscape/Mozilla and decide that it would never be up to the competition. Not only would user support drop, but developer support would drop as well. The comments for this article are evidence with this -- many people have given up on Mozilla being able to produce a good browser, and it hasn't even been released yet. Just imagine the comments if the current Mozilla was labeled "v1.0" instead of "alpha".
So when Mozilla is released, it has to be able to compete with browsers that have been around for a few years...including the old Netscape and IE. Yes, Mozilla was able to build off of the old Netscape source, but the developers decided (correctly in my opinion) that now (or rather, near the beginning of the project) would be the best time to remove all of the junk that had accumulated over the years, and redesign the browser so that it could be more useful, more easily maintained, and more easily extended.
So why is it taking so long? Because the Mozilla developers are trying to write a world-class browser that implements technology that has been developed over a period of years in as little time as possible. Not an easy task.
I hate that calculator too, but it is more powerful than it would first appear. Go to the "View" menu, and select "Scientific". You'll get a bunch more buttons to use.
I realize that price discrimination doesn't happen when there is enough competition. Ideally, there would be more competition in this market, and that would drive down the prices further and spark more advancements as the various producers compete for marketshare.
But that's not how it is today. We've got Intel, AMD, and maybe a couple other smaller companies. That's not going to change in the immediate future, so for now we can just consider what would work best given the current market.
Option 1: Intel leaves SMP enabled the Celeron. This creates a relatively narrow difference between the "low-end" Celeron chips and the "high-end" PIII/Xeon. Many buyers (primarily companies) realize that an SMP Celeron setup is sufficient for their needs. Sales of Celeron go up. Sales of PIII/Xeon go down. In order to maintain maximum profitability, Intel must make price of Celeron relatively higher. (The price may still go down as costs decrease, but it would be higher than it would be with less demand.)
Option 2: Intel makes SMP an important difference between Celeron and PIII/Xeon by disabling it in Celeron. Celeron is now aimed at the low-end market (where it was originally intended for). It is no longer competing with Intel's high-end chips, and therefore can be priced lower without hurting profits. Less demand for the chip (since it is aimed at a smaller portion of the market) will also help keep prices down.
Either way, competition is still the major force keeping the prices down. The more competition, the better. But with the low number of competitors, it is better to have multiple differentiated products at different price levels than essentially one product at one price.
I'm not a big Intel fan, and I hope that they do continue to allow SMP on the Celeron. However, it would seem perfectly reasonable for them not to, and could actually (possibly) be a good thing.
It's been a few years since my economics courses, but most of it is common sense anyway. A business can maximize their profit by selling everything at the highest cost a consumer is willing to pay. Of course, this cost is different for each consumer, making this goal very hard to achieve. The airlines have come about the closest. Everybody else generally has to aim for finding the price that will attract a sufficient number of consumers with a significant enough profit margin.
One way to help increase the number of consumers willing to buy your product without lowering profit margins too far is to offer multiple similar products with different feature levels. For example, when buying a car, there are usually a few variations on the same model (e.g. Honda Accord DX, LX, EX) at different prices. This allows the company to sell their product at three different prices, hoping that the additional features of the more expensive variations will encourage people to buy them, while the cheaper versions will attract those consumers who do not want to spend a lot of money on their car, and are willing to sacrifice some features.
Intel is doing the same thing. They have several chips, all with the basic function of executing x86 instructions. They know that some people are willing to spend several hundred dollars for a chip that will execute the instructions, while other people are only willing to spend less than $100. If they sold all of their chips at the sub-$100 price, they couldn't afford to develop or include some of the features of the more advanced chips. But if they sold all of their chips at the several hundred dollar range, they would lose a lot of business from customers who are not willing to spend that much.
Thus, Intel offers several chips with different features. Now their goal is to balance price with features to get as many customers buying their chips for as much as possible. The introduction of the Celeron was aimed to help do this, by providing a good performing processor for a relatively low cost. Intel's competitors were having a significant impact in this area of the customer base. However, Intel did not want the introduction of the Celeron to impact sales in the server market, where they had little competition.
Well, the Celeron turned out to be a bit too powerful. Intel found that a lot of people were content with the Celeron for higher-end machines, at a much cheaper price (and therefore, less money for Intel). Disabling SMP is a way that Intel can continue to offer this cheaper processor while providing incentive for customers to use the more expensive PII/PIII/Xeon chips for their server machines.
This is not entirely bad for the consumer. It (potentially) allows Intel to keep the Celeron cheaper in order to compete without drawing business away from their other chips. And it may even (potentially) allow Intel to keep the higher-end chips cheaper because of increased demand for those processors. Whether these potential savings become real probably depends a lot on AMD, since competition will be the major driving force in keeping prices low.
Anyway, that's my 2 cents. I don't care a whole lot, since my next machine will probably be an AMD.
Nope, the slot-loading ones are no good. A few weeks ago I was helping a coworker set up Linux on a box with a slot-loading CD drive. We were making a boot disk, and he reached down to put the disk in. Accidentally missed the floppy drive and stuck it in the CD drive instead. Then we got to spend the next half hour trying to get the floppy back out without ruining anything. :)
I'd be curious to hear what shortcomings you find that prevents Java from being "Useful". I wouldn't be surprised to hear some, but I've been using Java for a couple years now, and other than the seemingly long time it takes for an API to go from specification to being on the average person's system, I have few real complaints.
JDBC, while not perfect, is certainly the easiest database programming I've done. Last week I helped somebody with a quick program to dump an Oracle database on Solaris out to an AS/400 database....not something I'd want to do using vendor-specific APIs.
Currently I'm in the middle of a rather large servlet (currently on the order of 10,000 LOC). While I'm sure it could have been done just as well in Perl, I don't think it would be nearly as maintainable or flexible....which is important since the requirements for the project often change a couple times per week.
I've also done a fair amount of GUI programming in Java. (The largest project has about 12,000 lines of GUI code, and 10,000 lines of DB and processing code to give the GUI something to display.) Swing certainly provides the easiest and most flexible GUI programming I've done. Unfortunately, it's still got a fair number of bugs and runs rather slowly, but that's been improving over the past few months, and should continue.
Having said all that, I should mention that I certainly don't believe that Java is the solution to all the world's problems. I still use Perl for a lot of utility programs. Since my job is Java, I don't do much with C/C++ these days, but they certainly have their place to. (Although perhaps I should start an effort to rewrite the Linux kernel in Java.) :)
On a more relevant note, Visual Age is pretty good IDE. I've been using it for development of that servlet. It would be nice if vi could be embedded as the editor, but nothing's perfect. My biggest complaint is that it requires so much RAM to run. But it is one of the few IDEs I've used that really seems to offer more than I already get with a text editor and command-line compiler.
To take this one step further (and assuming you want to go into CS), it can be important to know which college the CS department is associated with. If it is with engineering and all you want to do is program, you're probably going to end up with a bunch of classes you don't want to take. At my school, CS was part of the college of science, which made them rather independent, since CS has few practical similarities with the other sciences.
Personally, I thought school was quite worthwhile. The classes were okay....sometimes I learned something useful, and other times I didn't really learn anything at all. There were a few things (mostly computer theory) I thought I would never use, and since then have found some of these things quite useful. I would have been happy to skip some of the non-computer classes, but many of them turned out to be rather helpful as well.
But the most worthwhile part of college was the things outside of class. I think college teaches you a lot about people, and yourself, that you don't get nearly as easily from the workplace.
As somebody else already mentioned, you can't expect school to make you a good programmer. They can teach you the techniques, but they can't give you the desire or talent necessary, just like no amount of art school could possibly make me an artist. Programming is an art of its own.
You'll have (hopefully) 40 years to make big bucks in the workplace....taking 4-5 years for college won't hurt. And (if you're going to the right school, etc) it will be some of the most enjoyable years you have.
Finger works fine -- unless the person you are looking for happens to be on a Windows box or another machine that isn't running a finger server, or a machine running a finger server but doesn't actually give any useful information (which seems to be the trend these days).
ytalk works fine -- assuming the person is on a machine with a talk client (and server? I can't remember). And (as you mentioned) is computer literate (or, more precisely, UNIX/command-line literate).
Instant messaging has its place, as do IRC, talk, etc. It is especially convenient for running in the background while doing other work. Instant messaging doesn't replace these programs...it fills a slightly different need.