Re: It's not Rust, it's FreeBSD (and LLVM)

On 9/3/2024 18:16, Chris wrote:
> On 2024-09-03 12:36, David Cross wrote:
>>> On Sep 3, 2024, at 11:32 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> 
>>> 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.
> ...
>>>
>>> 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.
>>
>> As a quick note I constantly build freebsd from source. I do it for 
>> all of my
>> systems for all updates, all patch releases.
>>
>> I may be an outlier here, ...
> You're definitely not. I build world/kernel for the multitude of 
> servers (and home
> equipment). For the servers, I only need to do it once (per hardware 
> profile). Where I
> then simply make images and pour it onto the boot/storage media.
>
> In my opinion, the most attractive feature of the BSD's are that there 
> are so darned
> many options. There is no one-size-fits-all for anything, and the fact 
> that FreeBSD
> provides so many options to make/install/add/subtract/... provides a 
> near perfect match
> that tailors to anyone's needs.
>
> --Chris
>
I'll third that.

/One of the reasons I use FreeBSD almost-exclusively, /beyond my 
personal familiarity (I used it as the Unix "power" if you will behind 
my ISP in the 1990s) is that I can tailor it through the source build 
process quite-easily to multiple purposes.

My primary build and operating platform here is /always /built and 
updated from source, and has several versions on it as "worktrees" at 
any given point in time.  That in turn builds both release media /and 
/more-specialized "releases" that are more "appliance" like for specific 
purposes which are then deployed to various places.  Most of those are 
nanobsd (or Crochet, same basic deal) based because they need to be 
extremely power-fail tolerant and effectively operate, other than when 
saving configuration changes, without having to have an r/w mounted 
filesystem during normal operation.  Dual partition setup allows for 
"live" updating; update the non-running one and reboot.

I also have machines in-field that are binary updated with 
freebsd-update -- those systems are quite "vanilla" in terms of their 
requirements.  I also have systems that I want to and do update from 
-STABLE when commits come into the codebase but don't necessarily merit 
a "release-px" patch.

When llvm came into the tooolchain build times went vertical. 
Fortunately by then so had processing power and I/O performance for 
"reasonable" equipment, but please do not kid yourself on the impact -- 
it was extremely significant in that self-hosted builds on lesser 
machines became intolerable.  Today I crossbuild rather than native in 
some cases because I basically /have to /in order to get reasonable 
build times, and incidentally there's a hard-to-reproduce (and thus far 
no fix as a result) issue I have open from having to do it that way 
right now against some ARM systems 
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280038) that showed 
up with an LLVM fix for an issue that looks like it results in an 
alignment problem within LLVM in the target on the code that gets built, 
but disappears if you try to enable debugging symbols, assertions and 
even building with debug files (and then removing them before install.)  
Of course without symbols the backtrace is very close to useless in 
figuring out exactly where its segfaulting and with them included it 
doesn't blow up.  Would this be immediately able to be isolated in a 
native build (or even not happen as its an artifact of 
cross-compiling)?  I don't know, but at 12 hours a crack to try on a 
Pi3, if LLVM will even build at all on that due to RAM limitations, I'm 
not very inclined to try to find out.  My workaround for the present is 
to include the debug files -- but strip them from the finished media -- 
which makes the problem disappear.

Making that sort of problem worse, in my opinion, is to be avoided if 
the project can reasonably do so.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/