On Sat, 12 Feb 2022, Benjamin Coddington wrote: > On 11 Feb 2022, at 15:51, Chuck Lever III wrote: > > >> On Feb 11, 2022, at 3:16 PM, Benjamin Coddington > >> <bcodding@xxxxxxxxxx> wrote: > >> > >> On 11 Feb 2022, at 15:00, Chuck Lever III wrote: > >> > >>>> On Feb 11, 2022, at 2:30 PM, Benjamin Coddington > >>>> <bcodding@xxxxxxxxxx> wrote: > >>>> > >>>> All the arguments for exacting tolerances on how it should be named > >>>> apply > >>>> equally well to anything that implies its output will be used for > >>>> nfs client > >>>> ids, or host ids. > >>> > >>> I completely disagree with this assessment. > >> > >> But how, and in what way? The tool just generates uuids, and spits > >> them > >> out, or it spits out whatever's in the file you specify, up to 64 > >> chars. If > >> we can't have uuid in the name, how can we have NFS or machine-id or > >> host-id? > > > > We don't have a tool called "string" to get and set the DNS name of > > the local host. It's called "hostname". > > > > The purpose of the proposed tool is to persist a unique string to be > > used as part of an NFS client ID. I would like to name the tool based > > on that purpose, not based on the way the content of the persistent > > file happens to be arranged some of the time. > > > > When the tool generates the string, it just happens to be a UUID. It > > doesn't have to be. The tool could generate a digest of the boot time > > or the current time. In fact, one of those is usually part of certain > > types of a UUID anyway. The fact that it is a UUID is totally not > > relevant. We happen to use a UUID because it has certain global > > uniqueness properties. (By the way, perhaps the man page could mention > > that global uniqueness is important for this identifier. Anything with > > similar guaranteed global uniqueness could be used). > > > > You keep admitting that the tool can output something that isn't a > > UUID. Doesn't that make my argument for me: that the tool doesn't > > generate a UUID, it manages a persistent host identifier. Just like > > "hostname." Therefore "nfshostid". I really don't see how nfshostid > > is just as miserable as nfsuuid -- hence, I completely disagree > > that "all arguments ... apply equally well". > > Yes - your arguement is a good one. I wasn't clear enough admitting > you > were right two emails ago, sorry about that. > > However, I still feel the same argument applied to "nfshostid" > disqualifies > it as well. It doesn't output the nfshostid. That, if it even contains > the > part outputted, is more than what's written out. > > In my experience with linux tools, nfshostid sounds like something I can > use > to set or retrieve the identifier for an NFS host, and this little tool > does > not do that. > I agree. This tool primarily does 1 thing - it sets a string which will be the uniquifier using the the client_owner4. So I think the word "set" should appear in the name. I also think the name should start "nfs". I don't much care whether it is nfssetid nfs-set-uuid nfssetowner nfssetuniquifier nfssetidentity nfsidset though perhaps I'd prefer nfs=set=id If not given any args, it should probably print a usage message rather than perform a default action, to reduce the number of holes in feet. .... Naming - THE hard problem of computer engineering .... NeilBrown
