Gosling: If I Designed a Window System Today...

An anonymous reader writes "In his blog entry for the 10th August, James Gosling (finally) publishes a short paper he wrote in 2002 entitled 'Window System Design: If I had to do it over again in 2002'. His design is to make the window system do the absolute minimum and move all the work into the client."

Comments

Good idea

[penguinoid]

I think it is a good idea to separate the server and the client so each does its own stuff. This will increase modularity and compatibility quite a bit, IMCUO (in my completely uninformed opinion)

Re:Good idea

[shfted!]

On the other hand, it would waste resources. By consolidating your RAM in the server, copies of the same program could reference the same pages in memory -- a very significant savings, if you have a smart OS and your users typically run the same applications. Plus, because user activity tends to be bursting (i.e. the CPU and hard-drive sit idle most of the time), money could be saved by equiping the clients with less capable hardware, and/or performance could be beefed up for those bursts by having a high speed/capacity server (imagine having several timse the processing power of your client machine at your disposal). Granted, this latter benefit is reduced when your users run long-running, intensive tasks.

Re:Good idea

[Short Circuit]

I was at AutoZone today. (Er, yesterday. It's after midnight.) I asked the sales clerk what their computer system was.

He said, "It's an old piece of crap." (He works on a green dumb terminal)

I asked him if it did the job well enough...

Re:Good idea

[ipfwadm]

It takes about 2 seconds for MS Word to come up on my laptop when running on batteries. When plugged in, that would presumably be a tad faster. Even if your central server can have it open in 0.1 seconds, I would bet that the network latency would make that 1.9 seconds all but go away, and 1.9 seconds isn't much of an inconvenience to me anyway. Sure, some apps take longer, but once I've started those up, they usually stay open for a long long time. Besides, we're still only talking about a few seconds of initialization time -- Visual Studio just took 4 seconds, Photoshop CS took 20. I waste more time blowing my nose.

There's a reason nobody runs client-server. Desktop systems with fast processors are just too cheap.

Re:Good idea

[Jeremi]

m afraid I disagree with the idea of a minimalist windowing system - one that leaves most everything to user level libraries. This still leaves the door wide open for applications to implement various looks, various copy/paste mechanisms, and other things that annoy people.

So you don't want a windowing system that is flexible, because people might want to take advantage of that flexibility?

I think your reasoning is a misguided attempt to solve by technical means what is really a politicial/sociological problem. The proper solution is to have a strong set of UI guidelines and standard libraries that make it trivially easy to follow those standards, not to limit the capability of the system just because you don't trust people not to abuse it.

Re:Good idea

[ipfwadm]

And the fact that Office apps are mostly loaded into memory at boot, thus providing the illusion of speed when they're 'opened', hasn't been pointed out to you?

Your point? When I double-click on the Word icon, it takes two seconds for the window to come up. Why should I care if the app is pre-loaded or not? If it's pre-loaded on everyone's system, why should we time it as if it weren't?

And you still conveniently neglected to address the fact that I mentioned other apps, and that even in today's high-speed world, a few seconds of waiting for your app to load really isn't a big deal. Like I said, I dedicate more time to excretory bodily functions every day than I do to waiting for my software to load.

Re:Good idea

[nathanh]

In the common case, there is no client or server, just an app running on a PC. So don't build the assumption of networking into windowing.

OK. So let's run with that idea. We still have multiple clients and one set of hardware, so we need to arbitrate the access. We also need to have a common place where the clients can share information like window clip lists. Then there are issues like drag and drop, cut and paste, etc which also require inter-client communication. And how do you solve the issue of two clients seeing the mouse button being pressed, and both assuming that the click was for them?

At one stage you realise you need to have a program, somewhere, that coordinates all of the clients. Assuming this won't be the kernel, it must be another userspace program. We call this program "the X server". And because we have all these clients in userspace, and the X server is also in userspace, they need to use some form of inter-process communication. XFree86 and X.org already use UNIX sockets; one of the fastest IPC methods available. The only thing faster would be shared memory but that's been tried before and it's more hassle than it's worth.

Now admittedly there are some situations where the clients simply need to talk directly to the hardware. For example the client needs to upload a 3D texture or render an MPEG-2 frame. For those situations it makes no sense to send that data to the X server first. So for those situations we do have solutions that bypass the X server and go directly to the hardware. These include the DRI extension, the MIT-SHM extension and the DGA extension.

Re:Good idea

[nathanh]

Anyways, the intention was more to point out the fact that CPUs are so fast that application load time is all but negligible, and certainly not so lengthy as to make me wish I could farm it all out to a central server.

That works fine for word processors. But there are several situations where client-server GUI is the preferred solution. For example, VPN clients are often implemented as Citrix over IPSec. In scientific and academic circles it's common for the applications to run on headless mainframes and/or supercomputers. In high security environments it's sometimes impossible to run a client locally; you must run it remotely and display it locally.

And when you start to consider other issues - how much does it cost to patch and maintain 3000 Windows desktops? - it quickly becomes obvious that per-user desktops aren't the be-all and end-all.

Load times, sure, I'll agree with you that's not a big deal.

Re:Good idea

[maxpublic]

Why should I care if the app is pre-loaded or not? If it's pre-loaded on everyone's system, why should we time it as if it weren't?

It isn't, and therefore your point is irrelevent. Just because it happens to work for you that way doesn't mean it does, or needs to, work for everyone that way.

I'd prefer not to have apps load on boot unless I tell them to load on boot, thank you very much. I don't need either my RAM or swap being soaked by an app I haven't given explicit permission to load.

But then, that may be why I don't live in a Windows world.

Max

Re:Good idea

[shirai]

So you don't want a windowing system that is flexible, because people might want to take advantage of that flexibility?

I'm afraid you have it ass backwards. An integrated system allows you the *flexibility* to do whatever you want, including a uniform interface.

You can still do whatever you want with the interface ultimately but you would be encouraged to do it the consistent way. The encouragement would come from the fact that you wouldn't have to build standard features from scratch every time.

For example, Windows never stopped Photoshop from implementing their proprietary windowing subsystem for their palettes and such. But I, for one, am glad that they still use standard drop down menus, minimize/maximize buttons, etc.

Re:Good idea

[nathanh]

Kernel space is only dangerous in the case of badly written graphics drivers. Windows NT has had kernel-level graphics hardware since its inception, and its only been a cause of problems with extremely buggy graphics drivers. And guess what - buggy graphics drivers are gonna cause problems whether they're in the kernel or not. Might as well put them there for the speed advantages.

I disagree. A properly separated model like the DRI/DRM has high speed userspace drivers and doesn't cause problems when there is a bug with the driver. The model requires a tiny kernel module called the DRM. It manages the hardware resources (eg, DMA) and queues the clients so they don't stomp on each other. The majority of the driver is written in userspace and links directly into the client application (via libGL).

Putting an entire video driver in the kernel isn't sensible. There is too much complexity and there is no actual benefit. It's actually faster with modern cards to link the driver directly to the client. The reason being that the client can fill the command buffer without context switches. If the entire video driver was in the kernel you would need two context switches per queue flush.

Network transparency's of only marginal value, particularly considering the cost (non-kernel graphics). Anyway, there's plenty of other methods of doing network logins without needing it built into the core graphics API.

The only cases when the network transparency causes a measurable impact is when a lot of data is being pushed from the client to the hardware. For those situations we have direct rendering in the client. For all other situations, the costs of network transparency are lost in the noise. I wouldn't be too concerned about it.

Re:Good idea

[NtroP]

There's a reason nobody runs client-server. Desktop systems with fast processors are just too cheap.

Actually, we do, and very successfully. I can get an empty Microtel workstation from Walmart for $168.00 with a 17 in monitor for another $120.00 or so. This gives me a great "thin client" for under $300.00. Sure, that's not much more savings over, say a $500.00 stand-alone desktop, but the savings (in a lab environment) comes down the line. With a standalone desktop I have to replace it in 4-5 years and probably at least add RAM in the mean time (think Longhorn will run on 128Mb well?). At, say $500.00 a pop for 30 workstations, you are looking at $15,000 to upgrade the lab (and a $500 standalone workstation won't last very long). I can put a whole new thin-client lab in for under $10,000 or upgrade an existing lab (either monitors or CPUs) for half that (though why I'd ever need to do that I don't know - maybe moving to flat-panel monitors or bigger CRTs?)

The thin clients, once in place, are good indefinitely. If I need more speed or capacity, I just upgrade the server - not a whole lab of 30 workstations. The savings continues from there. With no internal moving parts the energy consumption for the lab goes down, and the lab also stays cooler - requiring less energy again from the H/VAC system. Small savings, but with 30 labs - it adds up. On top of this, I don't ever have to touch the clients. They PXE-boot from a central Tao-tc Linux server which loads a small kernel and rdesktop on the client and then severs the connection. The client connects to a Dell rack-mount Windows 2003 Terminal server or one of our Fedora LTSP Terminal Servers, depending on our needs.

This means that, for any given lab, I have, at most, one machine to manage, install apps on, patch, secure and otherwise babysit. This saves big bucks on time, OS upgrade licenses, Patchlink licenses, Antivirus licenses, etc. that I would have needed for every computer in the lab (assuming they were Windows desktops). I also have much greater reliability: if one of the servers goes down I just change a setting on the Tao-tc box, have the lab reboot their clients, and presto, they're pointing to one of the other servers in another building and sharing it's power while I re-ghost the dead server.

We also allow our users to disconnect from their sessions instead of logging out. This means they can come back later to any of the thin-clients in the building, log in and be exactly where they left off before. This is a godsend during power outages - the servers are on UPS's, when the power comes back on, the users reconnect to their existing sessions and no work is lost, no data is corrupted.

Granted, the thin-client scenario is doesn't work for every situation - we use high-end workstations for CAD/CAM and Video Production Labs. We also use dedicated workstations for those staff who need to sync Palms or use local USB devices, etc. but for "normal" staff, classroom and lab use - it rocks!

One Dual-processor 3.2GHz server with 4Gb of RAM can serve over 100 clients running Office at blazing speeds. Word and Exel load "instantly". You should see the look on peoples faces when I show them an empty IBM 300PL (P2 133 MHz) system net-booted to windows, and I click on Word. It invariably blows their workstations away. And because people using the Terminal Server can't install every shiny, blinky piece of software that shows up it STAYS fast. And saves me more money and headaches in the process.

The best part is that our our Mac OS X users can use RDP to connect to the terminal servers too - allowing them to use the Windows-only software with ease - instead of forcing them to give up their Macs. In fact we just did a week-long class on some proprietary Windows-only app in our iMac Lab. With the 3-button scroll-mice plugged in, they never even knew the difference; worked, like a charm.

So, yeah, you aren't going to use thin-clients for gaming and surely not at home, but in a controlled corporate or school environment, you can't beat it for ease of management, performance and cost savings.

trust your eyes, not negative comments.

[twitter]

I can't count how many times I hear on /. someone saying that X is too bulky, etc, etc. And here's Gosling saying (2 years ago) that X is headed in the direction of slim and lightweight.

People who complain about X being "bulky", "bloated" and all that are trolls. It was designed on slim hardware and designed flexibly.

The real test is to simply use it. Try Feather Linux or any of the other tiny distros out on some crufty old hardware and see for yourself. I've got a 90 MHz laptop that runs X just fine with 24MB of RAM thanks to Woody, fluxbox and other light applications. Gnome 1.4 also is snappy enough, though KDE is a little slow. X is not the problem if there is one! Feather runs even faster running testing and unstable Debian code and I suspect that two further years of going down Gosling's path is responsible. Of course newer hardware runs better and I don't have problems with things like xawtv, Xine or quake running with KDE or Window Maker on top of X.

From where I stand, I have no idea what people are talking about when they complain about X. They never say anything specific.

Re:Network bandwidth?

[be-fan]

He's not suggesting sending over huge amounts of pixel data. If the app speaks OpenGL, you can ship over the OpenGL command stream. Since OpenGL was designed to support network rendering from day 1, this can be very efficient.

Re:Really dumb, missing the point entirely

[be-fan]

How many fucking library dependancies do you need for a modern windowing system?
Quite a lot, and they are all pretty necessary.
I think you're understimating all the things that modern applications are required to do.

The windowing system should offer basic 2D and 3D functions, widgets (file selection boxes, drop-downs, radio buttons, checkboxes, crap like that),
What about ListViews? TreeViews? IconViews? What about internationalized text? Text-layout libraries? Image-loading libraries? Component libraries? HTML renderers? Interprocess-communications libraries? Event-notification libraries? Audio libraries? You can't "un-invent" all of these features. Few people want to go back to the bad-old days of poorly formatted text, apps that can only read BMP files, each app needing to reinvent stuff like PDF display and HTML display widgets, apps that can't talk to each other, apps that can't handle multimedia, apps that don't notice when things in the system change, etc, etc. Doing things "quick, fast, and shitty" is a lot easier than doing things "right," but you'd be stupid to want "shitty" over "right."

They simply used Toolbox calls, and any functions that were needed beyond that were not so hard to include right in the binary itself.
What the fuck do you think the toolbox was? It might not have been a shared library (it was a widget in ROM), but it *was* a library nonetheless. It was no different than Qt is, only it can't handle HTML, internationalized text, etc, etc.

client side libraries

[CaptnMArk]

He is mostly right.

The one problem is there though: by using lots of client side libraries with their own per-client state some efficiency is lost and startup time increases greatly.

We are already seeing this with today's gtk and kde programs that already have disastrous startup times.

[mark@silver mark]$ time xterm -e exit

real 0m0.111s
user 0m0.066s
sys 0m0.007s

[mark@silver mark]$ time gnome-terminal -e exit
Bonobo accessibility support initialized
GTK Accessibility Module initialized
Atk Accessibilty bridge initialized

real 0m0.311s
user 0m0.203s
sys 0m0.032s

[mark@silver rxvt-unicode-3.3]$ time src/rxvt -e exit

real 0m0.052s
user 0m0.004s
sys 0m0.003s

The machine is Athlon XP 2500+ 1G RAM, no swap, Fedora Core 2.

Bad idea

[haraldm]

This concept kills the concept of thin clients and X terminals - that are way more in widespread use than most people think.

Letting the app take care of its own window borders is a bad idea as well. This is one of the worst parts in M$ Windows - once an app hangs, there is no way of closing or minimizing a window or simply of getting it out of the way. It's way better to have this handled by a separate process.

Re:New windowing system from scratch?

[IamTheRealMike]

Gosling basically described DirectFB so if you like this sort of idea, go hack on that.

However, I'd suggest talking to various people in the industry first - people tend to get lots of misinformation that sounds correct but actually isn't by reading random stuff on the web (and slashdot). See the remarks about Office preloading above - doesn't happen.

So the design of X it turns out isn't actually a serious bottleneck on performance. If you do profiling runs and such, you find that having everything co-ordinated by the X server isn't a serious speed problem and that much larger issues are things like having to read from the fb to do XRENDER blending (or was last time I checked).

Basically, before going "wow yeah, right on!" I suggest you do a lot of research into the design of past and present windowing systems - what sounds intuitively right often isn't.