Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!EU.net!ieunet!news.ieunet.ie!jkh
From: jkh@whisker.hubbard.ie (Jordan K. Hubbard)
Newsgroups: comp.os.386bsd.development
Subject: Re: Request to ``ports'' developers
Date: 29 May 1994 13:11:35 GMT
Organization: Jordan Hubbard
Lines: 80
Distribution: world
Message-ID: <JKH.94May29131135@whisker.hubbard.ie>
References: <2s291q$pnl@meatball.rwwa.com> <2s37a4$mp9@pdq.coe.montana.edu>
<VIXIE.94May27220527@office.home.vix.com> <hm.770154713@hcswork>
<VIXIE.94May28221230@office.home.vix.com>
<JKH.94May29085921@whisker.hubbard.ie>
<VIXIE.94May29041924@office.home.vix.com>
NNTP-Posting-Host: whisker.hubbard.ie
In-reply-to: vixie@vix.com's message of 29 May 94 04:19:24
In article <VIXIE.94May29041924@office.home.vix.com> vixie@vix.com (Paul A Vixie) writes:
> "That's how it is, Jordan."
>
> Systems _do_ evolve. Version N of an operating system or library or
> whatever will have fewer features than Version N+1 but more than Version
> N-1. When I write code for these systems I have the choice of coding for
> the least common denominator, which often results in a suboptimal program
> that doesn't take good advantage of a system's recent improvements, or
> putting in some #ifdef's which often results in an unreadable and
> unmaintainable and generally gateful program text.
I think you missed my basic point. *I* know that, and *you* know
that, but just how the heck is Joe Blow supposed to know that? Or,
for that matter, just how are we supposed to even *remember* such
things 5 or even 3 years from now? There is truly no easily
accessible roadmap to follow that's going to give someone who hasn't
been intimately coupled with the BSD effort (and say what you like,
not all of us can or even should be) the ability to say that 9303
means one particular set of things and 9201 means another. Certainly,
you who know such things can write your code just fine to
conditionally adapt to the various incarnations, and you may even
strenuously defend the practice since it gives you a potentially high
degree of granularity to work with in determining just what features
you can rely on, but it fails the acceptance test in 2 critical (IMHO)
areas:
1. It gives the user who is trying to use your code for reference
absolutely no idea _why_ it is you're doing what you're doing.
Sure, they can sort of intuit that 9301 must have been something
special in the tty code department if they see lots of termios
features #ifdef'd to it, but they can't really be sure to exactly
what extent those features were implemented at that time.
It can scarcely be argued that `HAVE_TERMIOS' is a far superior
and more descriptive option flag than `#if BSD >= 9212', and to
my mind actively encouraging people to use this BSD hook just
discourages the more self-documenting feature specific macros
that CSRG really ought to have been providing in the first place.
I know you can't change the past, but now wouldn't have been a bad
time to start worrying about the future.
2. It encourages the user to think in entirely the wrong way.
The chronology of an OS is important to its maintainers and
those close to the action, but basically irrelevant to anyone
else. If the user twigs onto some special bit of behavior in a
commercial product, they do it either by version number
("Lotus 1-2-3 version 4.0") or by feature ("Windows for
Workgroups"). They don't do it by date, and considering the
variable lag times between development and general release, such
dates wouldn't have a lot of meaning anyway.
> But I sure would like it if ULTRIX was defined as a datecoded macro in
> <sys/param.h>, since that way BIND and my other software systems could make
> compile-time decisions about which kernel bugs to work around, rather than
> testing for the existence of macros which I knew (because I worked at DEC
> at the time) weren't in some older version of the system. Talk about your
> counter-intuitive software.
You do make a reasonable point in saying that a datecoded ULTRIX would
allow you to work around kernel bugs with specific #ifdefs, the
assumption being that the maintainers of ULTRIX probably didn't know
about those bugs at the time of release and therefore were hardly able
to give you handy `SIGMASK_SAVE_ON_LONGJMP_BROKEN' types of defines in
sys/param.h, but would not a version number give you much the same
thing? For each release of the OS there's going to be some version
and point release number, and that number DOES at least have the
advantage of being written on the fronts of enough manuals and other
supporting documentation to be fairly visible to the user. It's also
a lot easier to pass along oral history in the form of "avoid versions
2.1 or 2.2, they were both full of mice" than "april 3rd and may 22nd
were pretty bad days!"
Doesn't look like we're going to agree on this one, Paul, but then it
wouldn't be the first time.. :-)
Jordan
--
Jordan K. Hubbard FreeBSD core team Friend to mollusks