Subject: Re: 3 Lisps, 3 Ways of Specifying OS
From: Erik Naggum <erik@naggum.net>
Date: Wed, 17 Oct 2001 21:28:54 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3212342927708991@naggum.net>

* Duane Rettig <duane@franz.com>
| I have to confess to being the probable initiator of some of the FUD I've
| seen in the threads up to now, although there is ceratinly no fear,
| uncertainty, or doubt in my own mind.

  Please do not attempt to take the blame for this, Duane.  Your articles
  are always sufficiently detailed and clear that anyone can go look things
  up for themselves and see that you are speaking about real issues, and if
  they do not agree with your conclusion, at least one can see what you saw.

  The FUD and "propaganda" against Linux that I object to is a hodge-podge
  of negative comments that simply lack substance and only want to impart a
  very negative impression.  Such impressions are hard to combat precisely
  because they constitute "irreproducible results" and a very unscientific
  approach to imparting one's knowledge of problematic areas, if that is
  indeed what it is.  For instance, nobody would have been able to decipher
  the precise conditions under which a combination of kernels, libraries
  and other components John Foderaro's comments _have_ applied, nor to what
  it may apply in the future.  _Lacking_ such specificity, it is dishonest
  to denigrate the good work of others and especially something as diffuse
  and general as "other" Linux distributions just because somebody else had
  a _specific_ problem that has even been _solved_.  If one cannot figure
  out what would make some criticism go away, it is only destructive.  I
  have never seen any such criticism of anything from you, Duane, so you do
  not qualify for fear, uncertainty, and doubt.

  But as for the "problematic" nature of kernels and supporting randomness,
  what does it really say about people who blame the vendor of a _stable_
  system when they introduce a change to _its_ environment?  For instance,
  if you have kernel 2.4.x and your application runs fine, but you upgrade
  to kernel 2.4.x+1 and it stops working or misbehaves somehow, what kind
  of idiot programmer assumes that _Allegro CL_ was the component that
  broke between the two kernels that were used?  I mean, sheesh.


| I have never looked at Perl's source, and am not inclined to do so.

  :)  It is, however, fascinating to watch its configuration script run.

[ example deleted ]

  Thanks again for the detailed answer that makes it so much easier to
  known _precisely_ what kind of issues have been challenging and why.
  This re-establishes the predictability that is so lacking from reading
  the unspecific complaints.

  I think it is fair to say that until those who post negative comments can
  show us some _actual_ and specific negative experiences with particular
  combinations and the _reason_ they came up, I think it the time has come
  to conclude that supporting _Linux_ (not just a particular distribution)
  is no harder than supporting any other Unix, but still _way_ easier than
  supporting whatever "Windows" means today.

  However, Tim Bradshaw touched on the very bad habits of RedHat that
  resurfaced recently when they chose to _ship_ a version of the GCC
  compiler suite which produced C++ code and thus libraries that nobody
  else could talk to unless they installed and built using that version of
  RedHat.  Imagine all the vendors who would have to recompile everything
  for that particular version of RedHat.  This is the direct opposite of
  the prudent delay that serious vendors would be expected to engage in,
  and the prudent course of action is instead to _unsupport_ that version
  explicitly.

  If other distributions or specific kernels or library versions are _not_
  supported, this should, consequentially, be quite easy to list and the
  reasons why.  This would be in addition to the information about which
  _are_ supported, because a user can choose to mix and match kernels and
  libraries even on a supported system.

  As for which libraries and versions are actually required for a package
  to be installed and to run successfully, this problem has been solved.
  Both RPMs and Debian packages have ways to specify required packages.
  Debian's package system is so much better than anything else people do
  that it amazes me that other people do not grab it and use it, especially
  since the RPM format has proven so problematic in graceful upgrades, and
  it is too hard to automate the task of upgrading prerequisite packages.
  In any case, publishing software for Linux should in my opinion include a
  Debian package so those who want to perform responsible upgrades have
  that option.  There is an "installer" for Allegro CL Trial Edition for
  Debian, produced and maintained by Peter Van Eynde, for instance, but it
  does not include any dependencies.

///
-- 
  The United Nations before and after the leadership of Kofi Annan are two
  very different organizations.  The "before" United Nations did not deserve
  much credit and certainly not a Nobel peace prize.  The "after" United
  Nations equally certainly does.  I applaud the Nobel committee's choice.