why is there not a lisp pc?
gavino
with power of lisp could be quite grand..
jos...@lisp.de
> why is there not a lisp pc for under $300?
>
> with power of lisp could be quite grand..
\|||/
(o o)
,~~~ooO~~(_)~~~~~~~~~,
| Please |
| don't feed the |
| TROLL! |
'~~~~~~~~~~~~~~ooO~~~'
|__|__|
|| ||
ooO Ooo
Alan Mackenzie
> why is there not a lisp pc for under $300?
There once were lisp machines, in the 1980s. Look up "lisp machine" in
wikipedia for some interesting history.
> with power of lisp could be quite grand..
Indeed it could. But the demand for such a powerful machine is
insufficient to pay enough for its development.
--
Alan Mackenzie (Nuremberg, Germany).
Tamas K Papp
> gavino <gavc...@gmail.com> wrote:
>> why is there not a lisp pc for under $300?
>
> There once were lisp machines, in the 1980s. Look up "lisp machine" in
> wikipedia for some interesting history.
I have a Dell laptop. It runs Lisp. That makes it a Lisp PC.
> Indeed it could. But the demand for such a powerful machine is
> insufficient to pay enough for its development.
I wish the garden center sold soil specifically for yellow tulips. I
just can't believe that "Miracle-Gro for Flowers" is good enough for
my purposes. I am sure I could do better with an expensive
special-purpose formula instead of the mass-produced general one. And
they could also carry special soil for pink azaleas, red geraniums,
etc.
Tamas
Victor
> On Tue, 29 Dec 2009 09:03:00 +0000, Alan Mackenzie wrote:
>
>> gavino <gavc...@gmail.com> wrote:
>>> why is there not a lisp pc for under $300?
>>
>> There once were lisp machines, in the 1980s. Look up "lisp machine" in
>> wikipedia for some interesting history.
>
> I have a Dell laptop. It runs Lisp. That makes it a Lisp PC.
Tamas, AFAIU Lisp Machines were not only merely able to run Lisp
compiler/interpreter but substantial parts of the operating system
and related system software was written in Lisp, creating
an environment for convenient development in Lisp.
And that's if we put specific details in their hardware design
to improve Lisp interpreter performance.
Modern personal computers are able to run Lisp code, but PCs
are not truly "Lisp Machines" as far as I see.
Victor
Espen Vestre
> Modern personal computers are able to run Lisp code, but PCs
> are not truly "Lisp Machines" as far as I see.
Modern mobile phones aren't phones either, the "Phone" in the iPhone is
just another unix process...
--
(espen)
Captain Obvious
??>> are not truly "Lisp Machines" as far as I see.
EV> Modern mobile phones aren't phones either, the "Phone" in the iPhone is
EV> just another unix process...
As far as I know, smartphones do not work that way -- there is a dedicated
processor which handles telephony, and main processor handles only
applications.
Of course there is some form of communication between these processors,
but as telephony is essentially a real time stuff, it is not a good idea for
it
to depend on application processor.
Captain Obvious
??>> are not truly "Lisp Machines" as far as I see.
EV> Modern mobile phones aren't phones either, the "Phone" in the iPhone is
EV> just another unix process...
Particularly for iPhone you can see components here:
There is "Application processor" ARM core from Samsung,
and "Baseband" -- Dual ARM826 and ARM7Core.
Espen Vestre
> EV> Modern mobile phones aren't phones either, the "Phone" in the iPhone is
> EV> just another unix process...
>
> As far as I know, smartphones do not work that way -- there is a dedicated
> processor which handles telephony, and main processor handles only
> applications.
Sure, but you can't make a telephone call without that unix process,
since it handles the interface to the mobile phone hardware.
--
(espen)
Tamas K Papp
> On Tue, 29 Dec 2009 12:31:14 +0200, Tamas K Papp <tkp...@gmail.com>
> wrote:
>
>> On Tue, 29 Dec 2009 09:03:00 +0000, Alan Mackenzie wrote:
>>
>>> gavino <gavc...@gmail.com> wrote:
>>>> why is there not a lisp pc for under $300?
>>>
>>> There once were lisp machines, in the 1980s. Look up "lisp machine"
>>> in wikipedia for some interesting history.
>>
>> I have a Dell laptop. It runs Lisp. That makes it a Lisp PC.
>
> Tamas, AFAIU Lisp Machines were not only merely able to run Lisp
> compiler/interpreter but substantial parts of the operating system and
> related system software was written in Lisp, creating an environment for
> convenient development in Lisp.
Yes, I know what LM were. But I fail to see the big benefit. Of
course it is "nice" if the OS is written in the same language as an
application, but as long as they can communicate, it does not matter
much. Convenience surely does not depend on that. Would my
SBCL+SLIME+Emacs environment be "more convenient" if it was ticking on
top of a LM? Why would I care?
> And that's if we put specific details in their hardware design to
> improve Lisp interpreter performance.
Or---and I know that this sounds crazy---you can just take advantage
of off-the-shelf hardware, especially the low price and ever improving
performance, and maybe compile (maybe JIT) your code, so that you don't
need a hardware interpreter. Just a wild idea.
> Modern personal computers are able to run Lisp code, but PCs are not
> truly "Lisp Machines" as far as I see.
I think that the distinction is academic. Modern CPUs have so many
layers anyway that I don't really care if the topmost layer exposed to
the software is some variant of Lisp or not. If we had a "Lisp machine"
today, it would most likely be a "microcode machine" that implements
some Lisp. And then we would have gavino trolling about how it is not
a LM.
I have noticed that some people are nostalgic about Lisp Machines, and
I appreciate the sentiment, but to me they look like nothing but a
glorious dead end. And incidentally, the failure of the Lisp Machine
market provided another opportunity for people to write Lisp off.
Cheers,
Tamas
Lars Rune Nøstdal
> why is there not a lisp pc for under $300?
>
> with power of lisp could be quite grand..
There are several, but the setup is as follows:
* X86(-64) hardware
* Linux kernel + libpthread + libc (ASM/C)
* SBCL (Lisp)
* Emacs/Slime (ELisp)
It matters not that the kernel is written in C; it deals with the
boring, tedious crap. The important and interesting things (Lisp
libraries and development environment) are available in a "Lisp
fashion" or style anyway.
Pascal J. Bourguignon
> On Tue, 29 Dec 2009 12:48:22 +0200, Victor wrote:
>
>> On Tue, 29 Dec 2009 12:31:14 +0200, Tamas K Papp <tkp...@gmail.com>
>> wrote:
>>
>>> On Tue, 29 Dec 2009 09:03:00 +0000, Alan Mackenzie wrote:
>>>
>>>> gavino <gavc...@gmail.com> wrote:
>>>>> why is there not a lisp pc for under $300?
>>>>
>>>> There once were lisp machines, in the 1980s. Look up "lisp machine"
>>>> in wikipedia for some interesting history.
>>>
>>> I have a Dell laptop. It runs Lisp. That makes it a Lisp PC.
>>
>> Tamas, AFAIU Lisp Machines were not only merely able to run Lisp
>> compiler/interpreter but substantial parts of the operating system and
>> related system software was written in Lisp, creating an environment for
>> convenient development in Lisp.
>
> Yes, I know what LM were. But I fail to see the big benefit. Of
> course it is "nice" if the OS is written in the same language as an
> application, but as long as they can communicate, it does not matter
> much. Convenience surely does not depend on that. Would my
> SBCL+SLIME+Emacs environment be "more convenient" if it was ticking on
> top of a LM? Why would I care?
Because you are a programmer. It's not the ABI that matter, but the
API, and the possibility you'd have to modify it or its
implementation. You could change your OS, even on the fly,
programming in Lisp.
>> And that's if we put specific details in their hardware design to
>> improve Lisp interpreter performance.
>
> Or---and I know that this sounds crazy---you can just take advantage
> of off-the-shelf hardware, especially the low price and ever improving
> performance, and maybe compile (maybe JIT) your code, so that you don't
> need a hardware interpreter. Just a wild idea.
>
>> Modern personal computers are able to run Lisp code, but PCs are not
>> truly "Lisp Machines" as far as I see.
>
> I think that the distinction is academic. Modern CPUs have so many
> layers anyway that I don't really care if the topmost layer exposed to
> the software is some variant of Lisp or not. If we had a "Lisp machine"
> today, it would most likely be a "microcode machine" that implements
> some Lisp. And then we would have gavino trolling about how it is not
> a LM.
Indeed. Just take a normal PC, and write a Lisp VM kernel. Boot it,
and voil�, Instant Lisp Machine!
> I have noticed that some people are nostalgic about Lisp Machines, and
> I appreciate the sentiment, but to me they look like nothing but a
> glorious dead end. And incidentally, the failure of the Lisp Machine
> market provided another opportunity for people to write Lisp off.
One advantage of a Lisp Machine is that programs written in C would
run slower on it than programs written in Lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Alan Mackenzie
> On Tue, 29 Dec 2009 12:48:22 +0200, Victor wrote:
>> On Tue, 29 Dec 2009 12:31:14 +0200, Tamas K Papp <tkp...@gmail.com>
>> wrote:
>>> On Tue, 29 Dec 2009 09:03:00 +0000, Alan Mackenzie wrote:
>>>> gavino <gavc...@gmail.com> wrote:
>>>>> why is there not a lisp pc for under $300?
>>>> There once were lisp machines, in the 1980s. Look up "lisp machine"
>>>> in wikipedia for some interesting history.
>>> I have a Dell laptop. It runs Lisp. That makes it a Lisp PC.
>> Tamas, AFAIU Lisp Machines were not only merely able to run Lisp
>> compiler/interpreter but substantial parts of the operating system and
>> related system software was written in Lisp, creating an environment for
>> convenient development in Lisp.
> Yes, I know what LM were. But I fail to see the big benefit.
You've presumably never used (or played on) one.
> Of course it is "nice" if the OS is written in the same language as an
> application, but as long as they can communicate, it does not matter
> much.
Not only was the Lisp Machine's OS written in lisp, its (microcoded)
object code embodied lisp. For example, the "call" instruction just
pushed the address of a function onto a stack, the actual call being done
after the last argument has been evaluated (the opcode for this
evaluation itself containing a "last operand" field).
> Convenience surely does not depend on that. Would my SBCL+SLIME+Emacs
> environment be "more convenient" if it was ticking on top of a LM?
Yes. Perhaps not for any single great feature, more lots of little
things which are annoyances on Windows or GNU simply just worked on a LM.
Think of doing everything in Emacs, only more so.
> Why would I care?
>> And that's if we put specific details in their hardware design to
>> improve Lisp interpreter performance.
More Lisp object code, though there was of course an interpreter too.
> Or---and I know that this sounds crazy---you can just take advantage
> of off-the-shelf hardware, especially the low price and ever improving
> performance, and maybe compile (maybe JIT) your code, so that you don't
> need a hardware interpreter. Just a wild idea.
>> Modern personal computers are able to run Lisp code, but PCs are not
>> truly "Lisp Machines" as far as I see.
> I think that the distinction is academic. Modern CPUs have so many
> layers anyway that I don't really care if the topmost layer exposed to
> the software is some variant of Lisp or not. If we had a "Lisp machine"
> today, it would most likely be a "microcode machine" that implements
> some Lisp. And then we would have gavino trolling about how it is not
> a LM.
> I have noticed that some people are nostalgic about Lisp Machines, and
> I appreciate the sentiment, but to me they look like nothing but a
> glorious dead end. And incidentally, the failure of the Lisp Machine
> market provided another opportunity for people to write Lisp off.
Yes indeed. The Intel PC (language: C) won over the Lisp Machine
(language: lisp). My own opinion (for what it's worth) is that it takes
a much more capable programmer to master Lisp than C, and in the late
1980s there weren't enough Lispers around to make a PC priced LM
economic.
> Cheers,
> Tamas
Citizen Jimserac
True. Particularly galling to me is that the programmers of today
have but the foggiest notion of the power and degree of integration
between operating system and lisp interpreter that those old machines
had. All they know is that piece of crap Windows with its eye candy
and pathetic .Net Mucrosoft nonsense. Equally frustrating is that the
code is locked up and forgotten, hidden away never to be seen again
despite the advances to R&D that its release would naturally entail.
As an example of the kind of software from that era, I give you one
small example, "Maxima", the symbolic algebra software apparently a
derivative of Macsyma from the early 1980's. It took Dr. Schleter at
Utexas YEARS of negotiations with the Dept. of Energy to get the code
released and then it took a long while to get in shape for mass
distribution. But the results are stunning, beautiful infinite
precision computations, a capable symbolic algebra system and it even
has full rotatable 3d graphs, and is programmable too. How many math
teachers in our schools falling behind in math and science even know
of it? Totally free download. Search for it.
The workstation software from Symbolics and Lisp Machine Inc. would
take even more work and have even more delicate legal issues involved
but the benefits would be even greater.
Aside to "Gavino"
You posted quite a few times in the comp.lang.apl newsgroup asking for
a free APL interpreter.
For private use and learning, just type in, glogan apl2, in google and
download the APL for DOS 32 bit "demo" version. Download and try it.
It turns out this is actually part of the famous APL/PC 1.02
interpreter from IBM - the interpreter is fully functional unlike the
crippled IBM TryAPL2 demo. Gives a 15Meg available workspace by
default. If you run it on Linux in a dosbox, just adjust the wine
memory parameter in winecfg and you can get more. Great for
learning.
Citizen Jimserac (James Pannozzi)
Citizen Jimserac
> On Tue, 29 Dec 2009 09:03:00 +0000, Alan Mackenzie wrote:
> > gavino <gavcom...@gmail.com> wrote:
> >> why is there not a lisp pc for under $300?
>
> > There once were lisp machines, in the 1980s. Look up "lisp machine" in
> > wikipedia for some interesting history.
>
> I have a Dell laptop. It runs Lisp. That makes it a Lisp PC.
NOT EVEN CLOSE!!
Gavino has a point and implies something, I think, which I will try to
extrapolate on.
In the world of the future as we envisioned it in the 60's and early
70's, there would be hotels on the moon, intelligent HAL like
computers and like science fiction staple advancements.
In reality, while in the realm of computer hardware, such advances
occured on time or even ahead of "schedule" many of the other things
are not even close to happening. Why not?
Some will say because the problems were far harder than originally
understood. That is true up to a point, I agree.
But there is much more - I believe the misappropriation and
misapplication of government funds, the politicization of research,
the dangerously subversive and unproductive influence of the lobbyists
and the deliberate quelling of the American futuristic imagination and
desire after the Vietnam war are some of the more real factors
involved in the inequality between expectation and reality that
actually happened. Likewise, if the organizational difficulties
endured by Dr. Schelter were any example, the entire foundations of
research and development infrastructure in this country need to be
seriously rebuilt if we are ever to hope to return to the post
Sputnik era of high developement attainments over relatively short
periods of time. The obstructions ... and obstructors are many.
Observe the appalling mismanagement at NASA and the obvious directions
of the future when Bert Rutan was able to accomplish, on his own,
something formerly done only by governments. The prize was a measly
million dollars. One wonders what he could have accomplished with $20
million or 50 million - large sums of money but a pittance to the
budget.
I think it was only recently that the software involved in the LEM
guidance was released to the public domain, something that properly
should have been done decades ago. AND, TONS of code and research
remain locked up by NASA and subcontractors that, although
declassified, requires $$$ to obtain. Inexcusable since much of it
was written on the taxpayers own tab.
Observe the appalling waste of money on cancer "research" - yes some
breakthroughs over the years, even major ones, but how much of that
money is being wasted, one wonders, on barking up the wrong tree in
the wrong forest for the wrong reasons. See "The Secret History of
the War on Cancer" by Davis for details.
Think of the impact that freely available Lisp Machine and Symbolics
type software would have on these activities!
Citizen Jimserac
Tamas K Papp
Sorry, but this rationalization sounds like sour grapes.
The Intel PC is not a "C machine": various CPU designs are equally
close to C, the Intel PC is not special. The architecture won because
it was cheap and _general_. Generality is the key. You can jolly
well program Lisp on an Intel PC, but what if you want to use a
significantly different language on a Lisp machine? So unless you are
100% sure you want Lisp, you will not risk buying an expensive
specialized machine.
Having specialized hardware is always very expensive. Given the high
price of competent labor and the labor intensiveness of hardware
design & development, it is rarely worth it. There are of course
exceptions, and flexible options (eg FPGAs) make specialized hardware
viable in some limited scenarios.
Tamas
Tamas K Papp
> Gavino has a point and implies something, I think, which I will try to
> extrapolate on.
Gavino doesn't even understand his own questions, even if they
accidentally make sense. Him having a point is a rather far-fetched
idea.
> Observe the appalling waste of money on cancer "research" - yes some
> breakthroughs over the years, even major ones, but how much of that
> money is being wasted, one wonders, on barking up the wrong tree in the
> wrong forest for the wrong reasons. See "The Secret History of the War
> on Cancer" by Davis for details.
>
> Think of the impact that freely available Lisp Machine and Symbolics
> type software would have on these activities!
You didn't provide any arguments to substantiate this. I don't deny
the possibility that Lisp machines are a neat thing to have, but to
argue that they provide some magical benefit that revolutionizes
cancer research etc is nonsensical.
Here is a puzzle for you: if Lisp machines are so great, why don't we
have any nowadays? It is not that they are prohibitively expensive to
make. As Pascal remarked above, you can write a Lisp VM on an Intel
PC and have your very own Lisp Machine, with many (if not all) of the
claimed benefits. But no one is doing this, so the benefits must be
quite small.
Cheers,
Tamas
Pillsy
[...]
> As Pascal remarked above, you can write a Lisp VM on an Intel
> PC and have your very own Lisp Machine, with many (if not all)
> of the claimed benefits. But no one is doing this, so the
> benefits must be quite small.
It just means benefits don't outweigh not having a decent web browser.
But they could be amazingly huge and still not make up for that lack.
Cheers,
Pillsy
Alan Mackenzie
> On Tue, 29 Dec 2009 16:50:46 +0000, Alan Mackenzie wrote:
>> Tamas K Papp <tkp...@gmail.com> wrote:
>>> I have noticed that some people are nostalgic about Lisp Machines,
>>> and I appreciate the sentiment, but to me they look like nothing but
>>> a glorious dead end. And incidentally, the failure of the Lisp
>>> Machine market provided another opportunity for people to write Lisp
>>> off.
>> Yes indeed. The Intel PC (language: C) won over the Lisp Machine
>> (language: lisp). My own opinion (for what it's worth) is that it
>> takes a much more capable programmer to master Lisp than C, and in the
>> late 1980s there weren't enough Lispers around to make a PC priced LM
>> economic.
> Sorry, but this rationalization sounds like sour grapes.
> The Intel PC is not a "C machine": various CPU designs are equally
> close to C, the Intel PC is not special.
All these CPU designs are targetted at "C-like"/"Fortran-like" languages,
primarily made up of sequential computations and assignment statements
with function calls being relatively rare. That's what I meant by "C",
and I should have been clearer.
> The architecture won because it was cheap and _general_. Generality is
> the key. You can jolly well program Lisp on an Intel PC, but what if
> you want to use a significantly different language on a Lisp machine?
You can compile that language with the lisp machine as the target
architecture. The lisp machine is just as general, it just emphasises
languages dominated by heavily nested function calls, rather than those
made up of assignment statements. The architectures that came to
dominate (Intel, Motorola 68000, some RISCs) did so because "C-like"
languages had far more programmers that "lisp-like" languages.
> So unless you are 100% sure you want Lisp, you will not risk buying an
> expensive specialized machine.
Indeed. Not now, at any rate. Back in the mid 1980s, all machines were
expensive, the recently appeared IBM-PC with it's 4.7 MHz 8-bit chip, and
256kB of RAM retailing at (?) ~$5000.
> Having specialized hardware is always very expensive. Given the high
> price of competent labor and the labor intensiveness of hardware design
> & development, it is rarely worth it. There are of course exceptions,
> and flexible options (eg FPGAs) make specialized hardware viable in
> some limited scenarios.
Yes.
Citizen Jimserac
> On Tue, 29 Dec 2009 09:59:25 -0800, Citizen Jimserac wrote:
> > Gavino has a point and implies something, I think, which I will try to
> > extrapolate on.
>
> Gavino doesn't even understand his own questions, even if they
> accidentally make sense. Him having a point is a rather far-fetched
> idea.
>
> > Observe the appalling waste of money on cancer "research" - yes some
> > breakthroughs over the years, even major ones, but how much of that
> > money is being wasted, one wonders, on barking up the wrong tree in the
> > wrong forest for the wrong reasons. See "The Secret History of the War
> > on Cancer" by Davis for details.
>
> > Think of the impact that freely available Lisp Machine and Symbolics
> > type software would have on these activities!
>
> You didn't provide any arguments to substantiate this. I don't deny
> the possibility that Lisp machines are a neat thing to have, but to
> argue that they provide some magical benefit that revolutionizes
> cancer research etc is nonsensical.
I disagree but without a common frame of reference, it is impossible
to convince you!!
I see them as computational engines of enormous power, far in advance
of their time, but based on development paradigms which are very
likely foreign to both of us and of which I have only an inkling.
That is the problem. Seen in the context of the eclipse or visual
studio design, compile, link, test, debug cycle, those paradigms may
appear to you to be archaic curiosities. This explains your inability
to conceptualize how they might be of any use in anything - including
cancer research!
> Here is a puzzle for you: if Lisp machines are so great, why don't we
> have any nowadays? It is not that they are prohibitively expensive to
> make. As Pascal remarked above, you can write a Lisp VM on an Intel
> PC
Excuse me? A microcoded one? That's NOT something you dash off in an
afternoon!!
and have your very own Lisp Machine, with many (if not all) of the
> claimed benefits.
I MOST VOCIFEROUSLY disagree! I don't think you have a clue as to what
those machines can do.
But no one is doing this, so the benefits must be
> quite small.
Disagree completely but, what the hell, this is just my opinion.
Nothing more. I'm just stating an opinion off the top of my head.
I've no agenda, need to prove nothing and welcome your opinion as
being as good as mine or better!
It took Schelter something like 20 years of negotiations to bring us
Maxima. Would you have told us that it was probably not worth the
trouble if he had failed and we had never seen it?
I've had my say and will shut up - ponder what I said. Those who are
interested can google for more info on what those old machines could
do. It's out there.
Thanks
Citizen Jimserac (James Pannozzi)
Friedrich Dominicus
>
> Indeed. Not now, at any rate. Back in the mid 1980s, all machines were
> expensive, the recently appeared IBM-PC with it's 4.7 MHz 8-bit chip, and
> 256kB of RAM retailing at (?) ~$5000.
Atari ST? Amiga?
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Mahesh Subramaniya
> why is there not a lisp pc for under $300?
>
> with power of lisp could be quite grand..
I'm a novice user in lisp. Trying to understand few things in the world
of Lisp.
- MS.
Tamas K Papp
> You can compile that language with the lisp machine as the target
> architecture. The lisp machine is just as general, it just emphasises
> languages dominated by heavily nested function calls, rather than those
> made up of assignment statements. The architectures that came to
> dominate (Intel, Motorola 68000, some RISCs) did so because "C-like"
> languages had far more programmers that "lisp-like" languages.
Maybe, but I am still not convinced that this was the main reason.
First, the number of programmers is itself endogenous: programmers
gravitate to languages which they find useful. Sure, there are some
other factors, but in the days of Lisp machines, these worked in favor
of Lisp much more than today (it was much more widespread, had a
significant presence at universities, etc).
Second, Intel-like architectures could have had other advantages which
have nothing to do with the number of programmers. Maybe they were
simpler, cheaper to produce, easier to optimize, etc. I don't think
we can explain how these architectures came to dominate without taking
these factors into account, and when we do this, I would be surprised
if the "Lisp had less programmers" story still retains a lot of
explanatory power.
Tamas
Tamas K Papp
> On Dec 29, 1:41 pm, Tamas K Papp <tkp...@gmail.com> wrote: [...]
>> As Pascal remarked above, you can write a Lisp VM on an Intel PC and
>> have your very own Lisp Machine, with many (if not all) of the claimed
>> benefits. But no one is doing this, so the benefits must be quite
>> small.
>
> It just means benefits don't outweigh not having a decent web browser.
:-)
> But they could be amazingly huge and still not make up for that lack.
If some tool has "amazingly huge" benefits, people usually end up
creating it. Eg many people consider having a Common Lisp
implementation to be very beneficial, so they are willing to devote a
substantial amount of effort (free implementations) or money
(commercial ones) in order to have one.
Yet when I asked about the benefits of Lisp Machines, all I got were
either (1) vague arguments about how nice it would be to have all the
"environment" in Lisp, (2) patronizing responses on how I can't
imagine how great it is unless I have used one, without any details.
(1): I still can't see why it would matter to have the OS etc in Lisp.
This may be because I don't want to hack the OS: my ideal state of
existence is when I can ignore the OS entirely and get on with my
work. I don't want to hack device drivers and filesystems, I prefer
not to know that such things exist. Yes, sometimes I have to deal
with them, but that's usually a PITA and I hate doing it. Fortunately
for me, there are people who do like doing these things. They seem to
prefer C, and I am fine with that. I imagine that if I tried telling
them how they would be better off using Lisp, I would get a
well-deserved laugh.
(2): The tone that some people use when they talk about Lisp Machines
reminds me of other groups which enjoy reminiscencing about solutions
that they hold in high regard but disappeared for various (mostly
economic) reasons. I still hear people talking about NeXTstep or
Amiga as if nothing that has happened ever since can compare. Maybe.
I think that even if a particular product line disappears, worthwhile
solutions resurface in other forms.
Cheers,
Tamas
Tamas K Papp
> On Dec 29, 1:41 pm, Tamas K Papp <tkp...@gmail.com> wrote:
>> You didn't provide any arguments to substantiate this. I don't deny
>> the possibility that Lisp machines are a neat thing to have, but to
>> argue that they provide some magical benefit that revolutionizes cancer
>> research etc is nonsensical.
>
> I disagree but without a common frame of reference, it is impossible to
> convince you!!
It is also impossible to convince someone without arguments :-)
>> and have your very own Lisp Machine, with many (if not all) of the
>> claimed benefits.
>
> I MOST VOCIFEROUSLY disagree! I don't think you have a clue as to what
> those machines can do.
Yes, I see that you disagree most vociferously. If you could learn to
disagree by providing some arguments, you would be more convincing.
> I've had my say and will shut up - ponder what I said. Those who are
> interested can google for more info on what those old machines could do.
> It's out there.
I don't see anything that I could ponder on. "You are wrong, I am right,
just google for it, it is out there." Sheesh.
Tamas
Frode V. Fjeld
> Yet when I asked about the benefits of Lisp Machines, all I got were
> either (1) vague arguments about how nice it would be to have all the
> "environment" in Lisp, (2) patronizing responses on how I can't
> imagine how great it is unless I have used one, without any details.
Lisp would be a tool to make a tool (the OS) that supports tools
(applications) that help you do what you want to do. I'm guessing this
rather long chain of tools explains something of why it's hard to give a
list of concrete benefits. Also, there's nothing that is inherently only
possible to do in lisp and not other languages/systems. The question is
rather in what direction(s) the languages/systems tends to lead in terms
of the end-user experience. That is, "given this basic system, what is
easy/natural to build on top of it?"
There has been a huge collective effort over the last few decades to
build good "desktop" systems based on the predominant C/unix technology
(that includes linux, windows, mac, etc.), and the observation is I
believe that there's still significant aspects of the old lisp-machines
that were better, even if the number of man-years put into those lisp
systems were minuscule in comparison.
That's not to say that it's impossible for some hypothetical future
"ubluntu linux 18.0" to provide everything the lisp machines did and
more. But I do think (also) this suggests that there are serious
drawbacks to the way we are making operating systems today, and that
these have negative effects on the end-user experience.
> (1): I still can't see why it would matter to have the OS etc in Lisp.
The point would be to provide a better overall end-user experience. I
don't think "Lisp" as such is the full answer to that call, but it might
be part of the answer.
> This may be because I don't want to hack the OS: my ideal state of
> existence is when I can ignore the OS entirely and get on with my
> work. I don't want to hack device drivers and filesystems, I prefer
> not to know that such things exist. Yes, sometimes I have to deal
> with them, but that's usually a PITA and I hate doing it. Fortunately
> for me, there are people who do like doing these things. They seem to
> prefer C, and I am fine with that. I imagine that if I tried telling
> them how they would be better off using Lisp, I would get a
> well-deserved laugh.
To simply reimplement the OS kernels we use today in lisp would indeed
be laughable.
> (2): The tone that some people use when they talk about Lisp Machines
> reminds me of other groups which enjoy reminiscencing about solutions
> that they hold in high regard but disappeared for various (mostly
> economic) reasons. I still hear people talking about NeXTstep or
> Amiga as if nothing that has happened ever since can compare. Maybe.
> I think that even if a particular product line disappears, worthwhile
> solutions resurface in other forms.
Arguably much of the last few years of development in software has been
a resurfacing of solutions/ideas from the lisp machines, such as GC and
language/VM-based security/safety. That's not to say there aren't more
good ideas to reuse :)
--
Frode V. Fjeld
Alan Mackenzie
>> You can compile that language with the lisp machine as the target
>> architecture. The lisp machine is just as general, it just emphasises
>> languages dominated by heavily nested function calls, rather than
>> those made up of assignment statements. The architectures that came
>> to dominate (Intel, Motorola 68000, some RISCs) did so because
>> "C-like" languages had far more programmers that "lisp-like"
>> languages.
> Maybe, but I am still not convinced that this was the main reason.
> First, the number of programmers is itself endogenous: programmers
> gravitate to languages which they find useful.
Kind of, perhaps. Programmers use whatever language their boss says, or
what the free software project they've just joined uses. I doubt many
consciously chose their language, though some do.
> Sure, there are some other factors, but in the days of Lisp machines,
> these worked in favor of Lisp much more than today (it was much more
> widespread, had a significant presence at universities, etc).
> Second, Intel-like architectures could have had other advantages which
> have nothing to do with the number of programmers. Maybe they were
> simpler, cheaper to produce, easier to optimize, etc.
The Intel 80x86 architecture came to predominate for exactly one reason,
namely that it was chosen by IBM for their PC back in the early 1980s.
Microsoft's software predominates for exactly the same reason. Nobody
would claim that the 80x86 was particularly good; other 16-bit machines
of that era used the Motorola 68000 (the Atari ST, Amiga, the Apple Mac).
Since that time, better RISC chips have appeared, yet the 30 yo Intel
architecture is as entrenched as ever. If RISC chips couldn't displace
the 80x86, what chance did a Lisp Machine have?
> I don't think we can explain how these architectures came to dominate
> without taking these factors into account, and when we do this, I would
> be surprised if the "Lisp had less programmers" story still retains a
> lot of explanatory power.
You're right here, I think. However, let's put it this way: If the
number of competent Lisp programmers in the 1980s had been higher by a
factor of 100, I think we would still have lisp machines today.
Tamas K Papp
> Tamas K Papp <tkp...@gmail.com> wrote:
>
>> Maybe, but I am still not convinced that this was the main reason.
>> First, the number of programmers is itself endogenous: programmers
>> gravitate to languages which they find useful.
>
> Kind of, perhaps. Programmers use whatever language their boss says, or
> what the free software project they've just joined uses. I doubt many
> consciously chose their language, though some do.
I agree with you. Scientists who program also tend to use widespread
languages---usually the first language that was taught reasonably well
to them---without any further thought. Very few make a conscious
choice.
> The Intel 80x86 architecture came to predominate for exactly one reason,
> namely that it was chosen by IBM for their PC back in the early 1980s.
> Microsoft's software predominates for exactly the same reason. Nobody
> would claim that the 80x86 was particularly good; other 16-bit machines
> of that era used the Motorola 68000 (the Atari ST, Amiga, the Apple
> Mac). Since that time, better RISC chips have appeared, yet the 30 yo
> Intel architecture is as entrenched as ever. If RISC chips couldn't
> displace the 80x86, what chance did a Lisp Machine have?
Again, I agree. Chip design and manufacturing exhibit significant
economies of scale, so if a technology is entrenched for whatever
reason, it will have a good chance of prevailing. If Company A
sells 10^n times the CPUs Company B sells, then A can pour more money
into the process, design new chips faster, and take advantage of
Moore's law. Then you can buy the latest A chip using today's
technology for the price of the latest B chip which lags a year
behind, even though it would have beaten last year's A chip. The
critical value of n is an interesting empirical question.
But I am wondering if this pattern will hold if Moore's law breaks
down. If you can't squeeze more bang into a single CPU, and
multithreaded CPUs don't deliver the promised miracles either, then
architectural choices for CPUs may matter again. I am not saying that
Lisp Machines will be resurrected, but x86 may not be the only
architecture around if it can be dominated---maybe in a niche.
The above scenario would be more likely to happen if free software
were more prevalent. If MS controls software, then they get to decide
whether your new CPU architecture lives or dies. But if they don't,
you may get away with rewriting a fraction of existing software (eg a
compatibility layer, etc).
>> I don't think we can explain how these architectures came to dominate
>> without taking these factors into account, and when we do this, I would
>> be surprised if the "Lisp had less programmers" story still retains a
>> lot of explanatory power.
>
> You're right here, I think. However, let's put it this way: If the
> number of competent Lisp programmers in the 1980s had been higher by a
> factor of 100, I think we would still have lisp machines today.
A related thought: anecdotal evidence suggests that Lisp makes certain
programmers more productive for certain tasks. Current desktop
environments have a lot of man-hours put into them, but if you are
more productive, you can make a working desktop environment with a lot
less effort. OTOH I think that this is precisely the kind of software
that has a lot of nitty-gritty details that will take a lot of time,
regardless of the language.
If I were a super-rich and I wanted to finance the development of a
Lisp machine, I would first aim for a successful "Lisp environment"
(not a Lisp machine, but a Lisp-based OS on stock hardware, not unlike
Movitz when/if it grows up). I would make it super-easy to contribute
simple utilities, and provide a compatibility layer (that runs current
desktop software, doesn't matter if it is 1/10 the speed). I would
only experiment with Lisp-optimized hardware after I have a
functioning ecosystem on x86. So having a Lisp Machine per se would
be of secondary importance to me. But of course this is all a pipe
dream :-)
Tamas
Kaz Kylheku
> So, why do we need a lisp PC basically?
What we need to do is to precisely define ``lisp PC''.
I don't know what a ``lisp PC'' is.
If I don't know what it is, then how can I tell whether or not I need one?
It may be safe to assume that if I don't need any kind of PC at the moment, and
if a ``lisp PC'' is a kind of PC, then I don't need a ``lisp PC''.
> I'm a novice user in lisp. Trying to understand few things in the world
> of Lisp.
A machine programmed Lisp from the ground up has the potential to be more
efficient in its use of resources, as well as more reliable and secure, than a
machine with a conventional kernel programmed in a higher level assembly
language.
An all-Lisp system can be devised in such a way that there is no need for
separate privileged and unprivileged modes of execution, and no
virtual memory.
That translates to performance.
gavino
> wikipedia for some interesting history.
>
>
> insufficient to pay enough for its development.
>
> Alan Mackenzie (Nuremberg, Germany).
I have read about symbolics a little.
Bugger that no one has one going now.
would be quite interesting to me to see what web broswer in lisp
talking to server in lisp could do vs browser in running javascript
and flash talking to a webserver in c speaking php or java.
too bad open source could not somehow catapult this
gavino
wrote:
> On 29 Dez., 07:58, gavino <gavcom...@gmail.com> wrote:
>
> > why is there not a lisp pc for under $300?
>
>
> (o o)
> ,~~~ooO~~(_)~~~~~~~~~,
> | Please |
> | don't feed the |
> | TROLL! |
> '~~~~~~~~~~~~~~ooO~~~'
> |__|__|
> || ||
> ooO Ooo
pants stainer! have you finished your open source world of warcraft
clone in common lisp yet?
gavino
> On Tue, 29 Dec 2009 09:03:00 +0000, Alan Mackenzie wrote:
> > wikipedia for some interesting history.
>
>
> > insufficient to pay enough for its development.
>
> just can't believe that "Miracle-Gro for Flowers" is good enough for
> my purposes. I am sure I could do better with an expensive
> special-purpose formula instead of the mass-produced general one. And
> they could also carry special soil for pink azaleas, red geraniums,
> etc.
>
> Tamas
well you have a c+javascript+lisp+flash pc....
gavino
> Victor <bob...@ua.fm> writes:
> > Modern personal computers are able to run Lisp code, but PCs
> > are not truly "Lisp Machines" as far as I see.
>
> --
> (espen)
lisp mobile phone wow
that would be awe some
gavino
wrote:
> ??>> Modern personal computers are able to run Lisp code, but PCs
> ??>> are not truly "Lisp Machines" as far as I see.
>
> EV> Modern mobile phones aren't phones either, the "Phone" in the iPhone is
> EV> just another unix process...
>
>
> http://www.isuppli.com/News/Pages/iPhone-3G-S-Carries-178-96-BOM-and-...
>
> There is "Application processor" ARM core from Samsung,
> and "Baseband" -- Dual ARM826 and ARM7Core.
almost like adam smith wrote: a specialization and division of labor
gavino
> On Tue, 29 Dec 2009 12:48:22 +0200, Victor wrote:
> > On Tue, 29 Dec 2009 12:31:14 +0200, Tamas K Papp <tkp...@gmail.com>
> > wrote:
>
> >> On Tue, 29 Dec 2009 09:03:00 +0000, Alan Mackenzie wrote:
>
YOU are a real unhapy guy.
I suggest going hogging.
gavino
captain obvious is the other guy
gavino
I would buy one if it were not too expensive.
many also say windows won, but I don't feel like a winner on it...in
fact I am on openBSD now and feel great!
gavino
oow interesting, I shall add this to my blog.
gavino
Lol I only make a point by accident? LOl wow thats kinda
codescending. You could say you sound like you have a pointy head.
LOl
As far as the old stale why don't we have X if its so good, that leads
you down the path of just using windows, or more interestingly, why
did bush win 2 elections if he was so bad?
gavino
same reason you need a windows xp pc
gavino
No reason to get riled up. It is possible a lisp pc would be fun to
use.
I am amazed that web is using something like javascript to deliver
dynamic content, instead of a read languae client/interpreter.
Seems web has grown organically with herd just doing it that way cuz
others do in an incrememnatal style.
I really cherish instances where people do something different and it
works nicely.
eg BSD, linux, paul graham's viaweb, plan 9 from bell labs, lisp,
haskell, forth, smalltalk, erlang, etcetc
even things such as the rotary engine I think it is great when an
alternative design does well.
I could even throw in the accidenatal discovery of philly cheese steak
sandwiches or chiecken in hot sauce commonly called "buffalo wings".
Innovation is awesome.
gavino
How was the interface on lisp machines? Any gui? graphics? video?
gavino
I am sad when I heard that MIT had given up using scheme and switched
to python for programming courses.
Are there any universities today using common lisp as a teaching
language?
gavino
would it be possible to write something like X windows in lisp?
gavino
woa, and what about the gui? and how could it be more secure? sound/
video?
no virtual memory how? because lisp garbage collection handles it? or?
interesting post!
why also more reliable?
Alan Mackenzie
> How was the interface on lisp machines? Any gui? graphics? video?
The interface was great. Yes, there was a gui - the LM was one of the
pioneers in the use of high resolution bit mapped graphics. Yes there
was graphics.
Video? That's the Latin for "I see", and has no single meaning in the
realm of computing.
Alan Mackenzie
> would it be possible to write something like X windows in lisp?
Of course. You could write something like X windows in Cobol if you
really wanted to.
The Lisp Machine had a windowing system. It is likely (though I don't
know for sure) that X Windows would have taken ideas, possibly even
design elements, from the LM windowing system.
gavino
Oww cool. I took 6 years of latin. Forgive me.
Lisp machine sounds capable.
Video I mean something where one could play small clips in a player
like mplayer.
If they had something to capture video I am guna fall off my seat.
gavino
WOW
have you ever seen the youtube [I think it was youtube] of the "demo
to end all demos" at standfor I think in the 70s?
It had apparently video in 128k and showed an engineer somewhere in a
lab talking to the demostrater.
There was something about alan kay asking UCLA students how they did
it?
Mr Kay said only one answered correctly: "beacause they wanted to!"
http://sloan.stanford.edu/MouseSite/1968Demo.html
Alan Mackenzie
> On Dec 31, 6:13?am, Alan Mackenzie <a...@muc.de> wrote:
>> gavino <gavcom...@gmail.com> wrote:
>> > How was the interface on lisp machines? Any gui? graphics? video?
>> The interface was great. ?Yes, there was a gui - the LM was one of the
>> pioneers in the use of high resolution bit mapped graphics. ?Yes there
>> was graphics.
>> Video? ?That's the Latin for "I see", and has no single meaning in the
>> realm of computing.
>> --
>> Alan Mackenzie (Nuremberg, Germany).
> Oww cool. I took 6 years of latin. Forgive me.
> Lisp machine sounds capable.
> Video I mean something where one could play small clips in a player
> like mplayer.
> If they had something to capture video I am guna fall off my seat.
No, there was nothing like this. The technology didn't exist yet. This
was in the mid-1980s when hard disk sizes, even on expensive
workstations, was measured in tens and hundreds of megabytes.
Citizen Jimserac
>
> oow interesting, I shall add this to my blog.
You're welcome!
Citizen Jimserac
Pascal J. Bourguignon
> gavino <gavc...@gmail.com> wrote:
>> On Dec 31, 6:13?am, Alan Mackenzie <a...@muc.de> wrote:
>>> gavino <gavcom...@gmail.com> wrote:
>>> > How was the interface on lisp machines? Any gui? graphics? video?
No. It is well known that lisp machines were programmed with punch
card and line printers. No GUI, no graphics, no video. Only paper
and holes. We're in for serrious Artificial Intelligence work, not
for video-games.
>>> The interface was great. ?Yes, there was a gui - the LM was one of the
>>> pioneers in the use of high resolution bit mapped graphics. ?Yes there
>>> was graphics.
>
>>> Video? ?That's the Latin for "I see", and has no single meaning in the
>>> realm of computing.
>
>>> --
>>> Alan Mackenzie (Nuremberg, Germany).
>
>> Oww cool. I took 6 years of latin. Forgive me.
>> Lisp machine sounds capable.
>> Video I mean something where one could play small clips in a player
>> like mplayer.
>> If they had something to capture video I am guna fall off my seat.
>
> No, there was nothing like this. The technology didn't exist yet. This
> was in the mid-1980s when hard disk sizes, even on expensive
> workstations, was measured in tens and hundreds of megabytes.
http://video.google.com/videoplay?docid=8612534856516244040#
--
__Pascal Bourguignon__ http://www.informatimago.com/
Alan Mackenzie
>> gavino <gavc...@gmail.com> wrote:
>>> On Dec 31, 6:13?am, Alan Mackenzie <a...@muc.de> wrote:
>>>> gavino <gavcom...@gmail.com> wrote:
>>>> > How was the interface on lisp machines? Any gui? graphics? video?
> No. It is well known that lisp machines were programmed with punch
> card and line printers. No GUI, no graphics, no video. Only paper and
> holes. We're in for serrious Artificial Intelligence work, not for
> video-games.
And a Happy New Year to you too, Pascal. :-)
Lars Rune Nøstdal
Indeed; so what is your problem?
Go buy yourself an AMD Phenom II processor(#1) and create a setup like
the one I mention above -- probably adding PostgreSQL to the list.
This is _dirt cheap_ and provides you with more power (in several
ways) than you can possibly need or expect within reason. With enough
skill and knowledge you can do whatever you want today; a "Lisp PC"
would _not_ help you as if by magic here.
#1: If you're on a budget the 2 core ones can actually be unlocked to
4 core:
http://edgemeal.110mb.com/AMD_Unlock/index.htm
Jurgen Defurne
> On Dec 29, 7:58 am, gavino <gavcom...@gmail.com> wrote:
>> why is there not a lisp pc for under $300?
>>
>> with power of lisp could be quite grand..
>
> There are several, but the setup is as follows:
>
> * X86(-64) hardware
> * Linux kernel + libpthread + libc (ASM/C)
> * SBCL (Lisp)
> * Emacs/Slime (ELisp)
>
>
> It matters not that the kernel is written in C; it deals with the
> boring, tedious crap. The important and interesting things (Lisp
> libraries and development environment) are available in a "Lisp fashion"
> or style anyway.
Well, being interested in Common Lisp, I have made myself such a
setup, but with more modest means.
* Portable PC, 10yo, 233MHz PII, 96Mb RAM, 3.5GB disk
* Debian 5.0
* mksh instead of bash to save some memory
* X (with startx and evilwm)
* CLISP
* Emacs 22.1
Further supporting software :
* org-mode (which is one of the best Lisp applications I know, even if
it is Emacs Lisp)
* w3m
* bzr for version control
* trac for change management
The two latter applications imply that I need Python, a C compiler for
being able to add the latest trac version + support for the bzr
plugin, sqlite libraries and support.
The 96 Mb of memory is enough to work at the limits of comfort under X
with GTK Emacs. Using C-x 5 2 I can open new Emacs windows, so that I
can tab through them. I use it as a workstation for a simulator of a
32-bit CPU, for which I have also developed an assembler. Using the
power of SLIME, I can easily assemble machine code, load it in the
simulator and step through or run programs.
Now, suppose indeed that everything was more like Common Lisp. I would
already save space and (probably) run-time resources if w3m, bzr, trac
and X where written in Common Lisp and compiled with SBCL. I would be
able to use SBCL, which I am loathe to do now on this machine because
of its runtime footprint (I think at least 32 Mb, vs. CLISP's
4MB).
Is the following setup not possible : suppose you have a setup of the
Linux kernel, with on top of it SBCL and its libraries, instead of the
Linux kernel with on top of it glibc. Would not that already make a
difference ? What we really would need would be a standard addition to
Common Lisp for having the same possibilities as C wrt. struct and
unions and the possibility to do with a block of memory what we want,
and a (optimizing, intelligent) C to Common Lisp translator for
porting those applications that we like to have in the Common Lisp
environment. Of course, normally, if you have emacs, than you can
mostly add what you want. Now comes a bold question : could you
envision such a setup growing into a full fledged system, usable for
common installation like a Linux distro, with tools nice enough for
the normal user to use, a web browser which can format advanced page
layouts, an office suite, DOSBOX, Gnome and/or KDE with all their
possible widgets... (just a grip from the favorite things that I use)
Regards,
Jurgen
gavino
you sound dumb when you try and be patronizing like this, just letting
you know
gavino
Madhu
* Tamas K Papp <7q1o87...@mid.individual.net> :
Wrote on 30 Dec 2009 19:33:28 GMT:
| On Wed, 30 Dec 2009 18:51:45 +0000, Alan Mackenzie wrote:
|
|> Tamas K Papp <tkp...@gmail.com> wrote:
|>
|>> Maybe, but I am still not convinced that this was the main reason.
|>> First, the number of programmers is itself endogenous: programmers
|>> gravitate to languages which they find useful.
|>
|> Kind of, perhaps. Programmers use whatever language their boss says, or
|> what the free software project they've just joined uses. I doubt many
|> consciously chose their language, though some do.
One can argue that this is a conscious choice.
| I agree with you. Scientists who program also tend to use widespread
| languages---usually the first language that was taught reasonably well
| to them---without any further thought. Very few make a conscious
| choice.
And these "Scientists" continue writing the language that they were
taught --- in the syntax of the new language. [Except they may then be
very vocal about the new language as it gives them something to be vocal
about ... ]
|> The Intel 80x86 architecture came to predominate for exactly one reason,
|> namely that it was chosen by IBM for their PC back in the early 1980s.
|> Microsoft's software predominates for exactly the same reason. Nobody
|> would claim that the 80x86 was particularly good; other 16-bit machines
|> of that era used the Motorola 68000 (the Atari ST, Amiga, the Apple
|> Mac). Since that time, better RISC chips have appeared, yet the 30 yo
|> Intel architecture is as entrenched as ever. If RISC chips couldn't
|> displace the 80x86, what chance did a Lisp Machine have?
|
| Again, I agree. Chip design and manufacturing exhibit significant
| economies of scale, so if a technology is entrenched for whatever
| reason, it will have a good chance of prevailing. If Company A
| sells 10^n times the CPUs Company B sells, then A can pour more money
| into the process, design new chips faster, and take advantage of
| Moore's law. Then you can buy the latest A chip using today's
| technology for the price of the latest B chip which lags a year
| behind, even though it would have beaten last year's A chip. The
| critical value of n is an interesting empirical question.
It looks like a meaningless question, coming from an "economist". This
whole paragraph is a bunch of nonsense. At least "designing new chips
faster" and selling them are different things, and I doubt the price
depends on any issues you touch upon.
| But I am wondering if this pattern will hold if Moore's law breaks
| down. If you can't squeeze more bang into a single CPU, and
| multithreaded CPUs don't deliver the promised miracles either, then
| architectural choices for CPUs may matter again. I am not saying that
| Lisp Machines will be resurrected, but x86 may not be the only
| architecture around if it can be dominated---maybe in a niche.
the "general purpose CPU niche"? Again, I'd caution that its hardly
clear how much Moore's law is responsible: Moore of course is at Intel
and the x86.
| The above scenario would be more likely to happen if free software
| were more prevalent. If MS controls software, then they get to decide
| whether your new CPU architecture lives or dies. But if they don't,
| you may get away with rewriting a fraction of existing software (eg a
| compatibility layer, etc).
This too is specious. Consider how Apple decided to let the PPC die for
the consumer PC market. And it did. TBMK No cause-result scenario you
ascribe fits any picture. As a consumer in the "General purpose" market
what choice do you think you have on cpu architecture?
|>> I don't think we can explain how these architectures came to
|>> dominate without taking these factors into account, and when we do
|>> this, I would be surprised if the "Lisp had less programmers" story
|>> still retains a lot of explanatory power.
|>
|> You're right here, I think. However, let's put it this way: If the
|> number of competent Lisp programmers in the 1980s had been higher by
|> a factor of 100, I think we would still have lisp machines today.
|
| A related thought: anecdotal evidence suggests that Lisp makes certain
| programmers more productive for certain tasks. Current desktop
| environments have a lot of man-hours put into them, but if you are
| more productive, you can make a working desktop environment with a lot
| less effort. OTOH I think that this is precisely the kind of software
| that has a lot of nitty-gritty details that will take a lot of time,
| regardless of the language.
But `Certain programmers' are always VERY productive in certain
environments. You had Visual basic/smalltalk gurus who could code
circles around you. These 1% of top programmers are not what is being
talked about.
What is being talked about is the Human Resources industry, where you or
XXX Inc. hire Labour (programmers) at a certain salary X, and sell their
services for a certain amount, and make a profit. There is a huge
middle management in place to oversee this process.
This situation does not require very productive programmers or
environments. It just needs numbers in terms of programmers, a provider
of services, and a customer (ideally both backed by the same investors).
These factors decide what (adequate) software/platform wins by appearing
in the invoices and bills. Technology itself is only secondary and a
controlled tool. What is important here is the `whole marketplace'. In
such situations Extreme productivity without checks and balances which
destabilizes the status quo will be eliminated automatically
While Lisp traditionally has not fallen in this category, there is
increasing scope of common lisp fitting this bill (mediocre programmers,
in massive numbers, mediocre libraries, sufficient advertising, advocacy
in that developer market, a critical number of new adopters in the
developer market, etc)
--
Madhu
Lars Rune Nøstdal
Try git! :)
> * trac for change management
>
> The two latter applications imply that I need Python, a C compiler for
> being able to add the latest trac version + support for the bzr
> plugin, sqlite libraries and support.
>
> The 96 Mb of memory is enough to work at the limits of comfort under X
> with GTK Emacs. Using C-x 5 2 I can open new Emacs windows, so that I
> can tab through them. I use it as a workstation for a simulator of a
> 32-bit CPU, for which I have also developed an assembler. Using the
> power of SLIME, I can easily assemble machine code, load it in the
> simulator and step through or run programs.
>
> Now, suppose indeed that everything was more like Common Lisp. I would
> already save space and (probably) run-time resources if w3m, bzr, trac
> and X where written in Common Lisp and compiled with SBCL. I would be
> able to use SBCL, which I am loathe to do now on this machine because
> of its runtime footprint (I think at least 32 Mb, vs. CLISP's
> 4MB).
>
> Is the following setup not possible : suppose you have a setup of the
> Linux kernel, with on top of it SBCL and its libraries, instead of the
> Linux kernel with on top of it glibc. Would not that already make a
> difference ?
I honestly can't think of much at all. Things like Java and SBCL are
virtual machines. Instead of processes you have threads, and they pre-
allocate memory from the OS and do their own memory management with
the little "world" they are given -- more-or-less totally ignoring the
C and UNIXy stuff. If some machine'ish type thing is missing like e.g.
ability to deal with blocks of memory directly (or simulation of this
for a C -> Lisp compiler?); libc won't get in your way AFAICT.
No, I don't think the dependency on libc is _really_ stopping you from
doing what you mention below. I might be missing something though.
Adding some more memory to compensate for an "outside" world that
(however unfortunate that is) isn't Lisp centric might be worth it if
you care about the "outside" world. Still, I don't see how some
_current_ dependency on libc is stopping you from writing a C -> Lisp
compiler.
Ray
> why is there not a lisp pc for under $300?
>
> with power of lisp could be quite grand..
Way back in the wayback there were lisp machines - workstations that
came loaded with a lisp development environment and an operating
system that was written in lisp and which was very well integrated
with that development environment.
They were nice. Some amazing work was done on them. And because of
the environments where it was done and the business interests surrounding
it, most of that work is now lost to us. This is a shame. The GNU
public license managed to save UNIX from getting locked up in that way -
but it did not come along in time to save the Lisp Machines.
But they were not appropriate for any environment in which untrusted
software can be run. Part of their "power" was that the OS did not
defend itself from any potentially malicious code.
In a unix system, you need both the (originally and usually, C)
development tools *and* root privileges to hose your system and/or
the network it's on. When I used 'bolics machines, all you needed
was the development environment. There was no concept of a
privileged account for administration, no concept of a user account
that other parts of the system were protected from, and no concept
of a program running with limited privileges. If it ran, it was
root. And that was a *Necessary* feature of the so-called power
of the Operating system.
If running a Lispm today, I would not *DARE* run anything downloaded
from the Internet. Not even a java applet embedded in a webpage.
Bear
Ray
> gavino <gavc...@gmail.com> wrote:
>
>> would it be possible to write something like X windows in lisp?
> The Lisp Machine had a windowing system. It is likely (though I don't
> know for sure) that X Windows would have taken ideas, possibly even
> design elements, from the LM windowing system.
It definitely did. I used LispMs at college, and a lot of their
windowing system design and UI elements got recycled in X.
Presumably by way of Xerox PARC.
Bear
Tim Bradshaw
> Presumably by way of Xerox PARC.
I don't think so. X was associated with MIT which was also where the
(east-coast) Lisp machines generally came from, so I think the
influence was much more direct.
Scott Burson
>
> I have noticed that some people are nostalgic about Lisp Machines, and
> I appreciate the sentiment, but to me they look like nothing but a
> glorious dead end.
There was a level of integration there that we no longer see in
today's systems. If you're using a program and it does something you
don't like, hit c-m-Suspend and bam, you're in the debugger. Click on
a frame and hit c-E and bam, you're editing the source. Change
something and hit c-sh-C and bam, your change is installed. Switch
back to the debugger and hit Resume and bam, the app is running with
your mod. The elapsed time could be well under 30 seconds if the bug
or change is a really obvious one.
Contrast what you have to do nowadays: track down the source, maybe
puzzle over the configure options, make sure you have the right
versions of dependent components, build the thing with debugging
enabled, fire it up under the debugger to see what it's doing, edit
and rebuild. Elapsed time: at least half an hour if you've never
hacked this app before. Maybe several hours.
It's this level of integration that made the LispMs so wonderful to
work on. The fact that the code was all in Lisp was, to some extent,
just a means to that end, though it certainly required a dynamic
language of some kind.
-- Scott
Tamas K Papp
> On Dec 29 2009, 4:41 am, Tamas K Papp <tkp...@gmail.com> wrote:
>>
>> I have noticed that some people are nostalgic about Lisp Machines, and
>> I appreciate the sentiment, but to me they look like nothing but a
>> glorious dead end.
>
> There was a level of integration there that we no longer see in today's
I also recall reading that it had no user separation or privilege
containment. Is that true? I know that this was before the internet
became ubiquitous, but is this a good security model? If not, could
one remedy this (in principle) and still have something similar to a
Lisp machine?
> Contrast what you have to do nowadays: track down the source, maybe
> puzzle over the configure options, make sure you have the right versions
> of dependent components, build the thing with debugging enabled, fire it
I think that managing software components is an orthogonal issue.
Lispers have full control over ASDF and its ilk, and we didn't do such
a great job with those. Did the Lisp Machine have a framework for
managing software updates (think Debian or similar), or was is so cozy
because the issue didn't arise?
Tamas
Robert Uhl
>>> I appreciate the sentiment, but to me they look like nothing but a
>>> glorious dead end.
>>
>> There was a level of integration there that we no longer see in today's
>
> I also recall reading that it had no user separation or privilege
> containment. Is that true? I know that this was before the internet
> became ubiquitous, but is this a good security model? If not, could
> one remedy this (in principle) and still have something similar to a
> Lisp machine?
I think so. Consider something like Plan 9's overlay filesystems, and
apply that to code. Any user could, say, view the source code of any
running program, but when he modifies it then he's updating his own copy
of it. There'd have to be some privileged mechanism to push individual
changes into the base image.
There would be some issues when User A updates the base image and User B
has his own updates to the older base image, but this sort of thing has
been solved for the general case by DVCSes--certainly it could be solved
for the particular case of an S-expression language.
--
Robert A. Uhl
There is no place for nationalism in the Church. All are one in
Christ. --Blessed Martyr Philoumenos of Jacob's Well, +1979
Tim Bradshaw
> I also recall reading that it had no user separation or privilege
> containment. Is that true? I know that this was before the internet
> became ubiquitous, but is this a good security model? If not, could
> one remedy this (in principle) and still have something similar to a
> Lisp machine?
Yes, everything was in a single address space and anyone could do
anything. No, it wasn't a good security model - it wasn't really a
security model at all. Things were made much better by bounds & type
checking of course. I guess they were a bit like what JavaScript
environments look like now that way.
I think you could do better without going to complete separation.
>
> I think that managing software components is an orthogonal issue.
> Lispers have full control over ASDF and its ilk, and we didn't do such
> a great job with those. Did the Lisp Machine have a framework for
> managing software updates (think Debian or similar), or was is so cozy
> because the issue didn't arise?
They had patches and a mechanism for managing them. I don't think
there was any automated update-getting thing (but this is pretty recent
actually - Debian may have been the first sorted out example of it).
Barry Margolin
Tim Bradshaw <t...@cley.com> wrote:
> On 2010-01-18 17:31:00 +0000, Tamas K Papp <tkp...@gmail.com> said:
>
> > I also recall reading that it had no user separation or privilege
> > containment. Is that true? I know that this was before the internet
> > became ubiquitous, but is this a good security model? If not, could
> > one remedy this (in principle) and still have something similar to a
> > Lisp machine?
>
> Yes, everything was in a single address space and anyone could do
> anything. No, it wasn't a good security model - it wasn't really a
> security model at all. Things were made much better by bounds & type
> checking of course. I guess they were a bit like what JavaScript
> environments look like now that way.
Even worse than JavaScript, which mostly tries to keep each page
separate (there are some openings, which is one of the causes of
cross-site scripting problems). Lisp Machines made no attempt at any
separation, it was not much different from any other personal computers
of the era.
As you said, bounds and type checking prevent inadvertent security
problems, but if an application calls EVAL on data read from the
network, it's totally vulnerable. We actually had an EVAL-server
running on the machines at our company, but I think it was only
listening on a CHAOSnet socket, not TCP/IP, so it wasn't accessible from
outside our network (and if we did run it over TCP/IP, our corporate
firewall wouldn't have had that port open).
>
> I think you could do better without going to complete separation.
>
> >
> > I think that managing software components is an orthogonal issue.
> > Lispers have full control over ASDF and its ilk, and we didn't do such
> > a great job with those. Did the Lisp Machine have a framework for
> > managing software updates (think Debian or similar), or was is so cozy
> > because the issue didn't arise?
>
> They had patches and a mechanism for managing them. I don't think
> there was any automated update-getting thing (but this is pretty recent
> actually - Debian may have been the first sorted out example of it).
They sent patches on tapes, and later, CD's.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Antony
>
> I also recall reading that it had no user separation or privilege
> containment. Is that true? I know that this was before the internet
> became ubiquitous, but is this a good security model?
But your sentence above seems just weired
If it had no user separation, it wasn't a good security model for what?
People used MS-DOS just fine.
What does internet have to do with this. In fact with the internet (if
we are to talk about people using any of the stuff from amazon, google
etc, that is www applications) we have more machines requiring less
multi user security (of course I am simplifying). The user uses his PC
all by himself, the server(s) runs in a secluded environment one app,
under a user account that has nothing to do with the gazillion users
connecting and utilizing it from the browsers. For webservers I don't
think it is essential to have classic 'OS users' management.
On the client side I don't think iphone, netbooks need lots of the user
isolation stuff.
I know people might run apache as one user and mysql as another,
personally i think it means little in a controlled webserver farm
environment.
Classic multi user setup is pretty much obsolete these days. Even in
corporate setting you use some oracle app that services a few corporate
users that may have no OS level user identity on that oracle app server.
On the other hand we heavily use the quick user switch feature on
windows at home :)
-Antony
Tamas K Papp
> Tamas K Papp wrote:
>>
>> I also recall reading that it had no user separation or privilege
>> containment. Is that true? I know that this was before the internet
>> became ubiquitous, but is this a good security model?
> I have no idea about lispMs other than the tidbits I read here.
>
> But your sentence above seems just weired
>
> If it had no user separation, it wasn't a good security model for what?
> People used MS-DOS just fine.
People who used MS-DOS usually had no alternative (in that price range),
so it is hard to say if they were satisfied it it. By the same token,
you could also say that in the Middle Ages, people died in the bubonic
plague just fine.
> What does internet have to do with this. In fact with the internet (if
The internet just leads to a higher chance of having someone else's
application run on your computer. Imagine having desktop Lisp machines
today, with x86-like speed but the same security model. Would you browse
the web on that?
> Classic multi user setup is pretty much obsolete these days. Even in
$ ps -eo euser | sort | uniq
avahi
daemon
dictd
haldaemon
messagebus
postfix
root
syslog
tpapp
Sorry, you were saying?
Tamas
Frode V. Fjeld
> The internet just leads to a higher chance of having someone else's
> application run on your computer. Imagine having desktop Lisp
> machines today, with x86-like speed but the same security model.
> Would you browse the web on that?
I don't get it. Are you saying you feel safe about firing up any
executable file you find floating around the internet because the unix
(etc) security model is going to protect you? I believe the current
"best practice" implies that all bets are off once you do that, unless
you very painstakingly set up a sandbox.
What unix has is the ability to have multiple security domains on a
single system, which was crucial back in the eighties or so. Now we have
Personal Computers. Plural.
--
Frode V. Fjeld
Frode V. Fjeld
> On Mon, 18 Jan 2010 09:20:08 -0800, Scott Burson wrote:
>> Contrast what you have to do nowadays: track down the source, maybe
>> puzzle over the configure options, make sure you have the right
>> versions of dependent components, build the thing with debugging
>> enabled, fire it
Tamas K Papp <tkp...@gmail.com> writes:
> I think that managing software components is an orthogonal issue.
> Lispers have full control over ASDF and its ilk, and we didn't do such
> a great job with those. Did the Lisp Machine have a framework for
> managing software updates (think Debian or similar), or was is so cozy
> because the issue didn't arise?
But there are two separate issues there: One is working with the system
you already have up and running: Understanding what goes wrong and
having the ability to fix it. This is what the lispms did well and the
others don't.
The other issue is something like software lifetime maintenance: keeping
track of versions and keeping your system synchronized and consistent as
they are being developed community-wide. Avoiding "DLL Hell". I don't
think lispms or lisp in general shines at all in this regard.
I think this latter issue is a quite interesting problem though, and in
particular in the context of "permanently-on" systems: How do you keep
multiple versions of the "same" function around in the same image? What
are the appropriate protocols for upgrading some library in a system
without disrupting its service? Etc.
--
Frode V. Fjeld
Tamas K Papp
> Tamas K Papp <tkp...@gmail.com> writes:
>
>> The internet just leads to a higher chance of having someone else's
>> application run on your computer. Imagine having desktop Lisp machines
>> today, with x86-like speed but the same security model. Would you
>> browse the web on that?
>
> I don't get it. Are you saying you feel safe about firing up any
> executable file you find floating around the internet because the unix
> (etc) security model is going to protect you? I believe the current
> "best practice" implies that all bets are off once you do that, unless
> you very painstakingly set up a sandbox.
Not necessarily the unix security model, but yes, sandboxes are a good
idea. And they are not painstaking at all -- see eg Firefox. In
contrast, AFAIK a sandbox as I understand it would be impossible on the
original Lisp machine (unless you are willing to have a virtual machine
run inside it).
> What unix has is the ability to have multiple security domains on a
> single system, which was crucial back in the eighties or so. Now we have
> Personal Computers. Plural.
I don't understand what you are trying to say.
Anyhow, I don't mean to imply that it is impossible to come up with an
architecture for a Lisp machine that would have better separation of
privileges, just that it is my impression that the original architecture
was not evolved in that direction at all.
Tamas
Frode V. Fjeld
> Not necessarily the unix security model, but yes, sandboxes are a good
> idea. And they are not painstaking at all -- see eg Firefox. In
> contrast, AFAIK a sandbox as I understand it would be impossible on
> the original Lisp machine (unless you are willing to have a virtual
> machine run inside it).
I don't know that there's anything with Firefox that would be impossible
or even more difficult to do on a lispm than e.g. linux. Other than the
sheer amount of work required to implement a browser, that is.
Firefox I believe can execute "internet code" either by running a
downloaded executable, in which case all bets are off, or it can run
something like javascript, flash, or java applets, all of which are
examples of virtual machines that could be implemented on a lispm just
as well as on linux.
--
Frode V. Fjeld
Nicolas Neuss
> [...]
Hello Frode,
reading your post I thought about trying to run your Movitz. Could you
maybe sketch a little bit how difficult this is? Are there images which
can be run within some virtual machine?
Nicolas
Helmut Eller
> I don't know that there's anything with Firefox that would be impossible
> or even more difficult to do on a lispm than e.g. linux. Other than the
> sheer amount of work required to implement a browser, that is.
Isolation? Unix uses the MMU to isolate process from each other. That
makes it fairly safe to execute programs written in low level languages
like C or assembler. The accessible memory is protected by the MMU and
everything else must be done via syscalls.
On the Lisp Machine every program had (intentionally) access to the
whole machine. That simplified debugging. On the downside, a bug in
one program could bring down the entire machine. In Unix terms, there
was no distinction between user space and kernel space.
Isolation also forced the Unix people to invent shared libraries so that
at read-only data/code could be shared safely. Nothing like that existed
on Lisp Machines, or does it?
I would not want to use an OS that doesn't provide isolation.
Helmut
Frode V. Fjeld
> reading your post I thought about trying to run your Movitz. Could
> you maybe sketch a little bit how difficult this is? Are there images
> which can be run within some virtual machine?
It shouldn't be difficult at all. There's an (somewhat old) image for
download, which should load right into any x86 emulator.
--
Frode V. Fjeld
Pascal J. Bourguignon
So you can happily use an OS written in lisp, without a hardware MMU.
(let ((v1 (vector 1 2 3)))
(defun f (x)
(if (<= 0 x 2) (aref v1 x))))
(defun g (v i)
(setf (aref v i) 0))
There is no way to call g so that it modify v1: there is isolation in lisp!
Tim Bradshaw
> I don't know that there's anything with Firefox that would be impossible
> or even more difficult to do on a lispm than e.g. linux. Other than the
> sheer amount of work required to implement a browser, that is.
>
> Firefox I believe can execute "internet code" either by running a
> downloaded executable, in which case all bets are off, or it can run
> something like javascript, flash, or java applets, all of which are
> examples of virtual machines that could be implemented on a lispm just
> as well as on linux.
Well, it's fairly well known that these things are pretty leaky (in the
"leaking information" sense), with a fairly large number of resulting
attacks. People are now implementing browsers which enforce a much
stronger isolation between components, by making use of the
address-space isolation provided by the OS the browser runs on. That
simply would not be available on a LispM at all.
Antony
>
>> Classic multi user setup is pretty much obsolete these days. Even in
>
> $ ps -eo euser | sort | uniq
> avahi
> daemon
> dictd
> haldaemon
> messagebus
> postfix
> root
> syslog
> tpapp
>
> Sorry, you were saying?
>
Helmut Eller
> So you can happily use an OS written in lisp, without a hardware MMU.
>
> (let ((v1 (vector 1 2 3)))
> (defun f (x)
> (if (<= 0 x 2) (aref v1 x))))
>
> (defun g (v i)
> (setf (aref v i) 0))
>
> There is no way to call g so that it modify v1: there is isolation in lisp!
Tell me your implementation and I'll show how to modify v1. Since all
current cl implementations use in-process debugging, it pretty easy to use
the debugging facilities to extract v1 from the closure stored in F's
function slot. E.g. for CLISP, which seems your favorite
implementation, you could do:
(compile 'f)
(setq vv (aref (nth 2 (sys::closure-consts #'f)) 1))
(g vv 1)
(f 1) => 0
Helmut
mdj
> I know people might run apache as one user and mysql as another,
> personally i think it means little in a controlled webserver farm
> environment.
Nonsense. Any service exposed to the internet is an potential remote
attack vector. For this reason services like apache run in a user
group with as little privilege as one can get away with, to lessen the
chance that a remote exploit can gain control of the entire machine.
Matt
Scott Burson
> Imagine having desktop Lisp machines
> today, with x86-like speed but the same security model. Would you browse
> the web on that?
HELL no.
Clearly a lot of work would have had to be done on security.
-- Scott
Scott Burson
wrote:
>
> There is no way to call g so that it modify v1: there is isolation in lisp!
But not on the LispM, which had subprimitives (with names like SI:%P-
CONTENTS-OFFSET if memory serves) to read and write arbitrary
locations within any object, and which were not bounds-checked either.
On the other hand, ordinary arrays were bounds-checked, and were not
stack-allocated either, removing one familiar attack style that works
on many C programs. Still I am sure there were other vulnerabilities
-- and once you're in at all, you have the whole machine.
-- Scott
Frode V. Fjeld
> Tell me your implementation and I'll show how to modify v1.
Tell me your flavor of unix and I'll show you how to modify another
process. Here's an example form the machine I'm sitting at now:
frode@shevek:~$ sleep 1000 &
[1] 21184
frode@shevek:~$ ll /proc/21184/mem
-rw------- 1 frode frode 0 2010-01-20 09:47 /proc/21184/mem
My point is, in all security problems you have to be explicit about what
the threat you're protecting against is.
Typical linux desktops today have two security domains: "root" and some
user. Root privileges are if I'm not mistaken required only to do
permanent damage to the system as such (i.e. ruin the file-system other
than /home). Note that in at least one sense this is the least
protection-worthy part of the system because you can always download a
new OS CD and reinstall it. (Of course I know there are other issues
involved, but I'm making a one-sided argument here..) Most MS-windows
desktops don't even bother with this protection, and provide the user
with administrator privileges.
If you have user privileges you can still read and write *everything*
you (qua user) have on disk and in memory, so privacy is out, and safety
is out.
I'm not saying there aren't advantages to the inter-process safety that
e.g. linux provides, but it's not absolute safety, and these things do
crash, and I suspect there is a heavy, heavy cost in terms of usability
(for sure) and performance (perhaps) incurred by this safety model.
--
Frode V. Fjeld
Nick Keighley
> Helmut Eller <eller.hel...@gmail.com> writes:
<snip>
> My point is, in all security problems you have to be explicit about what
> the threat you're protecting against is.
>
> Typical linux desktops today have two security domains: "root" and some
> user. Root privileges are if I'm not mistaken required only to do
> permanent damage to the system as such (i.e. ruin the file-system other
> than /home). Note that in at least one sense this is the least
> protection-worthy part of the system because you can always download a
> new OS CD and reinstall it. (Of course I know there are other issues
> involved, but I'm making a one-sided argument here..) Most MS-windows
> desktops don't even bother with this protection, and provide the user
> with administrator privileges.
this is less true than it used to be. I don't have admin privilege on
the windows machine I'm currently using. I suspct many office machines
are set up so the user doesn't have admin privs.
Later version of XP had better security and Vista came with them out-
of-the-box. Which caused much whining amongst those people used to the
older Windows "security model" (ie. none to speak of). Vista now has
the reputaion of prompting you every 30s for the admin password. It
doesn't, of course. And if you really want to you can turn off the
security.
> If you have user privileges you can still read and write *everything*
> you (qua user) have on disk and in memory, so privacy is out, and safety
> is out.
>
> I'm not saying there aren't advantages to the inter-process safety that
> e.g. linux provides, but it's not absolute safety, and these things do
> crash, and I suspect there is a heavy, heavy cost in terms of usability
> (for sure) and performance (perhaps) incurred by this safety model.
--
Nick Keighley
Nick Keighley
wrote:
I recall reading some stuff anout PLT Scheme that, if I recall
correctly, was saying that the virtual machine used by PLT scheme did
much of the protection that OSs typically do. The perticular machine
prevents you from doing whatever the VM provider wishes to prevent you
from doing.
Helmut Eller
> Helmut Eller <eller....@gmail.com> writes:
>
>> Tell me your implementation and I'll show how to modify v1.
>
> Tell me your flavor of unix and I'll show you how to modify another
> process. Here's an example form the machine I'm sitting at now:
>
> frode@shevek:~$ sleep 1000 &
> [1] 21184
> frode@shevek:~$ ll /proc/21184/mem
> -rw------- 1 frode frode 0 2010-01-20 09:47 /proc/21184/mem
>
> My point is, in all security problems you have to be explicit about what
> the threat you're protecting against is.
But Unix at least makes a try, by forcing all programs to use syscalls
and can refuse to execute some.
That was simply not possible on Lisp Machines; everybody could call and
modify every function.
> Typical linux desktops today have two security domains: "root" and some
> user. Root privileges are if I'm not mistaken required only to do
> permanent damage to the system as such (i.e. ruin the file-system other
> than /home). Note that in at least one sense this is the least
> protection-worthy part of the system because you can always download a
> new OS CD and reinstall it.
Still, you don't want to allow the bad guys to install key-loggers by
modifying libc and the like.
> (Of course I know there are other issues
> involved, but I'm making a one-sided argument here..) Most MS-windows
> desktops don't even bother with this protection, and provide the user
> with administrator privileges.
From a security point of view, it would be better to minimize
privileges. Windows at least has some support for that while Lisp
Machines has nothing to offer in this regard.
> If you have user privileges you can still read and write *everything*
> you (qua user) have on disk and in memory, so privacy is out, and safety
> is out.
So you are saying Unix's security model is bad. What then is the Lisp
Machine model? Very bad?
> I'm not saying there aren't advantages to the inter-process safety
> that e.g. linux provides, but it's not absolute safety, and these
> things do crash, and I suspect there is a heavy, heavy cost in terms
> of usability (for sure) and performance (perhaps) incurred by this
> safety model.
All true, but I still think that isolation is very desirable feature and
the cost seems quite bearable in the Unix case.
Helmut
Pascal J. Bourguignon
Yes, but look at what you had to do here! You had to use a function
from SYS. It is easy enough to forbid such a access, thus rendering
the system safe.
Pascal J. Bourguignon
> On Jan 19, 12:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>>
>> There is no way to call g so that it modify v1: there is isolation in lisp!
>
> But not on the LispM, which had subprimitives (with names like SI:%P-
> CONTENTS-OFFSET if memory serves) to read and write arbitrary
> locations within any object, and which were not bounds-checked either.
Again, you had to use the specific SI package, which can be prevented
easily enough.
Frode V. Fjeld
> * Frode V. Fjeld [2010-01-20 10:13+0100] writes:
>> My point is, in all security problems you have to be explicit about
>> what the threat you're protecting against is.
>> Helmut Eller <eller....@gmail.com> writes:
> But Unix at least makes a try, by forcing all programs to use syscalls
> and can refuse to execute some.
>
> That was simply not possible on Lisp Machines; everybody could call
> and modify every function.
So, again, what exaxctly is the thread model here? You can argue that
some minimally modified lisp system also "makes a try" by some package
access scheme or whatever. What do you mean "can refuse to execute
some"? In the example I showed you, there's nothing preventing me from
bitbanging that process however I want, and the only reasonable
interpretation of "can refuse" I can see is where you apply some
extra-paranoid kernel patch to disallow this.
> Still, you don't want to allow the bad guys to install key-loggers by
> modifying libc and the like.
What is the essential difference between this and all the things that
can be done with "mere" user access?
> From a security point of view, it would be better to minimize
> privileges. Windows at least has some support for that while Lisp
> Machines has nothing to offer in this regard.
It is true that lisp machines have very little to offer anyone (in
concrete terms) today. We (or I) are trying here to establish precisely
what this support that windows/unix provides is.
> So you are saying Unix's security model is bad. What then is the Lisp
> Machine model? Very bad?
I'm not saying that unix's model is necessarily bad, I'm saying that
the difference between that and that of the lisp machines is perhaps not
as big as one perhaps initially things. In particular in the context of
personal desktop systems.
> All true, but I still think that isolation is very desirable feature
> and the cost seems quite bearable in the Unix case.
I think the cost in terms of usability is possibly quite unbearable. So
much software is so brittle and user-unfriendly it's downright
painful. In terms of performance the picture is more difficult to see, I
think.
--
Frode V. Fjeld
Helmut Eller
> So, again, what exaxctly is the thread model here? You can argue that
> some minimally modified lisp system also "makes a try" by some package
> access scheme or whatever. What do you mean "can refuse to execute some"?
The Unix kernel can return EACCES "permission denied" instead of
executing the request.
> In the example I showed you, there's nothing preventing me from
> bitbanging that process however I want, and the only reasonable
> interpretation of "can refuse" I can see is where you apply some
> extra-paranoid kernel patch to disallow this.
If your process is executed as a different user than mine then you
aren't allowed to overwrite my /proc entries. You can also not
overwrite kernel memory and in particular not the parts which implement
access restrictions.
>> Still, you don't want to allow the bad guys to install key-loggers by
>> modifying libc and the like.
>
> What is the essential difference between this and all the things that
> can be done with "mere" user access?
Users can execute (access) stuff in libc but can not overwrite it.
>> From a security point of view, it would be better to minimize
>> privileges. Windows at least has some support for that while Lisp
>> Machines has nothing to offer in this regard.
>
> It is true that lisp machines have very little to offer anyone (in
> concrete terms) today. We (or I) are trying here to establish precisely
> what this support that windows/unix provides is.
>
>> So you are saying Unix's security model is bad. What then is the Lisp
>> Machine model? Very bad?
>
> I'm not saying that unix's model is necessarily bad, I'm saying that
> the difference between that and that of the lisp machines is perhaps not
> as big as one perhaps initially things. In particular in the context of
> personal desktop systems.
On the Lisp Machine, all memory was shared and readable and writable by
all processes, right? On Unix, the bulk of applications doesn't run in
kernel space. Seems quite a difference to me.
Considering that a whole industry is busy writing anti-virus programs
for those PCs, it seems that even a small improvement in the security
model could save a lot of money.
>> All true, but I still think that isolation is very desirable feature
>> and the cost seems quite bearable in the Unix case.
>
> I think the cost in terms of usability is possibly quite unbearable. So
> much software is so brittle and user-unfriendly it's downright
> painful. In terms of performance the picture is more difficult to see, I
> think.
Usability seems harder to measure than performance. I've the impression
that those Mac/iPhone using people are quite happy with usability.
Helmut
Frode V. Fjeld
>
>> So, again, what exaxctly is the thread model here? You can argue that
>> some minimally modified lisp system also "makes a try" by some
>> package access scheme or whatever. What do you mean "can refuse to
>> execute some"?
Helmut Eller <eller....@gmail.com> writes:
> The Unix kernel can return EACCES "permission denied" instead of
> executing the request.
But it fact, it doesn't. That's the reality with which we're making a
comparison, I believe.
>>> Still, you don't want to allow the bad guys to install key-loggers by
>>> modifying libc and the like.
>>
>> What is the essential difference between this and all the things that
>> can be done with "mere" user access?
>
> Users can execute (access) stuff in libc but can not overwrite it.
As I've tried to indicate before, libc etc. has about zero intrinsic
value. What has value is things like the user's documents, his privacy,
the system's resources, etc. If you already have access to those things,
the libc binary is of little consequence.
> On the Lisp Machine, all memory was shared and readable and writable
> by all processes, right? On Unix, the bulk of applications doesn't
> run in kernel space. Seems quite a difference to me.
Well, I'm trying to move beyond initial appearance and understand the
actual difference. Again, if all the crucial information is in
user-space, it matters little if the kernel is protected.
> Considering that a whole industry is busy writing anti-virus programs
> for those PCs, it seems that even a small improvement in the security
> model could save a lot of money.
Correct me if I'm wrong, but I thought you were describing the current
state of the art, not proposing some improvement? Anyhow, this sounds to
me a variation of "we need to do something.. this is something, let's do
it".
> Usability seems harder to measure than performance. I've the
> impression that those Mac/iPhone using people are quite happy with
> usability.
So apropos this, does the iPhone do inter-process safety?
--
Frode V. Fjeld
Helmut Eller
>> On the Lisp Machine, all memory was shared and readable and writable
>> by all processes, right? On Unix, the bulk of applications doesn't
>> run in kernel space. Seems quite a difference to me.
>
> Well, I'm trying to move beyond initial appearance and understand the
> actual difference. Again, if all the crucial information is in
> user-space, it matters little if the kernel is protected.
The part which implements security restrictions seems crucial. That
part should not be modifiable by unprivileged processes. It's also
important that processes must communicate with the kernel to reach
outside their private memory.
>> Considering that a whole industry is busy writing anti-virus programs
>> for those PCs, it seems that even a small improvement in the security
>> model could save a lot of money.
>
> Correct me if I'm wrong, but I thought you were describing the current
> state of the art, not proposing some improvement? Anyhow, this sounds to
> me a variation of "we need to do something.. this is something, let's do
> it".
Lisp Machines would not be an improvement but a step backwards.
>> Usability seems harder to measure than performance. I've the
>> impression that those Mac/iPhone using people are quite happy with
>> usability.
>
> So apropos this, does the iPhone do inter-process safety?
I guess so. It's the Darwin kernel compiled for ARM.
Helmut
mdj
> On the Lisp Machine, all memory was shared and readable and writable by
> all processes, right? On Unix, the bulk of applications doesn't run in
> kernel space. Seems quite a difference to me.
Yes but a language that does not allow arbitrary pointer arithmetic is
less vulnerable to attack and easier to secure.
A BIG part of the security problem is that most of the software is
written in C or one of its variants. If all software is written in a
language which disallows arbitrary memory access, the necessity of
hardware based protection is significantly diminished.
Matt
Frode V. Fjeld
> The part which implements security restrictions seems crucial.
If that which is to be secured is already compromised, I would have to
disagree.
> That part should not be modifiable by unprivileged processes. It's
> also important that processes must communicate with the kernel to
> reach outside their private memory.
If the kernel routinely (as it in fact does) allows such access, this is
not important, it is irrelevant.
--
Frode V. Fjeld
Duke Normandin
> Alan Mackenzie wrote:
>
>> gavino <gavc...@gmail.com> wrote:
>>
>>> would it be possible to write something like X windows in lisp?
>
>> The Lisp Machine had a windowing system. It is likely (though I don't
>> know for sure) that X Windows would have taken ideas, possibly even
>> design elements, from the LM windowing system.
>
> It definitely did. I used LispMs at college, and a lot of their
> windowing system design and UI elements got recycled in X.
>
> Presumably by way of Xerox PARC.
>
> Bear
>
>
Sounds like these LispMs were a lot like the Forth Machines of that same era
(I suppose).
--
Duke
*** Tolerance becomes a crime, when applied to evil [Thomas Mann] ***