Date: Sun, 15 Sep 2024 12:37:53 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> Cc: Kyle Evans <kevans@FreeBSD.org>, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <202409151237.48FCbrA4052180@critter.freebsd.dk> In-Reply-To: <20240915123004.136429333eeed0c347e114dc@dec.sakura.ne.jp> References: <CAOtMX2iCNX5OkdeghnbmcMrO0UYWwm4zfxFSZGznOznu%2Bmh5rA@mail.gmail.com> <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> <c8b52bcd-725d-473e-a30c-a611b9c2e44c@FreeBSD.org> <20240911010657.a23295639d222b057e883da2@dec.sakura.ne.jp> <a3cfa6fd-e29d-4c43-bc5e-7209630ed27d@FreeBSD.org> <20240915123004.136429333eeed0c347e114dc@dec.sakura.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202409151237.48FCbrA4052180>