[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Regarding the ULTRIX and OSF1 compats
Le 16/03/2019 à 16:12, Robert Elz a écrit :
Date: Sat, 16 Mar 2019 14:28:27 +0100
From: Maxime Villard <max%m00nbsd.net@localhost>
| Ok. So you believe that dead wood should hold back all of the development
No, but only if it truly is dead. Just because you don't see the
utility does not make it so.
| I believe you misread,
You're right, I did, I just skimmed the patch you made, and did not
look carefully enough. But the point is unchanged. There was a bug.
When it was reported it was fixed. That's what's supposed to happen,
and isn't evidence of anything being wrong.
| As I said, this is one example among others.
Yes, so you keep saying. But those others are in one of three
groups. Either they're like this one, and have now been fixed,
in which case they're irrelevant. Or they have been reported,
and no-one is fixing them (which can happen for many reasons) in
which case you should just supply the PR numbers for all of these
problems, that might stir some activity around some of them, or it
might not. Or you know of bugs that no-one else knows about, and
you're just sitting on. That would be all on you.
| And yes, this bug was introduced because the API was being replaced,
| and yes, the person who committed this code likely did all he could
| to make sure no bug was introduced, and yes, he did still add a bug
| because a certain number of these compat layers are dead wood that
| can't be tested, not even by those who claim they are so important.
But this one (the one above) is in code that is apparently not dead
wood, and that people do use. But that people use code does not mean
that every bug is going to be encountered - bugs often stay undetected for
a very long time, just because no-one happens to do whatever it takes
to trigger them.
| In fact, all of your "rules" were respected, yet the bug still inevitably
| came in. Why is that?
Because bugs happen. ALways have, always will. The only way to
avoid bugs in NetBSD would be to shut it down. Delete everything.
Then it would have no remaining bugs. It wouldn't be useful though.
But it would end this discussion!
| This is what happens with dead wood, you just don't want to face it.
But, apparently, COMPAT_ULTRIX isn't dead woood, and people still use it.
And that's what the one bug (now fixed bug) you have cited, that I have
seen, was in.
| And I'm not even speaking for myself, you just have to see the answers to
| "does anyone use compat_xxx". You can even try as hard as I did, with
| COMPAT_SVR4, ask on several different mailing lists, repeatedly, over and
| over. No one ever answers.
And most likely no-one ever will. You cannot get answers that way,
the people on our mailing lists mostly only care about this week's (or
this year's anyway) code, and wouldn't consider running anything that
didn't come from available sources.
But NetBSD (and all the other systems) are used by more people that that.
I know of several NetBSD users who would never go anywhere near any of
our mailing lists ... the closest they ever come is looking at the web
site from time to time to see if there's been a new release.
The only way to find out whether something is being used is to remove
it from the default config, but leave it relatively easy to turn back
on again (and ideally ask - where it is to be enabled - for anyone who
needs it, and enables it, to send e-mail to xxx%netbsd.org@localhost)
That was done with the removal of the ISA graphics card support (I mean,
who uses ancient PCs, new ones are cheap, and much better...) but then
it turned out that someone still did.
| If UVM was of questionable utility,
Everything is of questionable utility. We used to not have UVM
so we know it is possible to survive without it.
Note I am not questioning keeping that, just your certainty that you
know everything that is required, and useful, and that everything else
is "dead wood" and should be deleted.
| I stated my point clearly and logically, about why certain things have
| legitimate reasons to go away,
Sorry, I must have missed that. All I ever seem to see is that xxx is
unmaintained and full of unspecified bugs, and that obviously no-one cares,
and so we should delete it. That's not an argument for anything.
Also note I am not arguing for keeping anything in particular, just
against your reasons for deleting it. If some functionality really
is of no further use (and some of the drivers that were recently removed
seem to be in that category) then by all means, we should remove it.
But that you don't use it, and no-one on the mailing lists admits to
using it, does not mean no-one uses it. You need to move much more
I'd suggest perhaps for something that we believe might be of no further
use, then if it is userland, we just unlink it from the build, but leave
the sources in the tree, with a mk.conf option to cause it to be included,
and if it is kernel (like most of what you're concerned with) then we
just remove it from the default kernel config. And we do that for -9
(whatever is the next release after the issue is raised). Then if by the
time we're getting ready to release -11 (nb: not -10, not everyone updates
to every new release, and in fact waiting for -12 might be safer) - that is,
2 or 3 major releases after that first step, if no-one has complained, or
asked why it isn't (seemingly) available any more, we might delete the old
code. If there are questions/complaints, then we perhaps (in addition to
telling people how to restore the omitted functionality) restore it in
the next point release(s).
Yes, this makes it a long slow, and tedious process (involving a bunch of
additional work) to delete something - but so it should be. Someone spent
a lot of time making the thing you want to discard work in the first place.
I totally disagree with strictly all of what you just said.
a) Yes the bug was in COMPAT_ULTRIX, which was found recently to have been
used by _one_ person, in the past moreover. This doesn't change anything
to anything, it doesn't suddenly make COMPAT_ULTRIX maintained, or less
of a burden. It just shows that COMPAT_ULTRIX has reached the minimum of
the minimum threshold, by having had solely one user in the recent past,
and that's reason enough to keep it for now, as was agreed upon.
b) All of the removals done so far were after discussions and agreements.
You just can't say that "you believe it is not used...", when I _did_
systematically bring up discussions. And no, you can't say either that
"uh but what if people don't subscribe to mailing lists?"; if they don't
subscribe, it's their problem, what do you want me to tell you, cut the
crap one minute.
c) "You don't use it..." Yeah I don't use it, yet I still systematically
ask on mailing lists.
d) "Unspecified bugs" that's completely wrong, many were shown in DEFCON,
I brought examples myself all along. Totally wrong.
e) "Tedious process" Yes, what you're talking about is a very tedious process,
that will take literally _decades_ before we move forward and drop code
that by that time, may not even compile properly because GCC support is
I believe there is actually a strong cultural difference at play in e). To me,
I perceive what you said in e) as something totally awful and crappy, that
will dissuade every skilled developer from working on NetBSD because they can't
even remove code without waiting decades. We are in 2019, the earth is spinning
faster and faster, we must open doors and move forward, not be stuck in the
previous century with a ton of things we don't even maintain because, like it
or not, *no one wants to maintain them*. I find it absolutely filthy, even more
when the reason is "uh what if people are not subscribed to our lists". Really
awful, filthy, disgusting and backwards way of seeing things, that will
definitely sink NetBSD for good, by making it a perpetually obsolete OS that
struggles to implement features of 2020 because of the burden from 1990. Really
I'm shocked, so I'll just put that on possible deep cultural differences, and
forget about e) and a small part of the rest also. Enough heart attacks for
Main Index |
Thread Index |