Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 Mar 2019 20:57:32 -0700
From:      Frank Fenderbender <>
Cc:        David Christensen <>, Valeri Galtsev <>
Subject:   Re: FreeBSD desktop "best-fit" Dell platform suggestions?
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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".=20
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.=20
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.=20=

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).=20
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 =
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, =

That was an issue which adopted-specs would have defined & prevented (if =
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).=20
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.=20

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 =

best wishes,

Want to link to this message? Use this URL: <>