From nobody Sun Sep 15 13:34:43 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 4X68DK4xMGz5WY1n for ; Sun, 15 Sep 2024 13:34:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 4X68DJ6T9Cz4F6y for ; Sun, 15 Sep 2024 13:34:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-7c6b4222fe3so2284589a12.3 for ; Sun, 15 Sep 2024 06:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1726407295; x=1727012095; 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=cgn1L0L6gXnBFMBBBa5XEMHUKkWoodju6Mtjl+P8U5A=; b=FyqsmJAYITC1kR5xR5RWXSNQFEx1AmDPacgdbGe0BHj7b+4JJ5m2fGIb3sbklwQKKg pGg+i6HO26X1w4+1sRM2AeWLlAraCpMfO6VDEMAlIVHFspr9E2pKiEj4vagvcTddnc9k Lu+0PRwPbGbOfh7SNx88KXE/2Rs+8UF8IOXV43Ust+NW3DARfLkRBX2r+u7izfvdmK5Y LnF9KB682TZ7zig4Xqnk0Y8CPSX1zWNRaTi82oevat72v0BHN+IQLf7ERyg99EsN3Ry4 l2ZfNmPs8/hkkqASSetzjFvmRcvPIP5SUH6HWtLFIGphI079tr4RAlTa+3iyygTieLhn qSSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726407295; x=1727012095; 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=cgn1L0L6gXnBFMBBBa5XEMHUKkWoodju6Mtjl+P8U5A=; b=AsZg33oa5AoP4oI1mYS1E/tEvvmlg5yX9NsiTsyYPmOAcLnHQoxuN102/EYzKFa8XG L480pkdfcLAv8dsU7DW3JD+yJYILe74qNNAsss4Gw4nOAUFhc9lFj7W0W14wow1En2J4 hCW2Zov54J31TEyu5uFmnaRxSi+qWuANpYH1I9gvoWvXT66D4yYBB67odoXFA6G69qx1 ieKGGdoR1IpsyIHvpkDXbrbPLqj1TF/nXKXCQVk29KhDyYCSQ7PQOin6AnCmdCJjIRXF aV4sRLQsgF7jGZnwvb46QPf0dFkXA5BiaEY+KezEp0wywkxQGLC176X0g90Ebg6tdxU4 FaoA== X-Forwarded-Encrypted: i=1; AJvYcCVmdDpwyjLhDWuJl4ZzhGmnBFErsXpmH/v6kfgeDCKvvzW0ovtw2o79f1N823mikrbl3P6fhDAl7AYin7o8Few=@freebsd.org X-Gm-Message-State: AOJu0YyPxnb/EsphN2QpW/hrT3lex8KAq+qR5kQ/uvAzHBZuETDMnuQC TIt5RIPPoleC1r7tFFWPTcI6D2MHA3s1BJn8DD7gRqPWLnqjkudWuDueMeTUVzlP+clDdZoqRNg PU7MPP0MIgOMkA7xX13UoSjb94MV15XKDndD2Hw== X-Google-Smtp-Source: AGHT+IEKcXPuc+SPXR87lfY4uHx6CTULDyfpsnzO8s3RHIVZCqqbvh77Lk4/GlIAMBBE7BpmI/LG4CtSc3gErtPojao= X-Received: by 2002:a17:90a:d507:b0:2d3:b8d6:d041 with SMTP id 98e67ed59e1d1-2dba0064f94mr13477530a91.32.1726407294758; Sun, 15 Sep 2024 06:34:54 -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: <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> <20240911010657.a23295639d222b057e883da2@dec.sakura.ne.jp> <20240915123004.136429333eeed0c347e114dc@dec.sakura.ne.jp> <202409151237.48FCbrA4052180@critter.freebsd.dk> In-Reply-To: <202409151237.48FCbrA4052180@critter.freebsd.dk> From: Warner Losh Date: Sun, 15 Sep 2024 14:34:43 +0100 Message-ID: Subject: Re: The Case for Rust (in any system) To: Poul-Henning Kamp Cc: Tomoaki AOKI , Kyle Evans , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000008ad65b0622288556" 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: 4X68DJ6T9Cz4F6y --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 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


On Sun, Sep 15, 2024, 1:38=E2=80=AFPM Poul-Henning Kam= p <phk@phk.freebsd.dk> wrot= e:
--------
Tomoaki AOKI writes:

> My most important point I've intentionally didn't directly wri= tten is
> that I don't want to see cases like newbus vs newconfig case anymo= re.

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.
<= br>
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...

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.

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.

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 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.

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" commitme= nt
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:=C2=A0 Since this is a consequence of the FOSS model, it must therefore be A
Good Thing.=C2=A0 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.=C2=A0 (Feel free to disagree,
but I'm not going to entertain any arguments on this point.)

Circulate that mockup-documentation.=C2=A0 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.=C2=A0 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.=C2=A0 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=C2=A0 =C2=A0 =C2=A0 =C2=A0| UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| TCP/IP since RFC 956
FreeBSD committer=C2=A0 =C2=A0 =C2=A0 =C2=A0| BSD since 4.3-tahoe=C2=A0 =C2= =A0
Never attribute to malice what can adequately be explained by incompetence.=

--0000000000008ad65b0622288556--