The real division isn't atheist vs. religious. As you say, there are plenty of renowned and despised figures on both sides of that particular debate. The real division is authoritarian vs. free-thinker.
Organized religion is almost always authoritarian by nature, and tends to attract authoritarian followers, but the reverse is not always true. Plenty of atheists and agnostics tend toward authoritarianism just as much as their religious counterparts.
I imagine that each visitor generates more than one database hit. This/. article page is made up of over thirty files, for example, each of which would probably count as at least one hit. By my simplistic calculations each visitor would need to generate about 212 database hits to maintain an average of 500 hits/s, which, while high, is not entirely unreasonable.
Letting individual copyright holders opt-out makes the proposal useless. The entire point was that, for a small monthly tax, people wouldn't have to worry about copyrights so far as non-commercial, personal use was concerned. If it doesn't apply to all copyrighted content, though, the resulting situation wouldn't be much different than what we have now; people would still run the risk of a lawsuit every time they shared something. (You don't expect anyone to actually check the lists, right? Even assuming they're even published in an accessible fashion, if people are paying a monthly "file sharing" tax they're going to expect access to everything.)
The theoretical throughput might be 480 Mb/s, but I have yet to see any real-world benchmarks above about 300 Mb/s (37.5 MB/s), and if my own experience is any indication you'd be lucky to get even 20 MB/s on bulk transfers without high-end (read: expensive) hardware.
Actually, what there needs to be is a significant reduction in the scope of government -- particularly the upper, more distant levels -- such that people are rarely affected by decisions made without their consent.
The ideal form of this is not democracy, which purports to seek input from all but places no value whatsoever on sovereign individual rights. Instead it resembles the system known to some as Unanimous Consent, or voluntaryism, where each individual possesses full veto power insofar as their own person and property are concerned.
Sure, they can assume whatever they want -- but their unfounded assumptions shouldn't interfere with anyone else's ability to buy or sell; nor should it be deemed sufficient grounds to suspend anyone's eBay account.
If they think the product is fake they should have no trouble backing that claim up with evidence. Even then, it's the defrauded buyers that should be pressing claims, not the purported manufacturer.
Adding fsync()s before rename()s are committed to disk in the ext4 filesystem module, as I proposed, would fix the issue from the application's P.O.V. No workarounds would be required.
This isn't really about the applications. POSIX doesn't specify what happens in the event of a crash; ext2 was perfectly POSIX-compliant despite the fact that an unclean shutdown could lead to arbitrary data loss, even with fsync(). The entire point of creating ext3, and now ext4, was to improve (among other things) the behavior of the system with respect to system crashes and power outages. The nature of these improvements are specific to the filesystem, and not part of any spec.
Application developers did contribute to the problem, but they are not solely responsible. There is no API available to communicate the behavior they actually wanted -- not an immediate flush to disk, as in fsync(), but rather a delayed flush which preserves both the order of operations and performance. Given their two options of unacceptable performance and an extremely small chance of data loss -- which didn't occur at all on the most common filesystem -- I do not fault their choice. I would, in fact, go so far as to say that it was the right choice under the circumstances. The risk was small, and their goals did not include an absolute aversion to data loss. They did, however, include the desire to maximize performance during normal use.
There are two separate aspects to this issue. On the one hand, some application developers were not doing all they could according to the POSIX APIs to avoid data loss in a portable manner. Whether they should have been doing so is for the application developers to decide in combination with the application's users. There are trade-offs to be made either way. On the other hand, the filesystem developers introduced a change which increased the probability of data loss with respect to the previous version of the filesystem. Ext4 is intended to be an improvement over ext3, and regressions such as this -- even if the system remains POSIX-compliant, even if the applications in question were not written portably -- detract from that goal.
I mean I could write a spec for a file system that says "No write is guaranteed to be written to disk until the OS is shut down, everything can be cached in RAM for an indefinite amount of time." However that'd be real flaky and lead to data loss. That makes my FS useless.
Not quite useless; every modern Linux system makes use of a filesystem designed to work in exactly that way. It's known as tmpfs.
More seriously, this is more about users' expectations for their filesystem than it is about application's expections regarding kernel APIs. There's no reason that any application should expect data to reach the disk without an fsync(), so from that point-of-view ext4 is compliant with all the relevant APIs. However, given that this is a common use-case and that users expect modern filesystems to magically "do the right thing" and avoid data loss, it makes sense to patch this particular issue by implicitly inserting fsync()s just before rename()s over existing non-empty files are committed to disk. That would eliminate the data loss without seriously impacting performance.
To me, the mathematical nature of the universe makes perfect sense based purely on the concept of increasing entropy. Given the tendency of entropy to increase over time, the amount of unique information needed to describe any given aspect of the universe tends toward a minimum. Physical laws which correlate to simple mathematical formulas represent less information than non-mathematical (i.e. arbitrarily complex) relationships.
It would be nice to have at least ONE politician I could vote for who would tell these legalized extortionists where to shove it.
Let me get this straight: You want to address an appeal against legalized extortion to politicians -- the most blatant practitioners of legalized extortion around? Seriously?
IANAL either, but a contract shouldn't be thrown out as "under duress" unless the duress in question was initiated by the other party. The GP's situation was not the doctor's fault, and the doctor has every right to place binding conditions on any services rendered.
Whether a doctor should place such conditions on medical aid--considering the Hippocratic Oath and all that--is another matter entirely.
Alternatively you could write a program that goes through your code to look for situations where variables that may be uninitialised are used (I believe Java does this) and whines about it.
Most C compilers will do that as well, including GCC, provided you enable the appropriate warnings (either -Wall or -W; I forget which).
Regardless of how Amazon may or may not be advertising these e-books, and regardless of how well or poorly these TTS systems substitute for human readers, the simple fact is that what Amazon is distributing is text, not audio recordings (phonorecords); e-books, not audio books. They are not the ones abusing copyright here.
If authors and/or publishers wish to raise their royalty rates (for new licenses) to compensate for the impact of TTS on audio book sales, that is their legal right. Copyright only grants them the privilege to control how their works are distributed or publicly performed, not how they are used or advertised. It certainly isn't designed to shield them from technological obsolescence, or to maximize their profits.
I did comment on what you said; did you somehow miss the direct quote?
As for the rest, it simply wasn't worth commenting on; I should hope that no one else would be taken in by such a flimsy argument. If you really want a response, however, then know this: taxes are not voluntary. Claiming that you agree to them simply by not moving proves too much; one could say the same about any other kind of criminal enterprise. E.g., that protection money really is voluntary, since you can always move out of the racket's territory. E.g., you were acting voluntarily when you gave that money to the armed robber; you could've tried to finangle your way out of the situation (and risked getting shot). Obviously each of these examples is, in fact, under duress and thus involuntary; taxes are exactly the same. The ever-present threat of force negates any possibility of voluntary agreement.
Simply put, if taxes were voluntary you could choose not to pay them without risking any loss of personal freedom or property. That is not the case, ergo they are not voluntary. QED.
If it was your money, it would be in your pocket and yours to spend, wouldn't it?
So... your money stops being yours as soon as its out of your immediate possession? Government and taxes aside, if a common thief takes your money, you no longer consider it yours, or care if you get it back? Perhaps you should re-think that argument.
All three of the services you mention have been provided through private enterprise in the past, and successfully for the most part (particularly fire and police services). In any event, none of these basic services are provided by the federal government; nor do they represent any significant portion of total government spending. We can worry about just how little government is actually required after we've discarded the vast majority which clearly isn't (basically everything above the municipal level, less a minimum of public defense).
[M]aybe you think it is wrong to not pay an artist but not wrong to not pay the government?
You find that surprising? Personally I don't find either action immoral -- unless one already agreed to the payment voluntarily -- but I do find it trivial to understand why someone would choose to fund an artist they liked out of gratitude and yet have no objection to fending off attempts to steal their property.
"Tax fraud" -- deception practiced under duress, to counter aggression, and outside the bounds of a contract -- is much less obviously immoral than even the mere freeloading you present as an alternative (which isn't particularly immoral to begin with).
Of course it would be crazy to require proof of mental competence for every action, or to rely on some sort of self-declaration. However, it wouldn't be impractical to make proof of mental incompetence the deciding factor. The standards would be exactly the same as those currently used to determine insanity; every individual, regardless of age, is presumed competent to enter into binding legal agreements unless they (or a legal guardian) can persuade a court otherwise. (Others could still choose not to enter into agreements where mental competence is in question, thus avoiding the risk of nullification.)
Essentially, under this plan extreme youth becomes a recognized form of temporary insanity -- and we already have procedures in place to deal with that.
If criminals (or at the very least, immoral hackers) are backing TPB, then why is it a stretch to say that TPB has been assisting in some form of not-perfectly-legal activity?
Lots of people support TPB, for a variety of reasons. I'd be more surprised to find that "immoral hackers" were underrepresented vs. a random sample of the Internet-using population.
You can't judge an individual, organization, or movement by its most disreputable supporters. If only "immoral hackers" supported TPB that would be a different story, but such is not the case.
So if I were to lure you someplace with the promise of a million dollars, you no longer possess free will?
The presence of bait does not prevent one's choices from remaining free. If the cat is considered a free agent, the only context in which "free will" has meaning, then its actions remain free regardless of any lure involved. In order for the action to be non-free the cat would have to be coerced: deliberately threatened with the violation of its rights of self-ownership by another free agent.
Of course, the laws in most jurisdictions don't recognize cats as free agents, so (in a legal context) it makes no sense to speak of a cat acting "of its own free will". Essentially, you can't blame the cat; rather, you'd have to show that selecting "I agree" was not the consequence of your own deliberate actions. (Though INAL, this is not legal advice, etc., etc.)
A much better solution to the EULA problem would be a general update to the copyright laws clarifying that only distribution and public performance count as infringement. In other words, that no additional license is required to copy software from the installation media to your own PC, or to make undistributed derivative works. At that point there would be no need to agree to the EULA, although you might have to patch the installer to skip the prompt.
Even better would be for the courts to recognize that copyright only properly applies to source code. If you strip out any embedded resources -- images, non-trivial text, etc. -- the compiled binaries are purely facts, formal mathematical descriptions of algorithms, and facts don't qualify for copyright privileges.
Best of all, of course, would be the elimination of copyright altogether, but one of the above would at least be a good start.
The entire article is exactly about running random scripts received through email attachments.
Mere scripts can't disguise themselves, or trick the DE into doing so for them.
... the user has to take several unusual steps to voluntarily open himself up to this "problem".
These "several steps" consist solely of saving an attachment to the desktop without checking the name. That's hardly an ideal example of "user stupidity".
... there is no technological solution to it.
Really? How about requiring the execute bit? That would trivially solve this class of attack, regardless of whether you consider it a case of "user stupidity" or a bug in the DE.
The simple fact is that the execute bit exists to prevent exactly this situation, and the current implementation of.desktop files opens a gaping hole in that first line of defense. The user should be able to trust their DE, and other applications, to not silently run arbitrary code from any file not marked as a program. It's a vulnerability everywhere else it happens, and it's a vulnerability here as well. Requiring shortcuts to have the execute bit set would eliminate the vulnerability without impacting usability in any way, so why not make that the standard behavior?
There needs to be some sort of guarentee that the icon chosen to represent a file actually represents the file.... But it should be obvious to everyone except for this site that if the icon shows that it's a picture file or a spreadsheet or whatever else, that that is what the interface should be.
How do you expect to enforce that, while still allowing applications to supply meaningful, identifiable icons for themselves? Need I remind you that the A.I. problem remains unsolved? Requiring the OS to visually identify each icon and infer its meaning is not a practical solution.
Or do you suggest that all applications should be labeled with the same useless "executable file" icon? That is more doable, but it would represent a major step backward in usability.
All that's really needed is to treat.desktop files as a form of program; they would then require execute privileges not conferred simply by saving an attachment or Internet file to disk. Problem solved.
Insightful? Really? Please, just read the article. This isn't about running random scripts received through e-mail attachments -- although even in that case the DE would be at fault if it didn't check the execute bit first. This is about non-executable files which disguise their icon and label and, when opened in the context of a DE, are capable of launching arbitrary code.
Once the file is saved it looks like whatever the creator wanted it to look like, be that an image, a text document, etc. The user doesn't think they're running an application they just received through e-mail. They reasonably think, based on the icon and label shown to them by the DE, that they're opening an inert document.
P.S. I haven't seen any evidence that.desktop files can't be opened directly from an e-mail client. Presumably the client passes the attachment to the DE for processing, in which case the DE probably runs the indicated command just as if the shortcut had been saved and opened explicitly.
However it is not clear how to ever fix this if any kind of installer exists that can turn on the -x bit.
Why is that? If a.desktop file is to be created by an installer, you'd want it to set the execute bit. This is for protection against files created by programs which aren't intended to install software, such as e-mail clients, web browsers, and archive extractors. Such programs should never set the execute bit by default.
Slashdot Mirror
The real division isn't atheist vs. religious. As you say, there are plenty of renowned and despised figures on both sides of that particular debate. The real division is authoritarian vs. free-thinker.
Organized religion is almost always authoritarian by nature, and tends to attract authoritarian followers, but the reverse is not always true. Plenty of atheists and agnostics tend toward authoritarianism just as much as their religious counterparts.
I imagine that each visitor generates more than one database hit. This /. article page is made up of over thirty files, for example, each of which would probably count as at least one hit. By my simplistic calculations each visitor would need to generate about 212 database hits to maintain an average of 500 hits/s, which, while high, is not entirely unreasonable.
Letting individual copyright holders opt-out makes the proposal useless. The entire point was that, for a small monthly tax, people wouldn't have to worry about copyrights so far as non-commercial, personal use was concerned. If it doesn't apply to all copyrighted content, though, the resulting situation wouldn't be much different than what we have now; people would still run the risk of a lawsuit every time they shared something. (You don't expect anyone to actually check the lists, right? Even assuming they're even published in an accessible fashion, if people are paying a monthly "file sharing" tax they're going to expect access to everything.)
The theoretical throughput might be 480 Mb/s, but I have yet to see any real-world benchmarks above about 300 Mb/s (37.5 MB/s), and if my own experience is any indication you'd be lucky to get even 20 MB/s on bulk transfers without high-end (read: expensive) hardware.
Actually, what there needs to be is a significant reduction in the scope of government -- particularly the upper, more distant levels -- such that people are rarely affected by decisions made without their consent.
The ideal form of this is not democracy, which purports to seek input from all but places no value whatsoever on sovereign individual rights. Instead it resembles the system known to some as Unanimous Consent, or voluntaryism, where each individual possesses full veto power insofar as their own person and property are concerned.
Sure, they can assume whatever they want -- but their unfounded assumptions shouldn't interfere with anyone else's ability to buy or sell; nor should it be deemed sufficient grounds to suspend anyone's eBay account.
If they think the product is fake they should have no trouble backing that claim up with evidence. Even then, it's the defrauded buyers that should be pressing claims, not the purported manufacturer.
What are you rambling on about?
Adding fsync()s before rename()s are committed to disk in the ext4 filesystem module, as I proposed, would fix the issue from the application's P.O.V. No workarounds would be required.
This isn't really about the applications. POSIX doesn't specify what happens in the event of a crash; ext2 was perfectly POSIX-compliant despite the fact that an unclean shutdown could lead to arbitrary data loss, even with fsync(). The entire point of creating ext3, and now ext4, was to improve (among other things) the behavior of the system with respect to system crashes and power outages. The nature of these improvements are specific to the filesystem, and not part of any spec.
Application developers did contribute to the problem, but they are not solely responsible. There is no API available to communicate the behavior they actually wanted -- not an immediate flush to disk, as in fsync(), but rather a delayed flush which preserves both the order of operations and performance. Given their two options of unacceptable performance and an extremely small chance of data loss -- which didn't occur at all on the most common filesystem -- I do not fault their choice. I would, in fact, go so far as to say that it was the right choice under the circumstances. The risk was small, and their goals did not include an absolute aversion to data loss. They did, however, include the desire to maximize performance during normal use.
There are two separate aspects to this issue. On the one hand, some application developers were not doing all they could according to the POSIX APIs to avoid data loss in a portable manner. Whether they should have been doing so is for the application developers to decide in combination with the application's users. There are trade-offs to be made either way. On the other hand, the filesystem developers introduced a change which increased the probability of data loss with respect to the previous version of the filesystem. Ext4 is intended to be an improvement over ext3, and regressions such as this -- even if the system remains POSIX-compliant, even if the applications in question were not written portably -- detract from that goal.
I mean I could write a spec for a file system that says "No write is guaranteed to be written to disk until the OS is shut down, everything can be cached in RAM for an indefinite amount of time." However that'd be real flaky and lead to data loss. That makes my FS useless.
Not quite useless; every modern Linux system makes use of a filesystem designed to work in exactly that way. It's known as tmpfs.
More seriously, this is more about users' expectations for their filesystem than it is about application's expections regarding kernel APIs. There's no reason that any application should expect data to reach the disk without an fsync(), so from that point-of-view ext4 is compliant with all the relevant APIs. However, given that this is a common use-case and that users expect modern filesystems to magically "do the right thing" and avoid data loss, it makes sense to patch this particular issue by implicitly inserting fsync()s just before rename()s over existing non-empty files are committed to disk. That would eliminate the data loss without seriously impacting performance.
To me, the mathematical nature of the universe makes perfect sense based purely on the concept of increasing entropy. Given the tendency of entropy to increase over time, the amount of unique information needed to describe any given aspect of the universe tends toward a minimum. Physical laws which correlate to simple mathematical formulas represent less information than non-mathematical (i.e. arbitrarily complex) relationships.
It would be nice to have at least ONE politician I could vote for who would tell these legalized extortionists where to shove it.
Let me get this straight: You want to address an appeal against legalized extortion to politicians -- the most blatant practitioners of legalized extortion around? Seriously?
IANAL either, but a contract shouldn't be thrown out as "under duress" unless the duress in question was initiated by the other party. The GP's situation was not the doctor's fault, and the doctor has every right to place binding conditions on any services rendered.
Whether a doctor should place such conditions on medical aid--considering the Hippocratic Oath and all that--is another matter entirely.
Alternatively you could write a program that goes through your code to look for situations where variables that may be uninitialised are used (I believe Java does this) and whines about it.
Most C compilers will do that as well, including GCC, provided you enable the appropriate warnings (either -Wall or -W; I forget which).
Regardless of how Amazon may or may not be advertising these e-books, and regardless of how well or poorly these TTS systems substitute for human readers, the simple fact is that what Amazon is distributing is text, not audio recordings (phonorecords); e-books, not audio books. They are not the ones abusing copyright here.
If authors and/or publishers wish to raise their royalty rates (for new licenses) to compensate for the impact of TTS on audio book sales, that is their legal right. Copyright only grants them the privilege to control how their works are distributed or publicly performed, not how they are used or advertised. It certainly isn't designed to shield them from technological obsolescence, or to maximize their profits.
I did comment on what you said; did you somehow miss the direct quote?
As for the rest, it simply wasn't worth commenting on; I should hope that no one else would be taken in by such a flimsy argument. If you really want a response, however, then know this: taxes are not voluntary. Claiming that you agree to them simply by not moving proves too much; one could say the same about any other kind of criminal enterprise. E.g., that protection money really is voluntary, since you can always move out of the racket's territory. E.g., you were acting voluntarily when you gave that money to the armed robber; you could've tried to finangle your way out of the situation (and risked getting shot). Obviously each of these examples is, in fact, under duress and thus involuntary; taxes are exactly the same. The ever-present threat of force negates any possibility of voluntary agreement.
Simply put, if taxes were voluntary you could choose not to pay them without risking any loss of personal freedom or property. That is not the case, ergo they are not voluntary. QED.
If it was your money, it would be in your pocket and yours to spend, wouldn't it?
So... your money stops being yours as soon as its out of your immediate possession? Government and taxes aside, if a common thief takes your money, you no longer consider it yours, or care if you get it back? Perhaps you should re-think that argument.
All three of the services you mention have been provided through private enterprise in the past, and successfully for the most part (particularly fire and police services). In any event, none of these basic services are provided by the federal government; nor do they represent any significant portion of total government spending. We can worry about just how little government is actually required after we've discarded the vast majority which clearly isn't (basically everything above the municipal level, less a minimum of public defense).
[M]aybe you think it is wrong to not pay an artist but not wrong to not pay the government?
You find that surprising? Personally I don't find either action immoral -- unless one already agreed to the payment voluntarily -- but I do find it trivial to understand why someone would choose to fund an artist they liked out of gratitude and yet have no objection to fending off attempts to steal their property.
"Tax fraud" -- deception practiced under duress, to counter aggression, and outside the bounds of a contract -- is much less obviously immoral than even the mere freeloading you present as an alternative (which isn't particularly immoral to begin with).
Of course it would be crazy to require proof of mental competence for every action, or to rely on some sort of self-declaration. However, it wouldn't be impractical to make proof of mental incompetence the deciding factor. The standards would be exactly the same as those currently used to determine insanity; every individual, regardless of age, is presumed competent to enter into binding legal agreements unless they (or a legal guardian) can persuade a court otherwise. (Others could still choose not to enter into agreements where mental competence is in question, thus avoiding the risk of nullification.)
Essentially, under this plan extreme youth becomes a recognized form of temporary insanity -- and we already have procedures in place to deal with that.
If criminals (or at the very least, immoral hackers) are backing TPB, then why is it a stretch to say that TPB has been assisting in some form of not-perfectly-legal activity?
Lots of people support TPB, for a variety of reasons. I'd be more surprised to find that "immoral hackers" were underrepresented vs. a random sample of the Internet-using population.
You can't judge an individual, organization, or movement by its most disreputable supporters. If only "immoral hackers" supported TPB that would be a different story, but such is not the case.
So if I were to lure you someplace with the promise of a million dollars, you no longer possess free will?
The presence of bait does not prevent one's choices from remaining free. If the cat is considered a free agent, the only context in which "free will" has meaning, then its actions remain free regardless of any lure involved. In order for the action to be non-free the cat would have to be coerced: deliberately threatened with the violation of its rights of self-ownership by another free agent.
Of course, the laws in most jurisdictions don't recognize cats as free agents, so (in a legal context) it makes no sense to speak of a cat acting "of its own free will". Essentially, you can't blame the cat; rather, you'd have to show that selecting "I agree" was not the consequence of your own deliberate actions. (Though INAL, this is not legal advice, etc., etc.)
A much better solution to the EULA problem would be a general update to the copyright laws clarifying that only distribution and public performance count as infringement. In other words, that no additional license is required to copy software from the installation media to your own PC, or to make undistributed derivative works. At that point there would be no need to agree to the EULA, although you might have to patch the installer to skip the prompt.
Even better would be for the courts to recognize that copyright only properly applies to source code. If you strip out any embedded resources -- images, non-trivial text, etc. -- the compiled binaries are purely facts, formal mathematical descriptions of algorithms, and facts don't qualify for copyright privileges.
Best of all, of course, would be the elimination of copyright altogether, but one of the above would at least be a good start.
The entire article is exactly about running random scripts received through email attachments.
Mere scripts can't disguise themselves, or trick the DE into doing so for them.
... the user has to take several unusual steps to voluntarily open himself up to this "problem".
These "several steps" consist solely of saving an attachment to the desktop without checking the name. That's hardly an ideal example of "user stupidity".
... there is no technological solution to it.
Really? How about requiring the execute bit? That would trivially solve this class of attack, regardless of whether you consider it a case of "user stupidity" or a bug in the DE.
The simple fact is that the execute bit exists to prevent exactly this situation, and the current implementation of .desktop files opens a gaping hole in that first line of defense. The user should be able to trust their DE, and other applications, to not silently run arbitrary code from any file not marked as a program. It's a vulnerability everywhere else it happens, and it's a vulnerability here as well. Requiring shortcuts to have the execute bit set would eliminate the vulnerability without impacting usability in any way, so why not make that the standard behavior?
There needs to be some sort of guarentee that the icon chosen to represent a file actually represents the file. ... But it should be obvious to everyone except for this site that if the icon shows that it's a picture file or a spreadsheet or whatever else, that that is what the interface should be.
How do you expect to enforce that, while still allowing applications to supply meaningful, identifiable icons for themselves? Need I remind you that the A.I. problem remains unsolved? Requiring the OS to visually identify each icon and infer its meaning is not a practical solution.
Or do you suggest that all applications should be labeled with the same useless "executable file" icon? That is more doable, but it would represent a major step backward in usability.
All that's really needed is to treat .desktop files as a form of program; they would then require execute privileges not conferred simply by saving an attachment or Internet file to disk. Problem solved.
Insightful? Really? Please, just read the article. This isn't about running random scripts received through e-mail attachments -- although even in that case the DE would be at fault if it didn't check the execute bit first. This is about non-executable files which disguise their icon and label and, when opened in the context of a DE, are capable of launching arbitrary code.
Once the file is saved it looks like whatever the creator wanted it to look like, be that an image, a text document, etc. The user doesn't think they're running an application they just received through e-mail. They reasonably think, based on the icon and label shown to them by the DE, that they're opening an inert document.
P.S. I haven't seen any evidence that .desktop files can't be opened directly from an e-mail client. Presumably the client passes the attachment to the DE for processing, in which case the DE probably runs the indicated command just as if the shortcut had been saved and opened explicitly.
However it is not clear how to ever fix this if any kind of installer exists that can turn on the -x bit.
Why is that? If a .desktop file is to be created by an installer, you'd want it to set the execute bit. This is for protection against files created by programs which aren't intended to install software, such as e-mail clients, web browsers, and archive extractors. Such programs should never set the execute bit by default.