OSNews

I've never had a problem with it. X is designed to be able to do that, but I'm not sure how good the implementation is.


Well, maybe it can do that in some special cases, but I know that I've had Windows 7 and XP crash and bring down everything. My point is, in any OS, if a critical system component goes down, everything will go down. And Windows in general is more prone to this since it is more tightly integrated. Also, I've never had X crash, but I use only Intel hardware, which has very good drivers, so I understand that I'm not in the majority...

There is certainly nothing in X that prevents apps from not killing themselves if X crashes. The main problem is that right now, the toolkits leave a lot of state on the server. However, if you look at the design of Wayland, there is really no server state. The kernel stores the window surfaces. This means that it would be trivial for apps on Wayland to reconnect. The nice thing is that the same method is entirely possible with X too, toolkits are just lazy.


I don't think so. Enlightenment is gaining some usage with Samsung's Bada thing, but other than that, my guess is that its usage is declining.


This is just a myth popularized by Adobe (which is just using the myth as an excuse to be lazy). It's actually really simple. If you are writing anything to do with playing or editing videos/music, you use GStreamer. If you just want to play some simple sounds in your app, you use libcanberra. If you are writing a game, you use SDL. That's pretty much it. Those libraries will handle all the low level things that you don't need to know about. It's really not complicated...


True, it's not perfect. It still beats Windows, where every other app decides to draw its own ugly, unthemable widgets. Linux is certainly way more consistent in this regard. However, Mac OS X beats them both by miles.


Yes, it's really not realistic. I'm probably going to start using KDE soon, because I'm tired of GNOME not doing anything interesting in the last 5 years, and I really don't like GNOME-Shell.

X is a server, not a framebuffer with compositing and acceleration. It is a design made to scale up and allow advanced corner case of headless, or mindless (thin) computers.

It was designed to be that and it is. If you think it's too much for you, then it probably is. Some design decisions may make sont aspect of it look strange compared to Windows, but it is not done without reasons. Your needs are just too restricted to see why it have been done that way.

Looking at other posts, it seems that several other people have this problem, but that it isn't necessarily related to X. So although I don't understand how an unresponsive graphics layer can exist at all (just put X and the toolkits at RT priority ! ^^), I won't try to argue.


I only encountered this because of a BSOD. If you're talking about X, please compare it to the equivalent part(s) of Windows. A kernel crash is not the same as a graphics layer crash.


A graphic layer is *not* a critical component. As long as the kernel is alive, every error should theoretically be recoverable without reboot. As far as I know, Windows NT does this pretty well...


I don't want to discuss general Windows quality, just to say that their design, in this precise area, looks better to me.


That's probably it. Before my new laptop (which won't ever work with anything else than VESA on linux), I've never owned any graphic hardware from Intel because I used to play games in the past. Drivers from ATI and NVidia can cause severe crashes, both on Windows and Linux.


This looks interesting. I just wonder : do you think that the "lazy" part is sufficiently important to prevent guys from the QT and GTK teams from fixing one of the worst design flaws of the linux desktop ? Are those behaviors so deeply embedded in QT and GTK design, so that a major rewrite would be necessary in order to get rid of them ?


Ubuntu is considering using it too, and since it is at the moment the #1 beginner linux distro, chances are that they could turn it into less of a technological demo and more of a mature desktop...
I tried E17 some times ago, it looked very nice and speed was impressive, confirming my impression that hardware acceleration should not be needed on the average PC, but it lacked some global vision and was still too buggy for everyday use.


Well, they are partly right. I remember days spent fighting with OSS emulation, nightmarish encounters with PulseAudio, struggling in order to make all applications support popular codecs (be them based on GStreamer, FFmpeg, or Xine, that is). Then there was arts fighting with ESD, before phonon came around. And JACK was incompatible with all of them for some reasons, even if some walkthroughs pretended to make other apps work with it (it was a flat-out lie). Looking at this, I think that there really is a problem with multimedia infrastructure on Linux. It's just much more complicated than it should be.


In all cases, there should be one standard toolkit to rule them all ^^ Though actually, except for Adobe apps, drivers, and other support software, Windows managed to keep a relatively consistent toolkit in all apps until the XP days. Then came the Vista days of consistent look&feel inconsistency, which are far from being over yet...

QtCurve might suck, but QGtkStyle (the style Qt uses on Gnome desktop) looks just like the Gnome theme looks, and uses the native dialogs.



I don't see a need to rewrite anything in Qt. Why rewrite a program in the first place? You just let the old program live on and write a new program.

Right now the innovation within Gnome happens on Javascript + Clutter...

If you're using the default Oxygen theme, try the Oxygen Molecule GTK+ theme at:

http://kde-look.org/content/show.php?content=103741

You'll probably have to manually install it, but I find it makes GTK+ applications fit in just as well in KDE as QGtkStyle does for Qt applications in GNOME/XFCE. It still doesn't use native dialogs, but it does make the GTK+ dialog look like it belongs in KDE.

I don't know why more distributions don't package it; the only ones I know of that do are Gentoo and PCLinuxOS, the latter of which uses it by default.

Try to play with it when some heavy calculation is running in the background, and see if it remains responsive ^^

Are you saying that X becomes unresponsive if you have heavy calculation in the background? If so then you're just talking out of your rear-end. I often compile stuff and as you should know compiling IS rather CPU intensive. And I haven't noticed any kind of lag or issues with responses from X.

Wrong. If windows' graphic layer crashes, and I've seen it crash many times, the desktop disappears for a moment, then reappears with all your apps on top of it. You can safely save your work before rebooting your computer and investigating what's wrong if crashes happen again.

True, indeed. And surprisingly many people insist that X and Windows act the same in this regards but they don't: I've had X crash several times and it took down everything I had open, including a coding session I hadn't saved for half an hour. But I've also had Windows graphics layer crash, in XP and in 7, and all that happened was that the screen went black for a moment and then got back, with all my apps still intact.

What does this mean? Well... that even the god damn old XP handles this thing better than X!

I was under the impression that apps crashing when X goes down was due to the toolkits and not X, since X is not actually killing anything nor stopping apps from reconnecting.

At the end of the day you are still losing your work if X crashes, but the blame is not on the usual suspect.

Why do people keep saying this? X handles it fine. It's Gtk+ and Qt that are too lazy to implement it properly.

A good way to understand it is to look at how Wayland works. Pretty much all clients do is get events from the server, and give handles to kernel-managed buffers containing the window contents to the server. This means that a client would not even have to know if the server crashed. A new server could just take over on the same socket, and everything would be fine.

The same method is possible with X, it's just that X makes it a lot easier to design your toolkit in such a way that this is not possible... (like how Gtk+ and Qt do it now)

Try to play with it when some heavy calculation is running in the background, and see if it remains responsive ^^ Though you're right that "slow" is not the good word. In terms of performance, X is acceptably fast, except for demanding things like games where I think that crappy drivers and compositing are more likely to blame. "

Again, don't blame shortcomings of Linux on X11. Just because Linux has a horrible scheduler that can't handle background tasks without locking up the X interface layer, doesn't mean that's how it is for every OS that runs X11.

For example, FreeBSD can run a tonne of compilations and file transfers in the background, without affecting mouse/keyboard input in X.

There's nothing wrong with X11 ... just with some of the OSes that is runs on.

Really, there is no problem in Linux or X with interactivity.

Don't make things up. The CFS scheduler is quite good and has no problems with interactivity on the desktop.

If you want to see a bad scheduler, look at Windows XP. I don't know if it has been improved in Vista and 7 though.


Umm... so can Linux. I do it all the time.


While there are some things I don't like about Linux, in general, we would be much better off if X were replaced than if Linux were replaced.