Slashdot Mirror

I read the mailing list thread as well as the bugzilla report...Kay certainly was certainly being a complete dick here. Too many people will see this as "an asshole being an asshole" w/respect to Linus, but he actually had a reason [this time, lol].

Here is the actual bug and arguement: https://bugs.freedesktop.org/s...

From the previous message in the thread, to which Linus was reacting:

It has come to our attention that a system running a specific user
space init program will not boot if you add "debug" to the kernel
command line. What happens is that the user space tool parses the
kernel command line, and if it sees "debug" it will spit out so much
information that the system fails to boot. This basically renders the
"debug" option for the kernel useless.

This bug has been reported to the developers of said tool
here:

https://bugs.freedesktop.org/s...

The response is:

"Generic terms are generic, not the first user owns them."

That is, the "debug" statement on the *kernel* command line is not
owned by the kernel just because it was the first user of it, and
they refuse to fix their bug.

I don't care if Kay wrote "Jesus 2.0". He broke kernel debugging for all development and responded to this with arrogant platitudes based on architecture principle, rather than join with cooperative interest to seek a solution.

Linus was restrained, in response to such a "community contributor". This is the Linux kernel, not Oxford dons, vying for college chairs.

Goddamn that was painful, but I found the actual patch:

http://cgit.freedesktop.org/xo...

I would say it is rather shocking that this Peter Hutterer actually did about 90% of the work, then posted something that is not a clue as to how to see the answer.

And that the original poster (who I assume made this Slashdot story) did not post any followup for 3 months, probably leading Peter to forget all about fixing this.

XWayland is the X server for Wayland, so that you can run traditional X applications on Wayland (as opposed to Qt etc. applications, which will talk directly to Wayland). http://wayland.freedesktop.org...

If I'm not mistaken the Direct Rendering Manager is 8 years older: http://dri.freedesktop.org/wik... - you have to blame Hollywood for that :)

If you watched the video, it also mentions Kristian Hogsberg (who started Wayland), so that would make it plural.
If you want more, there's also Martin Peres, Matt Turner, Egbert Eich, Rob Clark, ...
You can find their names in the Wayland mailing lists and on the X.org site .

The slides are here. While I respect the idea that video is an inefficient means to convey information but, since this is an issue that you seem to care about, you may want to take the time to educate yourself. I believe it is possible to speed up playback of youtube videos. This article conveys some similar points, but not much depth. Here is an architectural overview.

Why don't you go over some of this information, and we can take this conversation over again from the top. You should find most of your concerns answered. I'm not particularly interested in spoon-feeding it to you, however -- please accept my apologies on that score.

The slides are here. While I respect the idea that video is an inefficient means to convey information but, since this is an issue that you seem to care about, you may want to take the time to educate yourself. I believe it is possible to speed up playback of youtube videos. This article conveys some similar points, but not much depth. Here is an architectural overview.

Why don't you go over some of this information, and we can take this conversation over again from the top. You should find most of your concerns answered. I'm not particularly interested in spoon-feeding it to you, however -- please accept my apologies on that score.

The systemd way of handling problem 3 is to create a unit.socket configuration file - on restart it will stop the old service, capture the sockets, start the new service and hand over the sockets to it. http://www.freedesktop.org/sof... I hope this helps, although I don't know how extensive the functionality is having never used it myself.

> I have yet to figure out how to even create a service with systemd or how I figure out what I'm depending on.

man systemd.profile

> Let's take my *THREE HOUR* debugging session on systemd yesterday. [...] It would've been [simple] with SysV init because the errors during the mount would've been spewed to the console and I would've seen them.

http://freedesktop.org/wiki/So...

30 seconds of Googling.

Not really sure what the problem is here other than your ignorance.

There are numerous solid reasons for /usr

• Network boots.
• Partitioning in general
• Modular filesystem permissions (I can mount /usr/ ro,nodev, / requires dev and write access

There are others, but that's just off the top of my head.

I've been watching Poettering's comments and attitude, and have to say I've got a bad feeling about this. Too complex. Not a sufficiently compelling use case.

systemd fully support a separate /usr .

There may be solid reasons for a separate /usr, and Lennart agrees on that. His whole point is, that actual Linux distros no longer support a separate /usr, which result in spurious and hard to track and debug bugs, which is why systemd issues warnings with such setups, unless you use initramfs. You can always ignore the warnings.

He actually have a very fine technical explanation here:
http://freedesktop.org/wiki/So...

With a boot media it is a piece of cake to read the journald log files.

My boot media doesn't have journalctl and such. You may say 'just make new boot media', the point is that's yet another requirement driving evolution of something that has historically not needed much touchup. Because Lennart pushes a new toolset, now downstream projects that focus on recovery images have to spin, and users of
those projects have to be aware and pick up updates.

That is just a pathetic excuse, and you know it too. It is a 5 minute job make a Linux distro boot from a USB key. There are plenty of easy GUI tools to that, and it can even been done from a MS-Windows machine.

If you run a distro using systemd, LVM, Btrfs, or any other such newish technology, you need a boot media to match, and not rely on your old 1995 edition of Yggdrasil Linux. Floppies just aren't reliable these days anyway.

I don't think they have promised forwards compatibility, meaning journalctl might have to rev or else be completely unable to render the files on some updated version of a distro. It creates a scenario where more specific match between diagnostic and runtime is made a more hard requirement.

It just makes sense that diagnostic data to the extent possible should be readily available in a format that really *anything* can read without particular tooling.

First of all, the systemd log file format is fully documented and covered by the interface stability promise. Look here for more information:
http://www.freedesktop.org/wik...
So it isn't going to change suddenly. So it isn't a problem at all.

Secondly, there are already many tools and programs that can directly read and manipulate the journald log files. Among these are of course good old syslog-ng that now handles such log files natively. There are more to come, especially since it is now possible to make GUI logviewers that actually work because of the structured file format.

The false dicotomy presented is that it's either unstructured plain text logs or unreadable structured binary data. The machine friendly structured binary data could have been managed alongside text representation of that data.

I personally *hate* that if I'm using a linux system to look at a windows system, there really isn't a good way to get 'eventviewer' sort of data. This is presenting the exact same scenario.

Not sure what exactly you are complaining about here, so I am guessing.

Feeble attempts have been made to make structured text log files, but the goal remained elusive for two reasons; it required the cooperation from all those making programs that wrote in the log (do it this way), and because the present logfiles effectively had become an API because of those many many log analysing scripts SA are using. Of course, there was also several different syslog variants too.

It is of course very easy to convert journald log files into text files if that is what you want, syslog will do this automatically, but it has excellent export tools too.

It is quite possible view MS-Windows event-log files from Linux. You can't use cat or less, but there are actually programs available.

I'm an old school user and absolutely hate SystemD because it absolutely violates the LFSH standard by requiring /usr to be part of the root file system. This is the primary complaint against SystemD in regards to the Gentoo community and I'm sorry to see that Debian has fallen for breaking the KISS principle.

No, systemd didn't break anything. It is merely the messenger that tells that a separate /usr is a broken idea on a modern Linux. systemd works fine with a separate /usr, but your Linux distro probably doesn't.
Just use "initramfs" if you actually have a real need for a separate /usr.

Look here for more information:
http://freedesktop.org/wiki/So...

I don't think I have much qualm about systemd as it relates to the init process. However, the people behind systemd push *hard* that text format logging is some anachronistic evil and that files on disk should just be binary. They do some pandering to the crowd by saying to run something like rsyslog alongside systemd, but that seems pretty counter to the other areas where there is an emphasis on running as few processes as possible...

I was sceptical about binary log-files too in the beginning. However, I didn't have to play around with the journalctl tool before I realized that systemd's logging is far superior to any existing simple text logging.

stuff like "journalctl -b 2" (only show logs from previous boot) and "journalctl -F _SYSTEMD_UNIT" (show all systemd units that have ever written to the logs) are pure gold. The amount of tab-completion with everything is just so nice. Try "jou (TAB) -F (TAB)" and it will show all possible values.
You get logging info from much earlier in the boot process then previously, and with kdbus something that will get even earlier and later in the boot process and when shutting down.

journalctl works great with all the usual text tools like grep, just think of it as a super 'cat' with god-like sorting powers.

Forget what others sneers about Poettering and systemd, and give it a proper workout with a distro that supports it properly, like Fedora 20 or similar. Make up your own mind by actually using it.

This is a good starting point:
http://www.freedesktop.org/wik...

To me it is clear that systemd simply is the future Linux plumbing system, and to me it is a quite brilliant solution as it is now.

Especially logging is a huge improvement. Novices can for the first time actually do usable filtering without knowing arcane programs and switches. A simple "journalctl -b -p err" will reveal much of interest for the novice trying to debug a problem. (shows all messages of priority levels ERROR and worse, from the current boot).

And because the log is structured in db form, there will be GUI logviewers that are actually useful, and that can do filtering and sorting by eg. error levels, monotonic timestamps etc.

...here.

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.

FFmpeg (upstream SVN tree >= 2010/01/18 / version 0.6.x and onwards)

for reference: http://www.freedesktop.org/wik...

The wayland repository continues to mature and moves slowly. This cycle again only saw a few wayland changes, most of which where fairly unexciting:

- SHM Buffer SIBGUS protection. We added and couple of utility functions to help compositors guard against broken or malicious clients who could truncate the backing file for shm buffers and thus trigger SIGBUS in the compositor (Neil Roberts).

- Subsurfaces protocol moved to wayland repo and as such promoted to official wayland protocol (Pekka Paalanen).

- wl_proxy_set_queue() can take a NULL queue to reset back to default queue. (Neil Roberts).

- A few bug fixes, in particular, I'd like highlight the fix for the race between wl_proxy_create() and wl_proxy_marshal().

- A few scanner error message improvements and documentation tweaks and polish.

I'm hoping the Maui Project (which uses Wayland) can continue to gain momentum as Wayland does and that it becomes a viable option in the next few years.

What do you mean that X forwarding is not working? It is usually deactivated by default and you have to turn it on with -X or in a config file. If you use '-Y' you turn off security. You have no reason to complain, if you turned security off yourself.

Looked it up. Openssh secure forwarding only works if the X server is compiled with XC-SECURITY enabled, which is disabled by default. Some distros consider it insecure, as does upstream. So, on distros that do not override this and enable XC-SECURITY secure Openssh forwarding is disabled. If you use openssh -X to connect you get the error "Warning: untrusted X11 forwarding setup failed: xauth key data not generated." X11 forwarding does not work in this case. Using -Y works fine.

There is some relevant discussion at:
https://bugs.freedesktop.org/show_bug.cgi?id=2606

Every X11 server needs a rendering target. For some X11 servers, this is a video card. For others, it is a virtual frame buffer that gets served through X11VNC or XRDP. And on machines running Wayland, the X11 server will render to the Wayland compositor. Porting an application's GUI toolkit allows the application to bypass XWayland, but not all applications will be ported to Wayland immediately, especially proprietary software no longer under mainstream support and free software without a large enough user base. But once enough applications get ported, the more complex and less security-hardened parts of X11 will be paged in only while an X11 application is updating its window.

http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html

"Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely."

Is it possible to be udev-free with current kernels? Gentoo did fork eudev a while back, but at the moment it appears that Gentoo is solidly into the systemd camp, so I don't know what the fate of eudev will be. Static /dev was a pain, too.

In the end, there are a few things I need from Wayland, and I think they will be there in the end:
...
- middle click paste. Maybe done with a virtual frame buffer and rdp to ship the final rendering across the wire.

Middle-click paste has nothing to do with how rendering is done. It has to do with 1) the event loop in your toolkit being able to get middle-click events and 2) code in a GUI application (whether toolkit or application code) being able to get the contents of the most recent selection, even if that might happen to be in another application.

The issue with middle-click paste in Wayland appears to be with 2) and how to do that in Wayland.

There's already a D-Bus implementation available on BSD and other Unices. The API is documented and anyone has the freedom to implement it any way they want, userspace, kernelspace or outerspace.

I fail to see how one more implementation, more specfically the Linux kernel one, has anything to do with giving up on anything.

You may want to check out this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=71116

Basically, GCC changed instruction ordering a bit to boost performance with out of order executing processors... If your code had undefined behavior similar to the code in that bug report, it may well be the cause.

I don't think making syslog only register error levels above "Error" is a solution. After all, seeing that a service is starting correctly can be very useful debugging information too.

I don't share your view, that only people mastering awk, sed and grep should be allowed to use Linux, and while I love the power of e.g. GNU tools, I don't think they should be mandatory to learn just to perform basic system maintenance.

As a newbie desktop user coming from Windows, there are so many new concepts to learn, adding for them incomprehensible CLI magic doesn't help their transition at all.

I still remember how hard it was to learn all those things when I was a Linux newbie.

If you admin Linux machines, then I find it amazing that you haven't heard of systemd. The majority of Linux distributions are changing to it. There is a very vocal minority who rants against this development, they apparently have cushy jobs where they never need to learn anything new.

Systemd is the most significant change in Linux for a decade at least, since it changes and unifies many core aspects on how Linux works.

But even if you too find systemd foreign to the knowledge to have accumulated, try to give it a serious chance by eg. getting F20 and walk through "The systemd for Administrators Blog Series" at http://www.freedesktop.org/wiki/Software/systemd/

The new RHEL 7 will be pure systemd, so will the upcoming SUSE and CentOS etc, so not having thorough knowledge on how it works will seriously impede future job opportunities for Linux SA's that don't posses systemd skills.

> journalctl -b -1 -p err

is of course straight forward compared to

grep "some error" log

The AC brigade is out in force tonight I see. Anyway.

Your example shows exactly what is wrong:
1. What error? How does the newbie know what to grep for without knowing what is written in the log? A 'grep "some error"' will of course miss both "Error" and "", but also miss errors indicated with "Failure" or "Warning".
2. The newbie can be swamped with error messages since your simplistic grep (without -i switch and path, and no pager too) just dump every "some error" logged the last couple of months unto the terminal. The journalctl example just showed errors generated since previous boot, something that is much harder to do with grep only.

The journalctl example shows how simple it is to filter the log so that only essential information is shown.

I really recommend you try to actually learn systemd. Get F20 and hack away.
This is a good starting point:
http://www.freedesktop.org/wiki/Software/systemd/

You can still use all the grep, sed, awk Kung Fu you know with journalctl, it just makes it so much easier.

So how come the new hotness of the Windows video system is only as good as this apparently old and knackered XWindows system

Did the tests in question go through the X server, or were they rendering images by directly talking to the graphics hardware and largely bypassing the X server, using the X server mainly for 2D stuff?

This is the problem with using DRM and other 3-letter acronyms in the article body; they become quite ambiguous.

Yup. Direct Rendering Manager, not Digital Rights Management.

(Having worked on Server Message Block protocol implementations, seeing "SMB" stand for "Small and Medium Businesses" gives my brain heartburn. :-))

systemd already has systemd-nspawn, but it's not touted as a secure container.

You've made me ruin my moderation in this thread, but I can't let such wrong statements unreplied.

The fact that these keywords are pre-processed by a special compilation step into C++ code does not make the code you actually edit standard C++.

Wrong. Is not a special compilation step. Is the classic C preprocessor, which is as standard C++ as any other feature of the language. Does this mean that udev is not standard C because it defines a foreach with a macro?

Also, Qt has its own notions of strings and files and threads and what-have-you. Once Qt is in your code, you ain't getting it out.

Qt has its own notion of string, because till C++11 there was no string type that allowed Unicode. Likewise for threads. Besides, QThread has features to integrate with an event loop, notion that the standard library doesn't have.

How the hell were programs written with WxWidgets using threads? Relying on Windows POSIX capabilities? Seriously.

And don't even try again the "but Qt duplicates all the containers". Qt's containers use a very different implementation (e.g. with implicit sharing), and so have pros and cons against STL containers. And Qt's containers have compatibility APIs with the STL ones as well. And you are not forced to use them at all. If some part of the API exposes a Qt container, you can convert to and from STL, since such functions are provided.

The C++ standard library is now much better than it used to be, but Qt started in an age where the STL wasn't even an acceptable option in all the environments where it had to run.

Once Qt is in your code, you ain't getting it out.

Certainly not. People is migrating from VxWidgets (e.g. VLC) to Qt, and not the other way around. Why it might be? Maybe is because is such a good application framework that is convenient to use, even for non-graphical applications.

systemd is modular. All I needed to read is about systemd.unit and systemctl

Yes there are more stuff for systemd, but it's optional. In my opinion, systemd is like git. Sure git brings 50 commands (or more) but all you need are the core commands: clone, commit, merge, branch, add, remove, push, pull.

systemd is modular. All I needed to read is about systemd.unit and systemctl

Yes there are more stuff for systemd, but it's optional. In my opinion, systemd is like git. Sure git brings 50 commands (or more) but all you need are the core commands: clone, commit, merge, branch, add, remove, push, pull.

I love Lennart Poettering's response:

It's really appalling how GNOME first NIH'ed Unity, and then the Wayland guys came and NIH'ed Mir, and then the git guys came and NIH'ed bzr, and then the github guys and came and NIH'ed launchpad. But the systemd guys are still the worst, NIH'ing Upstart! Such suckers! Let's stand together against NIH'ing Canonical technology!

https://plus.google.com/115547683951727699051/posts/RCfN9NwZrLN

NIH is only a problem if you "invent" something inferior to what's already there. And really, NIH is an intellectual weak argument that someone uses when they lack the stones to make an argument based on metrics that are actually meaningful. Lennart is actually very clear on the technical reasons why he chose to create systemd even if Mark wants to remain ignorant of them.

Also, we'll know that Mark as actually done his homework when he learns the proper capitalization of systemd. Come on Mark, at least read the fucking cover page and FAQ.

PS: you can also read up on various topics on their site http://freedesktop.org/wiki/Software/systemd/
eg, FAQ http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions/
and Myths http://0pointer.de/blog/projects/the-biggest-myths.html

PS: you can also read up on various topics on their site http://freedesktop.org/wiki/Software/systemd/
eg, FAQ http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions/
and Myths http://0pointer.de/blog/projects/the-biggest-myths.html

It can't even do basic stuff properly. It's even more buggy than MS Office. Even simple things are broken.

For example this bug has been around for years:
https://issues.apache.org/ooo/show_bug.cgi?id=15501
Basically you can't step by step find within a selection and choose which found item you want to replace.

I just wasted time downloading and installing 4.1.2.3 and the bug is still around after TEN YEARS!

They even regressed this feature in their spreadsheet (e.g. it worked, then they broke it, then they fixed it (recently): https://bugs.freedesktop.org/show_bug.cgi?id=53106 ).

OpenOffice Impress used to bother me a lot too - formatting presentations was just much harder than it needed to be - had to fight it a lot with text sizes. I hope it's better now.

If you don't use the bleeding edge Microsoft Office, you don't encounter as many "obvious" bugs like that.

All this time I've been pissed at the nouveau drivers that came as default with my linux distribution. "NVIDIA's drivers are working perfectly" I thought. "Why the hell are you building something not as good, just to make it open source?"

Now I know.

Was it pure failure,or today's sick fascination with 'mobile' that would lead a 'modern-replacement-for-X' project to have "multi-monitor issues"?I

The thing is that Weyland is just as mobile friendly as Mir: The freedesktop site says: "The Weston compositor is a minimal and fast compositor and is suitable for many embedded and mobile use cases".

It certainly is not that out of the question: http://lists.freedesktop.org/archives/nouveau/2013-September/014497.html

Guessing this
http://people.freedesktop.org/~agd5f/radeon_ucode/
The license says "free to redistribute in binary form" but its not open source and the license specifically forbids reverse engineering.

Select to copy and middle-click to paste

No, select to select and middle-click to paste selection; currently, I think the Athena widgets (as used by Good Old Xterm), GTK+, and Qt all implement the freedesktop.org clipboards specification (and I think at least some other toolkits, such as Motif, might behave that way as well; Open Look used the middle button, rather than Shift+left button, to adjust the selection, so XView and OLIT didn't work that way), so that selecting selects (but doesn't copy to the clipboard) and middle-click pastes the selection (rather than the clipboard).

"Select to copy", updating the clipboard if you merely select something, might well be confusing to new users and inconvenient for all users; fortunately, that's not how the feature actually works.

I'm not certain how "middle-click to paste the selection" would be confusing to new users, other than being surprising if the user happens to have something selected and accidentally clicks the middle button. That might justify making it an option, and even defaulting to "disabled", but dropping it entirely (by which I presume they mean "removing support for it from GTK+") doesn't seem appropriate.

• 1. It's inconsistent with Mac/Windows;
• 2. It's confusingly. Selecting anything overwrites the clipboard;
• 3. It's not efficient with a tool such as xclipboard;
• 4. You should be able to select text, then paste the clipboard over it, but that doesn't work if the selection and clipboard are the same;
• 5. The copy menu item is useless and does nothing, which is confusing;
• 6. If you think of PRIMARY as the current selection, cut doesn't make any sense since the selection simultaneously disappears and becomes the current selection.

I would like to add that this behavior completely takes over the middle mouse button, rendering the input useless except for this application which is only efficient in a very specific use case (you want to paste the thing you just highlighted)

I hope you know that you did not address my argument at all but merely attacked me personally.

There was a false assertion that the Sidebar was not done at Apache. I rebutted that. I then remarked that LibreOffice *supporters* seem to have difficulty graciously accepting the fact that the most notable feature of LO 4.1 is coming from Apache. You responded by saying that you have never seem a TDF member saying anything bad about AOO. That is irrelevant, since that was not my claim. And it is also untrue since I could point to ample examples of this.

From my perspective LO is downstream. A look at their logs shows that their use of AOO code is frequent and routine. They are not occasionally cherry picking, but deliberately mining every relevant patch:

http://cgit.freedesktop.org/libreoffice/core/log/?h=aoo/trunk&showmsg=1

In any case, I imagine this large scale use of AOO code is a source of some cognitive dissonance for them, after spending so much time trying to convince themselves that having a fork was better than working together with Apache, arguing that nothing good would ever come from Apache. Now they are faced once again with the inconvenient facts, that the AOO code is good, it is worth taking in large quantities. In fact their users are demanding this. TDF members were beaten up quite a bit at a recent conference from users demanding to know when they would improve their UI like Apache was. Somehow they need to reconcile these facts and their actions with their ongoing stance of non-cooperation with Apache.

sure the port of FreeRDP by Kristian Høgsberg into Wayland is much more recent.

http://lists.freedesktop.org/archives/wayland-devel/2013-March/007740.html

Your analogy holds true only if both projects, being Wayland and Mir, are serving the same purpose - They aren't.

Yes, they are both a display server/protocol, and yes, they are designed to replace X, but the goals of each project couldn't be more dissimilar.

Wayland is a long needed update to X that will fix a number of issues and allows for secure buffers that only the application and server can access. Wayland is being designed for the existing Linux desktop market and is a much needed project.

Mir, while adopting some ideas from Wayland, is a completely different beast that will focus on achieving two primary objectives: A display server that runs natively on both desktop and mobile, and, being actively developed and supported by new commercial partner Valve. It makes little sense for Canonical to wait for Wayland and then extend it for these two purposes as doing so will leave Canonical years behind on a shift that is happening NOW.

Wayland is absolutely being developed with mobile and desktops in mind: From the official wayland site itself (http://wayland.freedesktop.org/): "Part of the Wayland project is also the Weston reference implementation of a Wayland compositor. Weston can run as an X client or under Linux KMS and ships with a few demo clients. The Weston compositor is a minimal and fast compositor and is suitable for many embedded and mobile use cases."

And that's just the reference compositor.

But there's more. Work to get Wayland running on android about a year before (april 2012) Canonical's Mir announcement : http://lists.freedesktop.org/archives/wayland-devel/2012-April/003149.html

In fact, while we're on the topic of Android, Canonical took someone else's code (libhybris) for running Wayland on Android drivers to achieve Mir support for android drivers. Here's an article about it from the author of libhybris: http://mer-project.blogspot.fi/2013/04/wayland-utilizing-android-gpu-drivers.html
Quote from the article "Earlier this year however, I discovered that a well-known company had taken the code - disappeared underground with it for several months, improved upon it, utilized the capability in their advertisements and demos and in the end posted the code utilizing their own source control system, detached from any state of that of the upstream project's. Even to the extent some posters around the web thought libhybris was done by that company itself."

Oh yeah, Canonical's criticisms of Wayland (ie, their stated reasons for creating their own display server instead of going with Wayland) were so awful that they had to retract them: http://www.phoronix.com/scan.php?page=news_item&px=MTMxODY

Regarding Valve's support... Citation please. Last I heard Valve was sticking with X and hadn't made any further comments. Unfortunately I'm unable to find a link to back this up at the moment. I *suspect* Valve is taking a wait and see approach, and they're probably silently hoping Wayland wins as Canonical has stated that Mir has no stable API/ABI, which would make it a nightmare for application developers to support. It's unclear if they'll stabilize the ABI/API in the future, but it's sounding like they won't. This is one of the major reasons why the major desktops don't want to support Mir.

Everyone has been waiting for the Year of Linux on the Desktop; this will bring the goal one step closer. The same goes for an unadulterated Linux on the Mobile where graphical applications are more easily ported from their desktop counterparts.

There is nothing stopping Wayland importing code from Mir and vice versa.

Mir can use Wayland code as Wayland is under the extremely permissive MIT lice

Does intel make an HD7850 counterpart? Your comment lacks a lot of perspective.

Full prick mode: Also I wouldn't say that they claim there's a open source driver for it. It is not like they market it that way with a big sticker on the box. There are a lot of missing features yet for the whole south islands series and there are a lot of bugs. This is /. you should know these things.

Nice mode again: It is one thing that your card is a year old, but you should have bought something older or done some more research. I went full ghetto (in early 2010) and bought a 4670 and have had no problems with the setup. And it was cheap, the kind of cheap where you don't care that you are using a potentially slower open source driver.

I had this experience too. I managed to get it running with a single X session, but XRandR only supports one "screen" (in X11 terms) per GPU, which means that you can drag windows between monitors on the same GPU, but the monitors on the other GPU are separate and you can't drag windows over to them. (Here's a corroborating mailing list post.) Window dragging works with Xinerama (windows maximized properly etc), but Xinerama doesn't work with 2D hardware acceleration, so you lose that.

Even with Xinerama, I still found some oddities. Menus in some programs (I guess probably "in some toolkits") would open aligned with the top of my smallest monitor -- if I maximized a program on my main monitor and tried to open the menu for it, the menu would show up a couple of inches away from the menu bar. XFCE's system menu on smaller monitors would try to open aligned with the top of the biggest monitor. The mouse behavior in the corners of monitors was terrible (either the mouse went into the dead zone, or it jumped several inches to fit onto the smaller monitor, depending on whether I was using Xinerama or XRandR), making it really difficult to hit anything in a corner.

None of this stuff happens on Windows. It just works. I don't have to give up 2D acceleration. And that's with XP, which is almost a decade older than the Linux version I was testing with. I was expecting the same from Linux, but... nope.

On the plus side, while writing this post I discovered that XRandR 1.4 is a thing now, and apparently it does include support for multiple GPUs. Maybe this stuff will actually work now.

Seems like a bit of FUD on both sides of the argument...

A while back, I spent a few minutes skimming the Wayland FAQ and Wayland Architecture Diagram. Interesting stuff, especially the architecture page, and they provide actual detail while the TFA mostly doesn't.

For comparison of the two architectures, when running X, you might have an ordinary window manager or you might have a compositing window manager. The Wayland model is that Wayland *is* a compositor that provides both window manager functions and some of the functionality of an X server.

From what I can see, here's the architectual differences between X and Wayland when it comes to supporting remote app display:

Intentionally misstating by being over simplistic, it sounds like the reason Wayland doesn't support remote displays is because it also doesn't support local displays! More accurately, Wayland supports local displays (of course), but unlike X11 provides no way to render to them. Wayland doesn't do rendering; it apparently "just" knows how to swap video buffers to a display device and coordinate buffers between multiple clients.

I'm thinking that, for example, if you want to write a graphical app, you might target OpenGL or cario and then expect your code to work in both Unix (with X) and on Windows (without X). With Unix/X, I'd expect an OpenGL library that handed X primitives to the X server. With Wayland, you'd apparently have an OpenGL library that rendered to a buffer and then handed the buffer off to the Wayland compositor.

So, Wayland isn't doing some of the things than an X server would do. Wayland is never working with drawing primitives. It seems obvious that you'd never be able to run apps that use the old X toolkit libraries against Wayland without an X server in the picture. And, both the TFA and the FAQ report this and note that you'll need X server(s) in addition to Wayland for the foreseeable future. The X server(s) talk to Wayland instead of to hardware.

There's going to be support for running Wayland apps remotely. However, as others have noted, an obvious question is how efficiently a "native" Wayland app could be displayed remotely. If the app and its libraries are rendering graphics primitives into display buffers, it seems obvious that low level primitive operations are lost by the time Wayland gets the buffers, so you have to be able to efficiently transmit bitmap deltas. Queue arguments re whether drawing primitives are more efficient or bitmaps are more efficient...

The discussion of doing remote Wayland apps seems to revolve around how to transmit the per-app buffers across the network instead of handing the buffer to the local Wayland compositor / display driver. Or perhaps about having the compositor know that certain app buffers should be transmitted instead of composited to the local display, but that's almost the same thing when viewed as a flow.

Transmitting bitmap deltas works pretty well, but for some apps, sending higher level information such as the original OpenGL might be better. With X, they defined an extension, GLX for essentially passing the OpenGL to a remote server. Similarly, I imagine it would be useful if an OpenGL app could talk to a remote Wayland server instead of sending bitmap deltas. So, it looks to me like it would be useful to define an extension mechanism for transport that would allow OpenGL commands to be sent to a remote computer where they could be rendered to a remote buffer and handed off to the remote Wayland compositor. Bonus points if the extension mechanism is generic. Seems like transport of audio might be another fit for a modern replacement of X.

Not an X server developer nor a Wayland developer. I may have garbled things somewhat, but perhaps someone could clarify the mistakes and help take a portion of the FUD out of the

Seems like a bit of FUD on both sides of the argument...

A while back, I spent a few minutes skimming the Wayland FAQ and Wayland Architecture Diagram. Interesting stuff, especially the architecture page, and they provide actual detail while the TFA mostly doesn't.

For comparison of the two architectures, when running X, you might have an ordinary window manager or you might have a compositing window manager. The Wayland model is that Wayland *is* a compositor that provides both window manager functions and some of the functionality of an X server.

From what I can see, here's the architectual differences between X and Wayland when it comes to supporting remote app display:

Intentionally misstating by being over simplistic, it sounds like the reason Wayland doesn't support remote displays is because it also doesn't support local displays! More accurately, Wayland supports local displays (of course), but unlike X11 provides no way to render to them. Wayland doesn't do rendering; it apparently "just" knows how to swap video buffers to a display device and coordinate buffers between multiple clients.

I'm thinking that, for example, if you want to write a graphical app, you might target OpenGL or cario and then expect your code to work in both Unix (with X) and on Windows (without X). With Unix/X, I'd expect an OpenGL library that handed X primitives to the X server. With Wayland, you'd apparently have an OpenGL library that rendered to a buffer and then handed the buffer off to the Wayland compositor.

So, Wayland isn't doing some of the things than an X server would do. Wayland is never working with drawing primitives. It seems obvious that you'd never be able to run apps that use the old X toolkit libraries against Wayland without an X server in the picture. And, both the TFA and the FAQ report this and note that you'll need X server(s) in addition to Wayland for the foreseeable future. The X server(s) talk to Wayland instead of to hardware.

There's going to be support for running Wayland apps remotely. However, as others have noted, an obvious question is how efficiently a "native" Wayland app could be displayed remotely. If the app and its libraries are rendering graphics primitives into display buffers, it seems obvious that low level primitive operations are lost by the time Wayland gets the buffers, so you have to be able to efficiently transmit bitmap deltas. Queue arguments re whether drawing primitives are more efficient or bitmaps are more efficient...

The discussion of doing remote Wayland apps seems to revolve around how to transmit the per-app buffers across the network instead of handing the buffer to the local Wayland compositor / display driver. Or perhaps about having the compositor know that certain app buffers should be transmitted instead of composited to the local display, but that's almost the same thing when viewed as a flow.

Transmitting bitmap deltas works pretty well, but for some apps, sending higher level information such as the original OpenGL might be better. With X, they defined an extension, GLX for essentially passing the OpenGL to a remote server. Similarly, I imagine it would be useful if an OpenGL app could talk to a remote Wayland server instead of sending bitmap deltas. So, it looks to me like it would be useful to define an extension mechanism for transport that would allow OpenGL commands to be sent to a remote computer where they could be rendered to a remote buffer and handed off to the remote Wayland compositor. Bonus points if the extension mechanism is generic. Seems like transport of audio might be another fit for a modern replacement of X.

Not an X server developer nor a Wayland developer. I may have garbled things somewhat, but perhaps someone could clarify the mistakes and help take a portion of the FUD out of the