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

[Bobbie Sellers]

On 3/3/19 6:21 PM, Rick Moen wrote:
> 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....

     Then I saw the hard part curiously enough most intense around the 
scene of the late gas explosion
on Geary where the bus's windshield wipers could not keep up with the 
downpour.

>>       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.
         I don't expect Linux to be automagical to any degree and hate 
the term but usually when installing
you get better hardware detection.    I see similar problems to a lesser 
degree with my 1920 x 1080 display
on this notebook.
> 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 repeatedly, three
> times over,  rather than do the obvious, and _still_ walk away having
> accomplished nothing?  That's sad.

         These were not entire Distro installations but booting up from 
Live distributions.
Sorry for not making that more clear.  Since I don't (yet) have a 4K 
screen to check
these out I cannot make pre-meeting attempts to modify the startup in 
such a way
that either the full resolution is not used or that the parts of the 
distribution can be
quickly changed to more readable-sized typefaces.

     And the system John has installed is one we may not mention here 
but it is not
MacOS, Unix, but the ever colorful program launcher from Redmond.
> 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.

     And this is why I included this in every meeting notes I send to 
the list


    " Anyone attending the meeting is free to correct my omissions or
incomprehension of the activities and asked to do so asap so that the
membership not in attendance will not be mis-informed any longer
than necessary. "

     Every valid criticism is proof that someone has read the notes.

> {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.

     Thanks for your clarifications.

>> 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
     And I also have the full disks with the added firmware from your 
external portable hard drive.
> {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 installers 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.

     Well I don't tell them to use Live Installers but to try out Live 
versions of the distributions they
are interested in.  I have seen live versions of distributions work 
without problems but when
the installation was made from an install disk of, say Mandriva 2011, I 
had a non-operable
system.   Which is why I moved to the fork of Mandrake/Mandriva I 
presently use, though
it took me a couple of years to do it.

     bliss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20190303/c5a94e59/attachment-0001.html>