Subject: Re: utmp file format change
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 09/21/2001 03:18:22
[ On Friday, September 21, 2001 at 16:54:04 (+1000), Simon Burge wrote: ]
> Subject: Re: utmp file format change
> Greg A. Woods wrote:
> > I'm not so sure the Solaris solution is anywhere near ideal. It has
> > numerous twisted bass-ackwards quirks due to their insane desire to give
> > 100% backward binary run-time compatabilty of the on-disk data.
> This is a goal for NetBSD too.
I really truly sincerely hope it is not. (note I said run-time compat)
Do we really have to "fork the code" with every major release just so we
can make some long-term forward progress?
Binary compatability, especially on this scope, is only for proprietary
vendors and has no place as a goal with a freeware system that offers
open source code as a primary goal.
The most anyone should ever ask for in any open-source environment are
the conversion tools necessary to assist in migration.
> Perhaps someone has a binary-only
> program that scribbles wtmp entries, and they can't upgrade the program
> for whatever reason.
The only programs in that category that I care about -- and indeed that
anyone using NetBSD should ever care about -- are programs that run
under some binary emulation.
In all of those case it's trivial to arrange for a bogus
/emul/foo/etc/utmp file to be used and to be done with it.
If someone's really desperate for a merged solution then they can port
one of the already available utmp updater daemons to work with NetBSD.
> We don't want to tell them "you can use any
> version of NetBSD up to version Foo, after that tough luck because we
> made a gratuitous file format change without bothering to put any amount
> of thought into backwards compatibility."
I actually do want to say things like that -- at least any time the
programs in question are available in source form.
One of the primary reasons I came to like "open" source "freeware" (long
long before NetBSD!) was because it meant I didn't have to do twisted
bass-ackwards stupid things just because I couldn't change some program
to deal with a new interface.
If third-party NetBSD vendors (eg. wasabisystems.com) wish to maintain
binary utmp compatability then they don't have to pull in any changes to
their repositories that would break it! ;-)
In this particular case though, i.e. w.r.t. utmp/wtmp, these issues have
already been discussed and debated seveal times. Though my prejudice
may have swayed my interpretation, I felt the consensus each time was to
forget about backwards compatability and to simply offer conversion
tools for forward migration. After all we're not talking about anything
really critical here (such as binary object code and executable formats).
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>