FreeBSD desktop "best-fit" Dell platform suggestions?

[Frank Fenderbender]

David, Valeri:

Thanks for addressing my first email, "FreeBSD desktop "best-fit" Dell platform suggestions?". It mysteriously took on punctuation & spelling errors despite passing the spellchecker's "know-how". 
So much for the AI at the core of the anti-human Transhumanism movement.... ;-) You were kind to wade through the mistakes. Thanks.
I shortened up a second email question, "desktop [install- or configur-]ation issues on Dell workstations?", to address the same issue but with less clutter. 
Here's my response to your response to my first email about the possibility of installing FreeBSD on a compatibility-tested Dell (or any system for that matter):

---

[cr]Apple, before and after their A.I.M. (Apple-IBM-Motorola) association, was similar to "on-demand" manufacturing companies like Dell (who fill their boxes with what is available that meets base criteria), because they never put in enough or qualified capacitors, and so, had a rash of supposed circuit board burnouts (which sold more computers) which would have been alleviated by replacing $19 worth of over-priced caps, which few these daze could ever troubleshoot, let alone replace... what with most tech schools buzzing around the iNtel RISC-free copper-free chipsets. I was lucky and found DT&T in Pleasanton CA for restoring boards.

So, Dell and FreeBSD sound iffy, but then, no list seems to exist whereupon any standardized test suite has run against any documented platforms to verify that all modules installed properly and form a fully-working [thus, "operating"] system afterwards. That would be a rarity for any OS these daze. [cr]Apple avoids ALL testing so that sales are not slowed: a marketing-driven company. No class. No quality. Only fashion walkways and gimmicks. No innovation whatsoever. Colors. Shapes. An assembly-line of connectors to outdate predecessor systems. Constant memory leaks. No regression testing at all. No release testing at all. 

They would be so easy to surpass if everyone here created a system/driver/configuration spreadsheet with "issue" hyperlinked out to a database of verified and reproducible solutions.

Has anyone seen or attempted such an undertaking.
It would be have use very much like a bug-tracking system.
And, with a curated list of componentry (hw and sw) it could alleviate redundant question like my own.
I am not prepared to go through another installation debug, esp. when I have no base with which to compare.
I tried and failed at FreeBSD, OpenBSD, and TrueOS server installs on my dual-NIC, four internal 2TB HDDed server.

Maybe luck, experience, or the install procedure, I "got it" with Ubuntu the first time after trying (and painfully learning what bait not to bite at) the BSD installs, true, but had to correct the error-riddled/unedited/visibly-impaired/unverified/untested book by the need-parasiting Kefa Rabah in his "The Book Everyone Has Been Waiting For" self-anointed book, "The Ultimate Linux Ubuntu 16.04 Powered Media Streaming & Storage Servers" (2019; 380pp). 
I had to go back to the "100 flavors of vanilla" internet to seek a solution from all those who did not document the systems onto which they were installing.
The sharing is wonderful, however, diseases are also shared, as are bad science and qualifiable process methodology.

The problem I had with the BSD installs was the issue of engaging the extended installation of add-ons. Next time I shall avoid them all. None are tested at all.
It's like buying a "new" car that needs every part adjusted to all other parts. A lifetime of tinkering that shouldn't be necessitated at all.
The dependencies are never verified and neither are the version conflicts.
For starters, a "BOM" is needed that shows every file, folder.permission, and link that SHOULD be created at install-time, and then verifies that they did get created as intended.
Secondly, with any add-on, each should also have a BOM of all requirements and all other modules with which it may conflict.

At Intel, our split development team was using two C compilers, Borland and Microsoft, which used different clocking systems: Microsoft time started with seconds from at 1900; Borland, like UNIX, began January 1, 1970.

That was an issue which adopted-specs would have defined & prevented (if followed).
As well, when tools were added, a DLL wasn't noticed that conflicted with our product-defined DLLs. Whenever a feature kicked in that used the conflicting DLL, the problem would appear.

At Analogy we used BOMs and ran test suites in reproducible NT, AIX, SunOS, Solaris, and HP-UX environments using Norton Ghost (for NT) and equivalents for UNIX systems. The registry was defaulted after each NT suite and the user was erased after and recreated before each UNIX run.

At Network general Corporation, every install step (and check) was documented and verified against the documentation and the reality of the install and tests. We would run (pre-IBM, pre-Rational) versions of Purify and PureCoverage on every supported system's code, tests, and installs. Nothing is perfect, esp. software, so we tried to be consistent in terms of improving the calculus of building-and-releasing. You know, as quality approaches infinity, bugs approach zero... or so the theory goes. ;-)

Many "tolerated" issues did not exist at Tektronix or Mentor Graphics Corporation, because they had a process integrated with the whole and "pieces" of every product release, covering hardware, covering software, covering partnered-code integration, covering hardware-software integration, and finally, as a fully-integrated system of modules, functions, and I/O.

It "only" takes that first time to get it into place and then the time saved easily allows for updates and improvement: build, acceptance, regression, GUI, button/knob, load, voice recognition, BETA, and release test suites, made with scripting languages (Expect, Tcl, Perl, Korn, Bourne, Csh/Tcsh), GPIB, sed/grep/awk/cat/find built-in functions, with results converted into both email and HTML, so that appropriate builders, developers, and managers got notified). 
No one by themselves has that kind of time to, so maybe we can proactively address the proverbial-"it" as a community rather than reactively as a list of issues.

So, it can be done, and the time "in" saves so much, much time "out" chasing bugs. The suites can be run via distributed tests run on "standardized" systems throughout the throughout the [secured] FreeBSD community. Because it's distributed the tests run concurrently rather than sequentially.I'm going to be running the same set of tests on all software I create, and so, would happily work with others to make a set of suites that is portable for all of us to use, modify (in a repository) for varied purposes, and document.

Anyway, this time I'm installing none of the "add-ons" and following Michael Bernal's "A Comprehensive Installation & Configuration Guide of the BSD variants" (2018; 68pp) for its brevity and clean install. 

Thanks to you both for your comments and suggestions. I appreciate the effort and will document and report-on the process I use.
I'm going to order the Dell tomorrow after adjusting to re-reading your comments.

best wishes,
Frank
frankfenderbender at council124.org