Could somebody use SCSH, Sheme, or Lisp to create the "Lispm" architecture.
Franz Kafka
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.
Christopher Browne
> 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("moc.enworbbc@" "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
Henrik Motakef
> 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
Joe Marshall
> IMHO, Operating Systems have become boring in the last years. There
> are several "good enough" OSes you can build upon.
What a horrible idea.
Wade Humeniuk
"Franz Kafka" <Symbolics_XL1201...@hotmail.com> wrote in message
news:b3b6b110.03033...@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
as an example.
Wade
Anne & Lynn Wheeler
> 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
Petter Gustad
> 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
Franz Kafka
> Well, so what? Why do you think having a Lisp Machine is important?
>
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.
Franz Kafka
> 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.
Henrik Motakef
> 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
Christopher C. Stacy
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.)
Christopher C. Stacy
Petter> Symbolics_XL1201...@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?
Anne & Lynn Wheeler
cst...@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).
Joe Marshall
> 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.
Franz Kafka
> > 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!!!!!
Andrew Reilly
> 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
Simon András
> 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
Franz Kafka
> 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.
Petter Gustad
> >
> > 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...
Ketil Malde
> Andrew Reilly <and...@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
James A. Crippen
> Symbolics_XL1201...@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))
Paul Wallich
"Ketil Malde" <ket...@ii.uib.no> wrote:
> asi...@math.bme.hu (Simon András) writes:
>
> > Andrew Reilly <and...@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
Franz Kafka
> 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.
Franz Kafka
>
> 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.
Christopher C. Stacy
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.
be...@sonic.net
>
> >
> > 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)
Marco Antoniotti
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
James A. Crippen
> 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.
Barry Margolin
James A. Crippen <ja...@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, barry.m...@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.
Franz Kafka
> > 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.
Franz Kafka
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
Marc Spitzer
> > >
> > > 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
Marc Spitzer
> 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
Bernd Paysan
> 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/
Christopher C. Stacy
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.
Andreas Eder
> 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æ„€ my $HOME.
Wade Humeniuk
"Franz Kafka" <Symbolics_XL1201...@hotmail.com> wrote in message
news:b3b6b110.0304...@posting.google.com...
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
Ole Myren Rohne
> 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
Paul Wallich
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
Petter Gustad
Well, you could write it in EDIF, which is Lisp :-)
Marc Spitzer
> Marc Spitzer <mspi...@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
Barry Margolin
Andreas Eder <Andrea...@t-online.de> wrote:
>Marc Spitzer <mspi...@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.
Anne & Lynn Wheeler
>
> 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
Nick Maclaren
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.
Jouni Matti Juhani Osmala
> Ole Myren Rohne <ole....@fys.uio.no> writes:
>
> > Marco Antoniotti <mar...@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.)
Petter Gustad
> Petter Gustad <newsma...@gustad.com> writes:
>
> > Ole Myren Rohne <ole....@fys.uio.no> writes:
> >
> > > Marco Antoniotti <mar...@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.
Rupert Pigott
news:b6m4oc$mik$1...@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
Stephen J. Bevan
> ... . 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.
Nick Maclaren
Rupert Pigott <r...@dark-try-removing-this-boong.demon.co.uk> wrote:
>"Nick Maclaren" <nm...@cus.cam.ac.uk> wrote in message
>news:b6m4oc$mik$1...@pegasus.csx.cam.ac.uk...
>
>> 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.
Andrew Reilly
> In article <10495786...@saucer.planet.gong>, Rupert Pigott
> <r...@dark-try-removing-this-boong.demon.co.uk> wrote:
>>"Nick Maclaren" <nm...@cus.cam.ac.uk> wrote in message
>>news:b6m4oc$mik$1...@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
Robin KAY
> 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)
Rob Warnock
+---------------
| 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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock
+---------------
| Jouni Matti Juhani Osmala <jos...@nimaatre.hut.fi> writes:
| > Petter Gustad <newsma...@gustad.com> writes:
| > > Ole Myren Rohne <ole....@fys.uio.no> writes:
| > > > Marco Antoniotti <mar...@cs.nyu.edu> writes:
| > > > 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
Nick Maclaren
Andrew Reilly <are...@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.
Bernd Paysan
> 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.
Dennis Ritchie
... [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
Dennis Ritchie
"Barry Margolin" <barry.m...@level3.com> wrote in message
news:MSija.10$cO1...@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
Nick Maclaren
In article <b6qpf3$h...@netnews.proxy.lucent.com>,
"Dennis Ritchie" <d...@bell-labs.com> writes:
|> "Nick Maclaren" <nm...@cus.cam.ac.uk> wrote in message
|> news:b6m4oc$mik$1...@pegasus.csx.cam.ac.uk...
|>
|> > 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.
Barry Margolin
Nick Maclaren <nm...@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.
Christopher C. Stacy
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.
Christopher Browne
> 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/>
Eric C. Cooper
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
Dennis Ritchie
about earlyish Unix licensing (after quoting me)
> |> 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. ...
I'm in off-line communication with Nick, and have
no doubt at all that Cambridge, at least, had problems
with the license. In the meantime, as a grounding point,
the KU Nijmegen license, as well as two later price lists,
are at
http://cm.bell-labs.com/cm/cs/who/dmr/licenses.html
if anyone is interested.
Dennis
Petter Gustad
> 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.
Nick Maclaren
Christopher Browne <cbbr...@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.
Christopher C. Stacy
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).
Harri Haataja
>>>>>> 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".
Christopher C. Stacy
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.
Andy Glew
> >>> 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
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.
be...@sonic.net
> 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
Andreas Eder
> (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æ„€ my $HOME.
Nick Maclaren
In article <jDLka.258$VY5.25...@newssvr15.news.prodigy.com>,
"Andy Glew" <andy-gle...@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.
Rob Warnock
+---------------
| 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... ;-}
Adam Warner
> 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
Joe Marshall
> 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.
Florian Weimer
> 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-)
Andreas Eder
> 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.
Pascal Bourguignon
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.
Sander Vesik
> | 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 +++
Florian Weimer
> 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.
Tom Knight
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.
Brian Hurt
> Joe Marshall <j...@ccs.neu.edu> writes:
>
> > be...@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
Rupert Pigott
news:81f0f84e.03040...@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
MJ Ray
> 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?
Toon Moene
> 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 - mailto:to...@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)
Harri Haataja
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
Christopher Browne
> 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"
-- Herb....@novatel.cuc.ab.ca
Andy Glew
> > 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.
Patrick Schaaf
>> > 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
Jaap Weel
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 MYLAS...@caltech.edu.
Joe Marshall
> 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.
Peter da Silva
>>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?
Peter da Silva
> 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.
Peter da Silva
>>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.
Nick Maclaren
Peter da Silva <pe...@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.
Nick Maclaren
>>>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.
Jeffrey Mark Siskind
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.
Jeffrey Mark Siskind
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.
Jeffrey Mark Siskind
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.
Andrew Reilly
> 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