[linux-elitists] Re: Yet another mozilla atrocity

Karsten M. Self kmself@ix.netcom.com
Tue Oct 7 18:07:22 PDT 2003


on Tue, Oct 07, 2003 at 01:37:56PM +1000, Martin Pool (mbp@samba.org) wrote:
> On  4 Oct 2003, "Karsten M. Self" <kmself@ix.netcom.com> wrote:
> > on Fri, Oct 03, 2003 at 12:19:50PM +1000, Martin Pool (mbp@samba.org) wrote:
> > > On  2 Oct 2003, Jeremy Hankins <nowan@nowan.org> wrote: 

I want to split discussion into two topics.  This one focusses on
lock-in, GNOME's costs to application development, and overall
suitability of configuration management tools.

> > The fundamental problem is one which is best stated, IMO, in the
> > recently published white paper "Cyber Insecurity", Greer et al.  Yes,
> > the paper addresses Microsoft.  Its principles are generalizeable,
> > however, particularly this paragraph on page 13:
> > 
> >     Tight integration, whether of applications with operating systems or
> >     just applications with each other, violates the core teaching of
> >     software engineering, namely that loosely- coupled interfaces make
> >     maintenance easier and life-cycle costs lower. Academic and
> >     commercial studies supporting this principle are numerous and
> >     long-standing.  Microsoft well knows this; Microsoft was an early
> >     and aggressive promoter of modular programming practices within its
> >     own development efforts. What it does, however, is to expressly
> >     curtail modular programming and loose-coupling in the interfaces it
> >     offers to others.  For whatever reason, Microsoft has put aside its
> >     otherwise good practices wherever doing so makes individual modules
> >     hard to replace.  This explains the rancor over Prof. Ed Feltens
> >     Internet Explorer removal gadget just as it explains Microsofts
> >     recent decision to embed the IE browser so far into their operating
> >     system that they are dropping support for IE on the Macintosh
> >     platform. Integration of this sort is about lock-ins through
> >     integration too tight to easily reverse buttressed by network
> >     effects that effectively discourage even trying to resist.
> > 
> > Read that until you get it.  I see strong echos of this practice within
> > GNOME especially -- it's a reason I find it very, very hard to trust
> > Miguel, it's why I don't generally like design decisions GNOME makes.
> > For the most part, where I like GNOME apps it's *despite* rather than on
> > account of many of the GNOME tight-integration features.
> 
> It's an interesting comparison, although I'm starting to think
> Godwin's law ought to apply to comparisons to Microsoft.

While I grin slightly at this, there are some valid points to be made.
Microsoft isn't wholly irrelevant to software development.  It can
always be used as a bad example.


> Of course Microsoft are intentionally trying to lock people in, and
> using monopoly power to do so.  I don't think either of those apply to
> GNOME.
> 
> Many people seem to use some GNOME-based applications on non-GNOME
> desktops, or use part of the desktop.  (I often disable Nautilus,
> which is reasonably straightforward.)  I sometimes run Metacity, rxvt
> and emacs, and nothing else.  OK, I can hear echos, but it's a long
> way away.

First:  don't think that free software isn't immune to influence by
external factors.  If anything, it always has been, and will be getting
more so over time.  Lately the battles have been overtly political, with
governmental initiatives in Australia, Germany, Massachussets, and the
UN, as well as elsewhere.  IBM is certainly the 800# gorilla of Linux
development, and Microsoft is trying to influence the scene with its
usual mix of internal FUD, journalist shills, and increasingly political
lobbying efforts, many associated with strongly right-wing, or
(amusingly) libertarian groups  who apparently fail to see the irony in
backing criminally abusive monopolies unduly influence government
policy.

Specifically:  GNOME has been a darling of organization seeking to
corporatize the GNU/Linux desktop.  This isn't necessarily  bad, and
some efforts (such as Sun's usability studies) are much needed.  Still,
this has been accompanied by what appears to be a very strong push
toward de-featuring GNOME and GNOME applications, many times in ways
which _aren't_ analogous to your automobile choke control example, but
directly influence user experience.  The Galeon 1.2.5 => 1.3.x
transition -- acknowledged by the Galeon development team itself as
widely criticized.  See their "History" article:

    http://galeon.sourceforge.net/links/history.php 

GNOME itself is directly to blame for much of this.  The fact that a
large number of apps are locked in to a set of libraries means that
heinousness such as libbonoboui are imposed on all projects.  If twelve
months of wasted software development across 885 software projects is an
acceptable cost, GNOME has some extreme architecture governance
problems:

    http://www.gnome.org/softwaremap/list 
    885 projects listed

    http://galeon.sourceforge.net/news/index.php
    Galeon 1.3.0 released October 26, 2002.


> > While we're talking gripes:
> 
> As Jesse said, these are just bugs.  Most software has them, and I
> don't see any systematic reason for them.  File non-incendiary bug
> reports and they will probably be fixed.

I've filed several bugs against Galeon to which the response was that
there is no work on the current (1.2.x) branch, but that all work is
being focused on 1.3.x.  E.g.:

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=165514&archive=yes


GNOME again has several things to answer to:

  - The project has repeatedly made major, and I mean truly sweeping,
    changes in both "preferred applications", and in underlying
    libraries.  This has lead to abandonment of such very promising
    projects as Enlightenment, Galeon and AbiWord by GNOME (in favor of
    Sawfish/$WINDOWMANGER, Ephiphany and OOo, respectively).  Yes, the
    user remains able to choose alternatives, but the application
    situation is a bit rocky as a result.

  - Library changes mean that small development teams for small but
    useful projects are forced to choose between developing for the new
    targets, _or_ supporting and updating existing releases.  This
    creates a new development treadmill situation which developers can
    barely manage to keep abreast.

  - Complex relationships among libraries mean that applications are
    saddled with fundamentally broken, half-assed crap like libbonoboui.
    If anyone ever wants evidence that free software can result in
    terminally fucked up designs and solutions, they need look no
    further.  Again, the costs of this screwup are huge.

  - Ironically, RH tends to push GNOME, while Debian until relatively
    recently IIRC tended to provide a WindowMaker desktop by default
    (this may be inaccurate).  But Debian's vast superiority at
    dependencies resolution made it far easier to pick and choose from
    among specific GNOME apps to install, particularly without a full
    GNOME desktop environment installed.



> > > If software authors want to address an audience who does not enjoy
> > > editing dot files in vi, who are you to tell them not to?
> > 
> > If we want to point out the very obvious flaws and problems in a
> > scheme, who are you to tell us to shut up?
> 
> I guess I would respect it more if you could think of a better design,
> rather than just complaining.  The ones that have come out (e.g.
> Nick's "just poll every second", Don's "put it all in one
> configuration file") have problems.

First:  complaints themselves are legitimate, whether or not they pose a
solution.  The response we've had from a number of people (yourself
largely excepted, but Jeff and Jason specifically) has largely been a
"piss off".  Viz:  Hankin's comments quoted above.  Not acceptable.

Second:  there have been suggestions, some of which you're rejecting,
some of which do appear to have merits.  I think we're starting to make
progress.


> > GNOME's development team is welcome to follow any idiotic path of
> > development they wish to.  They are not welcome to tell the rest of the
> > community to stuff it *and* shut up.  "Stuff it" is acceptable, but
> > that's a two-way street.  It's not a particularly rewarding journey.
> 
> I'm not sure what you mean by "stuff it" here.  

See above WRT Hankins, Spence, and Waugh, specifically.


> If you never use GNOME applications, the debate is irrelevant.  

As I've said repeatedly:  I use GNOME apps, *despite* their associations
with GNOME, for the most part.  And several of these apps have been
massively screwed over by GNOME decisions and functionality.


> If you want the people writing e.g. Pan or gnumeric to do things your
> way, they you need to come up with a concrete better design, and
> preferably working code.

I do what I can.  Largely that's specific bug reports detailing broken
behavior.  When these are responded with "we can't fix this because it's
all we can do to keep us with the curves GNOME current development is
throwing at us" (not a quote, but reading between the lines), I call
bullshit.



> > > It's strange and unfortunate to have GUI software that can only be
> > > configured through a text file, just as it would be s & u to have
> > > a daemon that could only be configured through a GUI.
> > 
> > There are happy mediums.  You're presenting a false dichotomy.
> > 
> > Two applications which spring to mind are w3m and WindowMaker.  While
> > neither may be mainstream or particularly Joe-sixpack oriented, both
> > have the following advantages:
> 
> OK, this sounds like the current best design for interactively
> configured Unix applications.  It's certainly a long way ahead of
> xrdb.
> 
> >   - They use plain-text, human editable configuration files.
> 
> XML is human editable, though not as easy as a simple line-based
> format.  emacs and vi understand XML, and at least it's a standard.

As Microsoft is exquisitely demonstrating, it's possible to create fully
obfuscated XML DTDs and formats.  I'll also note, again, that neither
you, Jeff, or Jason have tried to determine my Evolution weather or
headline settings.

XML offers the illusion of human-readability without actually delivering
the goods.



> >   - They have very intuitive, easy to use, configuration utilities.
> >     WMaker's is, in fact, GUI (WPrefs).  In the _specific_ case of a
> >     window manager, I find this acceptable.  For w3m, the 'o' key brings
> >     you to a menu-driven config screen, covering a wide range of useful
> >     options.  Noting Joey Hess's comment that preferences should be
> >     searchable, I'll note that standard vi search ("/expression", n, ?,
> >     etc.) works.  
> 
> Similarly, GNOME applications have configuration dialogs that are
> generally friendly and easily available.  Most people need never know
> gconf is under the bonnet.

We've been hearing this canard about the legacy MS Windows Registry for
a decade.  Unfortunately, GNOME is going to suffer the memetic pollution
of Microsoft's lies and abuses.  I don't trust registries.  Period.
I'm not the only one.  And yes, this means an uphill job selling the
damned things.

Secondly, a constant gripe with both GNOME and KDE is that I can't
consistently change, e.g.:  an application's font settings FROM WITHIN
THAT APPLICATION.   Example:  changing Gabber's default chat window
fonts.  No controls.  I suppose that's buried somewhere in a global
GNOME configuration....  Konqueror is similarly infuriating (I realize
Konq isn't a GNOME app, I'm simply indicating that the brain damage
isn't GNOME specific).


> Are you really saying that it is not acceptable for gui applications
> to have graphical configuration, only window managers?  That seems a
> bit wierd.

For fucks sake, Martin:

    PREFERENCES SHOULD BE ***FLEXIBLE***.  THIS MEANS OFFERING THE
    ***OPTION*** FOR ***BOTH*** GUI ***AND*** EDITOR BASED CHANGES TO
    CONFIGURATIONS.

If you're still having trouble grasping that, I'll type it again for
you, slowly.


> I agree that preferences should be searchable.  I love that in emacs.

Itself a marvel of ease of configurability....  <coff>


> >   - In both cases, copying a file (~/.w3m/config) or directory tree
> >     (~/GNUstep/) transfers all the appropriate settings between systems.
> >     Preferences portability has always been a hallmark of 'Nix systems,
> >     and the loss of this under the current GNOME scheme is a very
> >     serious step backward.
> 
> Does this in fact not work with gconf?  It seems to work for me.  If
> not, file a bug.

Simply put, it's not clear which of several settings / file trees is
necessary for an application's configurations to be moved:

  - .Gabber/
  - .Gabber-spool/
  - .gnome/gabber  
  - .gnome/Gabber  
  - .gnome_private/Gabber
  - Other files under .gnome or .gnome-private
  - Other files under .gnome2 or .gnome2-private
  - .gconf/
  - .gconfd/
  - Various /etc trees.
  - Other unspecified locations, schemas, libraries, etc.

...vs:  .<application>/


> Here are some problems with w3m, from brief experimentation.  They're
> typical of this kind of approach where you just read and write a
> configuration file.

First:  I was indicating things that w3m does right.  I'm not saying
it's a perfect solution.  I *AM* saying that it achieves a good balance
of menu-driven and hand-editable configurations.


>  - Syntax errors in the configuration file are silently ignored.

This can be fixed at the application level _or_ through standard
libraries to achieve a broader fix.  It's an implementation bug, not a
fatal flaw.


>  - If I change an option in one instance, it is not propagated to the
>    others until I quit and restart them, losing some state.

The changes _are_ updated for the current instance of w3m if modified
from within the session.  Given that w3m is a single session per
instance app, the state loss for closing a single instance is low.
While I'm known to run multiple w3m sessions, the state issue isn't a
huge one.

Still, if this is a sufficiently major issue, it can be addressed, as
above, at the application or library level.


>  - If I save the options from one instance, the changes overwrite each
>    other.  In particular my persistent browser history is lost -- we
>    are losing (slightly) valuable user data.


Can be addressed at application or library level.

>  - OK, I can edit the configuration file by hand, but I need to
>    restart the program to make my changes take effect.


Can be addressed at application or library level.

>  - There is no consistency between applications; I have to adjust my
>    color preferences through a different mechanism in links, w3m, tin,
>    and mutt.  For applications of this vintage this is expected but for 
>    modern GUIs it's lame.

Well, w3m *is* a console-based (mostly, I'm excepting w3m-img) app.  I
don't see why it's not legitimate for application to specify local
preferences for color, font, etc., overriding global defaults.  This is
intrinsic in xrdb.



> gconf fixes, or mostly fixes, these problems.  I think that is a
> reasonable tradeoff when the price is just using gconftool rather than
> an editor.

I disagree.

> > I don't believe anyone here is *mandating* use of editors on
> > configuration files.
> 
> I think this was in the context of xrdb, where editors are the only
> way.

xrdb has been posed as an example of a globally managed resources
system.  Again, you're misreading the "here's a tool which does some of
the functionality you're ascribing to gconf" as "we demand a rigid
reimplementation of xrdb".  We're not.  We are calling your bluff when
you say that gconf is the only way, however.

I'll also freely admit that xrdb resources are less than transparent,
inadequately documented, and beyond the grasp of most users _as a
directly modified configuration setting_.  There are, however, several
instances which come to mind of tools which programmatically modify xrdb
setting through preferences dialogs.

Presentation of xrdb, w3m, and other examples is on the basis that there
ideas worth harvesting.  Not that they should be slavishly copied --
stop presenting them as such.


> > What I am *requesting* and *strongly recommending* is that
> > configuration files follow conventions of location (so you can find
> > the damned things), 
> 
> Looking under ~/.gconf/ does not seem incredibly onerous.

See above.  Note too that this *isn't* a standard for applications in
the past.

I'll include my .gconf* trees below.

> > and be both comprehensible and modifiable by a reasonably
> > technical user.
> 
> Well, I suppose I just think that a reasonably technical user can
> learn to use gconftool.  It is not that hard, especially given that
> you can use that knowledge across many applications, and it avoids the
> need to work out the syntax for every single application.

If you're going to realisticly suggest this for us "old farts", as well
as hapless admins repairing user files over remote ssh links, gconftool
will have to provide a sufficiently meaningful manpage.  Info is not
acceptable for reasons stated in the previously posted Info vs. Man
rant.  Suitable introductory docs for the /usr/share/doc/gconf and/or
GNOME system, 

    *** INCLUDING INSTRUCTIONS FOR USERS ON HOW TO ACCESS AND      ***
    *** CHANGE SETTINGS, WHICH ARE SPECIFICALLY MISSING FROM THE   ***
    *** WEB PAGES YOU POSTED EARLIER IN THIS DISCUSSION            ***

...are necessary.


Peace.


--------------------

And for everyone's edification, here's that oh-so-accessible .gconf*
tree.  Note that there are 55 files for three GNOME apps....

Why does this remind me of qmail....


.gconf
|-- %gconf-xml-backend.lock
|   `-- ior
|-- %gconf.xml
|-- apps
|   |-- %gconf.xml
|   |-- galeon
|   |   |-- %gconf.xml
|   |   |-- Advanced
|   |   |   |-- %gconf.xml
|   |   |   |-- Crash
|   |   |   |   `-- %gconf.xml
|   |   |   |-- Filtering
|   |   |   |   `-- %gconf.xml
|   |   |   |-- Network
|   |   |   |   `-- %gconf.xml
|   |   |   |-- Persistent
|   |   |   |   `-- %gconf.xml
|   |   |   `-- Security
|   |   |       `-- %gconf.xml
|   |   |-- Browsing
|   |   |   |-- %gconf.xml
|   |   |   |-- Find
|   |   |   |   `-- %gconf.xml
|   |   |   |-- General
|   |   |   |   `-- %gconf.xml
|   |   |   `-- History
|   |   |       |-- %gconf.xml
|   |   |       `-- Session
|   |   |           `-- %gconf.xml
|   |   |-- Handlers
|   |   |   |-- %gconf.xml
|   |   |   |-- Downloading
|   |   |   |   `-- %gconf.xml
|   |   |   |-- Help
|   |   |   |   `-- %gconf.xml
|   |   |   `-- Programs
|   |   |       `-- %gconf.xml
|   |   |-- Print
|   |   |   `-- %gconf.xml
|   |   |-- Rendering
|   |   |   |-- %gconf.xml
|   |   |   |-- FontsColors
|   |   |   |   `-- %gconf.xml
|   |   |   `-- Language
|   |   |       `-- %gconf.xml
|   |   |-- State
|   |   |   |-- %gconf.xml
|   |   |   |-- PageInfo
|   |   |   |   `-- %gconf.xml
|   |   |   |-- SmartBookmarks
|   |   |   |   |-- %gconf.xml
|   |   |   |   |-- EntrySize
|   |   |   |   |   `-- %gconf.xml
|   |   |   |   `-- Visibility
|   |   |   |       `-- %gconf.xml
|   |   |   |-- bookmarks_editor
|   |   |   |   `-- %gconf.xml
|   |   |   |-- history
|   |   |   |   `-- %gconf.xml
|   |   |   |-- history_dock
|   |   |   |   `-- %gconf.xml
|   |   |   |-- js_console
|   |   |   |   `-- %gconf.xml
|   |   |   |-- page_info_css
|   |   |   |   `-- %gconf.xml
|   |   |   |-- page_info_forms
|   |   |   |   `-- %gconf.xml
|   |   |   |-- page_info_images
|   |   |   |   `-- %gconf.xml
|   |   |   |-- page_info_links
|   |   |   |   `-- %gconf.xml
|   |   |   `-- prefs_dialog
|   |   |       `-- %gconf.xml
|   |   `-- UI
|   |       |-- %gconf.xml
|   |       |-- Mouse
|   |       |   `-- %gconf.xml
|   |       |-- Tabs
|   |       |   `-- %gconf.xml
|   |       `-- Toolbar
|   |           `-- %gconf.xml
|   |-- gconf-editor
|   |   |-- %gconf.xml
|   |   `-- dialog-settings
|   |       `-- %gconf.xml
|   `-- gnumeric
|       |-- %gconf.xml
|       |-- core
|       |   |-- %gconf.xml
|       |   `-- file
|       |       |-- %gconf.xml
|       |       `-- history
|       |           `-- %gconf.xml
|       `-- plugins
|           `-- %gconf.xml
`-- desktop
    |-- %gconf.xml
    `-- gnome
        |-- %gconf.xml
        `-- applications
            |-- %gconf.xml
            |-- help_viewer
            |   `-- %gconf.xml
            `-- terminal
                `-- %gconf.xml
.gconfd
|-- lock
|   `-- ior
`-- saved_state

53 directories, 55 files


-- 
Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Bush/Cheney '04: Deja-voodoo all over again!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20031008/46c47b8c/attachment.pgp 


More information about the linux-elitists mailing list