[Discuss] I need a recommendation for a Linux-compatible high-end PC builder

[Alan W. Irwin]

On 2018-01-28 21:16-0800 Cy Schubert wrote:

> Memory leaks should be fixed. As an O/S developer I appreciate bug
> reports, especially detailed bug reports. It all helps.

Hi Cy:

I completely agree that memory leaks caused by the OS system should be
reported.  And I also think such leaks generally are reported and are
fixed (at least on OS's based entirely on free software such as Linux
and *BSD) thanks to strong community support and appeals like yours. 
However, that good free software feeling is not so clear for
javascript memory leaks created by a set of bad javascript commands
created by some anonymous company in webspace.  I think such commands
do technically qualify as "open source" but not necessarily free
software.  However, they are so obfuscated by the many layers of
javascript that hierarchically include them, that it makes such issues
difficult to fix which is another motivation for using a whitelist
approach such as the "noscript" extension for firefox for domains
which you trust to have good javascript.

Anyhow, due to Adam's result on Mac OS X, I brought up leaks because I
was desperately looking for any scenario where the principle is
violated that sufficient RAM makes drive performance irrelevant
(except for the first load of a system file during or after a boot).

So far nobody has argued with that general scenario (even for Mac OS
X) so I assume the disagreements about the effectiveness of SSD
performance for system use only concern how much RAM would be enough
to achieve this ideal.  And I made a mistake in my previous estimate
of that (ignoring the effect of user files potentially overflowing the
part of RAM that caches files) that one of you should have caught and
which might explain Adam's clear result for Mac OS X and the more
subjective results of others on other platforms that SSD's seem to enhance
system responsiveness.

So to look at that again in our own use case (both Barbara and I
jointly use this computer on a daily basis thanks to the magic of a
nettop thin client that gives me seamless remote access to it) the
size of our current "/" partition is 18GB. That represents just our
current package install needs since we have been relentless about
being careful not to install packages that don't satisfy our needs and
purging packages we no longer need. Nevertheless all free software
distributions including Debian organize files into packages such that
typically more file space is installed then ever needed by a particular
use case. And I assume that fraction for our use case won't change
much for Debian versions for the next 10 years, but our actual needs
may evolve quite a bit during that time (e.g., when some new unique
feature is available for Debian that we want to try out).  So just to
be completely safe lets adopt a maximum of ~32GB for *used* system
file needs for our use case over the next 10 years.

Then for a 64GB RAM dream machine, that leaves room for 32GB to
satisfy both address space needs AND user file needs.  From
yesterday's "free" result (the sum of "used" for the second and third
rows to account for the address space stored in RAM and SWAP) those
total address space needs were only 3.4GB.  Of course that number is
quite volatile and depends for example on what websites are being
viewed at the time and what javascript commands are being allowed to
run by the noscript extension to firefox and the equivalent ability in
konqueror (which we use heavily) to work with a limited whitelist of
domains whose javascript commands are trusted.

The other concern I have just remembered (the one somebody should have
reminded me of before) is user files whose contents are written or
read during the time from a given boot to the next.  Such activity
could potentially overflow the RAM used (the "buffers" and "cached"
statistics from "free") to cache file results so we will call this
concern the user file cache concern that effectively expels system
files from that cache and therefore causing an SSD versus HDD
performance difference the next time that system file is required.

In sum, one alternative is to not buy an SSD for my dream machine now
and only consider buying an SSD later and reinstalling Debian on that
SSD in case there is clear evidence that something that we need
(likely in user space files) is overflowing on a regular basis the
part of the physical RAM that is used to cache file results for the
dream machine.  The other alternative is simply to buy the minimum
size of SSD from ZaReason (120GB for ~$120) and let them worry about
how to configure their Debian install on that SSD device so that
device is not worn down too quickly by write events.  That convenience
factor and relatively small extra cost makes this second alternative
attractive.  On top of which we don't want to be limited in any way
with what we do for user space files to avoid HDD performance issues
on system files.  So I currently plan to take this second alternative
now, and the difference maker from my previous different conclusion on
this subject was the potential impact of user file reads and writes on
the part of RAM that is used to cache file results. So this has been
quite a journey to this decision, but I have learned a lot and I hope
the guys who hung in there with me (who I want to thank in any case
for their input) learned a lot from this journey as well.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________