Date: Sun, 15 Sep 2024 14:34:43 +0100 From: Warner Losh <imp@bsdimp.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>, Kyle Evans <kevans@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: The Case for Rust (in any system) Message-ID: <CANCZdfot6oaUEw-8oZXRruLXjAYDcM7VmY19pTKNS3OGTL3LLA@mail.gmail.com> In-Reply-To: <202409151237.48FCbrA4052180@critter.freebsd.dk> References: <CAOtMX2iCNX5OkdeghnbmcMrO0UYWwm4zfxFSZGznOznu%2Bmh5rA@mail.gmail.com> <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> <c8b52bcd-725d-473e-a30c-a611b9c2e44c@FreeBSD.org> <20240911010657.a23295639d222b057e883da2@dec.sakura.ne.jp> <a3cfa6fd-e29d-4c43-bc5e-7209630ed27d@FreeBSD.org> <20240915123004.136429333eeed0c347e114dc@dec.sakura.ne.jp> <202409151237.48FCbrA4052180@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000008ad65b0622288556 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Sep 15, 2024, 1:38=E2=80=AFPM 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 incompetenc= e. > > --0000000000008ad65b0622288556 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Sun, Sep 15, 2024, 1:38=E2=80=AFPM Poul-Henning Kam= p <<a href=3D"mailto:phk@phk.freebsd.dk">phk@phk.freebsd.dk</a>> wrot= e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex">--------<br> Tomoaki AOKI writes:<br> <br> > My most important point I've intentionally didn't directly wri= tten is<br> > that I don't want to see cases like newbus vs newconfig case anymo= re.<br> <br> As somebody who was around back then: That was a real shambles and<br> the bad and missing communication, from all sides, made everything<br> worse than it needed to be.<br></blockquote></div></div><div dir=3D"auto"><= br></div><div dir=3D"auto">Yes. Too little duscussion, too much decision ma= king by fiat. Language barriers and cultural customs made this worse than i= t needed to me. Poor documentation of newbus and poorly articulated newconf= ig benefits as well. I wish we'd wound up with a hubrid of the two, sin= ce the newconfig code is much nicer. But newconfig is a bit less flexible f= or dynamic devices and one has to hand roll sw tables that newbus gives for= free. Newconfig has better config data specifications than hints (though t= he dynamic busses need it less). At the time, too few people had all the co= ntext 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 u= p 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 hac= ker 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...</div><div dir=3D"auto"><br></div><div dir=3D"auto">It's = one reason I don't want to anoint a winner before there's code. It&= #39;s also why I've been firm that no rust in base until we can build i= t and learn the actual benefits and pitfalls from doing that over the long = run. It will fall somewhere between no worries and nightmare of incompatibi= lities 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 newco= nfig.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Open source is don= e on the speculative belief people will use it. We need to allow novel expe= riments to run somehow run without them getting in the way of the rest of b= ase and vice versa.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Rust= is good enough to try. Experience will say if we kill it or keep it.</div>= <div dir=3D"auto"><br></div><div dir=3D"auto">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 ne= ed 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.</d= iv><div dir=3D"auto"><br></div><div dir=3D"auto">Warner</div><div dir=3D"au= to"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex"> But since then I've seen the same basic situation play out many<br> times, both in FreeBSD and elsewhere in FOSS.<br> <br> The people with the idea do not want to waste their time, so they<br> want a clear "Yes, if you write that, we'll take it" commitme= nt<br> from the FOSS project.<br> <br> FOSS projects do not commit to nonexistent code.<br> <br> It is a fundamental conflict which can have no solution, because<br> both positions are 100% rational and mutually incompatible.<br> <br> The net result is that many good ideas are never tried out.<br> <br> (Some FOSS-philosophers have tried to post-rationalize that:=C2=A0 Since<br= > this is a consequence of the FOSS model, it must therefore be A<br> Good Thing.=C2=A0 I disagree.)<br> <br> But as I said, there can be no "solution" only compromises and<br= > workarounds.<br> <br> The best I can suggest is the following:<br> <br> The proposers /start/ by writing mockup "usage documentation",<br= > because if they cannot explain how to use it, it's guaranteed not<br> a good idea and it is not going anywhere.=C2=A0 (Feel free to disagree,<br> but I'm not going to entertain any arguments on this point.)<br> <br> Circulate that mockup-documentation.=C2=A0 Dont expect much if any<br> feedback, but at least people have a chance to know what you're<br> trying to do, and you may get some competent input.=C2=A0 Getting the<br> bikesheds started early also saves time.<br> <br> Find a way to partition the implementation into stages, each of which<br> provides some amout of positive benefit, so that even if the larger<br> project fails to reach the goal-line, you will have made a positive<br> contribution along the way.<br> <br> If there are major negative effects, concentrate them in the final<br> stage, which brings benefits to offset them.=C2=A0 But even better: Spend<b= r> extra effort (backwards compat syntax etc.) to avoid such major<br> negative effects.<br> <br> And then eat your veggies bite by bite until you get to the desert :-)<br> <br> Again: This is not "a solution", it is merely what my experience = shows<br> work least bad.<br> <br> Poul-Henning<br> <br> -- <br> Poul-Henning Kamp=C2=A0 =C2=A0 =C2=A0 =C2=A0| UNIX since Zilog Zeus 3.20<br= > phk@FreeBSD.ORG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| TCP/IP since RFC 956<br> FreeBSD committer=C2=A0 =C2=A0 =C2=A0 =C2=A0| BSD since 4.3-tahoe=C2=A0 =C2= =A0 <br> Never attribute to malice what can adequately be explained by incompetence.= <br> <br> </blockquote></div></div></div> --0000000000008ad65b0622288556--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfot6oaUEw-8oZXRruLXjAYDcM7VmY19pTKNS3OGTL3LLA>