From nobody Sun Sep 15 12:37:53 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 4X66yj2vrMz5WPb1 for ; Sun, 15 Sep 2024 12:38:05 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4X66yj0XCwz45dd; Sun, 15 Sep 2024 12:38:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 8132189284; Sun, 15 Sep 2024 12:37:55 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 48FCbrA4052180; Sun, 15 Sep 2024 12:37:53 GMT (envelope-from phk) Message-Id: <202409151237.48FCbrA4052180@critter.freebsd.dk> To: Tomoaki AOKI cc: Kyle Evans , freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) In-reply-to: <20240915123004.136429333eeed0c347e114dc@dec.sakura.ne.jp> From: "Poul-Henning Kamp" 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> 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 Content-Type: text/plain; charset="us-ascii" Content-ID: <52178.1726403873.1@critter.freebsd.dk> Date: Sun, 15 Sep 2024 12:37:53 +0000 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:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4X66yj0XCwz45dd -------- 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. 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 incompetence.