3 Lisps, 3 Ways of Specifying OS
Pratibha
for *Linux*" of a few months ago (it made my head swim) in which
Duane Rettig and John Foderaro of Franz mentioned Franz's
headaches with nonstandardized signal handling among the various
Linux distributions, and explained why Franz specifies its compatible
(or at least supported) platforms the way it does, namely,
as "RedHat X, Y, Z" instead of something like
"kernel x, glibc y, ...".
From their respective websites, Franz, Xanalys, and CMUCL specify
their compatible PC Unixes as follows:
Franz: FreeBSD 4.x
RedHat 5.x, 6.x, 7.0
Xanalys: RedHat 5, 6
kernel 2.0, glibc 2.0; kernel 2.2, glibc 2.1
CMUCL: FreeBSD 4.x, 5.x
glibc 2.1, glibc 2.2
kernel compiled with CONFIG_1GB (not CONFIG_2GB)
Given Franz' explanation of *its* way of specifying OS, what is
to be made of Xanalys' way? Is the kernel and
glibc specification redundant? ...or more restrictive?
...or more expansive?
If Xanalys can run on FreeBSD as someone asserted, why is
this not officially specified? If it cannot run, why not?
Given Franz' explanation, how is CMUCL able to "get away"
with specifying only the glibc versions and a kernel compilation
option, rather than a distribution identity and version number?
Or is Franz' explanation somehow unique only to Franz'
design?
Are any of these implementations expected to support
the current RedHat version or SuSE version (7.2 in both
cases, I believe) anytime soon? I am somewhat surprised
that none of these implementations officially support
even any version of SuSE, as I thought Lisp and SuSE were
both "big" (relatively speaking) in Europe.
Dr. Edmund Weitz
> Are any of these implementations expected to support
> the current RedHat version or SuSE version (7.2 in both
> cases, I believe) anytime soon? I am somewhat surprised
> that none of these implementations officially support
> even any version of SuSE, as I thought Lisp and SuSE were
> both "big" (relatively speaking) in Europe.
At least LispWorks 4.1.20 works fine with SuSE 7.2. I think they just
didn't have the time and/or manpower to test with other distros than
Red Hat.
I think it would be a good thing if the big Linux distributions would
actively try to make their product a good Lisp platform but the market
doesn't seem to be there. After all, SuSE is working hard to make sure
that Oracle runs and is certified on their platform, and they also
include a couple of commercial demos - like VMWare - with their
releases. They _could_, if they decided it to be worthwhile, try to
include a working version of LispWorks Personal Edition also - I'm
quite sure that Xanalys would like this. But, alas, it took them a
loooong time to even find out that GCL might not be the best solution
just because it has the GNU label attached to it. Only very recently
(with 7.2, I think) did they switch to CLISP, and there's still no
CMUCL...
Edi.
Friedrich Dominicus
> ibpra...@yahoo.com (Pratibha) writes:
>
> > Are any of these implementations expected to support
> > the current RedHat version or SuSE version (7.2 in both
> > cases, I believe) anytime soon? I am somewhat surprised
> > that none of these implementations officially support
> > even any version of SuSE, as I thought Lisp and SuSE were
> > both "big" (relatively speaking) in Europe.
>
> At least LispWorks 4.1.20 works fine with SuSE 7.2. I think they just
> didn't have the time and/or manpower to test with other distros than
> Red Hat.
Well I'm using Lispworks 4.1.20 and 4.2.0 Beta on a Debian
system. If Xanalys says we are supporting especially RedHat, does that
not mean that it won't run elsewhere. How it works for you is easy to
check just download the personal editon and try it.
Regards
Friedrich
Doug Alcorn
> Xanalys: RedHat 5, 6
> kernel 2.0, glibc 2.0; kernel 2.2, glibc 2.1
>
> Given Franz' explanation of *its* way of specifying OS, what is
> to be made of Xanalys' way? Is the kernel and
> glibc specification redundant? ...or more restrictive?
> ...or more expansive?
My company sells a binary-only application on Linux. This is how we
specify our compatibility. We don't want to limit our support to just
specific versions of a specific distribution. Basically, we say we
work on any distrubution that is kernel 2.2.x (or greater) and glibc
2.x. IMO, this is more inclusive than saying "RedHat 5, 6".
--
(__) Doug Alcorn (mailto:do...@lathi.net http://www.lathi.net)
oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543
|_/ If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.
John Foderaro
> Basically, we say we
> work on any distrubution that is kernel 2.2.x (or greater) and glibc
> 2.x. IMO, this is more inclusive than saying "RedHat 5, 6".
>
You're correct. That is much more inclusive. Can I ask how many
combinations of a kernel 2.2.x and glibc 2.x and distribution you
actually tested your application on? I would guess between
1% and 5% of the total number of combinations out there.
How did you then extrapolate to conclude that it will work on
all combinations now only in existence now but those yet to be created?
Have you run an automated test to see that your C library calls
all conform to the API? I once ran an automated API tester on
a huge C program I was working on an was surprised to see the
violations it picked out of a perfectly working program.
The typical one was a system call that could return a value
in a block of memory to which you supplied a pointer. If you
supplied a null pointer the system call would silently ignore
this API violation and just not return anything. However
maybe sometime in the future someone would "fix" the
kernel to treat that as an error and your program would
stop working.
Are you sure that your program doesn't depend on the location
and form of system configuration files that can vary from
distribution to distribution?
Saying that something works in Redhat 5 and Redhat 6 says
something very concrete: this program was tested and found
to work on those particular distributions.
Saying that a program works on kernel 2.2.x, glibc 2.x with
any distribution says: there exists some set of
distributions, kernels and glibc for which this has been tested
and we know it works. We aren't going to tell you what
those known working combinations are. However we feel
confident that it will work on any combination.
Supporting customers is more difficult if you claim to work
on a huge combination of distro,kernel and glibc. You may
spend days getting a machine setup to reproduce their
system in order to reproduce their problems.
It would be great if all programs on Linux could be specified
as working on something as general as kernel 2.2.x and glibc 2.x.
As the complexity of the program increases it becomes
more difficult to make such a broad statement with a
acceptably high probability that you are correct.
Martin Cracauer
>I just read through the very long thread "Lisp Vendor support
>for *Linux*" of a few months ago (it made my head swim) in which
>Duane Rettig and John Foderaro of Franz mentioned Franz's
>headaches with nonstandardized signal handling among the various
>Linux distributions, and explained why Franz specifies its compatible
>(or at least supported) platforms the way it does, namely,
>as "RedHat X, Y, Z" instead of something like
>"kernel x, glibc y, ...".
>From their respective websites, Franz, Xanalys, and CMUCL specify
>their compatible PC Unixes as follows:
>Franz: FreeBSD 4.x
5.x as well.
> RedHat 5.x, 6.x, 7.0
>Xanalys: RedHat 5, 6
> kernel 2.0, glibc 2.0; kernel 2.2, glibc 2.1
>CMUCL: FreeBSD 4.x, 5.x
> glibc 2.1, glibc 2.2
> kernel compiled with CONFIG_1GB (not CONFIG_2GB)
>Given Franz' explanation of *its* way of specifying OS, what is
>to be made of Xanalys' way? Is the kernel and
>glibc specification redundant? ...or more restrictive?
>...or more expansive?
>If Xanalys can run on FreeBSD as someone asserted, why is
>this not officially specified? If it cannot run, why not?
I added the neccessary support to FreeBSD's Linux layer to make
Lispworks run. I didn't use it afterwards, so if there are problems,
let me know.
Franz has a native version for FreeBSD.
>Given Franz' explanation, how is CMUCL able to "get away"
>with specifying only the glibc versions and a kernel compilation
>option, rather than a distribution identity and version number?
We don't do massive amounts of testing. Whatever the developer used
to build the distribution is "supported". If don't think there was
ever a Linux variant I couldn't run CMUCL on.
If you want an OS that runs applications after updates and not invest
the resources to gain this knowledge, you have to use FreeBSD anyway,
so what would be the point?
>Or is Franz' explanation somehow unique only to Franz'
>design?
>Are any of these implementations expected to support
>the current RedHat version or SuSE version (7.2 in both
>cases, I believe) anytime soon? I am somewhat surprised
>that none of these implementations officially support
>even any version of SuSE, as I thought Lisp and SuSE were
>both "big" (relatively speaking) in Europe.
Your whole posting missed the point entirely. If you run non-redhat,
you have to be clever and experienced enough to overcome problems when
running applications like these. That is what the current Linux model
is about.
Also, Suse and Redhat run (ran?) modified kernels and probably also
modified libc's. How is any vendors going to give predictable
information in this situation?
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Eric Moss
> If Xanalys can run on FreeBSD as someone asserted, why is
> this not officially specified? If it cannot run, why not?
Lispworks does run in FreeBSD, but in linux-compatibility mode, rather
than as native app. I suspect the reason for not officially specifying
it is that doing so might imply support for that. That could be
difficult for Xanalys to do because FreeBSD can change, the Linux
compatibility "port" can change, and libraries that Linux Compatibility
mode needs can change, all independently. It would be a headache to keep
track of.
Eric
Marc Battyani
> I added the neccessary support to FreeBSD's Linux layer to make
> Lispworks run. I didn't use it afterwards, so if there are problems,
> let me know.
Useful work.
All my web servers work with LWL on FreeBSD boxes without any problems.
Marc
Martin Simmons
news:MPG.1635df64a...@news.dnai.com...
> In article <87pu7no...@balder.seapine.com>, la...@seapine.com says...
> > Basically, we say we
> > work on any distrubution that is kernel 2.2.x (or greater) and glibc
> > 2.x. IMO, this is more inclusive than saying "RedHat 5, 6".
> >
>
> You're correct. That is much more inclusive. Can I ask how many
> combinations of a kernel 2.2.x and glibc 2.x and distribution you
> actually tested your application on? I would guess between
> 1% and 5% of the total number of combinations out there.
Aren't there are too many different configurations of Red Hat 5 & 6 to test in
advance as well, e.g. different release CDs, different packages installed,
different sets of patches, different kernel modules loaded etc? In practice,
the only really significant compatibility problem we have found is the versions
of the kernel and glibc (which are closely tied anyway) because they determine
whether the program will even start :-)
--
Martin Simmons
zne...@xanalys.com
rot13 to reply
Paolo Amoroso
> Given Franz' explanation, how is CMUCL able to "get away"
> with specifying only the glibc versions and a kernel compilation
> option, rather than a distribution identity and version number?
Here are a couple of possible explanations (not speaking for CMU CL
maintainers):
- lack of resources for providing more accurate specifications
- the average CMU CL user is likely to directly try the system to see
whether it works on his setup, or drop a line to the mailing list asking
for feedback
And by the way, since CMU CL is a public domain system, it can probably get
away with anything :) ACL and LW are commercial products and they can not
take such liberties.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
John Foderaro
combinations to test them all. However the nice
thing about packages is that adding packages generally
just adds stuff to your disk and doesn't move or remove
existing stuff. Thus a program working in the basic
RedHat configuration will have a very high probability
of working if you add in a bunch of other packages.
It may be possible to install from the RedHat disks
a version of Linux so small that it doesn't have the needed
libraries to run the application. It's just very
unlikely that someone would do that and we would just
have to tell that person that "these extra packages
are needed".
RedHat does update the kernel and patch libraries.
This can lead to unforeseen incompatibilities but
we haven't been hurt by this. Once nice thing about
having the people at RedHat generate the patch
rather than users getting them off the net themselves
is that the lag between when the change was
made to the source and when RedHat releases the change
gives the chance for the change to be tested in
the field first.
Linux kernel 2.4.11 was released Oct 9th and then
quickly superseded on Oct 11th by 2.4.12 when a
serious bug was discovered in symbolic links.
A number of "works in any 2.4 kernel" programs
may have had problems in 2.4.11.
The built-in lag that results in getting updates
through a distribution company like RedHat means
that its users would never see kernel 2.4.11.
Erik Naggum
| Are any of these implementations expected to support the current RedHat
| version or SuSE version (7.2 in both cases, I believe) anytime soon?
If you want a stable system, choose Debian: even their "unstable" version
is more stable than RedHat. If you want to "conform" to a distribution,
at the very least do not choose RedHat -- they have done so many insanely
weird things to Linux kernels and libraries and versions of compilers and
everything you would have to have a nightmare to dream about that it is a
wonder something that works with RedHat works with anything else. That
many vendors "standardize" on them is very unfortunate, since it means
that their random brokenness defines the playing ground for everyone else,
just like that other supplier of random brokenness and version hysteria.
| I am somewhat surprised that none of these implementations officially
| support even any version of SuSE, as I thought Lisp and SuSE were both
| "big" (relatively speaking) in Europe.
If you choose to officially support RedHat, you have few resources left
to support any other distribution. Most of the acidic comments you find
from vendors who debunk Linux as a mass of randomness and pain come from
having had to deal with RedHat's utter lack of respect for stability and
quality in the versions of things they ship. Of course, if you start off
with RedHat, all other distributions _are_ different, giving a falsely
negative impression. If you just ignore RedHat, the Linux world is so
much less random and unpredictable.
It was not always like that. The kernels used to be unpredictable, too,
and the track record for backward compatibility for glibc was quite bad,
but in the past couple years, these things have stabilized remarkably.
If it were not for RedHat, vendors _would_ be able to list the version of
the kernel and the prerequisite libraries and that would work just fine.
It is therefore a disservice to the Linux community to list RedHat as the
reference supported implementation and leave it at that. A much better
approach would be to list the distribution, kernel, library version
combinations that the vendor has focused on and to include those that
have been tested and found working by the users. After all, the vendors
are giving away software and it should help everyone to let users report
back that it works well on their distribution, kernel, library version
combinations, such as by running a test suite. This could help build a
community of users on Linux systems, too, and if there are problems, the
cost of finding and fixing their causes would not be left to the vendor.
///
--
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.
Erik Naggum
| The built-in lag that results in getting updates through a distribution
| company like RedHat means that its users would never see kernel 2.4.11.
Debian's very responsible package maintainers have kept buggy kernel
versions and buggy versions of packages alike from hitting their users
consistently for years, quite _unlike_ RedHat. For the same reason, the
2.4.11 kernel was not packaged up for Debian users even in the "testing"
distribution. Those who want to track the kernel development know what
the are doing. I would think everyone else _avoids_ upgrading their
kernels until some trusted source says it is OK. My trusted source is
the Debian project. And I do not trust RedHat at all -- doing so has
cost me too much real money and real time in the past. But we also know
that _trust_ means very different things to different people.
If you want release lags, nothing beats Debian there, either. :)
had...@worldnet.att.net
work perfectly well with Slackware 7.1, 7.2, and 8.0, although I
wouldn't necessarily say that I exercised it very hard.
--
Howard Ding
had...@worldnet.att.net
http://math.sunysb.edu/~hading http://thunder.prohosting.com/~hading
Thomas F. Burdick
> On 15 Oct 2001 22:13:07 -0700, ibpra...@yahoo.com (Pratibha) wrote:
>
> > Given Franz' explanation, how is CMUCL able to "get away"
> > with specifying only the glibc versions and a kernel compilation
> > option, rather than a distribution identity and version number?
>
> Here are a couple of possible explanations (not speaking for CMU CL
> maintainers):
>
> - lack of resources for providing more accurate specifications
> - the average CMU CL user is likely to directly try the system to see
> whether it works on his setup, or drop a line to the mailing list asking
> for feedback
>
> And by the way, since CMU CL is a public domain system, it can probably get
> away with anything :) ACL and LW are commercial products and they can not
> take such liberties.
Right. If a CMUCL binary doesn't work on a linux system it was
thought to support, the user will be annoyed, the CMUCL maintainers
will be annoyed, and everyone will probably want to figure out what's
the problem wo it can be fixed if it's not a massive amount of work
for an obscure system. If a commercial company made the same
promises, the customer would demand that they get it working on
his/her system, and the vendor would be obligated to put in the
resources necessary, since they sold the system claiming it would work
on the customer's system. So, naturally, commercial vendors will try
to avoid making promises they can't keep, while free vendors will try
to give the user an idea of where the system should work.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Doug Alcorn
> In article <87pu7no...@balder.seapine.com>, la...@seapine.com says...
> > Basically, we say we
> > work on any distrubution that is kernel 2.2.x (or greater) and glibc
> > 2.x. IMO, this is more inclusive than saying "RedHat 5, 6".
> >
>
> You're correct. That is much more inclusive. Can I ask how many
> combinations of a kernel 2.2.x and glibc 2.x and distribution you
> actually tested your application on? I would guess between 1% and
> 5% of the total number of combinations out there.
You're probably correct. Although the number is quit high: debian
stable is our "build box", I do development and unit testing on debian
testing. We have another developer doing unit testing on Mandrake
7.2. Our QA department actually tests on RH 6.2, 7.0, and 7.1. One
of our support guys runs and "tests" on the latest SuSE (meaning our
app has seen several versions of SuSE). Finally, I have vmware with
many VMs and buy every distribution cheapbytes sells. I also keep a
list of distributions and what kernel/glibc/and stuff the various
releases have. While this is far from 100% coverage, it is probably
90% coverage of what our customers are using. We might hit 60%
coverage with just the RedHat varieties. If our support is unable to
reproduce a bug that a customer sees and we don't have that distro, I
would expect us to get our hands on that distro and version ASAP and
setup a box. However, this hasn't happened in over a year. So far,
every bug our customers have reported is reproducable on one of our
test systems here.
> Are you sure that your program doesn't depend on the location
> and form of system configuration files that can vary from
> distribution to distribution?
Yes system config file locations vary from distro to distro. However,
even with the high number of distributions there's still a small
number of variations. These can be tested for at install time.
Again, if we find something new; we'll handle it then.
> Saying that a program works on kernel 2.2.x, glibc 2.x with
> any distribution says: there exists some set of
> distributions, kernels and glibc for which this has been tested
> and we know it works. We aren't going to tell you what
> those known working combinations are. However we feel
> confident that it will work on any combination.
It probably would be helpful to our customers to list the distros we
actually test against. However, I do fee confident that our app will
work on almost any distribution that meets our kernel/glibc
requirements.
> Supporting customers is more difficult if you claim to work
> on a huge combination of distro,kernel and glibc.
true.
> You may spend days getting a machine setup to reproduce their system
> in order to reproduce their problems.
Our experience hasn't shown this to be the case.
> As the complexity of the program increases it becomes more difficult
> to make such a broad statement with a acceptably high probability
> that you are correct.
Maybe our system is reasonably simple. We use pthreads, but that's
part of glibc. We use libstdc++, but statically link it in. We also
statically link in our own database engine. We use semaphores and
sockets; again, glibc. The only reason the kernel matters is because
of the max files per process issue. Our install tries to find the
httpd.conf (since part of our app is cgi). But if your run something
other than apache you have to hand tune the installation
configuration. We also have to detect at install time where the
startup scripts are (since part of our app is a daemon). But, there's
really only two (maybe three) places it could go.
In conclusion, yes, linux compatibility isn't as cut and dry as you
might want it to be. No, it doesn't have to be impossible.
Obviously, the more interaction you do with the OS the more dependent
you are on the distro. However, I would think most service type
applications could be fairly immune to distro variances.
Erik Naggum
| In conclusion, yes, linux compatibility isn't as cut and dry as you might
| want it to be. No, it doesn't have to be impossible. Obviously, the
| more interaction you do with the OS the more dependent you are on the
| distro. However, I would think most service type applications could be
| fairly immune to distro variances.
One of the things I keep wondering about when reading all this weird
stuff and FUD-like propaganda against Linux stability is "How come _Perl_
can run so well on all those _wildly_ differing systems?" Perl includes
more operating system interaction than any other language around -- that
interaction is half its raison d'etre -- and yet it manages to provide
both a specific and a general interface to the operating system that
remains portable and stable between releases of Linux kernels and glibc.
Or at least so it appears. I realize that building Perl from scratch on
any given system queries so many properties of the system that one has to
marvel at the collective pain that its developers must have suffered, but
this indicates that autoconf and similar GNU tools actually _do_ manage
to collect and destill all the painful collective experience in porting
code and building applications under the many and varied Unices. This
experience should be eminently exploitable internally by vendors, too --
using these tools does not "GNUtaminate" the product as far as I can tell.
Friedrich Dominicus
> * Pratibha
> | Are any of these implementations expected to support the current RedHat
> | version or SuSE version (7.2 in both cases, I believe) anytime soon?
>
> If you want a stable system, choose Debian:
Well I support that. The sytem here started as a 2.0 version around 3
years ago. In the meantime I went through a bunch of upgrades even of
"crucial part" of the system like libc updates, different kernel
upgrades, X11 upgrades etc etc. All the updates of the system went
smoothless. So I think the Debian package management is probably the
best available. I had run before the following distributions.
Slackware, Caldera, used Debian 1.3, RedHat. Why did I switch to try
RedHat. Now I can't tell today, and regret that I did it. Well now my
System is a Debian system and I'm happy ;-)
Regards
Friedrich
Duane Rettig
> * Doug Alcorn
> | In conclusion, yes, linux compatibility isn't as cut and dry as you might
> | want it to be. No, it doesn't have to be impossible. Obviously, the
> | more interaction you do with the OS the more dependent you are on the
> | distro. However, I would think most service type applications could be
> | fairly immune to distro variances.
>
> One of the things I keep wondering about when reading all this weird
> stuff and FUD-like propaganda against Linux stability
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. The
problems I have experienced with Linux are specific and narrow.
So I'd like to clarify my own position on this thread, even as
I had thought I had made myself clear on the previous thread:
1. I like Linux a lot. I use it every day, and in fact one of
our fast Linux machines is one of the first machines I do
development on. I _even_ like Redhat Linux, though sometimes
the experimental versions do cause some problems. We see some
of the same problems on LinuxPPC, but usually a year later,
because x86-based linux development has tended to preceed other
platforms.
2. The problems we have had at Franz Inc with Linux has to do
specifically with signal handling, and even more specifically
with reading and changing the context in order to vector off to
lisp interrupt handlers, and, for example, to return a value from
the unbound-variable handler to the specific register in inline
code in which received the unbound value (see example, below).
If another lisp implementation or any other program doesn't do
this kind of thing with trap handlers, then it will never see the
kind of difference that we've seen between kernels.
3. One of the things I learned in the previous thread was that
Linux kernels before a certain level did not implement the
SA_SIGINFO flag in sigaction(). [We always use sigaction() instead
of signal(), because signal() has always had an overloading and
library dependency due to conflicting definitions which BSD-style
and SVR4-style give to this function. Because sigaction() can emulate
both signal() behaviors, we use sigaction() exclusively.] Because
SA_SIGINFO was not implemented until a particular kernel level
(whose version numbers I don't remember), context information
suddenly changed when the kernel suddenly implemented it, since
we have always specified it (whether or not we actually use the
siginfo struct).
4. I fully expect things to get more stable now, as indicated in the
previous thread in which it was stated that Linux implementations are
now adhering to a standard signal interface. I would dearly love to
say "yes" to all Linux kernels, when asked if our lisp runs on them.
Hopefully now that things are settling down, we will return from being
gun-shy and start giving that answer more and more.
> is "How come _Perl_
> can run so well on all those _wildly_ differing systems?" Perl includes
> more operating system interaction than any other language around -- that
> interaction is half its raison d'etre -- and yet it manages to provide
> both a specific and a general interface to the operating system that
> remains portable and stable between releases of Linux kernels and glibc.
> Or at least so it appears. I realize that building Perl from scratch on
> any given system queries so many properties of the system that one has to
> marvel at the collective pain that its developers must have suffered, but
> this indicates that autoconf and similar GNU tools actually _do_ manage
> to collect and destill all the painful collective experience in porting
> code and building applications under the many and varied Unices. This
> experience should be eminently exploitable internally by vendors, too --
> using these tools does not "GNUtaminate" the product as far as I can tell.
I have never looked at Perl's source, and am not inclined to do so. So
perhaps someone who is curious can answer whether or not Perl does the
kinds of trap-based context-manipulation that we do in Allegro CL. As
an example, here is a stripped-down unbound-variable reference which
generates very little code, and yet allows a restart to return the
value to the register which got the unbound value (this is on LinuxPPC
on a Mac):
CL-USER(1): (defvar *x*)
*X*
CL-USER(2): (defun foo ()
(declare (optimize speed (safety 0) (debug 0)))
(excl::compiler-let
((comp::verify-symbol-value-is-bound-switch t))
*x*))
FOO
CL-USER(3): (compile 'foo)
FOO
NIL
NIL
CL-USER(4): (disassemble 'foo)
;; disassembly of #<Function FOO>
;; formals:
;; constant vector:
0: *X*
;; code start: #x40453f84:
0: 81970022 lwz r12,34(r23) *X*
4: 806cfffd lwz r3,-3(r12)
8: 7c8e1808 tweq r14,r3 "unbound"
12: 3a000001 [addi] lil r16,1
16: 82e10008 lwz r23,8(r1)
20: 4e800020 blr
CL-USER(5): (foo)
Error: Attempt to take the value of the unbound variable `*X*'.
[condition type: UNBOUND-VARIABLE]
Restart actions (select using :continue):
0: Try evaluating *X* again.
1: Set the symbol-value of *X* and use its value.
2: Use a value without setting *X*.
3: Return to Top Level (an "abort" restart).
4: Abort entirely from this process.
[1] CL-USER(6): :cont 2
enter an expression which will evaluate to a new value: 'hi
HI
CL-USER(7): *x*
Error: Attempt to take the value of the unbound variable `*X*'.
[condition type: UNBOUND-VARIABLE]
...
Note that the control locus returns to the instruction at byte 12
of the codevector, after setting the value of r3 to the value returned
in the error handler. Note that in this particular case, r3 had been set
to the unbound-value in the instruction at 4, and that *x* still has
that value, but the function FOO returned 'hi because it had been
stuffed into r3's location in the context in the trap handler. R3 also
happens to be the function's return-value register, but if the symbol-value
had chosen to put the result into another register, then the trap handler
would have stuffed that register instead.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Tim Bradshaw
> If you choose to officially support RedHat, you have few resources left
> to support any other distribution. Most of the acidic comments you find
> from vendors who debunk Linux as a mass of randomness and pain come from
> having had to deal with RedHat's utter lack of respect for stability and
> quality in the versions of things they ship. Of course, if you start off
> with RedHat, all other distributions _are_ different, giving a falsely
> negative impression. If you just ignore RedHat, the Linux world is so
> much less random and unpredictable.
This is unfair to redhat I think. You need to understand what they
are trying to do, which is steal market share from MS-based desktop
systems. Randomness and pain, lack of stability and low quality is a
requirement in this market. People *won't buy* stable, high-quality
systems for desktops.
This is also why Lisp doesn't do too well: if you can't cause the
system do crash impressively, preferably taking the OS with it (and,
for added value, trashing any large, critical data on any nearby
disks) bv a single trivial mistake, then you can't really expect to
succeed.
--tim
Tim Bradshaw
* John Foderaro
> Debian's very responsible package maintainers have kept buggy kernel
> versions and buggy versions of packages alike from hitting their users
> consistently for years, quite _unlike_ RedHat. For the same reason, the
> 2.4.11 kernel was not packaged up for Debian users even in the "testing"
> distribution. Those who want to track the kernel development know what
> the are doing. I would think everyone else _avoids_ upgrading their
> kernels until some trusted source says it is OK. My trusted source is
> the Debian project. And I do not trust RedHat at all -- doing so has
> cost me too much real money and real time in the past. But we also know
> that _trust_ means very different things to different people.
I think that there's a fair amount of macho `I-have-the-latest-kernel'
type people unfortunately who *don't* know what they are doing, but do
deserve what they get.
As for RedHat, shipping a version of gcc different than (and
occasionally binarily incompatible with) anything the gcc maintainers
want to support does not fill me with confidence so far. I can see
why vendors support RH though, since they must have a lot of market
share.
--tim
Friedrich Dominicus
>
> This is also why Lisp doesn't do too well: if you can't cause the
> system do crash impressively, preferably taking the OS with it (and,
> for added value, trashing any large, critical data on any nearby
> disks) bv a single trivial mistake, then you can't really expect to
> succeed.
Well spoken to get that level of maturity I suggest you wrap up around
a C function with at least 10 layered Macros. Hopefully people will
get bored to see all thos macorexpansions. Run that last macro and
crach the machine. Then cry out lout "I can crasch my computer easily
with Lisp", and watch the Lisp sellings raising :)))
Regards
Friedrich
Thomas F. Burdick
Or do it the easy way and ensure that all of your otherwise-uncaught
exceptions get handled by some (safety 0) code that does something
stupid. Ta-da! instant ldb> prompt (in CMUCL -- I'm sure you can
figure out something similar on your lisp system ;)
Erik Naggum
| 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.
cbbr...@acm.org
>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.
The thing that the Debian folks have done that has conspicuously _not_
happened amongst users of RPMs is to have a coherent way of building
not just packages, but whole sets of packages, including tools to do a
fair bit of validation that files are being stuck into the right
places and such. And that whole "world" is pretty accessable to the
public.
In the RPM world, the "world" is a set of packages that a small set of
engineers at Red Hat manage internally. (Or SuSe. Or Mandrakesoft.
Or whatever vendor...) The feedback loop is not nearly as public.
With Debian, there's a command, "reportbug," which submits problem
reports directly to the "engineer in charge," and puts it into a
publicly accessible database. No such direct feedback exists for the
RPM-based systems.
Arguably the BSD folks have an even better scheme, with their "make
world" approach, combined with "Ports"; you can pull arbitrary
proportions of your system out of public CVS archives, and recompile
it all locally, which means that you can be _sure_ that your libraries
all match.
Making something work on BSD ought to be a _snap_, so long as you can
be sure that the risky bits can be recompiled locally.
But everybody's too proud of their own existant systems integration
efforts to toss it out and adopt someone else's...
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.cbbrowne.com/info/
Never take life seriously. Nobody gets out alive anyway.
Pratibha
> 2. The problems we have had at Franz Inc with Linux has to do
> specifically with signal handling, and even more specifically
> with reading and changing the context in order to vector off to
> lisp interrupt handlers, and, for example, to return a value from
> the unbound-variable handler to the specific register in inline
> code in which received the unbound value (see example, below).
> If another lisp implementation or any other program doesn't do
> this kind of thing with trap handlers, then it will never see the
> kind of difference that we've seen between kernels.
Hi, I am curious to know if doing "this kind of thing" and the
consequent dependence on a distribution's (or kernel's)
signal handling peculiarities is unique to Franz' implementation.
Do Xanalys, CMUCL, and other Lisps also have this problem,
or do they avoid it somehow (and if so, how).
If this problem is unique to Franz, what is the benefit and bottomline
from the programmer's (as opposed to language implementor's) point of
view, compared with other implementations which "sidestep" it
(assuming "sidestep" is the right word).
For example, is there a correctness benefit, in that as a
result of doing "this kind of thing", the Franz behavior
is able to conform strictly to the language standard in
such and such situation, whereas Xanalys or CMUCL or others
do not, or may not necessarily, or may not always?
Anyway, I guess this thread has scared me [us] away from
RedHat. It sounds as if, for those of us without the
expertise or willingness or time to deal with RedHat problems,
or the willingness to use obsoleted distribution versions,
the best common denominator to run all of the 3 Lisps
are FreeBSD 4.x and, on the Linux side, the latest Debian,
and perhaps the latest SuSE (for installation ease).
Hopefully, Allegro won't have any problems with those,
even though Debian and SuSE aren't officially "supported".
I would dread getting those SIGSEGV violations that I
see being reported here every now and then...
(Lisp was supposed to free us from that sort of low-level
error, where you don't have a clue as to what hit you, no?)
Daniel Barlow
> Duane Rettig wrote
> > If another lisp implementation or any other program doesn't do
> > this kind of thing with trap handlers, then it will never see the
> > kind of difference that we've seen between kernels.
>
> Hi, I am curious to know if doing "this kind of thing" and the
> consequent dependence on a distribution's (or kernel's)
> signal handling peculiarities is unique to Franz' implementation.
> Do Xanalys, CMUCL, and other Lisps also have this problem,
> or do they avoid it somehow (and if so, how).
CMUCL and SBCL both use signals in (what appears from Duane's
description to be) a similar way to ACL. For example, in the
Linux/Alpha SBCL port, internal errors ("function does not exist",
that kind of thing) will run something like (from memory, this may be
wrong)
call_pal bug_chk
byte 10
byte foo,bar,baz,quux
where 10 is the error code and the following bytes are arguments to
the trap handler. This will cause the kernel to signal the process
with SIGTRAP; becaause we set up our sigtrap handler with the
SA_SIGINFO flag, it's called with a third argument containing a
ucontext structure, which has copies of the registers and the program
counter and similar things at the time of the trap.
(Why not use the normal bpt instruction? Because we're already using
that for breakpoints and it looked painful to change all the relevant
bits to have it serve both purposes. It's possible that we revisit
that decision in future, though, because I don't know how much of a
guarantee there is that newer kernels and newer PALcodes (BIOSes, more
or less) will continue to give us a user-level trap for bugchk)
After we're done handling the trap we need to resume execution at the
code following those data bytes, and we expect to be able to do this
by modifying the program counter in the ucontext that we were given.
We don't have coping strategies if the third argument is something
else, but consider
- SBCL is comparatively new and probably has never even been tried on
pre-2.2 kernels.
- It still doesn't work with the kernel/libc combination on the Sparc
we have access to, which doesn't appear to support SA_SIGINFO at
all. An upgrade may fix that.
(Actually, if anyone knows for certain what Linux/Sparc kernel
versions do support SA_SIGINFO, Christophe Rhodes would probably
be quite happy to hear from you)
- It was a problem with PPC as well, but that went away when I moved
from kernel 2.2.aged to 2.4.recent, and at the present rate of
progress a PPC SBCL is unlikely to be usable before practically
everyone is running 2.4 anyway. So, it could also have been fixed
in later 2.2 kernels, but I haven't investigated further
So, yeah. If we tried to support the range of systems that ACL does,
we'd have similar problems. As it is, it's free software. If it
breaks, you get to keep both pieces ;-)
Actually, I've just thought of another example of needing to modify
the register contents - calling the garbage collector from interrupt
context. When the GC moves objects around, it needs to update the
pointers to them - if some of those pointers are in registers, we'd
better update those too ...
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Doug Alcorn
> Arguably the BSD folks have an even better scheme, with their "make
> world" approach, combined with "Ports"; you can pull arbitrary
> proportions of your system out of public CVS archives, and recompile
> it all locally, which means that you can be _sure_ that your
> libraries all match.
Of course, I'm sure you know that you can 'apt-get source foo' and
build your own packages that way. I'm not sure how ports is better.
From what I've heard is pretty much the same as apt.
> But everybody's too proud of their own existant systems integration
> efforts to toss it out and adopt someone else's...
I'm not sure what this statement means. I personally wrote the
install script for our product. It was easier to do that than use
existing package formats. The problem is that I didn't want to have
to do rpm and deb and pkg (on solaris). It was much easier to just
write install.pl and put it in the tarball. It's not that I'm
particularly "proud" of my install.pl. It's just less effort.
cbbr...@acm.org
> cbbr...@acm.org writes:
> > Arguably the BSD folks have an even better scheme, with their
> > "make world" approach, combined with "Ports"; you can pull
> > arbitrary proportions of your system out of public CVS archives,
> > and recompile it all locally, which means that you can be _sure_
> > that your libraries all match.
> Of course, I'm sure you know that you can 'apt-get source foo' and
> build your own packages that way. I'm not sure how ports is better.
> From what I've heard is pretty much the same as apt.
The difference is that the default is to grab sources, and compile
them, rather than to _usually_ download precompiled binaries.
The merits are likely to be about threefold:
1. You might use CVS/rsync to update the source trees, which is
liable to be a bit more efficient than what Debian does now...
2. You might be able to do some bits of customization on (oh, say)
compiler options so that everything would be generated with your
favorite bits of tuning.
3. You can be _certain_ that library headers will match _perfectly_,
because your system compiled them, rather than being "virtually
certain," as is typically the case with binary packages.
The place where #3 is likely to be the most important is with C++
code, where variations in versions of G++ can have really significant
effects on whether programs and libraries can correctly interact.
> > But everybody's too proud of their own existant systems
> > integration efforts to toss it out and adopt someone else's...
> I'm not sure what this statement means. I personally wrote the
> install script for our product. It was easier to do that than use
> existing package formats. The problem is that I didn't want to have
> to do rpm and deb and pkg (on solaris). It was much easier to just
> write install.pl and put it in the tarball. It's not that I'm
> particularly "proud" of my install.pl. It's just less effort.
The point is _not_ about the packaging of one product; it's of the
packaging of whole "distributions."
The point is that the Linux distribution makers have too much invested
in their existing code bases to be willing to change things to conform
with someone else's approach.
Think of the amount of effort that would be required if (say) Red Hat
decided that they were (for the sake of argument):
a) Going to follow LSB in all respects, and so had to move all sorts
of bits of the system around, and
b) Replacing RPM with DPKG.
That would be quite a lot of work.
Throw in that doing this would be an admission that their "old ways"
were inferior - that loss of face would _not_ sell well at the
shareholders' annual meeting.
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.cbbrowne.com/info/nonrdbms.html
:FATAL ERROR -- ERROR IN USER
Rahul Jain
> The merits are likely to be about threefold:
> 1. You might use CVS/rsync to update the source trees, which is
> liable to be a bit more efficient than what Debian does now...
Debian works fine with CVS/rsync'ing the source tree. The only
problems may occur when the debianization patch has conflicting chunks
with the new source.
> 2. You might be able to do some bits of customization on (oh, say)
> compiler options so that everything would be generated with your
> favorite bits of tuning.
This is easy with debian. I export CFLAGS in my shell init script, and
when I apt-get -b source foo, it compiles with those CFLAGS
> 3. You can be _certain_ that library headers will match _perfectly_,
> because your system compiled them, rather than being "virtually
> certain," as is typically the case with binary packages.
Yes, this is what happens when you compile a .deb from source. Also,
debian is a single distro, so all the stuff in it works with
everything else unless there has been a binary ABI change. In that
case, just recompile the package and you're set.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:rahul...@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
Erik Naggum
| Not trying to start a Linux vs. FreeBSD flamewar [...]
I shall attempt to keep that in mind.
| Contrast this to the number of combinations that an ISV may have to deal
| with a Linux distribution. The base system is a (IMHO hodge podge)
| collection of independently maintained packages. It doesn't matter how
| good your packaging system is: you cannot precisely define the
| environment unless you specify the version numbers of several packages.
Nice try with yet more FUD, though. Debian delivers exactly as
well-defined releases as FreeBSD does. 2.2r3 is the current release.
FreeBSD folks need to figure out that while they have a definitve edge
compared to the worst Linux distributions, that does not mean they have
that an edge compared to the best Linux distributions. Why anyone would
want to compare themselves to anybhing _but_ the best is beyond me. I
guess it is the only way some people _think_ they can win, at least until
someone points it out to them, but from what I have seen of FreeBSD, it
is a worthy competitor even for the best of the Linuxes and should not
have had to resort to such game-playing.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
The purpose of computing is insight, not numbers. -- Richard Hamming
Johannes Groedem
> Fact: each individual system component in Debian is individually
> upgradeable.
Isn't it in FreeBSD, as well? What if there was a security hole in
some arbitrary part of the distribution? Wouldn't you upgrade it?
Individual system components in Debian are updated for the same reason
that components in FreeBSD are updated. Neither of them would update the
major version of a component within a stable release.
> Fact: individual system components in Debian are periodically updated
> even within the same release.
As they are in FreeBSD. (The "RELENG_4_4_0_RELEASE"-branch, for example,
and I think you also get binary package-updates now.)
> point where (the dynamically linked) /bin/sh stops working etc.
(You're right here, though, /bin- and /sbin-binaries should be
statically linked. I think it's strange that a distribution which
do so many other things right, that they've gotten this basic thing
wrong.)
--
johs
Erik Naggum
| Fact: each individual system component in Debian is individually
| upgradeable.
|
| even within the same release.
|
|
| So tell me, how exactly can you tell with any degree of certainty what
| 2.2r3 consists of without an inventory of all the relevant installed
| packages?
All these findings of facts hold for FreeBSD, too, do they not? Since
you claim that you can say what you say for FreeBSD, the onus of proof
remains on you to show it to be true for FreeBSD. When you have shown
that, you have also shown that it is true for Debian, because the same
conditions hold for Debian. In other words, I fail to see what your
argument really is, here. It looks like so much useless FUD.
| Perhaps you've been lucky enough to never have your Linux system hosed to
| the point of having to edit the package database manually (due to poorly
| specified package dependencies and conflicts), or getting burnt with libc
| changes to the point where (the dynamically linked) /bin/sh stops working
| etc. but I haven't been as lucky.
Oh, geez, another burn victim with another sob story. Just get over it!
Painful experiences that damage your ability to deal with a fast-changing
reality are just holding you back. Memory is a wondeful thing with us
humans, but not when you remember things that change under your feet. If
you choose to give priority to your painful memories over tracking the
developments that invalidate them, that should be a personal choice the
consequences of which should not be levied on anyone else.
Only if you have reason to believe that people are evil and do harmful
things on purpose, such as is obviously the case with Microsoft, can you
rely on prior experience to predict the future. Just because you had a
painful experiernce does not mean that somebody else meant to hurt you
_and_ will continue to hurt you if presented with the opportunity again.
These are disjoint judgments. Far too often, people who have been hurt
cannot see beyond their pain, but one of the most important, if not _the_
most important time to exercise your observational skills to the fullest
and require the utmost of your intelligence is when you experience pain,
because it is an indication that _something_ is wrong. Fortunately for
us humans as a species, that is just how the cognitive system works in
the psychical reality, but we seem to nee to be taught to do it in the
psychological reality we create for ourselves. The biggest intellectual
mistake you can make is to make up a conclusion from what looks like
convenient enemies at the time it hurts and then never re-examine it --
such is the very recipe for intellectual dishonesty and any disaster that
follows is easily trackable to that one decision not to think while you
experienced something painful. Unfortunately, people are effectively
taught to disconnect their thinking process while suffering pain, and it
is somehow legitimate in most Western societies to react irrationally to
something painful long after the pain itself is gone. This is just a bad
cognitive process and needs to be fixed, because it causes such things as
unfair characterizations of the work of other people, of other people as
such, of groups of people, of cultures, of countries, etc, and before you
know it, some monosyllabic president goes to war because he is pissed off.
Erik Naggum
| The problem that I have run into in the past with Debian is that some
| application upgrades trigger an update in the base package as well. On
| occasion this has resulted in changed version for the component even on
| stable releases.
Some of us are able to discern the subtle difference between normal and
abnormal situations before we base a blanket judgment of a system on our
painful experiences. Computers do not generally say they are sorry, but
that does not mean the person behind the computer's action is not. In
fact, most computers are far sorrier than their humans, but they do not
have the power to express their feelings, they just commit suicide when
they are too depressed. This explains the frequent "crashes" on Windows,
but I digress, sort of.
Erik Naggum
| In other words, no matter what you do under /usr/local, /usr does not get
| affected. For Debian, this is not true.
I am so relieved to see that you have no idea what you are talking about.
Debian does not place any packages in /usr/local. If you now blame the
package system for its ability to require packages or versions you have
not instaleled, you need to ask yourself whether you actually asked for
the right package for your system or went for that bleeding edge version.
If you did the latter, the problems you will run into are not caused by
any package system whose goal is to maintain sanity on your system: You
have brought the insanity. If the system actually _survives_, but needs
packages _outside_ of the distribution, which _you_ have to tell it how
to get from somewhere else, that is a credit to its design. Surviving
abuse by idiots is a good thing. Having said idiots not grasp this is
unfortunately the downside of not causing idiots to harm themselves when
they do really stupid things. That way, they never learn, but if they
get hurt, they tend to blame the wrong guy, anyway, so maybe the only
solution is to reject idiocy outright, but this generally gets in the way
of the work of intelligent, careful people.
| You could install an application package A (that would normally go into
| /usr/local in FreeBSD) which requires an upgrade to libc or libtermcap or
| ld.so (all of which have happened to me.)
And from where would you get this package and the upgraded versions?
_NOT_ from the Debian archives for the release you have installed. You
_must_ have tweaked /etc/apt/sources.list to get the behavior you fault
the distribution for. This is typical of people who lack relevant clues.
| In other words for, say, FreeBSD 4.3, you can definitively state the
| version numbers of various libraries whereas for, say, Debian 2.2 it
| depends on the exact mix of packages that have been installed.
You are factually wrong on this count. Please demonstrate the situation
you have observed and falsely accuse Debian of having caused, so maybe
somebody who pays attention to the details you have ignored can explain
back to you why you have made up your mind about blaming the wrong guy.
| FUD implies a vested interest. I have none.
Then stop presenting false accusations. Failure to do so _constitutes_
an agenda. And anyone who _had_ vested interests would say he had none.
| <standard Erik rant snipped>
Geez. How mature. But it appears that the standard Rajappa Iyer rant is
one of lying and false accusations. We shall remember this and not give
you a chance to change or improve because you do not grant that to others.
The number of FreeBSD "advocates" who need to falsely accuse various
Linux systems of problems they do not in fact have, is alarming. I am
not sure what cause this need to lie and misrepresent the competition is,
but it colors my impression of FreeBSD that so many of its adherents need
to engage in such tactics to make FreeBSD appear an alternative for
people who do stupid things and do not realize their culpability.
Pierre R. Mai
> Erik Naggum <er...@naggum.net> writes:
>
> > * Rajappa Iyer
> > | Fact: each individual system component in Debian is individually
> > | upgradeable.
> > |
> > | Fact: individual system components in Debian are periodically updated
> > | even within the same release.
> > |
> > | Fact: installing some package may result in an upgrade of another package.
> > |
> > | So tell me, how exactly can you tell with any degree of certainty what
> > | 2.2r3 consists of without an inventory of all the relevant installed
> > | packages?
> >
> > All these findings of facts hold for FreeBSD, too, do they not?
>
> No and here's why: the base system in FreeBSD is part of the OS src
> tree. The base system does not get updated as a result of adding a
> package; it gets updated only as a result of updating the base system.
The same is true of Debian. Since the only source of base packages is
the distribution, unless there are upgrades to the distribution (which
only happens through new releases), there is no way a base package can
get updated, period.
> In other words, no matter what you do under /usr/local, /usr does not
> get affected. For Debian, this is not true. You could install an
/usr/local is completely outside the realm of package managing systems
on Debian (and any other LSB-compliant distribution), so whatever you
do under /usr/local is up to you. And all the non-base packages (the
stuff that is comparable to the packages system of FreeBSD) of the
stable distribution only depend on other packages in the stable
distribution, hence they will not even request an update of
base-packages within a release. And even if they did, that request
would fail, and no updating would happen, because there is no source
for the new base packages to come from!
> application package A (that would normally go into /usr/local in
> FreeBSD) which requires an upgrade to libc or libtermcap or ld.so (all
> of which have happened to me.)
As said above, installing packages from a certain distribution onto a
system of that distribution will never require such updates. If it
did, this would be a bug, not something done by design.
And 3rd party applications/packages can of course require a newer
libtermcap than is installed on your system. But even in that case no
automatic upgrade to the base packages can happen, since there is no
source from which newer packages can be installed. So unless you
upgrade to a new distribution (which you can do incrementally, if you
want that), again no changes in base-package versions happens.
And the situation is identical in FreeBSD, if a 3rd party application
needs newer versions of some base packages, the only recourse you have
is upgrading to a newer release.
> In other words for, say, FreeBSD 4.3, you can definitively state the
> version numbers of various libraries whereas for, say, Debian 2.2 it
> depends on the exact mix of packages that have been installed.
That is untrue. Take a look at the base section of Debian 2.2r3, and
you will see exactly what packages can be installed, with what version
numbers. And you will find those exact versions on all of my Debian
2.2r3 machines.
Of course, if you add unstable or testing to your apt-sources, then
upgrades as you described can and do happen, since by so doing you are
indicating that you want to (incrementally) update to the new
distribution, and hence installing an application package from that
new distribution will of course often require matching base-package
versions, and hence automatic updates will happen.
But this is by your own choice of incrementally updating to the new
distribution. If you could do this in FreeBSD, then the same
"problems" would apply. Since FreeBSD, to the best of my knowledge,
doesn't allow incremental upgrading at this granularity-level,
associated problems of course don't apply to FreeBSD. But that's
hardly an advantage of FreeBSD, since Debian distributions can just as
easily be upgraded non-incrementally, (that's what apt-get
dist-upgrade is for).
Furthermore complaining about stability problems of unstable or
testing distributions seems hardly intelligent behaviour. Stay with
stable distributions, upgrade when they are released/when you are
ready, and I don't see (or have experienced) the problems you are
talking about (and I maintain lots of Debian based machines for many,
many years).
Now if you had complained about the larger frequency of incompatible
changes in Linux base-components (such as glibc, etc.) than on
FreeBSD, I would have been sympathetic. But blaiming the problems on
the packaging/distribution system seems strange.
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Tim Bradshaw
> FreeBSD maintains a distinction between the base system that is part
> of the FreeBSD distribution and third party applications. This is
> crucial to the stability of the system since third party applications
> cannot affect the main distribution. This is not the case (by design)
> of Debian or Red Hat.
However, Debian (by design) has a mechanism which ensures a similar
level of stability.
--tim (a FreeBSD user when I have time, and a BSD user since 4.1)
Ingvar Mattsson
> Tim Bradshaw <t...@cley.com> writes:
>
> > * Rajappa Iyer wrote:
> >
> > > FreeBSD maintains a distinction between the base system that is part
> > > of the FreeBSD distribution and third party applications. This is
> > > crucial to the stability of the system since third party applications
> > > cannot affect the main distribution. This is not the case (by design)
> > > of Debian or Red Hat.
> >
> > However, Debian (by design) has a mechanism which ensures a similar
> > level of stability.
>
> I'm unfamiliar with this mechanism. Could you or someone else
> elaborate? Email is fine.
Run "stable" and you get security fixes as needed.
Run "unstable" and hope things work out.
//Ingvar (I think "testing" is somewhere in-between, stability-wise)
--
When it doesn't work, it's because you did something wrong.
Try to do it the right way, instead.
cbbr...@acm.org
> "Pierre R. Mai" <pm...@acm.org> writes:
> > > application package A (that would normally go into /usr/local in
> > > FreeBSD) which requires an upgrade to libc or libtermcap or
> > > ld.so (all of which have happened to me.)
> > As said above, installing packages from a certain distribution
> > onto a system of that distribution will never require such
> > updates. If it did, this would be a bug, not something done by
> > design.
> But that's precisely the point of my objection: a bug in the package
> specification can result in changes to your base system. I consider
> this to be a systemic flaw that is endemic to the approach of
> package-izing the base system.
Fine; call it a "systemic flaw."
How many times have you been affected by this "systemic flaw?" How
many times have you observed this "systemic flaw" in action?
It's _not_ something that is commonly seen outside of the "unstable"
and "testing" environments, and those are environments that involve
some specific and conscious risks.
> > And 3rd party applications/packages can of course require a newer
> > libtermcap than is installed on your system. But even in that
> > case no automatic upgrade to the base packages can happen, since
> > there is no source from which newer packages can be installed. So
> > unless you upgrade to a new distribution (which you can do
> > incrementally, if you want that), again no changes in base-package
> > versions happens.
> This has not been true in my experience. If this has changed in the
> past couple of years, then I stand corrected.
_What_ has "not been true in my experience"?
- That automatic upgrade could not happen?
I see this precise scenario happen quite regularly, thank you very
much; I have the "Galeon" web browser installed, each version of
which depends on a particular version of "Mozilla."
Someone may update Mozilla; I don't pull that update until Galeon
has been brought up to date, at which point _both_ packages come in
to be upgraded at the same time.
It might be irritating not to have the latest version of Mozilla at
some points in time; the dependancy system has been nicely
maintaining the constraint that Galeon and Mozilla be upgraded in
sync with one another.
- That upgrades of base packages won't take place spontaneously?
If there's no new version of the libncurses5 package out there, then
_obviously_ there can't be any upgrade done to it.
At one point [obLisp reference], I tried adding some of the CCLAN
packages to a Debian/stable system. Somewhat unfortunately, but not
particularly surprisingly, I couldn't even so much as add in CLISP
from CCLAN without forcing it in as a source package, and then
pushing it _hard_, because parts of CCLAN depend on LIBC versions
that aren't available in "Debian/stable."
Note that the attempt to install CLISP from CCLAN _attempted_ to
request that a newer version of LIBC be installed. THAT COULDN'T
HAPPEN, because no newer version of LIBC was available in
Debian/Stable.
If you're going to claim that this isn't true, I suggest you point out
some specific instances. The above certainly reflects how the
dependency system is _designed_ to work; it also reflects how the
dependancy system is _observed_ to work.
> > Furthermore complaining about stability problems of unstable or
> > testing distributions seems hardly intelligent behaviour.
> So many assumptions.
The stable versions don't change very much, so it would seem quite
surprising for someone to observe significant stability problems with
the stable release.
Feel free to elaborate with _specifics_, if you can, although that
would fit better into the context of some other newsgroup.
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.cbbrowne.com/info/languages.html
Editing is a rewording activity.
-- Alan Perlis
[And EMACS a rewording editor. Ed.]
Stig E. Sandoe
> At one point [obLisp reference], I tried adding some of the CCLAN
> packages to a Debian/stable system. Somewhat unfortunately, but not
> particularly surprisingly, I couldn't even so much as add in CLISP
> from CCLAN without forcing it in as a source package, and then
> pushing it _hard_, because parts of CCLAN depend on LIBC versions
> that aren't available in "Debian/stable."
I think the cCLan-people would appreciate that you report this either
as a bug in the BTS or on the mailing-lists.
> Note that the attempt to install CLISP from CCLAN _attempted_ to
> request that a newer version of LIBC be installed. THAT COULDN'T
> HAPPEN, because no newer version of LIBC was available in
> Debian/Stable.
I think cCLan has currently tracked sid/unstable, but it would
probably be much appreciated if people with potato/stable reported
their issues and possibly contributed some time to test packages
for potato/stable. Until people with potato/stable can test these
things and report back the cCLan-team cannot do much. However, I'll
add a notice on the web-page that only sid/unstable is recommended.
However, I'd exploit the chance to say that cCLan now consist of
41 packages of lisp-code for x86, and 36 for powerpc and alpha. All
of them should be trivial to install and get working out-of-the-box.
Progress is limited to what people contribute. Even if you don't know
how to make such packages but have lisp-code suitable for a package
(or two) please contact the cclan mailing-list and you might get
help. Lisp to the people! :-)
(Yes, the goal is to make this work for other systems than Debian, but
the people doing the work now use Debian, so they need help from
other people who want a cool distribution-system for Common Lisp
code)
--
------------------------------------------------------------------
Stig E Sandoe st...@ii.uib.no http://www.ii.uib.no/~stig/
Michael Livshin
> However, I'll add a notice on the web-page that only sid/unstable is
> recommended.
FWIW, a combination of "testing" and cmucl from "unstable" works fine
for me. (or, if clisp & sbcl are enough, just "testing"). that would
be safer than "unstable", theoretically at least.
--
I think we might have been better off with a slide rule.
-- Zaphod Beeblebrox
Rahul Jain
> Another time, I think this was an update for XEmacs, a change in
> libtermcap ensued which triggered off some conflicting upgrades. This
> one didn't hose my system to the point that I was unable to boot to it
> without a rescue disk, but I did have to fix the package database by
> hand.
Sounds like you changed to unstable without upgrading to it and then
blamed debian on the fact that major upgrades in glibc require
upgrades in all packages on the system. Note that there is a
difference between compiled binaries and source code, so you're
comparing apples and oranges.
Erik Naggum
| On the contrary, Erik, you are the one that doesn't have a clue.
You admit to being vague because all this is two years old (what have I
been saying about your "experiences" and the dishonesty of using stale
painful experiences to _continue_ to post negative comments about
something?) and that you have no specific examples to back up your claim.
I already knew that, but it is good to see that you admit to this.
This leaves us with a very simple, straightforward conclusion: There is
absolutely no reason to believe anything you say. You are simply too
much of a dishonest person to have any credibility at all. Until and
unless you can show us exactly what you did and exactly what happened,
your whole set of experiences falls in the category of "idiot operator
error". Blame whoever you want, every honest person has to conclude that
it was your own goddamn fault. _No_ system can be so fool-proof that a
self-destructive, lying, angry fool cannot find something to blame it for.
Only good thing is it was a Linux and not a Common Lisp system that you
mistreated so badly that your hatred was misdirected towards Common Lisp.
There have been enough dishonest lunatics just like you who have been so
angry about their failure to understand what they are doing in Common
Lisp that they publish books about it. It is fortunate for Debian that
you are unlikely to be capable of such demanding intellectual endeavors.
Erik Naggum
of the poster:
Return-Path: <r...@panix.com>
Received: from mail1.panix.com (mail1.panix.com [166.84.0.212])
by naggum.no with ESMTP id <f9MKCoDh024580>
for <er...@naggum.net>; Mon, 22 Oct 2001 20:12:52 GMT
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mail1.panix.com (Postfix) with ESMTP id 736BC48766
for <er...@naggum.net>; Mon, 22 Oct 2001 16:12:44 -0400 (EDT)
Received: (from rsi@localhost)
by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id f9MKCi826485;
Mon, 22 Oct 2001 16:12:44 -0400 (EDT)
Message-Id: <200110222012...@panix2.panix.com>
X-Authentication-Warning: panix2.panix.com: rsi set sender to r...@panix.com using -f
Sender: r...@panix.com
To: Erik Naggum <er...@naggum.net>
Subject: Re: 3 Lisps, 3 Ways of Specifying OS
References: <18e1cdb3.01101...@posting.google.com>
<87pu7no...@balder.seapine.com>
<MPG.1635df64a...@news.dnai.com>
<87heszn...@balder.seapine.com> <32122772...@naggum.net>
<4n12qw...@beta.franz.com> <32123429...@naggum.net>
<%0nz7.7335$W61.6...@news20.bellglobal.com>
<87k7xtm...@balder.seapine.com>
<U%5A7.10228$3v.19...@news20.bellglobal.com>
<873d4dt...@photino.sid.rice.edu>
<n7ylmi4...@panix2.panix.com> <32126893...@naggum.net>
<n7yitd8...@panix2.panix.com> <32127030...@naggum.net>
<n7yhess...@panix1.panix.com> <32127373...@naggum.net>
<n7y3d4b...@panix2.panix.com> <32127691...@naggum.net>
From: Rajappa Iyer <r...@panix.com>
Date: 22 Oct 2001 16:12:44 -0400
Reply-To: r...@panix.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Erik Naggum <er...@naggum.net> writes:
> * Rajappa Iyer
> | On the contrary, Erik, you are the one that doesn't have a clue.
>
> You admit to being vague because all this is two years old (what have I
> been saying about your "experiences" and the dishonesty of using stale
> painful experiences to _continue_ to post negative comments about
> something?) and that you have no specific examples to back up your claim.
> I already knew that, but it is good to see that you admit to this.
>
> This leaves us with a very simple, straightforward conclusion: There is
> absolutely no reason to believe anything you say. You are simply too
> much of a dishonest person to have any credibility at all. Until and
> unless you can show us exactly what you did and exactly what happened,
> your whole set of experiences falls in the category of "idiot operator
> error". Blame whoever you want, every honest person has to conclude that
> it was your own goddamn fault. _No_ system can be so fool-proof that a
> self-destructive, lying, angry fool cannot find something to blame it for.
>
> Only good thing is it was a Linux and not a Common Lisp system that you
> mistreated so badly that your hatred was misdirected towards Common Lisp.
> There have been enough dishonest lunatics just like you who have been so
> angry about their failure to understand what they are doing in Common
> Lisp that they publish books about it. It is fortunate for Debian that
> you are unlikely to be capable of such demanding intellectual endeavors.
Do you do this to embarass your parents?
rsi
--
<r...@panix.com> a.k.a. Rajappa Iyer.
They also surf who stand in the waves.
Thomas F. Burdick
> The number of FreeBSD "advocates" who need to falsely accuse various
> Linux systems of problems they do not in fact have, is alarming. I am
> not sure what cause this need to lie and misrepresent the competition is,
> but it colors my impression of FreeBSD that so many of its adherents need
> to engage in such tactics to make FreeBSD appear an alternative for
> people who do stupid things and do not realize their culpability.
I think this is generally true of "advocates". I will sometimes
advocate Debian, but I'm not generally a Debian advocate -- I only
suggest it to people when I think that they will see a benefit from
changing; I don't go around suggesting Debian to FreeBSD'ers, or those
running Solaris, without a really good reason. Don't let the
loudmouthed FreeBSD advocates scare you away -- it's a really nice
system, and I'd guess that most Debian users, if forced to pick a new
OS, would go with FreeBSD over another linux distro. I know I would.
One of its biggest advantages over Debian is the fact that they
control the kernel. So they're not victim to the whims of the Linux
kernel maintainers. "Sure, let's release 2.4.x -- it must be time to,
since it's been so long -- any user hopes of a decent VM system, be
damned!" So, while my experience with FreeBSD was that it was harder
to run a *really* old system, it also wasn't as necessary.
Gonna be using kernel 2.2.x and Emacs 20.7 for a long time more...
(Yes, yes, I know I'm posting this from emacs 21 -- I meant for things
more important than news :)
Pierre R. Mai
> I updated some applications from the stable platform which required a
> new locales package which in turn required changes to libc. There was
> a broken conflict in the locales package which caused an incorrect
> attempted upgrade to libc and totally hosed my system.
Where did this updated application come from? The packages within one
release of Debian _are not_ updated, so I fail to see where this
updated application package could have come from.
Remember that your complaint was with base packages changing within
one release. They don't, just as application packages don't change
within one release.
The system breaking on upgrading to another release is not at issue
here.
Pierre R. Mai
> > As said above, installing packages from a certain distribution onto a
> > system of that distribution will never require such updates. If it
> > did, this would be a bug, not something done by design.
>
> But that's precisely the point of my objection: a bug in the package
> specification can result in changes to your base system. I consider
> this to be a systemic flaw that is endemic to the approach of
> package-izing the base system.
Maybe I don't make myself clear: Even _if_ any such bug existed, and
hence upgrades would be required, then they wouldn't happen
automatically, because there is no source for those updated packages
to come from. Hence installation of the application package will just
fail, with a clear error message. You file a bug report, the package
gets fixed, and that's it.
Not that I have encountered such a bug in my 6 years of Debian usage
in stable distributions (such things happen all the time in unstable,
but that's precisely what unstable is for).
> This has not been true in my experience. If this has changed in the
> past couple of years, then I stand corrected.
It hasn't changed in the past couple of years, it has always been this
way, to the best of my knowledge.
Erik Naggum
| Sheesh and you talk about dishonesty!
Smart people understand that personal communication can be employed to
change the outcome of an exchange without the possible embarrassment of
losing face in public. Idiots think personal communication is the best
venue to prove what utter misfits they are. You had an opportunity to
regret your behavior that you failed to use, and you got a chance to make
up for it, but you continued in your fantastically stupid and hostile
ways, simply because you are unwilling to admit to posting negative crap
about something based on vague memories of several years ago, which is
such an incredibly stupid thing to do that anyone with any brains would
have been better off admitting it was not productive, but you choose a
very different path, straight to self-destruction. I think you have done
enough damage to yourself by now. I hope you enjoy what you fought for.
Erik Naggum
| Meanwhile, how about explaining your dishonesty in posting email?
What is _dishonest_ about that? And why is that relevant to the fact
that you post two-year old vague memories of a painful experience that
you want to use to smear Debian unfairly for what looks like a stupid
operator error and do not accept that people who have a _very_ different
opinion than you do post corrections to your false claims and a different
take on it all? Why is it so important to have your false accusations
against Debian stand unchallenged? You have failed to come up with the
only thing that could redeem yourself: _evidence_. All you now claim is
that this is so long ago, you are vague, you no longer remember, etc.
Why then is the _conclusion_ still valid? Why do you _still_ believe
that Debian suffers the kind of problems you have _attributed_ to it with
what looks very much like idiotic prejudice and an enraged ignorance that
lashes out in random directions until it find something to attack and
then it keeps attacking no matter what the result is. Now you have gone
from attacking Debian to attacking me, with equally outlandishly stupid
and unfair nonsense. What is _wrong_ with you?
And do you think I am bound by the choices made by a deranged lunatic who
chooses to use e-mail to mount such a fantastically moronic personal
attack on me? It was _obviously_ meant for public consumption by the
very nature of the message. Insults and the like are _not_ private. The
person who receives an insult has the _right_ to post it _because_ it is
hurtful and damaging if it is _not_ made publicly visible. The only
defense anyone can possibly have against using personal communication to
harrass and insult people is precisely to post it and make the community
aware of the behavior of those who do such things. If you do not want to
have the mail you send exposed by people who do not want to respect your
desire to keep it private when you clearly do not respect the recipient
at all, adjust your behavior accordingly: Do not mail people any insults
over which you want to maintain control of distribution. It is that easy.
I really thought you had done yourself in, but just how stupid _are_ you,
Rajappa Iyer? Do you think _you_ have right to privacy when you choose
to invade people's private mail with unwelcome and insulting messages?
You _violate_ people's privacy by doing that, and then _you_ whine when
you get exposed? Why? Get a grip on yourself and snap out of your
stupid hostility. You are the transgressor here. You lie about Debian,
you choose to call people clueless, you refer to other people's concerns
over your ways "rants". What do you _expect_? And then you mail people
insults? How the hell did you think you could even _believe_ you could
get away with that?
I think you actually made a third-party application upgrade to your brain
and that the base system got seriously screwed up. Reinstall and reboot!
Erik Naggum
| The fact that you mis-represented it as mis-sent. A transparent excuse
| if there were ever one.
Yeah, that gives you _such_ a great excuse to be outraged, does it not?
Never mind that you proved to the whole Common Lisp community what kind
of person you are and that you dug your own grave so deep you get to stay
there for quite a while, did absolutely nothing to regret your action
when you had the chance, and continue to act like a little terrorist in
training. Just coughing up some real information about your gripes with
Debian is certainly out of the question for someone so stupid as you.
| > [more rabid insanity deleted]
Who do you think wins the most points when you resort to this behavior?
Do you think anything I have said about you is considered _less_ accurate?
| You must have me confused with someone who gets intimidated by your
| lunatic ravings. So give it a rest and take your medication. And a
| refresher course in netiquette.
Amusing. You really have _nothing_ left to argue with, anymore, do you?
It is actually quite amusing to watch people self-destruct so thoroughly
as you have. And just because you cannot deal with corrections to your
stupid negative propaganda against Debian and demonstrations that you
base your very strong negative opinions on vague memories and painful
experiences so long ago you cannot even remember what they were! You
want credibility for so useless negativism? You could have remembered
better and provided evidence, but what do you do? You attack me because
I ask you for the evidence that you cannot provide and because you know
that when you cannot present any evidence at all, you look like an idiot,
which I think you actually _are_, since a smart person who looked like an
idiot would back down and get back on top of things by admitting his
mistakes and learning from people who know better. I do in fact enjoy
exposing people like you for what you are, just like I get a personal
satisfaction from exposing racism and other forms of prejudice when it
runs amuck and causes people to act on stale information and too strong
emotions for their intellectual capacity.
But thanks for the good laugh. It always brings laughter to an enjoyable
day to find someone incoherently hurling random insults in all directions
in what looks very much like the imagery he himself brings up: medicated
insanity, suggest that somebody else, but never himself, take courses in
netiquette. Whoever taught you, Rajappa Iyer? This is just _too_ funny!
Erik Naggum
| What's the matter, can't take your own medicine? What's sauce for the
| goose is sauce for the gander. If you don't like being called a crook,
| feel free to stop calling others dishonest.
So the _only_ thing that I have ever actually done _wrong_ that you can
grab onto is that you think I "misrepresented" your insult as an obvious
case of a public message? Why, thank you! I thought I had done a lot
more bad things in my life than just that, but since you have found
absolutely _nothing_ of substance to attack me for besides your pathetic
outrage over having your incredibly stupid transgression posted under my
interpretation as it being an obvious public message, I am _honored_.
But why is that a wrong interpreration, by the way -- please explain why
your incredibly stupid insult was an instance of _proper_ use of personal
communication. If something is _not_ a proper use of a personal means of
communication when you have been communicating publicly previously in the
exact same way, is it not a _valid_ conclusion that you made a mistake?
Just because it makes you appear to be a stinking piece of shit does not
mean that you have anything to complain about. You brought this _all_ on
yourself, buddy. Small-time newsgroup terrorists who cannot deal with a
simple correction to their emotionally based propaganda originating in
stale painful experiences, but who blow up and become so irrational that
they completely lose track of what they _could_ do to improve their own
situation (namely: provide _evidence_ backing their opinions, for the
umpteenth time!), simply need to be shot down. In time, 90% of those who
behave this way and get shot down realize the simple corrections to the
errors of their ways and figure out that they should think and check the
_facts_ they talk about before posting any ludicrous drivel in the
future, The real idiots learn nothing, insist they did nothing wrong,
and come back to haunt the newsgroup with ever more insane "opinions".
(Then they will complain that other people do not tolerate differences of
opinion, despite the fact that _they_ do not tolerate that others post
opinions differing from theirs, illustrating that the real problem is
that other people do not agree with _them_, and they cannot argue for
their opinions, anymore, so anyone who does not agree with them, cannot
deal with "differing opinions". You have a mental illness indication in
two words right there. Just so you know, Rajappa Iyer, this may happen
to you some time down the line. It seems to take an inordinate inability
to back down from a demonstrably wrong position for it to happen, and you
have at least admitted that you are vague and remember nothing of value
about your painful Debian experiences of two years ago, so you could, in
theory, just hold on to your stupid opinion out of a desire not to lose
face, which will wane over time, and this stage might not happen to you.)
| Your amusement, such as it is, seems to be a manifestation of your
| psychoses. I suggest that you take your medication and reflect on why
| you're the only one with whom this exchange has deteriorated to this
| level.
Why are you so intent upon telling the whole world that your worst
nightmare would be to have to take medication to control your mental
illness? I think your ability to count has suffered tremendously, too.
There are two people in this exchange. A psychosis is the inability to
distinguish reality from purely mental constructions, one such obvious
case being the inability to see oneself as part of the problem, but you
share that with almost every rabid idiot who gets into flamewars on
USENET. There is nothing unique with me -- your behavior would get you
into serious trouble wherever anyone cares about truth and honesty and so
crack down on propagandizing lying idiots. You see, you have in fact
been posting a lot of false accusations against Debian based on your
vague memories and long past painful experiences whose substance you have
now forgotten. Psychosis is a pretty good name for living in a world
where emotions shape your _perception_ of reality to the point where you
can no longer deal with the facts, can no longer _remember_ the facts
that shaped your emotions, and refuse to update your emotions when you
must have seen that the facts have changed. I am a little surprised that
you tell us, by way of choosing your insults to unintelligently, that you
are very, very afraid of the stigma of psychosis. Why this fear? Anyone
who has figured out what people base their insults on knows that they
tell an interesting story about the person who does the insulting, and
has absolutely no relevance for the person insulted if this is known.
Unless, of course, the insult is based in fact, but the only facts we
have on USENET are what people choose to post. Some people tend to
forget that and start to presume things about other people based on what
_they_ think someone they can barely see through their emotional rage
must be like -- but that is just a mirror image of their own dark side.
It is fascinating to watch people drag in completely insane and out-of-
context things to try to insult other people and the only effect they
achieve is to tell everybody else what _they_ have a problem with. One
would have thought that people recognized this, but I believe people who
blow up this way have never been challenged intellectually and actually
believe thay are smart and in control of their lives, neither of which
are true, and when they realize that they are not, react violently.
| To the rest of the group: my apologies for this flamewar, I did try to
| take it email, but...
Intelligent people do not take flamewars to e-mail. Only rabit idiots
keep flaming people in private communication. You have proven that you
have _no_ desire to stop the flaming, so the halo you appear to don now
is a particularly egregious case of, in your words, "a transparent excuse
if there were ever one". Again, thank you for supplying us with more
details on your own modus operandi when your brain has snapped.
The only solution to your problem, however, is to provide _evidence_ of
the alleged problems you had with Debian's package system, which you have
so far refused to offer, admit that you were mistaken if you cannot find
such evidence, and retract your negative propaganda against Debian as
outdated and irrelevant. Since this seems to be impossible for you, you
destroy your credibility with every message you post that does _not_
contain such evidence. And since I keep telling you this and you have a
serious authority problem, you will not abide by this request at _any_
cost, either. I also find this particular part of the stupid behavior of
net.idiots quite amusing: It would blow any criticism of their stupid
behavior out of the water if they could swallow their pride, so the only
thing under _real_ attack is that pride. Imagine having tied your pride
to being _wrong_! It really is quite hilarious.
Now, let us see if a pathetic knee-jerk response is the best you can do.
Erik Naggum
| I don't know what else one calls posting email to newsgroups, but hey,
| whatever floats your boat.
If you send me a message, I can do whatever I want with it until I agree
to some particular terms, such as by replying privately to it, in which
case I have _agreed_ to make the exchange private. You may not have
noticed, but I made no such agreement with you at all, and certainly no
promise or claim that I would not post it. That you think this has
anything at all to do with dishonesty betrays an utter failure to grasp
what honesty is and applies to, which is hardly surprising, considering
how you attempt to insult people by making up one thing more idiotic than
the next instead of at least _trying_ to hit the target. Sheesh!
As for _your_ intentions, you simply failed to communicate them. Lots of
people send mail when they wanted to post and some even the reverse -- it
is a common mistake and smart people know this. It is therefore a very
good idea to label messages _intended_ to be private as such, but you did
not do that, did you? I repeat, and I mean it: the message was obviously
intended for public consumption, by the very nature of the contents
(private flames are _so_ idiotic that a sender _must_ be presumed to have
made a mistake lest be presumed completely braindead), by continuing a
public flame (no difference from anything you _have_ posted), by _not_
being labeled private, and by coming from a person very likely to be
careless enough to make such a mistake and stupid enough not to admit it,
but instead attempt to take advantage of it, which you also have done,
which is really quite amazing.
_If_ I had replied to you in private and _if_ I had agreed to keep it
personal, I would have lied about it being intended for public view. The
problem here is that you failed to understand which options you had and
chose among -- I fault you most of all for not exercising _any_ of the
smart options, but going _only_ for the really retarded ones.
Incidentally, have you noticed anything in the news lately about how
unwelcome personal mail is handled? So far, the sender of these letters
has at least been smart enough to refrain from jumping up and accusing
the news media of publishing them.
| I always thought that the conventional advice in a flamewar was for the
| concerned parties to take it to email.
It means "take it outside", you doofus, an attempt at being polite when
really yelling "GO AWAY!", but polite does not work with some people --
they have to be yelled at to grasp the slightest little thing, and most
of them do not even get it after _several_ attempts, like you. It is not
a recommendation to be taken literally. Geez, some people!
Why would anyone want to send, much less receive, flames by mail? Flames
received by mail can be used for only one thing: public posting, like on
web pages or in newsgroups. Otherwise, trash them, like spam, and forget
them. If they actually hurt, public posting is the only option, because
the person behind it needs to be exposed and punished, and one cannot do
that in mail. Just look at you, you do not even grasp that you have done
something wrong in this thread even though the whole world is watching
you self-destruct while you deny it. If you can sit there and continue
to behave as if you were right in all your whining about Debian, imagine
what _lack_ of public exposure does to a drooling idiot's conviction that
he is in the right and everybody else is in the wrong!
Sending abusive messages by mail requires that the sender believes he has
the right to _dictate_ what the recipient should feel able to do with the
message -- indicating that abusive mail is also a power game -- such as
respecting the sender's privacy while the sender disrespects and violates
the private space of the recipient. This is quite rich! You would have
to be really stupid and unprincipled and generally a bad person to think
you could get away with this, much worse if you think it is a good idea
and gives you any right to complain about what heppens to you afterwards.
Again, some people! Face it: Once you send a message on the Internet, it
is out of your control. It is even true for good old paper-based mail.
The only thing you can do is to try to make sure people who receive your
private messages actually _do_ feel bound by a sense of privacy in the
communication, and that means being _nice_ in private communication. Why
does this take more brainpower than some people have at their command to
figure out? Don't they _ever_ think?
| I certainly do not wish to stop the flaming
I'm glad to see that you can admit _something_.
Erik Naggum
| You're the last person who should be lecturing anyone about politeness.
*laugh* After what you have been doing here -- just look at yourself! --
you still think you have the right to complain about _anything_ relating
to etiquette and politeness! This is just too damn funny.
| I'll happily admit to not being intimidated by a thug.
It is really quite amusing to see how simple-minded the fantasy world is
that you have to make up so you can relate to what you do not understand
And it is quite appropriate that you resort to "thug" -- you do seem like
a person who is unable to deal with other people with mind and language,
and the imagery you prefer is one where muscles are the only source of
strength and power. So I can only assume that this is true for you. In
_my_ simple world, people who think muscles are a source of strength and
power are recyclable trash. But you are welcome to your fantasy world,
as it explains so much of your amazingly unintelligent behavior when you
have simply been requested to cough up the _evidence_ to support your
negative bullshit about Debian, which you refuse to do, for the obvious
reason: You have been fully aware that your tarnishing Debian has been a
dishonest ploy from the get-go, and now you pretend to be upset that your
insulting personal mail got posted with a tongue-in-cheek comment that
only you have a transparent excuse for a problem with. I wonder how
people like you manage to survive -- some _thugs_ should have eliminted
you long ago if you had managed to behave as stupidly in real life.
Erik Naggum
| The disconnect with reality ...
So you have snapped for good. It had to happen. Enjoy your personal reality.