We reported earlier on a blog post entitled "Ubuntu Report Card (2009)" where the author detailed how they felt the Ubuntu experience had improved over the years. In a follow-up series of articles looking at the future, Tanner Helland has written 10 different broadly-scoped feature requests that [he] 'and many others would like to see by the time Ubuntu 10.10 rolls around'.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2009-05-06
Argh, more blind X hate.
Play with X and ssh. Sorry, but it's a great system.
From the shell on a the laptop I can:
* login into the desktop
* run some gui app so it's windows are on the laptop's desktop for me to use as I see fit (firefox for instance is faster running this way than native on the craptop).
* set running some gui app on the desktop on its second screen (for instance the second screen is a TV, so a movie) (X server 0, screen 1).
All with just:
ssh -Y user@mydesktop
someguiApp&
SSHDISPLAY=$DISPLAY
DISPLAY=:0.1
setsid someotherguiApp&
DISPLAY=$SSHDISPLAY
And yes, I do use my computer like that. And no, I don't feel there is some make believe IPC/network cost when I'm not.
And yes, I like the server/client design, it fits well here (but I do feel audio belongs with graphics, and I want a Plan9 style filesystem interface).
But there is a problem with XOrg, it contains real drivers that should be in the kernel.
However, I know XOrg is going through a revolution (though of course closed drivers like Nvidia lack way behind).
With Gallium3D and KMS the drivers can be removed from XOrg and put into the kernel where they belong.
Then there would be one XOrg "driver" and it would just be a Gallium3D+KMS one.
This means XOrg can be stripped right down. This will improve the code no end, and mean that XOrg can run as the user not root.
Also, it means better accelerated XNest etc etc. Which means you could perhaps have an extra X, just piped through, so if the "real" one crashes, the "fake" one can keep everything and hook into a new "real" one once it's running, and nothing is lost.
All that will Wayland, etc etc, X's future is very interesting.
Member since:2007-02-17
The real benefit of Gallium+kms to me is that once the drivers are moved out of X, we can finally get rid of X itself. Most of the leg work would have already been done and any display server should be able to piggy back off of the Gallium+KMS without having to rewrite all the drivers which is what has kept most competitors to X away.
Member since:2005-09-13
Member since:2009-02-19
Amen, amen. I work with a Linux cluster, and I do a similar dance a lot:
xhost $SOME_MACHINE
ssh $SOME_MACHINE
export DISPLAY=$MY_MACHINE:0.0
gvim $SOME_FILE
Windows/Mac users, don't let the fact that they're weird commands dropped into a console scare you, it ends up working out quite well. Home Desktop users may not use the networked X architecture much, but there definitely are real-world usage-cases out there for it.
You're also definitely right that using IPC is not why X sucks. There are basically three reasons: horrible/third-party-hacked drivers; lack of adequate failure recovery and isolation; and poor auto-detection. And you're also right that X is evolving right now, as we speak, and points 1 and 3 are being actively and incrementally dealt-with.
Member since:2005-07-06
You screw up another term: you criticize X design by saying that X11 sources are awful..
Do you understand that the design of an API is something totally different from the sources of a particular implementation???
I'm not sure exactly why you don't like X, me I like its network transparent design, XFree isn't that good on many points but that's a manpower issue, this has nothing to do with the design..
Member since:2007-02-17
What use is a network transparent design that doesn't get used? Even on Linux today most people use VNC, RDP, Citrix to access remote resources because they don't really require any special command line options to get them to work. There are real issues with X, performance is one of the top complaints against it. The real problem with X is that it wasn;t designed with real desktop use in mind, instead its getting retrofitted for that purpose and it shows. IMO, it probably would have been easier to start something new and there have been plenty of opportunities for this to happen but we keep chinking away at the same old codebase in hopes of making it work properly. Why, because of compatibility which is something we constantly berate MS for doing with windows. X is no different. X itself is the least forward thinking part of Linux.
Like I said before, once the drivers are removed from X and put in the kernel where they belong then it would be much easier to replace X altogether if that is what the community chooses to do (and I hope they do). There are alternatives in the sideline waiting to take its place. Wayland is a great candidate, imo.
Member since:2006-01-02
I tested UNIX domain socket latency on my machine and I get an average around 250 microseconds to send a 1 KB message between two processes. Granted, there's no overhead for an abstraction layer like libxtrans, but shuffling around bits entirely in userspace is probably pretty fast compared to sending data through the kernel.
Network latency is not the problem. I don't know why people keep harping on it.
As for the rest of your incomprehensible rant, the best I can say is that you are uninformed, or you are overgeneralizing. The drivers do not have to follow any specific architecture (except in the interface between the driver and X) because that is dependent on the hardware and the people who developed the driver. So you will find a range of quality. Then again, based on the crappiness of many Windows drivers, I'm not convinced that they are really that much better.
The rest of the X code base is actually pretty decent. The X server is decently well-designed, albeit not perfect (no software is, except for what they use at NASA). It has proper layering from the abstract portions in the DIX down to the generalized framebuffer and machine-independent code, down further to the OS and HW specific parts. Extensions live in their own directories for the most part and don't interfere more than need be with the core stuff.
Convenient bad-driver: I'm sorry you don't like this response, but fact of the matter is, it generally is the problem. Hardware is flaky and really hard to deal with, especially when you have no docs or limited docs. In my experience, and in watching the mailing lists and to a lesser degree, bugzilla, most bugs and problems are related to the drivers. You just need to accept that and move on.
I don't know what lagged I/O you are talking about. X drawing is pretty fast in many cases, where it is properly hardware accelerated. I don't notice any input lag. If applications are laggy, blame that on the app/toolkit, or, again, bad drivers that don't accelerated commonly used operations (RENDER is a repeat offender here). On my machine, most 2d ops are properly accelerated, so I get great 2d performance, even with a compositing manager running. It's almost on par with XP, and that's saying something given the crappitude of GTK+ (Qt3 feels, however, about as good as GDI, if not better). I have noticed that some distros, Ubuntu especially, are particularly poor performers on my machine. I will continue to use Gentoo as long as that's the case.
Member since:2009-10-04
The fact that apps go down when X goes down is entirely the app's and the distro's faults. Apps are perfectly capable of waiting for X to restart and reconnecting to the new X server, and distros are perfectly capable of not returning users to GDM/KDM when the X server crashes.
Yes there are problems with X, but this is not one of them. With a few simple patches to Gtk+ and Qt, and a few changes to upstart in Ubuntu, and this problem would be nearly solved for most users.
Member since:2008-09-11
Member since:
2008-02-26
The X protocol is used over IPC instead of a network, which is why it doesn't matter that they removed the network. That is what I wanted to say, and you know it, but ad-hominem attacks work better.
Of course I know that from third parties that write about X design. No(sane)body can possibly bear looking at X11 source for long periods of time. I did it once to debug a driver that was bothering me and won't do that again. Surely not to win an argument with you.
Anyways that I screwed up a term doesn't help with my apps going down when it dies because of the convenient bad-driver(TM) or getting lagged i/o or other marvelous side-effects of using X as opposed to some superior system like Windows 3.0 GDI.
Linux could do fine with even that and would do if it weren't that X gets all the drivers and support.