Compaq Australia has taken out full-page advertisments in the broadsheet papers proclaiming their brilliant new "Echrg" software, that allows your computer to run off power downloaded from the Internet if mains power or the battery goes flat. Simple, effective, and sure to suck in those morons who discuss how their Internet-time business strategy will actively synergise their customer relationship management . . .
Re:you make the same mistake!
on
The Mind of God
·
· Score: 2
While I agree with the comments on the oversimplification of Pascal's wager, it has a more fundamental problem. As I understand the argument (my understanding mostly tallies with the one-sentence summary above), it says absolutely nothing about whether God actually exists or not. The only thing that Pascal's wager shows is that it may be personally advantageous to believe in God.
Huh? Not following my argument? Say I offer you {a small fraction of Bill Gates' personal wealth, a gaggle of incredibly attractive members of the appropriate sex to do whatever comes naturally, Alan Cox as your personal bug-hunter and nifty-feature-that-I-don't-have-time-to-implement coder} for you to be an atheist. You decide to take the option of guaranteed instant gratification rather than the long-term gamble on the joy of eternal life with God, if God exists. I've just altered your personal payoff matrix in favour of atheism. Has this one iota of influence on the existence of God? Not one bit!
Therefore, Pascal's wager, IMHO, is a philosophical red herring, and I don't know why it is treated with such significance.
Quickified version - imagine an anglophone man at a computer terminal, with a giant book telling him exactly what to type in response to messages sent to him in Chinese. This man does not understand what he is doing at all, and yet this hypothetical manual he is following allows him to exactly simulate an intelligent response. If this man passes a Chinese Turing test this way, do we claim that he understands Chinese??
He may not understand Chinese, but I would argue that the system does understand Chinese. How do we know that you understand English and aren't just doing a convincing simulation?:)
I'm alcohol-free, so I won't have much use for that wine... but what the heck - I'll raise: a signed copy of The Art of Computer Programming...
Believe it or not, that was my initial thought for an appropriate wager . . . I'll see your Knuth. Let's hope we're still around to collect - either way!
Incidentally, it occurred to me a month or two ago that the following problem is equivalent to the halting problem: "Construct a program of a size no Incidentally, it occurred to me a month or two ago that the following problem is equivalent to the halting problem: "Construct a program of a size no greater than N, which runs as long or longer than any other programs of equal or lesser size (except those that run forever, of course.)"
This problem (or a close variation of it) is known as the "busy beaver problem", and is undecidable (I've forgotten the exact details of the proof, but basically it's a reduction proof - if you can solve this problem, you can solve the halting problem, and since you can't solve the halting problem, you can't solve this problem).
OK then, I'll ante up a bottle of Penfolds Grange, Australia most famous (and expensive) wine. I also promise to make it an original and not nanotech-engineered!
I have done AI-related research, and spent quite a deal of time learning about the history of AI. One thing that is abundantly clear is that, over the years, we have been horribly over-optimistic about the progress we will be able to make.
AI is a very hard problem, and there have been very few fundamentally new techniques discovered in the last 20 years. While I don't buy Penrose's argument that intelligence is noncomputable, I do suspect that a much better understanding of how the brain does what it does is required before we can build human-like intelligences. In the meantime, what we can and have been doing is attacking specific problems and building systems to solve those. We can do a lot of very useful things without solving the "general intelligence problem".
However, the premise that smarter-than-human AI is right around the corner and we should be preparing for it is bunk. In fact, I'm prepared to bet we will have a permanent settlement on Mars before we develop an AI system with capabilities equivalent to an average six-year-old. Any takers?
I'm sure I've seen some old film of a Nazi "marching machine" that used a frame that the lower body could rest in while the machine did the work of moving your legs.
If I remember rightly, the problem then was the same problem as would afflict a modern-day exoskeleton - lack of a compact, efficient, and sufficiently powerful energy source. They tried compressed air, which only gave ten or so minutes of marching.
DVD manufacturers aren't stupid - they know very well that customers prefer multi-region players. However, they have to keep the MPAA happy to keep their DVD coding.
Therefore, my guess is that the information necessary to enable multi-region is coming from the manufacturers themselves as part of a deliberate strategy.
Zero Gs is really harsh on the human body (bone loss, and worse), there are little if any plans to deal with a medical 'situation' in space (how do you perform even basic medicine when blood turns to aerosol?)
Easily solved, don't do the trip in zero G. Get the upper stage of your booster, tether it to the habitation with a piece of cord, and set it spinning. Artificial gravity.
and the problem of background radiation is even worse given that shielding is heavy and fuel is scarce.
It's just not that bad - the maximum probable dose is about 50 rem over a two year period. This is not lethal over the short term, and poses only a slight additional cancer risk in the long term. Robert Zubrin, a vociferous and convincing advocate of Mars exploration, suggests using smokers for the crew, but keep tobacco out of their cargo. Quitting smoking would reduce their cancer risk far more than the radiation dose!
Check out The Mars Society or read Dr. Zubrin's book The Case For Mars for more information.
As linux becomes more popular binary distributions will become common.
Agreed - in fact, they already are
Download a binary that has a virus and run it as a normal user. OK - where from? ftp.debian.org? If I check the signature on the package I can be sure that it's as the package author sent it out, and I trust that package author not to have virii on his/her machine. I (as a programmer), wouldn't download binaries from an untrusted source (as I might get a trojan, which could do far more vicious things than a virus), but a newbie might and would get infected.
Lets say the user now compiles some code, that binary will be infected, the user puts the binary into a tar ball and shoves it onto their ftp site for distribution.. the virus spreads.
The type of people who download untrusted binaries don't tend to upload binaries either.
I still remain unconvinced about the abilities of virii to do real damage in the Linux environment (heck, binary virii haven't really caused problems in the Windows environment for years). However, you make some good points. Now that these vulnerabilities in the ELF file format and the Linux kernel have been pointed out, is there any work being done to close them?
A cursory browse at the example virii there (I didn't read all the papers, I admit), doesn't explain how a virus could gain root privileges (which it requires to propagate effectively), without being executed by root. Could you give me a pointer to a specific paper?
After all, it's not too terribly hard to write a virus for any computer operating system
That may be the case, but it's pretty damned tough to write an effective virus that will propagate with any efficiency on a Linux box.
I'll first discuss binary viruses, then macro virii, as they are seperate issues. All system-installed programs are owned by root (modulo some daemons and the like owned by administrative account), so to infect "ls" or "emacs" the virus would either have to use some exploit to gain root priviliges, or get itself installed suid root. Root exploits tend to get closed, pronto. Whilst newbies wouldn't check to see if a program installed itself suid root, experienced users would, and would let the world know if a paint program from www.reallycoolsoftware.com was installing itself suid root for no good reason. So propagation by infecting system software would be pretty damn difficult.
What could a virus then do to propagate itself without root priviliges? It could infect any program it had write permissions to - that is, any executable owned by the user, or set group or world writable. Newbies don't tend to have executables that they own, group-writable executables are rare (and not a great idea), and world-writable executables are extremely bad practice. Not much room for propagating there.
Even worse for the virus, binaries don't tend to get shared around much in the Linux community. Binaries tend to get distributed using CD-ROM's, distribution ftp sites, and possibly project ftp sites - none of the rampant floppy-swapping that made the viruses of the 80's and early 90's so prevalent. Nor do Linux email programs allow the blithe execution of binaries as many Windows mailers do.
Therefore, I consider it extremely unlikely that Linux binary virii will be able to propagate effectively.
Macro virii are a different proposition. File permissions are not such a defence here. However, these beasties rely on macro languages which were enabled by default, which allow arbitrary macro code to be executed on loading a document. If auto-executable macros are disabled by default (or banned outright), and macro languages restricted in their power to prevent them altering documents other than the one they are embedded in, the macro virus cannot propagate itself. Why can Linux applications do this readily, while Windows is more restricted? Simple - because the foreknowledge of what has happened in the Windows world is allowing Linux applications to be designed with macro-virus proofing in mind.
In summary, Linux is a damned hard target for virus writers. Next time Mr Garfinkel tries to drum up some business for himself, he might consider doing a little more research.
While not really in a position to comment on the US Constitution's position, one should realize that the issue goes beyond just sales taxes.
Consider a situation where a CEO, say, has most of their salary paid in some offshore tax haven, has most goods delivered from a company incorporated in another tax haven with a wharehouse in Mexico, say, whose government (hypothetically) removes all sales taxes for re-exported goods. I'm not sure of the import duty situation, but with NAFTA I'd imagine they are very low. Our executive ends up paying virtually no tax in the jurisdiction where he/she lives, works, and uses government provided services.
I suspect that in the not-too-distant future governments will need to come to additional treaty arrangements to ensure people pay a fair amount of tax, and this will probably involve a tax on internet-based transactions be they domestic or international. Is this intrusive and a bugbear? Yes? Is it any more intrusive than the IRS (or its equivalents)? Probably not. Is it necessary? Almost certainly.
The current state of the art in low-pollution petrol powered cars has almost nowhere to go
Wrong. Research in to learn-burn technology, petrol-electric hybrids, and petrol-powered fuel cells continues.
2. Research on electricity based transport is advancing rapidly . . .
I haven't heard of any major advances in battery technology in years. Yes, new electronics is helping, but power density and cost are as unfavourable now as they were ten years ago.
If America (and my home country Australia for that matter) are serious about reducing greenhouse emissions the only real choice is a carbon tax (and a substantial one). That might even things up and give alternative fuels (not to mention public transport) a chance.
The essay argues that proprietary software is usually developed around extensive user-interface testing, while open-source software is just hacked together without even using any of the user-interface research out there in the literature. That's simply not the case. While Microsoft might do lots of UI experimentation (though the number of clangers that get through the system make me wonder sometimes), a lot of proprietary software has its UI designed by non-experts, and isn't properly user-tested either.
Additionally, while it can be difficult, it is possible to incorporate feedback from "ordinary users" (or at least slightly adventurous non-programmers) into the open-source development process. Particularly since the new beta release, the GnuCash mailing list receives quite a lot of mail from non-programmers asking questions and commenting on the project.
Ask a member of the PKK if he considers himself a "terrorist".
This is an extremely dumb analogy, IMHO. While this might be a fair comment if you were talking about, say, Jon Johansen, what Linus, Alan, Larry Wall, and the like do has *nothing* to do with circumventing security restrictions.
You are correct in saying we're not likely to get "cracker" generally accepted, but the distinction is (usually, but not always) pretty stark. "cracker", therefore remains useful as a piece of terminology to facilitate discussion amongst ourselves.
But if I could point a finger at a possible threat it would be to another Unix base. And a very good user interface; - MacOS 10
You're making the same mistake the author of the article did - you're ignoring the critical difference that open source makes. While MacOS 10 has open-sourced the BSD backend, but the bit that differentiates the Mac certainly isn't.
Without completely open-sourcing MacOS, the platform will *never* have many of the advantages (lack of vendor domination, speedy bugfixing etc.) that Linux and the real BSD's do.
Don't get me wrong I'm sure that Linux could get very sick and old. But it has to many hardcore advocates to just disapear.
Advocates don't keep a system alive. Users and developers do.
It contains a obvious, but accurate, observation of the reason why Transmeta keeps its code morphing software secret:
When the rent from secret bits is higher than the return from open source, it makes economic sense to be closed-source. When the return from open source is higher than the rent from secret bits, it makes sense to go open source.
The code-morphing software is the key to the Transmeta chips' superior features, so I'd say the rent from keeping the bits secret is pretty high.
RMS would probably argue that Transmeta has a moral obligation to free its software, but the pragmatic net payoff of a lot of the open-sourcing we've seen just isn't there in this case, and it's not realistic to expect a company to do so without it.
Apparently, Sony's tight control over the Beta format meant that they wouldn't allow porn to be pre-recorded on it. VHS had no restrictions. Which format succeeded?:)
But when Microsoft talks of 65K bugs, they're bugs like, Windows 2000 wont properly detect XXX hardware, Windows won't run XXX software, so it does generally include a heck of a lot of software that runs on windows.
True, but a very high proportion of the bugs in Debian are with "non-core" parts of the distribution (things that wouldn't be distributed with a Microsoft OS). Many bugs are just users being "niggly" as well. A significant number of "bugs" are in fact proposals for policy changes. Not much difference in fact (except that Debian doesn't hide the problems).
Also, Windows 2000 has some HUGE features that debian doesn't have, like Active Directory.
Debian has some huge features that Win2000 doesn't have, including a complete development environment, full server functionality, lots of powerful applications, etc. etc. etc. The upcoming Debian release will span 4 CD's of binaries. Big as Win2000 is, if you take all the code that Debian distributes, Debian is far bigger.
But these comparisons wouldn't be possible except a memo happened to fall into ZDNet's hands. Wouldn't it be nice if Microsoft made its bug tracking database public?
It's a little under this, as you can see on this graph.
The current list of "release-critical" bugs (that is, bugs that must be fixed before release, is available from here.
Of course, there is a huge fluff factor here. Debian uses the bug-tracking system to track things that aren't really bugs, there are bugs that weren't really bugs, and so on.
This books sounds rather like Roger Penrose's "The Emporer's New Mind", minus the (provably wrong) computability claims.
I thought his computability argument was wrong, but I wasn't sufficiently confident in my own reasoning to be sure. Do you have a citation for a refutation of his argument?
That's just not correct. All the support students need is freely available on the web, via IRC. Go to any irc network and join the #linux channel. Or #linuxnewbie or whatever. You only need ONE student connected to irc, via Linux, Windows, Solaris or whatever, and all the other students can get enough support to get their own machines up and connected.
I'm going to have to disagree, for several reasons:
If you provide a resource for students, they expect you (with some justification) to support their use of it - particularly if you make it a course requirement.
You grossly underestimate the enthusiasm, resourcefulness, and dare I say it competence of the average first-year student. Particularly in introductory courses, you get a whole bunch of mostly engineering majors who are required to do the subject, don't like or understand computers, and whose goal is to scrape through with the absolute minimum effort. Letting these people loose with an operating system is just asking for trouble.
While students living in dorms help each other, there are many first-year students in Australian universities that continue to live at home with their parents, or live in share houses around campus with people who may not be doing the same course. Therefore, many students do not know many people in their course, and some do not know anyone in their course! Their only contact is the tutor (ie me)
Unix is hard for some people to grasp. Why these people are doing CS I have no idea, but it means that the silly question factor is *extremely* high.
While integrating Linux (and students running Linux boxen) into CS courses is, IMHO, a very good idea, it needs to be thought about carefully, and properly resourced. An ad-hoc approach, handing out a few RedHat CD's without any backup, just won't work.
Slashdot Mirror
Compaq Australia has taken out full-page advertisments in the broadsheet papers proclaiming their brilliant new "Echrg" software, that allows your computer to run off power downloaded from the Internet if mains power or the battery goes flat. Simple, effective, and sure to suck in those morons who discuss how their Internet-time business strategy will actively synergise their customer relationship management . . .
Huh? Not following my argument? Say I offer you {a small fraction of Bill Gates' personal wealth, a gaggle of incredibly attractive members of the appropriate sex to do whatever comes naturally, Alan Cox as your personal bug-hunter and nifty-feature-that-I-don't-have-time-to-implement coder} for you to be an atheist. You decide to take the option of guaranteed instant gratification rather than the long-term gamble on the joy of eternal life with God, if God exists. I've just altered your personal payoff matrix in favour of atheism. Has this one iota of influence on the existence of God? Not one bit!
Therefore, Pascal's wager, IMHO, is a philosophical red herring, and I don't know why it is treated with such significance.
He may not understand Chinese, but I would argue that the system does understand Chinese. How do we know that you understand English and aren't just doing a convincing simulation? :)
Believe it or not, that was my initial thought for an appropriate wager . . . I'll see your Knuth. Let's hope we're still around to collect - either way!
This problem (or a close variation of it) is known as the "busy beaver problem", and is undecidable (I've forgotten the exact details of the proof, but basically it's a reduction proof - if you can solve this problem, you can solve the halting problem, and since you can't solve the halting problem, you can't solve this problem).
Your turn . . .
AI is a very hard problem, and there have been very few fundamentally new techniques discovered in the last 20 years. While I don't buy Penrose's argument that intelligence is noncomputable, I do suspect that a much better understanding of how the brain does what it does is required before we can build human-like intelligences. In the meantime, what we can and have been doing is attacking specific problems and building systems to solve those. We can do a lot of very useful things without solving the "general intelligence problem".
However, the premise that smarter-than-human AI is right around the corner and we should be preparing for it is bunk. In fact, I'm prepared to bet we will have a permanent settlement on Mars before we develop an AI system with capabilities equivalent to an average six-year-old. Any takers?
If I remember rightly, the problem then was the same problem as would afflict a modern-day exoskeleton - lack of a compact, efficient, and sufficiently powerful energy source. They tried compressed air, which only gave ten or so minutes of marching.
Therefore, my guess is that the information necessary to enable multi-region is coming from the manufacturers themselves as part of a deliberate strategy.
Zero Gs is really harsh on the human body (bone loss, and worse), there are little if any plans to deal with a medical 'situation' in space (how do you perform even basic medicine when blood turns to aerosol?)
Easily solved, don't do the trip in zero G. Get the upper stage of your booster, tether it to the habitation with a piece of cord, and set it spinning. Artificial gravity.
and the problem of background radiation is even worse given that shielding is heavy and fuel is scarce.
It's just not that bad - the maximum probable dose is about 50 rem over a two year period. This is not lethal over the short term, and poses only a slight additional cancer risk in the long term. Robert Zubrin, a vociferous and convincing advocate of Mars exploration, suggests using smokers for the crew, but keep tobacco out of their cargo. Quitting smoking would reduce their cancer risk far more than the radiation dose!
Check out The Mars Society or read Dr. Zubrin's book The Case For Mars for more information.
Add "binary" to the first "virii" in the last paragraph.
Agreed - in fact, they already are
Download a binary that has a virus and run it as a normal user. OK - where from? ftp.debian.org? If I check the signature on the package I can be sure that it's as the package author sent it out, and I trust that package author not to have virii on his/her machine. I (as a programmer), wouldn't download binaries from an untrusted source (as I might get a trojan, which could do far more vicious things than a virus), but a newbie might and would get infected.
Lets say the user now compiles some code, that binary will be infected, the user puts the binary into a tar ball and shoves it onto their ftp site for distribution.. the virus spreads.
The type of people who download untrusted binaries don't tend to upload binaries either.
I still remain unconvinced about the abilities of virii to do real damage in the Linux environment (heck, binary virii haven't really caused problems in the Windows environment for years). However, you make some good points. Now that these vulnerabilities in the ELF file format and the Linux kernel have been pointed out, is there any work being done to close them?
A cursory browse at the example virii there (I didn't read all the papers, I admit), doesn't explain how a virus could gain root privileges (which it requires to propagate effectively), without being executed by root. Could you give me a pointer to a specific paper?
That may be the case, but it's pretty damned tough to write an effective virus that will propagate with any efficiency on a Linux box.
I'll first discuss binary viruses, then macro virii, as they are seperate issues. All system-installed programs are owned by root (modulo some daemons and the like owned by administrative account), so to infect "ls" or "emacs" the virus would either have to use some exploit to gain root priviliges, or get itself installed suid root. Root exploits tend to get closed, pronto. Whilst newbies wouldn't check to see if a program installed itself suid root, experienced users would, and would let the world know if a paint program from www.reallycoolsoftware.com was installing itself suid root for no good reason. So propagation by infecting system software would be pretty damn difficult.
What could a virus then do to propagate itself without root priviliges? It could infect any program it had write permissions to - that is, any executable owned by the user, or set group or world writable. Newbies don't tend to have executables that they own, group-writable executables are rare (and not a great idea), and world-writable executables are extremely bad practice. Not much room for propagating there.
Even worse for the virus, binaries don't tend to get shared around much in the Linux community. Binaries tend to get distributed using CD-ROM's, distribution ftp sites, and possibly project ftp sites - none of the rampant floppy-swapping that made the viruses of the 80's and early 90's so prevalent. Nor do Linux email programs allow the blithe execution of binaries as many Windows mailers do.
Therefore, I consider it extremely unlikely that Linux binary virii will be able to propagate effectively.
Macro virii are a different proposition. File permissions are not such a defence here. However, these beasties rely on macro languages which were enabled by default, which allow arbitrary macro code to be executed on loading a document. If auto-executable macros are disabled by default (or banned outright), and macro languages restricted in their power to prevent them altering documents other than the one they are embedded in, the macro virus cannot propagate itself. Why can Linux applications do this readily, while Windows is more restricted? Simple - because the foreknowledge of what has happened in the Windows world is allowing Linux applications to be designed with macro-virus proofing in mind.
In summary, Linux is a damned hard target for virus writers. Next time Mr Garfinkel tries to drum up some business for himself, he might consider doing a little more research.
Consider a situation where a CEO, say, has most of their salary paid in some offshore tax haven, has most goods delivered from a company incorporated in another tax haven with a wharehouse in Mexico, say, whose government (hypothetically) removes all sales taxes for re-exported goods. I'm not sure of the import duty situation, but with NAFTA I'd imagine they are very low. Our executive ends up paying virtually no tax in the jurisdiction where he/she lives, works, and uses government provided services.
I suspect that in the not-too-distant future governments will need to come to additional treaty arrangements to ensure people pay a fair amount of tax, and this will probably involve a tax on internet-based transactions be they domestic or international. Is this intrusive and a bugbear? Yes? Is it any more intrusive than the IRS (or its equivalents)? Probably not. Is it necessary? Almost certainly.
Wrong. Research in to learn-burn technology, petrol-electric hybrids, and petrol-powered fuel cells continues.
2. Research on electricity based transport is advancing rapidly . . .
I haven't heard of any major advances in battery technology in years. Yes, new electronics is helping, but power density and cost are as unfavourable now as they were ten years ago.
If America (and my home country Australia for that matter) are serious about reducing greenhouse emissions the only real choice is a carbon tax (and a substantial one). That might even things up and give alternative fuels (not to mention public transport) a chance.
Additionally, while it can be difficult, it is possible to incorporate feedback from "ordinary users" (or at least slightly adventurous non-programmers) into the open-source development process. Particularly since the new beta release, the GnuCash mailing list receives quite a lot of mail from non-programmers asking questions and commenting on the project.
This is an extremely dumb analogy, IMHO. While this might be a fair comment if you were talking about, say, Jon Johansen, what Linus, Alan, Larry Wall, and the like do has *nothing* to do with circumventing security restrictions.
You are correct in saying we're not likely to get "cracker" generally accepted, but the distinction is (usually, but not always) pretty stark. "cracker", therefore remains useful as a piece of terminology to facilitate discussion amongst ourselves.
You're making the same mistake the author of the article did - you're ignoring the critical difference that open source makes. While MacOS 10 has open-sourced the BSD backend, but the bit that differentiates the Mac certainly isn't.
Without completely open-sourcing MacOS, the platform will *never* have many of the advantages (lack of vendor domination, speedy bugfixing etc.) that Linux and the real BSD's do.
Don't get me wrong I'm sure that Linux could get very sick and old. But it has to many hardcore advocates to just disapear.
Advocates don't keep a system alive. Users and developers do.
When the rent from secret bits is higher than the return from open source, it makes economic sense to be closed-source. When the return from open source is higher than the rent from secret bits, it makes sense to go open source.
The code-morphing software is the key to the Transmeta chips' superior features, so I'd say the rent from keeping the bits secret is pretty high.
RMS would probably argue that Transmeta has a moral obligation to free its software, but the pragmatic net payoff of a lot of the open-sourcing we've seen just isn't there in this case, and it's not realistic to expect a company to do so without it.
Apparently, Sony's tight control over the Beta format meant that they wouldn't allow porn to be pre-recorded on it. VHS had no restrictions. Which format succeeded? :)
True, but a very high proportion of the bugs in Debian are with "non-core" parts of the distribution (things that wouldn't be distributed with a Microsoft OS). Many bugs are just users being "niggly" as well. A significant number of "bugs" are in fact proposals for policy changes. Not much difference in fact (except that Debian doesn't hide the problems).
Also, Windows 2000 has some HUGE features that debian doesn't have, like Active Directory.
Debian has some huge features that Win2000 doesn't have, including a complete development environment, full server functionality, lots of powerful applications, etc. etc. etc. The upcoming Debian release will span 4 CD's of binaries. Big as Win2000 is, if you take all the code that Debian distributes, Debian is far bigger.
But these comparisons wouldn't be possible except a memo happened to fall into ZDNet's hands. Wouldn't it be nice if Microsoft made its bug tracking database public?
The current list of "release-critical" bugs (that is, bugs that must be fixed before release, is available from here.
Of course, there is a huge fluff factor here. Debian uses the bug-tracking system to track things that aren't really bugs, there are bugs that weren't really bugs, and so on.
I thought his computability argument was wrong, but I wasn't sufficiently confident in my own reasoning to be sure. Do you have a citation for a refutation of his argument?
I'm going to have to disagree, for several reasons:
While integrating Linux (and students running Linux boxen) into CS courses is, IMHO, a very good idea, it needs to be thought about carefully, and properly resourced. An ad-hoc approach, handing out a few RedHat CD's without any backup, just won't work.