Lead Mir Developer: 'Mir More Relevant Than Wayland In Two Years' 226
M-Saunders writes Canonical courted plenty of controversy with it announced Mir, its home-grown display server. But why did the company choose to go it alone, and not collaborate with the Wayland project? Linux Voice has an interview with Thomas Voss, Mir's lead developer. Voss explains how Mir came into being, what it offers, and why he believes it will outlast Wayland.
Not Invented Here (Score:5, Insightful)
I think the main issue Canonical has with Wayland and X is that they are Not Invented Here [wikipedia.org]. Canonical has their own priorities and regardless of the technical merits vs. Wayland and others Canonical wants to be in control of the display server so they can lead it to their interests and not have to convince other parties to go their way.
Re:Not Invented Here (Score:5, Funny)
Quite (Score:5, Interesting)
Wish I had mod points. Canonical arn't really interested in Linux or unix in general other than how it can ultimately make them money. Its a means to an end and if that means dropping 30 years of experience because it doesn't quite suit them then they will.
X is far from perfect but its the unix display standard and it isn't going anywhere anytime soon. If canonical want to go their own way then they'll find their user base dropping away even further.
Re: (Score:3)
Wish I had mod points!
Canonical --said it once and'll say it again-- is a PR Company. And, as with PR, it's braindead, and memory-deficient.
Remember those "100 Paper Cuts", introduced by Mr. You Know Whom?
Re: (Score:2, Flamebait)
Can you point to something specific that the old way is better?
As with systemd it seems that some people are ready to adopt the new and toss the old in the trash. NIH served Canonical well there, as their customers are both direct users (who according to the Ubuntu philosophy have no need to know what systemd is or what it does) and people who maintain Debian based or similar distros.
If Canonical makes something better, and people who do not have financial incentive to adopt it do so, what does it say abou
Re: (Score:3)
But Wayland or an implementation has always seemed to be two years away. It's just so slow moving - drivers, distros, toolkits, DEs need to be there. I'm figuring out we can finally use it in 2016 (Ubuntu 16.04 LTS variants and derivates), 2017 for debian-stable-after-jessie.
I'm figuring Ubuntu wanted their Mir so they could control the development, QA, testing, whatever of it for the Ubuntu phones, which eventually failed to be introduced or were delayed.
Re: (Score:2)
Re: (Score:3)
I agree that development on Wayland is at a glacial pace. I think Mir is serving a purpose: it actually got the Wayland developers to speed up considerably. But then they slowed down over the last year, so bringing up Mir again may be a good idea.
Re: (Score:3)
its more like wayland is Designed by committee which gives you a never ending cluster of everyone's best wishes, which is why after hearing about it since 2008 the most promising thing it can say about itself in the first sentence of their own website is
GNOME and KDE are expected to be ported to it.
Its DOA
Site broken (Score:5, Funny)
It appears to be Slashdotted. Someone's got to show them how to use IIS!
Re:Site broken (Score:4, Informative)
from the archive.org headers (X-archive-orig-server), I can tell its cloudflare-nginx they use. What wonders me, as cloudflare prevents slashdotting??
Why? (Score:4, Insightful)
What's wrong with Wayland that Mir fixes?
What else does Mir bring to the table that would make people use it over Wayland?
What is preventing Wayland from improving over the next 2 years?
If you want people to click on, read, and discuss articles, Slashdot, you should have articles worth clicking on, reading, and discussing.
I read TFA. Nothing in it answers the questions I have, not even the answer to the same fucking question that the interviewer had.
So that’s looking at Mir in relation to X. The obvious question is comparing Mir to Wayland – so what is it that Mir does, that Wayland doesn’t?
This might sound picky, but we have to distinguish what Wayland really is. Wayland is a protocol specification which is interesting because the value proposition is somewhat difficult. You’ve got a protocol and you’ve got a reference implementation. Specifically, when we started, Weston was still a test bed and everything being developed ended up in there.
No one was buying into that; no one was saying, “Look, we’re moving this to production-level quality with a bona fide protocol layer that is frozen and stable for a specific version that caters to application authors”. If you look at the Ubuntu repository today, or in Debian, there’s Wayland-cursor-whatever, so they have extensions already. So that’s a bit different from our approach to Mir, from my perspective at least.
There was this protocol that the Wayland developers finished and back then, before we did Mir and I looked into all of this, I wrote a Wayland compositor in Go, just to get to know things.
Re: (Score:2)
what he means to say is that mir wont have a protocol spec nor wont it have extensions?
oh and that he's a code hipster.
Re: (Score:2)
A lack of competition is what Wayland doesn't fix.
Re: (Score:2)
Stuff the Mir developers want but the Wayland developers think is not important or should be dealt with at the application level.
It's that simple - a different list of desired features.
Re: (Score:2)
My read of the article is that the problem with Wayland is that the devs were writing specs instead of software. There was lots of planning and no doing. Remember that originally Ubuntu was supposed to be running X-Mir by default in Oct 2013.
Those days were more optimistic times for Ubuntu and they thought they could create a new display server in a year. These days Mir and Wayland seem to be at about the same stage of readiness.
Re:Why? (Score:5, Insightful)
What's wrong with X?
Fixing old code that mostly works is boring. Must Have New Shiny!
Re: (Score:2)
Sigh.
By 'X' here, most people are referring to the X Windows code they run on their PC. That code mostly works, and is updated largely to fix bugs and support new hardware.
Most developers find fixing bugs and supporting new hardware boring, so they continually want to throw everything in favour of The New Shiny! which will inevitably be full of bugs and not support half the hardware it used to. Then they get back to fixing bugs and adding new hardware support, at which point they start dreaming of The New N
Wayland exists because X is bad at what it does (Score:2)
Have you seen the videos about why X is fundamentally broken? Did you read the fine article? There are a lot of horrible flaws in X that cannot be fixed short of a rewrite.
I get the impression that you haven't done any research into this issue, and are dismissing it based on a stereotype. Familiarity breeds contempt, and I am sure that to some degree the trend you identify exists. However, devs don't usually go that far out of their way to make work for themselves just on a whim, and I do expect them to act
I've seen a video but not one with proof (Score:3)
There's one that people link to a LOT of Daniel Stone giving an unfinished powerpoint presentation at linuxconf.au 2013 where he forgot his cable so you can't actually see his Wayland desktop. It's the one where he says X is slow and gives startup times of gedit on Gnome3 as proof! That's like saying MS Windows is slow because homemade VB crapware that needs to load a pile of stuff before it can get started is slow. He also has the joke about o
Re: (Score:2)
Look halfway down the page - point II (Score:2)
Sorry, that is clearly just a derivative product of the video from someone that watched it without enough background to understand it.
Surely there's something other than that video from close to two years ago or a newbies review of it?
Re: (Score:2)
Not unless you go as far as claiming that the people that wrote some X code that was borrowed by Wayland afterwards (there's a lot of it) are now suddenly Wayland developers.
Re:Why? (Score:5, Insightful)
The things X does well (e.g. network transparency) are really irrelevant nowadays (you can just send video instead of a render command stream, it will be better) while it's underlying design makes many things we want now (e.g. smooth UI, hotplug display devices without spending 3 hours maintaining Xorg config, composited rendering, works on limited hardware) unnecessarily difficult and complicated, which encourages the proliferation of X extensions (XRandR, AIGLX), hurts the performance of the display stack, and actually break the one thing X does well (network transparency was dropped sometime around when they added Direct Rendering Manager to try and fix the X performance issues).
Re: (Score:3, Informative)
The things X does well (e.g. network transparency) are really irrelevant nowadays (you can just send video instead of a render command stream, it will be better)
No, network transparency is much more than sending pixels. It is full integration: cut&paste, window management, client to client communication etc..
while it's underlying design makes many things we want now (e.g. smooth UI, hotplug display devices without spending 3 hours maintaining Xorg config, composited rendering, works on limited hardware) unnecessarily difficult and complicated,
I do not think this is true. The underlying design of Wayland is basically the same as X: Sending messages over a socket and some buffer sharing.
which encourages the proliferation of X extensions (XRandR, AIGLX), hurts the performance of the display stack,
Why does it hurt performance?
and actually break the one thing X does well (network transparency was dropped sometime around when they added Direct Rendering Manager to try and fix the X performance issues).
This is complete bullshit. X network transparency works perfectly fine still today. I use it every day. Yes, you cannot use direct rendering over the network. 99% of all applications do
Re: (Score:2)
Sigh... "X IS NETWORK TRANSPARENT!! I MAKE XTERM GO!! TRANSPARENT POWAR!!"
No.. granparent poster is right and you are wrong.
Being able to send stuff over a network pipe != network transparency. Get it through your head.]
Here's an excellent presentation by Daniel Stone, a guy who's forgotten more about X than most of us will ever know, saying the exact same thing: https://www.youtube.com/watch?... [youtube.com]
Re: (Score:2, Troll)
X is network transparent. I use it *every* day with different applications. If some clown comes along and says it is already broken (because his direct-rendered wobbly windows do not work over the network or something) then this is simpy FUD. And you are an idiot if you believe it.
Re: (Score:2)
Re: (Score:2, Troll)
Then half of the windows on my desktop cannot actually exist...
Re: (Score:2)
II) “X is Network Transparent.” Wrong. Its not. Core X and DRI-1 were network transparent. No one uses either one. Shared-Memory, DRI-2 and DRI-3000 are NOT network transparent, they do NOT work over the network. Modern day X comes down to synchronous, poorly done VNC. If it was poorly done, async, VNC then maybe we could make it work. But its not. Xlib is synchronous (and the movement to XCB is
Re: (Score:3)
Obviously, shared memory and direct access to the hardware are not network transparent. Guess how many applications require it?
You know, this discusson is rather surreal. I run remote applications right now and you guys keep telling me it is broken. It is like sitting in an airplane and your seat neighbor claims that flying is actually impossible.
Chinese whisper result above (Score:2)
If you think that's a good example keep looking (Score:3)
Including forgetting to bring his cables, forgetting to finish writing up his presentation, forgetting to remind people that his "three people who understand ..." was a joke, forgetting that gedit needs to start up a pile of gnome3 stuff so it's a poor measure of X speed and so on. You are not seeing him at his best. There must be a video or something out there of the finished presentation. You also need to understand the context is about displays for phones, which is on
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
IMHO, the point of X network transparency is a no-brainer in the same way as local OpenGL acceleration. Instead of wasting bandwidth on raw bitmaps, you just send the drawing commands, whether over the network or PCIe. (It's like MIDI vs. raw audio for the keyboardists out there.) I don't know all the programming details, but I've done 3D modelling over 2 MB/s cable this way, and I can't imagine it would have worked as smoothly using raw video.
You are talking about indirect 3D rendering, which is a fundamentally different topic. It is true that you can in theory send OpenGL command streams over a network, but in practice, this works only for certain applications, where the size of the commands is not too large, and no large assets (textures, meshes) etc. are transmitted. There's a reason why everybody wants *direct* rendering for 3D on the local machine. Forget about running games with indirect rendering, for example.
But when it comes to 2D appli
Re: (Score:2)
assuming it's not trying to do things with drm
Which is what 99,99% percent of all modern OpenGL applications will do.
Re: (Score:3)
Hey, if you like RDP better, why don't you just use it. There are clients for X. I am not the one who wants to break your user experience. All I am asking for is that you don' please break mine, because for me X works just fine.
Re: (Score:2)
To do network transparency you do want a vector based protocol like the X protocol and the GLX protocol, not the bit scraping and bitmap based ones, especially on a slow link. VNC has its uses but its not the be all and end all, there is need for a vector protocol.
Re: (Score:2)
The things X does well (e.g. network transparency) are really irrelevant nowadays (you can just send video instead of a render command stream, it will be better)
How am I to use a GUI application on a remote device witha video stream? How does that render menus, etc?
Re: (Score:2)
Network Transparency Use Cases I use often (Score:2)
Many of the remote management applications I used to do with X are being replaced by HTTP interfaces, optionally with AJAX, or sometimes REST APIs, but there are still a number that aren't.
Re: (Score:2)
X the network protocol is bearable, if you are trying to use a Motif style application remotely. But almost nobody is actually doing that any more. Most GUI frameworks were just using X to push graphics buffers.
The async design of the X protocol had a number of weak points. If both the client and the server changed something, this could lead to undefined behaviour. A number of fairly simple use cases resulted in the client needing to wait for multiple network round trips. RDP is a much saner protocol in co
Re: (Score:2)
Qt4 just pushes bitmaps (even Qt3 did, partially). So does Gtk 3. So do Chromium and Firefox, and IIRC also Thunderbird. Yes, that fits the term "most", unless you are running some old distro.
Re: (Score:2)
Again, I wrote:
Yes, that fits the term "most", unless you are running some old distro
Also, you completely disregard the MUCH bigger number of administrators and helpdesk personnel working with VNC, RDP, Citrix etc.
You said it yourself: the X remote functionality is okay for *old* stuff (RHEL5 is from when, 2007?), which still draws content by asking X draw this line, that text etc. It is much more efficient to let the application draw these things by itself these days, which is why every newer toolkit and application uses this client-side drawing model. And this is *exactly*
Let's please stay on topic (Score:2, Troll)
NONE of those things is X windows.
Re: (Score:2)
And none of them use the X way of remote desktop either. Yet, they are efficient, and in heavy use. You make it sound as if remote desktop is unfeasible without the X remote functionality, which simply isn't true. Stick VNC/RDP to Wayland, and you are done.
Re: (Score:2)
If you mean enlightenment evas, note that the lead developer would agree with me. Evas has been one of the earlierst adopters of client-side drawing. It is so efficient that it can even outperform GL-accelerated 2D drawing in certain cases. Evas has (or had) support for the Xrender extension as well, but quickly dropped that, because letting the application handle all of the drawing and small-bitmap blitting (by that I mean stuff like icons) is so much more efficient. If anything, Evas is a perfect example
Re: (Score:2)
Great. Name calling, with zero actual substance. I am reminded now why I don't frequent Slashdot much anymore. I suppose you can't be bothered to bring actual arguments against what I wrote in my earlier, post, right? No, spitting out curses is much easier of course. It should be completely obvious that I am *not* speaking for Raster, but instead am stating that he *would* agree with what I said since his design decisions for Evas are pretty much what I described. But hey, I don't expect an actual discussio
Re: (Score:2)
Re: (Score:2)
But remember that when Gnome went from Gnome2 to Gnome3, KDE4 became the superior choice. And the appear to be an equivalent of xfce appears to be X Window (and it's associated tools).
Analogies are always tricky, of course.
I still don't see what's wrong with X (Score:5, Interesting)
Re: (Score:3)
X was great for its time. But its time was when graphics hardware was slow and software was relatively undemanding. Times have changed, "we" want better software and have faster hardware, and now the bottleneck is X itself.
Re: (Score:2, Interesting)
X was great for its time. But its time was when graphics hardware was slow and software was relatively undemanding.
Ha-ha-ha... you clearly never used an X-Terminal back when we were all going to have dumb terminals on our desks talking to The Cloud... sorry... super-powerful 68020-based Unix servers The X overhead is miniscule today, unless you're trying to push X sessions over the Internet, or video over the LAN.
Re:I still don't see what's wrong with X (Score:5, Funny)
It's worse... these days we're making our dumb terminals using AJAX.
Supporting Mobile Devices on X or NeWS (Score:2)
We definitely have to dumb down protocols to run on mobile phones with 1024x768 screens and only 1 GHz CPUs and 1GB RAM, because they can't possibly run anywhere near as fast as they did on 1152x900 screens with 10 MHz CPUs and 4 MB RAM running X10, or 640x480 screens with 25-33 MHz 386 CPUs and (I forget how much, but not enough) RAM and X11 with Motif.
And yes, there were really good reasons for running NeWS instead of X, because some changes in which work you did on which end of the wire could make a hu
Re: (Score:2)
Re: (Score:2)
Theres an advantage to dropping graphical networking support (15 years after even windows has embraced it) and built in inter client communication? More like it made the coders job easier.
"Networked graphics? Hey , thats hard, lets not bother. No one uses remote X sessions in 2014, right? Right? Oh, they do... well who cares anyway. Our server is new and shiny, thats all anyone really wants"
Re: (Score:3)
It the GPU exports an MP4 video stream that can be delivered directly to any display (local or remote) that deals with the last connection bottleneck. It's a standard, its ubiquitous, and its implemented in hardware. The return channel for user interaction needs to be done, but that doesn't have the per
Re: (Score:2)
The layer in the system between the user applications and the hardware interface is the place where QT, GTK, Windows graphics api, and all the other graphics toolkits go. Those toolkits shouldn't care too much about the hardware details, just the published capabilities of the GPUs.
It's kinda hard not to care, because a lot of it depends on where you have the data, where the processing capability is and what the link capability is. Sending a video stream is heavy. Even sending an event stream like applications do all by themselves is too heavy during say a resize or scrolling action. Some time ago I experimented with turning Qt into a remote application toolkit, basically taking all signals and slots and serializing them over SSL. It was actually surprisingly successful, basically it
Re: (Score:2)
I think the reason you don't see such systems very often is that in the end it's simpler to just run a normal local application for the UI and have it connect back to a separate server app for the heavy lifting, rather than making it all one app which runs on the remote server and exports the UI through some generic mechanism. As a bonus, with the split UI/backend approach you can probably reuse the same APIs for an AJAX web app and a CLI interface suitable for automation.
If you put in the effort up front t
Re:I still don't see what's wrong with X (Score:5, Insightful)
Except that's pretty much what all AJAX web apps do, they "export the UI through some generic mechanism" to the browser so I'd say it's very common. No need for roll-outs and patches, if the server now says there should be a new button there is a new button for everyone. The issue is that I find most web apps really suck compared to native applications so locally I usually want a native, non-web application.
What I'm talking about is a native toolkit that'd make the applications you normally use locally network transparent at the application level, not the display server level. Essentially a toolkit where the UI is always living in its own thread, asynchronously to the actual application. Network transparency just means that thread happens to be living on a different machine, drawing to a different display. And you could tweak it to handle that better, but you wouldn't have to it'd sort of run remotely without modification.
For example, I made a basic calculator just as a proof of concept. Connected locally (I still used a TCP connection just to localhost, better options are available) it looked and acted entirely as a native app you could use every day. It recorded buttons pushed, sent the push events to the back-end and sent updated display text back. I hadn't made it better, but I hadn't made it worse either. The cool thing though was that now I could connect to it remotely. Same calculator popped up, my button clicks go over the network, display text came back over the network. It's a working local native app and a working network transparent remote app. At once. Without any application logic in the client, just drawing tools.
Re: (Score:3)
And no one uses "command stream" style network rendering, nor is it actually faster, in 2014.
The only advantage X has over networked graphics is that you can forward the socket and have the app pop up in it's own window on your machine....but you can't detach and re-attach to it, or move it locally or remotely to another machine, and the actual rendering is effectively a very unnecessarily chatty bitmap stream anyway (hence why things like x2go are such huge improvements).
Remote apps and desktop on Linux *s
Re: (Score:2)
2) Uecker claims X is fine because he installed X
Re:I still don't see what's wrong with X (Score:5, Interesting)
Seriously, what's so broken about X? Is it just a pain in the ass for developers to work with?
I taught myself X from scratch last year. I didn't find it hard at all. In fact, I found it a whole lot easier than either of the fancy modern GUI toolkits that I looked at first and tried to use to implement the project I was working on.
Out of desperation born of lack of progress over an extended period, I thought I'd take a look at X. And suddenly it became easy to get the interface to behave *exactly* the way I wanted instead in somebody else's idea of what I should want.
And the documentation was complete, correct, and easy to follow. I didn't have to keep asking people for help (often, with no resolution). In a word, both the documentation and the code for X are mature. Which I submit beats bleeding edge every time if you're trying to build something robust.
Re: (Score:2)
both the documentation and the code for X are mature. Which I submit beats bleeding edge every time if you're trying to build something robust.
So true.
Re: (Score:2)
Seriously, what's so broken about X? Is it just a pain in the ass for developers to work with?
I thought I'd take a look at X. And suddenly it became easy to get the interface to behave *exactly* the way I wanted instead in somebody else's idea of what I should want.
And the documentation was complete, correct, and easy to follow.
Here's a transcript of a video call I recently had with a Lead Mir Developer(*): Ahhh! Geez, over here -- it's another luzer. Look, using this is just so obvious it's painful. We write wonderful, self-documenting code and haven't had a bug in months! And it's completely compatible with X -- here, let me show you.
See? It starts up and looks and responds completely like X, but it's got our better code and much better responsiveness. All you have to do it is read the simple documentation that Joe i
Re:I still don't see what's wrong with X (Score:4, Insightful)
Seriously, what's so broken about X? Is it just a pain in the ass for developers to work with?
If X, or more specifically the X.org implementation, had been written by Leonard Poettering every article would be followed by a gazillion comments whining about how it is a monolithic single point of failure (which had to run as root until very recently on many systems), it has terminal NIH syndrome (everything from ELF library loading to low-level graphics drivers to stippled line rendering), it "violates the UNIX philosophy" by doing multiple things (it's a remote display protocol, it's a input event multiplexer, it's a bitmap typeface renderer), it is not easily extensible (extending the core protocol is often not portable so GNOME and KDE etc overload scores of "window properties" to serve as a quasi-protocol), it's full of useless crud (for example, with modern toolkits the much-vaunted 'network transparency' usually boils down to sending pre-rendered bitmaps, as the aforementioned stippled line support is not considered sufficient) etc.
Of course, X11 was a gift stolen by Prometheus from the Unix gods. All right-thinking people know that it is obviously sacrosanct and even the suggestion that someone might someday be able to do better is a vile heresy. If you need to do something it doesn't support, why not glue another carbuncle of an extension onto the creaking superstructure and perform the required ritual goat sacrifice? Thus it ever was, thus it ever shall be.
Re: (Score:2)
Re: (Score:3)
you should care when the X *developers* decide that in the long run it is unmaintainable and the number of people who actually understand how everything works are less than four.
Developers always say the code is unmaintainable and they must start from scratch.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Informative)
Seriously, what's so broken about X? Is it just a pain in the ass for developers to work with?
You might seek out some of the tech talks given by Wayland developers. They lay it out pretty clearly.
Here's a good one: https://www.youtube.com/watch?v=RIctzAQOe44 [youtube.com]
From memory, X11 is full of cruft that no longer makes sense. Everyone wants beautifully rendered, anti-aliased fonts, but X11 not only doesn't give you that, if you comply with X11 you can't do that.
Wayland took a look at how X11 is actually used, tod
Re:I still don't see what's wrong with X (Score:4)
"Wayland is exactly as network-transparent as X11 is in actual use these days: not very but you can make it work. Everyone is pretty much asking X11 for a drawing canvas, drawing on it, then giving it to a compositor to display. See above comments about beautifully anti-aliased fonts."
From the perspective of a low-level programmer working on Xorg and/or Wayland this is probably true. They certainly say it enough. As a user I'm not even entirely sure what a compositor is. However, I can create an X terminal in a few minutes by just doing a bare-bones Debian install with X but no desktop manager. Then a quick rc script edit makes it automatically start X and connect to my XDMCP server. From that point on all I have to do is hit the power button and I have the illusion of being at my main desktop PC. I don't really care how X is or isn't making this happening so long as it works!
Knowing nothing about compositors, 3d or 2d APIs or the source code of Weston how the hell will I do this when Wayland has replaced X? Do I have to learn write my own compositor? I already do aplicaiton programming for a living but when these Wayland guys talk I have no idea what the hell they are going on about. What will I have to learn to make Wayland work remotely? Where would I even begin?
Or.. until the applications I want to run no longer support it I can just keep using X. But what then?
Re: (Score:2)
Wayland includes a remote protocol. For an application programmer you'll use a graphical widget set and that will display remotely fine.
Re: (Score:2)
Re: (Score:2)
The compositor is the program that stitches the framebuffers for each element on the screen together into the final image. It is usually a part of, or closely related to, the window manager.
Modern drawing APIs typically work by allowing the application to ask the windowing system for a buffer (may be hardware accelerated) to which the application will perform all of its draw calls. The compositor then gathers all of the frame buffers and uses attributes to draw the final image into its own frame buffer that
Re: (Score:2)
Wayland is exactly as network-transparent as X11 is in actual use these days:
Love that quailfier: "in actual use these days". One of the Wayland devs evidently looked around his office and didn't see any remote clients running. So toss that requirement out.
I don't care if Wayland provides X Server emulation. That's not the point. Once the Xlib support underlying higher level toolkits is thrown out, the resulting clients built will not be network-capable. And most of the application developers will never notice (except that the DISPLAY arg doesn't seem to do anything anymore). And
Re: (Score:2)
Mod points from me. Have name, will deliver -- if not now, then on any other topic soon.
Re: (Score:2)
That's not what he meant I think.
Modern X applications (well, the toolkits) are resorting so much to simply pushing bitmaps to the X server that X is becoming unusable over the network.
Eg, the Qt developers found sometime ago that their client side rendering backend was much faster for local usage than the Xrender backend. So they made it the default for Qt4.4 And for Qt5 they didn't even bother with a Xrender based backend.
The client side rendering backend pushes so much data Kate is actually painful to u
Re: (Score:2)
Well, I also find strange that people say they see no difference.
My workplace is a simple LAN, with a dozen or so computers attached to a decent switch, perfectly capable of full bandwidth and a less than 200 s pings.
I run remote stuff everyday and I have a bunch of applications, using a bunch of toolkits, that perform between worse-than-local-but-ok to really bad.
From the top of my head, GTK3 applications are the only ones based on a modern toolkit that still run very well.
The fact that Qt5 needs libXrende
Re: (Score:2)
it should have read "less than 200 micro-second pings".
Re: (Score:2)
Let's hope the toolkits and applications will keep supporting X forever, or at least 10 years. No news of GTK3, Qt etc. dropping X11 support and there still is the older or simpler stuff around (GTK2, Motif, FLTK 1.3..)
Then the distro and app maintainers have to not throw X11 out as you say, like apps or libraries compiled with flags so they do not support X11.. Realistically for a good while they won't do that, with the moutains of applications and older hardware to support.
Then it shouldn't matter if you'
Don't you have anything better? (Score:2)
The "X is slow because gedit takes a long time to start" (because it's loading half of fucking gnome3!) is one of the low points, another, which is not his fault just one of people misunderstanding, is where his joke about only three people understanding X input fell flat and had been cited by the clueless as a
Re:I still don't see what's wrong with X (Score:5, Informative)
There are 3 situations involving applications, networking and graphics
a) Running an application on a machine sharing ram with the video card.
b) Running applications on a machine close enough to the video card that the latency between them is lowish and the bandwidth is plentiful and performance is irrelevant.
c) Running applications on a machine where either the latency is high or the bandwidth is limited
X11 does terrific for (b) in exchange for damaging (a) and (c). X11 was designed in a world where (b) is common. In today's world (b) is uncommon.
Other issues:
1. The mixing of signed and unsigned coordinates causes problems both in the protocol, where 3/4 of the coordinate space is often unrepresentable, and in the C language bindings.
2. The X protocol is asynchronous for efficiency: in general, neither the server nor clients wait for replies. But the protocol’s synchronization mechanisms are insufficient, and leave many unavoidable race conditions.
3. The X protocol attempts to be policy-free and tries not to dictate any particular style of window management. However, some desirable window manager features cannot be implemented correctly, because there are window attributes which the window manager can neither fetch nor monitor.
4. The X protocol provides visibility notification events so that clients can avoid computation of obscured window contents. However, this notification doesn’t work well for nested windows or for windows with backing store.
5. None of the several ways that an application can implement interactive mouse tracking of crosshairs, bounding boxes, etc., allow both efficiency and correctness.
6. Popping up menus and dialog boxes is slow because it requires too many round trips and generates too many events. Repainting when portions of a window become visible is often slow.
7. Exceptional conditions are poorly handled. Faulty programs can freeze the server, and clients cannot kill queued requests if the user doesn’t want to wait for the server to finish servicing them.
Re: (Score:2)
Yes. But. X. Real. Mir. Wishful. Thinking.
Re: (Score:2)
Hawaii desktop on Arch which runs Wayland: https://www.youtube.com/watch?... [youtube.com]
Re: (Score:2)
There are 3 situations involving applications, networking and graphics
a) Running an application on a machine sharing ram with the video card.
b) Running applications on a machine close enough to the video card that the latency between them is lowish and the bandwidth is plentiful and performance is irrelevant.
c) Running applications on a machine where either the latency is high or the bandwidth is limited
X11 does terrific for (b) in exchange for damaging (a) and (c). X11 was designed in a world where (b) is common. In today's world (b) is uncommon.
Nonsense. For (a) X can do fundamentally exactly the same thing as Wayland: Direct Rendering and and messages over a UNIX domain socket. (b) is still very common and I use X over such a network every day. In fact (b) is much more common now than when X11 was designed because we have much better networks now and a good wireless network falls into this category. (c) is a problem for X, but this is not a fundamental problem with X but with Xlib which could be fixed. But even there Wayland does not offer any ad
Re: (Score:3)
X can't do direct rendering. An application buffer is distinct from a graphical buffer.
It is not more common. How many people share applications across a wireless? Servers are generally over a WAN not a LAN. Even when it is a WAN there are few reasons to not ju
Re: (Score:2)
Re: (Score:2)
X is optimized for programs that use a small number of colors to draw an effectively vector-based user interface on a raster display. It is very, very good at that, and provides a powerful range of tools for the job.
Most programs use color-rich bitmap-based user interfaces. Doing this with core X functionality is painfully slow and difficult (think tens of seconds to draw a 800x600 JPEG), so everyone uses protocol extensions for this. Wayland is designed around bitmap-based drawing at the core.
Re: (Score:2)
For teh codes, stupid! (Score:2)
"MIR" is just a simple caesar cyphering away from "NIH'.
Re: (Score:2)
Most TLAs are a "caesar cypher" away from most other TLAs. (The obvious exception being ones with repeated letters, like BBC -> SSL)
Re: (Score:2)
Thanks, Dwight.
Re: (Score:2)
Mir de-orbited in 2001... (Score:2)
...why would it still be relevant now?
Re: (Score:3, Informative)
He's even the author of the linked article. When you follow the link, you see it. I think that's disclosed enough?
Re:Full Disclosure: M-Saunders works for LinuxVoic (Score:5, Funny)
Follow the link? What are you, new?
Re: (Score:2)
Not true. I know a few people (who know me) whose relevance is dwarfed even by the lowliest Anonymous Coward.