[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