Lennart Poettering: BSD Isn't Relevant Anymore

Polytropon freebsd at edvax.de
Fri Jul 22 14:39:28 UTC 2011

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

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.

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list