Slashdot Mirror
Xfce, LXDE, GNOME3 Desktops Running On Ubuntu Mir Via XMir
An anonymous reader writes "Through the use of XMir, a translation layer for running legacy X11 applications atop Ubuntu's forthcoming Mir display server, the GNOME Shell, Xfce, and LXDE desktops now run on this X.Org Server alternative. With XMir, the traditional window managers are still running while Mir treats these desktops as a single window."
Finally USB Display functioning?
or XMirWayland or in case I want to run XMir in Wayland.
Thousands of distros, tens of DE's and WM's, lots of different graphical toolkits, tons of libraries with significant overlapping functions, tons of system utils that do similar things, 6 or 7 common http servers, but TWO graphics servers? FRAGMENTATION! It's all gonna fly apart!
You dumbass.
there are actually at least 8 X servers
...except X.org is just another Xserver. It's not an entirely new protocol. This is why X servers and clients from a variety of Unixen and non-Unixen can all talk to each other.
It's like HTTP.
Mir is more like Microsoft trying to create it's own web browser protocol.
You should really follow your own advice.
A Pirate and a Puritan look the same on a balance sheet.
Truth. He is indeed a master baiter.
Violence is like duct tape. If it doesn't solve the problem, you didn't use enough.
http://test.ubuntu-discourse.org/t/non-unity-desktops-now-running-on-xmir/479/2
The story is specifically about avoiding fragmentation, adding compatibility layers, so even if you don't develop for Mir it will run there. Maybe you meant goodbye fragmentation?
Don't be ridiculous; the whole idea of Mir and Wayland is to speed up the desktop, as X is horribly obsolete and slow. This "XMir" is just so X stuff can be run on Mir until it gets updated to run on Mir directly.
Of course, there's a whole separate issue which is that Mir competes with Wayland and fragments the Linux infrastructure, but this doesn't affect speed.
The lower the level, the worse fragmentation is. Who cares how many text editors are out there, for instance? It doesn't matter, because you can use any of them that you please.
But lower down the chain, fragmentation becomes more of a problem, because things higher up the stack rely on standardization below them to work.
How many Linux kernels are there, for instance? Only one. (There's some different versions, but they're all compatible with each other as far as running application code.) (There's also *BSD and HURD, but those aren't used nearly as much, and at least one of the BSDs actually has a Linux compatibility layer to run binary Linux applications.) Until recently, there was only one display server, X; so graphical applications and toolkits only had to work with that. Then along came Wayland, which promised to fix a lot of problems with X; this wasn't so bad: most of us knew that X was long in the tooth and a replacement had to come sooner or later, so having everyone transition from the old to the new was a doable thing. But now, stupid Canonical had to decide to fragment things with Mir, which does mostly the same thing as Wayland but in an incompatible manner, so who knows what's going to happen.
Anyway, back to your other complaints: different libraries aren't a problem. Using one library doesn't interfere with using another; applications just use whatever libraries they're linked against. System utils doing the same things isn't a problem: use the one you like, the others aren't going to keep you from doing that. Different HTTP servers is a good thing: use the one you like. Choice is a good thing, not a bad thing, as long as things are compatible. Graphical toolkits are a little lower on the stack, so that is a bit of a pain having more than one, so it's a balance between choice and standardization. Having two main ones doesn't seem so bad; 6 or 7 of them would be more of a problem. (There's more than 2 graphical toolkits, but only 2 of them are really in widespread use in Linux-land.) DEs are higher up the stack than toolkits; use the one you like. There's nothing preventing you from using KDE apps in GNOME, and vice-versa. However, DEs are lower than regular apps, usually have a lot of stuff integrated, and are the "face" seen by users, so it would be nice if Linux had its act together better in that regard. Of course, when a DE is tied directly to an incompatible display server, that really fragments things.
BTW, last I heard there were at least 3 or 4 different graphical toolkits for Windows (Win32, MFC, .NET), and those are all from the same company.
You don't know much about software, do you?
X.org wasn't a different display server, it was a fork of XFree86. Not only did it use the exact same protocol, it even used the exact same code (at least at first, though they added some new extensions later after everyone dumped XFree86 and switched to X.org).
No one (except a few morons) said that the X.org fork would be the "demise" of Linux. I remember the whole thing quite well; everyone was relieved that X on Linux would finally stop stagnating, and get some much-needed new development without that idiot Dawes holding everyone back. Within a very short time, all the distros had switched to the new fork and XFree86 became nothing more than a memory.
Had sex once. Got bored halfway through. Went back to my Linux box. Much more interesting than trying to find nontrivial words in a language with only two words, In and Out, and one form of punctuation.
Except Wayland is being developed by 15 year X devs that understand windowing systems, and engineers. Mir is being developed by developers.
what was that saying about developers and engineers. Windows was written by developers, Unix was designed by engineers?
Good god you're making me feel old. Not only have all the big three BSD OSes had Linux binary emulation for a long damn time... but I distinctly recall writing how-to's for a couple of them (that bounced around the internet and got translated into many languages I don't speak) some time LAST MILLENIUM.
No exaggeration there. The date on OpenBSD's compat_linux man page is March 1995. FreeBSD may have been a couple years earlier.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
millenium - a thousand anuses, from latin 'anus'
millennium - a thousand years, from latin 'annus'
FCKGW 09F9 42
He's talking BS.
Martin Graesslin, the KWin maintainer, began to prepare KWin for Wayland before Mir was even announced. So he designed the transition path to support two and only two back ends. See https://plus.google.com/115606635748721265446/posts/136nV4uojKH for details (public post, no need for a G+ account).
Graesslin also made it repeatedly clear that he won't support single-distro solutions. That means no support for MS Windows in KWin, OSX' Quartz, or Android's SurfaceFlinger. Somehow nobody ever had a problem with that decision. Only after Canonocal announced Mir Ubuntu fanboys began to whine.
There are no technological benefits for Mir over Wayland. Canonical made false claims as outlined on http://www.phoronix.com/scan.php?page=news_item&px=MTMxODA but they've since redacted the statements. Wayland even works with Android drivers: http://mer-project.blogspot.fi/2013/04/wayland-utilizing-android-gpu-drivers.html
The reasons for Mir are not technological, they are purely economical. Canonical wants to establish asymmetric licensing to have an economic advantage over the competition: http://mjg59.dreamwidth.org/25376.html
Wayland OTOH is under MIT/X11 license for everybody. This means that not only can any Linux vendor grab it and to anything with it, incl. to make an Android version that uses Wayland: http://ppaalanen.blogspot.com/2012/09/wayland-on-android-upgrade-to-404-and.html
Mir's licensing makes it forever impossible to become part of any major BSD variant. Wayland, however, is being ported to FreeBSD: http://www.phoronix.com/scan.php?page=news_item&px=MTMwMzE
Wayland is being pushed by industry giants such as Intel and Red Hat, as well as smaller companies like Collabora (creators of many technologies commonly used on GNU-based Linux such as Telepathy, WebKit-GTK, etc.: https://www.collabora.com/projects/ ).
Mir is just backed by Canonical who, while claiming to be the most popular Linux distributor, still makes no money: http://www.internetnews.com/blog/skerner/canonical-ubuntu-linux-is-still-not-profitable.html
Using Xorg.conf for xinerama config, while maybe not ideal for grandma, wasn't terrible, and you only did it once. But, for folks like you, there is now xrandr which you can setup via xorg.conf, use your WMs hooks into it to do it all gui-ish, or just run shell commands to setup your multi-monitor layout (since it would be trivial to write [hell you could do it in a short shell script], there is probably a daemon available that will auto add a monitor when plugged in and remove it when unplugged, but I am not familiar with it if it exists).
Unfortunately xdmx only works with xinerama, and newer graphics cards only work with xrandr, so in a crappy transition period now for this. But, if you ever want to setup a video wall with 100 monitors acting as one unified display, xdmx is probably the only game in town.
You had me at "Just right click and click output to and select multi-monitor". Phew that was easy.
Except you didn't say that. What you propose is something that Linux was known for in the 90s, really shit complicated and borderline unusable multi-monitor support.
Err, no.
DRI get X out of the way a lot, but there still areas for improvement.
Besides using DRI for rendering (or doing it client side), once done rendering a frame, the X client needs to notify the X server so it can notify the X window manager so it can do it's job and notify the X server again so the frame can actually finally show up on screen on the correct place.
And while in theory an X server could do this very quickly and efficienty, the real X.org server is quite slow.
Clients also need to talk to the X server over other things like object property manipulation.
Once more, in theory an X server could handle this quickly and efficiently, the real X.org server is quite slow.
(And full screen does help, as there's less of this going on).
All in all, Wayland won't get you higher frame rates in Portal. But it will make your desktop smoother, with less CPU/GPU usage.