Date: Thu, 5 Sep 2024 19:39:24 -0600 From: Warner Losh <imp@bsdimp.com> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: The Case for Rust (in any system) Message-ID: <CANCZdfoFgMshcLL1MF060YxVUvsE3S09XDNrT0GiosCreeN5RQ@mail.gmail.com> In-Reply-To: <CAOtMX2hY22v6w5coXSVEtoKWfJTYY-ML6zt-fUf=R6upc-bvgQ@mail.gmail.com> References: <CAOtMX2iCNX5OkdeghnbmcMrO0UYWwm4zfxFSZGznOznu%2Bmh5rA@mail.gmail.com> <CANCZdfoHP3G3YMvpqVwpQZSRQ64pnYhBJD60Dcar%2BBCUaJNL-w@mail.gmail.com> <CAOtMX2hY22v6w5coXSVEtoKWfJTYY-ML6zt-fUf=R6upc-bvgQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000cc79a20621697aac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 5, 2024 at 2:36=E2=80=AFPM Alan Somers <asomers@freebsd.org> wr= ote: > On Thu, Sep 5, 2024 at 2:16=E2=80=AFPM Warner Losh <imp@bsdimp.com> wrote= : > > > > > > > > On Thu, Sep 5, 2024 at 12:10=E2=80=AFPM Alan Somers <asomers@freebsd.or= g> wrote: > >> > >> By now I expect that most of you have seen the long list of new > >> security advisories that just came out. Strikingly, all were the > >> result of memory handling errors. And none of them wouldn't have > >> happened if their respective programs had been written in a > >> memory-safe language. > > > > > > FreeBSD represents hundreds of thousands or millions of man hours > > in its current form (depending on how you measure it). It has evolved > > over 30 years. To get to the same level of maturity in a rust rewrite > would > > take a similar amount of time. But even if it took an order of magnitud= e > > less because rust is that much better, that represents a huge pool of > > manpower that don't seem to be hanging out around the project just > > waiting for something to do. > > Sure. I for one am not volunteering to rewrite CTL next week. > > > > > Where do the resources for this come from? Without enough resources, > > the rewrites will be crap and nobody will want to use them (or maybe ev= en > > FreeBSD). The rewrites to date have lost functionality (though maybe no= t > > functionality that's important) relative to what they replace. > > Which rewrites are you thinking of? > rs-gstat differs in a number of ways from gstat, including writing ANSI codes directly (at least in the version I looked at) rather than using curses. It's a little thing, and it might not really matter. > > > > So great, we should switch to rust. But so far we have no way to do tha= t > > incrementally (other than a parallel build system, which isn't very > FreeBSDish). > > And if we can't even find the resources to do that minimal level of > work, how > > can the rest possibly be robustly undertaken? > > > > Warner > > Your point is obvious; FreeBSD is too big to rewrite the whole thing. > But my point stands: new projects (whether inside of FreeBSD or not) > should almost always be using a safe language. And any component that > needs a major overhaul anyway should probably also be written in a > safe language, too. > I tend to agree with that. New, large products should be written in the mos= t appropriate language for their problem domain. We'll have a lot of legacy C code for a long time, though... I'm not entirely convinced it has to be a safe language, however, but that's more about practical considerations than whether it would be better... Warner --000000000000cc79a20621697aac 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 Thu, Sep 5, 2024 at 2:36=E2=80=AFP= M Alan Somers <<a href=3D"mailto:asomers@freebsd.org">asomers@freebsd.or= g</a>> wrote:<br></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"= >On Thu, Sep 5, 2024 at 2:16=E2=80=AFPM Warner Losh <<a href=3D"mailto:i= mp@bsdimp.com" target=3D"_blank">imp@bsdimp.com</a>> wrote:<br> ><br> ><br> ><br> > On Thu, Sep 5, 2024 at 12:10=E2=80=AFPM Alan Somers <<a href=3D"mai= lto:asomers@freebsd.org" target=3D"_blank">asomers@freebsd.org</a>> wrot= e:<br> >><br> >> By now I expect that most of you have seen the long list of new<br= > >> security advisories that just came out.=C2=A0 Strikingly, all were= the<br> >> result of memory handling errors.=C2=A0 And none of them wouldn= 9;t have<br> >> happened if their respective programs had been written in a<br> >> memory-safe language.<br> ><br> ><br> > FreeBSD represents hundreds of thousands or millions of man hours<br> > in its current form (depending on how you measure it). It has evolved<= br> > over 30 years. To get to the same level of maturity in a rust rewrite = would<br> > take a similar amount of time. But even if it took an order of magnitu= de<br> > less because rust is that much better, that represents a huge pool of<= br> > manpower that don't seem to be hanging out around the project just= <br> > waiting for something to do.<br> <br> Sure.=C2=A0 I for one am not volunteering to rewrite CTL next week.<br> <br> ><br> > Where do the resources for this come from? Without enough resources,<b= r> > the rewrites will be crap and nobody will want to use them (or maybe e= ven<br> > FreeBSD). The rewrites to date have lost functionality (though maybe n= ot<br> > functionality that's important) relative to what they replace.<br> <br> Which rewrites are you thinking of?<br></blockquote><div><br></div><div>rs-= gstat differs in a number of ways from gstat, including writing ANSI codes<= /div><div>directly (at least in the version I looked at) rather than using = curses. It's a little</div><div>thing, and it might not really matter.<= /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"> ><br> > So great, we should switch to rust. But so far we have no way to do th= at<br> > incrementally (other than a parallel build system, which isn't ver= y FreeBSDish).<br> > And if we can't even find the resources to do that minimal level o= f work, how<br> > can the rest possibly be robustly undertaken?<br> ><br> > Warner<br> <br> Your point is obvious; FreeBSD is too big to rewrite the whole thing.<br> But my point stands: new projects (whether inside of FreeBSD or not)<br> should almost always be using a safe language.=C2=A0 And any component that= <br> needs a major overhaul anyway should probably also be written in a<br> safe language, too.<br></blockquote><div><br></div><div>I tend to agree wit= h that. New, large products should be written in the most</div><div>appropr= iate language for their problem domain. We'll have a lot of legacy C</d= iv><div>code for a long time, though... I'm not entirely convinced it h= as to be a safe</div><div>language, however, but that's more about prac= tical considerations than</div><div>whether it would be better...</div><div= ><br></div><div>Warner</div></div></div> --000000000000cc79a20621697aac--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoFgMshcLL1MF060YxVUvsE3S09XDNrT0GiosCreeN5RQ>