Re: It's not Rust, it's FreeBSD (and LLVM)
- Reply: Mark Delany: "Rust: kernel vs user-space"
- In reply to: Poul-Henning Kamp: "It's not Rust, it's FreeBSD (and LLVM)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 04 Sep 2024 08:46:24 UTC
Hello,
Few days ago I builded FreeBSD system with WITHOUT_TOOLCHAIN="yes" for use in VM.
Then I have a sly idea to use it for poudriere-jail: let integrate llvm18 package to 'installed' dir and we'll have job done.
I have no luck. I somehow put llvm18 into 'installed' dir (dir that ws DESTDIR for installworld) via 'pkg' -r but "poudriere bulk" failed to find a compiler. I stuck with googling 'use llvm from ports as default compiler'. This is what about using external toolchain nowtime.
After 15+ years of using FreeBSD I came to the viewpoint that 'FreeBSD is src' in a mean that 'src' is a self-sufficent and is able per se to generate ad hoc operating systems.
As for 'self-sufficent' I suggest to test any decision with thought experiment:
Someone get FreeBSD and build the system (world/kernel). Then he install builded system on servers. After 5 years he return and want to apply a patch and rebuild system. Would he be successful?
In case of ports I definetly answer: "No". Ports system told me to set ALLOW_UNSUPPORTED, then ALLOW_INSECURE, then it failed because certificates of sites changed and it didn't know fresh root CAs.
May be I just call for little more care for those who prefer long-lived systems.
Sorry for interfering in the conversation.
Tuesday, September 3, 2024, 6:32:00 PM, you 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.
--
Best regards,
Anthony Pankov