Rethinking The Desktop Model

Tue, 02 Sep 2008 22:21:28 GMT
by pdp

It is time to rethink the way the desktop works. Some of my ideas may seem radical but sometimes evolution is the only solution to all of our problems.

I have had this idea for quite some time now. Picture the following: a stripped-down Linux kernel with all security mechanisms to the max; levels 2 to 5 configured to run just the most basic set of services such the scheduler, the hardware abstraction and support mechanisms, printing etc., a web server, a browser and the x environment. The low level processes keep the system running while the x, the browser and the web server provide the application layer functionality.

Each application is hosted on the web server. Technically speaking we have an application server. The browser provides the rendering engine, while the x puts everything on the display. No compilation. Everything is interpreted and under the strict control of the browser and the web server.

The browser is not just the typical browser you will find. Each application opens in its own browser process. It renders just like any other application you may have on your desktop. The only difference is that applications in this environment are written on top of standard, widely-adopted technologies. No dependencies and no cross-platform issues. Applications are easy to patch, extend and control.

The web server is just like any other web server. A module for more granular user control will be required, i.e. different applications will be able to run with different privileges and users should be able to identify themselves without the need to login, etc. Of course, this is only needed if such features are required.

I think that this type of environment will provide more granular control over each application. For example, if an application misbehaves then we can either fix the code on the fly or patch it on the web server with a config hack. We've got the technology even to jail the app in a chroot environment. Fixes can be easily implemented at any stage. Because we are using standard technologies, fixes will be easier and more robust. The browser also provides functionality to extend its chrome via extensions. Developers can implement a layer on the top of the application layer to provide even greater control, customization and interactivity.

Obviously, because everything becomes a web application, for security reasons, the browser should differentiate between local and remote applications but at the same time make sure that both types are as transparent to the user as possible.

This model is far from being perfect. In fact, it has many flaws. I know that there are even some failed attempts to do something almost similar. However, this model seems so right. It is 2008 and we are still stuck with technologies designed 20 years ago. No wonder why they often break. Perhaps their time has come to an end? I don't know. Let the crowd decide.

My philosophy is: whatever works will be employed to complete the given task. But sometimes I think what it would have been if things were otherwise.

Archived Comments

Sam AldisSam Aldis
I have been thinking about this for a long time, Have tryed to come up with a windows version in VB.net but thought that starting with a basic linux package would probably be better. with VB.net these web applications can then have transparant backgrounds or a developer could extend the applications with plugins on a per-application basis. I think it is very important to create some sort of "web-desktop" with a good (web)application launcher.
paramparam
You do realize that X is way too bloated to make your lean mean setup credible, right?
pdppdp
perhaps. i am sure that you will find more problems with it. i am merely suggesting something that may work.
Andrew ShirleyAndrew Shirley
One of the main reasons apps are written for the web is that it aids distribution massively. You have no install issues for users and, more importantly, large organisations don't end up running "GMail 1995" as the currently do "Office '95". This seems to make deploying local apps from a webserver pointless. It does however have one advantage, You can deploy the same code on your servers as you do on (maybe the more advanced) clients computers. I have always thought that going away from javascript webapps and towards Java webstart would be the best way to achieve simple webapp style deployment for richer local applications. Webstart (assuming you distribute the source of your app) also has the shared codebase advantage as a more advanced user could download the code (possibly modifying it) and deploy it locally without having to rely on your webserver. NB. webstart also has the advantage that once an app is downloaded the first time, it will run offline (although it won't updating itself). The missing link here is accessing remote data offline, google gears style.
robertrobert
there is such a beast. gOS.
favertamafavertama
have you tried http://g.ho.st/ WebOS?
Rodrigo SalvalagioRodrigo Salvalagio
Using granularity: We can use a boot circuit to always get the most recent kernel and browser from a master server. And could use separate boot images for different areas inside a company. Saying that, an administrator can patch once and play a lot.
duidduid
How will this improve security? 1) The apps need to access user data. X11 apps run as user context. They can do whatever they like and will not be able to read data of other user. Your web site program can read data of other users have to check permissions for themself. The smallest security bug can mean a disaster. 2) The performance of dynamic web sites is very low and the latency is very high compared to X11 programs. You have very limited possibilities on what you can display. Complex layouts are even slower and destroyed very quickly if the user changes the font size in his browser. 3) Programs often need access to special hardware: sound, 3d graphics, joystick, camera and a lot more. You have to program an abstraction layer for all of these. (You do not seriously want to use flash, do you?) 4) All cross-side scripting bugs which I have seen so far are caused by doing things in your browser which should rather be done by a client application. You can do email, banking, ... in a client. I think blogs, boards, ... should rather be done by a client (there are protocols like nntp which would be nice to see revised). Wikis should be a program on their own. Nothing should send any more data to an http server than asking about the content the user wants to see. 5) There is no such thing as "operating system independance" programs. There are just (1) programs which run on one platform, (2) programs which have been ported, (3) programs which do not use any advanced operating system features and (4) programs, which have their own slow+buggy implementation of nearly everything the operating system would have done for them. When have you seen e.g. the last java program which can be configured via ~/.Xressources, sends mails by invoking the "sendmail" binary or changes the language based on the "locales" configuration? 6) I think this web-hype is mostly caused by 2 reasons: (1) ad income, (2) income by selling user data (nobody knows what is going on). I consider none of these things to be good for any user.
pdppdp
duid, all valid points. but you have to admit that we simply wont know whether it is more secure or less secure unless we try it. imho, it will be a much better, streamlined approach to technology and it will definitely improve the security along the way. but this is my opinion only. however, if you look around, you will see that everything becomes web-enabled nowadays. perhaps, even more people think like me.
JasonDJasonD
Isn't this what Google are effectively trying to push out with Chrome? Chrome is the browser and Google gears (a prerequisite for Chrome) is essentially a web browser that proxies and serves content up
FilipMFilipM
I follow JasonD. Slowly all the pieces from the Google puzzle come together. Chrome is just the next step for the bigger Google plan: Beeing the new Microsoft...