Date: Mon, 5 Aug 2024 16:19:23 -0600 From: Warner Losh <imp@bsdimp.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Steffen Nurpmeso <steffen@sdaoden.eu>, Cy Schubert <Cy.Schubert@cschubert.com>, freebsd-hackers@freebsd.org, Bakul Shah <bakul@iitbombay.org> Subject: Re: The Case for Rust (in the base system) Message-ID: <CANCZdfpB9k_gzuLUij-kuwXMeMDqVwfx9DUsWBdmwNEtMvVkaA@mail.gmail.com> In-Reply-To: <202408052206.475M6h8E067967@critter.freebsd.dk> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <vdmg5zocd6wqcwc2bvzvzqn4bii2pwdc2r4mgnisukfkboj6nf@f7lv5quu4fjx> <CAOtMX2iDK3uN_oQgzzZAdoOZCfNsnvpefeZvKoTCRmPBhZywzA@mail.gmail.com> <CANCZdfqB1%2B-8BkpKwKoCM%2BzM4mCOFy63yHr1Pco7MnT1DFkb4w@mail.gmail.com> <EF084C36-D2EA-4194-B30F-253B0E8D5B4D@iitbombay.org> <704D020F-78A4-4926-AE3C-41F7FD619A89@cschubert.com> <20240805210149.nrkHN3j3@steffen%sdaoden.eu> <202408052127.475LROnE067608@critter.freebsd.dk> <CANCZdfrh-74M0L-Z%2BOOnqSD6xO3PyaUXWc8LPWxtRbsWawu4qA@mail.gmail.com> <202408052206.475M6h8E067967@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000066a6a0061ef712ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 5, 2024 at 4:06=E2=80=AFPM Poul-Henning Kamp <phk@phk.freebsd.d= k> wrote: > -------- > Warner Losh writes: > > > > > Most user space tools could be written in lua. > > > > > > That /exact/ same argument was made for Perl :-) > > > > Lua's been in the base since I imported it for the boot loader, though.= .. > > Lua is is much more "language" than "eco-system", by design as I > understand it, so that is a different situation than Perl or Rust. > Indeed. The standard stuff is fairly small, and we're doing it all as a 'private' library, so ports will never see what we pull in. I personally do not subscribe to to the "let's rewrite all the 50 > year old source code to make it more safe" philosophy, but there > are valid arguments when the old code is horrible. > Plus we're writing new stuff only, and typically only where it makes a lot of sense (lots of string processing). Plus we're keeping the scripts as compatible with what little ecosystem there is so we can go back and forth between the ports lua and the base flua. > But there are some wrinkles. > > First: Anything setuid/setgid is off-limits. > > There are good reasons why we dont have setuid shell-scripts (any more!) > > I guess with most systems being effectively single-user these days, > that may not be as much a security focus as it was back in the 1990ies. > Yea. No plans there. > Second: Performance. > > I cannot remember the exact subset of bin programs somebody did in > Perl as proof of concept, but it slowed down buildworld a LOT to > fire up all of Perl to do trivial stuff like "echo", "chown" and > "mkdir". > > Lua may be cheaper than Perl, but it will still be measurable. > Yea. I'm guessing you wouldn't notice, but why do that. There's no benefit and only a myriad of ways to introduce new bugs or non-posix conformance where we were conformant before. I'm definitely in the "why are we rewriting stuff in rust" because it doesn't move the ball forward, really. At best it's a great leap sideways, maybe with marginally better actual safety. At worst, it's a great leap int= o a morass of almost compatible that causes great grief in the gaps, or worse, has new security problems the old one didn't. So rewriting for the sake of rewriting seems like a giant waste of resources. Rewriting strategically to fix areas that have had safey issues may be different, but cp.rst isn't going to be any better, than cp.c in most aspects because cp.c has had 50 years to be debugged. And 50 years makes up for a lot of danger in the language.... So there may be things that we get some advantage out of by doing a rewrite in rust, but I'm in the 'case by case basis' camp there: those cases where the cost / benefit ratio is favorable should be considered. But they can't be considered entirely in a vacuum because there's a non-zero cost to rust in the base, even as an external toolchain. Having said all that, I'd love to see us be able to make better of rust and new rust programs where it makes sense. That's why I've been encouraging people to give it a go to show us the money. To show up that we can integrate it (even if it is just a few lines in Makefile.inc1 that builds everything, optionally, as part of buildworld). That shows us we can keep the dependency hell under control, that we can update things sanely (more ecosystem here, not language). How much work is it to track the latest versions, how do we deal with that as the number of new rust programs grow, how do we deal with ABI stability, etc. And to show us if there's an actual advantage to all of that over what we can do in ports, or what we might do with pkgbase somehow. I'm unsure of the outcome of all this, but I think it would be wrong to shout it down completely. To do all that, people need room to experiment and show what's what. Warner --00000000000066a6a0061ef712ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 5, 2024 at 4:06=E2=80=AFP= M Poul-Henning Kamp <<a href=3D"mailto:phk@phk.freebsd.dk">phk@phk.freeb= sd.dk</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:= 1ex">--------<br> Warner Losh writes:<br> <br> > > > Most user space tools could be written in lua.<br> > ><br> > > That /exact/ same argument was made for Perl :-)<br> ><br> > Lua's been in the base since I imported it for the boot loader, th= ough...<br> <br> Lua is is much more "language" than "eco-system", by de= sign as I<br> understand it, so that is a different situation than Perl or Rust.<br></blo= ckquote><div><br></div><div>Indeed. The standard stuff is fairly small, and= we're doing it all as</div><div>a 'private' library, so ports = will=C2=A0never see what we pull in.</div><div><br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex">I personally do not subscribe to to the &q= uot;let's rewrite all the 50<br> year old source code to make it more safe" philosophy, but there<br> are valid arguments when the old code is horrible.<br></blockquote><div><br= ></div><div>Plus we're writing new stuff only, and typically only where= it makes</div><div>a lot of sense (lots of string processing). Plus we'= ;re keeping the scripts</div><div>as compatible with what little ecosystem = there is so we can go back</div><div>and forth between the ports lua and th= e base flua.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"> But there are some wrinkles.<br> <br> First: Anything setuid/setgid is off-limits.<br> <br> There are good reasons why we dont have setuid shell-scripts (any more!)<br= > <br> I guess with most systems being effectively single-user these days,<br> that may not be as much a security focus as it was back in the 1990ies.<br>= </blockquote><div><br></div><div>Yea. No plans there.</div><div>=C2=A0</div= ><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border= -left:1px solid rgb(204,204,204);padding-left:1ex"> Second: Performance.<br> <br> I cannot remember the exact subset of bin programs somebody did in<br> Perl as proof of concept, but it slowed down buildworld a LOT to<br> fire up all of Perl to do trivial stuff like "echo", "chown&= quot; and<br> "mkdir".<br><br> Lua may be cheaper than Perl, but it will still be measurable.<br></blockqu= ote><div><br></div><div>Yea. I'm guessing you wouldn't notice, but = why do that. There's</div><div>no benefit and only a myriad of ways to = introduce new bugs</div><div>or non-posix conformance where we were conform= ant before.</div><div><br></div><div>I'm definitely in the "why ar= e we rewriting stuff in rust" because</div><div>it doesn't move th= e ball forward, really. At best it's a great leap sideways,</div><div>m= aybe with marginally better actual safety. At worst, it's a great leap = into</div><div>a morass of almost compatible that causes great grief in the= gaps, or</div><div>worse, has new security problems the old one didn't= . So rewriting</div><div>for the sake of rewriting seems like a giant waste= of resources.</div><div>Rewriting strategically to fix areas that have had= safey=C2=A0issues</div><div>may be different, but cp.rst isn't going t= o be any better, than</div><div>cp.c in most aspects because cp.c has had 5= 0 years to be</div><div>debugged.=C2=A0 And 50 years makes up for a lot of = danger</div><div>in the language.... So there may be things that we get som= e</div><div>advantage out of by doing a rewrite in rust, but I'm in the= </div><div>'case by case basis' camp there: those cases where the c= ost / benefit</div><div>ratio is favorable should be considered. But they c= an't be</div><div>considered entirely in a vacuum because there's a= non-zero</div><div>cost to rust in the base, even as an external toolchain= .</div><div><br></div><div>Having said all that, I'd love to see us be = able to make better of rust and</div><div>new rust programs where it makes = sense. That's why I've been</div><div>encouraging people to give it= a go to show us the money. To</div><div>show up that we can integrate it (= even if it is just a few lines in</div><div>Makefile.inc1 that builds every= thing, optionally, as part of</div><div>buildworld). That shows us we can k= eep the dependency hell</div><div>under control, that we can update things = sanely (more ecosystem</div><div>here, not language). How much work is it t= o track the latest versions,</div><div>how do we deal with that as the numb= er of new rust programs grow,</div><div>how do we deal with ABI stability, = etc. And to show us if there's an</div><div>actual advantage to all of = that over what we can do in ports, or what</div><div>we might do with pkgba= se somehow. I'm unsure of the outcome of all</div><div>this, but I thin= k it would be wrong to shout it down completely. To do</div><div>all that, = people need room to experiment and show what's what.</div><div><br></di= v><div>Warner</div><div><br></div></div></div> --00000000000066a6a0061ef712ce--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpB9k_gzuLUij-kuwXMeMDqVwfx9DUsWBdmwNEtMvVkaA>