I like how the free software community is very loose. Lots of jokes in the documentation. Python and Norwegian Blue parrots, for example. But naming your distro Rebecca Black Linux, might undermine credibility just a tiny bit. (But obviously you aren't hurting anyone, so: nice job on the wayland live cd!)
For a technology preview project the name is fine, albeit not googleable. I don't think that a project like this has to choose a name people can sell to the management.
From my own experience, really chose something that is googleable. It's frustrating when you never have a change to be found when people type your project's name into google because it's an artist's name or a common word. And yes, i think finding a good name for a project is hard.
Not copyright, but possibly trademarked. Even in that case, it only applies to use in areas in which the mark is already being used. So while it would be trademark infringement to sell albums under that name, releasing an OS would be fine unless someone else is also planning on doing the same thing and applied for a trademark in that area.
It's interesting to see how Canonical's announcement of Mir seemed to spur new interest around Wayland and an acceleration of its development, generating a new wave of announcements (i.e.: Gnome deciding to go "all wayland" by 3.12, etc).
That sure seems to have been a kick in the pants. More specifically, it spurred interest in using the Android HAL in the underpinnings of a Weston compositor.
Having gotten that kick in the pants, I hope they can all just get along and resolve resource and schedule issues between two projects that look functionally identical now.
It initially sounded like a convenient way to quickly try out Wayland, but there must be a lot of unnecessary software included with it, thus making it quite inconvenient to try out.
I do have lots of dev packages and lots of Wayland related software is installed, like the Wayland version of mplayer and gstreamer, and GTK, and Qt and SDL.
Lots of people are asking about the 1.7GB, so I brought back my smaller ISO in my buildscript for the next version, which attempts to remove all dev packages and some other stuff:
Download with DownThemAll, it's a great Firefox download manager extension. It supports multiple pieces, multiple mirrors and resuming, taking all the trouble out of downloading big files over http.
Display <- X server <- Compositor/WM <- X server <- Your app
Where compositor/WM and your app are X clients, i.e. there's lots of context switches between clients and the server.
I personally don't see much wrong with this design BTW, despite the context switches X is pretty smooth even on some pretty wimpy hardware (eg. Raspberry pi, or Nokia N900, or the wimpy Pentiums I ran X on 15 years ago).
> No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.
To support remote rendering you need to define a rendering API
See, this makes no sense to me. The truth of this statement holds if I substitute s/remote/local/.
The fact is, Wayland manages a shared resource via a well-known API. This is the very definition of client/server architecture. There's no additional technical hurdle to be crossed to support network transparency.
Yes, but the resources it passes around are handles to buffers in memory (as little copying as possible). Not so trivial to pass around the network (well, most networks). I suspect a VNC-like approach would work easiest and most generally, but performance would suffer (though I've found situations where VNC beats remote X11, even over very low latency connections).
My understanding of OpenGL (which could be wrong) is that buffers are only transferred when loading textures onto the graphics card, which generally only happens at startup, and is time-consuming anyway (since they must find their way from disk to graphics memory).
So memory buffer handles can still be passed around, since clients rarely touch the raw data. (Indeed, this is exactly how X11 works.)
You can send OpenGL over the network, but I suspect sending the rendered window contents will use less bandwidth. So that's what Wayland is going to do.
That's one of the first questions asked in every discussion about Wayland :) The answer is basically no, it's out of scope. That said, remoting might be added to one or more Wayland compositors in the future. http://wayland.freedesktop.org/faq.html#heading_toc_j_8
