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."
I guess Linux will continue to have a shitty ui and amateurish graphics.
If they don't matter, why mir?
NOTHING to do with Canonical at all. Yay for the let's all hate Canonical bandwagon.
Ubuntu is for losers, why does anyone care what Canonical has to say?
I need to know who to blame when they screw it up again because the open-source management by committee model ensures they end up bloated mockeries of their original design goals.
I think the biggest advantage of open source is we get the entertainment of seeing the pissing contests.
Gotta love it when Linus cusses out someone on the LKML who crossed him*.
* - OT, but I love Linus when he does that. I hope it makes some poor butthurt pussy bleed. This world is way too full of overly sensitive pussies and I'm so glad Linus is doing his best to make sure they remove themselves from the gene pool.
Now go fuck yourself, your family dog, and the gopher hole out back. ;-)
Obviously they are supervillains! Open source means no need to burn the witch to prove it's a witch!
I do like Ubuntu though. No witch burnings today.
Interesting how KDE and those responsible for Unity have differing perspectives... who would have thought?
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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.'"
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
.. And it IS indeed shitty and amateurish. Why do you think most distros choose something slightly less shitty by default?
The NIH-ness and "let's completely rewrite something for fun" mentality spawned this display server debacle, plus the wonderful systemd/upstart mess. How about we follow the unix's KISS principle, and the traditional modularity and openness it gave us.
- cynical FreeBSD user
Qt is a widget toolbox used for designing UIs. What does this have to do with a display server? As far as I know, display servers are X and Wayland.
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?
Namely gui toolkit developers, driver developers and DE developers. All of the above aren't very fond of MIR..
If you don't want people to make fun of your crappy desktop, don't make it so crappy. Fanboys with modpoints are always sad, but KDE fanboys are extra sad.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Fact is that I can remotely control almost any computer running on almost any platform utilizing countless different variations of the theme of 'render to the display - wait, let's render to an image instead then send it over the wire'
The reason so much attention is being put on display servers is as a distraction from the real problems, such as the fact that so much attention is being put on the display servers. They're not the weak point, there are a lot of them, and one exercise that remains THROUGHOUT COMPUTING HISTORY, is the task of updating software and porting it to another display server, because at the end of the day you're drawing colored rectangles on a screen.
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?
Whether display server matters or not, this debate doesn't matter. You need to support them both, or else you're doing a poor job.
Is there an actual story here, or it just about two different groups of open-source developers having a difference of opinion on whether display servers are important or not? The summary doesn't suggest this disagreement is having any real ramifications on Ubuntu/Kubuntu.
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.
Back when Canonical announced they were working on Mir, my first reaction was like "are you guys serious?". Writing your own display server is not a trivial thing. I mean, it's not as simple as providing an API with a few classes and methods. It goes much further than that. You have to interface with kernel, display drivers, input devices, provide drawing context for 2D/3D graphics, manage things like video playback, provide framework for IPC between X applications, etc. And all this, is not achieved simply by writing a few lines of C code. It requires deep understanding of what is needed and properly designing architecture, protocols, APIs, etc. So basically, you need a dedicated team of people who really know what they're doing and have plenty of time and resources. I'm not convinced that Canonical has such a team or a big stash of money to pay them.
I see you've driven a Toyota.
Push the shift lever FORWARD to go BACK, and BACKWARDS to go FORWARD! It's intuitive! Just stand on your head (and that way you'll be able to see all the controls, too).
And let's just not even talk about the "flying bridge" in the 2012+ Priapus... or any recent model of "infotainment" system from any car vendor....
Ubuntu and Canonical say a lot but you have to wonder if they forgot their roots. KDE is a rich and robust desktop eco-system. It has everything from windowing, widgets, plasmons, wallpapers and artwork to grandly complex integrated applications. KDE to this developer is nothing short of Cool on steroids.
On the other hand, the desktop of a stock Ubuntu is crippling, lacking, stripped of options and toyish. Unity? Its nothing more than a program loader.
I've been a KDE user for a very long time, hated Gnome. Frankly I hate Unity even more Gnome (which is a lot). I've seen KDE do things that Microsoft can't, using less CPU and overall better performance, and it's always been compatible with X. So now we have a nextgen X and Canonical want's to disperse the market. Nothing new there, they did it with Unity. Fragmentation is good for some people, and I have to wonder if Canonical gets paid to cause fragmentation? Sure, they have a product that is "theirs" too, but who really likes "theirs" and why is theirs better for consumers?
Look, if you happen to love Gnome you should have the same issues with this fragmentation as me being pro-KDE does. Years of getting Gnome X.X working properly and enough traction from users, and then a company creates a rift. Ubuntu makes some things easier for people not experienced with Linux, but they don't do UIs as Unity clearly demonstrates.
If they are unhappy with Gnome or KDE why not put devs on the project instead of back door'ing their own?
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
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"
i'm not familiar with Linux but i guess the displays are connected to the internet? I tried reading the article but I got confused.
SailfishOS, running on the current Jolla device, is quite smooth and nice, in a way that my N9 (despite the slickness of the design of the UI) never was. Both were underpowered hardware for their times, but Wayland allows the kinds of GPU-accelerated and compositing-oriented display that allow for what people are increasingly used to from other OSes.
Now, in terms of systemd I'm more on your side, there's certainly a baseline of arrogance that the primary devs have shown. On the other hand, they seem sometimes to be justified, and while there was some shouting and mudflinging in the recent Debian decision, there were also some extremely thoughtful and thorough considerations that I read from Debian developers which convinced me that, despite some of its shortcomings, systemd is a needed improvement and is well thought out. Err, I can't seem to find any of them right now, but from a system administration perspective I do see this blog as a fairly succinct list of reasons why systemd is good for sysadmins. As one myself, who until now has worked merely on SysV or Upstart systems, many of those reasons do seem pretty compelling to me. So far I've only toyed with systemd in the phone that now resides in my pocket, however, so I certainly can't speak from direct experience yet. But I'm very interested to try it out.
I remember sigs. Oh, a simpler time!
For including a link to Muktware, the only linux site sleazier and more willing than publish sensationalistic crap than Phoronix.
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.
What color would you like the bikeshed?
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
and it's been a long time since I've walked by a construction site and heard [a hammer]
You should have walked past my place 4 weeks ago. Contractors were re-roofing my house and they used hammers. Made a good job too.
The Jolla phone has much better hardware than the N9. And X11 on N9 is GPU-accelerated as well. Why do you think Wayland has anything to do with it?
"Refuted" doesn't mean that someone disagrees. "Refuted" means that someone has conclusively proved that something is incorrect.
And the Kompany should give a fuck about Canonical or anything Canonical does?
Canonical at best treats KDE as a second class citizen.
Equal parts incompetent and arrogant. They're like a fledgeling Microsoft, except now everybody else is moving on from yesteryear and won't waste time indulging such foolishness anymore.
Wayland allows the kinds of GPU-accelerated and compositing-oriented display that allow for what people are increasingly used to from other OSes
No, it doesn't. That's nothing to do with Wayland at all. Wayland is just a compositor that allows you to manage pixel buffers (and when they are ready) and input devices.
Any hardware GPU accelerated stuff is supported by OpenGL or other parts of the stack, just like on Xorg.
SJW n. One who posts facts.
Why aren't you linking to the blogpost, instead of the article quoting the blogpost?
The display server really matters; everybody uses one.
The stuff on top of the display server (KDE, Gnome, ...) matters less, that is the interchangeable stuff. Some likes a "desktop environment" and uses KDE. Nice for beginners and all that. Some are different and go for gnome. Some goes for speed and ditch all that - relying on a simple window manager and no "desktop" at at all. Experts launch their apps from the xterm's they have up all the time anyway. Typing is so much faster than mousing around when you know the commands well.
But they all use a display server. Real terminals are a bit restricted...
The first platforms I used with X Windows were a Sun-3 and a 386/25, usually with about 4MB of RAM (some of our Sun boxes had 8MB, and if you wanted to use NeWS instead of X you definitely needed 8. It's possible that the 386 had less RAM than that.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Aaron also raised the problem which the larger Free Software community is trying to fix – reduce duplication of work.
Part of why Linux (IMO) succeeded was the duplication.
Because if you carefully evaluate the duplication, lots of it is not really duplication - but it is the choices, we are free to make.
Take away the "duplication" and you end up with something close-minded as Java, Windows or Mac OS.
The only "negative" of the duplication I have seen so far is the hurt ego of the competing developers.
The Linux desktop is more consistent and coherent today than it ever has been as a result, from icon themes to clipboards to compatibility between window managers to IPC to application notifications to application launching to multimedia to ...
The consistency was achieved not because we have single implementation - but because everybody has agreed what should be inside the implementation! Without previous duplication, without seeing the flipside of different design choices, reaching agreement wouldn't have been possible!
I work for commercial ISV. Believe me when I'm saying you from a decade of practical experience that "no duplication" doesn't mean "consistency" or "ease of development". Very very often decisions are rushed for marketing reasons and developers are stuck for years with a "committee design" nobody can change because nobody knows alternatives because we do not allow duplication.
All hope abandon ye who enter here.