Re: Old gconf keys (was: Tab width)

on Thu, Mar 24, 2005 at 09:20:12AM -0500, Adam Hooper ([email protected]) wrote:
> On Thu, 2005-24-03 at 04:29 -0800, Karsten M. Self wrote:
> >   - How do you prevent one application from modifying another app's
> >     keys?  Don't think everything's going to play nice, particularly as
> >     commercial apps start using GNOME infrastructure.  Does gconf have
> >     an internal security model?  That accounts for different actions
> >     _within a single user context_ being untrusted?
> 
> Whereas modifying another app's dot-file is impossible?
> 
> I've never had a problem with apps stepping on each other's toes
> (probably because I use good apps), but if an app were to do so it could
> do it just as easily with or without a registry.
> 
> >   - How do you manage shared key data (say:  proxy config data).
> 
> You put it in a standard location. GNOME already does this.

How do you resolve those conflicts.

Look to Debian (or Ubuntu) and use of -common packages.  OK.  Now how do
you enforce that?

I'm not saying there isn't a solution.  I am saying:

  - It doesn't fall out the sky.
  - It isn't self-enforcing.
 
> >   - How do you deal with apps parking obfuscated data in the registry?
> 
> As opposed to parking obfuscated data in dot-files?

Data that's meant to be modified by humans tends strongly to be
human-readable.  Sure, there are exceptions.  Sendmail.  Files which
request a delay...but neglect to mention measurement units.  I've seen
miliseconds, deciseconds, seconds, and minutes....

Once you automate and mediate all data access, it's easy to go
obfuscated (as Evo did), even if it's not an intentional decision.
 
> >   - How do you deal with bloat (old settings, stale settings).  Treating
> >     gconf as a write-only repository...leads to its own problems.
> >     Messing up the cleanup process also has its downsides.
> 
> There are *no* pitfalls when messing with GConf. Just do a "gconftool
> --dump" before and "gconftool --load" if you screw up. 

"Just do" or "require all automated accesses do"?

If you're going to design for atomic commits and rollback capability
(and versioning, why not go whole-hog), fine.  But don't put the onus on
the user.  Aunt Tillie ain't gonna do it, and her nephew Joey won't
remember reliably.

> You can do it while the app is still running and nothing will go
> wrong. And I already posted an example of how one could write a
> trivial script to clean up stale settings.

Guaranteed?

See atomic and rollback capabilities.

 
> >   - How do you trivially make before-after comparisons, to see what an
> >     installation or config change have done?
> 
> "gconftool --dump" + "diff"
 
> >   - How do you clean up after something *does* eff-up a gconf file?
> 
> "gconftool --load"

From where?  Are you snapshotting the fiel continuously?  What's your
storage/processing overhead for this?
 
> Really, gconftool is great. Not only is gconftool great, but GConf uses
> an open and fairly simple API, so you can write your own program to do
> specific things to it.

Oh yeah, it rocks:

    $ man gconftool
    No manual entry for gconftool

Y'know, I *love* how GNOME goes _miles_ out of its way to smooth the
waters with us old-time farts who expect to find freakin' *man pages* in
our man pages.

Bug #108142, filed 09 Aug 2001.  Think we might have a manpage by 2009?

    
> > I'm not saying that gconf (and the Registry) don't have their benefits.
> > But there are some serious costs, many of these *are* common to both
> > gconf and the MS Windows Registry.  Naysaying doesn't make it otherwise.
> 
> Of the serious costs you've mentioned, none are serious and none are
> costs above and beyond those of dot-files.

I believe you've misunderestimated system complexity.

 
> I'd argue that even your "comments for a group of options" gripe could
> be easily solved by allowing documentation on GConf directories, which
> shouldn't be all that complicated.

Pardon?  How?  So I've got to edit two files to keep track of what's
what?  Why can't I edit-in-place within a single file?

 
> > > The problem is that Windows, with its shockingly poor
> > > implementation, has given the entire concept a bad name.
> > 
> > No:  the concept has some fundamental problems.  Microsoft embraced
> > the Registry in no small part because it's a vast pit of confusion
> > from which Microsoft could establish and extend its criminal
> > monopoly abuse.
> 
> As much as we all hate Microsoft, there comes a point when conspiracy
> theory has to be thrown aside. They thought it would be good, and it
> sucked.

You don't know Microsoft like I know Microsoft.  Spend a decade or so
reading legal docs, Findings of Facts, subpoenaed emails, and the like.
There's a nice start here:

    http://www.maxframe.com/DR/Info/fullstory/factstat.html

Gems like:

    You never sent me a response on the question of what things an app
    would do that would make it run with MSDOS and not run DR-DOS. Is
    there any version check or api they fail to have? Is there [a]
    feature they have that might get in our way? I am not looking for
    something they cant get around.  I am looking for something their
    current binary fails on.
    - Bill Gates, September 22, 1988, building better software.

    It only takes a couple of reports about non-compatibility to give the kiss
    of death to a PC: we've seen that on the hardware side as well as in the
    operating system area.
    - Jeremy Butler, Microsoft Corp. September 22, 1989

    This really isn't that hard. If you're going to kill someone there
    isn't much reason to get all worked up about it and angry -- you
    just pull the trigger. 
    - Jim Allchin, Microsoft Corp., Sept 18, 1993.  Business as usual.

You really think these people have changed?  They're still there, Butler
excepted.  And those quotes are from case documents.


 
> I'd go as far as to say there are no *fundamental* problems with GConf
> above and beyond the fundamental problems of a hierarchical filesystem.
> There may be missing features -- it's still only a few years old, after
> all -- but they're solvable.

And dotfiles have shaken out the bugs for three decades.  Gee, now
_that_ can't be any good, toss it out.  Wouldn't do to have any tried
and true technology around.

 
> But GConf *does* solve two nearly-fundamental problems with dot-files:
> 
> 1. Each one uses a separate syntax.

Really?  Most are pair-assignment, with some minor variations in theme.
Knowing the valid settings and their values is the hard part.  There's a
few variants, but that covers most of 'em.

> 2. Editing the dot-file doesn't modify the behaviour of
> already-running applications.

Samba much?  File-watching isn't *that* hard to implement.

I'd suggest you look into that leasing arrangement, it's a real win for
you.

 
> ...both of those problems *could* be solved, but it's not going to
> happen.

Um.  I guess in the sense of "if it's already happened, then it can't
happen for a first time again", sure.
 


Peace.

-- 
Karsten M. Self <[email protected]>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Bush:  All we have to sell is fear itself.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCQtZ3efG8443k044RAnDyAJ98JlCX5lbKO8OOABAeB91A648qwgCeJOgC
gSucAz7Bb6GmbUcGJC+d33w=
=J29u
-----END PGP SIGNATURE-----