On Wed, Mar 21, 2007 at 03:51:02PM +0100, Oswald Buddenhagen wrote: > On Wed, Mar 21, 2007 at 12:27:10AM +0000, Dave wrote: > > On Tue, Mar 20, 2007 at 12:14:17PM +0100, Oswald Buddenhagen wrote:
> > > otoh, most users *are* idiots (yes, even the unix users - > > > > Idiots have the right (a) to exist, and (b) not to have decisions that > > are rightfully theirs stolen by a zealous system, not even in the name > > of security. People don't lose their rights by being idiots. > > > i believe that you believe this - it's so truly american. I don't necessarily disagree with that statement. > i even know > for a fact, that many of your kind agree with using heavy weaponry to > "convince" others of these ideals. Many do, and many don't. At the end of the day, indirect Democracy has certain problems. On the other hand, a country trying to defend itself against terrorists in a world that doesn't care is in a rather unenviable position. > the problem with this attitude is > that *a lot* of people have to suffer from those idiots. A lot of people also have to suffer from the terrorists that these idiots are fighting. At any rate, we're getting a tad off-topic, no? > blind trust in > unlimited freedom based on the assumption that the bad things will go > away by themselves eventually That's basically one of the main attitudes that lead to most of the world not really caring much about countries sponsoring terrorists. I'd rather not discuss these topics on-list unless you believe that the consequences of the discussion are relevant. > won't make perversions like creationism, > scientology or hate tv vanish, quite on the contrary. I definitely don't want to get into _these_ topics, since they open many new cans of worms in new domains. > and they *do* hurt > - some short-term, some long-term, some physically and some > economically. and no matter how you twist it, it limits the freedom of > those affected. I'd say that if your sysadmin is supporting crackers, you're in the unenviable position of being an agent of a terrorist. The only difference is that unlike an employee, it's kinda hard for you to quit your "job" when you're simply a citizen/resident of a country whose government supports terrorists. Either way, it's important to point out that your freedom has already been affected by your own government if you're an Iraqui, Iranian, Syrian, Lebanese, etc., resident. If a foreign country decides to quit doing business with your country, you're in a position analogous to a physical user of a system that other systems around the world are blocking because your sysadmin is rogue. Again, it's not so easy for you to jump ship in the real world, due to the finiteness of land on our planet that hasn't already been claimed by some other country. In the world of computers, new "land" is being built every day. Many people own a whole network of "land." If you don't like your sysadmin, you might have to settle for a less powerful system (since you no longer have the resources of your old sysadmin available), but at least you can have _a_ system. In the real world, finding a square inch of unowned land (not counting Antarctica, which under international treaty can't be owned) is a challenge. You're also on your own as far as protecting your new country, even if you discover some new land (or take a page from our book and nuke the natives). The local police does a fairly good job of protecting your computer in any first-world country, in the real world. > how does *that* fit with your ideals? We're in the wrong place to debate ideals in other contexts. If you want to discuss ideals in the hopes of being able to apply them to Mutt, no problem, but I don't think the list would be happy if we went off on endless tangents. > the bottom line is > that sometimes you have to limit some freedoms to preserve other, more > important ones. anything else is simply irresponsible. I'd like you to elaborate on exactly which freedoms you propose to limit in order to preserve which other, more important ones. In my book, the most important freedoms are those of the system owner, if we start out from a worldview that recognizes the concept of private property. (If we don't, we can get into a lot of hot water in the real world.) > > > and even the most security conscious ones make mistakes. > > > > It's up to an individual user to decide not to trust himself, if he > > knows he's in the habit of making mistakes. > > > this is silly. everbody makes mistakes. That doesn't matter. The user is in charge of deciding how many (if any) limits he wants to place on his own decisionmaking authority. The question is outside of the domain of the programmer. > confirmation dialogs are a > typical example of a measure to prevent small mistakes from having big > effects. That's why mv(1), for example, offers the -i option. If you don't trust yourself to move carefully, you can instruct the move command to force you to confirm actions that it interprets as possible mistakes. However, the -i option isn't on by default, since it'd violate the UNIX philosophy of doing your job right (without asking ten million unnecessary questions first). (It'd also violate the principle of least surprise, incidentally, since an mv(1) user expects "mv a b" to result in "the object formerly known as a" now being b. It's not up to the user to guess all the artificial reasons that mv(1) might fail; guessing all the real reasons is hard enough. Adding fake reasons for failure (or worse, attempting to prompt a user who may not even understand the prompt (say, another program ... yes, I know you can test if it's a tty, and make assumptions based on that test, and create even more complexity, but you'll only be creating more surprises by doing so ... remember, following the KISS principle is by definition the simplest method of following the principle of least surprise, since b is merely a natural consequence of a) surprises.) > but like any other safety measure, they have to be placed > wisely. You just hit the nail on the head: the user himself is the only one in a position to reverse engineer his own psychology in order to place prompts wisely. A programmer should write programs that simply do their job without asking qusetions, and leave Psychology assignments to Psychology experts. A programmer shouldn't have to be a security expert and a psychology expert, in addition to being an expert at whatever task he's actually hoping for his program to perform after all the prompts. Programs should perform tasks, not prescribe user interfaces. > same goes for security, only that it is way harder. Sticking to the KISS principle is an easy way of avoiding the whole problem. Let the user decide for himself what type of UI he wants. > > > i can accept absolute paths determined at configure time in the > > > default config, > > > > I can't. The configure script has no authority to steal decisions > > from the user. The user owns his copy of Mutt, not the other way > > around. > > > dude, it is a config file that can be overridden, so such dogmatic > argumenation is completely pointless. As Robin Hood would put it, it's the principle of the matter, if nothing else. (We don't know if it's anything else, because once you start violating user rights, all bets are off. It's stupid to ask people to prove that there's something else before accepting that it's wrong, since by violating user rights, you're setting yourself and your users up for trouble. It might not bite today, but it'll bite eventually.) It doesn't matter whether a certain behavior is the default because a config file installed automatically makes it so, or because a command-line switch is required to change the setting, or even because the program triggers that behavior based on some random number that it generates every morning. At the end of the day, the program, as installed normally, tramples its owner's rights. > an actual reason would be the principle of least surprise: if i put a > new gpg in front of $PATH, i expect it to be used by every program > without checking each program's configuration first. one could call this > a part of the unix principle, too. :) You aren't disagreeing with me here about the solution (or even about a problem), only about the root of the problem. The root of the problem to you is a purely practical matter, AFAICT. To me, the root of the problem is simply that the programmer has no right to steal the user's free choice. The practical problems are all nothing but the inevitable results of violating user rights. - Dave
