Quo vadis Linuxum?
Until I can raise the money and renew Easel or the News server (network extensible windowing system) and build some RAD tools for Linux, it will remain dormant as a desktop replacement for windows. I do desktop stuff in Linux in GNOME window manager, but is is based on X-Windows as the other window managers are as well, i.e. the motif clones and KDE. Replacement of the X-Windows paradigm is the key. It was built to be a more universal window manager that would operate over a network, and it does, but it is way too high bandwidth, and the basic program level window creation commands are way too complex. Another problem with it is management of inputs, like mouse and keyboard, suffer from focus problems, so cut and paste is a tad more difficult than windows, and not as sure-footed. You want a sure-footed mouse. Colour maps and windowing services are controlled by the programs and not the window manager so there can be conflicts between programs. This paradigm needs to be replaced by windowing-lite, where a "central server", i.e. the console itself shells out graphical services, memory and colours to the program. Right now the program makes all the decision, and its memory requests can clobbber another program which know nothing about them. It's like all the students at once trying to write on the blackboard at the front of the class.
X was built this way so graphical programs could run on a memory poor terminal. The idea was for a mainframe running the X programs to send commands to a max 1 meg-ram X-terminal. All the windowing commands would be made up on the main computer, sent over the network and the graphics run on the terminal, which does not have to run a huge computer to put the graphics up.
With Linux I can run an X program like Netscape on a remote computer, which X calls the client** but which actually is the server, and display them on my satellite computer I sit in front of. Of course both computers have to run X, but the remote computer does not have to run a display. It works ok on ethernet, but will not work that well over the internet, even on high speed lines.
** why does X call the remote program running on the server, the client? Because the like to think of the displaying X program as providing services such as mouse inputs, and graphic display as the "X-Server."
Since satellite or PC computers have all the memory they need to run programs and display them, the remote running technology is no longer desperately needed. Sun replaced its network extensible windowing manager they had been writing to replace X, by Java, which they figured would be far more universal and would allow them to take over the world. It may have but only so far as microsoft supported it.
What I propose is the same idea as a browser. All the complex display tech is in the OS, and the program need know squat about it. It asks for a window with the command makewindow sizeof.. x.y pixels and where to put it. It should not need to build it pixel by pixel like X does. There are high level window creation tools for X (Tcl/Tk, GTK) but they are embroiled in X's already sticky syntax, focus and memory problems and outdated approach. They are somwhats low and buggy. Slow to write in as well.
What I am thinking of is a graphical interface windowing system that is sufficiently efficient that you could build a graphical interface itself with it. One graphical OS running inside another.
Once X was replaced by Y-Windows, Linux would be efficient and fast to write programs in. Users could write acceptable programs with drag and drop on simple text commands. This would make Y-Windows Linux the preferred platform to write for, as Linux is already several orders of magnitude more stable than MS Windows.
A preferred platform would be very, very commercial.
EC<:-} |
