From nobody Fri Sep 6 01:39:24 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X0Jn60jgbz5V8Cr for ; Fri, 06 Sep 2024 01:39:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X0Jn53rWVz4k8n for ; Fri, 6 Sep 2024 01:39:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-7cd8d2731d1so1174704a12.3 for ; Thu, 05 Sep 2024 18:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725586776; x=1726191576; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=d6I7ICS1PCa1I8hi10EErwig3Nw+YMOEXqbdRgcHswg=; b=Ie2/wfCrRebHrQFU6NvZWwv2KqNNNd5/G1D/jlbe3w7qkm041+AmZhrJi88fKk5pnM jUQfmfuMlnv+mQ9pbqZpDM2xzMIbSYXDmhEBPLmwzCSn47FXvsEdb7JYAFCltbYECgW8 7Y/DxgLVlOr02zv6fdK0Np3n0Bp7oE74+qWL5nw7dXPBwrktTdbmxiJEE0u0JbgQCF9l YNYNftyu7Uk9bAQG34ustrEDrA5RMSdawaOsSkJImbmRSM/k6VMD1M0oEPbNHk2b2tDa FOo+opBcelQDq3ZII0tftQKWXma7zrRiTG//h6HsG5QNO/9PqHKFniNo62LGZB0mzPXR PXgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725586776; x=1726191576; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=d6I7ICS1PCa1I8hi10EErwig3Nw+YMOEXqbdRgcHswg=; b=qp1DLenYmrSVmYdm4Pu3g35ItrcEfJFSmAegWOQaGi5DBO0+YAS2JqJUukAuRJsBgD RKClza0jEXpRmGpsb6fFGMYPvHab0gxT2qQJuVQ4aT6cYamvGQ8C8bnT8qNG4qY7yTUn qaYe5E5iQLrcXWlbwQnQhNr6nq9F4cYbpTYFUaQsc9cquzLoSL/p7sJtWEeb07B9rOCL FCwqMEKVVpuIz74WsC/OBirbRo/yZxiH1hVOw38SuI/7U2lEIxCtUG0+sLUYynK/K9YC pzGMERBek/XAhqvxfQ4aA2DTEHtQqKNgPODkLreIjvBjvJHzlN9dc1N5/49sewJAv15n KBGw== X-Gm-Message-State: AOJu0YxPgT8b+DPQOEJtwihh1fj0mE5gTqxAYGYOcIAy6hm50+aXOYLz jsR+ozjUobLLHeMr0nBW+k/zbJYoJNRAfg9NiywuUc8PpSetLIHg/qmVuts0yxCO4WnhzNzvrYo H5SJtM3Vfsbd2kLLatKyhLK230KfpQNgxXDlCOQ== X-Google-Smtp-Source: AGHT+IGL04Y0Q5CraytQhxb6hJU87DVt6olfkE/blgNbDlFS64pJT9E0qxQYNsDUs6jsKmRlpTbcCakAJffYx8eGLGk= X-Received: by 2002:a17:90a:f48b:b0:2c1:9892:8fb with SMTP id 98e67ed59e1d1-2dad4de4c5bmr1447959a91.5.1725586775757; Thu, 05 Sep 2024 18:39:35 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 5 Sep 2024 19:39:24 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Alan Somers Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000cc79a20621697aac" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X0Jn53rWVz4k8n --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 wr= ote: > On Thu, Sep 5, 2024 at 2:16=E2=80=AFPM Warner Losh wrote= : > > > > > > > > On Thu, Sep 5, 2024 at 12:10=E2=80=AFPM Alan Somers 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


=
On Thu, Sep 5, 2024 at 2:36=E2=80=AFP= M Alan Somers <asomers@freebsd.or= g> wrote:
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.org> wrot= e:
>>
>> By now I expect that most of you have seen the long list of new >> security advisories that just came out.=C2=A0 Strikingly, all were= the
>> result of memory handling errors.=C2=A0 And none of them wouldn= 9;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<= br> > 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 magnitu= de
> 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=
> waiting for something to do.

Sure.=C2=A0 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 e= ven
> FreeBSD). The rewrites to date have lost functionality (though maybe n= ot
> 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<= /div>
directly (at least in the version I looked at) rather than using = curses. It's a little
thing, and it might not really matter.<= /div>
=C2=A0
>
> So great, we should switch to rust. But so far we have no way to do th= at
> incrementally (other than a parallel build system, which isn't ver= y FreeBSDish).
> And if we can't even find the resources to do that minimal level o= f 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.=C2=A0 And any component that=
needs a major overhaul anyway should probably also be written in a
safe language, too.

I tend to agree wit= h that. New, large products should be written in the most
appropr= iate 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 h= as to be a safe
language, however, but that's more about prac= tical considerations than
whether it would be better...

Warner
--000000000000cc79a20621697aac--