On 30 Jul, 2013, at 09:21 , Christos Zoulas <christos%astron.com@localhost> wrote: > In article <2dfe3cdfcd48d7abaaaec6f06925afcf%mail.marples.name@localhost>, > Roy Marples <roy%marples.name@localhost> wrote: >> On 29/07/2013 18:15, Alan Barrett wrote: >>> New features that are likely to be controversial should be discussed >>> before being implemented. >> >> I don't view these changes as controversial hence I just did it. If you >> look at my prior posting history I always launch discussion, often with >> a patch, prior do doing something I consider controversial. >> >>> Even after implementing the changes, you >>> still have not seen fit to esplain what the new options are supposed >>> to be used for, under what circumstances they might be useful, what >>> problem they are intended to solve, or even what their semantics are. >>> >>>> So if someone doesn't like it with a CVS commit bit, feel free to rip >>>> it out and I'll keep my changes local. >>> >>> Since you are not even willing to explain why you made the changes, I >>> think thay should immediately be reverted. >> >> It seems that you can neither read, or you are just willfully ignoring >> my explanation. >> >> I fail to see why I should justify myself when others frankly just state >> their opinion with none or limited technical merits. >> How the hell is their opinion worth any more than mine? Not saying mine >> is worth more, but from where I am now it says my view is worth squat. >> >> Maybe it's time for me to step away from NetBSD. > > There is a simple solution to all of this. Provide a separate command called > nodename or netname or something! I agree with this. While it is an extreme case, I've compiled operating system software to run on machines which can have thousands, or even ten's of thousands, of configured network interfaces. In the process of dealing with this it is normal to find that the existing utilities for dealing with interface configuration (and some network protocol software which does the same, like ntpd and bind) simply don't work, and that in fact the APIs they use for getting and setting information about interfaces were not designed with that size and complexity of configuration in mind. This is okay, though, you replace the APIs with something more appropriate (replacing the API is also a good way to identify all the software that probably isn't going to work anyway), rewrite the things you care about to use it and omit the things you can do without. It is the case, though, that most basic operating system utilities don't care at all about this and continue to be useful for what they do just the way they are. The thing is, though, that the string set by sethostname(3) and returned by gethostname(3) has no inherent relationship with anything related to networking; that's entirely up to you. It is just a string. It is useful because it gets attached to log files and shows up in shell and login prompts, reminding you of what you are talking to, but the string itself can be anything you find useful for those purposes. It doesn't have to be anything in particular unless you want or need it to be. I hence think that there should be a utility that provides a human and shell-script interface to sethostname(3) and gethostname(3) but does nothing beyond that, in the same way that a utility like date(1) should probably just deal with settimeofday()/gettimeofday() and the system timezone files and nothing else (e.g. I think a utility to set the time using ntp is a fine idea, but including it in date(1) isn't; the fact that date(1) had code to talk to timed was an original sin). I would hence prefer that hostname(1) just remain a human and shell script interface to sethostname()/gethostname(), and that it not show up on a list of things that need to be modified or rewritten because of the use an a network interface configuration API that needed to be replaced. The new functionality is fine, it just needs to go somewhere that doesn't take the basic interface to sethostname()/gethostname() with it in the odd case that the added functionality is somehow inappropriate or gets in the way. Making a separate utility with the new functionality allows everyone to have their cake and eat it too. Dennis Ferguson
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail