On Wed, 11 Jun 2003, Michal Jaegermann wrote: >> MAH> In the land of the GUI, I subscribe to Havoc's mission on >> MAH> simplicity in UIs, >.... >> MAH> All modern hardware detects video ram properly. >> >> I wasn't aware that a TNT2 was a ten year old card. > >Actually you have seen here a vivid example of this "Havoc's >principle" in action which cleary is "Screw a significant percentage >of users in a hope that the remainder would not mind". http://www.joelonsoftware.com <-- read this >Somebody decided to add this videoram setting to config files >unconditionally. Personally it did not affect me in a major way >(it was a minor PITA on occasions but not a show stopper) but >some people wasted significant time and effort trying to find >what the problem is. A few persistent ones, hanging on that >list, found a solution. A vast majority of those hit undobtely >said: "Forget it. This thing is broken and lets find something >else." and in a sense they were right. > >An old principle says "Things should be as simple as possible but >NOT simpler". Hey, I'm not saying it is perfect. It is impossible to solve all the worlds problems in a day/week/month if ever. You set goals of what you wish to achieve and you aim to reach those goals. When writing software, you'll no doubt end up with users with conflicting requirements/preferences/interests. GUI tools in particular, at least in our mandate, are not intended to just be graphical config file editors. If someone wants a graphical tool which can configure every possible option of anything, the tool is called "emacs" and it is a universal tool which works with all config files in the system. The GUI tools are intended to present the most frequently used options to users in a friendly way, and not be templates of every possible option in existance. Given the choice between: 1) Putting options in tools which the overwhelming majority of users do _not_ need ever, and then having 1000 users screw themselves by forcing videoram unnecessarily and ending up with all kinds of problems, and either being upset with the system, with X, with Red Hat or whatever, and then having 20 of them actually report bugs, or issue tech support calls. or 2) Removing the option, making the tool simple and easy to use for the masses, and then only the people who NEED such an option can have problems potentially. They can easily edit their config files. I choose #2, with the addition that it is nice to know what hardware out there has broken RAM detection, in hopes that it can actually be fixed some day. You can't possibly please everyone out there, and if you try, you end up not pleasing _anyone_. When it comes to choices which no matter what choice is chosen, someone out there will be upset, I generally look at the big picture, and try to decide which choice I think is best for the widest possible audience with the least amount of problems, or what type of default behaviour is best for the largest group of people, make a decision about it, and stick to that. Then at worst, you upset one group of people whom are the smallest group, explain yourself, and move on to the next piece of code. It isn't "screw the users" like you make it out to be. Users always feel screwed no matter what you do, and if one loses sleep over some user out there feeling screwed, then one will never sleep, since someone out there will always feel screwed. RAM detection doesn't work on TNT2? Fine, send me a TNT2 card, and I'll investigate it. -- Mike A. Harris _______________________________________________ xfree86-list mailing list xfree86-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/xfree86-list IRC: #xfree86 on irc.redhat.com
