What if there was only the OS ?
I've been a follower of the
"OS should spawn processes and otherwise get out of the way"
school since I learned what an OS was.. On my first computer, the C64, it was
normal for programs to entirely disable parts of, or the entire operating system.
Side note: I consider Kernal + BASIC to be the OS of the C64, but I digress.
It seems like a beautiful idea, you run your application, that's it.
I've disliked, and to some degree, still dislike the object oriented paradigm,
but not the idea of smalltalk.. Why am I ranting? Struggle on!
The idea that objects can provide some functionality, and provide that to the
system is beautiful.. In a twisted and local way, that's what you get within
a C++ program, and if you stretch your imagination, through dynamic loading of
libraries, but.. Where the world ended up seems to be that we have the SO or DLL
files and we get all the problems, but almost none of the benefits..
One benefit that I can think of is a niche, overriding DLLs and SOs to provide
updated functionality, for example, on my Windows 10 machine, when I want to
play a game that has 3dfx vooodoo glide support, I usually use that, but I replace
the glide2x.dll with a new version from the nGlide project, which translates the
glide api into a modern API and also gives me control over resolution and stuff
that the original program does not know anythig about..
My point is, such things are nice to be able to do, check my site, I have
a hook object that can be preloaded in front of Soldier of Fortune on Linux,
which modifies a datastructure in the graphics engine to let you set your own
screen resolution instead of having to accept the ones hard-coded into the game.
But these are niche uses, and very much confined to a realtively small percentage
of the general PC using population.
I think part of why we're missing out on the benefits of "smalltalkish" forms
of code-sharing is because the operating systems are doing almost nothing to
encourage it.. It's almost as if there's a divide between libraries and programs..
Like, they'er so different, a program will use libraries, but libraries rarely
use programs.. Programs usually provide functionality directly to the user, while
libraries provide functionality only directly to programs. (Unix pipes is the
exception, and my idea borrows a bit from that idea, but they're not where I want
to end up at all).
What if we turned everything upside down.. What if there was ONLY the SYSTEM..
And everything was a plugin, literally, everything.. Your drivers, your web browsers
your libraries, your shells and GUI and games.. All of it, plugins to the SYSTEM..
What does that even mean?
I imagine the SYSTEM is bundled with some standard package of plugins for various
things like some drivers and providers for things like TCP/IP and maybe some other
protocols, maybe some encryption stuff like TLS and whatnot.. Some plugin to
allow windows to be created and populated with widgets and drawable surfaces, and
of course some standard set of widgets..
If one were to create a webbrowser for such a system.. One approach would be to
make a single plugin which provides an enduser activity "browse the web", it might
make use of the TCP socket functionality provided by the OS and that's about it.
It might go a step further and make use of the DNS functioality too..
It'd do that by requesting a DNS provider, basically telling the SYSTEM
"I'm providing 'user activity / internet / HTTP browsing' under the name
'Mazolla Wetdog' and I need 'DNS resolution' and 'TCP sockets' to do it"
furthermore, it might suggest the OS a particular plugin, like
"system standard DNS resolver".. Internally, the browser plugin would still need
to implement HTTP protocol details, TLS wrapping for HTTPS and whatever else is
needed..
Assuming the SYSTEM came with TLS stuff, the browser could ask for those..
Even nicer was if the browser package has some nice TLS implementation which
it provides as a plugin.. Then it can hint to the system, "I have a TLS implementation
and I need a TLS implementation", a reasonable behaviour would then be for the system
to link provide that particular TLS plugin to the browser activity when it's started.
Why does this matter?
It's a weak point, and a silly example, I'll rant on to a better one later..
But let's say you have an even better, or more trusted TLS implementation,
imagine if your "browse the internet" activity was little more than a description
of which functionalities to wire together to get a browser.. Then you'd just
clone the activity, and, from the system gui, simply tell the system
to provide your alternative tls implementation to the browser.. A bit like
replacing a DLL, but without it being hackish and a "special thing"..
A bit further, a browser may consist of "a window that can render a website" and
"a website provider" which then again is made up of several subelements..
What if every buffer in my text-editor registered "I am a source of text,
and I am a target of text".. When I open a file, I can chose a file-system
plugin to provide the text to the buffer, but I could also use the HTTPS provider
if I just wanted the source-code of some website directly into my buffer..
So, I'm a simp, and I chose to open a text-editor buffer with a file as a data source..
Now, my buffer is also a data source, so I can open an instance of my web-browser
and instead of the website-provider being the HTTP backed one, link the browsers
text-input to my text-editor buffers output, boom, whatever is in my text-editor buffer
is instantly rendered in the web-browser, actually, I don't need a web-browser..
I could just spawn the HTML rendering engine and link that to my text-editors buffer.
Imagine how radically different it'd be to use a computer if we had a lot of nice
software packages, but they were all these pre-built lego-sets that we could
easily rearrange and remix and combine across each-other, taking some
functionality from your 3D editor and embed it into your spreadsheet for data
visualization.. Whatever applications provide the right stuff.. Maybe one of your
graphics packages has a really nice filter effect, but you want to apply it
to the output of another program ? I don't think I can imagine it entirely..
It's so far from how we're used to thinking about computers, and I'm sure there is
a lot of technical challenges (data exchange formats for instance) but I don't think
they're impossible to fix.. Something like being able to declare which outputs you
provide precisely, and exactly how you expect data you consume to look, and which
fields are optional and which are required, and providing the user some means of
resolving conflicts.. This rants me on the next benefit: forcing apis and formats
to be well-thought out and as simple as they can be, when you're not only
designing for the machine, but for the end-user, you can't just put flags all over the
place, you can't just send messages that are needed for some internal state, you
have to really think "How do I make this API end-user understandable and friendly"
and if you can't do that, you're at the wrong abstraction layer anyway. Go one up
or one down and try again.
