From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsrouter.chello.at!newsfeed.Austria.EU.net!newsfeed.kpnqwest.at!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader3.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: 3 Lisps, 3 Ways of Specifying OS References: <18e1cdb3.0110152113.1cb2e998@posting.google.com> <87pu7noko1.fsf@balder.seapine.com> <87hesznkj6.fsf@balder.seapine.com> <3212277220965737@naggum.net> <4n12qwxty.fsf@beta.franz.com> Mail-Copies-To: never From: Erik Naggum Message-ID: <3212342927708991@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 88 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Oct 2001 21:28:54 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader3.kpnqwest.net 1003354134 193.71.66.49 (Wed, 17 Oct 2001 23:28:54 MET DST) NNTP-Posting-Date: Wed, 17 Oct 2001 23:28:54 MET DST Xref: archiver1.google.com comp.lang.lisp:18052 * Duane Rettig | 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.