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."

Comments

wayland, systemd

[bzipitidoo]

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.