Is there any OpenSource OS or Arcitecture that
uses Lisp, Scheme, or ScSh to create a Lisp Machine.
One possilbe Lispm is
vlee.sourceforge.net
and there was also talk about an Explorer II emulator.
How hard would it be to turn a Linux box into a Scheme/Lisp machine.
Are there any OS's that are written in Lisp/Scheme?
Could Linux be ported from C into Lisp/Scheme, and would this
constitute a Lispm.
Please help with a Lisp/Scheme based OS.
If one were freely available, and more people started using and liking
it, it could cause a rebirth of the Lisp Machine--just like Linux
caused the
rebirth of UNIX.
The only important thing is to not tie the Lispm to a specific chip,
or Machine like Symbolics, LMI, Xerox, TI, and the Scheme Chip did but
to make it able
to run on all hardware--so that more people could try it out.
Porting Linux into a Lisp/Scheme OS would be a great start.
From: Tom Lord
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <v8hsbpehmiiv7b@corp.supernews.com>
Is there any OpenSource OS or Arcitecture that uses Lisp,
Scheme, or ScSh to create a Lisp Machine.
How hard would it be to turn a Linux box into a Scheme/Lisp machine.
If one were freely available, and more people started using
and liking it, it could cause a rebirth of the Lisp
Machine--just like Linux caused the rebirth of UNIX.
It sounds like you are just playing around with ideas, so here are
some toys:
1) Don't bother trying to make a new kernel. Use an existing one.
Otherwise, at _best_, you'll spend a decade fretting over device
drivers and the tcp/ip stack. Anyway, unix kernels are pretty good
-- even as lispm kernels. Unless your goal is OS research -- just
"take" rather than "make" that component.
2) Don't bother trying to make a "pure lisp" system. Otherwise,
at _best_, you'll spend half a decade fretting about replacing X11
and writing a web browser.
3) I think one lispm virtue that could stand to be reborn is the
extreme hackability, and compactness of code. E.g., suppose you're
machine is running a POP3 service and you want to add some weird
feature like, say, server-side autoclassification of incoming
messages into folders. You should be able to fire up an emacs
buffer and start tweaking the server code -- maybe even connecting
to a listener on the running server. The "seemlessness" of that
kind of hackability, compared to, say, grabbing the source RPM,
reading the config instructions, etc.... would be on of my goals if
I were going to work on what you're suggesting.
4) An interesting starting place -- especially appropriate if you're
interested in SCSH: work on replacing the boot scripts of your
system; then on replacing the inetd services. Can you get to a
state where the first invocation of the (traditional) shell is
after you log in? From my personal experience, if you're a pretty
good scheme/lisp hacker, you can get a bootable system (missing a
bunch of services, of course) in a couple of weeks.
5) Another interesting starting place might be to work on replacing
the shell for interactive use.
6) Another lispm virtue (from what little I saw, anyway) was
Emacs-based gui interaction. Read up on Plan9's gui, and on
emacs, and then edwin -- then do something clever.
7) Whence from there? You could dig in to making server functionality
really secure/fast -- you could build out towards making desktop
apps really slick -- lots of options.
-t
From: Peter Seibel
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <m365pzvu1v.fsf@localhost.localdomain>
····@emf.emf.net (Tom Lord) writes:
> Is there any OpenSource OS or Arcitecture that uses Lisp,
> Scheme, or ScSh to create a Lisp Machine.
>
> How hard would it be to turn a Linux box into a Scheme/Lisp machine.
>
>
> If one were freely available, and more people started using
> and liking it, it could cause a rebirth of the Lisp
> Machine--just like Linux caused the rebirth of UNIX.
>
>
> It sounds like you are just playing around with ideas, so here are
> some toys:
>
>
> 1) Don't bother trying to make a new kernel. Use an existing one.
> Otherwise, at _best_, you'll spend a decade fretting over device
> drivers and the tcp/ip stack. Anyway, unix kernels are pretty good
> -- even as lispm kernels. Unless your goal is OS research -- just
> "take" rather than "make" that component.
Along those lines, you might want to check out the Flux OsKit.
From <http://www.cs.utah.edu/flux/oskit/>:
The OSKit is a framework and a set of 34 component libraries
oriented to operating systems, together with extensive
documentation. By providing in a modular way not only most of the
infrastructure "grunge" needed by an OS, but also many higher-level
components, the OSKit's goal is to lower the barrier to entry to OS
R&D and to lower its costs. The OSKit makes it vastly easier to
create a new OS, port an existing OS to the x86 (or in the future,
to other architectures supported by the OSkit), or enhance an OS to
support a wider range of devices, file system formats, executable
formats, or network services. The OSKit also works well for
constructing OS-related programs, such as boot loaders or OS-level
servers atop a microkernel.
For language researchers and enthusiasts, the OSKit lets them
concentrate on the real issues raised by using advanced languages
inside operating systems, such as Java, Lisp, Scheme, or ML---
instead of spending six months or years groveling inside ugly code
and hardware. With the recent addition of extensive multithreading
and sophisticated scheduling support, the OSKit also provides a
nmodular platform for embedded applications, as well as a novel
component-based approach to constructing entire operating systems.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
From: Alex Shinn
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <x5wuif7xla.wl@strelka.synthcode.com>
>>>>> "Tom" == Tom Lord <····@emf.emf.net> writes:
Tom> 1) Don't bother trying to make a new kernel. Use an existing
Tom> one. Otherwise, at _best_, you'll spend a decade fretting
Tom> over device drivers and the tcp/ip stack.
The TCP/IP stack is a one time, simple driver. The problem with other
device drivers is that they become outdated so quickly. I buy a new
digital camera and it doesn't have any support under Linux, the HW
manufacturers won't provide specs, and Linux+C is a terrible platform
for reverse engineering and experimental driver development. It would
be much better to have a nice Lisp/Scheme repl where you can
interactively query the HW and write newer drivers faster. It would be
worth the initial time investment.
Tom> 2) Don't bother trying to make a "pure lisp" system.
Tom> Otherwise, at _best_, you'll spend half a decade fretting
Tom> about replacing X11 and writing a web browser.
X11 is a monster, better not to replace. All functional web browsers
are likewise. GUI's are not difficult, and easy to improve on.
Tom> 4) An interesting starting place -- especially appropriate if
Tom> you're interested in SCSH: work on replacing the boot
Tom> scripts of your system; then on replacing the inetd
Tom> services. Can you get to a state where the first invocation
Tom> of the (traditional) shell is after you log in? From my
Tom> personal experience, if you're a pretty good scheme/lisp
Tom> hacker, you can get a bootable system (missing a bunch of
Tom> services, of course) in a couple of weeks.
Using a C-compiled Lisp/Scheme? If you want to up the ante a few more
years, drop C and write a native compiler. Are there any free Lisp
assemblers out there? I have a Scheme assembler if there's nothing
better, but it's x86-only right now and the ELF linker is primitive and
doesn't handle shared libraries.
--
Alex
From: Burton Samograd
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <crdnlxkd3.ln2@kruhft.dyndns.org>
["Followup-To:" header set to comp.lang.lisp.]
> Using a C-compiled Lisp/Scheme? If you want to up the ante a few more
> years, drop C and write a native compiler. Are there any free Lisp
> assemblers out there? I have a Scheme assembler if there's nothing
> better, but it's x86-only right now and the ELF linker is primitive and
> doesn't handle shared libraries.
I jsut started playing with the Chicken scheme-to-C compiler and it
looks very promising. It's pretty well documented and offers a good
stepping stone for people (like me) that are experienced C programmers
but can't figure out how to do everything in Lisp/Scheme yet. Combine
that with an online R5RS and scheming gets pretty fun and far less
frustrating (so far, but I haven't done that much substantial work
with it yet). It's quite well documented as well (ie. there's an
actual manual that's usable).
If anybody is interested in using it and is running Gentoo Linux, I
wrote an ebuild that you can use to install and test it out.
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
Alex Shinn <····@synthcode.com> wrote in message news:<·············@strelka.synthcode.com>...
> Using a C-compiled Lisp/Scheme? If you want to up the ante a few more
> years, drop C and write a native compiler.
http://www.cons.org/cmucl/
http://sbcl.sourceforge.net/
http://openmcl.clozure.com/
http://www.franz.com/
http://www.lispworks.com/
http://www.cormanlisp.com/
http://www.scieneer.com/
http://www.digitool.com/
From: Daniel Barlow
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <871y0mxulh.fsf@noetbook.telent.net>
Alex Shinn <····@synthcode.com> writes:
> device drivers is that they become outdated so quickly. I buy a new
> digital camera and it doesn't have any support under Linux, the HW
> manufacturers won't provide specs, and Linux+C is a terrible platform
> for reverse engineering and experimental driver development. It would
> be much better to have a nice Lisp/Scheme repl where you can
> interactively query the HW and write newer drivers faster. It would be
> worth the initial time investment.
Although this is a reasonable position as stated, I get the impression
that you think the advantage would be great enough to allow you to
punt all the _other_ drivers you do already have in
Linux/free-unix-of-your-choice. PCI bus and bridges, power
management, ACPI, IDE and SCSI, USB, i2c, exciting long blacklists and
ten years assorted workarounds for specific devices that don't
actually follow specs, networking (ethernet, 802.11, etc), video
cards. Not only do you have to write the drivers, you have to go
through all the same contortions as the free unix people have done to
get contacts at the company, sign NDAs, and the rest of that hassle.
Without the critical mass of something Linux-developer-base-sized, it
sounds like a lot of work. And as you observe, they become out of
date so quickly.
Not having done much of this kind of work, but my suspicion is that
if you want to interactively query the hardware, your first investment
should be in a logic analyser, not a repl.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Alex Shinn
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <x5pto58vdp.wl@strelka.synthcode.com>
>>>>> "Daniel" == Daniel Barlow <···@telent.net> writes:
Daniel> Not having done much of this kind of work, but my suspicion
Daniel> is that if you want to interactively query the hardware,
Daniel> your first investment should be in a logic analyser, not a
Daniel> repl.
Not just interactively query the hardware, interactively write the
driver. So you could query the driver, write a driver function, test
it, and make changes and redefine the driver functions as needed. It
seems worth it to sacrifice support for older hardware if you could add
support for newer hardware more easily.
--
Alex
On Tue, 01 Apr 2003 11:36:33 +0900, Alex Shinn wrote:
> It would be much better to have a nice Lisp/Scheme repl where you
> can interactively query the HW and write newer drivers faster.
> It would be worth the initial time investment.
You might be interested in Schemix (aka SILK = Scheme In the Linux
Kernel). Have a look at:
http://www.abstractnonsense.com/software/schemix.html
for more information.
Best wishes,
Bill.
From: David Rush
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <okfznn2egsc.fsf@aol.net>
"William Bland" <····@abstractnonsense.com> writes:
> On Tue, 01 Apr 2003 11:36:33 +0900, Alex Shinn wrote:
> > It would be much better to have a nice Lisp/Scheme repl where you
> > can interactively query the HW and write newer drivers faster.
> > It would be worth the initial time investment.
>
> You might be interested in Schemix (aka SILK = Scheme In the Linux
> Kernel). Have a look at:
NOOooooo!!!! Not another SILK!
david rush
--
Scheme: When the line noise gets too much for you.
-- Anton van Straaten (the Scheme Marketing Dept from c.l.s)
From: Christopher Browne
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <b6b0bo$3dm8b$1@ID-125932.news.dfncis.de>
Quoth ·································@hotmail.com (Franz Kafka):
> Is there any OpenSource OS or Arcitecture that
> uses Lisp, Scheme, or ScSh to create a Lisp Machine.
There's a sizable wasteland of fairly much failed projects; see the
URL below.
There are projects that try to create their own kernel; they tend to
run afoul of the problem of being tied to a /precise/ set of
hardware. They support one CPU, one SCSI card, one graphics card, and
as soon as the winds change, and 3dfx disappears from the market,
the software becomes a curiosity that hardly anyone could have run in
the first place.
The system that gets cited a lot is FluxOS, from U of Utah; they were
able to quickly embed a port of MzScheme atop the OS, which is
interesting. On the other hand, they never got around to letting it
communicate with either networks or persistent filesystems, which
makes it somewhat /less/ than a curiosity.
People in the Lisp world often hate X, and the way Linux and BSDs use
C for their native "APIs," but it would take a LOT of effort to put
enough effort in to equal the efforts going into maintain
compatibility of them with the latest and greatest hardware on
numerous architectures.
--
output = reverse(·············@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/lisposes.html
"We use Linux for all our mission-critical applications. Having the
source code means that we are not held hostage by anyone's support
department." -- Russell Nelson, President of Crynwr Software
From: Henrik Motakef
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87n0jaer0b.fsf@interim.henrik-motakef.de>
·································@hotmail.com (Franz Kafka) writes:
> Is there any OpenSource OS or Arcitecture that
> uses Lisp, Scheme, or ScSh to create a Lisp Machine.
No. There is/was a mailing list where people interested in a new Lisp
OS gathered, but AFAIK there were no big successes.
See <http://lists.tunes.org/mailman/listinfo/lispos>.
> How hard would it be to turn a Linux box into a Scheme/Lisp machine.
Depends on how you define "Scheme/Lisp machine" (and "Linux box", of
course). Lisp Machines tended to have specialized processors that your
"Linux box" is not likely to have, so you'd have to replace it. If
your Linux box is an Alpha, you can deinstall Linux und use
Genera. You can also use any computer running Linux to run Lisp on top
of it, just not as as OS.
> Are there any OS's that are written in Lisp/Scheme?
Not any that you can get at Sourceforge or your local computer store.
> Could Linux be ported from C into Lisp/Scheme, and would this
> constitute a Lispm.
Linux is nothing but a huge collection of C, C++ and Assembly code. If
you rewrote it in Lisp, it wouldn't be Linux any more. And probably
not a good LispOS either, just translating a C program will result in
poor Lisp style.
> Please help with a Lisp/Scheme based OS.
>
> If one were freely available, and more people started using and liking
> it, it could cause a rebirth of the Lisp Machine
Well, so what? Why do you think having a Lisp Machine is important? I
for one would be more happy if we had a set of really good development
tools and seamless integration with OSes that other people actually
use.
>--just like Linux caused the rebirth of UNIX.
But Unix wasn't dead. Linux probably caused at least as many problems
for the existing Unixes than it solved, maybe a lot more.
Building a Lisp OS that would be all like Genera today probaly would
not be a too bright idea, anyway - not only because you would not be
able to run lots of good existing software on it without good reason
(unless you would implement a POSIX layer, which is probably not fun),
I wouldn't want to connect a machine running a single-user OS focusing
on openness and easy tweakability to todays internet.
IMHO, Operating Systems have become boring in the last years. There
are several "good enough" OSes you can build upon. My advice for
someone trying to build a Lisp OS would be to start with the
user-visible parts, and let other people deal with boot loaders and
device drivers first.
(Not that I would try to stop anyone from building a Lisp OS, it
surely would be cool to have one. I just think there are other, more
interesting things to to.)
Regards
Henrik
From: Joe Marshall
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <3cl2e22e.fsf@ccs.neu.edu>
Henrik Motakef <··············@web.de> writes:
> IMHO, Operating Systems have become boring in the last years. There
> are several "good enough" OSes you can build upon.
What a horrible idea.
>
> Well, so what? Why do you think having a Lisp Machine is important?
>
I used Genera 7.1 for about two years until my monitor cable broke,
and I found it hard to get a replacement--plus it was getting slow by
current standards.
What I liked about it was:
1.) It never crashed on me. Windows gave me the Blue Screen of Death,
and Linux gave me coredumps--but my Lispm gave me a menu that allowed
me to interactively fix any errors and continue. I never lost
important data because the the OS locked up, or a page fault was
encountered because some lazy programmer at Microsoft forgot to check
the bounds of an array, or forgot to free some memory.
2.) Everything was written in Lisp, from the lowest device driver, to
the file systems, and network protocols--not that I understood
everything. But, I could look at a Lisp reference, or interactivally
test each function to find out how it worked.
3.) Everything was intergrated. The Word Processor/Text Editor,
E-Mailer, GUI-Toolkit, Web Browser. And, I could switch from one to
the other without worrying about wasting system resources, or having
too many apps opened at once. It was like the OS was a large Lisp
Interperter--that seemed to have unlimited virtual memory, and a great
garbage collector.
4.) you did not have to specify what datatypes a function expected.
Each operator knew what datatypes it operated on and how to handle
exceptions. This freed the programmer from having to worry about
making sure data types matched and from having to write fifteen
functions that did the same operation to different datatypes.
5.) The OS was Object Oriented. It was easy to extend a class to add
new functionality to the system.
6.) Each user was on the same OS as a different instance of the class
OS. This means that if one user screwed up the OS--it could be
restored to the default class OS. And also prevented one users
mistakes from affecting other users.
7.) A new instance of the OS could be loaded when the OS was running.
These instances called worlds could be loaded in real time--plus a
user could create a new version of the OS for his own use.
8.) Even the microcode could be written in Lisp.
9.) Security made sure that no code could be loaded from the net
without the sysadmins concent.
10.) The system could be configured to be bootable from the net. So,
sysadms could manage systems from far away.
>
> I wouldn't want to connect a machine running a single-user OS focusing
> on openness and easy tweakability to todays internet.
>
The new system would have to have a layer of security to prevent
people from the net from modifying the system. Linux is an open system
too. But, most users would want a system that's easy to modify. It
would make developing code on the system easier, and would also make
adding new features to the system easier.
As for a single user system--Lisp does not require a system to be
single user. With CLOS or Multithreading, or even Scheme-like
continuations it should be very easy to write a multi-user Lispm.
When network protocols such as TCP/IP, Sockets, Chaosnet, or Ethernet
are added to the Lispm security could be added as well to make sure
that only the sysadm could change the system. And by providing a
function in microcode--that could not be changed--to restore the
system to some default. This one concession should make a Lispm safe
on the Net.
It a GNU Lispm OS were developed--I'm sure people would use it. What
kept people from Lisp based OSes in the past was the high prices and
the speciallized hardware requirements.
But, If we write our own we could make it run on stock hardware
(Intel,AMD,Motorola) everything Linux runs on.
ALSO:
We could make Linux the FEP (Front End Processor) and have the
Lisp OS load on top of Linux.
Any OS could be the FEP. The FEP was used to debug a faulty Lisp OS
hardware error.
The Lispm would need an Editor, a GUI Builder, an E-Mailer, Lisp
Debugger, and other Lisp tools. Any OS could be the FEP even Windows
but I would shy away from Windows.
The only key difference between a Lisp Compiler and a Lisp OS is
support for a file system, a verious development tools.
I'm sure that someone could write Linux code to emulate one of the
older Lispm environments--kind of like OpenGenera...& this would be a
good start to creating a new Lispm.
From: Paolo Amoroso
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <elOMPvPof=WXoGVRfax0F9U2moP1@4ax.com>
[Followup posted to comp.lang.lisp only]
On 1 Apr 2003 13:33:18 -0800, ·································@hotmail.com
(Franz Kafka) wrote:
> It a GNU Lispm OS were developed--I'm sure people would use it. What
[...]
> But, If we write our own we could make it run on stock hardware
> (Intel,AMD,Motorola) everything Linux runs on.
[...]
> We could make Linux the FEP (Front End Processor) and have the
> Lisp OS load on top of Linux.
[...]
> I'm sure that someone could write Linux code to emulate one of the
> older Lispm environments--kind of like OpenGenera...& this would be a
> good start to creating a new Lispm.
It might be instructive for you to estimate the amount of resources
required for turning your "if we write...", "we could make..." and "someone
could write" into actual software.
In case you are interested in contributing, there are two projects for
creating Lisp Machine emulators, one for TI Explorers and the other for
Symbolics.
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Henrik Motakef
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87adf71chi.fsf@interim.henrik-motakef.de>
·································@hotmail.com (Franz Kafka) writes:
> [...] a GNU Lispm OS [...]
BTW: Even if I guess that you mean "licensed under the terms of the
GNU GPL" when you say "GNU", the original GNU announcement� mentioned
that "Both C and Lisp will be available as system programming
languages" in the GNU system.
I guess that full set of Lisp system libraries and development tools
will be released shortly after the HURD goes gold. ;-)
Regards
Henrik
� <http://www.gnu.org/gnu/initial-announcement.html>
"Franz Kafka" <·································@hotmail.com> wrote in message
·································@posting.google.com...
> Is there any OpenSource OS or Arcitecture that
> uses Lisp, Scheme, or ScSh to create a Lisp Machine.
>
> One possilbe Lispm is
> vlee.sourceforge.net
>
> and there was also talk about an Explorer II emulator.
>
> How hard would it be to turn a Linux box into a Scheme/Lisp machine.
>
> Are there any OS's that are written in Lisp/Scheme?
>
> Could Linux be ported from C into Lisp/Scheme, and would this
> constitute a Lispm.
>
> Please help with a Lisp/Scheme based OS.
There are already Lispm's around. Just take an IDE like
Lispworks or ACL. They have editors (much like emacs),
listeners (much like xterms), generic interfaces to
file systems, a compiler, a loader (compile, compile-file and load).
They run under xservers or Windows. You can write "shell scripts" to your
hearts content. If you really want to write a lisp device driver, you
can. You could start with with a IDe like these and gradually replace
the underlying OS, web applications, device drivers with code
written in Lisp. Just see Franz's site
http://opensource.franz.com/
as an example.
Wade
>
> There are already Lispm's around. Just take an IDE like
> Lispworks or ACL. They have editors (much like emacs),
> listeners (much like xterms), generic interfaces to
> file systems, a compiler, a loader (compile, compile-file and load).
>
That's true.
But, most Lisp Systems cost way too much for a hobbyist or typical
computer user (> $1,000) or even (> $5,000) in most cases.
If companys would release GNU or freeware versions of there
products--I think that the market for the corporate versions would
increase. Because a freeware version would increase the number of base
users. Some would learn to code in LISP and develop new apps. This
would make more firms want to use Lisp with Java (which spread because
SUN released a free version) and C/C++ which is popular because a free
OS uses them.
Symbolics or MIT should release a version of OpenGenera that runs on
Linux.
Franz did a good job but should release a GNU Version of Allegro CL
Gold Hill should release a GNU Version of Gold Works 3
and other LISP companys should follow suit.
Clisp is good.
However, LISP is not as popular as it could be--not because it is very
hard to learn, but because there are no GNU Versions of Commerical
Grade products. I think that once a GNU version is out there--the
company that released it could make money on support, documentation,
and delivery; like RedHat does.
Another thing is to release cheaper versions of Lisp Compilers that
can create a Windows executable. Some programmers I know would love to
switch to LISP but cannot because they cannot justify why thay should
spend in the thousand dollar range--when they can get Visual Basic,
and Visual C++ for way under a thousand and sometimes way under a
hundred. (The managers told those programmers that they could buy a
Lisp compiler if it conformed to the ANSI standard, and came with some
GUI builder such as CLIM, or a VB type interface--they could not find
such a system.)
If a company released such a version it would make LISP more popular,
and if a old Lisp Machine company such as: TI, Symbolics, Xerox (which
did, Melady, I think), LMI, or even MIT released a freeware version of
their Lisp environment which ran either on Linux, or Windows, or
better yet both it would rekindle the need, and want for LISP based
OSes. (Users want OSes they can customize, and programmers would find
an open source OS easier to extend when new features are desired.)
The ultimate would be a Lisp OS that ran as a Java applet, or better
yet make a Lisp OS that is web based like Java so that people from
verious computers can log on to one central server. The server should
be protected so that only the client can make chages to itself--to
eliminate any security problems.
From: Kent M Pitman
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <sfwpto561gh.fsf@shell01.TheWorld.com>
[ replying to comp.lang.lisp only
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
·································@hotmail.com (Franz Kafka) writes:
> But, most Lisp Systems cost way too much for a hobbyist or typical
> computer user (> $1,000) or even (> $5,000) in most cases.
No, that's not true.
> If companys would release GNU or freeware versions of there
> products
Franz Allegro and Xanalys LispWorks both have free (as in beer) versions.
GNU CL, clisp, and CMU CL are, I believe, all available free.
Don't know the price of Corman Lisp, but last I saw it was WAY
less than $1000.
I'm not sure the current price of MCL for the Mac, but I believe it
is substantially less than $1000.
Even Xanalys LispWorks professional is less than $1000 for its
professional version.
I think the only two that are more than $1000 is Franz Allegro and
Symbolics Genera.
> I think that the market for the corporate versions would
> increase.
You have your wish. Why isn't the market increasing?
If there is a problem with the Lisp market, I am quite sure it is not
the absence of available, low-cost offerings.
> Because a freeware version would increase the number of base
> users.
Bzzzzt.
> Some would learn to code in LISP and develop new apps.
Bzzzzt.
> This would make more firms want to use Lisp with Java (which spread
> because SUN released a free version) and C/C++ which is popular
> because a free OS uses them.
Bzzzzt.
So far as I know, having free implementations has increased the number of
low-end users.
So far as I know, few if any of those users have gone on to use a
commercial Lisp, and therefore it's not even clear why Xanalys offers
a free version. I'd be surprised if the sales they lose to people who
are hanging on the edge are later made up by larger numbers of people
wanting a paid product.
I bet just the opposite. I bet people get used to getting stuff for free
and are even more annoyed at even the slightest charge for software
they can get for free.
> Symbolics or MIT should release a version of OpenGenera that runs on
> Linux.
Why? So that people can later not want to buy a for-fee version of
that, too? I don't see it.
> Franz did a good job but should release a GNU Version of Allegro CL
>
> Gold Hill should release a GNU Version of Gold Works 3
>
> and other LISP companys should follow suit.
Why?
> Clisp is good.
Then use it.
> However, LISP is not as popular as it could be--not because it is very
> hard to learn, but because there are no GNU Versions of Commerical
> Grade products.
I'm not sure what this means.
It might be a claim that when things are free, there's no budget for
doing the polish that a commercial version can offer. But giving away
more for free is not a recipe for commercial systems to stay in business.
It's a recipe for self-destructive socialism.
I've heard arguments that one day freeware versions will grow up to be
as good as commercial versions. I've even myself made claims that freeware
drives down the cost of commercial versions enough that there's too little
free cash to improve the commercial versions, which as a consequence might
make this claim easier to come true. But this is the first time I've heard
anyone have the gall to say that the problem is that freeware CAN'T make
something that competes with commercialware and that the solution is that
the commercial world should give away more free. I don't buy that for
so many reasons I can barely count them.
> I think that once a GNU version is out there--the
> company that released it could make money on support, documentation,
> and delivery; like RedHat does.
Then the makers of clisp are in a fine situation to prove this true.
> Another thing is to release cheaper versions of Lisp Compilers that
> can create a Windows executable.
Vendors are already HIGHLY motivated to drive the prices as low as
they can. Every vendor knows that if it lowers prices, it will get
more customers. The only question is how many. Every vendor thinks
seriously about lowering prices all the time. They are not idiots.
They keep their prices at the point they do not out of stupidity or
ill intent but because of the fact that they cannot AFFORD to lower
prices or they will not be able to pay salaries and they will go out
of business. They have bet their business on their pricing and they
know it. There is no more serious way they can tell you that they
know.
> Some programmers I know would love to switch to LISP but cannot
> because they cannot justify why thay should spend in the thousand
> dollar range
Then they have not investigated their options
> --when they can get Visual Basic, and Visual C++ for way
> under a thousand and sometimes way under a hundred.
The only language products you can get at that price are
(a) free software made by people not trying to make a profit on the price
(b) software made by monopoly-sized companies that can earn millions
on pennyware because of the volume they are dealing in.
If you're microsoft, and you sell a product for $600 to a million
customers, you make $600,000,000 dollars. Enough to pay a team of
developers with a tidy profit left over for a zillion people.
If you're a lisp company
and you make a product for $600 and sell it to 1000 customers, you
make $600,000 which will barely pay for the salary and overhead requried
to employ a CEO, a head of marketing, a sales person, a developer,
a receptionist, and, if you're lucky, a part-time combination lawyer
and part-time human resources person. Hitting a million customers
doesnt happen by accident. It requires marketing/advertising, and all
kinds of up-front expenditures that one doesn't just do--one has to build
up to. And one needs cash to do that. If one is not lucky enough to be
par tof a multi-million-dollar company like Microsoft, one does not
raise that cash by lowering the price of their product prematurely.
That doesn't create word of mouth buzz, it creates zero revenues.
And the word of mouth becomes "dn't buy that, it's about to go out of
business".
> (The managers
> told those programmers that they could buy a Lisp compiler if it
> conformed to the ANSI standard, and came with some GUI builder such
> as CLIM, or a VB type interface--they could not find such a system.)
This isn't the typical story. Most managers in the modern world don't
approve much other than C, C++, and Java or their variations.
> If a company released such a version it would make LISP more popular,
Based on what evidence?
> and if a old Lisp Machine company such as: TI, Symbolics, Xerox (which
> did, Melady, I think), LMI, or even MIT released a freeware version of
> their Lisp environment which ran either on Linux, or Windows,
That would take investment capital. It doesn't run there. There's no
staff to get it there.
> or
> better yet both it would rekindle the need,
Based on what evidence?
> and want for LISP based OSes.
Based on what evidence?
OpenGenera, by the way, cool as it is, is an emulated environment that
runs at best about 5x slower than the native host operating system on the
DEC Alpha that it runs on. [Last I heard, which might be old info. But
in any case, a small constant factor slower.] I don't see why an emulated
environment is going to convince anyone to take over. Java made similar
claims and in spite of being "obviously better" than semantically
bankrupt C++, it has not beaten out C++ because its virtual machine
is still way slower than native C++. And, to my surprise, it has not
even seemed to promote the creation of Java-hardware, something I was sure
was going to follow directly after Java took hold. [Maybe someone knows
something I've missed..]
> (Users want OSes they can customize, and programmers would find
> an open source OS easier to extend when new features are desired.)
That wasn't enough to make Lisp Machines take hold the last time around.
They used to be very much in demand in certain quarters, but the marketing
world is more complicated to navigate than this.
> The ultimate would be a Lisp OS that ran as a Java applet,
Emulated emulations. Mmmm. Cool for historical nostalgia. But I don't
think this would improve the marketplace for Lisp. Maybe it would make
sure that the memory of Lisp didn't die utterly as Lisp went down the
drain due to lack of dollars if all of this was free.
> or better yet make a Lisp OS that is web based like Java so that
> people from verious computers can log on to one central server.
I couldn't understand this.
> The server should
> be protected so that only the client can make chages to itself--to
> eliminate any security problems.
This is a complete change from any existing lisp-based operating system.
From: Gabe Garza
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87pto5ldd7.fsf@ix.netcom.com>
Kent M Pitman <······@world.std.com> writes:
> Bzzzzt.
>
> So far as I know, having free implementations has increased the number of
> low-end users.
>
> So far as I know, few if any of those users have gone on to use a
> commercial Lisp, and therefore it's not even clear why Xanalys offers
> a free version. I'd be surprised if the sales they lose to people who
> are hanging on the edge are later made up by larger numbers of people
> wanting a paid product.
I think you're wrong, and I'll offer myself as a data point:
My first exposure to list outside the mandatory first-semester SICP
course was when I decided to use Lisp to write a ray-tracer for the
final project of my graphics class. I chose it because I thought Lisp
was a really stupid language to use for that kind of thing. However,
after a few weeks I had a ray tracer that supported multiple light
sources, primitive shaders (patterns, blurred reflections, etc.)
several basic shapes, and was efficient enough to render polymetric
surfaces with a "high enough" polygon count so that they looked cool.
Compared to the other tools I knew, I was able to accomplish a
phenomenal amount. It placed in the end-of-class competition and won
me a couple games from the judging EA representative. It was a very
nice introduction to Lisp. :)
I graduated, and have pushed for Lisp non-stop since, including at my
current position at MegaCorp. I used Lisp to implement a system the
other developers (Perl, ColdFusion, Delphi, VB, etc.) around me
couldn't even dream of, and it is currently deployed and used--and
will soon be deployed in a second organization within the company.
When I was a student, I used CMUCL. I could not have used a trial
commercial Lisp (I would have vastly exceeded the heap limits) nor
could I have afforded the full version of one. With MegaCorp, I've
purchased the Enterprise Edition of LispWorks, a support contract, and
once the paperwork reaches the end of a LONG trail I'll also have
bought (or had someone else buy so they could use the app) quite a few
Scieneer Common Lisp licenses. Outside of MegaCorp, I also bought a
MacIvory from Symbolics.
>
> I bet just the opposite. I bet people get used to getting stuff for
> free and are even more annoyed at even the slightest charge for
> software they can get for free.
>
I'm not. I'm not as anti-FS as you: I'd say I'm ambivalent about it.
I think it is hurting businesses. Except for a Windows XP[1]
partition that I boot on average once a week, all the software I use
regularly[2] is free. If the free stuff didn't exist, I'dve bought
it, and someone would've made money.
On the other hand, when I was a student I *couldn't* have bought this
stuff. I think the most (perhaps only?) legitimate place for free
software is for students (where a "student" is someone trying to learn
something, not necessarily someone eating top Ramen and sleeping
through that damn 8am signal analysis class). And Lisp *NEEDS*
students. It needs them very bad.
> > Symbolics or MIT should release a version of OpenGenera that runs on
> > Linux.
>
> Why? So that people can later not want to buy a for-fee version of
> that, too? I don't see it.
Well, I think Genera should be proclaimed an International Treasure
and released to the world. But until that happens I certainly agree
that no Lisp vendor should have to release GNU virusware. ;)
> And, to my surprise, it has not even seemed to promote the creation
> of Java-hardware, something I was sure was going to follow directly
> after Java took hold. [Maybe someone knows something I've missed..]
You've missed Sun. :) They have a perfectly good Java processor: the
Sparc. It doesn't run Java fast (nor does it run anything fast), but
if you're a hardware vendor, that just means your clients have to buy
more of your hardware, which is a Good Thing. It's still April 1st,
but I'm only half-joking.
Gabe Garza
[1] Which I actually bought, shrinkwrapped, from a store!
[2] Linux, XEmacs, Mozilla, XFree86, CMUCL, etc.
From: Kent M Pitman
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <sfwhe9h5odx.fsf@shell01.TheWorld.com>
Gabe Garza <·······@ix.netcom.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Bzzzzt.
> >
> > So far as I know, having free implementations has increased the number of
> > low-end users.
> >
> > So far as I know, few if any of those users have gone on to use a
> > commercial Lisp, and therefore it's not even clear why Xanalys offers
> > a free version. I'd be surprised if the sales they lose to people who
> > are hanging on the edge are later made up by larger numbers of people
> > wanting a paid product.
>
> I think you're wrong, and I'll offer myself as a data point:
I didn't mean "few if any" to mean "none". I meant it just as I said
it. That is, "I won't be surprised if a small number of people
suppose themselves to be counterexamples, but I won't accept that as
evidence against my point". You're welcome to amass a list of all the
people who've taken the free version and find how many years people
have used the free version, then make a list of all the people who
have ultimately upgraded to the professional version later, and
finally to somehow demonstrate that the number of people getting a
professional version is longer than the number of people who would
have buckled and paid money earlier. Let me give you an example:
Suppose they gave out 500 free versions. Suppose of those, 15 people
would have had the money to buy the pro version earlier, but instead
those fifteen people used it for free for 3 years. Then to make your
claim, you need to show at least 15 and preferrably 45 names (assuming
that those few people would also pay for upgrades in that time, you're
welcome to assert that's a smaller number, so let's say 30 names) of
people who upgraded. I guess my point is that yes, a lot of people get
the free version, but that doesn't result in a sale. And yes, a few
people upgrade, but that doesn't make back the lost revenue of a prior
sale.
What I mean is that yes, the total number of users (paid+unpaid) might
be lower, but the total net size of the business (revenues from paid
side only) could still be higher with that lower (all paid) number of
users because of the lack of giveaway causing some people to ante up.
Not even to mention that this money would be received earlier in time,
perhaps at some time when it could be strategically used for a longer
term vision rather than later when it was perhaps too late.
The numbers like 500 and 15 and 30 are just made up by me. I really
don't know the numbers. But I suspect the number who get it greatly
outnumber the ones who later upgrade. And so on, to support the
conclusion my sample numbers purport to support.
You see, I'm nearly certain there are commercial environments that could
afford to pay for a Lisp but that know they can get away with a free one
or two or three. Maybe they say "eventually I'll pay" or "I'll just pay
for one but we'll use several". And each of those is lost revenue to
the company. How many result in product? Maybe none. So maybe the people
finally say "well, it wasn't a business use after all, I don't need to pay."
But geez, people buy software for business they don't use all the time.
I have a ton of macromedia and adobe products i bought "to see what they
would do" and never used that I paid good money for. I don't get to
send them back and say "sorry, i didn't use them for anything that made
money". So why should the Lisp industry bear that?
They do. And it's great they do. But let's give credit where credit
is due: The vendors took a BIG risk in guessing this would pay back, and
to date I don't think there is evidence that this was a risk that paid off.
I do think it's the burden of someone who wants to assert that vendors
should do more to show that there's hard evidence that vendors are not
doing enough already. I think the evidence BY FAR shows the vendors have
bent over backwards to do as much as they can. I think it's up to the
community at this point, if it wants to be that ungrateful, to show
otherwise, not vice versa.
> > I bet just the opposite. I bet people get used to getting stuff for
> > free and are even more annoyed at even the slightest charge for
> > software they can get for free.
>
> I'm not. I'm not as anti-FS as you: I'd say I'm ambivalent about it.
> I think it is hurting businesses. Except for a Windows XP[1]
> partition that I boot on average once a week, all the software I use
> regularly[2] is free. If the free stuff didn't exist, I'dve bought
> it, and someone would've made money.
>
> On the other hand, when I was a student I *couldn't* have bought this
> stuff. I think the most (perhaps only?) legitimate place for free
> software is for students (where a "student" is someone trying to learn
> something, not necessarily someone eating top Ramen and sleeping
> through that damn 8am signal analysis class). And Lisp *NEEDS*
> students. It needs them very bad.
Free as in beer? Sure. Student academic licenses, where they can be worked
out. Sure. But the LispWorks free-as-in-beer offering is much more
generous than that, and I'm betting does not pay them.
Further, I think a lot of students just end up learning that all
software should be free, just like they think everything should be
free. The harsh realities of life--that things cost--don't set in
until later. I think the trends show that mostly colleges are going
for free software, for two reasons--price and open source (which
amounts to "free books" since they are meaning to use it for
teaching). But those two things could be and should be accomplished
in other ways. Symbolics had open source under trade secret and could
have been taught.
> > > Symbolics or MIT should release a version of OpenGenera that runs on
> > > Linux.
> >
> > Why? So that people can later not want to buy a for-fee version of
> > that, too? I don't see it.
>
> Well, I think Genera should be proclaimed an International Treasure
> and released to the world. But until that happens I certainly agree
> that no Lisp vendor should have to release GNU virusware. ;)
When something is claimed by imminent domain, my understanding is that
the owners are to get paid for it commensurate with some reasonable
measure of the value.
But moreover, if it were released to the world under "public domain", I'd
have no objection because it could be reworked into proprietary software.
If it were released to the world under an anti-commercial poison pill
such as GPL, that would be bad because it would injure other players in the
market.
> > And, to my surprise, it has not even seemed to promote the creation
> > of Java-hardware, something I was sure was going to follow directly
> > after Java took hold. [Maybe someone knows something I've missed..]
>
> You've missed Sun. :) They have a perfectly good Java processor: the
> Sparc. It doesn't run Java fast (nor does it run anything fast), but
> if you're a hardware vendor, that just means your clients have to buy
> more of your hardware, which is a Good Thing. It's still April 1st,
> but I'm only half-joking.
Half-thanks. :) No, I meant there is no JAM that I know of.
(Java Actual Machine.)
From: Peter Herth
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <m3wuid12vd.fsf@uranus.local>
In the absence of statistics, perhaps we can collect some experiences of those
reading this list. So here is my very own experiences with Lisp offerings.
I have been toying around with Lisp for about 2 years now for simple interest
in the language as an alternative to those I knew at that time and am
more and more thrilled by its possibilities so I will probably continue
to lisp for the time coming. As a private person it was out of question
to spend hundreds of dollars to just try a language out, so at that time
the free as beer offerings either from the OSS world as well as the trial
versions of the commercial vendors *did* enable me to learn Lisp. Without
such offerings I would probably never entered the Lisp world.
With my current level of Lisp experience and especially looking at my
financial status I would be quite willing to spend $100 - $200 for a
commercial Lisp, but I fear there are currently no options there for me
(the only offer in that price range is Corman Lisp, but I do not use
Windows). So at least for me I can say: a lower priced Lisp could add
some customers. Please note, I am no saying that their prices are
too high per se or unreasonable by any means. I think the $ 900 for
Lispworks professional are quire nice in comparison to other commercial
software products of that size, I am only saying I cant spend $ 900
right now on Lispworks, though I would really like to, since the
trial version was very nice to use.
Currently I am mainly using CMUCL, I started preferring it to the
personal version of Lispworks since the heap restriction of the latter
is too strong to be usable for the things I am doing currently. Which
also means, the trial version doesnt really impede sales to people
wo want to do more than just testing. But here comes the catch:
if at any time in the future I get a chance to do a Lisp project
at work, I might even prefer CMUCL to other Lisps even if I could
easily afford the licence costs, because I have more experiences with
CMUCL. A very good example on how a Vendor can solve this problem
is in my eyes TrollTech with their QT library. It is available as
a commercial package as well as in a GPL-ed version for Linux.
I am not sure how well this method could be translated into other
kinds of products, but in this case GPL works greatly for them.
Students or other people who just want to write software to learn
or for fun can use the GPL version, paying just the price that they
can only create GPL-ed software based on QT. But this creates
a huge market share for QT, one has just to look on how many QT-based
programs are around. And this means there are a lot of programmers
around using QT. And when doing commercial work, all those programmers
are probably likely to choose that lib they know best...
Peter
--
Peter Herth
Dawn of the Ages
http://dawn.netcologne.de
From: Daniel Barlow
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87n0j9ujb3.fsf@noetbook.telent.net>
Peter Herth <·····@netcologne.de> writes:
> With my current level of Lisp experience and especially looking at my
> financial status I would be quite willing to spend $100 - $200 for a
> commercial Lisp, but I fear there are currently no options there for me
Scieneer (which is based on CMUCL) goes for around $155 for a
single-cpu Linux version. See http://www.scieneer.com/s/
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Nils Kassube
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <81n0j9c5w0.fsf@darwin.lan.kassube.de>
Kent M Pitman <······@world.std.com> writes:
> side only) could still be higher with that lower (all paid) number of
> users because of the lack of giveaway causing some people to ante up.
You make the funny mistake of assuming that the removal of an offical
try-before-you-buy version also removes the free availability of
commercial software. If someone doesn't want to pay for a license, he
can get anything he wants for free (as in beer). Software piracy is
not exactly new. The folks who will be hurt by the abandonment
of legal free versions are those who respect the law.
I (and I suspect the majority of all software developers) will not
buy any software I've not seen and used before.
From: Tim Bradshaw
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <ey3llytyljd.fsf@cley.com>
* Nils Kassube wrote:
> I (and I suspect the majority of all software developers) will not
> buy any software I've not seen and used before.
Have you ever heard of the term `evaluation license'? I guess not.
--tim
From: Nils Kassube
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <81k7ecdhsb.fsf@darwin.lan.kassube.de>
Tim Bradshaw <···@cley.com> writes:
> Have you ever heard of the term `evaluation license'? I guess not.
Sure I have. Like the program I have installed two months ago which
offered a 30-day evaluation. Unfortunately I only had the time to
use it once during the limit, now I won't be able to test it again.
LispWorks offers a "Personal Edition" with a heap limit, so we were
talking about an evaluation license and I presented the benefit
of having one.
I'd also like to point to the success of Cincom's VisualWorks
Smalltalk, which is available for free for non commercial use. Please
note that I do not want everything for free. I do pay for software
(although less than I used to due to getting burnt too much, this
never happend with Open Source). This is only a reference to a
successful business. I can build an extensive knowledge of VW
Smalltalk during my CS studies (with no time limit or size limit)
which enhances the probability that I will recommend its use in
commercial endeavors.
From: Tim Bradshaw
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <ey3vfxwbvrq.fsf@cley.com>
* Nils Kassube wrote:
> Sure I have. Like the program I have installed two months ago which
> offered a 30-day evaluation. Unfortunately I only had the time to
> use it once during the limit, now I won't be able to test it again.
Presumably you're not up to using the phone or email to ask the people
for an extension?
> LispWorks offers a "Personal Edition" with a heap limit, so we were
> talking about an evaluation license and I presented the benefit
> of having one.
They will also, I'm sure, give you evaluation license on the full
product, as will the other vendors.
--tim
Nils Kassube <····@kassube.de> wrote in message news:<··············@darwin.lan.kassube.de>...
> Tim Bradshaw <···@cley.com> writes:
> > Have you ever heard of the term `evaluation license'? I guess not.
>
> Sure I have. Like the program I have installed two months ago which
> offered a 30-day evaluation. Unfortunately I only had the time to
> use it once during the limit, now I won't be able to test it again.
Might I ask which CL this is? Corman does 30 days, then goes to annoy
screens if you don't reinstall. Franz does 60 days, then asks you to
download a new license file. (BTW, running their newlicense util is
broken under some conditions; just look at the orig email they sent
and redownload a license file.)
The problem is that crippling the free versions is the way to go, in
general. It might seem that it's bad for business, but empirically
with such products, I'm told it's actually best by far. For each user
who's honest, there are many more who'd say, "Thanks for the free
beer," and spend the cash at McDonald's.
You are correct that there's a natural antagonism between proprietary
software and its users. What is there to say? It's a muddled
situation, but there are free versions out there you can use. Pricing
is an interesting art, and many companies have gone out of business
because they tried to apply the most naive strategies.
Here's a recent entertaining article on pricing strategies.
http://www.fastcompany.com/online/68/pricing.html
Tj
From: Kenny Tilton
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <3E8BBE9D.4040606@nyc.rr.com>
Kent M Pitman wrote:
> Suppose they gave out 500 free versions. Suppose of those, 15 people
> would have had the money....
whoa, that's micro, Lisp vendors are thinking macro when they offer free
versions: if you were a Lisp vendor with a nice IDE and GUI framework
(ACL's CG or LW's CAPI) and all sorts of add-on libraries of very high
quality, would you want people curious about CL to judge it by CormanCL
or CLisp or even CMUCL? Those are all fine products, but it's kinda
"some assembly required" (add Emacs, stir, add ILisp, knead 5 min...)
and "you want libraries? check out cliki". not good for newbies.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
From: Kent M Pitman
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <sfwvfxwkp13.fsf@shell01.TheWorld.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Kent M Pitman wrote:
> > Suppose they gave out 500 free versions. Suppose of those, 15 people
> > would have had the money....
>
> whoa, that's micro, Lisp vendors are thinking macro when they offer
> free versions: if you were a Lisp vendor with a nice IDE and GUI
> framework (ACL's CG or LW's CAPI) and all sorts of add-on libraries of
> very high quality, would you want people curious about CL to judge it
> by CormanCL or CLisp or even CMUCL? Those are all fine products, but
> it's kinda "some assembly required" (add Emacs, stir, add ILisp, knead
> 5 min...) and "you want libraries? check out cliki". not good for
> newbies.
Vendors can and will use whatever theory they want to decide what they do.
What I'm saying is that if you're standing on the outside claiming
they are doing the wrong thing, you need to show an absolute
improvement to the bottom line in order to make a rock-solid case.
Anything else is just hot air because it is not your own money you are
asking to be gambled.
I'm sure if they thought that (a) these things matter [and they might
indeed think that, but I'm just saying it's a debatable point] and
(b) they can afford to care [and this is the thing I'm saying is really
open to question, since they have payroll to meet and stockholders to
satisfy that they are breaking even], they'd be doing what you say. But
if they are not, then that means, by definition, that they either don't
agree with (a) or (b). [There are some other cases I consider unlikely
and am not discussing; I don't really mean (a) and (b) to be exclusive,
just the most likely ... for example, it is all-too-commonly suggseted
that they've never given any thought to this issue, and I'm not counting
that as a likely possibility.]
From: Paolo Amoroso
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <fV2MPv2p7P2L+EYn8qFXfUGzmX6e@4ax.com>
On Wed, 02 Apr 2003 04:41:57 GMT, Gabe Garza <·······@ix.netcom.com> wrote:
> I graduated, and have pushed for Lisp non-stop since, including at my
> current position at MegaCorp. I used Lisp to implement a system the
> other developers (Perl, ColdFusion, Delphi, VB, etc.) around me
> couldn't even dream of, and it is currently deployed and used--and
> will soon be deployed in a second organization within the company.
If this isn't confidential information, you might consider adding a note
to:
http://alu.cliki.net/Industry%20Application
and/or:
http://alu.cliki.net/Success%20Stories
Paolo
--
Paolo Amoroso <·······@mclink.it>
* Kent M Pitman <······@world.std.com>:
> Don't know the price of Corman Lisp, but last I saw it was WAY
> less than $1000.
And Scieneer, too, although it's a bit over $1000 if you want the four
processor-license.
> It might be a claim that when things are free, there's no budget for
> doing the polish that a commercial version can offer.
Yes, but you can also spin this the other way: Maybe it will actually
be done better because you don't have the pressure that you might
experience in a commercial setting. (Where you may have strict
deadlines, for example, whereas in (some) free software-projects,
people do work on it when they have time or when they feel like it.)
This is all just speculation, though. Also, there are differing
opinions on whether socialism is actually a bad thing. (I'm not sure
myself.)
(I also notice you used the word "polish", which doesn't exactly
connote "substantial functionality". This is the feeling I have
regarding some commercial products versus free software equivalents:
It's often just the polish that separates them. Better docs, prettier
user interfaces, etc.)
--
Johannes Gr�dem <OpenPGP: 5055654C>
From: Tim Bradshaw
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <ey3vfxxynnq.fsf@cley.com>
* Johannes Gr�dem wrote:
> Yes, but you can also spin this the other way: Maybe it will actually
> be done better because you don't have the pressure that you might
> experience in a commercial setting. (Where you may have strict
> deadlines, for example, whereas in (some) free software-projects,
> people do work on it when they have time or when they feel like it.)
Well, let's have something half as good as, say, CAPI, for a free
system then. It needs to run transparently on Windows, Unix and
(within a few months as far as I can tell) MacOS.
Or let's have Allegro's heavyweight cross-platform Unicode support.
Or let's, for that matter, have a across-platform implementation that
doesn't suck. At the moment we've got CMUCL which isn't
cross-platform, but mostly doesn't suck (modulo it doesn't have
threads in half its versions), and CLISP which is, and (last time I
checked, which I admit was some time ago) didn't support most of the
interesting bits of CLOS to the extent that I couldn't even start to
get code built on it.
> (I also notice you used the word "polish", which doesn't exactly
> connote "substantial functionality". This is the feeling I have
> regarding some commercial products versus free software equivalents:
> It's often just the polish that separates them. Better docs, prettier
> user interfaces, etc.)
These things *count*.
And this isn't just about Lisp, incidentally: despite the rhetoric in
which we are all drowning, a *lot* of free software systems -
including, dare I mention it, the sacred L*n*x[1], often suck really
pretty badly.
Yes, I am a heretic, You can burn me at the stake now.
--tim
Footnotes:
[1] Do we dare mention its name lest we are struck down?
From: Pascal Costanza
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <b6es1q$t06$1@f1node01.rhrz.uni-bonn.de>
Kent M Pitman wrote:
>>Some programmers I know would love to switch to LISP but cannot
>>because they cannot justify why thay should spend in the thousand
>>dollar range
>
>
> Then they have not investigated their options
I think that's an important point. $900 distributed over a period of,
say, 18 months is $50 per month. $540 over 24 months is $22.50 per
month. I don't think that's too much. Get yourself a loan. (Maybe
vendors should think about offering loans?!?)
Another take on the GPL: AFAIK the GPL hasn't been tested in court yet.
IANAL, but it's not clear to me that the GPL would stand up in court. I
am pretty sure that at least in Germany, it's forbidden to have
contracts without time limits.
(That's probably one of the reasons why someone might prefer open source
software over closed software - because open source software seems to
give you the guarantee that you can use it forever, without any time
limits. But I guess that's the same as with type systems: Static isn't
always strong, dynamic isn't always weak. And free isn't always open,
commercial isn't always closed. Or something like that... ;)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
From: Florian Weimer
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87r88k6f3h.fsf@deneb.enyo.de>
Pascal Costanza <········@web.de> writes:
> Another take on the GPL: AFAIK the GPL hasn't been tested in court
> yet.
Maybe because the case would be hopeless (on part of the infringer, of
course)? 8-)
If the GPL is not a valid license, you have no right to copy or modify
a GPLed work, and you infringe the copyright of the author.
From: Henrik Motakef
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <878yut8oha.fsf@interim.henrik-motakef.de>
·································@hotmail.com (Franz Kafka) writes:
> Symbolics or MIT should release a version of OpenGenera that runs on
> Linux. Franz [...] should release a GNU Version of Allegro CL [...]
> The ultimate would be a Lisp OS that ran as a Java applet,
Way to obvious. Try something more subtle next year.
Regards
Henrik
Henrik Motakef <··············@web.de> wrote:
> > Symbolics or MIT should release a version of OpenGenera that runs on
> > Linux. Franz [...] should release a GNU Version of Allegro CL [...]
> > The ultimate would be a Lisp OS that ran as a Java applet,
>
> Way to obvious. Try something more subtle next year.
>
We need to be obvious because if people just hint at it. it might take
too long to get done. Genera is over 10 years old. Nobody uses it
anymore--not counting serious LISP hobbyists who use old Symbolics
hardware. (But, the Lispm companys either dropped Lisp or filed for
bankrupcy.)
A GNU version of a program like Genera will allow a new group of Lisp
hackers to see why Lisp is such a good language.
Since, freeware was invented by a person at MIT with EMACS and
X-WINDOWS, they could hopefully make a freeware version of a Lisp OS
like Genera--I'm assuming that MIT still has Lisp hackers who would
love to create a Lisp or Scheme based OS.
Look, they already build the LM-1 a Lisp Machine, and a CPU that
executes Scheme code. I'm sure that some Lisp/Scheme hackers over at
MIT, or in this newsgroup worked on such projects and would love to
help create a Lisp OS that runs as a Linux/Windows application.
The Lisp would need to handle filesystems, calling devices, I/O,
graphics, garbage collection in a standard way--but they could form a
layer that calls the Linux/Windows kernal, so that the highlevel
syntax would be machine independant and the low level details would be
handles by the OS that the Lisp environment is running in.
We already have several applications that would run in such an
environment: Maxima, CL-HTTP, CLIM, and EMACS. just some examples!!!!!
On Thu, 03 Apr 2003 02:01:42 +1000, Franz Kafka wrote:
> A GNU version of a program like Genera will allow a new group of Lisp
> hackers to see why Lisp is such a good language.
I clearly don't understand some subtle advantage of this Genera system. In
what sense is it /different/ from emacs? Is it just the dialect of lisp
involved that's at question?
> We already have several applications that would run in such an
> environment: Maxima, CL-HTTP, CLIM, and EMACS. just some examples!!!!!
Emacs has numeric and symbolic math packages, at least one web browser. I
don't know what CLIM is (a mailer? emacs has a couple of those), but
there are examples of just about everything else.
--
Andrew
From: Simon Andr�s
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <vcdwuicxzav.fsf@tarski.math.bme.hu>
Andrew Reilly <······@gurney.reilly.home> writes:
> On Thu, 03 Apr 2003 02:01:42 +1000, Franz Kafka wrote:
> > A GNU version of a program like Genera will allow a new group of Lisp
> > hackers to see why Lisp is such a good language.
>
> I clearly don't understand some subtle advantage of this Genera system. In
And one could hardly blame you, when you don't know what it is:
> what sense is it /different/ from emacs? Is it just the dialect of lisp
> involved that's at question?
http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/genera/genera.html
>
> > We already have several applications that would run in such an
> > environment: Maxima, CL-HTTP, CLIM, and EMACS. just some examples!!!!!
>
> Emacs has numeric and symbolic math packages, at least one web browser. I
> don't know what CLIM is (a mailer? emacs has a couple of those), but
> there are examples of just about everything else.
CL-HTTP is not a browser, CLIM is not a mailer, and Google is your
friend.
Andras
>
> --
> Andrew
On Thu, 03 Apr 2003 09:19:36 +1000, Simon Andr�s wrote:
> Andrew Reilly <······@gurney.reilly.home> writes:
>
>> On Thu, 03 Apr 2003 02:01:42 +1000, Franz Kafka wrote:
>> > A GNU version of a program like Genera will allow a new group of Lisp
>> > hackers to see why Lisp is such a good language.
>>
>> In
>> what sense is it /different/ from emacs? Is it just the dialect of
>> lisp involved that's at question?
>
>
http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/genera/genera.html
So, it's different because it uses CL instead of elisp? It certainly
doesn't sound like anything particularly revolutionary, and emacs does
pretty much everything that that document describes. Just about every
smalltalk and forth system uses the same "everything's in the image" model
of operation too. Sometimes that helps, sometimes it doesn't. Emacs is
GPL and freely and readily available, which seemed to be what the original
poster was looking for.
>> Emacs has numeric and symbolic math packages, at least one web browser.
>> I don't know what CLIM is (a mailer? emacs has a couple of those), but
>> there are examples of just about everything else.
>
> CL-HTTP is not a browser, CLIM is not a mailer, and Google is your
> friend.
For those also too lazy to check google: CL-HTTP is an HTTP server, and
CLIM is an interface (GUI) builder.
--
Andrew
From: James A. Crippen
Subject: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <m3y92rc2rq.fsf_-_@kappa.unlambda.com>
Andrew Reilly <······@gurney.reilly.home> writes:
> On Thu, 03 Apr 2003 09:19:36 +1000, Simon Andr�s wrote:
>
>> Andrew Reilly <······@gurney.reilly.home> writes:
>>
>>> On Thu, 03 Apr 2003 02:01:42 +1000, Franz Kafka wrote:
>>> > A GNU version of a program like Genera will allow a new group of Lisp
>>> > hackers to see why Lisp is such a good language.
>>>
>>> In
>>> what sense is it /different/ from emacs? Is it just the dialect of
>>> lisp involved that's at question?
>>
>>
> http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/genera/genera.html
>
> So, it's different because it uses CL instead of elisp? It certainly
> doesn't sound like anything particularly revolutionary, and emacs does
> pretty much everything that that document describes. Just about every
> smalltalk and forth system uses the same "everything's in the image" model
> of operation too. Sometimes that helps, sometimes it doesn't.
No, no, no.
The entire *point* of a Lisp Machine is that it is written entirely in
Lisp. *ALL* *OF* *IT*. From the boot code all the way up to the
GUI. The SCSI driver, the filesystem, the network protocols, the
graphics devide driver, all the other low level crud, the user
interface, the process scheduler, the editor, the mail client,
*EVERYTHING* is all written in the exact same language. And not just
that, but all written along basically the same design techniques.
The beauty of this is that you can discover some random bug in some
high level application and *interactively* trace it all the way down
to the lowest levels of hardware interaction.
Here's an imaginary scenario. Suppose you're hacking on some random
high-level user app, a web browser perhaps. Your requests look like
they get to the server without a problem, and the responses seem to be
sent over the wire without error, but something goes wrong because
when the response makes it to the renderer all you get is random
garbage. So you figure the best way to find out what's going wrong is
to set a breakpoint near the beginning of the rendering process. You
test and hit the breakpoint. But the args given to the renderer are
garbage.
So you start poring over the call stack. Pop back a couple and you
find that there's something wrong with the data coming to you from
your protocol socket. Okay, so set a breakpoint right before your
socket call, then step through it. Step, step, step, oh look, this
call here gets some weird crud back from the guts of a low-level
protocol call. So you step into that function, looking for where the
data gets mangled. But it looks like the protocol handler never fouls
up, it's just getting erroneous data itself.
So you trace backwards a little further into the network device
driver, and see that some random function there seems to have a
problem because its args go in good but its return is all broken. You
right-click on the name of the function, select Edit Definition from
the menu, and zap to your editor where it has opened the relevant
source file and has the appropriate function at the top of the window.
Reading through it, you notice a stupid mistake where some moron LSHed
instead of RSHed. Fix, fix. Compile the function, load it, and try
again. You forgot that you set a lot of breakpoints so go back to the
debugger and unset them. Run, run, run, and everything looks good.
Save the newly changed source, compile the changed source file, and
pop to your mailer where you include the diff in a message complaining
to the network device driver maintainer that he's an idiot. Back to
hacking.
Wouldn't you like to be able to do that in a modern system? Even with
an open source Unix system like Linux or FreeBSD you don't get that
level of interactivity. Maybe if you really know what you're doing
you can convince the debugger to walk down the call stack as far as a
kernel syscall, but not any further. It's simply not possible for you
to even see, much less make changes to the running system at the
extreme lowest levels of the operating system.
You can't go frobbing the scheduler code, or some random device driver
without having to *at least* unload some modules and reload them
(during which period all the functionality provided by those modules
is unavailable), and at most recompile the entire kernel and reboot
the box. And *no way* do you have the ability to point and drool at a
function name in the debugger and pull up its source without even
caring what file it's in. Nor can you compile a single function and
load it without having to recompile the entire executable or object
file that the function was dumped to.
And this is just one admittedly trivial example. There's some amazing
stories about Lisp Machines, like the one of a support guy sending off
a patch that worked fine except at the complainer's site where it just
slowed down to molasses. Further inspection showed that the
complaining luser hadn't compiled the patch so the system was slowed
way down while it ran a hefty chunk of interpreted code at a hardware
interrupt level but never crashed the machine. It just ran really
slow, the interpreter making everything else wait while it wanked its
way through a bunch of hardware dinking.
Another story I liked was where one individual wanted a particular
file from a backup tape but the tape was written out in a format that
only allowed for bulk dumps, not incremental or selective ones. He
could have hacked up a utility to scan the tape and read out the
particular file he wanted, which would have entailed a lot of work as
well as a thorough understanding of the storage format. Instead a
much quicker solution was to start the bulk dump, drop into the
debugger with a magic incantation, step through the dump code until
the tape index was read, read through the index until he found the
particular file, then manipulate the arguments to the dumping function
so it skipped over all the tape blocks until it hit the location of
the desired file. At that point the dumper ran for a while and when
the file was extracted the guy again dropped into the debugger and
killed the dumping function and went back to normal operation. File
recovered, the rest of the contents of the tape untouched, and total
elapsed time was about five or ten minutes rather than the hours it
would have taken to write the appropriate utilities.
Anyhow, there's really no easy way to describe a Lisp Machine
environment. Pictures don't do them justice because they predate the
days of cheap high resolution color monitors, so everything is as
black-and-white as a Mac Plus. But unlike a Macintoy, a Lispm was not
made for "the rest of us". It was made for programmers, for power
users, for *hackers*. Every aspect of the system could be probed,
poked, and prodded without concerns of confusing ordinary users. Not
terribly user-friendly, but it wasn't intended to be used by 'mere
users'. Indeed, you basically *had* to know Lisp to even begin to use
the thing, since the shell was just a glorified Lisp interpreter. A
computer made for people who understood computers, not a computer made
for mass marketing and target audiences.
Even today there are a considerable number of Lispm users who do
nearly all of their development activities on Lisp machines,
regardless of what type of computer or operating system the end result
is supposed to run on. Even to the point of hacking up crude
emulations of the target system for quick testing turnaround. The
development environment of a Lisp machine is incomparable. There has
never been another environment that even began to approach the
capability, transparency, customizability, and programmability of the
Lisp machine. And the pathetic thing is to see how many 'modern'
systems are simply reinterpretations or rediscoveries of software and
designs that were pioneered with Lisp machines.
'james
(Oh, and by the way the Lispms didn't use CL natively. Due to
historical reasons the Symbolics Lispm used around six different Lisp
dialects, depending on how you define the term 'dialect'. CL
postdates the Lisp machines, which either ran a variant of MIT MACLisp
called 'Lisp Machine Lisp' or 'Zetalisp', or otherwise ran some flavor
of Interlisp. CL was an afterthought. Genera provided a couple
different types of CL as well, with different levels of compliance to
different standards.)
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
From: Kent M Pitman
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <sfwn0j7bkzb.fsf@shell01.TheWorld.com>
·····@unlambda.com (James A. Crippen) writes:
> The entire *point* of a Lisp Machine is that it is written entirely in
> Lisp. *ALL* *OF* *IT*. From the boot code all the way up to the
> GUI.
A minor correction here (and also matter of personal opinion, of course):
It's important that it uses Lisp data, that it uses the Lisp stack
conventions, etc. Lisp Machines did have implementations of Fortran
and other languages (Pascal and Ada, I think)--not used much, but
could have been without it upsetting the plan, because those
implementations used Lisp (tagged) data rather than Lisp using
untagged machine data. But the point is that it all compiled down to
data that was executed by a Lisp-savvy microcode and/or hardware
(depending on processor). And even then, it's not so much that it was
Lisp but that it was (a) all uniform and (b) tagged-pointer-based.
This means uniform conventions for finding source code, uniform
conventions for interpreting and displaying data, etc.
Incidentally, on Symbolics systems, there were pre-loaded in the same
address space interpreters and/or compilers for about 5 syntactically
and sometimes semantically incompatible dialects of Lisp that were running
in the same address space. What _was_ compatible was the data formats,
so these dialects could cross-call.
I emphasize the multilingual issue because if you want to see a non-Lisp
example, you're better off going to MIT Multics, which was a pretty true PL/1
machine that again was pointer-based and again had cross-language stack
formats and a more uniform theory of data layout. The Lisp Machine was a
much better rendition of the idea done by some of the same people.
(Multics also had security, for those of you who think it can't be done.
LispMs just didn't WANT security at the machine/OS level, other than simple
data integrity as through tagged pointers. It wasn't that they couldn't
have had security inside this paradigm...)
And a few other remarks to extend some of your examples:
One important reason that pointer-based everything was important is
that often you could have multiple versions of things loaded. This
would be a nightmare in a text-based system because you wouldn't
remember which functions were which versions. In debugging Symbolics
Macsyma while porting it to Common Lisp, I used to load one copy of
Macsyma (written in Zetalisp), rename its packages, and then load
another copy (written in Common Lisp). Then I could run functions
that compared results of one version to results of another in the same
address space. (Macsyma was not designed for external calling, so
calling a separate program image as on a conventional processor wasn't
really an option.)
The line between system programming and user-programming was totally
blurred, which was double-edged. I once found a user who had crashed
their machine by redefining the Zetalisp TIME function, which was used
for the system clock. (They'd dont a DEFSTRUCT with no conc-name, and
one of the accessors clobbered the system function.) Being able to
redefine system stuff was useful in the right hands, but not always
perfect for novices. Then again, I was able to rescue the system by
opening the manual and reading what time did. It seemed to just
increment some integer every second. So I did APROPOS for other
functions that were time related and found SI:FIXNUM-MICROSECOND-TIME
and made a variable to store some arbitrary base time (using DEFVAR,
not system patching magic) and I made a function to add that base time
to 1000000 times the result of the other function (using DEFUN, not
some system patching magic). Then I told the debugger to proceed
using the new definition of TIME. The system came back up (although
the mode line said it was idle for several thousand years--itself a
remarkable thing, since the system was tolerant of the calendar time
having changed in ways I'm sure the designers didn't intend, probably
well exceeding some column number they'd expected to use). I told the
user to save his files and boot, with a better definition, though I
could just as well have said to grab the system source for TIME and
just c-sh-C (compile definition) that one function--I wasn't sure what
else they might have broken, and figured for them a reboot was good.
For more sophisticated users, we used to use the same address space to
develop and debug for often periods of 3-6 months without booting. This
is not just a server running in steady state mode--this is a developer
continually redefining and reloading and patching elements of the operating
system and producing production quality code in a continuously available
address space.
From: Frank A. Adrian
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <Be8ja.116$uo6.181286@news.uswest.net>
Kent M Pitman wrote:
> The line between system programming and user-programming was totally
> blurred, which was double-edged. I once found a user who had crashed
> their machine by redefining the Zetalisp TIME function, which was used
> for the system clock.
Yes. As always, the ability to dynamically change the environment is a
mixed blessing. I've often cruched an image in Smalltalk systems and am
just getting to the point on my lisp machine where I can experience the
same joy :-).
It still doesn't seem to me that many of the folks around here understand
just how important it is that the Lispiness of the system goes way past the
software level and down into the hardware. One could achieve the same feel
of a Lisp machine by building a LAP-like compiler for an Intel chip, and
coding the compiler, GC, device drivers, scheduler, etc. in Lisp. And, for
99.9% of hackers out there, that would be sufficient. But in the end, the
code at the bottom would still look like a set of x86 code and the mapping
from Lisp constructs into this code would be non-obvious and be a
conceptual hazard. This is why the hardware constructs at the bottom of
the hierarchy are so important. You know that some crappy pointer access
in the middle of the emulation of the PLUS instruction is going to blow you
out of the Lisp world and into the x86 world. Not that this sort of thing
couldn't occur in the lisp machine world - you could always hit a crummy
bit of microcode. But in the end, the microcode still made sense in the
context of a single Lisp instruction. This would not be the case in the
emulated environment because most compiler writers wouldn't stop
optimization at the Lisp-op level - they'd always be tempted to mush Lisp
operations together to make things run faster and, when something went
wrong - BAM! - your face is pushed into a bunch of random x86 code again,
most of which represent a mishmash of overlapping Lisp instructions. And
that, my friends, would just suck...
faa
From: Joe Marshall
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <he9eb6fz.fsf@ccs.neu.edu>
"Frank A. Adrian" <·······@ancar.org> writes:
> You know that some crappy pointer access in the middle of the
> emulation of the PLUS instruction is going to blow you out of the
> Lisp world and into the x86 world. Not that this sort of thing
> couldn't occur in the lisp machine world - you could always hit a
> crummy bit of microcode. But in the end, the microcode still made
> sense in the context of a single Lisp instruction.
Not a problem. You simply go to the other Lisp processor on the bus,
look at the microcode backtrace and history buffer of the halted
processor, repair the bad data and restart the other processor. If
you are lazy, you could simply restart the other processor at the
ZMACS::SAVE-ALL-BUFFERS function and reboot.
Joe Marshall <···@ccs.neu.edu> writes:
> "Frank A. Adrian" <·······@ancar.org> writes:
>
>> You know that some crappy pointer access in the middle of the
>> emulation of the PLUS instruction is going to blow you out of the
>> Lisp world and into the x86 world. Not that this sort of thing
>> couldn't occur in the lisp machine world - you could always hit a
>> crummy bit of microcode. But in the end, the microcode still made
>> sense in the context of a single Lisp instruction.
>
> Not a problem. You simply go to the other Lisp processor on the bus,
> look at the microcode backtrace and history buffer of the halted
> processor, repair the bad data and restart the other processor. If
> you are lazy, you could simply restart the other processor at the
> ZMACS::SAVE-ALL-BUFFERS function and reboot.
Ugh. That's like cheating. You're supposed to figure out what
happened and cuss out the guy who did it, not cheat and have Zmacs
sweep the problem under the carpet.
I think another interesting thing about the LispMs was their
community. Most people had some sort of way to complain to the people
who wrote the code. It might have been through commercial support or
because the guy was down the hall. And the users often had the
knowledge to explain the bug and fix it and then browbeat the
instigator. That's something that isn't very common anymore, and is a
reflection of the high level of competence of LispM hackers.
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
·····@unlambda.com (James A. Crippen) writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
> I think another interesting thing about the LispMs was their
> community. Most people had some sort of way to complain to the people
> who wrote the code. It might have been through commercial support or
> because the guy was down the hall. And the users often had the
> knowledge to explain the bug and fix it and then browbeat the
> instigator. That's something that isn't very common anymore, and is a
> reflection of the high level of competence of LispM hackers.
And just think about the incentive for high quality code:
User: You dolt you call this code acceptable?!?!?! Look at
all these bugs and how easy they were to fix. Go give
back your last paycheck, you do not deserve it. ;-)
marc
In article <··············@kappa.unlambda.com>,
James A. Crippen <·····@unlambda.com> wrote:
>I think another interesting thing about the LispMs was their
>community. Most people had some sort of way to complain to the people
>who wrote the code. It might have been through commercial support or
>because the guy was down the hall. And the users often had the
>knowledge to explain the bug and fix it and then browbeat the
>instigator. That's something that isn't very common anymore, and is a
>reflection of the high level of competence of LispM hackers.
It's also a reflection of the relatively small size of the LispM
community. It's easy for a vendor to provide intimate technical support
to a small customer base. When you have many thousands of customers, you
can't afford to let them all contact the developers directly.
We had similar intimate relationships between customers and vendors when I
worked for Honeywell on Multics, and when I worked at Thinking Machines.
Both had under 100 customers, and targeted very sophisticated customers.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Gorbag
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <BAB32239.27F6%gorbagNOSPAM@NOSPAMmac.com>
On 4/3/03 9:54 PM, in article ····················@news.uswest.net, "Frank
A. Adrian" <·······@ancar.org> wrote:
> It still doesn't seem to me that many of the folks around here understand
> just how important it is that the Lispiness of the system goes way past the
> software level and down into the hardware.
While having turtles "all the way down" has some advantages, don't
overemphasize it relative to the importance of just having the editor,
shell, scheduler (for the machine, not just your threads) etc. all part of
the same lisp world. I know my productivity was far more enhanced by having
a genuine single-user environment and single address space (while still
supporting multi-processing and indeed deadline scheduling in later versions
of Genera) than it was by the device drivers also happening to be in Lisp.
At some point, I'd dump a stack trace and forward it to HOSS, not try to
debug every low-level microcode interaction bug. (Thanks, though, to folks
like Barry who often did!).
Gorbag <············@NOSPAMmac.com> writes:
> At some point, I'd dump a stack trace and forward it to HOSS, not try to
> debug every low-level microcode interaction bug. (Thanks, though, to folks
> like Barry who often did!).
Most important was the fact that the machine was always functioning
enough to *get* a stack trace in digital form so that it could be
forwarded. Garbage like one does with a hosed Windows box, copying
down arcane hex runes on a notepad because the machine is so borken
that all it can do is display, that's something I don't appreciate
despite all the increases in power.
I once screwed up my LispM so badly that any time I moved the mouse
the debugger would crash -- into the debugger. I still managed to get
it functioning again by tracing down to where things blew up,
restarting before that point, and then restarting again to the Lisp
listener. This of course left some crud lying around on the stack but
it got me to a point where I could save my work (screwing with the
FEPFS code) and restart. I still have no idea what I did to break it
though.
Can't do that when Windows or Unix craps itself. And I really like
the fact that I can always drop to the FEP, poke provocatively at a
memory address, and then go back to the running system for more
damage.
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
"Frank A. Adrian" <·······@ancar.org> writes:
> Yes. As always, the ability to dynamically change the environment is a
> mixed blessing. I've often cruched an image in Smalltalk systems and am
> just getting to the point on my lisp machine where I can experience the
> same joy :-).
One day, I hope to combine Lisp-style "hacking the running process"
with POSIX fork() -- so that you can test things in a copy of the
process first. (This is not trivial in the cases I'm interested in
because they involve a lot of networking.)
> This would not be the case in the emulated environment because most
> compiler writers wouldn't stop optimization at the Lisp-op level -
> they'd always be tempted to mush Lisp operations together to make
> things run faster and, when something went wrong - BAM! - your face
> is pushed into a bunch of random x86 code again, most of which
> represent a mishmash of overlapping Lisp instructions. And that, my
> friends, would just suck...
Even if you renounce optimization for that reason, such x86 code would
probably run faster than any Lisp processor you could afford to build.
Florian Weimer <··@deneb.enyo.de> writes:
> "Frank A. Adrian" <·······@ancar.org> writes:
>
> > This would not be the case in the emulated environment because most
> > compiler writers wouldn't stop optimization at the Lisp-op level -
> > they'd always be tempted to mush Lisp operations together to make
> > things run faster and, when something went wrong - BAM! - your face
> > is pushed into a bunch of random x86 code again, most of which
> > represent a mishmash of overlapping Lisp instructions. And that, my
> > friends, would just suck...
>
> Even if you renounce optimization for that reason, such x86 code would
> probably run faster than any Lisp processor you could afford to build.
I just had a thought here, what about the transmeta(sp?) cpu? They
built an X86 tranlater in micro code.
marc
Marc Spitzer <········@optonline.net> writes:
>> Even if you renounce optimization for that reason, such x86 code would
>> probably run faster than any Lisp processor you could afford to build.
>
>
> I just had a thought here, what about the transmeta(sp?) cpu? They
> built an X86 tranlater in micro code.
Relying on Transmeta won't give you the technology to compete directly
with the x86ers. At least that's my conclusion based on the
observation that Transmeta can't compete with AMD or Intel in the
general x86 market.
In article <··············@deneb.enyo.de>,
Florian Weimer <··@deneb.enyo.de> wrote:
>Marc Spitzer <········@optonline.net> writes:
>
>>> Even if you renounce optimization for that reason, such x86 code would
>>> probably run faster than any Lisp processor you could afford to build.
>
>> I just had a thought here, what about the transmeta(sp?) cpu? They
>> built an X86 tranlater in micro code.
>
>Relying on Transmeta won't give you the technology to compete directly
>with the x86ers. At least that's my conclusion based on the
>observation that Transmeta can't compete with AMD or Intel in the
>general x86 market.
AFAIK, they never intended to take on that market. They've always said
that the reason they developed their technology was for the handheld
market, because the chip's design allows it to run on much less power than
typical CPUs.
But if your goal is to write an emulator for another chip, it seems like
doing it on the Transmeta architecture rather than on a general purpose CPU
would be better. Transmeta is designed for writing emulators on.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <··············@level3.com> writes:
> AFAIK, they never intended to take on that market. They've always said
> that the reason they developed their technology was for the handheld
> market, because the chip's design allows it to run on much less power than
> typical CPUs.
Yes, you are right, but to me it looks as if the Transmeta approach
didn't really work out and the PDA market is just some kind of exit
strategy. I mean, why do you want to design an x86-compatible PDA
processor? You have to rewrite most applications for the PDA anyway,
so instruction set compatibility is not a real benefit.
> But if your goal is to write an emulator for another chip, it seems like
> doing it on the Transmeta architecture rather than on a general purpose CPU
> would be better. Transmeta is designed for writing emulators on.
Unfortunately, as far as I know, the microcode platform completely
closed.
In article <··············@deneb.enyo.de>,
Florian Weimer <··@deneb.enyo.de> wrote:
>Barry Margolin <··············@level3.com> writes:
>
>> AFAIK, they never intended to take on that market. They've always said
>> that the reason they developed their technology was for the handheld
>> market, because the chip's design allows it to run on much less power than
>> typical CPUs.
>
>Yes, you are right, but to me it looks as if the Transmeta approach
>didn't really work out and the PDA market is just some kind of exit
>strategy. I mean, why do you want to design an x86-compatible PDA
>processor? You have to rewrite most applications for the PDA anyway,
>so instruction set compatibility is not a real benefit.
Yet there *are* handheld PC's running Windows and Windows applications,
which all require an x86-compatible CPU.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <··············@level3.com> writes:
> Yet there *are* handheld PC's running Windows and Windows applications,
> which all require an x86-compatible CPU.
Is the Libretto still around? The handheld PCs running WinCE aren't
generally x86 compatible. I think they're all StrongARM-based these
days.
--
Alan Shutko <···@acm.org> - I am the rocks.
Looking for a developer in St. Louis? http://web.springies.com/~ats/
He's got a magnet! Everyone BACKUP! - Data
Alan Shutko <···@acm.org> writes:
> Barry Margolin <··············@level3.com> writes:
>
> > Yet there *are* handheld PC's running Windows and Windows applications,
> > which all require an x86-compatible CPU.
>
> Is the Libretto still around? The handheld PCs running WinCE aren't
> generally x86 compatible. I think they're all StrongARM-based these
> days.
The 70, 90, 100, 110 are readily available on ebay- though they're
really only small laptops up to about a Pentium 233 or so. The 1000
and greater are a bit fancier- but still only laptops.
Gregm
Florian Weimer <··@deneb.enyo.de> writes:
> Marc Spitzer <········@optonline.net> writes:
>
> >> Even if you renounce optimization for that reason, such x86 code would
> >> probably run faster than any Lisp processor you could afford to build.
> >
> >
> > I just had a thought here, what about the transmeta(sp?) cpu? They
> > built an X86 tranlater in micro code.
>
> Relying on Transmeta won't give you the technology to compete directly
> with the x86ers. At least that's my conclusion based on the
> observation that Transmeta can't compete with AMD or Intel in the
> general x86 market.
Well if you are trying to build a lisp machine box you are not in
the general computing market. What you are trying to do, IMO, is to
create a very developer friendly box to help them get more work done.
Then you deploy to x86, sun, ...
marc
Marc Spitzer <········@optonline.net> writes:
> Florian Weimer <··@deneb.enyo.de> writes:
>
>> Marc Spitzer <········@optonline.net> writes:
>>
>> >> Even if you renounce optimization for that reason, such x86 code would
>> >> probably run faster than any Lisp processor you could afford to build.
>> >
>> >
>> > I just had a thought here, what about the transmeta(sp?) cpu? They
>> > built an X86 tranlater in micro code.
>>
>> Relying on Transmeta won't give you the technology to compete directly
>> with the x86ers. At least that's my conclusion based on the
>> observation that Transmeta can't compete with AMD or Intel in the
>> general x86 market.
>
> Well if you are trying to build a lisp machine box you are not in
> the general computing market. What you are trying to do, IMO, is to
> create a very developer friendly box to help them get more work done.
>
> Then you deploy to x86, sun, ...
In the later days of the LispMs that is exactly what they were used
for. It's obvious because of the improvement of non-LispM networking
support which flowered in the latter days; lots of Unix protocols
being implemented (NFS, VT100 emulator, X11, etc). Oddly, the
opposite was true in the early days of the CONS, where some other
machine (a DEC PDP-10 running ITS) was used to deploy to the LispM.
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
From: Martti Halminen
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <3E8C888B.6ED09691@kolumbus.fi>
Kent M Pitman wrote:
> Lisp Machines did have implementations of Fortran
> and other languages (Pascal and Ada, I think)
Also C (pre-ANSI).
--
From: Barry Margolin
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <tD1ja.17$jn5.1002@paloalto-snr1.gtei.net>
In article <·················@kolumbus.fi>,
Martti Halminen <···············@kolumbus.fi> wrote:
>Kent M Pitman wrote:
>
>> Lisp Machines did have implementations of Fortran
>> and other languages (Pascal and Ada, I think)
>
>Also C (pre-ANSI).
It was dpANS C.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <··············@level3.com> writes:
> In article <·················@kolumbus.fi>,
> Martti Halminen <···············@kolumbus.fi> wrote:
>>Kent M Pitman wrote:
>>
>>> Lisp Machines did have implementations of Fortran
>>> and other languages (Pascal and Ada, I think)
>>
>>Also C (pre-ANSI).
>
> It was dpANS C.
And it worked well enough to compile X11R5, which is a pretty decent
test of compiler verification.
Genera has an X server and an X client service. The server absolutely
loses, although it theoretically works. The client service (running X
clients outputting to some other machine) works pretty well, even
supporting 8bpp color.
The X servers were necessary for a VME bus card version of the
XL400/XL1200 that plugged into a Sun 3 system. Its terminal was the
Sun's X server. Later products included a standalone XL1201 box that
could be used in a similar manner without needing a head.
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
On 4/3/03 4:25 PM, in article ··············@kappa.unlambda.com, "James A.
Crippen" <·····@unlambda.com> wrote:
> Barry Margolin <··············@level3.com> writes:
>
>> In article <·················@kolumbus.fi>,
>> Martti Halminen <···············@kolumbus.fi> wrote:
>>> Kent M Pitman wrote:
>>>
>>>> Lisp Machines did have implementations of Fortran
>>>> and other languages (Pascal and Ada, I think)
>>>
>>> Also C (pre-ANSI).
>>
>> It was dpANS C.
>
> And it worked well enough to compile X11R5, which is a pretty decent
> test of compiler verification.
>
> Genera has an X server and an X client service. The server absolutely
> loses, although it theoretically works. The client service (running X
> clients outputting to some other machine) works pretty well, even
> supporting 8bpp color.
>
> The X servers were necessary for a VME bus card version of the
> XL400/XL1200 that plugged into a Sun 3 system. Its terminal was the
> Sun's X server. Later products included a standalone XL1201 box that
> could be used in a similar manner without needing a head.
Ah yes, the UX400. I had one of those plugged into a Sun-4. A pretty nice
system, that was substantially faster than the 3620 I had been using prior
to that... I continued to use it until the compile times on a
Sparcstation-20 blew it away by such a large margin that we switched to a
unix based lisp for further development.. Which turned out to be opportune
because we next hit the upper limits of CLIM and had to switch to Motif for
further UI development.
>
> 'james
In article <··············@kappa.unlambda.com>,
James A. Crippen <·····@unlambda.com> wrote:
>Barry Margolin <··············@level3.com> writes:
>
>> In article <·················@kolumbus.fi>,
>> Martti Halminen <···············@kolumbus.fi> wrote:
>>>Kent M Pitman wrote:
>>>
>>>> Lisp Machines did have implementations of Fortran
>>>> and other languages (Pascal and Ada, I think)
>>>
>>>Also C (pre-ANSI).
>>
>> It was dpANS C.
>
>And it worked well enough to compile X11R5, which is a pretty decent
>test of compiler verification.
IIRC, it worked *too* well to compile X11R4. It had lots of stuff that was
not valid in ANSI C. For instance, many functions for color displays took
an extra argument that the corresponding b&w functions didn't have; these
functions would be called generically through a dispatch vector, and the
caller would pass the extra argument. Traditional Unix compilers would
just ignore extra arguments, but the Lispm would signal a "wrong number of
arguments" error. We had to find all those functions and add an extra
"ignore" argument to them (which then resulted in lots of "unused variable"
warnings at compile time -- C doesn't have anything like (declare (ignore
...))).
>Genera has an X server and an X client service. The server absolutely
>loses, although it theoretically works. The client service (running X
>clients outputting to some other machine) works pretty well, even
>supporting 8bpp color.
I remember using both, and I agree with your assessment. For the last year
or so that I was using Lispms, I was also working Suns heavily, so I
replaced the Lispm display on my desktop with an X terminal, and displayed
my Lispm desktop on it. It worked very well -- the only time I needed to
use the real console was to access the FEP (we had 36xx Lispms, not Ivory).
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Martti Halminen <···············@kolumbus.fi> writes:
>> Lisp Machines did have implementations of Fortran
>> and other languages (Pascal and Ada, I think)
> Also C (pre-ANSI).
BTW, I seem to remember that there were two versions of a C compiler
for Genera; the newer one directly compiled to microcode, while the
older compiled to Lisp. If this is not completly wrong (which it may
well be), I hereby promise most-positive-fixnum coolness points for
the first one to use the older approach to implement an FFI-ersatz for
a modern CL. :)
Regards
Henrik
In article <··············@interim.henrik-motakef.de>,
Henrik Motakef <··············@web.de> wrote:
>Martti Halminen <···············@kolumbus.fi> writes:
>
>>> Lisp Machines did have implementations of Fortran
>>> and other languages (Pascal and Ada, I think)
>> Also C (pre-ANSI).
>
>BTW, I seem to remember that there were two versions of a C compiler
>for Genera; the newer one directly compiled to microcode, while the
>older compiled to Lisp. If this is not completly wrong (which it may
>well be), I hereby promise most-positive-fixnum coolness points for
>the first one to use the older approach to implement an FFI-ersatz for
>a modern CL. :)
I don't think there was one that compiled to microcode -- I think you mean
it compiled directly to machine code, just like the Lisp compiler. That
was the one that Symbolics wrote.
The other compiler was ZETA-C, written by a non-Symbolics person, whose
name I don't remember.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Donald Fisk
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <3E8D850D.140A0C31@enterprise.net>
Martti Halminen wrote:
>
> Kent M Pitman wrote:
>
> > Lisp Machines did have implementations of Fortran
> > and other languages (Pascal and Ada, I think)
>
> Also C (pre-ANSI).
Also Prolog, at least on Symbolics Genera.
Le Hibou
--
In any large organization, mediocrity is almost by definition
an overwhelming phenomenon; the systematic disqualification
of competence, however, is the managers' own invention, for
the sad consequences of which they should bear the full blame.
-- Edsger W. Dijkstra, 1986.
From: Barry Margolin
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <Lohja.2$cO1.432@paloalto-snr1.gtei.net>
In article <··············@cupid.igpm.rwth-aachen.de>,
Mario S. Mommer <········@yahoo.com> wrote:
>Donald Fisk <················@enterprise.net> writes:
>> Martti Halminen wrote:
>> > Kent M Pitman wrote:
>> >
>> > > Lisp Machines did have implementations of Fortran
>> > > and other languages (Pascal and Ada, I think)
>> >
>> > Also C (pre-ANSI).
>>
>> Also Prolog, at least on Symbolics Genera.
>
>Did they have a BASIC interpreter?
I think someone at Thinking Machines wrote a *BASIC implementation that ran
on the Lispm/Connection Machine combination.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Barry Margolin
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <2yhja.3$cO1.556@paloalto-snr1.gtei.net>
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
>The line between system programming and user-programming was totally
>blurred, which was double-edged. I once found a user who had crashed
>their machine by redefining the Zetalisp TIME function, which was used
>for the system clock.
And we once crashed the system with something analogous to:
(setq some-variable t)
(set some-variable nil)
thus creating a 1984-ish environment where truth is falsehood, and all hell
breaks loose.
SETQ had a special check for the first argument being T or NIL (like
Maclisp's "Veritas Aeternas" error), but SET didn't. In the next release
the value cell of T was moved to a read-only page.
You could also seriously screw things up by tracing functions that were
used to implement TRACE, e.g. (trace prin1). Lispms gave you plenty of
rope to hang yourself with, but the benefits outweighed the costs
significantly.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <··············@level3.com> writes:
> You could also seriously screw things up by tracing functions that were
> used to implement TRACE, e.g. (trace prin1). Lispms gave you plenty of
> rope to hang yourself with, but the benefits outweighed the costs
> significantly.
The beauty of it was that hanging yourself was always entertaining and
you usually learned something valuable during the experience. Much
less frustrating than staring at a blue screen full of hex, or a
"segmentation violation" message and a pile of rotten bits.
Friendly debuggers had a lot to do with this level of user experience,
I think.
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
From: Tim Bradshaw
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <ey3he9ghvg0.fsf@cley.com>
* Andrew Reilly wrote:
> So, it's different because it uses CL instead of elisp?
No. It's different because in Genera everything was an object, even
though much of it looked like text, while in Emacs everything is text,
even though some of it looks like objects. It really matters.
--tim
From: Ketil Malde
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <egd6k4dpn2.fsf@sefirot.ii.uib.no>
······@math.bme.hu (Simon Andr�s) writes:
> Andrew Reilly <······@gurney.reilly.home> writes:
>> I clearly don't understand some subtle advantage of this Genera
>> system. In what sense is it /different/ from emacs? Is it just the
>> dialect of lisp involved that's at question?
> http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/genera/genera.html
Is there a version of this document that is updated a bit? I mean,
we know about garbage collection these days. Clicking on director names
to see what's inside is also not too new. How does it compare to a
modern Lisp system running on a modern OS?
More specific question: how is security achieved, when everything's
open, and communciation is done through unrestricted, shared objects?
The reasons given doesn't sound very convincing, looking from a
malicious user perspective.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
In article <··············@sefirot.ii.uib.no>,
"Ketil Malde" <······@ii.uib.no> wrote:
> ······@math.bme.hu (Simon Andr�s) writes:
>
> > Andrew Reilly <······@gurney.reilly.home> writes:
>
> >> I clearly don't understand some subtle advantage of this Genera
> >> system. In what sense is it /different/ from emacs? Is it just the
> >> dialect of lisp involved that's at question?
>
> > http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/genera/gen
> > era.html
>
> Is there a version of this document that is updated a bit? I mean,
> we know about garbage collection these days. Clicking on director names
> to see what's inside is also not too new.
On the other hand, clicking on a function name to see and potentially
edit its definition, find the names of all the other functions that call
it, and inspect (and potentially edit) the stack frames of all currently
running invocatons of that function is kinda cool. Especially when it's
just a single mouse click to find the function/variable/whatever behind
any object or piece of text on the screen.
In my (very very very) limited experience the integration of language,
OS and IDE provides significant advantages over even most modern Lisp
IDEs on conventional OS's because you don't suddenly run into some
opaque block of code or binary data when you're following the path of
how something works (or doesn't).
paul
From: Christopher C. Stacy
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <uk7eb5peh.fsf@dtpq.com>
>>>>> On 03 Apr 2003 09:08:33 +0200, Ketil Malde ("Ketil") writes:
Ketil> More specific question: how is security achieved, when everything's
Ketil> open, and communciation is done through unrestricted, shared objects?
Ketil> The reasons given doesn't sound very convincing, looking from a
Ketil> malicious user perspective.
It's a single-user system and there is no protecting the
user from himself, if he decides to be self-malicious.
Christopher C. Stacy wrote:
>>>>>> On 03 Apr 2003 09:08:33 +0200, Ketil Malde ("Ketil") writes:
> Ketil> More specific question: how is security achieved, when
> everything's Ketil> open, and communciation is done through
> unrestricted, shared objects? Ketil> The reasons given doesn't sound
> very convincing, looking from a Ketil> malicious user perspective.
>
> It's a single-user system and there is no protecting the user from
> himself, if he decides to be self-malicious.
System protections[1] aren't there for users. They are there to protect
various resources from *programs*. Users may or may not be somewhere
behind some program that happened to call a chain of dozen others, but
that has nothing to do with things. Neither has this hypothetical
creature's intentions. It's all about programs for any system.
[1] No, you never protect. You just allow. What is not allowed
(=implemented) is impossible. There is no concept "protect".
From: Christopher C. Stacy
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <uy92keapw.fsf@dtpq.com>
>>>>> On Wed, 09 Apr 2003 01:53:21 +0300, Harri Haataja ("Harri") writes:
Harri> Christopher C. Stacy wrote:
>>>>>>> On 03 Apr 2003 09:08:33 +0200, Ketil Malde ("Ketil") writes:
Ketil> More specific question: how is security achieved, when
>> everything's open, and communciation is done through
>> unrestricted, shared objects? The reasons given doesn't sound
>> very convincing, looking from a malicious user perspective.
>>
>> It's a single-user system and there is no protecting the user from
>> himself, if he decides to be self-malicious.
Harri> System protections[1] aren't there for users. They are there to protect
Harri> various resources from *programs*. Users may or may not be somewhere
Harri> behind some program that happened to call a chain of dozen others, but
Harri> that has nothing to do with things. Neither has this hypothetical
Harri> creature's intentions. It's all about programs for any system.
You are the one who began the conversation with the phrase
"malicous user", so naturally I addressed your specific concern.
Now you're saying that the problem is not "users" at all.
Can you please give a specific example of what you're afraid of?
The Lisp Machine, rather surprisingly to people who are unfamiliar
with it, did not in reality experience the kinds of problems that
I think you are worrying about. My personal experience with the
design of secure computing systems goes back 24 years, but I would
like you to elaborate, since you are so insistent that there must
be a terrible problem here. Perhaps we can walk through some examples
to show why the this was, in practice, not a problem on the LispM.
From: ····@sonic.net
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <3E93987C.3343169E@sonic.net>
"Christopher C. Stacy" wrote:
> You are the one who began the conversation with the phrase
> "malicous user", so naturally I addressed your specific concern.
> Now you're saying that the problem is not "users" at all.
> Can you please give a specific example of what you're afraid of?
> The Lisp Machine, rather surprisingly to people who are unfamiliar
> with it, did not in reality experience the kinds of problems that
> I think you are worrying about. My personal experience with the
> design of secure computing systems goes back 24 years, but I would
> like you to elaborate, since you are so insistent that there must
> be a terrible problem here. Perhaps we can walk through some examples
> to show why the this was, in practice, not a problem on the LispM.
Bear in mind that during the period under discussion, there was also
no problem with SMTP and no problem with FTP. The users of these
machines were largely either professionals, academics, or military.
Access to them was expensive and monitored carefully, so they
largely didn't have to deal with malicious users. These people
were not regarded as a general market segment yet, so there was
no spam and no financial motive to subvert remote machines for
purposes of sending spam. No secondary market for personal information
to use in targeted advertising had yet emerged, so there was no
financial motive for software developers to embed spyware or other
malicious code in the programs. And "script kiddies" had not yet
emerged either, nor had industry associations with herds of lawyers
available yet employed darkside hackers to start trying to take
down machines and network segments whose network traffic they
didn't like.
A modern LispM would face a very different environment in terms of
what type of users it was available to. Given the new motivations
of users and developers, and would need much different defenses
against malicious users and malicious code. I think the separate
memory spaces and permission controls of a UNIX type system are an
absolute minimum for anything that's going to be connected to the
net these days. Buffer overruns and stack screws can't happen in
LISP, but if you put something on the net, it will have to deal
with all the hostility that anyone can throw at it.
Bear
From: Joe Marshall
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <8yujztyq.fsf@ccs.neu.edu>
····@sonic.net writes:
> A modern LispM would face a very different environment in terms of
> what type of users it was available to. Given the new motivations
> of users and developers, and would need much different defenses
> against malicious users and malicious code. I think the separate
> memory spaces and permission controls of a UNIX type system are an
> absolute minimum for anything that's going to be connected to the
> net these days. Buffer overruns and stack screws can't happen in
> LISP, but if you put something on the net, it will have to deal
> with all the hostility that anyone can throw at it.
www.whitehouse.gov was running CL-HTTP on a Symbolics machine
*outside* the firewall for many years. It was never broken into and
not for lack of trying.
It is true that the vast majority of crackers and script kiddies
wouldn't know where to begin to attack the server, and presumably the
vulnerabilities would be better known if the hardware and software
were more popular, but the immediate evidence indicates that a LispM
running CL-HTTP in a shared address space is far more secure than your
average Apache or IIS installation running in a separate one.
From: Kent M Pitman
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <sfwof3fbxdb.fsf@shell01.TheWorld.com>
[ replying to comp.lang.lisp only
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
Joe Marshall <···@ccs.neu.edu> writes:
> It is true that the vast majority of crackers and script kiddies
> wouldn't know where to begin to attack the server, and presumably the
> vulnerabilities would be better known if the hardware and software
> were more popular,
Ah. Maybe these crackers are C programmers out to make a name for
themselves and afraid Lisp will look bad on the resume... ;)
Hmmm... With the kind of spontaneous "can't do" attitudes that Lisp
mysteriously evokes among programmers of other languages, maybe Lisp's
killer-app-in-waiting is servers for more fundamental reasons than
mere handling of buffer overruns.
From: Florian Weimer
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87istnivax.fsf@deneb.enyo.de>
Kent M Pitman <······@world.std.com> writes:
> Hmmm... With the kind of spontaneous "can't do" attitudes that Lisp
> mysteriously evokes among programmers of other languages, maybe Lisp's
> killer-app-in-waiting is servers for more fundamental reasons than
> mere handling of buffer overruns.
I hope that Lisp gives me the productivity to reimplement all the
stuff I need for my security-critical applications. More "imperative"
programming language options ("traditional" isn't the right word after
all) were as good as Lisp from a buffer overflow perspective (if not
better), but rewriting all this infrastructure stuff is *so* much work
if you want to do it properly.
From: Florian Weimer
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87ptnviybq.fsf@deneb.enyo.de>
Joe Marshall <···@ccs.neu.edu> writes:
> It is true that the vast majority of crackers and script kiddies
> wouldn't know where to begin to attack the server, and presumably the
> vulnerabilities would be better known if the hardware and software
> were more popular, but the immediate evidence indicates that a LispM
> running CL-HTTP in a shared address space is far more secure than your
> average Apache or IIS installation running in a separate one.
Garfinkel and Spafford recommended to run web servers on MacOS (not X)
back in 1996:
| Because of the richness of its tools, the plethora of programming
| languages, and the ability of multiple users to be logged in at the
| same time from remote sites over a network, the UNIX operating
| system is a remarkably bad choice for running secure Web servers.
| Because many PC-based operating systems share many of these
| characteristics, they are also not very good choices. Experience
| has shown that the most secure Web server is a computer that runs a
| Web server and no other applications, that does not have a readily
| accessible scripting language, and that does not support remote
| logins. In practice, this describes an Apple Macintosh computer
| running MacHTTP, WebStar, or a similar Web server. According to
| recent surveys, such computers comprise as many as 15% of the Web
| servers on the Internet.
(Pre-X MacOS didn't even a decent virtual memory management, and no
process separation. 8-)
From: Sander Vesik
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <1049914954.346746@haldjas.folklore.ee>
In comp.arch Florian Weimer <··@deneb.enyo.de> wrote:
> | Because of the richness of its tools, the plethora of programming
> | languages, and the ability of multiple users to be logged in at the
> | same time from remote sites over a network, the UNIX operating
> | system is a remarkably bad choice for running secure Web servers.
> | Because many PC-based operating systems share many of these
> | characteristics, they are also not very good choices. Experience
> | has shown that the most secure Web server is a computer that runs a
> | Web server and no other applications, that does not have a readily
> | accessible scripting language, and that does not support remote
> | logins. In practice, this describes an Apple Macintosh computer
> | running MacHTTP, WebStar, or a similar Web server. According to
> | recent surveys, such computers comprise as many as 15% of the Web
> | servers on the Internet.
>
> (Pre-X MacOS didn't even a decent virtual memory management, and no
> process separation. 8-)
Yeah, now imagine a buffer overrun in a cgi and what the result is 8-)
But I think there are enough problems also around efficent support
for multi-stream i/o that these OSs have traditionaly been lousy on.
Also 'no remote logins' makes administration so much more painful and
costly.
--
Sander
+++ Out of cheese error +++
From: Florian Weimer
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87istne62i.fsf@deneb.enyo.de>
Sander Vesik <······@haldjas.folklore.ee> writes:
> Yeah, now imagine a buffer overrun in a cgi and what the result is 8-)
Well, back in 1996, there weren't any worms, and the crackers were
after decent platforms. 8-)
Consumer Windows boxes are pretty much in the same boat today, and
they *are* targeted heavily. Sure, most home users haven't really
fast Internet connections, but a botnet of a few thousand bots can
wreck a lot of havoc, no matter how much the individual hosts can
contribute.
> But I think there are enough problems also around efficent support
> for multi-stream i/o that these OSs have traditionaly been lousy on.
MacOS is very good at two-stream I/O.
(Yeah, I know, you meant something else. 8-)
> Also 'no remote logins' makes administration so much more painful and
> costly.
If MacOS was more interesting, we had stuff like Back Orifice for it.
Florian Weimer <··@deneb.enyo.de> wrote:
> Well, back in 1996, there weren't any worms, and the crackers were
> after decent platforms. 8-)
Nice rose-tinted glasses that you have there. Nostalgiavision?
From: Pascal Bourguignon
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87u1d7o80o.fsf@thalassa.informatimago.com>
Joe Marshall <···@ccs.neu.edu> writes:
> ····@sonic.net writes:
>
> > A modern LispM would face a very different environment in terms of
> > what type of users it was available to. Given the new motivations
> > of users and developers, and would need much different defenses
> > against malicious users and malicious code. I think the separate
> > memory spaces and permission controls of a UNIX type system are an
> > absolute minimum for anything that's going to be connected to the
> > net these days. Buffer overruns and stack screws can't happen in
> > LISP, but if you put something on the net, it will have to deal
> > with all the hostility that anyone can throw at it.
>
> www.whitehouse.gov was running CL-HTTP on a Symbolics machine
> *outside* the firewall for many years. It was never broken into and
> not for lack of trying.
>
> It is true that the vast majority of crackers and script kiddies
> wouldn't know where to begin to attack the server, and presumably the
> vulnerabilities would be better known if the hardware and software
> were more popular, but the immediate evidence indicates that a LispM
> running CL-HTTP in a shared address space is far more secure than your
> average Apache or IIS installation running in a separate one.
Web servers running on MacOS (not MacOSX) with a shared address space
too are deemed quite secure too. The absence of a "shell" running on
the OS seemed to be helpful.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
Pascal Bourguignon <···@informatimago.com> wrote in message news:<··············@thalassa.informatimago.com>...
> Joe Marshall <···@ccs.neu.edu> writes:
>
> > ····@sonic.net writes:
> >
> > > A modern LispM would face a very different environment in terms of
> > > what type of users it was available to. Given the new motivations
> > > of users and developers, and would need much different defenses
> > > against malicious users and malicious code. I think the separate
> > > memory spaces and permission controls of a UNIX type system are an
> > > absolute minimum for anything that's going to be connected to the
> > > net these days. Buffer overruns and stack screws can't happen in
> > > LISP, but if you put something on the net, it will have to deal
> > > with all the hostility that anyone can throw at it.
> >
> > www.whitehouse.gov was running CL-HTTP on a Symbolics machine
> > *outside* the firewall for many years. It was never broken into and
> > not for lack of trying.
> >
> > It is true that the vast majority of crackers and script kiddies
> > wouldn't know where to begin to attack the server, and presumably the
> > vulnerabilities would be better known if the hardware and software
> > were more popular, but the immediate evidence indicates that a LispM
> > running CL-HTTP in a shared address space is far more secure than your
> > average Apache or IIS installation running in a separate one.
>
> Web servers running on MacOS (not MacOSX) with a shared address space
> too are deemed quite secure too. The absence of a "shell" running on
> the OS seemed to be helpful.
A friend of mine uses an old Apollo DN10K workstation (for those of
you who remember the DN10K) as his firewall/mailserver. He derives
great amusement watching 31337 haxorz trying to deal with this
machine. He hasn't be hacked yet...
Is the defense something innate to the system, or just using an
obscure enough machine that the black hat community isn't set up to
deal with it?
Brian
From: Rupert Pigott
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <1049930404.372248@saucer.planet.gong>
"Brian Hurt" <·····@spnz.org> wrote in message
·································@posting.google.com...
[SNIP]
> A friend of mine uses an old Apollo DN10K workstation (for those of
> you who remember the DN10K) as his firewall/mailserver. He derives
> great amusement watching 31337 haxorz trying to deal with this
> machine. He hasn't be hacked yet...
I'd love to have a DN10000. :/
> Is the defense something innate to the system, or just using an
> obscure enough machine that the black hat community isn't set up to
> deal with it?
Depends on what it's running I suspect. Domain/OS
could run BSD and AIX personalities and had a sort
of Multics inspired feel to it - AFAICT. I would
not be surprised if someone has ported NetBSD to it
too. I haven't had the chance of playing with one,
more is the pity. :(
I really don't trust security by obscurity, but it
may just be difficult enough that a casual cracker
won't bother with it after discovering none of the
skr1ptz work and he can't find any 5pl017z for it
in the vulnerability databases.
Cheers,
Rupert
From: Toon Moene
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <3E95E36B.20701@moene.indiv.nluug.nl>
Brian Hurt wrote:
> A friend of mine uses an old Apollo DN10K workstation (for those of
> you who remember the DN10K) as his firewall/mailserver. He derives
> great amusement watching 31337 haxorz trying to deal with this
> machine. He hasn't be hacked yet...
I recall reading about someone who installed the Hercules IBM/360
emulator on his Linux system and running (Debian) Linux/360 on that.
He installed and started Apache on the emulated Linux and tried it.
Thinking about it, he just let it run that way - it surely wouldn't be
hacked :-)
--
Toon Moene - ···········@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)
From: Tom Knight
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <vuy65pnqrst.fsf@suspiria.ai.mit.edu>
The stability of the Lisp Machine was due in large part to fundamental
issues of language design. In Lisp, you can't reference an object in
memory unless you have a pointer to the object. You can't reference
outside of the array bounds of an array. Buffer overflow attacks
essentially are impossible. The result is that it is VERY easy to
write code which is bullet-proof compared to essentially any other
system. All you have to do is control who has access to pointers, and
who gets to hand out the pointers. As usual, there are
"sub-primitive" operations which allow users to do things out of the
box, but it is a relatively straightforward check to assure that none
of those primitives are used in code (the names by convention began
with a % symbol). While we did not attempt to make highly secure
operating systems, the security of the resulting systems was very high
compared to the junk we see palmed off as software today.
Eventually, I suppose, we'll get back to that point again. Anyone who
would like to help, let me know.
Christopher C. Stacy wrote:
>>>>>> On Wed, 09 Apr 2003 01:53:21 +0300, Harri Haataja ("Harri") writes:
> Harri> Christopher C. Stacy wrote:
> >>>>>>> On 03 Apr 2003 09:08:33 +0200, Ketil Malde ("Ketil") writes:
> Ketil> More specific question: how is security achieved, when
> >> everything's open, and communciation is done through unrestricted,
> >> shared objects? The reasons given doesn't sound very convincing,
> >> looking from a malicious user perspective.
> >>
> >> It's a single-user system and there is no protecting the user from
> >> himself, if he decides to be self-malicious.
>
> Harri> System protections[1] aren't there for users. They are there to
> protect Harri> various resources from *programs*. Users may or may not
> be somewhere Harri> behind some program that happened to call a chain
> of dozen others, but Harri> that has nothing to do with things. Neither
> has this hypothetical Harri> creature's intentions. It's all about
> programs for any system.
>
> You are the one who began the conversation with the phrase "malicous
> user", so naturally I addressed your specific concern. Now you're saying
> that the problem is not "users" at all. Can you please give a specific
> example of what you're afraid of? The Lisp Machine, rather surprisingly
> to people who are unfamiliar with it, did not in reality experience the
> kinds of problems that I think you are worrying about. My personal
> experience with the design of secure computing systems goes back 24
> years, but I would like you to elaborate, since you are so insistent
> that there must be a terrible problem here. Perhaps we can walk through
> some examples to show why the this was, in practice, not a problem on
> the LispM.
I don't remember that and I don't see it in the thread. I do remembering
commenting on similiar subject in a thread about a scheme interpreter in
Linux kernel. My memory may ofcourse fail.
That was just a brief comment, since people always seem to talk about
"user this" and "user that" when all programs care about are other
programs or in some specific cases input data streams.
It is too large a question to address here and very elementary to common
security practises in real world and in computers. Maybe there's something
like that in lispm, but I haven't seen it nor any of these machines. To me
"it's a single-user computer" sounds like an excuse to make win3 or
amigaos.
I'll try to steer this in a discussable direction:
In this hypothetical lisp os or on a real one, is the language enforced?
Can you use mere syntax to say "you can't access what you don't have a
reference to" and have that solve problems? What about data storage and
directory or catalog interfaces to files? What about compiled programs?
What's to stop a buggy web server from writing over files it's only
supposed to serve, for example?
--
War is Peace
Slavery is Freedom
Backspace is Delete.
-- Currently unattributed .sig
From: Kent M Pitman
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <sfwwuhzenp1.fsf@shell01.TheWorld.com>
[ replying to comp.lang.lisp only
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
"Harri Haataja" <·············@cs.helsinki.fi> writes:
> Can you use mere syntax to say "you can't access what you don't have a
> reference to" and have that solve problems?
(An interesting and crisp goal statement.)
> What's to stop a buggy web server from writing over files it's only
> supposed to serve, for example?
What's to stop a buggy 'program that compiles a program that uses mere
syntax to say "you can't access what you don't have a reference to"' from
writing over files it's only supposed to serve, for example?
From: Christopher Browne
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <b79teg$c9cql$1@ID-125932.news.dfncis.de>
After a long battle with technology,"Harri Haataja" <·············@cs.helsinki.fi>, an earthling, wrote:
> What's to stop a buggy web server from writing over files it's only
> supposed to serve, for example?
Read only access, maybe?
My Apache processes are running under a user role that does not allow
them to overwrite the files they are serving.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://cbbrowne.com/info/lisp.html
"Windows/NT - From the people who brought you EDLIN"
-- ···········@novatel.cuc.ab.ca
> > What's to stop a buggy web server from writing over files it's only
> > supposed to serve, for example?
>
> Read only access, maybe?
>
> My Apache processes are running under a user role that does not allow
> them to overwrite the files they are serving.
That's the way to go - or, capabilities.
Whatever, the access control must be made lighterweight and
not dependent on sysadmin/IT. I just set up a wiki server,
and am tied in knots because sysadmins don't want to
give me a new userid or groupid, so that I can properly
restrict the server.
Creation of new "user roles" should not require sysadmin
intervention. It should be possible for any user role to create
a subrole with a subset of capabilities.
Administering your own machine, whether physical or virtual,
might amount to the same thing.
From: Patrick Schaaf
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <3e9906f1$0$1375$9b622d9e@news.freenet.de>
"Andy Glew" <················@sbcglobal.net> writes:
>> > What's to stop a buggy web server from writing over files it's only
>> > supposed to serve, for example?
>>
>> Read only access, maybe?
>>
>> My Apache processes are running under a user role that does not allow
>> them to overwrite the files they are serving.
>That's the way to go - or, capabilities.
Full ack. When designing production Unix systems (Linux, in fact),
it is a good idea to have at least the network visible parts
running A) under their own uid, B) chrooted, if possible,
and C) with everything you can get away with being readonly.
>Whatever, the access control must be made lighterweight and
>not dependent on sysadmin/IT. I just set up a wiki server,
>and am tied in knots because sysadmins don't want to
>give me a new userid or groupid, so that I can properly
>restrict the server.
Shoot that admin. He does not honor security. It's a clear
sign of bad administration when people _request_ a proper
security related separation, and are denied due to lazyness.
It does not help a bit if that lazyness is codified as policy.
>Creation of new "user roles" should not require sysadmin
>intervention. It should be possible for any user role to create
>a subrole with a subset of capabilities.
A nice experimental OS I read about, which had that as one of its
main points, is Andrew Valencia's VSTA. See the capability papers at
http://www.vsta.org/documentation/documentation.html
>Administering your own machine, whether physical or virtual,
>might amount to the same thing.
Exactly. Regarding the "virtual" bit, another project worth looking
at, which is actively developed (though a bit off the normal Linux
development track), can be found at
http://www.solucorp.qc.ca/miscprj/s_context.hc
That's an attempt at making Linux virtual at the syscall level,
giving the possibility to have whole different Linux distributions
running, private init process and all. Both the visible processes,
and the visible networking setup (netstat, IP address binding, also
its implicit wildcard forms) are properly virtualized.
We start to build production web farm systems, inhouse, using this
project's code.
best regards
Patrick
From: Armadillo
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <3E8BFECD.4030807@eee-fs7.bham.ac.uk>
Simon Andr�s wrote:
> Andrew Reilly <······@gurney.reilly.home> writes:
>
>
>>On Thu, 03 Apr 2003 02:01:42 +1000, Franz Kafka wrote:
>>
>>>A GNU version of a program like Genera will allow a new group of Lisp
>>>hackers to see why Lisp is such a good language.
>>
>>I clearly don't understand some subtle advantage of this Genera system. In
>
>
> And one could hardly blame you, when you don't know what it is:
>
>
>>what sense is it /different/ from emacs? Is it just the dialect of lisp
>>involved that's at question?
>
>
> http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/genera/genera.html
>
>
>>>We already have several applications that would run in such an
>>>environment: Maxima, CL-HTTP, CLIM, and EMACS. just some examples!!!!!
>>
>>Emacs has numeric and symbolic math packages, at least one web browser. I
>>don't know what CLIM is (a mailer? emacs has a couple of those), but
>>there are examples of just about everything else.
>
>
> CL-HTTP is not a browser, CLIM is not a mailer, and Google is your
> friend.
>
> Andras
>
>
>>--
>>Andrew
>
How does this system stop one process messing up another (either
deliberately or accidentally)? It does seem painfully insecure from
malicious programming.
Also, the structure described in the link looks much like a black-board
system - or have I got that horribly wrong?
JonM
From: Kent M Pitman
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <sfw65pvq55k.fsf@shell01.TheWorld.com>
Armadillo <········@eee-fs7.bham.ac.uk> writes:
> How does this system stop one process messing up another (either
> deliberately or accidentally)?
It doesn't.
> It does seem painfully insecure from malicious programming.
Then don't do that. Get programs from people you trust.
The same problem exists today. People routinely download things from
public sites and run them with personal or root perms, even on
so-called secure systems. It all comes down to who you trust.
> Also, the structure described in the link looks much like a
> black-board system - or have I got that horribly wrong?
It has some of this quality in the sense that it's all one address space.
Although blackboard makes it sound to me like it _only_ has global space to
write data, and that's certainly not true.
From: Armadillo
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <3E8C4ACF.4070107@eee-fs7.bham.ac.uk>
Kent M Pitman wrote:
> Armadillo <········@eee-fs7.bham.ac.uk> writes:
>
>
>>How does this system stop one process messing up another (either
>>deliberately or accidentally)?
>
>
> It doesn't.
>
>
>>It does seem painfully insecure from malicious programming.
>
>
> Then don't do that. Get programs from people you trust.
>
> The same problem exists today. People routinely download things from
> public sites and run them with personal or root perms, even on
> so-called secure systems. It all comes down to who you trust.
>
>
Yes - I guess that goes without saying :) But it does strike me though,
if this sort of system is to become more widely used then it ought to
have some mechanism by which the "safety" of a program can be (at least
partially) guaranteed. Even if you trust someone and even if their code
is normally bug free, it is quite possible for something unexpected to
cause problems - most "general" users will not want to have to debug
somebody else's code. Even most academics & techie types will not want
to spend time sorting out somebody else's mistakes when they could be
working on their own...
>>Also, the structure described in the link looks much like a
>>black-board system - or have I got that horribly wrong?
>
>
> It has some of this quality in the sense that it's all one address space.
> Although blackboard makes it sound to me like it _only_ has global space to
> write data, and that's certainly not true.
From: Kent M Pitman
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <sfwistvbjiw.fsf@shell01.TheWorld.com>
Armadillo = <········@eee-fs7.bham.ac.uk>, kmp = <······@world.std.com>
Armadillo> How does this system stop one process messing up another (either
Armadillo> deliberately or accidentally)?
kmp> It doesn't.
Armadillo> It does seem painfully insecure from malicious programming.
kmp> Then don't do that. Get programs from people you trust.
kmp> The same problem exists today. People routinely download things from
kmp> public sites and run them with personal or root perms, even on
kmp> so-called secure systems. It all comes down to who you trust.
Armadillo> Yes - I guess that goes without saying :) But it does
Armadillo> strike me though, if this sort of system is to become more
Armadillo> widely used then it ought to have some mechanism by which
Armadillo> the "safety" of a program can be (at least partially)
Armadillo> guaranteed.
I don't want it more widely used. I just want to use it myself. A
private decision. I don't care what others use. I found it a
pleasure to work with a system that didn't bother me with bogus
security and just let me get work done. (And I didn't feel unsafe at
all. We were live on the net in the days that people were writing all
kinds of worms and stuff, and we were never bothered.)
Armadillo> Even if you trust someone and even if their
Armadillo> code is normally bug free, it is quite possible for
Armadillo> something unexpected to cause problems - most "general"
Armadillo> users will not want to have to debug somebody else's code.
(so much for open source... geez, I thought that was the nature of
the whole, misguided passion)
Armadillo> Even most academics & techie types will not want to spend
Armadillo> time sorting out somebody else's mistakes when they could
Armadillo> be working on their own...
(oh, is that what they want to do...)
Look, there is no real serious attempt at security at all that I can
see on Windows 95, 98, ME, etc. but it has not hurt market share
except probably for server machines, and probably exactly because
most machines in the world do outgoing-only connections that only
download data (hence the success of the conceptually-weird ADSL
connectivity product).
In Windows (non-NT/2000/XP), programs look to me to have apparent
write access to the whole file system. Yet I would trade my NT
workstation OS at this point in a minute for 98, which seems to be a
LOT more reliable, if I thought the set of programs I'd amassed would
survive the 'downgrade' and still run... [I get zero value from all
that security, I've found, and I get plenty more headache from NT
because I'll bet what makes 98 good is not the technically cool fact
of its "designed features" but the uninteresting fact that it is "used
more", probably meaning it's been fixed more.
It's true that in 98, any program can crash the machine (and routinely
they test this ability, just to make sure it's still implemented
properly). And their security comes from locking the room that the
computer sits in--which turns out to be (quite literally) "good enough
for government use". But none of this has been a barrier to
"widespread use".
"Armadillo" <········@eee-fs7.bham.ac.uk> wrote in message
·····················@eee-fs7.bham.ac.uk...
> >
>
> Yes - I guess that goes without saying :) But it does strike me though,
> if this sort of system is to become more widely used then it ought to
> have some mechanism by which the "safety" of a program can be (at least
> partially) guaranteed. Even if you trust someone and even if their code
> is normally bug free, it is quite possible for something unexpected to
> cause problems - most "general" users will not want to have to debug
> somebody else's code. Even most academics & techie types will not want
> to spend time sorting out somebody else's mistakes when they could be
> working on their own...
No, trust also extends to trusting that someone wrote good code that
is pretty well bug free. You have the same problem again when you
dowload and run any code. It could have bugs which could fataly
injure your system. An inordinate amount of wasted time and effort
goes into worrying about trust and catering to the general user. In
most systems like Linux if an unexpected bug happens you
are in an even worse scenario than with a LispM. You can just get
a core dump or the system freezes, (with no explantion). At least with
a LispM you get a debugger with a condition, a backtrace and a better
possibility of locating the problem. In both cases the general user
still needs to rely on the creator or some other expert of the
software to find and fix the problem.
It reminds me of the statement that "C is for consenting
adults". The same goes for the possible Lisp Machines.
Wade
From: Frode Vatvedt Fjeld
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <2h7kab620w.fsf@vserver.cs.uit.no>
Armadillo <········@eee-fs7.bham.ac.uk> writes:
> Yes - I guess that goes without saying :) But it does strike me
> though, if this sort of system is to become more widely used then it
> ought to have some mechanism by which the "safety" of a program can
> be (at least partially) guaranteed. Even if you trust someone and
> even if their code is normally bug free, it is quite possible for
> something unexpected to cause problems - most "general" users will
> not want to have to debug somebody else's code. Even most academics
> & techie types will not want to spend time sorting out somebody
> else's mistakes when they could be working on their own...
But this also applies to Unix, and not to mention Windows. These
systems are supposed to guarantee that applications can't crash or in
other way cause harm to the system as a whole. Yet this does
happen. I've spent hours chasing bugs in Linux and *BSD when I should
have been solving my own problems. As for Windows, your mostly left
with the option of throwing your hands in the air and develop
(consciously or not) soft "rules" for what you can do and cannot and
how, trying your best not to get bitten by the same bug for the
twentieth time (the "wizard" potential here is limitless).
My point is, I guess, is that a "guarantee" is only as good as
practice shows it to be.
--
Frode Vatvedt Fjeld
From: Joe Marshall
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <u1dhc5c6.fsf@ccs.neu.edu>
·································@hotmail.com (Franz Kafka) writes:
> Symbolics or MIT should release a version of OpenGenera that runs on
> Linux.
>
> Franz did a good job but should release a GNU Version of Allegro CL
>
> Gold Hill should release a GNU Version of Gold Works 3
>
> and other LISP companys should follow suit.
Someone should give me enough money to pay my mortgage so I can spend
my spare time writing a Lisp Machine emulator.
From: Francois-Rene Rideau
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87llyetxil.fsf@Samaris.tunes.org>
Joe Marshall <···@ccs.neu.edu> writes:
> Someone should give me enough money to pay my mortgage so I can spend
> my spare time writing a Lisp Machine emulator.
How much would that be?
What about licensing issues to run the Lisp Machine software afterwards?
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
The Law of Eristic Escalation is as follows:
Imposition of Order = Escalation of Chaos.
Fenderson's Amendment adds that the tighter the order in question is
maintained, the longer the consequent chaos takes to escalate,
but the more it does when it does.
From: Joe Marshall
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <llydcer1.fsf@ccs.neu.edu>
Francois-Rene Rideau <····@tunes.org> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
> > Someone should give me enough money to pay my mortgage so I can spend
> > my spare time writing a Lisp Machine emulator.
> How much would that be?
I'm not sure I want to discuss that on Usenet.
If you care to make an educated guess, though, the median cost of a
house in Boston last year was $395,000. Mortgage rates are at about
5.5% (30yr fixed).
> What about licensing issues to run the Lisp Machine software afterwards?
You'd want to hire an intellectual property lawyer to straighten out
the matter. I bet he'd own a nicer house than mine.
From: Christopher Browne
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <b7f79d$bdc7$4@ID-125932.news.dfncis.de>
A long time ago, in a galaxy far, far away, Joe Marshall <···@ccs.neu.edu> wrote:
> Francois-Rene Rideau <····@tunes.org> writes:
>
>> Joe Marshall <···@ccs.neu.edu> writes:
>> > Someone should give me enough money to pay my mortgage so I can spend
>> > my spare time writing a Lisp Machine emulator.
>> How much would that be?
>
> I'm not sure I want to discuss that on Usenet.
>
> If you care to make an educated guess, though, the median cost of a
> house in Boston last year was $395,000. Mortgage rates are at about
> 5.5% (30yr fixed).
Actually, the relevant figure is simply $395,000 :-).
If you have an "generally typical" sort of mortgage, then paying it
would involve something not wildly different from $395K...
--
output = ("cbbrowne" ·@acm.org")
http://www.ntlug.org/~cbbrowne/languages.html
Rules of the Evil Overlord #80. "If my weakest troops fail to
eliminate a hero, I will send out my best troops instead of wasting
time with progressively stronger ones as he gets closer and closer to
my fortress." <http://www.eviloverlord.com/>
From: Joe Marshall
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <3ckj3g5v.fsf@ccs.neu.edu>
Christopher Browne <········@acm.org> writes:
> A long time ago, in a galaxy far, far away, Joe Marshall <···@ccs.neu.edu> wrote:
> > Francois-Rene Rideau <····@tunes.org> writes:
> >
> >> Joe Marshall <···@ccs.neu.edu> writes:
> >> > Someone should give me enough money to pay my mortgage so I can spend
> >> > my spare time writing a Lisp Machine emulator.
> >> How much would that be?
> >
> > I'm not sure I want to discuss that on Usenet.
> >
> > If you care to make an educated guess, though, the median cost of a
> > house in Boston last year was $395,000. Mortgage rates are at about
> > 5.5% (30yr fixed).
>
> Actually, the relevant figure is simply $395,000 :-).
>
> If you have an "generally typical" sort of mortgage, then paying it
> would involve something not wildly different from $395K...
True, but I have no intention of paying the entire thing off *this
month*.
From: Christopher Browne
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <b8kqtj$av8pd$3@ID-125932.news.dfncis.de>
In an attempt to throw the authorities off his trail, Joe Marshall <···@ccs.neu.edu> transmitted:
> Christopher Browne <········@acm.org> writes:
>
>> A long time ago, in a galaxy far, far away, Joe Marshall <···@ccs.neu.edu> wrote:
>> > Francois-Rene Rideau <····@tunes.org> writes:
>> >
>> >> Joe Marshall <···@ccs.neu.edu> writes:
>> >> > Someone should give me enough money to pay my mortgage so I can spend
>> >> > my spare time writing a Lisp Machine emulator.
>> >> How much would that be?
>> >
>> > I'm not sure I want to discuss that on Usenet.
>> >
>> > If you care to make an educated guess, though, the median cost of
>> > a house in Boston last year was $395,000. Mortgage rates are at
>> > about 5.5% (30yr fixed).
>>
>> Actually, the relevant figure is simply $395,000 :-).
>>
>> If you have an "generally typical" sort of mortgage, then paying it
>> would involve something not wildly different from $395K...
>
> True, but I have no intention of paying the entire thing off *this
> month*.
If I got a project paying enough, I'd certainly take on such
intentions :-).
And note that while I'm being a fair bit facetious, here, it's not a
ridiculous matter in overall principle. It *is* important for a
would-be project of this sort to "pay the mortgage" over a period of
time that makes it more significant than to merely cover the interest
charges for a year.
A significant project needs to be either lucrative enough or long-term
enough to be attractive for things like paying down mortgages...
--
output = ("cbbrowne" ·@ntlug.org")
http://cbbrowne.com/info/lsf.html
"Recursion is the root of computation since it trades description for time."
-- Alan Perlis
Joe M. writes:
>
> > What about licensing issues to run the Lisp Machine software afterwards?
>
> You'd want to hire an intellectual property lawyer to straighten out
> the matter. I bet he'd own a nicer house than mine.
If you emulate some of the early Lispm's that were developed at MIT,
and not some of the later comercial Lispm's. The Lawyers won't get
involved. You could also just ask people who use your software, and
like it to contrubute something. You probably won't get the $$$
demanded by big Lisp companys but a bunch of people sending in cents
could add up to a few people sending in $$$.
Plus, you could add the feat on your resume, or use it to advance your
career.
(defvar *fame* 15) ;; Don't you want your 15 min.
(+ *fame*) ;; what more could you want.
From: Christopher C. Stacy
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <uwuhudg2r.fsf@dtpq.com>
>>>>> On 15 Apr 2003 19:55:56 -0700, Franz Kafka ("Franz") writes:
Franz> Joe M. writes:
>>
>> > What about licensing issues to run the Lisp Machine software afterwards?
Franz> If you emulate some of the early Lispm's that were developed at MIT,
Franz> and not some of the later comercial Lispm's. The Lawyers won't get
Franz> involved. You could also just ask people who use your software, and
Franz> like it to contrubute something. You probably won't get the $$$
Franz> demanded by big Lisp companys but a bunch of people sending in cents
Franz> could add up to a few people sending in $$$.
Franz> Plus, you could add the feat on your resume, or use it to
Franz> advance your career.
MIT holds the copyright on the original Lisp Machine software;
it was licensed to Symbolics and LMI, not given to them for free.
Therefore, I don't know why you would so definitely state that
lawyers would not get involved. MIT has very aggressive lawyers
for protecting their intellectual property.
Perhaps you might be able to obtain a license without cost,
if you asked the right people, nicely. Perhaps not.
But that software has never before been "free"
in any sense of the word.
Figure it might cost, conservatively, $150,000 for someone to
write an emulator for the CADR processor, recover the sources,
and bring up the emulator. Assume the MIT software is free.
Are there 150 people who would be interested in each contributing
$1000 each, and is that very different from the amount charged by
the "Big Lisp Companies"? What if it costs several times that much?
Are you sure you really need a Lisp Machine, and not just a very
good Lisp development environment that runs on actual modern machines?
If so, in these price ranges, why not scrounge up a used DEC Alpha
and purchase a license to Symbolics Open Genera, which would be
infinitely more useful than an emulated CADR?
From: Joe Marshall
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <adeqxiwu.fsf@ccs.neu.edu>
·································@hotmail.com (Franz Kafka) writes:
> Joe M. writes:
> >
> > > What about licensing issues to run the Lisp Machine software afterwards?
> >
> > You'd want to hire an intellectual property lawyer to straighten out
> > the matter. I bet he'd own a nicer house than mine.
>
> If you emulate some of the early Lispm's that were developed at MIT,
> and not some of the later comercial Lispm's. The Lawyers won't get
> involved.
If a lawyer smells money, he'll get involved. The things that are
important to scientists --- facts, external reality, causality,
etc. --- don't matter to lawyers.
> Plus, you could add the feat on your resume, or use it to advance your
> career.
Oh yeah. There'd be a line of employers outside my door.
> (defvar *fame* 15) ;; Don't you want your 15 min.
> (+ *fame*) ;; what more could you want.
I could join the pantheon of other famous Lisp Machine hackers like,
er, um.....
I got the following reply from, Tom Knight, at MIT:
>
Several people have asked about the naughty bits of the original MIT
lisp machine architecture. I've put my master's thesis (1979) on line
for those of you with a generous non-critical spirit to take a look
at. I will duck all arrows, but praise will be gratefully received.
There are genuine logic diagrams for those of you who recall Schottky
TTL logic or who want to know how hard it was to do anything back in
the bad old days.
General features include a 32 bit word, 180ns cycle, 3-stage pipe,
bypass logic, barrel shifter, single cycle arbitrary field
extract/deposit, and a "dispatch" instruction which did an extracted
field multi-way table lookup branch in a single cycle. Microcode PC
push down stack, top-of-stack cache, and an ability to variablize
microcode instructions on-the-fly are also interesting features.
Branch delay slots appeared here also.
Best, tk
http://www.ai.mit.edu/people/tk/tk-sm-79.pdf
>
and then I got the following message:
>
I meant to post that last message instead of mail it.
>
I quoted the letters I got word for word.
Since he talked about people replying I am going to assume he wanted
people in this newsgroup to get his e-mail address. But, since I don't
think he inteneded web-spiders to get it it is encoded in the
following Lisp code--I've seen someone else use.
(remove #\space "tk @ ai . mit . edu") ;; Spamer's Suck!!!!!
Note: I don't know about the legal issue of using the info. but I have
gotten permission to dist. the info. I'll post when I find out the
status of the software.
PS
ANSI CL or Scheme has got to be a better language to use for systems
programming that machine language is. One reason why Lisp is a good
Machine Language: Programs and Data are in the same format. The
language is portable so you can only learn one Machine Language not
thousands.
C is a universal assembler; let's make Lisp a univeral machine
language or microcode language--don't flame me about this; I don't
really know the difference between machine and micro code.
From: Tim Bradshaw
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <ey3fzp1tbw0.fsf@cley.com>
* Franz Kafka wrote:
> Another thing is to release cheaper versions of Lisp Compilers that
> can create a Windows executable. Some programmers I know would love to
> switch to LISP but cannot because they cannot justify why thay should
> spend in the thousand dollar range--when they can get Visual Basic,
> and Visual C++ for way under a thousand and sometimes way under a
> hundred. (The managers told those programmers that they could buy a
> Lisp compiler if it conformed to the ANSI standard, and came with some
> GUI builder such as CLIM, or a VB type interface--they could not find
> such a system.)
What is these people's time worth per hour? I suspect a license for a
commercial Lisp system, complete with GUI tools, would be under a week
of time, possibly under a day.
But hey, what's rationality when you can have some stupid mantra about
free software?
I used to really be in favour of free software, but the kind of
endless fundamentalist idiocy from the free software converts typified
by your post makes me just want to get rid of it all and buy something
which doesn't come with some kind of half-baked religion attached to
it.
--tim
>
> I used to really be in favour of free software, but the kind of
> endless fundamentalist idiocy from the free software converts typified
> by your post makes me just want to get rid of it all and buy something
> which doesn't come with some kind of half-baked religion attached to
> it.
>
I an a student who wants to learn Lisp, and maybe make a few freeware
apps. in Lisp. I have bough a used Lispm for $500, and gotten two
years out of it. I am going to try to get it back on-line. But, I
would love a Lisp for Windows/Linux that could produce powerful apps.
I am not empolyed now, am going to school full time. It is hard to
learn Lisp when most of the Lisp compilers I've tried can't even run
all of the examples in CLTL2 let along ANSI. Is their a freeware
version of Lisp that can produce executables, and is fully ANSI
complient. I don't want to use it to create commercial
applications--just to learn Lisp a little better, and product some GNU
AI or AL apps. that I'd just post to the web.
How good is Clisp, CMUCL, does any come with an interface builder like
CLIM?
I am also thinking about a good Scheme compiler? Do you know of any?
Is there any good Lisps that are as cheap as VB, for a student that
is, and are able to produce Lisp apps. under Windows?
How good are Allegro CL, and Gold Works 3?
Thanks a mil
From: Thomas F. Burdick
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <xcvvfxwkzi5.fsf@famine.OCF.Berkeley.EDU>
·································@hotmail.com (Franz Kafka) writes:
> How good is Clisp, CMUCL, does any come with an interface builder like
> CLIM?
CMUCL is probably all you need, on Linux. It's not a seamless
environment, but it's very high quality, and free. Use Hemlock, or
Emacs/ILISP as your IDE, and Garnet as your toolkit, and you'll get
yourself a nice development environment, and a GUI toolkit with a
Motif look-and-feel and all the tools you'd expect. You can dump your
applications as CMUCL cores, and deliver them with the runtime and a
shell script to launch.
> Is there any good Lisps that are as cheap as VB, for a student that
> is, and are able to produce Lisp apps. under Windows?
Check out Corman Lisp, the bargain-basement CL for Windows.
Alternatively, Lispworks Professional is only $540 with academic
discount.
> How good are Allegro CL, and Gold Works 3?
>
> Thanks a mil
Well, more like $1000, but that's okay.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Henrik Motakef
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87y92s7m5l.fsf@interim.henrik-motakef.de>
·································@hotmail.com (Franz Kafka) writes:
> It is hard to learn Lisp when most of the Lisp compilers I've tried
> can't even run all of the examples in CLTL2 let along ANSI.
That's not my experience. I use CMUCL and SBCL most of the time, and
both seem to be quite close to the ANSI standard, and getting
closer. I'm sure the developers would be glad to hear about any
non-compliances, and treat them as bugs that have to be fixed.
> Is their a freeware version of Lisp that can produce executables,
The "building executables" question comes up frequently here, you
might want to check the google archives for details. Basically, the
answer is no, you can't build executables in the sense you can with C
with any free Lisp, but in most cases, it doesn't matter. You simply
have to ship two files instead of one, an executable and an image.
Recent SBCL versions include some trick to build nearly-executables,
IIRC, but I never bothered to look at it in detail yet. I just don't
see the existing delivery options as that big a problem.
> How good is Clisp, CMUCL, does any come with an interface builder
> like CLIM?
There is a project to build a free CLIM implementation, see
<http://mcclim.cliki.net>. It doesn't include a VB-like interface
builder however.
> Is there any good Lisps that are as cheap as VB, for a student that
> is, and are able to produce Lisp apps. under Windows?
There is Corman Lisp (http://www.cormanlisp.com), which can be used to
build Windows apps and DLLs. A student license is $125, parts of it
(including the compiler) are free at least for noncommercial use. I
don't know how good it is, but there is a free trial version.
Regards
Henrik
From: Daniel Barlow
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <871y0kv634.fsf@noetbook.telent.net>
Henrik Motakef <··············@web.de> writes:
> Recent SBCL versions include some trick to build nearly-executables,
(require :sb-executable)
(compile-file "test1")
(sb-executable:make-executable "hello" *)
generates a "nearly-executable" as you so aptly describe it, called
"hello". It's a fasl file with appropriate #! magic glommed on the
front, so still requires that you ship (or at least tell people how
to get) an sbcl runtime and core.
FAQ #1: SBCL doesn't currently run on Windows
FAQ #2: SBCL sort of has threads, FSVO "has". They only work on Linux
x86 (using the kernel clone() syscall), and were committed to the CVS
version about 6 hours ago, so it's not really what you'd call mature
technology yet.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Paolo Amoroso
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <dFOMPprpcobVuJ2jrE66ZxaMMAH2@4ax.com>
On 2 Apr 2003 08:19:01 -0800, ·································@hotmail.com
(Franz Kafka) wrote:
> apps. in Lisp. I have bough a used Lispm for $500, and gotten two
[...]
> all of the examples in CLTL2 let along ANSI. Is their a freeware
> version of Lisp that can produce executables, and is fully ANSI
Just out of curiosity: how do you create an "executable" with your Lisp
Machine?
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: James A. Crippen
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <m3u1df6upf.fsf@kappa.unlambda.com>
Paolo Amoroso <·······@mclink.it> writes:
> On 2 Apr 2003 08:19:01 -0800, ·································@hotmail.com
> (Franz Kafka) wrote:
>
>> apps. in Lisp. I have bough a used Lispm for $500, and gotten two
> [...]
>> all of the examples in CLTL2 let along ANSI. Is their a freeware
>> version of Lisp that can produce executables, and is fully ANSI
>
> Just out of curiosity: how do you create an "executable" with your Lisp
> Machine?
There's not really such a thing. You just load code into the system
and then call some random startup function provided.
There are object files created by the compiler. Depending on the
system they are usually known by the same sorts of suffices that show
up on non-Lispms, eg FASL, LOAD, etc. These aren't executables
though, in the sense that they are run as subprocesses of the shell.
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
From: Paolo Amoroso
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <utGNPht+35s1irMPgZTJtgBk06PG@4ax.com>
On Thu, 03 Apr 2003 14:13:16 -0900, ·····@unlambda.com (James A. Crippen)
wrote:
> Paolo Amoroso <·······@mclink.it> writes:
[...]
> > Just out of curiosity: how do you create an "executable" with your Lisp
> > Machine?
>
> There's not really such a thing. You just load code into the system
> and then call some random startup function provided.
I know :-) Which leaves me wondering why Kafka is caring so much about
executables if he just wants to learn Lisp.
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Nils Goesche
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <871y0k7vzw.fsf@darkstar.cartan>
Tim Bradshaw <···@cley.com> writes:
> * Franz Kafka wrote:
> > Another thing is to release cheaper versions of Lisp
> > Compilers that can create a Windows executable. Some
> > programmers I know would love to switch to LISP but cannot
> > because they cannot justify why thay should spend in the
> > thousand dollar range
> What is these people's time worth per hour? I suspect a
> license for a commercial Lisp system, complete with GUI tools,
> would be under a week of time, possibly under a day.
Right. Heck, at work we once had to pay $10000 for a f*cking C
compiler, and I mean $10000 for /one/ user license. And just
imagine for a second what some people spend for /cars/!
> But hey, what's rationality when you can have some stupid
> mantra about free software?
>
> I used to really be in favour of free software, but the kind of
> endless fundamentalist idiocy from the free software converts
> typified by your post makes me just want to get rid of it all
> and buy something which doesn't come with some kind of
> half-baked religion attached to it.
Amen.
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
From: Paolo Amoroso
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <FViMPp6HYBcal9vVwsh0gMFGi7rc@4ax.com>
[Followup posted to comp.lang.lisp only]
On 1 Apr 2003 18:27:55 -0800, ·································@hotmail.com
(Franz Kafka) wrote:
> However, LISP is not as popular as it could be--not because it is very
> hard to learn, but because there are no GNU Versions of Commerical
> Grade products. I think that once a GNU version is out there--the
Paul Graham used GNU[*] CLISP, which is GPLed, to write part of a
commercial grade system. Graham later sold his company for over 50M$. Does
that count?
> Another thing is to release cheaper versions of Lisp Compilers that
> can create a Windows executable. Some programmers I know would love to
You may check Corman Lisp.
Paolo
[*] I think it was not called "GNU" at the time, but it was GPLed
nonetheless.
--
Paolo Amoroso <·······@mclink.it>
From: Anne & Lynn Wheeler
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <uk7ee5873.fsf@earthlink.net>
·································@hotmail.com (Franz Kafka) writes:
> The only important thing is to not tie the Lispm to a specific chip,
> or Machine like Symbolics, LMI, Xerox, TI, and the Scheme Chip did
> but to make it able to run on all hardware--so that more people
> could try it out.
>
> Porting Linux into a Lisp/Scheme OS would be a great start.
slight drift regarding mit lisp machine & 801 circa 1979 ...
see last ref at
http://www.garlic.com/~lynn/2003e.html#65 801 (was re: reviving Multics)
appears just before the next posting at:
http://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools ... what and when
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Christopher C. Stacy
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <u1y0lfc0i.fsf@dtpq.com>
>>>>> On Tue, 01 Apr 2003 19:22:58 GMT, Anne & Lynn Wheeler ("Anne") writes:
Anne> slight drift regarding mit lisp machine & 801 circa 1979 ...
That story is pretty garbled. The early people on the Lisp Machine
project were certainly aware of the 801 due to assorted connections
with people at Yorktown, but they did not consider creating the Lisp
Machine by using the IBM processor. (The Lisp Machine was invented
more than 3 years before the time you're citing, there, by the way.)
From: Anne & Lynn Wheeler
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <uu1dhhru8.fsf@earthlink.net>
······@dtpq.com (Christopher C. Stacy) writes:
> That story is pretty garbled. The early people on the Lisp Machine
> project were certainly aware of the 801 due to assorted connections
> with people at Yorktown, but they did not consider creating the Lisp
> Machine by using the IBM processor. (The Lisp Machine was invented
> more than 3 years before the time you're citing, there, by the way.)
that was just a copy of email to me ... sent on the date indicated; it
didn't actually give a date as to the request to Evans. i would have
expected the actual date of the request to Evans would have been at
least a couple years earlier given the 8100 reference. The first 801
presentation I attended was spring of '76 (... which would correspond
to your reference).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
From: Petter Gustad
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87y92ugcrg.fsf@zener.home.gustad.com>
·································@hotmail.com (Franz Kafka) writes:
> The only important thing is to not tie the Lispm to a specific chip,
> or Machine like Symbolics, LMI, Xerox, TI, and the Scheme Chip did but
> to make it able
> to run on all hardware--so that more people could try it out.
I think it would be cool to implement a Symbolics type CPU in a
FPGA...
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
From: Christopher C. Stacy
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <uwuiddxeo.fsf@dtpq.com>
>>>>> On 01 Apr 2003 22:53:55 +0200, Petter Gustad ("Petter") writes:
Petter> ·································@hotmail.com (Franz Kafka) writes:
>> The only important thing is to not tie the Lispm to a specific chip,
>> or Machine like Symbolics, LMI, Xerox, TI, and the Scheme Chip did but
>> to make it able
>> to run on all hardware--so that more people could try it out.
Petter> I think it would be cool to implement a Symbolics type CPU in a
Petter> FPGA...
Isn't that called the "G-Machine" circa 1986?
>
> I think it would be cool to implement a Symbolics type CPU in a
> FPGA...
>
It would be even better if some one could create a VM that implemented
a Symbolics type CPU on an Pentium and/or Athlon chip.
Or even better if someone wrote a Symbolics emulator for Linux, Mac (a
software emulator--forget the MacIvory), or Windows.
We already have Mac emulators on PCs, PC emulators on Macs, and both
PC and Mac emulators on Linux boxes.
What we need is a GNU version of Genera that will run on home
computers. I as a student would love it.
From: Petter Gustad
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87llysb0up.fsf@zener.home.gustad.com>
·································@hotmail.com (Franz Kafka) writes:
> >
> > I think it would be cool to implement a Symbolics type CPU in a
> > FPGA...
> >
>
> It would be even better if some one could create a VM that implemented
> a Symbolics type CPU on an Pentium and/or Athlon chip.
I agree that this would be better in the sense that it would be
accessible to more people. Personally I think it would be more fun to
make the FPGA version :-)
> What we need is a GNU version of Genera that will run on home
> computers. I as a student would love it.
There is a port called OpenGenra (which is not open source) which runs
on Alpha. I think OpenGenra assumes a 64-bit architecture, but a
version for the Opteron would be nice...
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
From: James A. Crippen
Subject: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <m31y0kc5co.fsf_-_@kappa.unlambda.com>
Petter Gustad <·············@gustad.com> writes:
> ·································@hotmail.com (Franz Kafka) writes:
>
>> > I think it would be cool to implement a Symbolics type CPU in a
>> > FPGA...
>>
>> It would be even better if some one could create a VM that implemented
>> a Symbolics type CPU on an Pentium and/or Athlon chip.
People have been talking about this for a long time, but it turns out
it's both a lot of hard work as well as there being very little
documentation. Much of what has been done in this direction has been
realized by reverse-engineering from bootable images of the operating
system.
Also it's important to note that Lispms (specifically MIT, Symbolics,
LMI, and TI ones) were microcoded hardware. The actual CPU ran
microcode that ran macrocode instructions that Lisp was compiled to.
So the output of the Lisp compiler was just macrocode. There doesn't
seem to be much of a need to emulate the microcode hardware, but the
macrocode design makes a lot of assumptions based on the microcode
architecture. These make implementing the macrocode interpreter
fairly difficult, particularly because these design assumptions are
only implicitly mentioned in extant documentation.
> I agree that this would be better in the sense that it would be
> accessible to more people. Personally I think it would be more fun to
> make the FPGA version :-)
That honestly be a bad decision in this day and age. Computers are
plenty fast enough to emulate processors, and there's really no reason
to tie oneself to a very specific and nonstandard piece of hardware.
Once an emulated system was built it might be a good idea to implement
an FPGA-based implementation, but it would make sense for a complete
and verifiable emulator to be built first, since this would solve the
sparse documentation problem.
>> What we need is a GNU version of Genera that will run on home
>> computers. I as a student would love it.
Not gonna happen. Sorry. Genera is way too valuable IP for them (the
current owners of Symbolics) to release it under the GPL. If Genera
is ever released openly it'll probably require that all changes be
made available to Symbolics at no cost and with no restrictions. This
is similar to the agreement they had with MIT for the original Lispm
software.
Now, an enterprising youngster might manage to convince TI to release
the rights to the TI Explorer OS and software as open source,
considering that they've probably completely forgotten about the
existence of it. And that they apparently garbaged all their copies
and related documents back before they sold off their computing
division to HP.
> There is a port called OpenGenra (which is not open source) which runs
> on Alpha. I think OpenGenra assumes a 64-bit architecture, but a
> version for the Opteron would be nice...
OpenGenera is a product from Symbolics Technologies, Inc that emulates
an Ivory processor (the CPU of the later XL series of Symbolics
Lispms) on HP (Compaq, Digital, DEC, whatever) Alpha systems running
Tru64 Unix (Digital Unix, OSF/1, whatever). It's written in Alpha
assembly language. Any porting to non-Alpha platforms would require
massive amounts of effort, basically a total rewrite.
Why was it written in Alpha assembler, you ask? Well, because the C
compiler couldn't produce efficient enough code to handle the 48 bit
addressing required to emulate the Ivory word size and memory model.
So the designers figured that to make it fast enough to use in a
reasonable amount of time the best solution was to get Alpha assembler
gurus to write in assembler. Symbolics was going down the tubes at
the time and couldn't afford to wait for computers to get faster
before the product could see market sale.
BTW, the current cost for a copy of OpenGenera is $5k, not including
licensing or hardware cost for an Alpha and a copy of Tru64 Unix. The
latest cost I've seen for a Symbolics XL1200 is around $3k, but the
system is much slower (1 or 2 orders of magnitude slower) than
OpenGenera on the Alpha. But you don't get the nifty keyboard on the
Alpha, if that matters to you. But you do get the advantage of not
having a 150 (200?) pound monster with fans that can blow an angry cat
across a shag carpet.
As for TI Explorers, if you can find one in working order *with the
funny fiber optic console cable* then lucky you. Make sure you look
into the mailing list (look around, you'll find it) and offer to share
software and load bands with people if you want to make friends.
You'll need them.
If you have an LMI Lambda or MIT CADR then you should report to the
nearest computing history museum and donate it immediately. Don't
attempt to get it working yourself unless you've hacked on them before
and know what you're doing, or have the courage to lose big. Certain
people do however have such courage and are keeping things like CADRs
in their garages. Those people have more guts than I ever would.
(If you do want to run a CADR it's a good idea to invest in some other
Lispm as well. And maybe a DEC KS-10 running ITS and Chaosnet. The
latter can be had with an emulator and some hardware magic,
apparently.)
If you have some other weirdo Lispm (like a Xerox D-Machine, a Siemens
Interlisp box, or one of those weirdo Fujitsu thingies) then you
should pray to the deity of your choice for guidance and report to Al
Kossow immediately.
For fascinating Lispm info see:
http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/symbolics.html
http://fare.tunes.org/LispM.html
http://www2.thecia.net/users/ptw/VLM.html
http://www.spies.com/~aek/xerox.html
(cheers)
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
From: Franz Kafka
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <b3b6b110.0304030855.2eb1a45e@posting.google.com>
>
> As for TI Explorers, if you can find one in working order *with the
> funny fiber optic console cable* then lucky you. Make sure you look
> into the mailing list (look around, you'll find it) and offer to share
> software and load bands with people if you want to make friends.
> You'll need them.
>
Who would I contact at TI; nobody there seems to even remember the
Explorer--let alone know where I can find the source.
Would MIT be willing to share infomation about a LISP OS? They brought
us GNU EMACS? I know the MIT version would be older then the other
versions, but becasue they are a school they might release an GNU
freeware version.
Didn't Symbolics file Chapt. 11 and Symbolics Tec. flop--I've been
trying to find a used Lispm and after 1996--Symbolics.com went
down--it has never went up again, but I've seen mirror sites.
How old does the OS have to be before it falls into the public domain?
It someone wrote a microcode emulator--if they owned the machine they
could use a Logic Analyzer to probe it without having to understand
the design principals of the microcode. They could create an Ivory or
Explorer emulator which would load the Lisp OS.
I am concered about the technical aspects of this project--not the
legal or moral or ethical ones. I'd love to see a GNU Lisp OS build
within the next few years--it has already been ten years since they
were built, how much longer do we have to wait to rebuild them?????
What ever happened to Macsyma.com--I bought there product but their
site went down as soon as Symbolics.com did.
If Lispm companys are still in business, as people keep telling me,
why can't I find Lispms being sold anywhere on the net, not even on
EBay.
From: Kent M Pitman
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <sfwel4jbig0.fsf@shell01.TheWorld.com>
[ replying to comp.lang.lisp only
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
·································@hotmail.com (Franz Kafka) writes:
> Didn't Symbolics file Chapt. 11 and Symbolics Tec. flop--I've been
> trying to find a used Lispm and after 1996--Symbolics.com went
> down--it has never went up again, but I've seen mirror sites.
Symbolics filed Chap 11, yes, and later I believe Chap 7 (whatever
liquidation is). They sold their technology to Symbolics Technologies.
"flop" is not a term of art in the business community. Assets don't
go nowhere--they continue to be held by whowever still owns them.
Symbolics Technologies continues to exist and owns the IP.
Odd as it might seem, having a web site is not a requirement to have a
business. It probably _helps_. But it's their choice.
I wish it were more accessible, too, btw. But on the other hand, real
money was probably paid to acquire these things, and the owner is
probably right that there is unrealized value here. So I can sympathize
with not just open sourcing it.
And, finally, buzz in the back rooms is that the issues holding this
back are medical, not financial. So cut the owner some slack.
Serious medical conditions do not always schedule themselves well with
respect to commercial timelines. The world copes.
> How old does the OS have to be before it falls into the public domain?
I suspect that the legal copyrighting was probably all post-1978 (when
the copyright act of 1976 took effect). That
Don't know the citation notation, but USC Title 17, Chap 3, Sec 302(c) says:
(c) Anonymous Works, Pseudonymous Works, and Works Made for Hire. -
In the case of an anonymous work, a pseudonymous work, or a work made
for hire, the copyright endures for a term of 95 years from the year
of its first publication, or a term of 120 years from the year of its
creation, whichever expires first. [...]
"I'm not a lawyer, but..."
As a technical matter, I don't think that it was ever published. I'd
guess ("and you might want to confirm through a lawyer if it mattered
to you enough to make commercial decisions abou it") that it is not
really relying for its public non-use on copyright at all; that is,
I'd guess that the copyright merely acts as a backup safety net assuring
that if the trade secret is every violated in the first 120 years, there
is additional recourse. (I don't know how trade secret law is enforced.)
The Symbolics sources have been offered only to paying customers under
trade secret, and anyone else who has it has a copy that was
unpublished and illegally obtained. I'm not sure what happens in that
case if you try to use it. Maybe nothing. Maybe after 120 years, no
one cares and case law will take a long time to establish.
Kent M Pitman <······@world.std.com> writes:
>> How old does the OS have to be before it falls into the public domain?
>
> I suspect that the legal copyrighting was probably all post-1978 (when
> the copyright act of 1976 took effect). That
Here's a line from COMPILER;COMPILE.LISP:
;;; Copyright (C) 1980, Massachusetts Institute of Technology
This is from the Explorer sources, but nonetheless would have been the
same for Symbolics's copy as well.
Symbolics and LMI both got their sources from MIT. It appears that
all the sources were branded with MIT's copyright before they were
shared out to the two spinoffs subsequent to the Great Schism.
LMI later was swallowed by TI. If that helps make things clear.
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
In article <··············@kappa.unlambda.com>,
James A. Crippen <·····@unlambda.com> wrote:
>LMI later was swallowed by TI. If that helps make things clear.
I don't think so. TI licensed LMI's technology to create the Explorer, but
I don't think they ever acquired the company itself. IIRC, LMI was
acquired by Gigamos, and then they either stopped marketing the LMI
products or went out of business as well.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <··············@level3.com> writes:
> In article <··············@kappa.unlambda.com>,
> James A. Crippen <·····@unlambda.com> wrote:
> >LMI later was swallowed by TI. If that helps make things clear.
>
> I don't think so. TI licensed LMI's technology to create the Explorer, but
> I don't think they ever acquired the company itself. IIRC, LMI was
> acquired by Gigamos, and then they either stopped marketing the LMI
> products or went out of business as well.
I thought I had heard, though it might be incorrect, that TI bought
something like 20% or 25% or something like that of LMI in order to
get that technology... but in any case, I agree with Barry that LMI
was not wholly swallowed by TI.
Barry Margolin <··············@level3.com> writes:
> In article <··············@kappa.unlambda.com>,
> James A. Crippen <·····@unlambda.com> wrote:
>>LMI later was swallowed by TI. If that helps make things clear.
>
> I don't think so. TI licensed LMI's technology to create the Explorer, but
> I don't think they ever acquired the company itself. IIRC, LMI was
> acquired by Gigamos, and then they either stopped marketing the LMI
> products or went out of business as well.
Right. TI didn't actually *purchase* LMI outright but had them over a
barrel and got full rights to do whatever they wanted with the LMI
property that was given to them. In essence TI 'took the place of'
LMI in the market. LMI was left with essentially nothing except the
dream of some new hardware, the K-machine. That never made it into
production before they were acquired and shut down.
Last I heard the docs and other physical goods from LMI were sold to
some scrap heap place where some of them were rescued by Greenblatt.
Rumor has it that he still has a working Lambda that he plays with in
his garage or somesuch. But I think like Wozniak he took off to teach
kids or something and hasn't done much in the industry since.
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
James A. Crippen <·····@unlambda.com> wrote:
+---------------
| Last I heard the docs and other physical goods from LMI were sold to
| some scrap heap place where some of them were rescued by Greenblatt.
| Rumor has it that he still has a working Lambda that he plays with in
| his garage or somesuch. But I think like Wozniak he took off to teach
| kids or something and hasn't done much in the industry since.
+---------------
He was at ILC 2002. Gave a talk in the bioinformatics track:
<URL:http://www.international-lisp-conference.org/Speakers/
People/Richard-Greenblatt.html>
"Precisely Universally Conserved Amino Acid Residues"
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
·····@unlambda.com (James A. Crippen) writes:
> Last I heard the docs and other physical goods from LMI were sold to
> some scrap heap place where some of them were rescued by Greenblatt.
Eli Hefron and Sons on Norfolk Street in Cambridge, MA. (A computer
salvage company.)
I didn't know RG grabbed anything, but I grabbed a couple of things
from them at the time.
> Rumor has it that he still has a working Lambda that he plays with in
> his garage or somesuch. But I think like Wozniak he took off to teach
> kids or something and hasn't done much in the industry since.
Last I heard he's doing consulting at Boston University (Department of
Biomedical Engineering, College of Engineering working with Lucia
Vania). You can see his pic at http://bme.bu.edu/facility.htm I've
seen him in Cambridge occasionally.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>·····@unlambda.com (James A. Crippen) writes:
>
>> Last I heard the docs and other physical goods from LMI were sold to
>> some scrap heap place where some of them were rescued by Greenblatt.
>
>Eli Hefron and Sons on Norfolk Street in Cambridge, MA. (A computer
>salvage company.)
Which, BTW, seems to be no more. I recently noticed that it has morphed
completely into E.L.I. Computers.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
>
> Here's a line from COMPILER;COMPILE.LISP:
>
> ;;; Copyright (C) 1980, Massachusetts Institute of Technology
>
Since it was copyrighted by MIT and the head of fsf workers for
fsf he might be willing to gpl the code for the Lispm that MIT
developed. I know that we can't get Symbolic's extensions; I found
that they are still in business--I might even buy a system from them
as soon as I can get some money. We might be able to talk TI into
releaseing their extensions--along with LMI's extensions--because
both products are not longer maintained or sold.
I'm sure that if MIT releases the sources that they own, the Lisp
community will produce a new OS from the base system that is owned
by MIT--I'm not saying that this will happen overnight, but it will
happen eventually.
I also hope that some company will offer a Lispm Environment for sale
with a good price for students, I know I'll buy one if the price is
reasonable. (>$500 for students; full time students can't afford much
more.)
How good was Meledy as a Lispm Environment; I think it's student price
was $250 if you can still get it. (How does it compair to Genera?)
·································@hotmail.com (Franz Kafka) writes:
> >
> > Here's a line from COMPILER;COMPILE.LISP:
> >
> > ;;; Copyright (C) 1980, Massachusetts Institute of Technology
> >
> Since it was copyrighted by MIT and the head of fsf workers for
> fsf he might be willing to gpl the code for the Lispm that MIT
> developed. I know that we can't get Symbolic's extensions; I found
> that they are still in business--I might even buy a system from them
> as soon as I can get some money. We might be able to talk TI into
> releaseing their extensions--along with LMI's extensions--because
> both products are not longer maintained or sold.
TI sold the Explorer stuff to HP a few years back.
Joe Marshall <···@ccs.neu.edu> writes:
> ·································@hotmail.com (Franz Kafka) writes:
>
>> >
>> > Here's a line from COMPILER;COMPILE.LISP:
>> >
>> > ;;; Copyright (C) 1980, Massachusetts Institute of Technology
>> >
>> Since it was copyrighted by MIT and the head of fsf workers for
>> fsf he might be willing to gpl the code for the Lispm that MIT
>> developed. I know that we can't get Symbolic's extensions; I found
>> that they are still in business--I might even buy a system from them
>> as soon as I can get some money. We might be able to talk TI into
>> releaseing their extensions--along with LMI's extensions--because
>> both products are not longer maintained or sold.
>
> TI sold the Explorer stuff to HP a few years back.
No, TI sold their computing systems division to HP. The Explorer
project was shut down and disposed of mere months before that sale.
So the Explorer never went to HP, only the TI 1500 which was a
Motorola based Unix box. Same hardware and bus as the Exploder, but
completely different processor. And different OS of course.
I got this info from someone who works for TI and was on the Explorer
project at the time.
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
·····@unlambda.com (James A. Crippen) writes:
> Joe Marshall <···@ccs.neu.edu> writes:
> >
> > TI sold the Explorer stuff to HP a few years back.
>
> No, TI sold their computing systems division to HP. The Explorer
> project was shut down and disposed of mere months before that sale.
> So the Explorer never went to HP.
I stand corrected.
So what did TI do to `dispose of' the Explorer stuff? What happened
to the people on the project?
There was also a little-known Lisp Machine effort at a place called
something like Racal-Norsk, in Europe. Does anyone remember that one?
I'm not sure which sources it was working from or what the nature of
its license was. (If I recall correctly, the UK's Open University had
some dealings with them while I was there in the summer of 1984.)
Kent M Pitman <······@world.std.com> writes:
> There was also a little-known Lisp Machine effort at a place called
> something like Racal-Norsk, in Europe. Does anyone remember that one?
> I'm not sure which sources it was working from or what the nature of
> its license was. (If I recall correctly, the UK's Open University had
> some dealings with them while I was there in the summer of 1984.)
http://lists.tunes.org/archives/lispos/1998-April/002273.html
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Kent M Pitman <······@world.std.com> writes:
> There was also a little-known Lisp Machine effort at a place called
> something like Racal-Norsk, in Europe. Does anyone remember that one?
> I'm not sure which sources it was working from or what the nature of
> its license was. (If I recall correctly, the UK's Open University had
> some dealings with them while I was there in the summer of 1984.)
I have seen things you people wouldn't believe:
a Racal Norsk on fire in the basement at the University of Oslo.
a Symbolics 3600 dropped on the floor while moving the comp.sci. department.
Lisp classes given witout any course credits.
All these moments will be lost in time,
like Teco.
Time to go for Java.
--
(Rmz)
·············@telenor.com writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > There was also a little-known Lisp Machine effort at a place called
> > something like Racal-Norsk, in Europe. Does anyone remember that one?
> > I'm not sure which sources it was working from or what the nature of
> > its license was. (If I recall correctly, the UK's Open University had
> > some dealings with them while I was there in the summer of 1984.)
>
> I have seen things you people wouldn't believe:
> a Racal Norsk on fire in the basement at the University of Oslo.
> a Symbolics 3600 dropped on the floor while moving the comp.sci. department.
> Lisp classes given witout any course credits.
> All these moments will be lost in time,
> like Teco.
> Time to go for Java.
Nicely done.
-----
That's good, Kent. Appreciate first. (And I did. :)
There. NOW offer optional, marginally intersting additional nitpicking...
The "tears in the rain" line is my favorite in that movie, so I might
have said:
like Teco in line noise.
Incidentally, this has been a concern of mine for a long time about the
SETI project. We worry that there are few people out there transmitting,
but the problem is worse than I often hear it told. Only nascent
civilizations will transmit messages without compression, since
compressionless transmission is such a bad use of bandwidth. Compressed
transmissions, though, have the problem that they approach randomness.
"A bit is a surprise"; so when full compression has occurred, almost every
bit is a surprise, and there's little "information" left in the bits.
That means that the only thing SETI can recognize will be either intentional
communications (which will surely contain massive redundancy, and may
hopefully exploit the prisoner's dilemma in other ways) or else the
communication of very early civilizations, pre-compression. The situation
featured in Contact, where a civilization notices the 'momentary' event
of our world broadcasting uncompressed must be extremely rare. And, to
twist this aside back into vague relevance, our civilization as a whole
will be lost to others, like Teco in line noise, if we don't find budget
to intentionally trasmit some easier to decode formats than commerce seems
to be devising of late...
Back to the poem, I might have left the end as
Time to 'go'
on the belief that more elegant programmatic expressions in lisp and
other expressive langauges yield regularly to the most basic imperative
transfers of control in the most basic of languages, which Java surely is.
Ah well. Please feel free to ignore me. I'm a compulsive tinkerer of
wording and style, even in humor and other fiction...
Kent M Pitman <······@world.std.com> writes:
> twist this aside back into vague relevance, our civilization as a whole
> will be lost to others, like Teco in line noise, if we don't find budget
> to intentionally trasmit some easier to decode formats than commerce seems
> to be devising of late...
Perhaps XML's closing tag redundancy is not such a bad idea after all...
"We're currently working on the hypothesis that this is a fragment
from an invocation of or prayer to one of this culture's deities or
major cultural figures. From the bits we've been able to decode, we
think that the recipient of the plea might have been called BODY. Or
perhaps TABLE or FONT"
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
I think a lot of signal intelligence work involves detailed recording of
transmission start/stop times. The fact that a transmission took place
is important knowledge even if the contents are not known. Many problems
with networks can be diagnosed by examining only a trail of
from/to/timestamp tuples. Analysis of email traffic is analogous in that
much can be learned by looking at from/to totals by time slot without
knowing the contents of any message.
In SETI the first problem is establishing that there is traffic, not
necessarily decoding the traffic. Unless the SETI traffic is an
"infinitely long continuous stream", there will be stop/start patterns
as files or packets are transmitted. If the packets are encypted
television packets, the packets will arrive at precise and regular
intervals. Other transmission types will have traffic bursting and
slowing in generally-recognizable patterns.
Kent M Pitman wrote:
...
> Incidentally, this has been a concern of mine for a long time about the
> SETI project. We worry that there are few people out there transmitting,
> but the problem is worse than I often hear it told. Only nascent
> civilizations will transmit messages without compression, since
> compressionless transmission is such a bad use of bandwidth. Compressed
> transmissions, though, have the problem that they approach randomness.
> "A bit is a surprise"; so when full compression has occurred, almost every
> bit is a surprise, and there's little "information" left in the bits.
> That means that the only thing SETI can recognize will be either intentional
> communications (which will surely contain massive redundancy, and may
> hopefully exploit the prisoner's dilemma in other ways) or else the
> communication of very early civilizations, pre-compression. The situation
> featured in Contact, where a civilization notices the 'momentary' event
> of our world broadcasting uncompressed must be extremely rare. And, to
> twist this aside back into vague relevance, our civilization as a whole
> will be lost to others, like Teco in line noise, if we don't find budget
> to intentionally trasmit some easier to decode formats than commerce seems
> to be devising of late...
...
Joe Marshall <···@ccs.neu.edu> writes:
> ·····@unlambda.com (James A. Crippen) writes:
> > No, TI sold their computing systems division to HP. The Explorer
> > project was shut down and disposed of mere months before that sale.
> > So the Explorer never went to HP.
>
> I stand corrected.
I am not so sure how accurate this information is. HP was definitely
providing support (for customers with TI support contracts), hardware
spares, and patches for the Explorer system after it acquired the
various business units from TI.
·································@hotmail.com (Franz Kafka) writes:
>>
>> Here's a line from COMPILER;COMPILE.LISP:
>>
>> ;;; Copyright (C) 1980, Massachusetts Institute of Technology
>>
> Since it was copyrighted by MIT and the head of fsf workers for
> fsf he might be willing to gpl the code for the Lispm that MIT
> developed.
I can't parse the head phrase of that sentence.
> I know that we can't get Symbolic's extensions; I found
> that they are still in business--I might even buy a system from them
> as soon as I can get some money.
The changes made by Symbolics to the LispM OS were much more extensive
than 'extensions'. The various LispMs were distinctly different
operating systems and hardware, although they were very similar in
principle.
> We might be able to talk TI into
> releaseing their extensions--along with LMI's extensions--because
> both products are not longer maintained or sold.
Nobody's tried to talk to TI as far as I know. If you want to then
good luck. I frankly think that they will first ask for money for the
rights, then if turned down they will work out some way to prosecute
so that they can make up the cost of the time wasted. Or even more
likely, they will just ignore you.
> I'm sure that if MIT releases the sources that they own, the Lisp
> community will produce a new OS from the base system that is owned
> by MIT--I'm not saying that this will happen overnight, but it will
> happen eventually.
Sure. That sounds like it would definitely happen. But you'd need to
get MIT to license the code officially first. Till then any use of it
is theft. But they've done similar things so many times that it
wouldn't be much trouble for them.
> I also hope that some company will offer a Lispm Environment for sale
> with a good price for students, I know I'll buy one if the price is
> reasonable. (>$500 for students; full time students can't afford much
> more.)
> How good was Meledy as a Lispm Environment; I think it's student price
> was $250 if you can still get it. (How does it compair to Genera?)
Melody was based on Interlisp, not MIT MACLisp. It's quite different
from Common Lisp. You might find it quite confusing. Although I
believe that Xerox later released a flavor that was CL-compatible.
It's nowhere near as functional as the MIT-derived LispMs, and lacks a
lot of the integration that made the MIT LispMs so easy to use.
If you can get a copy of Melody let us know what it's like. I'd like
to hear. But I don't want to spend my time on it because I think it's
kind of a dead end.
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
On Fri, 04 Apr 2003 16:22:02 -0900, James A. Crippen <·····@unlambda.com> wrote:
> If you can get a copy of Melody let us know what it's like. I'd like
> to hear. But I don't want to spend my time on it because I think it's
> kind of a dead end.
For anyone interested in playing with Medley, the PARC LFG Grammar
Writer's Workbench is available from Xerox
(ftp://ftp.parc.xerox.com/pub/lfg/). It is a Medley application, and
while I don't know how much of the environment is included (they may
have pared it down a bit), it may give a hint about how Medley
works. It is not available for MacOS X, unfortunately, so I can't play
with it myself and so don't know too much about it.
Another option is to buy Medley from Venue
(http://top2bottom.net/medley.html), which costs $1595 for a Linux x86
license or $3395 for various Unix systems.
* James A Crippen wrote:
> Melody was based on Interlisp, not MIT MACLisp. It's quite different
> from Common Lisp. You might find it quite confusing. Although I
> believe that Xerox later released a flavor that was CL-compatible.
> It's nowhere near as functional as the MIT-derived LispMs, and lacks a
> lot of the integration that made the MIT LispMs so easy to use.
I think you mean `medley' not `melody'. Medley was the `M' release of
InterLisp-D, and also the last one they gave a sensible name to - I
think subsequent releases were given numbers like Medley n.n I think.
The two previous releases were Koto and Lyric, can't remember the ones
before that (they were all musical terms). Medley had a pretty
reasonable CL system, but well pre-ANSI - no CLOS for instance (though
PCL ran in it, and later versions may have bundled PCL).
> If you can get a copy of Melody let us know what it's like. I'd like
> to hear. But I don't want to spend my time on it because I think it's
> kind of a dead end.
Is that more or less of a dead end than creating a new MIT-derived
LispM would be? I find it hard to distinguish the degrees of futility
here.
--tim
In article <··············@kappa.unlambda.com>,
James A. Crippen <·····@unlambda.com> wrote:
>·································@hotmail.com (Franz Kafka) writes:
>
>>>
>>> Here's a line from COMPILER;COMPILE.LISP:
>>>
>>> ;;; Copyright (C) 1980, Massachusetts Institute of Technology
>>>
>> Since it was copyrighted by MIT and the head of fsf workers for
>> fsf he might be willing to gpl the code for the Lispm that MIT
>> developed.
>
>I can't parse the head phrase of that sentence.
Looks like a simple typo. I think if you just change "workers" to "works"
it parses easily.
However, I suspect Franz's premise may be wrong. If someone works for MIT
and writes software, MIT gets to decide what the license is. Since
universities make quite a bit of money by licensing technology, they're
often very protective. In MIT's case, the only software technology I can
think of where they had pretty free licensing was stuff developed by
Project Athena -- the vendor partners paid hefty sums to be associated with
the project and get early releases of the technology, on the condition that
MIT be allowed to license them freely. But this was an exception to the
general style.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: ····@sonic.net
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <3E8C9E3E.E4165772@sonic.net>
Franz Kafka wrote:
>
> >
> > As for TI Explorers, if you can find one in working order *with the
> > funny fiber optic console cable* then lucky you. Make sure you look
> > into the mailing list (look around, you'll find it) and offer to share
> > software and load bands with people if you want to make friends.
> > You'll need them.
> >
>
> Who would I contact at TI; nobody there seems to even remember the
> Explorer--let alone know where I can find the source.
It's actually a double quest: First, you must find a copy of
Explorer - Then you must convince TI to allow you to release
it opensource. You may need to "decompile" it in order
to get a source code, which will be nearly as incomprehensible
as the machine code but at least a starting point.
> Would MIT be willing to share infomation about a LISP OS? They brought
> us GNU EMACS? I know the MIT version would be older then the other
> versions, but becasue they are a school they might release an GNU
> freeware version.
MIT has lots of things they know about LispM's which they cannot
tell you or release because they have license agreements with
Symbolics (or with whomever now owns Symbolics' IP). And I'd
hesitate to assign too much responsibility for EMACS to MIT --
EMACS is mostly the result of the obsession of a single individual.
> Didn't Symbolics file Chapt. 11 and Symbolics Tec. flop--I've been
> trying to find a used Lispm and after 1996--Symbolics.com went
> down--it has never went up again, but I've seen mirror sites.
If so then someone else must now own their IP. It would be an
important first step to find out who.
> How old does the OS have to be before it falls into the public domain?
Patents last 20 years; corporate copyrights for American companies
are up to about a century now and getting longer every time Mickey
Mouse threatens to escape his continuing enslavement by Disney (who
ought to be ashamed of themselves for their baldfaced robbery of the
public domain, but that's another rant).
What that means is that 20 years after they produced it, (which
judging by the last publication dates of the manuals would be
around 2011, or judging from the first versions would be about
now) you can copy any ideas or techniques in a new work. But
you can't use their source code without permission in this
lifetime, unless Disney is first destroyed. And even if Disney
is destroyed, it probably won't be less than three-quarters of a
century.
> It someone wrote a microcode emulator--if they owned the machine they
> could use a Logic Analyzer to probe it without having to understand
> the design principals of the microcode. They could create an Ivory or
> Explorer emulator which would load the Lisp OS.
The problem with this is that the microcode isn't resident on the
chip across power cycles. The Ivory had a central CPU core that ran
"microinstructions" and a "microcode cache" that stored sequences of
microinstructions. The microcode cache had 64 (? I may misremember
here) addresses, each of which could hold up to 32 microinstructions.
On bootup, the microcode cache was loaded from persistent storage
(usually a disk). In the machine code for this chip, the address of
a block of microinstructions in the microcode cache was equivalent
to an instruction that ran that sequence of microinstructions. You
could also use microinstructions directly in the machine code.
So anyway, the point is that if you come across some old machine that
contains a Symbolics Ivory chip but you don't have their IP on the
disk drive and motherboard of that machine, and you power it up, the
microcode cache won't contain the same blocks of microcode that they
contained when that chip would power up and load the cache in a
Symbolics machine. If it fails to load anything from persistent
storage into the microcode cache, your logic analyzer would tell
you how the chip behaves when the microcode cache is zeroed - not
how it would behave with their IP loaded into the cache. And the
machine code, all of it, for the Genera system, assumed particular
loadings of the microcode cache and is incomprehensible or at least
multivalent in a very complex way in the lack of exact knowledge
of that loading.
> I am concered about the technical aspects of this project--not the
> legal or moral or ethical ones. I'd love to see a GNU Lisp OS build
> within the next few years--it has already been ten years since they
> were built, how much longer do we have to wait to rebuild them?????
About now, if you follow the earliest design of Genera. But I
think you'd need to invest at least ten years working obsessively
on it before you got something compelling enough to get critical
mass for opensource development anyway.
> What ever happened to Macsyma.com--I bought there product but their
> site went down as soon as Symbolics.com did.
Hooboy. Long story, many twists and turns, but it has a happy ending.
Macsyma was originally developed by MIT under an ARPA grant. In 1982
it was licensed to Symbolics Inc, which triggered a "no-freeze-out"
clause in the terms of the original grant under which it was developed,
and that resulted in DARPA getting its own fork of the Macsyma source
code. Genera was largely built to support this application, and
according to some the early ARPANET (precursor to the Internet) was
built mainly in order to provide access to it for researchers and
military contractors. Talk about a killer app!
In 1983 or thereabouts, Dr. William Schelter, a CS professor at the
University of Texas and longtime LispM enthusiast, made an offer to
DARPA to do the maintenance of their version of Macsyma under contract,
which they granted and which task he undertook. This fork of the
Macsyma source code is the original LISP code licensed to DARPA by
MIT under the terms of the ARPA grant under which it was developed;
the commercial version, sold by Symbolics and later Macsyma Inc, was
a separate fork.
In 1992, Symbolics Inc. licensed its version of Macsyma to a new
company, Macsyma, Inc. But that doesn't turn out to be important
in this story except that it made "Macsyma" into a company name which
couldn't be used for a different version after that.
In 1998, when Macsyma ceased to be available from commercial sources,
DARPA granted Dr. Schelter permission to redistribute their version
of it royalty-free, but under a different name so as not to confuse
it with the erstwhile commercial product and now-registered company
name. He proceeded to do so for three years. The alternate name he
chose is "Maxima." People ignored it in droves because by then the
commercial version had substantial extensions such as PD which Maxima
lacked. Then, in 2001, Dr. Schelter died of a heart attack.
There was some confusion about the changeover, but eventually a
sourceforge project took over its maintenance and distribution, and
a GPL'd version of it can be found today at
http://maxima.sourceforge.net .
> If Lispm companys are still in business, as people keep telling me,
> why can't I find Lispms being sold anywhere on the net, not even on
> EBay.
Two LispMs have been sold on ebay in the last year. If you want one,
you just need to have patience and be persistent. Oh, and be ready to
bid high; collectors are paying museum-piece prices for these, which is
at this point a couple orders of magnitude higher than the cost of
equivalent processing power in other hardware.
Bear
(used to hack LispMs in college)
····@sonic.net writes:
> Franz Kafka wrote:
>>
>> >
>> > As for TI Explorers, if you can find one in working order *with the
>> > funny fiber optic console cable* then lucky you. Make sure you look
>> > into the mailing list (look around, you'll find it) and offer to share
>> > software and load bands with people if you want to make friends.
>> > You'll need them.
>> >
>>
>> Who would I contact at TI; nobody there seems to even remember the
>> Explorer--let alone know where I can find the source.
TI doesn't have anything on Explorers anymore. People who work there
have personally told me so. They trashed it all months before they
sold their entire computing equipment division to HP.
The only Explorer related things that TI still has are the IP rights,
such as patents and copyrights. Getting that out of the hands of
their lawyers could be entertaining.
TI basically would like the Explorer to be completely forgotten.
They've already forgotten about it.
> It's actually a double quest: First, you must find a copy of
> Explorer - Then you must convince TI to allow you to release
> it opensource. You may need to "decompile" it in order
> to get a source code, which will be nearly as incomprehensible
> as the machine code but at least a starting point.
Like all LispMs, the Explorer came with the OS source. The
*microcode* sources were almost never included, except for clients
with certain special needs. The documentation for the macrocode
engine is pretty sparse but it's almost what you need to know to
construct an emulator. The hardware interface part is hard though,
and undocumented. It has to be worked out by looking at the
disassembled macrocode and paying attention to memory usage. (The
Explorer has *two* memory maps, one for the macrocode Lisp system and
the 'real' one that the microcode and NuBus backplane know about.)
>> Would MIT be willing to share infomation about a LISP OS? They brought
>> us GNU EMACS? I know the MIT version would be older then the other
>> versions, but becasue they are a school they might release an GNU
>> freeware version.
>
> MIT has lots of things they know about LispM's which they cannot
> tell you or release because they have license agreements with
> Symbolics (or with whomever now owns Symbolics' IP). And I'd
> hesitate to assign too much responsibility for EMACS to MIT --
> EMACS is mostly the result of the obsession of a single individual.
It might be possible to find someone with the sources from the CADR,
which would be basically owned by MIT and not by Symbolics. You'd
have to look at each source file to see if it was copyrighted by one,
the other, or both. Same goes for LMI copyright, which would be owned
by TI.
>> How old does the OS have to be before it falls into the public domain?
>
> Patents last 20 years; corporate copyrights for American companies
> are up to about a century now and getting longer every time Mickey
> Mouse threatens to escape his continuing enslavement by Disney (who
> ought to be ashamed of themselves for their baldfaced robbery of the
> public domain, but that's another rant).
>
> What that means is that 20 years after they produced it, (which
> judging by the last publication dates of the manuals would be
> around 2011, or judging from the first versions would be about
> now) you can copy any ideas or techniques in a new work. But
> you can't use their source code without permission in this
> lifetime, unless Disney is first destroyed. And even if Disney
> is destroyed, it probably won't be less than three-quarters of a
> century.
The patent issued for Symbolics for the 3600 was in 1985. So count
from then. That patent is available online if you search for it.
It's huge though, including the entire octal dump of microcode.
TI issued patents all over the place, from the day they first met LMI
all the way to the very end of the Explorer line. Theirs are much
less comprehensive and scattered, and are of little use except for
occasional reference for certain hardware specs not otherwise
documented.
> The problem with this is that the microcode isn't resident on the
> chip across power cycles. The Ivory had a central CPU core that ran
> "microinstructions" and a "microcode cache" that stored sequences of
> microinstructions. The microcode cache had 64 (? I may misremember
> here) addresses, each of which could hold up to 32 microinstructions.
> On bootup, the microcode cache was loaded from persistent storage
> (usually a disk). In the machine code for this chip, the address of
> a block of microinstructions in the microcode cache was equivalent
> to an instruction that ran that sequence of microinstructions. You
> could also use microinstructions directly in the machine code.
Direct references to microinstructions used the DTP-U-ENTRY, at least
on the Exploder. That's what makes emulating it hard, because you
have to emulate ucode entries just like other macrocode. And the
ucode stuff usually did the hardware interface stuff, like I/O.
> So anyway, the point is that if you come across some old machine that
> contains a Symbolics Ivory chip but you don't have their IP on the
> disk drive and motherboard of that machine, and you power it up, the
> microcode cache won't contain the same blocks of microcode that they
> contained when that chip would power up and load the cache in a
> Symbolics machine.
The microcode load was supplied off of the Breath Of Life tape (or
CD). Without that all you got was the FEP.
>> I am concered about the technical aspects of this project--not the
>> legal or moral or ethical ones. I'd love to see a GNU Lisp OS build
>> within the next few years--it has already been ten years since they
>> were built, how much longer do we have to wait to rebuild them?????
>
> About now, if you follow the earliest design of Genera. But I
> think you'd need to invest at least ten years working obsessively
> on it before you got something compelling enough to get critical
> mass for opensource development anyway.
It looks to be taking that kind of obsession, yes. Which is rare,
yes. Which is why we're not seeing anything yet.
>> If Lispm companys are still in business, as people keep telling me,
>> why can't I find Lispms being sold anywhere on the net, not even on
>> EBay.
>
> Two LispMs have been sold on ebay in the last year. If you want one,
> you just need to have patience and be persistent. Oh, and be ready to
> bid high; collectors are paying museum-piece prices for these, which is
> at this point a couple orders of magnitude higher than the cost of
> equivalent processing power in other hardware.
As I posted elsewhere you can usually get a used working XL1200 for
around $3600 bucks. Shipping is outrageous. It uses SCSI so you
don't have much problem with disks (except that only disks which can
be formatted at 1280 bytes per block will work). And it uses ethernet
so connectivity isn't a problem either. The console is irreplaceable,
as it's entirely hardware specific. The console cable (which carries
monitor output and key/mouse input as well as serial) is also
irreplaceable unless you're really good at making cables.
The Explorer is not commercially available anywhere, but can be had
occasionally from warehouse or machine room cleanouts. It has a fiber
optic cable for its console which uses some weird connector unknown to
mankind. Replacing it is very hard. Other than that it's much like
the Symbolics boxen, but instead of VME bus it uses NuBus (the
predecessor to that used in Macintoys).
LMI Lambdas and MIT CADRs are essentially unavailable unless the
Goddess smiles upon you. And even then it's hard to keep one around
because they're so big and crufty. You basically have to be a wizard
to maintain one.
Xerox D-Machines are marginally more available and have various
limitations of their own, particularly el-cheapo displays that let out
magic smoke frequently.
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
> >
> > Patents last 20 years; corporate copyrights for American companies
> > are up to about a century now and getting longer every time Mickey
> > Mouse threatens to escape his continuing enslavement by Disney (who
> > ought to be ashamed of themselves for their baldfaced robbery of the
> > public domain, but that's another rant).
> >
> > What that means is that 20 years after they produced it, (which
> > judging by the last publication dates of the manuals would be
> > around 2011, or judging from the first versions would be about
> > now) you can copy any ideas or techniques in a new work. But
> > you can't use their source code without permission in this
> > lifetime, unless Disney is first destroyed. And even if Disney
> > is destroyed, it probably won't be less than three-quarters of a
> > century.
>
People can anonymously use 20 year old source code. I don't think
lawyers will be willing to spend millions trying to track down a
hacker using an ip-spoofer or an anonymous remailer. And, unlike Mickey Mouse
once it's out it's out.
The GNU folks are not looking to turn a profit only to release freeware.
If the twenty year or even ten year old code is released--the cat would
be out of the bag; once the code is posted just try to stop hardware
hackers and Lisp hackers from using it.
TI doen't even remember the explorer; I don't think they'd try to stop
it release.
·································@hotmail.com (Franz Kafka) writes:
> > >
> > > Patents last 20 years; corporate copyrights for American companies
> > > are up to about a century now and getting longer every time Mickey
> > > Mouse threatens to escape his continuing enslavement by Disney (who
> > > ought to be ashamed of themselves for their baldfaced robbery of the
> > > public domain, but that's another rant).
> > >
> > > What that means is that 20 years after they produced it, (which
> > > judging by the last publication dates of the manuals would be
> > > around 2011, or judging from the first versions would be about
> > > now) you can copy any ideas or techniques in a new work. But
> > > you can't use their source code without permission in this
> > > lifetime, unless Disney is first destroyed. And even if Disney
> > > is destroyed, it probably won't be less than three-quarters of a
> > > century.
> >
>
> People can anonymously use 20 year old source code. I don't think
> lawyers will be willing to spend millions trying to track down a
> hacker using an ip-spoofer or an anonymous remailer. And, unlike
> Mickey Mouse once it's out it's out.
Well your argument is that you can steal and not be worth catching is
interesting for your opinion of private property. Society thinks that
stealing is bad and enacts laws to prevent and punish theft. And if
Mickey Mouse ever gets in the public domain it will stay there, Disney
will have failed.
>
> The GNU folks are not looking to turn a profit only to release freeware.
> If the twenty year or even ten year old code is released--the cat would
> be out of the bag; once the code is posted just try to stop hardware
> hackers and Lisp hackers from using it.
From what I have observed the gnu folks have a very specific
social/political agenda that they pursue through the gpl and
systematically lying about what it means to use it, redefining "free" to
a definition that I have never seen in a dictionary comes to mind. I
also remember the claim that the fsf made about code generated from
their tools being gpled. They claimed that bison and gcc output files
were under the gpl, if I remember correctly. This claim did not last
long, get this crap out of my shop said management(cheaper to buy the
compiler from sun).
>
> TI doen't even remember the explorer; I don't think they'd try to stop
> it release.
I do not agree. Even if there is no immediate and direct losses it is
dangerous for a owner not to protect his property. The reason for
this is that when you do not protect part of it you open the rest of
it for attack. So instead of having to pay for one legal action you now
have to deal with 10. Part of the reason for unix's success is that
in its early non product days it was ATT's property and you *did not
mess with ATT's legal department*. Also by not protecting it, if it
is used by some third party to do something bad, you may be sued
because you encouraged them to do this by not taking any action( think
implied consent). This is much more likely if you have more money
then the other people involved.
marc
[ replying to comp.lang.lisp only
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
Marc Spitzer <········@optonline.net> writes:
> ·································@hotmail.com (Franz Kafka) writes:
>
> > People can anonymously use 20 year old source code. I don't think
> > lawyers will be willing to spend millions trying to track down a
> > hacker using an ip-spoofer or an anonymous remailer. And, unlike
> > Mickey Mouse once it's out it's out.
>
> Well your argument is that you can steal and not be worth catching is
> interesting for your opinion of private property. Society thinks that
> stealing is bad and enacts laws to prevent and punish theft. And if
> Mickey Mouse ever gets in the public domain it will stay there, Disney
> will have failed.
You might want to look up what the statutory damages are for
copyright infringement, but just about any lawyer would take them on
contingency because
(a) they are enormous ($750-$30,000 statutory damages just for showing
there was an infringement of a registered work, and up to $150,000
if you can prove the infringement is "willful". What's evidence of
willfulness? Hmmm. Good question. I wonder if saying "People can
anonymously use 20 year old source code. I don't think lawyers
will be willing to spend millions trying to track down..." on a
permanent, globally available medium like Usenet would qualify...?
http://www4.law.cornell.edu/uscode/17/504.html
(b) as to the question of the millions that the lawyers will spend,
"Sec. 505. - Remedies for infringement: Costs and attorney's fees
In any civil action under this title, the court in its discretion
may allow the recovery of full costs by or against any party other
than the United States or an officer thereof. Except as otherwise
provided by this title, the court may also award a reasonable
attorney's fee to the prevailing party as part of the costs."
http://www4.law.cornell.edu/uscode/17/505.html
As a general rule, I've been told that it's not wise to talk about
willfully violating a copyright just because you don't think someone
will have the money to go after you...
Marc Spitzer wrote:
> Well your argument is that you can steal and not be worth catching is
> interesting for your opinion of private property. Society thinks that
> stealing is bad and enacts laws to prevent and punish theft. And if
> Mickey Mouse ever gets in the public domain it will stay there, Disney
> will have failed.
Disney doesn't make much money out of rehasing old 30s Mickey Mouse books
(maybe they could today by rehashing the hooray-patriotic Mickey Mouse of
the early 40s ;-). They make money out of writing new Mickey Mouse stories,
and Mickey Mouse itself has changed quite a lot since (it started as a
black mouse with short trousers and a tail, which acted as a slapstick
character - nowadays, no tail, normal clothing, and it's a detective). The
current Mickey Mouse would still be under copyright protection if the
original one was set free.
I'd like Walt Disney to pay a few billions to the heirs of the Grimm
Brothers for "stealing" Snowwhite and Cinderella. Fair is fair. If you want
copyright to last for infinity minus one, you ought to pay the price.
Note also that copying is not theft, quite the contrary. Copying is a
natural law, restricted by gouvernment for a limited time, so copyright is
the reverse of a natural law, while property is a natural law, and
restrictions to property (such as taxes and regulations) need to have
exceptional status, too.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Marc Spitzer <········@optonline.net> writes:
> Part of the reason for unix's success is that
> in its early non product days it was ATT's property and you *did not
> mess with ATT's legal department*.
But the source was more or less freely available, wasn't it? Which
surely was *the* reason for unix's success. And all that without AT&T
giving up its property. Maybe this could be a model for the release of
the Explorer source? I'd hope so.
'Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
[ replying to comp.lang.lisp only
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
Andreas Eder <············@t-online.de> writes:
> Marc Spitzer <········@optonline.net> writes:
>
> > Part of the reason for unix's success is that
> > in its early non product days it was ATT's property and you *did not
> > mess with ATT's legal department*.
>
> But the source was more or less freely available, wasn't it? Which
> surely was *the* reason for unix's success. And all that without AT&T
> giving up its property. Maybe this could be a model for the release of
> the Explorer source? I'd hope so.
Uh, if by "freely available" you mean "it was present at numerous
sites", then the answer might be yes.
I'm pretty sure I know of one case where major corporations refused to
hire an otherwise-qualified individual from a college where they had
_seen_ the Unix sources, though. The apparent problem was that they
were afraid that hiring him would lead to suit over him sharing AT&T's
ideas now that he was contaminated by knowing how they did Unix...
Curiously, I doubt that the license that Unix had and the license that
Symbolics had were very different. Both probably required that the
information in the sources be kept strictly trade secret, etc. I'm
sure there were some differences of wording, but I wonder if the
differences were consequential. I bet the main difference was in the
zeal and focus of the legal department at the companies. I don't know
if that was an intrinsic difference in how they did business, or an
accidental consequence of their respective market shares, though.
In article <··············@elgin.eder.de>,
Andreas Eder <············@t-online.de> wrote:
>Marc Spitzer <········@optonline.net> writes:
>
>> Part of the reason for unix's success is that
>> in its early non product days it was ATT's property and you *did not
>> mess with ATT's legal department*.
>
>But the source was more or less freely available, wasn't it? Which
>surely was *the* reason for unix's success. And all that without AT&T
>giving up its property. Maybe this could be a model for the release of
>the Explorer source? I'd hope so.
My understanding is that AT&T licensed Unix source code inexpensively to
many universities. This was when they were still part of the Bell System
monopoly, so they weren't allowed to be a software company. But they
didn't just give it away. And later on when other companies tried to sell
versions of Unix derived from this (e.g. BSD Unix) they went after them.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
"Barry Margolin" <··············@level3.com> wrote in message
·····················@paloalto-snr1.gtei.net...
....
> My understanding is that AT&T licensed Unix source code inexpensively to
> many universities. This was when they were still part of the Bell System
> monopoly, so they weren't allowed to be a software company. But they
> didn't just give it away. And later on when other companies tried to sell
> versions of Unix derived from this (e.g. BSD Unix) they went after them.
>
Someone has turned up a price lists from the early 80s.
As of Sept 1983, System V (variant not specified), 32V, and
7th Edition were each $400.
As of February 1984, SVr2 was $800, with extra charges
for the 68K compiler and some other things like
WWB (Writer's Workbench).
In this later pricelist, commercial SVr2 was $43K, with
$16K for each additional CPU.
The BSDI suit ("went after them") is more complicated,
and ten years later.
BSDI's claim was that the system they adapted from
the BSD-Lite rendition was uncontaminated by AT&T-derived
code. To condense into two words, BSDI won.
Others had already produced Unix-alikes (e.g. Mark Williams
Company, with Coherent) without disturbance. I suspect
that the USL/AT&T people were reluctant to believe that a university
that had spent the last 10+ years distributing an AT&T licensed
version of the system could magically produce a truly independent
rendition.
Dennis
Andreas Eder <············@t-online.de> writes:
> Marc Spitzer <········@optonline.net> writes:
>
> > Part of the reason for unix's success is that
> > in its early non product days it was ATT's property and you *did not
> > mess with ATT's legal department*.
>
> But the source was more or less freely available, wasn't it? Which
The source was licenced. The univ. paid a small fee for a site licence
for unix, a few hundred dollars to cover taps and shiping. And they
got a site licence.
> surely was *the* reason for unix's success. And all that without AT&T
The reason for unix's success was that for a small fee the univ got:
1: time sharing os
2: everything you need for a compilers course
3: everything needed for an OS course
4: later a networking course(BSD/IP)
This lead to when startups like Sun and Apollo hired people to
build their new desktop computers the people they hired had much
experience hacking on unix and they said "go get us a unix licence".
Then ATT relized they had a product and charged accordingly.
> giving up its property. Maybe this could be a model for the release of
> the Explorer source? I'd hope so.
If you use this model the source never gets released.
marc
>
> 'Andreas
> --
> Wherever I lay my .emacs, there�s my $HOME.
Marc Spitzer <········@optonline.net> writes:
>
> The reason for unix's success was that for a small fee the univ got:
> 1: time sharing os
> 2: everything you need for a compilers course
> 3: everything needed for an OS course
> 4: later a networking course(BSD/IP)
>
> This lead to when startups like Sun and Apollo hired people to build
> their new desktop computers the people they hired had much
> experience hacking on unix and they said "go get us a unix licence".
> Then ATT relized they had a product and charged accordingly.
appearance of inexpensive processor industry. previous computer
offerings had proprietary operating system offerings ... the expense
of creating a proprietary operating system offering could be an order
of magnitude than the cost of developing the new generation of
processor offerings.
being able to deploy a (portable) operating system on the processor
for a fraction of the hardware development costs (rather than several
times the hardware development costs) was significant. being able to
pick up people that already had skills in the operating system was an
additional characteristic of the emeraging portable operating system.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
In article <·············@earthlink.net>,
Anne & Lynn Wheeler <····@garlic.com> wrote:
>Marc Spitzer <········@optonline.net> writes:
>>
>> The reason for unix's success was that for a small fee the univ got:
>> 1: time sharing os
>> 2: everything you need for a compilers course
>> 3: everything needed for an OS course
>> 4: later a networking course(BSD/IP)
>>
>> This lead to when startups like Sun and Apollo hired people to build
>> their new desktop computers the people they hired had much
>> experience hacking on unix and they said "go get us a unix licence".
>> Then ATT relized they had a product and charged accordingly.
>
>appearance of inexpensive processor industry. previous computer
>offerings had proprietary operating system offerings ... the expense
>of creating a proprietary operating system offering could be an order
>of magnitude than the cost of developing the new generation of
>processor offerings.
>
>being able to deploy a (portable) operating system on the processor
>for a fraction of the hardware development costs (rather than several
>times the hardware development costs) was significant. being able to
>pick up people that already had skills in the operating system was an
>additional characteristic of the emeraging portable operating system.
All of this is true, but does not explain why it was Unix rather than
any of the others.
The explanation is almost certainly that it was freely available to
USA universities, especially those in Silicon Valley, and some people
from those places started up the workstation companies.
Regards,
Nick Maclaren.
"Nick Maclaren" <····@cus.cam.ac.uk> wrote in message
·················@pegasus.csx.cam.ac.uk...
[SNIP]
> All of this is true, but does not explain why it was Unix rather than
> any of the others.
One key feature of UNIX that has always struck me
is that conceptually it provides a very simple set
of abstractions that hide the hardware well, and
portably. Many other OSes just don't do that, they
are wedded to specific hardware or use "virtual
machines" to fake it.
> The explanation is almost certainly that it was freely available to
> USA universities, especially those in Silicon Valley, and some people
> from those places started up the workstation companies.
Didn't hurt progress, but the ball *appeared* to
be rolling before that really built up a head of
steam.
Cheers,
Rupert
In article <·················@saucer.planet.gong>,
Rupert Pigott <···@dark-try-removing-this-boong.demon.co.uk> wrote:
>"Nick Maclaren" <····@cus.cam.ac.uk> wrote in message
>·················@pegasus.csx.cam.ac.uk...
>
>> All of this is true, but does not explain why it was Unix rather than
>> any of the others.
>
>One key feature of UNIX that has always struck me
>is that conceptually it provides a very simple set
>of abstractions that hide the hardware well, and
>portably. Many other OSes just don't do that, they
>are wedded to specific hardware or use "virtual
>machines" to fake it.
The other portable and semi-portable operating systems of the time
were pretty similar to Unix in that respect, and sometimes simpler.
>> The explanation is almost certainly that it was freely available to
>> USA universities, especially those in Silicon Valley, and some people
>> from those places started up the workstation companies.
>
>Didn't hurt progress, but the ball *appeared* to
>be rolling before that really built up a head of
>steam.
Yes, but why did Unix replace the others? There were lots of balls
rolling, but only Unix kept doing so.
Regards,
Nick Maclaren.
On Sun, 06 Apr 2003 19:56:00 +1000, Nick Maclaren wrote:
> In article <·················@saucer.planet.gong>, Rupert Pigott
> <···@dark-try-removing-this-boong.demon.co.uk> wrote:
>>"Nick Maclaren" <····@cus.cam.ac.uk> wrote in message
>>·················@pegasus.csx.cam.ac.uk...
>>
>>> All of this is true, but does not explain why it was Unix rather than
>>> any of the others.
>>
>>One key feature of UNIX that has always struck me is that conceptually
>>it provides a very simple set of abstractions that hide the hardware
>>well, and portably. Many other OSes just don't do that, they are wedded
>>to specific hardware or use "virtual machines" to fake it.
>
> The other portable and semi-portable operating systems of the time were
> pretty similar to Unix in that respect, and sometimes simpler.
Out of interest, could you put a name to any of the plausible
alternatives? I don't know how portable was FLEX, which was putting in a bit
of an appearance on 6809 systems: never used it. I think that the
Cambridge thing that lay under what became AmigaOS (whos own name I
forget) came later, I think. CP/M managed to be ported to the 68000, but
was pretty limited as OSes go.
I.e., Unix had already swpept all before it before I was in a position to
notice...
>>> The explanation is almost certainly that it was freely available to
>>> USA universities, especially those in Silicon Valley, and some people
>>> from those places started up the workstation companies.
>>
>>Didn't hurt progress, but the ball *appeared* to be rolling before that
>>really built up a head of steam.
>
> Yes, but why did Unix replace the others? There were lots of balls
> rolling, but only Unix kept doing so.
I'd like a counter-example to Henry Spencer's "Those that do not
understand Unix are condemned to reinvent it. Badly."
Are you perhaps thinking of one of the lisp or forth or smalltalk
language/OSes that have been the focus of this thread?
--
Andrew
Andrew Reilly wrote:
> I think that the
> Cambridge thing that lay under what became AmigaOS (whos own name I
> forget) came later, I think.
TripOS. I think it was developed on an IBM mainframe in the late 1970s.
The 68k port came later.
--
Wishing you good fortune,
--Robin Kay-- (komadori)
Robin KAY wrote:
> TripOS. I think it was developed on an IBM mainframe in the late 1970s.
> The 68k port came later.
Tripos was in BCPL. If it had been in a language that had even the
minimal data abstraction capabilities of C it might have had a chance.
Though the Tripos parts were never the most attractive parts of
AmigaDOS, the Exec was a much cleaner design. Exec was much too late to
make the kind of splash UNIX did, of course.
In article <····················@news-server.bigpond.net.au>,
Andrew Reilly <·······@bigpond.net.au> wrote:
>
>Out of interest, could you put a name to any of the plausible
>alternatives? I don't know how portable was FLEX, which was putting in a bit
>of an appearance on 6809 systems: never used it. I think that the
>Cambridge thing that lay under what became AmigaOS (whos own name I
>forget) came later, I think. CP/M managed to be ported to the 68000, but
>was pretty limited as OSes go.
After all these years, especially as I never used any of them, no.
Sorry. As Robin Kay says, Tripos was later and more CP/M-like. I can
remember a fair number of rude remarks being made about Tripos that
it was mere development and not research, even though it probably
had some new ideas.
Though we mustn't forget Edinburgh's work, with POP/2, EMAS etc.,
but I can't remember when their portable version was being developed
and how far it got.
>I.e., Unix had already swpept all before it before I was in a position to
>notice...
More or less and me, too. Though I used to bump into people who used
or favoured some of the other systems.
>I'd like a counter-example to Henry Spencer's "Those that do not
>understand Unix are condemned to reinvent it. Badly."
Oh, I can give lots of counter-examples, but most have fallen by the
wayside by now. Today, it isn't a bad rule of thumb.
>Are you perhaps thinking of one of the lisp or forth or smalltalk
>language/OSes that have been the focus of this thread?
To some extent, yes. Most of the ones that were language-independent
were rather CP/M-like rather than Unix-like, but all evidence is that
was a viable design for single-user workstations. I call MacOS and
MS-DOS as evidence of THAT :-)
Unix was one of the few complete operating systems, as distinct from
run-time executives and intermediates, that was practically portable.
But that wasn't regarded as an essential target in the 1970s (or 1990s,
for that matter).
Regards,
Nick Maclaren.
Nick Maclaren wrote:
>>Are you perhaps thinking of one of the lisp or forth or smalltalk
>>language/OSes that have been the focus of this thread?
> To some extent, yes. Most of the ones that were language-independent
> were rather CP/M-like rather than Unix-like, but all evidence is that
> was a viable design for single-user workstations. I call MacOS and
> MS-DOS as evidence of THAT :-)
I'm not sure how you figure MacOS is in any way CP/M like. There wasn't
even as much of an OS as CP/M once you stripped the GUI away...
everything was built around that. But what there was, was far more
sophisticated than CP/M and MS-DOS.
As a *workstation* OS, CP/M and MS-DOS were not in the running. They
were at best boot loaders for things like Windows, Desqview, and Gem.
In article <·············@jeeves.eng.abbnm.com>,
Peter da Silva <·····@abbnm.com> wrote:
>Nick Maclaren wrote:
>>>Are you perhaps thinking of one of the lisp or forth or smalltalk
>>>language/OSes that have been the focus of this thread?
>
>> To some extent, yes. Most of the ones that were language-independent
>> were rather CP/M-like rather than Unix-like, but all evidence is that
>> was a viable design for single-user workstations. I call MacOS and
>> MS-DOS as evidence of THAT :-)
>
>I'm not sure how you figure MacOS is in any way CP/M like. There wasn't
>even as much of an OS as CP/M once you stripped the GUI away...
>everything was built around that. But what there was, was far more
>sophisticated than CP/M and MS-DOS.
I am distinguishing the true operating systems from the run-time
executives. Unix is one of the former; MacOS, CP/M, MS-DOS etc.
are the latter.
>As a *workstation* OS, CP/M and MS-DOS were not in the running. They
>were at best boot loaders for things like Windows, Desqview, and Gem.
Eh? Lots of people used them without those. The IBM PC got established
before Windows 3 was ever perpetrated.
Regards,
Nick Maclaren.
There appears to be a common misconception in this thread that at the
time Unix was created it was the only `real' operating system in the
sense that it provided a protected kernel. And that all other existing
operating systems were like DOS, CP/M, and MacOS in that they did not
offer
a protected kernel that performed scheduling and virtual memory.
This is the farthest thing from the truth, as anyone old enough to
remember
can tell you. While there were precursers to unprotected OSes like
OS/8 and
RT-11, they were in the minority. There were many estabilshed
protected OSes
that provided scheduling and virtual memory that were written before
and at
the approximate same time as Unix. VMS, OS/MVT, OS/VS2+TSO,
VM/370+CMS, TOPS-10,
TOPS-20, TENEX, all of the flavors of MCP+CANDE on the various
Boroughs machines, NOS on CDC machines,
to name just a few. Most of the flavors of MCP+CANDE were written in
SDL, a high-level Algol/PL-I derivative that in many ways is
higher-level than C.I believe that much of VMS is written in BLISS, a
cousin of C.I'm not sure but I believe that much of TENEX is written
in BCPL, another cousin of C. And then there was MULTICS, another
protected OS that provided scheduling and VM, which was written in
PL/I.And MULTICS even had the notion of a microkernel architecture:
the
secure code base was supposed to be only 4K.
And while not protected by classic means, there were numerous OSes
that provided scheduling and VM and were written in even higher-level
languages like
Lisp and SmallTalk: The MIT CADR and its derivatives:
Symbolics/Genera, the TI/Explorer; the Xerox D machines: Interlisp-D,
SmallTalk, and Cedar/Mesa, not to mention the UCSD Pascal system.
I would bet that DG has protected OSes on their machines. And so did
Prime. And Interdata, and Harris, and Varian,and RCA/Spectra70, and
Sperry/Univac. By the mid 70s, the notion of a protected OS with
scheduling, VM, time-sharing, and a consistent API, wirtten in a
high-level language was commonplace.So much so that the research
forefront shifted to things like the MIT CADR and the Xerox Alto and D
machines.The only reasons that DOS, CP/M, and MacOS are not are
a. the early microprocessor hardware that they were written for did
not provide
a protected mode because they were intended as controlers, not as
computers
Indeed, as far back as 1975, I was working on how to augment early
microprocessors like the 6800 and the 8080 with custom external
hardware to
provide protected mode and memory mapping hardware precisely so that
we could
build a real OS for them (and we even did).
b. the people who wrote DOS, CP/M, etc. were hobbyists who were
largely
unfamiliar with mainframe OSes and were more familiar with things like
OS/8
because that is what people in high school in the early 70s had access
to.
Though even TSS/8 and ETOS on the PDP-8 provided protection,
scheduling, and
VM.
Caveat Emptor: I have been in the field for `only' 30 years. Much of
what I report in this email is vague memory from my early teens and
may be inaccurate. I'm sure that there are people reading this who can
present more accurate history. But the point is this: Unix was not
unique in being a protected OS.
Nor was it unique in being written in a high-level language at the
time. I doubt that prior to the porting effort that it was necessarily
more portable than other such OSes written in high-level languages.
And many would argue that
it was far from the best OS at the time. The reasons that it caught on
lie elsewhere.
On Wed, 16 Apr 2003 14:49:53 +1000, Jeffrey Mark Siskind wrote:
> There appears to be a common misconception in this thread that at the
> time Unix was created it was the only `real' operating system in the
> sense that it provided a protected kernel. And that all other existing
> operating systems were like DOS, CP/M, and MacOS in that they did not
> offer
> a protected kernel that performed scheduling and virtual memory.
Oh, I don't think that that was the implication at all. Well, it
certainly wasn't what I implied in my original post (which didn't mention
MacOS).
To the best of my knowledge, all of the OSes that you mentioned, with
the exception of Multics and UCSD-Pascal (thanks for reminding me of
those!), were all the property of their respective system manufacturers,
and were tied to a particular hardware platform, whether they were coded
in an HLL or not. As such, they never stood a chance of being the
run-away success "universal OS" that Unix (which was not the product of a
system manufacturer) has become.
I squezed CP/M in there because whatever it was written in (PL/M and
assembler?), it was at least simple enough to have been ported to the 8086
and the 68000, as well as it's original 8080 base. I've used an
"enhanced" CP/M that was reverse engineered and coded in Z-80 assembler.
TripOS was portable and abstract, I believe, even though it wasn't
actually ported to much.
> Caveat Emptor: I have been in the field for `only' 30 years. Much of
Me only a bit more than 20 years: Post Unix :-)
> what I report in this email is vague memory from my early teens and may
> be inaccurate. I'm sure that there are people reading this who can
> present more accurate history. But the point is this: Unix was not
> unique in being a protected OS.
Certainly not. Even today there are others.
> Nor was it unique in being written in a high-level language at the time.
True.
> I doubt that prior to the porting effort that it was necessarily more
> portable than other such OSes written in high-level languages.
Perhaps not more portable than Multics, given it's layering, but there's
not much machine uniqueness poking through the abstractions. And the
porting effort happened early and often.
> And many
> would argue that
> it was far from the best OS at the time. The reasons that it caught on
> lie elsewhere.
If not portability, availability, and being "good enough" (many would say
better than good enough), what else?
Someone (perhaps Nick?) once wizely said that portability arises from
being ported. VMS has been ported once (to Alpha), and is being ported
again, to Itanium, so it's probably getting to be pretty portable. Maybe
one day it can become a standard OS product?
Windows-NT is/was portable, as is Windows-CE, but they came later.
--
Andrew
In article <···················@news-server.bigpond.net.au>,
Andrew Reilly <······@gurney.reilly.home> writes:
|> On Wed, 16 Apr 2003 14:49:53 +1000, Jeffrey Mark Siskind wrote:
|>
|> > There appears to be a common misconception in this thread that at the
|> > time Unix was created it was the only `real' operating system in the
|> > sense that it provided a protected kernel. And that all other existing
|> > operating systems were like DOS, CP/M, and MacOS in that they did not
|> > offer
|> > a protected kernel that performed scheduling and virtual memory.
|>
|> Oh, I don't think that that was the implication at all. Well, it
|> certainly wasn't what I implied in my original post (which didn't mention
|> MacOS).
No, but I may have started this. As far as I recall, almost all of
the PORTABLE operating systems of the early 1970s were very limited,
and often were jumped-up run-time executives. After all, even early
Unix used quite a lot of hardware function (e.g. a secure privileged
mode, secure memory protection and reliable, asynchronous interrupt
handling) that was not universal.
Of course, there is the religious debate about whether a form of
Unix that works only if the user processes do not do certain things
is 'true' Unix. This is at the core of the debate about whether it
could ever be implemented on an 80286/80287. It certainly COULDN'T
be if the processes were allowed to use arbitrary floating-point
instructions and were not required to poll for interrupts, because
of the failure of the hardware to save enough state for recovery on
interrupt.
In fact, one of the reasons that Tripos was developed was PRECISELY
because Unix couldn't be ported to some of the systems that people
wanted a system on. And not all of that was licensing ....
|> To the best of my knowledge, all of the OSes that you mentioned, with
|> the exception of Multics and UCSD-Pascal (thanks for reminding me of
|> those!), were all the property of their respective system manufacturers,
|> and were tied to a particular hardware platform, whether they were coded
|> in an HLL or not. As such, they never stood a chance of being the
|> run-away success "universal OS" that Unix (which was not the product of a
|> system manufacturer) has become.
That is, I think, the point. Unix was by far the simplest and most
portable of the gereric operating systems, though at the back of my
mind are some vague memories of competitors that never got out of
academia.
|> TripOS was portable and abstract, I believe, even though it wasn't
|> actually ported to much.
Oh, yes, it was. LOTS of systems, though few of them ever took off.
And it was later and more restrictive.
|> If not portability, availability, and being "good enough" (many would say
|> better than good enough), what else?
|>
|> Someone (perhaps Nick?) once wizely said that portability arises from
|> being ported. VMS has been ported once (to Alpha), and is being ported
|> again, to Itanium, so it's probably getting to be pretty portable. Maybe
|> one day it can become a standard OS product?
Not me! I would have said that portability arises from being designed
to be portable. I don't agree with that statement, though there is
some truth in it. I might have said that portability should always
be doubted until something is ported, or that the first port will
raise most of the issues, but those are not the same.
Unix and Windows/NT were designed to be portable; VMS wasn't.
Regards,
Nick Maclaren.
····@cus.cam.ac.uk (Nick Maclaren) wrote:
>
>Unix and Windows/NT were designed to be portable; VMS wasn't.
I don't think Unix was originally; it just turned out to be simple enough
that porting turned out to be easier than people expected.
Tony.
--
f.a.n.finch <···@dotat.at> http://dotat.at/
NORTH UTSIRE: SOUTH BECOMING VARIABLE 3. FAIR. MODERATE OR GOOD, OCCASIONALLY
POOR.
In article <·········@news.chiark.greenend.org.uk>,
Tony Finch <···@dotat.at> wrote:
>····@cus.cam.ac.uk (Nick Maclaren) wrote:
>>
>>Unix and Windows/NT were designed to be portable; VMS wasn't.
>
>I don't think Unix was originally; it just turned out to be simple enough
>that porting turned out to be easier than people expected.
Interesting. If so, I have been deluded for years :-) The person who
would know is Dennis Ritchie.
Regards,
Nick Maclaren.
Tony Finch wrote in message ...
>····@cus.cam.ac.uk (Nick Maclaren) wrote:
>>
>>Unix and Windows/NT were designed to be portable; VMS wasn't.
>
>I don't think Unix was originally; it just turned out to be simple enough
>that porting turned out to be easier than people expected.
>
Tony's right.
http://www.cs.bell-labs.com/who/dmr/portpap.html
However, portability of C programs was thought
of from the start. Nick (in some unrelated message)
is also right that it can be hard to write a C library
for an OS that differs sufficiently from Unix.
Dennis
Andrew Reilly <······@gurney.reilly.home> writes:
> Someone (perhaps Nick?) once wizely said that portability arises from
> being ported. VMS has been ported once (to Alpha), and is being ported
> again, to Itanium, so it's probably getting to be pretty portable. Maybe
> one day it can become a standard OS product?
Worth noting about the VMS ports is that since quite a bit of the OS
is written in VAX assembler and BLISS, it is emulating VAX instructions!
According to a VMS engineer I asked, it did so for Alpha and it will
do so for Itanium. He was somehow involved in the porting so I guess
he would have to know. It's supposedly done to keep working code
working and for not introducing new bugs. Interesting design.
/andreas
Andreas Davour <····@update.uu.se> wrote:
+---------------
| Andrew Reilly <······@gurney.reilly.home> writes:
| > Someone (perhaps Nick?) once wizely said that portability arises from
| > being ported. VMS has been ported once (to Alpha), and is being ported
| > again, to Itanium, so it's probably getting to be pretty portable. Maybe
| > one day it can become a standard OS product?
|
| Worth noting about the VMS ports is that since quite a bit of the OS
| is written in VAX assembler and BLISS, it is emulating VAX instructions!
+---------------
The assembler code, perhaps, but not the BLISS. Except for data widths
(and even those can be parameterized in header files), BLISS code is
quite machine-independent. In fact, ISTR that the entire front-end of
the Common BLISS compiler (written in Common BLISS, of course) ran
*unchanged* on at least three different architectures.
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Andreas Davour <····@update.uu.se> wrote:
> +---------------
> | Andrew Reilly <······@gurney.reilly.home> writes:
> | > Someone (perhaps Nick?) once wizely said that portability arises from
> | > being ported. VMS has been ported once (to Alpha), and is being ported
> | > again, to Itanium, so it's probably getting to be pretty portable. Maybe
> | > one day it can become a standard OS product?
> |
> | Worth noting about the VMS ports is that since quite a bit of the OS
> | is written in VAX assembler and BLISS, it is emulating VAX instructions!
> +---------------
>
> The assembler code, perhaps, but not the BLISS. Except for data widths
> (and even those can be parameterized in header files), BLISS code is
> quite machine-independent. In fact, ISTR that the entire front-end of
> the Common BLISS compiler (written in Common BLISS, of course) ran
> *unchanged* on at least three different architectures.
My bad. I should have written that in two sentences. What I meant to say
was that it's written in BLISS and assembler, and that at least
the assembler part is still VAX and maybe even the BLISS parts is.
/andreas
Jeffrey Mark Siskind wrote:
> There appears to be a common misconception in this thread that at the
> time Unix was created it was the only `real' operating system in the
> sense that it provided a protected kernel.
Ye Gods ! Are there people out there who actually believe that ?!?!?
Read Fred Brooks's "Mythical Man Month", some history stuff about
Multics and the conclusion is inevitable: Unix is Multics' second system
effect.
--
Toon Moene - ···········@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)
In article <················@moene.indiv.nluug.nl>, Toon Moene
<····@moene.indiv.nluug.nl> wrote:
> Jeffrey Mark Siskind wrote:
> > There appears to be a common misconception in this thread that at the
> > time Unix was created it was the only `real' operating system in the
> > sense that it provided a protected kernel.
>
> Ye Gods ! Are there people out there who actually believe that ?!?!?
[Evil cross-posting removed. Now c.l.l. only.]
Not only are there people who believe this, but they are actually the
majority. Most people believe that the state of the practice is the state
of the art.
It's a very bad situation. I really wonder if this phenomenon happens in
other industries, or if CS is unique for some reason.
E.
Toon Moene <····@moene.indiv.nluug.nl> writes:
> Jeffrey Mark Siskind wrote:
> > There appears to be a common misconception in this thread that at the
> > time Unix was created it was the only `real' operating system in the
> > sense that it provided a protected kernel.
>
> Ye Gods ! Are there people out there who actually believe that ?!?!?
Not only that, there are people that believe that Unix `invented' the
operating system.
In article <················@moene.indiv.nluug.nl>,
Toon Moene <····@moene.indiv.nluug.nl> wrote:
>Jeffrey Mark Siskind wrote:
>> There appears to be a common misconception in this thread that at the
>> time Unix was created it was the only `real' operating system in the
>> sense that it provided a protected kernel.
>
>Ye Gods ! Are there people out there who actually believe that ?!?!?
Probably :-(
>Read Fred Brooks's "Mythical Man Month", some history stuff about
>Multics and the conclusion is inevitable: Unix is Multics' second system
>effect.
Yes, quite.
Well before Unix was produced, virtually every mainframe had a protected
'kernel' - even IBM MVT was theoretically protected, though it was
grossly insecure in practice. There were even some systems (like the
Titan) that had a degree of security almost unknown today.
Regards,
Nick Maclaren.
Toon Moene <····@moene.indiv.nluug.nl> writes:
>> There appears to be a common misconception in this thread that at the
>> time Unix was created it was the only `real' operating system in the
>> sense that it provided a protected kernel.
>
> Ye Gods ! Are there people out there who actually believe that ?!?!?
>
> Read Fred Brooks's "Mythical Man Month", some history stuff about
> Multics and the conclusion is inevitable: Unix is Multics' second
> system effect.
cp/67 had a protected micro-kernel ... in the same time-frame as
multics and had significantly wider deployment (some number of people
that had worked on ctss went to 4th floor, 545 tech sq and worked on
cp/67, others went to 5th floor, 545 tech sq and worked on multics).
cp/67 also had early deployment in some number of time-sharing service
bureau operations ... where the rule-of-thumb would have been a large
collection of essentially authorized and unauthorized users from all
over the world, sharing the same system(s) ... and all requiring
protection from each other.
the 545 tech sq cp/67 system was also used by corporate hdqtrs people
for analyzing the absolutely most/highest senstive corporate data,
while there was also concurrent availability to non-employees, like BU
and MIT students (some with the apparent intent of cracking the system
based on various indications).
there is some indication that cp/67 saw possibly wide-spread
deployment in sensitive, secure operations ... based on some active
participants at SHARE (customer organization).
the follow-on to cp/67 was vm/370 ... not exactly a 2nd system effect,
just a port from 360/67 architecture to 370 architcture.
misc. 545 tech. sq
http://www.garlic.com/~lynn/subtopic.html#545tech
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Anne & Lynn Wheeler <····@garlic.com> writes:
> Toon Moene <····@moene.indiv.nluug.nl> writes:
> >> There appears to be a common misconception in this thread that at the
> >> time Unix was created it was the only `real' operating system in the
> >> sense that it provided a protected kernel.
> >
> > Ye Gods ! Are there people out there who actually believe that ?!?!?
> >
> > Read Fred Brooks's "Mythical Man Month", some history stuff about
> > Multics and the conclusion is inevitable: Unix is Multics' second
> > system effect.
>
> cp/67 had a protected micro-kernel ... in the same time-frame as
> multics and had significantly wider deployment (some number of people
> that had worked on ctss went to 4th floor, 545 tech sq and worked on
> cp/67, others went to 5th floor, 545 tech sq and worked on multics).
Just to state the obvious, CTSS had a protected kernal, in a separate
core bank. Earlier than either was the PDP-1 heavily modified by Jack
Dennis with a largely hardware implemented time sharing system,
including protection. Also worthy of early note was the SDS-940
system.
From: Christopher C. Stacy
Subject: Re: Lisp Machines
Date:
Message-ID: <ully9n4gd.fsf@dtpq.com>
>>>>> On 16 Apr 2003 17:02:25 -0400, Tom Knight ("Tom") writes:
Tom> Anne & Lynn Wheeler <····@garlic.com> writes:
>> Toon Moene <····@moene.indiv.nluug.nl> writes:
>> >> There appears to be a common misconception in this thread that at the
>> >> time Unix was created it was the only `real' operating system in the
>> >> sense that it provided a protected kernel.
>> >
>> > Ye Gods ! Are there people out there who actually believe that ?!?!?
>> >
>> > Read Fred Brooks's "Mythical Man Month", some history stuff about
>> > Multics and the conclusion is inevitable: Unix is Multics' second
>> > system effect.
>>
>> cp/67 had a protected micro-kernel ... in the same time-frame as
>> multics and had significantly wider deployment (some number of people
>> that had worked on ctss went to 4th floor, 545 tech sq and worked on
>> cp/67, others went to 5th floor, 545 tech sq and worked on multics).
Tom> Just to state the obvious, CTSS had a protected kernal, in a separate
Tom> core bank. Earlier than either was the PDP-1 heavily modified by Jack
Tom> Dennis with a largely hardware implemented time sharing system,
Tom> including protection. Also worthy of early note was the SDS-940
Tom> system.
Another early example is the Rice Machine, which was the basis of
the capability model on Burroughs.
······@dtpq.com (Christopher C. Stacy) writes:
> Another early example is the Rice Machine, which was the basis of
> the capability model on Burroughs.
And presumably these were built by Djikstra, and the maintenance was
perfomed by Tarzan?
Somebody slap me, please.
david rush
--
Finding a needle in a haystack is a lot easier if you burn down the
haystack and scan the ashes with a metal detector.
-- the Silicon Valley Tarot
David Rush wrote:
> ······@dtpq.com (Christopher C. Stacy) writes:
>> Another early example is the Rice Machine, which was the basis of
>> the capability model on Burroughs.
>
> And presumably these were built by Djikstra, and the maintenance was
> perfomed by Tarzan?
Then the blue prints *must* be here some where ...
http://www.cs.utexas.edu/users/EWD/
--
Jens Axel S�gaard
On Thu, 17 Apr 2003 04:16:51 GMT in alt.folklore.computers,
······@dtpq.com (Christopher C. Stacy) wrote:
>Another early example is the Rice Machine, which was the basis of
>the capability model on Burroughs.
Is that where the Edgar editor originated?
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
············@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
Brian Inglis <············@SystematicSw.ab.ca> writes:
> On Thu, 17 Apr 2003 04:16:51 GMT in alt.folklore.computers,
> ······@dtpq.com (Christopher C. Stacy) wrote:
>
> >Another early example is the Rice Machine, which was the basis of
> >the capability model on Burroughs.
>
> Is that where the Edgar editor originated?
>
I thought he meant the Rice University Computer, also called the R1.
There's a nice on-line history of it here:
http://www.princeton.edu/~adam/R1/r1rpt.html
I went to Rice with the son of someone who worked on it.
obhistorytrivia: In the much earlier days of the web (I'm thinking 1994?)
this link was the only hit for a search (using Yahoo when it was
still inside of Stanford) for the text string "Ampex Core Memory".
-deborah
deborah (at) best (dot) com
Deborah Gronke Bennett <·······@best.com.invalid> writes:
> obhistorytrivia: In the much earlier days of the web (I'm thinking 1994?)
> this link was the only hit for a search (using Yahoo when it was
> still inside of Stanford) for the text string "Ampex Core Memory".
1/21/94 "yahoo" reference
ncar.ucar.edu [128.117.8.111]
An archive of selected NCAR data and an inventory of what data is
available from their Data Support Section. Some datasets and
papers are available. Also includes Colorado weather and ski
(yahoo!) reports.
......
12/30/94 reference
http://akebono.stanford.edu/yahoo/Computers/Internet/Newsletters/
Computers:Internet:Newsletters
[Menu Bar]
Computers: Internet: Newsletters
* Digital Future - focuses on the information media and related
technology. Abridged version for free.
* Edupage(2) - Edupage, a summary of news items on information
technology, is provided three times each week as a service by
Educom
* GNN NetNews
* In, Around and Online - A Weekly Summary of Events in the Consumer
Online Industry
* LI NewsWire - Here you will find the news and views shaping the
world of Online Information.
* Matrix ····@ (2) - Matrix News is a newsletter about cross-network
issues. Networks frequently mentioned include USENET, UUCP,
FidoNet, BITNET, the Internet, and conferencing systems such as
the WELL and CompuServe. Matrix News is not about any single one
of them. It is about the Matrix, which is all computer networks
worldwide that exchange electronic mail.
* Netsurfer ······@ (2)
* Scout Report - The Scout Report is a weekly publication offered by
InterNIC Information Services to the Internet community as a fast,
convenient way to stay informed on network activities.
* SIMBA Media Daily
* The Web Word
* Index - Information Showcase of the Los Angeles Internet Group
_________________________________________________________________
[ Yahoo | Up | Search | Mail | Add | Help ]
_________________________________________________________________
·····@akebono.stanford.edu
Copyright ) 1994 David Filo and Jerry Yang
......
MOUNTAIN VIEW, CALIFORNIA, U.S.A, 1995 JUL 28 (NB) -- Yahoo plans to
enhance its Internet navigation and directory site with a more
sophisticated look and business plan. In little more than one year,
Yahoo has changed from a university project to one of the most popular
World Wide Web (Web) sites.
Two Stanford graduate students, David Filo and Jerry Yang, decided the
Internet desperately needed an efficient directory, search and
navigation tool. Their university project, now know as Yahoo, became a
Web site and is visited by more the 300,000 users a day. Filo and
Yang, along with a senior management team, are taking Yahoo to a more
fully developed, more complete navigational guide.
With incorporation and other business matters settled, the company is
demonstrating the first step of its evolution into an online business.
On July 31, its Web site will debut a new graphic interface, faster
navigational features, news updates from Reuters New Media, and
advertisements from five sponsors. The charter sponsors are Internet
Shopping Network, Mastercard, MCI, NECX and Worlds, Inc. All have
agreed to a three-month trial advertising program.
For Web surfers who are unable to wait for the July 31 debut, Yahoo
has a beta version of the site at: http://beta.yahoo.com . The new
company says many more changes and new developments are planned for
the site, but promises to remain true to the Internet community as a
grass-roots guide to the Internet.
Yahoo's director of marketing, Tim Brady, said "We put ourselves into
the shoes of a user and asked whether we would want subscriptions or
advertising. Without a doubt the answer was advertising. While
advertising on the Internet is still unmeasured in its effectiveness,
we think it is the avenue which will allow Web sites to turn into
effective businesses. We will work closely with our sponsors to make
ads as interesting as possible. We are committed to keeping the site
free for users."
Looking towards future developments, Brady said Yahoo will consider
its own newsgroups or posting areas along with a chat feature. He also
said the Yahoo search and directory capabilities would become even
more efficient as smart agent technology and broader bandwidth access
are integrated into Yahoo's technology.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Toon Moene <····@moene.indiv.nluug.nl> writes:
>> There appears to be a common misconception in this thread that at the
>> time Unix was created it was the only `real' operating system in the
>> sense that it provided a protected kernel.
...
> Read Fred Brooks's "Mythical Man Month", some history stuff about
> Multics and the conclusion is inevitable: Unix is Multics' second
> system effect.
Umm, how could Unix suffer from the "second system effect" given that
it (started off to be, but that's what matters here) a much simplified
and cut-down version of Multics?
Craig
In article <·······················@newsreader.visi.com>,
Craig A. Finseth <···@visi.com> wrote:
>Toon Moene <····@moene.indiv.nluug.nl> writes:
>>> There appears to be a common misconception in this thread that at the
>>> time Unix was created it was the only `real' operating system in the
>>> sense that it provided a protected kernel.
> ...
>> Read Fred Brooks's "Mythical Man Month", some history stuff about
>> Multics and the conclusion is inevitable: Unix is Multics' second
>> system effect.
>
>Umm, how could Unix suffer from the "second system effect" given that
>it (started off to be, but that's what matters here) a much simplified
>and cut-down version of Multics?
"Suffer from"? The usual interpretation of the effect is that the
second system avoids the mistakes of the first.
Regards,
Nick Maclaren.
> "Suffer from"? The usual interpretation of the effect is that the
> second system avoids the mistakes of the first.
>
"Plan to throw the first one away"
Unfortunately, what happens is you make compromises to SHIP the first
product, then the second product is the one with everything but the
kitchen sink. Sometimes, the second one never ships at all, and you
end up with product number one with a few new features as product
number two.
On the other hand, the old rule of thumb is you never want
even-numbered software releases, since the even-numbered one
breaks everything, and the odd-numbered one gets it working again.
···@spies.com (Al Kossow) writes:
> "Plan to throw the first one away"
>
> Unfortunately, what happens is you make compromises to SHIP the first
> product, then the second product is the one with everything but the
> kitchen sink. Sometimes, the second one never ships at all, and you
> end up with product number one with a few new features as product
> number two.
>
> On the other hand, the old rule of thumb is you never want
> even-numbered software releases, since the even-numbered one
> breaks everything, and the odd-numbered one gets it working again.
cp/67 ... did have an intermediate ... which was cp/40 (between it and
the ctss 7094).
360/67 was official product with virtual memory hardware support.
before 360/67 was available, the csc group built special modified
virtual memory hardware for a 360/40 and built cp/40 for that machine
during 1966 (the 360/40 dat/virtual memory hardware had almost no
resemblance to the 360/67 implementation). then during 1967, it was
rewritten for 360/67 and installed on 360/67 that csc got at 545 tech
sq ... and on lincoln lab's 67s. the last week in jan. 1968, three
people came out from cambridge to install at the university i was at.
the official corporate product for 360/67, virtual memory support,
time-sharing, etc was tss/360. this was a system that started out with
extremely huge bloat (including the kitchen sink); recent tss/360
bloat reference:
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi
above having footnote regarding unix ported on top of tss/370 (subset)
and deployed inside at&t.
and possibly the biggest bloat of all time .... which never saw the
light of day and few people are even aware of was "future system" or
"FS"
http://www.garlic.com/~lynn/subtopic.html#futuresys
the university found os/360 release 14 to be quite stable .... but
there was never a (real?) os/360 release 15 ... the next release was
called os/360 release 15/16 (aka combined release 15 and 16).
there is a bunch of stuff about ctss, multics, tss/360, cp/40, and
cp/67 (some amount was 360/67 loosing multics bid to GE):
http://pucc.princeton.edu/~melinda/
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
···@spies.com (Al Kossow) wrote:
>
>On the other hand, the old rule of thumb is you never want
>even-numbered software releases, since the even-numbered one
>breaks everything, and the odd-numbered one gets it working again.
Interestingly Linux has formalized this the other way around, and
FreeBSD seems to have fallen into an even-odd good-flaky release
cycle.
Tony.
--
f.a.n.finch <···@dotat.at> http://dotat.at/
SOUTHEAST FITZROY: VARIABLE 3 OR 4 BECOMING MAINLY NORTH 4 OR 5. OCCASIONAL
RAIN. MODERATE OCCASIONALLY GOOD.
In article <············@pegasus.csx.cam.ac.uk>,
Nick Maclaren <····@cus.cam.ac.uk> wrote:
>In article <·······················@newsreader.visi.com>,
>Craig A. Finseth <···@visi.com> wrote:
>>Umm, how could Unix suffer from the "second system effect" given that
>>it (started off to be, but that's what matters here) a much simplified
>>and cut-down version of Multics?
>
>"Suffer from"? The usual interpretation of the effect is that the
>second system avoids the mistakes of the first.
Culled from the Jargon file:
second-system effect n.
(sometimes, more euphoniously, `second-system syndrome') When one is
designing the successor to a relatively small, elegant, and
successful system, there is a tendency to become grandiose in one's
success and design an elephantine feature-laden monstrosity. The
term was first used by Fred Brooks in his classic "The Mythical
Man-Month: Essays on Software Engineering" (Addison-Wesley, 1975;
ISBN 0-201-00650-2). It described the jump from a set of nice,
simple operating systems on the IBM 70xx series to OS/360 on the 360
series. A similar effect can also happen in an evolving system; see
Brooks's Law, creeping elegance, creeping featurism. See also
Multics, OS/2, X, software bloat.
Multics n.
[from "MULTiplexed Information and Computing Service"] An early
time-sharing {operating system} co-designed by a consortium
including MIT, GE, and Bell Laboratories as a successor to
{CTSS}. The design was first presented in 1965, planned for
operation in 1967, first operational in 1969, and took several more
years to achieve respectable performance and stability.
...
Bell Labs left the development effort in 1969 after judging that
second-system effect had bloated Multics to the point of practical
unusability. Honeywell commercialized Multics in 1972 after buying
out GE's computer group, but it was never very successful: at its
peak in the 1980s, there were between 75 and 100 Multics sites, each
a multi-million dollar mainframe.
...
cheers,
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
····@armstrong.invalid wrote:
> In article <············@pegasus.csx.cam.ac.uk>,
> Nick Maclaren <····@cus.cam.ac.uk> wrote:
>
>>In article <·······················@newsreader.visi.com>,
>>Craig A. Finseth <···@visi.com> wrote:
>>
>>>Umm, how could Unix suffer from the "second system effect" given that
>>>it (started off to be, but that's what matters here) a much simplified
>>>and cut-down version of Multics?
>>
>>"Suffer from"? The usual interpretation of the effect is that the
>>second system avoids the mistakes of the first.
> Culled from the Jargon file:
Yes, even the original text of the chapter "Second System Effect" talks
about "frill after frill, embellishment after embellishment". So people
usually associate "Second System Effect" with "growth".
However, the crucial sentence of this chapter is: "The general tendency
is to over-design the second system".
This can mean both "restrict it overly" as well as "expand it without
limits".
Unix clearly is of the first kind.
--
Toon Moene - ···········@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)
I recived the following message form, Tom Knight, at MIT:
>
Several people have asked about the naughty bits of the original MIT
lisp machine architecture. I've put my master's thesis (1979) on line
for those of you with a generous non-critical spirit to take a look
at. I will duck all arrows, but praise will be gratefully received.
There are genuine logic diagrams for those of you who recall Schottky
TTL logic or who want to know how hard it was to do anything back in
the bad old days.
General features include a 32 bit word, 180ns cycle, 3-stage pipe,
bypass logic, barrel shifter, single cycle arbitrary field
extract/deposit, and a "dispatch" instruction which did an extracted
field multi-way table lookup branch in a single cycle. Microcode PC
push down stack, top-of-stack cache, and an ability to variablize
microcode instructions on-the-fly are also interesting features.
Branch delay slots appeared here also.
Best, tk
http://www.ai.mit.edu/people/tk/tk-sm-79.pdf
>
and then I recived this letter:
>
I meant to post that last message instead of mail it.
>
(remove #\space "tk @ ai . mit . edu") ;; In his letter he wanted
reply's.
;; I hope including this code is OK.
I am pushing for a Lisp Archetecture becuase I think ANSI CL/Scheme
would make an excellent machine/micro code. (Don't flame; I don't know
how machine/micro code differ.) I think this for the following
reasons:
1.) Programs + Data are in same format.
2.) Programs are portable to different platforms.
3.) ANSI CL/IEEE Scheme allows more abstractions that machine
language.
4.) Macros make it easy to write code generators/transaltors.
5.) Debuging is interactive.
6.) Standards exist.
7.) It is easier to learn two HLL's even if they are difficult to
learn--
easier than learning thousands of machine languages for each CPU.
8.) Memory Support is built in.
9.) Lisp has been used as a Machine Language. Read the paper that is
being
linked.
10.) Lots of packages are avail. for Lisp. Not many that can run on
all
Machine Languages.
C is the Universal Assebly Language; Make Lisp the Universal Machine
Language.
Lisp is more readable that machine language.
0000011101010101010101001 or (+ 1 1) ;; 1 + 1, you decide.
In article <····························@posting.google.com>,
·································@hotmail.com (Franz Kafka) wrote:
> I recived the following message form, Tom Knight, at MIT:
>
> >
> Several people have asked about the naughty bits of the original MIT
> lisp machine architecture. I've put my master's thesis (1979) on line
> for those of you with a generous non-critical spirit to take a look
> at. I will duck all arrows, but praise will be gratefully received.
> There are genuine logic diagrams for those of you who recall Schottky
> TTL logic or who want to know how hard it was to do anything back in
> the bad old days.
>
> General features include a 32 bit word, 180ns cycle, 3-stage pipe,
> bypass logic, barrel shifter, single cycle arbitrary field
> extract/deposit, and a "dispatch" instruction which did an extracted
> field multi-way table lookup branch in a single cycle. Microcode PC
> push down stack, top-of-stack cache, and an ability to variablize
> microcode instructions on-the-fly are also interesting features.
> Branch delay slots appeared here also.
>
> Best, tk
>
> http://www.ai.mit.edu/people/tk/tk-sm-79.pdf
PDF'ed scans of related material can be found at
http://www.spies.com/web/pdf/mit
I've been promised a copy of the CADR schematics, hopefully
they'll be here soon so I can put those on line and have
them to debug the CADR that I have
Finding surviving software is a much larger problem, unfortunately.
···@spies.com (Al Kossow) writes:
> PDF'ed scans of related material can be found at
> http://www.spies.com/web/pdf/mit
I couldn't get that URL to work, but
<URL:http://www.spies.com/~aek/pdf/mit/> did work.
--
Frode Vatvedt Fjeld
·································@hotmail.com (Franz Kafka) writes:
> I recived the following message form, Tom Knight, at MIT:
> Several people have asked about the naughty bits of the original MIT
> lisp machine architecture. I've put my master's thesis (1979) on line
> for those of you with a generous non-critical spirit to take a look
> at. I will duck all arrows, but praise will be gratefully received.
> There are genuine logic diagrams for those of you who recall Schottky
> TTL logic or who want to know how hard it was to do anything back in
> the bad old days.
So I can throw out the crappy microfiche I had made at the MIT library
in 1986 while attending the ACM Lisp Conference? TK told me at the time
that that was the only way to get a copy! I've nearly gone blind from
trying to read it sometimes.
Please, thank him for me.
--
Rich Alderson ····@alderson.users.panix.com
"You get what anybody gets. You get a lifetime." --Death, of the Endless
I don't know about the legal aspect.
As soon as I hear about the status of the Lisp software developed at
MIT I will post an other message.
It looks 'good' but we'll have to wait an see.
In article <················@moene.indiv.nluug.nl>,
Toon Moene <····@moene.indiv.nluug.nl> wrote:
>
>Yes, even the original text of the chapter "Second System Effect" talks
>about "frill after frill, embellishment after embellishment". So people
>usually associate "Second System Effect" with "growth".
Maybe I have been around too long. I remember the previous
definition.
>However, the crucial sentence of this chapter is: "The general tendency
>is to over-design the second system".
>
>This can mean both "restrict it overly" as well as "expand it without
>limits".
>
>Unix clearly is of the first kind.
Well, maybe. My own view is that Unix bears the same relationship
to Multics as BCPL does to CPL, and for most of the same reasons.
Regards,
Nick Maclaren.
In alt.folklore.computers Nick Maclaren <····@cus.cam.ac.uk> wrote:
>
> Well, maybe. My own view is that Unix bears the same relationship
> to Multics as BCPL does to CPL, and for most of the same reasons.
>
>
An elegant and perceptive summary ;)
pete
--
····@fenelon.com "there's no room for enigmas in built-up areas" HMHB
"Pete Fenelon" <····@fenelon.com> wrote in message
···················@corp.supernews.com...
> In alt.folklore.computers Nick Maclaren <····@cus.cam.ac.uk> wrote:
> >
> > Well, maybe. My own view is that Unix bears the same relationship
> > to Multics as BCPL does to CPL, and for most of the same reasons.
>
> An elegant and perceptive summary ;)
Ah, so while Multics and BCPL are user-friendly,
readable, intuitive (in their command sets, APIs,
lexical syntax, whatever), UNIX and C are instead
user-un-friendly, unreadable, counter-intuitive...
Yes, I'd have to agree with this as well...
In article <··········@news.iglou.com>,
"Douglas H. Quebbeman" <·····@iglou.com> writes:
|> "Pete Fenelon" <····@fenelon.com> wrote in message
|> ···················@corp.supernews.com...
|> > In alt.folklore.computers Nick Maclaren <····@cus.cam.ac.uk> wrote:
|> > >
|> > > Well, maybe. My own view is that Unix bears the same relationship
|> > > to Multics as BCPL does to CPL, and for most of the same reasons.
|> >
|> > An elegant and perceptive summary ;)
|>
|> Ah, so while Multics and BCPL are user-friendly,
|> readable, intuitive (in their command sets, APIs,
|> lexical syntax, whatever), UNIX and C are instead
|> user-un-friendly, unreadable, counter-intuitive...
|>
|> Yes, I'd have to agree with this as well...
Eh? No, it is Multics -> Unix bears a similar relationship
to CPL -> BCPL. Let's leave C out of this one.
Regards,
Nick Maclaren.
Toon Moene <····@moene.indiv.nluug.nl> writes:
> Yes, even the original text of the chapter "Second System Effect"
> talks about "frill after frill, embellishment after embellishment".
> So people usually associate "Second System Effect" with "growth".
>
> However, the crucial sentence of this chapter is: "The general
> tendency is to over-design the second system".
>
> This can mean both "restrict it overly" as well as "expand it without
> limits".
>
> Unix clearly is of the first kind.
"Novell to Make Linux Robust and Reliable"
http://www.computerweekly.com/articles/article.asp?liArticleID=121012
http://slashdot.org/articles/03/04/16/229244.shtml?tid=190&tid=106
wasn't it around 89 or 90 where the tandem lab in austin did something
about making sysV.4 more robust and reliable by contributing source
changes that eliminated/fixed something like 1000-1200 kernel panics
(and not just a case of deleting the statement).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Toon Moene wrote:
> ····@armstrong.invalid wrote:
>> In article <············@pegasus.csx.cam.ac.uk>,
>> Nick Maclaren <····@cus.cam.ac.uk> wrote:
>>
>>>In article <·······················@newsreader.visi.com>,
>>>Craig A. Finseth <···@visi.com> wrote:
>>>
>>>>Umm, how could Unix suffer from the "second system effect" given that
>>>>it (started off to be, but that's what matters here) a much simplified
>>>>and cut-down version of Multics?
>>>
>>>"Suffer from"? The usual interpretation of the effect is that the
>>>second system avoids the mistakes of the first.
>
>> Culled from the Jargon file:
>
> Yes, even the original text of the chapter "Second System Effect" talks
> about "frill after frill, embellishment after embellishment". So people
> usually associate "Second System Effect" with "growth".
>
> However, the crucial sentence of this chapter is: "The general tendency
> is to over-design the second system".
>
> This can mean both "restrict it overly" as well as "expand it without
> limits".
I always interpreted it as meaning:
First system, plan to throw away at least fifty percent of your stuff,
because you're just getting your feet wet for the first time, and nothing
is sacred except comleting the taks.
Second system, plan everything meticulously because you've learnt how to
plan and are not only willing to do so, but also obsessed with it.
Ergo, where with the first system, you were willing to take risks and chuck
out whatever wasn't working, with the second syste, you are always trying
to shoehorn the glitched stuff back into line, _because_ _you_ _planned_
_it_ _all_ _so_ _beautifully_, and it would break your heart to throw it
out.
The only thing with Brooke's argument I have any sort of dispute with, is
the necessary linking of the second system effect to the second system
I've gone baroque, if not roccoco, with the design of an electronic guitar
pickup, and that was my first effort at digital design. I never completed
it ... :(
Wesley Parish
>
> Unix clearly is of the first kind.
>
--
First the wife, tone of awe. So much a condition. Kent in the labs,
forward. "So how was the worthlessful businessman?" But they hadn't
stopped meat for year ago, that arose hotel facade slowly moved apper.
- Don't let emacs meta-x dissociatedpress write your speeches!
Nick Maclaren wrote:
> In article <·······················@newsreader.visi.com>,
> Craig A. Finseth <···@visi.com> wrote:
>>Umm, how could Unix suffer from the "second system effect" given that
>>it (started off to be, but that's what matters here) a much simplified
>>and cut-down version of Multics?
> "Suffer from"? The usual interpretation of the effect is that the
> second system avoids the mistakes of the first.
Indeed - otherwise, this joke
http://gcc.gnu.org/ml/gcc/2003-03/msg01065.html
would be completely incomprehensible.
--
Toon Moene - ···········@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)
On 4/16/03 2:41 PM, in article ················@moene.indiv.nluug.nl, "Toon
Moene" <····@moene.indiv.nluug.nl> wrote:
> Nick Maclaren wrote:
>
>> In article <·······················@newsreader.visi.com>,
>> Craig A. Finseth <···@visi.com> wrote:
>>> Umm, how could Unix suffer from the "second system effect" given that
>>> it (started off to be, but that's what matters here) a much simplified
>>> and cut-down version of Multics?
>
>> "Suffer from"? The usual interpretation of the effect is that the
>> second system avoids the mistakes of the first.
>
> Indeed - otherwise, this joke
>
> http://gcc.gnu.org/ml/gcc/2003-03/msg01065.html
>
> would be completely incomprehensible.
Perhaps, but Multics was actually much smaller than Unix is today...
Plus it had better abstractions (everything is ram instead of everything is
a byte stream), better protection, etc.
In article <··························@NOSPAMmac.com>,
Gorbag <············@NOSPAMmac.com> wrote:
>
>Perhaps, but Multics was actually much smaller than Unix is today...
>
>Plus it had better abstractions (everything is ram instead of everything is
>a byte stream), better protection, etc.
The problem with Unix is not with its design for what it was intended
for, but what it has been mangled into. When I started to use Unix,
its proponents made very rude remarks about the size and complexity
of MVT and its documentation. Well, modern Unices are MUCH larger.
Of the problems that send me up the wall with Unix, 90% fall into the
category of ones where the basic design is unsuitable for the purpose
for which it is being used. Usually because a supercomputer of 2003
is a wildly different system to a minicomputer of 1973. Unfortunately,
all of the 'improvements' going on take the form of bolting on yet
another ill-suited feature that interacts badly with the others.
I/O is my current headache. If you think of the problems of providing
high-speed parallel I/O across dozens of disks and multiple computers,
each with many CPUs, and try to maintain the full POSIX semantics, you
will see what I mean. Think of multiple processes on different computers
opening the same file for append or updating and displaying the same
directory, and passing the same descriptor between processes owned by
different users (setuid), some of which use fcntl in uncooperative ways.
Or the terribly simple requirement to get asynchronicity and zero
copying on a large SMP system without creating cache havoc - when you
have to support byte interleaving for multiple threads and the I/O and
can't assume registration! Now add in all of the indirection caused by
I/O daemons, network I/O and all that. Having got there, now start
considering what you mean by an I/O error and how and who to tell what
when you get one. If you still think that you understand what is going
on, you don't.
The basic Unix I/O model was simple and fairly clean, more so than the
one used by MVT and MVS. The current chaos is complex, incredibly
unclean, and hacked to hell and back again under the covers. So, of
course, it doesn't work either reliably or efficiently.
Regards,
Nick Maclaren.
On 18 Apr 2003 08:07:23 GMT in alt.folklore.computers,
····@cus.cam.ac.uk (Nick Maclaren) wrote:
>In article <··························@NOSPAMmac.com>,
>Gorbag <············@NOSPAMmac.com> wrote:
>>
>>Perhaps, but Multics was actually much smaller than Unix is today...
>>
>>Plus it had better abstractions (everything is ram instead of everything is
>>a byte stream), better protection, etc.
>
>The problem with Unix is not with its design for what it was intended
>for, but what it has been mangled into. When I started to use Unix,
>its proponents made very rude remarks about the size and complexity
>of MVT and its documentation. Well, modern Unices are MUCH larger.
>
>Of the problems that send me up the wall with Unix, 90% fall into the
>category of ones where the basic design is unsuitable for the purpose
>for which it is being used. Usually because a supercomputer of 2003
>is a wildly different system to a minicomputer of 1973. Unfortunately,
>all of the 'improvements' going on take the form of bolting on yet
>another ill-suited feature that interacts badly with the others.
>
>I/O is my current headache. If you think of the problems of providing
>high-speed parallel I/O across dozens of disks and multiple computers,
>each with many CPUs, and try to maintain the full POSIX semantics, you
>will see what I mean. Think of multiple processes on different computers
>opening the same file for append or updating and displaying the same
>directory, and passing the same descriptor between processes owned by
>different users (setuid), some of which use fcntl in uncooperative ways.
>Or the terribly simple requirement to get asynchronicity and zero
>copying on a large SMP system without creating cache havoc - when you
>have to support byte interleaving for multiple threads and the I/O and
>can't assume registration! Now add in all of the indirection caused by
>I/O daemons, network I/O and all that. Having got there, now start
>considering what you mean by an I/O error and how and who to tell what
>when you get one. If you still think that you understand what is going
>on, you don't.
>
>The basic Unix I/O model was simple and fairly clean, more so than the
>one used by MVT and MVS. The current chaos is complex, incredibly
>unclean, and hacked to hell and back again under the covers. So, of
>course, it doesn't work either reliably or efficiently.
Maybe you should contract the Wheelers to build you a nice big
mainframe server with some nice big GB network pipes, possibly
running a custom version of VM, like TPF but supporting SMP,
async page mapped I/O with completion posting, and an optimized
network stack to serve up the data as fast as the CPUs can crunch
it.
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
············@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
In article <··································@4ax.com>,
Brian Inglis <············@SystematicSw.ab.ca> wrote:
>>
>>The basic Unix I/O model was simple and fairly clean, more so than the
>>one used by MVT and MVS. The current chaos is complex, incredibly
>>unclean, and hacked to hell and back again under the covers. So, of
>>course, it doesn't work either reliably or efficiently.
>
>Maybe you should contract the Wheelers to build you a nice big
>mainframe server with some nice big GB network pipes, possibly
>running a custom version of VM, like TPF but supporting SMP,
>async page mapped I/O with completion posting, and an optimized
>network stack to serve up the data as fast as the CPUs can crunch
>it.
Sigh. That is precisely what we DON'T need. Yes, it might do the
job, but there are well-understood solutions using existing, cheap
hardware. The problems are SOLELY that the CONCEPTUAL DESIGN of the
INTERFACES is wrong for the purpose.
I don't believe that better concepts would be hard to match with Unix,
either, PROVIDED that we were permitted to cause all programs that
rely on the rejected semantics to fail. And there are many fewer
such programs than most people think.
Regards,
Nick Maclaren.
Brian Inglis <············@SystematicSw.ab.ca> writes:
> Maybe you should contract the Wheelers to build you a nice big
> mainframe server with some nice big GB network pipes, possibly
> running a custom version of VM, like TPF but supporting SMP,
> async page mapped I/O with completion posting, and an optimized
> network stack to serve up the data as fast as the CPUs can crunch
> it.
the ibm system engineer on a financial services institution in
southern california did a virtual machine based transaction driver for
ATM machines ... basically a virtual machine per disk arm ... that he
measured on a 370/158 outperforming TPF running on a 370/168. the big
gain was a global disk arm scheduling algorithm that attempted to
anticipate arm activity based on past history of ATM machine use
patterns (aka all transactions came into a central scheduler ... that
re-ordered and then released them to the individual transaction
servers).
trivia ... i believe the same person also did the first pc version of
SCRIPT (cms document formater done at science center ... originally in
mid-60s by "mad" with runoff-like dot commands ... and then at csc
circa 1970, "G", "M", and "L" ... added GML to. I believe his PC
version first showed up on those PCs you could get from that chain of
local electronic parts stores.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Nick Maclaren wrote:
>
> [snip...] [snip...] [snip...]
>
> The basic Unix I/O model was simple and fairly clean, more so than the
> one used by MVT and MVS. The current chaos is complex, incredibly
> unclean, and hacked to hell and back again under the covers. So, of
> course, it doesn't work either reliably or efficiently.
>
IMHO you are *way* too tense, Mr. Maclaren. Some morning, someone
will come in and find you keeled over dead at the breakfast
table...still pointing at the burnt toast... If you need to get
a handle on your anger, go to see the movie "Anger Management"... ;-)
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
In article <·················@ev1.net>,
Charles Richmond <········@ev1.net> wrote:
>Nick Maclaren wrote:
>>
>> The basic Unix I/O model was simple and fairly clean, more so than the
>> one used by MVT and MVS. The current chaos is complex, incredibly
>> unclean, and hacked to hell and back again under the covers. So, of
>> course, it doesn't work either reliably or efficiently.
>>
>IMHO you are *way* too tense, Mr. Maclaren. Some morning, someone
>will come in and find you keeled over dead at the breakfast
>table...still pointing at the burnt toast... If you need to get
>a handle on your anger, go to see the movie "Anger Management"... ;-)
I never thought of that! Maybe, if I smoked what you are smoking,
all of the I/O systems I use at work would look reliable and efficient.
It might work on users, too: "Here, don't worry about your stupid
programs - light one of these and chill out!"
And, of course, the designers of those things might have been smoking
the same thing, which could explain a lot.
Regards,
Nick Maclaren.
In article <············@pegasus.csx.cam.ac.uk>, Nick Maclaren wrote:
>>IMHO you are *way* too tense, Mr. Maclaren. Some morning, someone
>>will come in and find you keeled over dead at the breakfast
>>table...still pointing at the burnt toast... If you need to get
>>a handle on your anger, go to see the movie "Anger Management"... ;-)
>
> I never thought of that! Maybe, if I smoked what you are smoking,
> all of the I/O systems I use at work would look reliable and efficient.
Which I/O systems is that? From reading the thread, I thought it was NT
you were talking about.
In article <·················@ev1.net>,
Charles Richmond <········@ev1.net> wrote:
>Nick Maclaren wrote:
>>
>> The basic Unix I/O model was simple and fairly clean, more so than the
>> one used by MVT and MVS. The current chaos is complex, incredibly
>> unclean, and hacked to hell and back again under the covers. So, of
>> course, it doesn't work either reliably or efficiently.
>>
>IMHO you are *way* too tense, Mr. Maclaren. Some morning, someone
>will come in and find you keeled over dead at the breakfast
>table...still pointing at the burnt toast... If you need to get
>a handle on your anger, go to see the movie "Anger Management"... ;-)
I never thought of that! Maybe, if I smoked something suitable, all
of the I/O systems I use at work would look reliable and efficient.
It might work on users, too: "Here, don't worry about your stupid
programs - light one of these and chill out!"
And, of course, the designers of those things might have been smoking
the same thing, which could explain a lot.
Regards,
Nick Maclaren.
Nick Maclaren wrote:
>
> In article <·················@ev1.net>,
> Charles Richmond <········@ev1.net> wrote:
> >Nick Maclaren wrote:
> >>
> >> The basic Unix I/O model was simple and fairly clean, more so than the
> >> one used by MVT and MVS. The current chaos is complex, incredibly
> >> unclean, and hacked to hell and back again under the covers. So, of
> >> course, it doesn't work either reliably or efficiently.
> >>
> >IMHO you are *way* too tense, Mr. Maclaren. Some morning, someone
> >will come in and find you keeled over dead at the breakfast
> >table...still pointing at the burnt toast... If you need to get
> >a handle on your anger, go to see the movie "Anger Management"... ;-)
>
> I never thought of that! Maybe, if I smoked something suitable, all
> of the I/O systems I use at work would look reliable and efficient.
> It might work on users, too: "Here, don't worry about your stupid
> programs - light one of these and chill out!"
>
> And, of course, the designers of those things might have been smoking
> the same thing, which could explain a lot.
>
Hey, it's *not* that I disagree about the disreputable state of
things. It just that stewing over Billy Boy is only going to give
us ulcers and lead to an early grave. Now, if you would like to
get on an airplane, fly to Redmond, Washington, and punch out
Mr. Gates, I would call that a productive afternoon... After all,
IMHO we need to find a way to take all the anguish he has caused,
and focus it back on him. IMHO.
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
On Sat, 19 Apr 2003 20:30:26 GMT, Charles Richmond wrote:
> Nick Maclaren wrote:
>>
>> In article <·················@ev1.net>,
>> Charles Richmond <········@ev1.net> wrote:
>> >Nick Maclaren wrote:
>> >>
>> >> The basic Unix I/O model was simple and fairly clean, more so than the
>> >> one used by MVT and MVS. The current chaos is complex, incredibly
>> >> unclean, and hacked to hell and back again under the covers. So, of
>> >> course, it doesn't work either reliably or efficiently.
> Hey, it's *not* that I disagree about the disreputable state of
> things. It just that stewing over Billy Boy is only going to give
> us ulcers and lead to an early grave. Now, if you would like to
> get on an airplane, fly to Redmond, Washington, and punch out
> Mr. Gates, I would call that a productive afternoon... After all,
> IMHO we need to find a way to take all the anguish he has caused,
> and focus it back on him. IMHO.
Bill Gates has caused the chaos of unclean, hacked to hell Unix
I/O? What a brilliant plan!
--
Andrew
Andrew Reilly wrote:
>
> On Sat, 19 Apr 2003 20:30:26 GMT, Charles Richmond wrote:
> > Nick Maclaren wrote:
> >>
> >> In article <·················@ev1.net>,
> >> Charles Richmond <········@ev1.net> wrote:
> >> >Nick Maclaren wrote:
> >> >>
> >> >> The basic Unix I/O model was simple and fairly clean, more so than the
> >> >> one used by MVT and MVS. The current chaos is complex, incredibly
> >> >> unclean, and hacked to hell and back again under the covers. So, of
> >> >> course, it doesn't work either reliably or efficiently.
>
> > Hey, it's *not* that I disagree about the disreputable state of
> > things. It just that stewing over Billy Boy is only going to give
> > us ulcers and lead to an early grave. Now, if you would like to
> > get on an airplane, fly to Redmond, Washington, and punch out
> > Mr. Gates, I would call that a productive afternoon... After all,
> > IMHO we need to find a way to take all the anguish he has caused,
> > and focus it back on him. IMHO.
>
> Bill Gates has caused the chaos of unclean, hacked to hell Unix
> I/O? What a brilliant plan!
>
Well, probably *not*... But Billy Boy has put his imprint on
Unix via SCO and XENIX... So *maybe* we can blame *some* of
that on Billy...but remember that a hugh majority of the boxes
out their run Mi$uck WinBloze. ISTM that Mr. Maclaren has
complained about that "OS" also...somewhere. Maybe...
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
In comp.arch Nick Maclaren <····@cus.cam.ac.uk> wrote:
>
> Of the problems that send me up the wall with Unix, 90% fall into the
> category of ones where the basic design is unsuitable for the purpose
> for which it is being used. Usually because a supercomputer of 2003
> is a wildly different system to a minicomputer of 1973. Unfortunately,
> all of the 'improvements' going on take the form of bolting on yet
> another ill-suited feature that interacts badly with the others.
>
[snip]
>
> The basic Unix I/O model was simple and fairly clean, more so than the
> one used by MVT and MVS. The current chaos is complex, incredibly
> unclean, and hacked to hell and back again under the covers. So, of
> course, it doesn't work either reliably or efficiently.
>
So, you'd say that the problem with unix as it stands is that existing
interfaces were extended beyond the breaking point in varuious incompatible
ways instead of adding new, cleanly designed interfaces that are separated
frominterfarance by the previous ones?
>
> Regards,
> Nick Maclaren.
--
Sander
+++ Out of cheese error +++
In article <················@haldjas.folklore.ee>,
Sander Vesik <······@haldjas.folklore.ee> wrote:
>>
>> The basic Unix I/O model was simple and fairly clean, more so than the
>> one used by MVT and MVS. The current chaos is complex, incredibly
>> unclean, and hacked to hell and back again under the covers. So, of
>> course, it doesn't work either reliably or efficiently.
>
>So, you'd say that the problem with unix as it stands is that existing
>interfaces were extended beyond the breaking point in varuious incompatible
>ways instead of adding new, cleanly designed interfaces that are separated
>frominterfarance by the previous ones?
Very close to that, yes. Except that I would put more stress on the
concepts on which the interfaces are based than on their details.
Regards,
Nick Maclaren.
····@cus.cam.ac.uk (Nick Maclaren) writes:
> In article <·······················@newsreader.visi.com>,
> Craig A. Finseth <···@visi.com> wrote:
> >Toon Moene <····@moene.indiv.nluug.nl> writes:
> >>> There appears to be a common misconception in this thread that at the
> >>> time Unix was created it was the only `real' operating system in the
> >>> sense that it provided a protected kernel.
> > ...
> >> Read Fred Brooks's "Mythical Man Month", some history stuff about
> >> Multics and the conclusion is inevitable: Unix is Multics' second
> >> system effect.
> >
> >Umm, how could Unix suffer from the "second system effect" given that
> >it (started off to be, but that's what matters here) a much simplified
> >and cut-down version of Multics?
>
> "Suffer from"? The usual interpretation of the effect is that the
> second system avoids the mistakes of the first.
No, the second system is the one where everybody piles in all the gorp
that was wisely kept out of the first system. The third system--if you
get that far, then takes the lessons learned from 1 and 2 and makes a
nice tidy system. Per the Jargon File:
<http://www.catb.org/~esr/jargon/html/entry/second-system-effect.html>
According to this it was Multics that was the bloated second system
and Unix is in fact the stripped down third system. FWIW.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
In article <··············@javamonkey.com>,
Peter Seibel <·····@javamonkey.com> wrote:
>>
>> "Suffer from"? The usual interpretation of the effect is that the
>> second system avoids the mistakes of the first.
>
>No, the second system is the one where everybody piles in all the gorp
>that was wisely kept out of the first system. The third system--if you
>get that far, then takes the lessons learned from 1 and 2 and makes a
>nice tidy system. Per the Jargon File:
>
> <http://www.catb.org/~esr/jargon/html/entry/second-system-effect.html>
>
>According to this it was Multics that was the bloated second system
>and Unix is in fact the stripped down third system. FWIW.
Well, the original reference I heard was that you build three systems:
one to throw away, one to get working, and one to add all of the
damn-fool ideas that stop it working again :-)
That reference is pre-Brooks, but I can't remember who originated it.
I think that Roger Needham told it to me, as someone else's aphorism.
Regards,
Nick Maclaren.
On 16 Apr 2003 21:06:15 GMT in alt.folklore.computers,
····@cus.cam.ac.uk (Nick Maclaren) wrote:
>In article <·······················@newsreader.visi.com>,
>Craig A. Finseth <···@visi.com> wrote:
>>Toon Moene <····@moene.indiv.nluug.nl> writes:
>>>> There appears to be a common misconception in this thread that at the
>>>> time Unix was created it was the only `real' operating system in the
>>>> sense that it provided a protected kernel.
>> ...
>>> Read Fred Brooks's "Mythical Man Month", some history stuff about
>>> Multics and the conclusion is inevitable: Unix is Multics' second
>>> system effect.
>>
>>Umm, how could Unix suffer from the "second system effect" given that
>>it (started off to be, but that's what matters here) a much simplified
>>and cut-down version of Multics?
>
>"Suffer from"? The usual interpretation of the effect is that the
>second system avoids the mistakes of the first...
...and makes every other possible mistake instead!
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
············@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
Brian Inglis wrote:
> On 16 Apr 2003 21:06:15 GMT in alt.folklore.computers,
> ····@cus.cam.ac.uk (Nick Maclaren) wrote:
>>"Suffer from"? The usual interpretation of the effect is that the
>>second system avoids the mistakes of the first...
>
> ...and makes every other possible mistake instead!
Well put! That's Brooks in a nutshell.
--
Roland Hutchinson Will play viola da gamba for food.
NB mail to ···········@eudoramail.com is heavily filtered to
remove spam. If your message looks like spam I may not see it.
>> Read Fred Brooks's "Mythical Man Month", some history stuff about
>> Multics and the conclusion is inevitable: Unix is Multics' second
>> system effect.
Hmmm. Beg to differ. Taking that interpretation, Multics was the "Second
System Effect" (bigger, more ideas, "does everything") applied to
CTSS. Early Unix was a lean, mean fighting machine of an OS - and
didn't acquire many of the distinctive features of Multics (written
in a high-level language, particularly) for several years. Many it
never acquired but has grown substitutes for (Unix dynamic linking,
mmap and recent use of pseudo-filesystems to make things appear as
part of the same namespace just don't quite seem as conceptually
elegant as Multics' approach to naming and virtual memory - just
one of the many reasons I'd love to see a genuinely Multics-like
OS on commodity 32 or 64-bit hardware).
Interestingly you can't really apply Brooksian "Second System Effect"
to the research stuff that came out of Bell Labs - their OS stuff
remained elegant right through 10th Edition, Plan9 and Inferno. You
*can* argue that the USG products experienced SSE bloat - System
III as a "second system" after V7 for example.
pete
--
····@fenelon.com "there's no room for enigmas in built-up areas" HMHB
Toon Moene <····@moene.indiv.nluug.nl> wrote in message news:<················@moene.indiv.nluug.nl>...
> Read Fred Brooks's "Mythical Man Month", some history stuff about
> Multics and the conclusion is inevitable: Unix is Multics' second system
> effect.
Well, I would tend to think of Multics as CTSS's second system, and
Unix as the third (and therefore usable) system.
An addendum to my previous post.
I should point out how commonplace such ideas were.In 1974, my high
school had
a PDP-8e. And we had ETOS but it was so buggy that we didn't run it.
So I
decided to write my own OS. I called it VM/8. I was aware of VM/370
and the notion
of a virtual machine. VM/8 had protection, virtual memory, scheduling.
I wrote in
assembler. As a high-school student. Whose primary access to the
literature was the
local public library.At the time, I had no contact with the mainstream
computer
science community. I independently discovered the need to emulate the
CPU between
the CIF instruction and the following JMP/JMS instruction.It wasn't
until some
30 year later, about a year or so ago, I heard of others on some
newsgroup refering to that same need. And I remember that our machine
had a special ETOS
board. At the time (i.e. 30 years ago) I conjectured that the board
had some
special hardware to preclude the need for emulation between CIF and
JMP/JMS. I
even asked the field engineering but he denied that. Again, it wasn't
for 30
years until a year or two ago that someone on the net confirmed that
the ETOS
board did exactly that. In fact, it was my conjecture about the ETOS
board that
motivated me several years later to design external hardware to add
protection and memory
mapping to the 8080 and 6800.
You see, the notions of protection, virtual memory, scheduling, memory
mapping,
and even hardware mods to allow protection and memory mapping were so
commonplace and pervasive by the early to mid 70s that even a
high-school student reading material available in a public library
could fully learn and grasp the ideas.
By 1977 or 1978, I took a course in computer security as an
undergraduate.
And read the paper on protection rings in Multics which is where I
remember being told about the 4K secure code base issue. At the time I
took the course, that was presented as ancient material already, not
as new state-of-the-art stuff.
As a field, we really have a problem with how ignorant the younger
generation
is. And how poorly we educate them.
····@purdue.edu (Jeffrey Mark Siskind) writes:
> As a field, we really have a problem with how ignorant the younger
> generation is. And how poorly we educate them.
Amen.
In article <············@ccs.neu.edu>, Joe Marshall wrote:
> ····@purdue.edu (Jeffrey Mark Siskind) writes:
>
>> As a field, we really have a problem with how ignorant the younger
>> generation is. And how poorly we educate them.
>
> Amen.
You should visit your local univerisity some time.
I somehow managed to cram a 4-years degree into only 8 years, so I saw a
lot more than some other students. I started in 1986, about the time
when the "programmer shortage" was causing pressure on schools to have
a higher graduation rate among programmers.
When I started out, only about 10% of students graduated in data
processing and computer science, without changing to something easier.
For example, I started out in a class of 50-60 people. The first
semester removed 30 of them, and by years's end, only about 12 people
remained in the program.
This changed though, because someone (and we can debate who) said that
this was not acceptable, and that at least 75% of new programming
students should graduate, and do so with high scores.
I believe that unless you really love it, and have a certain mental
skillset, you just cannot be a good programmer. That doesn't mean you
are stupid, it just means this profession isn't for you.
But the schools were pressured to become "programmer factories", and the
damage done is pretty obvious.
Charles Shannon Hendrix <·······@news.widomaker.com> writes:
> I somehow managed to cram a 4-years degree into only 8 years, so I saw a
> lot more than some other students. I started in 1986, about the time
> when the "programmer shortage" was causing pressure on schools to have
> a higher graduation rate among programmers.
there was some amount of angst during that period .... i believe
schools like MIT and UCB had something like 50 percent of the freshman
applicants in computer science; there was lots of hand-wringing about
where whole departments might evaporate ... being crowded out by
computer science. this issue wasn't so much industry putting pressure
on schools to turn out the CS graduates ... but the incoming freshman
all wanting to be in CS program.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
In article <·············@earthlink.net>, Anne & Lynn Wheeler wrote:
> Charles Shannon Hendrix <·······@news.widomaker.com> writes:
>> I somehow managed to cram a 4-years degree into only 8 years, so I saw a
>> lot more than some other students. I started in 1986, about the time
>> when the "programmer shortage" was causing pressure on schools to have
>> a higher graduation rate among programmers.
>
> there was some amount of angst during that period .... i believe
> schools like MIT and UCB had something like 50 percent of the freshman
> applicants in computer science; there was lots of hand-wringing about
> where whole departments might evaporate ...
50% of the freshman applications... in the Boston area or the US? I
would doubt the latter, big as MIT may be.
> being crowded out by computer science. this issue wasn't so much
> industry putting pressure on schools to turn out the CS graduates ...
> but the incoming freshman all wanting to be in CS program.
That was true, but the word I got was that the industry was panicked
about not having enough.
And certainly a lot of people wanting to be in CS did not force the
schools to water it down.
Anne & Lynn Wheeler wrote:
>
> Charles Shannon Hendrix <·······@news.widomaker.com> writes:
> > I somehow managed to cram a 4-years degree into only 8 years, so I saw a
> > lot more than some other students. I started in 1986, about the time
> > when the "programmer shortage" was causing pressure on schools to have
> > a higher graduation rate among programmers.
>
> there was some amount of angst during that period .... i believe
> schools like MIT and UCB had something like 50 percent of the freshman
> applicants in computer science; there was lots of hand-wringing about
> where whole departments might evaporate ... being crowded out by
> computer science. this issue wasn't so much industry putting pressure
> on schools to turn out the CS graduates ... but the incoming freshman
> all wanting to be in CS program.
>
And I'll bet that a large part of those CS majors were only
in it because they thought they could make a *lot* of money
in programming. I have known people like that before...
known them, but *not* understood them. IMHO these types will
*never* make good programmers.
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
In article <·················@ev1.net>, Charles Richmond wrote:
> And I'll bet that a large part of those CS majors were only
> in it because they thought they could make a *lot* of money
> in programming. I have known people like that before...
> known them, but *not* understood them. IMHO these types will
> *never* make good programmers.
Yep. While you can make good money by being a programmer, you cannot be
a good programmer if all you work on is making good money.
Another addendum, just because I had one of those days.
Back when I took that computer security course, I realize now that it
must have been 1978 or 1979, I did an undergraduate research paper.
I read about protection rings in Multics, and indepepndently read
Backus' Turing Award paper. In my research paper, I proposed a novel
language-based approach to protection in which all data were tagged
with a classification and all procedures were tagged with a clearance.
I designed a lattice-based approach for deciding which procedures were
allowed access to which data and how to derive the classification of
the results of applying a procedure to input data given the classification
of the input data and the clearance of the procedure. (Recall that
FP was a purely function language.) And I augmented FP with new procedures
for declassifying and reclassifying results.
I can't find the paper now. (In those days students wrote papers with pen
and ink, not with word processors.) But my professor, Israel Gat, probably
will remember. I recall that he was so impressed that he encouraged me to
publish the paper.Unfortunately, I didn't follow his suggestion.
About 25 years later, Jon Reicke published the SLAM calculus.
> >>> All of this is true, but does not explain why it was Unix rather than
> >>> any of the others.
> >>
> >>One key feature of UNIX that has always struck me is that conceptually
> >>it provides a very simple set of abstractions that hide the hardware
> >>well, and portably. Many other OSes just don't do that, they are wedded
> >>to specific hardware or use "virtual machines" to fake it.
> >
> > The other portable and semi-portable operating systems of the time were
> > pretty similar to Unix in that respect, and sometimes simpler.
>
> Out of interest, could you put a name to any of the plausible
> alternatives? ...FLEX, TripOS, POP...
I think one of UNIX's key early advantages was f77.
Not great FORTRAN, but good enough so that a lot of engineers
could use it.
(CP/M wasn't in the running - no source code.)
Later, one of the things Convex did better than Gould was realize
that it was better to have a VAX compatible FORTRAN than
vanilla f77.
"Andy Glew" <················@sbcglobal.net> writes:
> (CP/M wasn't in the running - no source code.)
No problem. You could easily disassemble it. But the could that was
produced by the PL/M compiler looked quite horrible. I know, because I
did that. (And rewrote CP/M in Z80 assembler. It was a bit faster and
smaller afterwards).
'Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
Hi Andreas Eder,
> No problem. You could easily disassemble it. But the co[de] that was
> produced by the PL/M compiler looked quite horrible. I know, because I
> did that. (And rewrote CP/M in Z80 assembler. It was a bit faster and
> smaller afterwards).
I remember trying out CP/M on an Amstrad CPC 464. CP/M came with the
optional 3" floppy disk drive. Along with Amsoft Logo IIRC. As the Amstrad
had a Z80 microprocessor is there any chance you were involved with the
port?
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> writes:
> Hi Andreas Eder,
>
> I remember trying out CP/M on an Amstrad CPC 464. CP/M came with the
> optional 3" floppy disk drive. Along with Amsoft Logo IIRC. As the Amstrad
> had a Z80 microprocessor is there any chance you were involved with the
> port?
No, I did most of that work on Osborne machines. I liked them - kind
of the first transportable computer.
'Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
In article <······················@newssvr15.news.prodigy.com>,
"Andy Glew" <················@sbcglobal.net> writes:
|>
|> I think one of UNIX's key early advantages was f77.
|> Not great FORTRAN, but good enough so that a lot of engineers
|> could use it.
Grrk. I think that Stu Feldman will be amused by that - not happy,
but that isn't the same :-)
I don't think that you will find that f77 helped in the early days.
Well, obviously not, because Unix is a lot older than Fortran 77 :-)
When f77 was freshly out, even engineers had experience of systems
with high-quality Fortran compilers, and few of them were prepared
to touch f77. Quite rightly. It wasn't until the new generation
hatched, who had no experience of using anything else for real work,
that it started to be used for that.
Regards,
Nick Maclaren.
In article <············@pegasus.csx.cam.ac.uk>,
Nick Maclaren <····@cus.cam.ac.uk> wrote:
>Yes, but why did Unix replace the others? There were lots of balls
>rolling, but only Unix kept doing so.
I agree with you that the university connection is the reason why Unix
won. Lots of kids were graduating from college with knowledge of Unix and
Unix internals. So companies could reduce the learning curve by hiring
these people and using Unix.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
>>One key feature of UNIX that has always struck me
>>is that conceptually it provides a very simple set
>>of abstractions that hide the hardware well, and
>>portably. Many other OSes just don't do that, they
>>are wedded to specific hardware or use "virtual
>>machines" to fake it.
> The other portable and semi-portable operating systems of the time
> were pretty similar to Unix in that respect, and sometimes simpler.
I would love to see an example. I don't know of any system of that or
any other time that provided as simple, as widely applicable, and as
easily implemented a combination of abstractions, tools, and interfaces.
It is true that they didn't always take full advantage of the model, and
what Berkeley and USG did with networking is just not natural, but I
can't think of anything that would have been implementable on a small
PDP-11 that was even close.
Perhaps the "other balls" were simply too hard to inflate?
In article <·············@jeeves.eng.abbnm.com>,
Peter da Silva <·····@abbnm.com> wrote:
>>>One key feature of UNIX that has always struck me
>>>is that conceptually it provides a very simple set
>>>of abstractions that hide the hardware well, and
>>>portably. Many other OSes just don't do that, they
>>>are wedded to specific hardware or use "virtual
>>>machines" to fake it.
>
>> The other portable and semi-portable operating systems of the time
>> were pretty similar to Unix in that respect, and sometimes simpler.
>
>I would love to see an example. I don't know of any system of that or
>any other time that provided as simple, as widely applicable, and as
>easily implemented a combination of abstractions, tools, and interfaces.
As simple, yes, as easily implemented, yes. As widely applicable, it
depends slightly on what you mean. Let's use Tripos as a model, but
it was by no means unique, and it was later.
By the standards of that era, Unix was among the more complicated and
hard to implement of the portable systems. As a corollary, it was a
genuine operating system (no matter WHAT your definition), whereas the
simpler ones were often closer to OS/2 or Windows 2000 in level. For
example, many did not support memory protection between processes.
Similarly, Unix had more abstractions than most, but tools and interfaces
are as much question of the human resources to add them as basic to
the system.
>It is true that they didn't always take full advantage of the model, and
>what Berkeley and USG did with networking is just not natural, but I
>can't think of anything that would have been implementable on a small
>PDP-11 that was even close.
Hmm. I can't remember now, but I think that there were some comparable
systems around, though probably they came later. However, my response
was to:
One key feature of UNIX that has always struck me
is that conceptually it provides a very simple set
of abstractions that hide the hardware well, and
portably. Many other OSes just don't do that, they
are wedded to specific hardware or use "virtual
machines" to fake it.
Unix was good, make no mistake, but it was by no means unique in that
respect. Portable operating systems were an active research area at
that time, though most were more of the run-time executive nature.
Like OS/2, Windows 3 to 2000, CP/M and so on.
>Perhaps the "other balls" were simply too hard to inflate?
Not the ones I am thinking of. Less general once inflated, perhaps.
Regards,
Nick Maclaren.
····@cus.cam.ac.uk (Nick Maclaren) wrote:
>
>Unix was good, make no mistake, but it was by no means unique in that
>respect. Portable operating systems were an active research area at
>that time, though most were more of the run-time executive nature.
>Like OS/2, Windows 3 to 2000, CP/M and so on.
Windows 2000 is in the NT line not the 16 bit line. Perhaps you're thinking
of Windows ME.
Tony.
--
f.a.n.finch <···@dotat.at> http://dotat.at/
LOUGH FOYLE TO CARLINGFORD LOUGH: EAST OR SOUTHEAST 3 OR 4, LOCALLY 5. FAIR.
MODERATE OR GOOD. SLIGHT OR MODERATE.
Nick Maclaren <····@cus.cam.ac.uk> wrote:
+---------------
| All of this is true, but does not explain why it was Unix rather than
| any of the others.
|
| The explanation is almost certainly that it was freely available to
| USA universities, especially those in Silicon Valley, and some people
| from those places started up the workstation companies.
+---------------
Two timely factors that were *extremely* significant to companies like
Onyx Systems and Fortune Systems (and later, Sun):
1. The introduction of the "Binary Sub-License, Limited Number of Users"
license by AT&T in 1980 (early '81?). Previously, Unix could only
be obtained via a source license of (for commercial sites) ~$25K...
PER CPU! [Yes, there were discounts for volumes, but not large ones.
And the price for later versions rose to over $130K.] But suddenly,
any organization that had at least one source license could get
*binary* licenses for a few hundred bucks per machine!! And more
importantly, this new license permitted a company to sell *further*
binary-only sublicenses to *their* customers, with specific royalties
going back to AT&T. Those royalties were discounted according to the
*total* cumulative royalty payment, so that by the time you'd paid
a million dollars or so (IIRC), the incremental price-per-CPU for a
16-user license was less than $80. Almost overnight, this completely
changed the economics of using Unix versus cooking up a homegrown O/S!!
2. At the same time, Steve Ward's research group at MIT picked Unix to
run on their NuMachine and ported it (including the "PCC" C compiler)
to the Zilog Z8000, the Intel 8086, and the Motorola 68000. More to the
point, they *GAVE AWAY* their working port to anyone who asked politely
and had a valid Unix source license from AT&T. This enabled a *huge*
number of Unix startups to jump-start their development, especially
the 68k-based ones such as Fortune Systems (1981) and Sun (1982). As
noted at <URL:http://www.lcs.mit.edu/about/architects.html>:
Although it would not be clear for several years, by building a
single-user computer with a bitmapped display, a network interface,
and a powerful microprocessor, Ward's group had just created one
of the world's first UNIX workstations.
Over the next decade, Ward's group became a clearinghouse of
sorts for UNIX operating system ports. Many companies that
created commercial UNIX workstations, including Sun Microsystems,
started with a UNIX system that had either been sent to them
from LCS or was directly descended from another system that was.
Put #1 & #2 together, and there was practically no other choice for a
small startup to use. When Fortune Systems showed it's first system at
Comdex in Fall 1981, there were but a handful of other desktop/deskside
microprocessor-based Unix systems companies there. But by the Fall 1982
Comdex, there were nearly three dozen!!
-Rob
p.s. One other significant factor, though much less so than the above two:
3. The availability in the same time frame of production quantities of
the then-new 64 Kbit NMOS DRAM chips, which made the "huge" amounts
of memory needed for Unix systems (a whole megabyte, imagine that!!)
feasible for "low-cost" commercial systems, those in the under-$5000
market segment.
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Nick Maclaren" <····@cus.cam.ac.uk> wrote in message
·················@pegasus.csx.cam.ac.uk...
... [about the spread of Unix ]
> All of this is true, but does not explain why it was Unix rather than
> any of the others.
>
> The explanation is almost certainly that it was freely available to
> USA universities, especially those in Silicon Valley, and some people
> from those places started up the workstation companies.
Well, all universities. I actually have a copy of the license
for Katholieke Universiteit in Nijmegen, December 1974.
There were several other early ones in Europe and Israel.
Warnock later in the thread refers to commercial
sublicensing; this was no doubt important too (commercial
and government licensing started by the mid-70s).
I'm somewhat dubious of Warnock's claim that
Ward's MIT group had a lot to do with Sun specifically,
albeit it's made with the support of the document he references
http://www.lcs.mit.edu/about/architects.html
As I recall, Bill Joy took the BSD distribution directly
from Berkeley. Perhaps the 68K C compiler came from
MIT? Or maybe there's more to the MIT-UCB relationship
than is common knowledge?
Dennis
In article <··········@netnews.proxy.lucent.com>,
"Dennis Ritchie" <···@bell-labs.com> writes:
|> "Nick Maclaren" <····@cus.cam.ac.uk> wrote in message
|> ·················@pegasus.csx.cam.ac.uk...
|>
|> > All of this is true, but does not explain why it was Unix rather than
|> > any of the others.
|> >
|> > The explanation is almost certainly that it was freely available to
|> > USA universities, especially those in Silicon Valley, and some people
|> > from those places started up the workstation companies.
|>
|> Well, all universities. I actually have a copy of the license
|> for Katholieke Universiteit in Nijmegen, December 1974.
|> There were several other early ones in Europe and Israel.
Sorry, but that was not so! We tried and failed to get a licence,
several times. The problem was that the conditions for non-USA
universities were such that most could not honestly agree such a
contract - and certainly none in the UK could. Inter alia, the
licence forbade any work where the rights to the results of ANY
work done on the system (including with no access to the source)
were assigned to a third party.
A similar thing was true for roff, and our complete inability to
get even the slightest variation in that contract meant that we
developed our own layout program, GCAL. Note that it really DID
say that any results produced using roff had to be put into the
public domain, which was in flat contradiction to the conditions
imposed by most government-funded research grants, then and now.
Our computer scientists had a licence but, not merely was it a
little easier for that subject, they didn't have any funding of
the sort that gave trouble. This wasn't accidental, either. The
department and Roger Needham were powerful enough to be able to
refuse that sort of condition and get away with it. It lost
some money, but gained more benefits.
Of course, the standard action by many universities was to sign
a licence and ignore the conditions, but at least a couple of
them got caught up by that, and there were some lawyer's letters
flying around. I don't know what eventually happened in those
cases if, indeed, the matter was ever settled - there may STILL
be lawyer's letters flying around for all I know!
Regards,
Nick Maclaren.
From: Christopher C. Stacy
Subject: Re: Lisp Machines
Date:
Message-ID: <uy92mntip.fsf@dtpq.com>
>>>>> On Mon, 7 Apr 2003 03:18:24 -0000, Dennis Ritchie ("Dennis") writes:
Dennis> I'm somewhat dubious of Warnock's claim that
Dennis> Ward's MIT group had a lot to do with Sun specifically,
Dennis> albeit it's made with the support of the document he references
Dennis> http://www.lcs.mit.edu/about/architects.html
Dennis> As I recall, Bill Joy took the BSD distribution directly
Dennis> from Berkeley. Perhaps the 68K C compiler came from
Dennis> MIT? Or maybe there's more to the MIT-UCB relationship
Dennis> than is common knowledge?
I know that at least some of the work on BSD was done by MIT guys.
The shell's "job control" feature is one important example.
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On Mon, 7 Apr 2003 03:18:24 -0000, Dennis Ritchie ("Dennis") writes:
> Dennis> As I recall, Bill Joy took the BSD distribution directly
> Dennis> from Berkeley. Perhaps the 68K C compiler came from
> Dennis> MIT? Or maybe there's more to the MIT-UCB relationship
> Dennis> than is common knowledge?
> I know that at least some of the work on BSD was done by MIT guys.
> The shell's "job control" feature is one important example.
Job control was added to 3BSD by Jim Kulp, who was indeed an MIT guy,
but at the time he was running the computer facility at IIASA (outside
Vienna, Austria). I was working for him during the summer of 1980,
just before he returned to Cambridge to join Symbolics.
Jim added the SIGTSTP/CONT support in the kernel, and I added the "fg"
and "bg" commands to the shell. I'm pretty sure Jim was nostalgic for
similar features under ITS. Jim sent our modifications directly to
Bill Joy at Berkeley, and I hand-delivered a mag tape when I started
grad school there in the fall.
--
Eric C. Cooper e c c @ c m u . e d u
From: Christopher C. Stacy
Subject: Re: Lisp Machines
Date:
Message-ID: <uptnxqc4v.fsf@dtpq.com>
>>>>> On 07 Apr 2003 20:52:16 -0400, Eric C Cooper ("Eric") writes:
Eric> I'm pretty sure Jim was nostalgic for similar features under ITS
Yup; that's why that interrupt characters is control-Z.
There are some other ITS homages in Unix, but I forget what they all are.
The name "comsat" was another one (although not representative of what COMSAT did).
Dennis Ritchie <···@bell-labs.com> wrote:
+---------------
| I'm somewhat dubious of Warnock's claim that
| Ward's MIT group had a lot to do with Sun specifically,
| albeit it's made with the support of the document he references
| http://www.lcs.mit.edu/about/architects.html
+---------------
Actually, that document was my first and only exposure to that
"claim", which I tossed into my reply only to avoid leaving Sun
Microsystems out of the listing of early 68k-based systems based
on Ward's group's port [if they had been].
All I really know first-hand is that the name "SUN" was originally
the "Stanford University Network" project to provide affordable
networked graphical computing stations for the Stanford campus,
based on homebrew 68k-based Multibus boards with frame buffers &
Ethernet on them, and that many of the folks who had worked on that
went off and started Sun Microsystems, whose first systems were
curiously close to the planned "SUN" terminals. ;-} ;-}
+---------------
| As I recall, Bill Joy took the BSD distribution directly
| from Berkeley. Perhaps the 68K C compiler came from MIT?
+---------------
Your guess is as good as mine. But it's possible, since I know that at
Fortune Systems the MIT 68K C compiler was one of the most important
bits, but we also took a 4.1a-BSD distribution directly from Berkeley.
The Fortune box used a mish-mash of bits, being basically a Unix v.7
kernel hacked locally from the MIT port plus some of BSD-4.1a kernel
(particularly the TTY line disc. code), with a sometimes confusing
union of BSD and Unix System III & PWB user-mode utilities as well.
IIRC, we had a Sys-III license because AT&T had stopped selling the
standalone v.32 licenses needed to get BSD. Or maybe it was that we
wanted PWB too, and PWB came bundled with Sys-III, I forget. Whichever,
our Sys-III license was enough to get both the MIT & BSD tapes, which
were what we *really* cared about... ;-}
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Centuries ago, Nostradamus foresaw when ·································@hotmail.com (Franz Kafka) would write:
> People can anonymously use 20 year old source code. I don't think
> lawyers will be willing to spend millions trying to track down a
> hacker using an ip-spoofer or an anonymous remailer. And, unlike
> Mickey Mouse once it's out it's out.
You may get away with it if nobody cares to pursue the matter, but
that's not an interesting case.
It might be well and interesting to, in the privacy of my home, noodle
around with some old source code.
But if I were to get really interested in using that code for
something truly important, perhaps for the Next Great Internet
Application, nobody is going to want to "bet their business" on some
anonymously-stolen source code I have been toying around with.
--
output = ("cbbrowne" ·@cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/lisp.html
Rules of the Evil Overlord #167. "If I am recruiting to find someone
to run my computer systems, and my choice is between the brilliant
programmer who's head of the world's largest international technology
conglomerate and an obnoxious 15-year-old dork who's trying to impress
his dream girl, I'll take the brat and let the hero get stuck with the
genius." <http://www.eviloverlord.com/>
In article <··············@ID-125932.news.dfncis.de>,
Christopher Browne <········@acm.org> wrote:
>
>But if I were to get really interested in using that code for
>something truly important, perhaps for the Next Great Internet
>Application, nobody is going to want to "bet their business" on some
>anonymously-stolen source code I have been toying around with.
You aren't allowing for the code-laundering companies :-)
Seriously, you might be surprised at how much code currently being
relied on by the largest vendors doesn't have a recognisable history
beyond a couple of previous owners. Remember that transliteration
into other languages is fairly easy and gives a spurious appearance
of fresh development.
Regards,
Nick Maclaren.
Since Symbolics may still be in business, and TI scraped there
Lispm--I think we should release an opensource version of
the explorer OS.
We could start by puting Exploror tapes and Lisp sources on
the Internet.
TI is pretending Explorer's don't exist--
they kinda gave up the Copyright, I think.
The sources from the CADR, and LM-2 could be posted on the net
if people still have them.
THANKS
·································@hotmail.com (Franz Kafka) writes:
> Since Symbolics may still be in business, and TI scraped there
> Lispm--I think we should release an opensource version of
> the explorer OS.
That require TI to release the code or to do a clean room
version.
>
> We could start by puting Exploror tapes and Lisp sources on
> the Internet.
This is theft, pure and simple, with out written permission
from TI. Also TI may be bound by its licensing agreement
so it could not release the code even if it wanted to.
>
> TI is pretending Explorer's don't exist--
> they kinda gave up the Copyright, I think.
And you are ignorant. This means your opinion
is worth nothing.
>
> The sources from the CADR, and LM-2 could be posted on the net
> if people still have them.
>
> THANKS
no problem
marc
[ replying to comp.lang.lisp only
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
·································@hotmail.com (Franz Kafka) writes:
> TI is pretending Explorer's don't exist--
> they kinda gave up the Copyright, I think.
The former statement suggests knowledge and willful intent to mislead.
The more likely truth is that they don't have anyone whose job it is
to remember. I doubt they would deny it if they knew. They might not
be any more helpful, but they have no motivation to hide the history.
The use of the connective em-dash suggests that you think the former
statement supports the latter conclusion. I don't see any reason to
suppose they gave up the Copyright. Copyright cannot be "given up".
It has to be transferred in writing by explicit action.
Also, "although I am not a lawyer", I'd wager that "kinda" is not an
appropriate term of art for any serious conclusion under intellectual
property law.
Moreover, if they did know they had the intellectual property, and if
they knew where the sources resided physically, and they had someone
competent to know what it was, I doubt they would want to give it up.
Selling it off to someone else who wanted to give them real money would
sound more likely.
Even fans of free software would presumably have to agree that TI has
little to gain from contributing this stuff since (a) they don't plan
to make money by supporting it, (b) they don't plan to make money by
selling the hardware, and (c) there probably exists someone who would
pay them cash. The ordinary arguments for free software are usually
that either there's a strategy for making money on some other aspect
of it after giving it away or [as in (a)&(b) or other similar
strategies, such as vertical markets, etc.] or else they don't think
someone else sees commercial value in it. Note that a free software
advocate who really believes all this tommyrot about money to be made
in support could put their money where their mouth is and offer cash
to TI for the sources, then open source them (giving away what they
just paid cold cash for) and then hope they could make it back on
whatever business plan they are always telling others would work so
well.
On 04 Apr 2003 10:28:43 -0500, Kent M Pitman <······@world.std.com> wrote:
> ·································@hotmail.com (Franz Kafka) writes:
>
> > TI is pretending Explorer's don't exist--
> > they kinda gave up the Copyright, I think.
>
> The former statement suggests knowledge and willful intent to mislead.
> The more likely truth is that they don't have anyone whose job it is
> to remember. I doubt they would deny it if they knew. They might not
> be any more helpful, but they have no motivation to hide the history.
TI is apparently "officially" proud of Explorers:
http://www.ti.com/corp/docs/company/history/artificial.shtml
Paolo
--
Paolo Amoroso <·······@mclink.it>
·································@hotmail.com (Franz Kafka) writes:
> Since Symbolics may still be in business, and TI scraped there
> Lispm--I think we should release an opensource version of
> the explorer OS.
>
> We could start by puting Exploror tapes and Lisp sources on
> the Internet.
>
> TI is pretending Explorer's don't exist--
> they kinda gave up the Copyright, I think.
No, they haven't. And you would put yourself at risk for legal action
from corporate lawyers who quite honestly have nothing else to do
except hunt around for people who violate their IP rights. Really,
big companies have lawyers paid to do nothing but prosecute IP
violations.
It would be a fairly bad idea.
> The sources from the CADR, and LM-2 could be posted on the net
> if people still have them.
Maybe. But you'd still have to ask MIT for permission. Unlike the
ITS sources which were never 'officially' copyrighted, the LispM
sources were branded and copyrighted when they were distributed to the
two LispM companies.
'james
--
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))
"Franz Kafka" <·································@hotmail.com> wrote in message
································@posting.google.com...
> Since Symbolics may still be in business, and TI scraped there
> Lispm--I think we should release an opensource version of
> the explorer OS.
>
> We could start by puting Exploror tapes and Lisp sources on
> the Internet.
>
> TI is pretending Explorer's don't exist--
> they kinda gave up the Copyright, I think.
>
> The sources from the CADR, and LM-2 could be posted on the net
> if people still have them.
Here is a novel suggestion.
Instead of being lazy and trying to do things under the table,...
How about _you_ do the leg work and ASK the owners of Explorer to
release the software publically? Instead be upfront with those that
have Explorer and use some voluntary persuasion instead of resorting
to poor morality.
Wade
James: I have two questions.
1. How do your legal comments relate to the stuff on
http://www.unlambda.com/lispm/, which you seem to maintain? There it
says the following
<quote>
The emulator (known as 'E3', or the 'Explorer III') is desgined to run
as an ordinary user program on most modern desktop workstations. It
is intended to be portable between different processor architectures
and different operating systems. It is also intended to be an open
development project, with little licensing restrictions. A license has
not yet been developed, but it is assumed that the current status of
the project falls somewhere under the MIT X or BSD-style license.
</quote>
Is this a TI project that went public? Is it still alive? Is this
purely a hardware emulator, without the OS tapes included, or does it
involve the OS?
2. Is the Explorer OS like Genera (real-time debugging, that kind of
stuff everybody likes so much), or does it just happen to be
Lisp-based?
/jaap
I'm Jaap Weel, with email ··········@caltech.edu.
········@yahoo.co.uk (Jaap Weel) writes:
> 2. Is the Explorer OS like Genera (real-time debugging, that kind of
> stuff everybody likes so much), or does it just happen to be
> Lisp-based?
While both the Explorer OS and Genera had their roots in the MIT Lisp
Machine, Genera had much more development over its lifetime.
In article <··············@kappa.unlambda.com>,
James A. Crippen <·····@unlambda.com> wrote:
>The patent issued for Symbolics for the 3600 was in 1985. So count
>from then. That patent is available online if you search for it.
>It's huge though, including the entire octal dump of microcode.
If you were going to emulate something, Ivory would probably be a better
choice than 3600. In fact, isn't OpenGenera basically Genera running on an
Ivory emulator for the Alpha?
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Hi. I've tried several times to get to your site lately, but it doesn't
seem to be operating. You have, or had a LispM emulator there - or at
least it was there once.
Is there anything further to add to that?
Wesley Parish
James A. Crippen wrote:
> ····@sonic.net writes:
>
>> Franz Kafka wrote:
>>>
>>> >
>>> > As for TI Explorers, if you can find one in working order *with the
>>> > funny fiber optic console cable* then lucky you. Make sure you look
>>> > into the mailing list (look around, you'll find it) and offer to share
>>> > software and load bands with people if you want to make friends.
>>> > You'll need them.
>>> >
>>>
>>> Who would I contact at TI; nobody there seems to even remember the
>>> Explorer--let alone know where I can find the source.
>
> TI doesn't have anything on Explorers anymore. People who work there
> have personally told me so. They trashed it all months before they
> sold their entire computing equipment division to HP.
>
> The only Explorer related things that TI still has are the IP rights,
> such as patents and copyrights. Getting that out of the hands of
> their lawyers could be entertaining.
>
> TI basically would like the Explorer to be completely forgotten.
> They've already forgotten about it.
>
>> It's actually a double quest: First, you must find a copy of
>> Explorer - Then you must convince TI to allow you to release
>> it opensource. You may need to "decompile" it in order
>> to get a source code, which will be nearly as incomprehensible
>> as the machine code but at least a starting point.
>
> Like all LispMs, the Explorer came with the OS source. The
> *microcode* sources were almost never included, except for clients
> with certain special needs. The documentation for the macrocode
> engine is pretty sparse but it's almost what you need to know to
> construct an emulator. The hardware interface part is hard though,
> and undocumented. It has to be worked out by looking at the
> disassembled macrocode and paying attention to memory usage. (The
> Explorer has *two* memory maps, one for the macrocode Lisp system and
> the 'real' one that the microcode and NuBus backplane know about.)
>
>>> Would MIT be willing to share infomation about a LISP OS? They brought
>>> us GNU EMACS? I know the MIT version would be older then the other
>>> versions, but becasue they are a school they might release an GNU
>>> freeware version.
>>
>> MIT has lots of things they know about LispM's which they cannot
>> tell you or release because they have license agreements with
>> Symbolics (or with whomever now owns Symbolics' IP). And I'd
>> hesitate to assign too much responsibility for EMACS to MIT --
>> EMACS is mostly the result of the obsession of a single individual.
>
> It might be possible to find someone with the sources from the CADR,
> which would be basically owned by MIT and not by Symbolics. You'd
> have to look at each source file to see if it was copyrighted by one,
> the other, or both. Same goes for LMI copyright, which would be owned
> by TI.
>
>>> How old does the OS have to be before it falls into the public domain?
>>
>> Patents last 20 years; corporate copyrights for American companies
>> are up to about a century now and getting longer every time Mickey
>> Mouse threatens to escape his continuing enslavement by Disney (who
>> ought to be ashamed of themselves for their baldfaced robbery of the
>> public domain, but that's another rant).
>>
>> What that means is that 20 years after they produced it, (which
>> judging by the last publication dates of the manuals would be
>> around 2011, or judging from the first versions would be about
>> now) you can copy any ideas or techniques in a new work. But
>> you can't use their source code without permission in this
>> lifetime, unless Disney is first destroyed. And even if Disney
>> is destroyed, it probably won't be less than three-quarters of a
>> century.
>
> The patent issued for Symbolics for the 3600 was in 1985. So count
> from then. That patent is available online if you search for it.
> It's huge though, including the entire octal dump of microcode.
>
> TI issued patents all over the place, from the day they first met LMI
> all the way to the very end of the Explorer line. Theirs are much
> less comprehensive and scattered, and are of little use except for
> occasional reference for certain hardware specs not otherwise
> documented.
>
>> The problem with this is that the microcode isn't resident on the
>> chip across power cycles. The Ivory had a central CPU core that ran
>> "microinstructions" and a "microcode cache" that stored sequences of
>> microinstructions. The microcode cache had 64 (? I may misremember
>> here) addresses, each of which could hold up to 32 microinstructions.
>> On bootup, the microcode cache was loaded from persistent storage
>> (usually a disk). In the machine code for this chip, the address of
>> a block of microinstructions in the microcode cache was equivalent
>> to an instruction that ran that sequence of microinstructions. You
>> could also use microinstructions directly in the machine code.
>
> Direct references to microinstructions used the DTP-U-ENTRY, at least
> on the Exploder. That's what makes emulating it hard, because you
> have to emulate ucode entries just like other macrocode. And the
> ucode stuff usually did the hardware interface stuff, like I/O.
>
>> So anyway, the point is that if you come across some old machine that
>> contains a Symbolics Ivory chip but you don't have their IP on the
>> disk drive and motherboard of that machine, and you power it up, the
>> microcode cache won't contain the same blocks of microcode that they
>> contained when that chip would power up and load the cache in a
>> Symbolics machine.
>
> The microcode load was supplied off of the Breath Of Life tape (or
> CD). Without that all you got was the FEP.
>
>>> I am concered about the technical aspects of this project--not the
>>> legal or moral or ethical ones. I'd love to see a GNU Lisp OS build
>>> within the next few years--it has already been ten years since they
>>> were built, how much longer do we have to wait to rebuild them?????
>>
>> About now, if you follow the earliest design of Genera. But I
>> think you'd need to invest at least ten years working obsessively
>> on it before you got something compelling enough to get critical
>> mass for opensource development anyway.
>
> It looks to be taking that kind of obsession, yes. Which is rare,
> yes. Which is why we're not seeing anything yet.
>
>>> If Lispm companys are still in business, as people keep telling me,
>>> why can't I find Lispms being sold anywhere on the net, not even on
>>> EBay.
>>
>> Two LispMs have been sold on ebay in the last year. If you want one,
>> you just need to have patience and be persistent. Oh, and be ready to
>> bid high; collectors are paying museum-piece prices for these, which is
>> at this point a couple orders of magnitude higher than the cost of
>> equivalent processing power in other hardware.
>
> As I posted elsewhere you can usually get a used working XL1200 for
> around $3600 bucks. Shipping is outrageous. It uses SCSI so you
> don't have much problem with disks (except that only disks which can
> be formatted at 1280 bytes per block will work). And it uses ethernet
> so connectivity isn't a problem either. The console is irreplaceable,
> as it's entirely hardware specific. The console cable (which carries
> monitor output and key/mouse input as well as serial) is also
> irreplaceable unless you're really good at making cables.
>
> The Explorer is not commercially available anywhere, but can be had
> occasionally from warehouse or machine room cleanouts. It has a fiber
> optic cable for its console which uses some weird connector unknown to
> mankind. Replacing it is very hard. Other than that it's much like
> the Symbolics boxen, but instead of VME bus it uses NuBus (the
> predecessor to that used in Macintoys).
>
> LMI Lambdas and MIT CADRs are essentially unavailable unless the
> Goddess smiles upon you. And even then it's hard to keep one around
> because they're so big and crufty. You basically have to be a wizard
> to maintain one.
>
> Xerox D-Machines are marginally more available and have various
> limitations of their own, particularly el-cheapo displays that let out
> magic smoke frequently.
>
> 'james
>
--
First the wife, tone of awe. So much a condition. Kent in the labs,
forward. "So how was the worthlessful businessman?" But they hadn't
stopped meat for year ago, that arose hotel facade slowly moved apper.
- Don't let emacs meta-x dissociatedpress write your speeches!
From: Christopher C. Stacy
Subject: Re: Lisp Machines (was Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.)
Date:
Message-ID: <ud6k25x9q.fsf@dtpq.com>
>>>>> On Thu, 03 Apr 2003 20:11:53 GMT, bear ("bear") writes:
bear> And I'd hesitate to assign too much responsibility for EMACS
bear> to MIT -- EMACS is mostly the result of the obsession of a
bear> single individual.
Your above statements are not very accurate.
Petter Gustad <·············@gustad.com> wrote:
>
> Personally I think it would be more fun to
> make the FPGA version :-)
>
A CPU specification language could be used to write a Symbolics type
CPU.
Then the CPU could be emulated by people who want to play with the
Lisp OS
and turned into a chip by people who want to hardware-hack a Lisp
machine.
If you could somehow create some mircocode for a Intel or AMD
processor to turn it into an Ivory-type (LISP) processor--that would
be cool.
Prehaps someone could write a good quality Lisp compiler in a ROM and
use it like BIOS to build a Lisp Machine out of stock chips.
How hard would it be to write a Lisp Compiler on a EPROM and create a
Lisp board or even a board for any other language.
If you wrote a BIOS in Lisp you'd be well on your way to creating a
Lisp machine.
And, after the kernal is written--the rapid prototyping and
interactive development that Lisp provides would make it easier to
create a Lisp OS.
I'm sure that people are working on such kernals--if anyone needs help
with such projects please e-mail me I'm a Lisp programmer who's
willing to help.
From: Marco Antoniotti
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <jW1ja.21$zV2.1671@typhoon.nyu.edu>
Other people have already pointed this out, but....
Franz Kafka wrote:
> Petter Gustad wrote:
>
> >Personally I think it would be more fun to
> >make the FPGA version :-)
> >
>
>
> A CPU specification language could be used to write a Symbolics type
> CPU.
Once you have chosen your Hardware Design Language (VHDL, Verilog or one
you have implemented from scratch in CL) you can start writing the
"Symbolics type CPU".
Can you estimate the cost for this enterprise?
>
> Then the CPU could be emulated by people who want to play with the
> Lisp OS
This assumes you have the OS. Can you estimate the cost of this enterprise?
>
> and turned into a chip by people who want to hardware-hack a Lisp
> machine.
Again, can you estimate the cost of this enterprise, given the cost of
producing hardware?
>
>
> If you could somehow create some mircocode for a Intel or AMD
> processor to turn it into an Ivory-type (LISP) processor--that would
> be cool.
Yes. And this is usually beyond the time-frame of a Ph.D. thesis.
>
> Prehaps someone could write a good quality Lisp compiler in a ROM and
> use it like BIOS to build a Lisp Machine out of stock chips.
Once you have done all of the above, yes.
>
>
> How hard would it be to write a Lisp Compiler on a EPROM and create a
> Lisp board or even a board for any other language.
It isn't hard. It's costly.
>
> If you wrote a BIOS in Lisp you'd be well on your way to creating a
> Lisp machine.
>
> And, after the kernal is written--the rapid prototyping and
> interactive development that Lisp provides would make it easier to
> create a Lisp OS.
>
> I'm sure that people are working on such kernals--if anyone needs help
> with such projects please e-mail me I'm a Lisp programmer who's
> willing to help.
How about helping on many other less risky, less costly, more directly
useful projects out there first? McCLIM for example.
Cheers
--
Marco Antoniotti
From: Ole Myren Rohne
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <m3of3mi6r4.fsf@pcpenn04.cern.ch>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Once you have chosen your Hardware Design Language (VHDL, Verilog or
> one you have implemented from scratch in CL) you can start writing the
> "Symbolics type CPU".
That's cheating! He needs to start defining a lisp-based HDL;-)
Ole
In article <··············@pcpenn04.cern.ch>,
Ole Myren Rohne <·········@fys.uio.no> wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Once you have chosen your Hardware Design Language (VHDL, Verilog or
> > one you have implemented from scratch in CL) you can start writing the
> > "Symbolics type CPU".
>
> That's cheating! He needs to start defining a lisp-based HDL;-)
Most of the early public geometry-description languages more or less
took s-expressions, so that's a start. (I can't remember whose silicon
compiler it was that took Lisp code that implemented simple algorithms
and ran it through a series of code transformations that ended up
emitting piles of properly placed rectangles. It was useless, but very
sweet to look at.)
paul
From: Petter Gustad
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <m3u1dep3ka.fsf@scimul.dolphinics.no>
Ole Myren Rohne <·········@fys.uio.no> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Once you have chosen your Hardware Design Language (VHDL, Verilog or
> > one you have implemented from scratch in CL) you can start writing the
> > "Symbolics type CPU".
>
> That's cheating! He needs to start defining a lisp-based HDL;-)
Well, you could write it in EDIF, which is Lisp :-)
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
From: Jouni Matti Juhani Osmala
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <cy7y92pw4g0.fsf@nimaatre.hut.fi>
Petter Gustad <·············@gustad.com> writes:
> Ole Myren Rohne <·········@fys.uio.no> writes:
>
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> > > Once you have chosen your Hardware Design Language (VHDL, Verilog or
> > > one you have implemented from scratch in CL) you can start writing the
> > > "Symbolics type CPU".
> >
> > That's cheating! He needs to start defining a lisp-based HDL;-)
>
> Well, you could write it in EDIF, which is Lisp :-)
Well, I personally like lisp, and dislike VHDL, can EDIF be recommended as a
general purpose HDL?
How widely its used? Is it supported by most foundries?
Is there something that is cheap enough for student to import edif files to
FPGA:s.
Jouni Osmala
Helsinki University of Technology
Electrical Engineering.
ps. They only teach us VHDL. (And if there is something better I'd love to
learn it.)
From: Petter Gustad
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <87el4g4qh5.fsf@zener.home.gustad.com>
Jouni Matti Juhani Osmala <·······@nimaatre.hut.fi> writes:
> Petter Gustad <·············@gustad.com> writes:
>
> > Ole Myren Rohne <·········@fys.uio.no> writes:
> >
> > > Marco Antoniotti <·······@cs.nyu.edu> writes:
> > >
> > > > Once you have chosen your Hardware Design Language (VHDL, Verilog or
> > > > one you have implemented from scratch in CL) you can start writing the
> > > > "Symbolics type CPU".
> > >
> > > That's cheating! He needs to start defining a lisp-based HDL;-)
> >
> > Well, you could write it in EDIF, which is Lisp :-)
>
> Well, I personally like lisp, and dislike VHDL, can EDIF be recommended as a
> general purpose HDL?
No (notice the smiley). EDIF is a netlist format. However, you could
probably write some clever macros and functions in order to produce
some readable and maintainable HDL descriptions in Common Lisp if you
had an EDIF simulator (or you could convert the EDIF to verilog prior
to simulation).
> How widely its used? Is it supported by most foundries?
Very widely used and probably the most supported netlist format.
> Is there something that is cheap enough for student to import edif files to
> FPGA:s.
You can do this in Altera Quartus and Xilinx ISE. Don't know if the
free Web versions can do this though.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
From: Stephen J. Bevan
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <m3ists4jfn.fsf@dino.dnsalias.com>
Petter Gustad <·············@gustad.com> writes:
> ... . EDIF is a netlist format. However, you could
> probably write some clever macros and functions in order to produce
> some readable and maintainable HDL descriptions in Common Lisp if you
> had an EDIF simulator (or you could convert the EDIF to verilog prior
> to simulation).
EDIF 2 0 0 tried to cover lots of areas but effectively only really
supported netlist and some schematics. EDIF 3 0 0 made a much better
job of schematics and EDIF 4 0 0 added support for PCB/MCM layouts,
design rules, drawings, ... etc. However, it is possible that
although EDIF 3 0 0 became an IEC standard almost 10 years ago,
various tools have not been updated since the users/vendors were
mainly interested in netlists.
From: Rob Warnock
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <k9OcnemStuz-tg2jXTWc-w@speakeasy.net>
Petter Gustad <·············@gustad.com> wrote:
+---------------
| Jouni Matti Juhani Osmala <·······@nimaatre.hut.fi> writes:
| > Petter Gustad <·············@gustad.com> writes:
| > > Ole Myren Rohne <·········@fys.uio.no> writes:
| > > > Marco Antoniotti <·······@cs.nyu.edu> writes:
| > > > > Once you have chosen your Hardware Design Language (VHDL, Verilog...
| > > > That's cheating! He needs to start defining a lisp-based HDL;-)
| > > Well, you could write it in EDIF, which is Lisp :-)
| > Well, I personally like lisp, and dislike VHDL, can EDIF be recommended
| > as a general purpose HDL?
|
| No (notice the smiley). EDIF is a netlist format. However, you could
| probably write some clever macros and functions in order to produce
| some readable and maintainable HDL descriptions in Common Lisp if you
| had an EDIF simulator (or you could convert the EDIF to verilog prior
| to simulation).
+---------------
Here's one design/simulation approach, albeit somewhat dated by now:
<URL:http://www.swiss.ai.mit.edu/~jaffer/SIMSYNCH>
<URL:http://www.swiss.ai.mit.edu/~jaffer/Work/scm95-1>
<URL:http://www.swiss.ai.mit.edu/~jaffer/Work/scm97>
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Petter Gustad
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <m3d6jxpg31.fsf@scimul.dolphinics.no>
····@rpw3.org (Rob Warnock) writes:
> Here's one design/simulation approach, albeit somewhat dated by now:
>
> <URL:http://www.swiss.ai.mit.edu/~jaffer/SIMSYNCH>
> <URL:http://www.swiss.ai.mit.edu/~jaffer/Work/scm95-1>
> <URL:http://www.swiss.ai.mit.edu/~jaffer/Work/scm97>
Thank you for the url's.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
From: Bernd Paysan
Subject: Re: Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Date:
Message-ID: <4qjn6b-va4.ln@cohen.paysan.nom>
Jouni Matti Juhani Osmala wrote:
> Well, I personally like lisp, and dislike VHDL, can EDIF be recommended as
> a general purpose HDL?
EDIF is just a netlist format. A lisp-like general purpose HDL would allow
to define event-triggered functions; I'm pretty sure you could use Lisp to
define a complete high-level HDL.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/