Well, if you don't want to remap the key in software, glue a small block of wood to the top of the Esc key. Then lay a strip of tongue depressor so the key extends past the left edge of the keyboard. You can also overhang the right edge of F1 a bit if you want.
Seriously, part of being a geek is realizing that you don't have to accept the world around you *as is*... at least not when it comes to *made things*.
Yes, Google would not be doing this if it weren't for Congress.
But Google is not *required* to use this *particular* mechanism to preemptively quash potential copyright violations. That was its choice.
The question is whether Google's actions are a reasonable response to current statutory law, as opposed to being an overreaction. If a reasonable person would find it advisable to quash fair use of IP in a policy debate, right there you have a demonstrable chilling effect.
If this event just reflects a bug in Google's requirements analysis, you can't lay *fault* to DMCA or Congress. Congress is implicated in the event, sure, but you can't blame them for unreasonable responses to laws, even if those laws are otherwise unreasonable.
You can argue that if a law or regulation prompts widespread unreasonable responses, that the law needs improvement, possibly extensions and clarifications of whatever safe harbor provisions it has.
I'll paraphrase what you said in your first paragraph: "Regardless of what a person chooses to call himslef, if you look closely enough at his political philosophy, most of the time you'll find it's incoherent."
Actually, he'd have to have an application that required measuring the state of the platters independently of the drive heads to literally need to control the "physical location" of the bits. Otherwise he's already dealing with an abstraction of the physical layout of the disk. Given that, he might as well build the abstraction he wants on top of the raw disk interface provided by the OS.
In international law, "legal" is what countries can customarily get away with. It follows that one does not expect international law to be fair. It's just the continuance of war by other means. Less destructive means.
if you describe your requirements so abstractly? It sounds to me like you've come up with a solution ("Let's write the bits directly to the hard disk") and now you want pointers on how to make it work without explaining why.
If you just want to get around the file system, then use raw block I/O to the device. However it *sounds* to me like for some reason you've decided the *actual physical* layout of bits on the drive is important, in which case you are going to have to write your own disk driver -- if the drive electronics themselves don't defeat your attempt to know where bit is physically written.
It's inconceivable to me that you'd actually need to know this. Since you only *read* the data through an interface, it should make no difference if you *write* though the same interface, as long as it's consistent. In other words, unless you are going to disassemble the drive and examine it with an atomic force microscope, you have no way of telling the difference between a physical layout and an equivalent *model* of a "physical layout".
If you can't say *why* you need to do this, at least explain the parameters (how much storage, how fast, what kind of retreival etc.). My first reaction was that you should not use a magnetic disk at all, but an MTD flash device. Even so, you're dealing with an abstraction. You have no idea whether the device itself has mapped a bad bit to a different location at the hardware level. However short of tearing the device apart and putting the flash chips in a special circuit, you'd have no way of telling.
I disagree. What we need to do is compartmentalize.
Why do you have to use the same system to browse the corporate intranet over VPN and handle personal web browsing? Each of these activities should take place on a different virtual machine on a different virtual network. Then you watch the virtual/host interfaces like a hawk.
This is not an airtight strategy -- there is no such thing. What it does is buys time and spreads the footprint of the attack.
It's not entirely convenient. But you can focus your security attention on mechanisms you use to move data between different security universes. Companies seriously interested in security also really need a solid cryptographic infrastructure, including two factor security with a hardware component, and revocable trust. That's not convenient either.
If you *know* that ignoring an error will cause database corruption then you have a very serious bug in your program that needs to be fixed before a user even has a chance to touch it.
This is where the "prevent errors from happening in the first place" school is entirely correct. There should be no condition under the control of your software where a real database (as opposed to a file store you manipulate with SQL) can be corrupted by user action or inaction. Atomic operations should be wrapped in transactions; beyond that it is the DB vendor's responsibility to give practically bullet-proof data integrity.
That said, database platforms can flag thousands, sometimes tens of thousands of error conditions. These are things that happen completely out of your control (e.g. a tablespace that fills up; a license restriction that is exceeded).
Probably the most serious problem this poses is when user transactions are not posted. This might not be noticed by the user, and can create operational problems for them later as severe as literal "corruption". If you can't figure out why a transaction was not accepted, if its not one of the various foreseeable integrity exceptions, you almost have no choice but to throw up the database error message with a request it be reported to tech support.
I once worked with a RDBMS and users complained *my* software was losing data. "Impossible" was my reaction. Except that when I looked into it I discovered that the database server was configured to treat abnormally terminated connections as if they were wrapped in an implicit transaction. If the network connection got dropped or the client program crashed, user data simply disappeared, even though the database platform was told to commit. That's just *wrong* behavior, but hardly the most egregious thing I've seen.
That means that if I can't properly shut down a database connection for some reason, I *have* to tell the user to check that all his data was saved, and I *have* to tell him that if its missing he ought to contact me for help configuring the server. I can argue that it's not my problem, it's the database vendor or DBA's fault, but it won't matter. The users will blame *me* if I don't tell them what to do.
If you really have time for writing the "more information", you'd better write a function that checks what permissions are missing and what locks are held.
That's one of my points. Thinking it through the guidance you ought to offer the user leads you to the the things you ought to check yourself. It's very easy to say "file operation failed" and leave it at that.
Have you ever written messages like that in a real application?
Yes. Maybe not quite like that one, but I try to provide these kinds of things to users in every error message I write:
(1) An identifier that tech support can correlate to code. (2) A clear description of what happened. (3) An explanation of consequences of the next action the user might take.
And yes, my error messages sometimes look silly, because they aren't what people are used to.
I like your shorter error message, but I think it misses an important element: what is the consequence of canceling? In *this* case it's relatively benign. If it happens on user data, it is not necessarily so. The problem is that saying it's a "failed file operation" is a programmer centric error message. What matters to a user is this: "What am I going to lose if I choose 'Cancel'?" Conceptualizing this error as a "file permission problem" means lumping in losing configuration data (feh -- who cares?) and losing work that might be saved by copy and paste.
I understand there's a problem with writing too much into an error message, although I don't agree that the problem is with the user. The problem is with the programmer.
An error message is something like a comment in code that the user gets to see. We all agree that good comments are a big help, but sometimes really verbose comments can obscure the code itself, or even get out of sync with it. So the biggest downside of trying to be informative is to end up *misinforming* the user. That's the point where you have to curb yourself, not having other programmers laugh at you.
Because we've reached the point where programming per se is not the limiting factor in programmer.
Oh, some languages are nicer to program in than others. I'll take Python over Java, for example, if the criterion is just how fun and easy it is to write programs. But I'll often choose Java in many instances because it has libraries and frameworks that make my job easier.
And there's the rub. It's dealing with frameworks and APIs and libraries that kills you. The Java ecosystem is like a huge, booby-trapped treasure chest.
When I started programming professionally back in the 1980s it was a lot more fun, because there wasn't much in the way of libraries. Programming was mostly thinking about problems. Now it's mostly thinking about APIs.
Programmers have an ethical duty to safeguard users' work. Where we can't, we must give useful guidance (not just in verbiage, but in UI design altogether). If we do our best and users ignore that, it's not our fault.
I've in fact written error messages this way for years. I've found it extremely helpful. About 80% of users ignore the text at first, but that's a hell of a lot better than leaving 100% of the users up the creek.
The problem is that users are not accustomed to error messages that try to help them. Over time users begin to realize that there's useful information, and many tech support problems are reduced in severity. Eventually the program itself gets better, because of the thought that has to be put into common error conditions and the feedback from support.
If you are going to fail, fail in a big, obvious and *transparent* way.
On what basis do you claim the #1 problem is that errors are too wordy?
Naturally all things being equal, an less wordy error message that is equally informative is preferable to a more wordy one. But a succinct and cryptic error message is less preferable than a long but highly informative one in my opinion.
If the user is overrun with verbiage, it's because your program is too error prone.
Your first responsibility toward the user is to minimize the possibility something drastically bad will happen to his data. If you can't handle an error message, you *must* delegate that to the user and give him enough information he can take steps to secure his work. That includes calling tech support.
Hiding your failure to protect the user's work with the rationalization that some users are too ignorant to take effective action is not ethical system design. When you fail, you *must* tell the user even if it makes him scared or angry. That prospect should motivate you to do a better job.
In my experience, *some* users do read informative error messages. They tend to be important ones. Most have to be trained, but they come around once the realize that this is useful.
There are always some users who could manage to drown themselves in a teacup. Helping the intelligent users is (as I'll show in a minute) a first step toward helping the hopeless ones.
I don't like the "eliminate as many error messages as possible" strategy. Not that that's not a worthwhile thing *if you can isolate the user from the impact*. The problem I see is that programmers will just sweep errors under the carpet. I can't tell you how many times I've seen serious error conditions caught and shoved away in an obscure error log somewhere. If you are going to fail, fail in a big an obvious way. I've also seen bug tracking systems where they highest severity bug is a "crash bug". Many crash bugs are in fact benign. I've had to retrain practically every single programmer who's worked to me to drill this into their heads: the most severe class of bug is a *data corruption* bug. The very worst bugs of this class give innocuous looking but wrong results. After that come the bugs that cause work to be lost.
Every single error condition must be handled, or delegated to the user. Handling without user intervention is best, but ignoring error message to reduce the number of errors seen by users is bad, bad, bad design. The elimination of error messages should be a *result* not an *end*.
Part of the point of disciplining yourself to write informative error messages is that it forces you to *think* about the underlying problem. Excessive error messages are the result of not thinking a situation through. My point is that every message put before the user should *inform his response*. Setting that criterion forces the programmer to do the thing he doesn't do when he throws up an extraneous message: work through what ought to be done about it.
It's not either or. I'm all for everything you suggest. But I'm also for writing clear error messages that reward the users who take the effort to read them. What I'm certainly not for is adding bells and whistles to *bad* error messages to try to grab user attention, as suggested by the asker.
A: How do you write error messages that are worth reading?
Commentary: Users do not read error messages because they are mystified by them. To mystify them willfully only increases their resistance.
The first job is to create error messages that actually help the user. Users are conditioned by the generally crappy state of error messages to ignore them. If you provide helpful error messages then the users that *can* be helped can be trained to read them. It's operant conditioning -- like giving a rat a food pellet for successfully navigating a maze.
The very first thing you should do with error messages is pull them all together into some kind of document. This document should have (1) an unambiguous ID for the error; (2) a description of *what* happened ; (2) a description or at least a guess for *why* it happened; (3a) the impact of the error on the user (3b) how the user can recover from the error; (3c) what the programmer can do to avoid this; (4) what the user needs to do in the future.
Note that 3b also implies that *you* should consider how the program is apt to behave after the error message is displayed so you can offer the user sensible choices. For example, if the program fails to write the application preferences file on exiting, it makes sense to give the user both retry and cancel options, rather than sending him into a pointless loop that requires him to shoot the process down.
Then you write an error message that tells the user roughly what happened, what the impact on him may be, what he needs to do to get out of the corner he's painted himself into, and what he can do in the future. This should always include an unique message identifier for your use.
Example:
Please note this error number: #1234. You will need it if you contact technical support.
The program was unable to update the application preferences file. That is the file that stores the settings you have chosen for things like preferred document styles and last document viewed (choose "More Information" for details).
File updates can fail when the security permissions on the preferences file or directory ave been set to prevent changes; when more than one program is editing the preferences file at the same time; or when the computer's file system is damaged.
You can check for these kinds of problems (chose "More help" for instructions) then choose "Retry" to see if the problem is solved. If you choose "Ignore Error" the program will continue without saving any preference changes. If this error persists it is recommended that you check the security settings, permissions and integrity of your filesystem.
[More information] [Retry] [Ignore Error]
Now if this sounds like a pain in the ass, it *is*. But it's a much better approach than trying to trick users into reading a piece-of-shit error message like "File operation failed" for a condition like that described.
So if financing a nuclear power plant is economically attractive, then so should financing consumer solar panels. In fact if they are lightweight an easy to install, it'd be a lot more feasible to repossess and resell them, although that means you'll probably need to insure them against theft.
That said, I'd bet the problem is with consumers rather than banks. Most houses wouldn't be able to generate enough power to go off the grid, and the payback time doesn't justify the aggravation of having another household system to manage and the changes to the appearance of the house. I'll bet farmers who use photovoltaics (e.g. vineyards) get loans for their systems like any other kind of equipment.
Er... Griswold is one of the most important landmark constitutional decisions in the last hundred years. I don't know how one measures "attitude", but Griswold is *binding* on all US courts.
It's flawed English, both semantically and syntactically ("does not give due consideration to the value to intellectual creations.")
The logic is faultless. What these vendors of proprietary software are saying is that open source competition will reduce the value the market assigns to their products.
The question is whether you share the unspoken assumptions: that this is a bad thing, and that the government should do something about it.
Geez. I'm always jealous when I see those pictures of old European canals that are still navigable. Of course we had a few really historically important canals here in the US, but never quite the same kind of network, and a lot of the smaller ones have been filled or are otherwise unnavigable.
There are still some cool waterways to houseboat on -- the Saint Johns in Florida is amazing.
Slashdot Mirror
Well, if you don't want to remap the key in software, glue a small block of wood to the top of the Esc key. Then lay a strip of tongue depressor so the key extends past the left edge of the keyboard. You can also overhang the right edge of F1 a bit if you want.
Seriously, part of being a geek is realizing that you don't have to accept the world around you *as is* ... at least not when it comes to *made things*.
Not irrelevant, but case not proven yet.
Yes, Google would not be doing this if it weren't for Congress.
But Google is not *required* to use this *particular* mechanism to preemptively quash potential copyright violations. That was its choice.
The question is whether Google's actions are a reasonable response to current statutory law, as opposed to being an overreaction. If a reasonable person would find it advisable to quash fair use of IP in a policy debate, right there you have a demonstrable chilling effect.
If this event just reflects a bug in Google's requirements analysis, you can't lay *fault* to DMCA or Congress. Congress is implicated in the event, sure, but you can't blame them for unreasonable responses to laws, even if those laws are otherwise unreasonable.
You can argue that if a law or regulation prompts widespread unreasonable responses, that the law needs improvement, possibly extensions and clarifications of whatever safe harbor provisions it has.
I'll paraphrase what you said in your first paragraph: "Regardless of what a person chooses to call himslef, if you look closely enough at his political philosophy, most of the time you'll find it's incoherent."
Actually, he'd have to have an application that required measuring the state of the platters independently of the drive heads to literally need to control the "physical location" of the bits. Otherwise he's already dealing with an abstraction of the physical layout of the disk. Given that, he might as well build the abstraction he wants on top of the raw disk interface provided by the OS.
In international law, "legal" is what countries can customarily get away with. It follows that one does not expect international law to be fair. It's just the continuance of war by other means. Less destructive means.
if you describe your requirements so abstractly? It sounds to me like you've come up with a solution ("Let's write the bits directly to the hard disk") and now you want pointers on how to make it work without explaining why.
If you just want to get around the file system, then use raw block I/O to the device. However it *sounds* to me like for some reason you've decided the *actual physical* layout of bits on the drive is important, in which case you are going to have to write your own disk driver -- if the drive electronics themselves don't defeat your attempt to know where bit is physically written.
It's inconceivable to me that you'd actually need to know this. Since you only *read* the data through an interface, it should make no difference if you *write* though the same interface, as long as it's consistent. In other words, unless you are going to disassemble the drive and examine it with an atomic force microscope, you have no way of telling the difference between a physical layout and an equivalent *model* of a "physical layout".
If you can't say *why* you need to do this, at least explain the parameters (how much storage, how fast, what kind of retreival etc.). My first reaction was that you should not use a magnetic disk at all, but an MTD flash device. Even so, you're dealing with an abstraction. You have no idea whether the device itself has mapped a bad bit to a different location at the hardware level. However short of tearing the device apart and putting the flash chips in a special circuit, you'd have no way of telling.
Oh, he'll find investors. And they won't necessarily be stupid in terms of something you can measure on an IQ test.
All he has to do is to take advantage of the kind of bug in human cognition that make otherwise sensible people fall for any other scam.
I disagree. What we need to do is compartmentalize.
Why do you have to use the same system to browse the corporate intranet over VPN and handle personal web browsing? Each of these activities should take place on a different virtual machine on a different virtual network. Then you watch the virtual/host interfaces like a hawk.
This is not an airtight strategy -- there is no such thing. What it does is buys time and spreads the footprint of the attack.
It's not entirely convenient. But you can focus your security attention on mechanisms you use to move data between different security universes.
Companies seriously interested in security also really need a solid cryptographic infrastructure, including two factor security with a hardware component, and revocable trust. That's not convenient either.
If you *know* that ignoring an error will cause database corruption then you have a very serious bug in your program that needs to be fixed before a user even has a chance to touch it.
This is where the "prevent errors from happening in the first place" school is entirely correct. There should be no condition under the control of your software where a real database (as opposed to a file store you manipulate with SQL) can be corrupted by user action or inaction. Atomic operations should be wrapped in transactions; beyond that it is the DB vendor's responsibility to give practically bullet-proof data integrity.
That said, database platforms can flag thousands, sometimes tens of thousands of error conditions. These are things that happen completely out of your control (e.g. a tablespace that fills up; a license restriction that is exceeded).
Probably the most serious problem this poses is when user transactions are not posted. This might not be noticed by the user, and can create operational problems for them later as severe as literal "corruption". If you can't figure out why a transaction was not accepted, if its not one of the various foreseeable integrity exceptions, you almost have no choice but to throw up the database error message with a request it be reported to tech support.
I once worked with a RDBMS and users complained *my* software was losing data. "Impossible" was my reaction. Except that when I looked into it I discovered that the database server was configured to treat abnormally terminated connections as if they were wrapped in an implicit transaction. If the network connection got dropped or the client program crashed, user data simply disappeared, even though the database platform was told to commit. That's just *wrong* behavior, but hardly the most egregious thing I've seen.
That means that if I can't properly shut down a database connection for some reason, I *have* to tell the user to check that all his data was saved, and I *have* to tell him that if its missing he ought to contact me for help configuring the server. I can argue that it's not my problem, it's the database vendor or DBA's fault, but it won't matter. The users will blame *me* if I don't tell them what to do.
If you really have time for writing the "more information", you'd better write a function that checks what permissions are missing and what locks are held.
That's one of my points. Thinking it through the guidance you ought to offer the user leads you to the the things you ought to check yourself. It's very easy to say "file operation failed" and leave it at that.
Have you ever written messages like that in a real application?
Yes. Maybe not quite like that one, but I try to provide these kinds of things to users in every error message I write:
(1) An identifier that tech support can correlate to code.
(2) A clear description of what happened.
(3) An explanation of consequences of the next action the user might take.
And yes, my error messages sometimes look silly, because they aren't what people are used to.
I like your shorter error message, but I think it misses an important element: what is the consequence of canceling? In *this* case it's relatively benign. If it happens on user data, it is not necessarily so. The problem is that saying it's a "failed file operation" is a programmer centric error message. What matters to a user is this: "What am I going to lose if I choose 'Cancel'?" Conceptualizing this error as a "file permission problem" means lumping in losing configuration data (feh -- who cares?) and losing work that might be saved by copy and paste.
I understand there's a problem with writing too much into an error message, although I don't agree that the problem is with the user. The problem is with the programmer.
An error message is something like a comment in code that the user gets to see. We all agree that good comments are a big help, but sometimes really verbose comments can obscure the code itself, or even get out of sync with it. So the biggest downside of trying to be informative is to end up *misinforming* the user. That's the point where you have to curb yourself, not having other programmers laugh at you.
Because we've reached the point where programming per se is not the limiting factor in programmer.
Oh, some languages are nicer to program in than others. I'll take Python over Java, for example, if the criterion is just how fun and easy it is to write programs. But I'll often choose Java in many instances because it has libraries and frameworks that make my job easier.
And there's the rub. It's dealing with frameworks and APIs and libraries that kills you. The Java ecosystem is like a huge, booby-trapped treasure chest.
When I started programming professionally back in the 1980s it was a lot more fun, because there wasn't much in the way of libraries. Programming was mostly thinking about problems. Now it's mostly thinking about APIs.
Very true.
Programmers have an ethical duty to safeguard users' work. Where we can't, we must give useful guidance (not just in verbiage, but in UI design altogether). If we do our best and users ignore that, it's not our fault.
Why?
I've in fact written error messages this way for years. I've found it extremely helpful. About 80% of users ignore the text at first, but that's a hell of a lot better than leaving 100% of the users up the creek.
The problem is that users are not accustomed to error messages that try to help them. Over time users begin to realize that there's useful information, and many tech support problems are reduced in severity. Eventually the program itself gets better, because of the thought that has to be put into common error conditions and the feedback from support.
If you are going to fail, fail in a big, obvious and *transparent* way.
On what basis do you claim the #1 problem is that errors are too wordy?
Naturally all things being equal, an less wordy error message that is equally informative is preferable to a more wordy one. But a succinct and cryptic error message is less preferable than a long but highly informative one in my opinion.
If the user is overrun with verbiage, it's because your program is too error prone.
Don't patronize users.
Your first responsibility toward the user is to minimize the possibility something drastically bad will happen to his data. If you can't handle an error message, you *must* delegate that to the user and give him enough information he can take steps to secure his work. That includes calling tech support.
Hiding your failure to protect the user's work with the rationalization that some users are too ignorant to take effective action is not ethical system design. When you fail, you *must* tell the user even if it makes him scared or angry. That prospect should motivate you to do a better job.
In my experience, *some* users do read informative error messages. They tend to be important ones. Most have to be trained, but they come around once the realize that this is useful.
There are always some users who could manage to drown themselves in a teacup. Helping the intelligent users is (as I'll show in a minute) a first step toward helping the hopeless ones.
I don't like the "eliminate as many error messages as possible" strategy. Not that that's not a worthwhile thing *if you can isolate the user from the impact*. The problem I see is that programmers will just sweep errors under the carpet. I can't tell you how many times I've seen serious error conditions caught and shoved away in an obscure error log somewhere. If you are going to fail, fail in a big an obvious way. I've also seen bug tracking systems where they highest severity bug is a "crash bug". Many crash bugs are in fact benign. I've had to retrain practically every single programmer who's worked to me to drill this into their heads: the most severe class of bug is a *data corruption* bug. The very worst bugs of this class give innocuous looking but wrong results. After that come the bugs that cause work to be lost.
Every single error condition must be handled, or delegated to the user. Handling without user intervention is best, but ignoring error message to reduce the number of errors seen by users is bad, bad, bad design. The elimination of error messages should be a *result* not an *end*.
Part of the point of disciplining yourself to write informative error messages is that it forces you to *think* about the underlying problem. Excessive error messages are the result of not thinking a situation through. My point is that every message put before the user should *inform his response*. Setting that criterion forces the programmer to do the thing he doesn't do when he throws up an extraneous message: work through what ought to be done about it.
It's not either or. I'm all for everything you suggest. But I'm also for writing clear error messages that reward the users who take the effort to read them. What I'm certainly not for is adding bells and whistles to *bad* error messages to try to grab user attention, as suggested by the asker.
Q: How do you get users to read error messages?
A: How do you write error messages that are worth reading?
Commentary: Users do not read error messages because they are mystified by them. To mystify them willfully only increases their resistance.
The first job is to create error messages that actually help the user. Users are conditioned by the generally crappy state of error messages to ignore them. If you provide helpful error messages then the users that *can* be helped can be trained to read them. It's operant conditioning -- like giving a rat a food pellet for successfully navigating a maze.
The very first thing you should do with error messages is pull them all together into some kind of document. This document should have (1) an unambiguous ID for the error; (2) a description of *what* happened ; (2) a description or at least a guess for *why* it happened; (3a) the impact of the error on the user (3b) how the user can recover from the error; (3c) what the programmer can do to avoid this; (4) what the user needs to do in the future.
Note that 3b also implies that *you* should consider how the program is apt to behave after the error message is displayed so you can offer the user sensible choices. For example, if the program fails to write the application preferences file on exiting, it makes sense to give the user both retry and cancel options, rather than sending him into a pointless loop that requires him to shoot the process down.
Then you write an error message that tells the user roughly what happened, what the impact on him may be, what he needs to do to get out of the corner he's painted himself into, and what he can do in the future. This should always include an unique message identifier for your use.
Example:
Please note this error number: #1234. You will need it if you contact technical support.
The program was unable to update the application preferences file. That is the file that stores the settings you have chosen for things like preferred document styles and last document viewed (choose "More Information" for details).
File updates can fail when the security permissions on the preferences file or directory ave been set to prevent changes; when more than one program is editing the preferences file at the same time; or when the computer's file system is damaged.
You can check for these kinds of problems (chose "More help" for instructions) then choose "Retry" to see if the problem is solved. If you choose "Ignore Error" the program will continue without saving any preference changes. If this error persists it is recommended that you check the security settings, permissions and integrity of your filesystem.
[More information] [Retry] [Ignore Error]
Now if this sounds like a pain in the ass, it *is*. But it's a much better approach than trying to trick users into reading a piece-of-shit error message like "File operation failed" for a condition like that described.
Hmmm.
So if financing a nuclear power plant is economically attractive, then so should financing consumer solar panels. In fact if they are lightweight an easy to install, it'd be a lot more feasible to repossess and resell them, although that means you'll probably need to insure them against theft.
That said, I'd bet the problem is with consumers rather than banks. Most houses wouldn't be able to generate enough power to go off the grid, and the payback time doesn't justify the aggravation of having another household system to manage and the changes to the appearance of the house. I'll bet farmers who use photovoltaics (e.g. vineyards) get loans for their systems like any other kind of equipment.
You know, I do find the results of wavelet sharpening pretty darn amazing. Pretty close to magic, although not quite as magic as in the movies.
Actually, there *is* a keyboard. One of the docking stations includes a keypad. Gosh I wish the Kindle had that.
It also generally enables it by allow the Executive to engage in law enforcement and the states to do a wide variety of things.
You're excerpting me out of context.
Er... Griswold is one of the most important landmark constitutional decisions in the last hundred years. I don't know how one measures "attitude", but Griswold is *binding* on all US courts.
It's not flawed logic.
It's flawed English, both semantically and syntactically ("does not give due consideration to the value to intellectual creations.")
The logic is faultless. What these vendors of proprietary software are saying is that open source competition will reduce the value the market assigns to their products.
The question is whether you share the unspoken assumptions: that this is a bad thing, and that the government should do something about it.
And ironically, ducking the issue is chicken.
Geez. I'm always jealous when I see those pictures of old European canals that are still navigable. Of course we had a few really historically important canals here in the US, but never quite the same kind of network, and a lot of the smaller ones have been filled or are otherwise unnavigable.
There are still some cool waterways to houseboat on -- the Saint Johns in Florida is amazing.