Date: Fri, 22 Jul 2011 16:39:26 +0200 From: Polytropon <freebsd@edvax.de> To: Chad Perrin <perrin@apotheon.com> Cc: FreeBSD <freebsd-questions@freebsd.org> Subject: Re: Lennart Poettering: BSD Isn't Relevant Anymore Message-ID: <20110722163926.7af46a9d.freebsd@edvax.de> In-Reply-To: <20110722125826.GA73065@guilt.hydra> References: <4E22DFE9.7050007@pathscale.com> <201107172016.30727.lobo@bsd.com.br> <4E23989F.7010701@gmail.com> <4e242fab.s4vpgxxZEUq0LFDq%perryh@pluto.rain.com> <1311017168.44397.YahooMailRC@web36508.mail.mud.yahoo.com> <13800_1311018255_4E248D0F_13800_81_1_D9B37353831173459FDAA836D3B43499C521864F@WADPMBXV0.waddell.com> <20110718162245.0d426239@scorpio> <20110719032131.GA29635@guilt.hydra> <20110719085529.1671ec7f@scorpio> <20110722105642.d21067c0.freebsd@edvax.de> <20110722125826.GA73065@guilt.hydra>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 Jul 2011 06:58:26 -0600, Chad Perrin wrote: > I mean that its primary purpose is to try to guess what the > user wants based on the developers' mental model of what users want, then > tries to make it happen -- and, too often, the developers' mental model > of what users want does not match up with the reality. Users, and their > circumstances, are not always the same. This is the _main_ problem: Because users are different, you cannot guess what "they" want, as there are too many of them, with very different habits and expectations. To give an illustration: When printing from within Gimp, I get a message that it "could not connect to the server", which refers to the use of CUPS's lp* command. I don't have CUPS installed, but it seems to be hardcoded in Gimp to try to access it. Why? Maybe the majority of users uses CUPS - possible. Older versions of Gimp didn't have that bug, and: No, it's NOT a feature. So why have some developers made things more complicated? Another example is a bug (in terms of annoying and useless interruption of work flow for _no_ benefits) seen in Gtk2's file dialogs. Let's say you are using Sylpheed mail client and want to attach a file. Instead of manually clicking through a file list or hierarchy, you can enter the name. Sounds very comfortable. Let's also say you have a file "bla.txt" you want to attach which is in a directory /home/bla/bigdir/small/bla.txt where bigdir contains 3000 or more files. But you don't want one of that files. What happens? You start typing /home/bla/bigdir/sm... hello? Erm... what... the dialog STOPS and you can continue typing as soon as all files that you are NOT interested in have been listed. This may take several seconds, depending on file count. Why is this? The program "knows better" than me! Properly implemented file dialogs allow you to confirm a directory change before reading that directory (instad of all directory on the way to the one you want). The list should be populated only if you _intend_ to use it. But... HOW to communicate _that_ to the system is... well, the developer thinks: "I'll make sure we read every directory, just to be sure, even if it won't be used." Meanwhile, I have to even use xrandr to make X.org do what XFree86 could to in the past: Run a 21" CRT at 1400x1050 (and _not_ just 1024x768 without stopping the whole system). So much for the glory of prediction and autodetection. :-) > In fact, these damned automated wireless management tools are so focused > on trying to provide what the developers expect people to do that they > often interfere with one's ability to tell them "No, I don't want you to > do that, do something else." This is commonly the situation when the autodetect magic does _not_ work. You can also see that in X given some specific (often older) hardware that you need to manually setup. NEED TO, because the automated approach doesn't work. As soon as you have the change to actually OVERRIDE this automation, it's okay, but as soon as you have to start FIGHTING the automation in order to make the system do what YOU want, something's terribly wrong. > Automation is great when it takes a back seat to serving the individual's > needs/desires, allowing itself to be overridden in simple, obvious ways. > When it does not, it sucks. Very true. Even if automation is the preferred default, it's not _always_ welcome. > To do the former, all the developers of > automated network management tools on Linux-based systems had to do is > ensure there was a manually configured, manually operated command line > toolset for network management and build automation around that. In my opinion, that would be the ideal approach: Easier for building ON that working basis, and working WITHOUT anything built upon it. > [...] non-deterministic behavior, > doing different things at different times for the same evident inputs, > and fighting the user's actual needs and desires at times. That's the WORST thing imaginable for anybody who is using a computer with his own brain in a working condition... > In fact, the NetworkManager set of network management tools has in some > ways outdone the stupidities of MS Windows network management. "Hey, > this is stupid, but it's not stupid enough. We can do 'better'." I think this is an attitude today very often found among developers. They just don't want to be _like_ MICROS~1, they want to be "better" in order to convince users to use their programs. Therefore they believe that in order to gain access to the majority (!) of users, they need to dumb down everything. Professional users are therefore traditionally out of scope. > This is the kind of crap I do *not* want to see make its way into FreeBSD > from the Linux world, and it's why I said I'm okay with tools like > NetworkManager being released under restrictive licensing that makes it > less likely to be harvested for ideas by OS projects like FreeBSD. You already have "good" examples in the ports collection (see my examples above). Luckily, for doing that on OS level, it takes much more. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110722163926.7af46a9d.freebsd>