Re: Regarding the ULTRIX and OSF1 compats

--000000000000aeb3d005843a0761
Content-Type: text/plain; charset="UTF-8"

Picking a random message in this thread to respond to.

FreeBSD has struggled with deprecation as well (which is what this is).

I'm working on a doc to help there, but the basic criteria are:

1. What is the cost to keep it. Include the API change tax here.
2. What is the benefit the project gets from it. How many people use THING
and how much "good" do we get out of this.
3. Is the THING working for anything non-trivial?
4. Is there someone actively looking after THING?

It's basically nothing more than a cost-benefit analysis.

In the case of COMPAT_ULTRIX (which is not going away) you'd get:

1. Cost is low, though not zero. It's a thin veneer over stuff the system
would have anyway.
2. Some people are still running Ultrix binaries.
3. As far as has been reported, it's useful for non-trivial binaries.
4. Nobody is really looking after it, but there's enough use to generate
bug fixes.

So on the whole, there's some benefit at a modest cost to keeping a feature
that's basically working. Keep is a decent decision.

In the case of COMPAT_OSF (which some would like to be removed):

1. Cost is relatively high, as there's parts we'd not have in a normal
system (MACH features missing, must make API changes blind, no way to test)
2. Nobody has reported OSF binaries in recent memory, though some used it
years ago (it was quite important in the 90s for alpha bring up).
3. It's basically broken. Non-trivial binaries are impossible because of
the missing bits.
4. No one is looking after it.

Which is all negative: there's no benefit for something that's not known to
be working, and even if it was working it's incomplete for a user base of
zero with no maintainer. Add to that that since there's no good way to
test, the work to keep it compiling is make-work: it's a box to tick that
provides no benefit other than ticking the box.

Seems like a clear and compelling case to me, but my involvement with
NetBSD is too tangential for me to strongly advocate for that.

Anyway, my suggestion is that if there's this much contention for a
removal, I'd suggest coming up with a set of reasonable criteria people can
agree on that help focus the discussion on cost / benefit rather than some
of the more esoteric philosophical arguments I've seen in the thread which
feel good, but put a lot of work on others to generate that good feeling.

Warner

--000000000000aeb3d005843a0761
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Picking a random message in this thread to respond to.<div=
><br></div><div>FreeBSD has struggled with deprecation as well (which is wh=
at this is).</div><div><br></div><div>I&#39;m working on a doc to help ther=
e, but the basic criteria are:</div><div><br></div><div>1. What is the cost=
 to keep it. Include the API change tax here.</div><div>2. What is the bene=
fit the project gets from it. How many people use THING and how much &quot;=
good&quot; do we get out of this.</div><div>3. Is the THING working for any=
thing non-trivial?</div><div>4. Is there someone actively looking after THI=
NG?</div><div><br></div><div>It&#39;s basically nothing more than a cost-be=
nefit analysis.</div><div><br></div><div>In the case of COMPAT_ULTRIX (whic=
h is not going away) you&#39;d get:</div><div><br></div><div>1. Cost is low=
, though not zero. It&#39;s a thin veneer over stuff the system would have =
anyway.</div><div>2. Some people are still running Ultrix binaries.</div><d=
iv>3. As far as has been reported, it&#39;s useful for non-trivial binaries=
.</div><div>4. Nobody is really looking after it, but there&#39;s enough us=
e to generate bug fixes.</div><div><br></div><div>So on the whole, there&#3=
9;s some benefit at a modest cost to keeping a feature that&#39;s basically=
 working. Keep is a decent decision.</div><div><br></div><div>In the case o=
f COMPAT_OSF (which some would like to be removed):</div><div><br></div><di=
v>1. Cost is relatively high, as there&#39;s parts we&#39;d not have in a n=
ormal system (MACH features missing, must make API changes blind, no way to=
 test)</div><div>2. Nobody has reported OSF binaries in recent memory, thou=
gh some used it years ago (it was quite important in the 90s for alpha brin=
g up).</div><div>3. It&#39;s basically broken. Non-trivial binaries are imp=
ossible because of the missing bits.</div><div>4. No one is looking after i=
t.</div><div><br></div><div>Which is all negative: there&#39;s no benefit f=
or something that&#39;s not known to be working, and even if it was working=
 it&#39;s incomplete for a user base of zero with no maintainer. Add to tha=
t that since there&#39;s no good way to test, the work to keep it compiling=
 is make-work: it&#39;s a box to tick that provides no benefit other than t=
icking the box.</div><div><br></div><div>Seems like a clear and compelling =
case to me, but my involvement with NetBSD is too tangential for me to stro=
ngly advocate for that.</div><div><br></div><div>Anyway, my suggestion is t=
hat if there&#39;s this much contention for a removal, I&#39;d suggest comi=
ng up with a set of reasonable criteria people can agree on that help focus=
 the discussion on cost / benefit rather than some of the more esoteric phi=
losophical arguments I&#39;ve seen in the thread which feel good, but put a=
 lot of work on others to generate that good feeling.</div><div><br></div><=
div>Warner</div></div>

--000000000000aeb3d005843a0761--