This is just crazed personal musings, hence the odd subject. Sorry about that. You have been warned.
From time to time, I will look in on gnu.org, to see what might be going on with the hurd project. Interesting that this, the progenitor of Linuces, as it were, has been more than a quarter-century in the making and, as of now, is barely stable, negligibly useful, on the verge of being left behind for dead.
Yet the basic concept seems sound, if one is willing to sacrifice maximum performance for flexibility and security. But the sacrifice has been a painful choice, perhaps leaving contemporary OSes somewhat wanting in these areas for the sake of pleasing/impressing the user.
So, my thought was, what if the hurd project were to place an active object environment at the bedrock, as the primary means of reaching the kernel, as the basic structure of the OS. It seemed to me that some of the limitations of the microkernel (primarily, the cost of daemon IPC and its context switches) might be overcome through the use of an object model along the general lines of Cocoa (meaning as a part of OS architecture, rather than via the compiler, such as with C++).
How, then, does the "math" work out? If objects rely on "opaque references" instead of plain pointers ("opaque" in the sense that the table-lookup scheme is not defined across implementations, possibly even within one implementation), but service methods can operate mostly within the space of a process (perhaps small context adjustments), does it seem likely that the balance might work out in favor of an object-based architecture?
Cocoa is obviously a fairly thin layer on top of Darwin+Carbon, It would be interesting to see how well a system would perform with the paradigm reversed:
I think I will be more careful in future as to when I am eating the sharp cheese.
From time to time, I will look in on gnu.org, to see what might be going on with the hurd project. Interesting that this, the progenitor of Linuces, as it were, has been more than a quarter-century in the making and, as of now, is barely stable, negligibly useful, on the verge of being left behind for dead.
Yet the basic concept seems sound, if one is willing to sacrifice maximum performance for flexibility and security. But the sacrifice has been a painful choice, perhaps leaving contemporary OSes somewhat wanting in these areas for the sake of pleasing/impressing the user.
So, my thought was, what if the hurd project were to place an active object environment at the bedrock, as the primary means of reaching the kernel, as the basic structure of the OS. It seemed to me that some of the limitations of the microkernel (primarily, the cost of daemon IPC and its context switches) might be overcome through the use of an object model along the general lines of Cocoa (meaning as a part of OS architecture, rather than via the compiler, such as with C++).
How, then, does the "math" work out? If objects rely on "opaque references" instead of plain pointers ("opaque" in the sense that the table-lookup scheme is not defined across implementations, possibly even within one implementation), but service methods can operate mostly within the space of a process (perhaps small context adjustments), does it seem likely that the balance might work out in favor of an object-based architecture?
Cocoa is obviously a fairly thin layer on top of Darwin+Carbon, It would be interesting to see how well a system would perform with the paradigm reversed:
- Live, run-time replacement/testing/upgrade of what are now perceived as system-level components.
- Method selectors subjected to privilege testing, selectively (surgical application of security measures).
- Classes offer a potentially lower-impact means of providing services than daemons+IPC.
- Similarly, integration, to construct large, more complex application environments, is supported inherently by the object architecture.
- Sub-classing the basic application object could allow processes to have finer control of things like scheduling and page-outs - meaning much of those functions can also live outside kernel (privileged) space.
- Traditional Unix-style applications could be supported by embedding them in an application object.
I think I will be more careful in future as to when I am eating the sharp cheese.
