tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/bin/hostname

On 30 Jul, 2013, at 09:21 , Christos Zoulas <> 
> In article <>,
> Roy Marples  <> 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 
in mind.  This is okay, though, you replace the APIs with something more 
(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 
the things you can do without.  It is the case, though, that most basic 
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

Home | Main Index | Thread Index | Old Index