1. 16

previous submission: https://lobste.rs/s/0ktcko/lispos_specifcation_lisp_operating

  1. 3

    PicoLisp OS

    1. 3

      I’m not sure what make of this, TBH.

      The introductory paragraph states, “A LispOS is also an operating system that uses the Lisp interactive environment as an inspiration for the interface between the user and the system, and between applications and the system. “ but the rest of the article doesn’t really talk about that. At least I’m not making the connection.

      As far as the actual “meat” of the article, it’s really light on details, hand waves quite a bit, and doesn’t justify many of the claims or required “features”. I suppose such a system could be created, but this article isn’t convincing me it’s necessary or that it would be an advantage over current systems.

      FWIW, I’m pretty happy using FreeBSD and Debian as “Lisp OSes”. I run StumpWM and Emacs, and over time I’ve done more and more every day tasks in the REPL. It’s not perfect, and I still use the terminal and other applications, but I do most of my hobby development in Lisp, and use it to automate quite a bit of my personal workflow. Where most people start at the command line, then move to a shell script or Python, I start at the command line and then move to the Lisp REPL.

      As far as every application providing a REPL and allowing runtime introspection and development, I don’t think there’s much advantage to the end user. Being able to connect isn’t useful without understanding how the application works, and just like open source code, there can be a huge learning curve to use it effectively.

      1. 1

        If an OS (not a DE) was built with LISP in mind it will be easier to deal with network and files, I think about async with fibers primitives as default. More about files, the most interesting aspect of the paper is the new approach to durable storage. With the advent of KV-SSD it might be time to re-think the persistence stack, and only provide a hierarchical file system as an emultation.

        edit: in fact, I am not sure what is the advantage of “everything is a file” as plan-9 does.

        1. 2

          Two thoughts.

          First, I don’t see what Lisp has to do with any of that. There’s nothing special about Lisp that would make a non-hierarchical file system easier to use, or make networking and files easier to deal with, or magically make everything more asynchronous or work better with fibers.

          As far as key value storge and non-hierarchical file systems go, I’m not seeing the advantage. Hierarchical file layout is a super-set of flat systems, and IMO do have significant advantages over a flat layout. If it’s not important for your use case, it’s easy enough ignore it and throw everything in one directory. If it’s important enough, choose a file system optimized for that use case.

          The comments about files being a stream of bytes are neither here nor there, really. In some sense, files will always be a stream of bytes because that’s how computers work at the lowest level, but treating them that way at the user level is a choice. If you don’t like it, don’t do it.

          I’m not saying Lisp couldn’t be used for such a system, or that it couldn’t adapt to those paradigms, but those systems could just as easily be written in C++ or Rust or some other language.

      2. 3

        I broadly agree with the ideals put forth here. Some minor nits, though:

        Clearly, if there is a single address space shared by all applications, there needs to be a different mechanism to ensure protection between them so that one application can not intentionally or accidentally destroy the data of another application. Most high-level programming languages (in particular Lisp, but also Java, and many more) propose a solution to this problem by simply not allowing users to execute arbitrary machine code. Instead, they allow only code that has been produced from the high-level notation of the language and which excludes arbitrary pointer arithmetic so that the application can only address its own data.

        This takes care of the biggest problem, but security is still an issue. You need still to prevent code from accessing objects it oughtn’t. My solution to this is a capability-based model with thread granularity (message-passing between threads heavily encouraged, over direct calling).

        As it turns out, you can still leverage virtual memory for this—with a trusted-compiler setup. Just identity map the entire physical memory space in triplicate, one mapping read-write, one mapping read-only, one write-only. (There is no reason not to have a flat memory space.) Converting a pointer between any of these should be as simple as applying an offset; and so though a pointer’s provenance nominally indicates—and dictates—its access limitations, conversion is easy should the need arise.

        Existing operating system come with a hierarchical file system. There are two significant problems, namely hierarchical and file.


        The problem with a file is that it is only a sequence of bytes with no structure

        This is somewhat of a misnomer. A file, in unix parlance, refers to a stream of bytes; which is important because it means it’s nonterminal. Most lisps don’t have a very good representation of lazy or nonterminating streams, which is an omission albeit a small one. (This isn’t a fundamental flaw, of course; languages with laziness built in, like haskell or raku, do just fine on that front.)

        Nowadays, computers have addresses that are 64 bit wide, making it possible to address almost 20 exabytes of data

        Virtual address space is only 48 (or occasionally 57) bits, and physical address space is usually closer to 40.

        1. 1

          Erratum: ‘it’s nonterminal’ should be ‘it can be nonterminal’.

        2. 2

          One thing which TFA doesn’t talk about is networking. IMO, the object model should be network transparent; just as the distinction between primary and secondary memory is abstracted, so too should the distinction between local and remote objects be abstracted.

          1. 4

            This is an RPC fallacy. It doesn’t work.