Re: Weirdness in /bin/sh of 8.0

[Izaac <izaac%setec.org@localhost>]

On Wed, Aug 15, 2018 at 08:29:29PM +0000, maya%netbsd.org@localhost wrote:
> You're complaining loudly at someone for changing code you believe is
> sacred.

Your ability to read minds and intentions across time and space is quite
a remarkable ability.  You should do talk shows.  But just in case you
weren't tuning in to me properly, I'll gently correct that I am not
"complaining" about altering anything "sacred." I am pointing out
irresponsible and unprofessional behavior as regards the handling of
changes to a critical code which is otherwise stable.

> - We don't want to have any code in netbsd that is too sacred to touch.

Religiosity isn't in question; stability and security are.  And the code
isn't being "touched", it's being substantially altered in place.  This
should be done with great discretion and in full understanding of the
risks and ramifications.  But it is not.

> - kre is ridiculously fucking nice.

Irrelevant.  Also true.  But Mr. Rogers is also really fucking nice.
And if I see him behaving like this, I will call him out on it.  It's
what one does when they see someone or something they respect making a
mistake or walking into trouble.

> - we really, really like kre.

Irrelevant.  I also don't dislike Mr. Elz.  I dislike that he is
conducting himself like some Linux-lust-filled teenager over core
systems of the operating environment that I and many, many other people
use every day.

(Who is this "we" by the way?) (And weren't you just criticizing a
strawman for getting over-protective of the sacred?)

> It's like everyone has a score. You can do negative and positive things.
> Positive:
> [ ] Not break other people's usage in a long of time
> [ ] Not breaking the build either
> [ ] Friendly in communications
> [ ] Fixing reported bugs
> [ ] Discuss criticism honestly
> 
> Negative:
> [ ] Hostile to others changes without a founded reason
> [ ] Hostile in communications

Is it like that?  Do you maintain little cards for everyone?  What does
your own card read for "discuss criticism honestly?"  Because I have yet
to see you do that to the criticism I raised a year ago and in the last
couple days.  You have instead elided the core point, i.e. that
unprofessional behavior is being observed regarding the handling of core
userland utilities, and resorted to a variety of logical fallacies and
irrelevancies.

I note, incidentally, that precisely one of your criteria is in any way
related to the actual act of developing and maintaining software.  Think
about that.

> kre has been doing a lot of the positive things and none of the negative
> things. You're doing the negative things.

Your opinion of me is noted and valued accordingly.  Would you care to
discuss the maintenance of software now?

> I would be defending him even if the criticism was about sh making my
> own system unbootable. And it isn't.

Do you find that to be a responsible position?  You seem to have your
eyes set on a leadership position within the project, so I'm curious.

> It's a problem in dash, which is supposed to be a fork of NetBSD sh.
> There's a high chance that the bug existed in older NetBSD sh.

First, I have no idea what "bug" you're talking about.  Second, as
described in another reply the notion of "bug" here is highly suspect.
Third, I don't know how dash came up.  And finally, your understanding
of the lineage of dash is confused.

> As far as risk goes, sh is maybe medium risk at most.

Is it?  By what means did you arrive at this conclusion?  And in what
way did this conclusion influence the decision-making process behind
altering it in the way which has been done and, I am advised, will
continue to be done?   The posing and answering of these questions are a
small portion of what is known as a "software development process."  Or
the audit of one.

> For comparison, take msaitoh's recent work. He wanted to make newer
> ethernet cards work. This was slightly delayed because his changes
> damaged his own hardware, which needed to be reflashed by the
> manufacturer.

In the one case, we're talking about the alteration of code which years
old and common, stable use in userland.  In the other, a developer who
is reverse engineering a device for the purpose of the development of
kernel driver code which will ultimately only be executed by those users
with that device.  In what possible way is that comparable?

> Yes, sh is not statically linked. By the way, neither is init.

Quite right.  Nothing in /sbin is, in fact.  Any idea what bizarre
sequence of events lead to that decision?

> - Currently netbsd has some limitations regarding i18n in statically
>   linked binaries

Let's elide the mysteries regarding that little bit of recent madness.
Why, exactly, does init need i18n support?  It provides no output.

> - /rescue/sh is statically linked if you must have it

I am familiar.

> Yes, netbsd could have a package-management method of managing base, but
> instead it makes extremely strong guarantees about backwards
> compatibility.

Congratulations!  You have made me literally laugh out loud.

You do realize that the topic of discussion is alteration to the
function of /bin/sh, right?  And how despite protests and predictions,
we've arrived at the point where it is not breaking compatibility with
scripts in the wild?  And that my position is the means by which that
"strong guarantee" is maintained?

Your phrasing also seems to imply that having basepkg somehow undermines
these guarnatees.  How?

> The versioning of netbsd is as follows:
> kernel version >= library version >= userland/packages.

<confused stare>  What are you describing?

> There were some cases it was violated, but in general, you can run
> binaries from very old netbsd with no modification to either libc or
> kernel.
> 
> We don't control libstdc++ as much but we try to major bump so old
> binaries will link against old libstdc++ when we have to change it.

Ultimately correct, provided sufficient attention to providing
compat_netbsd* with what it needs.  It is also unremarkable, as it is
also a basic requirement for what we refer to as "having a platform."
Much as buying a new pair of shoes is expected not to interfere with
one's ability to walk.

And, incidentally, having "some cases" of violation means "strong" is no
longer applicable.

-- 
. ___ ___  .   .  ___
.  \    /  |\  |\ \
.  _\_ /__ |-\ |-\ \__