[sf-lug] Living thru Cold War, Unix, going upstream, FF telemetry

aaronco36 aaronco36 at SDF.ORG
Tue Feb 15 09:34:07 PST 2022


Quoting Rick Moen <rick at linuxmafia.com> from [01]:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Living thru the Cold War and following the news.  The Russians
> who package it may be completely honest but how closely can they inspect
> all the code coming in.  The Russians have attacked via hacking but with
> a package in the very large distribution they could collect as much
> information as they pleased, use our private machines in Denial of
> Service Attacks and use them to propagate malware.  Is this paranoia
> or excessive caution?

No, it's a reasoned concern.  I was just curious, and what you say is
what I suspected after reading about the project's history.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Might be of interest to some that an article on Cold War "veteran" and 
Unix pioneer Brian Kernighan came out last week; 'Could Unix Happen Today? 
Brian Kernighan Looks Back and Forward' [02].

An interesting read.

Excerpt from article [02]:
"Young Brian Kernighan had received his Ph.D. from Princeton in 1969, then 
worked at Bell Labs legendary Computing Science Research Center until 
2000, according to a brief introduction to his talk from conference chair 
Miles Goodhew. Goodhew joked that Kernighan is now a Princeton computer 
science professor, where he writes short programs and longer books. "

Rick, IIRC you were at Princeton during his earlier years at Bell Labs 
Computing Science Research Center -- did you have occasion to listen to 
and/or meet Brian Kernighan back around that time?

What do other Cold War "veterans" reading this think about Kernighan's 
reflections and predictions in the article [02]?

FYI, according to page 36 (or page 50 of 268) in the document 'Coding 
Freedom THE ETHICS AND AESTHETICS OF HACKING' by E. Gabriella Coleman 
[03], that very Cold War time period of Unix was considered as "OUR 
GILGAMESH EPIC".

----

Quoting Rick Moen <rick at linuxmafia.com> from [01]:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is always well worth bearing in the back of one's mind that you are
always going to be putting a certain amount of trust in one's software
gatekeepers.  In the case of proprietary software, that's the software
OEMs (publishers) and their software supply chains.  In the case of open
source within[1] Linux distros, that's the distro packagers and to a
degree the upstream maintainers.  And so, it's always worth considering
how competent and reliable (and beneficent) the gatekeepers are.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Am mostly agreeing with Rick on this.

Further on in the 'Coding Freedom' document [03] -- bottom of pg37 (or 
bottom of pg51 of 268) -- there starts more extensive discussion of 
Richard M Stallman (RMS) and his "GNU Manifesto"/GPL.
One of the main points here is that RMS specifically advocated then and 
quite adamantly still advocates for F/OSS _outside of_ Linux distros 
themselves, i.e., for those very "upstream maintainers".

Linux From Scratch (LFS) is essentially a DIY Linux distro for those who 
wish to get their hands dirty by "gatekeeping" for themselves -- see at 
least [04].
Quoting the 'Essential pre-reading for life with LFS' from [05]:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Building from Source

Having got yourself a LINUX system, and played a bit, you now will
know a little about the subject, but before moving on to the building
of Linux from Scratch you should learn how to build packages from
source code. This is an area where it's hard to find good references.
The LFS book suggests Building and Installing Software Packages
for Linux and Autoconf, Automake, and Libtool is good too, if a
little advanced.

It's very important that you have some experience installing a package
from source on your distro before attempting LFS.

One good choice would be GNU-Emacs. Here's what to do:
  1. check out it's homepage
  2. download a source distribution as a gzipped tar file
  3. unpack the source with tar and gunzip
  4. read the README file
  5. read the INSTALL file
  6. build it from scratch

In doing this you will not only learn how to obtain and build a
package from scratch, you'll also prove that you have installed the
right tools for your distribution.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Anyone else also think that using RMS's GNU-Emacs [06] to learn how to 
build a package from source would seem to be in line with RMS's and 
others' by-and-large _avoiding_ those questionable distro packagers? ;)

OTOH Rick, you yourself wrote a comment at [07] clearly _cautioning_ 
against building packages from source from upstream maintainers:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rick Moen comments: While it's useful and worthwhile to know about a 
program's "upstream" development site, where (among other things) the 
author's latest source code can be downloaded, there are a few 
disadvantages that should be noted (and some alternative locations that 
should be usually be preferred, instead, if such are findable):
...
...
The smaller, less popular, and less dependency-ridden a package is, the 
more you might be tempted to use an upstream source tarball. For example, 
I use locally compiled versions of the Leafnode pre-2.0 betas to run my 
server's local NNTP newsgroups, because release-version packages simply 
lack that functionality altogether. On the other hand, that package's one 
dependency, the Perl PCRE library, I satisfy from my distribution's 
official packages, for all the reasons stated above.

[RM's post-publication addendum: I should have also mentioned that 
package-oriented distributions generally also have simple toolsets to 
craft local packages from tarballs when that is the best option for 
whatever reason, rounding out my listing of ways to avoid the lingering 
menace of unpackaged system software on software architectures with good, 
useful package management. (Linux distributions that either deliberately 
or otherwise lack software & configuration management using package 
management tools are, obviously, a separate topic, not addressed here.)]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

And quite ironically re: RMS's stance on upstream development, the GNU 
Emacs download page[08] writes "Most GNU/Linux distributions provide GNU 
Emacs in their repositories, which is the recommended way to install Emacs 
unless you always want to use the latest release." :-\


----

Quoting Rick Moen <rick at linuxmafia.com> from [01]:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Less-verbose HOWTO page about Firefox telemetry:
https://www.howtogeek.com/557929/how-to-see-and-disable-the-telemetry-data-firefox-collects-about-you/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thanks for that HOWTO link about Firefox telemetry, Rick :-)

Running a simple 'uniq' on the "preferences" snippet of the HOWTO page[09] 
gives us 17 unique entries to carry out for the disabling of Firefox's 
telemetry.
FWIW, by running a 'sort | uniq' on this "preferences" snippet and 
comparing it to Gamunu Balagalla's 'Disabling Firefox Quantum telemetry' 
page on GitHub[10], one can see that there are four extra Firefox 
'about:config' telemetry edits in the first HOWTO[09], which are...
- datareporting.healthreport.uploadEnabled = false
- datareporting.policy.dataSubmissionEnabled = false
- datareporting.sessions.current.clean = true
- devtools.onboarding.telemetry.logged = false
(somehow didn't myself find Gamunu Balagalla's "experiments" 
anti-telemetry entries) :-\


-A

======================================================
REFERENCES
======================================================
[01]http://linuxmafia.com/pipermail/sf-lug/2022q1/015531.html
[02]https://thenewstack.io/could-unix-happen-today-brian-kernighan-looks-back-and-forward/
[03]https://gabriellacoleman.org/Coleman-Coding-Freedom.pdf
[04]https://www.linuxfromscratch.org/lfs/
[05]https://www.linuxfromscratch.org/hints/downloads/files/essential_prereading.txt
[06]https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.html
[07]http://linuxmafia.com/~rick/weatherwax.html#1
[08]https://www.gnu.org/savannah-checkouts/gnu/emacs/download.html#gnu-linux
[09]https://www.howtogeek.com/557929/how-to-see-and-disable-the-telemetry-data-firefox-collects-about-you/
[10]https://gist.github.com/gamunu/7fbee4e2318fdc080395a7f74cc34fe9
======================================================

aaronco36 at sdf.org



More information about the sf-lug mailing list