Date: Wed, 04 Sep 2024 00:31:36 +0200 From: "Rein Fernhout (Levitating)" <me@levitati.ng> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Message-ID: <99fe98c0974bc1778e26097eec3fc244@purelymail.com> In-Reply-To: <202409031532.483FW0If007252@critter.freebsd.dk> References: <202409031532.483FW0If007252@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
I actually think Rust could be an opportunity to modernize the FreeBSD
src.
But if it is decided that no utilities found in FreeBSD will be eligible
for a Rust rewrite then I don't see why it should be part of src.
I do think Rust is mature enough for adoption into src. These
discussions have been riddled with misconceptions about Rust (and its
use in the Linux kernel).
Each FreeBSD release could just pin a stable release of the Rust
toolchain, it is common for Rust projects to have a Minimum Supported
Rust Version (MSRV).
Also Rust does have an extremely strong ecosystem. It includes gems like
the Serde serialization framework and the Clap argument parser.
I would personally like to potentially see parts of FreeBSD rewritten in
rust.
I think it would invite much more contributors in the long term.
However I don't see rust rewrites happen anytime soon. And if we only
allow new programs in Rust to enter src then I don't think it is worth
the burden of supporting a rust toolchain (and its dependencies).
On 2024-09-03 17:32, Poul-Henning Kamp wrote:
> What is FreeBSD ?
> -----------------
>
> Forget Rust for the moment, I promise I will come back to it.
>
> FreeBSD as a project was created almost entirely as protest against
> the incompetent "UNIX-industry" as it existed around 1990.
>
> One of the stupidities we reacted against, was the unbundling of
> the C-compiler: If you bought a UNIX system, the C-compiler would
> cost you extra, even through everybody knew that the vendor got it
> as part of their source license from AT&T.
>
> So from the very start, FreeBSD decided to deliver "A complete UNIX
> system with full source" and the only concession was that, hard
> disks costing what they did, you could choose to not install the
> manual pages and the source code on systems which did not need them.
>
> ('make world' celebrated 30 years last month! See: 3540f0e14a8)
>
> The only compiler we had source code for was GCC. We would have
> preferred a different license, but we had no choice at the time.
>
> There were people who, reasonably, thought that X11 was also part
> of a "complete UNIX system", but the reality of 1.2MB "3D-printed
> save icons" made that a total non-starter, and therefore the ports
> collection is FreeBSD's barely younger twin.
>
> The source tree became our citadel: "FreeBSD is src". If something
> was not in src, it was not FreeBSD.
>
> Buildworld or bust.
>
> The fight at the gate was fierce at times.
>
> Delivering a single consistent userland with the kernel has stood
> us well for three decades, and we should stick with that.
>
> But the world has changed, and we all know it, which is why ports,
> pkg, freebsd-update and pkgbase exist.
>
> A FreeBSD system with no installed ports is a rarity today.
>
> Not even a FreeBSD developers test-machine can avoid git-lite, but
> such machines do exist, typically in embedded applications.
>
> But a FreeBSD system recompiling itself from source is even rarer.
>
> And when it does, LLVM, source code we import verbatim from an
> entirely different project, and which no sane person would call
> "Related to FreeBSD", takes up more than three quarters of the
> compile time.
>
> That is objectively absurd.
>
> The only reason we do that, is because we stil have that outdated
> "FreeBSD is src" emotional hangup.
>
> We need to find a contemporary and useful answer to "What is FreeBSD?"
>
>
> The only answer I can think of
> ------------------------------
>
> "FreeBSD is ports (some of those ports contain the kernel and
> userland)"
>
> As part of the migration, we yank LLVM out of the src.
>
> LLVM does not belong in src by any sane criteria, and any microscopic
> benefits of "tight integration" can be delivered with a
> "toolchain-llvm"
> (meta-)port.
>
> Our minimal install images will contain:
>
> The installer
> The kernel package(s)
> The userland package(s)
>
> "pkg upgrade" also upgrade kernel and userland packages - Welcome to
> the century of the fruitbat.
>
> The "normal install images will also contain:
>
> The src package(s)
> the source code built into kernel and userland packages
> The toolchain package(s)
> the package used to build the kernel and userland packages
> The ports package(s)
> the ports tree used to build the toolchain package(s)
> All distribution files necessary to build the toolchain package(s)
>
> (The "toolchain-llvm" (meta-)port may have to be a short-cut, to
> not have the llvm port drag in everything and the kitchen-sink,
> which would be /precisely/ the same as the llvm which lives in src
> today.)
>
> This distribution format is neither more nor less perfect with
> respect to reproducible builds and "Reflections on trusting trust"
> than what we have today.
>
> And yes, we have ports written in Rust, why do you ask?
>
> Poul-Henning
>
> PS: I overdosed on release work 25+ years ago, and have not been
> paying them much attention since, but if this is what the pkgbase
> crew has been pushing for more than a decade, we all owe them an
> apology.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99fe98c0974bc1778e26097eec3fc244>