3 ms·

Very impressive. Since the demise Lisp machines, there have been several attempts at developing a Lisp-based operating system which didn't deliver anything: Li

Very impressive. Since the demise Lisp machines, there have been several attempts at developing a Lisp-based operating system which didn't deliver anything: LispOS, Tunes, and Loper; and one successful attempt at getting Lisp to run on the bare metal: Movitz. Lisp was its own operating system on the original Lisp machines developed at MIT, and this evolved into Genera at Symbolics. Is this the case here? I notice that Mezzano has files. Files are inherited from operating systems running non image-based languages. They're alien to Smalltalk, where everything is just stored in the image (or world, in Lisp parlance). This could also be done in Lisp. Text files could be replaced by long strings contained in the world. Hypertext, provided tags are balanced, could be stored as lists. When the system is shut down, and periodically beforehand, the world is written to disk. You can go further, by using a single address space. Particularly large blocks of text which don't fit into RAM, and so have to be stored on disk, can be addressed by treating the disk as an extension of RAM. You can even go further on 64 bit machines by treating the entire contents of the internet as an extension of RAM. I once wrote a small bare-metal Lisp interpreter in x86 assembler, which ran off a 1.4Mb floppy on an old laptop. The hardest part was writing the floppy disk driver, which has to handle frequent hardware errors. USB drivers are many times harder and I didn't attempt that. If the Mezzano developer(s) succeeded, I'm even more impressed.

spaceheeder 10y ago
I think files have proven themselves to be a useful abstraction in enough use cases across enough device form-factors to be worth backporting into whatever your idea of an ideal lisp machine might be. You could, with a non-trivial amount of effort, replicate the file-like conveniences of global tagging and sorting and organizing of all the objects in your image. You could, also with a non-trivial amount of effort, work out the schemes for permissions, etc. so that objects with all those file-like conveniences can be shared, like files, on multi-user systems or between machines or over networks. It's not clear to me that the above would offer any tangible benefit over files. So if you're going to put a non-trivial amount of effort into a lisp machine, why not just teach it what a file is?
- DonaldFisk 10y ago
  > I think files have proven themselves You will need to store data which doesn't fit into RAM in secondary storage. But that doesn't mean you need a file system or even files. > to be a useful abstraction Files are a necessary evil in non-image based systems because you need to store data somewhere when the programs using them aren't running. As the different objects they contain, such as plain text, hypertext, photographs, sound recordings, executables, etc. have nothing in common, they seem an unnecessary abstraction. They require that programs which use them parse/serialize their contents. This is unnecessary if the contents are already in memory, already in the format the program needs. > replicate the file-like conveniences of global tagging and sorting and organizing of all the objects in your image Why remember a file name and where it is in the directory tree when you could use a search engine to search for it based on content? Or simply chain through objects, going to the field you want and following the link? Programs, of course, will just directly link to the object. > work out the schemes for permissions I'd go for capabilities, rather than access control. > why not just teach it what a file is? Building a file system is a major undertaking. If it can be avoided, and to the extent it can be avoided, it should be. You would only need to know about files when you interact with systems which are based around files.
  - TeMPOraL 10y ago
    I think files are pretty cool because they're loosely coupled with programs. I.e. you can open and edit text or audio files in whatever you like, and even highly-specific binary formats like .doc or .psd have various levels of support in 3rd-party tools. This serves a very useful purpose of ensuring your data is truly yours, and will outlive the program in which it was created. This is a place where IMO we're taking a huge step backwards now, with increasing amount of work being done in the cloud and mobile ecosystems - both shed the concept of files for some amorphous database entries somewhere, thus taking away your control over your data. Can you preserve this flexibility/loose-coupling feature in image-based storage? I don't know. I'd be interested to learn if it can be done so.
- nickpsecurity 10y ago
  You can do the same with objects. Difference is the semantics is more flexible with an implementation that can be as simple or complex as you want. INFOSEC research used this to advantage where things like PSOS built files on top of simpler store and things like DASD could build in analysis or encryption at disk/object level.
hga 10y ago
Being file based is very much in MIT Lisp DNA, certainly MACLISP and the CADR MIT Lisp Machine. (Re-)Building from scratch from files and saving out an image for faster loading times (or resaving an image with your project's stable files), vs. the Smalltalk working on an image once you get one going. The single address space OS was well known from Multics, but I think would have been too much additional work for the developers, and running such a system with the much less reliable hardware of those days required a lot of tape backup, e.g. MIT-Multics would back up any dirty segment (file) after ~1/2 an hour, which of course required 24x7 operator staffing, that sort of Information Utility thing wasn't really in this group's DNA. The Incompatiable Time Shareing System (ITS) was in fact named in humorous opposition to the Multics predecessor, the Compatible Time Sharing System (CTSS), the latter was xompatible with batch, those jobs would soak up any spare cycles if possible, which was a big deal back then. ITS instead had features where you could pretty much take over the machine for a robotics experiment or demo, that sort of resource allocation was handled socially, and such features were hidden by obscurity and a sort of apprenticeship system, instead of being enforced by the OS.
jonjacky 10y ago
BBN Lisp and its successor Interlisp, popular in the 1960s and 70s, had a persistent data store that was more closely integrated with the running Lisp image than typical general-purpose file systems (slide 41 in [1]) The proposed (but apparently un-implemented) LispOS [2] was to have a single-level store where objects in the running Lisp image would be transparently checkpointed to disk, with no conventional file system. [1] http://www.international-lisp-conference.org/2005/media/baker-slides.pdf http://www.international-lisp-conference.org/2005/media/bake... [2] https://github.com/robert-strandh/LispOS/blob/master/Documentation/chap-intro.tex https://github.com/robert-strandh/LispOS/blob/master/Documen..., also chap-checkpointing.tex

spaceheeder 10y ago

I think files have proven themselves to be a useful abstraction in enough use cases across enough device form-factors to be worth backporting into whatever your idea of an ideal lisp machine might be. You could, with a non-trivial amount of effort, replicate the file-like conveniences of global tagging and sorting and organizing of all the objects in your image. You could, also with a non-trivial amount of effort, work out the schemes for permissions, etc. so that objects with all those file-like conveniences can be shared, like files, on multi-user systems or between machines or over networks. It's not clear to me that the above would offer any tangible benefit over files. So if you're going to put a non-trivial amount of effort into a lisp machine, why not just teach it what a file is?

DonaldFisk 10y ago
> I think files have proven themselves You will need to store data which doesn't fit into RAM in secondary storage. But that doesn't mean you need a file system or even files. > to be a useful abstraction Files are a necessary evil in non-image based systems because you need to store data somewhere when the programs using them aren't running. As the different objects they contain, such as plain text, hypertext, photographs, sound recordings, executables, etc. have nothing in common, they seem an unnecessary abstraction. They require that programs which use them parse/serialize their contents. This is unnecessary if the contents are already in memory, already in the format the program needs. > replicate the file-like conveniences of global tagging and sorting and organizing of all the objects in your image Why remember a file name and where it is in the directory tree when you could use a search engine to search for it based on content? Or simply chain through objects, going to the field you want and following the link? Programs, of course, will just directly link to the object. > work out the schemes for permissions I'd go for capabilities, rather than access control. > why not just teach it what a file is? Building a file system is a major undertaking. If it can be avoided, and to the extent it can be avoided, it should be. You would only need to know about files when you interact with systems which are based around files.
- TeMPOraL 10y ago
  I think files are pretty cool because they're loosely coupled with programs. I.e. you can open and edit text or audio files in whatever you like, and even highly-specific binary formats like .doc or .psd have various levels of support in 3rd-party tools. This serves a very useful purpose of ensuring your data is truly yours, and will outlive the program in which it was created. This is a place where IMO we're taking a huge step backwards now, with increasing amount of work being done in the cloud and mobile ecosystems - both shed the concept of files for some amorphous database entries somewhere, thus taking away your control over your data. Can you preserve this flexibility/loose-coupling feature in image-based storage? I don't know. I'd be interested to learn if it can be done so.
nickpsecurity 10y ago
You can do the same with objects. Difference is the semantics is more flexible with an implementation that can be as simple or complex as you want. INFOSEC research used this to advantage where things like PSOS built files on top of simpler store and things like DASD could build in analysis or encryption at disk/object level.

hga 10y ago

Being file based is very much in MIT Lisp DNA, certainly MACLISP and the CADR MIT Lisp Machine. (Re-)Building from scratch from files and saving out an image for faster loading times (or resaving an image with your project's stable files), vs. the Smalltalk working on an image once you get one going. The single address space OS was well known from Multics, but I think would have been too much additional work for the developers, and running such a system with the much less reliable hardware of those days required a lot of tape backup, e.g. MIT-Multics would back up any dirty segment (file) after ~1/2 an hour, which of course required 24x7 operator staffing, that sort of Information Utility thing wasn't really in this group's DNA. The Incompatiable Time Shareing System (ITS) was in fact named in humorous opposition to the Multics predecessor, the Compatible Time Sharing System (CTSS), the latter was xompatible with batch, those jobs would soak up any spare cycles if possible, which was a big deal back then. ITS instead had features where you could pretty much take over the machine for a robotics experiment or demo, that sort of resource allocation was handled socially, and such features were hidden by obscurity and a sort of apprenticeship system, instead of being enforced by the OS.

jonjacky 10y ago

BBN Lisp and its successor Interlisp, popular in the 1960s and 70s, had a persistent data store that was more closely integrated with the running Lisp image than typical general-purpose file systems (slide 41 in [1]) The proposed (but apparently un-implemented) LispOS [2] was to have a single-level store where objects in the running Lisp image would be transparently checkpointed to disk, with no conventional file system. [1] http://www.international-lisp-conference.org/2005/media/baker-slides.pdf http://www.international-lisp-conference.org/2005/media/bake... [2] https://github.com/robert-strandh/LispOS/blob/master/Documentation/chap-intro.tex https://github.com/robert-strandh/LispOS/blob/master/Documen..., also chap-checkpointing.tex