Please don't confuse NSI with ISI. Jon worked for ISI (USC's Information Sciences Institute) and ran IANA (the Internet Assigned Numbers Authority). But it's been a long time since IANA handled registering domain names - that role passed on to Network Solutions under contact to the government when it became too large a task for one person. IANA continued to handle registrations of protocol numbers, etc, but not domain names. I don't think Jon ever worked for Network Solutions.
NeWS was the Network-extensible Window System. I spent a year programming NeWS applications back around 1987, and have since programmed many X apps. I always thought the wrong technology won.
It's been a while - forgive me if I get some of the details wrong. Basically NeWS consisted of a display server (much like an X server) that spoke postscript. Everything was done in postscript, from defining windows, drawing text, handling mouse events, etc. But the really nice thing was that the client could extend the postscript interpreter on the server. In the usual postscript/forth way, new commands can be defined and run, but the client could determine where they ran - if they were closely coupled to the data, it was best to define and run them on the client machine. If they were closely coupled to the display, best to define and run them in the server's postscript interpreter. So, for example, if your app wanted rubber-banding as you drag the mouse, then it was best to extend the server to do rubber banding. The commands associated with getting the mouse events and drawing the rubber bands would then all happen in the server causing no network traffic, and when the final rubber band position was ready, a single response would go back across the network to the client. In this way, interactive NeWS applications behaved nearly as well if the client was running on the other side of the planet as if it was running locally. At least for applications where the client and server could be relatively loosly coupled anyway. This wouldn't work well for GIMP for example unless almost all the rendering happened in the server, and for that quantity of data, postscript probably wasn't all that fast.
Shame Sun didn't learn the lesson about open standards earlier, but at least they did learn and do things a little differently with Java.
An alternative approach to Stefan's that doesn't involve shoehorning information into IP data packets is Steve Bellovin's ITRACE. I think this is more feasible in practice, and it seems to be gaining some momentum in the IETF.
Basically roughly every 20,000 packets, a router chooses a packet at random and sends an ICMP traceback message to the packet's destination listing the router's address and the previous and next hop that the data packet took. At the receiver, if you're being seriously flooded, you start monitoring the traceback packets and when you get enough you can piece together the paths back to the attackers.
It won't stop the attack itself, but will at least help in discovering the cracked hosts being used to launch the attack.
Anyway, with windows, when everything is maxamise, and u just use the task bar to switch applications, it isn't like a windowing GUI, more like what u where wanting.
Actually this isn't what I want at all. Right now I'm sitting in front of two 1600x1024 SGI flat panels. I've got perhaps 40 windows on those two displays, and about 10 of those are actually visible. I need to have many tasks going on at once, and see those tasks (some of those windows monitor a whole load of machines, some monitor network status, some handle email, and there are a bunch of xterms where I'm doing real workl). But what I don't want to do is waste time tiling windows and sorting through them. If I give a window any real-estate, it should do its best (with the help of the window system) to display usable stuff in that space. What I want is more like Frames in a web browser, but where I give hints to the wm whats important to me right now, and the wm does its best to arrange the screens' real estate in a manner that satisfies my requirements and those of the applications I'm running.
A good user interface wouldn't use windows. At least not windows as pretty much all current window systems function. Humans just aren't good at handling the pseudo-3d stacking of windows in a way that makes good use of screen space.
What does a UI use windows for?
Context switching between applications
As a metaphor for a directory
For pop-up dialogs
For none of these tasks is a window a good mechanism.
For context switching, the stacking and overlapping of windows confuses people, makes partially obscured windows fairly unusable, and results in poor usage of the limited screen real-estate. This isn't to say we don't want multi-tasking - just that the pseudo-3D window is a pretty clunky way of managing the interaction. Modern window systems should be able to perform more active management of the division of screen space between apps, scale the results, etc, etc, so that all apps are usable to some extent if they're given any screen space at all. This becomes especially important if voice-command interfaces ever become popular.
As a directory metaphor, a window filled with icons is a terrible user interface - really bad use of screen space, and provides no context as to what a file is for (other than filename and file type) or where it actually came from. A better interface could be based around HTML, with automatically generated web-like pages serving the purpose of a directory, and having the advantage that they can be annotated by the user so she doesn't lose track of what the file is for.
For dialogs, windows are pretty poor too - they're only appropriate for cases where some catastrophic event occured and the user's work flow absolutely must be interrupted. Even then, you want to tie the dialog to the window that generated the error, rather than have it pop up in the middle of the screen and where it needs to be managed separated from the application.
Unfortunately, window-based applications are really easy to program, so the interests of the user play second fiddle for many applications.
Slashdot Mirror
--Fzz
It's been a while - forgive me if I get some of the details wrong. Basically NeWS consisted of a display server (much like an X server) that spoke postscript. Everything was done in postscript, from defining windows, drawing text, handling mouse events, etc. But the really nice thing was that the client could extend the postscript interpreter on the server. In the usual postscript/forth way, new commands can be defined and run, but the client could determine where they ran - if they were closely coupled to the data, it was best to define and run them on the client machine. If they were closely coupled to the display, best to define and run them in the server's postscript interpreter. So, for example, if your app wanted rubber-banding as you drag the mouse, then it was best to extend the server to do rubber banding. The commands associated with getting the mouse events and drawing the rubber bands would then all happen in the server causing no network traffic, and when the final rubber band position was ready, a single response would go back across the network to the client. In this way, interactive NeWS applications behaved nearly as well if the client was running on the other side of the planet as if it was running locally. At least for applications where the client and server could be relatively loosly coupled anyway. This wouldn't work well for GIMP for example unless almost all the rendering happened in the server, and for that quantity of data, postscript probably wasn't all that fast.
Shame Sun didn't learn the lesson about open standards earlier, but at least they did learn and do things a little differently with Java.
-Fzz
Basically roughly every 20,000 packets, a router chooses a packet at random and sends an ICMP traceback message to the packet's destination listing the router's address and the previous and next hop that the data packet took. At the receiver, if you're being seriously flooded, you start monitoring the traceback packets and when you get enough you can piece together the paths back to the attackers.
It won't stop the attack itself, but will at least help in discovering the cracked hosts being used to launch the attack.
-Fzz
Actually this isn't what I want at all. Right now I'm sitting in front of two 1600x1024 SGI flat panels. I've got perhaps 40 windows on those two displays, and about 10 of those are actually visible. I need to have many tasks going on at once, and see those tasks (some of those windows monitor a whole load of machines, some monitor network status, some handle email, and there are a bunch of xterms where I'm doing real workl). But what I don't want to do is waste time tiling windows and sorting through them. If I give a window any real-estate, it should do its best (with the help of the window system) to display usable stuff in that space. What I want is more like Frames in a web browser, but where I give hints to the wm whats important to me right now, and the wm does its best to arrange the screens' real estate in a manner that satisfies my requirements and those of the applications I'm running.
--Fzz
What does a UI use windows for?
- Context switching between applications
- As a metaphor for a directory
- For pop-up dialogs
For none of these tasks is a window a good mechanism.For context switching, the stacking and overlapping of windows confuses people, makes partially obscured windows fairly unusable, and results in poor usage of the limited screen real-estate. This isn't to say we don't want multi-tasking - just that the pseudo-3D window is a pretty clunky way of managing the interaction. Modern window systems should be able to perform more active management of the division of screen space between apps, scale the results, etc, etc, so that all apps are usable to some extent if they're given any screen space at all. This becomes especially important if voice-command interfaces ever become popular.
As a directory metaphor, a window filled with icons is a terrible user interface - really bad use of screen space, and provides no context as to what a file is for (other than filename and file type) or where it actually came from. A better interface could be based around HTML, with automatically generated web-like pages serving the purpose of a directory, and having the advantage that they can be annotated by the user so she doesn't lose track of what the file is for.
For dialogs, windows are pretty poor too - they're only appropriate for cases where some catastrophic event occured and the user's work flow absolutely must be interrupted. Even then, you want to tie the dialog to the window that generated the error, rather than have it pop up in the middle of the screen and where it needs to be managed separated from the application.
Unfortunately, window-based applications are really easy to program, so the interests of the user play second fiddle for many applications.
-Fzz