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
I'll be quick;
The other X implementation aren't as good as XOrg for the desktop. That is why everyone uses XOrg. Outside the desktop is different though. But it is important to distinguish between X the standard and XOrg the implementation.
The open source point is not bullshit. How can you possibly expect XOrg to be able to do anything if they don't have the source to do so!
Linus has made plenty of good arguments why a stable driver API + closed drivers isn't as good as an unfixed API with all open drivers in the kernel trunk. Or you can think all the kernel guys don't know what they are doing......
You can use Xrandr to setup a single desktop over two monitors. Just not on all the closed drivers, which goes back to my first point.
Locally XOrg IPC done with shared memory and sockets. The server/client model isn't a issue, and the power it adds I use almost daily.
The X API isn't meant to be a widget lib. X is designed to be the basic required. Not a easy widget kit. That's why you have widget libs on it. On top of that I'm betting your looking at XLib not XCB, which is meant to replace XLib.
KMS and Gallium3D replace existing abstractions, they don't go on top. Read on it, it's all pretty cool. It could be used to make a X replacement, like Wayland, but any X replacement will need X compatibility for the foreseeable future, again like Wayland.
The current X works well for me, as I said the network stuff I often use, and what's in the pipe looks even better.
Member since:2005-11-10
They don’t need the source! They need to provide a stable API/ABI that vendors can target with their cards.
For crying out loud, Windows 98 is closed source and vendors still targeted that fine—because the API was there and it was documented.
Because drivers have to be compiled into the kernel instead of providing a clean separation interface, the Linux kernel has done more to hold back the state of graphics on Linux than marketshare or lack of games has.
YOU HAVE WINE for Heaven’s sake—the community has already shown it can map APIs for compatibility. It wouldn’t be beyond the open source community to clone the Windows graphics API so drivers could be made for Linux with nothing but a re-compile of Windows code—if only the fecking Kernel and X and all that shite would stoop to making things easy for developers instead of being such hurdles to progress.
Member since:
2005-07-12
>> I think you are mixing up X11 and XOrg.
>> There are many implementation of X11, XOrg
>> is just the one used by Ubuntu and most Linux
>> desktops.
... and they all suffer from these problems, many of them WORSE than x.org.
>> And your problem is the XOrg driver for your
>> card, and I'm guessing it's not XOrg's own driver
>> your using but the closed driver from the graphics
>> card manufacturer, and that will be because I'm
>> guessing XOrg's driver for your card can't use all
>> the features (like 3D) of the card because the
>> people writing XOrg's own driver for the card don't
>> have the specs.
Don't give me that open source BULLSHIT... or more specifically where you point the finger on that is complete **** manure. Why do I say that? Because Windows has had FLAWLESS multiple display support since Win98, Apple has had it since System 5, and ALL you have to do is plug in the cards, install the drivers, and check off a box under display properties... and assuming your monitor is connected via DVI the mode detection has worked pretty well back to win98 and is flawless under V/7 (one of the few things that WORKS in Vista) and I've been running multi-display since Win 3.1 using a Targa board... NONE of which involves ANY open source driver malarkey. What it involved is a stable damned driver API - But don't ask that of the *nix community.
The dirty ***** hippy attitude of open source or nothing has prevented there being a consistent binary base for closed drivers - and hardware makers LIKE closed drivers... and so do I since to be brutally honest I'll stack nVidia's closed drivers on a crappy decade old Ge2 against the best open source driver efforts on a 'modern' Intel. What would you rather run linsux on? Ge2MX with closed drivers or GMA950 with open ones? Unless you've dipped into the FSF cool aid....
>> xinerama is old hat, Xrandr is what you want,
>> only closed drivers aren't keeping up.
Being the two do entirely different things, one setting display resolution and the other allowing the use of multiple monitors - I want BOTH. I want them talking to each-other, and be in nVidia, Intel or ATI guess what, they don't do so worth a flying ****.
>> "real" drivers have no place in any X server
That X is effectively monolithic when it comes to the video drivers I agree on that one part, but...
>> and through efforts suchs as KMS and Gallium3D
>> the drivers are indeed being moved out of X and in
>> to the kernel, then their need only be a single X
>> driver which talks to these abstractions.
Because adding yet another layer or two of abstraction to the process is the answer... NOT. Let's face it, the X11 server/client layers were not even developed to run off the same machine and as such ends up like driving with the parking brake on - which is why damned near every low end extension that's been done to X11 tries to bypass that relationship altogether - xRandR, Composite, dbe, bitmap, dri, glx - all exist to bypass how X11 is supposed to work because the server/client relationship is too slow to be practical for anything except remote server.
Much less the programming API that sucks so bad everyone and their brother has another layer of abstraction to sit atop it to make it usable - Old school you'd be hard pressed to find a single book that actually tells you how to program X11 directly - they all will tell you to just use Motif. Today we have GTK, QT, lessTif, FLTK, Fox, TCL/TK - all exist entirely because the X11 API is such a half assed convoluted mess nobody actually wants to program for it directly.
Adding yet another layer of abstraction adding yet another layer of bloat... So yeah, let's add another layer of abstraction to that, that's a GREAT idea.
... and we wonder why even when it works anything running X Windows feels like a disjointed buggy mess. Hell it's so bad most Desktop managers can't even get user notification that a program is in the process of launching right. Like when I start most any application if I have more than four of them running and the cursor sits there as the normal arrow for about fifteen seconds before it shows any indication of activity on screen on a Q6600 w/GTX 260 - naturally I click again and eventually have five copies open en-masse...
Even with the big fancy desktop managers most every X11 implementation still has all the fit and finish of a 1984 Yugo GV. If you are lucky it will get you where you are going - but you aren't going to be happy when you get there.
Edited 2009-10-02 16:46 UTC