Slashdot Mirror
Gnome 3.12 Delayed To Sync With Wayland Release
sfcrazy writes "Gnome developers are planning to delay the release of Gnome 3.12 by approximately a week. It's a deliberate delay to sync the release with the availability of Wayland 1.5. Matthias Clasen (Fedora and Gnome developer) explains that 'the GNOME release team is pondering moving the date for 3.12.0 out by approximately a week, to align the schedule with the Wayland release plans (a 1.4.91 release including all the xdg-shell API we need is planned for April 1). The latter 3.11.x milestones would be shifted as well, to avoid lengthening the freeze period unnecessarily.'"
This talk is insightful: https://www.youtube.com/watch?...
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Say, forever? MATE with Xorg is much more suitable than either Gnome or Wayland.
Ummm, even MATE is planning on switching to Wayland, so evidently the developers of MATE would disagree with you.
In my opinion...
Wayland + Systemd + Gnome 3 + kernelspace Dbus = transforming Linux into Windows. Or something more like Windows. They represent a complete rejection of the foundational Unix philosophy.
Regarding Wayland: You clearly have no idea how X works today. Todays X is not like Unix should be at all.
Regarding Dbus: How is a dbus protocol different from semaphores and shm in the kernel?
Regarding systemd, I agree and see it critically, because it is tries to solve everything at the same time. Perhaps the direction of OpenRC is more appropriate. But to criticise systemd you have to understand the issues: A number of links are on http://freedesktop.org/wiki/So... including http://0pointer.de/blog/projec...
Regarding Gnome3: Gnome3 is conceptionally little different than Gnome2, KDE or XFCE: Windows and pointers. I actually really like it. If you don't exchange it for something else. Very Unixy.
We have to keep in mind that the system we have today are not mainframes that are booted once and have their daemons running for months.
We have plug-and-play of devices and screens, hibernation, multiple input devices, while at the same time the screen output must not flicker or have delays beyond 50ms. It's a different arena today.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
X is an application that runs on a computer with a graphics card. A graphical application can then use the X libraries to send drawing commands over the network to an X server, eg "draw a line", "draw a box", "display this bitmap", "display this string in font zzz". Note that the concept of "client" and "server" are somewhat reversed from the normal meaning - the X "server" runs on your desktop, the client can run somewhere in a datacenter. Think about apps processing major datasets and then generating some output...makes sense then for the "client" to be on the larger computer.
The X "server" also controls keyboard/mouse/etc, sending events to the relevant client apps.
The problem with X is that the whole design no longer matches what client apps want to do - eg interact with 3d-capable GPUs, use exactly the fonts they want (rather than asking the X server to use the font with a specific name, and hoping the server has that font available). And the network layer inbetween adds latency. And the set of commands that X supports is now so large that the server is huge - making it buggy, full of security holes, and difficult to maintain.
Wayland is basically the lowest-level parts of X (handling the graphics card), plus a very simple API for clients - it accepts bitmaps only, no "draw a line" stuff. And no network support - clients are local only. Client apps can then code directly against the Wayland APIs (ie pass it bitmaps, often generated by interacting directly with a GPU to render 3d graphics into a buffer). Fast, simple. Or clients can code against the original X API, in which case the drawing commands are sent across the network as they always were, and then are handled by a slimmed-down X-server which executes the commands and passes the resulting buffer to the local wayland server.
In practice of course, most apps will code to the GTK or QT apis, and it is GTK/QT which is responsible for interacting with Wayland or X.
There is also code in development to create a "wayland network protocol" where clients can generate images (on whatever computer they are running on - which might have a GPU), and then send the (compressed) image over the network to another wayland server where the user actually sits and sees the graphics. This is a kind of "RDP remote desktop" mode - and according to many people will actually out-perform the old X way of doing things, as well as being vastly simpler to implement/maintain.
X11 doesn't even do anything anymore. Go watch one of the many presentations made by the many developers who have been working on X11 for over 20 years. They're not even sure what X11 does anymore, nearly everything bypasses it and just pushes around buffers, which X11 does not handle well at all.
The one thing that stood out is they said X11 can not implement vsync at all without breaking all compatibility. They are embarrassed that code is still being used in 2014 that does not handle vsync and gives "screen tearing", which other systems have had fixed since the mid 90s.
99% of the current use cases for X11 are now managing buffers and X11 does not manage buffers. Wayland is designed to handle the most common use case in a good way.
That team of wayland developers happens to be largely the same team who used to work on X, and wayland is endorsed by the X.org foundation. I've no technical opinion of wayland, but it's easy to see that X.org and the developers of X are in a better position to evaluate the need for it than you are.
This space intentionally left blank