>>>> NFSv4 and GSS may help resolve the group problem but it does come >>>> at the expense of performance. >>> Primarily, it comes at the expense of abandoning NetBSD, doesn't it? >> That is just a simple matter of programming. > This is a matter of where the valuable programming time goes, to make > it easier to use the old protocol versions, or to be able to use NFS > with a sound security model.
If programmer time were fungible, that would be true (or at least vaguely close; the amount of effort, and skill required, may not be equal for the two tasks). It isn't. Even in paid programming jobs, it isn't really; see Fred Brooks's _The Mythical Man-Month_. In a volunteer project like NetBSD it's not even anywhere close to true: what gets done is what people feel like working on. Whether the results are important to anyone is relevant only insofar as it influences what people choose to work on. (Actually, it's not quite that simple; there are (a comparatively few) people who actually get paid to hack on NetBSD, in which case "you do what you're paid to" comes back to an extent.) > As soon as you need security, the performance of v3 becomes > irrelevant. Unless your threat model is such that you can get that security through infrastructure instead of NFS version choice/config, in which case it becomes a choice. (For example, I once ran `insecure' NFS over the open Internet...with security provided by what amounted to a VPN.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
