[conspire] Ye olde diagnosis

[Rick Moen]

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Tue, 19 Jul 2016 13:27:02 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Rich 
Subject: Re: Precious!
Organization: If you lived here, you'd be $HOME already.

Quoting Rich:

> I very much appreciate your comments, fully understanding time limitations.
[...]
> I'll take your suggestion and search for a local Linux support
> group. 

Hi, Rich.

These two things are closely linked, as it turns out.  Just to stress, I
am far from being offended; I'm flattered in a way that you asked.  That
being said, the Linux community relies very heavily on the process of 
diagnosis and the process of teaching being public, because individual
private help does not scale.  Aspiring helpers are aware that they could
spend the same amount of time and energy solving problems in public
forums such that the results and the example of debugging benefit many
people.  Consequently, use of such forums is heavily (but politely)
urged and private help seldom, almost never, extended.

The more-sarcastic (sorry, and no reference to company intended) way of
phrasing the latter point would be to say that individual private help
is more properly called 'consulting' and costs money because it ties up
resources to benefit not the community but rather one individual.

This is why the primary communication method, the main teaching channel,
the main medium used to help people's problems is mailing lists.  Many,
many LUGs (Linux user groups) operate those.  You as a computerist in a
small rural community in north Georgia _can_ if you wish participate in
any and all such forums, regardless of where in the world they are.  For
example, I participate in LUG mailing lists in Australia and Ireland,
among others.

_Some_ LUGs also support in-person installation-help gatherings, which
traditionally are called installfests.  These are now a bit rare, but
they do sometimes occur.  (What is vanishingly rare is the willingness
to do house calls.  Sorry.  ;->  )

Now, both I and my friend Eric S. Raymond noticed over the years many
people failing to get effective help on LUG and similar public technical
discussion forums, felt empathy towards such people, and tried to do
something about it.  Around 2000, we each discovered that the other was
writing an essay to help such folk, so we joined forces and wrote a
co-authored version instead.  It's here:
http://www.catb.org/~esr/faqs/smart-questions.html 
'How to Ask Questions the Smart Way', by Eric S. Raymond and Rick Moen.

I should warn you in advance, I consider this essay a failure even
though it's wildly popular and linked from the support pages of
thousands of technical projects.  Why?  Because it's so long-winded
that the people who'd _most_ benefit from it, don't.

It didn't start out long-winded, but grew that way because we
good-naturedly complied almost every time someone wrote us and said 'You
should also cover [foo].'  Also, probably the essay's linear structure 
makes it inefficient to read on occasions when you would benefit from
what it says.

The reason I thought about Eric's and my essay, reading your description
of your problem, is that reading said description revisited on me the same
sense of frustration at inability to help you for lack of meaningful
information that impelled me to co-wrote the essay.  Let me quote one
passage that is among those I wrote for it:

  "All diagnosticians are from Missouri."  That US state's official motto
  is "Show me" (earned in 1899, when Congressman Willard D. Vandiver said
  "I come from a country that raises corn and cotton and cockleburs and
  Democrats, and frothy eloquence neither convinces nor satisfies me.  I'm
  from Missouri.  You've got to show me.")  In diagnosticians' case, it's
  not a matter of skepticism, but rather a literal, functional need to see
  whatever is as close as possible to the same raw evidence that you see,
  rather than your surmises and summaries.  Show us.

(Pardon me for quoting myself.  I'll freely admit sometimes having an
unseemly love of my own writing.  In this case, though, it's also
relevant.)

The entirety of the diagnostic data you supplied amounted to 'didn't
work right':  Fedora 20 didn't work right.  Precise Puppy worked right.
Some live CDs worked right, others didn't.  The live CDs that worked
right, didn't work right upon installation.  CentOS 5 worked right,
CentOS 7 didn't.  MATE-Compiz on some unstated distribution 'failed'. 
Which _particular thing_ went wrong during installation, though?  What
does 'didn't work right' mean explicitly?  What does 'failed' mean?
What was the raw, specific symptom?  You don't say; probably you don't
remember and/or didn't collect meaningful information at the time.
There's an ambiguous suggestion that graphics might be involved, but
even that is unclear.  It might involve 'jitter', which I would guess
offhand means flickering, but even that is just a guess.  Any time your
helpers are reduced to guessing for lack of data, you're basically in
trouble.

Nobody could possibly diagnose that problem, described the way you have.  
All that aspiring helpers could do would be to throw you random, poorly
aimed suggestions that _might_ help, but might not, because your helpers
have no real idea what your problem actually is.

Let me take an educated guess that your installation problem involves
some aspect of video support.  If we were serious about a diagnostic
session, you would logically have started with:

1.  A specific, accurate recounting of the raw symptoms in chronological
order, that you recorded contemporaneously to the installation
attempt(s).  (Attempting to remember those data retroactively is almost
always a bad idea.  I was slow to realise how often people trying and
failing to get technical help are attempting exactly this, or I'd have
warned more strongly against it in Eric's and my essay.)

2.  The specific make and model of your computer, and ditto of your
monitor.

If you consult a LUG mailing list, please make sure you include that.
Also, if you feel like skim-reading Eric's and my essay, it couldn't
hurt -- though I know it's irritatingly long, the last thing anyone
frustrated by a problem thinks he/she needs while engrossed in
attempting to solve that problem.

In the category of throwing you a random, poorly aimed suggestion that
_might_ help, but might not:  Booting a really cutting-edge live CD is
an excellent tool for gathering data.  One such, released quarterly, is
Siduction:  http://distrowatch.com/table.php?distribution=siduction
There are eight desktop flavours of that CD; for diagnosis purposes, I'd
recommend the one with the least-complex desktop software, the Fluxbox
one.

You attempt to boot the live CD.  Either it boots at least to the
console (text-mode) environment or it doesn't.  If it doesn't get at
least that far, diagnosis is more-difficult, but you should see clues
near the bottom of the scrolling startup display.

After console startup, the CD (as usual) attempts to start X11 and its
default desktop (say, using Fluxbox).  Either X11 runs or it doesn't.
If it doesn't, then you can still login at the text console and use
basic Linux command-line tools to collect information.  For example, the
output of 'lspci' will include the exact identity of your video chip.

(By the way, posting the specific make and model of your computer will
permit Linux experts to determine that video chip identity from online
information.  You can do that yourself with a little practice.)

If X11 _does_ start up, then again you can open a terminal and use tools
like 'lspci' to collect hardware and other diagnostic information --
except in this sub-case you would also know for certain that supporting
your hardware on current Linux is a highly solvable problem, and all you
need do is figure out how the live CD is doing it.

A brief note about Compiz.  As you perhaps are aware, it is a '3D'
desktop layer, what is called a 'compositing' window manager
(https://en.wikipedia.org/wiki/Compositing_window_manager) that can be
used in place of more conventional window managers in Desktop
Environment (DE) software such as GNOME2 or KDE.  (MATE, which you've
encountered, is one of two projects contrived to better serve fans of
old GNOME2 aesthetics as backlash against the widely-hated aesthetics of
GNOME3.  The other such project is called Cinnamon.  Both are
approximately a re-creation of the GNOME2 user experience using modern
GNOM3 software infrastructure, though they do this in different ways.)

Compiz makes heavy use of calls to OpenGL
(https://en.wikipedia.org/wiki/OpenGL) graphics library software for
the 3D visual effects.  There are competing compositing window managers,
such as Mutter in GNOME3, KWin in KDE4, Xfwm in XFCE, and Enlightenment
(https://en.wikipedia.org/wiki/Enlightenment_(software) ).  Compiz is
part of the default (and likewise widely hated) 'Unity' user interface
in the main (GNOME-based) flavour of Ubuntu Linux.

As it turns out, not all video chipsets OpenGL capability usable from
Linux's open source Mesa 3D libraries
(https://en.wikipedia.org/wiki/Mesa_(computer_graphics) ) that drive the
OpenGL functions in desktop Linux.  Moreover, sometimes fully enabled
OpenGL can be tricky to get going, most often because of uncooperative
video manufacturers (such as Nvidia).  

My point is that Compiz and competitors are not a _necessary_ part of
graphical computing on Linux, though there's nothing wrong with liking
and wanting them.  But they're a frill, an extra:  Getting them to work
is an additional complexity / challenge above and beyond just getting
Linux desktop graphics going.  For example, successfully booting and
playing around with the Fluxbox variant of the Siduction live CD most
emphatically does _not_ test and validate the ability to do 3D visual
effects.

But the advantage of starting with _simpler_ diagnostic tools like a
Fluxbox-flavoured Siduction live CD is that you can either validate 
or find problems in basic functionality, and maybe isolate where your
problem originates from where it doesn't, before going for gold and
attempting to make a whole marching band work all at once.

For whatever it's worth, I personally stay far away from all DEs
(desktop environments), and especially far away from all DEs that have
anything to do with GNOME.  That includes GNOME3, MATE, Cinnamon, and
Unity.  It even includes XFCE, because that DE is about 80% the same
code as GNOME.

Why?  Because in my experience DEs cause a lot of operational,
system-administrative, and setup trouble, and give me nothing I actually
want -- and all GNOME variants are a huge source of trouble, more than
all the rest.  But you are most certainly welcome to make up you own
mind.  The alternative to a DE is just a window manager.  I personally
like a window manager named Window Maker, though there are countless
other good ones.  See http://xwinman.org/ for more.

More links:
https://en.wikipedia.org/wiki/X_window_manager
https://en.wikipedia.org/wiki/Desktop_environment
https://en.wikipedia.org/wiki/Window_Maker

None of the above solves your problem.  Sorry about that.  But it's all
I've got.  I hope it helps.

----- End forwarded message -----
----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Wed, 13 Jul 2016 16:25:52 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Rich 
Subject: Re: Precious!
Organization: If you lived here, you'd be $HOME already.

Quoting Rich:

> Hi Rick:
>
> I think we could work together, except you're nowhere near me, and
> my skillset is 180-degrees out of phase with yours. I'm either an
> Engineering Technician or a Lab Technician ('lab rat') depending on
> the situation. I very much enjoy your candid, totally realistic,
> down-to-dirt logic and reasoning.

I'm sorry, but I don't have time I could spend on this.

Your account didn't include any diagnostic data about the nature of the
failure to install.  You might be able to collect the necessary data at
that time by just checking on the other consoles (do Alt-F2, Alt-F3,
etc., and then go back to Alt-F1 when done) to see what the specific
problem is.

A common error is to be overly optimistic about Linux driver support for
spanking-new hardware chipsets.  In a subset of those cases, the problem
is that, even though there's a working driver, it requires a binary
firmware file that the hardware manufacturer doesn't permit Linux
distributions to distribute (which thus would be copyright violation).

An example:  I worked six years at an Internet company where on Day One
they gave me a Dell Optiplex GX620 workstation.  I attempted to install
Debian on it, and found that its Broadcom 57xx gigabit ethernet
controller's driver loaded but did not pass traffic.  A little
investigation uncovered that Broadcom Corporation doesn't permit
Debian (or anyone else) to distribute necessary firmware file
'bnx2x.ko', but you can download that file separately.  So, I did so,
put it onto a USB flash drive, and supplied it during Debian
installation.  https://wiki.debian.org/Firmware

What you might wish to do is download and burn to CD a really good 'live
CD' distribution, boot it on your hardware, and see if it supports
everything.  If it does, study what drivers are loaded (lsmod, lspci),
and you should be able to determine what has gone wrong in your
installation attempts.

What you _really_ are best advised to do is seek _local_ in-person Linux
help from a Linux user group on your area.


----- End forwarded message -----