[sf-lug] updates Re: SF-LUG Sunday March 3, 2019 meeting notice

[Rick Moen]

Quoting Bobbie Sellers (bliss-sf4ever at dslextreme.com):

> I think I will want the alternative Debian iso files.

Sure, all yours.  Here's what I have at the present moment:

Liten-Datamaskin:isos rick$ ls -lh debian*.iso | awk '{ print $5 "  " $9 }'
2.2G  debian-live-9.8.0-lxde+nonfree-amd64.iso
2.2G  debian-live-9.8.0-lxde+nonfree-i386.iso
2.2G  debian-live-9.8.0-xfce+nonfree-amd64.iso
2.2G  debian-live-9.8.0-xfce+nonfree-i386.iso
3.4G  debian-unofficial-with-nonfree-firmware-9.8.0-amd64-gnome-dvd1.iso
327M  debian-unofficial-with-nonfree-firmware-9.8.0-amd64-netinst.iso
3.5G  debian-unofficial-with-nonfree-firmware-9.8.0-i386-gnome-dvd1.iso
413M  debian-unofficial-with-nonfree-firmware-9.8.0-i386-netinst.iso
Liten-Datamaskin:isos rick$

Descriptions of those from my collection's README.txt file:

Liten-Datamaskin:isos rick$ grep Debian README.txt
Debian-unofficial-with-nonfree-firmware 9.8.0 'stretch':  i386, amd64:  GNOME DVD, netinst,
Debian Live:  i386, amd64.  LXDE, XFCE.  Credentials user, live (has sudo root).
Liten-Datamaskin:isos rick$



BTW, I rename all ISOs to have filenames following the scheme 
'name-version-architecture-flavour (and I impose lowercasing so
that 'ls' shows them in the right order without special tricks).  
Each ISO has a few files that go with it, as I'll illustrate with the
AMD64 GNOME DVD:


Liten-Datamaskin:isos rick$ ls
debian-unofficial-with-nonfree-firmware-9.8.0-amd64-gnome-dvd1*
debian-unofficial-with-nonfree-firmware-9.8.0-amd64-gnome-dvd1.iso
debian-unofficial-with-nonfree-firmware-9.8.0-amd64-gnome-dvd1.iso.gpg
debian-unofficial-with-nonfree-firmware-9.8.0-amd64-gnome-dvd1.iso.sha256
debian-unofficial-with-nonfree-firmware-9.8.0-amd64-gnome-dvd1.iso.sha256-original
debian-unofficial-with-nonfree-firmware-9.8.0-amd64-gnome-dvd1.verification
Liten-Datamaskin:isos rick$


The '.sha256' holds a single checksum line (edited down to just that one
line by me) that can be used to verify download integrity.  The
'.sha256-original' and '.gpg' files are verbatim download files usable
to verify authenticity against the release signing key.  And the
.verification file is where I document (1) where this stuff was
downloaded from, (2) showing SHA256SUM verification, and (3) showing 
how to verify authenticity.  (In vetting all of my ISOs, I found there
was a lot of variation in the verification procedure, and often poorly 
documented -- so I've documented that for each ISO.

Having explained that scheme, here's this ISO's .verification file:


---<begin>---

# Source: # https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/9.8.0+nonfree/amd64/iso-dvd/

$ shasum -a 256 -c debian-unofficial-with-nonfree-firmware-9.8.0-amd64-gnome-dvd1.iso.sha256
debian-unofficial-with-nonfree-firmware-9.8.0-amd64-gnome-dvd1.iso: OK

$ gpg --list-keys 6294BE9B
pub   rsa4096 2011-01-05 [SC]
      DF9B9C49EAA9298432589D76DA87E80D6294BE9B
uid           [ unknown] Debian CD signing key <debian-cd at lists.debian.org>
sub   rsa4096 2011-01-05 [E]

$ gpg --verify debian-unofficial-with-nonfree-firmware-9.8.0-amd64-gnome-dvd1.iso.gpg debian-unofficial-with-nonfree-firmware-9.8.0-amd64-gnome-dvd1.iso.sha256-original
gpg: Signature made Sat Feb 16 13:32:07 2019 PST
gpg:                using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: Good signature from "Debian CD signing key <debian-cd at lists.debian.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B
$

---<end>---


That doesn't document the answer to the (important) question 'How do you
find out what's the right signing key, and where to get it?', which
frankly is a weakness practically everywhere, but otherwise these files
illustrate fully where the files came from, and how anyone can verify
that they're intact and genuine.

I submit that this scheme is a bit of an improvement over what most
people do.  (I wanted where possible to not only have done things 
right for users, but be able to prove and and help them check.)  
What my collection _doesn't_ have -- because I went for the low-hanging
fruit -- is concise information about what each ISO is best suited
for, suggested minimum hardware, quirks people should know about, 
etc.  I can imagine (in future) the collection sprouting a set of
accompanying Web pages in a subtree, and an index.html file inside the
main directory replacing the existing README.txt.  Then, people can
thumb through the collection _including_ local Web pages using a 
Web browser, deciding what they want on an informed basis instead of the
typical 'I've heard of $FAMOUS_DISTRO_DU_JOUR, so I think I want that.'


[my somewhat unfair comment about Tiny Core Linux and antiX:]

> AntiX is not exactly a micro-distribution.

You're right.  A point well taken.

I was reaching for an example and almost said 'DamnSmallLinux', which in
years past I know that SF-LUG has helped people install onto slightly
old computers that would have been perfectly fine with, say, properly
configured Debian _without_ a DE and with other obvious measures taken
to not waste RAM.  At the last moment, I remembered that DamnSmallLinux
has now been discontinued for a few years, so I needed a different
example and picked antiX.

I like antiX.  It's nowhere near as limited as it used to be.  In fact,
in writing this follow-up, I've read up on the recent versions and found
that all of the reservations I used to have about it no longer apply, 
so I take back what I said (because things have changed):  For someone
with a PII or PIII with less than a gig of RAM in the year 2019, it's
quite possible one _cannot_ do better than antiX for desktop duties.


> But I got KDE to run on a 700 MegaHertz Coppermine back in the day
> with 384 megabytes of ram and 8 megabytes of video ram.  Mandriva
> 2009.1

I've 'gotten things to run' in too-little RAM, too -- but that doesn't
mean I should have.

Also, talking about 'back in the day' has little or no relevance to
present reality.  Try current KDE5 Plasma with less than 2GB of RAM, and
you'll be appalled.  (Again, you can 'get it to run' in 1GB, but you
will be profoundly, profoundly unhappy.)


> Some of the users I see make me sad because they think they know it
> all and will not listen to sensible advice gained by somewhat painful
> experience.

It's always been the case that some people learn only the hard way.
There's also a psychological thing that surrounds all user groups:  A
large fraction of the population do not grasp how a 'gift economy'
works, and never will:

'Gift economy' is a concept from anthropology, where people build
relationships through giving items of value, and prestige is achieved
through the scale of one's generosity.  In the figurative sense of the
word, all user groups function as gift economies:  We give away for 
free something valuable, hard-won understanding and insight into what we
work with.  As we ex-accountants would say, implicit in this way of
looking at the world is the related concept of 'usage value' -- that
things (including information, and software) should be valued at what
can be achieved with them, instead of being valued at acquisition cost.

The problem is that 90%+ of the population is deeply acculturated to
always, always, always apply the metric of acquisition cost.  Things,
software, information, everything is to be assumed to be worth whatever
it cost to acquire.  That thing that cost me a fortune?  Obviously
proven to be valuable.  On the flip side, that advice I got for free?
Must be worthless!  If it weren't worthless, why wouldn't it have had a
nice, high price tag?

People with a particularly severe case of this mental framework are easy
to spot around user groups:  They are the ones treating careful advice
with disdain, and complaining that people aren't hopping more quickly to
solve their problems.  They're treating people's time and effort as
without value because it's offered for free.

There are some obvious ways to deal with this issue.  One, that's
poetic justice but otherwise might not appeal, is to say 'Oh, right! 
What you actually are seeking is paid private consulting.  My rates are
$115/hour plus materials, two hour minimum.'  This assumes you're
willing to have the person as a customer, of course, which is the hitch.
Escalate the hourly rate until you reach a level where you can stand the
person.

The less showy alternative is to just politely cut off the person and
say 'Good luck with your approach.  Let us know how doing it your way
turns out, but I'm afraid I need to turn my attention to other people.'


[LFS 8.4:]

> I hope you are correct but Distrowatch is only advertising
> two versions both marked as systemd.

Well, load https://distrowatch.com/table.php?distribution=lfs and look
at the '8.4' and '8.4-BLFS' columns in the table of releases.  On the
line for init software,  it says 'systemd, SysV' for both the LFS and
BLFS implementations of release 8.4.

Disclaimer:  I'm not a LFS guy at all.  My attitude is that LFS is what
we all had to do in the dark days of 1992-3 before we heard about
Slackware[1], and I'm glad I don't _have_ to any more.  So, anyway,
maybe what I think I see on DistroWatch is mistaken or I'm
misinterpreting.  Can't really say.


> The problem is that experienced users tend to shun LUG meetings which
> was not the case when I joined the LUG meeting at JavaCat cafe back in
> the mid-2000s. Some have died, some have suffered in the late
> Recession, some had to move to find work and some San Franciscans
> cashed out there property and went elsewhere.   Others doubtless find
> talking about the problems of newer users boring.

Well, you've heard even me voice my frustration because the very most
American thing about me is that I want to believe in progress, and after 
being involved in LUGs since the concept was invented, people at LUGs 
are still making the same hapless stupid mistakes they did back in the
early 1990s.  Some days, it seems like nobody ever learns a blessed
thing, and that all I've done is waste my time for decades and have
absolutely nothing to show for it.

Then, as a silver lining, I remember the not-insignificant number of
people I've taught to 'get it', and that the Inevitble Ones who never
learned a blessed thing and keep shooting themselves in the foot are
ones we'll always have with us -- but that nothing would have gotten 
them to stop violating the First Rule of Holes in any event.

Like people still trying to use Pentium II and PowerPC Macintoshes for
serious computing in 2019 when modern late-2010s laptops are available
for $100 on Craigslist.  ;->


[Ubuntu-specific forums:]

> There always seems to be a few people who have experienced similar
> problems and have a solution, sometimes now obsolete.

I've often been even more appalled by the solutions than by the
problems.  Example:  The recent Ubuntu issue caused by the optional
systemd-resolved daemon's inability to correctly handle some DNS
information because, basically, systemd-resolved is terrible code that
nobody in his/her right mind should be using, and that has no compelling
use-case in the first place.

The matter showed up this past December, and Ken Shaffer among other
people was talking about it.  The reported diagnostic message was
'Cannot resolve mail.comcast.net', and upon examination this was caused 
by systemd-resolved being unable to convey DNS answers bigger than 512
bytes, which is a bonehead programming error.  My point is that the
online Ubuntu-specific forums were reverberating with _awful_ solutions
like 'just substitute mail.comcast.net's current IP address in your
e-mail program' (i.e., do without DNS entirely for e-mail, just because
one terrible piece of optional system software cannot resolve it
correctly).  There is not enough, er, adult supervision on places like
ubuntuforums.org to make the obvious counter-suggestion:  Disable
systemd-resolved in /etc/nsswitch.conf, because it's just no good and
there's really no benefit to using it in the first place.

I _did_ say exactly that on this forum in December, but I'm not sure
Ubuntistas took what I said seriously.  Probably a few reasons: (1) the
aforementioned widespread dismissal of perceived value in what is
received for free.  (2) The error of thinking 'If Rick were correct, then
wouldn't this also be the standard advice on Ubuntuforums.org?'  (No,
because Ubuntuforums.org and alt.os.linux.ubuntu are where bad advice
goes to hang out with other bad advice, and not get lonely.)  (3) The
Church of Mark factor -- the Ubuntu analogue of the Church of Steve
effect observable among MacHeads during the Steve Jobs comeback years
(that continues even though he's gone).  This is the 'If it were a good
idea to disable the systemd-resolved service, then surely Benevolent
Dictator for Life Mark Shuttleworth would have decreed that it shall be
so.'  (No, guess what?  Canonical, Ltd. often makes pretty bad
decisions, such as in this case getting suckered by inept
Freedesktop.org coders.  Most other distros including Ubuntu's parent 
distro Debian do _not_ enable systemd's optional systemd-resolved
daemon, and now you know why:  Because it's buggy junk, and also lacks a
reason to be there at all.)

If indeed the reported 'problems with 18.04 LTS' (paraphrased) that
inspire a desire to install, instead, in 2019, the _previous_, already
three-years-outdated LTS release, are mostly like that one, then I am
even more bemused:  If the takeaway is that Canonical, Ltd. has bollixed
key parts of system architecture in 18.04 LTS, then wouldn't the logical
migration targets be something _non-Ubuntu_?  Like, dunno, maybe Linux
Mint, or something like that?  Deciding the right solution is 
_really old_ Ubuntu seems really bizarre.


> There was a mistake made recently in a bundle or perhaps bumble of
> updates that wiped out the ability to use WiFi on my main
> installation.  I gave up and moved that drive from my computer, put in
> a new drive and got my WiFi back again.

See, if that happened and a detailed examination failed to find a good
explanation, that would make me concerned about the distribution
project, and considering using something else entirely.  Distros that
have been confirmed to have bollixed QA in something important once are
rather likely to do it again and again.

I don't follow the travails of *buntu users closely because I really
don't care for any of their DE flavours and consider them to be clearly
inferior to other choices for a variety of reasons, so if this were a
well-established thing that they truly did screw up QA on important
system update packages, I wouldn't have heard.


> Frequently I mention LUGs or other user groups as solutions to
> problems on Usenet.  and in private correspondence to other users,
> describing how I found SF-LUG and the assistance it offered to me in
> my early Linux days.

It's generous of you to discuss people's problems (I gather) in private
correspondence.  Without objecting in any way (of course), I'll mention
in passing that it doesn't build communities, a point I'll get back to
below.

[problem 'because of updates to the libraries':]

> The user is pretty specific thus the quote that follows:
> 
> >Me and a friend had to leave our webhoster due to closing down.
> >So we went to a new one, running some ubuntu servers (16.04 LTS) and
> >everything was fine.
> >
> >B.t.w., we are "normal" customers without root privileges, living on a
> >"shared hosting system" among several hundreds of other customers.
> >
> >I was able to install Squirrel Mail (1.4.22) locally and therefore select
> >php 5.2 for the relevant directories. Php 5.4 would also fit, but we took
> >5.2. Well, but:
> >
> >A few days ago we got a message from our hoster, saying they intend to
> >switch to a new release soon, I think it's 18.04 LTS.
> >
> >They say that from now on php will only be available in version 5.6 and
> >above, and, since php 5.2 - 5.4 cannot use the new ssl libraries (?) etc.
> >anyway, hence it will no longer be selectable.
> >
> >As an alternative they offer "roundcube" as email / imap client, but its
> >functionality, handling and flexibility is far below Squirrel.
> >Besides this, the friend I mentioned is "70+" and I don't want to force
> >him to "learn" a new email system.
> >
> >So, please let me ask some questions:
> >
> >Is there a way, a trick, to get php 5.2 - 5.4 to work in the new ubuntu
> >release, also?
> >
> >Does someone know about a newer version of Squirrel Mail, which is
> >compatible to php 5.6 or even better 7.x?
> >
> >Any idea how to proceed?

It took me all of five seconds to visit the SquirrelMail upstream
developer site and see that SquirrelMail post-1.4.22 development
snapshots compatible with PHP 5.5 became available starting... wait for
it...  May 30, 2013.  

So, I'd say that user is indeed 'specific', but not what I'd call
talented at problem-solving.

If the user gets around to thinking a little further, he/she might
eventually wonder if it isn't a bit dicey hitching one's star to a
project (SquirrelMail) that hasn't had a full release since July 21,
2011.  Which is one reason why various levelheaded people immediately
suggested Roundcube.  (User doesn't like Roundcube as much because it's
not as much of feature-checklist marching band as is SquirrelMail.  
Gosh, one cannot help noticing that SquirrelMail has been very spottily
maintained and also has had much more frequent and more severe security
meltdowns.  Could there be a connection between these curious facts?)

If he were _really really_ thinking, he'd maybe realise that PHP is
extremely security-problematic when exposed to public networks, and that
old versions of OpenSSL are also bad news albeit not as bad as PHP, so
if he's shocked and indignant about forced upgrades to new PHP and
OpenSSL versions, he's not been paying attention.

And that, in turn, might some day make him start questioning relying on
public-facing PHP codebases such as SquirrelMail, particularly codebases
that he adores because of their being feature-rich.  Highly featureful
and security-risky code living on the public Internet is not a story
that tends to end well.


> So that is stuff on which my advice would be is to use Thunderbird or
> another mailer/news reader but I doubt that would make the user happy.

Indeed.  Many people, confronted with a software problem, think their
best solution is to complain loudly and demand that other people,
usually people they're not paying, work hard to ensure that their choice
of software and version, run in the manner of their choosing, act the
way they want.  

You cannot help some people.  But you can point to the liferaft and say
'Board or drown.  Your choice.'


I also said I'd circle back to the matter that private correspondence
doesn't build communities, so I will.  I appreciate your citing the
SquirrelMail user as an example of Ubuntu users unhappy with 18.04 LTS
and wishing for the continuation of 16.04 LTS days of yore.  You were 
_not_ asking me to solve his/her problem, and I'm very much not
suggesting you were trying to invite that.

Some _other_ people, who are not you, occasionally think they have a
super-bright idea.  They know someone who needs Linux help, but is not
willing to subscribe to a LUG mailing list (or participate in a Linux
newsgroup) to get help in a public forum, _and_ is either unwilling or
unable to attend LUG meetings.  So, this other person's bright idea is:  
LUG housecalls!  _Or_, the needy person sends the other person mail, who
posts it to the LUG (or Usenet) forum, and the other person shuttles
back the answers.

The bright idea thus amounts to:  Needy stranger isn't willing to
participate in the LUG, but let's bust our tails solving the needy
stranger's problem anyway -- without the (often essential) opportunity
to interact with said needy stranger in order to do diagnosis and arrive
at a remedy.

Now, other folks here are perfectly welcome to piddle away available
time and energy any way Works for Them[tm], but I reserve my LUG 
time and resources for people willing to participate in the LUG, trying
to 'pay forward' in gratitude for people who have simiarly given
generously to help me -- and knowing that that process works properly,
and builds the community, only if other LUG members can learn from the
problem, the diagnosis, the questions, the answers, and the solution.

This other thing is properly called 'consulting', and there's a two-hour
minimum at professional rates if available at all.


[1] Excitable detail freaks who recall that there were several earlier
distros, all now defunction that preceded Slackware:  Please don't bother
weighing in to 'inform' me about that.  Yes, I know.  At the time, a
bunch of us were still building up systems from things like H.J. Lu's
boot & root floppy images, and hadn't heard about early and then-obscure
distros like MCC Interim Linux, SoftLanding Systems Linux, TAMU Linux,
and Yggdrasil.  We heard about those typically after we heard about
Slackware, and said 'Oh yeah?  Cool.  Pity we hadn't heard about those.'