Hi,
Version 1.0 of the Linux standards base has been released. This
should allow software vendors to support all conforming
distributions (instead of out-of-date releases of RedHat).
Do the commercial Lisp Vendors have plans to support Linux, rather
than a specific distro?
You would increase the likelihood of people like me buying your
products, significantly.
Regards,
Peter
Peter Wood <··········@worldonline.dk> writes:
Speaking only for my own company and product:
> Version 1.0 of the Linux standards base has been released. This
> should allow software vendors to support all conforming
> distributions (instead of out-of-date releases of RedHat).
Unfortunately, it is the out-of-date versions of linux kernel that
most of our customers want to be compatible with. Some of these
customers have cusetomers themselves, and they cannot just upgrade
to the newer version at will. The previous lack of standards in the
signal-handling interfaces has cuased us no end of headaches, because
our product uses signals to a great extent and they _must_ work
correctly. Because new major releases of linux (x86 and ppc are the
ones we currently support) completely change the interface of signal
delivery, and until recently none of these delivery techniques have
conformed to any standard, we are constantly doing new "ports" to new
versions of the kernel and/or libc.
> Do the commercial Lisp Vendors have plans to support Linux, rather
> than a specific distro?
We have always had such plans. The problem has always been deciphering
the signal-delivery mechanism on each "distro", which has never followed
a standard.
> You would increase the likelihood of people like me buying your
> products, significantly.
That would, of course, be a major goal in our efforts!
--
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 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Peter Wood <··········@worldonline.dk> writes:
>
> Speaking only for my own company and product:
>
> > Version 1.0 of the Linux standards base has been released. This
> > should allow software vendors to support all conforming
> > distributions (instead of out-of-date releases of RedHat).
>
> Unfortunately, it is the out-of-date versions of linux kernel that
> most of our customers want to be compatible with. Some of these
> customers have cusetomers themselves, and they cannot just upgrade
> to the newer version at will. The previous lack of standards in the
> signal-handling interfaces has cuased us no end of headaches, because
> our product uses signals to a great extent and they _must_ work
> correctly.
Well, that is reasonable enough. There can be good reasons for using
old kernels, which are still maintained.
Your company's web site advertises support for:
linux 2.x, x86 RedHat 5.x, 6.x. Presumably, you have solved your
signals problems sufficiently to be able to support RH 5.0 with
kernels ranging from 2.0 to 2.4.5+ ?!?
If it is the kernel version which is the critical factor, then why not
offer support for _that_ kernel version (or range of versions), rather
than support for a specific distribution's release number?
I put my own systems together, and I could easily do so to conform to
the support requirements specified by Franz or Xanalys, if those
requirements are of the sort "kernel xxx, libc xxx, binutils xxx" etc.
> > You would increase the likelihood of people like me buying your
> > products, significantly.
>
> That would, of course, be a major goal in our efforts!
You have not convinced me that you really are interested in this. Why
not specify your requirements for supporting your product in enough
depth that anyone can satisfy those requirements in a system?
Regards,
Peter
In article <··············@localhost.localdomain>, ··········@worldonline.dk says...
> You have not convinced me that you really are interested in this. Why
> not specify your requirements for supporting your product in enough
> depth that anyone can satisfy those requirements in a system?
>
Consider the N dimensional matrix that results from considering
all combinations of the N different
parameters that characterize a Linux distribution (you mentioned
Kernel Version, libc version, binutils version and there are others
as well). You want Franz to identify all combinations for
which a version of ACL work. Considering how long it takes
to test ACL for a single combination of these parameters (e.g
what's in RedHat 7.0), the work involved to explore the
whole combination space and find all combinations in which ACL works is
massive.
If you are saying that instead of saying that ACL works in
RedHat 7.0 we say that it works in Kernel version X, libc version Y
and binutils version Z then this is both too general and too
restrictive.
It's too general because we don't know that there isn't a distro
out there with the same versions of the components that we
specify for which ACL doesn't work due to some other reason
(an odd pathname structure or some strange filesystem we
haven't seen). No company can afford the time to test their
product on all Linux distributions.
It's too specific because we know that ACL also works
in versions near the versions we specify. We don't know
the exact range of versions for which it works (and computing
that is too expensive, see above).
Thus what we specify is a Linux distribution for which we've
tested that it works. You can decide how far away your
distribution is from the one we specify.
I think that this is the only reasonable model for commercial
companies selling very complex products on Linux.
It remains to be see how the Linux Standards Base works out.
To be really successful they need to have a tool that
scans programs to ensure that the application conforms
to the Linux Standards Base and thus has the desired
portability.
Hello John,
Since both your company (Franz) and Xanalys
provide free evaluation versions for Linux, it
seems relatively easy for people to try the
trial version on their Linux distro of choice.
Even though I need to boot Win2000 frequently
for tasks for some customers, I really prefer
Linux, so it is a little sad (but interestring) to hear
your comments concerning the difficulties for
commercial vendors to support Linux.
Best regards,
Mark
--Mark Watson
--Java consulting, Open Source and Content: www.markwatson.com
John Foderaro <···@unspamx.franz.com> writes:
> In article <··············@localhost.localdomain>, ··········@worldonline.dk says...
> > You have not convinced me that you really are interested in this. Why
> > not specify your requirements for supporting your product in enough
> > depth that anyone can satisfy those requirements in a system?
> >
>
> Consider the N dimensional matrix that results from considering
> all combinations of the N different
> parameters that characterize a Linux distribution (you mentioned
> Kernel Version, libc version, binutils version and there are others
> as well). You want Franz to identify all combinations for
> which a version of ACL work.
Absolutely not. I am asking you to specify the versions of the
(possibly) critical components which make up the systems you _have_
tested your product on. Obviously a very large proportion of a RedHat
system is totally irrelevant to the functioning of your product. You
are not suggesting that ACL depends on most of the fluff which
comprises a commercial Linux distribution?
>
> If you are saying that instead of saying that ACL works in RedHat
> 7.0 we say that it works in Kernel version X, libc version Y and
> binutils version Z then this is both too general and too
> restrictive.
>
> It's too general because we don't know that there isn't a distro
> out there with the same versions of the components that we
> specify for which ACL doesn't work due to some other reason
> (an odd pathname structure or some strange filesystem we
> haven't seen). No company can afford the time to test their
> product on all Linux distributions.
>
I am not suggesting you do that. I agree that it would be
impractical, if not impossible. But you know your product works with
certain version numbers of n critical components of x RedHat
distribution. The list will be quite short, since _most_ of any
distribution will not be essential for ACL's functioning.. Please
specify these version numbers for your customer to qualify for
support. Specify the file system, if that _might_ be critical. I am
asking you to say "it works with _this_ combination: blah blah blah".
Not "it works with Redhat 6.2". As you know, a Linux system is
completely user-customisable. I can take a RedHat 6.2 and upgrade the
kernel, mangle the pathnames, put in devfs, a journalling file system,
a new libc version, etc. Am I still using RedHat 6.2 ? Do I still
qualify for support? This is not a hypothetical question. (Perhaps
this is answered in the small print of your licence ;-))
> It's too specific because we know that ACL also works
> in versions near the versions we specify. We don't know
> the exact range of versions for which it works (and computing
> that is too expensive, see above).
Again. I am not asking you tell me the range of versions. I am
asking you to say: "Our product has been tested on a Gnu/Linux system
with the following critical components [list of versions]. If your
system uses these versions of these components, you qualify for the
support which you are paying for anyway." You are free to cover
yourself as thoroughly as you like. You could even say: "If you alter
your system in any way which affects the functioning of the listed
components, you are no longer entitled to support."
If you really think my suggestion is unrealistic, perhaps your company
would contemplate an alternative licence for its product on untested
Linux systems. ("We don't say it will or won't work on your system,
and wether it does or not, we won't support it. On the other hand,
you get it at 1/nth of the full price.")[1]
Regards,
Peter
[1] Actually, come to think of it, this looks suspiciously like a
typical commercial software licence, apart from the 1/nth bit ;-)
In article <··············@localhost.localdomain>,
Peter Wood <··········@worldonline.dk> writes:
> support. Specify the file system, if that _might_ be critical. I am
> asking you to say "it works with _this_ combination: blah blah blah".
> Not "it works with Redhat 6.2".
Since "RedHat 6.2" is just a short hand for a particular "blah blah blah", I
don't see what your point is. It's very easy to find out what "RedHat 6.2"
consists of. You can find the list here for instance:
http://www.mikemac.com/mikemac/redhat62.html.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
| Since "RedHat 6.2" is just a short hand for a particular "blah blah blah", I
| don't see what your point is. It's very easy to find out what "RedHat 6.2"
| consists of. You can find the list here for instance:
| http://www.mikemac.com/mikemac/redhat62.html.
I think he means that if you have a system that consists of "blah blah
blah", but that isn't "RedHat 6.2", you probably won't qualify for
support (at least it's not clear to me that you'd qualify). I think
that's a valid point. I can also imagine systems wich consist of
"blah blah blah" + "blah" that won't work, and I can just as well
imagine a "RedHat 6.2" + "blah" system that won't work.
The question then becomes: Are there more "blah blah blah" + "blah"
than "RedHat 6.2" + "blah" systems that screw up your Lisp?
I honestly have no idea, so I'm not going to answer that one.
Boris
--
·····@uncommon-sense.net - <http://www.uncommon-sense.net/>
Paranoids are people, too; they have their own problems. It's easy
to criticize, but if everybody hated you, you'd be paranoid too.
-- D.J. Hicks
In article <··············@localhost.localdomain>, ··········@worldonline.dk
says...
> Absolutely not. I am asking you to specify the versions of the
> (possibly) critical components which make up the systems you _have_
> tested your product on.
Do you feel that you could identify those components?
We continue to have a problem with some distributions
which have an /etc/fstab that mounts cdroms in noexec mode
so users can't execute the script on the cdrom that installs
our Lisp. Would you have thought to list /etc/fstab as
a critical component?
Basically we're just telling you the truth. We test our
lisp on a set of distributions and we tell you what
those distributions are. We don't tell customers
that they have to use those distributions and many
use other distributions successfully. We try to
help people past problems no matter which
distribution they are using. But if it comes down
to something in your system that prevents Lisp
from working (like an experimental signal stack
layout in your kernel) for which we can't suggest
a workaround, we have to be able to point to
set of distributions and say that we only can support
it working on these distros. Otherwise
supporting Lisp (or any other complex product) on
a large set of custom OS's would be impossible.
-john foderaro
franz inc.
In article <··············@localhost.localdomain>,
Peter Wood <··········@worldonline.dk> writes:
>
> Hi,
>
> Version 1.0 of the Linux standards base has been released.
Debian actually agreed to this? LSB specifies RPMs! And then there's this
from the table of contents:
A. Alphabetical Listing of Interfaces
libX11
libXt
libm
libGL
libXext
libICE
libSM
libdl
libcrypt
libz
libncurses
libutil
libc
libpthread
librt
Must be one of those new internationization sorting orders!
Mike McDonald
·······@mikemac.com
Mike McDonald wrote:
> In article <··············@localhost.localdomain>,
> Peter Wood <··········@worldonline.dk> writes:
>>
>> Hi,
>>
>> Version 1.0 of the Linux standards base has been released.
>
> Debian actually agreed to this? LSB specifies RPMs! And then there's
> this
> from the table of contents:
>
> A. Alphabetical Listing of Interfaces
> libX11
> libXt
> libm
> libGL
> libXext
> libICE
> libSM
> libdl
> libcrypt
> libz
> libncurses
> libutil
> libc
> libpthread
> librt
>
> Must be one of those new internationization sorting orders!
Ah no.. it is sorted by looking at the first three characters ;-)
ciao,
Jochen
·······@mikemac.com (Mike McDonald) writes:
> In article <··············@localhost.localdomain>,
> Peter Wood <··········@worldonline.dk> writes:
> >
> > Hi,
> >
> > Version 1.0 of the Linux standards base has been released.
>
> Debian actually agreed to this? LSB specifies RPMs! And then there's this
> from the table of contents:
>
I didn't see the preceding article, so this may or may not be on
topic.
The last time I read the LSB (which was not 1.0, but an older
version), it said that the system does not neccessarily have to use
RPM itself, but allow users to install RPM packages in some way.
Debian has the ``alien'' tool -- which is *specifically* mentioned in
the standard as an alternative to directly using RPM (IIRC). So
hopefully in Debian, RPM will be a wrapper script around Dpkg, not the
other way around... ;)
> A. Alphabetical Listing of Interfaces
> libX11
> libXt
> libm
> libGL
> libXext
> libICE
> libSM
> libdl
> libcrypt
> libz
> libncurses
> libutil
> libc
> libpthread
> librt
>
> Must be one of those new internationization sorting orders!
>
Yes, didn't you hear that LSB decided on Elvish as the default
language? It was written and sorted in Tengwar (the cursive Elvish
letters, not those blocky runes!), and they used Babelfish to
translate it to English. SuSE, being a very internationalized
GNU/Linux distro, has refused to comment on this important decision.
However, their German users report that their terminal screens are
``Ein unlesbar schlamassel'' (An unreadable mess)... and American SuSE
users complain that, with SuSE Linux 8.0-beta's ``Audio Passwords''
feature turned on, they cannot get in by vocalizing their password,
but only by saying the word ``Friend''... ;) , <jk> (== Just Kidding
-- I think this ``emoticon'' is more common on Compu$erve than Usenet
-- but I don't use C$ so I'm not sure)
> Mike McDonald
> ·······@mikemac.com
>
Hope this-- oh, wait, never mind, this post isn't very helpful at all, sorry.
But at least now you know what someone means when you're on your
Debian box, and change directory to /usr/bin, and someone watching you
work screams ``*Don't cd to that directory--THE ALIEN'S IN THERE!''...
at that point you may choose to reveal to that person the great secret
that ``rm -rf ~'' will increase the space available so as to not
exceed their disk quota... (After all, that pun is Posix and LSB
compliant but not X/Open compliant :).)
The good thing about standards is that there are so many to choose from.
-- Andrew S. Tanenbaum
--
BPT <···@hobbiton.org>
backronym for Linux: Linux Is Not Unix
Hello Peter,
I never run the very latest kernel (usually use whatever is
in Debian stable). I don't think that I have ever
had a problem getting LispWorks or the Franz demo
running. The same comment holds for other Linux
software that I need to work (e.g., StarOffice, JBuilder,
TogetherJ). Also: same success with SuSE and Caldera,
although I prefer Debian (more work, more fun :-) )
OTOH, I have lots of problems getting fonts the way
I like them.
I am a little sceptical of the Linux Standards base, but perhaps it could be
a good thing.
Best regards,
Mark
--Mark Watson
--Java consulting, Open Source and Content: www.markwatson.com
"Mark Watson" <·····@NOSPAM_markwatson.com> writes:
> Hello Peter,
Hi,
>
> I never run the very latest kernel (usually use whatever is
> in Debian stable). I don't think that I have ever
> had a problem getting LispWorks or the Franz demo
> running.
I build my own systems, and have never had significant trouble getting
_anything_ to _build_ on them. I have also run LispWorks' and Franz'
demos without problems. The issue is that I will certainly not pay
for a commercial product which is not supported on my system. That is
why I have suggested that vendors specify in detail the requirements
for support eligibility.
Duane Rettig complained that the kernel's ever-changing treatment of
signals made it very difficult for Franz to support a wide range of
kernels, but according to Franz' website, they support kernel 2.x on
x86 RedHat 5.x 6.x. That is a fair range, in my opinion, and suggests
that they could easily support more distributions if they just went to
the trouble of specifying their requirements in more detail.
>
> I am a little sceptical of the Linux Standards base, but perhaps it could be
> a good thing.
>
It might be. I was a bit shocked to see that they specify rpm as the
package installer. Count me out.
Regards,
Peter
Peter Wood <··········@worldonline.dk> writes:
>Version 1.0 of the Linux standards base has been released. This
>should allow software vendors to support all conforming
>distributions (instead of out-of-date releases of RedHat).
I must be mistaken if that fixes the Kernel changes problem. If you
look over the list of breakages that CMUCL had in the last years due
to glibc and kernel changes, you see that the kernel is responsible
for its fair share.
*Especially* since you don't get CVS commit messages for changes in
the Linux kernel like for virtually every other piece of free
software.
I wont even start on the glibc mess.
>Do the commercial Lisp Vendors have plans to support Linux, rather
>than a specific distro?
Not commercial, but CMUCL of course tries to be compatible with all
Linux sytems and we have it comparibly easy since we do a lot of
system-dependent stuff ourself (that is a misfeature on a more
structured OS).
>You would increase the likelihood of people like me buying your
>products, significantly.
Just use FreeBSD. Allegro is available for FreeBSD and the Linux
version of Lispworks runs on it.
If you decided to use Linux, you'll have to learn to fix such problems
yourself, unless you use the most common Linux distro in existence
(which is usually crappy and outdated).
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Martin Cracauer <········@counter.bik-gmbh.de> wrote:
: If you decided to use Linux, you'll have to learn to fix such problems
: yourself, unless you use the most common Linux distro in existence
: (which is usually crappy and outdated).
very well said.
--
Reini Urban
Reini Urban <······@x-ray.at> writes:
> Martin Cracauer <········@counter.bik-gmbh.de> wrote:
> : If you decided to use Linux, you'll have to learn to fix such problems
> : yourself, unless you use the most common Linux distro in existence
> : (which is usually crappy and outdated).
>
> very well said.
> --
> Reini Urban
The most common Linux distro in existence? What the fuck is that?
How do you know its the most common? What is 'crappy'? What is
'outdated'?
Depending on your situation, there can be good reasons for using old
kernels.
My original post, to which Martin replied, concerned _commercial_ Lisp
vendors. The whole point of the posting, was to show that Lisp
vendors *don't* *support* *linux*. They charge you the full price for
their product, regardless of which distro you are using. But unless
you are using a system from RedHat of a specific version number, you
are *not* *legally* entitled to the support which you have paid for.
Its just typical, sharkish practice from proprietary software vendors.
I don't care that their systems 'probably' work with other Linux
distros. I don't care that they will 'try' to help me if I experience
problems. I want people (Linux users) to be aware of what they are
getting when they buy proprietary software.
I am not quite sure why Martin replied, since I did specify
_commercial_ lisp vendors in the original post.
Martin likes the public-domain type licence. I don't, although its
better than proprietary licenses. Where I have a choice, I will
always use GPL'd software. Thus: Linux, rather than FreeBSD; CLISP
rather than CMUCL.
Of course, if anyone wants to, they can download CMUCL and release it
as myname-lisp under the GPL, or myname-lisp under a proprietary licence.
Regards,
Peter
>>>>> "PW" == Peter Wood <··········@worldonline.dk> writes:
[...]
PW> They
PW> charge you the full price for their product, regardless of
PW> which distro you are using. But unless you are using a system
PW> from RedHat of a specific version number, you are *not*
PW> *legally* entitled to the support which you have paid for.
Don't they tell you this upfront? How is this different that buying
a 3rd. party add-on meant for American cars and then expecting the
manufacturer to be contractually or otherwise obligated to support
installation on a German car?
PW> Its just typical, sharkish practice from proprietary software
PW> vendors.
It might be typical, but I don't see how it is "sharkish." It I
understand you correctly you take supporting Linux to mean any version
of kernel, libc, other libs, FS layout, past, present, or future. So
I pay, say, Xanalys $800, monkey with my system/kernel, break LispWorks,
send them e-mail and they magically get the manpower to accomodate me.
If they don't, they are sharks? Just trying to understand here.
PW> I don't care that their systems 'probably' work with other
PW> Linux distros. I don't care that they will 'try' to help me if
PW> I experience problems. I want people (Linux users) to be
PW> aware of what they are getting when they buy proprietary
PW> software. [...]
I think they do and I have not seen evidence of vendors trying to
confuse people. The problem you are alluding to exists for any piece
of software. It does not magically disappear with open source (re:
Peter Van Eynde's remarks about the experience he's had keeping CMUCL
alive on Linux), nor is it necessarily cost-free to solve even with GPL.
It is entirely possible I am misunderstanding you. But if not, I'd like
to know why you think it is OK or necessary to say stuff like "sharkish
behaviour" about companies which, by all accounts here, have been honest
businesses.
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "PW" == Peter Wood <··········@worldonline.dk> writes:
> [...]
>
> PW> They
> PW> charge you the full price for their product, regardless of
> PW> which distro you are using. But unless you are using a system
> PW> from RedHat of a specific version number, you are *not*
> PW> *legally* entitled to the support which you have paid for.
> I pay, say, Xanalys $800, monkey with my system/kernel, break LispWorks,
> send them e-mail and they magically get the manpower to accomodate me.
> If they don't, they are sharks? Just trying to understand here.
Don't try too hard. If I buy a sack of potatoes + delivery for 10
bucks, and I get the potatoes delivered, well and good. If the seller
decides I live too far away for delivery, he should give me a
reduction in the price, or *specifically* warn me that I am paying for
something I am not going to get.
Here's what my bill looks like:
1 sack potatoes ------------ $8.50
delivery -------------------- $1.50
Get it? Get it? Get it? Huh?
> PW> I don't care that their systems 'probably' work with other
> PW> Linux distros. I don't care that they will 'try' to help me if
> PW> I experience problems. I want people (Linux users) to be
> PW> aware of what they are getting when they buy proprietary
> PW> software. [...]
>
> I think they do and I have not seen evidence of vendors trying to
> confuse people. The problem you are alluding to exists for any piece
> of software. It does not magically disappear with open source (re:
> Peter Van Eynde's remarks about the experience he's had keeping CMUCL
> alive on Linux), nor is it necessarily cost-free to solve even with GPL.
>
It doesn't apply to CMUCL because I don't pay for support.
> It is entirely possible I am misunderstanding you. But if not, I'd like
> to know why you think it is OK or necessary to say stuff like "sharkish
> behaviour" about companies which, by all accounts here, have been honest
> businesses.
>
'Honest business' is a legal thing, right? You are 'honest' if you
don't break the law. So yes, I think they are probably 'honest'.
Regards,
Peter
>>>>> "PW" == Peter Wood <··········@worldonline.dk> writes:
[...]
PW> Don't try too hard. If I buy a sack of potatoes + delivery
PW> for 10 bucks, and I get the potatoes delivered, well and good.
PW> If the seller decides I live too far away for delivery, he
PW> should give me a reduction in the price, or *specifically*
PW> warn me that I am paying for something I am not going to get.
OK, this makes it easier (me remembering the probable beginning of this
thread helped also). You're saying you can give them your address as in
kernel X, libc Y, etc. Your gripe then is that they don't explicitly say
you are paying for something that they _did_ tell you you would not get.
Correct?
PW> Here's what my bill looks like: 1 sack potatoes ------------
PW> $8.50 delivery -------------------- $1.50
PW> Get it? Get it? Get it? Huh?
Got it, got it, got it. Thanks. I disagree. I think your bill/offer
looks like: "1 sack, $10. Delivered to addresses in ZIP XYZ at no
additional charge." You want them to say, "1 sack, $8.50. Delivery
to ZIP XYZ $1.50. We are not obligated to deliver to other ZIPs."
How do you like this version?
>> ... The problem you are alluding to exists for
>> any piece of software. It does not magically disappear with
>> open source (re: Peter Van Eynde's remarks about the experience
>> he's had keeping CMUCL alive on Linux), nor is it necessarily
>> cost-free to solve even with GPL.
PW> It doesn't apply to CMUCL because I don't pay for support.
No you don't. The problem does not disappear though and still takes
resources to solve.
>> It is entirely possible I am misunderstanding you. But if not,
>> I'd like to know why you think it is OK or necessary to say
>> stuff like "sharkish behaviour" about companies which, by all
>> accounts here, have been honest businesses.
PW> 'Honest business' is a legal thing, right? You are 'honest'
PW> if you don't break the law. So yes, I think they are probably
PW> 'honest'.
I'll leave finer legal points to those better versed. I disagree with
the "you are honest if you don't break the law" bit (as I suspect you do).
I used "honest business" in the sense one would about the mom&pop grocery
store. They act in good faith and they don't try to cheat you in every
legal way they can. They are not your family, they clearly want to make
money, but they don't act as though you are some "mark" to be exploited.
Vague and hand-wavy, I know. No more so than "sharkish" I hope.
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "PW" == Peter Wood <··········@worldonline.dk> writes:
> [...]
> >> ... The problem you are alluding to exists for
> >> any piece of software. It does not magically disappear with
> >> open source (re: Peter Van Eynde's remarks about the experience
> >> he's had keeping CMUCL alive on Linux), nor is it necessarily
> >> cost-free to solve even with GPL.
>
> PW> It doesn't apply to CMUCL because I don't pay for support.
>
> No you don't. The problem does not disappear though and still takes
> resources to solve.
>
Yes, I agree, but it can take considerably less resources to fix free
software than proprietary software, especially if the software is
`unsupported'. The cost of time absolutely does not disappear with
free software but it can be reduced with free software, especially
with a tightly-knit community of users to help you and source code
that you are able to fix yourself. I am definitely *not* saying that
solutions are easy with free software (that's like saying that you
aren't allowed to sell free software -- it might seem correct to some
but it is very much incorrect) -- just that oftentimes the cost is
halved or quartered, *especially* for very serious problems that
require source-code level fixes.
> >> It is entirely possible I am misunderstanding you. But if not,
> >> I'd like to know why you think it is OK or necessary to say
> >> stuff like "sharkish behaviour" about companies which, by all
> >> accounts here, have been honest businesses.
>
> PW> 'Honest business' is a legal thing, right? You are 'honest'
> PW> if you don't break the law. So yes, I think they are probably
> PW> 'honest'.
>
> I'll leave finer legal points to those better versed. I disagree with
> the "you are honest if you don't break the law" bit (as I suspect you do).
> I used "honest business" in the sense one would about the mom&pop grocery
> store. They act in good faith and they don't try to cheat you in every
> legal way they can. They are not your family, they clearly want to make
> money, but they don't act as though you are some "mark" to be exploited.
> Vague and hand-wavy, I know. No more so than "sharkish" I hope.
>
Not sharkish, certainly, but non-optimal; they could certainly support
more Linuces (plus *BSD of course) and be more clear in their
contracts that they only support obsolete junk (that last phrase
sounds more sarcastic than it should be, but in many cases (not
necessarily this one) the companies do support only obsolete junk).
> cheers,
>
> BM
>
>
--
BPT <···@hobbiton.org>
backronym for Linux: Linux Is Not Unix
In article <··············@localhost.localdomain>, Peter Wood wrote:
> Bulent Murtezaoglu <··@acm.org> writes:
>
>> >>>>> "PW" == Peter Wood <··········@worldonline.dk> writes:
>> [...]
>>
>> PW> They
>> PW> charge you the full price for their product, regardless of
>> PW> which distro you are using. But unless you are using a system
>> PW> from RedHat of a specific version number, you are *not*
>> PW> *legally* entitled to the support which you have paid for.
>
>> I pay, say, Xanalys $800, monkey with my system/kernel, break LispWorks,
>> send them e-mail and they magically get the manpower to accomodate me.
>> If they don't, they are sharks? Just trying to understand here.
>
> Don't try too hard. If I buy a sack of potatoes + delivery for 10
> bucks, and I get the potatoes delivered, well and good. If the seller
> decides I live too far away for delivery, he should give me a
> reduction in the price, or *specifically* warn me that I am paying for
> something I am not going to get.
>
> Here's what my bill looks like:
> 1 sack potatoes ------------ $8.50
> delivery -------------------- $1.50
>
> Get it? Get it? Get it? Huh?
I can see what you are saying but I fail to see how it relates to the
statement you are commenting on.
Here is something more in line with the statement you are commenting
on, I think anyway:
I buy a jeep
I go on rutted dirt roads in my new and under warenty jeep
I find a big rock rip out the oil pan and sieze the engine
I go to dealer and demand he fix my jeep because it is under guarentee
The dealer replys that this is not covered so if you want it fixed we
take visa, mastercard and cash.
This seems reasonable to me
>
>> PW> I don't care that their systems 'probably' work with other
>> PW> Linux distros. I don't care that they will 'try' to help me if
>> PW> I experience problems. I want people (Linux users) to be
>> PW> aware of what they are getting when they buy proprietary
>> PW> software. [...]
>>
>> I think they do and I have not seen evidence of vendors trying to
>> confuse people. The problem you are alluding to exists for any piece
>> of software. It does not magically disappear with open source (re:
>> Peter Van Eynde's remarks about the experience he's had keeping CMUCL
>> alive on Linux), nor is it necessarily cost-free to solve even with GPL.
>>
>
> It doesn't apply to CMUCL because I don't pay for support.
>
Let me ask some question:
Do you need support to do your work, if you are down for 2 months
waiting for the next release of cmu is it no big deal?
Has Xanalys refused to support you, the told you to go away?
Or did they say yes we will be glad to help you, but the first step is
to get your system into a state where we can help you as defined in
our support agreement, we do not know who other things interact so we
can not help you. This is no different from Sun or HP or Oracle or
RedHat ...
Did you offer to do a time and materiels deal to have an engeeneer do
custome research to fix your problem?
>> It is entirely possible I am misunderstanding you. But if not, I'd like
>> to know why you think it is OK or necessary to say stuff like "sharkish
>> behaviour" about companies which, by all accounts here, have been honest
>> businesses.
>>
>
> 'Honest business' is a legal thing, right? You are 'honest' if you
> don't break the law. So yes, I think they are probably 'honest'.
I think that 'Honest business' ment did they try to honor there
support contract? If they asked you to get your system into a
supported configuration and you refused then they have made an honest
attempt to fix your problem. They cannot go to step 2 befor step 1 is
done.
>
> Regards,
> Peter
good day to all
marc
····@oscar.eng.cv.net (Marc Spitzer) writes:
> > Bulent Murtezaoglu <··@acm.org> writes:
> >
> >> >>>>> "PW" == Peter Wood <··········@worldonline.dk> writes:
> > Here's what my bill looks like:
> > 1 sack potatoes ------------ $8.50
> > delivery -------------------- $1.50
> >
> > Get it? Get it? Get it? Huh?
>
> I can see what you are saying but I fail to see how it relates to the
> statement you are commenting on.
>
Because there is a relationship between what I am getting, what is
being sold, and what it is costing the vendor. Support is a big
expense for a vendor, and if I don't get/qualify for support I am
saving the vendor money, because their employees are going to spend
less (read zero) time on me.
>
> Here is something more in line with the statement you are commenting
> on, I think anyway:
>
> I buy a jeep
> I go on rutted dirt roads in my new and under warenty jeep
> I find a big rock rip out the oil pan and sieze the engine
> I go to dealer and demand he fix my jeep because it is under guarentee
> The dealer replys that this is not covered so if you want it fixed we
> take visa, mastercard and cash.
>
> This seems reasonable to me
>
The way I see it is this. I build my jeep myself, from parts.
Everything works fine. In fact its better quality than the jeeps for
sale down the road. But the guy who sold me the tyres won't fix them
when they prove defective, because the jeep didn't get made by the
company down the road. OK, I say, give me a discount then. No
discount, no sale.
...
> > It doesn't apply to CMUCL because I don't pay for support.
> >
>
> Let me ask some question:
<irrelevant questions cut>
I'll answer all your questions like this. My original post was
designed to show that the commercial Lisp Vendors don't support Linux.
The followups to that post discussed this in some depth. When John
Foderaro said something like 'we try to support everyone, but if your
system ain't xyz, and there's a serious problem, we can't help you'
(from memory) I shut up, satisfied, because that's the plain truth,
which I think needed saying.
I don't know why Martin posted about CMUCL. It was OT. It doesn't
relate to what I am talking about which is: I don't want to pay for
what I don't get. Especially if what I don't get is a potentially big
expense for the vendor to provide.
You can use ACL or LW on Linux, but unless you use RedHat xyz the risk
is all yours. Risk=$.
Regards,
Peter
In article <··············@localhost.localdomain>, Peter Wood wrote:
> ····@oscar.eng.cv.net (Marc Spitzer) writes:
>
>> > Bulent Murtezaoglu <··@acm.org> writes:
>> >
>> >> >>>>> "PW" == Peter Wood <··········@worldonline.dk> writes:
>
>> > Here's what my bill looks like:
>> > 1 sack potatoes ------------ $8.50
>> > delivery -------------------- $1.50
>> >
>> > Get it? Get it? Get it? Huh?
>>
>> I can see what you are saying but I fail to see how it relates to the
>> statement you are commenting on.
>>
>
> Because there is a relationship between what I am getting, what is
> being sold, and what it is costing the vendor. Support is a big
> expense for a vendor, and if I don't get/qualify for support I am
> saving the vendor money, because their employees are going to spend
> less (read zero) time on me.
That is like a vegatarian eating at burgerking orfdering a whopper
without meat then asking that the price be lowered. BK will say have
it your way but a wopper costs x with or with out meat.
>
>>
>> Here is something more in line with the statement you are commenting
>> on, I think anyway:
>>
>> I buy a jeep
>> I go on rutted dirt roads in my new and under warenty jeep
>> I find a big rock rip out the oil pan and sieze the engine
>> I go to dealer and demand he fix my jeep because it is under guarentee
>> The dealer replys that this is not covered so if you want it fixed we
>> take visa, mastercard and cash.
>>
>> This seems reasonable to me
>>
>
> The way I see it is this. I build my jeep myself, from parts.
> Everything works fine. In fact its better quality than the jeeps for
> sale down the road. But the guy who sold me the tyres won't fix them
> when they prove defective, because the jeep didn't get made by the
> company down the road. OK, I say, give me a discount then. No
> discount, no sale.
>
the linux version of lisp works is $800 the Solaris version is around
$3000+ if I remember correctly and the linux version comes with free
runtime distribution again of I remember correctly. It sounds
like you are getting a very good discount on the product
> ...
>
>> > It doesn't apply to CMUCL because I don't pay for support.
>> >
>>
>> Let me ask some question:
>
> <irrelevant questions cut>
>
> I'll answer all your questions like this. My original post was
> designed to show that the commercial Lisp Vendors don't support Linux.
> The followups to that post discussed this in some depth. When John
> Foderaro said something like 'we try to support everyone, but if your
> system ain't xyz, and there's a serious problem, we can't help you'
> (from memory) I shut up, satisfied, because that's the plain truth,
> which I think needed saying.
So if you need support make your system conform to what they support
so they can help you. Xanalys states that clearly, KMP posted it.
But with that said they will support you if you are in a supported
configuration. If I was to put this in oracle/solaris terms you are
saying orcle does not support solaris because oracle 8.1.7 in not
supported on solaris8 so they tell me to put it on a solaris 7 box and
then we can help you. And then I say oracle does not support
solaris. Linux's product space is much more complex then solaris's
and each version requires qa, training of support staff and other
stuff that I do not know about because I have never worked in the ship
and support a product commericaly bussness.
>
> I don't know why Martin posted about CMUCL. It was OT. It doesn't
> relate to what I am talking about which is: I don't want to pay for
> what I don't get. Especially if what I don't get is a potentially big
> expense for the vendor to provide.
>
> You can use ACL or LW on Linux, but unless you use RedHat xyz the risk
> is all yours. Risk=$.
agreed so use a supported configuration, use redhat xyz and you are
supported.
>
> Regards,
> Peter
good day
marc
····@oscar.eng.cv.net (Marc Spitzer) writes:
> agreed so use a supported configuration, use redhat xyz and you are
> supported.
The problem then is if "BugHat Version xyz" has some crucial bugs that
make it otherwise unacceptable for use.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://vip.hex.net/~cbbrowne/sgml.html
"Real concurrency---in which one program actually continues to
function while you call up and use another---is more amazing but of
small use to the average person. How many programs do you have that
take more than a few seconds to perform any task?"
-- New York Times, 4/25/89
In article <····················@news20.bellglobal.com>, ········@hex.net wrote:
> ····@oscar.eng.cv.net (Marc Spitzer) writes:
>> agreed so use a supported configuration, use redhat xyz and you are
>> supported.
>
> The problem then is if "BugHat Version xyz" has some crucial bugs that
> make it otherwise unacceptable for use.
That is always a problem. But from what I have heard redhat 6.2 can
be made into a stable and secure os, I use freebsd myself. And with
an evil grin Linux is open source so you can just fix the problem and
contribute the patchs.
marc
> --
> (concatenate 'string "cbbrowne" ·@ntlug.org")
> http://vip.hex.net/~cbbrowne/sgml.html
> "Real concurrency---in which one program actually continues to
> function while you call up and use another---is more amazing but of
> small use to the average person. How many programs do you have that
> take more than a few seconds to perform any task?"
> -- New York Times, 4/25/89
····@oscar.eng.cv.net (Marc Spitzer) writes:
> In article <····················@news20.bellglobal.com>, ········@hex.net wrote:
> > ····@oscar.eng.cv.net (Marc Spitzer) writes:
> >> agreed so use a supported configuration, use redhat xyz and you are
> >> supported.
> >
> > The problem then is if "BugHat Version xyz" has some crucial bugs that
> > make it otherwise unacceptable for use.
>
> And with an evil grin Linux is open source so you can just fix the
> problem and contribute the patchs.
Of course, doing this causes you to loose support.
--
(__) Doug Alcorn (···········@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.
····@oscar.eng.cv.net (Marc Spitzer) writes:
>In article <····················@news20.bellglobal.com>, ········@hex.net wrote:
>> ····@oscar.eng.cv.net (Marc Spitzer) writes:
>>> agreed so use a supported configuration, use redhat xyz and you are
>>> supported.
>>
>> The problem then is if "BugHat Version xyz" has some crucial bugs that
>> make it otherwise unacceptable for use.
>That is always a problem. But from what I have heard redhat 6.2 can
>be made into a stable and secure os, I use freebsd myself. And with
>an evil grin Linux is open source so you can just fix the problem and
>contribute the patchs.
And how many vendors apply user-supplied patches for their integration
of software xyz? On a regular and hence dependable base?
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
In article <·············@counter.bik-gmbh.de>, Martin Cracauer wrote:
> ····@oscar.eng.cv.net (Marc Spitzer) writes:
>
>>In article <····················@news20.bellglobal.com>, ········@hex.net wrote:
>>> ····@oscar.eng.cv.net (Marc Spitzer) writes:
>>>> agreed so use a supported configuration, use redhat xyz and you are
>>>> supported.
>>>
>>> The problem then is if "BugHat Version xyz" has some crucial bugs that
>>> make it otherwise unacceptable for use.
>
>>That is always a problem. But from what I have heard redhat 6.2 can
>>be made into a stable and secure os, I use freebsd myself. And with
>>an evil grin Linux is open source so you can just fix the problem and
>>contribute the patchs.
>
> And how many vendors apply user-supplied patches for their integration
> of software xyz? On a regular and hence dependable base?
Well that is one of the reasons I like freebsd, if I make a good patch
and submit it it will make it into the distribution. freebsd 5.0 is
not far away and I think they are still doing maintenance work on the
3.x series.
marc
>
> Martin
> --
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
> FreeBSD - where you want to go. Today. http://www.freebsd.org/
····@oscar.eng.cv.net (Marc Spitzer) writes:
> In article <··············@localhost.localdomain>, Peter Wood wrote:
> > ····@oscar.eng.cv.net (Marc Spitzer) writes:
> >
> >> > Bulent Murtezaoglu <··@acm.org> writes:
> >> >
> >> >> >>>>> "PW" == Peter Wood <··········@worldonline.dk> writes:
> >
> >> > Here's what my bill looks like:
> >> > 1 sack potatoes ------------ $8.50
> >> > delivery -------------------- $1.50
> >> >
> >> > Get it? Get it? Get it? Huh?
> >>
No, I don't, sorry. Maybe potato delivery isn't such a good metaphor
for proprietary software ;). But seriously, I don't quite understand
how your example relates to proprietary software being
distro-specific.
> >> I can see what you are saying but I fail to see how it relates to the
> >> statement you are commenting on.
> >>
> >
> > Because there is a relationship between what I am getting, what is
> > being sold, and what it is costing the vendor. Support is a big
> > expense for a vendor, and if I don't get/qualify for support I am
> > saving the vendor money, because their employees are going to spend
> > less (read zero) time on me.
>
> That is like a vegatarian eating at burgerking orfdering a whopper
> without meat then asking that the price be lowered. BK will say have
> it your way but a wopper costs x with or with out meat.
>
It's more like buying a whopper, adding some of your own ketchup
(updating some noncritical part of your system), then buying some
sesame seeds for the top of the bun (proprietary Lisp), then the
sesame seeds explode (unrelated to the ketchup) and you do not get any
support because you added your own unsupported variety of ketchup.
> >
> >>
> >> Here is something more in line with the statement you are commenting
> >> on, I think anyway:
> >>
> >> I buy a jeep
> >> I go on rutted dirt roads in my new and under warenty jeep
> >> I find a big rock rip out the oil pan and sieze the engine
> >> I go to dealer and demand he fix my jeep because it is under guarentee
> >> The dealer replys that this is not covered so if you want it fixed we
> >> take visa, mastercard and cash.
> >>
> >> This seems reasonable to me
> >>
The vehicle metaphor I would choose is:
I obtain a `Red Hatch' tank. I add a cool translucent hatch, and get a
couple of extra status monitors for the cockpit (or whatever the
driving area of a tank is called). Then I add a special new component
to the engine (proprietary Lisp), the component explodes, and because
I added a different hatch and a status monitor, I get no support.
(borrowing from _In the Beginning Was the Command Line_ by Neal
Stephenson) I have to fix my tank (with help from
comp.unix.questions), and find that the proprietary component
temporarily turned it into a station wagon. Ergo, I toss out the tank
which has been ruined and go pick up a new invulnerable tank from the
Debian GNU/TankNix vehicle center, which is across the street
(actually it's just one of the large geodesic domes inside the
Open-Source Unix car dealership, I could have chosen Slackware or
Mandrake or FreeBSD or another Open Source Unix).
Finally, I find that the proprietary vendor will not support my new
tank, because they dislike the air-conditioning system Debian has in
its tanks, and they don't like the fact that Debian does not ship with
their proprietary junk. But luckily, my system comes with CLISP, GCL,
CMUCL, and more, so I do not worry about re-purchasing proprietary
software. The company goes out of business a short while later. I
learn more about tank maintenance. Nautilus begins to run at a
reasonable speed. Everyone lives happily ever after.
(Of course, if you have ever heard me complain about Red Hat, you may
find this passage similar to my own experiences with Unix, but my
problems with Red Hat were not because of the included proprietary
software, but with a hard disk failure. And I have no reason to
dislike Xanalys any more than, say, Apple, in fact I have heard they
have a rather good product. I am just talking about proprietary
software in general, and from the viewpoint of a free software
developer.)
You are free to pick your favorite vehicle metaphor, because any
scenario you can imagine will be true for some Unix user, however I
think my metaphor is more accurate for the average Unix user, who has
no reason to drive on rutted dirt roads (I run tons of huge daemons
and desktop environments, and am constantly hacking on my favorite
software, but I still haven't had a single problem with Debian
GNU/Linux; and I don't consider even most enterprise work to be
equivalent to a dirt road for advanced OSes like GNU/Linux and
FreeBSD. Besides, the average Unix user probably doesn't do much more
than normal usage, possibly some development, and a few daemons --
which is only a challenge for older MacOS versions and Microsloth
Windows.).
> >
> > The way I see it is this. I build my jeep myself, from parts.
> > Everything works fine. In fact its better quality than the jeeps for
> > sale down the road. But the guy who sold me the tyres won't fix them
> > when they prove defective, because the jeep didn't get made by the
> > company down the road. OK, I say, give me a discount then. No
> > discount, no sale.
> >
>
> the linux version of lisp works is $800 the Solaris version is around
> $3000+ if I remember correctly and the linux version comes with free
> runtime distribution again of I remember correctly. It sounds
> like you are getting a very good discount on the product
>
The main reason until recently that GNU/Linux users got a ``discount''
is that until very recently most big-iron vendors considered GNU/Linux
a toy for hobbyists (quote (from memory, maybe I should say
paraphrase) from _Mastering Tools, Taming Daemons: UNIX For the
Wizard's Apprentice_: ``Linux is about as close to a real UNIX as a
hobbyist can get.''). I think this has stopped now that IBM is
supporting GNU/Linux (or maybe McDonald's use of Caldera OpenLinux has
been more of an influence :)).
But that is irrelavent because I think that Peter Wood was referring
to distro-specificness again. I don't want to speak for him, but what
he most likely meant was that he got his jeep (hey, what do you mean a
jeep, haven't you read _In the Beginning was the Command Line_?
GNU/Linux is a *tank*! :)) from (Debian|Mandrake|Progeny|Caldera|
<your-favorite-non-RedHat-distro>), instead of Red Hat. And thus, if
he did buy the software he would not get support.
> > ...
> >
> >> > It doesn't apply to CMUCL because I don't pay for support.
> >> >
> >>
Well, you probably *could* pay for support, from LinuxCare or a
consultant, but of course you can always ask on c.l.l... which is a
form of support even for proprietary systems... but that does not
change the fact that most proprietary vendors do not provide any
support for non-Red Hat (or whatever) users, when they should have
support for other distros.
> >> Let me ask some question:
> >
> > <irrelevant questions cut>
> >
> > I'll answer all your questions like this. My original post was
> > designed to show that the commercial Lisp Vendors don't support Linux.
> > The followups to that post discussed this in some depth. When John
> > Foderaro said something like 'we try to support everyone, but if your
> > system ain't xyz, and there's a serious problem, we can't help you'
> > (from memory) I shut up, satisfied, because that's the plain truth,
> > which I think needed saying.
>
> So if you need support make your system conform to what they support
> so they can help you. Xanalys states that clearly, KMP posted it.
> But with that said they will support you if you are in a supported
> configuration. If I was to put this in oracle/solaris terms you are
> saying orcle does not support solaris because oracle 8.1.7 in not
> supported on solaris8 so they tell me to put it on a solaris 7 box and
> then we can help you. And then I say oracle does not support
> solaris. Linux's product space is much more complex then solaris's
> and each version requires qa, training of support staff and other
> stuff that I do not know about because I have never worked in the ship
> and support a product commericaly bussness.
>
I think that basic Linux training consists of just a few `courses'
(assuming existing Unix knowledge): Differences between GNU Software
and traditional Unix software; Installation and Package Management
(Debian package system, RPMs, and from-source); Participating in Open
Source Projects (Fixing Bugs, Adding Features, and Preparing Patches,
also CVS Basics); Making Programs LSB- and POSIX-compliant.
With troubleshooting, GNU/Linux (similarly for *BSD and other
open-source unixes such as the Hurd) is actually much easier than
Solaris (IMHO), because you can dig into the source, recompile with
debugging support, fix bugs, etc etc.
I am a free software developer (which I should really say is a
secondary job, since I am a student too, a---- and e- for those of you
with Geek Code Blocks), and my packages AFAIK work on other
LSB-compliant Unices besides Debian. (Although I haven't tested them
in a while.) And I can certainly help someone who uses a distro other
than my own. So why can a three-person, not-even-yet-incorporated
company outsupport a huge Lisp provider (er, support more distros that
is, I make no claims about our tech support, considering we don't have
any tech support yet :))? (Yes, their products are more complex, but
they hopefully limit themselves to POSIXy Unix features. The concept
remains the same.)
> >
> > I don't know why Martin posted about CMUCL. It was OT. It doesn't
> > relate to what I am talking about which is: I don't want to pay for
> > what I don't get. Especially if what I don't get is a potentially big
> > expense for the vendor to provide.
> >
> > You can use ACL or LW on Linux, but unless you use RedHat xyz the risk
> > is all yours. Risk=$.
>
> agreed so use a supported configuration, use redhat xyz and you are
> supported.
>
The point is not that you should use a supported configuration (I
agree that you should if you end up buying your software), but that
vendors should support several Linuces and Unices. My suggestion is
that vendors of software for Linux should support LSB-compliant
systems.
This is a little OT, but... wasn't Lisp *invented* in a hackerish
atmosphere (the AI Lab and TMRC is where hackerism *started* almost)
where free software did not even have a name? Proprietary Lisp is
almost an oxymoron. And I see little reason to use it, since free
software Lisps like CLISP and GCL are quite good (when combined with a
good editor like GNU Emacs (in this case a religion and computing
environment too :))).
Anyway, back on topic: Vendors ought to support LSB and POSIX
platforms. I see no reasonable alternatives nor any other good Unix
standards. (And if you dig out your circa June 1999 Linux Journals,
you will notice that the whole point of the LSB is compatibility.)
> >
> > Regards,
> > Peter
>
>
> good day
>
> marc
good evening,
Brian
(sleep-for "8 hours")
good morning,
Brian
;)
--
BPT <···@hobbiton.org>
backronym for Linux: Linux Is Not Unix
[ I think this lisp-vendor-trashing thread has gotten a little
out of hand, and it's time for an actual "proprietary" lisp vendor
to inject a little reality into it. Of course, the best way to get
the _facts_ is to ask the _vendor_. But it seems that some people
just don't care about facts...]
BPT <···@hobbiton.org> writes:
[many metaphors elided ... ]
> Anyway, back on topic: Vendors ought to support LSB and POSIX
> platforms. I see no reasonable alternatives nor any other good Unix
> standards. (And if you dig out your circa June 1999 Linux Journals,
> you will notice that the whole point of the LSB is compatibility.)
And what makes you think that vendors are not doing just that?
I have been fairly vocal in my praise for the new trend of Linux toward
standardization, even though that means incompatibility with older
versions of Linux. It shouldn't have been a trend, though; it should
have _started_ this way. We've had Linux ports since 1995, and it has
been a great challenge to stay consistent with all of the experiments
which Linux kernel hackers have foisted upon us. But what hurts most
is not that we are not 100% technically successful in providing a
compatible lisp product in the face of such incompatibility (and this is
my own fault), but that for all of our efforts to provide such
compatibility and support, and, in fact, for our relatively _high_ success
rate, we still get trashed by people who don't even use our product and
who thus don't have any facts.
> Well, you probably *could* pay for support, from LinuxCare or a
> consultant, but of course you can always ask on c.l.l... which is a
> form of support even for proprietary systems... but that does not
> change the fact that most proprietary vendors do not provide any
> support for non-Red Hat (or whatever) users, when they should have
> support for other distros.
This is where you brought me into the conversation. I had kept quiet
because the majority of this thread had been about Xanalys, and I can't
speak for them. However, when you generalize that _most_ vendors don't
support non-Redhat users, I have to correct your mistake, at least from
Franz's point of view.
We support all linux kernels 2.2 and 2.4, and probably 2.0.
On Allegro CL 6.0, we support glibc 2.0/2.1
On Allegro CL 6.1, we will support glibc 2.1/2.2
We have many supported customers on non-Redhat distributions. In the
future, please refrain from making such unsubstantiated and blatantly
false statements.
> (Of course, if you have ever heard me complain about Red Hat, you may
> find this passage similar to my own experiences with Unix, but my
> problems with Red Hat were not because of the included proprietary
> software, but with a hard disk failure. And I have no reason to
> dislike Xanalys any more than, say, Apple, in fact I have heard they
> have a rather good product. I am just talking about proprietary
> software in general, and from the viewpoint of a free software
> developer.)
Ahh - so this is the crux of the matter. You've never really used their
product, but you dislike Xanalys simply because they are proprietary
software and you are a free-software developer.
This is precisely the kind of unsubstantiated trash-talking that forces
Kent Pitman to offer some of the "balance" which then makes him appear
as if he is anti-free-software. If you people would base your opinions
on facts, or else hold them to yourselves, then such reaction would not
be necesaary and such misinformation would not be so easily propagated.
It is possible for you to be free-software developer and at the same time
to not be anti-proprietary. Take us, for example. We put quite a bit of
software into opensource. One of the more popular packages, Allegroserve,
has been ported to several different CL implementations. Take a look at
http://opensource.franz.com, or go to http://sourceforge.net and search
for "lisp", to find all kinds of free software available, some from
these very proporietary vendors which you are trashing so vehemently.
--
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 ·····@Franz.COM (internet)
Peter Wood <··········@worldonline.dk> writes:
> You can use ACL or LW on Linux, but unless you use RedHat xyz the risk
> is all yours. Risk=$.
The reason that the most common Linux distro is ``crappy and
outdated,'' presumably has something to do with initial quality. If
you don't trust your OS vendor to provide a stable platform for Lisp
development, look into another OS. (I guess you could also pay one of
the vendors to support your flavor of the week, but it might get
expensive.)
^L
Louis Theran <······@genet.cs.umass.edu> writes:
> Peter Wood <··········@worldonline.dk> writes:
>
> > You can use ACL or LW on Linux, but unless you use RedHat xyz the risk
> > is all yours. Risk=$.
>
> The reason that the most common Linux distro is ``crappy and
> outdated,'' presumably has something to do with initial quality. If
> you don't trust your OS vendor to provide a stable platform for Lisp
> development, look into another OS.
Any suggestions? (Just kidding :) ).
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Louis Theran <······@genet.cs.umass.edu> writes:
>
> > Peter Wood <··········@worldonline.dk> writes:
> >
> > > You can use ACL or LW on Linux, but unless you use RedHat xyz the risk
> > > is all yours. Risk=$.
> >
> > The reason that the most common Linux distro is ``crappy and
> > outdated,'' presumably has something to do with initial quality. If
> > you don't trust your OS vendor to provide a stable platform for Lisp
> > development, look into another OS.
>
> Any suggestions? (Just kidding :) ).
I suspect that you'll find my answer surprising: at the lab where I
work we just use one of the supported Linux distros for allegro. My
comments were directed toward those who don't consider this a viable
option.
^L
Peter Wood <··········@worldonline.dk> writes:
> You can use ACL or LW on Linux, but unless you use RedHat xyz the risk
> is all yours. Risk=$.
You have answered your own question right there.
I bet these companies will write a custom contract with you for your
configuration, but since you are asking to use a system other than the
one they use, the cost will probably be commensurate with the risk.
The risk is there regardless. If you think, and I think you're right,
that it is the same as $, then they'd be fools to raise the price for
all implementations to accomodate the risk in the implementations they
haven't tried. So you need to make up the risk.
If you think the risk is small, the case to make is tht they shouldn't
charge you "much" more. Maybe they'll agree. But you'd be surprised
how fast someone can run up a few thousand dollars of expenses.
Why not maintain a redhat system in which to isolate and report bugs?
What? It costs money for the hardware, the installation, the time to
move stuff back and forth across the platforms? There's your answer.
If you think there are a lot of people with the same need as you and
you show up as a block at the sales office of some vendor, each ready
to pay for product and support, I'm sure you'll get their attention
nice and fast, and perhaps can negotiate a better rate than working
in isolation.
Vendors, as a rule, do not leave money sitting on the table without good
reason. If they thought they could handle more platforms economically,
you can usually be sure that they'd try, and that if they don't tehy
have a reason, probably economic.
Kent M Pitman <······@world.std.com> writes:
> Peter Wood <··········@worldonline.dk> writes:
>
> > You can use ACL or LW on Linux, but unless you use RedHat xyz the risk
> > is all yours. Risk=$.
>
> You have answered your own question right there.
>
> I bet these companies will write a custom contract with you for your
> configuration, but since you are asking to use a system other than the
> one they use, the cost will probably be commensurate with the risk.
>
> The risk is there regardless. If you think, and I think you're right,
> that it is the same as $, then they'd be fools to raise the price for
> all implementations to accomodate the risk in the implementations they
> haven't tried. So you need to make up the risk.
>
> If you think the risk is small, the case to make is tht they shouldn't
> charge you "much" more. Maybe they'll agree. But you'd be surprised
> how fast someone can run up a few thousand dollars of expenses.
>
Hi,
The risk I am talking about is 'the risk that this customer will cost
us a lot of support hours'. If I am using an unsupported system, I am
(per contract) not entitled to the support. So I won't cost them $.
So, the risk is MINE. Sorry, I just had to shout. I don't feel like
I'm getting through. I don't want a custom contract. I don't want
to have to pay _more_ to Xanalys/Franz just because my custom Linux
distro is better <<<< BETTER than RedHats.
As a (potential) customer, I will willingly do one of two things. I
will:
(1) *exactly* and *precisely* duplicate any <<<< ANY lisp-vendor
specified component or combination of components in a Linux
system in exchange for the recognition that my system thereafter
is legally (contractually) supported
or, alternatively
(2) I will forego all right to official support in exchange for a
substantial reduction in the price of a licence for the Lisp
system. And (very important) a similar reduction for _my_
customers using my distro.
Otherwise -- no sale.
I regard this thread as talked out.
Regards,
Peter
Peter Wood <··········@worldonline.dk> writes:
> My original post, to which Martin replied, concerned _commercial_ Lisp
> vendors. The whole point of the posting, was to show that Lisp
> vendors *don't* *support* *linux*. They charge you the full price for
> their product, regardless of which distro you are using.
I'm sure they'd be happy to say "we will only sell you Linux for the
platforms we support" except that then someone would say "but mine is so
similar, I can't believe you refuse to sell it to me. So they allow you
voluntarily elect to take on the burden of saying "this platform is close
enough".
For example, if you go to the Xanalys Linux page,
http://www.xanalys.com/software_tools/products/lwl.html
and read the very first sentence, it says:
This is a full native implementation of Common Lisp for
Red Hat Linux 5 & 6 running on Intel hardware.
How much more clear could it be? They *can't* say they support all
implementations of Linux because IT'S FREE SOFTWARE. It can go anywhere
and be anything. No one knows how many implementations there are, what
they might do, what platforms they do or don't adhere to, or anything else
because any part of it can be changed at any time by anyone for any reason.
That's not something definite enough to write a contract about.
> But unless you are using a system from RedHat of a specific version
> number, you are *not* *legally* entitled to the support which you
> have paid for.
No. Contract law works this way: You read the contract. You sign if
you agree, you don't sign if you don't agree. If you do agree, then the
terms of the contract include consideration ($) which you understand at
the time of signing to be adequate compensation for the value to be
received (which certainly include notice that you will not be supported).
Hence, you are NOT legally entitled to support because the contract you
had available in advance does not say you are, and you have NOT paid for
otherwise because the thing you paid for and are bound by says what it
says, not otherwise.
> Its just typical, sharkish practice from proprietary software vendors.
Sharks are often misunderstood. They have a straightforward contract and
tend to abide by it. In spite of rumor, they are not weasels. Proprietary
software vendors have straightforward contracts, too. And they tend to
abide by them. So I take this statement by you to be relatively accurate,
but perhaps not for the reasons you may have intended.
> I don't care that their systems 'probably' work with other Linux
> distros.
Then don't buy from vendors who can only tell you this.
> I don't care that they will 'try' to help me if I experience problems.
Then don't buy from vendors who can only tell you this.
> I want people (Linux users) to be aware of what they are
> getting when they buy proprietary software.
This sounds fair, although they could get the same information by reading
the contract. Most vendors, when it's been pointed out that they are in
violation of contract, will attempt to make good on the contract. If they
don't, it's not usually because they are bad guys, but because they have
probable reason to believe that it's you and not they who are asking for
something not in the contract.
Kent M Pitman <······@world.std.com> wrote:
> For example, if you go to the Xanalys Linux page,
> http://www.xanalys.com/software_tools/products/lwl.html
> and read the very first sentence, it says:
> This is a full native implementation of Common Lisp for
> Red Hat Linux 5 & 6 running on Intel hardware.
>
> How much more clear could it be? They *can't* say they support all
> implementations of Linux because IT'S FREE SOFTWARE. It can go anywhere
> and be anything. No one knows how many implementations there are, what
> they might do, what platforms they do or don't adhere to, or anything else
> because any part of it can be changed at any time by anyone for any reason.
> That's not something definite enough to write a contract about.
Probably, it will be better if they also write about real requirements for
their product (as is version of kernel, glibc and so on). I'd wish also
that they distributed Linux version of the product with sources for system
dependent parts. Like in the case with Nvidia's drivers, for example.
They can sale such product with a minimal support or without one. Also
they can support it for additional money. I believe, it can help them to
increase the number of users from different flavours of Linux.
--
Best regards,
Aleksandr Skobelev
<····@mail.ru> wrote:
> Kent M Pitman <······@world.std.com> wrote:
>
> > They *can't* say they support all implementations of Linux because IT'S
> > FREE SOFTWARE. It can go anywhere and be anything. No one knows how
> > many implementations there are, what they might do, what platforms they
> > do or don't adhere to, or anything else because any part of it can be
> > changed at any time by anyone for any reason. That's not something
> > definite enough to write a contract about.
>
> Probably, it will be better if they also write about real requirements for
> their product (as is version of kernel, glibc and so on). I'd wish also
> that they distributed Linux version of the product with sources for system
> dependent parts.
The problem is that this means all sources because, ultimately,
everything /is/ system dependent. For instance, 80x86 object files are
no use to me running LinuxPPC. Just what *is* the 'Linux' of the
subject line?
Supply object files for common microprocessor architectures you say?
Well, I designed my own processor, coded it in VHDL, burned it onto an
FPGA, ported a version of Linux to it and now wish to run a (supported!)
Common Lisp implementation on it.
Reductio ad absurdum? Why yes (in the literal sense, I've /proved/
nothing). But I suspect Kent *really* meant what he said when he wrote
"It[Linux; Free software in general] can go *anywhere* and be
*anything*" (pointless emphasis added).
Where does one draw the line?
--
Duncan Harvey
"Smiling and waving. Before letting himself fall."
-- Anja Garbarek, The Diver
Duncan Harvey <····@hubris2.demon.co.uk> wrote:
> <····@mail.ru> wrote:
>
>> Kent M Pitman <······@world.std.com> wrote:
>>
>> > They *can't* say they support all implementations of Linux because IT'S
>> > FREE SOFTWARE. It can go anywhere and be anything. No one knows how
>> > many implementations there are, what they might do, what platforms they
>> > do or don't adhere to, or anything else because any part of it can be
>> > changed at any time by anyone for any reason. That's not something
>> > definite enough to write a contract about.
>>
>> Probably, it will be better if they also write about real requirements for
>> their product (as is version of kernel, glibc and so on). I'd wish also
>> that they distributed Linux version of the product with sources for system
>> dependent parts.
>
> The problem is that this means all sources because, ultimately,
> everything /is/ system dependent. For instance, 80x86 object files are
> no use to me running LinuxPPC. Just what *is* the 'Linux' of the
> subject line?
I haven't wrote about different platforms but only about different Linux
flavours on only platform. Of course, you can not use x86 object files on
machine with PowerPC. I think it is clear enough.
I wrote about those parts of software which relevant to some low level
things in glibc, kernel or somewhere else in which Linux variants (for same
hardware platform) can differ. I think such parts shouldn't exceed 10-15%
of the whole code.
>
> Supply object files for common microprocessor architectures you say?
> Well, I designed my own processor, coded it in VHDL, burned it onto an
> FPGA, ported a version of Linux to it and now wish to run a (supported!)
> Common Lisp implementation on it.
>
Again, I haven't wrote that all Linuxes on all platforms would be
supported. Nobody is able to come over an unboundness. :) So I am afraid
your platform won't be supported. :( Think twice before you buy a CL
implementation for it. :)
Aleksandr Skobelev
From: Michael J. Ferrador
Subject: Lisp Machine in FPGA Re: Lisp Vendor support for *Linux*
Date:
Message-ID: <3B718B15.A9E88175@orn.com>
····@mail.ru wrote:
>
> Duncan Harvey <····@hubris2.demon.co.uk> wrote:
> > <····@mail.ru> wrote:
> >
> >> Kent M Pitman <······@world.std.com> wrote:
> > Supply object files for common microprocessor architectures you say?
> > Well, I designed my own processor, coded it in VHDL, burned it onto
> > an FPGA, ported a version of Linux to it and now wish to run a
> > (supported!) Common Lisp implementation on it.
Are you going to do a Lisp Machine in FPGA? Are they dense enough yet?
I've never seen clock speeds (or instructions/clock) listed for the
Lisp Machines. How they compare w/ Ghz x86, .5Ghz RISC. So how would
one at 50, 100, 200Mhz in an FPGA(s) do?
Hardware GC? 1 cycle associative memory symbol lookup?
--
Michael J. Ferrador <·····@orn.com> wrote:
> ····@mail.ru wrote:
> > Duncan Harvey <····@hubris2.demon.co.uk> wrote:
> > > Supply object files for common microprocessor architectures you say?
> > > Well, I designed my own processor, coded it in VHDL, burned it onto
> > > an FPGA, ported a version of Linux to it and now wish to run a
> > > (supported!) Common Lisp implementation on it.
>
> Are you going to do a Lisp Machine in FPGA?
ohmygod! This is what happens when I delurk for five minutes -- people
assume I'm intelligent and talented. Mistake.
The above was merely a hypothetical example constructed to illustrate
that 'Linux' has (or can have) a meaning wider than most people assume.
Linux can be ported to any host platform -- not just those provided by
established CPU vendors, but any strange thing cooked up by a group or
individual -- and it would still be a Linux.
That was my original point. Although Aleksandr failed to bite at my
strawman, so to speak.
To be clear: I have /not/ (and could not have!) designed my own
processor, Lisp-flavoured or otherwise. Sorry if I raised anyones'
expectations.
> Hardware GC? 1 cycle associative memory symbol lookup?
Oh yeah, my made-up-chip had all this and more... ;)
--
Duncan Harvey
"Smiling and waving. Before letting himself fall."
-- Anja Garbarek, The Diver
From: Aleksandr Skobelev
Subject: Re: Lisp Machine in FPGA Re: Lisp Vendor support for *Linux*
Date:
Message-ID: <b1fuk9.6j.ln@hermit.athome>
Duncan Harvey <····@hubris2.demon.co.uk> wrote:
> Michael J. Ferrador <·····@orn.com> wrote:
>
>> ····@mail.ru wrote:
>> > Duncan Harvey <····@hubris2.demon.co.uk> wrote:
>> > > Supply object files for common microprocessor architectures you say?
>> > > Well, I designed my own processor, coded it in VHDL, burned it onto
>> > > an FPGA, ported a version of Linux to it and now wish to run a
>> > > (supported!) Common Lisp implementation on it.
>>
>> Are you going to do a Lisp Machine in FPGA?
>
> ohmygod! This is what happens when I delurk for five minutes -- people
> assume I'm intelligent and talented. Mistake.
>
> The above was merely a hypothetical example constructed to illustrate
> that 'Linux' has (or can have) a meaning wider than most people assume.
> Linux can be ported to any host platform -- not just those provided by
> established CPU vendors, but any strange thing cooked up by a group or
> individual -- and it would still be a Linux.
>
> That was my original point. Although Aleksandr failed to bite at my
> strawman, so to speak.
>
Could you please explain me in a more plain english this you phrase about
"your strawman" I failed to bite at. :) It sounds funny but I don't see your
point. :( For my english is not very good (as you could see) and I just don't
know this idiom.
Aleksandr.
From: Kent M Pitman
Subject: Re: Lisp Machine in FPGA Re: Lisp Vendor support for *Linux*
Date:
Message-ID: <sfw7kwd14dx.fsf@world.std.com>
Aleksandr Skobelev <····@mail.ru> writes:
> Could you please explain me in a more plain english this you phrase about
> "your strawman" I failed to bite at. :) It sounds funny but I don't see your
> point. :( For my english is not very good (as you could see) and I just don't
> know this idiom.
Speaking only to the idiomatic point, a "straw man" is something offered as
a start a discussion but is expected to be knocked down or blown down by
serious discussion. Its purpose is to get conversation moving and often
it is deliberately flawed to make the first few comments especially easy.
The phrase "bite at" usually goes with "bait", e.g., as in "fishing".
He's mixing metaphors.
In article <············@hermit.athome>, Aleksandr Skobelev wrote:
>Could you please explain me in a more plain english this you phrase about
>"your strawman" I failed to bite at. :) It sounds funny but I don't see your
>point. :( For my english is not very good (as you could see) and I just don't
>know this idiom.
A strawman argument is formed by arguing against a weaker version of
the position that your opponent actually holds, rather than against the
opponent's actual position. That weaker position is the ``strawman''
that is easy to knock over, compared to the real position. Needless to
say, a strawman argument is no argument at all; it's an irritation that
hinders debate.
From: Aleksandr Skobelev
Subject: Re: Lisp Machine in FPGA Re: Lisp Vendor support for *Linux*
Date:
Message-ID: <60i0l9.vs.ln@hermit.athome>
Thank you all for the such thorough answers.
I am sorry that I dissapointed Duncan. :) To console him I'd like to say
that I was also disappointed a little. For nobody comments my own
utterance about distributing sources for commercial Lisp realizations. :(
Aleksandr
Kaz Kylheku <···@ashi.footprints.net> wrote:
> In article <············@hermit.athome>, Aleksandr Skobelev wrote:
>>Could you please explain me in a more plain english this you phrase about
>>"your strawman" I failed to bite at. :) It sounds funny but I don't see your
>>point. :( For my english is not very good (as you could see) and I just don't
>>know this idiom.
>
> A strawman argument is formed by arguing against a weaker version of
> the position that your opponent actually holds, rather than against the
> opponent's actual position. That weaker position is the ``strawman''
> that is easy to knock over, compared to the real position. Needless to
> say, a strawman argument is no argument at all; it's an irritation that
> hinders debate.
"Michael J. Ferrador" <·····@orn.com> wrote in message
······················@orn.com...
> ····@mail.ru wrote:
> >
> > Duncan Harvey <····@hubris2.demon.co.uk> wrote:
> > > <····@mail.ru> wrote:
> > >
> > >> Kent M Pitman <······@world.std.com> wrote:
> > > Supply object files for common microprocessor architectures you say?
> > > Well, I designed my own processor, coded it in VHDL, burned it onto
> > > an FPGA, ported a version of Linux to it and now wish to run a
> > > (supported!) Common Lisp implementation on it.
>
> Are you going to do a Lisp Machine in FPGA? Are they dense enough yet?
I'm sure that you can fit several Lisp machines in a single Virtex II FPGA.
> I've never seen clock speeds (or instructions/clock) listed for the
> Lisp Machines. How they compare w/ Ghz x86, .5Ghz RISC. So how would
> one at 50, 100, 200Mhz in an FPGA(s) do?
The major advantage of FPGAs is distributed processing. You can do several
billions arithmetic operations in a FPGA, but if you only want to do a
single processor you will be slower than an very optimized processor chip.
Anyway if the microcode of a Lisp machine were available it could be fun to
plug it into a FPGA. It will probably be much faster than the original!
Marc
From: ···@itasoftware.com
Subject: Re: Lisp Machine in FPGA Re: Lisp Vendor support for *Linux*
Date:
Message-ID: <r8tlk9rx.fsf@itasoftware.com>
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Michael J. Ferrador" <·····@orn.com> wrote in message
> ······················@orn.com...
> > ····@mail.ru wrote:
> > >
> > > Duncan Harvey <····@hubris2.demon.co.uk> wrote:
> > > > <····@mail.ru> wrote:
> > > >
> > > >> Kent M Pitman <······@world.std.com> wrote:
> > > > Supply object files for common microprocessor architectures you say?
> > > > Well, I designed my own processor, coded it in VHDL, burned it onto
> > > > an FPGA, ported a version of Linux to it and now wish to run a
> > > > (supported!) Common Lisp implementation on it.
> >
> > Are you going to do a Lisp Machine in FPGA? Are they dense enough yet?
>
>
> I'm sure that you can fit several Lisp machines in a single Virtex II FPGA.
No problem. Lisp Machines aren't all that complicated, just
unorthodox. I don't know the details of the later chips such as the
Ivory, but the vintage 80's machines didn't have speculative
execution, on-the-fly instruction stream optimization, out-of-order
writes, or any of the hair associated with top-of-the-line processors
you see today.
> > I've never seen clock speeds (or instructions/clock) listed for the
> > Lisp Machines. How they compare w/ Ghz x86, .5Ghz RISC. So how would
> > one at 50, 100, 200Mhz in an FPGA(s) do?
>
> The major advantage of FPGAs is distributed processing. You can do several
> billions arithmetic operations in a FPGA, but if you only want to do a
> single processor you will be slower than an very optimized processor chip.
>
> Anyway if the microcode of a Lisp machine were available it could be fun to
> plug it into a FPGA. It will probably be much faster than the original!
No doubt. The LMI Lambda operated at a speed of somewhere around 4
MHz. It's kinda hard to be specific because the machine's clock
generator was in a RAM (yes, you could reprogram the clock cycle on
the sucker. The first few lambda's were `detuned' because of race
conditions in the hardware.) This would be roughly the amount of time
to execute a single microinstruction. A `macroinstruction' could take
anywhere from about 2 microinstructions (for something like POP) to
100 microinstructions (for a FUNCALL). I'm not an expert on FPGAs,
but I think that reproducing the CADR hardware in an FPGA would not be
too much of a challenge. (Probably easier than finding a copy of the
microcode.)
An x86 really isn't an optimal design for running lisp. An
appropriately programmed FPGA ought to be able to perform as well as a
much faster x86 doing `lisp machine' type tasks. (Let me hazard a
guess of on the order of a 10:1 advantage.)
~jrm