why is there not a lisp pc?
in [Lisp]
|
From: Frode V. Fjeld on 20 Jan 2010 15:13 > * Frode V. Fjeld [2010-01-20 15:50+0100] writes: > >> 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.helmut(a)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
From: Helmut Eller on 20 Jan 2010 17:18 * Frode V. Fjeld [2010-01-20 21:13+0100] writes: >> 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
From: mdj on 20 Jan 2010 18:46 On Jan 21, 3:48 am, Helmut Eller <eller.hel...(a)gmail.com> wrote: > 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
From: Frode V. Fjeld on 21 Jan 2010 02:58 Helmut Eller <eller.helmut(a)gmail.com> writes: > 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
From: Duke Normandin on 11 Feb 2010 23:04
On 2010-01-13, Ray <bear(a)sonic.net> wrote: > Alan Mackenzie wrote: > >> gavino <gavcomedy(a)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] *** |