Blue Abyss
Blue AbyssA project to discover the minimal specification for any ObjectOrientedOperatingSystem that satisfies all (except the last) OperatingSystemsDesignPrinciples, and then implement that specification.
Conceived as an extremely long-term project, it suffered several setbacks, including AnalysisParalysis, difficulty finding collaborators, and difficulty maintaining interest. It's taken more than 5 years to get close to a spec, the BlueAbyssFramework.
It starts like this:
And so, what is the bare minimum system which could exist which embodies these? By which I mean to ask, how much is the endeavour complicated by functionality? Presumably if a machine only has a single 25 character led display, the GUI level becomes simpler, but in a way which is consistent with the ideals, and therefore scalable once that becomes a priority? -- WilliamUnderwood
Well let's see. You need a RAM component, a scheduler component, and I suppose you could build a text UI process, maybe even build it up to a Smalltalk transcript window.
Wow, that is so not what I had in mind. I am amazed. I am depressed. It's starting to look, to look ... achievable.
It does mean that I don't have to build a GUI for the demo, and it would serve as a SpikeSolution to the language interface problem; if a language module has a link to some object somewhere, where does the link exist?
(What's the name for the phenomenon where something which seems to be an intractable problem requiring outlandish solutions is not a problem at all once you forget about the problem for a long time?) -- RK
I don't know, but I know the feeling :)
On the topic of FutureObjects, I'm having some difficulty tracking down your definition... but is this a correct reference (http://www.merlintec.com/old-self-interest/msg00676.html)? I've implemented a primitive mechanism for this in java making use of the Proxy support, but the support is too static to accomplish many useful tasks. It would seem to be a functional idiom though, and tremendously useful. -- cwillu
Yes, that's it. Jecel's got lots of cool ideas. The best are no doubt stolen, but so are mine. :)
I feel that there is a necessity to be able to work with sets of objects in the same way one can work with individual objects. This would imply that one needs a relational algebra as a requirement, by force of uniformity. For example, I have an object, which can give me a specific object. If I have a collection of the first object, I should be able to get a collection of the objects that each first object can give me... effectively, if we have 'object' with method 'get()', I can select 'get()' from the set 'objectSet' and get the results of 'get()' from each 'object' in 'objectSet'. -- cwillu
You don't need to concern yourself with this at a low level. It's a UserInterface issue, and only a tiny feature of the UI at that.
Argh, I'm gonna give away a secret I hinted at in LanguageIsAnOs.
In the UI, as elsewhere, you're dealing with graphs (DirectedAcyclicGraphs within a component) of objects. The subgraph from any particular object can be represented by that object. If you want to search through a subgraph and collect the results, that just results in a new graph, represented by another top object, linked from either the object you called Find process from, or the Find process itself.
What that means is that if you're in Windows or Unix, the result of the Search / Find function is a new directory object at some point of the filesystem (perhaps in the Find directory, perhaps the Desktop directory, whatever).
And in the UniversalCatalog, whenever you call the Search function to look through Categories to find books according to specific criteria, this search function will just create a new subCategory (private to you) somewhere, probably under the Search Category.
And if you want to keep the initial search criteria around, you just stick them inside a sub-object. I mean, you could even treat a search object as a different class with its own representation / handler. -- RK
Akin to the way that when you do operations on a set of tables, you get a new table with the results of the operations, which would be 'live'. Live in this case meaning that if you update the result, you modify the original tables by implication, and if you update the original tables the result is modified as well. This is actually reasonably straightforward to accomplish (by which I mean, it can be implemented in java with out holes in the abstraction without resorting to writing a Smalltalk or Lisp interpreter). At least this is what I originally had in mind.
The other possibility that comes to mind now that I think about it, is that the result could be 'live', as in independent from the original sources, and therefore would continue to exist even if the original references were destroyed. I can imagine either being useful, but in this context, the former is probably the most appropriate.
-- cwillu
BlueAbyss will have both semantics. If you delete an object (eg. a collection, eg. a search result) from the graph (system), you also recursively delete any object that would end up being disconnected from the rest of the graph. But if you have the power to delete an object, you can also go out of your way to delete the whole subgraph below it. Subgraph being the sticking point. Just because you have a link to an object (eg, it shows up in a search) doesn't mean you have a downwards chain to that object. Just because another user let you search through his UserDomain doesn't mean you get to delete anything outside of yours. -- rk
BlueAbyss reminds me of TedNelson's XanaduProject - a theoretically perfect design that will be all things to all people and solve all the world's problems but which will never actually end up on people's desktops. This isn't necessarily a bad thing if the ideas behind it end up in operating systems designed and (most importantly) built by pragmatists who understand that real tools always trump imaginary tools.
The multiplexer concept
I'm curious how an OS designed around this principle, like BlueAbyss, would represent most actions - for instance comparing two objects, or going in and out of an immersive game. Is there some place this is already outlined?
I think I do deal with graphics some in NewOsFeatures.
Following the ExoKernel principle, there must be a multiplexer at every layer of abstraction. So at the top-level of the graphics stack, where you're dealing with 3D models and spaces, there is a multiplexer that provides a 3D space for every object. (An object is a bunch of functions interpreting some data; a process/daemon interpreting a "file"). Now, if you're multiplexing then that means spaces can be nested (multiplexed further). And that means there must be a general mechanism to inform the user when they've crossed a boundary between spaces. What this means is that a space might be surrounded by a translucent coloured barrier which ripples and opaques when you cross it. This is what BlackAndWhite uses to indicate land ownership. It'd be a good mechanism to indicate user ownership of objects too but it would be difficult to find out who owns any particular object, in general; users won't normally have the privileges necessary to find this out.
With all those multiplexers and abstraction, you must be running on a mighty powerful machine since I guess you plan on actually having a process load and run in your lifetime ...
It need not necessarily be slower then current technology, provided you have a SufficientlySmartCompiler/Optimizer, that optimizes the code for special cases. -- .gz
Since the system is transferring visual control to an untrusted process, this can be abused by the process. A user might see 20 boundary crossings when they've only actually performed one. But that's all right so long as there is a secure way to break out of a space. Something like a SecureAttentionKey? that pops you up one level in the nested spaces. This is easy to provide, and so long as no process can hide space crossings then the system is secure.
[some stuff moved to ObjectBrowser] -- RichardKulisz
Moved from GrossDeficienciesOfUnix:
Am I to understand that you believe the OS (regardless of definition -- let's ignore that for now) and application functionality should represent a programmable continuum, based on common concepts, from lowest level hardware abstraction to the highest level of the HCI, including what we currently call applications, thus rendering moot the distinction between OS and application? And, therefore, it is meaningless to speak of (say) a high level GUI being "part of the OS" or not, as it's all part of the OS, whether actually installed or not, unless specifically designed to not be programmed and/or not partake of the aforementioned common concepts? -- DV
Yes, that's it exactly. You got it completely. And further, what are currently called applications are with very few exceptions just non-programmable systems software created specifically with the malicious intent of monopolizing power / preventing users from reprogramming them or using them in novel, non-approved ways. [...] -- RK
EditText of this page
(last edited December 4, 2008)
or FindPage with title or text search