In article <36BA37F3.9E583...@mindspring.com>, gmerr...@mindspring.com wrote: > > 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.
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).
In article <36BC8AB2.3853...@mindspring.com>, gmerr...@mindspring.com wrote: > 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.)
> 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).
* "Gary H. Merrill" <gmerr...@mindspring.com> | 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.
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.
>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?
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.
Paul Meurer wrote: > On Sat, 06 Feb 1999 13:32:18 -0500, "Gary H. Merrill" > <gmerr...@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 H. Merrill" <gmerr...@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.
| 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" <gmerr...@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 H. Merrill" <gmerr...@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.
> (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.]
* "Gary H. Merrill" <gmerr...@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.
| 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" <gmerr...@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.
Christopher R. Barry wrote: > "Gary H. Merrill" <gmerr...@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 H. Merrill" <gmerr...@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. ------
> "Gary H. Merrill" <gmerr...@mindspring.com> writes:
> > Christopher R. Barry wrote:
> > > "Gary H. Merrill" <gmerr...@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.
In article <36C0DA9C.967AE...@mindspring.com>, gmerr...@mindspring.com wrote: > 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.
g...@jpl.nasa.gov (Erann Gat) writes: > In article <36C0DA9C.967AE...@mindspring.com>, gmerr...@mindspring.com wrote:
> > 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.
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.
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.
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.
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 H. Merrill" <gmerr...@mindspring.com> | And just how large was this company in which you succeeded and what was | its organization?
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.
> * "Gary H. Merrill" <gmerr...@mindspring.com> > | And just how large was this company in which you succeeded and what was > | its organization?
> 200 people, 55 million dollars of revenue in 1997. offices in 10 nations.
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.]
