X11 Chrome Reportedly Outperforms Windows and Mac Versions

An anonymous reader writes "In a curious contrast to conventional wisdom, there are reports of X11 Chromium being faster than Windows or Mac versions. In the thread titled 'Why is Linux Chrome so fast?,' a developer speculates that it is due to the use of X11 capabilities: 'On X-windows [sic], the renderer backingstores are managed by the X server, and the transport DIBs are also managed by the X server. So, we avoid a lot of memcpy costs incurred on Windows due to keeping the backingstores in main memory there.' Has the design of X11 withstood the test of time better than people tend to give it credit for?"

Comments

Test of time

[Anonymous Coward]

"Has the design of X11 withstood the test of time better than people tend to give it credit for?"

Yes of course it has. X11 is great and anyone who thinks otherwise doesn't understand it properly, or have an accurate idea of what it's genuine problems are actually due to.

Re:Test of time

[eugene2k]

Why is this modded funny?

Re:Test of time

[Yvan256]

Forget about the gp, why is THIS modded funny?

Re:Test of time

[supersloshy]

And God forbid that I continue the joke and say, "Why is /THIS/ modded funny!?"

Re:Test of time

[Tetsujin]

Forget about the gp, why is THIS modded funny?

Because if you say "why is this modded funny" and "this" isn't modded funny, then people get confused...

Re:Test of time

[rhyder128k]

He means that the pioneers who started X development did so on massive 22" mono monitors that gave out a lot of rads.

Re:Test of time

[Anonymous Coward]

This is not funny.

Re:Test of time

[Yvan256]

I know!!!

Re:Test of time

[awshidahak]

Ooh, ooh, I wanna be cool and popular. Why is /THIS/ modded funny!?!?!?!?!?!?!?. Dang, where's the confused smiley button.

Re:Test of time

[cloudkiller]

you guys are hilarious.

Re:Test of time

[KZigurs]

Sir, you managed to say it with a straight face. Hat off to you!

Re:Test of time

[Tetsujin]

you guys are hilarious.

We certainly think so. XD

Re:Test of time

[Thinboy00]

you guys are hilarious.

Why isn't this modded redundant?

Re:Test of time

[dave87656]

X11 is great

I think it is a great design and considering it stems from the 60's if I remember correctly as an MIT project it's pretty amazing.

However, I remember coding my first Xt project in the 90's and I remember two things: it was extremely fast and extremely difficult (as in Low Level) to program. Of course, noone really programs real-world applications with Xt directly anymore.

Re:Test of time

[mahadiga]

So X11 was designed for future software.

I read the article. So sue me.

[LizardKing]

Interesting comment from one of the developers:

We could also just move process creation to a background thread. An unused process might just get swapped out and be no cheaper to "make live" than it would be to create a new process.

Surely this reusing of a process would negate the supposed security benefits of Chrome/Chromium's multi-process spawning architecture?

Re:I read the article. So sue me.

[Anonymous Coward]

We could also just move process creation to a background thread.
Ok, that's just making the process and subsequent address space.

An unused process might just get swapped out and be no cheaper to "make live" than it would be to create a new process.
It sounds like process just being put into a pool - the process creation thread is holding onto the handle - and when someone wants a new process, the thread just hands over that one presumably the heap and stack for that process would be cleared.

I don't see where there could be a security issues - but, then again, it's been 15 years since I worked on an OS, let alone an Intel based one; I have only 1 cup of coffee in me; I'm still drudging through the posts in the "article".

Re:I read the article. So sue me.

[mea37]

I guess maybe I'm making bad assumptions, as I don't really know what Chrome's intent with multiple processes is... but I think the answer to your question is no, it wouldn't necessarily impact security and certainly wouldn't fully negate the multi-process approach's advantages.

The major advantage to keeping separate tasks in separate processes, it seems to me, is that they have separate memory spaces. I can't sneakily inject code into another task's buffers if I'm not in the same process. In particular, if the browser spawns a process to execute some plug-in or whatever, there's less risk that the plug-in or whatever can trick the browser into executing malicious code. (Or cause it to crash, but that's more "stability" than "security".)

In other words, the biggest security risk comes from two processes sharing the same process at the same time. I don't think re-use is as big a problem. Sure, if you did a bad job of wiping buffers, then in theory one process could see its predicessor's data; and I guess there are scenarios where that could be an issue, though I'm a little skeptical that a malicious process would go rooting around its uninitialized space "just in case" it was handed a process with something it would recognize as sensitive data from a previous task...

Re:I read the article. So sue me.

[kLaNk]

...I'm a little skeptical that a malicious process would go rooting around its uninitialized space "just in case" it was handed a process with something it would recognize as sensitive data from a previous task...

Why are you skeptical? That is exactly what a malicious process would do in that case.

Re:I read the article. So sue me.

[mea37]

Why am I skeptical? What kind of question is that?

Describe a practical attack based on that principle, and I'll be less skeptical.

X11 Chromium on Mac?

[Danathar]

Does anybody know if it's possible to compile a version of Chromium for X11 Mac?

Re:X11 Chromium on Mac?

[Anonymous Coward]

Right now the Chromium download page only supplies Linux and Windows versions:

http://www.reptilelabour.com/software/chromium/download.htm

Re:X11 Chromium on Mac?

[An anonymous Frank]

+1 Very Interesting

Yes please! Pretty please?!

Re:X11 Chromium on Mac?

[leamanc]

Why not grab the source code, install gcc from your OS X Developer Tools disc and try it for yourself?

Get the source here

Re:X11 Chromium on Mac?

[remmelt]

Are you aware of the Chrome (not Chromium) binaries?

http://dev.chromium.org/getting-involved/dev-channel scroll down to Mac and download the dmg.

Re:X11 Chromium on Mac?

[eggnoglatte]

Probably, although maybe with some effort. But you won't get anywhere near the same performance, since on the Mac, X11 sits on top of other libraries, rather than directly on the hardware. That is how it integrates with the native GUI.

Re:X11 Chromium on Mac?

[Tetsujin]

Does anybody know if it's possible to compile a version of Chromium for X11 Mac?

What, seriously?

Maybe things have changed over the last few years but I couldn't stand the poor integration of the X server into Mac OS X... it's one of the reasons I moved away from the Mac platform and back to Linux... Bad clipboard support, bad window list integration, troublesome keyboard shortcuts... It's like Apple went out of their way to make X11 apps uncomfortable.

Re:X11 Chromium on Mac?

[cloudkiller]

yes. check out http://build.chromium.org/buildbot/snapshots/

Re:X11 Chromium on Mac?

[AtrN]

Try here.

Re:X11 Chromium on Mac?

[DaVince21]

Why don't you just try?

Re:X11 Chromium on Mac?

[badkarmadayaccount]

They did.

Re:Windows and OS X versions, please.

[jedidiah]

No. It's MacOS 10. OS X is just stupid intentionally confusing terminology.

We already had a GUI called X. It was around for about 20 years before Apple decided to start it's Microsoft-esque nonsense.

X11 has never been a problem.

[miffo.swe]

X11 has never been a bottleneck in performance on the desktop. Many people have been confusing X11 with the desktop system/kernel/applications and wrongly blamed X11 for any slowness.

Re:X11 has never been a problem.

[jellomizer]

So you are saying it is not X11 that is slow but Linux... Oh man you are taking it out of the frying pan and into the fire.

Re:X11 has never been a problem.

[miffo.swe]

No, im saying that X11 is fast and not a bottleneck, not that Linux is slow. The slowest applications on Linux is non native applications like OpenOffice, Firefox, Azureus and the like. Native apps are mostly fast and nimble.

Re:X11 has never been a problem.

[nicodoggie]

?? Firefox is a non-native application on Linux? How exactly is it non-native? It's compiled by gcc for the platform isn't it? I agree that OpenOffice and Azureus and loads of other Java-based junk are god-awfully slow though... (Firefox is too, but AFAIK it's Linux-native)

Re:X11 has never been a problem.

[pz]

X11 has never been a bottleneck in performance on the desktop. Many people have been confusing X11 with the desktop system/kernel/applications and wrongly blamed X11 for any slowness.

Yes, exactly. X11 ran reasonably complicated applications 20 years ago on hardware that we throw out as woefully inadequate (or quaintly archaic) today, and did so with entirely acceptable speed. X11 isn't the problem -- hardware is what, two orders of magnitude faster now? -- it's all of the poor programming practices that have layer upon layer of abstraction and interpretation stacked tall and high.

I had a 266 MHz laptop in the mid 1990s (about 15 years ago) that ran Linux (RedHat 6.2, mostly) and X11 perfectly well with a mere 64 MB of main memory. A while ago, I tried to load a Fedora release (9, if I recall correctly) on it. "Laughable" is a good term to describe the result. My current laptop has a 10x faster processor and 50x more memory. There's more cache on the processor in my new laptop than total system memory on the old one --- And yet, Fedora 11 feels sluggish on the new hardware. X11 is not the problem.

Re:X11 has never been a problem.

[MemoryDragon]

Yeah sure because every layer of indirection is faster than direct ram access... sorry
But I still after 10 years am not convinced about the design. X11 follows the design philosophy of enforcing
a methotology (remoting on drawing level) which is needed by about 5% of its users and thus burdening a layer
of complexity on top of the rest of 95% users who then have to deal with shoddy drivers.
Heck even the remoting does not scale well enough that it is usable without tricks for modern UIs out of the box.
Unless you use athena widgets or third party hacks you wont even get remotely the performance RDP or even plain VNC has.

Re:X11 has never been a problem.

[domatic]

I think he means applications where Linux or a BSD is the primary development environment and those APIs were the target. Agreed it is a sloppy use of "native". In the case of Firefox, XP is a the primary dev environment and it also benefits from Profile Guided Optimizations when compiled. The Linux port could in principle but the work hasn't been done (and probably won't be).

Re:X11 has never been a problem.

[LWATCDR]

I never thought that X11 was slow. My problem with X windows has always been that it was too fragile and complex. A lot of features of X seemed to be over kill for use on a standard desktop.
I never felt X11 as too slow just that it tended to break way to easy.

Re:X11 has never been a problem.

[Enderandrew]

This is the one gripe about X that I can understand and get behind.

Wayland is not designed to be network transparent, nor do remote rendering. I'd rather have a system like that.

Re:X11 has never been a problem.

[MikeBabcock]

To be fair I think the gp meant Linux exclusive, not native. But even then Firefox is a pretty bad choice, since its development has always had Linux in mind as well as other platforms.

If you benchmark some random 3D games between Linux and Windows there is no Linux slow-down. If you benchmark the responsiveness of a well written GUI environment on Linux vs Windows, there's no slow-down. In fact, I've only rarely run into a situation where Linux is slower than Windows in a GUI or otherwise. The primary reason I've come to realize is lazy programmers writing slow client software, and in some cases, horribly inefficient GUI toolkits (Gtk, I'm looking at you).

X11 isn't the bottleneck, and ever since a few tweaks were done for desktop users, the Linux kernel isn't either.

Re:X11 has never been a problem.

[Anonymous Coward]

people should be blaming B-Bus, GNOME and GTK+ for performance issues of Linux desktops, not X11.

Re:X11 has never been a problem.

[OrangeTide]

memcpy of 1000s of bytes is slower than sending a message. Many of these systems that provide direct access to RAM require lots of copying too. (OSX one example I'm most familiar with)

X11 also supports direct access to memory, but it is only used in very specific circumstances because it's extra work to set up.

Re:X11 has never been a problem.

[OrangeTide]

B-Bus? don't you mean D-Bus?

Re:X11 has never been a problem.

[Anonymous Coward]

Naaaaaah, he means B-BUS, you funky honky!

Re:X11 has never been a problem.

[Elbows]

I've never had performance issues running X11 over a LAN. VNC, on the other hand, is noticeably sluggish (RDP seems to work well though). I don't run apps over a WAN very often, except for the occasional emacs session (which is a bit laggy but useable).

But more importantly, the X style of remote access is much, much more useful than VNC/RDP. Remote apps integrate seamlessly into my desktop, instead of being stuck in a separate window. And multiple people can run remote apps on the same machine, without interfering with each other or a user who's physically sitting at the machine.

VNC and RDP are useful hacks for systems that weren't designed for remote access, but they're no replacement for real network transparency.

Re:X11 has never been a problem.

[thePowerOfGrayskull]

The problem is that when monitoring processes, people can "see" X11 using CPU cycles, whereas in Windows they only "see" the application doing. It's six of one, half dozen of the other -- but it makes it look like X11 is CPU-resource intensive. In reality, the same cycles are used for windows based apps (perhaps more? I certainly don't know...), but they look like the app using the CPU which is somehow more expected.

Re:X11 has never been a problem.

[DrXym]

X11 isn't a bottleneck by itself since at its heart its a very basic API. But therein lies the issue. For it to be any use it must run a raft of extensions (for 3D, multiple displays, fonts etc.), and then layers of widgets and libraries on top, and a window manager too. Then on top of that you have the "desktop", GNOME or KDE which might run a pile of periphery processes to handle messaging, virtual file systems, automount, screen saver and other tasks. And everything is at the mercy of gcc for its generated code size / speed, and the kernel for timeslicing and prioritisation.

It means it is wrong to blame X11 since there is plenty to go around. However, it wouldn't hurt to imagine a world without X11 running *under* the desktop and what possibilities it might open in terms of performance or development cost if it weren't. X11 could run over the desktop as it does on other operating systems.

Would it be better if X11 died? I don't know. But it would be interesting to find out.

Re:X11 has never been a problem.

[itsdapead]

X11 has never been a bottleneck in performance on the desktop.

Has rendering speed ever been an issue with X11? If I had to criticize X11, I'd point at "responsiveness" to clicks and drags (making the desktop feel a bit "clunky" c.f. Windows/Mac), rather than any problem with how fast it could render a window - it only takes a small lag or a badly chosen movement threshold to destroy the illusion of dragging tangible things around a destop.

Also, issues like easily switching resolution and handling multiple screens sensibly - I'd say that distros like Ubuntu are just about caught up with where Mac and Windows were 15 years ago, although partly that's down to waiting for Gnome, KDE etc. to provide friendly interfaces to what could be achieved with a bit of xorg.conf hacking.

The other thing I find slightly disaapointing is that many modern apps and Gnome/KDE desktops don't work very well in conjunction with X11's USP: network transparancy - I've only really had adequate results using xnest - but then again, that's a fault of window managers and desktop suites, not X11.

Re:X11 has never been a problem.

[jedidiah]

I've never seen the rendering layer as the problem.

The real problem always seems to be total system resources and
the ability of the underlying OS to juggle competing demands on
these and multitasking.

Do io waits cripple the system? Can it the system run at 100%
CPU usage well? Is it easy (or automated) to manage process
priority? Are background jobs prone to cripple interactive
programs? Does the given hardware have enough resources to run
the OS at all?

Re:X11 has never been a problem.

[dpilot]

No thanks. I use network transparency routinely at work and at home. I have no problem whatsoever with a fast-path, direct-rendering, or whatever for the console user, and applaud (and use) such efforts.

But network transparency is just too useful to get rid of. Think of the clouds!

Re:X11 has never been a problem.

[JesseMcDonald]

The thing is, X11 gets network-transparency essentially for free. The system requires some sort of inter-process communication, even when running on a local machine, and Unix-domain sockets are one of the fastest IPC mechanisms available short of shared memory (which is orders of magnitude harder to get right). X11 supports shared memory for local processes, to speed up communication of large objects like pixmaps, but the core protocol is socket-based and there is absolutely no reason to change that. So long as this is the case, why not support network transparency? BSD network sockets are interchangeable with Unix-domain local sockets once the connection has been established, so it's not like there's much more effort involved.

Re:X11 has never been a problem.

[Microlith]

VNC and RDP give you the ability to interact in an explicitly remote sense, the windows in question operate on the remote server instance and will remain in existence regardless of what happens to the local system.

That's one reason I stopped using X11 forwarding even though I could: If I lost connection on my laptop for any reason, every application I had open was dead. With VNC (or RDP), they were always running remotely.

Also, if I have an application open on display :0 I have no way (that I know) of moving it from :0 to :10 and having it appear uninterrupted on my local display.

I'd say that they're extremely useful hacks that solve issues that are, at least for me, unresolved in X11.

Re:X11 has never been a problem.

[H0p313ss]

That's one reason I stopped using X11 forwarding even though I could: If I lost connection on my laptop for any reason, every application I had open was dead. With VNC (or RDP), they were always running remotely.

Also, if I have an application open on display :0 I have no way (that I know) of moving it from :0 to :10 and having it appear uninterrupted on my local display.

Amen brother.

Random but related question to the "experts": Is there no way to "suspend" an X session and allow it to reconnect later? It would be a truly killer feature.

Re:X11 has never been a problem.

[jeremyp]

Yes, exactly. X11 ran reasonably complicated applications 20 years ago on hardware that we throw out as woefully inadequate (or quaintly archaic) today

But that was in an environment where the average PC had a 640x480 display with 16 or maybe 256 colours. High end workstations had higher resolution but were often monochrome. The X server simply didn't have to do anywhere near as much work as a modern one.

Re:X11 has never been a problem.

[eugene2k]

You do understand that the amont of code executed to implement IPC through unix domain sockets equals to an observational error compared to the amount of code even a simple GTK+ "hello world" application executes, right?

Re:X11 has never been a problem.

[miffo.swe]

Firefox is very much not a native application for Linux. Its primarily developed for Windows and then ported to Linux just as its predecessor (netscape) was. The only "linuxy" about it is that it happens to be using the GCC toolchain and compiles on Linux.

My main problem when managing terminal servers with Linux on them is applications that isnt developed primarily for it. Putting worldwide settings in /etc would be a good start. Arcane and broken registrys, XML files and sprinkling the filesystem with settings all over /usr/lib/ is not what i call a linux adapted application.

Re:X11 has never been a problem.

[gbjbaanb]

ok, so we've upped the requirements from 640x480x8bpp to 1280x960x32bpp. That's 16x as much data. Networking has increased from old 10mbps coax cables to gigabit networks in the same time. That's 100 times as much. Processors, RAM and graphics accelerators are similarly increased (gfx tremendously so), so I'd expect performance to be roughly on par with those old systems at the minimum.

Re:X11 has never been a problem.

[Hurricane78]

Have you tried using the same window manager as back then, running the same programs, and especially killing all background programs / daemons that weren't there back then?

Because else, you're comparing apples to oranges.

Re:X11 has never been a problem.

[that this is not und]

Why are you referencing the average PC of 20 years ago, which ran Windows 3.1, not X11, to the average workstation from back then, which the GP referred to as 'woefully inadequate' today? Did you know that there were actual framebuffer cards back then in typical use that cost more than your '386-DX 25 with 16MB of RAM' that all the secretaries were impressed by?

Re:X11 has never been a problem.

[TheRaven64]

And this is a typical X11 criticism: a comment based on a complete lack of understanding of how a modern display system works.

Every modern operating system enforces isolation of processes both from each other and from the hardware. With something like Apple's QuickDraw, this isolation was bypassed at the drawing level; applications were allowed to write directly to the frame buffer. No modern systems - including Windows and Apple's Quartz - work this way. Each application opens an IPC connection to a display server which handles drawing commands. With X11, the communication goes via a mixture of UNIX domain sockets and shared memory. With Quartz, it goes via Mach ports and shared memory.

The only difference between how X11 implements this and how Quartz or the Vista display server implement it is that the protocol used via the serial channel that X11 uses is well documented. This means that, rather than using local IPC, you can use remote IPC such as a TCP (or SCTP these days) socket with exactly the same code that you use for local communication. This means that your remote display code path is almost as well tested as the local one (although you don't get shared memory and you have protocol overhead from TCP/IP so it's slower).

Re:X11 has never been a problem.

[that this is not und]

I pity you, then, that you've never operated in an X11 environment running in cinerama mode. I had a multi-headed Sparcstation 10 running Solaris like that a number of years back, and it was nice.

solve issues that are, at least for me, unresolved in X11.

You surely don't want X11 to devolve into something like VNC, do you? Really?

Well maybe you do. Clue us in, does Steve Ballmer really have bad breath?

Re:X11 has never been a problem.

[TheRaven64]

Extensions are not a problem. Extensions are how the protocol evolves. Complaining about X11 extensions is like complaining about the overhead of using libc functions that were not part of K&R C. Complaining about needing widget sets and window managers is complaining about modularity. You need all of these things on any windowing system, but with X11 you have a separation of policy and mechanism so you can easily replace parts independently when they are too dated or when they don't fit with a particular device. Look at a system like Maemo; it runs X11, but with a window manager designed for small screen devices. You can run any X11 application written since 1984 on this system, either compiled to run locally or displayed remotely from any system that it's run on in the last 27 years.

Re:X11 has never been a problem.

[JasterBobaMereel]

That's because VNC and RDP assume you have a fast network connection.... and X11 assumes you have a 96Kbaud dial up line ....

Re:X11 has never been a problem.

[JamesP]

I've never had performance issues running X11 over a LAN.

VNC and RDP are useful hacks for systems that weren't designed for remote access, but they're no replacement for real network transparency.

Oh no you don't!

Try using X11 over something slightly slower as LAN. Just try it, over ADSL, whatever

I tried. And X11 is totally and utterly USELESS. A well configured VNC (and you have to really play with the knobs) is usable. RDP is the best (of course, it wasn't developed by Microsoft...)

Re:X11 has never been a problem.

[celle]

"Heck even the remoting does not scale well enough that it is usable without tricks for modern UIs out of the box."

Maybe the problem is with the "modern UIs" don't you think?

Re:X11 has never been a problem.

[Alpha830RulZ]

Hm-m-m. You might want to fiddle with your VNC connection. I run many VNC sessions over LAN/WAN combos. On LAN, it's as fast as console, as near as I can tell. On LAN/WAN, it's a bit sluggish, but quite usable. I often VNC from home, over comcrap, through the VPN, through the company netowrk, over a busy T1 to an office, to the machine I'm working on, and it's usable. Not stellar, but quite usable.

Re:X11 has never been a problem.

[gknoy]

I must agree. It would be awesome if one could have a "screen"-like functionality with X. For all I know, it's already there, and I just don't know how to use it...

Re:X11 has never been a problem.

[Bigjeff5]

The modular nature multiplies the number of potential bugs by an order of magnitude for each layer. I.e. if the Client/Server model of X11 were merged into simply the X11 renderer, GUI applications would be an order of magnitude easier to write. It isn't too bad for X11 because it isn't that big or all that complicated, but the client/server nature of X11 creates the potential for a lot more bugs.

The biggest example of the bug problem with modular systems is the GNU HURD kernel. It is modular, I believe it has 4-5 parts that must work in unison to function, and in 20 years Stallman and his group have yet to produce a working kernel. Compare that to Torvold's Linux kernel, which was integrated and took a couple years to develop pretty much by himself.

Part of the problem with X11 is that it is NOT a complete package - it's the "last mile", so to speak, and you need three or four more layers to get a modern desktop. If you make an honest comparison of a complete desktop package based on X11 that matches Windows Vista/7 or Mac OSX and there is no question as far as quality. The X11 based setup is harder to use and generally less useful than the Windows or Mac counterparts. Incidentally, I've used OSX the least but found it the easiest to pick up - good design counts.

Re:X11 has never been a problem.

[MemoryDragon]

Guess what the same applications ran probably better on a C64 using GEOS... the reason why X11 performed 20 years ago was that the applications if they did graphics at all used the athena widget set, so basically all they did was to draw a few circles. The issue with X starts as soon as you do more it severely shows that it does not scale up too well especially on the networking side.
Most other UIs simply went for higher level drawing primitives and added networking later with better results.

Re:X11 has never been a problem.

[MemoryDragon]

The issue is that the network transparency is utterly useless on modern UIs everything beyound Athena Widgets, or a plain xtern simply clogs your network in no time if you use it from more than one client server connection.
The protocol simply is too low level to scale. Sure there are solutions which fix this, but this needs to be fixed in the core protocol. And yet this layer of indirection makes it harder for everyone, the driver authors have a harder time, the users have to fight with a more complex configuration and shoddy drivers.

Re:X11 has never been a problem.

[sarhjinian]

No, he wants it to evolve into something like Citrix XenApp, where high-latency doesn't completely screw the experience and, if you lose connection, you can reconnect at a later time.

Rootless remote applications are a nifty X feature, but for most people, they're not helpful, not when the death of your connections takes your running apps with it.

Re:X11 has never been a problem.

[Anonymous Coward]

Don't use X11 raw over remote links. Use NX. It meets your criteria from start to finish and actually brings to X11 the things you talk to with actual performance, when compared to the others.

Re:X11 has never been a problem.

[bill_mcgonigle]

layer upon layer of abstraction and interpretation stacked tall and high

yes, especially how well each layer optimizes. There was a good article by a KDE dev a few months ago lamenting that KDE rarely ever runs with the acceleration it's capable of due to what's assumed and what's implemented at each layer.

Re:X11 has never been a problem.

[MikeBabcock]

I've not had a problem with any of those areas in the modern era of Linux use. Have you?

I run 3D games on my system at high frame rates while it simultaneously downloads with Vuze and serves music and videos to the PS3 for my wife.

'sar' shows me that there's a lot of task switching going on, and a lot of activity, but it never seems to have any effect on productivity.

Re:X11 has never been a problem.

[JesseMcDonald]

I agree; there are issues with the core protocol, or at least with how it is used. In particular, interactivity is not ideal when high-latency connections are involved. Some of that is the toolkits—the protocol is designed to be asynchronous, but many recent toolkits don't take full advantage of that design. That works fine when the server is local, but doesn't scale otherwise.

However, once these issues with the protocol and toolkits were resolved the result would still be based on Unix-domain sockets, and so would still naturally support network transparency. The only way to eliminate the "indirection", as you put it, would be to integrate the clients into the same process and codebase as the server; in every other case you will have an indirect interface of some sort. Integrating the clients into the server is obviously not a general solution; you would lose all the benefits of a modular design: privilege separation, independent development, transparency, etc. However, so long as the client and server are separate processes there is no reason not to support network transparency.

Re:X11 has never been a problem.

[asdfghjklqwertyuiop]

Using X that way is also a MUCH bigger security risk than VNC or RDP. The remote machine to which you're granting access to your X server can read all the keystrokes you type (wether they're to the remote app or not) and take screen shots of the whole display, etc...

Re:X11 has never been a problem.

[Anonymous Coward]

What are you talking about? I was using X-forwarding from the University back to my dorm in 2001, simply because the machine I had at home was faster than what the U had to offer. My (adsl) connection was 512kb/64kb at the time (may have been 128k up), and my applications ran flawless.

Any chance you had enabled MIT-SHM over your wan connection, or any one of the other X extensions that were really intended to only be used when client and server were on the same PC?

Re:X11 has never been a problem.

[JesseMcDonald]

I.e. if the Client/Server model of X11 were merged into simply the X11 renderer, GUI applications would be an order of magnitude easier to write.

What are you proposing, exactly? The client is the GUI application. Merging "the Client/Server model" into the X11 renderer would mean integrating the GUI application (rather, all GUI applications) into X11's codebase and runtime address space. This is obviously impractical. However, so long as the GUI applications remain separate processes there must be a client and a server and the only question is how they communicate, to which socket-based IPC is the obvious answer.

I'm all for removing unneeded middle-layers; a general rule-of-thumb in Unix software design is that anything over three layers is too many. However, shifting the boundary between "client" and "server" by merging the toolkits into X11 (as seems more likely to have been your intent) would not eliminate the need for IPC or the possibility of network transparency. It would also force the overhead of a GUI toolkit on applications which have no need for it; for example, most games just want an empty window to draw into and receive events from, and couldn't care less about the standard system widgets.

If you make an honest comparison of a complete desktop package based on X11 that matches Windows Vista/7 or Mac OSX and there is no question as far as quality. The X11 based setup is harder to use and generally less useful than the Windows or Mac counterparts. Incidentally, I've used OSX the least but found it the easiest to pick up - good design counts.

That depends entirely on both your prior experience and what you're trying to do with the interface. I've used all three myself. Good design does count, which is why I honestly find most Unix interfaces to be easier to use and more useful than either Windows or OS X.

There are multiple reasons, but the main one is simple: Unix applications are designed as modular tools, with clean interfaces, and in particular are designed to the integrated with other tools in ways their designers never imagined. Good up-front design thus ensures that you are not limited by the interface-designer's imagination. Windows and Mac OS applications, on the other hand, are generally designed as complete, stand-alone interfaces, and are not scriptable or extensible. There are some exceptions, but they are exactly that: exceptions. To be fair, Mac OS does have a better track-record in this regard than Windows, but neither approaches the separation between engine and UI which is a staple of Unix software design.

Re:X11 has never been a problem.

[Homburg]

The issue is that the network transparency is utterly useless on modern UIs everything beyound Athena Widgets, or a plain xtern simply clogs your network in no time if you use it from more than one client server connection.
The protocol simply is too low level to scale

Bollocks. Largo, Florida runs about 300 users on thin clients over X, with all the latest Linux UI stuff, like GTK and Compiz. Yes, the fancy 3D desktop cube works just fine over networked X11.

And yet this layer of indirection makes it harder for everyone

No, this layer of indirection is necessary whether or not you want network transparency. All modern OSs, including Windows and OS X, use an IPC mechanism in their graphics subsystem.

Re:X11 has never been a problem.

[JamesP]

Any chance you had enabled MIT-SHM over your wan connection, or any one of the other X extensions that were really intended to only be used when client and server were on the same PC?

Probably... :) I don't remember looking into the issue too much... Probably ssh -X, then running the app...

Still, considering what other people commented, I would still use VNC.

(But 90% can be done over ssh, so...)

Re:X11 has never been a problem.

[richlv]

you could only say that rdp is the best if you haven't heard of nx.
building on top of x, it is really, really great.
and with the added coverage that neatx (google developed nx server) brought, i'm surprised you don't know about it...
http://www.nomachine.com/.

Re:X11 has never been a problem.

[ClosedSource]

"The thing is, X11 gets network-transparency essentially for free."

It's everything else you pay for.

Re:X11 has never been a problem.

[ClosedSource]

"There are multiple reasons, but the main one is simple: Unix applications are designed as modular tools, with clean interfaces, and in particular are designed to the integrated with other tools in ways their designers never imagined."

You mean like being integrated via binary instead of ASCII?

Re:X11 has never been a problem.

[ClosedSource]

Gee, what's the infatuation with sockets?

Re:X11 has never been a problem.

[P-Nuts]

The closest thing to screen for X11 that I know about: xpra. A bit rough around the edges, but usable.

Re:X11 has never been a problem.

[ClosedSource]

So X11 and TCP were developed in the same ecosystem so they play well together. Luckily for X11, other computing ecosystems adopted TCP instead of something else.

Re:X11 has never been a problem.

[rrohbeck]

If VNC is usable, you'll love NX. It is *far* more responsive for a given bandwidth/latency and it is persistent too (the session keeps running if your client disconnects.).

You can even run VNC to other machines through NX and it feels faster on limited bandwidth (NX creates a session on the Linux client that runs a fullscreen vncviewer to another system.)

It's my standard way of working remotely. My default work desktop lives on a Linux machine at the office and it resizes automatically depending on what screen size the client uses (as long as your Gnome or KDE version is recent.) Even at the office I run NX to my work session - over a LAN I can't tell the difference between local and NX.

Re:X11 has never been a problem.

[TheRaven64]

TCP is completely irrelevant to X11. By default, X uses UNIX domain sockets (basically equivalent to named pipes) and shared memory for communication between the client and the display server. The shared memory is optional and the socket can be replaced by any stream, including pipes or TCP sockets.

Re:X11 has never been a problem.

[PastaLover]

Has rendering speed ever been an issue with X11? If I had to criticize X11, I'd point at "responsiveness" to clicks and drags (making the desktop feel a bit "clunky" c.f. Windows/Mac), rather than any problem with how fast it could render a window - it only takes a small lag or a badly chosen movement threshold to destroy the illusion of dragging tangible things around a destop.

There's definitely some problems with some graphics cards with some drivers in some configurations. Usually the proprietary ones when they fail to implement the correct subset of the fancy API du jour. This is traditionally blamed on the graphics card companies (ATI, Nvidia, Intel,...) but there comes a point where you have to wonder why they all seem to be struggling to put out something halfway decent. And don't see "developer resources", that's just a cop-out and you all know it.

If X isn't crap for you that's nice. But it's failing for a lot of other people and has been for a long time. It's good to see it's improved in certain places (i.e. configuration) but I can't believe people are claiming it's better than anything the competition has. It hardly inches any of them out.

Re:X11 has never been a problem.

[tbuskey]

Yes, exactly. X11 ran reasonably complicated applications 20 years ago on hardware that we throw out as woefully inadequate (or quaintly archaic) today

But that was in an environment where the average PC had a 640x480 display with 16 or maybe 256 colours. High end workstations had higher resolution but were often monochrome. The X server simply didn't have to do anywhere near as much work as a modern one.

I was running on a 486 with 1024x768 and 256 colors using and ATI VL-localbus card in 1993. 8 MB RAM. The graphics were faster then the Sun Sparcstation 1+ at work with the same resolution. Compiles & multitasking were slower.

People were doing less work. Instead of OpenOffice, I had LaTeX. sc for a spreadsheet (or Excel 4 on Windows). Xfig ran fine. Emacs 18.59, pine, kermit, ghostscript. olvwm, xclock, xload.

Re:X11 has never been a problem.

[JesseMcDonald]

Well, what would you suggest instead? I already stated that the only IPC mechanism with better performance is shared memory. Given that shared memory involves a great deal more complexity, synchronization issues and deadlocks being only the most obvious drawbacks, resorting to it without trying sockets first is a case of premature optimization.

Re:X11 has never been a problem.

[sootman]

Random tip: if you just want to run a single app from the remove machine, ssh -XC
The X tells ssh to forward X and the C means compress. One particular app I used to run (connecting from anywhere to my Linux box at home, which was behind a 256k up DSL) launched in 30 seconds with -X and 10 seconds with -XC.
Of course, different people's definitions of "usable" differ. :-)

Otherwise, I hear good things about http://freenx.berlios.de/ .

Re:X11 has never been a problem.

[JesseMcDonald]

What? Binary or ASCII, it makes no difference. Unix programs tend to use ASCII because it makes the communication transparent; humans can see what's going on, interact with the program for debugging or testing without learning specialized tools, etc. That, however, is orthogonal to the modularity aspect.

Please, just read the book: The Art of Unix Programming. It explains all these issues. I don't have the time or the inclination to teach you every lesson learned during the development of Unix in a comment thread. Suffice it to say that to someone used to working with applications designed with the Unix design philosophy in mind, working with Mac OS or Windows applications often feels like putting on a straitjacket.

Re:X11 has never been a problem.

[ClosedSource]

"Unix programs tend to use ASCII because it makes the communication transparent; humans can see what's going on, interact with the program for debugging or testing without learning specialized tools, etc."

Humans can read ASCII because there are tools designed to read it. Because people have been using these specialized tools to read ASCII for so long they forget that ASCII is just an old convention like the QWERTY keyboard.

"I don't have the time or the inclination to teach you every lesson learned during the development of Unix in a comment thread."

I don't recall asking you to teach me anything. Perhaps you should look into pre-UNIX computing history to broaden your perspective.

Re:X11 has never been a problem.

[ClosedSource]

"I already stated that the only IPC mechanism with better performance is shared memory."

Isn't that really a question of implementation? Why should sockets necessarily be faster than pipes for example?

Re:X11 has never been a problem.

[Thetawaves]

Do you suggest that everybody writes in raw xlib? I do not think the distinction you are trying to make is relevant. Abstraction of some kind will always be necessary. Nobody wants to write in raw xlib.

Re:X11 has never been a problem.

[VisceralLogic]

At one point around the same time frame I was browsing the web using X forwarding from a university over a 56k modem because my parents' AOL was broken!

Re:X11 has never been a problem.

[timeOday]

The sad thing is X isn't even any good for what it was designed for - remote display. It's just too slow, even on a WiFi lan connection. VNC and Windows Remote Desktop, though hacked on after-the-fact, work far better in any situation, other than perhaps a wired LAN. (But even then I use vncserver instead; you can disconnect and reconnect to a session, and access from cross-platform clients). By default, most distros don't even configure X to listen for TCP connections anymore. And very few developers access the Xlib API anymore, it's too primitive.

Take that away and what problem does X actually solve? Letting you draw rectangles and pixmaps? All the real UI design work was simply passed along, and has finally, sort of, been done in the last few years.

Re:X11 has never been a problem.

[timeOday]

the X style of remote access is much, much more useful than VNC/RDP.... multiple people can run remote apps on the same machine, without interfering with each other or a user who's physically sitting at the machine.

Actually VNC for linux does that too ("vncserver"). Or, if what you wanted really was remote control of the console, it supports that too, via x11vnc.

Re:X11 has never been a problem.

[Btarlinian]

Oh no you don't!

Try using X11 over something slightly slower as LAN. Just try it, over ADSL, whatever

I tried. And X11 is totally and utterly USELESS. A well configured VNC (and you have to really play with the knobs) is usable. RDP is the best (of course, it wasn't developed by Microsoft...)

That's not a problem with the architecture but with the protocol. Have you ever used FreeNX? It's amazingly fast in comparison to VNC and even RDP.

Re:X11 has never been a problem.

[anon mouse-cow-aard]

Yes, exactly. X11 ran reasonably complicated applications 20 years ago on hardware that we throw out as woefully inadequate (or quaintly archaic) today, and did so with entirely acceptable speed. X11 isn't the problem -- hardware is what, two orders of magnitude faster now?

20 years of Moore's law is 2**10 == 1024 so ... three orders of magnitude.

Re:X11 has never been a problem.

[deek]

Actually, I've run X11 over a 33k modem. It was a little sluggish, but quite usable. Maybe it depends on the application you're running?

I didn't even use something like FreeNX or nxproxy, which is designed to compress and streamline X11 connections over slow links.

Re:X11 has never been a problem.

[BikeHelmet]

So you are saying it is not X11 that is slow but Linux... Oh man you are taking it out of the frying pan and into the fire.

He's correct. Look at Gnome/KDE/XFCE. Some of these are billed as "optimized" and "lightweight".

Yes, they run fast on fast hardware. But boy do they use a lot of RAM!... and you wouldn't want to run them on an old P3 if you could avoid it.

Then compare to something like LXDE. You lose a lot of GUI goodness, but memory and CPU usage drop like a brick. I use LXDE for all my servers that need a remote desktop. (which right now is just one :P )

Re:X11 has never been a problem.

[mr exploiter]

Who modded this informative? You can also see CPU cycles consumed by the kernel in windows, just open the task manager and look up the "system" process. And based on the responsiveness of windows vs X I doubt its "the same cycles" or more.

Re:X11 has never been a problem.

[h4rr4r]

You have fun with that, the rest of us, who do real work need ssh -X to actually work.

Re:X11 has never been a problem.

[consonant]

Red Hat 6.2 was released in 2000, IIRC. I know I installed a spanking new Red Hat 5.8 on a 266 MHz P-II desktop in 1998. Something doesn't quite gel - could it be the hyperbole in the pursuit of making a point?

Re:X11 has never been a problem.

[man_of_mr_e]

The only difference between how X11 implements this and how Quartz or the Vista display server implement it is that the protocol used via the serial channel that X11 uses is well documented.

That's a very broad statement to make. While it's true that all three systems use some form of IPC, you are completely glossing over the efficiency of the protocol for various purposes. OSX and Windows can basically change their protocol whenever they want to improve efficiency on new hardware. X11 doesn't really have that luxury and is largely confined to a protocol developed for ancient displays (which works pretty well in most situations). But let's face it, having the ability to change your protocol when you see fit gives you a huge advantage. Even being able to design your protocol with modern knowledge is a huge advantage.

Yes, X11 works quite well for being a 30 year old system, and there have been lots of extensions grafted on to help modernize it. But it's still a bit like a frankensteins monster where the Doctor says "Yeah, those scars are an advantage, what are you talking about?"

Re:X11 has never been a problem.

[mahadiga]

X11 has never been a bottleneck in performance on the desktop

MicroXwin doesn't think so.

Re:X11 has never been a problem.

[icebike]

Complaining about needing widget sets and window managers is complaining about modularity.

Well you had me till the above sentence.

X is fine.

But the modularity of the widets, window managers, GTK, decorations, Desktops, display managers, etc culminaing in KDE or XFCE4 or Gnome ends up as a mind numbing separation of roles that no one really understands any more, and a construct that has outlived its usefulness.

Several of those layers could, and arguably should be flattened into something that we recognize as as Gnome or KDE.

These days the user interface is held hostage by too many layers under separate development, separate release cycles, and occasionally shoddy integration.

When it works well, its very nice, but it is still pretty fragile if you ask me.

Re:X11 has never been a problem.

[TheRaven64]

Yet another criticism from ignorance. X11 had an extension mechanism built in to it from the start. Every X11 message starts with a tiny header which indicates the type and size of the message. This makes it trivial to add new features to the protocol. You don't think encapsulating OpenGL command streams was in the protocol from the start do you? Or compositing, rendering to off-screen buffers, antialiased text, 32-bit RGBA visuals, notifications when the screen resolution or rotation changes, and so on were in the protocol from the start do you? A modern X11 application only really uses the core protocol for receiving events. Almost everything else goes via extensions. The older parts of the protocol are still present, for legacy applications, but newer ones don't use them.

Re:X11 has never been a problem.

[itsdapead]

And don't see "developer resources", that's just a cop-out and you all know it.

No, its the closed-source model - and for pragmatic reasons rather than simple FOSS ideology.

The (L|U)i?n(i|u)x OS kernels and X window system are in perpetual development and lack stable binary APIs. The best way of supporting that is to release the source so that the FOSS community and distro producers can share the responsibility for maintaining it and building binaries. Trying to support numerous distros and multiple kernel and X versions via a binary release is a hugely inefficient way of supporting what is currently a minority market, c.f. a massive Windows market with only a couple of "active" major OS versions - with 5-year shelf-lives - to support. Frankly, I'm surprised that they bother.

Personally, I think its time that the (L|U)i?n(i|u)x ecosystem pulled itself out of perpetual alpha and settled down to a much longer release cycle. However, even if you like the "realase soon, release often" model, it doesn't mix well with closed source binaries.

If X isn't crap for you that's nice.

If you want true network-transparent graphics (not just a remote desktop), X is in a class of its own - although if you do just want a remote desktop then VNC-type solutions seem to cope just-as-well, if not better, with eye-candy laden desktops.

For a personal desktop, X just seems massivley over-engineered and also fails in one vital respect that hasn't been mentioned yet:

Windows and Mac each provide a standardised GUI that strongly encourages consistency between applications. Forget psychobabble about the desktop metaphor or visual cognition: I think that a major reason why the destop GUI initially succeeded was that suddenly all the applications did the basics - like saving and opening files, copying, pasting, setting preferences - in the same way at a time when competing application software houses were trying to copyright the "look and feel" of their ideosyncratic text-based menus. X doesn't do this (to be fair, that was never supposed to be part of X) and although Gnome/KDE have taken on this job, the earlier attempts at window managers and desktops seemed to have a design philosophy of "I can't conceive of any UI finer than the un*x shell and vi/emacs, but I do want to run 8 instances of XTerm on something that looks as cool as NeXTStep".

Re:X11 has never been a problem.

[PastaLover]

And don't see "developer resources", that's just a cop-out and you all know it.

No, its the closed-source model - and for pragmatic reasons rather than simple FOSS ideology.

The (L|U)i?n(i|u)x OS kernels and X window system are in perpetual development and lack stable binary APIs. The best way of supporting that is to release the source so that the FOSS community and distro producers can share the responsibility for maintaining it and building binaries. Trying to support numerous distros and multiple kernel and X versions via a binary release is a hugely inefficient way of supporting what is currently a minority market, c.f. a massive Windows market with only a couple of "active" major OS versions - with 5-year shelf-lives - to support. Frankly, I'm surprised that they bother.

That's a great theory, except for the pesky problem of explaining why the intel drivers keep breaking.

Re:X11 has never been a problem.

[incense]

RDP best? Something must've happened since I quit being a sysadmin some years ago. RDP used to be a security disaster.

X forwarding in SSH works well on ADSL (enable persistent connections on your ssh client if your ADSL modem insists on disconnecting inactive connections).

Re:X11 has never been a problem.

[thePowerOfGrayskull]

While some GUI activity is kernel level, most of it is in user-space. In my own experience, I don't see that the system process is consuming CPU during heavy GUI painting operations - it always has been the application.

Re:X11 has never been a problem.

[MikeBabcock]

My Internet bandwidth is an order of magnitude higher than you think it is. And as a professional sysadmin, my normal server bandwidth is orders of magnitude higher than that again.

My home PC runs Linux, my office desktop runs Linux and my servers all run Linux. I've got the odd saturated gigabit link, I've got drives doing file serving at speeds that make vmstat's columns go wonky, and I use I/O cards that don't cause major wait times for that data.

You may want to consider changing the disk scheduler you're using. There are instructions online.

Re:X11 has never been a problem.

[JesseMcDonald]

Pipes and sockets are probably about the same speed. The difference is that pipes only provide a single channel of communication; if there are multiple writers their messages get mixed together, and if there are multiple readers each gets a portion of the messages (or parts of messages) depending on the timing. To use pipes you would have to create a separate (named) pipe for every client, and somehow make each client open a different one (while avoiding contention). Unix-domain sockets are one-to-many; each client which opens the socket gets a separate connection to the server, so you only need to create one server socket.

Re:X11 has never been a problem.

[man_of_mr_e]

I'm aware of that, and even mentioned it in my message, which you apparently did not actually read.

You're still stuck with X11's basic protocol though, and the extensions only help with features that are entirely new. It doesn't allow the protocol for existing functions to be changed to be more efficient.

In any event, Extensions defeat the purpose of having a "standardized protocol" since it means any two X11 implementations may not be able to talk to each other properly.

Re:X11 has never been a problem.

[TheRaven64]

You're still stuck with X11's basic protocol though, and the extensions only help with features that are entirely new.

The core protocol handles event delivery and little else. The extension mechanism, by definition, is only required when you want to change the protocol. You can replace the implementation of existing message handlers (e.g. line drawing which went from unaccelerated to accelerated and back again in the reference implementation).

It doesn't allow the protocol for existing functions to be changed to be more efficient.

This comment doesn't even make sense. The protocol is not tied to the implementation. The protocol is the interface. If you can change the implementation to make it more efficient, you do so without changing the interface. If you want to change the interface to make it more efficient then the X11 way is to add a replacement interface and persuade clients to use it. A good example of this is how text rendering has evolved over the years.

Near the beginning, X clients used a font server in the X server to render text. This was bandwidth-efficient because it allowed text to be rendered just by sending the position and the character to draw. It had problems for things like PDFs, however, where the client needed to supply the font information. It also didn't make it easy for clients to provide their own fonts (e.g. an office suite comes with a load of fonts, but you needed to install them on every X server you want to use to display it).

Now the XRender extension is used for most text rendering. The client uploads the glyphs to the server and then the server composites them (with sub-pixel antialiasing) wherever they are required. This mechanism may be familiar to you if you've looked at how Apple implements text drawing: Quartz 2D Extreme introduced the same mechanism, but wasn't enabled by default until quite recently.

In any event, Extensions defeat the purpose of having a "standardized protocol" since it means any two X11 implementations may not be able to talk to each other properly.

Not at all. This was a problem in the early '90s when every UNIX vendor shipped their own X server with incompatible extensions, but now extensions are all generally prototyped in the same place and the ones people want are included with X.org. You can query an X server to find out which extensions that it supports and you can fall back to older mechanisms if they are not. For example, most toolkits that let you draw antialiased text will attempt to use the XRender extension, but will fall back to compositing in the client and then pushing pixmaps to the server if it's not present (which is still quite fast via shared memory, but much slower remotely).

The extension mechanism in X11 is very cleanly implemented, which was the point of my last post. It makes it easy for the protocol to evolve over time. If you absolutely need the latest features, then you can require them, just as you can require Windows Vista if you need the compositing support it added, but it's very easy to write fall-back support for when the extensions are not present. Most of the time, this will be abstracted away for you by the toolkit.

Re:X11 has never been a problem.

[ClosedSource]

Well, the definition of pipes varies a bit on different OS's (even among Unix systems), but certainly on Windows you can use named pipes that are message-oriented and won't scramble up messages from multiple clients.

Unix FIFOs (which can be considered a specialized pipe) also support atomic writes if the message isn't longer than the pipe buffer (PIPE_BUF). Typically a client creates a private FIFO and then sends it's path to the well-known server FIFO. Thus a one-to-many (server to clients) capability is created. See UNIX Network Programming, Interprocess Communications Volume 2, Second Edition by W.Richard Stevens, Chapter 4.

Re:X11 has never been a problem.

[JesseMcDonald]

All true, of course. Certainly on non-Unix systems you would have to find a solution other than Unix-domain sockets. If that solution involves independent, two-way communication channels, with the server side being identified by a single well-known name, you can consider it equivalent to Unix-domain sockets for the purpose of this discussion.

What you said about FIFOs is basically what I meant when I said you would need separate pipes for each client and a meta-protocol to coordinate their use with the server. Note, too, that FIFOs are typically one-way, so you would actually need two per client to replace a single socket.

Other IPC mechanisms can match sockets for speed, but none of them are faster than sockets in principle (apart from shared memory). Among those which are widely available, sockets tend to be the best match for one-to-many, independent, two-way communication. FIFOs, on the other hand, are more convenient for one-way, one-to-one communication. You can emulate either one with the other (as is true for all forms of IPC), but why not pick the one which best matches what you're trying to do?

Re:X11 has never been a problem.

[ClosedSource]

Well in the application we are talking about there isn't any need for two-way communication. Besides, if you look at Stevens' example you'll see only N+1 one-way pipes are required, not 2N pipes (where N is the number of clients).

Of course Windows has duplex pipes so it's not an issue there.

Interestingly enough Stevens doesn't consider sockets to be an IPC mechanism.

Re:X11 has never been a problem.

[man_of_mr_e]

I think you're being disingenous. Extensions have to be supported by both the client and the server.

Let's say i'm running an app written 5 years ago. My app knows how to talk to the X server using whatever was standard 10 years ago. If your new X server, via extensions, has changed the way the protocol works, the apps don't magically adjust. They still require the old protocol.

Now, true, if it's written to some intermedite X library that has changed to support the new features then that will work, but honestly the odds of that are at best 50/50 given how many different X toolkits there have been and how few of them are still actively maintained and kept mondern.

In the MacOS/Windows model, Apps talk to Quartz/GDI, so when those change to support a new model, the apps magically get those changes.

What's more, since this is a binary model, that means that the apps get the benefits without recompilation and/or upgrading to newer libraries (which may or may not be transparent.. and could require coding changes).

Re:X11 has never been a problem.

[JesseMcDonald]

Well in the application we are talking about there isn't any need for two-way communication.

What? The application we're talking about is X11, and the X11 protocol requires two-way communication. At the very least you have to be able to receive status reports back (success/failure), and there are all those event notifications (key press, mouse movement, etc.) to consider.

Besides, if you look at Stevens' example you'll see only N+1 one-way pipes are required, not 2N pipes (where N is the number of clients).

The contents of that book do not appear to be available online (and I'm not buying it just for this discussion), but from the source-code examples I assume you're referring to the fact that you can use just one pipe for all communication to the server, and separate pipes for communication to the clients. That works, but the server has no way of knowing which client sent a given message (aside from implementing some sort of ad-hoc message signing protocol itself), whereas sockets given each client a secure path to the server so that a misbehaving or malicious client can't send messages on some other client's behalf. Given that creating a socket takes about the same amount of effort as creating a FIFO, I don't see any reason to waste time mimicking sockets with FIFO pairs (even if half the pair is common to all clients).

Interestingly enough Stevens doesn't consider sockets to be an IPC mechanism.

"Oops". That's a fairly embarrassing omission for a book with Unix, network programming, and IPC all right there in the title.

Re:X11 has never been a problem.

[ClosedSource]

"What? The application we're talking about is X11, and the X11 protocol requires two-way communication."

No, this discussion is about GUI subsystems and how X11 stacks up against the others. The fact that X11 requires two-way communications doesn't mean it's essential in other solutions.

I love your statement about a FIFO solution "mimicking' sockets as if sockets were some fundamental building block rather than just one arbitrary solution out of a large set of possible solutions.

""Oops". That's a fairly embarrassing omission for a book with Unix, network programming, and IPC all right there in the title."

It's possible for anyone to make a mistake but I don't think you'll get much respect dissing Richard Stevens among Unix developers.

Re:X11 has never been a problem.

[mr exploiter]

So? The point is that is not hidden you can still have some kind of feedback on how much CPU % the application+GUI is using. Knowing how much is the application logic and how much is GUI would more difficult however, but not impossible, by using a profiler.

Re:X11 has never been a problem.

[TheRaven64]

In the Windows world, apps talk to GDI.dll. The interfaces to this have changed massively in the time X has been around. Apps using the older interfaces don't get the newer functionality and the function calls correspond quite closely to the client-server IPC.

In the OS X world, apps talk to the Quartz library and send serialised PDF commands. You may not be aware of this, but the command encoding is public and has not changed since OS X was released, it has only been extended. Quartz uses exactly the same model as X11. If you use Cocoa on top of Quartz then you will get support for some of the newer features automatically. Similarly, if you use GNUstep on top of X11 for the same code.

Your last point is complete nonsense. The Windows and OS X toolkits maintain a stable ABI. So do some X11 toolkits. If your apps use a toolkit with a stable ABI then it gets the benefit of new features on the display server on whatever the display server is.

Your comments make me wonder if you've ever actually written any code that talks to an X server.

Re:X11 has never been a problem.

[MemoryDragon]

Bollocks. Largo, Florida runs about 300 users on thin clients over X, with all the latest Linux UI stuff, like GTK and Compiz. Yes, the fancy 3D desktop cube works just fine over networked X11.

I assume they have added FreeNX or commercial NX to the mix to get the network performance. If you do that with Raw X11 then you can watch your network coming to a crawl, been there done that.
NX mostly alters the protocol on the fly and caches font information so that the overhead is reduced significantly (speaking of one packet per character sent instead of hundreds defining every pixel and its shadow)

Re:X11 has never been a problem.

[thePowerOfGrayskull]

So? The point is that is not hidden you can still have some kind of feedback on how much CPU % the application+GUI is using. Knowing how much is the application logic and how much is GUI would more difficult however, but not impossible, by using a profiler.

That's not the point I was trying to make at all. My point is pretty simple: to someone who doesn't understand how a given windowing system works, it will appear that X is very CPU hungry because they can see it using CPU while the application sits "idle" -- compared to Windows, where the application is using CPU without any indication that it's specifically performing a windowing operation. In reality, the GUI work on linux is just offloaded from the application to the windowing system - which happens to be a separate executable. But still, the perception remains: "X" is consuming CPU while on windows, there is no counterpart.

Obviously if you understand how the different windowing systems work, there's no need for confusion, as the specifics can certainly be quantified...

Re:X11 has never been a problem.

[JesseMcDonald]

No, this discussion is about GUI subsystems and how X11 stacks up against the others. The fact that X11 requires two-way communications doesn't mean it's essential in other solutions.

Any practical GUI solution is going to require that input events be communicated back to the clients. Well, I suppose the GUI server/toolkit could ignore input handling entirely, and make the clients get their input from the drivers directly, but then you need two-way communication between the clients and the input drivers instead (to handle changes in focus). And you'll get synchronization issues trying to coordinate drawing operations with sound, input, etc. if there's no indication from your GUI process back to your clients of when their drawing operations are complete.

I love your statement about a FIFO solution "mimicking" sockets as if sockets were some fundamental building block rather than just one arbitrary solution out of a large set of possible solutions.

Neither FIFOs nor sockets are fundamental. I already acknowledged that all forms of IPC are equivalent in principle, performance issues aside. You can mimick FIFOs with sockets, and sockets with FIFOs, or either one with shared memory or temporary files or.... That doesn't mean that all forms of IPC are an equally good fit for a given problem in practice, however. Given a choice between creating one socket and creating N+1 FIFOs (with N > 1), assuming they are equally fast and ignoring the fact that the socket provides more secure communication, I would choose sockets because they only require a single well-known-name and not the entire extra meta-protocol necessary for the FIFO approach. (Which is much the same reason I would choose sockets or FIFOs over shared memory, unless insurmountable performance issues made shared memory necessary.)

It's possible for anyone to make a mistake but I don't think you'll get much respect dissing Richard Stevens among Unix developers.

I'm not "dissing" Stevens; as you said, anyone can make a mistake. It's still an embarrassing omission given the subject of the book. He'd probably agree with me on that.

Re:X11 has never been a problem.

[ClosedSource]

"Any practical GUI solution is going to require that input events be communicated back to the clients."

Usually drawing is done by a different entity than processing input. Does your graphic card send you mouse notifications?

"I'm not "dissing" Stevens; as you said, anyone can make a mistake. It's still an embarrassing omission given the subject of the book. He'd probably agree with me on that."

I phrased my statement badly. What I meant is that in general I don't subscribe to the notion that we should blindly accept what a person says just because they're considered to be an expert.

So I didn't mean to imply that Stevens made a mistake and he wouldn't agree with you because he explicitly defended his choice in the preface. He wrote a whole book about sockets which makes up Volume 1 of Unix Network Programming

To be fair he differentiates between nonnetworked IPC and IPC across a network rather than claiming that sockets aren't IPC at all. On the other hand, he clearly doesn't advocate that networked IPC is a better approach for single-machine applications.

Obviously X11's approach isn't single-machine, but the question is whether that approach compromises the value of local GUI operations. This is the core of our disagreement.

Re:X11 has never been a problem.

[Homburg]

I assume they have added FreeNX or commercial NX to the mix to get the network performance.

No, they haven't, except for a small number of offsite users working over low-bandwidth connections.

speaking of one packet per character sent instead of hundreds defining every pixel and its shadow

Xft already stores glyphs on the server. The image information is transferred once for each character in each font at a given size, not for every text drawing operation.

Re:X11 has never been a problem.

[JesseMcDonald]

Usually drawing is done by a different entity than processing input. Does your graphic card send you mouse notifications?

A GUI consists of more than just drawing. You can separate drawing and input into separate processes, but a general-purpose GUI must include both, and the two must be coordinated in some fashion. That implies two-way communication. (Can you point out a single example of a practical UI with only unidirectional IPC?)

On the other hand, he clearly doesn't advocate that networked IPC is a better approach for single-machine applications.

That's fine, because Unix-domain sockets aren't networked IPC. They are only usable for intra- or inter-process communication on individual machines. They take advantage of the general socket API, but otherwise are no different than shared memory or FIFOs or message queues or whatever else he classified as non-networked IPC. The fact that they can be transparently exchanged with networked sockets, aside from actually setting up the the connection, is merely a side-benefit of using the same API. If Stevens, or anyone else, tried to claim that Unix-domain sockets aren't a form of IPC he would be wrong; they have no purpose other than IPC. I think he would recognize that.

Obviously X11's approach isn't single-machine, but the question is whether that approach compromises the value of local GUI operations. This is the core of our disagreement.

OK. So in what way are you saying that having a protocol based on Unix-domain sockets rather than pipes as a form of non-networked IPC, and trivially supporting connections from network sockets as well (with no changes to the rest of the server), "compromises the value of local GUI operations"?

Re:X11 has never been a problem.

[ClosedSource]

I'm not an expert in Unix-based sockets so I'm not aware of the difference between Unix-domain sockets and networked sockets beyond what is implied in your comment. So it would be risky to assume Stevens' detailed position based on my high-level understanding.

I can't prove the performance case and I doubt you can prove the opposite either. Yet FIFOs and Pipes continue to be used despite your belief that sockets are better.

Anyway, I don't think I have more to contribute on the subject. I've learned some things I didn't know as a side-effect of this discussion so thank you for participating.

Re:X11 has never been a problem.

[man_of_mr_e]

You're contradicting yourself. Out of one side of your mouth you claim that the protocol has been changed and enhanced over the years by use of extensions, then you say the protocol is stable and hasn't changed, thus compatibility is ensured.

You can't have it both ways.

There is no ABI for X11, unless you want to count xlib. It's a protocol. Apps (usually via various toolkits) talk to X11 through the protocol, not through an ABI in the OS.

The point, which you seem to be ignoring and spinning around, is that apps on Windows and OSX talk to an ABI supplied by the OS. The ABI is typically a link library of some kind (GDI.dll for instance) and GDI.DLL can change the way it talks to the actual display whenever it wants without the App being aware of it or needing to change.

Yes, new features have been added over the years that have new interfaces, but existing apps can benefit from a protocol enhancement in a new OS without changing the apps.

X11 has to maintain that protocol compatibility, and thus cannot change it's protocol on a whim, though it can add new features, which the apps are required to be written to know about.

Stop squirming and admit that legacy apps have to continue to use the legacy protocol unless rewritten. This protocol cannot be changed without the apps (or the toolkits) being aware ofit.

Re:Windows and OS X versions, please.

[Danathar]

Uh. Maybe you don't understand what I am saying....

I KNOW that MacOS 10 is OS X.

I'm asking if anybody has compiled a version of Chromium to use X11 instead of using Cocoa.

Re:Even if X is usually slower...

[Anonymous Coward]

I like how you took a bunch of graphics and video related words and threw them together in a post that sounds coherent, yet is totally wrong.

Really?

[complete loony]

From the later discussion on that topic, it seems the conclusion was that windows had a large history in the profile and may be bitblt'ing the first draw operation from main memory. Both of which have an impact on how slow it feels to the user.

20% faster on his 20% faster machine....

[Thantik]

After doing a fresh install on both systems the guy determined that it was just some sort of freak occurrence. He had one laptop with a 2.0ghz processor and another with a 2.4ghz processor and after the reinstall on both systems, VOILA...it was only roughly a 20% difference...

TFA - just keep reading further and further down the usenet post

Re:20% faster on his 20% faster machine....

[Anonymous Coward]

"X11 fanboi"? Like, seriously!?

Re:20% faster on his 20% faster machine....

[Jeremy Erwin]

Real X11 fanbois would ssh into a remote client, and run firefox over the network.

Re:20% faster on his 20% faster machine....

[Monsieur_F]

it can be very fast if you already have a local instance of firefox running ;)

Re:Even if X is usually slower...

[ArsonSmith]

Framebuffer is an unaccelerated bitmap display, X11 is an accelerated graphics layer (that can use a framebuffer)

something that writes directly to a framebuffer is going to need a lot of additional programming in order to be as fast as X11 is.

So in other words

[Anonymous Coward]

So in other words, those who programmed on X when X was the only big player are now older where you lose hair and sexual virility.

Colour me surprised.

Meanwhile X is still working better than Mac or Windows as a GUI framework.

Thing I don't get is why so many guys have a hard-on for dissing X.

Why?

Re:So in other words

[sarhjinian]

Because, from a user's perspective, it doesn't work all that well. Here's an example:

On MacOS X, it's just about impossible to get into a situation where a) video tears or flickers, or b) menus and windows can "rub out" other menus or windows (eg, you can't drag a window around like a giant eraser on Mac OS). On X+whatever, it's pathetically easy to do either. Windows is somewhere in-between the two.

To be fair to X, managing compositing et al isn't it's job---but it should be! Between X's by-design paucity of features and the number of combinations of video driver, X server, window manager and settings thereof, it's hard to get a decent, modern desktop experience. Had X been designed a little more smartly (eg, for actual people and not for computer scientists) this probably wouldn't be such a problem. Grafting things like multiple display support, accelerated 3D, video playback and now, compositing, have shown problems. Back in the day, when you could just buy IRIX (ro whatever) and be assured of a working, end-to-end X implementation this wasn't an issue. With the clusterfuck that is X.org+DRM+GEM+Mesa+KMS+GL/GLX/AIGLX+DRI/DRI2+UXA/EXA/XAA+whatever window manager is invovled, it's a crapshoot.

By comparison, again, we have MacOS X's system, which again just works, even if in theoretical terms it's a little slower. Users don't care that much about GTK benchmarks; they do care if the user experience breaks down.

The UNIX Hater's Handbook, which is a little bit out of date now, goes into the design errors of X. It's worth reading if you're wondering why X drives people nuts.

Re:So in other words

[Bigjeff5]

The UNIX Hater's Handbook, which is a little bit out of date now, goes into the design errors of X. It's worth reading if you're wondering why X drives people nuts.

The handbook may be out of date, but that section on X is just as true today as it was then. This part in particular hits the nail on the head:

(The idea of a window manager was added as an afterthought, and it shows.)

If X outperforms anything, it is by sheer luck and unexpected consequence. The planets align "just so" and for once it is the best implimentation for a particular task. It is not a common occurance. Coming to the conclusion that it "stood the test of time" based on a single piece of software is rather foolish. If X regularly out-performed Windows and Mac this would not be a surprise, but of course, it is a surprise.

Re:So in other words

[JasterBobaMereel]

The point is that while X is "an afterthought" and "badly designed" it has been fixed so well and so often by so many people (simply because there was nothing better) that it has already had all the major bottlenecks taken out of it ...

It is an afterthought in that it is stacked on top of the rest of the system rather than integrated, and it has a client server model because originally the display was normally on a different machine than the server (this is often raised as a bad design), but this can actually help to isolate it from the rest of the system so it is not dependent on it, and because it was always (on very old hardware) considered very slow, it was optimised to be as fast as possible within the design limitations it had .... this means that it is now very fast on fast hardware ....

Re:So in other words

[The Cisco Kid]

You are confusing X with a desktop/session manager. What you want is Gnome and/or KDE.

X is just a display-device-independent way of drawing crap on a screen. (and receiving keyboard and pointer input) It is not a "Desktop"

Re:So in other words

[steeviant]

On MacOS X, it's just about impossible to get into a situation where a) video tears or flickers, or b) menus and windows can "rub out" other menus or windows (eg, you can't drag a window around like a giant eraser on Mac OS). On X+whatever, it's pathetically easy to do either. Windows is somewhere in-between the two.

As a regular user of Ubuntu, Windows and Mac OS X, I'm really stunned by your claims that a modern Linux, or Windows suffers from slow repairs of damaged windows (notwithstanding the system being stuck in some legacy graphics mode) considering that the off-screen buffering inherent in such systems mean that a window can never be "caught with it's pants down", and too busy to repair a damaged window under such a system because damage and redraws is handled during composition by the windowing system. When applications become too unresponsive to update under a compositing system their windows stay frozen, but do not get "erased" by dragging another window over them. Ever.

"Tearing" of Windows during dragging is still a problem for all of these systems if somewhere along the line there's enough of a difference between refresh rates between devices and/or software. Apple have a natural advantage of being able to have control over framerate sync between the OS->driver->card, and often right through to the monitor, Windows has to deal with the problems of disparate video cards, drivers and monitors more often than OS X, and as you point out Linux has to do an even more delicate dance than Windows to get the entire graphics pipeline in agreement about such things. Having said that, all three OSes are trying very hard using mostly similar methods to keep everything at the same refresh rateto prevent flickering and tearing, and nobody's perfect.

I'm really not sure what day you were back in where dragging windows around in Irix didn't result in slow redraws over busy applications, I suspect that whatever it is you're smoking might have some fungus growing on it. Might be time to refresh your stash.

As for the UNIX hater's handbook's chapter about X11, I couldn't find anything in there that actually is still relevant. Kind of like your post really.

Back in the day, when you could just buy IRIX (ro whatever) and be assured of a working, end-to-end X implementation this wasn't an issue. With the clusterfuck that is X.org+DRM+GEM+Mesa+KMS+GL/GLX/AIGLX+DRI/DRI2+UXA/EXA/XAA+whatever window manager is invovled, it's a crapshoot.

Re:So in other words

[Bigjeff5]

, and it has a client server model because originally the display was normally on a different machine than the server (this is often raised as a bad design)

You should read that section on X the GP posted, they actually tried to use X for its intended purpose (back when that actually was an intended purpose, and had not been hacked around yet) and found it nearly useless as a remote display server/client setup compared to other setups, most notably Sun's at the time. It was arbitrarily devided into client/server (and "client" and "server" roles were reversed from convention, for some strange reason) without much rhyme or reason, which made it a bandwidth hog and meant half the graphics application had to reside on the client (the end computer the graphics, not X's retarded definition of client) anyway.

...it was optimised to be as fast as possible within the design limitations it had

Except that it wasn't. For the longest time X11 was the most bloated and slowest option out there, for remote and local applications alike. The only reason it is fast now is because hardware has moved so far beyond it that it is fast in spite of itself. It certainly isn't nearly as powerful as any other GUI system, and when you actually add on all the bells and whistles (which must be created separately by somebody else) it's still slower than anything around. Seriously, add the necessary components to make X11 match Windows XP/Vista/7 or Mac OSX, particularly a good window manager window dressing from Compiz, and you'll find almost everything GUI-based runs slower on X11.

That Chrome is an exception is shocking, and is why everybody is surprised, hence TFA.

Re:So in other words

[Abreu]

Don't include OSX in a graphics comparison. It is designed to work perfectly well with a limited subset of hardware

Re:So in other words

[sarhjinian]

I'm not confusing it.

What I am saying is that X should have been designed to provide more services than it does, and that some of the services we're trying to hack onto it are suffering as a result.

It's not so much KDE or GNOME, but Compiz/Metacity or KWin not being part of X that's the problem. The window manager should have been part of X from the get-go. So should a lot of things, for that matter.

Re:So in other words

[Tanktalus]

(and "client" and "server" roles were reversed from convention, for some strange reason)

What? Since when? I always thought that the X server was the behemoth application that ran, waiting for connections from other apps (the clients), consolidated the requests, acted on them, and responded back to those clients. You're telling me that X itself is termed the client, and those little apps that all connect to it are called servers? Yeah, that IS backwards!

Oh, hold it, that's not what you're saying at all. You think that "server" is a designation of the size of the machine it runs on, not a designation of the model of communication the application itself uses. You do realise, though, that even a "web server" (which could just be a wall wart acts as a client for DNS querying, right? That "client" and "server" are fluid terms based on what the app is doing, and not where it is?

A server responds to incoming request(s), usually from multiple sources. A client initiates those request(s), usually to a single target. That is all. X uses these terms perfectly. The application sitting on my desktop machine is the server, and the xterm I'm running on the Linux/zSeries box is the client. For this particular purpose. Of course, that Linux/zSeries box is also the ssh server that I use to connect to it in the first place, over which a tunnel is created in the reverse direction to allow that xterm to come up at all. It's not the convention that is being ignored. It's just that you're using the wrong definition.

Re:So in other words

[sarhjinian]

When applications become too unresponsive to update under a compositing system their windows stay frozen, but do not get "erased" by dragging another window over them. Ever.

I'm dragging a Firefox window over a dead RDP session right now. It's erasing the contents of the window. I've never, ever managed to do that on MacOS X and not often on Windows Vista.

If I use a compositing window manager, that problem goes away, but in it's place comes a whole new set of issues. Ever notice how common "turn off Compiz/KWin compositing" comes up when people try to troubleshoot X issues? At least Vista is smart enough to turn it off for you when the situation merits it.

"Tearing" of Windows during dragging is still a problem for all of these systems if somewhere along the line there's enough of a difference between refresh rates between devices and/or software.

On no other platform do you ever have to think about syncing refresh rates. On X, you're at the mercy of the driver and window manager. On an nVidia card you're probably ok. On a recent Intel card you might be. On ATI it's a complete crapshoot. Throw in compositing and it gets even more complex.

Meanwhile, on much of the same hardware, you could run a hacked version of Mac OS X and not see a lick of tearing or artifacting.

I'm really not sure what day you were back in where dragging windows around in Irix didn't result in slow redraws over busy applications, I suspect that whatever it is you're smoking might have some fungus growing on it. Might be time to refresh your stash.

I'm not saying that IRIX didn't do have that problem, but that, at the time, you could buy a commercial UNIX workstation and get a decently-integrated X server. The problem then was that you had to pay an astronomical sum to get the same window management performance that you took for granted on a Mac, and that a heck of a lot of tuning, testing and integration had to happen to get your (very expensive) video or 3D application to work, again, as well as a Mac.

Nowadays, you don't have to spend a fortune tog get decent X. What you have instead is that you're stuck with one card family (nVidia) or checking experimental code out of various git respositories, and even then you're not guaranteed the level of seamless video behaviour that you'd see on a Intel-based machine running Windows Vista.

I'm glad some people get decent X performance, but spending more than a little time on, say, Phoronix or Ubuntu's forums should disabuse you of the notion that everything works.

Re:So in other words

[sarhjinian]

You can run OS X on non-Apple hardware. Google "hackintosh" for a start.

I have, and it often works better than X on the same hardware. Sure, the raw performance might not be quite there, but even on hardware that Apple would spit on I get a cleaner experience. That should tell you something about the relative design strength of X.

Re:So in other words

[Tetsujin]

The window manager should have been part of X from the get-go. So should a lot of things, for that matter.

Why is that?

It seems to me that the ability to come up with new and better window managers has generally been an asset.

Re:So in other words

[sarhjinian]

I'd have expected TWM to evolve, much like the window managers of Windows and the Mac OS have evolved.

The reason we didn't do any of that years ago is because every vendor had to have their little fiefdom. HP, IBM and SGI would never have used Sun's window manager or display server extensions, and anything coming out of the open-source community just wouldn't get considered.

Now that all that's been pushed to the side I'd hope things would improve. They might, too, if the driver and window manager wars settle down and all the disparate projects get finished.

Re:So in other words

[sarhjinian]

How much of the graphical user interface evolution on UNIX has been put back because the varying WMs and toolkits?

It's better now that we're down to X.org and GTK or Qt, but years were wasted because you couldn't write an app that took advantage of, say, Display Postscript or multi-head or decent colour-correction or a given GUI toolkit without restricting your market.

For a very long time---and ending not so long ago---state of the art, cross-platform GUI toolkits on UNIX started and ended with Motif. That's horrible.

Re:So in other words

[GnuDiff]

I don't get it. Haven't seen video flickers or "rub outs" on my Ubuntu for at least 3 years... on different hardware. Is there something I should be aware/wary of?

Re:So in other words

[Paul Jakma]

The handbook may be out of date, but that section on X is just as true today as it was then. This part in particular hits the nail on the head:

(The idea of a window manager was added as an afterthought, and it shows.)

Yes indeed. Just look how stupid were the X designers to not have made TWM a core part of the protocol! </sarcasm>

It's amazing that people can quote from an old "haters handbook" straight-faced and claim X11 was designed badly, when all the points in that handbook are no longer relevant to modern GUIs, despite those GUIs still using X11! (While still supporting ancient apps using those obsolete technologies).

To me that says the X11 designers were amazingly prescient, and the commentators quoting from that handbook are quite clueless..

Re:So in other words

[johanatan]

I always thought of it this way: XServer provides display and I/O services to the client applications. Client and server may be on the same machine or not.

Re:So in other words

[Anonymous Coward]

If [OSX] just works means focusing on the minimize button, clicking on it, having it do nothing, then defocusing, refocusing and clicking on the minimize button a 2nd time to get a window minimized, then I'll stick with X11.

It must be me, but I seem to have that problem on every OSX machine I've used to date (upto SL) on a trackpad or mighty mouse...

Re:So in other words

[mrboyd]

To me a the server is the machine running the application that provide me with a service. In this case the service is running twm and mosaic and I use my "XClient" to access it a bit like I use my Mosaic to access your personal homepage on the world wide web. Why my X display is called a server while my html display is called a client is not clear to me.

Whether the direction of who open a socket first matters to define which machine is the actual server is up for debate.

Re:So in other words

[awshidahak]

My dragged windows don't tear. They wobble.

Re:So in other words

[Virak]

*drag*
*drag drag drag*
*drag all over the screen as fast as I can like an angry monkey on crack*
Nope, don't see any tearing. CLOSED WORKSFORME

Re:So in other words

[RAMMS EIN]

``On MacOS X, it's just about impossible to get into a situation where a) video tears or flickers, or b) menus and windows can "rub out" other menus or windows (eg, you can't drag a window around like a giant eraser on Mac OS). On X+whatever, it's pathetically easy to do either.''

Really? Interestingly, I've only ever seen this on Windows. Maybe it just depends on what applications you use.

``Grafting things like multiple display support, accelerated 3D, video playback and now, compositing, have shown problems.''

``Between X's by-design paucity of features and the number of combinations of video driver, X server, window manager and settings thereof, it's hard to get a decent, modern desktop experience. Had X been designed a little more smartly (eg, for actual people and not for computer scientists) this probably wouldn't be such a problem. Grafting things like multiple display support, accelerated 3D, video playback and now, compositing, have shown problems.''

While I am sure there have been problems, I think it is to X's credit that it _has_ been proven possible to add all this features all the while maintaining backward compatibility with existing software. I mean, what other display system in current use goes back to 1985? I don't know about Windows's, but OS X's certainly doesn't. Meanwhile, where X has arguably hit a few bumps implementing certain features, there are features that X has had since the beginning that Windows and OS X still lack. And while you may see a myriad of possible combinations as a Bad Thing, I see that as a strength: you can experiment with new ideas without having to replace the whole thing from scratch.

``By comparison, again, we have MacOS X's system, which again just works''

Define "just works". In what sense does OS X's display system "just work" more than X? Last I checked, code written for OS X's display system only worked on OS X. If you're lucky, it will work on multiple versions of OS X. Meanwhile, code written for yesteryear's X still works on today's X, and it can talk to X no matter of the operating system it runs on, and even to instances running on different machines. Sure, it is possible to come up with combinations of X and something that don't work. With OS X, there are very few combinations that _do_ work. But yes, if you find one, it will "just work". Just like if you find a combination of things that work with X, it will "just work".

Re:So in other words

[IntlHarvester]

How much of the graphical user interface evolution on UNIX has been put back because the varying WMs and toolkits?

For a very long time---and ending not so long ago---state of the art, cross-platform GUI toolkits on UNIX started and ended with Motif. That's horrible.

This has more to do with Unix vendors abandoning the workstation market in the mid-1990s than it does with the technology itself. If X11/Motif had received that 10-15 years of continual improvement, the situation would be far better today.

Re:So in other words

[wiredlogic]

On MacOS X, it's just about impossible to get into a situation where a) video tears or flickers, or b) menus and windows can "rub out" other menus or windows (eg, you can't drag a window around like a giant eraser on Mac OS). On X+whatever, it's pathetically easy to do either. Windows is somewhere in-between the two.

a) That is largely an issue of the video driver in use. Given the poor state of documentation on most video hardware these days it isn't difficult to understand why this might be happening. Back in the SVGA era you didn't see this happening because there was enough documentation of a standard interface to do things right. Some of this is server related as well. X was never designed to support opaque window moves. That has been grafted on in time.

b) That is something that afflicts the X.org server. You don't see these sort of compositing flaws in commercial X servers. This is not a fundamental problem with X. Just a common implementation of the server.

Re:So in other words

[wiredlogic]

back when that actually was an intended purpose

Lots of people still use X in its intended purpose. Many people in a corporate or academic environment who need to run X apps nowadays will run them on a server or compute cluster and have the display shown on their PC (Typically running Windows with Exceed or other server). Don't poo-poo that design feature just because you haven't made use of it. Everybody's hot to jump on the Citrix and VNC bandwagon these days to do what could be done with X 20 years ago.

The performance issues you see from running remote apps largely stem from the abundance of eyecandy in modern window managers and applications that have to throw a lot of pixmaps across the network to get the job done. Before this was commonplace, remote apps worked as smoothly as a local one. Actually remote apps would be even faster in the days when typical X usage involved a low power, low memory workstation as the server. That model is what X was designed for. Most workstations would be brought to their knees with swapping if you tried to run a non-trivial application locally. It isn't fair to criticize an architecture developed in the 80's that was flexible enough to still be in use today even if some design decisions would be different in a clean architecture started now.

Re:So in other words

[sarhjinian]

I think we said that: if you use Compiz or KWin, you don't get rub-out because all this is composited off-screen. (you might get tearing, if you don't have the right card and/or haven't precisely set up sync-to-blank). That's great.

Now, if you turn on Compiz/KWin, you break tear-free video playback on some cards/drivers/versions. You might also break display of accelerated 3D in a window. That's not so great.

Those of us who are complaining about tearing have probably forsaken Compiz/KWin+Compositing because we can stand a little rub-out versus video playback being shot. That you have to do this at all is kind of problematic, and the WORKSFORME (or, "get an nVidia card") attitude doesn't help. Even casual perusing of, say, Phoronix should tell you that this is a problem for a lot of people.

Re:So in other words

[octal_sio]

I completely agree.

However, that doesn't mean I think Quartz or whatever Windows uses is better. Some of the alternatives that are miles better, but unfortunately didn't catch on simply because they were a bit too late include Sun's NeWS and Plan 9's /dev/draw.

Re:So in other words

[serbanp]

Despite your low slashdot ID, you're really confused regarding X(11) matters.

X is just a protocol for network- and device-transparent way of dealing with graphical display and interacting with the pointer and keyboard. What the polygons on screen are and how they interact with the pointer are the job of a different piece of software, named "window manager". The fact that back in 1986 the designers at MIT did not deem that other piece to be critical may seem ridiculous to you but you benefit from a 20 years hindsight.

IMNSHO, the only shortcomings of the original design were the lack of real-time and sound support, but again, this was 1986.

Re:So in other words

[JBdH]

Everybody's hot to jump on the Citrix and VNC bandwagon these days to do what could be done with X 20 years ago

This is a joke, right? I tried to run a X server over an ISDN phoneline 15 years ago and it was unusably slow. That was the time a found out a little progam existed that was called vnc. VNC wasn't fast, but workable.

Re:So in other words

[Kalriath]

I'm dragging a Firefox window over a dead RDP session right now. It's erasing the contents of the window. I've never, ever managed to do that on MacOS X and not often on Windows Vista.

For RDP that makes sense- compositing doesn't happen over Terminal Services. What normally happens on Windows, is that when the Window Manager (not Aero) detects that an application has stopped responding to WM_PAINT messages, it actually swaps out the window for a special one that looks just like the last known good copy of the windows display surface. If it can't for some reason, it just dumps a plain white window with loading cursor instead.

That's actually intentional.

Re:So in other words

[timeOday]

Thing I don't get is why so many guys have a hard-on for dissing X.

I'll quit complaining after they finally get cut/paste working, which is to say, probably never.

Re:So in other words

[wiredlogic]

X wasn't meant for use in low bandwidth, high latency applications. It's meant for use over a LAN. The X critics always like to trot out their special cases where usability falls to the floor. VNC's killer feature is compression of a protocol already designed for efficient use of bandwidth. X was designed to work with rudimentary, "stupid" servers which wouldn't have the resources (RAM primarily) for significant local caching of data, something that VNC exploits in its design. This necessitated some of the extra "verbosity" in X protocol. If you want you can use a compressed X protocol today to get a usability comparable to VNC over a low bandwidth link.

Re:So in other words

[RCL]

GP probably meant that "server" role for something that draws "client"'s output is inappropriate. Consider a typical 3D game: server is what executes the game logic, and client is what paints the screen. X has it backwards, forcing remote application take a client role and initiate the connection to it, that's weird and illogical.

It would have probably make more sense if X had a server part running on the remote machine that executed the application and sent its output to a thin client part that would draw it. This way, implementing persistent sessions (e.g. changing X terminals while application is being run) would have been easier.

Re:So in other words

[inio]

Neither. The client/server confusion comes from the use common with internet/web applications. The "client" is the piece the user interacts with and the "server" has the application logic. By that user-centric logic, however technically incorrect it may be, X's names ARE reversed.

Re:So in other words

[Schraegstrichpunkt]

By that user-centric logic, however technically incorrect it may be, X's names ARE reversed.

Only in computers would you see people advocate for precise technical to be defined to be defined by non-experts.

Nobody argues about what a "normal distribution" is, or what "adaptive chosen ciphertext attack" is, but if you talk about "client/server", now everyone has an opinion.

Re:So in other words

[steeviant]

If you have to stack the deck to make a point why not just turn off the computer and say "Linux doesn't work at all".

I could force Mac OS X into VESA fallback mode, or Windows 7 into GDI mode as well. I can't see any point in continuing to talk to someone so willfully ignorant that they deliberately hobble their computer to prove something to themselves.

If you insist on running crappy old applications on unsupported hardware, the experience is going to continue sucking balls. In other news the sky is blue.

Re:So in other words

[IntlHarvester]

Servers have a technical function, but they also have a business function. Try asking your boss for a $50K "application client" system and see how that goes.

So while X might be techincally correct, it's nomenclature isn't exactly PHB-friendly.

(Speaking of which, when is the last time anyone's deployed a large-scale distributed X11 application. Has to be 10-15 years.)

Re:So in other words

[Stu22]

Thanks, now I understand. Not what you're explaining, I understand why everyone's confused by X.

Re:So in other words

[dave87656]

(eg, you can't drag a window around like a giant eraser on Mac OS). On X+whatever, it's pathetically easy to do

I just tried it on Ubuntu 9.10. No eraser effect. In fact, I haven't seen that behavior in the last 10 years. Could it be that your information is a little out of date?

Re:So in other words

[dave87656]

The point is that while X is "an afterthought" and "badly designed"

Kinda like multitasking on Windows. Okay, I know the current base is no longer DOS but NT, but the driver model is still single threaded to maintain compatibility. Or has that changed?

Re:So in other words

[cheesybagel]

Quartz is based on NeXTStep Display Postscript. Probably the closest thing to NeWS in your list.

Re:So in other words

[Mista2]

Again one of the reason I like OS X - nice gui, and if you need X11, you've got it included already, no messing around looking for a good thirdparty server to run on your desktop.
"ssh -X user@host ApplicationName" is a super easy way to get applications running on large powreful servers, and get the gui down on my netbook or mac mini. I run Scribus on my server for desktop publishing, and I have an old Compaq n800c laptop, that it pittifully slow and old, but still has a nice 16" screen. This makes a perfect X11 server for my DTP needs. As long as I have network, I can work anywhere.

Re:So in other words

[icebike]

It is an afterthought in that it is stacked on top of the rest of the system rather than integrated

Which, of course, is precisely why it has been able to survive, whereas display systems embedded in other platforms died with that platform.

It is perfectly aligned with the best practices of unix, and a design largely retained by OSX (as if that confers any special blessing).

There are as many performance gains to be realized by this method as there are drawbacks. With the advent of high performance GPUs, its only a matter of time before the entire X server is moved into the hardware on the video card, (where some say it belongs). Such compartmentalization would be harder if not impossible if it were embedded in the OS.

You are also correct that any criticisms of the past are largely without foundation with current x servers, it has been optimized and extended more than any other component of the unix ecosystem.

Re:So in other words

[flydpnkrtn]

I think (bear with me here) that the "flipped terms" with client/server stem from the fact that to run an X application over the network, you first set up a local X server and allow a client (the application you're running) to connect to your local X server.

This client application is actually running on a big honkin server across the hall that has a bunch of resources, and you're running your local X server on a puny desktop or thin client or wall wart or whatever.

See how the terms get flipped around? You run a local server in order to run a client that in reality is processing 'stuff' on the remote server across the hall....

Re:So in other words

[Tellarin]

(Speaking of which, when is the last time anyone's deployed a large-scale distributed X11 application. Has to be 10-15 years.)

Last year. Oil and gas industry.

Re:So in other words

[IntlHarvester]

Good to know, thanks.

Re:So in other words

[badkarmadayaccount]

X.org+DRM+GEM+Mesa+KMS+GL/GLX/AIGLX+DRI/DRI2+UXA/EXA/XAA

Gesundheit.

Re:So in other words

[BitZtream]

For RDP that makes sense- compositing doesn't happen over Terminal Services.

Just for reference, this is no longer true. The latest version of the RDP protocol does support compositing. You'll find this to be the case with RDP sessions to Win7 with the latest client.

Now if they'd update the freaking Mac client to use the new protocol.

Re:So in other words

[Kalriath]

I'd be happy if they updated the Mac client to support Terminal Services Gateway, and that's been out for years!

I also note that Aero is only supported when the RDC client is running on Windows 7, even with compositing. Still.

Re:So in other words

[mini me]

That is a strange way to think about client/server interaction. Even a web browser might execute some Javascript logic where the results are sent to a web server to generate a graphic. Does that mean in that case the web browser is the server and the web server is the client?

Re:So in other words

[mini me]

If the application is the server, and the display is the client, then a web browser running in X is a server. Does that make the HTTP server the client?

Re:So in other words

[mini me]

Quartz actually does not do the same job. You cannot execute Postscript code within it, for example. But Quartz does take many ideas from Display Postscript, including using a subset of Postscript features; those available within the PDF format. Maybe "inspired by" is a better way to put it.

Re:not "s"

[pe1rxq]

"X window system" not "X window"

Re:It's Chrome OS

[MBGMorden]

This doesn't say it's optimized for Linux - it says that it runs well on *X11*. X11 is used on almost all Unix derivatives, not just Linux. Most importantly though, all indications are that while Google intends to use Linux (the kernel) for ChromeOS, they have made some statements that would indicate that they likely will not use X11.

Choosing the correct abstraction layer

[FranTaylor]

If you choose your abstraction carefully, you can hide expensive details from user space.

In the short term it may not gain you anything.

But if the abstraction lives and thrives, then much can go on behind the scenes to improve the situation.

Java is another example of this: they carefully designed the language so that it would be possible to make vast simplifiying assumptions and implement optimizations that really improve performance without impacting the "other side" of the wall. Originally java was slow, but hard work behind the scenes means that your java programs run much faster now, without any extra effort on the part of the application developer.

X Windows is a great example of this. Originally we had dumb frame buffers with no acceleration at all. And yet X provides an abstraction that allows lots and lots of hardware optimizations to take place.

The Windows and OSX abstractions for the display don't provide an API that allows these sorts of optimizations to be done behind the scenes. We have incredible display hardware with awesome features that go unused in these environments because the display abstractions do not allow for them.

Re:Choosing the correct abstraction layer

[Megane]

The Windows and OSX abstractions for the display don't provide an API that allows these sorts of optimizations to be done behind the scenes. We have incredible display hardware with awesome features that go unused in these environments because the display abstractions do not allow for them.

Or maybe they do provide the API, and the non-X11 branches of the code simply didn't use them because the guy writing the code didn't know how, and it hasn't been long enough for someone else to come around and fix it?

Re:Choosing the correct abstraction layer

[FranTaylor]

"it hasn't been long enough for someone else to come around and fix it?"

It that is the case, then any such improvements are "tacked on" to the original design and by their very nature they are not going to be usable by existing programs, and they will not provide performance improvements to the system as a whole.

That's not exactly my idea of a thoughtfully-designed system.

Re:Choosing the correct abstraction layer

[Anonymous Coward]

Java is another example of this: they carefully designed the language so that it would be possible to make vast simplifiying assumptions and implement optimizations that really improve performance without impacting the "other side" of the wall. Originally java was slow, but hard work behind the scenes means that your java programs run much faster now, without any extra effort on the part of the application developer.

I'm not sure that's how I would characterize java myself. Something like this is closer to the mark: A mediocre design made optimisation of the VM rather hard (particularly in the face of concurrency). However after many years and some heroic effort, VMs are now available which can mostly mitigate the poor designs and perform well.

Re:Choosing the correct abstraction layer

[dkf]

Or maybe they do provide the API, and the non-X11 branches of the code simply didn't use them because the guy writing the code didn't know how, and it hasn't been long enough for someone else to come around and fix it?

It's difficult to write good drawing engine abstractions that work efficiently over both X11 and Win32 because the correct point to apply caches is different at the two levels of abstraction. IIRC, it's easier to start with something closer to the Win32 view and go to X11 (in an efficient way, of course; without efficiency then you can do anything you want) than the other way round, but I might be way wrong in this since I haven't done proper deep GUI work for a while now (a few years).

OSX's basic drawing model has a lot in common with Win32, but the details are massively different. In many ways, OSX is more like display postscript...

Re:Choosing the correct abstraction layer

[jedidiah]

> Originally java was slow, but hard work behind the scenes means that your java programs run
> much faster now, without any extra effort on the part of the application developer.

Yeah... that and the fact that instead of 100Mhz CPUs we now have 3Ghz CPUs.

Re:Choosing the correct abstraction layer

[MobyDisk]

The Windows and OSX abstractions for the display don't provide an API that allows these sorts of optimizations to be done behind the scenes.

That is not true. Windows GDI was designed for hardware acceleration. As an example: Circa 1998 I got an ISA Diamond Viper video card which performed orders of magnitude faster than comparable VESA cards because the drivers took advantage of the hardware rasterization. For example, dragging a window didn't redraw the window, it moved the bitmap from one place in video memory to another. Drawing/filling lines and shapes was absurdly fast because GDI offers primitives for those operations and the driver mapped those to the hardware functionality.

Those same things happen today under Windows Vista, Windows 7, and OS X. That is a big part of why the driver model changed for Windows Vista/7: Microsoft wanted to expose even more layers through the video driver to permit those kinds of optimizations. X11 would have a hard time trying to do the Windows 7 alt-tab or OS X expose features where Windows move around in 3-dimensions on the screen. X11 doesn't expose that kind of stuff.

Re:Choosing the correct abstraction layer

[jedidiah]

Isn't DRI not so much a part of X11 as it was the original Linux "community" attempt to address the functionality that nvidia came by later and fixed?

Re:Choosing the correct abstraction layer

[FranTaylor]

"X11 doesn't expose that kind of stuff."

I'm not talking about the stuff that is exposed. I'm talking about the things that are NOT exposed. X11 runs great over the network because of all the things that they chose to NOT allow the user to do.

Sure you can accelerate bit-blitting, that is really old school.

Take a look at the fundamental model. When you move a window in Windows, the app is notified and it has to respond. Try moving the window of an unresponsive app, it does not redraw because Windows is asking the app to redraw it. When you move the window of an unresponsive app in X, the window redraws because X already knows what it needs to know about redrawing the window without having to make a trip back to the application.

Those are the kinds of things that you DON'T expose. That way the driver and hardware are free to implement them as they see fit.

Re:Choosing the correct abstraction layer

[caseih]

You don't know what you're talking about. With the indirect rendering architecture in X11 right now, everything that Windows 7 does can or could be done with Compiz (if someone wanted to implement the effect). X11 provides the "stuff" to do all of what Window 7 does. Have you seen the ring-style switcher in compiz-fusion[1]? It uses major 3D-looking transformations. I use it daily. Kind of a clone of Apple's coverflow, but for switching windows. X11 indeed exposes "that kind of stuff." Before you spread this kind of nonsense about X11 in the future, please at least read up on the stuff.

There are indeed a lot of perceived and real issues in modern X11 desktops. Compiz helps with this as it reduces the redraws and makes things seem a lot smoother. Another common problem is that sync X11 events are asynchronous, as you resize a window, the interior widgets often lag behind in their redraw. I understand some time back there was work being done on a way to synchronize the redraws so that widgets in a window expand smoothly (like MS Windows and OS X does).

[1] http://www.youtube.com/watch?v=BEUf8BQB-YA

Re:Choosing the correct abstraction layer

[dpilot]

X itself is undergoing incredible levels of development and improvement. Way back when, "The Open Group" tried to say that X was "complete" with X11R6, and no more development was needed, though somehow defects and omissions let numbers start creeping in after the decimal point. IIRC it got to somewhere in the X11R6.3-X11R6.5 range. Then XFree86 took over, ramping up some innovation, though still slower than many liked. After that X.Org took over, decided it was high time for X11R7, (They did X11R6.9 as a stage to get there.) and things started moving faster.

At this point, they're redrawing the lines (KMS, DRI/DRI2, DRM) between kernel and user space to (hopefully) get a better balance speed and stability/security. They've pretty much reworked the 2D acceleration (*XA) and are reworking the 3D acceleration (Gallium3D) which will also simplify driver development. The inteface has been reworked down near the protocol level (xcb) to improve speed and memory usage. One thing I've heard talk of is "inverting" the stack to put all primitives on top of the 3D hardware, since that's where most of the hardware performance work has been done.

The next 6-12 months will be very interesting for X-Windows, but then again, the past few years have been interesting, too.

Re:Choosing the correct abstraction layer

[JasterBobaMereel]

No X11 can do Windows 7 and Vista and OSX expose features ... and does so .....

The whole point is that X11 does not draw Windows it draws tiles ... Window Managers draw windows ... and they can draw 3d glass dancing Windows on X11 without X11 caring about it ...

On Windows the layers are Driver - GDI - Application
On X11 the layers are Driver - Kernel - X11 - Window Manager - Application (there may be more ...)

The point is that you do not need to Expose the low level stuff to the application. .. just to the window manager, the application should not have to worry about redrawing itself, or resizing the window etc... it should let the window manager worry about that

Re:Choosing the correct abstraction layer

[knarf]

X11 would have a hard time trying to do the Windows 7 alt-tab or OS X expose features where Windows move around in 3-dimensions on the screen. X11 doesn't expose that kind of stuff.

Uhhhh... have you seen Compiz, Beryl, Metisse, Gnome-Shell or any of the other whiz-bang screen-flipping and warping and cubing desktops? They do run X11 apps... through an X11 extension, be it AIGLX or XGL or something similar. X11 exposes whatever you want through the use of extensions, including the stuff needed to do 3D window manipulation. It did this when Vista was still Longhorn, let alone Windows come lately annex 7...

Re:Choosing the correct abstraction layer

[Chester K]

Take a look at the fundamental model. When you move a window in Windows, the app is notified and it has to respond. Try moving the window of an unresponsive app, it does not redraw because Windows is asking the app to redraw it.

Windows has had a retained-mode graphics system for the past 3 years as long as you don't disable desktop composition.

Re:Choosing the correct abstraction layer

[Blakey Rat]

Take a look at the fundamental model. When you move a window in Windows, the app is notified and it has to respond.

How about you use a modern version of Windows and then come back?

Re:Choosing the correct abstraction layer

[ToasterMonkey]

The Windows and OSX abstractions for the display don't provide an API that allows these sorts of optimizations to be done behind the scenes. We have incredible display hardware with awesome features that go unused in these environments because the display abstractions do not allow for them.

GDI, QuickDraw, and Quartz2D are all hardware accelerated, and you'll even find GPU acceleration in frameworks above those (the functionality provided by such should embarrass X11 desktops), all the way to the compositing systems (yet again an embarrassment for X11 based cousins). How can you POSSIBLY think X11 can be optimized for underlying hardware in a way Windows/OS X analogs can't? Or that display hardware is underutilized in Windows and OS X compared to ..... X11 DESKTOPS? The complete opposite is true with 3d accelerator cards everywhere today. You have to use window manager hacks to get any extra utility from these cards at all on a X11 desktop, where newer versions of Windows and OS X have hardware/GPU accelerated rendering and compositing APIs. Where are those in X11?

Now, I can't even imagine what you had meant by "behind the scenes", or why that sounds like such a good thing to you.. sometimes change is good. In this case, it wasn't necessary for non-X11 rendering systems to utilize hardware acceleration, but GPU acceleration for one thing necessitates new APIs. X11 has outlived most of its usefulness, look at flow diagrams for X w&wo DRI, it's pretty obvious. RDP does a better job at remoting a GUI than X on the same networks - with kerberos authentication, and encryption... and sound forwarding. Wake up and smell the roses.

I'm going to read stackoverflow.com from now on. This place is getting a tad stale :\

Re:Choosing the correct abstraction layer

[ToasterMonkey]

Take a look at the fundamental model. When you move a window in Windows, the app is notified and it has to respond. Try moving the window of an unresponsive app, it does not redraw because Windows is asking the app to redraw it. When you move the window of an unresponsive app in X, the window redraws because X already knows what it needs to know about redrawing the window without having to make a trip back to the application.

Errr.. what? You can move windows without them redrawing, but if you resize it or cover portions of it, it will need to be redrawn. This is no different in X11, AFAIK. The only way around that are compositing systems, such as Compiz.

Re:Choosing the correct abstraction layer

[Bigjeff5]

Since those X11 extensions are hacks onto X11 to enable such exposure, I'd say the GP is right. X11 doesn't expose that kind of stuff.

If what you say were true, NVIDIA would not have had to hack the hell out of X11 to get decent 3d performance out of it.

I've used Compiz and Beryl, they both crash regularly and slow my laptop significantly (a couple years old, but runs Vista just fine). Gnome-Shell looks ok, but it isn't exactly out yet (you can get a preview from live.gnome.org) so it's hard to compare it. Metisse looks more like a "neat toy" than anything else, but I'm sure some people would find it useful, and if it is designed for flexibility then apps designed specifically for it could be quite powerful. Nothing I've used is as polished as Vista, or even XP, and not even close to OSX (OSX has the best desktop I've used, but I have a number of other reasons for not owning a Mac).

Beryl may have been around when Vista was still Longhorn, but in all this time it has still not managed to be a stable compositor, and most of its features aren't that useful (the 3d cube, my favorite feature, is useless beyond the "neato" effect).

Re:Choosing the correct abstraction layer

[ToasterMonkey]

Compiz is cute and all, but Windows & OS X both provide GPU accelerated frameworks to applications in addition to a compositing system wheres compiz does GPU accelerated window dressings. API? Wot API?

With the indirect rendering architecture in X11 right now

Using compiz to say X11 has an 'indirect rendering architecture' is just a tad extreme. Oh, but hey, this is /. of course, and it's the year of Linux on the desktop or something..

Re:Choosing the correct abstraction layer

[ToasterMonkey]

X itself is undergoing incredible levels of development and improvement. Way back when, "The Open Group" tried to say that X was "complete" with X11R6, and no more development was needed, though somehow defects and omissions let numbers start creeping in after the decimal point. IIRC it got to somewhere in the X11R6.3-X11R6.5 range. Then XFree86 took over, ramping up some innovation, though still slower than many liked. After that X.Org took over, decided it was high time for X11R7, (They did X11R6.9 as a stage to get there.) and things started moving faster.

At this point, they're redrawing the lines (KMS, DRI/DRI2, DRM) between kernel and user space to (hopefully) get a better balance speed and stability/security. They've pretty much reworked the 2D acceleration (*XA) and are reworking the 3D acceleration (Gallium3D) which will also simplify driver development. The inteface has been reworked down near the protocol level (xcb) to improve speed and memory usage. One thing I've heard talk of is "inverting" the stack to put all primitives on top of the 3D hardware, since that's where most of the hardware performance work has been done.

Read your second paragraph again and tell me The Open Group wasn't on to something and you should've left it as is while writing a better rendering system from scratch.
But nooooooo, no Linux userland (or otherwise) API can be stable, stable is all ooold and smeeely.

Re:Choosing the correct abstraction layer

[markbthomas]

... except that the application does have to worry about drawing itself.

Unless the app wants to look like something from 1987, it has to render all its own controls, icons, heck it even has to open the true-type font file, load the true-type interpreter, rasterise all its own font strings and send them as bitmaps to the X-server over a socket. There's so much stuff on the client-side, it's completely braindead. Just think how many times your computer loads bitstream-vera-sans.ttf. How many times should it load it? How many times does libgnome load its gnome icon cache?

Someone needs to make an XGTK extension that puts GTK object rendering in a module in the server. Then the client only needs to worry about making remote GTK objects. For example, gnome-calculator could make a display object, a dozen button objects, and register for clicks. Then all the gnome-calculator *process* needs to worry about is doing sums. It should be helloworld.c in size, not 128 KiB.

The good news is this could be done relatively easily within X's framework. The bad news it, no-one seems to care about fixing it.

Re:Choosing the correct abstraction layer

[MobyDisk]

Someone needs to make an XGTK extension that puts GTK object rendering in a module in the server.

So long as it is optional. If it isn't present, then I should still be able to run GTK apps, just more slowly.

Re:Choosing the correct abstraction layer

[dpilot]

Legacy problems.

I'd love to see X12 come along and clean everything up... as long as it has and X11 shim so I can run my old stuff that has no X12 version, yet.

Years back, I was participating in the OBERON2 discussions on Usenet. I had a very simple question: "How can I deal with legacy binary data in Oberon2?" In Modula2, or at least the variations of Modula2 that I used, there were facilities for picking apart bits and bytes, and I made good use of them. The answer from the Oberon2 people was laughable, "Tell your coworkers to quit using those legacy tools and start using Oberon2 versions." We all know how well that worked out.

Re:Choosing the correct abstraction layer

[spitzak]

Yes this is still true with Windows 7.

If a program does not call the event processing function then nothing happens when you try to raise or move the window.

I personally don't see the real problem with this, I think X11's separate window manager is a mistake. Programs should be responsible for drawing their own window borders and resizing windows (consistency is done by the toolkits). It would mean that if a program hung you would be unable to raise or move windows on X11 as well. I don't see this as being much worse than the current behavior where you can raise/move them but they don't redraw so the exposed portions are garbage.

Re:Choosing the correct abstraction layer

[spitzak]

Compiz IS EXACTLY THE SAME THING as Windows backing store and compositing window managers that allow the windows FROM DIFFERENT APPLICATIONS to be transparent and stack so you can see through them, and also so that redraws are unnecessary. I'm not sure why you think it has something to do with GPU acceleration. They are completely separate issues on both WIndows and X. You certainly can run Compiz or Windows compositing without hardware acceleration (it might be slow but it is not physically impossible).

And the link you provided says exactly the answer: the GPU accelerated API is OpenGL. It is not Compiz, any more than you use the window compositing on Windows to draw acclerated 3D in your game.

You really should get clear on what is happening rather than trying to act like you know stuff and proving you are an idiot.

Re:Choosing the correct abstraction layer

[SpinyNorman]

One thing I've heard talk of is "inverting" the stack to put all primitives on top of the 3D hardware, since that's where most of the hardware performance work has been done.

Or just forget about the X primitives and use OpenGL instead. If you use Qt then you can do this already since Qt supports OpenGL as a drawing engine as an alternative to X.

Re:Choosing the correct abstraction layer

[Guy Harris]

The Windows and OSX abstractions for the display don't provide an API that allows these sorts of optimizations to be done behind the scenes. We have incredible display hardware with awesome features that go unused in these environments because the display abstractions do not allow for them.

So what are some of those awesome features?

Re:Choosing the correct abstraction layer

[dpilot]

Don't you still need X for network transparency? Isn't that then GLX?

Re:Choosing the correct abstraction layer

[Blakey Rat]

Yes this is still true with Windows 7.

If a program does not call the event processing function then nothing happens when you try to raise or move the window.

Maybe if the program is running in some compatibility mode (there are several). I've yet to see this behavior on my machine. What happens for me is that Windows will "grey-out" unresponsive windows, but they can still be moved/focused/etc.

Re:Choosing the correct abstraction layer

[rrohbeck]

X11 would have a hard time trying to do the Windows 7 alt-tab or OS X expose features where Windows move around in 3-dimensions on the screen. X11 doesn't expose that kind of stuff.

I have a feeling that you haven't used Compiz. I'll admit that I'm no Windows 7 user, but no Windows 7 desktop effect looked new to me.

Re:Choosing the correct abstraction layer

[spitzak]

Possibly, this was tested with a program using the Win32 API.

It does seem an easy fix would be for the system to detect that there is no response for about 1 second and then make the window move. Not sure why they bothered to gray out the window and why they can't get all the APIs.

Re:Choosing the correct abstraction layer

[spitzak]

Even in Win93 backing store worked and the contents of the window were preserved if you moved other windows over it.

What I am talking about is the inability to resize, move, or raise the window of a program that is not calling the get-next-event api in WIN32.

I suspect the clams that this is fixed is due to .net using two threads, one of which keeps handling events. Or using some other API than WIN32.

Re:Choosing the correct abstraction layer

[the_enigma_1983]

I realise that what you say is how things worked for you, but on my old laptop (integrated Intel 945GMA, 1.6GHz single core cpu, 1.5GB RAM), compiz ran fine. I could do all the snazzy 3d effects, and I had no noticable slowdowns, and rarely if ever saw a crash.

I'm not sure what features are lacking from compiz when compared to OSX or Vista/7, but I find the application switchers, expose/desktop wall and window previews to be very useful, and these are things I've been using for a number of years now.

Re:Choosing the correct abstraction layer

[Eil]

As a Linux user for 13 years, I have to say that the greatest improvement in X over that time period is: I don't have to fuck with it anymore.

I became something of an unwilling expert on XFree86.conf and xorg.conf. Nowadays, I never have to touch it. And if I did try to touch it, I wouldn't know what to do since so much of it has changed or is automagically managed now.

And that's the way it should be.

Re:Choosing the correct abstraction layer

[Blakey Rat]

More likely, Microsoft is just counting on the (probably naive) hope that eventually the developers of the unresponsive software will fix their goddamned bugs, and it'd work correctly in the first place. Either way, I don't see it as Microsoft's job to make buggy software look less buggy... it's not like Windows is impatient when waiting for a response, it gives you like 10 full seconds.

Re:Choosing the correct abstraction layer

[spitzak]

No I can't blame them for not fixing this. What I can blame them for is not allowing me to make it possible to click without raising a window. It is obvious that it is physically possible as this is exactly what happens when the program does not respond, but all attempts to actually see the click (and I tried a lot) caused the window to raise.

If they did this then the Windows API would be better than X. As it is, I can still find X window managers that correctly do not raise on click (though Gnome is completely fucked up).

It does sound like it is libraries. A program running mulitple threads where the user code is in a different thread would not have this problem. Possibly that is where the reported gray windows are coming from.

Re:Choosing the correct abstraction layer

[SpinyNorman]

Yes, OpenGL on X is GLX which does bring the X benefit (and overhead) of network transparency to OpenGL. Qt also provides the OpenGL paint engine on other platforms where it's direct. But GLX has nothing to do with the XLib drawing API - it's just OpenGL which hopefully will be hardware accelerated at the server, so it does invert the graphics stack and put your (Qt) primitives on top of the 3-D accelerated API as was being discussed.

Re:Choosing the correct abstraction layer

[Wyzard]

Since those X11 extensions are hacks onto X11 to enable such exposure, I'd say the GP is right. X11 doesn't expose that kind of stuff.

They're not hacked on, you're just misunderstanding what the word "extension" means in X11 terminology. X11 extensions are named groups of commands that an X server can optionally implement. The core X protocol includes commands for checking what extensions are available, so that applications can use those additional commands when they're supported, or work around the lack of them (or just display an error message) if not.

This is a designed-in extensibility mechanism, not some afterthought kluge. Many "standard" facilities are provided through X11 extensions, such as displaying anti-aliased text (with the RENDER extension, though it can also be done in a slower way if RENDER isn't available), overlay-based video playback (with the XVideo extension), changing screen resolutions (RANDR), turning off the monitor to save power when idle (DPMS), and OpenGL (GLX).

OpenGL, by the way, has a similar extension mechanism, and that's what allowed it to support new GPU features (such as multitexturing and pixel shaders) as they were developed, without requiring a whole new version of the core OpenGL spec.

Desktop compositing in X11 is done by asking the X server to give each window an offscreen area of video memory to draw itself into, rather than drawing directly on the screen, and then asking the OpenGL implementation to make these offscreen areas accessible as OpenGL textures. The compositing manager paints the windows onto the screen by putting these textures on rectangles, applying whatever visual effects it wants to display (like the Compiz cube), using normal OpenGL drawing operations. The command to make the X server redirect window drawing to offscreen pixmaps is provided by the COMPOSITE extension, and exposing those pixmaps as OpenGL textures is done with a GLX command, GLX_EXT_texture_from_pixmap.

I've used Compiz and Beryl, they both crash regularly and slow my laptop significantly (a couple years old, but runs Vista just fine). Gnome-Shell looks ok, but it isn't exactly out yet (you can get a preview from live.gnome.org) so it's hard to compare it.

If Compiz is unstable, that's an application bug that doesn't really have anything to do with the design of X11. The compositor in Metacity (the GNOME window manager) is pretty stable (I've been using it for several years), and its scenegraph-based successor (called Mutter) is the foundation for Gnome-Shell.

Re:Choosing the correct abstraction layer

[Wyzard]

You have to use window manager hacks to get any extra utility from these cards at all on a X11 desktop, where newer versions of Windows and OS X have hardware/GPU accelerated rendering and compositing APIs. Where are those in X11?

By "window manager hacks" you mean switching to a compositing window manager like Compiz, right? What Compiz (or any compositing manager) does is not really very different from what its counterparts in Windows and OS X do. What you're complaining about is the fact that X11 allows a choice of window managers, and not all X11-based desktops use a compositing one yet, as opposed to the Windows and Mac platforms where there's essentially only one window manager available (it's built-in) and it's a compositing one.

As for new APIs, not really. Applications don't have to do anything different to display themselves on a composited desktop instead of a non-composited one. All the work for that is done by one program, the compositing manager, and the X enhancements needed to make its job possible (a new X11 protocol extension and a new GLX extension) were implemented in Xorg several years ago.

At this point, the lack of out-of-the-box compositing on Linux desktops is due mostly to accelerated 3D drivers (for the most common GPUs) not being installed by default for licensing reasons, not some fundamental problem with X.

Re:Choosing the correct abstraction layer

[Haeleth]

Beryl may have been around when Vista was still Longhorn, but in all this time it has still not managed to be a stable compositor

Have I somehow gone back in time and started reading an ancient Slashdot discussion? In my timeline, Beryl is an old experiment that was officially discontinued several years ago.

And Compiz is perfectly stable and runs very smoothly even on netbook hardware.

Re:Choosing the correct abstraction layer

[JasterBobaMereel]

...this is exactly what Windows GDI does as well ....it's just the GTK toolkit is awful ...

The API Toolkits on top of the GDI simplify this for you but they are just toolkits on top of the actual API (just like GTK) the GDI can only render the standard window decorations (and their appearance are not under your control) all the standard buttons etc are either the standard dialogs drawn by the toolkit and not properly under your control or self drawn, in the same way as same as directly accessing the X API...

If you think the standard GTK+ control looks like "something from 1987" then you are running a copy of GTK from 1987! (which is a good trick since GTK was not around then) they "can" look good (many don't)

Re:Choosing the correct abstraction layer

[yuhong]

IIRC it got to somewhere in the X11R6.3-X11R6.5 range.

I think it got up to X11R6.6.

Then XFree86 took over, ramping up some innovation, though still slower than many liked. After that X.Org took over

Which was a different story altogether that started with a licensing change that made it GPL-incompatible. I think it was the adding of a BSD-style attribution clause. GPLv3 finally fixed this incompatiblity, but by then it was too late, though XFree86 4.7 was released soon after GPLv3 was released.

Re:Choosing the correct abstraction layer

[dpilot]

I dunno. I got to be pretty decent at xorg.conf, too. I didn't like it either, at first. But recently on Gentoo they changed input handling from xorg.conf over to HAL, and that stuff is even worse. You fix problems by editing strings of XML that you get from experts in some forum or other. Those strings look like perfectly proper solutions in hindsight, but I generally have no idea whatsoever how to get there, not having seen the answer first.

"Just Works" is a great idea, as long as it just works. Too often when "Just Works" doesn't, it also fights your attempts to solve the problem yourself. I don't mind if xorg.conf can go away for the simple cases, I just like to have the capability around for when I really need it. Yes, I've had to use custom modelines, TV-out, multi-display, and those other oddities that at various times haven't been handled by the "Just Works" tools. To be sure, those tools are getting better, but they're still not 100%, and you'd still like to be able to fix a borked system from text mode.

Re:Choosing the correct abstraction layer

[spitzak]

I find it interesting that you declare "raise on click" to be "incorrect." You don't even pretend that it's a matter of opinion,

The reason it is incorrect is because THE PROGRAM CAN RAISE ITSELF IN RESPONSE TO A CLICK. Therefore a program can decide whether or not to raise the windows.

In addition this would remove a great deal of complex "child" and "layer" relationships that need to be communicated to the system, since the program can decide exactly what subset of windows to raise, thus simplifying the api considerably.

or concede that the earliest successful GUIs all did raise on click.

Yes, this was in X10 and was removed in X11 because they realized it was a mistake. That was in 1985 or so. Shameful that programmers forget.

It's not Windows' fault if a program locks-up its UI thread.

Excellent reading comprehension, there! I agree fully it is not Window's fault, and that X's ability to move/resize the windows but not redraw them is not any better.

Not trying to troll here...

[MikeRT]

But the 4.X beta runs incredibly fast on my dual core Windows workstation. If the Linux version is significantly faster in rendering, I would be very surprised.

Re:Not trying to troll here...

[TheModelEskimo]

The 4.X beta on the same hardware? Why don't you just get a live CD and try it? I'm on an Ubuntu Q8300 quad-core with 8GB RAM and even I can tell that, for whatever reason, Chromium is *much* faster than even Opera (to say nothing of Firefox) on my system. It's got its annoyances, but when I need to do Youtube or Slashdot or anything else that Firefox convinces me is "intensive," I switch over to Chromium where I have like 20 tabs open and things fly. So I'm not surprised somebody is bringing this up. It's very fast.

Memcpy not the biggest problem for chrome/chromium

[iamsquicky]

I'm pretty sure that the biggest slowdown for Chrome isn't the memcpy/bitblitting for the display - it's probably something to do with the insanely big history files it generates as part of it's searchable history.

Files you can't limit in size, can't compress, can't optimise. Instead all you can do is to delete them and loose all your precious history information.
It also has the bonus of providing a searchable address bar that performs significantly worse than firefox's searchable address bar !

I use both firefox and chrome simultaneously at home and at work, dedicated each browser for different tasks I do. It's a real shame that Chrome is being seriously degraded over time by this fault - I've started switching back to firefox because of it as my laptop just struggles too much with it now...

Re:Ummm...

[Henry V .009]

Yeah, at least the first one was succinct.

So, X11 gotta suck? The point?

[Ilgaz]

If you can take risk of re-compiling every X related app/library in case you give up in future, try the semi official/unofficial at http://xquartz.macosforge.org/ , it is newer than the Apple bundles. Install anything with the help of Fink/Macports like Konqueror from KDE 3 and see the amazing GUI speed, scroll speed, widget drawing speed.

I don't understand, as an OS X user, why a modern x.org on a good, supported hardware should be surprising to give better results. Also remember the insane things x.org has to do on OS X like using Aqua layer.

X11 is not bloated

[dvh.tosomja]

X11 is not bloated nor slow, GTK is both. Put 100 or so spinedits on one form in Win32 and in GTK. On netbook or anything other than quadcore machine, you will see significant difference in speed. And it is not because of the graphics. Sometimes I think GTK render fractals somewhere just to keep processor busy. Meanwhile, when I draw 100 spinedits using only cairo, it is almost as fast as Win32 while giving the same output as GTK including shadows, gradients, etc... I've being noticing this GTK behavior since forever.

GTK folks, please fix it.

Re:X11 is not bloated

[pe1rxq]

GTK folks, please fix it.

Have you tried posting your test to the gtk mailinglist?
I am sure they would love a nice objective testcase like that.....

Re:X11 is not bloated

[drsmithy]

Most (all now?) graphics cards are hardware accelerated for the Windows GDI, for things like drawing fonts, arcs, ellipses, fills, etc.

All *now* ?! They'd stopped selling video cards without 2D acceleration back when clock speeds were still measured in double-digit _Mhz_.

Re:X11 is not bloated

[MobyDisk]

Same problems happens with WPF on Windows. Yes, it is slower because it does anti-aliasing and all that. But just create 400 buttons in code, and never draw it to the screen. It's absurd.

Re:X11 is not bloated

[TheRaven64]

Most (all now?) graphics cards are hardware accelerated for the Windows GDI, for things like drawing fonts, arcs, ellipses, fills, etc.

No they aren't. They were in the '90s, and things like this were commonly offloaded. For almost a decade, doing this on the GPU has been slower than on the CPU due to the extra command overhead (drawing lines can be done incredibly fast on a modern CPU) and the newer X11 and Windows driver models don't offload them at all. X11 drivers and Windows drivers both used to take advantage of this acceleration, but they don't anymore.

Re:X11 is not bloated

[Melibeus]

"certifiable MCSE", there fixed that for you. No longer a tautology.

Re:To quote...

[JustOK]

bullshit. my digital clock stopped and now its never right.

Re:It's Chrome OS

[MrHanky]

And you know this because? Oh, you're just wildly speculating and don't actually know anything at all.

No NTLM, no Respect

[KWolfe81]

Until Chrome starts supporting NTLM, I know it will not get any respect at my firm, and likely many others....

Re:No NTLM, no Respect

[ChienAndalu]

You want a browser to be a file manager? How odd.

Re:No NTLM, no Respect

[kamochan]

As long as your firm keeps requiring NTLM, I know it will not get any respect in mine, and likely many others...

We'll gladly take your money, though.

Re:No NTLM, no Respect

[Guy Harris]

You want a browser to be a file manager?

No, he wants it to be a browser that supports NTLM Authentication for HTTP. The "LM" in "NTLM" nonwithstanding, it's used for more than just SMB.

Chrome - Webkit - KHTML - Linux

[Anonymous Coward]

Maybe it's because Chrome is based on Webkit that is based in KHTML that was developed mainly on Linux

Other performance gains

[Enderandrew]

How about a Qt build of Chromium as opposed to a GTK build of Chromium? I'd be real curious to see how it performs.

I was also saddened to see the port team bitch and complain initially that they had to use GTK, because GTK is "the standard toolkit" for Linux, while in the same paragraph complaining that Linux doesn't simply have one standard toolkit. Last time I checked, Windows has a bevy of toolkits and APIs to choose from as well. They also complained that writing audio in Linux was difficult.

If they had written a Qt app from day one, porting would be minimal, they wouldn't have to maintain this huge separate trunks, it would have worked from day 1 on Solaris, Mac, Linux, Windows, BSD, etc. Audio would have been very easy to code with Phonon.

I'm curious to see if Chrome (the browser and OS) are indeed both developed with GTK, then will they both need some retrofits when GTK 3.0 ships, further complicating the matter?

Re:Other performance gains

[Anonymous Coward]

A Qt build of chromium exists, and is normally known as "konqueror".

Re:Other performance gains

[OrangeTide]

They also complained that writing audio in Linux was difficult.

They should use PortAudio, it's pretty easy.

Re:Other performance gains

[Enderandrew]

Konqueror doesn't even run on Webkit.

Rekonq does use Webkit from Qt, and it is a promising browser. However, it doesn't have a multiple-process, sandbox model that Chromium does.

Re:Other performance gains

[BitZtream]

Windows does not have a bevy of toolkits to choose from out of the box.

Windows has, the Win32 API, GDI and the common controls. They come with EVERY install of Windows, it is a requirement. Pretty much everything else sits on top and is optional. You can draw buttons, checkboxes, ect, that work across all apps the same with nothing else. You can add a layer of abstraction with MFC and ATL if you want, but most developers who have been doing it for long enough will avoid those as they are more trouble then they are worth.

OS X has Cocoa, Quartz and some other APIs, same thing, included out of the box, required, and consistent.

Linux or more accurately, X11, doesn't. You need GTK, or QT or SOMETHING if you want a widget set rather than coding your own buttons and UI interfaces using the raw X11 API and a bunch of pixmaps. You HAVE to use GTK unless you want to design your own controls, and have no consistency with other applications. X11 does not include any common set of controls. And like it or not, GTK is crap. Qt is definitely a step up, but they hung themselves with their retarded licensing moves over the years, and GTK took over, sadly.

OS X has a standard audio interface.

Windows has a standard audio interface.

Linux does not, hence all the bitching and complaining done by more than just the Chromium people about audio in Linux. My recent looking into MythTV shows this.

No one wants their windows app to look like Qt. Mac users most certainly don't want Qt.

If it takes a bunch of work to 'retrofit' GTK 3 into apps, then once again, you have another reason why Linux app development is not worth the effort and something to bitch about. I have some non-trivial Windows apps that were built for Win95 that still run in Windows7. Outside of hello world, that is not true with GTK, hell, a Hello World app written for GTK won't even run any more on Linux since there have been several changes to things like vtables in the compiler.

I have the distinct impression that neither you, nor the people who modded you insightful have dealt with developing for a consistent OS before. You have, inadvertently I'm sure, just pointed out why most commercial software developers don't target Linux. Too many choices can be a bad thing. The changes to get most Windows or OSX apps to work on the next release are trivial, and you've usually known about them for the last 2 major revisions at least.

If they wanted the easy way out, they would have used wxWidgets, which at least feels native (by using the native toolkits) across Windows and Mac, and GTK on other Unixes. They did not. It probably wouldn't provide them with a low enough interface to do what they wanted to do, and now we're back to bitching about the lack of a standard toolkit on Linux. The two linux machines I have do not even have GTK installed. This of course is not Linux specific. My FreeBSD boxes are the same way. A few have GTK because they have some GTK apps installed. Some have Qt. Some have both, one has neither, no X at all, but thats a different story entirely and not really the point.

Re:Other performance gains

[Enderandrew]

Windows does not have a bevy of toolkits to choose from out of the box.

Yet Windows developers often find the core Win32 API doesn't fit their needs, and waffle between toolkits like GTK, wxWidgets, Qt, and the usual cross-platform suspects. They also turn to .NET, Java (technically a whole language), MFC and others.

I constantly run into issues where I need to download a runtime to run a Windows app, because many developers don't simply develop for what is out of the box with a standard Windows install.

I've seen native X11 apps offer up checkboxes, form elements, and the like. So it is possible. It just doesn't look nice.

Developing audio on Windows is not necessarily standard, not easy. That is why apps might ship with their own separate audio library like OpenAL, tie into QuickTime, etc.

I have some non-trivial Windows apps that were built for Win95 that still run in Windows7.

Sadly, there were many Windows 95 era apps that were still 16 bit, which don't work in x64 versions of Windows 7. Half of my games (mostly from the XP era, not Win95 era) wouldn't work properly in Windows 7. Windows breaks compatibility all the time, even with service packs. Saying you have a particular app that still works doesn't mean the Win32 API has stayed the same, because it hasn't.

The GTK API has stayed mostly the same over the 2.x life-cycle. That is likely to change with GTK 3.

Now, I'm not a fan of GTK by any means. However, the GTK 2.x API has been around since 2002. Anything written for that API should still work fine today.

If they wanted the easy way out, they would have used wxWidgets, which at least feels native (by using the native toolkits) across Windows and Mac, and GTK on other Unixes.

That is basically what I said, except you apparently didn't get that. I suggested they use Qt (like wxWidgets is a cross-platform toolkit). Qt makes more sense for a variety of reasons, such as native bindings to Webkit (the heart of Chrome), and very easy audio development where you write code once, and then the audio works on Windows, Mac, Linux, etc.

Re:Other performance gains

[JCholewa]

Konqueror doesn't even run on Webkit.

On my machine here, in Konqueror, you can go to the View Menu, select "View Mode", then click on "WebKit", to change Konqueror's renderer. So yes, it does. It just doesn't do so by default.

Re:Other performance gains

[Blakey Rat]

Yet Windows developers often find the core Win32 API doesn't fit their needs, and waffle between toolkits like GTK, wxWidgets, Qt, and the usual cross-platform suspects. They also turn to .NET, Java (technically a whole language), MFC and others.

dotNET (typing it that way to get around a Slashcode bug) uses the GDI and the common controls, so it's a layer above what you're talking about. Ditto with MFC.

Java draws its own widgets and get them all fundamentally wrong, as it does on pretty much every OS it runs on. (Except perhaps Linux, where there are so many competing standards, it's hard to declare something "wrong.")

And from my experience, the vast, vast majority of Windows applications don't use GTK, wxWidgets or Qt, unless they've been ported from Linux. And most of those applications get the simple widgets wrong. (See: Pidgin, which gets Save/Open dialogs utterly wrong, or Notepad++ which gets menus wrong*.)

* Think about that: it gets menus wrong. *Menus*. Which have been perfected since 1985, it somehow gets wrong in 2009! Holy Christ, that's shitty software. You wouldn't even think it was possible to get menus wrong!

I constantly run into issues where I need to download a runtime to run a Windows app, because many developers don't simply develop for what is out of the box with a standard Windows install.

Constantly? Given the amount of software for Windows, and your likely preference for open source apps (like Notepad++ and Pidgin, see above), you might have a different experience than most other Windows users. From my experience, finding a copy of Windows with GTK+ installed is pretty rare-- the only apps that *might* be popular enough for people to use it with are Inkscape, GIMP and Pidgin. (And note, once again, that the GUI in all of those apps is obviously wrong.)

Sadly, there were many Windows 95 era apps that were still 16 bit, which don't work in x64 versions of Windows 7.

True. Do you use any? Do you know anybody who uses any?

Half of my games (mostly from the XP era, not Win95 era) wouldn't work properly in Windows 7.

Half? Bunk. Total bunk.

Wizardry 8, worked without a hitch. Serious Sam? Same. Command and Conquer: Red Alert? Ran fine. The original Unreal? Ran fine. Starsiege Tribes? No problems. Those are all games much older than the XP era, and they work.

Maybe you have the strangest game collection in the world, but from my experience it's closer to 90%.

Re:Other performance gains

[Blakey Rat]

Oh, I kind of missed a point I wanted to make, apologies for the double-reply.

The biggest problem with cross-platform toolkits like QT, wxWindows, and GTK+ (other than the fact that their widgets are wrong) is that you have to use the lowest common denominator of every OS it supports. And if it supports Linux, the LCD is looow indeed.

For example, GTK+ apps don't work with pen input, or with voice recognition, both standard features in Vista, Windows 7, and OS X. Linux doesn't have them, so neither does Pidgin. That's actually the reason I got rid of it. Meanwhile, all apps written using Microsoft's APIs support them fine-- hell even Flash, *Flash*, has hooks to support pen input and voice recognition! (Which is why Flash is such a popular development platform for multi-touch tables, like the Microsoft Surface.)

By the time Linux/GTK+ gets support for pen input, I'll be lamenting it's lack of instant thought transference, or canine vocalization translation, or whatever other technology the rest of the computer industry has moved on to but the Linux hordes haven't found necessary yet.

Re:Other performance gains

[Enderandrew]

Qt has pen input that works on all platforms. Just saying.

Re:Other performance gains

[richlv]

i'm actually surprised about how many developers and it people who are fans of chrome do not know that it originated from konqueror.
as for the gtk choice, that seems to be a pretty huge mistake, as choosing qt would indeed have brought them many, many benefits. would be interesting to find out what the real reason for this choice was - maybe some politics regarding mobile devices and their toolkits/operating systems ?

Re:Other performance gains

[shutdown -p now]

Windows has, the Win32 API, GDI and the common controls. They come with EVERY install of Windows, it is a requirement. Pretty much everything else sits on top and is optional. You can draw buttons, checkboxes, ect, that work across all apps the same with nothing else.

It should be noted that two best Windows UI frameworks - namely, WPF and Qt - both draw their own widgets, and don't use stock ones. Part of the reasoning is performance, part is inability to add some features. In any case, Win32 API exposes lower-level widget drawing primitives as well, so you can draw buttons/menus/whatever using system theme. Both WPF and Qt do this right (in that it's hard to tell a widget draw by either one from a stock OS widget - you have to know the clues in advance to look for them). Java Swing also does this more or less okay. Gtk/Win32 tries to do that, too, but fails horribly on everything except Windows Classic theme.

You can add a layer of abstraction with MFC and ATL if you want, but most developers who have been doing it for long enough will avoid those as they are more trouble then they are worth.

UI portions of Win32 API are ugly and low-level enough that any sane developer will want an abstraction layer, and hand-coding one when there are good existing solutions with acceptable licensing (now that Qt is LGPL) is a waste of time.

In any case, even hardcore Win32 developers normally use at least something like WTL. The tedium of manual resource management in plain C is just too high.

Re:Other performance gains

[shutdown -p now]

The biggest problem with cross-platform toolkits like QT, wxWindows, and GTK+ (other than the fact that their widgets are wrong)

Given that wxWidgets uses native OS widgets on Win32, I would be very curious to hear what is wrong about them.

Qt renders its own, but I'm still not aware of anything being wrong about them.

You go on to kick Gtk for the lack of features, which it probably deserves. But what about Qt?

Re:Other performance gains

[plague3106]

Well, Vista and higher also come with .Net by default, as .Net will be standard from here on out.

Re:Other performance gains

[Jesus_666]

If they wanted the easy way out, they would have used wxWidgets, which at least feels native (by using the native toolkits) across Windows and Mac, and GTK on other Unixes.It looks native but it doesn't feel native. Example:

A dialog that tells the user "Warning: Applying these changes will reset the device." and asks them whether they want to continue or not. The detail in question are the buttons presented to the user.
Windows dialogs use [OK] [Cancel].
GTK dialogs use [Cancel][OK].
OS X dialogs use [Apply][Don't apply](the button labels are supposed to be self-explanatory and dialog-dependent).

Whatever you do, it's going to violate the HIG (or established best practices) on at least some platforms. You can get a decent approximation but it's always going to be slightly off - although with wxW it won't be as far off (on non-X11 platforms) as with Qt and nowhere near GTK's distance to proper integration.

Re:Other performance gains

[Jesus_666]

Java draws its own widgets and get them all fundamentally wrong, as it does on pretty much every OS it runs on.

Although on OS X it's miles ahead of X11, which isn't even capable of separating menus from windows - so yes, in a way X11 doesn't even get menus right. Speaking of which, what exactly is your issue with Notepad++'s menus? I haven't found anything unusual but then again I run Windows XP without visual styles so it might be a styling issue I can't see.

Maybe you have the strangest game collection in the world, but from my experience it's closer to 90%.

Or he plays stuff like System Shock 2 (extremely difficult to properly play under XP; virtually impossible to play under Vista/7) and X-Com: Apocalypse and refuses to put a DOSBox around the latter. In fact, thinking back to SS2, just about every Dark Engine game should be problematic; that engine really didn't age well.

Vista and XP deal with many games properly; the ones they don't play nice with are often the ones that are already tricky to get working under XP.

Re:Other performance gains

[Blakey Rat]

Although on OS X it's miles ahead of X11, which isn't even capable of separating menus from windows - so yes, in a way X11 doesn't even get menus right. Speaking of which, what exactly is your issue with Notepad++'s menus? I haven't found anything unusual but then again I run Windows XP without visual styles so it might be a styling issue I can't see.

http://sourceforge.net/tracker/index.php?func=detail&aid=1865630&group_id=95717&atid=612382

Dear Lord, it's actually marked as fixed!

Although, since his comment is, "making the language menu more compact," I'm thinking he still doesn't understand how the menu code is fundamentally wrong, regardless of the height of that particular menu. It's true that a more compact Language menu won't exhibit the bug, but that's not the same thing as fixing the bug.

The more fundamental question to me is, "where do you even GET a menu library in the year 2008 that flawed?" Also: "how much do you hate your users that you don't even bother to test your widgets before putting them in the program?"

I also reported a UAC issue, I haven't bothered checking back to see if that was fixed, but it was the kind of UAC bug that means Notepad++ *never* worked on a limited-user account in the past. Some software developers really just don't give a shit about the quality of their programs, do they?

BTW: there are styling issues, too. While searching for that bug, I found another that says the menu items have ugly white rectangles around the text.

Or he plays stuff like System Shock 2 (extremely difficult to properly play under XP; virtually impossible to play under Vista/7) and X-Com: Apocalypse and refuses to put a DOSBox around the latter. In fact, thinking back to SS2, just about every Dark Engine game should be problematic; that engine really didn't age well.

Well, ok, I never claimed compatibility was perfect. Wizardry 8 has issues, too, just none of them game-breaking. But if he's seriously saying 50%, then he must only own like 6 games and be the least lucky person ever. (Or more likely, he's exaggerating to make Windows look worse than it is.)

Re:Other performance gains

[shutdown -p now]

Give me a larger-than-trivial Qt application, and I (almost) guarantee I can find a bug in it in less than half an hour.

By "bug" do you mean any inconsistency with stock UI controls?

I really wouldn't go so far as to call it that, because it really is the norm on Windows. In fact, many Microsoft applications don't use stock controls themselves - Office doesn't, for example. Huge parts of VS2010 were rewritten in WPF, too (and it doesn't even try to look native anymore, even though it could - rather, it has its own distinct theme).

In any case, try Psi - that one is a Qt4 application that tries to look native. I'm curious as to what abnormalities you can quickly find in that.

Re:Other performance gains

[the_womble]

So Konqueror has:

1) Webkit rather than KHTML,
2) Process per tab,
3) Application shortcuts, .etc.

Does it?

Re:Other performance gains

[Blakey Rat]

By "bug" do you mean any inconsistency with stock UI controls?

An inconsistency is otherwise known as a "bug," yes.

I really wouldn't go so far as to call it that, because it really is the norm on Windows.

Yes, there are many buggy apps on Windows. Nobody ever claimed Windows apps were bug-free.

In fact, many Microsoft applications don't use stock controls themselves - Office doesn't, for example.

Office writes their own widgets, but (as far as I can work out) they behave 100% identically to the OS-standard widgets. Therefore, they aren't buggy. (Usually, the only difference is that Office adds their own theming.) Now, that said, there very could well be a case where the Office widget works differently, and then, yes, it would be a bug. Nobody ever claimed Office was bug-free.

Huge parts of VS2010 were rewritten in WPF, too (and it doesn't even try to look native anymore, even though it could - rather, it has its own distinct theme).

Yeah, and I think that's a huge mistake. When a programmer who is a bad UI designer doesn't know how to implement something, what's he going to do? Find a similar problem and see how VS solved it... and most of the time, VS gets it wrong. This is a huge problem, and leads to what you pointed out previously, about buggy Windows apps. (Oh, and same applies to Office.)

It's obvious if you work with Microsoft products that VS and SQL Server, for some reason, get little-to-none usability testing, as opposed to virtually everything else Microsoft creates. Why is this? Maybe Microsoft perceives that it's not a problem if "pro" apps are hard-to-use? I dunno. Like I said, I think it's a huge mistake.

SQL Server is actually even worse than VS. Even it's installer is basically equal parts confusion, meaningless buzzwords, and bugs. There's no reason a database package should be hard-to-use.

In any case, try Psi - that one is a Qt4 application that tries to look native. I'm curious as to what abnormalities you can quickly find in that.

The *screenshot* on the webpage has a wrong down-arrow control. I didn't even need to download the program.

It looks like they hacked off the end of a scrollbar and tinted it blue. Hell, I can't even really tell what widget it's supposed to be... is that a combo box arrow that somehow got detached from the rest of the box? The combo box arrow would at least look correct: http://schend.net/images/screenshots/combo_box_arrow.png

With something like that, I have absolutely no clue how to interact with it. I can assume that clicking it causes something to appear below it, but what is that something? A menu? A combo box? Who knows!

Is that seriously the best example you have? I'm starting to form a theory that most programmers have no eye whatsoever for detail... you're kind of confirming my suspicions.

Re:Other performance gains

[Blakey Rat]

Ugh. I just downloaded and installed the program. The widget is a menu, FYI, but God it's hideous! It's completely ignoring my Windows theme, and drawing a huge fat black arrow in the middle of what appears to be a button. Windows doesn't have a "button-menu" control that I'm aware of, so I guess I can forgive that it exists, but it could at least look like it fits in.

Also: the text selection highlight is wrong, it's supposed to be a dark blue background using my theme. And HOLY SHIT, Control-C to COPY doesn't work! COPY DOESN'T WORK! COPY DOES NOT WORK and you're holding this up as a good Qt4 app?! Jesus.

Re:Other performance gains

[shutdown -p now]

It's obvious if you work with Microsoft products that VS and SQL Server, for some reason, get little-to-none usability testing, as opposed to virtually everything else Microsoft creates.

Well, as it happens, I work on Microsoft products - VS specifically - and particularly on common UI parts - main and context menus, toolbars, toolwindows, start page, switcher, options dialog, toolbox etc (though as a developer, not an UX/usability expert). So if you can point any specific usability flaws, shoot. Especially those in VS2010 betas.

I know quite a few myself; for example, our toolbar customization dialog (Tools -> Customize) is atrocious from UX perspective. But it would be interesting to hear outside perspective.

That said, it's not true that there's "little to no" usability testing and UI design review, for VS at least. I should know; I've fixed quite a few bugs that boil down to "this looks kinda wrong because there's an extra 1px spacing between icons here", or "keyboard navigation doesn't wrap around in toolbars with overflow" in this release cycle. And this kind of stuff has to be signed off with a dedicated UX team.

Is that seriously the best example you have? I'm starting to form a theory that most programmers have no eye whatsoever for detail... you're kind of confirming my suspicions.

Last version of Psi that I've regularly used was 2 major releases before the current one; I don't recall seeing that button there back then (or at least it didn't look as wrong as on the screenshot).

Also: the text selection highlight is wrong, it's supposed to be a dark blue background using my theme.

I've checked it out, and it seems to be wrong in the chat window output area (which is a custom rich text control), but all textboxes (which are stock Qt) use my system colors. So not really Qt fault here.

And HOLY SHIT, Control-C to COPY doesn't work! COPY DOESN'T WORK! COPY DOES NOT WORK

Again, chat output area - a badly written custom control. As you surely understand, it's just as easy to write one like that in raw Win32 API.

Re:Other performance gains

[Blakey Rat]

The part that really throws me about VS is how it reconfigures itself, seemingly at random, when you load different projects/files/etc.

For example, we use Team Foundation Server as source control. In a typical day, I have TFS's source browser open while I'm working on other things-- Word docs, or email, or whatever. Fine. But then I need to do some work on a C# program, so I click the C# project in Explorer and it opens in the same VS window... well, ok.

But now it gets weird. Since TFS's source browser has no "solution", the Solution Explorer isn't there. I have an open project, but it's not showing me the project items, which is really dis-concerting... and even worse, if the project happened to be saved with no open tabs, the VS UI does *nothing at all* when you open a project. (Well, it does some stuff to the menus, but the window looks identical to before.) So I always have to manually show the Solution Explorer and Properties Explorer, and usually the Toolbox also.

What I'd MUCH rather have is TFS source control browser being treated as a completely different instance of VS, instead of just a tab in VS. Then when I opened a C# project, I'd get a whole new VS instance with the correct UI elements shown.

Oh, but it gets even weirder with Javascript. I'm running a JS project in a browser, and I hit "Debug" and choose VS as the debugger. Now, the JS file I'm running is RIGHT THERE in VS, but it seems completely unable to detect that the file I'm debugging is the same thing as the file I'm looking at... so I get a new VS tab, which is crazily showing the exact same file as the one I was editing a minute ago, except it's non-editable. Which means I always, and I mean *always*, try to edit it and get that idiotic error "you can't edit this file, dummy, it's being debugged" or whatever it says. Irritating as hell.

IE8 fixes that latest problem, except I'm still running IE7 for QA purposes.

I think the problem I really have is that VS is designed around the assumption that you sit down, open VS once, and open a single solution which is the *only* thing you work on each day. My work isn't like that... I'm editing HTML here, JS there, oh quick change to the C# site, another quick change to the DB schema, etc. I'm constantly opening and closing new projects, and VS seems to have a new and exciting UI configuration every single time I do so.

I'm not trying to suggest the widgets are broken (although they are weird in many ways), but the holistic experience for me just isn't there... I feel that every time I open up something that uses VS, I have absolutely no clue how it's going to look. "Is the Solution Explorer going to be there this time?" "Is the Properties Explorer?" "Is the Propeties Explorer going to be below or beside the Solution Explorer?"

That said, it's not true that there's "little to no" usability testing and UI design review, for VS at least.

The testing I need is, "hey, spend a few hours looking over my (a typical customer) shoulder, and see how weird this all is." Some groups do that, I know Office and Windows does. Maybe VS is doing that, but they don't watch people who work like I do.

VS has a lot of features I really love, although I have to admit I've been slowing moving over to Expression Web for all my HTML/Javascript needs. The only thing I really use VS for HTML-wise anymore is the "Format Document" function and the Javascript debugger.

Oh, and BTW, did you know the "Check for Updates" item in the VS Help menu does not, and has not ever, worked? Oh, it LOOKS like it works, but after you the install process, you actually end up with the same version of VS as before? It's devious. http://blakeyrat.com/2008/10/ms-sql-server-2008-installer-woes/

Last version of Psi that I've regularly used was 2 major releases before the current one; I don't recall seeing that button there back then (or at least it didn't look as wrong as on the screenshot).

Re:Other performance gains

[Blakey Rat]

Actually, I think I just realized what (conceptually) is wrong with Visual Studio.

VS uses a Solution metaphor, which is basically just a project full of projects. Each given VS window can have one Solution open at a time. That's fine.

The problem is that VS also can open a whole bunch of different tasks that don't count as Solutions. For example, the TFS source control browser doesn't count as a Solution, so if I double-click a real solution is takes over that window. Ditto with a Javascript file I just double-clicked to edit, that's not a solution it's just a file. Or the Javascript debugger.

Making that even more confusing, whatever was opened first controls the UI of that particular VS window... if I open TFS source control browser first, the VS window has no Explorers or Toolbox because those don't apply to it. But if I later double-click a C# project, that window gets re-used for the C# project *without adding the project-relevant UI elements*.

Now if I take that setup and double-click a JS file, the JS file crams into the same window once again, because it's not a Solution. So now I have a Javascript editor with a Solution Explorer and Toolbox.

I could be wrong, maybe the behavior is more complex than this. But it seems to match the clicking-around I'm doing as I type this.

A better way of doing this would be to have a "everything else" VS window where things like source control, ad-hoc file editing, debuggers go, and for which the UI changes each time you change a tab. Then each Solution should have its own independent window with a static UI.

Well, whatever, I'm not an expert either. I just know that by the end of the day, I usually have like 9 VS windows open, all containing random shit, and I have no idea what's going on with them.

Re:Other performance gains

[shutdown -p now]

For example, we use Team Foundation Server as source control. In a typical day, I have TFS's source browser open while I'm working on other things-- Word docs, or email, or whatever. Fine. But then I need to do some work on a C# program, so I click the C# project in Explorer and it opens in the same VS window... well, ok.

But now it gets weird. Since TFS's source browser has no "solution", the Solution Explorer isn't there. I have an open project, but it's not showing me the project items, which is really dis-concerting... and even worse, if the project happened to be saved with no open tabs, the VS UI does *nothing at all* when you open a project. (Well, it does some stuff to the menus, but the window looks identical to before.) So I always have to manually show the Solution Explorer and Properties Explorer, and usually the Toolbox also.

The behavior you describe is rather weird. Unless your VS crashes (i.e. if you shut it down normally), you shouldn't need to enable Solution Explorer / Properties / Toolbox more than once. Let me explain...

The way this works is actually a little bit similar to Eclipse "perspectives", only in case of VS they are hardcoded and more generic - so you get a "design" perspective (this is what you get initially when you open a solution), a "debug" perspective (obvious) etc. Each of them has its own set of visible toolbars and toolwindows and their position.

So, regardless of presence/absence of TFS Explorer window, once you make e.g. Solution Explorer show in "design" perspective, it should stick (there's no "TFS" perspective). If it doesn't, I'd be really curious to hear more about it (it would be a bug in my team's area of code) - there must be some other step in there that makes it misbehave as you describe. If you can come up with a step-by-step repro on any VS version, that would be perfect.

Can't comment on your JS problem, unfortunately - last web application I wrote was 5 years ago and in PHP.

I think the problem I really have is that VS is designed around the assumption that you sit down, open VS once, and open a single solution which is the *only* thing you work on each day. My work isn't like that... I'm editing HTML here, JS there, oh quick change to the C# site, another quick change to the DB schema, etc. I'm constantly opening and closing new projects, and VS seems to have a new and exciting UI configuration every single time I do so.

This is again weird, since individual solutions/projects do not have separate window visibility/location settings. I just killed Solution Explorer and switched between several solutions; it remained invisible. Re-enabled it, undocked and dragged around, and switched some more - it remains visible and in the position where I've put it.

Oh, and BTW, did you know the "Check for Updates" item in the VS Help menu does not, and has not ever, worked? Oh, it LOOKS like it works, but after you the install process, you actually end up with the same version of VS as before? It's devious.

I agree that the situation described in your blog post is quite a mess. To my personal excuse, I wasn't yet here in time for VS2008 (or SP1) release :) and I sure hope this won't fail like that for VS2010. From the description it sounds like Microsoft Update was broken with respect to VS, somehow.

Regarding installer in general - well, at least it's faster now... Though I understand that after 3-hour install of VS2005 SP1 that could sometime ask you to close explorer.exe to continue installation, this may not sound overly optimistic. I can only say that this is taken seriously, and it is being worked on.

Re:Other performance gains

[Blakey Rat]

You should pop me off an email or blog comment, so we could hash through this.

Now that I'm trying it on my work machine, it's actually behaving closer to what you describe. (At least if I'm reading you right, I've never used Eclipse, so I really have no clue at all what a "perspective" is. And VS certainly doesn't seem to have anything that tries to explain that metaphor.)

In any case, starting with a computer with no VS running, here's what VS looks like when I open it by double-clicking a .js file:
http://schend.net/images/screenshots/vs_opened_js_file.png

Contrary to what happens on my home computer (where I wrote the last post), if I then double-click a Solution, the Solution will get its own window completely separate from the .js window and with the correct UI elements visible. That's good-- just give the JS window a different icon, so I can tell it apart easier, and I'd be happy.

TFS, however, doens't behave the same way. Here's what VS looks like if I just open it using the Start menu icon:
http://schend.net/images/screenshots/vs_source_control_explorer.png

Note that it opens up the Source Control Explorer by default, with the appropriate UI elements. (BTW, what's an "Explorer?" It the little pane to the right is an "Explorer", but the main content of the window is also an "Explorer", WTF does that term even mean?)

Here's the same window after I open a Solution that just happens to have no saved open tabs:
http://schend.net/images/screenshots/vs_opened_solution_from_source_control.png

Can you tell the difference? Other than the Source Control Explorer window flashing, there's *nothing* in the UI to indicate that I now have an open Solution. The Solution Explorer didn't appear, nor did the Toolbox or Properties Explorer. The only difference, as far as I can work out, is that the File menu activated Close Project.

Now if I manually go and show the Solution Explorer, then it'll have all the Solution files in it and all will be well. But why should I have to manually show it even single time?

This might be a bug, but VS is working off such a complicated UI metaphor that I have no way of telling what's a bug or not. What your team really needs to do is simplify the metaphor to something you can explain in less than a paragraph without referring to a competing project :)

Re:Other performance gains

[Blakey Rat]

From the description it sounds like Microsoft Update was broken with respect to VS, somehow.

The most insane part is that it goes through the whole install process-- downloads the patch, asks you to close VS, shuffles through files for over an hour, tells you it's all updated with a happy little Close button. But when you check VS's version, it didn't actually change anything at all! I mean, how does a bug like that even happen? What the holy hell was the installer doing for that hour and a half? It boggles the mind.

Anyway, I'm not blaming you, I'm actually more pissed at SQL Server's installer, which IMO should be classified as a violation of the Geneva Convention. (Can you tell I've had to install a few SQL Server instances this week?)

Re:Other performance gains

[shutdown -p now]

You should pop me off an email or blog comment, so we could hash through this.

I'm sorry, I couldn't find your email anywhere (not in your /. profile nor on your blog), nor an appropriate blog post for random comments.

My /. profile has email visible - you can use that, or pminaev@microsoft.com, for further replies.

(BTW, what's an "Explorer?" It the little pane to the right is an "Explorer", but the main content of the window is also an "Explorer", WTF does that term even mean?)

I think it's supposed to mean "a browser of an item tree of some kind". In this case there are 3 - Solution Explorer for solution files, Source Control Explorer for source control files, and Team Explorer for work item queries, project-related documents etc.

Now if I manually go and show the Solution Explorer, then it'll have all the Solution files in it and all will be well. But why should I have to manually show it even single time?

Just to clarify this bit - if you make Solution Explorer visible after opening a project, and then close VS and restart it (using Start Menu icon), you don't see Solution Explorer anymore?

On a side note, if Solution Explorer is enabled while you're opening a project from TFS, even if it's not on a visible tab, it will become visible, serving as an indication for project load. I agree that it would make some sense for it to pop up either way when opening up a solution, though.

Re:Other performance gains

[shutdown -p now]

Anyway, I'm not blaming you, I'm actually more pissed at SQL Server's installer, which IMO should be classified as a violation of the Geneva Convention. (Can you tell I've had to install a few SQL Server instances this week?)

Do you want to install? No, really? Okay, click here to run some tests... all fine, now click here to agree with me on that. Right, so lets start the installer then... what? no, this wasn't it, this was a prerequisite check. And this is the installer now. So, do you want to install? No, really? Okay, let's run some tests... ;)

But it can be worse. Have you ever installed TFS2005 or TFS2008 with a service pack?..

(Gladly, this was much improved in VS2010, and I think the new TFS installer is now more sane than SQL Server one ever was. Of course, I'm biased ~)

Re:Other performance gains

[BitZtream]

Yet Windows developers often find the core Win32 API doesn't fit their needs, and waffle between toolkits like GTK, wxWidgets, Qt, and the usual cross-platform suspects. They also turn to .NET, Java (technically a whole language), MFC and others.

Yes, windows has many many shitty developers. The barrier to entry is low for Windows programming. X11 development while not overly difficult is none trivial for a newbie, there are far less wizards for generating an X11 app than there are for Windows apps. Almost every Windows IDE (built for windows, not ported from somewhere else) has a wizard for generating apps. You won't find the same true for UNIX IDEs, and what most consider as IDE's for UNIX take a fair amount of work just to get them working. Most (not all) UNIX devs can use emacs or vim as an IDE. Most (not all) Windows developers would run and hide if they had to do that, which I wish was the case. Cocoa's quirks slow down some of the potential OS X devs than god, but not by much.

Developing audio on Windows is not necessarily standard, not easy. That is why apps might ship with their own separate audio library like OpenAL, tie into QuickTime, etc.

People using OpenAL for basic audio are subjecting themselves to more pain than its worth. A better example would be something like BASS, which does make Windows audio easier, but thats mostly because of its ability to play multiple audio formats other than the native formats. I would argue that using OpenAL is harder in certain instances than native audio support. OpenAL is the way to go if you intend to target something other than Windows, but not because its easier, because its more consistent across platforms.

Sadly, there were many Windows 95 era apps that were still 16 bit, which don't work in x64 versions of Windows 7

I didn't say Win95 era apps, I said Win95 apps, big difference. I never implied that a Win3.1 app would work in XP, Vista or Win7.

Now, I'm not a fan of GTK by any means. However, the GTK 2.x API has been around since 2002. Anything written for that API should still work fine today.

Sure, for the most part thats true, if you recompile it. GCC changes alone since then require recompilation on Linux. Windows apps don't need the recompile.

That is basically what I said, except you apparently didn't get that. I suggested they use Qt (like wxWidgets is a cross-platform toolkit). Qt makes more sense for a variety of reasons, such as native bindings to Webkit (the heart of Chrome), and very easy audio development where you write code once, and then the audio works on Windows, Mac, Linux, etc.

And you missed the point of mentioning wxWidgets. It wasn't that there is a port, theres a port of GTK to OS X and Windows as well. Neither GTK nor Qt feel native, wxWidgets does, on Windows and Mac OS X (and if you were going to do so, older builds were native to Mac OS but we'll exclude those since they aren't supported anywhere anymore). wxWidgets also has a widget for WebKit, and audio classes. The main difference is how it feels to the user, which is more important than how it feels to the developer for anyone writing software intended to be used by others. Ignoring the native feel is a big sign of a ignorant developer. Most people don't use PCs to learn how some particular software works, they use it to get something done. By not following the common UI elements you break the feeling and require people to learn something different for your app, making it harder to use. Sometimes you can't help but to use custom UI elements as it doesnt' fall into what already exists, but thats not what Qt does as those custom elements are not part of Qt. It (and GTK) break the feeling of Windows and Mac OS X. Thats fine if you're a UNIX person who has to use Windows and wants things to feel like UNIX anyway, but its horrible for porting an app to Windows for Windows users to use.

Re:Hold the phone

[Anonymous Coward]

Yeah. As opposed to tests made by Microsoft and Apple paid "impartial and reliable" entities.
\sarcasm

What's with writing "[sic]" after "X-windows"?

[nuckfuts]

It's been called X-Windows for a long time. Longer than the term "X11" has been around. It's not a misuse of Microsoft's Windows® brand name.

Re:What's with writing "[sic]" after "X-windows"?

[FauxPasIII]

> It's been called X-Windows for a long time. ... incorrectly. It's actually the X Window System.

http://en.wikipedia.org/wiki/X11

Re:What's with writing "[sic]" after "X-windows"?

[yanyan]

Correct. In fact the X man page states the following:

The X.Org Foundation requests that the following names be used when referring to this software:

X

X Window System

X Version 11

X Window System, Version 11

X11

Personally i call it X11.

Re:What's with writing "[sic]" after "X-windows"?

[nuckfuts]

I don't care what Wikipedia labels it. I've been around since back in the day, and nobody went around saying "The X Windows System". We called it "X Windows". Maybe we weren't being 100% correct, but I'm pretty sure it was acceptable enough that nobody would have quoted us with a snide little "[sic]".

Re:What's with writing "[sic]" after "X-windows"?

[Bill_the_Engineer]

Well, The TFA uses a hyphen "X-Windows[sic]" while you didn't "X Windows".

So which one of you deserves the snide little "[sic]"? ;)

Re:What's with writing "[sic]" after "X-windows"?

[nuckfuts]

We didn't pronounce the hyphen.

Re:What's with writing "[sic]" after "X-windows"?

[Kidbro]

The difference between text and speech is that you expect text to actually be correct. When you're quoting someone that does include things that aren't quite correct, you insert the "snide little [sic]". That's its function.
Just because you called it "X Windows" that does not mean it was correct, nor, I hope, that it was what you actually wrote when you had to put it in text.

And, for what it's worth, I've been around since back in the day as well, and "we" simply called it "X".

Faster because it's incomplete?

[edmicman]

I've been using the daily Chromium PPA builds for a couple months now (updated weekly usually), and Chromium is by far more responsive than Firefox on my Ubuntu 9.04 laptop. For some reason FF just seems to get laggy in the UI dept, and if I open up a handful of tabs, especially if there is Flash involved, the whole thing chokes and the app turns grey. Chromium seems to perform much better.

That said, it still feels very much incomplete. I don't think printing is working still, although I haven't tried it in awhile. For some reason there are no "arrow button clickers" on scrollbars...not sure why that is the case. I can't open a file download directly or inline - for example to view a PDF I have to save it somewhere first, THEN open it. FF lets me choose what to open it with without having to save first. 99% of my browsing on Chromium is super fast, except for the Gizmodo.com RSS feed through Google Reader. I don't really know why, but it seems like it has something to do with the adds loading or something...does FF pre-fetch or cache things or something?

I've switched back and forth off and on for awhile now. I"ll get tired of the UI laginess in FF, or I'll break it on a nightly update, and then use Chromium for some time. Eventually I'll miss some features or speed in the RSS reading of Firefox (I wonder how much of that is due to Adblock?), and then return. All in all both browsers are good, and I'm looking forward to Chromium becoming a full fledged option on Linux.

Re:Faster because it's incomplete?

[domatic]

Printing works on the newest builds of google-chrome and chromium-browsrer but it can be buggy. It seems to get a little bit better steadily as more releases come out.

Read this yesterday, installed, then removed.

[isolationism]

The font rendering settings are locked in. There are some Google Groups discussions about why this is so, but it was all white noise -- every other application can use .fonts.conf (even if it is a workaround to do so) and Chrome can't/won't for a while, so it got promptly uninstalled.

What to make of X11?

[Enderandrew]

I'm wary of any real old legacy code.

I also know that graphic displays and inputs are vastly different today than they were 10 and 20 years ago.

Do I know that X11 is inefficient? No, but I sure read plenty of other people making those claims. However, I suspect that X11 wasn't developed initially with today's needs in mind. I do know that the X team keeps promising features, cutting them, and then still shipping six months past their projected release dates.

Novell has guys working on Mono, Evolution, OOo, KDE, Gnome, the kernel, etc. What I don't see a whole lot of is major distro companies (Red Hat, Novell, Canonical) paying for major upstream development with X. Maybe it just needs a little more love, some deprecation of old cruft, and a new forward-thinking design. There seems to be somewhat of a future direction (GEM, DRI2, MPX), but perhaps X needs a revolution.

Is Wayland a step in the right direction?

Re:What to make of X11?

[snadrus]

It's X11 changes that have helped make Wayland possible. Also, the breaking it apart into different pieces has helped accelerate it and offers an opportunity for some of those pieces to be replaced. I'd say the biggest problem is that it's still X11 instead of an army of pieces that are re-assembled differently for each distros intentions. Also, swappable pieces like Wayland should help add options without disposing of 20 years of work all at once.

Re:What to make of X11?

[Homburg]

What I don't see a whole lot of is major distro companies (Red Hat, Novell, Canonical) paying for major upstream development with X.

Really? David Airlie (one of the main developers of the open-source ATI drivers) works for Red Hat. Keith Packard, one of the major forces behind x.org (and important recent-ish developments like the composite extension) was employed by SuSE. A lot of the DRI2 work is, I believe, being done by employees of Red Hat, and Novell are also credited for work done on x.org. I don't think the situation is any different for X than it is for the other components of the Linux desktop.

Re:Even if X is usually slower...

[everynerd]

Give the guy a break. He's only trying to create synergy among web-enabled paradigms.

Re:Windows and OS X versions, please.

[Beezlebub33]

As a non-GUI developer, what's the Mac and Windows equivalent to X11? Would it be Quartz on the Mac? I don't know what it would be on Windows, since I avoid developing windows-specific things and have always viewed Windows as a monolithic, integrated mess.

Re:Windows and OS X versions, please.

[xaxa]

No. It's MacOS 10. OS X is just stupid intentionally confusing terminology.

X is the Roman numeral for 10. It's "Mac OS X", which I pronounce as "Mac oh-ess ten".

Re:It's Chrome OS

[Youngbull]

well... ChromeOS ~= google Chrome / Chromium, right? just add some way of running Chromium and your done!

Guestimates

[wye43]

I read TFA and all there is are feelings of some people that its faster, no numbers. I guess that is what "reportedly" means. Weasel words.

Aqua layer, you say?

[WaroDaBeast]

I call DIBs on the X server. Especially if it sucks.

Re:Memcpy not the biggest problem for chrome/chrom

[MikeBabcock]

I had the same problem with Google Desktop. It was a great tool and worked well for a while, but eventually its little database file was immense and was dragging my system down with it.

Re:Windows and OS X versions, please.

[The MAZZTer]

He wasn't responding to your post...

Re:Windows and OS X versions, please.

[Nikker]

MS Windows = Explorer.exe Linux = X11 MacOS = Quartz

Re:To quote...

[mjwx]

Even a stopped clock is right twice a day.

Tell that to my Casio, I'll let you know when we get to 88:88

Re:Windows and OS X versions, please.

[MikeBabcock]

Windows has the GDI and DirectX, neither of which are remotely comparable to the X window system.

Re:Memcpy not the biggest problem for chrome/chrom

[The MAZZTer]

I haven't noticed any degradation of performance, but yeah, the history files are 900mb for me for only 9 months of use and the thumbnails are 300mb. That's pretty big.

Re:Even if X is usually slower...

[xtracto]

s/then/than/g

Re:Memcpy not the biggest problem for chrome/chrom

[xtracto]

Which is the same for any other program that indexes the text inside different types of files...

The idea behind file/text-indexing is to generate that searchable index trading searching-time with hard disk space.

What to make of ignorant flamebait?

[FranTaylor]

"I also know that graphic displays and inputs are vastly different today than they were 10 and 20 years ago."

Really what is so different other than the number of pixels on the display?

"I suspect that X11 wasn't developed initially with today's needs in mind."

Then perhaps you should read about the original goals of the X window system.

Re:What to make of ignorant flamebait?

[Enderandrew]

Really what is so different other than the number of pixels on the display?

Varying color depth, widescreen display ratios, scaling elements to varying resolutions, transparency and composite effects, GEM, KMS, DRI, hardware and software acceleration, modern font rendering, sub-pixel hinting, LCD displays, anti-aliasing, etc.

On the input front you have mice that with 8 buttons, multiple mice, touchpads, joysticks, touchscreens, mice that poll at varying rates with varying "resolution", etc.

Re:What to make of ignorant flamebait?

[caseih]

All of which X11 has grown to support very capably, thank you very much. Unfortunately while X11 is indeed capable of supporting everything Windows 7 or OS X can do visually, tying everything together with polish is still something in which Linux distros lag behind. For example I have compiz fusion running right now with coverflow-style window switching, expose, etc, but getting the proprietary ATI driver running was a bit difficult. I had to edit grub.conf to add nopat to the kernel after installing the nice packages that I had to get from rpmfusion's repositories (not an automatic thing for Fedora 11 users). After all that I had to install the compiz-fusion extras and then modify /usr/bin/compiz-gtk to allow me to use the ccsm configurator (a UI nightmare!). Not something that is easy for people who just want their computer to work well and look nice.

On the plus side, unlike any other major non-Unix OS, it still retains incredible remote capabilities without resorting to hacks like Terminal Services. In fact, remote X11 apps can, to a point, even use 3D acceleration. The idea of having per-app display settings brings a level of flexibility that, while not that important all users, is invaluable in many places where Linux desktops are used. Cytrix had to do a lot of dark magic to implement the ability to remote individual MS Windows Apps. For folks who use remote X11 apps regularly, NX (GPL FreeNX or commercial NX) will make remote apps even faster.

Re:What to make of ignorant flamebait?

[neiras]

Varying color depth, widescreen display ratios, scaling elements to varying resolutions, transparency and composite effects, GEM, KMS, DRI, hardware and software acceleration, modern font rendering, sub-pixel hinting, LCD displays, anti-aliasing, etc. On the input front you have mice that with 8 buttons, multiple mice, touchpads, joysticks, touchscreens, mice that poll at varying rates with varying "resolution", etc.

That's quite the list; many of the non-input related items aren't the job of the X server though. Multiple-cursor support went in this release, I believe.

So sure, the type of work the X server is being asked to do has changed, but development has been keeping up. Ever since the switch to Xorg things have been ticking along. The new modular build system has made working on the project easier, hardware autoconfiguration works very well, and the deprecation of old cruft is continuing quite aggressively - see http://www.x.org/releases/X11R7.5/doc/RELNOTES.html#AEN620 .

We've come a long way in the last 5 years.

Re:What to make of ignorant flamebait?

[TheRaven64]

X wasn't developed with the needs of modern graphics systems in mind. It was designed to be able to evolve to meet goals that weren't part of the original design. The extension mechanism was inserted for exactly this reason. Things like resolution and screen changing (XRandR), 3D acceleration (XGL), sub-pixel font AA (XRENDER), off-screen rendering and compositing with transparency (XComposite), shaped windows (XShape) and so on have been added. And they have all been added in a backwards-compatible way, so that older applications continued to work, they just didn't usually get to take advantage of them. The composite extension is an exception to this, where applications get off-screen rendering and saved from some redraws if there is a compositing manager running.

Re:What to make of ignorant flamebait?

[JasterBobaMereel]

All of which X11 copes with quite nicely thank you .... ...Most of the Speed or Clunkyness complaints about X11 are actually about QT or GTK , which are Toolkits for predefined windows and controls, these do leave a lot to be desired are slow and overcomplicated

Re:What to make of ignorant flamebait?

[TD-Linux]

Varying color depth - X has supported this for _years_. You can do 1bit if you really, really want.
Widescreen display ratios - ditto.
Scaling elements - if you want it pretty, see XRender.
Transparency / composite - AIGLX
GEM / KMS / DRI - these aren't new hardware, they are parts of X11.
hardware / software acceleration - What, sofware acceleration? What is this? And X11 has supported hardware acceleration since man first put peanut butter on bread.
modern font rendering / sub-pixel hinting - I had these back in the windows 98 days, so X11 was ahead here.
anti-aliasing - see XRender, though most efficient apps prerender to pixel-aligned pixmaps first for efficiency, so this is a non-issue.
I'm not going to even go into your list of inputs just because almost all have those have existed for a very very long time.

Re:What to make of ignorant flamebait?

[ClosedSource]

E: "I suspect that X11 wasn't developed initially with today's needs in mind."

FT: "Then perhaps you should read about the original goals of the X window system."

Yes one of the goals was to develop a system with Tuesday November 3rd 2009's needs in mind.

Seriously, making an extensible system is good but it doesn't mean it's going to be the optimal solution for any particular future. They'll always be scenarios that lie outside the range of anticipated extensions.

Re:It's Chrome OS

[Anonymous Coward]

That logic makes significantly less sense than the fact that it's ultimately based on Konqueror, which was designed for X11 (and Linux) to begin with.

Re:Windows and OS X versions, please.

[Xtravar]

Funny, but the real answer is GDI.

http://en.wikipedia.org/wiki/Graphics_Device_Interface

Re:Windows and OS X versions, please.

[binarylarry]

ORLY X?

Huh?!?

[gbutler69]

Do you even know what the fuck you are talking about? Do you know what XAA, EXA, UXA, etc are? You need beaten with a clue-stick!

Re:It's Chrome OS

[MBGMorden]

No - ChromeOS is looking to be an actual honest to goodness OS built around the Linux kernel with a Google-developed graphics subsystem. They are mainly targetting it towards running their own web applications rather than bundling apps with it as is the case with most other OS's, so the only INCLUDED app might be Chromium, but all indications are that developers will be able to write/port other applications to the system if they desired.

Personally I'm interested in seeing it. It's just an opinion, but most Linux distributions just have far too much legacy code and ways of doing things stacked on top of each other these days. I want an open source OS, but I think we kinda need to toss out a lot of what we currently use and start anew. Unfortunately it's not easy to do that without commercial backing, but Google pushing such an effort would really help things along.

Re:Memcpy not the biggest problem for chrome/chrom

[mea37]

With all due respect, it sounds like you want to blame everything negative about Chrome on one feature you don't like. Just sayin', the developers might have a reason to think that the rendering speed has something to do with the windowing system - they're a lot less likely to be just guessing and calling their guess "pretty sure".

But for the sake of argument - if the history files are the big slow-down for Chrome, why is that slowdown less pronounced on the X11 version?

Uninformed and wrong

[FranTaylor]

"For whatever reason, Linux drivers have NEVER taken advantage of this, and that is why Linux often looks clunky compared to Windows on the same hardware."

This is just BLATANTLY WRONG.

All you need to do is read the feature announcements for the nVidia and ATI display drivers, which you apparently DON'T DO.

nVidia's REAL target market is the folks who work at animation companies, and the hard-core data visualization people. Their products are designed to fly in THIS environment. This market is VERY HEAVILY tilted toward Unix. That is WHY you can get such EXCELLENT display support under Linux. The rest of us are just piggybacking off of this.

Re:Uninformed and wrong

[eggnoglatte]

I don't think you are talking about the same thing as the GP. Of course Linux has excellent OpenGL support for NVIDIA. The question is: are toolkits like gtk using it for their 2D rendering? Because that is what happens on both windows and mac...

Re:not "s"

[cerberusss]

Or just "X". But then again, I've been modded -5 Pedantic Prick because I had said it's called either "X" or "X Window System". Kind of weird, because people would probably correct me if I would say "Windows Vistas" or "Mac OSeX" :-)

Re:Windows and OS X versions, please.

[Rockoon]

Is there a particular reason that you begin with misinformation?

What is this "X11?"

[IGnatius T Foobar]

What is this "X11" of which you speak? It sounds like some sort of Windows(tm) imitator. How can that be? Our wise leaders at Microsoft told us that using Lunix forces you to live in the command line!

Re:What is this "X11?"

[Anonymous Coward]

For added laughs, I just read that the next Microsoft graphical library is going to be called DirectX 11.

A bit like publishing (a few years after ODF) a document format in the shape of a zipped XML file and dubbing it "Office Open XML", I'm guessing..

Re:What is this "X11?"

[cptnapalm]

Windows Direct X 11 and X Windows 11... there are going to be some very confused noobz in the near future.

Re:Firefox did that already

[Loki_666]

Quote: 500+ tabs open simultaneously

You are shitting us? How the hell can you get anything done with 500+ tabs open simultaneously? I don't think its memory leaks thats your problem. I think its the sound of the entire OS deciding enough is enough and its going to take a break.

Chrome vs Firefox

[deathguppie]

I don't know about Chrome being faster on Linux than Windows, but I do know that it cleans the plate vs. Firefox on Linux. I'm using the Ubuntu version at "deb http://dl.google.com/linux/deb/ stable main" and I can finally pull Slashdot stories up in a second tab without locking up the browser while it loads. Scrolling and rendering are also noticeably faster .

Re:Chrome vs Firefox

[aardvarkjoe]

It certainly works much faster than Firefox on Linux in most circumstances. One thing I have noticed, though, is that Flash applications seem to run much more slowly in Chrome than in Firefox (to the point where Chrome becomes unusable on my computer for some sites that run acceptably in Firefox.) That seems a little weird to me, since it's the same plugin. Hopefully it's a problem that will be corrected before the official Linux release.

That and the lack of a decent ad blocker are the main things that keep me from switching from Firefox. I really like the speed and the interface is generally a big step forward, but I don't really like having to switch between two browsers.

Re:Windows and OS X versions, please.

[Tacvek]

The equivelent to X11 on Mac OS X is a program known as "WindowServer". This program could be argued to be part of the Quartz Compositor, it could be argued that the Quartz Compositor is part of this program.

The second interpretation would argue that the Quartz Compositor creates and generates the images to be displayed, and provides them to WindowsServer for it to place them into video memory. That is not the official interpretation as far as I know. I believe the official interpretation is that WindowServer is a component of Quartz Compositor. That bakes Quartz Compositor both a compositing window manager and a windowing server.

For Microsoft Windows I've been unable to determine what program is closest in nature to X11.

All of this is complicated by the fact that there are X11 for both MacOS and Windows that instead of driving the video card(s) directly like X11 does on Linux, it uses the Windowing servers the host OS, and also provides the option of using the Host OS's window manager as an X11 window manager.

Re:Windows and OS X versions, please.

[jedidiah]

IOW, MacOS 10.

X is just a "fancy" way of writing 10.

It also has the "added benefit" of possibly being confused with the Unix "GUI".

Re:Even if X is usually slower...

[jedidiah]

X has it's problems. It also has it's advantages. Some of those
advantages aren't so much a matter of X itself but side effects
of the old school Unix way of approaching a problem.

Seeing MacOS going through vnc side by side with X apps being
run remotely (and viewed locally) certainly gives me no
burning desire to get rid of X.

Re:Windows and OS X versions, please.

[cp.tar]

Funny, but the real answer is GDI.

As opposed to the Brotherhood of Nod?

Re:Even if X is usually slower...

[Zordak]

Really? I thought he was trying to leverage the cloud architecture to optimize his software services enterprise based on open standards.

Re:Windows and OS X versions, please.

[eggnoglatte]

I know X is kinda old, but was under the impression that roman numbers were even slightly older. ;-)

Re:Windows and OS X versions, please.

[ceoyoyo]

OS X does have a "GUI" called X, which is the same as the one that's been around for 20+ years. It also has a GUI called Aqua.

The operating system as a whole is called OS X, probably in no small part because it's easier for some reason to trademark a series of letters "OS X" than it is to trademark a version number "OS 10." Also, X is the Roman numeral for "10."

You seem to be the only one confused.

Re:Windows and OS X versions, please.

[BitZtream]

No.

Explorer is a cross between your shell and your window manager, its like the Gnome or KDE window managers except most of the window manager functions are the responsibility of process itself in Windows, although they are provided by the standard libraries, which us things like the uxtheme.dll and company to provide a consistent interface until the app goes well out of its way to do otherwise. You can use cmd.exe in place of explorer and apps won't notice the difference unless they interact with explorer, such as things that put items in the notification area (systray to most). Apps do not talk to explorer to display windows any more than apps on Linux talk to Gnome or KDE, or Finder on OS X. None of them have to be installed or work in order for Windows to be displayed. You can kill all explorer.exe processes in windows and you just won't have a start menu or clickable desktop until it restarts. You can not kill the X11 client and do the same, all processes using it will be disconnected and exit or crash.

Quartz is a toolkit/API used within the 'window_server', like DirectX to some extent on Windows. It is not the generic low level API like GDI is on Windows.

'window_server' would be almost the direct equivalent of X11 on OS X in native applications, if you exclude X11 for OS X, which acts as a translator basically between X11 servers (applications) and your X11 client (the gui you see) and passes that along to the window_server process to display.

In reality, all three of these systems use a different mix of the way these components interact and at which layer things are done due to their different designs. There isn't a 1 to 1 relationship between any of the components.

I do not recall which process on Windows handles the GUI, but it is more or less untouchable, unlike in OS X and traditional UNIX where you can easily kill the gui portion, doing so in Windows traditionally would result in a blue screen, this is no longer strictly true in the Windows 6.x versions (Win2k8/Vista/Win7), but I don't recall what process owns that part of the system off the top of my head.

Re:Memcpy not the biggest problem for chrome/chrom

[BitZtream]

Files you can't limit in size, can't compress, can't optimise. Instead all you can do is to delete them and loose all your precious history information.

If you want a bunch of features to tweak, you shouldn't be using Chrome. Its not intended to be full of a bunch of crappy features that 3 people use and 1200 extensions to make it run like crap. Its meant to be lean and mean.

Chrome supports cleaning up the history with a few options, you can delete the last day, last week, last month, or entire thing. If you want more options, you're using the wrong browser. More features bring more bloat, which is why Firefox has become such a pig. Please don't try to make Chrome another Firefox, then we'll just have to start ANOTHER browser to get back to where it runs fast.

Use Firefox if you want feature rich and bloated. Use Chrome if you don't want a toolbox, an Application development environment, the kitchen sink, and more code than needed to power some small countries.

Why would you be surprised?

[Phil Urich]

But the 4.X beta runs incredibly fast on my dual core Windows workstation. If the Linux version is significantly faster in rendering, I would be very surprised.

Just because it runs quite fast on your machine in no way precludes it from running faster on a setup that's more optimized and/or with less overhead (ie. X11/Linux). And just because things happen in nearly the blink of an eye doesn't mean that relatively they couldn't be significantly faster...it just means that you'd be nearly unable to notice a difference and thus wouldn't be inclined to care ;) "Whoo, this webpage loaded in 0.16 seconds instead of 0.20, I'm so glad I switched operating systems!"

(P.S. at this point, isn't dual-core the new single core? It's almost less "this system is so fast" and more "maaaan, this program is so non-bloated that it runs fine on a mere dual-core; suck it, Crysis!" I kid, I kid).

Re:Why would you be surprised?

[H0p313ss]

(P.S. at this point, isn't dual-core the new single core? It's almost less "this system is so fast" and more "maaaan, this program is so non-bloated that it runs fine on a mere dual-core; suck it, Crysis!" I kid, I kid).

Good question really... My gaming rig for the past two years has been a quad-core, I can barely tolerate the old dual-core crap my company pays for now.

Consequently I am seriously entertaining the thought of getting a mac-pro with a PAIR of quad cores and enough ram to bathe in.

Re:Windows and OS X versions, please.

[eugene2k]

Actually, I think the window system in windows might reside in the kernel itself.

By the way, the wikipedia page says this about GDI: "GDI is similar to Macintosh's QuickDraw and Linux Xlib."

Re:Windows and OS X versions, please.

[eugene2k]

Explorer.exe is the equivalent of GNOME's nautilus. It's not a window system.

Re:Windows and OS X versions, please.

[Urza9814]

No, if you want them to use OS X then they must also just use 'Windows Vista' or 'Windows 7', along with 'Ubuntu Linux 9.10' or 'Mandriva Linux 2009.1'. If they're just saying 'Windows' and 'Linux' then they should also just be saying 'Mac OS'...and personally I don't think anyone is gonna confuse 'Mac' and 'Mac OS' in this context.

What you're saying is equivalent to saying that they should be talking about HP, Sony, and tro 1000 for the hardware. (tro being half of 'Vostro')

The company is Apple, the product is Mac OS, and the version is X.

simple

[jipn4]

Mac, Windows, and X11 all are client/server window systems with a separate user process for rendering. X11 was designed from the ground up for that model, while both the Mac and Windows started off with different models and tried to retrofit an X11-like model onto their existing APIs. It's not surprising that they don't do it so well.

People tend to overestimate Windows and Mac performance for a couple of reasons. For example, Macs cache a lot more stuff than other platforms (and use a ton of memory to do it). And the X11 back-ends for cross platform libraries and ports are usually not very well written, and people blame X11 when they should be blaming those libraries.

Re:Windows and OS X versions, please.

[H0p313ss]

By the way, the wikipedia page says this about GDI: "GDI is similar to Macintosh's QuickDraw and Linux Xlib."

Whereas the Hitchhikers Guide to the Galaxy refers to it as: "The result of a lost weekend of binge drinking by a group of wankers who will be first up against the wall when the revolution comes."

Re:Windows and OS X versions, please.

[Anonymous Coward]

MS Windows = Explorer.exe
Linux = X11
MacOS = Quartz

That this is marked up as informative really shows how bad slashdot has become. You losers are even shitty at being computer nerds.

Re:Windows and OS X versions, please.

[ToasterMonkey]

Mod up.

Sounds like they need to fix the Windows builds.

[BitZtream]

Most of what they've listed is as the reasons its faster on X are entirely possible in Windows. Specifically, things like letting the GUI handling backing stores have been there since at least Win95, I don't know about before that, but I doubt Win 3.x or earlier had them. Sadly, it is not the default. Of course, X doesn't do it by default either.

At a low level, I found coding for X enjoyable, but requires more work for trivial tasks. But for writing any sort of complex app, just the dependency tree alone gets to be a headache compared to how lazy you can be in OSX and Windows and still get good performance and feature balance.

They are different environments, if you focus or code towards the style of one, the others are going to suffer. Its just as easy to code towards the Windows way of doing things and end up with some REALLY shitty X performance.

Re:Windows and OS X versions, please.

[devjoe]

The operating system as a whole is called OS X, probably in no small part because it's easier for some reason to trademark a series of letters "OS X" than it is to trademark a version number "OS 10." Also, X is the Roman numeral for "10."

And just like Intel did with the Pentium, once they figured out how to trademark a version number, they stuck with that same number for ages and ages. Intel eventually got over it, but I think only due to the fact that they were making different processors aimed at different markets.

Re:Windows and OS X versions, please.

[Xtravar]

Yeah, I know it wasn't completely accurate, as you can run in circles with these APIs, especially on Linux where Windows GDI is most like libcairo, but then libgdiplus depends on libcairo (I believe).

But the point of it all is that GDI is the lowest level graphics API that is clearly delineated on Windows, and so it kind of fit with the previous post which mentioned Quartz. The fact that X11 does drawing AND windowing/events sort of makes it hard to find a one-word equivalent.

Re:Windows and OS X versions, please.

[Yvan256]

We need more minerals!

Oh wait, wrong game.

Re:Windows and OS X versions, please.

[Yvan256]

You should just ask them why they keep talking about the Media Access Control address.

Re:It's Chrome OS

[that this is not und]

Apparently you want BeOS. Why not just dig up a CD copy of it and run with it?

None of that nasty 'legacy' to get in the way of your fresh new look. And even a handful of applets to run, since there are almost no third party apps.

Re:Windows and OS X versions, please.

[Xtravar]

When you're handling WM_PAINT event in Windows, you use GDI to draw your custom widget.

When you're handling drawRect: on OS X, you use Core Graphics/Quartz to draw your custom widget.

So I'd like to know the reasoning for not equating GDI with Quartz - in the typical scenario, they're used for the same thing and have similar calls.

Re:Windows and OS X versions, please.

[JCholewa]

explorer.exe does more than that. It is also the handler for the Windows equivalent of gnome-panel. That's why when (in 2k and XP, at least) your file manager in Windows freezes and you tell it to force quit that window, your entire startbar/desktop vanishes for a few seconds.

Re:Windows and OS X versions, please.

[Alef]

X11 servers (applications) and your X11 client (the gui you see)

I think you got it backwards -- the applications are the clients. They use the X server to receive input and get their windows displayed.

Oh dear. So wrong.

[Anonymous Coward]

Let's just say you're wrong and I've seen flickering on plenty of Mac OS desktops.

And with X11, the flickering you get is more likely due to the program ignoring X backing store and "doing their own thang". Well guess: their failure isn't the fault of X11, is it.

"To be fair to X, managing compositing et al isn't it's job---but it should be!"

Compiz: It IS!!!

Sheesh.

And Enlightenment had compositing freaking YEARS ago.

" Between X's by-design paucity of features"

You mean like C's "paucity of features" that means libraries that do whatever you damn well want?

There is no "by-design paucity": by design X11 is extensible. See X extensions.

"Had X been designed a little more smartly (eg, for actual people and not for computer scientists) this probably wouldn't be such a problem."

Uh, what design WOULD have been for "actual people"? This statement, bald as it is, makes no sense.

X11 is designed for the task it has to solve: drawing a GUI.

One program: one purpose. Expose capability and don't impose process: someone may think of a use you never considered when writing it, so don' t write a program that will hate them for it.

The UNIX way.

Which, oddly enough, Apple have embraced to a large extent since bringing out Ten.

"By comparison, again, we have MacOS X's system, which again just works, even if in theoretical terms it's a little slower."

Two problems: the dissing of X is how slow it is. So Ten's system being slower should be more dissed, yes?

Secondly, ten's system doesn't just works else there would be no problem with "But Mac can't support clones, they have to have a limited selected hardware to deliver the eXPerience!". Ignoring that this just works meme is wrong. I've seen it often just stop a lot.

"The UNIX Hater's Handbook, which is a little bit out of date now, goes into the design errors of X "

And here we see where you've been misled.

The UNIX paradigm is extensibility. Policy is set by the use of the program. not by its programming. And the UNIX haters hate UNIX so hate the UNIX paradigm. Ergo they hate X too.

Maybe they're just a little bit predisposed to a priori conclusions...

And it's not the "why does X drive people nuts" it's why do people get a stiffy when the opportunity comes to diss X?

(oh, and a quick look at that, hmm, *discourse* seems to be a person who gets a real big boner over getting to rant and rave about how X is teh devil. Could he be any less coherent?)

Re:Windows and OS X versions, please.

[Kymermosst]

You can thank your beloved Apple marketing gurus for that one.

"Hello, I'm a Mac."
"And I'm a PC."

Re:Predictable

[mzs]

There are lots of people named Linus, this is likely not who you think it is unless you find yourself disagreeing with a Mr. Upson regularly.

Re:Windows and OS X versions, please.

[jabjoe]

The Windows kernel is like X and Linux in one. Explorer is just a file manager with multiple windows as multiple instances, with a special window that is the taskbar. So of course killing it doesn't kill you apps (well End Process Tree can). It's not like X at all. In Linux, if you kill X, you are killing graphics. The closest thing to killing Explorer on Linux would be to kill Thunar/nautilus and kill xfce4-panel/gnome-panel. None of which will take out all your applications either.

I'm not sure how far I go with making X save everything and restart on a X panic... But X is in the middle of some interesting developments, and this kind of thing will be easier on the other side of those developments, but X crashes should be reduced as result of X being simplified, so maybe it won't be needed... The only problem is the closed graphics drivers people not joining in....

Re:Windows and OS X versions, please.

[jo_ham]

But didn't someone mention earlier that in X11 terminology, client and server were reversed, or has it been swapped around to make it more logical?

Re:Windows and OS X versions, please.

[Elektroschock]

They praise the DIB perfomance. In other news Wine still needs a DIB engine because graphics with X is so slow.

FYI: Firefox QT Port

[mpapet]

http://browser.garage.maemo.org/news/10/

One of the architecture mistakes in the Google browser was *not* using Qt.

Vive la X

[petrus4]

I've noticed that X unfortunately gets a lot of metaphorical rotten vegetables thrown at it from Linux users; even people who apparently are fans of Linux in every other respect.

In my own opinion, however, X qualifies as one of the greatest pieces of software ever written. Put it in perspective, here; the system has been in continual use and evolution since 1984. That's 25 years this year. Granted, its' configuration process in particular has needed radical reform, and fortunately it has recently got it.

I don't understand why people criticise its' stability, either; for me it has always been rock solid, particularly on FreeBSD.

I'm also not really surprised that Chrome might run faster under X than under Windows or the Mac. If there's one thing that's always been true of UNIX in general, it's that the system doesn't include unnecessary frills. When you're wanting to be optimised for speed in particular, that can only be a good thing.

I love X.

Re:Windows and OS X versions, please.

[Alef]

The only terminology I have ever heard of calls the X server "server" and applications using it "clients". Perhaps you are referring to the fact that the X server typically executes on the client computer (the user's computer), because that's where the keyboard and screen is, while the application (client) sometimes executes on a server computer, to which the user might have connected using a remote shell (such as SSH).

Re:Windows and OS X versions, please.

[Tetsujin]

That's not what he's talking about. OS X is a BSD-based system and as such, can run almost any Unix program, including X11. Apple has been including XQuartz (X + a bunch of libraries + hooks so it works nicely with the rest of OS X) since Leopard.
http://xquartz.macosforge.org/

Nicely? I never thought it worked that nicely... Though maybe they've improved things since 10.4 "Cheetara"...

What?

[ratboy666]

- As to overwriting. This occurs because the update events follow behind the UI. The problem is resolved by the composite extension, or by enabling backing store -OR- by increasing network bandwidth. Some old X Servers didn't have backing store (and certainly no compositing), AND ran over constrained pipes. It hasn't been a problem with desktop X for years.

- X is extensible by design. Multiple display support, accelerated 3D, video playback and compositing do work. For $DEITY sake, I use these features on my stinky little Acer Aspire One using Linpus! No particular problems -- "it just works" (tm). I don't like transparent windows, so I just don't bother, but it does work. Why the hell would a user want to know about the alphabet soup? Just use a packaged OS. The alphabet soup comes about because the development of X is an open process.

- And, in comparison with the Mac, you do notice that Apple packages an X Server with OS X? When running in a heterogeneous environment, it's necessary.

- Finally, you bring up the Unix Hater's Handbook. Ok, let's break it down:

1 - xload, xterm and xclock are possibly among the LEAST used programs under modern X based systems. They weren't
even installed on my Acer when I got it.

2 - Motif isn't used anymore.

3 - Cut and Paste really isn't an issue anymore, either.

4 - ssh -Y is usually used to remote X servers - authentication isn't an issue anymore either.

5 - Gnome and KDE provide the "customization methods"; since xterm isn't used anymore (or xcalc, or xedit),
the xresources issues are also gone.

6 - imake has been deprecated for YEARS.

7 - Pretty much nobody uses raw X protocol or XLib anymore either.

8 - NeWS was "killed" because IBM and DEC didn't want a repeat of NFS - they didn't want to send SUN any more money. So, they marketroids forced the issue. I agree the superior technology didn't win, but X is still around. Sucks to be the customer when they get what they have been told to ask for.

The UGH was relevant in the early '90s. No longer.

The "MAC UI Experience" could be planted on top of X. I am disappointed that Apple isn't driving that. It would involve developing several extensions that would be useful to X users. But, if Apple doesn't want to do it, others will:

http://www.freedesktop.org/wiki/Software/CompositeExt
http://en.wikipedia.org/wiki/XRender
http://keithp.com/~keithp/talks/randr/randr/
http://en.wikipedia.org/wiki/X_video_extension
http://docs.sun.com/app/docs/doc/801-6662/6i1196cd6?l=ja&a=view

The first four are generally implemented. The last is not (X/DPS). But, MAC OS X only implements a subset of X/DPS anyway (and, of course, it isn't compatible).

Re:What?

[Random Walk]

3 - Cut and Paste really isn't an issue anymore, either.

I beg to differ - it wasn't an issue, but now it is one. Once upon a time, every app supported the standard way of cut and paste (right and middle mouse button).. but now we have apps who do it like this, and others who want me to do Ctrl-C / Ctrl-V because someone thought it would be cool to emulate MS Windows and force me to get my hand from the mouse and to the keyboard. And then there are apps where cut and paste would work one way for some input fields, and the other way for some other input fields...

Re:What?

[ratboy666]

You know, you may be right -- I generally use OpenOffice, terminal sessions, Firefox, and some utilities.

For terminal, when I use "terminal" I can cut/paste *or* middle click. But, sometimes I use xterm (so I can pass in font selection on the command line) -- then, its middle click only.

Between OpenOffice, FireFox, Evince, its pretty much ok.

Re:It's Chrome OS

[MBGMorden]

Actually I loved BeOS, and it was a PRIME example of how to do an OS right from a technical standpoint. If you compared BeOS to your average Linux distribution of the time you'd notice that BeOS literally ran friggen circles around Linux when it came to a desktop user experience. Alas, it doesn't meet the open source part of my statement (making it impossible to still maintain support on modern hardware), nor does it any longer have the commercial backing I mentioned.

I AM anxiously following Haiku, but without the commercial backing, I think ChromeOS has a better shot at success - and with success comes good third party app support.

Re:Windows and OS X versions, please.

[Xtravar]

Analogous perhaps from the infrastructure perspective, but not from the application perspective. I wouldn't tell a Windows application developer that he has to learn DirectX to do GUI programming in Windows.

MAC OS X

[Tetsujin]

No. It's MacOS 10. OS X is just stupid intentionally confusing terminology.

X is the Roman numeral for 10. It's "Mac OS X", which I pronounce as "Mac oh-ess ten".

I pronounce it "Mac O'Sucks"

Re:MAC OS X

[gmhowell]

I bet you spell Microsoft with a dollar sign as well.

Do your parents know yet that you'll never be the source of grandchildren?

Re:MAC OS X

[Tetsujin]

I bet you spell Microsoft with a dollar sign as well.

No, I prefer to use actual words when I talk about how shitty Microsoft is. :)

Though I guess it should be noted that if you simply pronounce "Mac OS X" phonetically and fuck with the timing, you still don't get "Mac O Sucks" - it's more like "Mac O Sex"

Re:Memcpy not the biggest problem for chrome/chrom

[MikeBabcock]

Thanks for the inane and completely uninteresting reply. Creating an index file that cripples system performance is not actually that helpful though. Eventually the trade-off isn't one anymore and the system is too slow maintaining the index to be usable.

For and against tighter integration of wm's

[Tetsujin]

How much of the graphical user interface evolution on UNIX has been put back because the varying WMs and toolkits?

It's better now that we're down to X.org and GTK or Qt, but years were wasted because you couldn't write an app that took advantage of, say, Display Postscript or multi-head or decent colour-correction or a given GUI toolkit without restricting your market.

For a very long time---and ending not so long ago---state of the art, cross-platform GUI toolkits on UNIX started and ended with Motif. That's horrible.

That doesn't really speak to the question of whether the window manager should be built-in...

I mean, I don't want to sound like the situation is all roses here. Yes, as you say, there's been a lack of focus that has detracted from the overall experience. But, you gotta look at the bright side, too. Suppose Motif and/or mwm had been integrated tightly into the X server... Where would we be now? We'd still be stuck with it, probably... Would we really be happier knowing that a clear direction had been chosen, if that clear direction sucked?

I think the lack of focus is an unavoidable consequence of a system that's developed without clear-cut, authoritative leadership. That's a down-side of using a system that's not been designed by a single group like Microsoft or Apple. But the up-shot is that a system like that is open to experimental ideas. The result isn't a true meritocracy of software (that is, no matter how good a piece of software you might write for a particular task, there are still practical problems in terms of getting people to invest themselves in using it) but there are always options...

Going back to the question of tighter integration of the wm with the X server - I remain unconvinced. I could see how X could benefit from better compositing support and other features to make wm's behave better, but I don't see what the benefit would be of having the wm built right in to the X server. It seems like running it on the local machine is just as good...

Re:Windows and OS X versions, please.

[dotgain]

They didn't create the 'definition' of PC, they're just using terminology that is already mainstream. Would've been kinda stupid not to, don't you agree?
"Hi, I'm a Mac."
"And I'm an AT-compatible Intel-based computing platform running the Microsoft Windows Operating System"
I think the term 'PC' and its association with MS Windows predates the Mac vs. PC ads, just slightly.

Upstream X devs

[Sits]

Intel pay for a lot of X devs at the moment who do upstream development as well as Intel driver development: Eric Anholt, Jesse Barnes, Keith Packard (of at least Xrandr and COMPOSITE fame), Ian Romanick, Carl Worth...
Red Hat employ some upstream X devs too: Dave Airlie, Peter Hutterer, Adam Jackson, Kristian Høgsberg (who made Wayland) spring to immediate mind (I think they also used to emply Jesse and Carl)
Novell employ Matthias Hopf.
Nokia employ Daniel Stone.

There's an (incomplete?) list of xorg devs on ohloh. Just because you haven't heard of them doesn't mean they aren't out there hacking away...

Re:Windows and OS X versions, please.

[mrboyd]

Just saying but Roman numerals have been with us for about 3000 years before X "the display" existed.

Re:Windows and OS X versions, please.

[ClosedSource]

I don't know about the Mac, but I don't think there's anything in Windows that corresponds with a network protocol with GUI functions in "a bag on the side".

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Windows and OS X versions, please.

[Guy Harris]

Explorer is a cross between your shell and your window manager, its like the Gnome or KDE window managers

Actually, it's a file manager, hence like GNOME's Nautilus or KDE's Konqueror (the file manager part) or Dolphin. It might also provide functionality of various bars on the edges of the screen (task bar, etc.) and the desktop; I'm not sure which parts of GNOME and KDE implement those.

You can not kill the X11 client

...by which you mean the process/program that the X11 developers call "the X server" (because, with the model of "clients connect to a server and ask it to do things for them", that's the role it serves, confusing though that terminology might be for those who have a model of "a client is something like your desktop machine, a server is a machine in the machine room" nonwithstanding).

Re:Windows and OS X versions, please.

[Guy Harris]

Us losers? Are you implying that somehow you are exempt from being a loser while still posting to slashdot just because you are anonymous?

An anonymous coward who knows what he or she is talking about is far more valuable than a poster with an account who doesn't.

Wrong

[Kludge]

The window manager should have been part of X from the get-go.

The window manager should NOT be part of X. Choice of window managers is a good thing. And what is even better is choosing and changing window managers without logging out. Or running them in different windows (really handy sometimes.)
99% of users don't do that you say? I don't care. It's nerdy goodness, and this is news for nerds.

Re:Forwarding

[OrangeTide]

It took the rest of the world a long time to realize that engineers and scientists like network-centric computers. But X's design isn't useful to a few people out there, so it was quickly brushed aside by Mac and Windows fans as being archaic, obsolete, slow, etc.

It's a Window System called X.

[anon mouse-cow-aard]

A lot of folks misunderstanding does not make them correct.

X is the name of the thing. It is a window system. There should be no 's' at the end. "Window" is not part of the name. Look at any copyright notice, or any related site, like: http://www.xfree86.org/ "Home of the X Window System." The display server is an X Server, not an X-Windows Server. the clients are X clients, not X-windows clients. Look at the wikipedia article, it refers to the X protocol, X terminals, ad nauseam ...

So yeah, there should darn well better be a [sic].

Re:Windows and OS X versions, please.

[mr exploiter]

I think it's only the persons that call the terminology reversed are the ones that are backwards. It's very logical to me.

Re:Forwarding

[ClosedSource]

"OK great, how do I get this display from that PC to that one over there"

You just switch the cables.

Seriously, how many PCs of the Windows 3.1 era even had network cards. Most Unix guys really have no understanding of the limitations of early PCs and embedded systems.

Re:Windows and OS X versions, please.

[gmhowell]

10 would be the fancy way, what with it being harder to make circles in stone with chisels vs. making crosses.

Re:Memcpy not the biggest problem for chrome/chrom

[xtracto]

Eventually the trade-off isn't one anymore and the system is too slow maintaining the index to be usable.

That is a problem with the design of your selected indexing program (Google Desktop Search from your previous post). Try something like Copernic Pro for a change. There is also PocketSearch which is free.

Re:Even if X is usually slower...

[LS]

No, he said it very clearly: He's trying to render a framebuffer OS GUI like bitmaps when instead he should be using vector based information, using a Synergy2 client with cloud-based actionscript pseudo-code, reverse-compiled on a middle-endian pdp-12 zipdisk array. You thought Web-2.0 was easy. Don't be so condescending....

Flash?

[oglueck]

Who cares, when a Youtube Flash video is eating almost 100% of your CPU because it's idiotic use of X11? Playing a plain MPG video in mplayer uses almost no CPU.

Re:Memcpy not the biggest problem for chrome/chrom

[MikeBabcock]

My complaint was specifically about Google Desktop. It was related to the parent's comment about a design inefficiency in Google's Chrome.

At no point did I complain that I wanted a better desktop search option, nor did I say I hadn't found one if I was. My comment was solely and quite obviously interconnecting the two as a Google database inefficiency in their desktop db design.

Please learn to read context before replying.

Re:Windows and OS X versions, please.

[Lars T.]

And just like Intel did with the Pentium, once they figured out how to trademark a version number, they stuck with that same number for ages and ages. Intel eventually got over it, but I think only due to the fact that they were making different processors aimed at different markets.

And the X Window System has been stuck at version X11 for over 20 years now, so long that hardly anybody calls it "X Window System" anymore instead of just X11. When will they get over that?

Re:Windows and OS X versions, please.

[BitZtream]

Both of your points are 100% correct.

I know better on the X11 client/server side, and in my haste made sure to reverse what how I wrote them, which of course is wrong on my part. My dyslexia broke my dyslexia.

nx speeds up remote X usage dramatically

[Nivag064]

If you use 'nx' on both the server and client machines, you will find x applications running much faster.

The nx application intelligently caches x commands.

# yum info nx
Loaded plugins: refresh-packagekit
[...]
Installed Packages
Name : nx
Arch : x86_64
Version : 3.3.0
Release : 38.fc10
Size : 12 M
Repo : installed
From repo : updates
Summary : Proxy system for X11
URL : http://www.nomachine.com/
License : GPLv2 and MIT
Description: NX provides a proxy system for the X Window System.

#