You and Liam are on the same page. According to the transcript of his presentation:
Windows NT is just a second cousin to Unix: instead of a Unix-like design, it’s a DEC VAX/VMS-like design, implemented in Unix languages with Unix tools. Its design just accepts that what’s inside files may have complex structure.
We both agree with the thrust of what the author says concerning “technical debt” of today’s main operating systems. Returning to a post above:
I am assuming you refer to Genode amongst others. I’m surprised the author did not consider that as a possible foundation for his new Lisp / Smalltalk environment (he has certainly mentioned it in his previous writings), but perhaps it would not fit in with his narrative of reviving old technologies for the future?
Genode is a hypervisor, not an OS. It’s a framework for running multiple operating systems isolated from each other which in turn can run applications that are in that way isolated.
In contrast plan9 uses namespaces which create custom view of the OS resources for each application, albeit it does not work as isolation because the application itself can change that view.
On many modern microkernel OSes each application does implicitly have own view of the OS because it has its own set of access permissions, and it cannot see what it is not permitted to. Thus the application is by default isolated, and it’s safe to run untrusted code so long as the OS permission mechanism is considered robust.
The trick how they do this is rather simple and revolutionary at the same time.
You can view the permissions in a system as a huge table that has rows and column with actors and objects that can be acted on, each cell a bit that says if the access is permitted or not. This table does not exist on the system. The UNIX way is to slice the table into columns, and store one slice on each object that lists the actors that can access it, an ACL. The other way is to slice the table into rows, and store on each actor the list of objects it can access, a list of capabilities. The latter makes it much easier to manage permissions dynamically. When a process is created capabilities are assigned to it according to the task it’s expected to perform, and when it finishes the permissions are cleaned up with the process. Imagine doing that with ACLs.
There is another difference, though. Most capability systems support delegation - that is passing on the capability to another actor. That’s a mechanism how to assign capabilities to a process when it’s created, after all.
That is capabilities are like keys: you can pass your car key to somebody else, and they can unlock your car then. ACLs are like biometric authentication: you have to go in person, or enroll your deputy with the lock if you want to have something done you your behalf. Apparently the UNIX way of thinking is so entrenched that there are people trying to sell biometric authentication pretending it’s a good thing.
I have very little direct experience with Lisp. There is the thing that feature-wise it is not very appealing. It did get some things right, and other things quite horribly wrong.
Just like JavaScript with upfront type checks is no longer JavaScript but it’s a different language TypeScript Lisp with the shortcomings addressed cannot be called Lisp any longer.
I think it’s educational to look at Lisp and Lisp machine, and learn from the past but it’s pointless to re-create it. Today we have access to results of followup research and usage experience that the designers of Lisp did not so we can have a better language than that.
Please, before you hold forth any further, work with one or more of the branches of that family. Get some actual practical experience, and dispel your confusion and myriad misapprehensions. Then get into it in a more appropriate forum, such as the #commonlisp IRC channel on libera.chat, because I’m pretty sure this isn’t the place. That said, if a mod sets me straight on this point, I’ll stand corrected and we can carry on.
Lastly, however much you might dislike something, leave other people their joy. Let them explore what they find interesting, and allow that they might find something you didn’t.
I understand the appeal and joy of, say, restoring a century old automobile or a steam powered locomotive.
However, no veteran vehicle enthusiast requires you to restore and ride one for them to understand that what they do is restoring a living fossil as a hobby, and not something generally useful.
Please understand that restoring living fossils and putting them in motion is a joy for people who choose to do so but is not something that should be posed as an endeavor of general utility.
There is another possibility (building on the original talk that inspired this post), which is Dale Schumacher’s uFork project. It is a description of a hardware level actor system.You can read his justification for the project here.
I bring up this project for several reasons. First, the idea of Actor based systems (in the Carl Hewitt sense) came directly out of his observations of Smalltalk early on, as far as I’m aware. Second, the Actor idea was so tantalizing at the time, that some professors at MIT wanted to create a language in which to explore the concepts – this became Scheme, one of the lisp families. Third, Schumacher is already at work on an FPGA implementation of this system, which means it might be within the realm of possibility to integrate this work into real hardware, on a real system that a lot of us already have (ahem ahem).