Owner of Symbolics Lisp machines IP is interested in a non-commercial release
hachyderm.io
hachyderm.io
2018: "The current owner of Symbolics displayed interest in open-sourcing Genera a few years ago but nothing happened since then." https://news.ycombinator.com/item?id=17824330
2014: "The problem is that the Symbolics IP is now owned by John Mallery; he has stated he has plans for making it available but so far (several years) has not yet done so." https://news.ycombinator.com/item?id=7882034
The software itself can easily be found these days, if you're interested for hobbyist reasons.
I absolutely do not understand why Mallery is just sitting on it instead of making it available to everyone. It has zero non-historical value. Just put it out into the world and let it be examined as the historical artifact it is.
(That was my plan when I learned of Topping’s death. Unfortunately, Mallery beat me to acquiring it, and then just planted his ass on it.)
That reads as someone who sees it as a purely commercial investment, and is waiting for it to mature.
He co-authored this article about the development of the emulator: http://pt.withy.org/publications/VLM.html
The fact that he still has hope is significant.
Gary Palter was one of the last employees, and as such doesn't own the copyrights. However, he is in personal contact with Mallery, and the enhancements he has made to Genera (such as porting it to ARM) have been done with Mallery's permission.
Nobody seems to understand why Mallery is squatting on this rather than making it publicly available. Palter has never clearly explained it, although I imagine he doesn't want to burn his bridges with Mallery, and that may limit what he's able to publicly say.
Clearly he's hoping John Titor shows up and offers to exchange priceless insights about the future in exchange for access to the code in order to repair some weird embedded system in the far future. :)
More seriously, its not uncommon for people to have unrealistic expectations of the value of the things they've collected. They liked them enough to collect them, after all. People seeking them out might help cement the inflated valuation.
The sad thing is that when people die the people that inherit the assets often see no value in them at all and lose or discard them.
Does anyone know how much Mallery paid at the auction? It makes a big difference whether it was $50 or $50,000
If he paid a significant sum for it, he may still be clinging to hopes of an eventual return on his investment.
That’s the worst part of all this. It’s not like he’s sitting on a goldmine, he’s hoarding something of immense historical value because it’s slightly more beneficial for him to do so than it would be to share it.
I can’t imagine steering your legacy from being immortalized as an MIT AI researcher to… that.
I know it's not pretty, but it's an option.
where?
Background: I maintain the largest die photography collection on the internet. I wanted to take some die pictures for historical reasons. Fortunately I was able to get one to image from a third party, although I haven't posted it yet
Recently I found that not far from where I live, one can rent time on an electron microscope for a very reasonable price. But the lab in question does not have the gear needed for decapping and delayering.
If someone knows of a reasonably-priced (mid five-figures or less) commercial facility that will do it with a good chance of success, I'd be interested. But I won't be sending these chips to some random person who may or may not be able to (or even make an honest attempt) to do the job, as I have only this small handful of units and currently no way to get more.
Also, curious how old is the IP owner in this situation? What happens if he croaks with it?
As of several years ago, though, he was willing to part with a number of new-old-stock Ivory CPUs, for roughly the cost of their weight in gold. (And periodically offers Ivory machines for sale on eBay. Here's what these look like: http://www.loper-os.org/?p=2857 )
"Wish List: a knowledge-based operating system running on a MIMD parallel machine. The system should exceed the productivity of the Lisp Machine by several orders of magnitude and integrate seamlessly with a global knowledge base and with a global computational environment."
Looks like he recently registered a new company: https://opencorporates.com/companies/us_nh/872107
My favourite "conspiratorial" hypothesis concerning this question is that the Symbolics IP was ordered to be perma-buried for "national security" reasons (as it threatens to make practical systems with capabilities much superior to today's state of the art, but running on early 1990s IC fab processes) and that Mallery (who, per rumour, purchased the IP for next to nothing via a backroom deal) was the designated undertaker.
AFAIK it is still unknown whether the chip die masks, source for (the parts not included on the tapes/CD) os/compiler/IC workflow -- was even preserved to this day.
citing from the link:
> On Sunday, October 13th, 2002, Blender was released under the terms of the GNU General Public Licence, the strictest possible open-source contract. Not only would Blender be free, but its source code would remain free, forever, to be used for any purpose whatsoever.
keep this in mind when you pick a software license.
I wonder if there were any efforts in the 1990s or 2000s to create a FOSS clone of Genera in the vein of either the GNU project, the Linux kernel, and 4.4BSD and its descendants. I heard that Genera is quite complex, but complexity didn’t stop ReactOS and Haiku from chugging along after all these years.
https://www.softwarepreservation.org/projects/LISP/interlisp...
"Xerox PARC:Interlisp D Programmers Tools"
https://www.youtube.com/watch?v=xgMZ9gRhq8A
"The Medley Interlisp Project: Status and Plans"
Of course GNU project originally was heavily influenced by LISP machines, its only later that the lispy aspirations largely died off. Example from the original announcement:
> In particular, we plan to have [...] Lisp-based window system through which several Lisp programs and ordinary Unix programs can share a screen. Both C and Lisp will be available as system programming languages
As I understand the idea was to build free Lisp Machine clone which would have bits of unix in it.
https://www.gnu.org/prep/standards/standards.html#Source-Lan...
Back in the day it was mostly about C, hence why C adoption grew again as GNU/Linux gained adoption, when it was already being taken over by C++ in the Apple and Microsoft/IBM ecosystems.
> Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. So please write in C.
-- http://web.mit.edu/gnu/doc/html/standards_7.html
Lisp was only considered as part of specific applications like Emacs, as you can read on that surviving version from 1994.
What about guix? It uses guile ...
Not that I know of, but here's an install guide for the real deal: https://archives.loomcom.com/genera/genera-install.html
The industry has gone beyond “catching up” to surpassing the values of the Lisp Machine and Genera. Any grand ideas of this era have been considered, and either mined, reimplemented, and exploited or simply rejected as being past their time.
The lack of a Lisp machine or environment like Genera is not holding Lisp (much less the entire modern family of Lisp-y languages) back. And modern IDEs are off the charts, even if they don’t check every single box of what Genera has to offer.
As an industry, we’ve not just stood on the shoulders of giants of the past like Genera, we’ve stepped off and up and moved ahead.
I’ve seen the Genera image that’s floating around, it ran in a VM of some kind. There’s a couple YouTube videos of demonstrations, and maybe I’ve seen the wrong ones, but I’ve just seen them as interesting but not necessarily compelling. It would be wonderful to see a thorough review from a modern perspective.
And, yea, they should set the system free. It’s pushing 50 years old, and we’re in “internet” time, so who knows how much that is in “No one knows you’re a dog” years.
Why do I still have a clunky character-mode terminal instead of a Listener that can display rich text, images, mousable forms? Just think what we'd have today if we'd worked on that paradigm for 30 years instead of fetishizing the limitations of 70s minicomputers.
Why is it that when I type a command into said terminal and forget a parameter, I have to delete it, or open another window to type 'man', whereas on Genera I can hit <help> and view (rich, hypertext) documentation for a specific parameter, inline, while still typing in the command? That little feature was a revelation.
Genera's fluid, ergonomic developer experience is something we are turning away from more and more these days. Programming is increasingly surrounded by the most tedious bureaucratic and administrative work. The hoops I have to jump through before I can start creating something in a programming language are only increasing. If people had paid attention to Genera and to Lisp machines it wouldn't be like this.
And I've only mentioned surface aspects of the user experience. I haven't talked about being able to debug anything, or the idea that what look like applications are actually "substrates" that I can potentially use as APIs for my own work. We haven't scratched the surface yet.
But I took the time to get SLIME set up, with SBCL, and it seems like a completely different world. I’ve used languages with dynamic loading and REPLs before, and it seems like we still have something to learn from Lisp. Like, the experience is far from ideal—Lisp has its own problems. But it is just so damn nice to redefine a function in a running system, without having to then get the system back into the state that I need. I’ve used IDEs with dynamic code patching, and I’ve used Python systems that reload modules, but there have always been problems with the ergonomics.
https://learn.microsoft.com/en-us/visualstudio/debugger/edit...
To be clear—I’m not making the argument that people should be writing programs in Lisp. Just that there are some things to learn from the way Lisp development works.
In the past, when I’ve used the various edit-and-continue tools, it felt it was just cutting some time out of the edit-compile-run cycle. The Lisp system feels more like a workbench, where you create fixtures to try things out while you are building the system.
There's plenty of mature options both commercial and free, and to me, many years ago,they have a similar feeling.
It doesn't simply replace a function binding; it actually replaces code and puts the instruction pointer of existing threads that were running that code into some similar location in the new code. (Which is pretty amazing, to be sure).
What's going on in Lisp code reloading is something a lot pedestrian; just new functions are replacing old ones. Thread which are in the middle of running the old functions continue with those ones. When the last thread is done executing a function, it can be garbage collected.
I don't work with life-critical software and yet auditors demand that every code-change to production is peer reviewed and linked to a jira item.
Something like Fix & Continue in Visual Studio is good for testing out smaller changes. By comparison, something like SLIME + Lisp is powerful enough to use for developing new features. The running system on your developer workstation is mostly synchronized with the source code on disk because the interface you use for making changes is the editor. This synchronization is not perfect, but that’s why you have your unit tests and CI/CD pipeline.
If you're implying that this isn't thread safe, you're wrong. Edit and continue works just like how you described Lisp code reloading. Works just fine in production if you're crazy enough to push a debug build.
I dunno why Lisp people keep advertising ancient and widely distributed tech as revolutionary. Eg have you looked at LLVM XRay? It's yet another "self modifying C code hack", except it's explicitly designed to work in production on release builds: https://llvm.org/docs/XRay.html
I don't buy it. What in the world actually traces its roots to Genera in any way, outside of the Lisp microcosm?
I don't think the roots are going to be source code-based, but based on cultural transfer.
But the idea of Java being Lisp influenced is questionable. Though they had Guy Steele, who said something about bringing C programmers halfway to Lisp, pretty much the the only Lisp idea in Java is garbage collection.
The JVM is hostile against the efficient implementation of Lisp-like languages; it doesn't let you pack tag fields into pointer values.
>But the idea of Java being Lisp influenced is questionable. Though they had Guy Steele, who said something about bringing C programmers halfway to Lisp, pretty much the the only Lisp idea in Java is garbage collection.
Java also has some dynamicism through classloaders and reflection.
>The JVM is hostile against the efficient implementation of Lisp-like languages; it doesn't let you pack tag fields into pointer values.
It's a good trade off for Java, pointer coloring is used by ZGC for example.
Maybe PowerShell can also be described as using some of the same concepts of manipulating data as the Genera UI.
Dan Weinreb wrote an object-oriented database at Symbolics -> Objectstore was founded by former Symbolics people. Their C++ database was said to be influenced by Symbolics Statice.
Patrick Dussud from TI went to Microsoft. Dave Moon went to Apple. Gary Palter worked for Clozure. Steele worked for SUN on language design (Java, Fortress, ...). Weinreb later went to ITA -> worked on the flight search engine written in Lisp. There are a bunch of other examples.
A bunch of language infrastructure or even language designs was influenced.
Often when historical stuff like this is released for "non-commercial use", they're not just talking about not using the code itself in your own non-open-source product, but they mean "you can't run your business on this software."
The GPL certainly doesn't stop a commercial entity from downloading and using a GPL-licensed accounting package such a GnuCash to keep track of their company finances.
Perhaps more relevantly, here is an example of a GPL-ed Lisp implementation which has special provisions that allow proprietary programs to be redistributed which use it:
https://clisp.sourceforge.io/impnotes/faq.html#faq-licensing
One notable rule is that applications that access symbols non-portable internal packages (considered to be CLISP extensions) must comply with the GPL.
FFI is one of those packages. So this probably means that a proprietary application that extends CLISP via FFI (e.g. to call its own proprietary library) must split off that piece away from the application and make it GPL. I'm guessing that the rest of the code, which depends on the CLISP+extension, doesn't have to be GPL.
Shared libraries are very much NOT a firewall either, Stallman explicitly said otherwise[0] and Lesser GPL is there specifically for people who want it the other way round.
Linux is special - it's licensed with an exception that says user space never trips the GPL. Linus has also further interpreted said exception to mean that code that only touches user space equivalent APIs can live in kernel space without tripping GPL. They even have DRM[1] that enforces this interpretation on LKMs.
Absent that exception, who knows. The GPL copyleft is deliberately written to be as strong as copyright laws are, and we live in a legal environment where APIs can by copyrighted. So it's entirely plausible to argue that a GPL operating system trips its copyleft on all software written for it. A less hypothetical example: packaged emulators. If you sell a proprietary game wrapped inside a GPL emulator, that's a single program now, and you're violating GPL. However, while several emulator developers have had their work used in exactly this way, none of them have been willing to demand a relicense of the game their emulator was packaged with.
[0] https://sourceforge.net/p/clisp/clisp/ci/default/tree/doc/Wh...
[1] Digital Rights Management. Yes, Linus could actually sue a driver vendor that circumvented the Linux kernel linker licensing rules under DMCA 1201. GPLv3 explicitly contravenes such interpretations of the code, but well, Linus ain't touching that license with a ten foot pole.
In that specific case, the player has access to all the game files, and it's trivially easy to extract DooM out of the wrapper and play it somewhere else. I would agree that the GPL's "mere aggregation" language probably covers this particular use case - but I use the weasel word because the FSF's FAQ[0] about it is uncertain. This particular sentence comes to mind:
> But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Pretty much any program whose responsibility it is to host other programs (either OS kernels or emulators) is offering up interfaces that will carry intimate details of the host into the guest. In fact, this is precisely the reason why emulator development is a never-ending rabbit hole of implementing other people's bugs to get games to work. Another example of 'intimate communication' would be something like io_uring, where the OS kernel and user program are writing into ring buffers and trading ownership over subordinate data buffers around.
While the FAQ says a judge would ultimately decide each case on its own, practically speaking judges are going to defer to the guidance of the people who wrote the license unless there are facts to the contrary (e.g. an emulator developer said it's OK to aggregate game and emulator this way and then tried to change their mind). If Stallman says "sharing intimate details of execution constitute combination" then judges will take his side.
Another potential argument comes about if we swap out Steam for, say, the iOS App Store. Apple doesn't provide any ability to extract resources from iOS apps[1], nor do they allow shipping unpackaged emulators[2], so the user cannot meaningfully disaggregate the emulator from the game program as it has shipped on the App Store. Why would this specific case not be combining two programs into one?
[0] https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.htm....
[1] They aren't encrypted per se, but you don't have full filesystem access as the owner of the device, so...
[2] Apple doesn't want users downloading third-party code. This actually has nothing to do with the GPL - you ARE allowed to ship GPL code, if you provide custom EULA language that says that the GPL prevails over the App Store EULA.
I'd say, emulators are the easiest to defend. First and foremost, they emulated something which existed before. And the fact that there are different hardware and software emulations, several of them completely different to one another internally, proves that the program does not the intimate details of execution. Also, I read somewhere that especially if something existed before is a big difference when judging a GPL program. If a GPL program clones a previously existing behaviour, how can you with a straight face say an aggregate is derivative?
(Of course, there can be other things like GUI integration which muddies things up.)
GPL-incompatible applications that dynamically load a GPLed library and use it optionally can probably get away with it.
If you make a proprietary program which can optionally use a GPLed dynamic library, which you don't ship with the program, you're likely untouchable in court, if your attorney argues the point with a tongue more silver than the other guys' attorney.
on the other hand, not having this boundary would mean that a lot of commercial use would be prevented, which would work in favor of those who originally were looking for a non-commercial license.
but I don't see why it would be a concern here? you're saying to develop a non-gel application on top a gpl-d genera? I guess so.
Linkage is a very abstract concept; it just means name references in this piece here connect with name definitions in that piece over there. The tech may change, but the concept won't easily go away.
Function bindings being established or replaced, and used by code in other files, is linkage.
If you load a proprietary compiled file (.fasl or whatever) into a GPLed Lisp program/image such that either uses symbols in the other, that is a GPL violation.
However, a given Lisp can spell out exceptions to the rule. Like that a proprietary module may be used, provided it only uses certain symbols (in the module -> program direction), and certain registration mechanisms for its code being hooked in (program -> module direction). If it uses GPL symbols then it must be GPLed. Likewise, if the program is hacked to bypass the GPL-free module registration mechanism, so that it calls some proprietary symbols directly, that is also a GPL violation.
Same as Linux kernel .ko modules, basically. If you hack the kernel to call some function in a proprietary .ko, then that's a tainting situation. A .ko calling non-GPL functions, likewise. A proprietary .ko's module_init function being called by the kernel is not a GPL violation, and that module_init calling a non-GPL symbol to register something is also okay.
The GPL does not care about linkage status. The GNU Library license, which I originally wrote, is for cases such as this, and the lispm code could be licensed that way.
I don't understand what you mean by "partially on its way out".
Which would be a derived work under GPL and require publication of sources if distributed etc. etc.
GPL makes a lot of sense to me for something like this. Nobody is going to make money off Symbolic's old IP, but if they somehow were, clauses in the GPL3 or some variant of a copyleft license would likely force them to contribute back.
Back to proprietary software, during the AI boom of the 1980s, Lisp machine vendors had success selling high-end workstations to customers willing to pay good money for Lisp environments. This dried up during the subsequent AI winter, though some customers were able to move their Common Lisp solutions to commercial Lisp implementations that worked on workstations or servers running Unix or Windows. But at this point Lisp no longer had the same level of commercial interest, though the legacy and mindshare of Lisp grew through the use of Scheme in CS education (e.g., SICP and the team that wrote PLT Scheme, which was renamed Racket) and the advocacy of Lisp from prominent developers and researchers like Paul Graham, Richard Stallman (Emacs), Eric S. Raymond, Alan Kay (while he’s of course a Smalltalker, he’s spoken fondly of LISP 1.5 and also of The Art of the Metaobject Protocol), and many others. There are also many people who used Symbolics Genera in particular and who speak highly of its development environment, sometimes expressing the sentiment that modern development environments don’t compare to it.
There are FOSS Common Lisp implementations with wide usage. The most notable is Steel Bank Common Lisp (SBCL), and I also hear of plenty of people using Armed Bear Common Lisp (ABCL, which runs on the Java virtual machine) and Embeddable Common Lisp (ECL). There are other FOSS Common Lisp implementations that I know less about.
[1] https://en.wikipedia.org/wiki/Hackers:_Heroes_of_the_Compute...
Pick an editor: https://lispcookbook.github.io/cl-cookbook/editor-support.ht...
Good enough for games (and other commercial offerings) - https://kandria.com/
Well, Emacs, SBCL and SLIME are like bread and butter for obvious reasons.
Furthermore, Carl de Marcken, chief scientist/co-founder of ITA, had chosen Lisp because it was what he was most familiar with. He had told me in 2007 that if he had to choose a language again, he probably would have chosen Java, a choice Google would likely favor over Lisp.
I say this not to disparage Lisp—I enjoy Lisps, and I use Lisp professionally—but to contextualize this particular use of Lisp at Google.
EDIT: Just saw your reply to a sibling comment explaining that you meant SBCL, not Lisp per se.
The problem of parsing data from airlines is fiendishly hard. There are a ton of different rules for how to calculate prices, and all sorts of deals and promotions that may affect a particular route on a particular day. If you have a system which can parse this data, then you wouldn’t want to rewrite it. I’ve read a number of articles about ITA Software’s Lisp code and it’s really interesting.
Lisp may be a critical part of ITA’s success, but “good enough for Google” is probably the wrong take here—Google, I’m sure, purchased a company to add its working product to their portfolio. I doubt that Google’s processes would allow someone to ale a new product in Lisp.
http://www.paulgraham.com/carl.html
I’ve read other stories, and seen presentations, but the information is getting harder to find.
Nothing could be further from the truth.
Imagine programming Python by writing out the AST in JSON. That's what Lisp looks like.
I guess it makes the parser really simple and elegant, but they definitely went way too far towards the programmer on the "make it simple for the programmer/user" spectrum.
C/Java etc (which I was a professional in) have too many bits to the syntax - braces and semi-colons and the execution is not necessarily shown by the format.
I also like python for similar reasons.
Though I think it's more than likely that once people had free access to it and saw what modern conveniences were missing etc the mystique would be lost and it would be kept more as an archaeological asset than as an ongoing thing people wanted to maintain and use.
People would also discover that the architecture is not simple, but grown over a decade while there was rapid development of the basics people take for granted: standards, languages, networking, operating systems, ... In the mid 80s TCP/IP was an expensive add on for Genera. Later it was made a part of the OS. But development stopped before it could add things like IPv6, Unicode, basic security, HTTPS, and other things.
One could add it, but then one had to learn ZetaLisp (70s/80s), Flavors (early 80s), Symbolics Common Lisp (80s/90s), an object-oriented networking stack architecture from the 80s, ...
You would have a second life in a technology stack somewhere between the past and the future, in a parallel world.
Still I also think these kinds of "live editing" environments don't translate well into some modern "best practices" around version control, deployment, versioning, etc. Remembering my experience with LambdaMOO & similar and then later Smalltalk/Squeak and recently with doing stuff with Julia's REPL, etc. They're fascinating and fairly productive, but I am not convinced about this technique's ability to scale.
It may not have the fancy UI, may not have a fancy user experience, may not be an operating system, may have a more primitive Lisp dialect, may not have a good multi-threading story, ... but it might exist and people put a lot of work into it: GNU Emacs and its extensions.
That's how it is...
That plus the lovely keyboards, nice case design, etc. etc.
At some point in time they produced cards for the SUN VMEBus and for the Mac Nubus. Then the only thing left was the keyboard.
So, I agree, the Lisp Machine concept was a combination of Hard- and Software. The emulators of today only provide some of the software parts...
My understanding is Moore's law just ended up making these attempts uneconomical. By the time HW eng and manufacturing is done on the custom components, "orthodox" general MPU capabilities end up leapfrogging it and a well engineered software VM can outperform.
Maybe we could start to see this change again, who knows.
Maybe unikernels running highly tuned VMs on the hypervisor could be this generation's equivalent. Full control over the MMU, tagged pointers all the way down... hmmmmm
So would be really difficult to setup a public/no-profit startup/company to bring up all the stuff, and coordinate all the people involved? maybe even a new hw can be made again..
Probably the real problems arise from different opinions between owners and former employees about the future and possibilites of the technology?
But this story everytime make me think at the billions of lines of code leaved in the dark (or in the reels of 9inch tapes), representing so many years/man of work, developed and debugged, only to be forget and sometimes reinvented, some better it's progress of course, and may times only worse, reinventing the wheel every time. Even this is a form of waste/pollution?