Ever been to a physics lab? A real one, I mean. There's always aluminum foil everywhere. They have boxes filled with used aluminum foil that they save and reuse since they're too cheap to buy new aluminum foil.
"You misunderstood me. I'm not saying they'll be identical. I'm saying you will be able to use either one to run virtually any application made for either. Already, with Linux Binary Compatability, you can run most Linux software on FreeBSD. By 2005 it'll be more or less complete. And, just about every major package available for FreeBSD has a Linux version. They'll be interchangeable in the sense that any thing you might want to do will be possible on either platform without having to do too much work in porting your stuff over."
I'm not talking about the applications so much. Already you can pretty much run any Linux application on BSD even without binary compatability since most of them are open source. But that's not the point.
Your original post mentioned hardware compatability which is a big deal. The BSDs simply don't have the level of driver support that Linux does, and so long as they remain relatively obscure they never will. You cannot seamlessly switch from Linux to BSD if you are using hardware that is not supported by BSD.
Also, though I have no desire to start a flamewar I think it must be acknowledged that there is functionality present in Linux that is not in BSD (And of course there is functionality present in BSD that is not in Linux. My point is just that they are different.). For instance, Linux can more effectively scale to a large number of processors than BSD can. If you want to switch a box with many processors from Linux to BSD you should not expect to be able to do it without a big penalty.
All I am saying is that such a switch would not be nearly as seamless as you would imply. There is more to an operating system than applications.
"Yes, but most of the types of organizations that SCO is targeting are using relatively new builds of Linux. Given that this issue exists, when new kernels that are unencumbered are made available, don't you think people are going to snap them up? Realistically, I mean, think about it."
All I have to say to this is...huh?! Did you read my comment? Did you read your comment that my comment was responding to? Your response has nothing at all to do with what I was saying. You claimed in your original comment that by 2005 the only people still using 2.4 would be "Unabomber-like holdouts, crouching in a shed with a dilapidated old Pentium-II and a stockpile of candy bars and beer". That statement was ridiculously false, and so I felt a need to correct it.
Moving on to your newer and completely unrelated comment, the only reason SCO is targeting users of 2.4 is because the code they are complaining about wasn't in 2.2. What makes you think they aren't going to care if you're using 2.6? The code will still be there. 2.6 will still be "tainted". Of course, if they actually told the Linux community what the problem was the Linux community would fix it, but the whole damn point is that they refuse to tell anybody in order to sue them.
Moving on to the x86 stuff. I won't bother quoting your most recent comment because there's nothing there worth quoting. Again you have responded with a red herring. Your original post, the one I was responding to, said "By 2008...do you think we're still going to be using X86 machines, anyway?", to which my response was a resounding "yes"! x86 isn't going away anytime soon. But then you start babbling on about PDAs and cellphones, which of course are not x86, however that's completely irrelevant. I never claimed at any point that x86 was going to rule the universe; I simply claimed that it will still be there and still be important.
Do you honestly believe that normal desktop systems aren't even going to exist in 5 years? I certainly don't. If that makes me a "stick in the mud" then I guess I'm a stick in the mud. Personally I prefer to think of it as being realistic.
Finally, there is the issue of SCO's lawsuit being x86-specific. It's not. Yes, SCO was in the x86 business, but the
I agree with some of your points, and I agree with ignoring SCO, but I have this compulsive need to correct what I see as some rather large oversites in your post. No offense intended.
"2. By 2005, the BSDs and Linux will have become so similar in functionality, hardware support, and applications, that migrating from one to the other will be fairly painless. Since the BSDs are unencumbered, and SCO is specifically targeting the Linux 2.4 kernel, this means we have a great big safety net."
Linux and BSD have coexisted for what...12 years now, and they have nevertheless maintained distinctive personalities. Do you honestly believe that in 2 more years they will suddenly be interchangable? It's not as if that's the sort of thing anyone is even working on. It's just silly.
"3. By 2005, who's going to be using the 2.4 kernel? Unabomber-like holdouts, crouching in a shed with a dilapidated old Pentium-II and a stockpile of candy bars and beer? Any code which even remotely looks like SCO code is going to be stripped out long before then. So, the code in use by the time the court convenes is going to be unencumbered anyway. What could SCO possibly charge people money for, even if they win?"
There are still people running 2.2 now. Heck, there are still people running 2.0 now. I'm sure in 2005 there will be plenty of people still running 2.4. 2.6 isn't even done yet. Never underestimate the power of legacy software.
"5. By 2008 (when the case would probably get wrapped up and appealed, etc), do you think we're still going to be using X86 machines, anyway? It's 2003; how many of you are still using the 486's you had in '98? Who's still using a 16 bit O/S? Anyone? Bueller? Bueller?"
Another case of a strange conception of time. x86 has been with us for a very long time, and it is set to be with us for longer. Particularly if AMD's x86-64 extensions take off. Talking about 486s is a tad erroneous (even ignoring the fact that many of us, including me, still have 486s in their basements doing useful things) since the processors we use today are still based on the same exact ISA that those 486s were based on. So you just disproved your own point!
But nevermind that. What exactly does x86 have to do with anything anyway? Linux is a many-architecture OS. That is one if its strengths. To my knowledge there is nothing in SCO's lawsuit that is x86 specific.
Micropayments should in theory be a doable business. Yes, the money earned per transaction is extremely small, but with sufficient automation it is entirely possible to make money with a large enough number of small transactions. The reason nobody does is because our currency system is quantized.
It's a simple fact that you can't charge somebody a fraction of a penny for something. There's just no way around it; our currency system doesn't let you. You can use fractional amounts for all your internal accounting, however when it comes down to giving somebody the bill it must be some integer number of pennies.
So going back to your 3 cent example: A company trying to make money has to charge a fee. Paypal charges what, 5%? What is 5% of 3 cents? Why,.15 cents of course! What the hell is.15 cents? How do you charge somebody.15 cents? You are then left with the choice of either charging them nothing at all, in which case you probably won't make money, or charging them an entire cent. Well, 1 cent would be 33% overhead! Nobody is going to accept that. So what do you do?
Thus the only solution is consolidation: collect a bunch of payments into a single lump amount and then charge overhead based on that amount. The details of how this consolidation works will vary, but it must occur somewhere in the process. Notice that this is what everyone trying to get into the micropayments business does. Obviously somebody thinks they can make money off of it, even though they still have to keep track of the same number of transactions. In other words, the accounting when consolidating still really isn't any easier because the total number of transactions that must be tracked in some form or another is the same. All that is easier is the billing.
If our currency could deal with arbitrary fractions of a cent then this wouldn't be an issue. Unfortunately it can't, and trying to change that for the sake of micropayments really isn't worth it. (The cost of changing that would be enormous. All accounting software out there would a damn keeps track of money using integers and it would all have to be rewritten. Not to mention issues with the limited precision of computer systems possibly allowing for exploits of the Office Space [yes, I know Office Space is not the original source of that exploit, however I forget the original source and it is what came to mind] kind.)
I really don't see an easy solution to this problem
"Unless you've bought into Apple's desktop systems, buying an Apple notebook means having to maintain two seperate sets of software to run on your systems."
Hmm...nope. Debian Linux running on both my custom x86 desktop and my iBook. Funny how that works out.
"Well, that presupposes the NSA don't already have quantum decryption up and running. I wouldn't like to bet on that."
As someone who has actually spent some time studying how quantum computers work (or more accurately, how quantum computers should hopefully maybe work), I would take that bet without a moment's hesitation. We are at least 30 years away from a working quantum computer, assuming that a working quantum computer is even possible (Which is by no means assured). All we have now are a handful of theoretical algorithms without any hardware to run them, and a couple wildly speculative and impractical ideas of how we might someday be able to build the hardware.
Now I know a lot of people seem to think that the NSA has unlimited resources and can do anything they want to in secret, but we are far enough away from quantum computing that even if the NSA's budget was 100 times what it is now you shouldn't have to worry. I'm sure they would love to have a working quantum computer, but that's just the thing: Lot's of people would love to have a working quantum computer. This isn't an obscure subject area that others haven't thought about going into (which is how most secretive technological advances tend to occur); it's a thoroughly researched field with a huge prize for anyone who manages to get it to work. The amount of money that has been poured into quantum computing research is huge, and we still haven't gotten anywhere. Nobody has the slightest idea how to build the damn things!
First off, regular TIE Fighters, TIE Interceptors, and TIE Bombers do not have any shields at all. And yes, their armor sucked but that's not the point.
The standard TIE Fighter is actually an excellent design in its own way. The things aren't that fast, but they are very small and maneuverable and can be a challenge to hit, especially in large numbers. But most importantly, they are simple. They are basically nothing more than a cockpit, lasers, and engine. They are most likely incredibly cheap to build and maintain, and because of their small size you can pack a lot of them into a star destroyer. Thus you can overwhelm your enemy with superior numbers. In large packs TIE Fighters are extremely deadly.
The Empire almost certainly does not place a high value on the lives of its pilots, which is why they get away with this sort of design. People are expendible. The only thing strange about the movies is that so few TIE Fighters are actually used in most engagements. I mean, look at the final battle in episode 4. You know that Death Star is packed full of TIE Fighters, but they only actually send out a handful to fight the rebel fighters. Maybe they were just overconfident.
Since Loki is defunct you should check out the icculus.org page for more up-to-date information. Not that they have all that much information there either...
To my knowledge it doesn't do any real dependency checking. If the correct libraries are not installed then it just won't work. Since it's really intended for third party software and not core functionality this isn't as big a problem as it could be. After all, it's always possible to use your package manager to grab whatever libraries you're missing manually, and with a resonably up to date system you really shouldn't have to worry about that very often (I've never really had a problem with it). I'll admit that ideally this is something the user shouldn't have to do, but with so many different distributions out there with so many different package managers it's not an easy issue to solve. I know I would never want a tool like this to go installing libraries outside of my package management system, since that kind of defeats the entire purpose of package management.
On the upside there is a corresponding uninstaller and it seems to work just fine. At least I have never had any problems with it.
The technical solution to this problem already exists: It's called the Loki installer. I run Debian and I use apt-get for most free packages, but I've found that for the occasional self-contained commercial third party app the Loki installer works extremely well. It has been adopted by just about every commercial game released for Linux as far as I know, even those that have nothing at all to do with Loki. But it has also been adopted by many non-game apps.
It's exactly the solution you're looking for. The only real problem is that it's not a standard per say. There are still many apps out there that could benefit from using the Loki installer that for whatever reason do not. If the LSB were to officially support the Loki installer as the correct way to install third party software on a Linux system and provide guidelines for its use then we would be getting somewhere.
What?! Noooooo! I love the crap on the screen. The crap on the screen is great. I like to show it to people who know nothing about computers in order to make them think I'm working on highly technical computer stuff that they could never understand so they should just leave me alone when in actuality I'm just reading slashdot while I wait for a new kernel to compile. And damn that was a long sentence.
"Tesla demonstrated "beaming power" at the beginning of the last century. If things had turned out slightly differently for him, we might all be receiving our electricity wirelessly, and you wouldn't be making snide remarks about it."
Oh please. Spare me. The fact that we aren't "receiving our electricity wirelessly" has nothing at all to do with how things "turned out" for Tesla. It has to do with the fact that while it is theoretically possible (hell, I've even done this on a small scale for demonstation purposes), it's completely and utterly impractical. The traditional tesla coil is omnidirectional and therefore any energy you put into the thing is spread out uniformly about the tesla, and the vast majority of it doesn't actually reach the device you want to power. This is in stark contrast to a wire, which will take all of your energy from point A to point B (minus some lost to resistence of course, but that's a comparatively small effect). And I haven't even mentioned the side effects of the Tesla approach. The things tend to ionize the air and create a lot of ozone and there's no way that sort of approach could be healthy for people in the long run if it was actually implemented on a large scale.
This of course has nothing to do with the discussion at hand, which would most likely involve beaming power using masers or lasers, which, being focused beams, have the advantage of not spreading out very much as they travel great distances. This sort of approach is at least feasible, but there are a lot of details that have yet to be worked out.
Anyway, I will leave you with two parting thoughts: 1. The Martian atmosphere is much thinner and of a very different composition than the Earth's. How do we know that this sort of technology would be nearly as effective there as it is on Earth?
2. If you're just going to beam energy to your craft anyway, why not just use that energy to power a more conventional drive? What is the real advantage of this approach?
JC! I don't think I've seen you comment on slashdot before. I miss your website. How have you been? Send me an email sometime: davek at sdf dot lonestar dot org
Slashdot Mirror
Sure you can! You just use a ramdisk. The only problem is that you lose state when you turn the thing off.
Ever been to a physics lab? A real one, I mean. There's always aluminum foil everywhere. They have boxes filled with used aluminum foil that they save and reuse since they're too cheap to buy new aluminum foil.
Makes you think...
And so it continues...
"You misunderstood me. I'm not saying they'll be identical. I'm saying you will be able to use either one to run virtually any application made for either. Already, with Linux Binary Compatability, you can run most Linux software on FreeBSD. By 2005 it'll be more or less complete. And, just about every major package available for FreeBSD has a Linux version. They'll be interchangeable in the sense that any thing you might want to do will be possible on either platform without having to do too much work in porting your stuff over."
I'm not talking about the applications so much. Already you can pretty much run any Linux application on BSD even without binary compatability since most of them are open source. But that's not the point.
Your original post mentioned hardware compatability which is a big deal. The BSDs simply don't have the level of driver support that Linux does, and so long as they remain relatively obscure they never will. You cannot seamlessly switch from Linux to BSD if you are using hardware that is not supported by BSD.
Also, though I have no desire to start a flamewar I think it must be acknowledged that there is functionality present in Linux that is not in BSD (And of course there is functionality present in BSD that is not in Linux. My point is just that they are different.). For instance, Linux can more effectively scale to a large number of processors than BSD can. If you want to switch a box with many processors from Linux to BSD you should not expect to be able to do it without a big penalty.
All I am saying is that such a switch would not be nearly as seamless as you would imply. There is more to an operating system than applications.
"Yes, but most of the types of organizations that SCO is targeting are using relatively new builds of Linux. Given that this issue exists, when new kernels that are unencumbered are made available, don't you think people are going to snap them up? Realistically, I mean, think about it."
All I have to say to this is...huh?! Did you read my comment? Did you read your comment that my comment was responding to? Your response has nothing at all to do with what I was saying. You claimed in your original comment that by 2005 the only people still using 2.4 would be "Unabomber-like holdouts, crouching in a shed with a dilapidated old Pentium-II and a stockpile of candy bars and beer". That statement was ridiculously false, and so I felt a need to correct it.
Moving on to your newer and completely unrelated comment, the only reason SCO is targeting users of 2.4 is because the code they are complaining about wasn't in 2.2. What makes you think they aren't going to care if you're using 2.6? The code will still be there. 2.6 will still be "tainted". Of course, if they actually told the Linux community what the problem was the Linux community would fix it, but the whole damn point is that they refuse to tell anybody in order to sue them.
Moving on to the x86 stuff. I won't bother quoting your most recent comment because there's nothing there worth quoting. Again you have responded with a red herring. Your original post, the one I was responding to, said "By 2008...do you think we're still going to be using X86 machines, anyway?", to which my response was a resounding "yes"! x86 isn't going away anytime soon. But then you start babbling on about PDAs and cellphones, which of course are not x86, however that's completely irrelevant. I never claimed at any point that x86 was going to rule the universe; I simply claimed that it will still be there and still be important.
Do you honestly believe that normal desktop systems aren't even going to exist in 5 years? I certainly don't. If that makes me a "stick in the mud" then I guess I'm a stick in the mud. Personally I prefer to think of it as being realistic.
Finally, there is the issue of SCO's lawsuit being x86-specific. It's not. Yes, SCO was in the x86 business, but the
I agree with some of your points, and I agree with ignoring SCO, but I have this compulsive need to correct what I see as some rather large oversites in your post. No offense intended.
"2. By 2005, the BSDs and Linux will have become so similar in functionality, hardware support, and applications, that migrating from one to the other will be fairly painless. Since the BSDs are unencumbered, and SCO is specifically targeting the Linux 2.4 kernel, this means we have a great big safety net."
Linux and BSD have coexisted for what...12 years now, and they have nevertheless maintained distinctive personalities. Do you honestly believe that in 2 more years they will suddenly be interchangable? It's not as if that's the sort of thing anyone is even working on. It's just silly.
"3. By 2005, who's going to be using the 2.4 kernel? Unabomber-like holdouts, crouching in a shed with a dilapidated old Pentium-II and a stockpile of candy bars and beer? Any code which even remotely looks like SCO code is going to be stripped out long before then. So, the code in use by the time the court convenes is going to be unencumbered anyway. What could SCO possibly charge people money for, even if they win?"
There are still people running 2.2 now. Heck, there are still people running 2.0 now. I'm sure in 2005 there will be plenty of people still running 2.4. 2.6 isn't even done yet. Never underestimate the power of legacy software.
"5. By 2008 (when the case would probably get wrapped up and appealed, etc), do you think we're still going to be using X86 machines, anyway? It's 2003; how many of you are still using the 486's you had in '98? Who's still using a 16 bit O/S? Anyone? Bueller? Bueller?"
Another case of a strange conception of time. x86 has been with us for a very long time, and it is set to be with us for longer. Particularly if AMD's x86-64 extensions take off. Talking about 486s is a tad erroneous (even ignoring the fact that many of us, including me, still have 486s in their basements doing useful things) since the processors we use today are still based on the same exact ISA that those 486s were based on. So you just disproved your own point!
But nevermind that. What exactly does x86 have to do with anything anyway? Linux is a many-architecture OS. That is one if its strengths. To my knowledge there is nothing in SCO's lawsuit that is x86 specific.
You are right, but for the wrong reason.
Micropayments should in theory be a doable business. Yes, the money earned per transaction is extremely small, but with sufficient automation it is entirely possible to make money with a large enough number of small transactions. The reason nobody does is because our currency system is quantized.
It's a simple fact that you can't charge somebody a fraction of a penny for something. There's just no way around it; our currency system doesn't let you. You can use fractional amounts for all your internal accounting, however when it comes down to giving somebody the bill it must be some integer number of pennies.
So going back to your 3 cent example: A company trying to make money has to charge a fee. Paypal charges what, 5%? What is 5% of 3 cents? Why, .15 cents of course! What the hell is .15 cents? How do you charge somebody .15 cents? You are then left with the choice of either charging them nothing at all, in which case you probably won't make money, or charging them an entire cent. Well, 1 cent would be 33% overhead! Nobody is going to accept that. So what do you do?
Thus the only solution is consolidation: collect a bunch of payments into a single lump amount and then charge overhead based on that amount. The details of how this consolidation works will vary, but it must occur somewhere in the process. Notice that this is what everyone trying to get into the micropayments business does. Obviously somebody thinks they can make money off of it, even though they still have to keep track of the same number of transactions. In other words, the accounting when consolidating still really isn't any easier because the total number of transactions that must be tracked in some form or another is the same. All that is easier is the billing.
If our currency could deal with arbitrary fractions of a cent then this wouldn't be an issue. Unfortunately it can't, and trying to change that for the sake of micropayments really isn't worth it. (The cost of changing that would be enormous. All accounting software out there would a damn keeps track of money using integers and it would all have to be rewritten. Not to mention issues with the limited precision of computer systems possibly allowing for exploits of the Office Space [yes, I know Office Space is not the original source of that exploit, however I forget the original source and it is what came to mind] kind.)
I really don't see an easy solution to this problem
"Unless you've bought into Apple's desktop systems, buying an Apple notebook means having to maintain two seperate sets of software to run on your systems."
Hmm...nope. Debian Linux running on both my custom x86 desktop and my iBook. Funny how that works out.
"Well, that presupposes the NSA don't already have quantum decryption up and running. I wouldn't like to bet on that."
As someone who has actually spent some time studying how quantum computers work (or more accurately, how quantum computers should hopefully maybe work), I would take that bet without a moment's hesitation. We are at least 30 years away from a working quantum computer, assuming that a working quantum computer is even possible (Which is by no means assured). All we have now are a handful of theoretical algorithms without any hardware to run them, and a couple wildly speculative and impractical ideas of how we might someday be able to build the hardware.
Now I know a lot of people seem to think that the NSA has unlimited resources and can do anything they want to in secret, but we are far enough away from quantum computing that even if the NSA's budget was 100 times what it is now you shouldn't have to worry. I'm sure they would love to have a working quantum computer, but that's just the thing: Lot's of people would love to have a working quantum computer. This isn't an obscure subject area that others haven't thought about going into (which is how most secretive technological advances tend to occur); it's a thoroughly researched field with a huge prize for anyone who manages to get it to work. The amount of money that has been poured into quantum computing research is huge, and we still haven't gotten anywhere. Nobody has the slightest idea how to build the damn things!
As others mentioned, it's in /etc/hosts
But if you want really effective blocking, you're much better off with something like Junkbuster.
Let's hear it for mismatched hair!
I on the other hand have brown hair but a red beard. Figure that one out.
*sigh*...time for me to be geeky...
First off, regular TIE Fighters, TIE Interceptors, and TIE Bombers do not have any shields at all. And yes, their armor sucked but that's not the point.
The standard TIE Fighter is actually an excellent design in its own way. The things aren't that fast, but they are very small and maneuverable and can be a challenge to hit, especially in large numbers. But most importantly, they are simple. They are basically nothing more than a cockpit, lasers, and engine. They are most likely incredibly cheap to build and maintain, and because of their small size you can pack a lot of them into a star destroyer. Thus you can overwhelm your enemy with superior numbers. In large packs TIE Fighters are extremely deadly.
The Empire almost certainly does not place a high value on the lives of its pilots, which is why they get away with this sort of design. People are expendible. The only thing strange about the movies is that so few TIE Fighters are actually used in most engagements. I mean, look at the final battle in episode 4. You know that Death Star is packed full of TIE Fighters, but they only actually send out a handful to fight the rebel fighters. Maybe they were just overconfident.
"...impose an upload cap of say 2GB a month with a charge of $2.50 per GB or portion thereof uploaded over the 2GB level."
Funny, that's exactly what my university is doing. The cap is even at 2GB a month. The price they charge above that works out to $3 a GB however.
"I'll sell you a Thinkpad 770 for fifty bucks!"
;)
Does that include shipping? If so, if he doesn't want it, I'll take it
Since Loki is defunct you should check out the icculus.org page for more up-to-date information. Not that they have all that much information there either...
To my knowledge it doesn't do any real dependency checking. If the correct libraries are not installed then it just won't work. Since it's really intended for third party software and not core functionality this isn't as big a problem as it could be. After all, it's always possible to use your package manager to grab whatever libraries you're missing manually, and with a resonably up to date system you really shouldn't have to worry about that very often (I've never really had a problem with it). I'll admit that ideally this is something the user shouldn't have to do, but with so many different distributions out there with so many different package managers it's not an easy issue to solve. I know I would never want a tool like this to go installing libraries outside of my package management system, since that kind of defeats the entire purpose of package management.
On the upside there is a corresponding uninstaller and it seems to work just fine. At least I have never had any problems with it.
Wait...you consider those things to be negatives? I always thought they were bonuses. I mean...it's just cool ;)
The technical solution to this problem already exists: It's called the Loki installer. I run Debian and I use apt-get for most free packages, but I've found that for the occasional self-contained commercial third party app the Loki installer works extremely well. It has been adopted by just about every commercial game released for Linux as far as I know, even those that have nothing at all to do with Loki. But it has also been adopted by many non-game apps.
It's exactly the solution you're looking for. The only real problem is that it's not a standard per say. There are still many apps out there that could benefit from using the Loki installer that for whatever reason do not. If the LSB were to officially support the Loki installer as the correct way to install third party software on a Linux system and provide guidelines for its use then we would be getting somewhere.
"...it writes less crap on your screen..."
What?! Noooooo! I love the crap on the screen. The crap on the screen is great. I like to show it to people who know nothing about computers in order to make them think I'm working on highly technical computer stuff that they could never understand so they should just leave me alone when in actuality I'm just reading slashdot while I wait for a new kernel to compile. And damn that was a long sentence.
"If you mod me -1 flamebait, you my friend, have no sense of humor."
;)
That's a great line. I should put it on all my posts
"Tesla demonstrated "beaming power" at the beginning of the last century. If things had turned out slightly differently for him, we might all be receiving our electricity wirelessly, and you wouldn't be making snide remarks about it."
Oh please. Spare me. The fact that we aren't "receiving our electricity wirelessly" has nothing at all to do with how things "turned out" for Tesla. It has to do with the fact that while it is theoretically possible (hell, I've even done this on a small scale for demonstation purposes), it's completely and utterly impractical. The traditional tesla coil is omnidirectional and therefore any energy you put into the thing is spread out uniformly about the tesla, and the vast majority of it doesn't actually reach the device you want to power. This is in stark contrast to a wire, which will take all of your energy from point A to point B (minus some lost to resistence of course, but that's a comparatively small effect). And I haven't even mentioned the side effects of the Tesla approach. The things tend to ionize the air and create a lot of ozone and there's no way that sort of approach could be healthy for people in the long run if it was actually implemented on a large scale.
This of course has nothing to do with the discussion at hand, which would most likely involve beaming power using masers or lasers, which, being focused beams, have the advantage of not spreading out very much as they travel great distances. This sort of approach is at least feasible, but there are a lot of details that have yet to be worked out.
Anyway, I will leave you with two parting thoughts:
1. The Martian atmosphere is much thinner and of a very different composition than the Earth's. How do we know that this sort of technology would be nearly as effective there as it is on Earth?
2. If you're just going to beam energy to your craft anyway, why not just use that energy to power a more conventional drive? What is the real advantage of this approach?
Well, I've rambled enough.
JC! I don't think I've seen you comment on slashdot before. I miss your website. How have you been? Send me an email sometime: davek at sdf dot lonestar dot org
Physics Nobody, aka Upsilon