| |||||||||||||
A bit lopsidedA bit lopsidedPosted Mar 4, 2013 23:26 UTC (Mon) by man_ls (subscriber, #15091)In reply to: Canonical reveals plans to launch Mir display server (The H) by DiegoCG Parent article: Canonical reveals plans to launch Mir display server (The H) Why group Red Hat with "typical Linux distro", and not Ubuntu? I would say there are more Ubuntu derivatives than Red Hat derivatives out there. Anyway, it is nice to have alternatives, especially if they have learned from the predecessors' mistakes, and if Mir is compatible with Wayland.
(Log in to post comments)
A bit lopsided Posted Mar 5, 2013 0:20 UTC (Tue) by thebluesgnr (guest, #37963) [Link]
Red Hat uses and openly contributes to the entire open source stack so they fit well to the point DiegoCG was making. That's the distinction from where Ubuntu is headed, where they replace major components with NIH versions developed behind closed doors.
A bit lopsided Posted Mar 5, 2013 12:25 UTC (Tue) by chithanh (guest, #52801) [Link]
Indeed NIH is something you can't accuse Red Hat of. But they have demonstrated that they will do stuff behind closed doors if it makes sense from a business perspective. Most recently when they made RHEL kernel commit history non-public in order to gain advantages over Oracle.
Bad NIH, good NIH Posted Mar 5, 2013 13:53 UTC (Tue) by man_ls (subscriber, #15091) [Link] I wouldn't say that Red Hat is immune to NIH. I will give a couple of recent examples.Systemd developers have repeatedly stated that they don't want to contribute to Upstart because of its fundamental limitations. Having used Upstart for a while it starts to make sense. However we have seen a kernel developed for i386 cheap processors scale to supercomputers and to phones; from mainframes to $25 boards. I wonder, was it really so difficult to retrofit a good design on top of Upstart? Was it impossible to evolve the design, convincing Upstart maintainers? If so, it looks a little bit like Not Invented Here to me. Or was it really a case of Canonical holding the copyrights? If the collaboration model was at fault (and Canonical agreement sucks, frankly), isn't that a political reason? Journald did something similar with logs: syslog was apparently willing to accommodate any necessary changes, but instead they chose to go with their own solution. We needed another log system in Linux land like a third or fourth leg. Yes, it is often easier and faster to roll your own system; but that is exactly what NIH is about. Playing devil's advocate a little longer and in counter-fashion: NIH is not necessarily bad. I often roll my own code instead of going with the established for at least two reasons: knowledge and control. (Fun also plays a role, I have to admit.) It is more forgivable for private projects than for public operating systems, though.
Bad NIH, good NIH Posted Mar 5, 2013 16:07 UTC (Tue) by quintesse (subscriber, #14569) [Link]
Systemd and Upstart are completely different designs with a completely different philosophy behind them, trying to "evolve" that just doesn't make any sense whatsoever, especially when you're talking about a technology like Upstart that was very young as well. Now, if you take X then it makes sense to try to improve it... unless your new design is radically different and then you make Wayland, Surface Flinger or Mir ;)
Bad NIH, good NIH Posted Mar 5, 2013 19:08 UTC (Tue) by man_ls (subscriber, #15091) [Link] Let us see: both are init systems that have a configuration file to run tasks. The completely different design is, I gather, socket activation versus event-based; but it looks rather like just an implementation detail from the outside. Why not support both schemes? Is there a fundamental roadblock in init systems that prevent them from supporting different activation schemes, so that users can choose which to use when?But anyway this discussion has been rehashed a thousand times by now. The transition from X sounds much more radical: it changes where things are done, and also X is so old that I can believe it has too much cruft to clean up.
Bad NIH, good NIH Posted Mar 5, 2013 19:56 UTC (Tue) by quintesse (subscriber, #14569) [Link]
> X is so old that I can believe it has too much cruft to clean up.
But there is exactly where it still makes sense, it is used in SO many places that until recently there was really no alternative. So cleaning up still makes sense, and where necessary that has been done over years of hard work.
But there comes a time where it might just not do anymore and some radical new idea is needed, so you get something like Wayland. If you would have redesigned X to be what Wayland is now there just would be no reason to keep calling it X (except for PR purposes, see Atari or Commodore).
> but it looks rather like just an implementation detail from the outside
So you could say the same for X, Windows and Mac Quartz, they all seemingly handle showing and moving windows, the rest is just implementation details.
I just don't get people's urge for "making one system", what would that gain you? Better yet, examples abound where diversity results in faster progress and better results.
Now, I see much more evidence that the people starting on Mir should have talked with the Wayland developers before running of to make something of their own. But time will tell I guess.
Bad NIH, good NIH Posted Mar 5, 2013 20:34 UTC (Tue) by raven667 (subscriber, #5198) [Link]
Diversity in applications is great, that's competition, diversity in low level infrastructure is just a maintenance and compatibility burden, sometimes necessary but often it's just wheel re-invention.
Bad NIH, good NIH Posted Mar 5, 2013 20:54 UTC (Tue) by quintesse (subscriber, #14569) [Link]
That's exactly why you don't want a system that tries to combine both Upstart's and systemd's way of working. Diversity is in the way the good gets separated from the bad. And without that diversity there would be no progress.
Bad NIH, good NIH Posted Mar 5, 2013 21:14 UTC (Tue) by mmarq (guest, #2332) [Link]
Yes many things can be said, and both are true. Diversity is necessary, well established standards also...
I think the wisdom would be to try to combine the two.
As example, what misses now, who have 3 can have 4, is a new X project that combines some of the possible best features of all, yet maintains the X standard but is flexible enough to allow some extensibility =diversity.
I trace parallels with compiz/fusion and the all WM developments. It was nice to be able to change WMs, it will be nice to keep that possibility, yet all could function in the same system, and no need to "force" changes to the apps -> you have diversity, and you have a standard.
Bad NIH, good NIH Posted Mar 6, 2013 23:26 UTC (Wed) by nix (subscriber, #2304) [Link] maintains the X standard but is flexible enough to allow some extensibilityEr, you do know that X has had support for protocol extensions for about a quarter of a century now, right? Eventually it's just not enough. X has had an astonishing record of backward compatibility, but you can't drag an old horse forever, alas. Most of X is now unused by most applications, and there are things extensions just can't do :(
Bad NIH, good NIH Posted Mar 7, 2013 14:51 UTC (Thu) by mmarq (guest, #2332) [Link]
Think about Linux kernel...
Perhaps is not a good idea to drag an hold worse forever lol (not as old as X but pretty old). If only it was as easy to fork or start allover as X...
That is another cliche, there is no piece of software that can't be improved... only if wisdom "emperator", then things could be different, and anyone is "free" to fork the linux kernel or start a new one if they wish, only what is more prevalent at this low levels is quality and usefulness, *old* means nothing...
Bad NIH, good NIH Posted Mar 8, 2013 14:55 UTC (Fri) by nix (subscriber, #2304) [Link]
The problem is not that the software is old: software, indeed, does not rot. The problem is that the core protocol is old, imposes restrictions that cannot be avoided (e.g. slow startup due to multiple roundtrips) and 90% of it (probably more actually) is unused by everything you run, unless you really like running old Xaw-based paint programs. The protocol was very well-designed for its time, but its time was when PostScript was new: the designers couldn't foresee what was coming in graphics card design twenty years down the road. That sort of thing cannot be fixed without breaking protocol compatibility, by which point you're talking breaking every X app anyway. So why not try something quite different?
(I still think that a display protocol was a very important innovation and that making drawing direct to the framebuffer the core operation is a huge step back. But, hey, I'm not writing the code.)
Old software Posted Mar 8, 2013 15:13 UTC (Fri) by man_ls (subscriber, #15091) [Link] Software ages like any other human construct: style rules change, coding standards improve (and sometimes regress), libraries become unsupported and stop working on modern systems. Anyone who has tried to build software that is 20 years old can attest to it -- we are talking about the days when Linux was not yet two years old.That is of course a metaphor: while the code itself does not change with time, the world around it does. So in effect old code is as hard to use as other old tools.
Old software Posted Mar 8, 2013 19:04 UTC (Fri) by hummassa (subscriber, #307) [Link]
> Software ages like any other human construct: style rules change, coding standards improve (and sometimes regress), libraries become unsupported and stop working on modern systems. Anyone who has tried to build software that is 20 years old can attest to it -- we are talking about the days when Linux was not yet two years old.
> That is of course a metaphor: while the code itself does not change with time, the world around it does. So in effect old code is as hard to use as other old tools.
Kudos. Two EPIC paragraphs describing bitrot. I will quote you for ever and ever more, or at least until your quote is no longer pertinent. :-D
Bad NIH, good NIH Posted Mar 8, 2013 19:24 UTC (Fri) by HelloWorld (guest, #56129) [Link] I still think that a display protocol was a very important innovation and that making drawing direct to the framebuffer the core operation is a huge step back.I don't see why. Afaics, there were essentially two reasons for putting the rendering code in the X server:
Bad NIH, good NIH Posted Mar 9, 2013 0:21 UTC (Sat) by Serge (guest, #84957) [Link]
> Afaics, there were essentially two reasons for putting the rendering code in the X server
X server supports both client-side and server-side rendering.
But Xorg is much more than just rendering.
(#6 is not that strong now, Wayland fans talk a lot about Xorg being bad, and that gives some bad points to Xorg and commercial Linux development, sigh...)
At the same time X11 was never rotten. On the contrary, it was always among the first to innovate. First remote graphical terminals, first desktops with multiple workspaces, multi-monitor systems, first multiseats, first 3D-desktop, first multi-touch (MPX, yeah, it was done before iPhone :)) — most (if not all) of these things were first done under X-server.
> Otoh, client-side rendering is faster because it avoids the protocol overhead
You should probably like DirectFB a lot. It's direct, client-side, and has no server, so it completely avoids any overhead possible. :)
Bad NIH, good NIH Posted Mar 9, 2013 18:45 UTC (Sat) by HelloWorld (guest, #56129) [Link]
Bad NIH, good NIH Posted Mar 9, 2013 21:58 UTC (Sat) by Serge (guest, #84957) [Link]
> 1. Nobody needs or wants X servers for Windows, Mac OS or Android.
Have you heard about windows program called "putty"? You can ssh with it to remote server with no video adapter and run X11 apps over it. How? Using X server for Windows. You can do similar things with OS X, it has its own X server. There're also X11 implementations for Android.
Yes, people need and want X server for Windows, Mac OS and Android. And they have it.
> What people want is remote applications, and they'll get those with Wayland via a VNC-like protocol. Which, by the way, works way better than X for today's applications.
You don't need Wayland to use VNC, you know that? Also, Wayland is about direct client-side hardware use, you'll get some problems when you try using it on a server with no graphical hardware.
So, you have Xorg (works always, supports X11 forwarding, VNC, xpra, NX), and you have Wayland (works sometimes, theoretically supports VNC). I don't see a reason to choose Wayland in this case, do you?
> 2. It doesn't run everywhere. Android doesn't use it, Firefox OS doesn't, Tizen doesn't, Mac OS X and iOS don't, nobody right in their mind uses it except as a compatibility crutch.
It does run everywhere. It can be run on Android (and it was done since first androids), there're X11 implementations for iOS, and it's included in Mac OS X. Also it's used by Maemo/Meego.
> 3. That will come for Wayland as well, it's just a matter of time.
Wayland design makes me think it won't. What makes you think it will? Let's take an example: directfb. It's well known, was created 12 years ago (!) and still does not have those good tools.
> 4. You can run any desktop environment on Wayland too, and you can combine any Wayland compositor with any desktop, provided it offers the needed functionality (which obviously applies on X11 as well)
Theories again? Please, run Compiz on Wayland. At least run IceWM on Wayland. Have you ever used Wayland/Weston yourself?
> 5. The toolkits that matter will soon support Wayland (or already do)
I guess you have not seen how it looks. Try it. Anyway, all toolkits already support X11. Name one reason why they should bother supporting Wayland?
> 6. The Wayland protocol is stable
You obviously have no idea what's "stable". "Stable" means that I can release program today and it will continue to work. "Stable" means good for long term commercial use.
X11 is stable. It always was. Now Wayland has v1 protocol for a few months and you can't be sure that tomorrow there won't be Wayland v2 with completely different protocol. Bear in mind that currently you can't use Wayland protocol without compositor extensions. And a few existing compositors have them different. Wayland is unstable itself and it's trying to shake Xorg by constantly attacking it ("it can't be worse than X11"). This is bad for the entire Linux community.
> and X applications are supported via XWayland.
You haven't ever used it, have you? Try using RebeccaBlackOS LiveCD. When you notice that your X11 programs don't start any more try debugging that.
> That's why many of the X.org developers themselves (including Keith Packard, Kristian Høgsberg, Daniel Stone) support Wayland. Now please don't try to tell me that you know better than them what a future-proof graphics stack looks like...
Oh, that's the biggest mystery for me. Initially I thought that Wayland was just a proof-of-concept, like "Look, Linux has such a powerful graphical stack that I can easily create a simple window system". Then I thought that Wayland could be a test of new ideas before including them into Xorg. But Wayland is still promoted as being better than Xorg, and I don't see who it's supposed to be good for.
It just was not possible to do something like Wayland before. So I understand that it's fun for smart hackers to dig though something new, something that have never been done. But for now Wayland looks like a personal toy for its developers, that brings no benefits to anybody else.
Bad NIH, good NIH Posted Mar 10, 2013 3:07 UTC (Sun) by HelloWorld (guest, #56129) [Link]
People have explained dozens of times by now what's wrong with X11 and why it's worth working on a replacement. If you still didn't understand, it's because you don't want to, and I won't waste my time trying to convince you otherwise. Fortunately, the world keeps moving despite stick-in-the-muds like you.
Bad NIH, good NIH Posted Mar 10, 2013 15:37 UTC (Sun) by hummassa (subscriber, #307) [Link]
> People have explained dozens of times by now what's wrong with X11 and why it's worth working on a replacement.
No. No one has explained what is wrong with X11 or with its implementations.
More specifically, no one has explained why any possible flaws are not fixable.
About the worth of working on a replacement, to each its own, and no one can force others to work (or to pay someone to work) on something.
Bad NIH, good NIH Posted Mar 10, 2013 18:25 UTC (Sun) by patrick_g (subscriber, #44470) [Link]
> No. No one has explained what is wrong with X11 or with its implementations.
Please look at this video : http://www.youtube.com/watch?v=RIctzAQOe44
Bad NIH, good NIH Posted Mar 11, 2013 4:58 UTC (Mon) by Serge (guest, #84957) [Link]
>> No. No one has explained what is wrong with X11 or with its implementations.
> Please look at this video : http://www.youtube.com/watch?v=RIctzAQOe44
Presentation that starts with "Noone has any idea". Saying things like "I'm the smart guy and everybody else is stupid", even if you're joking or have reasons for that, still looks... not very polite. But let's get back to the X11 talks.
There goes an interesting story of XFree86/Xorg evolution, how it looked 20 years ago and how few features it had back then, and how many features it has now, how it adopted all the modern hardware, how older extensions were replaced by their newer versions etc.
But where are the problems? Gedit startup is too slow? Then fix gedit! The rest is like "X is doing that bad, so Wayland can't do that at all" or "X does it that way, we don't like that, so Wayland does it this way" or usually it's like "Wayland is going to do it better" because it's not implemented yet or the implementation is very basic/buggy. That's all! No problems of X11 protocol or even Xorg there.
What have I missed?
BTW, it was kind of fun listening to "X isn't network-transparent any more" while running some GUI tools over ssh -Y.
Bad NIH, good NIH Posted Mar 11, 2013 9:30 UTC (Mon) by gioele (subscriber, #61675) [Link]
> BTW, it was kind of fun listening to "X isn't network-transparent any more" while running some GUI tools over ssh -Y.
The presenter explicitly said that "X is network-capable, not network-transparent". It means that you can run X applications over the network, but the software has to handle it as a special case now, given that the current normality is the use of shared memory buffers.
Bad NIH, good NIH Posted Mar 11, 2013 4:33 UTC (Mon) by Serge (guest, #84957) [Link]
> People have explained dozens of times by now what's wrong with X11 and why it's worth working on a replacement.
No! People have dozens of times explained why they CAN work on a replacement, not why it's worth working on it. Usually all those explanations boil down to "X11 has too many features" and "Wayland is not too bad". But nobody have ever explained who's going to win from it. I would be glad if you provide me a link to such explanation.
Wayland/Weston is like a HelloWorld-program. It's useless but IN THEORY you can extend it to do whatever you want... Hm... HelloWorld is the best graphical manager! It's fast and simple! You can do everything else client-side! Sounds familiar? :-)
Bad NIH, good NIH Posted Mar 10, 2013 10:44 UTC (Sun) by nix (subscriber, #2304) [Link] Nobody needs or wants X servers for Windows, Mac OS or Android. What people want is remote applications, and they'll get those with Wayland via a VNC-like protocol. Which, by the way, works way better than X for today's applicationsThat's just as wrong as it was last time you said it. Even the Wayland developers say that to accelerate things like scrolling screenfuls of text (a common case) will require toolkit-level remoting that is aware of things like glyphs rather than just considering the framebuffer to be a big image.
Bad NIH, good NIH Posted Mar 11, 2013 12:27 UTC (Mon) by dgm (subscriber, #49227) [Link]
There are many things that can run smoother over the network if done more cleverly than just copying frames around, but:
1. Most people do not need to work over the network, specially those that have the greatest need for performance: games, video playback and such. 2. Copying frames is by far the simplest solution. 3. Being able to copy frames doesn't mean you cannot _add_ a cleverer solution.
So, a local only display covers maybe 95% of user needs, and with dumb frame copying you may be getting that up to 99% (statistics right out of my hat, but still). The remaining 1% _can_ be worked out, or just keep using X11.
The alternative is forcing network "transparency" down everybody's throat, even if they do not want or need it.
It's not really that nobody needs X11. I do, for instance. But I'm not so stupid to not realize that most people don't. And forcing them to play a price for something I need doesn't sound like a great idea.
Bad NIH, good NIH Posted Mar 11, 2013 15:27 UTC (Mon) by nix (subscriber, #2304) [Link]
I find it hard to believe that you think that playing video rendered over the network (without using something like Youtube) is a more common case than rendering scrolling text buffers over the network. The latter is about 99% of what people use X remotely *for*.
Bad NIH, good NIH Posted Mar 12, 2013 12:21 UTC (Tue) by dgm (subscriber, #49227) [Link]
> rendering scrolling text buffers over the network [...] is about 99% of what people use X remotely *for*.
Probably, but what percentage of people do use X remotely, actually?
Does it make sense to design the solution around that use case? Or would it be better to design things around the *common* use case (computing and display on the same node), specially when alternative solutions do exist?
Bad NIH, good NIH Posted Mar 13, 2013 21:41 UTC (Wed) by nix (subscriber, #2304) [Link]
I can't tell you how common it is, or isn't. I don't see how you could claim that you know that non-remote use is so common that the remote case should be disregarded, either.
Bad NIH, good NIH Posted Mar 13, 2013 20:14 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> That's just as wrong as it was last time you said it.
Well, it's more or less what Daniel Stone said in his recent talk about X and Wayland.
> Even the Wayland developers say that to accelerate things like scrolling screenfuls of text (a common case) will require toolkit-level remoting that is aware of things like glyphs rather than just considering the framebuffer to be a big image.
Bad NIH, good NIH Posted Mar 13, 2013 21:46 UTC (Wed) by nix (subscriber, #2304) [Link]
So... your 'argument' is that VNC-like stuff is 'good enough', even though it is clearly much worse than glyph-by-glyph stuff for the vast majority of windows that anyone ever opens using any windowing system -- those windows filled with text? (Discounting, for these purposes, games and video playback, which clearly should be local or use a video compression algorithm of some sort.)
Almost every use case (save only the GIMP, Inkscape and their ilk) can be covered by video compression or glyph-by-glyph stuff. VNC is bad for *both* of these. As far as I can tell, VNC is far suboptimal for *everything*.
Bad NIH, good NIH Posted Mar 13, 2013 22:51 UTC (Wed) by HelloWorld (guest, #56129) [Link]
Of course it's suboptimal. It's also easy to implement and doesn't need application or toolkit changes and still works better than X (which is unusable over high-latency links). Again, the question isn't whether it's possible to do better but whether someone can be bothered to invest a significant amount of work in a better solution. Given that remote applications == web applications for 95% of all users, I don't think anybody will.
Bad NIH, good NIH Posted Mar 13, 2013 23:43 UTC (Wed) by nix (subscriber, #2304) [Link]
It doesn't work better than X over even low-latency links the moment you have to scroll. Scrolling a windowful of text using normal VNC is laggy even over a quiet gigabit ethernet link: over anything slower it is hopeless.
Bad NIH, good NIH Posted Mar 14, 2013 3:10 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
you are so focused on what is the 'norm' today that you are completely blind to the future.
remote display uses that are going to become very common in the near future (especially when connected to mobile devices that do not have the CPU power to render locally, then ship VNC style full-frame images out to the remote display)
1. Google Glasses style head mounted displays.
Google is far from the only company working on this sort of thing. Many of these uses are text or simple geometric objects overlayed on the live video, shipping the video to the phone, doing the overlay, and shipping the result back out is wasting a lot of bandwidth, and battery. Not Going To Happen (at least not for very long). What's going to happen is the video will get shipped to the phone (although not necessarily in full resolution), the phone will craft the overlay, and the overlay will be transmitted back to the headpiece to be combined there with the direct feed from the camera.
2. remote displays (frequently wireless) from mobile devices to large, high-res displays.
Haven't you seen any of the many TV shows or movies recently that show people pulling something up on a phone/tablet and then 'flicking' the window over to the full display? What makes you so sure that this is not going to happen?
There are probably a lot of other examples that people could point out, but just because you don't currently use remote displays doesn't mean that they aren't going to be very popular very soon.
Bad NIH, good NIH Posted Mar 8, 2013 23:58 UTC (Fri) by Serge (guest, #84957) [Link]
I assume you're talking about Xorg.
> The problem is that the core protocol is old
That's not a problem. That's an advantage, which says that the protocol has such a good design that being old still works and supports all the modern features.
> imposes restrictions that cannot be avoided (e.g. slow startup due to multiple roundtrips) and 90% of it
That may be a problem. Let's check that:
$ time xterm -e /bin/true
Nope, that's not a problem too. :) Startup is fast enough.
If some programs start faster, while others start slower, then those programs are to blame, not Xorg, right?
Bad NIH, good NIH Posted Mar 9, 2013 4:41 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>That's not a problem. That's an advantage, which says that the protocol has such a good design that being old still works and supports all the modern features.
No, it doesn't.
For example, there's a long-standing problem with language switching by alt-shift keypress (not possible due to X quirks with modifier keys processing).
Then there's the whole full-screen rendering fiasco. There's no good way for an app to switch to a full screen and make sure the previous resolution is restored when the app exits.
Then there's a problem with OpenGL-based compositors - they don't always synchronize rendering correctly.
Etc.
Bad NIH, good NIH Posted Mar 9, 2013 19:50 UTC (Sat) by Serge (guest, #84957) [Link]
>> That's not a problem. That's an advantage, which says that the protocol has such a good design that being old still works and supports all the modern features.
> No, it doesn't.
> For example, there's a long-standing problem with language switching by alt-shift keypress (not possible due to X quirks with modifier keys processing).
Bad example.
> Then there's the whole full-screen rendering fiasco. There's no good way for an app to switch to a full screen and make sure the previous resolution is restored when the app exits.
First, it's a bad idea anyway, because if I changed resolution with `xrandr` I don't want it to change back when `xrandr` exits. Next, Xorg is able to "restore" whatever resolution you configure using Ctrl+Alt+GrayPlus and Ctrl+Alt+GrayMinus since forever. Also Xorg allows you to bind `xrandr` call with your favourite resolution to any hotkey. And finally, it STILL has nothing to do with X11 protocol.
> Then there's a problem with OpenGL-based compositors - they don't always synchronize rendering correctly.
That's not a bug, but optional feature. You can turn vsync off and see how many FPS you get. Good for benchmarks and regression testing. And this is still about compositing WMs, but it's not a bug of Xorg or X11 protocol.
No protocol problems found. :)
Bad NIH, good NIH Posted Mar 9, 2013 20:24 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>First, I'm not sure what's the problem you're talking about, can you explain in details?
Simple. There is no way for language switcher to use only modifier keys. X protocol itself doesn't support it and workarounds are too complicated (like getting grab on all input and re-inserting messages back).
>Next, what a strange choice for the keyboard layout hotkey, there're plenty of keys on a keyboard (CapsLock, Menu...) that are less used and easier to hit.
>First, it's a bad idea anyway, because if I changed resolution with `xrandr` I don't want it to change back when `xrandr` exits.
>Next, Xorg is able to "restore" whatever resolution you configure using Ctrl+Alt+GrayPlus and Ctrl+Alt+GrayMinus since forever.
...and here we have a wonderful example of X's "robustness"...
Bad NIH, good NIH Posted Mar 11, 2013 3:03 UTC (Mon) by Serge (guest, #84957) [Link]
> There is no way for language switcher to use only modifier keys. X protocol itself doesn't support it and workarounds are too complicated (like getting grab on all input and re-inserting messages back).
Just tried. I've set up xkb to switch layout using my Ctrl key. Looks working. I also configured xbindkeys to run some command when I press Shift. Looks working too. Both X11 protocol and Xorg itself allow you to use modifier keys to switch language, or write a custom switcher to do that.
> Duh. I think it's obvious that there should be a special protocol for resolution changing apps.
Ehm... Two protocols, one for games, changing resolution, and another for tools, changing resolution? And how are you going to stop games from using protocol for tools? Create another third protocol to authorize them? ;)
In Xorg there're much simpler solutions to that. I already told you about Ctrl+Alt+Plus/Minus and suggested you to bind `xrandr` call to some hotkey. Alternatively you can create a simple "restorer.sh" script:
#!/bin/sh
And run the game like: `restorer.sh thegame`
> And they do not always work. Besides, I don't _have_ a gray minus on my keyboard.
You don't have Numpad? Weird keyboard... Well, you can still get that key! You can remap any of your keys using `xmodmap`.
> ...and here we have a wonderful example of X's "robustness"...
Yeah. Xorg is great, it allows you use whatever use-case you want. It's much better than Wayland, where features like that are impossible.
Bad NIH, good NIH Posted Mar 11, 2013 4:01 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Just tried. I've set up xkb to switch layout using my Ctrl key. Looks working.
That's because ctrl key is not a modifier key, try that with alt-shift.
It's actually possible to use alt-shift for switching, but not easily. As far as I remember, that involves editing xkb bindings to remap this combination to another.
Decidedly not an example of X's robustness.
>Ehm... Two protocols, one for games, changing resolution, and another for tools, changing resolution?
>And how are you going to stop games from using protocol for tools? Create another third protocol to authorize them? ;)
Changing resolution is a privileged operation that shouldn't be exposed to games. In fact, games just need a way to hint the composer that they want to occupy the full screen (maybe with a specific screen resolution). For example, Mac OS X in these cases allocates a separate _desktop_ and switches to it, leaving other desktops untouched.
>In Xorg there're much simpler solutions to that. I already told you about Ctrl+Alt+Plus/Minus and suggested you to bind `xrandr` call to some hotkey. Alternatively you can create a simple "restorer.sh" script
Sorry, but using shell scripts to restore resolution belongs in early 90-s.
> You don't have Numpad? Weird keyboard...
>Well, you can still get that key! You can remap any of your keys using `xmodmap`.
Bad NIH, good NIH Posted Mar 11, 2013 5:46 UTC (Mon) by Serge (guest, #84957) [Link]
> That's because ctrl key is not a modifier key
...
> It's actually possible to use alt-shift for switching, but not easily. As far as I remember, that involves editing xkb bindings to remap this combination to another.
What? "alt_shift_toggle" is among standard xkb options. And most DEs allow you to choose it. What DE are you using?
> Yep. And it's actually already done!
Reimplementing (theoretically) one more feature from Xorg in Weston does not make Weston better than Xorg. And it's still impossible to do that using Wayland protocol.
> Yep. Just making wlrandr privileged is enough.
That would also make xrandr-like tools impossible, so we get back to the original problem. Or what do you call "privileged"?
> For example, Mac OS X in these cases allocates a separate _desktop_ and switches to it, leaving other desktops untouched.
They took that idea from X server. :-) Among the first links in google:
> Sorry, but using shell scripts to restore resolution belongs in early 90-s.
That was just one option among many. Xorg gives you the choice. You don't have even that option in Wayland.
> I don't care. Anything that doesn't work out-of-box is unacceptable.
Sorry, but restoring the resolution when user have not asked for is stupid. What if user have intentionally changed the resolution? ;-)
The entire idea of changing the resolution back when program exits is actually pointless. It solves nothing. Program can just change resolution and freeze or go into background.
And this is not a problem of X11/Xorg anyway. X11 allows you to implement whatever solution you like.
Bad NIH, good NIH Posted Mar 11, 2013 6:35 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
> What? "alt_shift_toggle" is among standard xkb options. And most DEs allow you to choose it. What DE are you using?
KDE. Using xkb options results in some strange behavior. Also, hotkeys involving alt-shift are sometimes garbled (i.e. you press alt-shift-k and it results in switching keyboard layout and printing 'л'). I moved to CapsLock for layout switching eventually.
> Reimplementing (theoretically) one more feature from Xorg in Weston does not make Weston better than Xorg. And it's still impossible to do that using Wayland protocol.
>They took that idea from X server.
Virtual desktops on Mac OS X are the same thing as virtual desktops on X. And Mac OS X allows virtdesktops on a same display to have different resolutions (which X doesn't allow, btw).
> That was just one option among many. Xorg gives you the choice. You don't have even that option in Wayland.
Wayland is so great because is designed from the start to BE RELIABLE in the modern world. That's why Wayland devs pay a lot of attention to details that you simply don't know about.
For example, X still has problem with subpixel rendering because there's no way for the client-side library to know the current display's orientation. That's why KDE and GNOME have separate manual settings for them, while Wayland carries this information in the native protocol.
Then there's a whole question of synchronization. Wayland devs spent quite a lot of time discussing the whole double buffering mechanism, making it much more robust than in X (where buffer swap either stalls your pipeline or can happen at indeterminate time).
Bad NIH, good NIH Posted Mar 11, 2013 15:15 UTC (Mon) by nye (guest, #51576) [Link]
>For example, X still has problem with subpixel rendering because there's no way for the client-side library to know the current display's orientation. That's why KDE and GNOME have separate manual settings for them, while Wayland carries this information in the native protocol.
What happens - either in X or Wayland - if one window spans displays which are not in the same orientation?
This monitor setup is not a hypothetical scenario for me BTW.
(And as an aside, I still think subpixel font rendering is a totally stupid idea, in part because of this very issue which means that the font renderer needs to have precise knowledge about the specific output device at any time; that sounds to me a lot like 'unwarranted chumminess with the implementation'. Leave aside what happens if there are any display transformations in effect, or if you want to create screenshots, or...)
Bad NIH, good NIH Posted Mar 11, 2013 15:20 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
> What happens - either in X or Wayland - if one window spans displays which are not in the same orientation?
One kind of rendering would be used.
Wayland has no notion of displays, really. An application just gets a surface to paint on, which might or might not span several displays. In case of multi-display surface Wayland can use 'unknown' subpixel ordering.
> And as an aside, I still think subpixel font rendering is a totally stupid idea, in part because of this very issue which means that the font renderer needs to have precise knowledge about the specific output device at any time
Bad NIH, good NIH Posted Mar 12, 2013 13:31 UTC (Tue) by nye (guest, #51576) [Link]
>In case of multi-display surface Wayland can use 'unknown' subpixel ordering.
Do you know if commonly available font renderers will automatically disable subpixel rendering in the case that they don't know the order of the subpixels?
(Not that there's any particular reason you should know, bu this is the first time I've even seen anyone bring up this issue in Wayland discussion which kind of implies you've at least thought about it more than most.)
>Uhm. It has this knowledge in 99% of cases.
But not in X, you previously said?
>And personally I prefer occasionally looking at blurred screenshots rather than looking at blurred text _all_ the time.
I'm not quite clear on that - subpixel rendering is an attempt to make text closer to its theoretically correct shape in exchange for making it less sharp, so I can't see how it could possibly make text *less* blurred than without it.
The entire theoretical basis of subpixel rendering is flawed because it relies on the fact that the colour perception of the eye is less accurate than its ability to discern the intensity. To rephrase that: your eye can discern the improved shape while not noticing the colour change.
This is true to an extent, but in the centre of the eye the colour perception is good enough that in practice there's visible colour fringing in subpixel rendered text unless you either have a very high-dpi display, or you're sitting miles away. I know a lot of people don't mind that and find the trade-off worthwhile, but I most definitely am not among them.
Bad NIH, good NIH Posted Mar 12, 2013 14:19 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
> Do you know if commonly available font renderers will automatically disable subpixel rendering in the case that they don't know the order of the subpixels?
Right now? I don't think so, as there's no support for getting subpixel order in X.
But it shouldn't be complicated to add if there's a way to obtain surface subpixel layout information.
>But not in X, you previously said?
>I'm not quite clear on that - subpixel rendering is an attempt to make text closer to its theoretically correct shape in exchange for making it less sharp, so I can't see how it could possibly make text *less* blurred than without it.
If you want to have completely 'sharp' fonts then you have to use 100% on/off pixels with the same intensity for all of their subpixels. So in this case subpixel information is irrelevant (unless you also want to do _colored_ text). But completely 'sharp' fonts also look too jagged and any attempts on smoothing that don't take subpixel ordering into account are going to result in a total mess.
I don't think that color fringing is a big problem for most people. Personally, all of my display devices are now at Retina resolution or close to it :)
Bad NIH, good NIH Posted Mar 12, 2013 22:15 UTC (Tue) by Serge (guest, #84957) [Link]
> there's no support for getting subpixel order in X.
> Subpixel rendering allows to draw better looking curves by taking into account the fact that physical pixels on the screen consist of discrete subpixels.
Here you're wrong. Twice. Both X11 and Wayland provide that information. But the fun part: it is useless in Wayland. By design. Because in Wayland your surface could be rotated, stretched or somehow transformed, so that subpixel information is completely useless there. That's the Wayland protocol with its great "reliable" design.
Bad NIH, good NIH Posted Mar 13, 2013 1:41 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>Here you're wrong. Twice. Both X11 and Wayland provide that information.
Nope. X protocol knows nothing about subpixel order. Wayland does.
Xranrd in this case is a cop-out because it's not universally available.
>But the fun part: it is useless in Wayland. By design. Because in Wayland your surface could be rotated, stretched or somehow transformed, so that subpixel information is completely useless there.
And of course, there are compositing managers in X that can mutilate the image in various ways.
Bad NIH, good NIH Posted Mar 14, 2013 5:38 UTC (Thu) by Serge (guest, #84957) [Link]
> Nope. X protocol knows nothing about subpixel order. Wayland does.
Both X and Wayland request information from display. If that information is available there they can read it. Both. Or do you thing that Wayland is reading the mind of display creators, while Xorg can't do that? ;-)
> Xranrd in this case is a cop-out because it's not universally available.
Run `xrandr --verbose` and see "Subpixel" there. Now think, if xrandr gets information from X-server then X-server knows about subpixels, and X11 protocol is able to transfer that, right? Just read the protocol if you still don't believe me.
> Wayland exposes the surface orientation to applications (surprise!)
Indeed, it's a surprise, could you point me to that part of the Wayland protocol?
Bad NIH, good NIH Posted Mar 14, 2013 5:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
> Both X and Wayland request information from display. If that information is available there they can read it. Both. Or do you thing that Wayland is reading the mind of display creators, while Xorg can't do that? ;-)
Yep. Try that trick with Xrandr on legacy NVidia drivers (hint: it doesn't work).
Of course, your app can also read display EDIDs and parse them. Through the X protocol! But that kinda says that you should probably stop doing it.
> Run `xrandr --verbose` and see "Subpixel" there.
>cyberax@whale2:~$ xrandr --verbose
Yeah, robust X protocol and all that....
> Indeed, it's a surprise, could you point me to that part of the Wayland protocol?
Bad NIH, good NIH Posted Mar 14, 2013 8:35 UTC (Thu) by Serge (guest, #84957) [Link]
> cyberax@whale2:~$ xrandr --verbose
> SZ: Pixels Physical Refresh > *0 1024 x 768 ( 260mm x 195mm ) *60 > ... > Yeah, robust X protocol and all that....
Ha-ha, that was fun. Either you have done that on purpose, or you're testing that on a server back from 2005. :-) You can check `xdpyinfo -ext RENDER` too, it's supported since about 2003.
Xrandr is just a tool to request that information. Xdpyinfo is another one. X-server knows about subpixels and uses them for a loooong time.
> Try that trick with Xrandr on legacy NVidia drivers (hint: it doesn't work).
Why do you think it won't work? Hah! Try Wayland with legacy NVidia driver (hint: it doesn't work)!
> See "enum transform" and various related events and requests
Have you seen that yourself? It's just display rotation, similar to xrandr, not the surface rotation done by compositor.
Bad NIH, good NIH Posted Mar 14, 2013 10:59 UTC (Thu) by nye (guest, #51576) [Link]
>You can check `xdpyinfo -ext RENDER` too, it's supported since about 2003.
"Screen 0 (sub-pixel order Unknown)"
i915 driver FWIW.
Bad NIH, good NIH Posted Mar 14, 2013 17:31 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Can you provide a reference to X specification about subpixel order and its relationship with display transformation? And not for xrandr, please.
Bad NIH, good NIH Posted Mar 15, 2013 7:15 UTC (Fri) by Serge (guest, #84957) [Link]
> Can you provide a reference to X specification about subpixel order and its relationship with display transformation? And not for xrandr, please.
Bad NIH, good NIH Posted Mar 15, 2013 16:04 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
That's an extension, not the X protocol itself.
Bad NIH, good NIH Posted Mar 16, 2013 0:15 UTC (Sat) by HelloWorld (guest, #56129) [Link]
Yes, that's true. It also doesn't matter at all.
Bad NIH, good NIH Posted Mar 16, 2013 7:22 UTC (Sat) by Serge (guest, #84957) [Link]
> That's an extension, not the X protocol itself.
In X world extensions are part of the X11 protocol. For example this particular extension is part of X11R6.9, you can see that in its URL.
Bad NIH, good NIH Posted Mar 16, 2013 9:08 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
But it's not a part of my X server.
Waaahhhh! X encourages fragmentation!
Bad NIH, good NIH Posted Mar 12, 2013 21:21 UTC (Tue) by Serge (guest, #84957) [Link]
> Using xkb options results in some strange behavior. Also, hotkeys involving alt-shift are sometimes garbled (i.e. you press alt-shift-k and it results in switching keyboard layout and printing 'л').
Well, you switched layout and pressed some key... Anyway, that's not X11 problem, just a bug in xkb in worst case. And it's not solved by Wayland (you probably don't know but Wayland/Weston kind of uses xkb :)). But if that's a bug it should be fixed. Just curious, what is expected behavior for you?
> So it's impossible even when I'm pointing to you that it IS already done? And using a Wayland protocol extension.
What you linked is same as what you have with Xorg, and don't like so much. :) And that's a compositor extension (suggested, since it's not a part of weston), it's not part of Wayland protocol. Wayland compositor is like HelloWorld program, you can extend it to do everything you want. But it will be supported by that compositor only.
It is one of the greatest problem of the entire Wayland design — it encourages you to put every missing feature into unique compositor extension, so you eventually end up with lots of incompatible compositors, each having a small subset of all the Xorg abilities and standards.
> Virtual desktops on Mac OS X are the same thing as virtual desktops on X. And Mac OS X allows virtdesktops on a same display to have different resolutions (which X doesn't allow, btw).
Virtual desktops on X are up to the window manager. Nothing stops it from switching resolution when you switch desktop. So again, that's not X11 problem.
> I don't care about many options. I want a display stack that works consistently and predictably in most cases.
Then what stops you from configuring it the way you want? X allows you to do that, Wayland/Weston does not.
> Wayland is so great because is designed from the start to BE RELIABLE in the modern world.
It's not designed to "be reliable". :) Sorry. It basically designed to be "like X but better". On the other hand X is reliable, because it allows you to configure it the way you want, and it will work that way for years.
> For example, X still has problem with subpixel rendering
What problem?
> because there's no way for the client-side library to know the current display's orientation. That's why KDE and GNOME have separate manual settings for them, while Wayland carries this information in the native protocol.
So does X. Check `xrandr --verbose`. (Oops) :) KDE and GNOME just allow you to configure some Xft/fontconfig options manually, because many (most?) monitors actually do not provide that information. And because some people don't like subpixel font hinting. Would you prefer it to be unconfigurable?
> Then there's a whole question of synchronization. Wayland devs spent quite a lot of time discussing the whole double buffering mechanism, making it much more robust than in X (where buffer swap either stalls your pipeline or can happen at indeterminate time).
(You talk about that as if you never used Wayland/Weston and never seen how windows blinked like crazy when you resized them) It's not that I understand what problem you talk about but who cares? Yes, Wayland is a lot about "we don't like how X does that so we do that differently", but who cares? Nobody works on that low level. And those who do (authors of toolkits and compositing managers) have already implemented that ten years ago. What's the point in changing the protocol that people either don't care or got already implemented and working?
Bad NIH, good NIH Posted Mar 13, 2013 8:04 UTC (Wed) by paulj (subscriber, #341) [Link] Virtual desktops on Mac OS X are the same thing as virtual desktops on X. And Mac OS X allows virtdesktops on a same display to have different resolutions (which X doesn't allow, btw). My multi-monitor setup in work consists of two different sized monitors. I run each at their native res. So I have desktops with 2 different resolutions right in front of me, here now. So I strongly suspect you may be wrong on this point.
Bad NIH, good NIH Posted Mar 11, 2013 22:58 UTC (Mon) by khc (subscriber, #45209) [Link]
> That's because ctrl key is not a modifier key, try that with alt-shift.
I use alt-shift to switch input method (with scim), and have been doing this for a few years. Other than me accidentally hitting it from time to time, I don't have a problem with it.
Bad NIH, good NIH Posted Mar 9, 2013 16:01 UTC (Sat) by nix (subscriber, #2304) [Link]
Um, startup is fast on low-latency connections, sure. Now try it over a higher-latency link. Be prepared to wait a while (sometimes *minutes*, not seconds: the worst I've ever encountered was over a dialup modem and took more than half an hour to map a window, though admittedly that was a program that took a couple of seconds to map its first window even on Ethernet).
Bad NIH, good NIH Posted Mar 9, 2013 19:10 UTC (Sat) by Serge (guest, #84957) [Link]
> Um, startup is fast on low-latency connections, sure. Now try it over a higher-latency link.
That example doesn't add points to Wayland because in cases when you actually need that (rare cases, like running Oracle GUI installer on a server without a video card on board) you can still make it work faster under Xorg (vnc, xpra, etc.) but you can't make it work at all under Wayland, since you can't start Wayland compositor there.
> the worst I've ever encountered was over a dialup modem and took more than half an hour to map a window, though admittedly that was a program that took a couple of seconds to map its first window even on Ethernet
Still if it's slow for some programs but fast for others, then those programs are to blame, not Xorg, right?
In that particular case I would try selecting simple widget theme on a server side for that slow program, without nice gradients, cool round buttons or realistic shadows. :)
Bad NIH, good NIH Posted Mar 9, 2013 20:01 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
> but you can't make it work at all under Wayland, since you can't start Wayland compositor there.
Wayland works just fine with purely software rendering ( http://www.phoronix.com/scan.php?page=news_item&px=OD... ). I'm not sure this support hasn't bitrotted since then, but there are certainly no fundamental reasons why Wayland should require graphics hardware at all.
Bad NIH, good NIH Posted Mar 9, 2013 20:17 UTC (Sat) by Wol (guest, #4433) [Link]
aiui, the X protocol REQUIRES that the video display is copied between the client and the server SEVERAL times.
If both are on the same machine, no problem. It's easy (and has been done) to do the copy by passing a pointer. Quick and simple.
However, I REGULARLY run KDE as a client on my linux machine, with the X server on either a different linux box, or my Windows laptop. SLOW SLOW SLOW. Slower than a spaced out sloth.
Cheers,
Bad NIH, good NIH Posted Mar 10, 2013 10:42 UTC (Sun) by nix (subscriber, #2304) [Link]
No, it doesn't require copying the video display at all. It requires protocol roundtrips (request/response), though, before the window is even mapped: and if the client is badly written it can require a *lot* of them. And there are a lot of badly written clients, since all too many people don't bother to test their programs on remote X at all, brushing off bug reports from people like me with "don't do that then".
Bad NIH, good NIH Posted Mar 10, 2013 11:01 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
the many round trips at startup are largely to figure out what options are supported on the display side (since X has existed so long, may 'obvious' things, like color, are optional), and a substantial part of the speedup that approaches like nx provide is to short circuit these round trips.
This is very similar to what the 'wan accelerator' appliances do to the windows networking protocol to make it tolerable over high latency links (same problem, too many round trips)
While the fashion right now is for every app to render things as a complete bitmap, that's just a fashion of what is considered 'good' this year, that swings back and forth over time, in part depending on the available processing power at each end.
Bad NIH, good NIH Posted Mar 10, 2013 20:17 UTC (Sun) by raven667 (subscriber, #5198) [Link]
> While the fashion right now is for every app to render things as a complete bitmap, that's just a fashion of what is considered 'good' this year, that swings back and forth over time, in part depending on the available processing power at each end.
Think this statement is a gross mischaractization of the last 30+ years of graphics development with a history of hard won experience with apps, operating systems and hardware that can't be hand-waved away as mere "fashion". Where is the yearly "swing" in the evolution of serial terminals to framebuffers to fixed function accelerators to programmable GPUs, which has taken decades? If there is anything cyclic, computing has existed for too short a time to see it
The best you can say is that the approach of sending high level drawing commands across the wire like X or NeWS is what is being implemented with HTML5 applications using JS, DOM, CSS and WebGL
Bad NIH, good NIH Posted Mar 11, 2013 4:13 UTC (Mon) by Serge (guest, #84957) [Link]
> aiui, the X protocol REQUIRES that the video display is copied between the client and the server SEVERAL times. If both are on the same machine, no problem. It's easy (and has been done) to do the copy by passing a pointer. Quick and simple.
It does not. Quite the contrary it encourages you to pass your images to the server and manipulate them using "pointers". And of course Xorg has local display optimisations. It's up to the application what and how to draw. A lot of small unique images to pass over the network may slow down the whole process, as many modern themes do.
Simpler themes help. Drawing something like http://www.zimagez.com/zimage/2012-03-30--1333132280.php over network is much easier than something like http://4.bp.blogspot.com/-Ezze7Ar8OQ4/TaRaTjLLh5I/AAAAAAA...
> However, I REGULARLY run KDE as a client on my linux machine, with the X server on either a different linux box, or my Windows laptop. SLOW SLOW SLOW. Slower than a spaced out sloth.
It's slow compared to what? xpra/winswitch.org? NX? VNC? There're many options under X.
Bad NIH, good NIH Posted Mar 11, 2013 14:40 UTC (Mon) by nye (guest, #51576) [Link]
$time /bin/true
real 0m0.004s user 0m0.000s sys 0m0.004s
$time xterm -e /bin/true
$ssh <remote-machine>
$time /bin/true
$time xterm -e /bin/true
In this example, <remote-machine> is at the end of an ADSL connection, with an RTT of around 45ms - ie. about the best kind of connection that's widely available for the kind of money that individuals and small organisations can afford (and if you think a couple of grand a month for an internet connection is affordable, you're not thinking 'small organisation').
Bad NIH, good NIH Posted Mar 11, 2013 17:29 UTC (Mon) by sfeam (subscriber, #2841) [Link]
You (or xterm) are doing something very wrong.
Here's what I get using ssh to a remote machine over a bog-standard comcast consumer cable connection, followed by display of not just a terminal window but full graphics display plus round-trip response to a mouse click. Some toolkits are better than others at negotiating fast response over a remote connection, but all are funneled through x11.
$ssh <remote-machine>
$time gnuplot -e 'set term qt; plot x; pause mouse'
$time gnuplot -e 'set term wxt; plot x; pause mouse'
$time gnuplot -e 'set term x11; plot x; pause mouse'
and here's the time for display only (no wait for mouse click):
$time gnuplot -e 'set term x11; plot x'
That's not to say that response couldn't be improved, but your 37 second latency is horrible for some reason other than x11.
Bad NIH, good NIH Posted Mar 11, 2013 23:07 UTC (Mon) by nix (subscriber, #2304) [Link]
I bet his connection is dropping packets, so there's an extra delay caused by TCP timeouts in there.
Bad NIH, good NIH Posted Mar 12, 2013 12:50 UTC (Tue) by nye (guest, #51576) [Link]
>I bet his connection is dropping packets, so there's an extra delay caused by TCP timeouts in there.
Nope, but there is something interesting to see from the ping statistics while this is going on:
118 packets transmitted, 118 received, 0% packet loss, time 117123ms
(Obviously this also covers some time before and after.)
Curious as to why my ping time goes up to several hundred ms while xterm is launching, I've discovered that this local machine feels the need to send a few megabytes of data to the remote machine before doing anything.
In fact, it looks like xterm is the culprit here. I don't have many X clients installed on the machine I'm ssh'ing into to test with, but xfontsel at least starts up a lot quicker (a couple of seconds).
If even xterm can't get X network transparency right, what hope is there for everyone else?
Bad NIH, good NIH Posted Mar 14, 2013 5:48 UTC (Thu) by Serge (guest, #84957) [Link]
> You (or xterm) are doing something very wrong.
You can check that using x11trace tool. Most of the time is taken by sending fonts and other settings. That increases startup time, but makes it work faster, because it does not have to send images, it can reference fonts on the server side.
Xterm is smarter than most people think. It has configurable fonts, colors, hotkeys and many other options. For example to see xterm menu hold Control+Left/Right/Middle mouse button. But the point is that those settings are stored on a server-side (XResource), and xterm reads them all from server during startup.
Some DEs are using that. For example on KDE xterm colors should match your theme, does not matter what host you start xterm from. That's the server-side themes in action. Nobody remembers them any more... (sigh)
Bad NIH, good NIH Posted Mar 14, 2013 5:43 UTC (Thu) by Serge (guest, #84957) [Link]
> $time xterm -e /bin/true
> real 0m0.359s > user 0m0.032s > sys 0m0.036s
Wow. I couldn't get it that slow even on a slowest Intel Atom netbook I could find. Was that the worst test of many?
Anyway, your samples confirm that running application remotely is slower than running it locally. That was obvious even without testing. :) If you wanted to say that applications should start faster under Wayland than under Xorg, you should test something like:
$ time xterm
$ time weston-terminal
But even that test does not necessary mean that X is faster than Wayland. It just means, that xterm starts faster. Both times are good enough. And X11 is not a bottleneck for faster program startup time. If you actually need faster startup over network right away you can try winswitch.org/xpra.
PS: When benchmarking some soft do multiple tests and select the best result. Also don't forget to switch cpufreq governor to "performance" otherwise you're benchmarking your governor, not your soft.
Bad NIH, good NIH Posted Mar 14, 2013 11:24 UTC (Thu) by nye (guest, #51576) [Link]
>Wow. I couldn't get it that slow even on a slowest Intel Atom netbook I could find. Was that the worst test of many?
No, but many repeated runs do bring it down to 0.109s in the best case.
To be fair, I don't know if the video device and driver in use have any bearing on this, but just in case it does it's worth noting that I'm running on a laptop with Intel integrated graphics, where I have historically found the quality of both hardware and driver ranges from 'awful' to 'unspeakably awful'.
> If you wanted to say that applications should start faster under Wayland than under Xorg, you should test something like:
I just wanted to disagree with your claim that slow startup is not an issue, because it very frequently is when you are running remote X clients. It happens that the example you picked was one that demonstrated the difference particularly clearly.
Bad NIH, good NIH Posted Mar 15, 2013 9:01 UTC (Fri) by Serge (guest, #84957) [Link]
> No, but many repeated runs do bring it down to 0.109s in the best case. I think this is an example where the first case is the relevant one though, because that's what you'd experience in real use.
It depends on what do you want to benchmark. If you're just curious "how fast would it be next time I try" then yes. But if your goal is to compare two programs then you must reduce impact of all other obstacles, i.e. cpu throttles, disk cache, memory/swap, other programs running, etc.
> I just wanted to disagree with your claim that slow startup is not an issue, because it very frequently is when you are running remote X clients. It happens that the example you picked was one that demonstrated the difference particularly clearly.
I was just trying to say that "core protocol imposes restrictions that cannot be avoided (e.g. slow startup due to multiple roundtrips)" is not true. Slow startup is not X11 issue when running locally. Wayland only makes things worse. Applications would ofter start slower on Wayland because they're expected to talk to hardware, which requires additional steps for hardware initialization.
As for remote startup it's not that fast because of software, not because of protocol limitations. For example it could be much faster if xterm was sending requests in batch instead of waiting for response every time before sending another request. But people are lazy... They don't like optimizing things. But they like rewriting things from scratch somewhy. It's not a problem of X11 protocol, it's a human problem.
Bad NIH, good NIH Posted Mar 5, 2013 21:11 UTC (Tue) by man_ls (subscriber, #15091) [Link] It is a burden that you don't have to carry, so I have to wonder why the vitriol. Do you feel the same about systemd and journald, or are those justified?
Bad NIH, good NIH Posted Mar 5, 2013 21:20 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
For changes in low level components, it would be better if there is more buy-in upfront by talking to the distros and figuring out what is needed. For systemd, Lennart talked to the Scott (upstart) first and then with Kay (udev maintainer, who was then working for SUSE) and several others before even announcing the project. Yes, it is partly political but without that, you won't have much of a success.
It is clear that no external communication happened in this case. I think these changes do affect all of us because vendors like Valve have to deal with it and we might get less software developed for our platform of our preference because of it and it is not vitriol to express such concerns.
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 5, 2013 21:26 UTC (Tue) by raven667 (subscriber, #5198) [Link]
I didn't mean to imply any vitriol and while it's true that this doesn't directly affect me I would like to see Canonical succeed and I don't think this is the right path to do so. As far as systemd is concerned it is fixing a number of long standing design flaws and stagnation in low level system management and is well on its way to becoming the standard for Linux systems so I think it's a great example of a wheel that did need to be re-invented. I am more skeptical about the journal although, like systemd, it provides great compatibility with the existing order so it is still a net positive but I wonder if more could be done to add its way of doing things to rsyslogd instead. In any event the journal provides useful capabilities.
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 5, 2013 21:49 UTC (Tue) by man_ls (subscriber, #15091) [Link] With systemd Poettering et al are using dirty tactics to get it included in other distributions, including appeal to authority, constant accusations of foul play and even of forking existing projects (when Upstart was there first). I do not like that, at all. It is for these things that Red Hat gets badmouthed by many community members. So it is not a good example of Red Hat building useful low level components, even if they did talk to Upstart devs first (answering to the above post by rahulsundaram too). Talking to devs is not useful if there is no collaboration afterwards, and it may even look like an excuse.
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 5, 2013 22:12 UTC (Tue) by raven667 (subscriber, #5198) [Link]
> With systemd Poettering et al are using dirty tactics to get it included in other distributions, including appeal to authority, constant accusations of foul play and even of forking existing projects (when Upstart was there first).
I don't even need to add anything to that...
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 5, 2013 22:21 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
Wow. you are the one complaining about vitriol? Your entire post is a bunch of random accusations and one factual inaccurate claim of systemd being a fork. Systemd was written from scratch because it was a entirely different design from Upstart and talking to developers is very useful to determine whether you can enhance the project or come up with a new one. So no, it is not a excuse and it is always better to talk to people and do your research first even if you decide not to collaborate. If you really think systemd got adoption from Fedora, RHEL, SUSE, Mandriva, Mageia, Arch Linux, NixOS etc by appeal to authority and foul play, you must be living in an alternative universe.
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 5, 2013 22:24 UTC (Tue) by man_ls (subscriber, #15091) [Link] OK, you are right; I guess I was carried away. Also, systemd is the superior technical solution, no discussion about that. But the accusations are not nice anyway.
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 6, 2013 0:19 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
I don't think people here are accusing anything or anyone. We are just having a reasonable debate.
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 6, 2013 0:26 UTC (Wed) by man_ls (subscriber, #15091) [Link] Of course. I don't mean here, I mean the constant accusations from Poettering at Upstart developers.
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 6, 2013 0:32 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Lennart has criticized the design but praised the code in some comments and I haven't seen any accusations at all. Can you provide a reference?
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 6, 2013 0:41 UTC (Wed) by man_ls (subscriber, #15091) [Link] Sure, why not. For instance:Ubuntu has now become an island that is growing more or more apart from any other bigger commercial Linux. [...] Canonical contributes barely anything to the Linux plumbing layer, much the same way they stay away from the kernel. (Source). Ultimately, this move of Canonical will be one more step towards splitting up the ecosystem. (Source).For more, just google "Poettering Upstart" and have fun.
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 6, 2013 0:52 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
That isn't a criticism of upstart developers at all but Canonical and Scott left for Google anyway.
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 6, 2013 0:57 UTC (Wed) by man_ls (subscriber, #15091) [Link] I think that criticizing Upstart for causing a rift in the Linux ecosystem has to place at least some blame at the developers. Also there are other quotes I am too lazy to search for right now (and I don't think they would change your mind much). But whatever, make it "constant accusations from Poettering at Canonical".
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 6, 2013 1:11 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Yeah. Lennart doesn't like Canonical much. I don't think that has anything to do with the current discussion or the technical merits of a particular technology so I am not sure why you bought it up.
Thanks for making my argument Posted Mar 6, 2013 1:19 UTC (Wed) by man_ls (subscriber, #15091) [Link] Precisely. When a Red Hat employee starts badmouthing a competitor instead of focusing on the technical merits of a product, it smells like foul play. It tends to happen a lot lately -- see this article and the Google+ discussion you linked here.
Thanks for making my argument Posted Mar 6, 2013 1:43 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
I don't think it has anything to do with the companies they work for. These are passionate opinionated developers and they were absolutely right about the technical criticisms and Mir page got updated to reflect that.
Thanks for making my argument Posted Mar 6, 2013 1:50 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
To add on to that, let's look at company/project affiliations of people participating in that Google thread who are critical of Mir
Kristian Høgsberg - Intel
As you can see, it is a very broad group.
Thanks for making my argument Posted Mar 6, 2013 10:20 UTC (Wed) by man_ls (subscriber, #15091) [Link] So Poettering is only making valid technical criticisms on those pages? Or David Airlie? Random quote:they barely have anyone competent enough to write a display server, the fact that they are actually quite ignorant of how wayland works makes it even more apparent.Your intellectual dishonesty is staggering.
Thanks for making my argument Posted Mar 6, 2013 12:01 UTC (Wed) by ewan (subscriber, #5533) [Link]
"It is for these things that Red Hat gets badmouthed by many community members."
That was you, upthread. If this was about one company unfairly dissing a competitor, that would be one thing. When it's basically the entire community, across multiple different companies (many of which aren't direct Canonical competitors) versus one individual organisation doing something different, that's another.
Thanks for making my argument Posted Mar 6, 2013 13:14 UTC (Wed) by paulj (subscriber, #341) [Link]
Intel and RedHat have financial ties, don't they? (Former is an investor in the latter).
Thanks for making my argument Posted Mar 6, 2013 15:15 UTC (Wed) by raven667 (subscriber, #5198) [Link]
[sarcasm]
I'm sure David checked his stock portfolio, chuckled, and pet his shaved cat before posting that, it had nothing to do with how he actually feels... [/sarcasm]
These assumptions of corruption reflect more about how the writer sees the world and thinks in their own head than about the people who are the subject of their words.
Thanks for making my argument Posted Mar 6, 2013 15:51 UTC (Wed) by paulj (subscriber, #341) [Link]
Untrue, affiliations, including corporate alliances, can easily bias us and subconsciously at that. To scoff at that is to deny provable human nature.
Thanks for making my argument Posted Mar 6, 2013 16:04 UTC (Wed) by paulj (subscriber, #341) [Link]
Oh, and if some free software programmer's view of something *were* biased because, e.g. that something was the product of a competitor of their employer or their employer's corporate allies, that does NOT make them a bad person. Indeed, I would *expect* a person to be biased toward acting in the interests of their employer - that would make them a *good employee*.
Such biases do exist, at various levels of consciousness. That is not to condemn them. However, we should be aware of them, and take care to note affiliations.
Thanks for making my argument Posted Mar 6, 2013 16:16 UTC (Wed) by raven667 (subscriber, #5198) [Link]
While at some level what you say is true I'm not sure it applies strongly in this case. Linux developers come from a wide range of companies and while they may be directed to work on a particular part of the system which is strategically important to their employer, they generally show more loyalty to Linux itself than to whichever company is currently paying them.
As far as I can tell, dissing Canonical provides no tactical or strategic benefit to any particular vendor who is involved in this discussion
Thanks for making my argument Posted Mar 6, 2013 16:28 UTC (Wed) by paulj (subscriber, #341) [Link]
Perhaps in this case, not strongly, sure.
However, there's been a number of times over the last few years where from several rouge capped free software people have snipped at Canonical, with a common theme that Canonical is somehow free-riding. The sub-text seems to be that Canonical gets more of the user-base with Ubuntu and recognition than their share of the work deserves. Guess who employees a lot of the people doing the work?
To think there is absolutely no element of corporate competition to this story seems, I'm sorry, a little naïve. Both in terms of Canonical choosing not to hitch their wagon to Wayland, and in the (predominantly) RedHat and Intel employees' reactions to that. There are pure, technical elements too, of course...
Thanks for making my argument Posted Mar 6, 2013 19:34 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> There are pure, technical elements too, of course...
Like what? So far, every technical reason named by Canonical either has been disproven or is phrased too vaguely to ever be.
Thanks for making my argument Posted Mar 6, 2013 15:56 UTC (Wed) by man_ls (subscriber, #15091) [Link] [counter-sarcasm]Your naïveness would be somewhat refreshing, I have to admit, were it not so biased at heart. Reinforced prejudices are very dangerous.
Thanks for making my argument Posted Mar 6, 2013 16:11 UTC (Wed) by raven667 (subscriber, #5198) [Link]
You are just so adorable! 8-)
In any event pointing out the clear lack of familiarity with the technologies they are (not) using is not pre-judice, it's post-judice. I don't think it's unfair to also say that they have not demonstrated technical leadership very often in the underlying infrastructure technologies they depend on, bzr and upstart being two examples. They need not just the cojones but the talent to pull this all off.
I should also point out that I wish nothing but the best for Ubuntu, which is why I'm talking about this in the first place, if I didn't care I wouldn't comment.
Thanks for making my argument Posted Mar 6, 2013 20:38 UTC (Wed) by airlied (subscriber, #9104) [Link]
Yes Paul,
Intel told Red Hat to tell me to say this. Thats exactly how it went down.
Thanks for making my argument Posted Mar 6, 2013 20:48 UTC (Wed) by paulj (subscriber, #341) [Link]
And that's not in any way what I was suggesting Dave.
Thanks for making my argument Posted Mar 6, 2013 16:33 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
I am sorry but you seem to be obsessed with Lennart for some reason. It is rather disturbing. My list of people did not include Lennart but developers across the community who have expertise in the Xorg/Mesa/Wayland stack and yes, David's statement was accurate and Canonical has subsequently revised the Mir page to retract their criticism against Wayland.
"Intellectual dishonesty" is just a weasel word for lying and if you want to accuse me of that because I disagree with you that this is somehow a Red Hat specific thing when I have clearly shown you otherwise (yet another criticism from KWin developer - http://www.reddit.com/r/LinuxActionShow/comments/19qcix/k...), then I don't think you get to advocate against vitriol or badmouthing. If you have a counter point, please express is politely.
Thanks for making my argument Posted Mar 6, 2013 17:12 UTC (Wed) by man_ls (subscriber, #15091) [Link] It is true that your list did not include Poettering, but why? He is clearly badmouthing Mir (comparing to some engineering disasters, not very ingeniously as it happens), he offers no valid technical points, he is a Red Hat employee. I am not obsessed with him, but I think he employs dirty tactics in his fight for systemd and against Upstart. You have still not refuted this point other than substracted this particular person from the argument, for some reason. That is intellectually dishonest IMHO.Let us leave him aside; another Red Hat employee (David Airlie) also badmouthed Canonical without offering any valid technical points, as quoted above (saying they don't have competent technical people). Other people expressed their opinions, in a mostly polite form, and with valid technical reasons; Airlie only made baseless accusations (such as lamenting the lack of source code, which was not true) and silly jabs (Jumping Sharks). That is just one random Google+ thread, there are many other examples that I have linked above. I am not in the mood to curate any more examples for you.
Thanks for making my argument Posted Mar 6, 2013 17:44 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
I have already refuted this point already by telling you two things
1) Lennart's dislike for Canonical is not based on his organizational affiliation. It has a much longer history.
2) it has nothing to do with the current discussion
David's points were already shown to be true. You are however just engaging in the same tactics you seem to be critical of.
Thanks for making my argument Posted Mar 6, 2013 17:50 UTC (Wed) by man_ls (subscriber, #15091) [Link] I knew this was not worth my time. Anyway, just a clarification: being intellectually dishonest is not the same as being a liar, it is rather to be a self-liar. You choose to see the reality in your own terms and disregard what doesn't fit. Is it intentional or not? I don't know and frankly I am not interested.Now you will no doubt accuse me of the same, and so on. Bah.
Thanks for making my argument Posted Mar 6, 2013 17:58 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
So "intellectual dishonesty" is your fancy way of saying, you disagree with me! and of course I do. If you see this thread, the only real badmouthing is from you.
Thanks for making my argument Posted Mar 6, 2013 20:58 UTC (Wed) by airlied (subscriber, #9104) [Link]
You have to realise I can be a bit of a dick sometimes.
http://airlied.livejournal.com/76828.html
I summed up my thoughts at the time here, in the end C removed the lies, but I'll still bet we'll see them repeated by fanbois across the Internet for years, and developer time will have to be spent correcting them.
I'll update the blog post to mention that they have removed the original source of the technical untruths.
The thing is if you think this is was a purely technical decision at Canonical's end you are already sucked into their event horizon, sometimes you have to realise technical isn't the game that you are being played in and address it as such.
Thanks for making my argument Posted Mar 6, 2013 21:32 UTC (Wed) by man_ls (subscriber, #15091) [Link] Of course I don't think it's a purely technical decision from Canonical. Also, I don't necessarily think it is a good decision, either for them or for Linux as a whole. But I do think that many good things can come out of it: new ideas, new code, encouragement for Wayland devs to finish their job.As to the downside, there may be bad consequences, but I don't see how we may end up with three (or four!) different, incompatible display servers. Either they will be compatible somehow or only one will survive. Hey, even GNOME and KDE have agreed to a lot of standards, making our life easier.
Thanks for making my argument Posted Mar 6, 2013 23:36 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> But I do think that many good things can come out of it: new ideas, new code, encouragement for Wayland devs to finish their job.
Name one reason why new ideas and code can't be created by extending Wayland.
> As to the downside, there may be bad consequences, but I don't see how we may end up with three (or four!) different, incompatible display servers. Either they will be compatible somehow or only one will survive. Hey, even GNOME and KDE have agreed to a lot of standards, making our life easier.
Thanks for making my argument Posted Mar 6, 2013 20:51 UTC (Wed) by airlied (subscriber, #9104) [Link]
how could I make technical criticism of a project that didn't exist in public before yesterday, and is only a few thousand lines of badly written C++?
Here's the thing, Canonical came out of the gate and bashed wayland. I'm not wayland's biggest supporter, but I don't like when companies uses lies and fanboi bases to make their arguments, to me it usually means they are hiding something.
As I've pointed out on my blog they are hiding something or they are technically incompetent. If they are hiding something, its most likely a control problem. If they really misunderstood how wayland worked and believed in what they posted, then its a competency problem, and I'd rather not base the future of Linux compositing on work done by people too incompetent to read and understand the few thousand lines of code that is wayland.
The other thing is Red Hat (as a corporation) doesn't even see this stuff, they do pay me to see this stuff, but they don't direct how I respond and I don't speak on their behalf. My job is to do what I think is best for Linux graphics in the long term, like seriously that is actually what they pay me for, and if I think pointing out flaws in Canonical's arguments for NIHing things is best for Linux then I'll go ahead and do it!
Thanks for making my argument Posted Mar 6, 2013 21:25 UTC (Wed) by man_ls (subscriber, #15091) [Link] Let me wear my sophist hat for a minute. Where to start.If you cannot make technical criticism, why do any criticism at all? After all you started with your criticism before even knowing there was a public repo, making a blunder in the process ("I remember when open source project announcements used to come with source"). Once you found the missing repo, why not take your time and make criticism of the few thousand lines of code? If Wayland is also a few thousand lines of code, is it enough to define it or not? Apparently a few thousand lines of code is not enough for you to understand, since you cannot make technical criticism; but it should be enough for Canonical engineers to not only make technical points (which after all can be superficial), but to completely understand it. And apparently not taking the time to understand another project in depth before criticizing it is equivalent to not being competent. Or perhaps a few thousand lines of code are not sufficient to evaluate and understand a complex project. As I've pointed out on my blog they are hiding something or they are technically incompetent.Maybe they are hiding something; after all they work for a company as you do and it has its agenda, just as yours. But that is a false dichotomy; maybe they just need something that moves faster and believe they can pull it. Or maybe Shuttleworth as a kid promised himself he would one day build a replacement for X; use your imagination instead of accusing others of incompetence. It will be more interesting. The other thing is Red Hat (as a corporation) doesn't even see this stuff, they do pay me to see this stuff, but they don't direct how I respond and I don't speak on their behalf. My job is to do what I think is best for Linux graphics in the long term, like seriously that is actually what they pay me for, and if I think pointing out flaws in Canonical's arguments for NIHing things is best for Linux then I'll go ahead and do it!Read what you wrote carefully. First you say that you don't speak on Red Hat's behalf, but then you go on to say that they pay you to speak your mind if you think something is wrong. Amazing. Red Hat as a corporation sees this stuff, since you are part of that corporation and are paid to see it. As others have said, you would not be a good employee if you had not interiorized some business principles, such as avoiding projects not under the direct control of your corporation. Sometimes the goals of that corporation will align with the interests of Linux, sometimes it will not (like not publishing a git repo for the kernel). You think Mir is a not good idea; fine. You might also say "Let us wait and see what they come out with; there may be good ideas that we can adapt, and it is Free software after all" or "They have come with good stuff in the past that has served Red Hat well, like Upstart", but hey. However, you are not only pointing out flaws in Canonical's arguments; you are actively despising them in public ("They should call the next Ubuntu Jumping Sharks"). It points to some kind of internal hostility towards Canonical, which somehow cannot surprise anyone at this point.
Thanks for making my argument Posted Mar 7, 2013 0:05 UTC (Thu) by airlied (subscriber, #9104) [Link]
Because technical criticism isn't the be all and end all, as much as people would like to believe. You should always question people and companies motives, you seem to be happy to question my motives, but can't apply that to Mir/Canonical?
If they aren't hiding something, and we can believe they believe they have the technical competence to design a replacement for wayland/X then you'd expect them to have the technical competence to understand wayland/X? Its generally considered a good idea to understand the thing you are trying to displace. Now if you write a page of falsehoods on the things you are trying to displace, you are either acting from malice, deliberately lying, or stupidity, lying through lack of knowledge. As I said on my blog posting, neither of these reasonings are the things I want to see from the group designing the next generation of display server.
What part of, I do not speak for Red Hat, makes no sense to you. Just because someone gives me a pay cheque it doesn't translate me into a mouthpiece for them. I know its probably hard to understand for people who've never worked in an environment like Red Hat. I have a position in the Linux community and I make statements that I feel like making, if something pisses me off, I say this pisses me off, and try to analyse why! so what if I don't like Canonical, their methods of open source development are anti-community and the direct opposite of how every open source project I've worked on has worked. So maybe I make petty one liner statements, shoot me, its the Internet.
Thanks for making my argument Posted Mar 7, 2013 0:20 UTC (Thu) by man_ls (subscriber, #15091) [Link] Great, so you dislike Canonical and badmouth them in public. That is exactly what I was trying to establish (and something that other commenters obtusely refuse to see). It is your choice, but expect no sympathy for your cause from those grateful for Ubuntu.Do you apply the same criteria always? Because I am eagerly awaiting your criticisms of Google Android, Tizen and the GNU project, just to name three prominent examples that are run more or less behind closed doors. (GNU is more open but still requires contributors agreement; the others are worse because AFAIK they don't even accept external contributions.) Me, I am grateful for what I get, and contribute back what little I can.
Thanks for making my argument Posted Mar 7, 2013 0:34 UTC (Thu) by airlied (subscriber, #9104) [Link]
Android never posted a criticism of a project I cared about, they did their own thing, I don't like how they do it, but I feel no need to comment on something that exists in its own universe. If they attempted to bring that universe into collision with mine, then yes I would be vocal about it.
If you believe signing the GNU contributors agreement equates to the Canonical contributor agreement, I have no further time for you, because frankly I expect to discuss things with people intelligent enough to interpret the agreements they sign and who they assign copyrights to.
Thanks for making my argument Posted Mar 7, 2013 0:47 UTC (Thu) by man_ls (subscriber, #15091) [Link] I find strange that doings things behind closed doors would be more palatable (or at least less deserving of your ire) than posting public documents. But everyone is entitled to their own contradictions, aren't we?As to the GNU project, I think they do a great and necessary job, but their contributor agreement (reasonable as it is) and their development policies (cathedralicious according to some) have been criticized before. They are certainly less agile than they might be, and probably unlike every other project where you have worked before. Hence the comparison.
Thanks for making my argument Posted Mar 7, 2013 1:35 UTC (Thu) by airlied (subscriber, #9104) [Link]
Android development model gets lots of criticism from lots of people, in the embedded space and everywhere else. Look at the kernel merge fun ongoing for years.
I have given out about Android and their encouragement of closed source graphics stacks before, and I do quite often at conferences and anywhere else. I've bitched about HW designs like the raspberry pi and I believe the FSF encouragement of such designs is totally anti their real mission.
Again you say the GNU project, but really its not one big monolith, you seem to be unable to distinguish individual pieces moving in their own directions, GNU projects are not beholden to some GNU development overlord.
some of them are more agile than others, the GNU project is an umbrella framework. Contributors to GNU projects again come from many companies and all believe that GNU is a good steward of the copyrights. (even if they don't use it enough to beat GPL violators with).
The thing is I don't believe Canonical is a good steward for my copyrights or anyone elses, and I think contributing code as an equal to their projects is very difficult. I've gone from 0 to being an integral part of 3 major projects *before* I joined Red Hat, and have never felt my company affiliation mattered in any of them, and was never asked to assign copyrights in any of them. Why would I want to give Canonical rights to take my code proprietary when they don't give me the same right? If you want the right to take code proprietary license it under MIT, and give the same right to other contributors (ala the Mesa 3D stack and X.org), if you don't want it use a GPL variant like the kernel. I also disliked Qt for doing the same for years, and MySQL also ran like that. It discourages individuals and other companies from making any decent contributions to your codebase, so in general you lose a major benefit of being open-source in the first place.
Its generally okay to give copyrights to a foundation that is setup correctly, but to individual companies, my personal believe is it doesn't end well.
Thanks for making my argument Posted Mar 8, 2013 14:29 UTC (Fri) by nix (subscriber, #2304) [Link]
Sheesh. The GNU project was cathedralicious *sixteen years ago*. It's not any more.
Not a cathedral, not a bazaar Posted Mar 8, 2013 15:05 UTC (Fri) by man_ls (subscriber, #15091) [Link] You are right (and I should know since I have been a voluntary Savannah admin for a few years). When handling code it is still not as agile as other environments, but it is certainly not centralized. The decision process however remains largely in the hands of a couple of people, and there have been some complaints about it recently.Let us see a practical example: inclusion in the project.The GNU project says about it: Based on the evaluators' report, Richard Stallman (the Chief GNUisance) makes the final decision on whether to accept the contribution. [...] Thus, becoming a GNU maintainer is a somewhat formal process, since affiliating with the GNU project as a maintainer means you must agree to work (within the confines of the maintenance) with the GNU project's mission for software freedom.Contrast with inclusion in other software collections:
Thanks for making my argument Posted Mar 7, 2013 4:05 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
"That is exactly what I was trying to establish (and something that other commenters obtusely refuse to see)."
Actually, no. What I refused to accept is that they are criticizing a project because of company affiliation. You are entirely wrong about.
Thanks for making my argument Posted Mar 7, 2013 11:54 UTC (Thu) by paulj (subscriber, #341) [Link]
No one is accusing you of being a mouth-piece.
However, there is clear evidence that even well-intentioned, professional people tend to be affected by their affiliations. They tend to have biases toward arguing or acting in favour of the interests of their affiliations. This can happen subconsciously, even against the logical desires of the person. It's well documented in other fields, medical research particularly, and there are various psychological experiments you can do to demonstrate what is thought to be the underlying behaviour involved.
No matter how logical and dispassionate we try to be, our wetware just appears naturally to have a predilection for biasing us towards groups we are members of. There is no good reason to think software people would be immune to this.
Rather than deny this general fact, the best thing to do is to acknowledge it, so we then can find ways to minimise it or work-around it.
Thanks for making my argument Posted Mar 7, 2013 12:23 UTC (Thu) by paulj (subscriber, #341) [Link]
Oh, and these effects occur even with full information. In the real-world, an obvious/frequent source of affiliation bias, is of having more complete or better information about your affiliations than of others.
Or as other commentators put it, communication issues. :)
Thanks for making my argument Posted Mar 7, 2013 12:30 UTC (Thu) by HelloWorld (guest, #56129) [Link]
It's rather hard to be informed about what Canonical is doing when they do it behind closed doors. And that's actually what all this is about: the fact that Canonical utterly misses the point in Open Source Software: collaboration instead of competition.
Sources of bias Posted Mar 7, 2013 12:41 UTC (Thu) by man_ls (subscriber, #15091) [Link] In-group bias is another well-researched source of bias, that probably can be traced back all the way to primate groups. This is important not because it is more primitive, on the contrary: it is much more subconscious and entrenched than other, more cultural (you could say "human") biases. We want our group / tribe / company to thrive not because we will be better off, but because we are the best.
Sources of bias Posted Mar 7, 2013 12:49 UTC (Thu) by paulj (subscriber, #341) [Link]
Yeah, I must have put it clumsily. My point was that lack of information is one obvious source of bias. But even when we have full information, we *still* have a definite tendency to be biased toward group members - even if subconsciously, as per your link.
Thanks for making my argument Posted Mar 8, 2013 14:27 UTC (Fri) by nix (subscriber, #2304) [Link] However, you are not only pointing out flaws in Canonical's arguments; you are actively despising them in public ("They should call the next Ubuntu Jumping Sharks"). It points to some kind of internal hostility towards CanonicalActually it's called a sense of humour. You might want to look that up, since it seems you were sadly deprived of one.
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 5, 2013 23:15 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> With systemd Poettering et al are using dirty tactics to get it included in other distributions,
Writing better software isn't a dirty tactic.
> when Upstart was there first
Bad NIH, good NIH (digression to Poettering, new Godwin's Law?) Posted Mar 6, 2013 0:21 UTC (Wed) by ringerc (subscriber, #3071) [Link]
Being there first means very little if you have a design that doesn't fit everyone's needs and isn't easily adapted to fit those needs.
The BSD kernel was there first. Does that mean Linus shouldn't have started the Linux kernel (even just for fun)? Sure, there were legal controversies around BSD, but that can be written off as "political reasons" the same way people are writing off licensing, ownership and policy issues with new stack components.
I don't understand why people take such a strong emotional angle on this. Extend, fork or rewrite, they're all different ways to develop software that fits your needs. Sometimes one approach is the right one, sometimes another is. None are morally wrong or always right.
A bit lopsided Posted Mar 5, 2013 2:32 UTC (Tue) by tetley80 (guest, #88691) [Link]
Except that they got the "mistakes" factually wrong, as evidenced by the discussion going on here. This strongly indicates Canonical didn't bother engaging with Wayland developers, even on a rudimentary level. It also indicates they didn't bother reading Wayland's specs. Seriously, how hard is it to ask on the Wayland mailing list, "Hey, we're thinking of adopting Wayland, but we have concerns about area XYZ. Can you shed some light on this?" Or even this would have been better-than-nothing: "Hey, we're doing our own display server, and have run into issue XYZ. How did you solve it in Wayland?" Instead, Canonical hasn't learned from other people's mistakes and is going to put a smaller engineering team (than Wayland et al) on their own display server. As Wayland folks (and X11 folks before them) know, making a display server is not a small task. So a few pertinent questions to Canonical and Mark Shuttleworth are: (1) What substantial value does your own Mir display server provide that's beyond what Wayland does? (2) Wouldn't it be more cost effective to send patches to Wayland developers? (3) Is keeping the development in-house worth the sacrifice of not leveraging the efforts of other organisations and developers? (4) How does fragmenting the ecosystem/software stack help Ubuntu and Canonical?
A bit lopsided Posted Mar 5, 2013 13:41 UTC (Tue) by deepfire (subscriber, #26138) [Link]
I'll reiterate the question voiced above -- why didn't Wayland people adopt SurfaceFlinger?
A bit lopsided Posted Mar 5, 2013 15:10 UTC (Tue) by tetley80 (guest, #88691) [Link]
That's a good point. To be honest, I'm not that familiar with SurfaceFlinger. To (partly) answer your question: two wrongs don't make a right. Perhaps Canonical/Ubuntu should adopt and extend SurfaceFlinger instead of rolling their own display server? On a related note, I'm starting to think that the most effective method to make Linux more relevant in the desktop space (and at the same time get a relatively sane OS stack: kernel, graphics, sound, input, UI) is to make Android self-hosting.
A bit lopsided Posted Mar 6, 2013 1:14 UTC (Wed) by robclark (subscriber, #74945) [Link]
because it didn't exist at the time. And is less complete than wayland.. maybe the question should be "why didn't surface flinger people adopt wayland" :-P
A bit lopsided Posted Mar 6, 2013 4:04 UTC (Wed) by swetland (subscriber, #63414) [Link]
Was Wayland around in 2006 when we wrote SurfaceFlinger?
Other discussion in this thread seems to imply Wayland only recently declared the protocol stable. Is this another "Android should abandon <thing they built that works today> in favor of <thing that's not done yet that's clearly going to be better because!>" discussion?
A bit lopsided Posted Mar 6, 2013 4:15 UTC (Wed) by hummassa (subscriber, #307) [Link]
two words: bluetooth stack.
why oh why? those days (4.2.2), two out of five times I have to restart BT on my Nexus when I enter my car, just "because!"
A bit lopsided Posted Mar 6, 2013 12:35 UTC (Wed) by nye (guest, #51576) [Link]
Your comment prompted me to try my BT keyboard that stopped working with 4.2 - it works again! Yay! And the mouse no longer seems to need a dance of turning off and on and re-pairing and praying to Eris and sacrificing a chicken.
A bit lopsided Posted Mar 8, 2013 19:12 UTC (Fri) by hummassa (subscriber, #307) [Link]
My car stereo still acts out 20% of the time.
A bit lopsided Posted Mar 6, 2013 4:39 UTC (Wed) by robclark (subscriber, #74945) [Link]
ok, then SF slightly predates wayland.. I couldn't find (and maybe I didn't look hard enough) any evidence of SF prior to 2008. My bad.
Anyways, certainly in the early days, SF wasn't in good shape for hotplug, multiple displays, vblank support, and these sorts of things that matter on desktop.
Anyways, re: protocol stability, I somehow doubt you could claim that SF is backwards compatible to SF from 2006. The protocol stability milestone should have mattered very little to something that is distributed and updated in the manner that android is.
And re: abandoning SF and going to wayland.. well, android has made equally big changes in it's plumbing from release to release. So it doesn't seem too big a stretch of the imagination.
A bit lopsided Posted Mar 6, 2013 7:03 UTC (Wed) by swetland (subscriber, #63414) [Link]
I wasn't pointing to protocol stability as a SF feature, just as a "it sounded like Wayland was only recently declared 'done'", but I haven't followed Wayland development very closely, so it's possibly I completely misunderstood things here.
First public exposure to SurfaceFlinger would be Fall 2007 (SDK preview release and emulator) and first code drop would be Fall 2008 (Android 1.0 and G1 launch), but it's certainly something that was there from the very early days of the platform -- possibly late 2005, but certainly early 2006.
The hwcomposer HAL actually aims for some level for forward/backward binary compatibility (to ease development and upgrades), and while it doesn't reach back to the early days of SF (which has definitely evolved over the years), I just this week have been writing some test code for the HWC HAL that happily runs on a variety of devices from different OEMs and with different versions of the platform.
I'd be pretty doubtful about us shifting away from SF (especially now that hwcomposer and sync support is looking pretty solid), but we certainly are willing to pull things up and rebuild if necessary -- though the other commenter with his bluetooth complaint may be actually arguing *against* that, I guess.
From the other direction, though, unlike the earlier (now abandoned, I gather) work to stack Wayland on top of Android underpinnings, the hwcomposer HAL provides a much more flexible and richer surface than the old fb HAL, which certainly should be useful to the Canonical folks with their Mir compositor, as well as to anyone wanting to revisit a Wayland-on-Android world, though in both cases I'd assume the goal would be to get access to a wide variety of hardware ready to run "out of the box" rather than to actually use much of Android.
|
|||||||||||||
