Assuming you can trivially find out anything about anybody, just add a filter to your inbox that rejects mail from anyone who is known for spamming. And thus, spam would not exist in the "free data utopia".
How is relying on a MIME type provided by the e-mail any better than relying on the extension provided by the e-mail? How will using MIME types allow the e-mail client to more easily distinguish what file types have executable content? (After all, some document formats could include embedded scripts.) How will using MIME types help if the executable is in a zip, like MyDoom was?
This glaring security hole is the result of the trusted-executable paradigm used by almost every OS in existence (including Windows and every variant of Unix). You do the math.
Yes, hijacking programs which have already been marked as "trusted" is still a problem. Unfortunately, it is a problem not just fundamental to the OS's we use, but to the actual programming languages we use. In C, any piece of code anywhere can perform any system call with the same priveledges as the rest of the process it is running in. To fix this, we need to move to programming languages that have capability-based security built-in. Sadly, none of the major languages used today seem to make any attempt at this, and it will take a very long time to popularize one that does. (I am actually working on such a programming language myself, but it's only in the early prototype phases.)
MyDoom is attached as a zip containing an executable. It does not appear as a jpg, doc, or other file type. It appears as a zip. What would you expect to happen when you click on a zip attachment? The e-mail program is probably not designed to explicitly recognize zips, so it sends it off to the OS's default handler for zip files. That handler happily allows the user to open the contents since it has no idea that the thing came from an untrusted source.
Being able to open a document attached to an e-mail with a single click is user-friendly, and is a feature I quite like having, even in my non-Microsoft e-mail client. It makes sense to prevent users from running actual executables with a single click (and every e-mail client I've seen does so), but it is not possible for the e-mail client to keep a complete list of dangerous vs. safe file types. Zips in particular are used legitimately in e-mails far more often than not, so why should you expect your e-mail client to stop you from opening one?
The real problem here is the trusted-executable paradigm on which all major operating systems are based. All variants of Unix (which, in my book, includes Windows) assume that you trust any executable you run. In other words, they assume that you know exactly what you are doing. Obviously, users don't always know what they are doing, and the OS should be there to watch and double-check with the user when anything suspicious happens. The OS should ask the user if they really want to allow this program to access the internet (spreading itself). It should ask if they really want to install that backdoor and let it run on startup. It should explain what each question means so that the user can make an informed decision.
If OS's did these things, not only would viruses no longer spread, but things like spyware and adware installed by programs like RealPlayer would no longer function. In fact, because it would be so obvious when a program contained spyware, companies would probably be less inclined to try to include it in the first place.
So why does no OS do this? Probably because it would take some work to implement. Who wants to be the first?
That's a great idea! In fact, I've been avocating exactly that for some time now. I note, however, that no operating system in existence currently does this, so to blame Microsoft specifically isn't exactly fair.
(Actually, you can use Zone Alarm on Windows to at least force programs to ask permission before using the network. I don't know if any equivalent program exists for any other OS.)
Do they exploit any vulnerability that Microsoft is responsible for creating? No. (They spread by tricking users into running the attached executables.)
I know it's fun to pretend that everything bad is Microsoft's fault (and I'm no fan of Microsoft myself), but come on... how does it make any sense to prefix something with "Microsoft" when Microsoft had absolutely nothing to do with it? What's next? "Microsoft OpenSSL vulnerability discovered"? "Microsoft recording industry sues 12-year-old kid"? "Microsoft PATRIOT act renewed"? "Hacker charged with violating the Microsoft DMCA"?
a function uses the parameters it is passed most of the time.
Sure, functions you are used to, written in normal, eager-evaluation languages, use all of their parameters most of the time. However, if you had lazy computation available, you might be more inclined to write code in completely different ways that take advantage of that functionality. Those ways might actually be a lot more efficient than you'd imagine. You probably haven't thought too hard about them since you haven't used any lazy computation languages.
Good compilers can do enough optimization to mostly negate the drawbacks of lazy computation. Yes, it will be less efficient if you simply rewrite eager-computation code in a lazy-computation language. But, perhaps there's some other way you could write that code to take advantage of lazy computation to make it faster?
Obviously, the answer to this question isn't simple, and I don't pretend to know for sure which method is "better".
If you only just learned it last year in class, no wonder you find it complicated. You probably have much more experience with imperative languages. Indeed, when you think about programming, your thoughts are probably imperative. Just as a native English speaker might think Japanese is complicated (even after "learning it in class last year"), a native imperative programmer will find functional programming difficult at first.
You know how they say, once you know one programming language, learning another is easy? Yes, once you know C++, picking up Java is a sinch, and you can probably even read someone's Python code without even learning the language first. But, this is because all of these languages are imperative. If someone tells you to write something in LISP, you may be able to figure out the syntax pretty easily, but no doubt you'll find yourself using imperative constructs like "progn". And, when you do that, the language seems very difficult to use indeed, because it was never supposed to be used that way. I made this mistake once myself.
Anyway, point is, it's not really fair for you to be judging functional languages until you've practiced them as much as the imperative ones. Personally, my imperative experience still dwarfs my functional experience by a factor of thousands... but I've now convinced myself that, for most purposes, functional languages are superior.
We have never had vulnerabilities exploited before the patch was known - Actual quote. Maybe not completely true, but mostly true. "Never" should be replaced with "almost never". I consider that an honest mistake.
Windows is never vulnerable until a patch appears - Misquote by Michael. Absurd. Anyone who would make this claim is an idiot.
The head of Microsoft's security business and technology unit states that Windows is never vulnerable until a patch appears
He said no such thing. Not only does he say no such thing, but you (Michael) are clearly aware of it. To claim that the vulnerability doesn't exist until a patch appears would certainly be absurd, which is probably why no one made that claim.
The article is simply making an observation: That most vulnerabilities are not actually exploited until after a patch is released. This is an observation, not an assertion. It seems like a very reasonable one, too, since most evil crackers are not smart or patient enough to go though Windows binaries instruction-by-instruction looking for bugs. Instead, they just wait until a patch is released, and see what was patched. That way, they know where to look.
No one is claiming that a bug can't be exploited before the patch is released. They are simply pointing out that they usually aren't.
Michael, you can't just misquote people like that. It is obvious from looking at the comments here than most people did not read the article. Most people believe what you write, and don't realize that it is a gross exaggeration of what was acutally said. Even if it is Microsoft (and mind you I'm no fan of Microsoft), it's still not ok. Don't stoop to Microsoft's level; lying about your enemy is not the right way to win any battle.
It's posts like this that made me give up on Slashdot as a source of anything other than humor long ago (see the sig).
I think his point was that buffer overflows and similar memory management errors are a problem inherent in C. Almost every language other than C and C++ provides, at the very least, automatic bounds checking. Sure, it slows the code down a little bit, but for the added security it is well worth it.
Of course, half of the problem is just that memory management in C is so hard that people would rather use static buffers to avoid it all.
Not like a virus couldn't start logging your keypresses and sniff your root password the next time you have to install something.
The trusted executable paradigm has got to go. We need process-level, capability-based security. Unfortunately, no real OS has even tried to implement it, probably because it would go against 35 years of Unix infrastructure. (In my book, Windows is just a variant of Unix.)
Well, the string in "host->h_name" is obviously supposed to be a hostname (lookup gethostbyaddr()). The DNS standard does not limit hostnames to 20 characters (take "www.welovetheiraqiinformationminister.com", for example). His code did not check to make sure the host name was shorter than 20 characters (a fact that I figured was implied).
Granted, you can't put just any character you want in a hostname, so it would be hard to create an acutal exploit with this one, but you certainly could crash the server. And, besides that, he made lots of these sorts of errors. I just only remember that one specifically. He was one of those "maximum efficiency" zealots, see, so he always preferred static buffers over dynamic allocation.
As for Outlook, I honestly don't know how easy it is to open an executable attachment since I don't use it, but if it at least gives a warning box, it has done its job. It is the user's responsibility to heed warnings. Making the interface less convenient in order to deter ignorant users does not seem like a reasonable tradeoff to me.
*sigh* Yes, I am aware that only root can open low-level ports, but that hardly prevents anything a virus might want to do. Assuming the author wants to set up a spam relay for himself, there's no reason he can't just put it on a different port.
it still doesn't make my primary observation: they aren't computer virus, they're Windows virus, any less true.
That wasn't the point you were trying to make in your original post. Let's review what you actually said, shall we?
We really do need to work to spread the meme that its not a computer virus, its a Windows virus. Make more people aware of the fact that its a Windows problem, not a computer problem, and it does two things: firstly it might make them consider alternatives to Windows, and secondly if they know its a Windows specific problem they might try and pressure MS into making Windows more secure.
You said that these viruses were a "Windows specific problem". You seemed to be referring to viruses as a general concept, not to any specific examples. Indeed, the article you commented on was itself refering to viruses as a general concept.
This is simply not true. Both Unix and Windows operate on the assumption that a user completely trusts any program that he or she runs. Viruses are designed to exploit this fact either by tricking the user into running them or by tricking an already-running program into running them. In order to fix this problem, we need an OS which does not make this assumption.
I think you are vastly underestimating the user/root separation. At the very least it prevents a single user infection from affecting the entire machine.
Back in the days of timesharing mainframes, that might have been significant. In this century, though, 99% of computers that people use to, say, check e-mail, are desktop machines with only one user. On such machines, user/root separation only protects the operating system and installed programs, which is possibly the least useful thing to protect since you can always just reinstall them. Important data, like the user's documents, are completely unprotected from any program that the user runs. And, again, the vast majority of viruses these days hardly care about hard drive access. Unix and Windows both provide absolutely no access control for network communications, allowing viruses to perform all of their tasks with ease.
the Outlook/Outlook Express situation where simply recieving a viral mail would infect the system
First of all, it is my understanding that those vulnerabilities were fixed years ago. There are not currently any known exploits in Outlook which allow arbitrary code to be run on receipt or view of an e-mail. The user has to actually open an executable attachment to spread the virus. Last I checked, Unix e-mail clients allowed e-mails to have executable attachments, too
Secondly, vulnerabilities in Outlook are not vulnerabilities in Windows. I, for one, would not touch Outlook with a 10-foot pole, though I have no problem with using Windows on my desktop. Please do not confuse the two.
Thirdly, don't be so quick to assume that all Unix e-mail clients are intelligently written. All it takes is one buffer overrun to exploit a client. I once worked with a guy who claimed to have played a part in KMail's development. We were writing what was supposed to be secure instant messaging software. He actually wrote lines of code that looked like this:
I shit you not. Had I not reviewed his code, that would have been one gaping security hole in our "secure" server. What makes you think that the authors of your client are any better?
but to say that its "just as bad" is to buy into MS's own FUD.
If one version of Unix (say, Linux on x86) had 90% market share, then, yes, it would be "just as bad". I don't see how it could possibly not be, as Unix does not have any additional safeguards that would make a significant difference to viruses.
there has not been a significant number of Mac OS X virus (virus for older Mac OSes are more common by far).
Your post was modded "troll" because it was blatant FUD. Pro-unix FUD, perhaps, but FUD nonetheless. You assert that Unix is superior to Windows because most viruses only run on Windows. The simple fact of the matter is that most viruses run on Windows because Windows has nearly 100% market share of people who aren't computer saavy. A worm for Linux would never work because Linux users know better than to run untrusted executables, and Linux users usually patch OpenSSH right away when a remote root exploit is found. The number of Linux machines left open to attack is so small that a virus or worm simply would not be able to propogate. Meanwhile, there are hundreds of millions of Windows users just waiting to open any e-mail attachment you send them, and who haven't ever heard of Windows Update.
Unix is not inherently less vulnerable to viruses than Windows is. No, user/root separation does not hinder e-mail viruses designed to DDoS web sites. Yes, there is software running on your Unix box right now that has buffer overrun vulnerabilities.
Modern hard drives have a half-life of 50,000 start/stop cycles. Let's say you start and stop your hard drive 10 times a day (hopefully, in reality, you do it far less that that). Then, the half-life of your hard drive is 5000 days, or about 13 years. The chance that it will die on any particular day is:
1 - (0.5)^(1/5000) = 0.0001386
Let's say that, if one drive dies, you will be able to replace it within a week. The chance that the other hard drive will die in that same week is:
1 - (0.5)^(7/5000) = 0.0009699
So, you have about a 1 in 1000 chance that you will lose all your data. Not 1 in 1000 per week, mind you. 1 in 1000 per hard drive death, which is already extremely rare. Of course, just add another hard drive do that, and it becomes 1 in a million.
I think the chances are higher that the location where you are storing your negatives will burn down, or flood, or something else. Of course, with digital media, you can easily protect against such occurrances by keeping off-site backups. With film, you can't even create backups without quality loss.
And that's easier and cheaper than storing the original film negatives rolled up in a plastic can which are then stored in a dark, cool basement?
You could buy a pair of 20GB hard drives for less than $100. You could probably store at least 100,000 pictures on one and use the other one as a backup. The chance that both hard drives would die simultaneously would be about the same as the chance that something bad would happen to your negatives.
I wouldn't be surprised if in a few years CD/DVD drives refuse to access old CD/DVD-R discs.
Oh, what rubbish. No drive manufacturer would put such a limitation on their drives because no one would buy them. No congress would enact a law requiring such a thing because of the obvious damage it would do to the computing industry. Besides that, moving digital data to new mediums is easy and has virtually zero risk of quality loss.
Your post about snail-mail doesn't even make sense. Snail mail doesn't get accidentally lost at the press of a DEL-key.
No, it accidentally gets lost because a gust of wind blew it out the window, or you mistook it for trash and threw it out, or you spilled coffee all over it, or you filed it in the wrong place in your gigantic file cabinet that you use to store e-mails. You can't very well hit ctrl+f and run a search of your file cabinet, or tell it to sort itself by sender, date, or subject.
Also, you should get a better e-mail client. If one press of the "delete" key deletes e-mails without any sort of confirmation, then your software has some serious design issues.
Not only does digital data never degrade, but you can easily make all the backups you want. If you are really so worried about losing any of it, get a RAID-5, make tape backups, whatever. But with analog, not only is it a lot of work to make copies of 100,000 pictures, but the image quality of the copies will be less than that of the original. Hell, most analog mediums degrade even when they're just sitting in storage.
Bottom line is, keeping digital data safe is much easier than keeping analog data safe, especially when you have a lot of it.
Slashdot Mirror
Well no shit! We don't live in a perfect information world.
Assuming you can trivially find out anything about anybody, just add a filter to your inbox that rejects mail from anyone who is known for spamming. And thus, spam would not exist in the "free data utopia".
How is relying on a MIME type provided by the e-mail any better than relying on the extension provided by the e-mail? How will using MIME types allow the e-mail client to more easily distinguish what file types have executable content? (After all, some document formats could include embedded scripts.) How will using MIME types help if the executable is in a zip, like MyDoom was?
This glaring security hole is the result of the trusted-executable paradigm used by almost every OS in existence (including Windows and every variant of Unix). You do the math.
Yes, hijacking programs which have already been marked as "trusted" is still a problem. Unfortunately, it is a problem not just fundamental to the OS's we use, but to the actual programming languages we use. In C, any piece of code anywhere can perform any system call with the same priveledges as the rest of the process it is running in. To fix this, we need to move to programming languages that have capability-based security built-in. Sadly, none of the major languages used today seem to make any attempt at this, and it will take a very long time to popularize one that does. (I am actually working on such a programming language myself, but it's only in the early prototype phases.)
I think it's clear that Slashdot means to imply that Microsoft and/or Windows is somehow at fault. Why bother to point this fact out otherwise?
Every OS I know allows complete network access to non-admin users, which is all most of these viruses care about.
MyDoom is attached as a zip containing an executable. It does not appear as a jpg, doc, or other file type. It appears as a zip. What would you expect to happen when you click on a zip attachment? The e-mail program is probably not designed to explicitly recognize zips, so it sends it off to the OS's default handler for zip files. That handler happily allows the user to open the contents since it has no idea that the thing came from an untrusted source.
Being able to open a document attached to an e-mail with a single click is user-friendly, and is a feature I quite like having, even in my non-Microsoft e-mail client. It makes sense to prevent users from running actual executables with a single click (and every e-mail client I've seen does so), but it is not possible for the e-mail client to keep a complete list of dangerous vs. safe file types. Zips in particular are used legitimately in e-mails far more often than not, so why should you expect your e-mail client to stop you from opening one?
The real problem here is the trusted-executable paradigm on which all major operating systems are based. All variants of Unix (which, in my book, includes Windows) assume that you trust any executable you run. In other words, they assume that you know exactly what you are doing. Obviously, users don't always know what they are doing, and the OS should be there to watch and double-check with the user when anything suspicious happens. The OS should ask the user if they really want to allow this program to access the internet (spreading itself). It should ask if they really want to install that backdoor and let it run on startup. It should explain what each question means so that the user can make an informed decision.
If OS's did these things, not only would viruses no longer spread, but things like spyware and adware installed by programs like RealPlayer would no longer function. In fact, because it would be so obvious when a program contained spyware, companies would probably be less inclined to try to include it in the first place.
So why does no OS do this? Probably because it would take some work to implement. Who wants to be the first?
That's a great idea! In fact, I've been avocating exactly that for some time now. I note, however, that no operating system in existence currently does this, so to blame Microsoft specifically isn't exactly fair.
(Actually, you can use Zone Alarm on Windows to at least force programs to ask permission before using the network. I don't know if any equivalent program exists for any other OS.)
Did Microsoft create them? No.
Do they exploit any vulnerability that Microsoft is responsible for creating? No. (They spread by tricking users into running the attached executables.)
I know it's fun to pretend that everything bad is Microsoft's fault (and I'm no fan of Microsoft myself), but come on... how does it make any sense to prefix something with "Microsoft" when Microsoft had absolutely nothing to do with it? What's next? "Microsoft OpenSSL vulnerability discovered"? "Microsoft recording industry sues 12-year-old kid"? "Microsoft PATRIOT act renewed"? "Hacker charged with violating the Microsoft DMCA"?
Apparently in Texas the saying is: Fool me once, shame on... shame on you. ... ... You fool me, can't get fooled again.
I said "most", not "all". Obviously it's a matter of opinion.
Depends.
a function uses the parameters it is passed most of the time.
Sure, functions you are used to, written in normal, eager-evaluation languages, use all of their parameters most of the time. However, if you had lazy computation available, you might be more inclined to write code in completely different ways that take advantage of that functionality. Those ways might actually be a lot more efficient than you'd imagine. You probably haven't thought too hard about them since you haven't used any lazy computation languages.
Good compilers can do enough optimization to mostly negate the drawbacks of lazy computation. Yes, it will be less efficient if you simply rewrite eager-computation code in a lazy-computation language. But, perhaps there's some other way you could write that code to take advantage of lazy computation to make it faster?
Obviously, the answer to this question isn't simple, and I don't pretend to know for sure which method is "better".
If you only just learned it last year in class, no wonder you find it complicated. You probably have much more experience with imperative languages. Indeed, when you think about programming, your thoughts are probably imperative. Just as a native English speaker might think Japanese is complicated (even after "learning it in class last year"), a native imperative programmer will find functional programming difficult at first.
You know how they say, once you know one programming language, learning another is easy? Yes, once you know C++, picking up Java is a sinch, and you can probably even read someone's Python code without even learning the language first. But, this is because all of these languages are imperative. If someone tells you to write something in LISP, you may be able to figure out the syntax pretty easily, but no doubt you'll find yourself using imperative constructs like "progn". And, when you do that, the language seems very difficult to use indeed, because it was never supposed to be used that way. I made this mistake once myself.
Anyway, point is, it's not really fair for you to be judging functional languages until you've practiced them as much as the imperative ones. Personally, my imperative experience still dwarfs my functional experience by a factor of thousands... but I've now convinced myself that, for most purposes, functional languages are superior.
... a written explanation for the purchase of his decision to purchase a SCO License...
Ah hah! So it's true! SCO bribed him into doing it!
What? Just a typo? Oh... uh... right. I knew that.
The following two statements are VERY DIFFERENT:
We have never had vulnerabilities exploited before the patch was known - Actual quote. Maybe not completely true, but mostly true. "Never" should be replaced with "almost never". I consider that an honest mistake.
Windows is never vulnerable until a patch appears - Misquote by Michael. Absurd. Anyone who would make this claim is an idiot.
The head of Microsoft's security business and technology unit states that Windows is never vulnerable until a patch appears
He said no such thing. Not only does he say no such thing, but you (Michael) are clearly aware of it. To claim that the vulnerability doesn't exist until a patch appears would certainly be absurd, which is probably why no one made that claim.
The article is simply making an observation: That most vulnerabilities are not actually exploited until after a patch is released. This is an observation, not an assertion. It seems like a very reasonable one, too, since most evil crackers are not smart or patient enough to go though Windows binaries instruction-by-instruction looking for bugs. Instead, they just wait until a patch is released, and see what was patched. That way, they know where to look.
No one is claiming that a bug can't be exploited before the patch is released. They are simply pointing out that they usually aren't.
Michael, you can't just misquote people like that. It is obvious from looking at the comments here than most people did not read the article. Most people believe what you write, and don't realize that it is a gross exaggeration of what was acutally said. Even if it is Microsoft (and mind you I'm no fan of Microsoft), it's still not ok. Don't stoop to Microsoft's level; lying about your enemy is not the right way to win any battle.
It's posts like this that made me give up on Slashdot as a source of anything other than humor long ago (see the sig).
I think his point was that buffer overflows and similar memory management errors are a problem inherent in C. Almost every language other than C and C++ provides, at the very least, automatic bounds checking. Sure, it slows the code down a little bit, but for the added security it is well worth it.
Of course, half of the problem is just that memory management in C is so hard that people would rather use static buffers to avoid it all.
Not like a virus couldn't start logging your keypresses and sniff your root password the next time you have to install something.
The trusted executable paradigm has got to go. We need process-level, capability-based security. Unfortunately, no real OS has even tried to implement it, probably because it would go against 35 years of Unix infrastructure. (In my book, Windows is just a variant of Unix.)
Well, the string in "host->h_name" is obviously supposed to be a hostname (lookup gethostbyaddr()). The DNS standard does not limit hostnames to 20 characters (take "www.welovetheiraqiinformationminister.com", for example). His code did not check to make sure the host name was shorter than 20 characters (a fact that I figured was implied).
Granted, you can't put just any character you want in a hostname, so it would be hard to create an acutal exploit with this one, but you certainly could crash the server. And, besides that, he made lots of these sorts of errors. I just only remember that one specifically. He was one of those "maximum efficiency" zealots, see, so he always preferred static buffers over dynamic allocation.
As for Outlook, I honestly don't know how easy it is to open an executable attachment since I don't use it, but if it at least gives a warning box, it has done its job. It is the user's responsibility to heed warnings. Making the interface less convenient in order to deter ignorant users does not seem like a reasonable tradeoff to me.
*sigh* Yes, I am aware that only root can open low-level ports, but that hardly prevents anything a virus might want to do. Assuming the author wants to set up a spam relay for himself, there's no reason he can't just put it on a different port.
That wasn't the point you were trying to make in your original post. Let's review what you actually said, shall we?
We really do need to work to spread the meme that its not a computer virus, its a Windows virus. Make more people aware of the fact that its a Windows problem, not a computer problem, and it does two things: firstly it might make them consider alternatives to Windows, and secondly if they know its a Windows specific problem they might try and pressure MS into making Windows more secure.
You said that these viruses were a "Windows specific problem". You seemed to be referring to viruses as a general concept, not to any specific examples. Indeed, the article you commented on was itself refering to viruses as a general concept.
This is simply not true. Both Unix and Windows operate on the assumption that a user completely trusts any program that he or she runs. Viruses are designed to exploit this fact either by tricking the user into running them or by tricking an already-running program into running them. In order to fix this problem, we need an OS which does not make this assumption.
I think you are vastly underestimating the user/root separation. At the very least it prevents a single user infection from affecting the entire machine.
Back in the days of timesharing mainframes, that might have been significant. In this century, though, 99% of computers that people use to, say, check e-mail, are desktop machines with only one user. On such machines, user/root separation only protects the operating system and installed programs, which is possibly the least useful thing to protect since you can always just reinstall them. Important data, like the user's documents, are completely unprotected from any program that the user runs. And, again, the vast majority of viruses these days hardly care about hard drive access. Unix and Windows both provide absolutely no access control for network communications, allowing viruses to perform all of their tasks with ease.
the Outlook/Outlook Express situation where simply recieving a viral mail would infect the system
First of all, it is my understanding that those vulnerabilities were fixed years ago. There are not currently any known exploits in Outlook which allow arbitrary code to be run on receipt or view of an e-mail. The user has to actually open an executable attachment to spread the virus. Last I checked, Unix e-mail clients allowed e-mails to have executable attachments, too
Secondly, vulnerabilities in Outlook are not vulnerabilities in Windows. I, for one, would not touch Outlook with a 10-foot pole, though I have no problem with using Windows on my desktop. Please do not confuse the two.
Thirdly, don't be so quick to assume that all Unix e-mail clients are intelligently written. All it takes is one buffer overrun to exploit a client. I once worked with a guy who claimed to have played a part in KMail's development. We were writing what was supposed to be secure instant messaging software. He actually wrote lines of code that looked like this:
I shit you not. Had I not reviewed his code, that would have been one gaping security hole in our "secure" server. What makes you think that the authors of your client are any better?
but to say that its "just as bad" is to buy into MS's own FUD.
If one version of Unix (say, Linux on x86) had 90% market share, then, yes, it would be "just as bad". I don't see how it could possibly not be, as Unix does not have any additional safeguards that would make a significant difference to viruses.
there has not been a significant number of Mac OS X virus (virus for older Mac OSes are more common by far).
Considering that OS9 was te
Your post was modded "troll" because it was blatant FUD. Pro-unix FUD, perhaps, but FUD nonetheless. You assert that Unix is superior to Windows because most viruses only run on Windows. The simple fact of the matter is that most viruses run on Windows because Windows has nearly 100% market share of people who aren't computer saavy. A worm for Linux would never work because Linux users know better than to run untrusted executables, and Linux users usually patch OpenSSH right away when a remote root exploit is found. The number of Linux machines left open to attack is so small that a virus or worm simply would not be able to propogate. Meanwhile, there are hundreds of millions of Windows users just waiting to open any e-mail attachment you send them, and who haven't ever heard of Windows Update.
Unix is not inherently less vulnerable to viruses than Windows is. No, user/root separation does not hinder e-mail viruses designed to DDoS web sites. Yes, there is software running on your Unix box right now that has buffer overrun vulnerabilities.
Let's calculate this, shall we?
Modern hard drives have a half-life of 50,000 start/stop cycles. Let's say you start and stop your hard drive 10 times a day (hopefully, in reality, you do it far less that that). Then, the half-life of your hard drive is 5000 days, or about 13 years. The chance that it will die on any particular day is:
1 - (0.5)^(1/5000) = 0.0001386
Let's say that, if one drive dies, you will be able to replace it within a week. The chance that the other hard drive will die in that same week is:
1 - (0.5)^(7/5000) = 0.0009699
So, you have about a 1 in 1000 chance that you will lose all your data. Not 1 in 1000 per week, mind you. 1 in 1000 per hard drive death, which is already extremely rare. Of course, just add another hard drive do that, and it becomes 1 in a million.
I think the chances are higher that the location where you are storing your negatives will burn down, or flood, or something else. Of course, with digital media, you can easily protect against such occurrances by keeping off-site backups. With film, you can't even create backups without quality loss.
And that's easier and cheaper than storing the original film negatives rolled up in a plastic can which are then stored in a dark, cool basement?
You could buy a pair of 20GB hard drives for less than $100. You could probably store at least 100,000 pictures on one and use the other one as a backup. The chance that both hard drives would die simultaneously would be about the same as the chance that something bad would happen to your negatives.
Easier. Cheaper. Zero quality loss.
I wouldn't be surprised if in a few years CD/DVD drives refuse to access old CD/DVD-R discs.
Oh, what rubbish. No drive manufacturer would put such a limitation on their drives because no one would buy them. No congress would enact a law requiring such a thing because of the obvious damage it would do to the computing industry. Besides that, moving digital data to new mediums is easy and has virtually zero risk of quality loss.
Your post about snail-mail doesn't even make sense. Snail mail doesn't get accidentally lost at the press of a DEL-key.
No, it accidentally gets lost because a gust of wind blew it out the window, or you mistook it for trash and threw it out, or you spilled coffee all over it, or you filed it in the wrong place in your gigantic file cabinet that you use to store e-mails. You can't very well hit ctrl+f and run a search of your file cabinet, or tell it to sort itself by sender, date, or subject.
Also, you should get a better e-mail client. If one press of the "delete" key deletes e-mails without any sort of confirmation, then your software has some serious design issues.
Not only does digital data never degrade, but you can easily make all the backups you want. If you are really so worried about losing any of it, get a RAID-5, make tape backups, whatever. But with analog, not only is it a lot of work to make copies of 100,000 pictures, but the image quality of the copies will be less than that of the original. Hell, most analog mediums degrade even when they're just sitting in storage.
Bottom line is, keeping digital data safe is much easier than keeping analog data safe, especially when you have a lot of it.