[sf-lug] SF-LUG meeting notes for Sunday March 3, 2019

[Rick Moen]

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

> It was a watery day on Geary Blvd. but warm and dry inside the
> Cafe Enchante.

As they phrase it in Ireland, it was 'soft weather', only to be called
rain if, say, you're a housecat.  ;->  (Our kitty here at Maison Moen
goes psychoceramic with any drizzle, and is currently keeping us busy
going in.  And out.  And in.  And out....

>      During the course of the meeting John tried out several distributions
> including the EasyOS 1.08, Beta 2 of Mageia 7, and perhaps DarkStar's
> compilation of PCLOS64 KDE-5 of 2019.03
>     There were problems with each due to failure of the system
> to automatically adjust to the 4K Display on his advanced laptop.

I was unaware of this sequence of events, or I would have said
something.  So:

Um, you cannot expect Linux distros' treatment of hardware to be always
100% automagical.  You just can't.  That is not 'failure', and I'm a bit
dismayed at the notion of abandoning an entire Linux distribution just
because the default X11 setup was one that would need subsequent manual
adjusting.

And, moreover, after the second distro 'failure' [sic], shouldn't the
takeaway message have been clear that John would (probably) need to 
do manual adjustment of his X11 configuration, _irrespective_ of how
many Linux distributions he default-installed and then chose to discard?

The above account is a bit disappointing, because the obvious remedy is
and was to stop and do half an hour or so of Internet research about how
to optimise X11 setup on that screen.  John might even luck out and find
that someone has already posted tips for his specific make/model of
laptop unit, making it easy.

But, just blowing away entire distro installations repeatedlyi, three
times over,  rather than do the obvious, and _still_ walk away having
accomplished nothing?  That's sad.


>  Joseph P. showed up and at one point was engaged with Rick Moen,
> for a considerable portion of the meeting, discussing alternatives to
> his present computer hardware situation and the use of Linux to
> replace MacOS on an older PPC powered machine.

Joe Puig and I have been friends for well over 30 years, in case you
didn't know.  (I didn't know until a year or two ago, though, that his
surname is Catalonian.  (Viu Catalunya lliure.)

> As Rick pointed out in his email to me and to the list, sometimes the
> basic iso files from Debian lack drivers.

{sigh}  No.

Not _drivers_, but rather proprietary _firmware files_ required before
some open source drivers can function.  Debian Project has a policy that
the main package collection, comprising Debian proper, must consist only
of open source code.  This policy also affects Official Debian
installation ISOs.

Cast your mind back to the 1990s.  Every ISA or PCI or VLB or PCMCIA
card included built-in option ROM chips containing low-level code to 
initialise the card during boot-up time (or, for PCMCIA, at the time you
insert it), to activate the hardware.  In the late 1990s, somebody at a
hardware company had a small brainstorm:  'Hey, we can save $0.10 per
card by omitting the option ROM chip, and instead furnishing the same
low-level code separately as a file, and expect system software to load
that code at startup time.'  So, that has now become the norm.

Essentially all of these 'firmware BLOB' (BLOB = Binary Large OBject)
files are manufacturer-prorietary, except for a few shining exceptions
like one series of wireless chips where the OpenBSD people
reverse-engineered them and wrote replacement firmware files for them.
The proprietary ones divide into two subclases:

1.  Ones the manufacturer/copyright owner has said may be freely redistributed.
2.  Ones where that has never happened (and so are illegal to redistribute).

Many Linux distributions include Category 1 firmware files.  _No_ 
Linux distributions may (lawfully) include Category 2 ones -- because,
lacking that permission, their inclusion would be copyright violation.

Debian's policy bans both subclasses from Official Debian ISOs.

The ISOs you copied from me today are unfficial ISOs differing from the
official ones in that Category 1 firmware files have been added in.


> So this means that we now have a lot more Debian live distributions
> with a variety of DM including KDE.  These alternatives might be more
> useful for new users

{sigh}    Not quite, and no.

1.  The ISOs with 'debian-live-' at the beginning of their 
filenames are live distributions.  The Debian ISOs whose names don't
include 'live' in their filenames aren't.

2.  I strongly disagree with the notion that live distros are more likely to
be useful for new users.  In fact, depending on the target machine,
using a live distro might actually be flat-out impossible.  You gain
something with 'live' operation, but there's also a price.

The concept of a 'live' distribution was invented with the Linuxcare
Bootable Business Card that Duncan MacKinnon, I, and some other
colleagues invented at Linuxcare, Inc., 850 Townsend, San Francisco in
1999.  Klaus Knopper in Germany studied what we did and created Knoppix
using the tricks we created with the Linuxcare BBC:  In a 'live'
distrbution, the initial media first boots up a non-installed graphical
running system using the boot device's compressed filesystem plus a huge
RAMdisk.  There is typically among the graphical applications available
an optional installer program that, if run, actually installs the system
onto a target long-term mass-storage device (your HD or SSD) for
long-term and non-volatile operation.

Simply booting up the 'live' system into the graphical desktop takes a
pretty serious amount of RAM and CPU, and then running a graphical
installer program on top of that takes even more RAM.  So, 'live'
distributions often cannot be installed _at all_ onto some target
hardware, for lack of ability to run all of that heavy code.  This is
the lesser of two reasons why _good_ distribution installers, such as
the ncurses-oriented 'd-i' installer on main (non-live) Debian disks and
the same 'd-i' installer on *buntu's 'alternate' ISOs, are deliberately
non-live, i.e., if run they offer to install but don't give you a
graphical desktop with Tetris, etc., to play with during installation.

The greater reasons why those installer are non-live is to make them
flexible in operation, making them adaptable to the installing user's
preferences and able to accommodate unusual hardware to a degree not
possible (or at least never yet seen) with live media installers.  Also,
the live installers are a lot slower.

Short version:  If you tell newcomers 'You should use the live
installers, as they're better', you'll be shooting some of them in the
foot, e.g., some won't be able to install anything, and consider the
message _that_ will send.

Live distros are cool. (That's why we at Linuxcare invented them.)  But
they're not a general solution.  There's no way they could be.