Status of gconf -> dconf

Wed Feb 25 22:31:01 UTC 2009

On Tue, Feb 24, 2009 at 10:14:25AM -0500, seth vidal wrote:
> On Tue, 2009-02-24 at 09:23 -0500, Simo Sorce wrote:
> 
> > oh but it has, ever tried to do locking on nfsv2/3 ? No? Wonder why most
> > apps have been working around proper locking inventing abominations like
> > lockfiles and other 1000 non standard and all incompatible ways to mange
> > locking because it was always broken on NFS ? To the point that now 99%
> > of unix apps don't even acknowledge nor test for locks on files and die
> > hard is locks are mandatory or just completely ignore them if they are
> > advisory (making advisory locking almost useless).
> 
> let's not chase off down solely the nfsv2/v3 path. There is also afs
> (which is still deeply entrenched in a number of big .edus, for better
> or worse) and you may be able to speak to this best but istr cifs-linux
> didn't play all that nicely on samba v3 and sqlite.

Agreed.  I'm not the only one here that supports home directories in
AFS.  No locking, no inotify.  There are things that AFS really sucks
at, there are things that AFS does best.  That's why its still common.

Also, centralized database daemons wont work trivially with AFS where
the server doesn't store files in a readable format and where a users
files can move from server to server depending on any number of issues.

Jack Neely

> 
> 
> > > When I started managing shared resource unix/linux systems a decade ago
> > > multiple logins to multiple desktops were running all the time. Hell, in
> > > many cases the end-user systems didn't even have local disks to speak
> > > of.
> > 
> > Yes, when I started a decade ago I had similar setups, I am *not*
> > advocating breaking networked home directories, but boy, we have to stop
> > making up systems that sucks only because people *insist* on using a
> > broken network filesystem.
> 
> Show me the fixed network filesystems, then. Making decisions based on
> theoretically deployable (but not really) fs seems like bad planning.
> 
> 
> 
> > > Somehow we managed with nfsv2.
> > 
> > yes, *somehow* I managed too and it was bitter hate. Isn't it time to
> > fix our stuff to work well and not "somehow" ?
> 
> Or maybe it's time to acknowledge that making apps which play with the
> existing systems is simpler than converting all the existing systems.
> 
> And it's not like apps breaking things in nfs is a new thing. When gconf
> was first introduced it made multiple, simultaneous logins impossible.
> 
> > It's not like we can't change protols today. Back then the NFS server
> > was an old Unix machine, with proprietary software we could not touch,
> > today we have Linux servers, I think we can fix stuff, and *surprise*,
> > we have NFSv4 and CIFS that do a *much* better job at serving out files
> > with decent semantics.
> 
> Does cifs-linux actually do that? Does it behave with sqlite? 
> 
> 
> 
> > > > NFSv4 and CIFS should be much better, is sqlite breaks on these
> > > > filesystems there are perhaps bugs in their client kernel components.
> > > 
> > > > It would be better to fix the FSs rather then just ditch the problem
> > > > completely.
> > > 
> > > It might be worthwhile to ask what the features are we're getting out of
> > > moving things to sqlite, for example, before deciding that there is a
> > > problem to be fixed at all.
> > 
> > As you well know some apps will use (and do use, like Firefox,
> > evolution, ..) sqlite already, it's late to ask if it is good or not,
> > its time to fix whatever need fixing if they do not work with
> > NFSv4/CIFS.
> 
> 
> I don't think it's too late to put the genie back in that bottle, or
> alternatively, to change where genie stores its frelling sqlite files.
> Tmp spaces are not unthinkable and last-in-wins behavior for multiple
> logins.
> 
> 
> > > The foregone conclusion seems to be that we have to add data-rich
> > > features. I don't think that's a good given.
> > 
> > Make a better proposal, but just screaming: "this breaks on broken
> > NFSv3!!" does not seem like anything useful to me, sorry.
> 
> Why is it unreasonable to ask that client applications not attempt to do
> things outside of the capabilities of the server?
> 
> Q. Doctor, Doctor, it hurts when I do this!
> A. Then don't do this.
> 
>  
> > Sure, there are requirements to be met, you think I'd advocate for
> > broken daemons after ranting about broken filesystems ?
> > However they do not need to be more fault tolerant than current
> > filesystems where you put your home on.
> 
> Show me a daemon that is as fault tolerant as filesystem daemons AND
> handles the authN/authZ like a filesystem does. Any daemon, please.
> 
> 
> > > We need to NOT lock out one set of users for another set of users.
> > 
> > No, we should not, in either direction.
> 
> Except I'm not asking for anyone to be locked out - I'm asking for app
> developers to not get locked into this world view of "well if it works
> on my laptop then surely it'll work everyone else, everywhere."
> 
> Sqlite in firefox is fine - but it's far from a requirement to use the
> web. Make the sqlite use optional, make the destination dirs deal with
> tmpfiles.
> 
> There are a ton of reasons why relying on local-drive semantics are
> doomed - I mean look at expiring kerberos tickets as another reason.
> Something that never happens on local-drive logins is that the user's
> rights to access their homedir suddenly and completely go away. Having
> the system even barely remain functional isn't an unreasonable request.
> 
> 
> -sv
> 
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
Jack Neely <jjneely at ncsu.edu>
Linux Czar, OIT Campus Linux Services
Office of Information Technology, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89