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

[Rick Moen]

Quoting aaronco36 (aaronco36 at SDF.ORG):

> 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?

Nope.  Among other things, I was an undergrad nobody.

In 2020, I'd been looking forward to finally meeting mathematician John
Conway, creator of Conway's Game of Life
(https://en.wikipedia.org/wiki/Conway's_Game_of_Life) that we all
learned about in Martin Gardner's "Mathematical Games" column in the
Oct. 1970 issue of _Scientific American) -- but then Reunions got
cancelled and Conway was killed by COVID-19, at approximately the same
time.

['Essential pre-reading for life with LFS']:

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

Do any or all of that for the experience and for learning, if you like,
but don't kid yourself into thinking that's a reasonable way to maintain
a Linux system.  Circa 1993, when everyone needed to do that, is what we
call the Bad Old Days.

In the long term, it's madness to maintain everything yourself: doing
quality control on upstream, checking and maintaining security, applying
advisable patches, making sure everything adheres to distro policies and 
is compatible with distro facilities and libs, compiling, and
constructing and installing packages.  Pick a distro with maintainers,
so you don't need to.

> OTOH Rick, you yourself wrote a comment at [07] clearly _cautioning_
> against building packages from source from upstream maintainers:

In _general_, except where that is the best available option because
you've searched intelligently for better options and not found them,
yes.  I am still of that view, for the reasons indicated.


> And quite ironically re: RMS's stance on upstream development [...]

I'm sorry, but _what_ view about upstream software development are you
attributing to Richard, Aaron?  Something-something GNU Manifesto?

I must confess, I'm having difficulty unpacking your meaning.  Richard's
a friend of mine, as is Biella Coleman (the author/reporter/researcher
you cited), and think I know both of their views pretty well (and of
course don't speak for either of them).

Page 37 (bottom) of Biella's book does indeed point to some hackers
being thrilled by Richard's "The GNU Manifesto".  But, sorry, what's
your point about that?

Page 51 (bottom) talks about hacker social practices.  

Your point seems to involve something about Richard "advocat[ing] for
F/OSS _outside of_ Linux distros".  I'm sorry, what what?  

Richard advocates for free software, full stop, always and everywhere.
In order for it to exist, someone must write it and make instances of
the creative work available to others under free software licences.
If/when other middlemen package and aggregate those works, then the
creators get viewed, from the middlemen's and end-recipients'
perspective as the "upstream source".  Sometimes, as with (to pick an
example) procmail, the upstream developers have gone away (ceased to
exist, packed up and gone fishin'), so there is no remaining upstream,
and in effect, one or more distro becomes the replacement upstream, as
is Debian with procmail.

I'm unaware of Richard having particular views about any of these
realities, except to believe and advocate his view "free software is
good; non-free software is bad".  (To the astonishment of many,
Richard's views on this are actually nuanced, e.g., he allows as how
there's nothing wrong with non-free software in particular cases, e.g.,
where it "embodies a business practice".  I don't care to get deeper
into that.  If you want to know more, ask Richard.)