Re: Regarding the ULTRIX and OSF1 compats

    Date:        Sat, 16 Mar 2019 16:53:16 +0100
    From:        Maxime Villard <max=40m00nbsd.net>
    Message-ID:  <7acc19dd-9f66-f825-d517-6e7013de1bd5=40m00nbsd.net>


  =7C   a) Yes the bug was in COMPAT_ULTRIX, which was found recently to =
have been
  =7C      used by _one_ person,

One that we know of.   Where there's one, (just like bugs) there's
almost certainly more.

  =7C   b) All of the removals done so far were after discussions and agr=
eements.
  =7C      You just can't say that =22you believe it is not used...=22, w=
hen I _did_
  =7C      systematically bring up discussions.

Yes, I am aware of that.

  =7C      And no, you can't say either that
  =7C      =22uh but what if people don't subscribe to mailing lists?=22;=


But I can, and I did - read my earlier message if you believe that
was impossible.

  =7C      if they don't subscribe, it's their problem,

Really?   Is that the same attitude you have everywhere?   If your
local council (or whatever the equivalent is in France) closes your stree=
t,
and when you object says =22we sent a request on our mailing list, no-one=

objected, and it is too late now, it is done=22 do you think you are to
blame because you're not on their mailing list?    Or if any other
prodct that you use (and NetBSD is a product) changes after sending
an announcement and request for objections to their mailing list?

How many mailing lists are you on, and do you really read every message o=
n
all of them?   How would you ever get anything real done?

No-one is obliged to be on any NetBSD mailing list, and nor should
anyone be =22punished=22 for not being on one.

Further, for these issues, it is exactly the people who are least likely
to bo on the lists that are most likely to be affected.

  =7C   d) =22Unspecified bugs=22 that's completely wrong, many were show=
n in DEFCON,
  =7C      I brought examples myself all along. Totally wrong.

In where?    Once again, if the bug is not in a PR, it is irrelevant.

  =7C   e) =22Tedious process=22 Yes, what you're talking about is a very=
 tedious
  =7C      process, that will take literally _decades_

Slowish, yes, but decades (plural)??   Be reasonable.   2 decades ago
NetBSD was on version 1.6 or something about there (maybe 2).  (Actually
in April 1999 we switched to 1.4A, ie: 1.4 was released, 1.4.1 in July)

Our releases are slow, but not that slow.   Hyperbole doesn't help.

In 2010 (less than 1 decade ago) 5.1 was released, -6 was branched
early in 2012, and released in Oct 2012.   Assuming we get to 9.0 by
October this year, that would be 7 years for 3 major releases (and
that includes a couple of the slowest ones ever.)

That is not =22literally decades=22.   It isn't even metaphorically decad=
es.

  =7C before we move forward and drop code that by that time, may not
  =7C even compile properly because GCC support is gone.

For anything that gcc supports now, or for that matter, even in the past,=

that's not possible, as the old compiler can still be used.   There
might be some issues, but they can be handled, if needed.

As others have said, NetBSD will never compete at being the flashiest
newest, ... we simply don't have the manpower for that.  But we can be
the system which runs on anything (including the stuff everyone else has
given up on supporting) and on which anything runs (including ancient old=

binaries.)   That gives us something to offer than the other (free
systems) do not have.   Many of the commercial systems - though not all -=

recognise the need for backward compat ... even Windows still runs ancien=
t
dos applications.

kre