Slashdot Mirror
KDE and Canonical Developers Disagree Over Display Server
sfcrazy (1542989) writes "Robert Ancell, a Canonical software engineer, wrote a blog titled 'Why the display server doesn't matter', arguing that: 'Display servers are the component in the display stack that seems to hog a lot of the limelight. I think this is a bit of a mistake, as it’s actually probably the least important component, at least to a user.' KDE developers, who do have long experience with Qt (something Canonical is moving towards for its mobile ambitions), have refuted Bob's claims and said that display server does matter."
If they don't matter, why mir?
NOTHING to do with Canonical at all. Yay for the let's all hate Canonical bandwagon.
The display server is hugely important. The fact that the user doesn't know they're using it is irrelevant, because they're using it at all times.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Hey! No need to bring systemd into this...
You heard the man, it's not important. Now stop talking about it! That way Canonical can more easily save face when they cancel their failed cluster-fuck of a display server and switch back to Wayland...
Rules of Conduct:
#1 - The DM is always right.
#2 - If the DM is wrong, see rule #1
Just one question. If the display server is of such minimal importance in the big scheme of things, then why did Canonical develop their own?
The most significant transition of a unix-style OS to the desktop is OSX. The most significant transition of a unix-style OS to handhelds is Android. X was left behind both times. Why did they re-invent the wheel if there was no need to do so?
The canonical developer said that users don't care which I think is pretty accurate. The majority of users won't care as long as applications run and are responsive.
Because the tool boxes (QT, GTK, and others) don't provide a complete abstraction layer, at least not when your project gets to the point of doing anything 'fancy' if all your application does is display some forms fine, but more complex stuff, window managers, media players with odd shapes and over lays etc; you have to interact with the display server directly or its APIs anyway.
More display servers more code paths and its not easy for one developer to test all that, sure they can have a bunch of VMs but now he has to know how work with multiple systems etc. It would be PITA. Its going to be bad enough for some with just X and Wayland to support.
My guess is many won't end up supporting multiple display servers and if there are to many it will just fragment the Linux desktop worse than even in the bad old days.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Too easy to downmod you.
From your comment about a shitty UI one can only conclude you have never used KDE.
Although better graphics would be nice calling them amateurish is rather silly.
I actually see KDE as the best Linux desktop right now: fast, feature-rich and stable. However I recently watched an interesting criticism piece regarding some funky and misleading behavior of this desktop environment. The user experience could be improved.
Because Metro sure knocked the socks off of everything...
It points to a new direction; you know one where UI designers cut the tops off their skulls, take an ice cream scooper and remove about two thirds of the brains, put the top of the skull back on.
Metro UI concepts are actually showing up in more and more places. The biggest problem with it was that Microsoft, in their wisdom, tried to force a touchscreen interface on desktop users. The interface itself isn't the problem, the lack of choice for the primary user was...
Although better graphics would be nice calling them amateurish is rather silly.
Why? The KDE desktop looks like the state-of-the-art from say 1993. If I wanted my desktop to look like Xaw3d, I'd just fall through a time warp and go back there. At least the music was better.
I'm pretty happy with my KDE desktop, but I use it as a tool to get work done, not because it looks pretty.
I bought a hammer from the hardware store that looks almost exactly like the 1920's era hammer my great grandfather used (though the handle is fiberglass instead of wood), but it works well and gets the job done. Just because a desktop "looks" old doesn't make it useless. I tried Unity and Windows Metro and found them to be much less usable for my developer/operations tasks.
KDE 4 is great except for Akonadi, which killed Kmail.
When all you have is a hammer, every problem starts to look like a thumb.
Figured systemd would get dragged into this.
One of the biggest problems with systemd is simply documentation. System administrators have a lot of learning invested in SysV and BSD, and systemd changes nearly everything. Changing everything may be okay, may be good, but to do it without explanation is bad no matter how good the changes. I'd like to see some succinct explanation, with data and analysis to back it up. Likely there is such an explanation, and I just don't know about it. But the official systemd site doesn't seem to have much, I'd also like to see a list with common system admin commands on one side, and systemd equivalents on the other, like this one but with more. For example, to look at the system log, "less /var/log/syslog" might be one way, and in systemd, it is "journalctl". To restart networking it might be "/etc/rc.d/net restart", and in systemd it's "systemctl restart network.service". Or maybe the adapter is wrongly configured, DHCP didn't work or received the wrong info, in which case it may be something like "ifconfig eth0 down" followed by an "up" with corrected IP addresses and gateway info.
When information is not available, it looks suspicious. How can we judge if systemd is ready for production? Is well designed? And that the designers aren't trying to hide problems, aren't letting their egos blind them to problems? To be brusquely told that we shouldn't judge it we should just accept it and indeed ought to stop whining and complaining and be grateful someone is generously spending their free time on this problem, because we haven't invested the time to really learn it ourselves and don't know what we're talking about, doesn't sit well with me.
Same goes for Wayland and MIR. Improving X sounds like a fine idea. But these arguments the different camps are having-- get some solid data, and let's see some resolution. Otherwise, they're just guessing and flinging mud. Makes great copy, but I'd rather see the differences carefully examined and decisions made, not more shouting.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
Windows 7 sure has a better working and cleaner UI
Eh, maybe? If I turn off all the Aero or whatever and make it look like 9x, I can live with that. The translucent borders, Big Button start menu and "pins," the god-awful switcher...7 is probably my only choice for Windows moving forward, if I have to have it, but it won't look like it does after a fresh install for very long.
Compared to the Win32 API the GEOS one looks clean and nice. I mean the 8 bit GEOS BTW.
The whole point about all of this, X/Wayland/MIR, is getting closer to the video card without having to yank one's hair out whilst doing it. Why would one need a little close interaction with the bare metal? If you've ever used Linux and saw tearing while moving windows around, then you've hit on one of the points for why closer to metal is a bit more ideal.
With that said, let's not fool ourselves and think, "OMG, they just want access to the direct buffers!" That wouldn't be correct. However, developers want to have an ensured level of functionality with their applications visual appearance. If the app shows whited out menus for half a second, blink, and then there is your menu options, then there is something very wrong.
It was pretty clear that with X, politically speaking, that developers couldn't fix a lot of the problems due to legacy and the foaming at the mouth hordes that would call said developer out for ruining their precious X. You can already see those hordes from all the "take X and my network transparency from my cold dead hands" comments. It is to a degree those people, and a few other reasons, that provided the impetus for Wayland. You just cannot fix X the way it should be fixed.
Toolkits understand that display servers and pretty much the whole display stack in general suck. Granted there is a few moments of awesome, but they are largely out weighted by the suck factor, usually when you code an application, you'll note that sometimes you'll gravitate to the "winning" parts of the toolkit being used versus the pure suck ones. Qt has a multitude for all the OSes/Display Servers it supports. Be that Windows, Mac, X11, and so on. Likewise for GTK+ but to a lesser extent, but that is what make GTK+ a pretty cool toolkit. Because let's face it, no display stack is perfect in delivering every single developer's wish to the monitor. Likewise, no toolkit is perfect either. The GNOME and KDE people know this, they write specific code to get around some of the "weirdness" that comes with GTK+ or Qt. Obviously, that task is made slightly easier with Wayland and the way it allows a developer to send specifics to the display stack or even to the metal itself.
Projects like KDE and GNOME have to write window managers and a lot of times those window managers have to get around some of the most sucktacular parts of the underlying display server. However, once those parts are isolated, the bulk of the work left is done in the toolkit. So display servers matter a bit to the desktop environments because they need to find all of the pitfalls of using said display server and work around them. Sometimes, it can be as simple as a patch to the toolkit or the display server upstream. Sometimes it can be as painful as a kludge that looks like it was the dream of a madman, all depends on how much upstream a patch is needed to be effective and how effective it would be for other projects all around.
That leads into the problem with MIR. MIR seems pretty gravitated to its own means. If KDE has a problem with MIR that can be easily fixed with a patch to MIR or horribly fixed by a kludge in KDE's code base, it currently seems that the MIR team wouldn't be as happy go lucky to accept the patch if it meant that could potentially delay Ubuntu or break some future unknown to anyone else outside of MIR feature. Additionally, you have the duplicated work argument as well, which I think honestly holds a bit of water. I fondly remember the debates of aRts and Tomboy. While I think it's awesome that Ubuntu is developing their own display server, I pepper that thought with, "don't be surprised if everyone finds this whole endeavor a fools errand."
I think the NIH argument gets tossed around way too much, like its FOSS McCarthyism. Every team has their own goals and by their very nature, that would classify them as NIH heretics. Canonical's idea is this mobile/desktop nexus of funafication, MIR helps them drive that in a way that is better suited to them. That being said
My main issue with systemd is that it is monolithic; it violates the fundamental Unix philosophy in a most egregious way, and whenever anyone comments on this, we are (to quote the GP) "brusquely told that we shouldn't judge it we should just accept it and indeed ought to stop whining and complaining and be grateful someone is generously spending their free time on this problem, because we haven't invested the time to really learn it ourselves and don't know what we're talking about".
We used to have separate, replaceable systems for each aspect of systemd - e.g. if you didn't like syslog, there was syslog-ng, or metalog, or rsyslog; each different and meant for a different purpose. Now, it's "all or nothing" - except that it's becoming progressively more difficult to opt for "nothing" because it's integrating itself into fundamental bits like the kernel and udev.
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Good luck extracting a nail with your nail gun Mr. Professional.
Patent litigation: A doctrine of Mutually Assured Destruction... in which everyone seems willing to push the button
You: "You just cannot fix X the way it should be fixed."
Reality: "... It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X..." (Wayland FAQ)
And now?
Obviously, display server does matter to users. If users cannot use a whole set of applications because they are not compatable with Distro Xs display server, that is a problem for users. This can be addressed by distros standardizing around display servers that uses the same protocol. Its also possible, but more complex, is if distros using different display protocols support each others display protocols by running a copy of a rootless display server that supports the others display protocol. Relying on widget sets to support all display protocols is too unreliable as we are bound to end up with widget sets which do not support some display protocols. Needless to say, it is best to have a single standard, it would have been easiest and best if Canonical had gone with Wayland and actually worked with Wayland to address whatever needs they had.
Its also true a new display protocol wasnt really necessary. The issue with X was the lack of vertical syncronisation. X already has DRI, Xrender, Xcomposite, MIT SHM, and so on for other purposes. An X extension could have been created to allow a way for an application to get the timing of the display, the milliseconds between refreshes, the time of the next refresh, etc.. X applications could then use this timing information, starting its graphics operations just after the last refresh, X applications could then use an X command to place its finished graphics pixmap for a window into a "current completed buffer" for the window, allowing for double buffering to be used. This could be either a command to provide the memory address, or a shared memory location where the address would be placed. All of the current completed buffers for all windows are then composited in the server to generate the master video buffer for drawing to screen. There is a critical section during which the assembly of the master video buffer would occur, any current completed buffer swap by an application during that time by an application would have to be deferred for the next refresh cycle. A new XSetCompletedBuffer could be created which would provide a pointer to a pixmap, this is somewhat similar to XPutPixmap or setting the background of an X Window, but provided that XPutPixmap might do a memory copy it may not be appropriate, since the point is to provide a pointer to the pixmap that the X server would use in the next screen redraw. Said pixmaps would be used as drawables for opengl operations, traditional X primatives, and such. This scheme would work with all of the existing X drawing methods. the pixmaps are of course transferred using MIT SHM, its also possible to use GLX to do rendering server side, for use of x clients over the network, GLX is preferable, otherwise the entire pixmap for the window would have to be sent over the network. The GLX implementation already allows GL graphics to be rendered into a shared memory pixmap. Currently however, some drivers do not support GL rendering into a pixmap, only a pbuffer, which is not available in client memory at all, however, the DRI/GEM stuff is supposed to fix this and the X server should be updated to support GLX drawing to a pixmap with all such DRI drivers.
Another issue is window position and visibility in how it relates to vertical synchronization. Simplistically the refresh cycle can be broken into an application render period and a master render period. If the X server has a whole pixmap buffer of a window, it grabs at a snapshot of the display window visibility/position state the beginning of the master rendering period and uses that to generate the final master pixmap by copying visible regions of windows into the master buffer.
It can be a good idea to allow the option for applications to only render areas of their windows that are visible, this saves on CPU resources and also avoid needless rasterization of offscreen vector data. In order to do this, applications would need to access visibility data at the beginning of the application render period. Applications would then have to, instead of providing a single
Sure a DE is an acquired taste but it does have to be functional without being ugly.
Nor is there outside the commercial offerings any DE with such a well integrated package of applications.
That doesn't mean I don't see the attractivity of something like Enlightenment but compared to KDE it is seriously limited, both in options and looks.
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
Or maybe he's somebody who:
* cares about real-estate on his screen and the density of information displayed vs shininess. Those borders and "modern" task bar are huge!
* is interested in having a UI that responds in a timely manner rather than having pretty but utterly useless animations that make him wait half a second every time he clicks on something.
* wants to use less memory for caching pretty animations and more for the programs he's running
* wants his processor to be working on the task he has assigned it rather than showing him shiny animations
* feels like it's more important to make something stable than pretty
* feels like it's more important to make something efficient than pretty
* feels like it's more important to make something compatible than pretty
This is all horseshit anyway. Any decent windowing system would be implemented with ncurses.
I had not used KDE in some time and worked with it recently. I was amazingly disappointed. Here are some of the things I found: http://www.youtube.com/watch?v... I was stunned at how bad it was and have been actively adding bug reports to let the developers know. There are literally dozens that I show though. It is pretty inexcusable.