> > Commercial Lisps for Unix (Solaris, etc.) are very expensive, I agree.
> > The only solution I have found, is not to use a commercial Lisp
> > under Unix.
> >
>
> Well, do you have any suggestions?
No.
> One problem is that having a simple Lisp
> interpreter/compiler system is not enough. What is attractive about the Harlequin Enterprise
> product, for example, is that it has a knowledge base construction component, database access
> modules, CORBA support, GUI development support, etc.
The Enterprise version for Windows costs $2000 (including CORBA support,
Knowledgeworks, ODBC support, ...
Unix versions are more expensive.
> preferred by the company). When I asked Harlequin if they had cross-compilers the answer was
> a pause and then "Uh, no." Okay. My company has deep pockets. I could easily spend several
> thousand dollars for a software development system without blinking an eye. But it has to do
> what I want and it has to have no strings attached. In fact, I could easily spend $10K or
> more for the right system.
Unfortunately a commercial Lisp development system for Unix can
easily be in that range when you add all the options you
have named. The competition might be even more expensive.
> By the way, the Harlequin system is still pretty amateurish compared to contemporary
> development systems such as Visual C++, VisualAge, JBuilder, etc. It suffers very much from
> its history and design philosophy as a UNIX product intended primarily for research and
> academic pursuits. Basically it is still a command line system with windows grafted onto it.
For some of their tools you are right.
> Objectively speaking, the interface and debugging capabilities are pathetic compared to what
> developers should expect today. And the integration of its NT version with NT is at points
> laughable (and at other points utterly frustrating). I've passed on a detailed evaluation of
> this to Harlequin, of course (a lot of high-priced consulting and product evaluation for free
> from me). I would still buy the product (even just for my Alpha) if I were convinced it
> really worked and they would drop the idiotic royalty constraints.
The UI has some rough edges (windows are not responsive when busy, grrr.).
Still, I think it is not that bad.
> So what do you suggest as an alternative?
Can't help you. Look for Smalltalk? Maybe expensive on Unix, too.
For my *personal* development purpose I'm using my Mac.
Sorry,
Rainer Joswig
Rainer Joswig wrote: The Enterprise version for Windows costs $2000 (including CORBA support,
> Knowledgeworks, ODBC support, ...
>
> Unix versions are more expensive.
>
I would not have minded paying the $7K for the version on my Alpha if it had been all there and
working. I was sent a beta copy for testing and examination -- without any installation
documentation (in fact, without any documentation at all), and so I never go around to really
testing it. But it didn't matter since some of the stuff I was interested in was not included in
the beta. At that time the Enterprise edition was not available for the PC.
> The UI has some rough edges (windows are not responsive when busy, grrr.).
> Still, I think it is not that bad.
>
They have made the (in my opinion, and I've been in the same position in porting environments)
deadly decision to retain the emacs interface on the NT version. This is *terribly* frustrating
since it means that you cannot do the normal things in the normal ways (e.g., copy, paste, etc.
with keystrokes) between LispWorks windows and any other windows on the PC. Sure, these are all
things one could get used to. But for the price of the product (ten times as much on the PC as I
just paid for a much more sophisticated Java development environment), one should not have to get
used to such things. Not to mention the documentation -- which is better not mentioned.
> > So what do you suggest as an alternative?
>
> Can't help you. Look for Smalltalk?
Gag me with a spoon, eh? I really wanted the KB stuff as a "light weight" alternative to Cyc. For
just normal development I am drifting in the direction of Java with a native code compiler.
> Maybe expensive on Unix, too.
> For my *personal* development purpose I'm using my Mac.
>
Alas, I am in the position of having to plan for deploying applications throughout one of the
largest pharmaceutical companies in the world. Macs don't cut it, corporate-wise. Even my nifty
little Alpha (330Mhz, 1G memory, 18G disk) is frowned upon by the system support folks (who are
ideologically committed to Solaris).
-- Gary Merrill
> I would not have minded paying the $7K for the version on my Alpha if it had been all there and
> working. I was sent a beta copy for testing and examination -- without any installation
> documentation (in fact, without any documentation at all), and so I never go around to really
> testing it. But it didn't matter since some of the stuff I was interested in was not included in
> the beta. At that time the Enterprise edition was not available for the PC.
Maybe it is time to look again?
> They have made the (in my opinion, and I've been in the same position in porting environments)
> deadly decision to retain the emacs interface on the NT version. This is *terribly* frustrating
> since it means that you cannot do the normal things in the normal ways (e.g., copy, paste, etc.
> with keystrokes) between LispWorks windows and any other windows on the PC.
They have their own editor which is Emacs like. Hmm, I like it.
If they cannot copy to other windows, then I'd say this is
a serios bug. In MCL for example, I'm using the usual Emacs
commands (and the unlimited cut buffer) together with the
usual Mac commands for cut/copy/paste. Shouldn't be that
difficult.
> things one could get used to. But for the price of the product (ten times as much on the PC as I
> just paid for a much more sophisticated Java development environment),
Hmm, the Lisp market is smaller (sadly) and I'd also guess that there
is quite a lot power under the hood of a Lisp system.
Otherwise, maybe there are systems for developing knowledge-based applications
under Java?
> one should not have to get
> used to such things. Not to mention the documentation -- which is better not mentioned.
You get HTML and PDF versions. Printed versions are available, too.
Actually the documentation has improved, compared to earlier versions. ;-)
> > > So what do you suggest as an alternative?
> >
> > Can't help you. Look for Smalltalk?
>
> Gag me with a spoon, eh? I really wanted the KB stuff as a "light weight" alternative to Cyc.
What do you want to do? There are a lot of alternatives in the
knowledge representation area.
> Alas, I am in the position of having to plan for deploying applications throughout one of the
> largest pharmaceutical companies in the world. Macs don't cut it, corporate-wise. Even my nifty
> little Alpha (330Mhz, 1G memory, 18G disk) is frowned upon by the system support folks (who are
> ideologically committed to Solaris).
Well, SPARCs with Solaris are also here in Germany more common than ALPHAs.
I'd wish Symbolics would port Open Genera to UltraSPARCs. Currently it
only runs on DEC ALPHA under Unix.
Rainer Joswig wrote:
> > Gag me with a spoon, eh? I really wanted the KB stuff as a "light weight" alternative to Cyc.
>
> What do you want to do? There are a lot of alternatives in the
> knowledge representation area.
>
I could make use of a decent knowledge representation language plus an inference engine. While it
would be nice to have something along the lines of CycL, it is not realistic to expect this. However,
some requirements are that it is a commercial product and Y2K compliant. An additional requirement is
that a KBS built with this have good response time in an interactive application. And there should be
decent tools to support development. In the case of NT applications this would include GUI
development, or at least a way to interface in an easy way with something like an interface written in
Java. I should either be able to straightforwardly develop NT based KBS applications or to develop
server applications that run on the Alpha and are web-accessible. All of this I can do (and currently
do) via Cyc. But as I say, the ability to produce applications with considerably less overhead and
with better response time would be advantageous.
> Well, SPARCs with Solaris are also here in Germany more common than ALPHAs.
> I'd wish Symbolics would port Open Genera to UltraSPARCs. Currently it
> only runs on DEC ALPHA under Unix.
It is really difficult (I would say "impossible") to beat the Alpha in terms of its price/performance
ratio. The system I have (again, 330 MHz processor, 1G memory, 18G hard drives, DEC Alpha UNIX) cost
only about $20K. Last time I checked, a comparable system from Sun would have cost twice as much.
(The memory is not DEC memory, but is a third party vendor. It works just fine.)
-- Gary Merrill
"Gary H. Merrill" wrote:
(snip)
> They have made the (in my opinion, and I've been in the same position in porting environments)
> deadly decision to retain the emacs interface on the NT version. This is *terribly* frustrating
> since it means that you cannot do the normal things in the normal ways (e.g., copy, paste, etc.
> with keystrokes) between LispWorks windows and any other windows on the PC.
Just because you need to use different keystrokes, you can still copy
and paste between LW and other applications. For example, copy examples
from the HTML documentation and paste them in the listener. You can
easily reassign the keystroke assignments if you want (maybe someone has
example code?).
I understand your point, but for us it is the power of CL rather than
the flashiness of the IDE that matters - that's where productivity is
coming from. I could still create pretty decent GUI functions
(spreadsheet-like grids with automatic layout and dynamic resizing). BTW
we have not chosen CL because of legacy code or AI - we evaluated Java
and Smalltalk as well, and made an informed decision based on
development productivity, application quality and performance.
> Sure, these are all
> things one could get used to. But for the price of the product (ten times as much on the PC as I
> just paid for a much more sophisticated Java development environment), one should not have to get
> used to such things. Not to mention the documentation -- which is better not mentioned.
I am sure you know how much more powerful CLOS is.
Documentation: on the positive side, Common Lisp is a very well
documented language. The additional features (SQL, CAPI, delivery etc.)
are still not documented too verbosely, but their support fills the gaps
(I think it is not as economical to them as adding to the documentation,
but there is some progress).
Robert
well, try this: dual 400 MHz Pentium II, 512M RAM, 3 x 9G SCSI disks, 16G
IDE disk, CD-RW burner, ethernet, no display, no sound. Debian Linux
2.1.125. intended as a small enterprise server. bought in October last
year at about USD 7,500, in Norway, with its world-famous 23% sales tax
included. as an added bonus, an Allegro CL license for Linux is the same
price as the Windows/NT license.
I reviewed Alpha and SPARC at the time, but I tend to distrust Compaq,
and the price/performance ratio was not at all competitive with Intel,
anyway.
#:Erik
--
Y2K conversion simplified: Januark, Februark, March, April, Mak, June,
Julk, August, September, October, November, December.
>
>
>Rainer Joswig wrote: The Enterprise version for Windows costs $2000 (including CORBA support,
>
>> Knowledgeworks, ODBC support, ...
>>
>> Unix versions are more expensive.
>>
>
>I would not have minded paying the $7K for the version on my Alpha if it had been all there and
>working. I was sent a beta copy for testing and examination -- without any installation
>documentation (in fact, without any documentation at all), and so I never go around to really
>testing it. But it didn't matter since some of the stuff I was interested in was not included in
>the beta. At that time the Enterprise edition was not available for the PC.
>
>> The UI has some rough edges (windows are not responsive when busy, grrr.).
>> Still, I think it is not that bad.
>>
>
>They have made the (in my opinion, and I've been in the same position in porting environments)
>deadly decision to retain the emacs interface on the NT version. This is *terribly* frustrating
>since it means that you cannot do the normal things in the normal ways (e.g., copy, paste, etc.
>with keystrokes) between LispWorks windows and any other windows on the PC. Sure, these are all
This is simply wrong. You can copy, paste etc. as much as you like,
the only difference is that you use an other key combination.
(ctrl-insert etc.) Takes some getting used to, right, and I too would
prefer ctrl-c etc.
I am very happy that they retained the Emacs interface where most
things can be done with key strokes, without dialogs popping up all
the time (in almost all other environments I am missing incremental
search and query replace). (Not having a decent built-in Emacs
interface is in my view a big shortcoming in the new ACL for Windows.)
Might take some getting used to if you haven't used Emacs before, but
you get a lot for it, in my eyes.
Paul Meurer
Paul Meurer at HIT UiB no
Humanities Information Technologies,
University of Bergen
Allegt. 27
5007 Bergen, Norway
Erik Naggum wrote:
> well, try this: dual 400 MHz Pentium II, 512M RAM, 3 x 9G SCSI disks, 16G
> IDE disk, CD-RW burner, ethernet, no display, no sound. Debian Linux
> 2.1.125. intended as a small enterprise server. bought in October last
> year at about USD 7,500, in Norway, with its world-famous 23% sales tax
> included. as an added bonus, an Allegro CL license for Linux is the same
> price as the Windows/NT license.
>
This would be a nice alternative except basically for two things. First, Linux
will not come remotely close to being accepted for support within a lot of
companies (mine in particular). And this won't be happening for some time.
Don't argue about how this is unreasonable. It is simply a fact. And then ...
> I reviewed Alpha and SPARC at the time, but I tend to distrust Compaq,
> and the price/performance ratio was not at all competitive with Intel,
> anyway.
Oh? So which of the 64-bit Sun and Intel processors were you reviewing?
-- Gary Merrill
Robert Monfera wrote: I understand your point, but for us it is the power of CL rather than
> the flashiness of the IDE that matters - that's where productivity is
> coming from. I could still create pretty decent GUI functions
> (spreadsheet-like grids with automatic layout and dynamic resizing). BTW
> we have not chosen CL because of legacy code or AI - we evaluated Java
> and Smalltalk as well, and made an informed decision based on
> development productivity, application quality and performance.
>
I fully understand this perspective. However, I take it you are not developing for multiple
platforms? If you are, I suppose you have spent the money for the LISP environment on *each*
platform? Now that really starts to add up. And then there is the unfortunate issue of the
royalties. I think the primary problem I had with Harlequin was that it simply had an unfinished,
academic, not well thought out feel to it. And the documentation of the *product* (not the language)
is pretty sad. I came up to speed in Java (a language I did not know at all) with JBuilder much more
quickly than I was proceeding with LispWorks -- and I at least used to know LISP *very* well. This
says something about the product. Their support people seem to be great. I may in fact try the
product again in a while, after the Enterprise product has been in the field for a release or two.
-- Gary Merrill
Paul Meurer wrote:
> On Sat, 06 Feb 1999 13:32:18 -0500, "Gary H. Merrill"
> <gmer...@mindspring.com> wrote:
>
>
> >They have made the (in my opinion, and I've been in the same position in porting environments)
> >deadly decision to retain the emacs interface on the NT version. This is *terribly* frustrating
> >since it means that you cannot do the normal things in the normal ways (e.g., copy, paste, etc.
> >with keystrokes) between LispWorks windows and any other windows on the PC. Sure, these are all
>
> This is simply wrong. You can copy, paste etc. as much as you like,
> the only difference is that you use an other key combination.
Please note the phrase "in the normal ways" that was part of my criticism. Thus it is *not* "simply
wrong".
> (ctrl-insert etc.) Takes some getting used to, right, and I too would
> prefer ctrl-c etc.
> I am very happy that they retained the Emacs interface where most
> things can be done with key strokes, without dialogs popping up all
> the time (in almost all other environments I am missing incremental
> search and query replace). (Not having a decent built-in Emacs
> interface is in my view a big shortcoming in the new ACL for Windows.)
> Might take some getting used to if you haven't used Emacs before, but
> you get a lot for it, in my eyes.
Well, I've been using Emacs for about fifteen years. So the problem isn't that I don't know or
appreciate emacs. But on an NT system I really prefer windows to act like *NT* windows uniformly
unless I am specifically intending to use one as an Emacs window. I suppose I might be able to
arrange things so that all of my NT applications conformed to the Emacs conventions (though I'm not
sure how possible this is to do do), but that would be terribly goofy for even the most rabid Emacs
fanatic. And short of that having *one* application's windows conform to a totally foreign convention
is, at least to me, terribly annoying. Software vendors who have attempted to follow the philosophy
(and I've worked for some) of "one common interface across all platforms" have discovered that this is
*not* what their customers want.
-- Gary Merrill
simple facts tend to be wrong. Linux is a fully supported commercial
operating system.
| Oh? So which of the 64-bit Sun and Intel processors were you reviewing?
64-bit vs 32-bit was not a concern for this acquisition.
Erik Naggum wrote:
> * "Gary H. Merrill" <gmer...@mindspring.com>
> | This would be a nice alternative except basically for two things. First,
> | Linux will not come remotely close to being accepted for support within a
> | lot of companies (mine in particular). And this won't be happening for
> | some time. Don't argue about how this is unreasonable. It is simply a
> | fact. And then ...
>
> simple facts tend to be wrong. Linux is a fully supported commercial
> operating system.
>
You still don't get it. The fact that Linux is "a fully supported commercial
operation system" is not sufficient. What matters is *who* supports it.
Unless it is supported by the *vendor* (as is OSF/1 for the Alpha, HP/UX, and
Solaris) many (if not most, if not all) large IT organizations will *not* have
anything to do with it.
> | Oh? So which of the 64-bit Sun and Intel processors were you reviewing?
>
> 64-bit vs 32-bit was not a concern for this acquisition.
Yeah, see ... if you are dealing with just tiny programs than almost any
hardware will do. (I do wish the 64-bit Intel chip would hit the market. Then
I would get a 64-bit Linux system real quick.)
-- Gary Merrill
> Yeah, see ... if you are dealing with just tiny programs than almost
> any hardware will do.
How are you defining "tiny"? AFAICR and know, you only need 64 bitness
for OODB stuff when you've got like more than 4GB physical+virtual
memory. On the Intel processor, you can decide if you want the
physical/virtual split to be 1GB/3GB (the Linux default, I believe) or
2GB/2GB.
> (I do wish the 64-bit Intel chip would hit the market. Then I would
> get a 64-bit Linux system real quick.)
Alpha Linux reputably is very robust these days.
Christopher
[BTW, I wish you would set up your newsreader to wrap lines so that
they are < 80 columns. It's annoying to those of us that fix our
frames at the 80 column "standard" to resize the frame or wrap the
long lines.]
having worked with an employee to introduce Linux to a company that had a
similar policy to the one you refer to, I have some solid evidence that I
understand what kinds of concerns managers have and how to answer them.
of course, if it suits you to ignore any and all proof that you might
succeed if you actually tried, that's your problem. I know how such
policies come to be and how to change them without scaring managers who
have legitimate concerns behind their decisions, not just the religious
edicts you imply that these policies are. that you don't understand how
to deal with these things is not my problem. I'm not trying to change
your mind, I'm just trying to make you aware that you make invalid claims
in the interest of making the _real_ concerns explicit. enough stupid
people hide behind things they don't _want_ to change to make it
necessary to figure out what they are frightened of. you give me a very
powerful hint that you are indeed afraid of something. had I had any
incentive (a lot of money) to convince you and your managers otherwise, I
would have succeeded in it, even if you can't.
| The fact that Linux is "a fully supported commercial operation system" is
| not sufficient. What matters is *who* supports it. Unless it is
| supported by the *vendor* (as is OSF/1 for the Alpha, HP/UX, and Solaris)
| many (if not most, if not all) large IT organizations will *not* have
| anything to do with it.
you appear to speak without knowledge of the Linux market. e.g., both
RedHat and Caldera are vendors of considerable size who support their own
Linux distributions and are held accountable for the systems they have
delivered. I'm not talking about the many hackers around the world who
make Linux a great system and for which some people have great disdain,
and who accept money for supporting people.
| Yeah, see ... if you are dealing with just tiny programs than almost any
| hardware will do.
it seems you have a problem with your assumption-generator: it appears to
be completely unchecked by facts or other input from the outside world.
a dual processor with 512M RAM and 40+ G of disk is not a good buy when
you have "tiny programs" and "almost any hardware will do", it's a waste
of money because "almost any hardware" is even _cheaper_.
I don't think further input to you would be anything but a waste, either.
Erik Naggum wrote:
> * "Gary H. Merrill" <gmer...@mindspring.com>
> | You still don't get it.
>
> having worked with an employee to introduce Linux to a company that had a
> similar policy to the one you refer to, I have some solid evidence that I
> understand what kinds of concerns managers have and how to answer them.
> of course, if it suits you to ignore any and all proof that you might
> succeed if you actually tried, that's your problem. I know how such
> policies come to be and how to change them without scaring managers who
> have legitimate concerns behind their decisions, not just the religious
> edicts you imply that these policies are. that you don't understand how
> to deal with these things is not my problem. I'm not trying to change
> your mind, I'm just trying to make you aware that you make invalid claims
> in the interest of making the _real_ concerns explicit. enough stupid
> people hide behind things they don't _want_ to change to make it
> necessary to figure out what they are frightened of. you give me a very
> powerful hint that you are indeed afraid of something. had I had any
> incentive (a lot of money) to convince you and your managers otherwise, I
> would have succeeded in it, even if you can't.
And just how large was this company in which you succeeded and what was its
organization? I sense the wounded response of the true Linux fanatic. Let me
make this clear. I would be happy to use such a system. I in fact have
suggested a very well defined project to demonstrate the viability of using
such systems in the company. I have offered to support such a demonstration.
But, not being a fanatic, and having a very good knowledge of the actual and
historical workings of this company, I do not choose to devote my time to a
crusade. All your puffery, breast beating, and name calling cannot change the
facts.
> | The fact that Linux is "a fully supported commercial operation system" is
> | not sufficient. What matters is *who* supports it. Unless it is
> | supported by the *vendor* (as is OSF/1 for the Alpha, HP/UX, and Solaris)
> | many (if not most, if not all) large IT organizations will *not* have
> | anything to do with it.
>
> you appear to speak without knowledge of the Linux market. e.g., both
> RedHat and Caldera are vendors of considerable size who support their own
> Linux distributions and are held accountable for the systems they have
> delivered. I'm not talking about the many hackers around the world who
> make Linux a great system and for which some people have great disdain,
> and who accept money for supporting people.
You are still not listening. I am well aware of the commercially distributed
and supported version of Linux. I thought that was clear. That is not the
issue. If it isn't Microsoft and it isn't supported by the *hardware* vendor,
it doesn't count. I can go out and buy any kind of machine I like and run it
in my office as my private lab machine -- as long as *I* support it. If the OS
software is not Microsoft and it isn't supported by the *hardware* vendor, then
the support organization will *not* support it. I can't get the support
organization to support NT on my *notebook*. They support NT on desktops, but
not on notebooks. You really don't have a clue about large organizations of
certain sorts. Your experience must be *very* limited.
> | Yeah, see ... if you are dealing with just tiny programs than almost any
> | hardware will do.
>
> it seems you have a problem with your assumption-generator: it appears to
> be completely unchecked by facts or other input from the outside world.
> a dual processor with 512M RAM and 40+ G of disk is not a good buy when
> you have "tiny programs" and "almost any hardware will do", it's a waste
> of money because "almost any hardware" is even _cheaper_.
>
In some corners of the software world, 512M RAM is a relatively small amount of
memory. Your own assumptions and lack of genuine experience are showing.
> I don't think further input to you would be anything but a waste, either.
>
Certainly not any further input from you.
-- Gary Merrill
Christopher R. Barry wrote:
> "Gary H. Merrill" <gmer...@mindspring.com> writes:
>
> > Yeah, see ... if you are dealing with just tiny programs than almost
> > any hardware will do.
>
> How are you defining "tiny"? AFAICR and know, you only need 64 bitness
> for OODB stuff when you've got like more than 4GB physical+virtual
> memory. On the Intel processor, you can decide if you want the
> physical/virtual split to be 1GB/3GB (the Linux default, I believe) or
> 2GB/2GB.
>
"AFAICR and know" is the operative phrase. Imagine a VLKB kept all in
memory and containing hundreds of thousands or millions of assertions.
For some things you really need a 64-bit address space.
> > (I do wish the 64-bit Intel chip would hit the market. Then I would
> > get a 64-bit Linux system real quick.)
>
> Alpha Linux reputably is very robust these days.
So is DEC Alpha UNIX -- and it is supported by the hardware vendor.
> Christopher
>
> [BTW, I wish you would set up your newsreader to wrap lines so that
> they are < 80 columns. It's annoying to those of us that fix our
> frames at the 80 column "standard" to resize the frame or wrap the
> long lines.]
80 columns was standard when we were confined to punch cards. It's
always better to wrap at 72 characters in any event. And that in fact is
what this mailer is set to.
-- Gary Merrill
> Christopher R. Barry wrote:
>
> > "Gary H. Merrill" <gmer...@mindspring.com> writes:
> >
> > > Yeah, see ... if you are dealing with just tiny programs than almost
> > > any hardware will do.
> >
> > How are you defining "tiny"? AFAICR and know, you only need 64 bitness
> > for OODB stuff when you've got like more than 4GB physical+virtual
> > memory. On the Intel processor, you can decide if you want the
> > physical/virtual split to be 1GB/3GB (the Linux default, I believe) or
> > 2GB/2GB.
> >
>
> "AFAICR and know" is the operative phrase. Imagine a VLKB kept all in
> memory and containing hundreds of thousands or millions of assertions.
> For some things you really need a 64-bit address space.
"For some things" is the operative phrase here. Nearly all
applications are comfortable with way under 4GB, and a lot of people
are successfully implementing KR and OODB systems on Intel hardware
with the 4GB limitation. And they are saving themselves a lot of money
by going with hardware that is far more cost effective.
Stop by www.pricewatch.com some time. You can get a top of the line
Pentium II or III motherboard for under $130, and a dual board for
under $200. A Pentium II 400 is $314, and a Pentium III 450 is $544.
And you'd have to see memory prices these days to believe them....
Now that the Alpha 21264 is out, 21164 chip prices are within reason
but you still can't get a motherboard for under $1000.
> > > (I do wish the 64-bit Intel chip would hit the market. Then I would
> > > get a 64-bit Linux system real quick.)
> >
> > Alpha Linux reputably is very robust these days.
>
> So is DEC Alpha UNIX -- and it is supported by the hardware vendor.
And what exactly does "support from the hardware vendor" really buy
you over support from a software vendor? Digital Unix costs at the
very least $1000 per license, and it isn't nearly as nice as Linux or
Solaris except for the Digital FORTRAN compiler, if you're really into
that kind of thing.
> > Christopher
> >
> > BTW, I wish you would set up your newsreader to wrap lines so that
> > they are < 80 columns. It's annoying to those of us that fix our
> > frames at the 80 column "standard" to resize the frame or wrap the
> > long lines.]
>
> 80 columns was standard when we were confined to punch cards.
And it should be abandoned now? Should we all just wrap lines at
whatever weird geometry our xterms or mail clients or IDEs happen to
be at and make printing a nightmare and make people take additional
steps to adjust their clients so that what they have in front of their
face is readable?
> It's always better to wrap at 72 characters in any event. And that
> in fact is what this mailer is set to.
Thank you for configuring it properly, but that's not what it was set
to do a few posts up when you had lines over 100 columns long that
your Windows 95 Mozilla client sent. You probably need a reminder
though. Here:
------
It is really difficult (I would say "impossible") to beat the Alpha in terms of its price/performance
ratio. The system I have (again, 330 MHz processor, 1G memory, 18G hard drives, DEC Alpha UNIX) cost
only about $20K. Last time I checked, a comparable system from Sun would have cost twice as much.
------
Christopher
> "Gary H. Merrill" <gmer...@mindspring.com> writes:
>
> > Christopher R. Barry wrote:
> >
> > > "Gary H. Merrill" <gmer...@mindspring.com> writes:
> > >
> > > > Yeah, see ... if you are dealing with just tiny programs than almost
> > > > any hardware will do.
> > >
> > > How are you defining "tiny"? AFAICR and know, you only need 64 bitness
> > > for OODB stuff when you've got like more than 4GB physical+virtual
> > > memory. On the Intel processor, you can decide if you want the
> > > physical/virtual split to be 1GB/3GB (the Linux default, I believe) or
> > > 2GB/2GB.
> > >
> >
> > "AFAICR and know" is the operative phrase. Imagine a VLKB kept all in
> > memory and containing hundreds of thousands or millions of assertions.
> > For some things you really need a 64-bit address space.
>
> "For some things" is the operative phrase here. Nearly all
> applications are comfortable with way under 4GB, and a lot of people
> are successfully implementing KR and OODB systems on Intel hardware
> with the 4GB limitation. And they are saving themselves a lot of money
> by going with hardware that is far more cost effective.
so he wants/needs 64 bit address spaces? what's it to you?
linux on intel can't really exploit all 4GB either. you get at most 2
GB of user stuff and the rest is gone to virtual memory mapping and
shuffling around.
> Stop by www.pricewatch.com some time. You can get a top of the line
> Pentium II or III motherboard for under $130, and a dual board for
> under $200. A Pentium II 400 is $314, and a Pentium III 450 is $544.
>
> And you'd have to see memory prices these days to believe them....
the price of the hardware is sometimes not an issue. if a $50k
machine does what you need it to do, then that may just be a good
route to take. nevermind if you can cobble together 40 obsolete PCs
into a beo-cluster for half the price. the whole project may be
budgeted in multi-million dollar amount and the price of the computer
you purchase is down in the noise.
> Now that the Alpha 21264 is out, 21164 chip prices are within reason
> but you still can't get a motherboard for under $1000.
>
> > > > (I do wish the 64-bit Intel chip would hit the market. Then I would
> > > > get a 64-bit Linux system real quick.)
> > >
> > > Alpha Linux reputably is very robust these days.
> >
> > So is DEC Alpha UNIX -- and it is supported by the hardware vendor.
>
> And what exactly does "support from the hardware vendor" really buy
> you over support from a software vendor? Digital Unix costs at the
> very least $1000 per license, and it isn't nearly as nice as Linux or
> Solaris except for the Digital FORTRAN compiler, if you're really into
> that kind of thing.
i don't think this is a logic or price-awareness type issue. `support
from hardware vendor' means that his IT department is willing to
service and administer his machine. i think that is _all_ there is to
it. it's a label used by the IT dept to restrict the things they are
going to support. you may think this is an idiotic policy, but it's
_policy_ and anyone who has worked for a large company knows how far
removed from reality policy can become.
some things are just not worth fighting for. i wouldn't care all that
much whether i got digital unix or linux. since the policy is use dec
unix, i'd just use it. big deal.
gary has been more than reasonable. he seems to understand the issues
involved. he even seems to like and respect linux. you are preaching
to the choir but gary's company has a different religion.
--
johan kullstam
> You are still not listening. I am well aware of the commercially distributed
> and supported version of Linux. I thought that was clear. That is not the
> issue. If it isn't Microsoft and it isn't supported by the *hardware* vendor,
> it doesn't count.
There are hardware vendors that support Linux. VA Research for example.
Erann Gat
g...@jpl.nasa.gov
And Compaq(DEC), Dell and Gateway2000 have announced plans to sell
Linux-based servers with support. There are rumours that IBM and HP
want to follow suit.
So choices are increasing, even for those who don't want to fight
their IT departments.
But the whole thread has strayed a bit far from Lisp or AI Philosophy,
so I'd suggest we return to more lispy topics here...
Hmm, IIRC prior to this discussion on Linux, hardware and corporate
live, Greg was talking about using Cyc to either implement KB
applications on NT, or implementing those applications on DU/Alpha
and making them web-accessible, and looking to Lisp as an alternative
to Cyc.
Well, I don't like the first "solution" (I refuse to put critical
functionality of systems on Microsoft-based systems), so I very much
prefer the second modus operandi, since it also gives you instant
portability to most client platforms, and it makes it easy for the
users to further process the output (e.g. integrating it with reports
in their favourite word-processors, etc.).
I'm currently leading a project that is redeveloping a fairly large
simulation package[1]. As part of the redevelopment, we are developing a
fairly extensive suite for evaluating and visualizing the simulation
results, to increase the user transparency and usability. At current,
most of the reports are generating DocBook (SGML) and graphics files
off-line, which are then translated to HTML, RTF and/or TeX/DVI/PDF.
To increase usability, we are currently evaluating cl-http[2] for
on-line generation of HTML and/or DocBook XML reports, as a first
step. Should this prove to be successful and usable, we are thinking
of building a complete interactive simulation desktop environment with
cl-http, so that the users can directly integrate new data-sets into
the simulation project, validate them, simulate and evaluate the
results, without direct involvement of the specialized simulation
group, so that the simulation group would only be involved in the
modelling, simulation development and user support/information.
Anyone who is working on similar things, or is simply interested is
welcome to contact me. I'll also try to keep the group informed of
our successes and failures in using Common Lisp for this project.
Regs, Pierre.
PS: To put some people here into perspective, _all_ applications that
run on single workstations (whether 32bit or 64bit) are tiny. Large
applications run on mainframes, supercomputers and/or clusters, for
various dimensions of large (e.g.. data volume, computation volume,
reliability, transaction throughput, response time, etc.). And despite
all the down-sizing hysteria a few years ago, it turned out that it
will stay this way for quite a while longer. Oh, and BTW, there are
also other people in this newsgroup that have direct experience with
large corporations and organizations, and I'd wager a bet that German
corporate giants are no less bureaucratic than American ones ;) And a
growing number of them are starting to use Linux in various parts of
their operations, and some are even openly admitting it ;) Ditto for
Common Lisp, btw. Wasn't someone in this group looking for Lisp work,
or something like this? Well, a quick glance at www.jobs.de has
revealed to me around 10 job offers that mention Lisp directly in
the last 4 weeks or so...
Footnotes:
[1] The original simulation suite was implemented in C++, with
visualisation tools in Tcl/Tk and some other tools in Perl. It was a
nightmare to maintain or extend, and after deliberations whether to
redevelop it in C++, it was decided (i.e. I convinced my client) to
redevelop it in Common Lisp. As was to be expected, since simulation
is a field where requirements change quickly, and are often only
understood clearly as more simulation projects are undertaken, we are
very much pleased with the speed and flexibility that Common Lisp has
given us. With very little developer resources, we were able to
proceed very far with this redevelopment, earning some of the fruits
along the way, while continue to maintain and support the legacy suit.
As for platform choices, the old simulation was run mostly on
DEC Alpha workstations and servers, with a small simulations running on
Pentium Linux workstations. For a number of reasons, among them the
continuing decrease of DEC support quality (when you have to explain to
the "Unix specialist" basic fundamentals of Unix filesystem operation,
you know it's time you left) and the ever worsening price/performance
ratio, we are moving away from DEC towards Intel/Linux based
workstations. Our current Lisp platform is CMU CL on both Alpha/DU
and Intel/Linux and we are very much satisfied with it and the support
we got from the CMU CL community when we needed it. We are continuing
to survey commercial implementations for the Linux platform, which we
might want to use for more advanced features, like CLIM, SQL,
OO-Databases, etc.
[2] http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
--
Pierre Mai <pm...@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Christopher R. Barry wrote:
> "For some things" is the operative phrase here. Nearly all
> applications are comfortable with way under 4GB, and a lot of people
> are successfully implementing KR and OODB systems on Intel hardware
> with the 4GB limitation. And they are saving themselves a lot of money
> by going with hardware that is far more cost effective.
And how big are their KBs? How many assertions?And what exactly does "support from the hardware vendor"
really buy
> you over support from a software vendor? Digital Unix costs at the
> very least $1000 per license, and it isn't nearly as nice as Linux or
> Solaris except for the Digital FORTRAN compiler, if you're really into
> that kind of thing.
Look. You folks aren't paying attention. I am not claiming (and have never claimed) that the policy of
preferring or requiring hardware vendor support is a *good* one or a *reasonable* one. I have simply
claimed that in certain organizations it *is* a policy and that changing it is not simple and
straightforward -- in fact, that changing it would require the involvement of large parts of the
organization with various vested interests and simply is unreasonable to expect. I'm sorry, but anyone
who doesn't realize this simply lacks the requisite experience with such organizations. Sure, I could
spend my time going on a crusade about this. But little, if anything, would be accomplished. And my
time is better spent in doing other things for the company. $1000 per license is *nothing*. Just today
I had occasion to go looking for a Java native code compiler. So I wandered down the hall to the
applications development group that is near us and asked them. Well, their manager said, they use Visual
Age Professional. $2,700 per seat on the PC. "Golly", I said, "I had hoped to not spend anywhere near
that much (having just spent less than $300 for JBuilder)." The response? "Ah, what's $3,000? Just
order it." It's not about *cost*. It's about perceived reliability (which may in fact be a
misperception) and response.
-- Gary Merrill
-- Gary Merrill
Johan Kullstam wrote:
> the price of the hardware is sometimes not an issue. if a $50k
> machine does what you need it to do, then that may just be a good
> route to take. nevermind if you can cobble together 40 obsolete PCs
> into a beo-cluster for half the price. the whole project may be
> budgeted in multi-million dollar amount and the price of the computer
> you purchase is down in the noise.
>
Ah, someone with *experience* and *knowledge*. How refreshing.
> i don't think this is a logic or price-awareness type issue. `support
> from hardware vendor' means that his IT department is willing to
> service and administer his machine. i think that is _all_ there is to
> it. it's a label used by the IT dept to restrict the things they are
> going to support. you may think this is an idiotic policy, but it's
> _policy_ and anyone who has worked for a large company knows how far
> removed from reality policy can become.
Oh Johan. You've been there. These others are as kinder in the garten, eh?
Actually, this has been quite a culture shock to me. Quite an education. I've
been at this place for two years and am still learning. Very odd.
> some things are just not worth fighting for. i wouldn't care all that
> much whether i got digital unix or linux. since the policy is use dec
> unix, i'd just use it. big deal.
>
> gary has been more than reasonable. he seems to understand the issues
> involved. he even seems to like and respect linux. you are preaching
> to the choir but gary's company has a different religion.
Exactly. It is a religious (or ideological, or turf) issue. Even the strongest
technical arguments bounce off.
-- Gary Merrill
Pierre Mai wrote:
> Hmm, IIRC prior to this discussion on Linux, hardware and corporate
> live, Greg was talking about using Cyc to either implement KB
> applications on NT, or implementing those applications on DU/Alpha
> and making them web-accessible, and looking to Lisp as an alternative
> to Cyc.
My Cyc applications all run on on DU/Alpha. Three servers: (1) My personal
machine (1G memory, 18G disk; a "baby" Alpha); (2) The "old Alpha" we use for less
critical development and as a backup; and (3) the primary production server (4G
memory). I have not tested the NT version of Cyc but plan to do so in the next few
months. There have been difficulties in creating this version. I cannot go into
details.
LISP is not an alternative to Cyc. This would be like saying that C is an
alternative to Oracle. Cyc is in fact (mostly) implemented in LISP. Duplicating
anything like the Cyc environment and system from scratch in LISP would be a
*significant* effort. I'm afraid I am not at liberty to to into further details.
-- Gary Merrill
200 people, 55 million dollars of revenue in 1997. offices in 10 nations.
| I sense the wounded response of the true Linux fanatic.
I sense a moron who needs to see fanatics when he knows he's in the wrong.
| If it isn't Microsoft and it isn't supported by the *hardware* vendor,
| it doesn't count.
you keep switching definitions and modifying what you have said to keep
from being wrong. no wonder you think in terms of fanatics.
| In some corners of the software world, 512M RAM is a relatively small
| amount of memory. Your own assumptions and lack of genuine experience
| are showing.
your fear of being exposed has been showing much longer.
| Certainly not any further input from you.
I sense a pouting, prejudiced moron who knows he's wrong, but who needs
to keep in the right for self-esteem reasons, nothing else.
Wow! What a huge organization!! I concede it must have been difficult
dealing with the complex management and organizational structure of such
a company. 55 million dollars of revenue in 1997. Offices in 10 (!)
nations. Very impressive.
> | I sense the wounded response of the true Linux fanatic.
>
> I sense a moron who needs to see fanatics when he knows he's in the wrong.
I bow to your intellect. While knowing nothing about my company, its
organization, or my role or position in it, you have deduced that:
1. I am stupid (well, now in fact a moron).
2. I have some hidden agenda or fear that I am concealing
3. You could easily accomplish changes on a grand scale in my
company
I confess that I would be unable to make such inferences based on the
information available to you.
> I sense a pouting, prejudiced moron who knows he's wrong, but who needs
> to keep in the right for self-esteem reasons, nothing else.
Well, I am having quite an emotional reaction to this. But "pouting"
doesn't quite capture it. I think "hilarity" might come closer.
As someone who claims to work as a consultant, this is an interesting
approach to making one's abilities, skills, and attitudes known to a
wide audience of potential employers. I know that I am sufficiently
impressed with your inferential abilities and your interpersonal skills
that I can only regret that we currently do not have a project on which
these could be put to use. We'll try to stay in touch.
--
Gary H. Merrill, Ph.D. / Knowledge Engineering and Applications
Global Emerging Technologies Group / GlaxoWellcome Inc.
[Views and opinions expressed here are my own and not necessarily
those of GlaxoWellcome Inc.]
just what _is_ your problem, Gary? I'm trying to answer your hostile and
stupid questions, and all you do is prove you're an asshole.
| I concede it must have been difficult dealing with the complex management
| and organizational structure of such a company. 55 million dollars of
| revenue in 1997. Offices in 10 (!) nations. Very impressive.
why do you talk in terms of "impressive"? whoever wanted to impress?
and in particular, why the hell would anyone want to impress _you_? you
asked a simple question, you got a simple answer. look at your reaction.
if you believe that bureaucratic management problems are linear in the
size of the corporation, you must _really_ be lacking in intellectual
capacity. my experience is that some of the worst run small companies
that don't grow large because of their management style. (yes, these are
also companies most in need of consultants, and they are also the most
likely to give consultants hell and not pay them. it's vital to a small
consulting shop to know such people. based on the available evidence, I
retract my offer to help any company Gary H. Merrill might work for.)
| > | I sense the wounded response of the true Linux fanatic.
| >
| > I sense a moron who needs to see fanatics when he knows he's in the wrong.
|
| I bow to your intellect. While knowing nothing about my company, its
| organization, or my role or position in it, you have deduced that:
|
| 1. I am stupid (well, now in fact a moron).
that you're a moron has nothing to do with your company. I concluded
that you're a moron because you invoked "Linux fanatic" just because I
showed you how a Linux system was very, very inexpensive compared to the
stuff you said could not be beaten in price/performance. I beat your
price/performance by a large factor. after you had published your false
statement of unbeatability, you kept adding requirements that you never
told anyone about. you turned around and threw _new_ arguments against
the suggestion in order to invalidate it. I'm sure this is necessary on
a personal level for you to avoid looking like an idiot to said possessed
boss, but it really has nothing to do with the fact that Linux runs on
dirt cheap hardware. you got an answer to what you _said_, not what you
_thought_ at the time. keeping vital information secret so you can beat
up anyone who corrects you is simply not intelligent behavior. it's what
morons do. that you now have to pretend that you're a moron for some
_other_ reason where _you_ obviously couldn't be a moron, just goes to
show that I'm pretty accurate.
incidentally, the choice of Linux was not at all made out of fanaticism,
but out of a desire to waste as little money as possible because we had
to reimplement a system that some incompetent fools in a large consulting
company had charged a lot of money for, and we needed a lot of resources
to get it right. instead of wasting 60-70 grand on computers, and _then_
100 grand on software, we figured it would be better to re-use old iron
and get the software at a much lower price. and that we did.
getting Linux past the sometimes very conservative, yet sometimes very
liberal, management took quite some time and effort, precisely because of
the nature of Linux _support_, which you appeared to bring up as an
argument, but then it turned out to be the _hardware_ vendor who had to
sell it. well, I'm just shaking my head at your insecure and stupid
responses.
incidentally, reusing old iron made it possible to use Common Lisp, and
we've done _much_ more with the money saved on the hardware than merely
fixing a broken system. because the money could all be spent on new
software, we now have a system that enables the company to advance into
new markets. we could not have done this with the old system, provided
we had been able to survive at all with its dangerous instability. I'm
sure you'll scoff at this to, and find some more stupid things to attack.
I don't know what you need to prove or to whom, Gary H. Merrill, but I do
know that your need to prove _something_ completely overshadows whatever
technical merit there could have been to this discussion.
| Well, I am having quite an emotional reaction to this.
as has been quite obvious for some time. all I did was show you a much
cheaper system, and you went postal. I think I'm fully entitled to judge
you as a moron, Gary H. Merrill.
| As someone who claims to work as a consultant, this is an interesting
| approach to making one's abilities, skills, and attitudes known to a
| wide audience of potential employers.
well, you're the kind of client I could not afford to take on -- with
such a moron as you in there who would do nothing but sabotage anything
that threatens your personal space, and Lord knows that's _anything_, the
chances of success are miniscule. I'm sure you have done a great job in
promoting yourself, as well, but I actually thought it was more than just
bad netiquette to attack people's livelihood. you really are quite a
remarkable asshole. good luck with your Alpha. I sympathize with Compaq
who actually has to support you.
I infer that your company employs about 53,000 people and had 1997 sales
of over $13 billion. How am I doing?
> > I sense a pouting, prejudiced moron who knows he's wrong, but who needs
> > to keep in the right for self-esteem reasons, nothing else.
>
> Well, I am having quite an emotional reaction to this. But "pouting"
> doesn't quite capture it. I think "hilarity" might come closer.
>
> As someone who claims to work as a consultant, this is an interesting
> approach to making one's abilities, skills, and attitudes known to a
> wide audience of potential employers. I know that I am sufficiently
> impressed with your inferential abilities and your interpersonal skills
> that I can only regret that we currently do not have a project on which
> these could be put to use. We'll try to stay in touch.
Yes, I'll pass Mr. Naggum's name with appropriate comments
on to my HR department, too.
--
<J Q B>
Excuse me for interrupting, but since I don't see much lisp-related
information in this thread, I wonder if this is what philosophical arguments
are like?
c.
-------------------------------------------------------------------
"Real stupidity beats artificial intelligence every time."
M.Ridcully
Ciske Busch
Lehrstuhl fuer Kuenstliche Intelligenz und Angewandte Informatik
Universitaet Wuerzburg, Germany
http://ki-server.informatik.uni-wuerzburg.de/~ciske/
ICQ: #23765977
-------------------------------------------------------------------
Erik> getting Linux past the sometimes very conservative, yet sometimes very
Erik> liberal, management took quite some time and effort, precisely because of
Erik> the nature of Linux _support_, which you appeared to bring up as an
Erik> argument, but then it turned out to be the _hardware_ vendor who had to
Erik> sell it.
It occurs to me that one way to convince conservative 'suits' to buy into
Linux is to convince them to use Unix for all its virtues. Then convince them
that there's no problem to run Unix on a PC. Then given them the choice to
buy a 'commercial Unix-for-PCs' (SCO Unix, anyone?) OR installing Linux (which
is commercially supported anyway).
I haven't been following what's happening to SCO lately, but I heard they
were struggling against Linux' popularity. A conservative decision maker might
find the choice SCO <-> Linux easier than Win* <-> Linux. It also would
demonstrate that 'commercial' doesn't really mean much, even to opponents of
Linux.
Philip
--
erh ... the laziness you wield is the patience you yield, sort of thing %-/
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk | European Bioinformatics Institute
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53