Several folks are advocating a different model. It doesn't involve
programmers working for nothing. It involves both money-making
companies and free software.
Suppose the government (or a school board, or a bank...) needed a
disk repartitioning tool. They previously had a few choices:
Find a commercial package and license it.
Develop it in house.
Hire an outside firm to develop it for them.
The "new" idea here is this: the company or government in question is
not in the software development business. They just want to get their
job done. They can develop it in house, or contract out the
programming and make sure it is in their contract that they are able
to give away the source code.
Why would they want to do this? Naive reasons include it "feels
good", or free support will fall from the sky. Better reasons
include:
If the software is truly useful to others and they improve it
(perhaps contracting out the job of creating improvements to the same
or other development firms) then the original developers could benefit
from those improvements.
If they get unhappy with their current development firm it might
be easier to hire another development firm to maintain the software if
the source is unencumbered.
If a quick or minor change is needed in the software then the
source is available to do this, without having to negotiate with an
outside development firm.
Once you have paid for the development of the software there are no longer recurring expenses such as licensing fees or compliance audits. The cost of maitenance may be cheaper.
My main point is this: Free software does not have to be built by
volunteers. You can hire professional developers to create and
maintain free software if your business or government relies on this
software. "Open source" and "free software" are two models
for doing this.
There exists an example of this. Gcc is licensed under the GPL.
Many people rely on it for their jobs: this compiler is used by many
folks to create code for embedded applications, unusual hardware,
research, and mainstream applications. Often a company will need a
specific improvement, or need it to be ported to a new operating
system, or support for new hardware, etc. It appears that Cygnus
exists mainly for the purpose of doing paid improvements to gcc. (I
have worked for companies that have hired them for exactly that.) The
folks who work for Cygnus don't work for free, and they often are
quite good at what they do. Many other programs could follow similar
models...
Re:One thing I've NEVER seen here....
on
Fair IP Laws?
·
· Score: 5, Insightful
I believe the fundamental reason why software patents are viewed as flawed is cultural. Software developers are taught from day one that modularity is the best way of creating software. You start with your toolbox of parts (perhaps the functions provided by the OS and standard C libraries), and you build them up into more useful parts, which you then package as a new library. You then integrate those parts together into a program, which solves a problem in a useful way.
The software engineer builds up a toolbox over time -- perhaps by creating lots of programs, by sharing with other engineers, or by purchasing libraries from other companies. It is assumed that if you write some code starting with just what you think up and what you find in your (legally acquired) libraries you end up with a piece of work that is yours to use and sell. Under copyright law this is true -- you only break the law if you copy someone else's code without their permission. Since it is clear who owns each piece of code, you know clearly if you are breaking the rules.
Patents don't work this way. It is possible for an average programmer to write a program and not know they are violating a patent. The program can be used and/or sold for years without any clue that a patent is being violated. If the patent owner finds out, they can sue! If patents were only granted for truely novel software techniques that were not likely to be independently re-invented, then this would not be a problem. But this is not the case -- programmers have a valid fear that any piece of code they write might be violating somebody's patent.
The software design process (as we know it) has no easy way for incorporating a patent search. Fear of being blindsided by a patent violation can fundamentally change how software development is currently done, by adding significant extra time and manpower to any project to ensure it is not infringing on any patents.
As an attorney, would you like it if you could be randomly hit by lawsuits from other lawyers even though you are just doing your job? If for every case you prosecuted or defended you had to think up entirely new arguments on behalf of your clients, out of fear of re-using a patented argument that someone else has used before? Programmers like to create software, and like to use available techniques for doing so. Having to constantly worry about which techniques are currently "allowed" or "forbidden" just detracts from the real job to be done.
I notice that they make a big deal out of the fact that this new chip has 80 million transistors, and compare this to modern CPUs. This is quite a lot of transistors, but says nothing of the wiring cost. I would think that the regular structure of a GPU would make wiring costs much lower than on a CPU.
Does anyone know what the die area of Matrox's new chip is? I am curious how that compares to CPUs, and if graphics processors are much more dense than regular CPUs.
Try this: hold a gun by its grip in your right hand. Place your left hand over the top of it, with your thumb behind the hammer. Pull the trigger. Scream in pain, as the motion of the slide breaks your thumb, and the ejecting shell casing burns your palm. Now do this another 8 times as the bad guy runs accross the room.
When I bought my first PC (I was a former Amiga addict) I had decided I wanted to run OS/2 on it. Being a poor high school student, I went comparison shopping on prices. Here is what I found in the stores in Toronto:
OS/2 2.1: $199
Windows 3.1 OEM edition: $45
OS/2 upgrade from Windows: $50
At the time I didn't want Windows, but the pricing scheme forced me to buy it anyways. Rediculous. Once I got it I discovered that the memory requirement of 8MB was a joke -- OS/2 was never happy doing any real work with less than 32MB, and as a student I could never afford to buy that much RAM...
Programs that catch cheating become more useful when you have a larger class. If you split up the grading over multiple TAs then you may not find these patterns. But once one of these utilities flags two submissions as being similar, it is very easy to tell if foul play was at work.
If your assignment is well designed, it is often possible to give a "right" answer, or to also give an "inspired" answer. To give an inspired answer requires creativity and insight into the problem -- if two students give the same inspired answer, then it is often worth looking closer as well.
When you are doing this, you have to keep in mind why you are doing these checks: in an intro class, you have to make sure that students are actually learning the material. Projects are often not worth that much, but if the students copy work on the projects then they will probably fail the exams. It is better to catch them early and show them how to do their own work than for them to wait until the end of the semester to fail the class.
Re:My take & link to Philly Inquirer original
on
Review: Black Hawk Down
·
· Score: 2, Informative
As a history piece, from what I have read, the movie is right on.
I watched this movie yesterday afternoon. I have also read the book. The movie was nothing like the book -- the amount of pure spin in the movie was sickening. Why did the movie completely ignore the Somali's side of the story? There was a reason why the entire city rose up and attacked the US soldiers -- they were sick and tired of their disruptive presence, and decided that the "evil warlords" were easier to tolerate than the US soldiers.
Before you pass any judgements, read the book too. Please.
I too started programming at 12 -- and when I graduated from high school I was not sure what I would get out of university. I was amazed at how much I didn't pick up from all the books I had read.:-)
You mention you want to go to grad school after you finish your undergrad degree. Chances are you will have to write the GRE CS subject test for your grad school application. Why not write it now, and see how you do? It might give you an approximate idea of how much computer science (as opposed to just programming) you have managed to pick up over the years.
If you had kept up with the updates as they came out (as all people who maintain and operate a computer should), you would have gotten the intermediate versions of RPM and glibc that eased the transition.
Do you use your a computer as a toy, or to get a job done? I use my computer as a tool -- and having the software I am running and rely on constantly changing does not help me get my job done. I upgrade my machine when newer software has an important feature that will help me be more productive (and make up for the time wasted in upgrading).
Playing the "kernel of the month club" game is not a good use of my time -- and I suspect this is true for most people who "operate and maintain a computer".
Mirror mirror on the wall
on
KDE 2.2.2
·
· Score: 1
So when can we expect to see the RedHat packages on the US KDE mirrors? It is weird that they are announcing the new version before the mirrors get a chance to copy the files and reduce server load...
I just tried it out under RedHat 7.2. When I tried Quicktime it had no problem playing movies, but there is no sound. I tried using the powerpoint viewer on a presentation of mine, and all the fonts were messed up.
So it still has a few rough edges. If it worked flawlessly, they would get my money right away...
With the development that the rest of the computer industry undergoes (ref. Moores Law) - why has the development in the HD department been in a state of virtual stand-still?
I am not sure if you are serious or not. If you compare the trends in storage to the trends in CMOS fabrication, you will find that the rate of change in storage capacities, price per MB, and transfer rates leave Moore's Law in the dust.
Why is this? It is because CMOS benefits primarily from improvements in photolithography. Hard drive heads are made using photolithography as well -- and every time you can produce smaller chips, you can also produce smaller hard drive heads. This means they are more precise, and can squeeze more data into less space. If you improve storage density, you make hard drives larger, faster (you have to move the head less to reach your data), and cheaper (you can use fewer platters to store the same amount of data). There is research into the materials used to store the data itself. Any improvements in the materials also improves the density of storage. In addition, there is the control circuitry used to position the heads -- if you improve the control you can decrease the seek time as well as improve the accuracy of positioning -- this also allows you to use tighter track spacing, getting more data onto the disk. All of these effects combine, meaning that progress in hard drives does not just match Moore's Law, but exceeds it.
Why not ditch this ancient tech and pour some more $$ into developing affordable solid-state disks?
Because moving media is orders of magnitude cheaper and more durable. But if you are looking for research projects dealing with new storage technologies, why don't you start here or here?
I believe most Australian ISP's already have large web caches in place. The problem is that much of the data on the web is non-cacheable. Things such as advertising and dynamically generated content can not be cached.
What is really needed are local mirrors of important web sites. Akamai already goes a long way in reducing traffic by keeping local caches of images and advertising. Local servers dedicated to generating dynamic web pages could also help. (Managing this could be a nightmare 'tho...)
Actually, the tradeoff between SMT and single chip multiprocessors is not quite so simple. By adding SMT to a chip you increase the complexity of the design. This means you have to spend more time designing it, and more time testing it.
With a single chip multiprocessor (SCMP) you can design a smaller, simpler processor and spend more time performance tuning it. Once you have a single core working and tested, you can stamp it out multiple times. The complexity then gets put in the glue logic which is used to communicate between cores and share caches between them. This problem is well understood from the design of conventional multiprocessors.
Basically, since SMT is new, the design takes longer. SCMP relies of understood technologies, and potentially could be put into production faster.
I have TAed a couple of courses here at CMU, and I have to let you know that on coding assignments catching cheaters is really easy. Why? There are two reasons:
If someone cheats, it is either because they do not understand the assignment (and hence want to borrow someone elses work), or because they do not have time to do the assignment (and hence understand it). If you are clueless or short on time then you do not have the time or ability to cheat well. If you do a poor job at cheating, it is easy to catch you.
Code is machine readable. This sounds obvious, right? But if it is machine readable, it means that machines can do the tedious work of comparing solutions to each other. And the solutions do not have to be compared as handed in -- you can run the code through a compiler, and have the compiler give you statistics about the code. Compare those statistics, and compute a distance vector between each handin. Any handins that are close to eachother (on whatever statistic you happen to be measuring) compare by hand. Or you can compare the topology of the parse trees. Etc. Etc. Tools exist to do all of these things (and much more), and if a professor or TA suspects cheating then they will use them. I have known instructors who keep collections of previous years assignment handins specifically as fodder for these tools.
The typical way of cheating on a programming assignment is to copy someone elses solution and modify it. Perhaps you will rename the variables, change the comments, rewrite a function or two. These changes are on the surface only, and do not change the functional decomposition you used, the algorithms you chose -- in short, these changes do not change the aspects that a good grader is actually concentrating on. (And a good cheating detection tool ignores comments, variable names, etc.) Often you will find that the only person you fool is yourself.
So what is the end result? It is often easier to do the assignment without cheating than it is to cheat and get away with it.
As a TA, I have to say that grade haggling is a pain in the neck. So I just don't do it. If a student comes to me with a grading question, I try to find out if I made a mistake in grading the question. (ie, an addition error, I missed an important aspect of the solution, I didn't see the right answer amongst all the scribbles) If there is no error, then there is no discussion.
I once had a student come to me and try to argue that I should give them more style points for their code. I just said "no". It is hard to argue with a flat out "no, you don't deserve more points". It is when a TA is inconsistent in their grading that they get a reputation for giving out more points, and then haggling becomes a real problem.
I had the good fortune to be playing with this recently via simulation. If you give the processor a *huge* instruction window (256 instructions) and the ability to execute *any* number of instructions of *any* type in parallel (except for memory accesses - see below), you still get an average Instructions Per Clock of about 2.1-2.2. 95% of the time, you're getting four instructions or fewer issued (and most of the time, far fewer than that).
What set of benchmarks were you running when you collected those numbers? I assume you were using a benchmark suite such as SPEC. This is only one measure, useful to a certain audience. IBM is more than happy to create special hardware to accellerate a single application -- DB/2. If they can show that building this hardware will run their customer's codes faster, they can (and will) ignore SPEC performance numbers.
I use SPEC in my own research because it is a well packaged, easy to use and simulate set of applications, and it includes source code. It also lets me make direct comparisons to the research of others. But my results are not universally applicable -- you still can't beat evaluating hardware directly on your customer's code. You can bet I would be using a DB/2 (or other commercial database) to evaluate compiler and architectural tradeoffs if:
There was a simple benchmark
It had source code
It was small enough to run under a CPU simulator (ie, no more than 1 cpu second on our current infrastructure), and
It was free from restrictions on what results I could publish.
Unfortunately, no such benchmark exists. So we are left simulating what we have, such as the vortex benchmark from SPEC.
When I lived in Canada, Robertson screws were common as mud. And I agree that they work better than flathead or Phillips screws for most applications.
Recently I was helping a friend redo her kitchen, and I was quite suprised to discover that they are not nearly as common down here in the US. It seems that this simple invention has yet to catch on everywhere. (Perhaps this is because they are patented, and the royalties make them more expensive?)
If you have never stripped a Robertson, then you haven't worked with them enough. But they are significantly harder to strip than flatheads or Phillips screws...
May I suggest you go look over your computability and complexity class notes again?
The halting problem has to do with computability -- what problems can be solved by a computer. It is a simple example of a problem that can never be completely solved for all inputs, no matter how long the computer works on it.
NP-complete describes a class of problems which can be solved, but seem to take a long time to do so. It is not known whether these problems can be solved quickly, but many man years of effort has been spent trying to find a fast solution.
So the halting probem is not NP-complete, simply because it can not be solved at all.
OS/2 was better than it's MS competition. It still lost because it wasn't marketed correctly.
Did you ever use OS/2? It was not just a matter of marketing -- OS/2 was a resource hog. In order to have the advanced capabilities that it did, OS/2 required more RAM than was commonly available on the machines of the day. This was back when RAM was extremely pricey. A machine with 16MB of RAM was rare, and to really work well OS/2 needed 32! (IMHO)
On a powerful enough machine OS/2 was much better than Windows. But on the average machine of the day, Windows was far more usable.
XFree86 4.0.1 crashes about 75% of the time when I try to suspend my laptop. (Dell Inspiron 4000, ATI Mobile Rage128) I have heard this is a known problem -- does anyone know if a fix has been found for XFree 4.0.2? I see no mention of this in the release notes...
As far as comparing prices/plans/features, you are much better off going to one of the cell phone comparison web sites than asking Slashdot. Point.com is the best site that I have found for that purpose.
Several folks are advocating a different model. It doesn't involve programmers working for nothing. It involves both money-making companies and free software.
Suppose the government (or a school board, or a bank...) needed a disk repartitioning tool. They previously had a few choices:
- Find a commercial package and license it.
- Develop it in house.
- Hire an outside firm to develop it for them.
The "new" idea here is this: the company or government in question is not in the software development business. They just want to get their job done. They can develop it in house, or contract out the programming and make sure it is in their contract that they are able to give away the source code.Why would they want to do this? Naive reasons include it "feels good", or free support will fall from the sky. Better reasons include:
- If the software is truly useful to others and they improve it
(perhaps contracting out the job of creating improvements to the same
or other development firms) then the original developers could benefit
from those improvements.
- If they get unhappy with their current development firm it might
be easier to hire another development firm to maintain the software if
the source is unencumbered.
- If a quick or minor change is needed in the software then the
source is available to do this, without having to negotiate with an
outside development firm.
- Once you have paid for the development of the software there are no longer recurring expenses such as licensing fees or compliance audits. The cost of maitenance may be cheaper.
My main point is this: Free software does not have to be built by volunteers. You can hire professional developers to create and maintain free software if your business or government relies on this software. "Open source" and "free software" are two models for doing this.There exists an example of this. Gcc is licensed under the GPL. Many people rely on it for their jobs: this compiler is used by many folks to create code for embedded applications, unusual hardware, research, and mainstream applications. Often a company will need a specific improvement, or need it to be ported to a new operating system, or support for new hardware, etc. It appears that Cygnus exists mainly for the purpose of doing paid improvements to gcc. (I have worked for companies that have hired them for exactly that.) The folks who work for Cygnus don't work for free, and they often are quite good at what they do. Many other programs could follow similar models...
I believe the fundamental reason why software patents are viewed as flawed is cultural. Software developers are taught from day one that modularity is the best way of creating software. You start with your toolbox of parts (perhaps the functions provided by the OS and standard C libraries), and you build them up into more useful parts, which you then package as a new library. You then integrate those parts together into a program, which solves a problem in a useful way.
The software engineer builds up a toolbox over time -- perhaps by creating lots of programs, by sharing with other engineers, or by purchasing libraries from other companies. It is assumed that if you write some code starting with just what you think up and what you find in your (legally acquired) libraries you end up with a piece of work that is yours to use and sell. Under copyright law this is true -- you only break the law if you copy someone else's code without their permission. Since it is clear who owns each piece of code, you know clearly if you are breaking the rules.
Patents don't work this way. It is possible for an average programmer to write a program and not know they are violating a patent. The program can be used and/or sold for years without any clue that a patent is being violated. If the patent owner finds out, they can sue! If patents were only granted for truely novel software techniques that were not likely to be independently re-invented, then this would not be a problem. But this is not the case -- programmers have a valid fear that any piece of code they write might be violating somebody's patent.
The software design process (as we know it) has no easy way for incorporating a patent search. Fear of being blindsided by a patent violation can fundamentally change how software development is currently done, by adding significant extra time and manpower to any project to ensure it is not infringing on any patents.
As an attorney, would you like it if you could be randomly hit by lawsuits from other lawyers even though you are just doing your job? If for every case you prosecuted or defended you had to think up entirely new arguments on behalf of your clients, out of fear of re-using a patented argument that someone else has used before? Programmers like to create software, and like to use available techniques for doing so. Having to constantly worry about which techniques are currently "allowed" or "forbidden" just detracts from the real job to be done.
I notice that they make a big deal out of the fact that this new chip has 80 million transistors, and compare this to modern CPUs. This is quite a lot of transistors, but says nothing of the wiring cost. I would think that the regular structure of a GPU would make wiring costs much lower than on a CPU.
Does anyone know what the die area of Matrox's new chip is? I am curious how that compares to CPUs, and if graphics processors are much more dense than regular CPUs.
At the time I didn't want Windows, but the pricing scheme forced me to buy it anyways. Rediculous. Once I got it I discovered that the memory requirement of 8MB was a joke -- OS/2 was never happy doing any real work with less than 32MB, and as a student I could never afford to buy that much RAM...
It can load X and rexec X apps with 16mb RAM for Pete sakes!
So can XFree86. At least, the version I was using back in 1992 certainly worked on a 486 with 4MB of RAM. Slow, but functional.
Programs that catch cheating become more useful when you have a larger class. If you split up the grading over multiple TAs then you may not find these patterns. But once one of these utilities flags two submissions as being similar, it is very easy to tell if foul play was at work.
If your assignment is well designed, it is often possible to give a "right" answer, or to also give an "inspired" answer. To give an inspired answer requires creativity and insight into the problem -- if two students give the same inspired answer, then it is often worth looking closer as well.
When you are doing this, you have to keep in mind why you are doing these checks: in an intro class, you have to make sure that students are actually learning the material. Projects are often not worth that much, but if the students copy work on the projects then they will probably fail the exams. It is better to catch them early and show them how to do their own work than for them to wait until the end of the semester to fail the class.
I watched this movie yesterday afternoon. I have also read the book. The movie was nothing like the book -- the amount of pure spin in the movie was sickening. Why did the movie completely ignore the Somali's side of the story? There was a reason why the entire city rose up and attacked the US soldiers -- they were sick and tired of their disruptive presence, and decided that the "evil warlords" were easier to tolerate than the US soldiers.
Before you pass any judgements, read the book too. Please.
Do you have an above average IQ? You seem to have confused "average" with "median"...
You mention you want to go to grad school after you finish your undergrad degree. Chances are you will have to write the GRE CS subject test for your grad school application. Why not write it now, and see how you do? It might give you an approximate idea of how much computer science (as opposed to just programming) you have managed to pick up over the years.
Hey Taco -- if Slashdot is so boring and poorly written that even _you_ do not bother reading it, do you think that might be a good hint?
Do you use your a computer as a toy, or to get a job done? I use my computer as a tool -- and having the software I am running and rely on constantly changing does not help me get my job done. I upgrade my machine when newer software has an important feature that will help me be more productive (and make up for the time wasted in upgrading).
Playing the "kernel of the month club" game is not a good use of my time -- and I suspect this is true for most people who "operate and maintain a computer".
So when can we expect to see the RedHat packages on the US KDE mirrors? It is weird that they are announcing the new version before the mirrors get a chance to copy the files and reduce server load...
Chris
I just tried it out under RedHat 7.2. When I tried Quicktime it had no problem playing movies, but there is no sound. I tried using the powerpoint viewer on a presentation of mine, and all the fonts were messed up.
So it still has a few rough edges. If it worked flawlessly, they would get my money right away...
I am not sure if you are serious or not. If you compare the trends in storage to the trends in CMOS fabrication, you will find that the rate of change in storage capacities, price per MB, and transfer rates leave Moore's Law in the dust.
Why is this? It is because CMOS benefits primarily from improvements in photolithography. Hard drive heads are made using photolithography as well -- and every time you can produce smaller chips, you can also produce smaller hard drive heads. This means they are more precise, and can squeeze more data into less space. If you improve storage density, you make hard drives larger, faster (you have to move the head less to reach your data), and cheaper (you can use fewer platters to store the same amount of data). There is research into the materials used to store the data itself. Any improvements in the materials also improves the density of storage. In addition, there is the control circuitry used to position the heads -- if you improve the control you can decrease the seek time as well as improve the accuracy of positioning -- this also allows you to use tighter track spacing, getting more data onto the disk. All of these effects combine, meaning that progress in hard drives does not just match Moore's Law, but exceeds it.
Why not ditch this ancient tech and pour some more $$ into developing affordable solid-state disks?
Because moving media is orders of magnitude cheaper and more durable. But if you are looking for research projects dealing with new storage technologies, why don't you start here or here?
I believe most Australian ISP's already have large web caches in place. The problem is that much of the data on the web is non-cacheable. Things such as advertising and dynamically generated content can not be cached.
What is really needed are local mirrors of important web sites. Akamai already goes a long way in reducing traffic by keeping local caches of images and advertising. Local servers dedicated to generating dynamic web pages could also help. (Managing this could be a nightmare 'tho...)
Actually, the tradeoff between SMT and single chip multiprocessors is not quite so simple. By adding SMT to a chip you increase the complexity of the design. This means you have to spend more time designing it, and more time testing it.
With a single chip multiprocessor (SCMP) you can design a smaller, simpler processor and spend more time performance tuning it. Once you have a single core working and tested, you can stamp it out multiple times. The complexity then gets put in the glue logic which is used to communicate between cores and share caches between them. This problem is well understood from the design of conventional multiprocessors.
Basically, since SMT is new, the design takes longer. SCMP relies of understood technologies, and potentially could be put into production faster.
I have TAed a couple of courses here at CMU, and I have to let you know that on coding assignments catching cheaters is really easy. Why? There are two reasons:
The typical way of cheating on a programming assignment is to copy someone elses solution and modify it. Perhaps you will rename the variables, change the comments, rewrite a function or two. These changes are on the surface only, and do not change the functional decomposition you used, the algorithms you chose -- in short, these changes do not change the aspects that a good grader is actually concentrating on. (And a good cheating detection tool ignores comments, variable names, etc.) Often you will find that the only person you fool is yourself.
So what is the end result? It is often easier to do the assignment without cheating than it is to cheat and get away with it.
As a TA, I have to say that grade haggling is a pain in the neck. So I just don't do it. If a student comes to me with a grading question, I try to find out if I made a mistake in grading the question. (ie, an addition error, I missed an important aspect of the solution, I didn't see the right answer amongst all the scribbles) If there is no error, then there is no discussion.
I once had a student come to me and try to argue that I should give them more style points for their code. I just said "no". It is hard to argue with a flat out "no, you don't deserve more points". It is when a TA is inconsistent in their grading that they get a reputation for giving out more points, and then haggling becomes a real problem.
I had the good fortune to be playing with this recently via simulation. If you give the processor a *huge* instruction window (256 instructions) and the ability to execute *any* number of instructions of *any* type in parallel (except for memory accesses - see below), you still get an average Instructions Per Clock of about 2.1-2.2. 95% of the time, you're getting four instructions or fewer issued (and most of the time, far fewer than that).
What set of benchmarks were you running when you collected those numbers? I assume you were using a benchmark suite such as SPEC. This is only one measure, useful to a certain audience. IBM is more than happy to create special hardware to accellerate a single application -- DB/2. If they can show that building this hardware will run their customer's codes faster, they can (and will) ignore SPEC performance numbers.
I use SPEC in my own research because it is a well packaged, easy to use and simulate set of applications, and it includes source code. It also lets me make direct comparisons to the research of others. But my results are not universally applicable -- you still can't beat evaluating hardware directly on your customer's code. You can bet I would be using a DB/2 (or other commercial database) to evaluate compiler and architectural tradeoffs if:
Unfortunately, no such benchmark exists. So we are left simulating what we have, such as the vortex benchmark from SPEC.
When I lived in Canada, Robertson screws were common as mud. And I agree that they work better than flathead or Phillips screws for most applications.
Recently I was helping a friend redo her kitchen, and I was quite suprised to discover that they are not nearly as common down here in the US. It seems that this simple invention has yet to catch on everywhere. (Perhaps this is because they are patented, and the royalties make them more expensive?)
If you have never stripped a Robertson, then you haven't worked with them enough. But they are significantly harder to strip than flatheads or Phillips screws...
May I suggest you go look over your computability and complexity class notes again?
The halting problem has to do with computability -- what problems can be solved by a computer. It is a simple example of a problem that can never be completely solved for all inputs, no matter how long the computer works on it.
NP-complete describes a class of problems which can be solved, but seem to take a long time to do so. It is not known whether these problems can be solved quickly, but many man years of effort has been spent trying to find a fast solution.
So the halting probem is not NP-complete, simply because it can not be solved at all.
Did you ever use OS/2? It was not just a matter of marketing -- OS/2 was a resource hog. In order to have the advanced capabilities that it did, OS/2 required more RAM than was commonly available on the machines of the day. This was back when RAM was extremely pricey. A machine with 16MB of RAM was rare, and to really work well OS/2 needed 32! (IMHO)
On a powerful enough machine OS/2 was much better than Windows. But on the average machine of the day, Windows was far more usable.
XFree86 4.0.1 crashes about 75% of the time when I try to suspend my laptop. (Dell Inspiron 4000, ATI Mobile Rage128) I have heard this is a known problem -- does anyone know if a fix has been found for XFree 4.0.2? I see no mention of this in the release notes...
Chris
As far as comparing prices/plans/features, you are much better off going to one of the cell phone comparison web sites than asking Slashdot. Point.com is the best site that I have found for that purpose.