https://futureofcoding.org/ logo
Join Slack
Powered by
Design Principles Behind Smalltalk by Ingalls Th...
# thinking-together
s
Design Principles Behind Smalltalk by Ingalls There's a lot of gold in this, including: "An operating system is a collection of things that don't fit into a language. There shouldn't be one." https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html Thanks for the recommendation, @jonathoda
👍 7
j
That’s a great paper that distills the whole ethos of Smalltalk, Scratchpad, and much else that followed. “The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone.” It inspires my own ethos
The purpose of the Subtext project is to provide computer support for doing stupid shit for everyone.
Also see this: “The operating system: should there be one?” https://www.cs.kent.ac.uk/people/staff/srk21/research/papers/kell13operating.pdf
❤️ 3
f
My understanding is the primary function of an operating system is _sharing_: - take something there is physically one of, and multiplex it for parallel usage by many programs, such that the programs are not directly aware of each other - share the programs themselves, by constructing a message protocol there is physically none of, and using it to restore the programs' ability to affect each other in limited well-defined ways (Yes, by that definition the browser is extremely an operating system: perhaps it is better to talk about "operating system layers" vs "application layers", if not necessarily in the http://oberon2005.oberoncore.ru/classics/bh1976b.pdf sense)
Some primitives for sharing are built into the smalltalk runtime, which is fair enough(though makes it awkward to execute non-smalltalk programs in a smalltalk system, to a significantly greater extent than it is to execute non-C programs in a C system) Others described seem underspecified: sure you can have a 
Keyboard
object that represents a keystroke log, but you don't necessarily want a keystroke log, and you definitely don't want every piece of code to implicitly have the capability to read your password. A real operating system usually has the concept of "keyboard focus", even if it's a tty - I believe when I tried pharo the 
Form
and 
Keyboard
objects did collaborate in this manner, and their combined code is something I would describe as an OS layer. It is above the language itself, but below what is normally considered application code, or even the standard library which may be somewhat frequently revised; if you were to try load in two versions of it they would hopefully explicitly conflict, but failing that the results would be unpredictable and almost certainly undesirable. It is of course possible to architect a system where inconveniencing yourself in this manner is easy(load in a third-party program package) vs hard (compile kernel module, sudo, load kernel module) ^-^
On the topic of file systems I do agree with Ingalls completely, file system traversal is a generic API that shouldn't be restricted purely to persistent data on disk - I'm very fond of transparent FUSE browsing of archives/git-repositories/blockchains, /proc, the concept of 9p, etc
d
When I first started playing with personal computers, I understood that the "operating system" was the hardware abstraction layer, distinct from the applications running on top of the operating system. And early operating systems were very small and simple. The definition of O.S. keeps expanding, so now Ubuntu is an operating system, and OpenOffice is part of Ubuntu, so OpenOffice is part of the Ubuntu operating system. It's operating system all the way down. I think that the files in my home directory are still considered distinct from the operating system, but I'm not sure (what about dot files). Given this situation, I think the software revolution requires us to destroy the operating system. If we accept the existing layer structure and APIs of "the operating system" then we have already lost.
❤️ 1
👏 1
💥 1
f
I would not say the ~ current structure ~ of APIs is "the operating system", but stablish APIs of some sort seem desirable and likely necessary. By my personal definitions, a "linux distribution" is a combination of an operating system and things that are known to operate on top of it. In particular the distinction between "bundled on the install disk" and "available through `apt`" seems somewhat overstated, and I'd describe at most the 
ubuntu-minimal
subset to be truly the operating system part: things like 
less
and 
sudo
As for dotfiles, it depends: is there a 
.emacs
? Would removing the 
.emacs
make the system in everyday use noticeably less turing-complete, in a somewhat metaphorical sense?
Similarly, 
~/.config/google-chrome/Default/Cookies
is distinct from an operating system, while 
~/.config/google-chrome/Default/Extensions/cjpalhdlnbpafiamejdnhcphjbkeiagm/1.19.6_0/assets/ublock/filters.txt
can be argued to be part of the foundational collection of software necessary to abstract interaction with modern hardware and software - it's certainly orthogonal to the direct performance of most computing tasks
(to tie this back into sharing, that file is part of a layer facilitating the sharing of bandwith / display / attention between different prospective programs/objects wishing to consume those, so as to render the system operable; in this particular case the layer is a patch("plugin") to the networking standard library as opposed to directly built into the latter, but that's an implementation concern)
s
Another thread had this link which develops a rather interesting concept of 'nexus' https://www.devever.net/~hl/nexuses
some sort of infrastructural system which is consumed by many different applications written by many different people.
3 Views
Open in Slack
PreviousNext
Powered by