Erik Naggum <e...@naggum.no> writes: > the U in GUILE is for Ubiquitous. there's going to be _many_ copies of > the GUILE heap on a system, one in each process, just like the C library. > in contrast, you're unlikely to exhibit the same behavior with a Common > Lisp system, which users load stuff into instead of running a new process > with its own heap all the time.
That doesn't have to be that bad. Obviously it depends on the application, but shared heaps are fairly doable. Either using the Emacs technique (purecopy + unexec) or just relying on copy-on-first-write VM, which I think most Unices can do now. Whether they'll do that is another matter of course.
Of course it's not the same as a single address space system, but it has its advantages as well. I'm much happier reading my mail in a completely different address space than my other Emacses live in for instance, so nothing I do in them can clobber mail. A shared-space system relies much more on really high-quality software, and even then you can end up dying horribly, and just having to reboot.
* Marco Antoniotti <marc...@copernico.parades.rm.cnr.it> | At this point in time, I believe that the vendors have some pieces of | software well developed, which they actually charge premiums for | distribution. This is a repackaging cost.
I wish these anti-vendor arguments could be a little more rational. of course they have some pieces of software well developed, like the entire Common Lisp system, the compiler, basically _everything_, right? the _purpose_ of charging for stuff that has paid for its development is to make it possible to respond to changes, continue to support customer needs, develop _new_ things, and/or to ensure financial independence for the founders or whatever. you don't appear to like this very much, but as soon as you come out saying that you don't believe in profits or in making money or in financial security or independence, business people _should_ turn deaf to your concerns and your suggested "solutions".
prices are set in the market based on what people want to give for what they get, and if this has worked well, it's really hard to argue against the success. believe it or not, what you see today actually _works_, all the misgivings to the contrary notwithstanding. people make money and make good money doing what they are doing. you'll have to entice them with _more_ money now or even higher future earnings at reasonably low risk if you want to change their behavior.
| I do not buy the argument that there are still development costs to | include CORBA support (or MK:DEFSYSTEM) in the standard distributions | (...) of Lispworks and MCL and ACL.
it doesn't really matter that _you_ don't buy it. while it may change marketing impressions and cause loss of goodwill if you ignore somebody else's reality and try to force losses on them through the moral equivalent of strikes and boycotts, the rational way to deal with this is to convince whoever footed the development bill of your views, and then you show them enough respect to listen when they answer your claims.
I'm in the business of selling software and my services to other people. I have done so for 15 years. in these years, I have donated thousands of hours of work to various causes that I believed in, some as a form of marketing, some as more important than personal gain, i.e., I wanted to create a better environment to work in rather than first reap the profits. over these years, what I have seen as the most astonishingly lacking in the demands and claims towards whoever should give people something is respect for their motivation. I can only surmise that the reason is that people don't ever stop to consider why _they_ are doing what they are doing, either. (and maybe that's good for them. :)
| Not doing so is short-sighted, as KMP has correctly pointed out with | very good arguments.
but who is he trying to convince? it doesn't matter that you agree with him, as long as _you_ are not the person making the decision to repackage or provide something for free. unlike what politicians believe, public sentiment doesn't actually and by itself change reality, it only changes how people will need to adapt to and change their experienced reality. if you deny them the right to affect their own reality, you engage in use of force, and you will therefore have to be treated as a hostile partner at best. a lot of people find such tactics to be uninspiring, to put it mildly. history is rife with people who stop doing whatever they were doing when somebody tried to force them to do stupid things, but usually, this happens to small businesses that just close shop when politicians try to force them into doing something that doesn't make sense to them.
it actually doesn't help people change their ways into something more constructive to tell them that what they are doing is short-sighted or stupid. the best you can achieve with that tactic is that they stop doing whatever they are doing and go away to regroup or do something else. if you have a specific new behavior in mind, you have to motivate it inside the core premises of their existing behavior. punishment does not work constructively, has never worked constructively, and will never work constructively. you punish to destroy, and the only hope is that people have something else to do that is more constructive, but if you punish, that's none of your business.
| Note also that at this point, giving away these freebies is *not* (or it | shouldn't be) a marketing gimmick. It is the only way to expand your | user base. Assuming that that is what you want to do.
this is what marketing is all about. you seriously underestimate marketing if you think about their decisions and tools as "gimmicks".
I suggest you guys make a solid business case for what you believe in, complete with market research and solid statistical groundwork, and I can promise you that you will be surprised by the reaction. if you don't, you're basically asking people to take your word for it and risk money on sentiments that are openly hostile to making money the way they do now.
note that I'm not saying that I disagree with any of your issues, but I'm _not_ whining about it on a newsgroup with a user-only "I need, so gimme" focus when I want a vendor to change his ways. I also think your anti- business whining could make my own efforts fail or make them harder, and since I get everything I want, anyway, the question "why should I help whiners who make things harder for me?" may soon require an answer.
Discussion subject changed to "Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))" by Erik Naggum
* Tim Bradshaw <t...@tfeb.org> | That doesn't have to be that bad. Obviously it depends on the | application, but shared heaps are fairly doable. Either using the Emacs | technique (purecopy + unexec) or just relying on copy-on-first-write VM, | which I think most Unices can do now. Whether they'll do that is another | matter of course.
first: that isn't how GUILE is intended to be used. second: I'm talking about actual memory consumed by the process for its _own_ data. data or code that cannot be shared. state information, whatever you want to call it. I haven't see anyone refer to this as anything other than "heap", and I find it odd that you think such a heap should be sharable.
Erik Naggum <e...@naggum.no> writes: > first: that isn't how GUILE is intended to be used. second: I'm talking > about actual memory consumed by the process for its _own_ data. data or > code that cannot be shared. state information, whatever you want to call > it. I haven't see anyone refer to this as anything other than "heap", > and I find it odd that you think such a heap should be sharable.
I think I was not clear enough. What I meant was that it's possible to share some static parts of the heap, either by lazy copying (the good way) or by the emacs trick. per-process data is obviously not sharable. However, at least in theory that per-process data should not be significantly more than the per-`application' data in a shared address-space system. Of course, in pratice it usually seems to be, for both good (finite page size means you end up copying a whole page if you only touch one thing on it) and bad (general bloat I guess, also no one ever actually seems to do the copy-on-write thing in practice) reasons.
As to how Guile is meant to be used, I don't know about that. I was just trying to argue that the Unix model doesn't have to be death in theory even though it may be in practice.
* Tim Bradshaw <t...@tfeb.org> | What I meant was that it's possible to share some static parts of the | heap, either by lazy copying (the good way) or by the emacs trick. | per-process data is obviously not sharable.
then this needs to be _added_ to GUILE.
| However, at least in theory that per-process data should not be | significantly more than the per-`application' data in a shared | address-space system.
this theory does not apply to GUILE. GUILE consumes a _lot_ of memory.
| As to how Guile is meant to be used, I don't know about that. I was just | trying to argue that the Unix model doesn't have to be death in theory | even though it may be in practice.
I think it's death in theory, but doesn't have to be in practice, the same way whole populations don't die out under dictatorships or under oppressive taxation -- i.e., the population survives because people do the _wrong_ thing according to its planners and designers.
it has been said that Microsoft's "operating systems" are nothing but a boot loader with a GUI. the process model in Unix is likewise geared towards a mode of operation that may cause it to be trivialized the same way, in not too distant a future, if it has not already happened.
think about it, the programming environment model in Unix is an imitation of the Lisp machine, and the way it is implemented is through processes and inter-process communication instead of function calls. functions in the Lisp heap are programs on disk in the Unix model. the optimizations that made Unix able to survive this incredible inefficiency are bad for Lisp, which would have done it a lot better had it been in control, but GUILE doesn't do it any better. GUILE combines the worst of both worlds, in an attempt to bring the best of one world to a world where it doesn't really belong. on top of this, it's Scheme, and it's expensive to run, there's so much wrong with it that nobody can use it without fixing some part of it. so, it's going to be a winner, but a real Lisp world would be so much better. however, a real Lisp world cannot win as long as GUILE is the image people have of a Lisp environment, just like Lisp has suffered tremendously from the Scheme people's insistence that Scheme as taught to college students is what they should expect from Lisp.
I'm not sure what needs to be done about this dismal situation, however.
Barry Margolin <bar...@bbnplanet.com> writes: > In general, the GNU project decided a couple of years ago that they wanted > to make Scheme the basis of their extension languages across the board, and > they developed the GUILE implementation to support this effort. Using it > for Emacs would be consistent with this plan.
"GNU will be able to run Unix programs, but will not be identical to Unix ... [GNU will have] perhaps eventually a Lisp-based window system through which several Lisp programs and ordinary Unix programs can share a screen. Both C and Lisp will be available as system programming languages."
In article <u71zj626l2....@ebi.ac.uk> , Philip Lijnzaad <lijnz...@ebi.ac.uk> wrote:
> On Tue, 02 Mar 1999 09:17:13 -0800, > "David" == David B Lamkins <dlamk...@teleport.com> writes:
> David> CORBA and FFI address two different problems. CORBA will not replace > David> FFI capability. What are you going to do when you want to call an > David> entry point in a library? Wrap the library so you can make a CORBA > David> call?
> yes, that would be the idea.
> David> The last time I looked (about a year and a half ago) a CORBA > David> method invocation cost a _lot_ more than a simple function call.
> yes, that's still the case. For many purposes, this would be good enough.
Ahh, the joys of selective quoting...
In article <u7k8x0nfxa....@ebi.ac.uk> you wrote: > If there is a CORBA language mapping, a foreign function interface > essentially becomes unnecessary. In fact, CORBA *is* the ultimate foreign > function interface.
The last time I used a commercial-quality CORBA implementation (about a year and a half ago), the latency it introduced was in the range of 10 to 15 milliseconds. Do you believe that this is an acceptable amount of overhead for calling a function outside of Lisp? Remember, you said that with CORBA, an FFI "becomes unnecessary." Should I take this to mean that, having CORBA, I should have no need of an FFI? Or did you have something else in mind when you wrote that?
>>> Likewise, you don't really *want* sockets if you've got CORBA.
> David> Maybe I've overlooked some context to this discussion that makes your > David> assertion seem less hyperbolic. But what about the existing protocols > David> that are already implemented via the facilities (ports, addresses, and > David> transports) provided by a simpler network layer? Will CORBA subsume > David> these, as well?
> not subsume, but use them (iiop is based on tcp/ip, so it uses IP addresses, > ports and tcp transport). Turns out many people prefer the higher abstraction > layer of CORBA over sockets, and I would argue that this is a Good > Thing. Based on numerous posts in comp.object.corba, people who have used > CORBA and sockets vastly prefer CORBA over sockets. This includes myself, > although I have no great experience with sockets.
They solve different problems, and are both useful in their own domains. CORBA can not completely subsume socket-like interfaces, which will remain useful as the layer upon which people build traditional protocols (HTTP, DNS, FTP, TELNET, DHCP, ...).
Discussion subject changed to "Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))" by Erik Naggum
* cba...@2xtreme.net (Christopher R. Barry) | IIRC, he wrote that in 1984.
at the time, incidentally, Common Lisp was his favorite Lisp. GNU CL (based on Kyoto Common Lisp, which I played with back in 1987) has turned out to be a serious flop, so maybe he thinks Scheme will fare better in the new language GUILE. I don't think it will. it has even less overall design than usual for overgrown Scheme implementations, and people add stuff to in the Unix and C spirit (each man his own conventions).
Tim Bradshaw <t...@tfeb.org> writes: > Kent M Pitman <pit...@world.std.com> writes:
> > Anyway, it's all about packaging. As far as I know, all of the > > systems we're talking about not having socket libraries do have > > foreign function call and that, I assume, implicitly supports > > sockets--so it's really just about the raw power. Just about the > > packaging.
> I think that's not really clear. Of course it depends what you mean > by `have soickets', but if you want things to work such that the Unix > (or whatever) file descriptors get suitably wrapped up in Lisp > streams, such that CLOSE & so on work right for them, and so that once > you've done the initial startup stuff you don't have to know if > there's a socket there or a file, then I think that is asking rather > more than foreign functions, unfortunately. And that *is* how sockets > look from the C point of view, so you want at least that.
Right, but in most modern Lisp implementations there is an FFI and there is "Gray Streams" (david gray's protocol for writing user-defined streams that do all the things you expect with streams). And that's enough to for users to write what you want.
> I only realised this when I was talking to someone the other day and > rashly said that sockets are obviously not hard in CL, when what I > meant was they're not hard to do in a portable way if you already have > some support for them...
Yeah, the underlying support isn't portable. But it is mostly universally available, I think, just in slightly different form in each implementation.
> I only realised this when I was talking to someone the other day and > rashly said that sockets are obviously not hard in CL, when what I > meant was they're not hard to do in a portable way if you already have > some support for them...
> Of course a CLOSified stream system would make this much easier (:-).
Yeah, that's the real underlying problem, that CommonLisp is not really an object-oriented language, but has CLOS tacked on the side... And just to add fuel to the fire, notice that ACL uses low-level hacks that don't really use CLOS for their streams because CLOS was too slow...
Without stream objects and methods, sockets are just another hacked C interface, which has been implemented upteen times by upteen people in upteen ways. I have my own too for the web server, which doesn't even use a Stream API to avoid the overhead.
>>>>> "tb" == Tim Bradshaw <t...@tfeb.org> writes:
tb> What I meant was that it's possible to share some static parts tb> of the heap, either by lazy copying (the good way) or by the tb> emacs trick.
What implementations are able to do this? I assume that this implies storing a part of the heap in text pages of the executable, which seems incompatible with the was most Lisp systems are implemented (a stub program loading an image file into memory). Scheme 48 has a static heap linker to address this problem.
I would appreciate any pointers to documentation on this subject.
Actually, a technical correction, Allegro CLIP did not use FUTURES, they just claimed they did, but they didn't know what a FUTURE was, just that people seemed to want it so they said they had it. In fact, when I went to see the Franz CLIP demo, I pointed out the reason they could only get a 2-times speedup in their example was precisely becuase they didn't have futures. Oh well, maybe that had something to do with nobody buying it, or perhaps that it only ran on a big-dollar Sequent, or it was incompatible with the "normal" lisp?
As a related business model comment, only doing what your customers pay you to do is a good way to stay in business doing what your customers will pay you to do. That's a different business than selling software.
In particular, as with Allegro CLIP, Franz did what Sequent paid them to do, deliver a multiprocessor lisp. No matter if it was actually useful to anyone or attracted more customers, it was still a good short-term business deal that made a profit.
Finally, I don't mean to beat up on my friend Duane. (actually I don't mean to beat up on anyone, but Duane in particular) Duane is the reason we have ACL under Linux -- all my arguments had little effect on Franz managment, it was Duane who "just did it" on his own time.. Like I imagine he will do for multiprocessing. Thanks Duane!
> > Correct, but it turns out that many of the lisp customers that would > > otherwise foot the bill for such a project are using our product in > > just that way: bringing many C, C++, and Java pieces together with > > the lisp being the "glue" that puts them together. When you add to > > that the fact that many of the things that can be done with multiple > > processors can also fairly easily be done with multiple processes > > (separate and autonomous), communicating via sockets or other ipc > > styles, and even explicitly allocated shared memory, the extra > > expense of trying to make things work within a single process simply > > doesn't make business sense to either those customers or us (I know > > some will disagree, but we have to focus on our entire customer base, > > and tend to cater to those that pay us more money :-) So we do what > > we can on our own nickel, edging things closer to what we think people > > want. Are we there yet? Of course not. Are we moving toward the > > goal? Yes.
> I take your point about not being able to afford to do it, although I > do think it's very sad.
> > In my opinion, my Company's pain stems from the experiences we had with > > our multiprocessor product: Allegro CLIP. It ran on a sequent, used > > "futures", and a hybrid deep-binding approach that implemented bindstacks > > with hash-tables, and ran about 20% slower as compared to an equivalent > > single-processor lisp. I do believe that we could have taken care of > > the speed problem, if there had been any corporate will to do so, but > > our biggest problem was with sales - very few bought the lisp.
> Do you mean 20% slower on a uniprocessor, or 20% slower even on a > multiprocessor? Scaling behaviour should be a good deal more > important than performance on a single CPU -- if you can get > near-linear speedup for some reasonably pllizable problem, then you're > ahead on a 2cpu box, already. OTOH I don't know what `futures' implies, > but if it's a clever technique for making multiprocessor systems look > easy to program I suspect it's doomed. I've seen too many systems that > claimed to make parallel programming easy lying forgotten in the corners > of machine rooms...
> > There's no shame in writing C code. In a perfect world, every problem > > would be solvable with a lisp-only solution. And some are able to > > work their solutions entirely in lisp. However, the majority of our > > customers settle on a hybrid effort, and this guides us as to where > > we go next; it is no accident that we added CORBA and OLE products > > last year, and are still working strongly on connectivity.
> Again, I can see your commercial point, though I think it is a sad > one. Half the the reason I like programming in Lisp is because it's a > wonderful language to think in, compared with C where I spend most of > my life fighting the language. If I was going to write programs on a > parallel machine, I'm already going to be fighting the fact that this > is a very hard thing to do: I could do without having to fight C as > well.
On Tue, 23 Feb 1999 14:03:07 GMT, Kent M Pitman <pit...@world.std.com> wrote:
>Anyway, I'm interested in doing a reality check on my present perceptions of >how Lisp is presently hampered in acceptance.
>What barriers have people recently seen first-hand to Lisp's acceptance in >their own working experience at their present or some recent organization?
I tried to get people at my former employer interested when we bought a copy of LWW, since the company was originally a lisp based one (they switched to Smalltalk when the lisp machines disappeared and now do C++ and Java in addition to ST), and many of the old-timers are still there. But from what I could tell, most were quite indifferent, if polite.
I don't have much experience with non-lisp languages (I programmed in Turbo Pascal for one year when I was a student and a little in Visual Basic) and I am simply not able to explain to anyone why lisp is significantly better than say Java or Smalltalk. From what I read on this newsgroup, it seems clear that lisp is enough better to be worth examining for a serious programming shop (but if Smalltalk had multiple inheritance, what would the difference between the power of the two languages be?). However, the lisp environments must be about equally pleasant to use as the competition, and that means a pretty IDE and a source code stepper. The lack of these things is a serious barrier, I think.
I don't think the parentheses and prefix syntax is an issue. Maybe on the contrary: it touches some kind of "real programmers can read unreadable code" attitude (and it only takes about 2 weeks to get used to anyway).
On 02 Mar 1999 21:51:04 +0000, Erik Naggum <e...@naggum.no> wrote:
> dealing with networking problems is so complex that an application really > cannot afford to trust a pre-packaged solution that does not give very > good access to the error conditions. I've spent hundreds of hours giving > Allegro CL's socket package and my protocol on top of it graceful failure > modes. it's really hard work. judging from what I see from people who
It would be very interesting to know how you deal with such problems. Do you map the existing failure modes provided by ACL's socket package to some sort of higher level error reporting/recovery layer? Or maybe you extend the socket library to provide more--or possibly more useful--failure modes reported by lower-level software? Or, of course, something completely different?
> Recent (1999-03-03 11:20:00) CST updates: > o The code compiles out of the box into the CL-USER package. > o There is a CMU CL port. > o There is an explicit notice that it is in the public domain.
> --David Gadbois
Looks good. I notice the elimination of run and arrest reasons quantum and priority, and other "internal" type stuff. Just not supported by all lisps, or is this a judgement on their value to the user?
Would it makes sense to collapse PROCESS-WAIT and PROCESS-WAIT-WITH-TIMEOUT into one method, where timeout of nil means no timeout.
Also, I think it's useful to have process-wait return the non-nil value of the wait function, or nil if it timed out.
A fairly common need is to poll multiple streams, i.e. select. One could write this as (process-wait (function (streams) (loop for stream in streams do (if (listen stream) then (return stream) )) (list stream1 stream2 ..))
As a general style question, does it make sense to put this stuff in another package? One often sees the naming convention of <type>-<method> for a function, and it ALSO gets in another package, so you'd get process:process-wait. In my view, why isn't the method called WAIT, in the process package, such that
(class process () ...)
(method wait ((p process) timeout function [args]*) ...)
One can just call process:wait or decide to use just wait by importing process:wait.
I agree completely that its the error handling which is the hard problem, and is HIGHLY unportable to both OS and Lisp implementation. Just yesterday I debugged a ACL socket problem that returned error code "22", which was in fact, running out of available sockets. And I also deal with error -14 when I/O into memory buffer areas that don't exist yet (because they haven't been paged in from the DB..) The problem is usually because that's all the OS gives you.
This is a great example of the value of a Lisp-based operating system as opposed to running on top of whatever C-based garbage is underneath...
> On 02 Mar 1999 21:51:04 +0000, Erik Naggum <e...@naggum.no> wrote:
> > dealing with networking problems is so complex that an application really > > cannot afford to trust a pre-packaged solution that does not give very > > good access to the error conditions. I've spent hundreds of hours giving > > Allegro CL's socket package and my protocol on top of it graceful failure > > modes. it's really hard work. judging from what I see from people who
> It would be very interesting to know how you deal with such problems. Do > you map the existing failure modes provided by ACL's socket package to some > sort of higher level error reporting/recovery layer? Or maybe you extend > the socket library to provide more--or possibly more useful--failure modes > reported by lower-level software? Or, of course, something completely > different?
Kelly Murray <k...@IntelliMarket.Com> writes: > I notice the elimination of run and arrest reasons quantum and > priority, and other "internal" type stuff. Just not supported by > all lisps, or is this a judgement on their value to the user?
Not supported. Those features depend a lot on the scheduler implementation.
> Would it makes sense to collapse PROCESS-WAIT and > PROCESS-WAIT-WITH-TIMEOUT into one method, where timeout of nil > means no timeout.
If I were doing it over again, I'd just have PROCESS-WAIT and SET-TIMEOUT.
> As a general style question, does it make sense to put this stuff > in another package?
Sure. Once the Lisp "substandards" stuff gets organized, it will make sense to have a standard place for all this to live.
Speaking of the substandards, is there any action on that front? Cycorp will put the rest of its porting layer (locking, sockets, and lexical environment access) in the public domain, though I'll have to spiff it up a bit first. Does anyone have a defsystem or foreign function interface to donate?
> One often sees the naming convention of <type>-<method> for a > function, and it ALSO gets in another package, so you'd get > process:process-wait. In my view, why isn't the method called WAIT, > in the process package,
Partly historical and partly so as to avoid naming conflicts when a package wants to import multiple symbols named WAIT from different packages.
I'll be happy to merge in any additions that folks want to write.
Discussion subject changed to "Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))" by R. Matthew Emerson
> think about it, the programming environment model in Unix is an imitation > of the Lisp machine, and the way it is implemented is through processes > and inter-process communication instead of function calls. functions in > the Lisp heap are programs on disk in the Unix model.
This reminds me of some things that I wonder about from time to time, namely:
How does a lisp machine deal with multiple simultaneous users, and how does it protect users' programs from interfering with one another? Are there permissions associated with lisp objects? Packages? On files in the file system?
Can one telnet in to a lisp machine, start up a lisp world and display it on one's desktop machine?
It seems to me that Lisp is about being able to have control of and access to everything, and is distinctly non-fascist. For example, just a little while ago, Kent Pitman wrote about extending the OS on his lispm to talk to his NT machine. So, thinking about a multi-user lisp system with all sorts of permissions and restrictions causes cognitive dissonance.
With a unix/plan9 process model, it is straightforward to deal with multiple users. Or maybe I just think it's straightforward, since I've had very little experience with anything else.
>> think about it, the programming environment model in Unix is an imitation >> of the Lisp machine, and the way it is implemented is through processes >> and inter-process communication instead of function calls. functions in >> the Lisp heap are programs on disk in the Unix model.
> This reminds me of some things that I wonder about from time to time, > namely:
> How does a lisp machine deal with multiple simultaneous users, and how > does it protect users' programs from interfering with one another? > Are there permissions associated with lisp objects? Packages? On > files in the file system?
On the LispM's of old, there was only one user logged in at a time.
> Can one telnet in to a lisp machine, start up a lisp world and display > it on one's desktop machine?
You can on the Symbolics LispMs, although only one of you will be logged in.
> It seems to me that Lisp is about being able to have control of and > access to everything, and is distinctly non-fascist. For example, > just a little while ago, Kent Pitman wrote about extending the OS on > his lispm to talk to his NT machine. So, thinking about a multi-user > lisp system with all sorts of permissions and restrictions causes > cognitive dissonance.
> With a unix/plan9 process model, it is straightforward to deal with > multiple users. Or maybe I just think it's straightforward, since > I've had very little experience with anything else.
> -matt
Part of the problem is this notion that one size fits all. That what you want from a server machine is the same as what you want on a desktop. The Lispm's philosophy was that there should be only one user of a "desktop" machine, namely the person who's desk it was sitting on. You don't need all of the multiuser protection stuff built in when there's only one user. As a result, they were able to make a different set of trade-offs than the Unix guys who's aim was to provide multiuser capabilities to expensive machines. LispM were meant to be cheap enough that everyone could have their own.
My hunch is that the vast majority of Unix machines only have one real user logged into them. So why pay for the protection you don't need nor necessarily want? Unix suffers from the same attitude that Windows does, namely that there can only be one OS and everything from supercomputers to toasters HAS to run it. Do you really think it's necessary to check my permissions before you'll let turn down the toaster?
mike...@mikemac.com (Mike McDonald) writes: > My hunch is that the vast majority of Unix machines only have one real > user logged into them. So why pay for the protection you don't need > nor necessarily want? Unix suffers from the same attitude that > Windows does, namely that there can only be one OS and everything > from supercomputers to toasters HAS to run it. Do you really think > it's necessary to check my permissions before you'll let turn down > the toaster?
One physical user... Yes. But then there are many other things imagineable with the multi-user capabilities. Running low priority jobs over a long period of time without interfering with the person at the desktop... Not accidentally trashing some important system files, because the admin is another user (even though that other user may in fact turn out to be you)...
I don't think UNIX really suffers from that problem, at least not to the extent you suggest. It is possible to adjust various parameters, such as buffer sizes, VM size, process switch granularity, etc. so that you can adjust to a variety of environments. Of course, there are some things that are simply not needed on a unix box meant for a single user. There are many annoying side-effects that protection has, such as the need to copy data from a user buffer to a network or print buffer before it can go out to the appropriate device. I believe there are quite a few efforts underway that get around some of these problems.
The advantage that Unix has had all along is that the one-size-fits-all model allows for simplicity of implementation, and therefore spread of the paradigm. Then they can take their own time slowly improving upon what they have. This point is of course not new. We can put down worse-is-better as much as we like, but IMHO we will lose unless we learn from it.
On Wed, 03 Mar 1999 08:52:34 -0800, "David" == David B Lamkins <dlamk...@teleport.com> writes:
David> In article <u71zj626l2....@ebi.ac.uk> , Philip Lijnzaad <lijnz...@ebi.ac.uk>
David> wrote: >> On Tue, 02 Mar 1999 09:17:13 -0800, >> "David" == David B Lamkins <dlamk...@teleport.com> writes:
David> CORBA and FFI address two different problems. CORBA will not replace David> FFI capability. What are you going to do when you want to call an David> entry point in a library? Wrap the library so you can make a CORBA David> call?
>> yes, that would be the idea.
David> The last time I looked (about a year and a half ago) a CORBA David> method invocation cost a _lot_ more than a simple function call.
>> yes, that's still the case. For many purposes, this would be good enough.
David> Ahh, the joys of selective quoting...
ehr ... this was lifted out of the following paragraph:
David> CORBA and FFI address two different problems. CORBA will not replace FFI David> capability. What are you going to do when you want to call an entry point David> in a library? Wrap the library so you can make a CORBA call? The last time David> I looked (about a year and a half ago) a CORBA method invocation cost a David> method invocation cost a _lot_ more than a simple function call.
Is this quoting selectively ? Moreover, I am basically agreeing with you.
David> In article <u7k8x0nfxa....@ebi.ac.uk> you wrote:
>> If there is a CORBA language mapping, a foreign function interface >> essentially becomes unnecessary. In fact, CORBA *is* the ultimate foreign >> function interface.
David> The last time I used a commercial-quality CORBA implementation (about a year David> and a half ago), the latency it introduced was in the range of 10 to 15 David> milliseconds.
yes that is a lot, and depends on primarily the ORB. I don't want to go into this debate; suffice it to say that some ORBS (notably Orbix) are notoriously slow.
David> Do you believe that this is an acceptable amount of overhead David> for calling a function outside of Lisp?
I would imagine that in some cases this is acceptable, and it also depends on how long the foreign call itselfs typically takes to return. What is the latency of your average cgi-bin perl script? They may not be routinely called from lisp programs, but I've seen people do stranger things. Of course, in practice, you do a foreign call to do some number crunching or so, and for that I agree CORBA is less well suited.
However, an ORB can be clever, and could put different clients and servers in one process, resulting in vastly improved throughput. Current orbs only do this within one language, but I don't think it is a priori impossible to co-locate, in one process, clients and servers in different languages. Internally, an FFI would be needed; externally, everything would be specified in IDL. But this scenario is mere phantasy.
David> Remember, you said that with CORBA, David> an FFI "becomes unnecessary."
the real quote is "essentially unnecessary."
David> Should I take this to mean that, having CORBA, I should have no need David> of an FFI?
ehrm, no, that is too strong. But I think CORBA can address some of the needs traditionally addressed by FFI's. In one fell swoop, it provides a mechanism for interoperability with Java, C++ and an increasing number of less common languages (of course provided the ORB works, is fast, does your language, etc. etc.) This is something that I have not seen in FFI's. Even if the current CORBA pratice is far from ideal, I think the framework is right. The fact that things are meticulously (if imperfectly) standardized isn't bad either.
To get to the bottom of this: I think that an FFI would only really be crucial where speed matters. But I'd love to hear counter arguments (other than that it might be termed a tautology :-).
David> They solve different problems, and are both useful in their own David> domains. CORBA can not completely subsume socket-like interfaces, David> which will remain useful as the layer upon which people build David> traditional protocols (HTTP, DNS, FTP, TELNET, DHCP, ...).
Agreed.
Philip
-- No electrons were harmed during the composition or transfer of this message --------------------------------------------------------------------------- -- Philip Lijnzaad, lijnz...@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
Discussion subject changed to "Emacs and CL (was Re: More LispOS talk (was Re: Lisp subverts the world (was Re: ints vs fixnums (was Re: Java ... (was Re: ... (was Re: ...))))))" by Christopher R. Barry
mike...@mikemac.com (Mike McDonald) writes: > LispM were meant to be cheap enough that everyone could have their > own.
For only $100,000 to $150,000???
> My hunch is that the vast majority of Unix machines only have one > real user logged into them. So why pay for the protection you don't > need nor necessarily want?
Since Lisp programming doesn't expose you to memory addresses I guess it's not as nessecary, but having to reboot Windows or MacOS or DOS everytime you you accidentally dereference the wrong pointer can be a real pain. If you want to do everything in C then the Unix protection model is the only sane way. Unix's relative stability is strong testament to this.
> Unix suffers from the same attitude that Windows does, namely that > there can only be one OS and everything from supercomputers to > toasters HAS to run it.
What does Windows run on other than Intel and a backwards NT Alpha port? I think portability and scalability are very important and Lisp need not make excuses here. I consider Lisp in one form or another as a one-size-fits-all solution.
To counter the fact that you can't do gzip or JPEG and other things fast in Lisp I think it would be nice to have some functions and types that give you C's hardware control when you need it instead of FFIing to C.
But then again, if such a feature were made available it would probably be abused to death and not used in the spirit it was originally intended so maybe that's not such a hot idea after all. What did Symbolics do about gzip? Do they have low-level Lisp functions for Genera that let you control memory when you want?
> Do you really think it's necessary to check my permissions before > you'll let turn down the toaster?
You say that a vast majority of Unix machines only have one real user logged in to them and I say that a vast majority of them are also on a network, even if only via PPP sometimes to the internet. Unix is the only OS that gets it right in this kind of environment.
On Windows 95 you can do whatever you want to other machines on the network just by typing crap into the "run" dialogue box. How many virus protection programs are there for sale for Windows, DOS and MacOS? How many for Unix? Come on.
Putting up with the crap involved in properly administrating my Linux box has been far less frustrating then the crap Windows gave me. Especially in the case of Debian, which gives you hassle-free way to worrylessly upgrade everything on your disk without any "foo.bar.so.6 not found" errors and the like.
