You could do a little beter than just dynamic code unrolling. Each time the virus propagates, it needs to rewrite parts of itself at the machine code level, so that the bitpattern changes. For example, there's more than one way to zero a register (XOR with self, subtract from self, move immediate zero to self) and there's more than one way to add a constant (add one, subtract -1). This would make viruses harder to identify.
Viruses also need to propagate decoys. For example, 65 gigabytes of simple pattern, bzip'd, is less than 100k. So, to thwart scanning of compressed files, send around lots of compressed nothing, that will bog down the scanners. That will cause people not to use them.
SoBig's rendezvous scheme was also pretty silly. 20 fixed IP addresses? Get real. Each virus should carry around (say) 100 IP addresses, and as it propagates it should randomly replace old addresses with new ones (dynamically assigned IP addresses would give this some trouble -- imagine that, variable IP addresses as a good thing). That way the viruses form a mesh that is not vulnerable to the loss of just a few links. Communications over the mesh would need to be public-key-signed, so that it could not be hijacked by people attempting to trace the behavior of the virus.
It could also tear apart its "next step" into pieces so that anyone intercepting just a few copies of the virus would be unable to tell what to do. At the activation time, it could do peer-to-peer reassembly of the Next Step, either using simple cut-and-paste, or using something more clever like Reed-Solomon coding so that it need not be so picky about exactly which peers it finds. (The peers, of course, must be programmed not to reveal their part of the Next Step until after the activation time.)
There's also been not nearly enough multi-mode propagation. An email virus combined with a few buffer-overflow attacks could get in behind a firewall and make a thorough mess of things.
The virus could also undertake a DDOS against all the usual suspects after it had achieved critical mass (similar to the behavior of actual bacteria as individuals, versus as a group) to make it difficult to receive security updates or news.
Macs derive some benefit from their approach to "administrator rights". I've got them, but to actually do anything, I need to type a password.
On Windows (at least W2K) if you need administrator privileges, then they're on all the time. Accidentally run a virus while in administrator mode, and it gets to use those administrator privileges, too.
Quoting
Felten
on the bizarro world of law
and policy debates:
One of the bizarro rules is that you should be happy when the other side accuses you of lying or acting in bad faith. In the normal world, such accusations will make you angry; but in bizarro world they indicate that the other side has lost confidence in its ability to win the argument on the merits. And so you learn to swallow your outrage and smile when people call you a scoundrel.
Of course, it goes both ways. Snide remarks
about McBride don't hurt him one bit. Much more
effective to be sure that any potential purchasers
of SCO stock know that this business plan (which is what it is, and it is clearly the only card left in their deck) is very likely to fail. SCO will continue this behavior until they are out of business, because it is the only choice that they have left themselves.
If you let the beer go flat first, and use a can with a mouth-sized nozzle and vent holes in the bottom, you can get 1.5 US pints down in under 10 seconds with little or no practice.
The "reason" for this is the Beer-Bike relay race held every year at Rice University. The best chuggers could pretty regularly finish their beer in under 3 seconds; I heard of, but did not see with my own eyes, a 1.6 second chug.
I was more than a little disappointed to see that Apple's Mail.app was not included in the comparison. It wouldn't surprise me in the least if it were already the most widely used Bayesian spam filter. Unsurprisingly, it is also very easy to use.
Mail.app also combines Bayesian filtering with the Address book -- any mail from a known correspondent won't be tagged as Junk. This reduces the risk of false positives. This is an integration cheat not available to stand-alone spam filters, because Apple supplies the Address book app and provides other integration between the two applications. But, (as a self-centered end-user) I don't care that it is a cheat, I am merely happy that it all works well. (And I cross my fingers and hope that somehow, Apple's C/C++/Objective-C programmers are less prone to leaving buffer overflow holes than Microsoft's programmers clearly are.)
The author needs to read Edward Tufte's books on presenting information (e.g., The Visual Display of Quantitative Information).
There is one minor problem with the implied/obvious solution to C buffer overflows. The "obvious" fix is to write that code in Java, but often as not, interesting "Java" functionality is instead implemented with native libraries, which are usually written in C or C++.
Other alternatives (Lisp, ML, Perl, Smalltalk) suffer similarly -- until we have decoders for all the various formats and protocols written in the safe languages themselves, there's still a risk.
Yes, you can do good statistics with subjective judgements. Not clear that these guys did good statistics, but it happens all the time, and for lossy music encoding, who is the winner is in fact a subjective judgement.
Ever wondered how essay tests get graded by teams of people? You look at the distribution of scores reported by the different graders -- you can spot just the sort of glitches that perplex you so, and with a little work, even correct for these biases. You can throw a few "test papers" into the mix to compare how different people grade something that is exactly the same.
Re:get down to the nitty gritty.
on
Eclipse in Action
·
· Score: 2, Insightful
Memory's cheap. It was easier to buy my own (512m) than argue for why it was necessary to run Eclipse. I'd have bought a gigabyte if there were slots in the box that would take it.
No, SPEC is supposed to be (more nearly) about real world use. That's why the benchmarks are take from actual applications, that actually mattered to someone, once.
That said, the first thing that happens when a new set of SPEC benchmarks comes out is everyone tries to game them. This can vary, from pattern-matching for the SPEC inner loops and replacing them with hand-crafted assembly language, to tuning your scheduler so it works very well on SPEC, to choosing your "branch prediction heuristics" so that it has 100% accuracy on SPEC.
A fair choice of compilers is those that are actually used by most developers. For MacOS X, gcc is a no-brainer, that's what you get. It's not so clear for Intel; I have always understood that Intel's compilers were well-tuned for benchmarks, but I don't know if they are used for anything else. I was under the impression that most Windows developers used Visual C++, and that most Linux developers used gcc.
Gcc has the additional benefit of being open source. I am certain that it is well-tuned for compiling certain pieces of code (back in the SPEC89 days, it excelled at compiling itself) but it is open source, and thus it cannot hide the sort of tricks that I know were performed by commercial compilers to do well on benchmarks. (I know because I worked on them, and studied the competition.) Before you sling too many stones at Apple for their arguably appropriate benchmarking configurations, you might, say, ask the guys at Intel if you could have a look at the source code for their compilers that generate such great benchmarks.
Speaking of benchmark cheats, there was a paper by Ben Zorn some years back on using a neural network branch-predicter. It worked very well in a "fair" evaluation (train on 19 of 20 benchmarks, measure on the other, repeat 20 times), but it worked even better in an "unfair evaluation" (train on all 20 benchmarks so that the "test" benchmark is in the training set). Gcc should do that, too, and make it configurable. That way, they can cheat like crazy on the industry-standard benchmarks, but then they can also let developers use profiling to generate tuned heuristics for whatever they happen to be working on. It's more flexible/usable than straight profile-directed optimization, because if you change the source code, the predictions only degrade a little.
Note that whether IBM intends to take it to trial or buy out SCO, their response (in this situation) will be identical. They get the best price by acting as if SCO had no case -- that drives down the price, which makes the acquisition more attractive. SCO knows this too, of course, and they are required to act as if they did have a valid case, with the exception that if they really did have a valid case, it they would have stuck to it a bit more consistently. The fact that their story changes, and that they seem less eager to bring it to trial than IBM, makes me think their case is not as strong as they claim.
I think, too, that IBM may be pushing for a stock price collapse; it all depends on shareholder perceptions. If they turn tail, then IBM gets to shut this down on the cheap, plus they get the option to do exactly what SCO accuses them of doing, which is copy Unix code into Linux. I'm sure Sun would like that.
So, that's my prediction -- more PR battles, IBM does whatever it takes to depress the SCO stock price, then they buy SCO cheap. It could still be a net win for the SCO shareholders, if they get more than it was trading at before all this folderol.
I've driven a front-wheel drive car in enough rain that it would start to hydroplane at 55 climbing hills (weight off the front wheels, more work to climb hill). You notice it instantly (when the speedometer reads about 65) and it is Not Fun;the steering gets all wiggly (no traction) and the engine is revving up and down as the hydroplaning varies. Unless you are a total idiot, you will immediately take your foot off the gas and slow down. Seems extremely unlikely that the situation you describe would occur. Seems much more likely that in the 35,000 auto deaths we expect this year, fault will sometimes be incorrectly assigned by the system we've already got.
Or, to put it differently -- odds are that if you are in an accident, it will not be in this contrived situation. In the usual case, do you want good data to help resolve fault, or just a pair of lawyers?
Besides Lisp and Eclipse and IntelliJ, this sort of syntax-tree-oriented manipulation has been going on in optimization and programming language research for the last 20 years. (And Eclipse does a fine job -- all that chit-chat about encapsulating public instance variables is just a choice on the refactoring menu, and it's free. I've got no idea why Gosling thinks this is new and interesting.)
For example, people (including me) at Rice University worked on a source-to-source Fortran vectorizer that manipulated ASTs. Derivatives of that AST reappeared in the Dana/Ardent/Stardent compilers for C and Fortran. The Fortran AST was also used in an AST-based editor, a Fortran interpreter/debugger, a pretty printer, an ugly (fixed-format card image) printer, and dependence-displaying Fortran browsers (dependence here refers to loop iteration dependences that hinder parallelization).
One thing that became clear while working on AST-based editors was that people didn't want the tree structure continuously in their face. For example, at the expression level, Fortran programmers (as opposed to, say, Lisp programmers) found tree-based editing to be intolerable. The tree structure can be handy for browsing/skimming code; uninteresting blocks of code could be elided. But, people did not want to be prevented from making changes that were "only" syntactic.
Keep in mind, this is just the Rice-centric view, other people were doing things like program slicing (what code depends on the value of this variable). I'd love to see some of this stuff nicely integrated into an IDE -- that nice integration is the hard part, the theory is generally done and old.
Very true. Eclipse is great, and the IBM VM is generally faster than Sun's VM.
Re:So let me get this straight...
on
SCO SCO SCO!
·
· Score: 1
But...
If this goes to trial, it all comes out in discovery. If SCO believes that they will actually end up in court, they gain little by keeping it a secret. (Yes, there is always the slim chance of a settlement, etc., but nothing makes your case in the press like proof.)
In addition, as several posts here have made clear, if the offending code is pointed out, it will be removed -- "problem" solved. If the existence of that code in the Linux source base were the actual harm, it would be fixed sooner if they simply identified the lines in Linux that they allege are infringing (this is different from proving that they own the IP, and reveals less of their own source code). It cannot help their legal case that they ignore this opportunity to get the alleged problem fixed as soon as possible.
This assumes that the physical materials add value. A mere 5Gb iPod holds roughly 100 CDs worth of music. Ever tried to fit 100 CDs into your shirt pocket?
It's unclear whether your question is one of morality, or deterrence. I'll assume deterrence for the moment. A punishment is only a credible deterrent if it is actually likely that the criminal will get caught. The false-positive rate of the deterrence (innocent people punished, or merely innocent people spending weeks demonstrating their innocence in court) and the surveillance infrastructure needed to improve the accuracy of the punishment both reduce our freedom.
Why would I need... ? Why shouldn't it be easy, that's the question you should be asking. It's easy for Windows, easy for OS X, what's wrong with Linux? If the user wants to waste resources, they're paying the power bill.
You didn't mention what OS you were running, which might indeed make a difference. Experimentally, I just copied a 68MB file from one folder on a hard disk to a folder on an encrypted volume on that same disk, and it took 10 seconds (800Mhz G4, MacOS 10.2.4, 200$ of memory). That's fast enough for me.
In terms of why choose a Mac over Linux or Windows:
- it definitely has a better UI than Linux.
- it definitely has better applications than Linux.
- it is definitely easier to manage and deal with security updates than Linux.
- it is definitely easier to manage and deal with security updates than Windows.
- I don't trust Microsoft to get security right, and I trust them less (as a corporation) than Apple. This is based on their track record.
- As an OS for nerd work, I like Unix more than Windows. I want emacs, it's got emacs. I want TeX, it's got TeX (yes, I know Cygwin and use it, and it's amazing, but it still fails the live-or-memorex test).
- iTunes, iPhoto, Disk Copy (where did I get that encrypted disk from?), iPod.
- adding hardware to a Mac (well, a G4 box) is easy; adding hardware to a PC is generally not as easy. (I've done both).
I agree, a Pentium box is cheaper, on a dollars-per-cycles basis. However, the Mac makes better use of the cycles, and makes better use of my time. I have never wanted to own a PC; I do like Macs, and have bought them in the past, and will probably buy them in the future.
I've used Eclipse on W2k, Linux, and MacOS X. As near as I can tell, it is best on Windows, worst on Linux, mostly because of problems with cut-and-paste.
Eclipse is the first IDE that got me pried loose from emacs. I've tried others, used MSVC++ for debugging, but this is the first time I've happily edited in the IDE, and I now find myself getting annoyed with emacs where it fall short of Eclipse's many editing features.
As far as integration goes, between the debugger, junit, ant, and cvs, I'm relatively impressed.
Downsides: I think it takes too long to learn. The 3rd-party plugins are a little random in their quality. It uses more memory than you will find in an old machine, at least for projects that get into the 100kloc range.
Modula-3 is pretty much Java with big clunky keywords. If you can't touch-type, you'll hate it. The two features I feel the lack of are interface types (data-less multiple inheritance) and first-class exception types. On the plus side, you can have non-heap-allocated simple aggregates, the interface to native code is lighter-weight, certain other overheads are removed, and if absolutely necessary, you can drop into unsafe code. It supports generics well enough (I want more, but it's good enough).
OCaml is Objective Caml which is Objective Categorical ML. Don't let that put you off.
Tcl can do GUIs. It's another scripting language, sort of.
Another choice is Modula-3. It lacks the comprehensive pile of libraries that comes with Java, but it is a "safe" language that has been widely ported over the years (I worked on one of the very first ports, so perhaps I am biased). I wrote a simple web server in it, I've used a simple mail client written in it. On the plus side (for detail/speed freaks) it supports arrays and structures as "value" objects, so you are not forced to use objects for everything (this is a bug or a feature, depending on your point-of-view). Like C#, it gives you the ability to write and get to "unsafe" code (but, don't use this unless absolutely necessary).
OCaml is another potential choice. It has a better type system than Java and Modula-3.
A good friend whose opinion I respect says great things about Python.
I don't have enough experience coding GUIs, so I cannot definitely say that these languages are good or bad for that.
I've also looked at Squeak, a sort-of-open Smalltalk implementation. Some of the demos are truly amazing, however I am unclear on the overall stability of Squeak as a platform. It is worth a look, though it is sufficiently different from C/C++/Java/Modula-3 that you might find it difficult to learn at first (again, some say feature, some say bug).
Slashdot Mirror
Seems like it would be more effective than a mere air hose.
You could do a little beter than just dynamic code unrolling. Each time the virus propagates, it needs to rewrite parts of itself at the machine code level, so that the bitpattern changes. For example, there's more than one way to zero a register (XOR with self, subtract from self, move immediate zero to self) and there's more than one way to add a constant (add one, subtract -1). This would make viruses harder to identify.
Viruses also need to propagate decoys. For example, 65 gigabytes of simple pattern, bzip'd, is less than 100k. So, to thwart scanning of compressed files, send around lots of compressed nothing, that will bog down the scanners. That will cause people not to use them.
SoBig's rendezvous scheme was also pretty silly. 20 fixed IP addresses? Get real. Each virus should carry around (say) 100 IP addresses, and as it propagates it should randomly replace old addresses with new ones (dynamically assigned IP addresses would give this some trouble -- imagine that, variable IP addresses as a good thing). That way the viruses form a mesh that is not vulnerable to the loss of just a few links. Communications over the mesh would need to be public-key-signed, so that it could not be hijacked by people attempting to trace the behavior of the virus.
It could also tear apart its "next step" into pieces so that anyone intercepting just a few copies of the virus would be unable to tell what to do. At the activation time, it could do peer-to-peer reassembly of the Next Step, either using simple cut-and-paste, or using something more clever like Reed-Solomon coding so that it need not be so picky about exactly which peers it finds. (The peers, of course, must be programmed not to reveal their part of the Next Step until after the activation time.)
There's also been not nearly enough multi-mode propagation. An email virus combined with a few buffer-overflow attacks could get in behind a firewall and make a thorough mess of things.
The virus could also undertake a DDOS against all the usual suspects after it had achieved critical mass (similar to the behavior of actual bacteria as individuals, versus as a group) to make it difficult to receive security updates or news.
So, yeah, life could get plenty interesting.
Macs derive some benefit from their approach to "administrator rights". I've got them, but to actually do anything, I need to type a password.
On Windows (at least W2K) if you need administrator privileges, then they're on all the time. Accidentally run a virus while in administrator mode, and it gets to use those administrator privileges, too.
If you let the beer go flat first, and use a can with a mouth-sized nozzle and vent holes in the bottom, you can get 1.5 US pints down in under 10 seconds with little or no practice.
The "reason" for this is the Beer-Bike relay race held every year at Rice University. The best chuggers could pretty regularly finish their beer in under 3 seconds; I heard of, but did not see with my own eyes, a 1.6 second chug.
I was more than a little disappointed to see that Apple's Mail.app was not included in the comparison. It wouldn't surprise me in the least if it were already the most widely used Bayesian spam filter. Unsurprisingly, it is also very easy to use.
Mail.app also combines Bayesian filtering with the Address book -- any mail from a known correspondent won't be tagged as Junk. This reduces the risk of false positives. This is an integration cheat not available to stand-alone spam filters, because Apple supplies the Address book app and provides other integration between the two applications. But, (as a self-centered end-user) I don't care that it is a cheat, I am merely happy that it all works well. (And I cross my fingers and hope that somehow, Apple's C/C++/Objective-C programmers are less prone to leaving buffer overflow holes than Microsoft's programmers clearly are.)
The author needs to read Edward Tufte's books on presenting information (e.g., The Visual Display of Quantitative Information).
There is one minor problem with the implied/obvious solution to C buffer overflows. The "obvious" fix is to write that code in Java, but often as not, interesting "Java" functionality is instead implemented with native libraries, which are usually written in C or C++.
Other alternatives (Lisp, ML, Perl, Smalltalk) suffer similarly -- until we have decoders for all the various formats and protocols written in the safe languages themselves, there's still a risk.
Yes, you can do good statistics with subjective judgements. Not clear that these guys did good statistics, but it happens all the time, and for lossy music encoding, who is the winner is in fact a subjective judgement.
Ever wondered how essay tests get graded by teams of people? You look at the distribution of scores reported by the different graders -- you can spot just the sort of glitches that perplex you so, and with a little work, even correct for these biases.
You can throw a few "test papers" into the mix to compare how different people grade something that is exactly the same.
Memory's cheap. It was easier to buy my own (512m) than argue for why it was necessary to run Eclipse. I'd have bought a gigabyte if there were slots in the box that would take it.
No, SPEC is supposed to be (more nearly) about real world use. That's why the benchmarks are take from actual applications, that actually mattered to someone, once.
That said, the first thing that happens when a new set of SPEC benchmarks comes out is everyone tries to game them. This can vary, from pattern-matching for the SPEC inner loops and replacing them with hand-crafted assembly language, to tuning your scheduler so it works very well on SPEC, to choosing your "branch prediction heuristics" so that it has 100% accuracy on SPEC.
A fair choice of compilers is those that are actually used by most developers. For MacOS X, gcc is a no-brainer, that's what you get. It's not so clear for Intel; I have always understood that Intel's compilers were well-tuned for benchmarks, but I don't know if they are used for anything else. I was under the impression that most Windows developers used Visual C++, and that most Linux developers used gcc.
Gcc has the additional benefit of being open source. I am certain that it is well-tuned for compiling certain pieces of code (back in the SPEC89 days, it excelled at compiling itself) but it is open source, and thus it cannot hide the sort of tricks that I know were performed by commercial compilers to do well on benchmarks. (I know because I worked on them, and studied the competition.) Before you sling too many stones at Apple for their arguably appropriate benchmarking configurations, you might, say, ask the guys at Intel if you could have a look at the source code for their compilers that generate such great benchmarks.
Speaking of benchmark cheats, there was a paper by Ben Zorn some years back on using a neural network branch-predicter. It worked very well in a "fair" evaluation (train on 19 of 20 benchmarks, measure on the other, repeat 20 times), but it worked even better in an "unfair evaluation" (train on all 20 benchmarks so that the "test" benchmark is in the training set). Gcc should do that, too, and make it configurable. That way, they can cheat like crazy on the industry-standard benchmarks, but then they can also let developers use profiling to generate tuned heuristics for whatever they happen to be working on. It's more flexible/usable than straight profile-directed optimization, because if you change the source code, the predictions only degrade a little.
Note that whether IBM intends to take it to trial or buy out SCO, their response (in this situation) will be identical. They get the best price by acting as if SCO had no case -- that drives down the price, which makes the acquisition more attractive. SCO knows this too, of course, and they are required to act as if they did have a valid case, with the exception that if they really did have a valid case, it they would have stuck to it a bit more consistently. The fact that their story changes, and that they seem less eager to bring it to trial than IBM, makes me think their case is not as strong as they claim.
I think, too, that IBM may be pushing for a stock price collapse; it all depends on shareholder perceptions. If they turn tail, then IBM gets to shut this down on the cheap, plus they get the option to do exactly what SCO accuses them of doing, which is copy Unix code into Linux. I'm sure Sun would like that.
So, that's my prediction -- more PR battles, IBM does whatever it takes to depress the SCO stock price, then they buy SCO cheap. It could still be a net win for the SCO shareholders, if they get more than it was trading at before all this folderol.
I've driven a front-wheel drive car in enough rain that it would start to hydroplane at 55 climbing hills (weight off the front wheels, more work to climb hill). You notice it instantly (when the speedometer reads about 65) and it is Not Fun;the steering gets all wiggly (no traction) and the engine is revving up and down as the hydroplaning varies. Unless you are a total idiot, you will immediately take your foot off the gas and slow down. Seems extremely unlikely that the situation you describe would occur. Seems much more likely that in the 35,000 auto deaths we expect this year, fault will sometimes be incorrectly assigned by the system we've already got.
Or, to put it differently -- odds are that if you are in an accident, it will not be in this contrived situation. In the usual case, do you want good data to help resolve fault, or just a pair of lawyers?
Besides Lisp and Eclipse and IntelliJ, this sort of syntax-tree-oriented manipulation has been going on in optimization and programming language research for the last 20 years. (And Eclipse does a fine job -- all that chit-chat about encapsulating public instance variables is just a choice on the refactoring menu, and it's free. I've got no idea why Gosling thinks this is new and interesting.)
For example, people (including me) at Rice University worked on a source-to-source Fortran vectorizer that manipulated ASTs. Derivatives of that AST reappeared in the Dana/Ardent/Stardent compilers for C and Fortran. The Fortran AST was also used in an AST-based editor, a Fortran interpreter/debugger, a pretty printer, an ugly (fixed-format card image) printer, and dependence-displaying Fortran browsers (dependence here refers to loop iteration dependences that hinder parallelization).
One thing that became clear while working on AST-based editors was that people didn't want the tree structure continuously in their face. For example, at the expression level, Fortran programmers (as opposed to, say, Lisp programmers) found tree-based editing to be intolerable. The tree structure can be handy for browsing/skimming code; uninteresting blocks of code could be elided. But, people did not want to be prevented from making changes that were "only" syntactic.
Keep in mind, this is just the Rice-centric view, other people were doing things like program slicing (what code depends on the value of this variable). I'd love to see some of this stuff nicely integrated into an IDE -- that nice integration is the hard part, the theory is generally done and old.
Very true. Eclipse is great, and the IBM VM is generally faster than Sun's VM.
But...
If this goes to trial, it all comes out in discovery. If SCO believes that they will actually end up in court, they gain little by keeping it a secret. (Yes, there is always the slim chance of a settlement, etc., but nothing makes your case in the press like proof.)
In addition, as several posts here have made clear, if the offending code is pointed out, it will be removed -- "problem" solved. If the existence of that code in the Linux source base were the actual harm, it would be fixed sooner if they simply identified the lines in Linux that they allege are infringing (this is different from proving that they own the IP, and reveals less of their own source code). It cannot help their legal case that they ignore this opportunity to get the alleged problem fixed as soon as possible.
I could stand a robot if it could fold my laundry.
Is JSR 166 really in 1.5? Neither the happy-talk article nor JSR 201 (draft proposals for 1.5) imply this.
This assumes that the physical materials add value. A mere 5Gb iPod holds roughly 100 CDs worth of music. Ever tried to fit 100 CDs into your shirt pocket?
So you think this will be about as successful as the iPod, right? They could do worse.
It's unclear whether your question is one of morality, or deterrence. I'll assume deterrence for the moment. A punishment is only a credible deterrent if it is actually likely that the criminal will get caught. The false-positive rate of the deterrence (innocent people punished, or merely innocent people spending weeks demonstrating their innocence in court) and the surveillance infrastructure needed to improve the accuracy of the punishment both reduce our freedom.
Why would I need ... ? Why shouldn't it be easy, that's the question you should be asking. It's easy for Windows, easy for OS X, what's wrong with Linux? If the user wants to waste resources, they're paying the power bill.
You didn't mention what OS you were running, which might indeed make a difference. Experimentally, I just copied a 68MB file from one folder on a hard disk to a folder on an encrypted volume on that same disk, and it took 10 seconds (800Mhz G4, MacOS 10.2.4, 200$ of memory). That's fast enough for me.
In terms of why choose a Mac over Linux or Windows:
- it definitely has a better UI than Linux.
- it definitely has better applications than Linux.
- it is definitely easier to manage and deal with security updates than Linux.
- it is definitely easier to manage and deal with security updates than Windows.
- I don't trust Microsoft to get security right, and I trust them less (as a corporation) than Apple. This is based on their track record.
- As an OS for nerd work, I like Unix more than Windows. I want emacs, it's got emacs. I want TeX, it's got TeX (yes, I know Cygwin and use it, and it's amazing, but it still fails the live-or-memorex test).
- iTunes, iPhoto, Disk Copy (where did I get that encrypted disk from?), iPod.
- adding hardware to a Mac (well, a G4 box) is easy; adding hardware to a PC is generally not as easy. (I've done both).
I agree, a Pentium box is cheaper, on a dollars-per-cycles basis. However, the Mac makes better use of the cycles, and makes better use of my time. I have never wanted to own a PC; I do like Macs, and have bought them in the past, and will probably buy them in the future.
I've used Eclipse on W2k, Linux, and MacOS X.
As near as I can tell, it is best on Windows,
worst on Linux, mostly because of problems
with cut-and-paste.
Eclipse is the first IDE that got me pried loose
from emacs. I've tried others, used MSVC++ for
debugging, but this is the first time I've happily
edited in the IDE, and I now find myself getting
annoyed with emacs where it fall short of
Eclipse's many editing features.
As far as integration goes, between the debugger,
junit, ant, and cvs, I'm relatively impressed.
Downsides: I think it takes too long to learn.
The 3rd-party plugins are a little random in their
quality. It uses more memory than you will find
in an old machine, at least for projects that
get into the 100kloc range.
Modula-3 is pretty much Java with big clunky keywords. If you can't touch-type, you'll hate it. The two features I feel the lack of are interface types (data-less multiple inheritance) and first-class exception types. On the plus side, you can have non-heap-allocated simple aggregates, the interface to native code is lighter-weight, certain other overheads are removed, and if absolutely necessary, you can drop into unsafe code. It supports generics well enough (I want more, but it's good enough).
OCaml is Objective Caml which is Objective Categorical ML. Don't let that put you off.
Tcl can do GUIs. It's another scripting language, sort of.
Well, there is Java. You could do much worse.
Another choice is Modula-3. It lacks the comprehensive pile of libraries that comes with Java, but it is a "safe" language that has been widely ported over the years (I worked on one of the very first ports, so perhaps I am biased). I wrote a simple web server in it, I've used a simple mail client written in it. On the plus side (for detail/speed freaks) it supports arrays and structures as "value" objects, so you are not forced to use objects for everything (this is a bug or a feature, depending on your point-of-view). Like C#, it gives you the ability to write and get to "unsafe" code (but, don't use this unless absolutely necessary).
OCaml is another potential choice. It has a better type system than Java and Modula-3.
A good friend whose opinion I respect says great things about Python.
I don't have enough experience coding GUIs, so I cannot definitely say that these languages are good or bad for that.
I've also looked at Squeak, a sort-of-open Smalltalk implementation. Some of the demos are truly amazing, however I am unclear on the overall stability of Squeak as a platform. It is worth a look, though it is sufficiently different from C/C++/Java/Modula-3 that you might find it difficult to learn at first (again, some say feature, some say bug).