Hello all,
The following writing is my attempt to suggest a real-world application for Genode that "philosophically" gives more "responsibility" to the OS/framework at the expense of application-dominance.
Starting in the late-90s, I felt that the OS should be closer to the applications (such as web-, data-, and logic-servers in opposition to the movement, which was to disassociate applications from OSs). My job was maintaining both OSs and applications (as an administrator) and I saw efficiency by blurring the differences between them.
My OS model (called the Thinman) was a single OS/application that would have libraries/modules that would be "called upon" and brought to windows on the desktop that had "browsed" for material such as pictures and edited the material using tools (libraries and modules). Of course, new material could be initiated with the "New" button.
More recently, I have personally concluded that the SVG, or Scalable Vector Graphics page, should be at the heart of the future Web, and the WC3 seems to agree by proscribing full HTML capability within SVG pages. Thus, nearly anyone can easily make an exceedingly attractive page (far more so than FaceBook or Google+), and then paste in the written material as basic html text.
Given this, I tend to use Inkscape (IS) SVG editor a lot. Previously, I used GIMP, but GIMP is an image editor, not a page editor. So, today, I use both, primarily to cover IS's weaknesses in graphics manipulation. As you might predict, the interrelation between the two systems is awkward. You can "cut" from GIMP using the mouse or "ctl" key combinations, and "paste" to IS, and the pasted image can be manipulated, but cannot be saved as an SVG page. (I use snipping tool to make web images).
In light of my "native" OS beliefs, I "fantasized" a solution that has an OS-based graphic image editor that I call Object Manipulator (OM). OM takes the input stream from the mouse (or ctl-keys), creates from it an object, and then applies the libraries of tools and filters from GIMP (and other sources) directly to the object, including all the cutting/selecting tools. The image, when fully altered, is then selected and "pasted" back into IS, or other format-specific editor, to be made into a presentable product.
Given this model, there is no reason the "pasted" object has to be a graphic; it could be a poem, and the libraries brought to it might include a thesaurus. Thus, OM has no specific purpose, except to bring together objects and libraries (which are technically also objects, but that is a different discussion).
OM has no connection to "reality" as its space is "an abstraction." It only works in the context of the OS and has the desktop as its "background" in ways no different than a repairman's bench-top is the "background" for fixing/developing some device such as an appliance. It does not even intend to use the filesystem to communicate with applications (though of course it can by converting to established file formats or by creating a native one).
The object might not even need a background, or even an application called OM to call it; it may be defined in of itself as a selected object, perhaps defined in the context of, or possessed by, the mouse.
I am hoping that this tangible example (that I emulate using IS and GIMP) can help provide a real-world basis, or context, for the Object OS layer that you are attempting with Genode. Implementing this idea involves subtle philosophic/holistic issues that are at the heart of an "agnostic" OS framework; that is to say that given circumstances either technical or political, a kernel can be switched out at the bottom, or, likewise, and object manipulator can be switched out. This suggests that the OS framework must be impartial and democratic --a sort of United Nations of OSs and desktops.
I hope that this writing is comprehensible, and I will continue to attempt to simplify it especially for a wider audience.
Regards, John
Hello John,
thank you for posting your ideas.
From what I understand, you would like to use a data-centric user
interface instead of the application-centric model, which is omnipresent today. I can only agree with that. Instead of big applications that import and export data, it would be much nicer to have data objects as first-level citizens of the OS. Small and independent programs could then manipulate, display, and transform those data objects. The power of the system comes with infinite ways of how those components can be combined.
Actually, this is almost what the Unix command-line interface is all about, and possibly the reason of why I am so much in love with it. Data (in the form of files) comes first and the many little Unix tools can be combined to manipulate it. The great thing about Unix is that it provides a useful user interface (the shell, pipes, scripts) that brings this idea to life.
Now, what you seem to suggest is to take the data-centric approach to the domain of interactive graphical applications. I think that Genode would provide a good playground for developing these kind of concepts because it already solves the problem of how multiple components can interact with each other in a useful and secure way. However, in my opinion, it does not solve the biggest challenge, which is the model of user interaction with such a system. How does a "desktop" of such a system look like, how does the user interact with the components, how to chain components, how to make data persistent, how to find data? If you have ideas about how to approach those questions, I would like to encourage you to substantiate your ideas using Genode as a tool. If I can assist you with matching your ideas with Genode's concepts, I'd be happy to help.
When it comes to Genode's road map for this year, I would like to keep the project focused on down-to-earth goals that are reachable in this time frame. Do you see technical steps that would help you to pursue your vision and that you would like to see as part of the road map?
Cheers Norman
I just want to acknowledge receiving your feedback, and mention how good it feels to hear someone else say "datacentric." I will take some time to comprehend your email.
Thanks again, John
On Thu, Jan 10, 2013 at 3:17 PM, Norman Feske <norman.feske@...1...>wrote:
Hello John,
thank you for posting your ideas.
From what I understand, you would like to use a data-centric user
interface instead of the application-centric model, which is omnipresent today. I can only agree with that. Instead of big applications that import and export data, it would be much nicer to have data objects as first-level citizens of the OS. Small and independent programs could then manipulate, display, and transform those data objects. The power of the system comes with infinite ways of how those components can be combined.
Actually, this is almost what the Unix command-line interface is all about, and possibly the reason of why I am so much in love with it. Data (in the form of files) comes first and the many little Unix tools can be combined to manipulate it. The great thing about Unix is that it provides a useful user interface (the shell, pipes, scripts) that brings this idea to life.
Now, what you seem to suggest is to take the data-centric approach to the domain of interactive graphical applications. I think that Genode would provide a good playground for developing these kind of concepts because it already solves the problem of how multiple components can interact with each other in a useful and secure way. However, in my opinion, it does not solve the biggest challenge, which is the model of user interaction with such a system. How does a "desktop" of such a system look like, how does the user interact with the components, how to chain components, how to make data persistent, how to find data? If you have ideas about how to approach those questions, I would like to encourage you to substantiate your ideas using Genode as a tool. If I can assist you with matching your ideas with Genode's concepts, I'd be happy to help.
When it comes to Genode's road map for this year, I would like to keep the project focused on down-to-earth goals that are reachable in this time frame. Do you see technical steps that would help you to pursue your vision and that you would like to see as part of the road map?
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Norman,
My break-down of your writing is that the biggest challenge for the user-model is to structure a
1) user-relationship via the 2) desktop to a 3) chain of interacting components with regard to data 4) persistence and 5) access
I describe this "chain of interaction" as "complexity," but complex data is usually described as "dictionaries" --showing low comprehension of it. Shell, in particular "comprehended" complexity so effectively with its file-objects that I think we fell into a homeostasis while we should have been extending it to create its own objects. Thus, we would have currently-valid interaction with the OS. An OO shell extension might include the "arrow" operator to define, or link, interaction between desktop objects.
I am attempting to create a summary of L4/Genode material including Drops and its OS kit components, the driver synthesis concept, and your alternative microkernels (such as Xen) to create SVG charting material. I have seen Lua used in L4 boot, so that should go in the summary as well.
Preserving the GNU/Unix gcc structure makes sense through "eating your own dog food" it provides an easy entry point for younger free/software programmers. Because these young programmers probably have limited resources, the computer running Genode (such as a flashed Android device) might be their only one, so allowing them to use this device for development reinforces "eating your own," well, vegetables. As an early administrator, I recall that Shell's and GNU's simplicity as its asset allowing for easy inquiry into efficiency, practicality (usability), and security. It was easy to make a good living when Shell was king from 1990-2000.
Regards, John