On 17 Jun 2010, at 21:40, Russ Allbery wrote: > > There is that. I intend to ship with DAFS enabled for Debian, but the > Debian packages have always taken a fairly aggressive approach to enabling > features. (They have had supergroups enabled for quite some time, for > example, and also enable UNIX domain sockets for fssync, and I intend to > enable disconnected as well.)
This is one of the many problems with having too many knobs that can be twiddled. There is no longer "OpenAFS" - you end up with "Debian's build of OpenAFS" which behaves in a completely different way to "the RPMS on the OpenAFS website", which use completely different paths from "the RPMFusion RPMS", which behave differently again to "the Solaris tarball" and so on. If you're a new user to OpenAFS, how on earth do you work out which set of settings you should be using? Do you know that you're using the Demand Attach Fileserver, or whether your package is build with Transarc paths, or what the difference between inode and namei is? At some point, you'll just give up in disgust. I'd really like us to standardise on a _small_ (ideally one) set of supported configurations which we suggest for each release - and for the binary packages that we point users at to use that set of configurations across all platforms. It's the only way that we're ever going to manage to produce a coherent documentation set, to provide meaningful advice on lists and in chatrooms, and in general, retain our sanity. If we believe the demand attach is ready then, IMO, it shouldn't be hidden behind a configuration switch. If it is, I doubt it will see much more use than it does at present. My current feeling is that it would be great if we could ship both fileservers, side by side, with different executable names - but I haven't looked at any of the code to see how complex this would be to achieve. Cheers, Simon. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
