Re: Old gconf keys (was: Tab width)

Ok, I haven't read the beginning of this thread at all, but I think I'm
guessing what this is all about.
If the debate is .ini files vs gconf, then I only have 1 simple
question: given that it's possible to write alternative config storage
backends for gconf (ie write a backend that doesn't use a deep directory
hierarchy and xml files), if gconf way of doing things is so bad, why
did no one write a backend using .ini files ? Such a backend would be
vastly superior to the existing one from what I understand, so it should
be easy to prove it to the world and make distro use it as the default
backend, wouldn't it ?

Sorry if the debate isn't about that ;)

Cheers, 

Christophe

Le jeudi 24 mars 2005 à 07:02 -0800, Karsten M. Self a écrit :
> 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.
> 




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click