6 ms·

Summary: - We don't need separate processes if the language we use is inherently safe (e.g., modern Common Lisp). - Without process isolation, it is possible

• varjag 7y ago
  Should mention that Mezzano OS satisfies most of these design points and already runs. https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano
  • mark_l_watson 7y ago
    I wanted to also mention Mezzano - really easy to play with using VirtualBox. A bit off topic, but when I miss the environment of the Xerox 1108 Lisp Machine that I had from 1982 to about 1987, I find the closest thing today that offers a similar experience is Pharo Smalltalk.
    • 0x445442 7y ago
      I've had some user interface ideas I've wanted to explore floating around in my head for more than a decade. I' m now in a position to start exploring these ideas and after an extensive survey I decided to use Squeak. The deeper I get into this system the more appreciation I gain for the entire model.
      • gambler 7y ago
        Be sure to check out Cuis and Pharo as well.
        • 0x445442 7y ago
          I like Pharo but Morphic seems to be much more front and center in Squeak. And becuase I'm focusing on are new UI paradigms the Morphic interaction is really what I'm concerned with.
• scroot 7y ago
  Dan Ingalls wrote similarly in his Design Principles Behind Smalltalk [1], noting that "An operating system is a collection of things that don't fit into a language. There shouldn't be one." [1] https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
  • all2 7y ago
    That makes me reconsider the Plan9 OS, where everything is a file system. Then, nothing fits in the language (C)?
    • dullgiulio 7y ago
      Well, the extremely generic interface of Plan9 (plaintext files) can make you use any language. It is the extreme difference with a OS which is in itself one language.
    • gambler 7y ago
      Making everything a file is one way to give all components a universal interface. It's not the only possible or even the best way. The problem is that today there are no universal interfaces at all, so even a file-based one seems immensely powerful by comparison.
      • auvrw 7y ago
        yes, files in plan 9 can be viewed as a way to "make objects look like files." http://doc.cat-v.org/plan_9/4th_edition/papers/names http://doc.cat-v.org/plan_9/4th_edition/papers/names note that the filesystem interface isn't totally durable across all operations: a syscall is still necessary to create processes, for instance. cp /proc/... doesn't do what one might think it does. http://doc.cat-v.org/plan_9/4th_edition/papers/9 http://doc.cat-v.org/plan_9/4th_edition/papers/9 i appreciate that the original article similarly acknowledges that lisp is an "all the things (except for some things)" solution in the Single address space section. synchronization libraries (and perhaps other libs as well?) in C-based OSs need to drop into assembly to get at test-and-set kinds of operations. addressing these special cases one-by-one is something that'll need to be ramified in source in order to get any real insight, although (perhaps just from the inertia of familiarizing with the original bell labs warp) it's difficult to imagine the kernel as a "all the things, seriously everything" abstraction away from the machine. ---- overall, the original article and discussion here was a bright spot in my day. it gives me hope that there's some actual thought and discussion about how to evolve operating systems intended for commodity hardware, not just generalized, "yea, that's something we could do," one-offs. i'm not as familiar with the xerox heritage mentioned elsewhere in the comments, and the view that, in some sense, linguistic abstraction might cover OSs is something to think about. i've heard the smalltalkers catch some flak about not actually writing an os because there was (apparently) the equivalent of exec(), no fork() http://bitsavers.org/pdf/xerox/alto/memos_1975/Alto_Operating_System_Reference_Manual_Jun75.pdf http://bitsavers.org/pdf/xerox/alto/memos_1975/Alto_Operatin... this criticism of the alto OS could be due to cognitive bias as much as anything else. the concept of processes is by now deeply ingrained in the way we conceptualize operating systems. so i have to ask: is leading with eschewing processes a clean-sheet rethink, informed by history's mistakes as well as its successes, or is limiting the number of OS primitives at the expense of less-rich interfaces actually a desirable tradeoff? like, although everything i've heard about multics in particular seems well thought-out, thomson and ritchie were doing something substantially different by opting for bytestreams as much of the interface rather than making strict decisions about arities and so on. every rule system makes is bound to be a rule a user will eventually want to break. i suppose the operating system's main job is to safely lift off of the hardware, not to impose further unnecessary artifice (of which hierarchical file systems AKA namespaces could be viewed as one) on the user. adding further icing onto this core objective is so much the better, so long as it's possible to scrape away and redecorate.
• 0xcde4c3db 7y ago
  > Not having a file system raises the question of what data should be persistent and what shouldn't. But on a modern computer, it is feasible to just treat all data as persistent (maybe excluding the youngest GC generation). I'd be concerned about the UX issue of ephemeral vs. permanent changes here. I doubt that files and save/revert operations are the best we can do, but I think there's a lot of value in the fact that some pattern for it exists that's common to most applications. Perhaps this has already been tackled in some system that doesn't natively use the concept of disk files. It could be as simple as having a pattern to assign names to persistent copies of objects, or something more sophisticated like assigning names to points in an undo tree that are then transparently converted into self-contained objects when the tree is pruned.
  • twic 7y ago
    If you squint a bit, the web is a bit like a giant multi-user operating system. We certainly save a lot of data in it, and expect it to persist. But we don't generally do that using a file metaphor, and i don't hear people crying out for one. My comments on HN don't look like files to me. Nor do my tasting notes on Untappd, my shitposts on various Slacks, my projects on GitHub (which contain files, but aren't files themselves), etc. So we already have an existence proof for an operating system without files. Now, whether the web would be better if everything was more file-like is an open question. That would be very interesting, and probably closer to the Nelsonian ideal.
    • krapp 7y ago
      Except, everything you mentioned are still one or multiple files sitting on a remote server. That it isn't necessarily presented as such through a particular web app's interface isn't relevant... under the hood, it's still just files on an operating system designed around that concept. Even data in a database is also data in a database file. I mean, there's a reason URLs look like directory paths... that's what they were originally meant to be, remote paths to files.
      • twic 7y ago
• magicalhippo 7y ago
  > We don't need separate processes if the language we use is inherently safe (e.g., modern Common Lisp). I note the year of the article, which was before Spectre and friends showed that this is not a reasonable assumption these days[1]. So does this mean LispOS is doomed? [1]: https://arxiv.org/abs/1902.05178 https://arxiv.org/abs/1902.05178
  • rjsw 7y ago
    If you have a single address space you don't need Spectre to be able to discover any aspect of the running system.
    • magicalhippo 7y ago
      How would you then circumvent the protection?
    • admax88q 7y ago
      Only if you're given raw memory access, which you are not in Lisp.
      • rjsw 7y ago
        You were given raw memory access on historical Lisp Machines.
      • sametmax 7y ago
        Without raw memory access, good luck supporting anything than basic hardware. Even some USB features requires it.
        • msla 7y ago
          It's entirely possible to write a system where application code only gets sanitized handles and OS code inside the implementation gets raw memory pointers at least some of the time. All running in one address space doesn't mean all running in one security context, necessarily. Really, address spaces are just a hardware implementation of a more general concept: Namespace-based security. Application code wouldn't even be able to know the names of privileged objects, and if someone told that code the right names, it wouldn't be able to use them, because resolution of names to things is, itself, privileged. In a simple example, assuming a Common Lisp-like system: Everything which handles raw pointers is in the SYSTEM package. Application code can't inspect the SYSTEM package, and, even if you told an application that the function SYSTEM:WRITE-DATA-TO-DISK was a thing, it couldn't call that function because the real evaluation code, which can see into the SYSTEM namespace, knows not to let application code call anything in SYSTEM; only the functions in SYSTEM and SYSCALL can do that.
• macmac 7y ago
  "inherently safe" - for which definition of "safe"?
• sametmax 7y ago
  The problem with the safety requirement, is that it's not just a language thing. It's also an architecture thing. We created sandboxes for a reason.