I wish we had a popular operating system for end users like ourselves that was “live” all the way down.
It’s unfortunate we’ve been stuck with Windows, Mac, and Linux only
back
5 comments
I have the same dream. A part of me wishes Richard Stallman set out on making a Lisp OS instead of making a Unix clone, but this was the mid-1980s and thus I understand the technical limitations and the social environment of the time. The 1990s could’ve been a better time; workstations and commodity PCs were powerful enough to run an entire Lisp or Smalltalk operating system, and there would’ve been substantial interest in such a system. Imagine had we ended up with a free, open source Lisp or Smalltalk OS running on the Pentium and PowerPC machines of the era as an alternative to Linux and the BSDs. I think this would’ve been an easier foundation to develop a FOSS desktop instead of the X11/KDE/GNOME/Wayland situation we have today.
But the dream isn’t dead. If only I had more free time…
The dream isn't dead, a number of people are working on it.
Several live systems are demonstrated in talks on Youtube.
There are several working systems and even a real OS with native device drivers on modern bare hardware.
You can run legacy code under its qemu sandbox, but that is added only to broaden its appeal to customers as this part is not 'live'.
Sadly the work from the STEPS project seems to have disappeared, especially the Frank software he used in some talks. That looks like it would have been very interesting to play with.
I have most of the Frank/STEPS code still running. I posted a lot about it before on HN.
Yes, its a lot of fun to play with it, I invite people to join in the fun. 20.000 Lines of code for almost all of personal computing.
Thanks, do you have any of it publicly available or would you prefer an email?
Not all is publicly available and most needs recompiling and explanation.
I prefer email.
The email address in your profile is bouncing:
[email redacted]
host mx02.mail.icloud.com [17.42.251.62]
SMTP error from remote mail server after pipelined end of data:
554 5.7.1 [CS01] Message rejected due to local policy. Please visit https://support.apple.com/en-us/HT204137> Sadly the work from the STEPS project seems to have disappeared
Unfortunately that phrase -- steps project -- is effectively un-Googleable.
Do you have a link at all please?
search/google "steps alan kay" or watch https://www.heidelberg-laureate-forum.org/video/lecture-putt...
Apply to YC for fun and see if they'll fund you. It's a long shot due to the non-commercial nature. But who knows? If you do, include me in it. I'm not the best OS dev, but I do know Pharo. I'm up for making a YC application if you are! ;-)
My email is in my profile if you'd want to entertain this idea.
> A part of me wishes Richard Stallman set out on making a Lisp OS instead of making a Unix clone
Oh so very much so, yes!
I worked at Interval Research (yet another Palo Alto lab) in the mid/late 90s on a large project (and if it had completed and worked out, would have led to a proper IoT without the crap, maybe) in which we use Smalltalk all the way down to the custom hardware. A few hundred lines of C and assembler tucked away in a corner, but interrupts and processes were all handled in Smalltalk.
It was fun. It could have been great.
Although impolite to ask, do you feel that it not working out may have been influenced by the implementation language?
People are different, that is why flame wars like Emacs vs. Vi still exists. It is incredible that we tend to assume that there ahould be just one technical response to problems.
One could repurpose Pharo for this, I think. I'm not entirely sure how the environment would be an "at the OS level thing" but it should be doable to have a basic OS that basically boots a Pharo environment and then that's your OS.
Live in what sense?
To me Emacs fits the bill, or at least a subset thereof.
With a live programming model: https://en.wikipedia.org/wiki/Live_coding
Pharo (a Smalltalk), is listed in that article as an example of a live programming environment.
Alan Kay is one of the designers of SmallTalk.
Yeah I like Pharo
It would be cool to be able to just click on anything and adjust its code to however you like it. I guess that Smalltalk and its descendants allow this. But so does Emacs. It's not an operating system, but it covers a lot of the use-cases.
You would need live routing of messages. And the ability to reroute, filter, inject messages dynamically into code.
Why must everything be done as a function call? You can’t change anything without recompiling the code.
Today everything is implemented as a function call. Need to send a message? Call a function named “snd_msg” or something.
> Why must everything be done as a function call? You can’t change anything without recompiling the code.
Emacs Lisp supports dynamic binding, so you can dynamically rebind function definitions at runtime.
It's curious how the original 1981 paper [1] on TECO Emacs, written before I was born, describes many qualities I recognize in the ELisp Emacs I grew up on.
Emacs "happens" to be open source ;-), but the paper stresses how the system & language were designed to allow users to mold it at run time without the barrier of recompiling from source, and how empowering users led to better features than "careful design" could have achieved. Selected points I found notable:
- awareness that "An EMACS system actually implements two different languages, the editing language and the programming language". - Editing Language is tweakable (again at run time) by re-binding keys to macros / existing commands / custom commands. This gives agency to users with less programming skill! - Language separation being necessary so that tweaking Editing Language can't break Programming code. - Key bindings are shallow "keyboard sugar" over the concepts of Programming Language. Commands are (almost) regular functions. User can invoke any command by name, bypassing the sugar. - Buffer-local & mode-local bindings. - Commands (and generally as much of the system as possible) implemented in Programming Language which was chosen to be interpreted not compiled, so that users can redefine at run-time and experiment. - "The only way to implement an extensible system using an unsuitable language, is to write an interpreter for a suitable language and then use that one" :-D - "variable [and function] names are retained at run time; they are not lost in compilation"
- Commands are extensively parametrized by variables. User can achieve quite a lot by simply setting [global] variables. - Dynamic not lexical scoping deliberately choosen to make code less encapsulated and more reusable with tweaks. See paper why lexical is worse for dynamic - Unique concept of File/buffer-local variables! Again, if programmer went to the trouble of parametrizing code, maximize the payoff. - Commands and especially compiled code extensively parameterized by calling "Hooks" at interesting points. "These hooks can be thought of as compensating for the fact that some parts of the system are written in assembler language and cannot simply be redefined by the user." <<-- I found this especially thoughtful
- Social dynamics like "library system" for loading extensions written by others. Well, ater Emacs actually lagged behind for decades in ease of obtaining 3rd-party libraries. "too cathedral, not enough bazaar..." Much better now with MELPA, still not as smooth as say VSCode extensions. But I feel a trade-off — VSCode extensions are more "opaque".
yeah, that's one of the main things people like about emacs