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

[shfted!]

True, but in that case, the users would notice a decline in their computing experience, versus a potential (and very real) increase by centralising resources. Take another example: When you reboot a stand alone client, very rarely is the program image for say, the word processor, already in ram. Thus, when the user starts the program, he or she has to wait for the program to be loaded into RAM. Compare this to a centralised system, where another user has likely used the word processor recently, and so the program is already loaded in RAM -- making the launch take a fraction of the time for the second user. This has everything to do with making the user experience better, not worse.

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

[be-fan]

The problem is that in any client/server architecture, you're going to need *some* sort of protocol. How else would you do it? And you can't ditch client server, because:

a) History shows that it's rarely the bottleneck (eg: fast GUIs like QNX and BeOS are client/server);
b) There is no other good place to put it --- kernel space is too dangerous.

So once you've defined the binary protocol between apps, it's a tiny step to make that network transparent while you're at it.

Re:Good idea

[be-fan]

Oh, btw. The X protocol will probably outlive Xlib. XCB aims to speak the X protocol, while fixing Xlibs shortcomings. So if we had standardized on Xlib, we couldn't have replaced it with XCB today.

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

[ipfwadm]

I wasn't advocating preloading all applications. And I really didn't intend for this to degrade into a discussion of pre-loading apps. Maybe I should have thought of that before mentioning Word. 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.

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

[Anonymous Coward]

It depends on what people take advantage of flexibility - users or application authors.

Application authors are users. Drop the "I'm better than everyone else because I can't code applications" attitude. Or the "I'm inferior because I can code applications" attitude. Both are pathetic.

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.

Re:Good idea

[gnuman99]

X was overly focused on the juicy technical aspects of the day (like networking) and stopped short of providing an application-ready windowing system.

Instead, focus on delivering 1) a rock-solid, high quality API and 2) a great-looking, high performance implementation for the common case - an app running locally on a PC.

Common case for X? Local PC? WTF are you talking about. X was designed for UNIX servers during the days when "Local PC" didn't even exist. I'm *very* glad that X is such a flexible and bullshit-free protocol. That's why you can have different desktop environments be it KDE, Gnome or even stuff like blackbox.

I had yet to crash X by passing some null value or whatever to the Server. Windows API, on the other hand, "solid" as you imply, craps out when you start passing NULLs to it. Heck, you can still crash the entire box by passing some weird numbers to the right functions!

Sorry, I'll take the simplicity and flexibility of the protocol over any copy&paste or drag&drop "standard".

Re:Good idea

[shfted!]

Right. There's absolutely nothing wrong with, say, sending OpenGL down the wire and have the client's graphics system render it. :)

Re:Good idea

[Short Circuit]

He said it worked great. I think he started out trying to look "cool."

It's funny how many places still use text-based systems. Autozone is one example. Blockbuster does it too.

The latter was an interesting discovery, because the clerk preferred to type in the commands, rather than hit the shortcut keys. And she was a pretty quick typer.

Network bandwidth?

[daVinci1980]

One problem is his treatment of remote windows... He suggests sending them over as video streams.

If networking bandwidth is a problem now with the X format (which is basically just sending clicks and so forth), why does he think the response is going to be any better when sending *a huge ton of pixel data*?

Even if you assume that you only have to transmit differences, there are still cases where the difference will be several megs. (For example, a fullscreen clear in 1600x1200x32).

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.

pixel pushing for remote connections?

[DataPath]

His idea of making remote connections a highly compressed pixel stream doesn't excite me - it seems less than ideal.

I would think that you would want to stream, when possible, rendering api calls, so that you can send pixel data as pixels, vector data as vectors, and 3d surface and texture data as such.

Maybe have a method for negotiating what rendering api's are supported, stream those, and then render the rest as pixels and push those.

My intuition tells me that doing so would make remote connection streaming a lot more efficient. Maybe someone with more knowledge than me can explain why this would/wouldn't be a good idea.

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:X is moving in this direction

[be-fan]

Where? You mean OpenGL over a network link? It'll probably take more bandwidth than the regular X stream, but mostly because it'll lead to graphically richer apps. In any case, OpenGL was designed for network rendering, and there are very efficient network protocols for GL command streams.

Really dumb, missing the point entirely

[JessLeah]

"His design is to make the window system do the absolute minimum and move all the work into the client."

This is ridiculous. Look, ALL modern software has gotten so incredibly bloated and complex that it's just a joke. What we need is a windowing system that adopts the concept of Apple's old "toolbox"-- windowing functions and basic graphical functions AS PART OF THE CORE SYSTEM-- without the horrible kluge that I've heard "classic" Mac OS coding was. The concept was nice, though.

Look at GNOME, KDE, Windows XP. It's fucking ridiculous. How many fucking library dependancies do you need for a modern windowing system? Have you ever run 'ldd' on a modern GNOME or KDE app? It's enough to make you vomit.

It shouldn't have to be so fucking complex. The windowing system should offer basic 2D and 3D functions, widgets (file selection boxes, drop-downs, radio buttons, checkboxes, crap like that), they should be efficiently and tightly coded (preferably in C, with some ASM for speed on common architectures, and in the most CPU-intensive crap like 3D).

Look at what the Amiga was able to do with a 680x0. Sure, it had some custom chips too, but it was still a 680x0-- and modern CPUs are so fast that those extra chips are no longer necessary. With an old Mac Plus, it would take maybe a minute to boot up System 6... and with a modern Windows XP or RedShat/Fedorka box, it takes... maybe a minute. And this is progress? Also, most programs for System 6 required how many libs? Count 'em... YES, THAT'S RIGHT: ZERO! They simply used Toolbox calls, and any functions that were needed beyond that were not so hard to include right in the binary itself.

Simplicity, people. What we need is simplicity. For most tasks, a P4 running XP "feels" no faster than a '386 running Windows 3.0 in '386 Enhanced Mode did.

And that is sad...

Re:Really dumb, missing the point entirely

[Anonymous Coward]

Well, what the problem *really* is isn't so much that People Are Making Bloat, but that Bloat Is Made To Solve Certain Percieved Problems. In the older days, everyone wrote their own GUIs if they wanted them - OR they used the single included toolkits.

But now neither choice is considered applicable. We want a unified desktop that's also infinitely customizable, so that you choose a theme or default fonts or whatnot and it goes everywhere automagically.

This massive chain of desktop environment dependencies is some attempt to do everything for us. It's silly, of course.

The better solution would probably be not to integrate the "desktop look&feel" from the ground up, with unified configurations and whatnot, but to build every app from the ground up, with its OWN look and feel, using whatever kind of libraries they want to. The best apps will offer extensive customization so as to make unifying the environment a matter of having an appropriate theme for everything.

I guess there could be some amount of crossover in configuration settings, but what exists today in Gnome and KDE feels overextended. It's no wonder they're so bloated.

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.

Re:Really dumb, missing the point entirely

[mike_sucks]

JWZ once said about Mozilla bloat: "Mozilla is big because your needs are big."

People demand a lot from their desktop these days, so their desktop does a lot of things. It can take a lot of code to do it all. Sure, you may get smaller binary sizes and no library dependencies writing everything in assembly, but a) it's infeasible and b) the desktop would lack most of the features people want.

But you're missing the point. Ever done an ldd on X or an Xserver? That's what Gosling is talking about.

Using this new windowing scheme with have little/no effect on existing clients because they will still use some toolkit like GTK to do their windowing and widgets. It's not like that client developers would have to write their own widget set for each client, they will still use GTK or Qt or whatever, just like they do today.

What will need to change is the toolkits themselves.

If you had actually RTFP you would see that he was advocating a windowing system that was even more simple what you suggest.

Re:Really dumb, missing the point entirely

[TheInternet]

With an old Mac Plus, it would take maybe a minute to boot up System 6... and with a modern Windows XP or RedShat/Fedorka box, it takes... maybe a minute. And this is progress?

The question is could most the average consumer realistically replace their current machine with a Mac Plus? I believe the answer is no. Why? Because there are lot of things that weren't around in those days that we take for granted now.

Imagine trying to tell people that they can no longer use 24-bit color, watch videos, play MP3s, surf the web, render PDFs, use instant messages, compose home movies, download photos from their camera, create DVDs. Do you think it would work? :)

Obviously all this code has to go somewhere and has to be loaded at some time. And don't forget about internationalization and accessibility features.

- Scott

Re:Really dumb, missing the point entirely

[Brandybuck]

How many fucking library dependancies do you need for a modern windowing system? Have you ever run 'ldd' on a modern GNOME or KDE app? It's enough to make you vomit.

You're talking about windowing systems, not application frameworks. There's a difference. Using ldd on this currently running Konqueror process, I see the following "windowing system" dependencies: KDE, Qt and X11. That's it. And most of KDE and Qt are NOT part of the "windowing system".

Most of the libraries you see in the ldd are part of X11. Don't consider them extra dependencies just because X11 has been split. The dependency is still just one X11 package (not counting fonts).

Don't place stuff like expat, jpeg, fam, libc and the like under the "windowing system" category. And leave off the app framework libraries of KDE. They're going to be used by your application no matter what the underlying windowing system is.

if I made a windowing system...

[mcovey]

it would have a control panel, and every app would have to register with it, so it's all central (of course they can link to their part of it from tools>options or whatever. There would be one toolkit, so everything would always look the same. there would be a quicklaunch menu like on windows, where the overflow becomes a menu. There would be good support for hotkeys, drag and drop, and an overall common look and feel. I think windows comes closest to this, but the lack of the ability to theme explorer without hacks sucks, and of course it's windows. I wish someone would write an explorer clone for linux.

Re:if I made a windowing system...

[dbIII]

it would have a control panel, and every app would have to register with it

This is impractical, and doesn't happen anywhere.

Look at MS Windows - if you go into add/remove programs you will see a few things listed. Do a find for *.exe *.com and other executable extensions. You find a few hundred more applications that are not listed there, many stand alone like ntbackup, cmd and tens or hundreds of others. Now consider a *nix system, which has the philosopy of lots of little programs that do one tiny job well. How are you going to list all of those? The best that's done is to list the commonly used things, taken to extremes with MS Windows XP where it lists recently used programs and hides the rest.

I wish someone would write an explorer clone for linux

I think the gnome people are on it - right after they do a windows registry clone and a talking paperclip.

The problem with any explorer clone is that if it looks like MS windows and sometimes acts like MS windows it will confuse when it sometimes can't act that way because the underlying system is so different - even things as trivial as people looking for a C: drive. We have to make things as usable as possible but still make it obvious to people that they are not on an MS windows system with all the assumptions that come with it (file extensions, ejecting CD's and all the rest).

Re:if I made a windowing system...

[BenjyD]

I think you're confused about what a Windowing System is. The windowing system is just the part that handles the drawing of client apps to the screen and moving them around, nothing else.

Astonishing that Gosling is getting things wrong..

[Anonymous Coward]

Since the advent of Quartz Extreme, the "clip list" should be a thing of the past. There's no application level support for clipping. There's barely Kernel support for CLipping. It's all 3-D graphics card clipping at this point. The "refresh event" should be a thing of the past by 1996, much less 2004, despite any Plan 9 patents.

Clip list for mouse events, sure. But for screen refresh? In 2004? I thought this was already a dead issue!

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.

Re:client side libraries

[CaptnMArk]

Exactly my point!

By running all this behavior (accessibility) independantly for all clients you have lots of overhead.

The above time is a second/cached run (w/ prelink). For the first one, it takes 4+ seconds while rxvt and xterm are still 1.

This encourages big/monolithic applications which is not the unix way.

note: rxvt I also listed has unicode support and eye candy can be enabled too. There's no need for configuration gui to run on startup.

Short-sighted design

[Dwonis]

From the article:

I would make the "window system" so minimal that it is almost non-existent. Each graphical application gets direct access to the hardware, and a window is nothing more than a clipping list and an (x,y) translation. I would build a "device driver" that did nothing more than manage the clipping lists and hand out graphic device ports. This might actually be best done at user level, rather than a device driver, using shared memory and semaphores.

The last thing we need is a new design that allows arbitrary user programs to have read/write access to the entire screen (read-only access is bad enough). Sooner or later, we are going to start running arbitrary programs on our computers in a secure sandbox environment that is enforced by the OS (and ultimately, the CPU). What happens when some cute little game your spouse downloaded yesterday decides to make itself look like your electronic banking program? Under this architecture, how do we avoid that? Hack every display driver in existence? Trust the shared library to prevent this?

Re:Quite frankly I wouldn't let him design a windo

[Panaflex]

I guess you never heard the NeWS have you?

Pan

Re:WHAT'S WRONG WITH PDFs?

[Mycroft_VIII]

Actually I haven't seen acrobat on a windows install cd yet. I also can't recall the last motherboard drivers cd that didn't have it.
That said pdf is EVIL INCARNATE a simple 15 page document suddenly becomes a 4 meg monstrosity trying to be a 'book' in a medium where it's inapropriate. That is a pain to navigate, and you can't cut and past sections from it most of the time so you can have just the part you need in a small usuable text file.
Needless to say I equate putting docs in a pdf file on par with most of the other stuff PHB's do with tech they don't understand.
Sorry for the rant, but I just spent an hour downloading docs in 4 pdf's averaging 3 megs+ each that would have easily fit (images included) in less than a meg in any other format and been more usefull as well. The smallest was 164k, 3 pages, no images.

Mycroft

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:Bad idea

[julesh]

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.

Huh? If an app hangs in MS windows, I find clicking on the window's close button results in an "Application not responding -- do you want to kill the process?" dialog box popping up. Whereas X tends to cope really badly with hung clients, generally requiring you to use an entirely different command (e.g. "kill window" rather than "close window", although the names vary according to your window manager) to get rid of such windows.

Re:Bad idea

[Sax Maniac]

If your app doesn't respond to commands, you kill the process. I mean really, how often do you expect your applications to hang?

All the time. Let's say I do mass-scale operation in Finale that's going to take a lot of time - extracting all 25 parts from a score and grinding them all out to disk. It's going to take a few minutes, where the application window goes dead.

Sure, I could kill the process, but that wouldn't give me the desired results, would it?

It would be sure nice to be able to minimize the !@#*&$!@# window when it does this, and go do something else.

Re:Bad idea

[argent]

You render to a servers back-buffer, and transmit it over the network to the client.

Bitmap scraping. Been there, done that, got the bad rendering, latency, crummy feedback, etcetera. By making heroic efforts and badly compromising the user experience you can actually make it more network efficient than X, but you completely blow the feedback you need for end-user efficiency.

The usual scenario is that when you click on an object the application's idea of what the UI looks like is completely different from what's actually there. You can prevent that from happening in X by having the display server aware of where the objects are and delivering the events to them, but in a bitmap scraper that information never gets all the way to the display... so where in X you can dependably click on an object as soon as it appears, in a screen scraper you have to wait to make sure it's stable and not going to go away in the next update.

I've used them all, and unless you have a really fast network so you can keep the updates coming they cause too much human-computer latency to be worthwhile.

how often do you expect your applications to hang

Unless you have an infinitely fast processor every application goes through periods where it's unresponsive for a few seconds now and then, and a lot of applications can hang for half a minute or more. In Windows, you might be able to kill these windows, but you can't minimise or move them until the app comes back.

Look X11 is a baroque architecture

Indeed, and there are much better designs, but taking all the problems that X has and making them bigger isn't the direction to go... but it's the direction Gosling seems to be suggesting.

As for where we should go from here... there are a bunch of alternate window systems out there and some have come quite a long way. Look them up.

Consistency

[Bluelive]

To have consistent looking application you still need to do everything in the server. Adding more layers like is now happening with X and GTK or one of the other packages, is one way of doing that. And moving this to the server instead of the client makes it all abit faster because less data has to be moved long distance

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.

Re:All the mistakes of X, made worse

[jaoswald]

Gosling is not discussing the details of widgets, etc., which make up the (hopefully consistent) USER EXPERIENCE of a graphical user interface; instead, he's concerned with the low-level plumbing which lets multiple applications share the screen and mouse, without having to be aware that other applications have windows which might be overlapping one's own. These problems are totally different, and mostly unrelated.

The widgets that make up the GUI of each application, as well as the lowest-common-denominator graphics tasks could be provided by a single system-wide library that every application would use, to ensure consistency. Gosling is only thinking about how this library would send colored bits to the screen and get mouse clicks from the user.

Quartz doesn't enforce a single user interface, as Apple's own "interface of the year" adventures demonstrate.

Re:Don't remember who it was...

[FooAtWFU]

XML is verbose, yes. That's why anyone sensible uses it as a mere file format and pipes it through gzip or something when loading and saving.