[sf-lug] SF-LUG meeting note for Monday November 20, 2017

[Rick Moen]

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

> Well it is an old habit of mine to max the memory if I
> can on my main machine.  This is from the days of megabytes on
> the Amiga.  I had my A2000b with 68060 up to 64 megabytes.

It's IMO indeed a really good idea!   Pretty much always a
cost-effective improvement that makes a real difference.

I guess my point really was boggling at that amount of RAM on a desktop
and particularly at the idea that it might not be enough for KDE5.
Let's just say that this scenario would imply a lot of... um...
discretionary RAM consumption by tht DE.

Here's one of my benchmarks in this matter:  In the mid to late 2000s, I
was working in the Linux Management Department at Cadence Design Systems
in San Jose.  This job involved managing the Linux builds for Cadence's 
servers, laptops, and workstations running Cadence's chip-design
software (various releases of RHEL and SLES), so I would be working
pretty much entirely in Linux -- but there was the complication that
corporate scheduling ('calendaring') and e-mail was on MS Exchange
Server.  I was issued an IBM Thinkpad T42p -- nice old rock-solid laptop
-- maxed out at 2GB total RAM.

Some of my colleagues dealt with the Exchange Server problem by running
bleeding-edge Evolution on Linux, compiled from betaware source code.
This caused them various problems, mostly on the scheduling side.

I pondered this, and decided to adopt an easier, more expedient, and 
less cutting-edge solution.  I blew away the laptop's WinXP preload 
and installed Debian with the Window Maker window manager.  Then, I used
Cadence's site license for VMware Workstation 5.5 to install that as
hypervisor layer.  Finally, inside a VM, I reinstalled the site-licensed
WinXP, which I then kept in it's own little window off to the side of my 
Window Maker desktop, able to run MS-Outlook and sometimes MS-Internet
Explorer if needed.

So, consider that all of those things' simultaneous RAM needs added up:
Debian with X11 and Window Maker, everything I ran in the Linux
graphical environment, VMware Workstation, Windows XP, and MS-Outlook.
All of that -- and my point is that I still had utterly excellent
performance with 2GB of RAM and a 2000s-era laptop CPU.

So, the notion of 12 GB possibly not being enough _just_ for a Linux
Desktop Environment boggles me a bit.

> I don't really get it either but a version of Open Mandriva was
> published on Distrowatch that did not have the proper checksum
> posted.  I attempted to contact the poster at the Open Mandriva site. 
> I never got a response.   I notified the Distrowatch and they were
> unable to contact the poster of that version either.

Looking right now on Distrowatch, I see notices about OpenMandriva Lx
releases with ISO links, but they have md5sum links with them.  Some of
the ISO links go to the SourceForge download redirector page, and then
after a countdown directly to an ISO link, which is annoying because it
makes it really difficult to just view the Web directory tree's contents
and see if there's a checksum file or how big the ISO is.  

Distrowatch's page _about_ OpenMandriva Lx
(https://distrowatch.com/table.php?distribution=openmandriva) shows
'https://www.openmandriva.org/download' and 'LinuxTracker.org' as
canonical download locations.  The former is a redirect to
https://www.openmandriva.org/en/documentation/openmandriva-lx/download .
Which in turn offers links to the OpenMandriva mirror network, or a page
with torrent files, or the SourceForge project.

If you delve into the mirror network, you eventually find the current
release with md5sums and sha1sums, e.g., 
http://ftp.acc.umu.se/mirror/openmandriva.org/release_current/OpenMandriva_Lx_3/

As I mentioned upthread, the purpose of those checksums is to permit
downloaders to verify that their downloads were complete and not
corrupted in transit.  What that does _not_ do is in any way verify that
the remote copy was authentic.  E.g., if someone broke into the
ftp.acc.umu.se and replaced the ISO with a trojaned copy of OpenMandriva
Lx 3.03 Plasma _and_ took to the trouble to post the matching checksums,
you as a downloader would not know that.

This is why OpenPGP-signing of checksum files (or, rarely, of the ISOs
themselves) would be handy.  That really is something OpenMandriva ought
to do, and apparently they aren't.

>     The latest example is MultibootUSB-live which was supplied
> without checksum and I went to the site
> and pointed this out.  The person answering me said
> 
> "Will put it in on the site from next release onwards...."
> 
> 	As though he had never heard of such a thing
> before.

Yep.  https://sourceforge.net/projects/multibootusb-live/files/8.8.0/
{shakes head}



> And you can read what Maestro had to say on the list and I am
> sorry that I may have
> conveyed a misunderstanding to the rest of the readers of the list.

You do a great job!  (For which, my thanks.)  Maestro can clarify what
the heck he _was_ trying to say, if he wishes.