Archive for septembre 2006

Independent Website

septembre 11, 2006

Nowadays, web-browsers are commodities. The browser is packaged with the OS and one has some alternative browsers at no charge. It’s hard to sustain a buisness in such condition. Moreover, despite the W3C recommendations, each browser renders a given web-page in its own way, as well as each website don’t treat them equally. Hence, I wonder if there’s still a necessity to render a web page completely by the browser? In the principle of the client/server the browser would just have to make the request, though, what will render the HTML page and so on? Well, since the browser market is no more fruitfull and since the webdesigners can’t satisfy every browsers, the client should come from the website accordingly.

Nothing new here, this the way of the remoted application, though, in my mind that should use the current user’s browser without requiring any further installation. I’m thinking here about 0Install and its way to load an application in the system cache. Same thing here with the use of the browser cache; the browser is just a receptacle for some micro-engines which render the web pages. To get the idea, considers that each HTML tag, each JavaScript function, each embedded object is one of these tiny engines; one can’t do less but one could organize more and that could work asynchronously, like AJAX. Certainly the hardiest task will be to correlate all these engines between them.

Anyway, if that could be achieved the economic would be renewed on the server side. Here again, nothing new in regard to Flash or Shockwave, their economic is based on the developer side, not on the user side. Same thing here, webdesigners could have the tools of their choice, Open source or proprietary, with a better control upon their websites, relatively to the client. In the end, the user won’t have to bother about his browser, excepted for some security issue.

In other words, since there’s nothing to earn anymore in the web-browser buisness, let’s the webdesigners controlling the browser. Sure, as any application, these micro-engines should be developed for the most current platforms, but that is what the Open source community can afford to do. So, it could be good.

Reflecting the principles of the operating system.

septembre 10, 2006

I’ve stressed earlier the frustration to discover that an user interface is dependent on an other one. It was about changing the keyboard layout from the preferences panel, I considered several things but, after some searchs it appears that the X11 config. file has a section devoted to input devices, and yes, it was unchanged and determinant.
At this stage the point is not about interfaces more or less correlated, because the desktop environment stands in the user space while X11, which drives the display, stands in the kernel space and so under the root privilege. That raises the following question: should a GUI hide the principles of an OS or should it reflect theirs ?

I’ve suggested the latter earlier by splitting the GUI accordingly to the multi-users scheme, like this: root | user. Though, the question examines the motivation to provide a graphical environment. It’s nice to have a desktop, but what can be the benefit if it is done despite the principles of the system ? Depending the design of the OS, the development of the environment cannot be the same. More exactly, one can obtain the same results, or acheived the same goals but not through the same ways.

As far as I know, there are not a lot of designs in this matter. By definition, a mono-user system is out of the scope, and there are at least two kind of multi-user system: the macrokernel and the microkernel. Relatively to the user, the former retains almost everything in its space while the latter let almost everything in the user space.

macro-microkernel

In the illustration above, the dotted arrows represent the mediation or the dependency to the kernel space and the size of the block represents its degree as well as the ability allowed to the user.Concerning a macrokernel, shown at the left side, I guess that some solutions exist for a usable mediation between the two spaces, though, the figure simply indicates that a graphical environment for the kernel space should be developed as well. That the case indeed, graphical administrative tools exist, but the main point here is to provide the means to the user when he or she has to cope with the system since it is its design. Concerning a microkernel, figured at the right side, albeit an OS can be really designed like that, most of the time several services are upon the kernel, with their own privilege not granted to the user. Though, these services won’t probably interfer with the needs of the user, more exactly, even if one cannot assume anything about him or her, this probability is lower with a microkernel than a macrokernel. Hence, the need of a GUI related to the administrative tasks is lower, though, that doesn’t prevent to develop it.

I would conclude that the user environment should not cross or pretend to do more than its assigned limit by the system, thus, the point is rather to organize two environments at least than to merge them with some missing mediations. Moreover, there is an objective reason to develope an UI reflecting the system. As far as this latter is a commodity, one can’t assume anything about the user. Since the GUI is the main environment for the user and the most current thing that the user will experiment, his or her understanding of the system as a whole will mostly rely on the GUI because it’s the first information and data that the user has about the system. So, what’s the best? A graphical environment which misleads the user understanding or an environment which provides the right premiss?