Re: [tlug] Classes

["Stephen J. Turnbull" <stephen@example.com>]

Josh Glover writes:
 > On Friday, May 18, 2012, Andrew Holway
 > >
 > > If your compiling software and setting up linux from scratch then your
 > > probably doing it wrong.
 > >
 > 
 > *plonk*
 > 
 > ;) (but not really)
 > 
 > Wow, TLUG has changed a lot in the 12 years I've been a member. I can only
 > imagine how the charter members feel...

Actually, we just had this discussion on two rather different lists in
the last week, Mailman Users and DJGPP.  (Mailman is the mailing list
manager/post distribution system this list uses, and DJGPP is the DOS
extender-based GCC for DOS developed by DJ Delorie, which is still in
use by embedded hackers and retro gamers.)  The conclusion on both was
the same: the distros (including *BSD and some user-space distros like
Cygwin and MSYS for Windows and MacPorts and Homebrew for the Mac) are
doing a very good job of providing basic functional systems.  (Of
course the implications for the software in question are very
different!)

Again, this is related to the Mythical Man-Month discussion.  Brooks
proposed the idea (now uncritically accepted) that higher-level
concepts like objects and libraries can function as information
chunks, allowing developers to be vastly more productive without
increasing the number of chunks each needs to handle at once.

The distros function in the same way, increasing the chunk size of
system administration functions.  When Ye Olde Guard got started in
the mid-90s, Linux and *BSD were hardly past the stage where you got
started by installing a kernel and a statically linked Bash, then GCC,
binutils, and a hacked and unreliable libc.  X11 came much later,
after you had stabilized your basic system, and console (not
terminal!!) utilities were fukaketsu.  Good luck if you needed a
bleeding edge libc for some new program -- you probably had to build a
bleeding edge GCC from scratch, and figure out for yourself how to
keep that from conflicting with the old stable GCC that actually
compiled your kernel correctly!

It would be silly to go back to that; we've got enough problems with
Metacity, GNUMB, Kiddie software, and Unity that it doesn't make sense
to use a homebrew system up to just below the level of the GUI these
days.  Just take what your distro offers; it will work fine.  X11 now
works fine (well, mostly; there are still no internal checks for bogus
data from the app level and documentation of what data is accepted is
still poor, so X can still crash your app without warning), and the
toolkits and app development frameworks are pretty good.  We may as
well use the distro-provided packages, except for mission-critical
apps and their support modules.  Even there you probably want to use a
customized source build of the distro pacakge, or a locally-packaged
build from upstream sources.

Note that using a system like Gentoo or MacPorts that defaults to
building applications from source is hardly what we would have
considered "compiling" in the old days.  (You should have tried
building the Wnn input method from the original Omron sources.  What a
fscking mess!  "imake" didn't work on Linux because SunOS assumptions
were baked into the Imakefile, it didn't properly include the system
.cfs!)  These systems really are basically a way of managing multiple
configurations without proliferating binary packages.

It's still important to learn some of the basics of Unix, the "small
single-purpose tools" philosophy, the concept of stdio and filtering
data through multiple tools, and basic scripting.

Amusingly enough, one of the aggressive "we don't need no support for
steenkin' DOS" types on the emacs-devel list described the Emacs s&m[1]
files as "obsolete" because of the autotools (speaking of broken-by-
design obsolescence!)

Footnotes: 
[1]  These are subdirectories of the Emacs source tree, where "m"
stands for "machine", and contains #defines which parametrize the
characteristics of the CPU.  "s" stands for "system" and does the same
for the OS.  The natural construction "s&m" is a serendipitously
accurate characterization.