Re: The Case for Rust (in any system)

On Sun, Sep 15, 2024, 1:38 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> --------
> Tomoaki AOKI writes:
>
> > My most important point I've intentionally didn't directly written is
> > that I don't want to see cases like newbus vs newconfig case anymore.
>
> As somebody who was around back then: That was a real shambles and
> the bad and missing communication, from all sides, made everything
> worse than it needed to be.
>

Yes. Too little duscussion, too much decision making by fiat. Language
barriers and cultural customs made this worse than it needed to me. Poor
documentation of newbus and poorly articulated newconfig benefits as well.
I wish we'd wound up with a hubrid of the two, since the newconfig code is
much nicer. But newconfig is a bit less flexible for dynamic devices and
one has to hand roll sw tables that newbus gives for free. Newconfig has
better config data specifications than hints (though the dynamic busses
need it less). At the time, too few people had all the context to have a
proper discussion. And the brashness of early core members mixed poorly
with the permission seeking Japanese culture so the questions that should
have facilitated a discussion never happened. I tried to pick up the
pieces, but it was too late. The damage was done and both NetBSD and
FreeBSD were worse off as a result. And the relations with the Japanese
hacker community were too strained for later collaboration, helping Linux
gain a deeper foothold as both BSDs lacked drivers since the barrier to
sharing was higher...

It's one reason I don't want to anoint a winner before there's code. It's
also why I've been firm that no rust in base until we can build it and
learn the actual benefits and pitfalls from doing that over the long run.
It will fall somewhere between no worries and nightmare of
incompatibilities that have been proffered. Shoe me the money, show the
benefits in a tangible way, give us real data on how hard supporting it is.
We can debate what's theoretical better forever, but without hard data
nothing will change. I want to avoid the worst of the past mistakes like
newbus vs newconfig.

Open source is done on the speculative belief people will use it. We need
to allow novel experiments to run somehow run without them getting in the
way of the rest of base and vice versa.

Rust is good enough to try. Experience will say if we kill it or keep it.

I mean, I'd love to see a u-root port to FreeBSD too. But before we put go
in the base, I'd have to show that cool thing working. And before we put it
in base, we'd need an ext tool chain solution to optionally build it... and
I'd have to convince the community that a just in time compiler for a
minimal root was a good idea and worked. There has to be a compelling
reason for change.

Warner

But since then I've seen the same basic situation play out many
> times, both in FreeBSD and elsewhere in FOSS.
>
> The people with the idea do not want to waste their time, so they
> want a clear "Yes, if you write that, we'll take it" commitment
> from the FOSS project.
>
> FOSS projects do not commit to nonexistent code.
>
> It is a fundamental conflict which can have no solution, because
> both positions are 100% rational and mutually incompatible.
>
> The net result is that many good ideas are never tried out.
>
> (Some FOSS-philosophers have tried to post-rationalize that:  Since
> this is a consequence of the FOSS model, it must therefore be A
> Good Thing.  I disagree.)
>
> But as I said, there can be no "solution" only compromises and
> workarounds.
>
> The best I can suggest is the following:
>
> The proposers /start/ by writing mockup "usage documentation",
> because if they cannot explain how to use it, it's guaranteed not
> a good idea and it is not going anywhere.  (Feel free to disagree,
> but I'm not going to entertain any arguments on this point.)
>
> Circulate that mockup-documentation.  Dont expect much if any
> feedback, but at least people have a chance to know what you're
> trying to do, and you may get some competent input.  Getting the
> bikesheds started early also saves time.
>
> Find a way to partition the implementation into stages, each of which
> provides some amout of positive benefit, so that even if the larger
> project fails to reach the goal-line, you will have made a positive
> contribution along the way.
>
> If there are major negative effects, concentrate them in the final
> stage, which brings benefits to offset them.  But even better: Spend
> extra effort (backwards compat syntax etc.) to avoid such major
> negative effects.
>
> And then eat your veggies bite by bite until you get to the desert :-)
>
> Again: This is not "a solution", it is merely what my experience shows
> work least bad.
>
> Poul-Henning
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>