Article:
  Rethinking the Linux Distribution
Subject:   requirements first
Date:   2007-05-14 05:20:32
From:   Kuros
I think a Linux rethink is a fantastic idea. I think a lot of developers and users have at one time or the other thought about this and if there is a realistic and fruitful approach, a project such as this will attract the necessary man power. Here are my initial thoughts:



  • My trackrecord as a software developer has taught me that an exact set of requirements are a key to every software project, especially a "web OS" project. It has to be clear, who the users of this software will be, and which set of applications and features it is to support. A best-of-breed approach will fail in this case, as it invariably bring in applications into the fold that are half-implemented or not good enough. Even
    today I feel that wether I choose Linux or Windows the top 10 features that I use these systems for, have a high chance of failure, due to:



    • software errors

    • inflexibility of the applications

    • software upgrades


    I wish to have a system that has the top 10 applications that I use most frequently, work PERFECTLY, without exceptions. I think the focus of "web OS" should be that...


  • Furthermore, my vision of a "web OS" goes along
    the lines of an "online mainframe" system. In
    the old days, a few people maintained the
    mainframe and all users benefited from their
    work. True, there was a single point of failure
    in the system, but it also meant that you had
    to fixed it at exactly on point. Today, each
    desktop has become its own little universe.
    I hesitate to accept the parts of the model
    proposed in this article, that are biased
    towards rich-client applications, i.e. anything
    requiring a client-side installation.

  • There a few fundamental obstacles to writing
    good web based applications or systems, and in my view these obstacles are never properly addressed even by experts in Web development. These obstacles must be addressed in, perhaps in SW models, and a good place to start is in "web OS". The obstacles are:



    • HTML was never meant to be a user interface language, yet we use (and abuse) it
      as such. If we want to have nice and reliable front ends to a "web OS" we should move away from it

    • HTTP is a bottle neck for writing networked applications. First of all, truly interactive applications require full support for the Model-View-Controller (MVC) paradigm. In MVC there is a scenario whereby, changes in the model effect changes in the view, yet HTTP does not allow for this. Most developers, ignore or underestimate how limiting this restriction is. Second, HTTP (Port 80) has become synonymous with application security. Because of this, effectively , any interesting application you want to write, becomes a nightmare to implement, because of this restriction. A new security model for "web OS" must be conceived.



  • Question: Where exactly is the discussion for this project taking place? (Link to Forum??)

Full Threads Newest First

Showing messages 1 through 9 of 9.

  • requirements first
    2007-05-14 06:22:13  georgebelotsky [View]

    This forum looks like the best place to have the discussion. The article text is right here, and O'Reilly should be a reliable host to store our ideas.

    Also, you raise important points regarding security, state management, and the need to think about network protocol design. The success of the Web OS will depend in large measure on the capabilities of the protocol.

    Regarding client side software, the thin vs. thick debate is a good one to have. How much runs on the client, and how much on the server? The approach proposed in the article entails a gentle transition from today's locally installed applications to a Web OS. So, clients will start out thick, and become thinner.

    How thin will the client become? That depends on the application, and the preference of specific users. Such flexibility is the attraction of the free Web OS. Some users will choose to run almost everything on a local PC. Others will set up in-house servers, and run thin clients. Still others will contract with an outside provider (or several) to host the applications. If the components are open, and can run anywhere, then there are many possibilities to create the right environment for everyone.



    • requirements first
      2007-05-14 07:22:29  Kuros [View]

      Yes, I think the thin/thick debate is a very good discussion, and also a discussion on which clients should be supported. Of course, an OS is a generalized platform to support countless applications, so it seems contradictory for me to demand a very limited set of applications. On the other hand, I am banking on the old 80-20 argument, i.e. why write something where 80% of the effort goes into supporting 20% of the productivity. It seems enough to pick out the applications that make up 80% of the productivity of the platform.
    • requirements first (2)
      2007-05-14 07:24:33  Kuros [View]

      I also have the following thought: The traditional OS is an interface to the PC/System hardware... Is this still the case for "web OS?". In fact what is it the interface to?
      • requirements first (2)
        2007-05-14 09:16:59  georgebelotsky [View]

        Excellent question. To start with the simplest observation, the traditional OS component does remain -- you need a kernel, for example, on both the client and the server.

        Of course, your question goes deeper than this. Extending the traditional view, the browser together with the server is the platform ("virtual" hardware, if you will) to which the the Web OS provides the interface. For example, imagine some sort of an evolved JavaScript library, together with a content management system. Note that this is early extrapolation from today's technology; the fully mature implementation may use different components.

        It is possible, however, to go even further. Consider the Web OS as an interface between the user, the application code, and the user's data. Regardless of where each component of the application runs, where the user is, and where the data resides, the Web OS can tie all of them together.

        It is important to realize that both the current PC-centric and the older mainframe-centric way of deploying applications have their advantages. Also, subscribing to a monthly service is the best approach in some cases; in others, it is better to manage software locally. What the free Web OS would offer is the ability to mix-and-match all of these models -- component-by-component, vendor-by-vendor, user-by-user, and situation-by-situation.
        • requirements first (2)
          2007-05-14 12:39:19  Kuros [View]

          i agree that a kernel is needed, perhaps in modern day terms we would call it a micro-kernel... yes i think this is a deeper issue. I remember when I used to work on telecom applications (telephony) there was a specification called AIN0.2 (AIN=Advanced Intelligent Networking) which started with an abstract model of the digital telephone network, identifying all the major hardware components in the network (and communication protocols), then designing a set of primitives upon which one could in principle design and implement a wide range of telephony applications. Furthermore, a lot of of what you say reminds me of another specification, called X-Windows. At the time of its definition was pretty advanced and had the main elements of a networked application "system". It too modeled the entire network containing the application. I think such a model and a subsequent specification are a best starting point. Why do you feel that the browser is a good place for a kernel, i.e. why do we need a browser at all (I am not a browser specialist). As I mentioned in an earlier reply, sofar I am not too convinced that HTML (and HTTP) are the best way to go. Perhaps you are thinking of the browser, as not just a place for rendering HTML? Some language like Extended Javascript is naturally needed. I was thinking some kind of a homogeneous programming language that tied the client and server together would be best (Javascript has too much baggage attached perhaps). The final form of the language should at the very least, make networks transparent (or trivially easy to navigate) and make it easier to write interface using same syntax everywhere. I come from a J2EE background, and I have to laugh at the notion that I am doing object-oriented design/programming, because once I start working with Javascript, HTML or XML (which is quite a lot) or development tools, like ant etc. I realize that there is nothing OO about them, so the claim of OO with J2EE is not legitimate. One needs a langauge (perhaps OO) that would allow programming at all levels of a "WEB" application...
        • requirements first (2)
          2007-05-14 12:39:33  Kuros [View]

          i agree that a kernel is needed, perhaps in modern day terms we would call it a micro-kernel... yes i think this is a deeper issue. I remember when I used to work on telecom applications (telephony) there was a specification called AIN0.2 (AIN=Advanced Intelligent Networking) which started with an abstract model of the digital telephone network, identifying all the major hardware components in the network (and communication protocols), then designing a set of primitives upon which one could in principle design and implement a wide range of telephony applications. Furthermore, a lot of of what you say reminds me of another specification, called X-Windows. At the time of its definition was pretty advanced and had the main elements of a networked application "system". It too modeled the entire network containing the application. I think such a model and a subsequent specification are a best starting point. Why do you feel that the browser is a good place for a kernel, i.e. why do we need a browser at all (I am not a browser specialist). As I mentioned in an earlier reply, sofar I am not too convinced that HTML (and HTTP) are the best way to go. Perhaps you are thinking of the browser, as not just a place for rendering HTML? Some language like Extended Javascript is naturally needed. I was thinking some kind of a homogeneous programming language that tied the client and server together would be best (Javascript has too much baggage attached perhaps). The final form of the language should at the very least, make networks transparent (or trivially easy to navigate) and make it easier to write interface using same syntax everywhere. I come from a J2EE background, and I have to laugh at the notion that I am doing object-oriented design/programming, because once I start working with Javascript, HTML or XML (which is quite a lot) or development tools, like ant etc. I realize that there is nothing OO about them, so the claim of OO with J2EE is not legitimate. One needs a language (perhaps OO) that would allow programming at all levels of a "WEB" application...
          • requirements first (2)
            2007-05-14 15:17:42  georgebelotsky [View]

            There is no intrinsic reason for the browser to be so central, but there is a definite historical reason. In the end it is simply how things turned out.

            At this point, Mozilla has invested a lot of effort into Firefox. Version 3.0 of the browser will have DOM storage and offline execution. This is a highly advanced FOSS project, with a lot of momentum. To match their significant technological achievement and market penetration would be a formidable task indeed.

            The above reasons is why I suggest adding X Window manager features to Firefox, making it the central mashup point for both SaaS and local applications.
            There is definitely a valid argument against putting too much in the browser, but what is the alternative? Maintain two separate desktop environments: the browser for SaaS, and a traditional X setup for local applications?

            Note that currently, the X-based desktop is the unifying construct, and the browser just another application that runs on top of it. Firefox, however is not just an application -- it is on the verge of becoming a platform. So, I am proposing to better integrate these two key systems, by making Firefox act like an X window manager.

            Of course, as you earlier pointed out, we do need to worry about many things, especially state management and the network protocol. HTML/HTTP is not the ideal solution. It should be possible, however, to solve these problems at higher protocol layers. This approach may not have the best architecture, but it avoids the monumental task of recreating Firefox's functionality elsewhere.

            Given your Java background, JavaScript will certainly seem strange to you. It does have an object model, and perhaps even its own peculiar elegance. Still, JavaScript OO development is very different from Java OO development.

            Since you prefer working in Java, maybe Google Web Kit (which automatically generates JavaScript from your Java code) is the right tool for you?

            http://code.google.com/webtoolkit/
            • requirements first (2)
              2007-05-17 00:46:23  Kuros [View]

              You are right about the historical reason... In fact legacy is always a problem (not just in Webdevelopment) and so far no silver bullet for dealing with it. I also don't see a problem with using FF as a base, however you also have to deal with IE. Or are you assuming that FF will be the dominant browser? Again, I think DOM is really problematic, where it not for the necessity to use HTML, no GUI designer in their right mind would use DOM/HTML as a basis for GUI design. Bringing X-Windows into the Browser (what about IE?) is a great idea, if it means that I'd have a component hierarchy for GUI design (and also addressing the HTTP bottleneck). I think Sun had the right Idea with using Swing in the browser, but that project failed among other, because the JDK became too bloated, but I think a similar way is the way to go, instead of HTML. Perhaps using a layer of Javascript is sensible, sort of a javascript virtual machine, on top of which I'd use a more elegant (networked) language which also works on the serverside (I know that Javascript has also a server edition).
              • requirements first (2)
                2007-05-21 13:46:50  georgebelotsky [View]

                Support for IE (and other browsers, especially Safari) is certainly an important area to cover. Since the article's topic is the future of Linux distributions, however, the focus is on Firefox, X windows and anything that runs under a Free/Open Linux or *BSD system. Of course integration via Java applet (e.g. VNC, NoMachine NX) can be cross-browser.

                In addition, Firefox 3.0 will have some very impressive features for SaaS. If a "killer app"
                emerges that takes advantage of these facilities, it is not inconceivable to require installation of a free browser to gain improved functionality -- especially in organizations.

                Currently, alternatives to the browser seem underdeveloped (if they exist at all). Contrast this with using Python, for example, to replace the shell and friends. Here, the alternative is highly mature, so the migration path away from the older toolset is clearly visible.

                Developing an alternative SaaS platform could certainly be an interesting project. It would be very difficult, however, to do better than Firefox, even taking into account the architectural disadvantages of JavaScript/HTTP/HTML/DOM. Most likely, the browser model has not reached its full potential yet, so the most fruitful approach would be to improve its Web application capabilities, while integrating better with the local X-based desktop software.

                Of course, if you are aware of any sufficiently capable and mature alternatives to the browser, feel free to discuss them.