Rethinking the Linux Distribution

Listen Print Discuss

Rethinking the Linux Distribution
Pages: 1, 2, 3

A window manager designed specifically for the VNC-based integration illustrated here could replace or augment any window management facilities built directly into Firefox. With multiple tabs open to the same desktop, such a window manager could automatically launch and maximize the desired application, depending on which Firefox tab the user selects.

It should be relatively straightforward to complete the required command path. After all, a VNC applet running inside a tab can already operate a window manager, via the VNC server. This design would allow the browser to control multiple remote applications, as well as local programs.

The specialized window manager could also maintain support for a traditional desktop view (as shown in Figure 3), or a tool similar to Skippy could provide this functionality. In addition, a compositing feature could generate window controls in the form of transparent HUD-style overlays (such as those used in aircraft) instead of traditional window decoration. The idea is not to compete with Compiz or Beryl for visual sophistication, but to provide a very compact interface, which focuses the user's attention on a just a single underlying task. Firefox itself would be the desktop environment, coordinating multiple tasks.

There are also alternatives to VNC (in various stages of development) for integrating X-based applications with Firefox. The WeirdX Java-based X server is one possibility. The WeirdMind project integrates WeirdX with the MindTerm SSH client (also in Java), giving encrypted shell and X access via the browser. Unfortunately, this project only supports the SSH1 protocol, and there are no recent updates.

The NoMachine NX Server (which won the Linux Journal/LinuxWorld 2006 award for best integration solution) offers fast remote X access. There is a FOSS version of the product (FreeNX) but the Java applet required to integrate with the browser is proprietary. The Univ-RX project is developing a FOSS Java applet that should work with FreeNX.

In summary, a complete Firefox desktop is perhaps not ready today, but with some work on integrating the components, it should be possible to produce one quickly. This would be an important step toward a consistent interface between web applications and traditional local programs. It also translates well to future portable devices, where a tabbed interface would ease navigation and make efficient use of the smaller screen space. Since the web browser will almost certainly be a central part of such devices, it is a good choice for implementing the overall user environment.

Overall, the Firefox desktop should encourage a move toward mashup suites of online and installed code, instead of monolithic, standalone software of either type. Now, the distinction between local and remote applications really begins to disappear.

The Free Web OS

The logical conclusion of the above refactorings may well be the Web OS. It would, however, be a free (FOSS) Web OS, not a proprietary one. This, in turn, is what may finally allow broad adoption of the technology. If only a few large suppliers offer such services, then the Web OS must overcome the steep reluctance of customers to give up control of their data, reluctance which may have doomed Microsoft's Hailstorm, and could yet harm Google Apps. The free Web OS, however, supports many more options for deployment, to better suit the needs of different users.

For example, ISPs know Linux well. The have provided managed hosting on this platform for awhile; some are now adding virtual private servers as well. For them to offer the Web OS, reached via the route described here, is not much more difficult than installing another Linux distribution. Many small and medium organizations may get better personal service from a local, trusted ISP than from a large supplier.

Similar arguments apply inside the corporate datacenter. With generic Linux boxes running a free Web OS, organizations can get most of the benefits, while retaining full control of their data.

Of course, products from large suppliers, such as Windows Live and Google Apps, will continue to have an important role. They will, however, be part of a diverse Web OS universe, a fact that may ultimately make them more successful than if they stood alone.

How will the free Web OS work? To fully understand any Web OS, you must consider at least the client machine, in addition to the server to which it connects. From the client's perspective, it is possible to use software in three major ways:

Wholly local (such as the Linux kernel)
Some components local (e.g., Firefox plugins), others online
Wholly online

Variations include downloading local code in binary form or compiling it from source (the approach used by Gentoo), and online code designed for multiple browsers or a single browser (such as Firefox 3.0).

Clearly, a pure Web OS is impossible; a kernel must run wholly on the client, for example. The exact mixture of components, however, can be very flexible in a free Web OS. This should allow multiple system flavors to emerge. In the future, it may even be possible to just go to a trusted site, and start using any application right in the browser, even if some (or all) of the components will be installed locally at first launch.

Advanced users may choose to run more software on their workstations, and assemble suites of online components on their own. Other users may choose a single Web OS provider, and run that provider's set of applications. Just like it is readily possible to switch ISPs today, a competitive Web OS environment will allow customers to select services from different vendors, piece by piece.

A Note on Governance

As mentioned earlier, it is my hope that the arguments presented here will create a discussion, from which genuine improvements will emerge. To this end, it is necessary to mention a few important things about project governance and the nature of debate.

Governance is a critical topic to the world at large, and FOSS is no exception. In a recent interview, Debian's founder argued that process paralysis is hurting the distribution. Also, members of the Subversion team gave an entire Google talk about dealing with "poisonous people" on a project. Sometimes, online discussion can even degenerate into something far more serious, such as the threats made against Kathy Sierra. Tim O'Reilly has proposed a blogger's code of conduct in response to that incident.

Proper governance, however, needs a sound philosophy, a model, in order to function. Of course, nothing could be accomplished without the community's desire for fairness and justice, but the model is also essential. The community is the musician, the model is the instrument. Interacting with others based on the wrong set of assumptions will lead to problems, including process paralysis, the emergence of "poisonous people", or worse.

When considering FOSS governance and online discussions, such as the future of the Linux distribution, the notion of a scientific inquiry is particularly suitable. Just like FOSS emerged from the academic world to transform other areas (including business), so the basic practices of science can inform projects outside the realm of research.

Here are the best parts of the scientific approach.

A willingness to explore the unknown, including unusual ideas, in a rational search for truth.
An understanding that even negative results (failures) provides valuable information.
A commitment to openness; all decisions have a definite, logical basis.
Explicit recognition of every contributor.
An effort to find prior work, to better inform current efforts.
Emphasis on gathering hard evidence and reproducible results.

Note that the common FOSS practice of encouraging patches from newcomers is an example of the scientific approach. New ideas are welcome, but it is important to show something that actually works.

The recognition of the value of negative results is in contrast to the prevailing strategy of blaming individuals for failure. The latter approach is actually of limited corrective value, and often leads to the kind of hostile situations cited at the beginning of this section. The Aviation Safety Reporting System (ASRS) offers a striking example of the value of learning from mistakes. Operated by NASA, the ASRS encourages detailed, penalty-free reporting of errors in the field of aviation, then anonymizes and publishes the results. The idea has clear interdisciplinary potential. Kim Vicente's book, The Human Factor, describes how hospitals which adopted ASRS-style techniques in place of traditional focus on individual guilt saw medical errors decline 90 percent.

If we adopt the spirit of scientific inquiry, then the resulting discussion has a chance to stimulate the emergence of a new type of platform. The subject will likely turn out to be much deeper than the familiar "Linux on the Desktop" or even "Linux for the Enterprise" debates. After all, the vastness and openness of the FOSS codebase is good for more than just following the existing trends. It can also uncover new trails.

Appendix A: Special Delivery

The packaging and delivery of Linux distributions is a difficult problem today. Current distributions are expensive and complicated to host, due to their size. Last year, Mepis faced this problem. The highly regarded distribution (number five on DistroWatch over the past 12 months at the time of writing) violated the GPL by not hosting the source code for every binary which it included.

Of course, Mepis was not trying to hide anything (the complete source code was readily available elsewhere) but it was still contrary to the GPL. The fault here is not with Mepis or the FSF. It lies in the fact that existing hosting, mirroring, packaging and delivery systems (which have served us well in the past) are beginning to show their age. Now is the time to consider what comes next.

As mentioned at the beginning of this article, diversity is the strength of FOSS. It should be easier for new distributions to get started. At the same time, having lots of identical, and nearly identical, programs floating around on the internet is wasteful and confusing. Which version is the canonical one, released by the project's authors? How do the available variants differ from one another?

What if the package management utilities were to download only the canonical project sources, via BitTorrent? These utilities could then use patches to "personalize" the code for a particular distribution. This approach is similar to how Gentoo works today.

Using BitTorrent in the package manager shields the user from having deal with torrents directly. It also makes it possible to create a package-level repository of torrent seeds, which many distributions could share.

For source distributions, the seeds would derive directly from the released code for each project. For binary distributions, perhaps the Linux Standard Base (LSB), which has made binary compatibility between distributions its goal, could operate the required seed repository.

Such a "FOSS seed bank" would consume minimal resources. Downloading via BitTorrent makes far better use of the network than the traditional host-and-mirror approach. In fact, the need for mirroring should decline significantly.

In general, we should pay more attention to the location and flow of FOSS code across the global internet. Better organization of the entire distributed FOSS codebase, with clearly visible lineage information between projects, would allow everyone to use this vast universe of resources much more effectively.

Google already offers Code Search, and a microformat for licenses also exists. Perhaps a few microformats, and a suitable search engine, would be the first step.

Appendix B: Green Software

Environmental concerns closely follow the emergence of the Web OS. Such services will require more machines at the datacenter. Even today, however, electricity consumption of large server farms is a serious problem, for the environment as well as the bottom line.

Disposal of computer equipment (e-waste) is also an issue. These unwanted machines contain many poisonous substances, and various governments are implementing new taxes to deal with the resulting toxic garbage.

Of course, there is evidence that FOSS, which requires fewer computing resources and less frequent upgrades, is already friendlier to the environment. What is needed is a specific effort towards green software, in parallel to the movement towards the Web OS. Programs which emphasize efficient use of computer resources (memory, CPU, disk, and bandwidth) delay obsolescence, while requiring fewer machines in the first place. This, in turn, reduces e-waste and electricity consumption. Saving computing resources translates directly into preservation of actual physical resources.

Nor are kernel changes, or virtualization alone sufficient to create green software. First of all, developers of such system-level software must already consider resource conservation, otherwise the resulting platform would be impractical for running application code. Therefore, rethinking resource use at the application level would likely uncover many more unrealized efficiency gains. Also, virtualization, which provides a great efficiency benefit by consolidating underutilized hardware, may actually hurt performance under peak loads.

The Linux distribution, however, is more than just a kernel, or system-level tools. It includes thousands of applications, assembled into entire environments. A "SaaS Ready" distribution can provide built-in examples, frameworks, network protocols, and benchmarking suites (complete with GUIs) to guide developers in writing more efficient applications. In turn, careful attention to conservation at the application level should reduce resource requirements (particularly electricity) that would hamper the adoption of SaaS and the emergence of the Web OS.

George Belotsky is a software architect who has done extensive work on high-performance internet servers, as well as hard real-time and embedded systems.

Return to ONLamp.com.

What is your vision of the next generation of Linux distributions?
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 24 of 24.

Author's Analysis of Results
2007-07-03 04:39:12 georgebelotsky [Reply | View]

Almost two months have passed since the publication of the article.
As with any experiment, it is necessary to analyze the results. Now
is a good time to do so. The initial wave of comments has gone down,
so it is possible to review, and draw conclusions. In addition to the
remarks posted to this forum, I have searched for posts on other
sites, and incorporated them into the following discussion.
Unfortunately, it is not practical to find every single remark that
exists across the global Internet.

Discussion Highlights

First, here are a few highlights of the ideas posted to this forum.

The minimal live CD by Matthew Nourse (matt_n) would make an
excellent companion to SaaS-based applications. The CD can be used
quite safely from almost any computer -- including one with viruses on
the hard drive. The SaaS/minimal live CD is also far more secure than
storing large amounts of data on a laptop, which can be stolen. You
can find this application at http://cl33n.com/

I also had a long discussion with Kuros, who made a number of
insigtful comments.

Finally, simon_hibbs proposed a fascinating roadmap, based on
virtual machines.

In addition, Bryan Dumm emailed me some information on his team's
projects related to the future of the Linux distribution. You can
download the source code from http://www.projectamin.org/svnweb/

Although the Web site is not yet finished, there are lots of
interesting ideas. You can also read their articles at
http://projectamin.org/svnweb/articles/

The VNC Desktop

The VNC-based desktop (using a Java applet inside Firefox) has been
the target of criticism, which does have a valid point. For purely
local applications, this approach -- as it currently stands -- is slow
and cumbersome. While I did find the system quite usable, it is not a
production-level solution for now. As the article states, the Firfox
desktop is perhaps not quite ready today.

Of course, the specific demonstration given in the article is
experimental, as evidenced by the supplied source code.
Unfortunately, this may not have been clear enough for some readers.

The idea itself, however, is not as crazy as it looks at first glance.
After all, X windows itself -- originally designed as a client-server
architecture -- works well with both the client and the server on the
same machine. This is the most common way to use X windows today, so
modern implementations are sufficiently optimized that the performance
penalty is not a problem.

Provided that the user experience is good enough for remote
applications, using the same technology for local access is appealing
-- especially if the remote applications will dominate. So, if heavy
use of such applications is the future, VNC deserves some
consideration. The technology is mature and cross-platform; at the
very least, it could serve as a testbed, or a temporary solution,
until the Web OS/SaaS variants are fully ready. Whether this is
indeed the future, or desireable, is a different topic (see below).

In a serious implementation, a combination of window manager features
built into Firefox itself, plus technology such as FreeNX (both
discussed in the article) would likely replace VNC in the above
scenario. Nevertheless it is probably too early to abandon VNC
altogether.

Is SaaS a Good Idea?

There were a number of remarks that SaaS/Web 2.0/Web OS is merely a
marketing phenomenon, created just so large companies can generate
perpetual revenue via subscriptions. Some of the comments went on to
say that a FOSS Web OS platform would actually harm the FOSS
community.

The criticism raises important points. In particular, there is a
danger in giving up control of your applications (and especially your
data) to a third party, which has the power to change the software or
its terms of use at any time.

SaaS and the Web OS, however, will be with us in some form. Today,
the Venture Capitalists and large companies are funding Web 2.0. The
massive infusion of capital attracts plenty of top engineering talent.
After all, few active engineers are sufficiently wealthy to sustain
major projects on their own. This is true even for FOSS work, which
almost always requires backing at some point.

Such dynamics are powerful enough to overcome the high failure rate of
startups, and the inefficiency of many large corporatex IT projects.
The phenomenon was clearly visible in the dotcom era. Despite the
crash, Web 1.0 was not, in the end, a failure. Companies such as
Amazon, Ebay, and even Google emerged from that period.

Thus, declining to build a Free Web OS platform will not prevent
proprietary Web OS offerings from emerging. Without the FOSS
alternative, however, there will be far fewer choices in the market.
The mere presense of a FOSS platform will tend to counteract the
natural tendency of vendors to lock in their customers. Lock-in is
especially dangerous in a SaaS scenario, so the availability of FOSS
solutions (which any ISP or small company can host) is particularly
important.

In addition, it is necessary to keep the needs of all users in mind
when discussing SaaS. Technology enthusiasts can maintain their local
desktops by themselves, but others require frequent, ongoing support.
Paying a subscription fee may well be more reliable, and less costly,
than emergency visits by technicians, or running to the store to have
the PC "repaired". IT departments inside organizations face an
analogous situation.

Of course, it would be fascinating to discuss if some other direction
would be preferrable to the current Web 2.0 trend. Unfortunately, all
the criticism of Web 2.0 that I came across argued for the
preservation of the status quo. This, of course, is not possible.
Only dead things stop evolving. The future Linux distribution
will be different from today's. Discussing that future is
vital for the community -- otherwise outside forces will fully
determine our next platform.

Harnessing the Wisdom of Crowds

The main goal of the article was to start a discussion on the future
of the Linux distribution. To help this discussion, the text contains
a large number of references, a strong encouragement to participate,
and a governance framework to guide the conversation.

With a few minor exceptions, the above approach had the intended
effect in this forum. Nevertheless, lots of comments across the
Internet ignored the governance framework altogether. Indeed,
hundreds of posts clearly originated from people that have not even
read the article. Unfortunately, such situations are common in online
discussion.

These results suggest that the ubiquitous forum may not be the best
way to harness the "Wisdom of Crowds". One of the ideas covered in
the article, however, offers a compelling alternative.

The Aviation Safety Reporting System (ASRS) has been preventing
aviation accidents since its launch in 1975. As mentioned in the
article, adoption of a similar facility in hospitals reduced medical
errors by up to 90%.

Rex Hardy, one of the architects of the ASRS, writes the following in
his book,

CALLBACK

anonymous

A Note of Thanks

Are you serious?
2007-05-23 09:24:29 serge-nn [Reply | View]

A browser running VNC as a Java applet is ridiculosly slow, compared to compiled applications, using native system calls and running on traditional desktop. I can't believe somebody calling himself "software architect" can be seriuosly proposing this. This is how you make any modern and powerful machine crawl.
Plus, the whole SaaS idea is bad. Users deserve some stability, and with SaaS, when you fire up you browser in the morning, you'll never know what changes were made to UI and functionality. "Free software people", with their "save the world" mission, are the ones who especially don't get it.

SaaS and live CDs
2007-05-14 18:47:41 matt_n [Reply | View]

Perhaps the client-side piece of the puzzle can be solved by simple Live CDs that are built primarily or exclusively for web browsing. One such Live CD is cl33n (http://cl33n.com/). cl33n just boots, connects to the internet and opens Firefox. There is no other functionality.

I put cl33n together after running a bunch of usability experiments existing live CDs and occasional computer users. I loved all the live CDs that I tried and I thought they would work out great but unfortunately the users (all Windows beginners) were confused by each of them.

With LiveCDs, the desktop machine becomes nearly irrelevant so all the heartache of backup & security management is centralized and/or becomes Someone Else's Problem :). The management issues reduce to those relatively-easy-to-manage dumb terminals of my youth :) but better....a LiveCD-based desktop is a smart dumb terminal :), able to do lots of client-side processing using Javascript. If it becomes virus-ridden, just reboot. If it breaks, no data is lost.

requirements first
2007-05-14 05:20:32 Kuros [Reply | View]
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??)

requirements first
2007-05-14 06:22:13 georgebelotsky [Reply | 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 (2)
2007-05-14 07:24:33 Kuros [Reply | 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 [Reply | 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:33 Kuros [Reply | 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 [Reply | 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 [Reply | 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 [Reply | 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.

requirements first (2)
2007-05-14 12:39:19 Kuros [Reply | 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
2007-05-14 07:22:29 Kuros [Reply | 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.

Web based apps
2007-05-14 03:05:51 dpawson [Reply | View]

Yes please.
Case in point. I want to share a utility with a windows user. If he could use the web based app (which happens to be running on Linux) and have the result returned to him, we can both benefit.

Does it really need to be browser based? Surely there could be command line apps that would suffice for many of the utilities that we use daiy? Kiss principle?

A problem to be addressed is security. Many of my shell scripts crawl over directories. I would be cautious about letting remote software have access to my disk. We'd need some sort of trust model to let url A in, but exclude url B.

Much food for thought! Thanks

Have a look at "Ulteo"
2007-05-14 00:54:11 nextgenos [Reply | View]

From what I've read in the press, they are working on providing the benefits of full-featured applications both within the webbrowser and as a standalone OS...
http://www.ulteo.com

This is an enormously bad idea
2007-05-13 16:39:58 macraig [Reply | View]

Offering OSS as Web services would validate the Web-services scheme as a means for commercial software vendors to collect monthly or annual SUBSCRIPTION fees for non-OSS software. That is a prospect over which software publishers have been salivating for years. The whole upgrade-or-else scheme to generate that cash flow and profits never really worked out, because too many stubborn SOBs like me looked at the bubblegum improvements in the upgrades and simply said, "Thanks, but no thanks." So they've been desperate to find another scheme. They've been watching the consistent cash flow and huge profits reaped by "content" publishers and thinking, "Geez, if only we could repackage our software as 'content', we could demand a subscription fee and make TONS of money." If Big Software can manage to "re-educate" people's perception of software, in the same way that, say, Big Pharma re-educates people about how to treat illness so that only their patented products seem viable (making people forget about folk medicine, etc.), then they'll win the war. Re-packaging software as Web services is actually Big Software's latest attempt at doing that, because Web services then "feel" more like content to people, and as we all know people are already indoctrinated to paying regular fees for content.

If OSS providers indulge in the same software-as-a-service route, it will validate that scheme and ultimately be handing a huge monetary victory to Big Software, a victory that will completely overshadow the small gains that OSS has made in recent years. Is that what we want?

This is an enormously bad idea
2007-05-13 19:59:17 georgebelotsky [Reply | View]

Avoiding FOSS Web services for fear of helping proprietary vendors is a dangerous strategy. After all, both Google and Microsoft are definitely moving towards SaaS -- as cited in the article. With their enormous power in the marketplace, they could just make it without anyone's help. This would marginalize FOSS.

Also, rejecting something valuable because others may twist it to harmful ends is rarely a good idea. Should FOSS authors stop working on their projects, because new releases validate the general idea of upgrades, for which proprietary vendors charge money? For example, was adding USB support to Linux a mistake? Should we stop releasing security patches?

This line of reasoning leads to absolute paralysis. As discussed in the article, a free Web OS would help IT operations inside organizations, less experienced users, ISPs, etc. This makes it worthwhile. Someone willing to twist our good works to less than benevolent purpose would just pursue their nefarious goals anyway -- even if we do nothing.

Nice, but you have one point a bit backwards.
2007-05-13 16:29:56 Gavin86 [Reply | View]

The article makes a few interesting points.

One thing I disagree with, however, is replacing the entire desktop with a browser. The problem this solution is attempting to solve is valid, however the implementation is terrible.

He's got it backwards: It's not, "The Desktop is the Browser", it should be, "The Browser is the Desktop". The desktop has evolved the way it has for a reason. And it should be noted that the desktop is not a series of static tabs that replace each other when clicked. The Window metaphor has served pretty well for the last few decades because it mostly works. It will be enhanced and modified and eventually replaced, but it is still pretty solid.

Case-in-point is the Symphony distribution's Mezzo, a Mozilla-based desktop environment. The entire interface is built in Javascript and XUL.

The desktop would be able to fetch applications online and cache them in an Applications directory for re-use, meanwhile displaying them just as any other native resident application would be, in a way that is consistent and familiar to users. In a recent interview Mitchell Baker, Firefox's CEO, claimed the company is expecting to support offline web application usage. This means something similar to the WHATWG Web Application 1.0 spec where web-programs can save local sessions. The browser is already moving in this direction, we just need a better way of tying and presenting it to the desktop and users.

The trend of web applications and dev technologies such as Microsoft's recently introduced Silverlight and Adobe's Flex--and of course Mozilla's Application Framework that has been using XML-based UI markup languages for almost a decade--are moves that support this idea.

Blackdown Java is NOT FOSS
2007-05-13 13:59:49 craig.knights [Reply | View]

ignoring how much I disagree with the idea of cramming even more functionality into browsers, I just wanted to point out that Blackdown isn't free software. The reason it has been given priority over Sun's JDK in Linux distributions in the past is because it had a less restrictive distribution license, which allowed them to repackage it in their native package formats.

Blackdown Java is NOT FOSS
2007-05-14 06:43:42 georgebelotsky [Reply | View]

Thanks for noticing that Blackdown is not actually FOSS. I sent the necessary correction to the editor.

Perl is quicker than Bash?
2007-05-13 13:01:01 DiggyK [Reply | View]

I strong disagree with that statement. I can write a shell script to find all the .c files in a directory and it's subdirectories and add a subversion keyword to it in a for-loop that I write in one line in Bash. I doubt doing the same in Perl would be as quick.

But Perl, Ruby, Python as certainly great for more complex tasks. But beware that if you use any external modules not distributed as part of the core of the Linux distro your organization uses, you need to first ensure that those modules have been made available on each system you would use this script, thus adding another complexity.

Unix Shells without backgrounding?!
2007-05-12 05:16:33 Paddy3118 [Reply | View]

As much as I like Python, I can't see any replacement Unix shell catching on if you can't create and control background processes. So if you can't do it in Ipython then Ipython as a shell to replace for example Bash will not work in too many cases.

- Paddy.

Unix Shells without backgrounding?!
2007-05-15 11:18:33 simon_hibbs [Reply | View]

Here's a roadmap:

1. Move to a more advanced shell and init script environment. Pyhon for init scripts sounds cool, especialy if it can implement some of the advanced process/service management features in Solaris 10. IPython is great stuff but Microsoft have a real headstart on this with PowerShell. This kind of approach is deffinitely the way to go and later can be transitioned to...

2. Software Virtual Machines such as the JVM, Mono/.NET or even Parrot. These need to mature further before they conquer the universe, but they're getting there. They can be embedded in browsers as Java FX and Silverlight show but soon we'll see.....

3. Browsers implemented in Software VMs such as Mono or the JVM that can execute web-based code as native extensions leading eventualy to...

4. Fully virtualised application environments taking advantage of hypervisor technology to host software VMs, or even hybrid hardware and software VM technology. Imagine something like Mono running as a kernel module with built-in hypervisor support. Now wer're moving beyond my humble abilities as a prognosticator.

Unix Shells without backgrounding?!
2007-05-12 15:44:38 georgebelotsky [Reply | View]

Job control is definitely useful. It should be possible to add it to IPython. Here is a module that may already do what you want.

http://ipython.scipy.org/moin/Cookbook/JobControl

The Free Web OS

A Note on Governance

Further Reading

Appendix A: Special Delivery

Appendix B: Green Software

Sponsored Resources

Related to this Article