>>> If you [change the binary format of utmp and wtmp], you break
>>> binary compatibility.

>> I have changed the format. All the tools that use it look at a
>> define for the length of the username.

> Well, all the tools to which you have the source.  But considering
> the number of popular software packages that are available on the net
> in Linux and BSDI formats but not NetBSD, I think that breaking
> binary compatibility is something that should not be undertaken
> lightly.

As regular readers of these lists may remember, I tend to be in favor
of things that make life difficult for binary-only code vendors.

Evangelical points of view aside, though, it does seem to me that if
you're going to break binary compatability anyway, you should do so in
an extensible way: redefine the file format so that it includes all
these lengths in the file, so that when someone wants usernames longer
than 16, or whatever, we don't have this situation happening again.
(Badly written code may still assume a given size, of course, but
there's no way to prevent badly written code from making boneheaded
assumptions like 8-char usernames...or 13-char hashed passwords, or
32-bit ints for that matter.)

Yeah, 16 characters seems like plenty for a username to me too.  But
I'd almost be willing to bet money that back when the current utmp
format was designed, nobody saw any need for more than 8 characters in
a username.  ("But that allows for 217,180,147,158 different usernames,
and that's even considering only lowercase letters!")  I am _not_
willing to bet anything at all that 16 will suffice for all time, nor
even for the expected lifetime of whatever the redesigned utmp file
format is.  Indeed, I would bet that it won't.  (I would be inclined to
accept single-byte lengths in the file, implying a hard limit of 255,
though I'd prefer two-byte lengths.)

Of course, none of this addresses the question of whether to break
binary compatability in the first place, or how to minimize the damage
if you do.  I'm only saying that _if_ you do, the only sensible thing
to do is to make things easy for yourself next time by ensuring that
there doesn't have to _be_ a next time.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
		    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D