Rahul Sundaram wrote:
You are overgeneralizing here.
You're right.
However:
(1) GUIs are expensive to develop. A GUI configuration dialog for a
system can be an order of magnitude more complex (and expensive to
develop) than the system.
(2) GUIs face difficult scalability problems. Part of this has to
do with HCI issues: one needs a different UI to choose between 10
items, 100 items, 1000 items or 10^6 items. Part of it has to do with
data structures: GUIs generally build bulky data structures in RAM,
causing swapping problems with modest data sets. Yeah, you can have
the data in external memory and use flyweights to display stuff on the
screen, but that's trading for another set of performance problems.
(3) Partially because of (1) and partially because of organization
imperatives (Apple, for instance, wants to use iTunes to push ALAC
instead of FLAC), GUIs express an ideology. At best a GUI makes
"certain tasks trivial and other tasks difficult", but it's more likely
to be "certain tasks trivial and other tasks impossible" or "certain
tasks difficult and other tasks impossible"
Perhaps things have gotten better in rawhide, but the "firewall
configuration" gimmick in RHEL is a classic example of "uselessware".
Pretty much every system I run needs to have a few ports punched in the
firewall that aren't in the list -- the firewall configuration gimmick
never remembers the ports that I've already opened, so I have to keep a
list of the ports that I've opened somewhere (or maybe look at the conf
file I'm not supposed to change) and enter them all in by hand. It's an
example of "for the want of a nail... the kingdom was lost" that often
kills GUI apps.
The basic issue is that a GUI firewall editor has to support 100% of
the functionality I need or coexist with my ability to edit conf files
by hand, or it's 100% useless. A GUI app that does 90% of what I need
isn't enough if there is no workaround to get the other 10%.
To make GUIs work, Unix would have to give up on
human-comprehensible configuration files. (Yes, that means XML.)
Many of them have indeed adopted XML but this is not the one true path
by any means.
I'm not against XML, I'm just saying that XML files don't count as
human-comprehensible and editable. Something that's basically a
database is another option, but again, other than (arguably)
relational databases, those aren't human-comprehensible and editable...
You may not really be able to have it the GUI way and the "Unix way"
-- that doesn't mean that everyone has to stick to the Unix way. My
complaint about GUI gadgets (particularly the one in RHEL/Fedora) is
that they "almost work" and never "really work" because of a mismatch
between the data structures and the UI model. One way to get a correct
application is to make the data structures fit the UI model. There are
problems with that, but it's possible to make tools that really work
that way.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
