More From Canonical Employee On: "Why Mir?"

An anonymous reader writes "Canonical Desktop and Mobile Engineer Christopher Halse Rogers explains in more detail the decision for Mir as apposed to Wayland. Although Halse Rogers 'was not involved in the original decision to create Mir,' he's had 'discussions with those who were.' 'We want something like Wayland, but different in almost all the details.' 'The upsides of doing our own thing — we can do exactly and only what we want, we can build an easily-testable codebase, we can use our own infrastructure, we don't have an additional layer of upstream review.' In a separate post Halse Rogers answer the question: Does this fragment the Linux graphics driver space?"

Comments

Context please?

[Anonymous Coward]

I nominate this submission for Slashdot's most lacking in context category.

Re:Context please?

[darkwing_bmf]

I concur. What the hell are they talking about?

Re:Context please?

[Bill Dimm]

This is follow-up to this story from a week ago.

Re:Context please?

[Intropy]

I can think of no context in which a furniture designer engineer, no matter how agile or standards-conforming would have as similarly viable alternatives a former Russian space station and an animated sycophant.

Re:Context please?

[undeadbill]

Go to the comments in TFA about details. There is some really juicy repartee between Seigo (OSS developer) and Shuttleworth (guy who funds Ubuntu).

There is a dust up going on between people working on the replacement for X under Ubuntu, and on the merits or lack thereof in choosing the Mir project over Weyland. Seigo and others make some interesting points, especially about the selection criteria.

Re:Context please?

[Anonymous Coward]

Because inexperienced, but otherwise intelligent, people often believe that they can do stuff better than everyone before them, there is a trend among hackers to rewrite otherwise perfectly fine code. Since X dates back decades, according to this line of thinking, it must need to be rewritten. "Wayland" is on such attempt (actually, what they are doing isn't nearly as sophisticated as X). Since Cannonical believes they are the shit, they want to be in control of the X successor. Their candidate is "Mir". I know nothing about Mir. The truth of the matter is that neither of these projects is going to go anywhere because it will require redoing lots of hard word (the video drivers, which are for some terrible reason part of X itself). X could use some work, but destroying the decades of compatibility is not the way to do it. The right way to do this would be to try to gather some kind of very broad support (say... from the developers of Qt and GTK) and get the two of these groups to converge on some modern subset of X, and implement the deprecated remainder as a legacy library. Of course, this doesn't let you "own" the end result, and it requires a LOT of work, so that won't ever happen. Also there's a feud between them, so it's probably impossible to do that.

Re:Context please?

[Anonymous Coward]

Why the Russian Space station of course! It never really fell from the sky, they replaced all the old computing equipment with modern stuff, and of course, are running Linux. The rocket engine drivers are important. Isn't that clear to everyone?

Re:Context please?

[Anonymous Coward]

Your assertion that Wayland will not go anywhere seems to be predicated on the incorrect assumptions that Wayland is born of naïvety (it's not; it's developed by people with a LOT of real experience working on the current X-centric stack), and that it needs to entirely supplant X to succeed (it doesn't; it deliberately does a lot less, and it can host a rootless X server, and indeed this is the only realistic use case for it on regular desktop distributions for the next couple of years).

Yes, there are many projects that are started for the reasons you describe, and go on to fail for those same reasons. But Wayland is not one of them. That is not to say that its success is guaranteed—but rather only that your reasons to assume its failure is inevitable are invalid.

Wayland does not need to destroy decades of compatibility. In fact, its approach is quite the opposite: to maximize compatibility initially (pass almost everything through to a rootless X server with XWayland if you want), and then offer an optional smooth migration path away from X for applications that don't need its complexity, would like to push the complexity into separate components, or would like to take advantage of some of the things that you simply can't achieve with X today, e.g., flicker-free from boot, to playing a game, and then on to playing hardware-accelerated videos.

You concede that the current state of video drivers being too tightly tied to X is terrible, so I assume you agree that the work has to be done to resolve that at some point, whatever path we collectively take. That also happens to be the only thing I'm aware of that's really holding Wayland back from mainstream use today. Everything else is just little bits and pieces that need to be finished or polished up, and then it could be dropped in to real general purpose distros.

Re:Context please?

[phantomfive]

Your assertion that Wayland will not go anywhere seems to be predicated on the incorrect assumptions that Wayland is born of naïvety (it's not; it's developed by people with a LOT of real experience working on the current X-centric stack)

His point wasn't that they are inexperienced with X, it's that they are inexperienced with software development in general. It's fairly common for inexperienced (though otherwise skillful) programmers to decide to re-implement a huge chunk of code in the hopes to make it better. It rarely works out very well.

Re:Context please?

[foniksonik]

Apple did it and it seems to be working out just fine. They could have tried to use X but probably had the same reasons as Canonical, full control.

Sometimes the only way to get better results is to tear it all down and start over. You learn from the past but let go of the baggage.

Re:Context please?

[Dahamma]

His point wasn't that they are inexperienced with X, it's that they are inexperienced with software development in general

Which is just an incorrect point, since as the poster you replied to pointed out these are the SAME PEOPLE who have developed many of the modern enhancements to X that keep it useful today.

How does he make any sense at all when he talks about how great X is and that they should pay attention to those who worked on it when they ARE the people who worked on it?

Re:Context please?

[interval1066]

They could have tried to use X but probably had the same reasons as Canonical, full control.

I hope they had the same reasons that most intelligent engineers have; X Sucks. Parts of that code tree are so old they have moss growing on them. The display code is in desperate need of a refesh. Mir instead of Wayland though? That's a control grab.

Re:Context please?

[phantomfive]

Maybe.

Having worked on the X Server in no way means their choice to create a new server is correct. Whenever someone forks software that's worked fine for nearly 30 years, the default position is, "they're making a mistake."

Maybe you're right and it's a great thing. We'll see.

Re:Context please?

[walshy007]

This, everyone seems to think wayland is more than it is. For now it's basicaly an overhyped screen multiplexer for X.

Re:Context please?

[Anonymous Coward]

His point wasn't that they are inexperienced with X, it's that they are inexperienced with software development in general. It's fairly common for inexperienced (though otherwise skillful) programmers to decide to re-implement a huge chunk of code in the hopes to make it better. It rarely works out very well.

That assumes that X11 was universally well-designed in the first place. It also assumes that experienced developers have been maintaining it (they all got laid off in the 1990s and nothing happend for 10 years). And it assumes that X11 is full of stuff that people care about, when much of it is legacy and not used by modern applications.

Eventually someone is going to have to suck it up and do something. Even if it was removing all the crap and making an "X12".

Re:Context please?

[Randle_Revar]

The comments from e.g. Dave Airlie, Kristian Høgsberg, Daniel Stone are even better, IMO, since they are Xorg/Wayland guys. Though Aaron is certainly a graphics guy, just at a higher level on the stack.

Re:Context please?

[gl4ss]

it has "canonical" in it.

that means it's a tech article about canonical doing some re-inventing of the wheel to get rid of some options shown to user.

Re:Context please?

[FranTaylor]

it's that they are inexperienced with software development in general.

So WHY do we let them fix X bugs?

Re:Context please?

[Dahamma]

First - it's not a fork. Forks are branches of the code. Wayland is a completely new display server.

And I'll just say I'm glad Apple decided NOT to use X by default on OSX. They managed to create a much more efficient display engine by not continuing to base it on the largely obsolete X protocol. Though, guess what, there is also a perfectly usable backwards-compatible optional X-server you can install if you want (which is a goal of Wayland, and I assume Mir, as well).

Re:Context please?

[Chrisq]

I concur. What the hell are they talking about?

Its about some guy that thought he wanted to go out with Wayland Smithers, but would like him to have great muscle tone, be in to martial arts, and many more things. He was thinking of putting Wayland on a body building and martial arts course but then decided it would be quicker just to go with Frank Mir instead.

Re:Context please?

[Anonymous Coward]

X is a protocol, not a code tree. However, these links actually detail problems with the damn protocol itself, which is better than what 99.99.99% of slashdot posts do.

Re:Context please?

[Udo Schmitz]

I hope they had the same reasons that most intelligent engineers have; X Sucks.

Quote from book: Steve Jobs told the USENIX audience in Phoenix, in June 1987, "that x was brain-damaged"

Source: http://books.google.de/books?id=CpAlTYwJJgAC&lpg=PA54&dq=%22Steve%20Jobs%20told%20the%20USENIX%20audience%20in%20Phoenix%2C%20in%20June%201987%2C%20%22that%20x%20was%20brain-damaged%22%22&hl=de&pg=PA54#v=onepage&q=%22Steve%20Jobs%20told%20the%20USENIX%20audience%20in%20Phoenix,%20in%20June%201987,%20%22that%20x%20was%20brain-damaged%22%22&f=false

Re:Context please?

[Mister Liberty]

SJ was liver damaged and a sociopath.
Need I say more?
Oh yes -- and stone cold DEAD.

Re:Context please?

[TheRaven64]

There is a great Slashdot post from one of the developers of Quartz around 2001 about why they chose to reinvent the wheel instead of using X11. The problem is, none of his criticisms applies to X.org circa 2006 or later. It was shown, by counterexample, that it was possible to add all of the missing features that Apple wanted to X11, without breaking backwards compatibility. And, as part of their rewrite, they lost some separation of concerns and they lost compatibility with X11 applications except via an ugly (visually) compatibility layer. The latter wasn't a problem for Apple, because they didn't want to be running X11 apps, they wanted people to write new Cocoa apps. It is a problem for a system attempting to take advantage of the large corpus of existing X11 apps.

Re:Context please?

[Alex Belits]

Because they suck at design, not at implementation?

Re:Context please?

[Dcnjoe60]

Apple did it and it seems to be working out just fine. They could have tried to use X but probably had the same reasons as Canonical, full control.

Sometimes the only way to get better results is to tear it all down and start over. You learn from the past but let go of the baggage.

Wasn't that the point of Wayland, to tear it all down and start over so as to get better results. You did get it right, though. Canonical did this because they want full control, they even say so. They developed Unity because they want full control. Canonical should have based Ubuntu on one of the BSDs because then they wouldn't have to worry about the troublesome "upstream" that they site as the reason for developing Mir.

Don't get me wrong, they are in their right to do with what they want with their product. However, they already had the reputation of taking more than the gave to the overall community and this just makes it more evident.

The word Ubuntu actually means "I am what I am because of who we all are." I think sometimes Canonical sometimes forgets that it is the "...who we all are" part of the definition that gives meaning to who they are.

Re:Context please?

[Looker_Device]

I'm beginning to wonder if anyone can write a summary anymore, or if there are any /. editors left to separate the wheat from the chaff.

Re:Context please?

[BrokenHalo]

Steve Jobs told the USENIX audience in Phoenix, in June 1987, "that x was brain-damaged"

I would rather be brain-damaged than a total asswipe. What Jobs did to Chrisann Brennan was, or should have been unforgivable.

Re:Context please?

[Anonymous Coward]

There wasn't anything wrong with his liver.

i believe it was his pancreas that was damaged.

Re:Context please?

[Burz]

Yes, because Apple were just a bunch of hackers... not.

X11 poses more problems than it solves. For one, it insists on being an independant entity so pressing archetictural concerns will always be denigrated (or not recognized at all) in favor of the status quo.

We can see the results of this in how, for decades, desktop environments struggled with the actually simple task of managing display settings (because the service did not ever save config info itself and the config file format was so open-ended, there was no canonical way for third parties to interpret or write the config data which means they all had a tendency to bungle it). And also the fact that X11, that whiz of "network transparency", ignored the need to efficiently *share* displays over the Internet (demerits for cluelessness if you reply and mention VNC); OS X and Windows got this capability back around 2000.

The config handling issue is partially fixed now (though not if multiple displays are involved). As for sharing and Internet-worthiness, there is the development of NX/freeNX but X.org seems indifferent to mainlining any of it.

If an entity like Canonical wants to have a go at supplanting X11, I say 'go for it'! I don't agree with all of Shuttleworth's positions (he still misses the point of personal computing), but in his insistence on copying Apple's footsteps he is at least marginally advancing the coherence and usability of Ubuntu (the Dash thing was a step back, however... OS X still makes it easy for a user to browse Apps heirarchically whereas Ubuntu 12.04 strips that ability).

Re:Context please?

[bluefoxlucid]

Since Cannonical believes they are the shit, they want to be in control of the X successor. Their candidate is "Mir".

You say a lot of words. I can answer the question in three:

Embrace. Extend. Extinguish.

Re:Context please?

[bluefoxlucid]

the merits or lack thereof in choosing the Mir project over Weyland

Embrace. Extend. Extinguish.

One day Git will be Bzr. One day Gnome will be Unity. One day X will be Mir. One day Linus Torvalds will be a gray-haired beggar on the street, still acting like an immature teenager, implying that people on the LKML would do better spending more of their time sucking cocks; and Canonical will be running the new, improved, coded-from-scratch, Linux-compatible Ubrik kernel.

Re:Context please?

[jedidiah]

> They managed to create a much more efficient display engine

You couldn't tell this by running an actual Mac.

This cult of Apple admirers would be amusing if they weren't potentially so destructive. They seem to blindly follow Apple without actually having any real experience with the product. They just swallow the usual media hype wholesale and then go on to replicate Apple's mistakes.

They also don't understand how an X server relates to the rest of MacOS.

Re:Context please?

[jedidiah]

The thing about Apple is that they have their own thing going. Despite the usual marketing rhetoric, MacOS X is not Unix. It is the latest version of MacOS which itself dates back to the early days of X11. Its an entirely different system. It's a different pile of legacy apps and legacy code.

It's a different set of expectations.

Whatever Apple chose, the appropriate thing was something that addressed the needs of people that were already using MacOS.

That's something that the Wayland cabal doesn't seem to get.

Re:Context please?

[jedidiah]

It would be much more convincing if Wozniak had said it.

Jobs is a glorified salesman.

Re:Context please?

[jedidiah]

> ignored the need to efficiently *share* displays over the Internet (demerits for cluelessness if you reply and mention VNC); OS X and Windows got this capability back around 2000.

Are you kidding? This aspect of MacOS is why I object so loudly to Wayland. What MacOS has SUCKS. It's the best possible advertisement you could have for X11.

Whatever structural purity it might have on the inside, it fails miserably at one key feature of modern desktops (not just X).

It helps to actually USE MacOS before putting it on a pedestal.

The Wayland cabal are trapped in 2000.

Re:Context please?

[Burz]

I've used OS X for over seven years.

In any case, you can complain about the implementation in OS X (maybe it does suck). It doesn't change the fact that it would be idiotic to try and use X11 for the purpose of conferencing when you could use Windows.

Apple at least gets points for trying here.

Re:Context please?

[larry bagina]

OS X is certified Unix. It's not X, but X isn't Unix.

The UI has a lineage going back to the 1984 Mac (and Lisa) but everything else is NeXT/OpenStep.

Re:Context please?

[Hatta]

In fact, its approach is quite the opposite: to maximize compatibility initially (pass almost everything through to a rootless X server with XWayland if you want), and then offer an optional smooth migration path away from X

How is this different from "Embrace, extend, extinguish"? Using X guarantees that I will get certain features from my GUI. If Wayland cannot provide those guarantees, it is a step back. That is not acceptable.

Re:Context please?

[Hatta]

Apple did it and it seems to be working out just fine.

What features are missing from OS X's display system that were present in OS 9?

What features are missing from Wayland that are present in X.

Answer these questions and you'll see why Apple's transition worked well, while Wayland will be a disaster.

Re:Context please?

[Anonymous Coward]

There wasn't anything wrong with his liver.

Sure, but what did you think of the faava beans?

Re:Context please?

[phantomfive]

Because no one else wants to do it.....

Re:Context please?

[interval1066]

Christ, the X11 implentation then. You're telling me that lump of crap is a paragon of good code? Let me get my laughing hat on here...

Re:Context please?

[interval1066]

X has won...

Uh, that doesn't make X a great engine (or protocol, whatever, mother) It simply means no one until Canonical has decided to to something about it.

Re:Context please?

[jbolden]

What features are missing from OS X's display system that were present in OS 9?

The OS9 Finder' which was powerful
Use of Fitt's law in design
Interface consistency
First controls differ in location and in tone
Symbols consistent with actions.
Clickable action and light up zone matching
Variable spacing for controls as a preference
Control of justification and spacing on the menu bar

etc...

Re:Context please?

[Anonymous Coward]

"Because inexperienced, but otherwise intelligent, people often believe that they can do stuff better than everyone before them, there is a trend among hackers to rewrite otherwise perfectly fine code."

I think I remember a guy that did this back in 1991. He tried to rewrite the perfectly fine OSes that we had at the time. He even named the OS after his name. I think you know the rest of the story...

Re:Context please?

[Dahamma]

This cult of Apple admirers would be amusing if they weren't potentially so destructive. They seem to blindly follow Apple without actually having any real experience with the product. They just swallow the usual media hype wholesale and then go on to replicate Apple's mistakes.

They also don't understand how an X server relates to the rest of MacOS.

Broad generalizations and assumptions never helps your point. I have worked on kernel and userspace graphics and video overlay drivers for Linux/X11, so I know plenty about how X11 and display servers in general work.

I do have a Mac. I also have a PC running Windows, and one running Linux (and honestly at this point VMs on these machines running more than one OS at a time - with fairly good unity/coherence modes, as long as we are talking display servers and window managers).

Some of us use computers as tools for accomplishing what we want at work, home, entertainment, etc and have no interest in blind Apple admirers OR blind Apple detractors (or Microsoft, or Linux, or any other software for that matter). Why does technology have to be like politics to some people?

(oh, and to your other comment, MacOS is more "UNIX" than Linux is, and is certified SUSv3 (for what that's worth, but it's worth more than your opinion on the matter).

Re:Context please?

[Eravnrekaree]

Apparently you have never programmed with X11 , because that is one of the most stupid comments I have ever heard and bears no relation to reality.

The X protocol contains various graphics primatives, facilities for dealing with fonts, setting colors, color managment facilities, and so on. There are extensions for non-rectangular windows, for faster video, shared memory buffers, and other things that have become desired over the years. There is really nothing in X11 that an application could not use to render its user interface. Nothing really useless. It is concievable that an application could use all of the features the X server provides and use them well and many still do. So the feature are there because applications may need to use them and to make sure applications continue to be supported.

What has happened is that some x11 extensions have been offered that offer an alternative way to do things, such as with handling fonts. This added some capability, but the additional capability is not necessarily needed by all apps. Programs can still use the old way and things will be perfectly fine and functional.

The way you talk about things you make it sound like X is bloated. This is an old canard that goes back to the days when 1 MB was a lot of RAM. X is only bloated if your computer has 1 MB of RAM. X itself is lean, in fact, esp. in comparison to modern software like Firefox, taking only a few megabytes for the core protocol code. So basically, you want to remove what would amount some fraction of a megabyte of protocol code and break compatability with hundreds of applications. You sir are an idiot that no one ought to ever listen to.

Re:Context please?

[Anonymous Coward]

It was shown, by counterexample, that it was possible to add all of the missing features that Apple wanted to X11, without breaking backwards compatibility.

Backwards compatibility to what? Mac OS and NeXTStep never used X11. Adopting X11 would have been breaking backwards compatibility.

Re:Context please?

[Anonymous Coward]

it's that they are inexperienced with software development in general.

So WHY do we let them fix X bugs?

And worse, some of them are eaven employed by Intel to work on wayland.

Re:Context please?

[Anonymous Coward]

You're telling me that lump of crap is a paragon of good code?

No. Exactly the opposite in fact. Xfree86 (or whatever it is called these days) is what really really sucks. X sucks much less, but obviously isn't perfect either.

Re:Context please?

[Sigg3.net]

I understand your case and I add that many developers use Apple machines (with OSX or Linux).

  However, We the nerds are in minority. I support the rest.

  The assumption that Apple customers made a better and more informed choice than their PC peers is wrong. Customers are mostly or statistically clueless on this particular subject, but Apple advertising/salesmen makes them believe that they made a better choice. Clever!

This is why an Apple user is superior to a PC user whenever they call me with the same problem. Usually they want me to confirm whatever justification they adopted from their shop.

So while "the right tool for the job" is a good point (personally all my tools are GNU/Linux branded but my thinking is the same so I use several distros), it doesn't invalidate the reality of the "cult like" axioms of the larger Apple user base.

It's psychological, I suspect, since most PC users start the conversation with how stupid they are with computers. Apple users are equally "stupid" but they know for a fact that they can't be wrong about their Apple choice, and allow themselves a fair portion of smugness, which makes these calls so hilarious.

If asked, I say I use GNU/Linux which shares a heritage with OSX, but has the freedom of PCs and comes at no cost. Sans any smugness.

Re:Context please?

[Dahamma]

Sorry, but I can't help but comment on "GNU/Linux" - I doubt all of your "tools" are GNU/Linux. "OSS"/Linux, maybe, but I thought only Stallman tries to pretend all of a Linux distro userspace is GNU :)

Re:Context please?

[Sigg3.net]

Forgot it was /. I replied to.

Standing by for public flogging.

Re:Context please?

[Dahamma]

No, not a flogging, just a teasing ;)

I have no experience from the IT/support side of things, but as far as users being "superior" - I don't think choice of computer makes anyone superior, but looking at the choice of computer of highly technically proficient users is interesting at least.

It's almost eerie how many people in the tech industry in SV, at least (developers, marketing, execs, etc) have started using MacBooks in the last few years. It seems 4 out of 5 people in meetings are using them. In fact, the exception to the rule was almost comical at a meeting with Microsoft - half the table was MacBooks, half was Ultrabooks (and half iPhone/Android, half Windows Phone ;) ) Apple haters can claim *all* of those people are just fanboys getting overpriced electronics for the image (I'm sure some do, but that's the exception rather than the rule of those I know). But it just comes across as a fairly petty and ignorant attitude - probably more so than the attitude they are railing against.

As I said, I have a Mac (Macbook Pro retina, my first Apple in 25 years) and I *really* like the hardware (the software I'm getting used to, but with VMs it's somewhat irrelevant). To go to the logical extreme of "the right tool for the job" - a few weeks ago I needed to install a Windows-based compiler toolchain on my Linux workstation at work so I could integrate it into our makefile-based automated build, but I was working from home. So I ran the Windows installer in Wine on my Linux workstation over VPN and an ssh tunnel from my laptop popping up the intstall window on the X11 server running on MacOS. Worked perfectly, and my head almost esplode. And this was all just to cross compile an app for the Nintendo Wii U :-D

And today I am home sick, so I'm about to fire up Windows running in a Parallels VM to play Planescape Torment on that Mac. And the only thing I see wrong with that picture is that I haven't finished Torment long ago!

Software is just a tool, not a religion... and there is no single "right tool" for all jobs... ;)

Fragment the Linux graphics driver space?

[Anonymous Coward]

"Does this fragment the Linux graphics driver space?"

No. That's the point of DRM and KMS. X11, Wayland, DirectFB, Mir, Xynth, whatever all share the same kernel drivers and userspace display and graphics libraries.

Re:Fragment the Linux graphics driver space?

[Alex Belits]

And none can coexist on the same system. And none, save for X11, have any usable remote protocol (if copying framebuffers is a usable protocol, then HDMI cable connection is a network).

Re:Fragment the Linux graphics driver space?

[Anonymous Coward]

And none can coexist on the same system. And none, save for X11, have any usable remote protocol (if copying framebuffers is a usable protocol, then HDMI cable connection is a network).

X11 can sit on top of Wayland perfectly well.

And anyway, none of the modern GUI toolkits (GTK, QT etc) are actually interested in using the built-in X11 features to do excitingly retro 80s things such as drawing 'stippled polygons' or bit-mapped fonts. In practice an X11 remote session consists of shuffling pre-drawn image buffers from the application to the X Server, and only works properly on a low-latency network.

Re:Fragment the Linux graphics driver space?

[Anonymous Coward]

X11 can sit on top of Wayland perfectly well.

This is just the usual FUD from Wayland fans.

X11 on top of Wayland is no different from Xming on top of Windows. It will work as a GUI terminal for a Linux (or other *nix) running real X, but it will not allow you to do "DISPLAY=remote:0 OUTLOOK.EXE".

As soon as Wayland gets any kind of traction, the Wayland fans will start trying to convince people to target their software to Wayland instead of X, and then we will be stuck with running everything locally, just like Windows.

Or we will need to use VNC, just like we did on Windows 95 (which, btw, you could also use as a GUI terminal for a Linux machine running real X11 with X-Win32 or Hummingbird Exceed).

Once this Wayland transition is complete, we will be just as limited as the Windows people. Somewhere in Redmond, in an office filled with broken chairs, someone is looking forward to that day.

Re:Fragment the Linux graphics driver space?

[Anonymous Coward]

You may want to look into Terminal Services RemoteApp. Remote applications on Windows have been supported since Server 2008.

Re:Fragment the Linux graphics driver space?

[jedidiah]

...you mean 20 years later.

That's about how long it took for Microsoft to get their act together and catch up to what X had from the beginning. Now you twits are going to replicate that and set the Linux desktop back 20 years.

That's what happens when you first ignore something and then have to retrofit it.

It makes things unnecessarily painful when compared to just paying attention to that requirement to begin with.

Re:Fragment the Linux graphics driver space?

[LWATCDR]

"As soon as Wayland gets any kind of traction, the Wayland fans will start trying to convince people to target their software to Wayland instead of X, and then we will be stuck with running everything locally, just like Windows."
Now they will not. They will target Qt or GTK just like they do today and have for years. Just about nobody writes applications for X.

Re:Fragment the Linux graphics driver space?

[Chemisor]

That's cute, but at this time the OSS drivers in the kernel are still not suitable for doing anything serious with OpenGL. They don't even support GL3.3 and core contexts yet, which is the minimum base any new code should target. And that's even without considering performance which is still lousy, and the fact that most games that run in Wine still won't work with OSS drivers. Don't get me wrong, I appreciate the effort Mesa developers are putting into these drivers, and I hope that someday they'll work, but they just aren't good enough to use yet, so for now there is no choice but to use binary drivers.

Re:Fragment the Linux graphics driver space?

[Anonymous Coward]

Citrix is 20 years old now.

The technology has been there for a long time, and it works fine. (much better than X over WAN links in fact) Microsoft has just been an ass about licensing it b/c they're afraid of PCs being replaced by dumbterms.

Re:Fragment the Linux graphics driver space?

[Anonymous Coward]

Since I live and work in the present, I really don't care when it was introduced. It's here and works now.

Re:Fragment the Linux graphics driver space?

[Alex Belits]

It's crap, and does not integrate remote applications nearly as well as X.

(much better than X over WAN links in fact)

No one cares about WAN when you have a huge multi-gigabit network with hundreds of hosts.

Re:Fragment the Linux graphics driver space?

[jbolden]

Wayland has made it clear they intend to implement an RDB style remote protocol.

Re:Fragment the Linux graphics driver space?

[Anonymous Coward]

At least until the bitrot sets in and Qt/Gtk stop supporting X, or begin to support it less well.

Re:Fragment the Linux graphics driver space?

[batkiwi]

Who uses X remoting to administer hundreds of hosts? An ex-windows-admin? Real administration is done over SSH, typically in screen or similar.

And no one uses pure X remoting for anything "real" due to the fact that losing your network connection means the app dies. For remote X useage everyone uses some sort of proxy layer anyways, so the "X does it natively" goes out the window, and it doesn't do it "better" due to the issue I mentioned before.

Re:Fragment the Linux graphics driver space?

[Alex Belits]

What administration?

People run their applications on multiple hosts.

Re:Fragment the Linux graphics driver space?

[Alex Belits]

Where is the specification?

Without specification and design documents or working implementation it's all hot air, and judging by how Wayland implementation is going in general, there is no expectation that they will implement things they actuallt agreed upon, leave alone ones they did not.

Re:Fragment the Linux graphics driver space?

[jbolden]

I'll do you better than design:

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

It's done.

Re:Fragment the Linux graphics driver space?

[Alex Belits]

It's worthless -- it's just a server that supports someone else's clients. Any graphics system that intends to replace X, must be able to run any application as a client, remotely. Otherwise it's shit.

Re:Fragment the Linux graphics driver space?

[jbolden]

No you are missing the point.

KDE, Gnome and most (hopefully) most other toolkits are going to support RDP
Wayland is going to have RDP clients
Most distributions will include RDP server software

So Wayland apps run remotely. It isn't part of the graphics system because part of the design of Wayland is that remote use changes things like buffering strategies that applications needs to know about. The graphics system is too far down the chain, far better is something like the toolkit.

Re:Fragment the Linux graphics driver space?

[Alex Belits]

No you are missing the point.

KDE, Gnome and most (hopefully) most other toolkits are going to support RDP

First and foremost, even if it was true, this is not something that can be done on the level of toolkit. Authentication, encryption, session management, support for absolutely everything that can be displayed, has to be done once, on one level. With X, it's done that way -- either through X, or ssh that wraps it, and it uses single implementation for all applications that the user can run.

Second, no GUI toolkit supports such a thing, or ever announced any intention to do so, so you are talking out of your ass.

Third, there would be a reason for a toolkit to support its own remote functionality, but that would make any sense only if it was an optional feature that optimized toolkit-specific behavior. RDP is designed for Windows, and would be suboptimal for any modern GUI toolkit other than Windows. Maybe you meant RFB, but RFB is not optimized for anything at all, it's worse than X, NX, and anything else.

Most distributions will include RDP server software

Surely you meant RFB, as RDP is a proprietary Microsoft protocol, and "most distributions" only include a client for it. As I have mentioned before, RFB is inadequate.

So Wayland apps run remotely.

No, they don't. Wayland applications (ones that use Wayland server) absolutely definitely can't run remotely. Qt anf GTK applications intended for Wayland potentially can be hacked with currently-nonexistent versions of Qt and GTK that talk RDP, RFB or some other protocol instead of Wayland interface, but that has absolutely nothing to do with Wayland, relies on other people doing something that those people don't plan doing, and does not cover any application that actually tries to use Wayland interface in its implemented form.

In other words, your claim is false, and unrelated to that, completely idiotic.

It isn't part of the graphics system because part of the design of Wayland is that remote use changes things like buffering strategies that applications needs to know about.

That's bullshit. Application programmer does not have to know details of X protocol, either, yet X11 libraries implement it, and applications use it. Wayland developers merely pretend that they can ignore huge pieces of design because they expect someone to create workarounds for their system's deficiencies. Not even Microsoft dares to do such a thing in GUI implementation, and Microsoft is a notorious bunch of lazy, talentless and bigoted developers.

The graphics system is too far down the chain, far better is something like the toolkit.

GUI toolkit is application specific and optional. Even though it may be a good decision to let it have its own optional protocol extension, it is a completely wrong place to implement a communications mechanism that is a core of remote UI/display support. What you pretend to propose, amounts to little more than insisting on application developers writing their UI as AJAX web pages, as this is the only "toolkit" that currently support remote operation on its own.

Re:Fragment the Linux graphics driver space?

[jbolden]

Second, no GUI toolkit supports such a thing, or ever announced any intention to do so, so you are talking out of your ass.

http://www.kde.org/applications/internet/krdc/
http://sourceforge.net/projects/gnome-rdp/

Surely you meant RFB, as RDP is a proprietary Microsoft protocol, and "most distributions" only include a client for it. As I have mentioned before, RFB is inadequate.

Microsoft publishes the spec:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383515(v=vs.85).aspx

That's bullshit [in reference to buffering] Application programmer does not have to know details of X protocol,

You are reading my comment backwards. In those situations where applications need to control buffering they can't under X11. Obviously applications that don't care about buffering won't have to worry about it under Wayland or X11.

RDP is designed for Windows, and would be suboptimal for any modern GUI toolkit other than Windows.

I don't think so. I think RDP works fine as long as the client (usual meaning, server for X11) has a toolkit capable of responding to high level instructions. So a Qt clients needs to have Qt but not .NET, a Gnome client needs to have GTK...

Authentication, encryption, session management, support for absolutely everything that can be displayed, has to be done once, on one level.

RDP is a secure protocol. Encryption is handled like any other network protocol. Authentication is handled using the security system on the server. Session management is handled by the server.

____

Anyway I think I've shown pretty conclusively that far from vaporware this is going on, this is the direction. It is being implemented, the support exist...

Re:Fragment the Linux graphics driver space?

[Alex Belits]

http://www.kde.org/applications/internet/krdc/ [kde.org]
http://sourceforge.net/projects/gnome-rdp/ [sourceforge.net]

Those are applications for viewing remote desktops, not implementations of toolkits that export UI to remote users. You don't know what this whole discussion is about.

X server is a _display server_, and all applications are its clients. It runs on the user's computer and handles all clients -- local, remote, remote forwarded over ssh, even ones running inside locally running virtual machines or containers if the user wishes to use them that way. For the user, they are all just applications with GUI, they can be integrated into any desktop, and they can use the most efficient mechanism among multiple available. Local application will use shared memory and direct access to 3D and video decoder, while remote application would have to tunnel its access through serialized network protocols, however both will benefit from local compositing when their windows overlap, as compositing is handled by a window manager. This is how things work now.

Remote desktop servers are GUI image streaming and input servers, their clients are applications that show remote desktop in a window. At best, they can be hacked to make the desktop background transparent, so remote applications will seem to be integrated into the local desktop. It's a worthless toy compared to a modern networked display architecture.

You are reading my comment backwards. In those situations where applications need to control buffering they can't under X11. Obviously applications that don't care about buffering won't have to worry about it under Wayland or X11.

Again, you have no idea what are you talking about. Applications use interfaces that hide or expose details of display mechanism as the application programmer requires. Most GUI applications' programmers need little more than a widget set and maybe a layout engine. Some have bitmaps and drawing primitives. Some need direct access to 3D primitives, video decoding, etc. Over their history, X11 and libraries that use it, solved all this by creating a stack of libraries, protocols, protocol extensions and data formats. It's not easy to implement and maintain, but it exists to allow developers to work on whatever layers and levels their application is supposed to be. People who do not understand it, get an impression that it all can be reduced to re-implementation of a small subset that they believe to be the only one needed, but this is not true for the whole range of applications and use scenarios that they don't know about.

I don't think so. I think RDP works fine as long as the client (usual meaning, server for X11) has a toolkit capable of responding to high level instructions. So a Qt clients needs to have Qt but not .NET, a Gnome client needs to have GTK...

Again, you have no idea what you are talking about.

RDP is a secure protocol. Encryption is handled like any other network protocol. Authentication is handled using the security system on the server. Session management is handled by the server.

And it's a shit mechanism compared to X11 over SSH, where X11 has local cookies (application access to display server), SSH handles encryption and session authentication (user's access to applications). User is in control of how independent SSH sessions let remote applications on multiple hosts display their interface on his display, while his desktop session can be anything on its own.

m4f - nsa

[Anonymous Coward]

looking for a cute asian girl to shit on my face.

Re:m4f - nsa

[Anonymous Coward]

I'm not a cute Asian girl, but I'll happily shit on your face. Email me: pater@slashdot.org

AND ... IT IS THE MICROSOFT WAY !!

[Anonymous Coward]

Lock in !! Motherfuckers !! Lock in !!

And we call it Mir for that communistic touch !! To make the freetardhippietypes feel more at home !!

"apposed?"

[logjon]

Really? Are we not even going to try to pretend to give a shit anymore?

Re:"apposed?"

[Anonymous Coward]

I agree, this sight is rediculous know! For all intensive purposes it is worse then Reddit.

Re:"apposed?"

[Anonymous Coward]

You weren't apposed to notice that.

Re:"apposed?"

[Anonymous Coward]

My God, the aliteracy of slashdot's n00bs is astounding. More astounding is the moderators modding a semi-literate post that rags a misspelling as "insightful" when it was not a misspelling at all, just a word that logjon and the mods (new band name?) didn't have in their vocabularies. You do have "vocabulary" in your vocabulatry, do you not?

This place used to be full of educated people. Seems 75% of commenters and mods are high school dropouts. So now a little unwanted education for you fucking jocks, who I wonder what are doing here in the first place: Webster's definition of appose.

appose
appose transitive verb \a-pz\
apposedapposing
Definition of APPOSE
1archaic : to put before : apply (one thing) to another
2: to place in juxtaposition or proximity

Would you fucking aliterates get the hell out of the internet's only real nerd site? And yes, aliterate is in the dictionary as well, it isn't a misspelling.

Fucking retards piss me off. If you don't have at least a high school diploma, go to the NASCAR or Sports Illustrated site. Slashdot is for nerds and you non-nerds are not welcome. No shoo!

Re:"apposed?"

[Anonymous Coward]

Really? Are we not even going to try to pretend to give a shit anymore?

why hshould we?

This just proves it's NIH

[rahvin112]

This just proves what everyone was saying last week. This decision was entirely based on NIH (Not in House) Syndrome. Ubuntu is convinced that they have to spend all their development resources on reinventing the wheel because Wayland isn't an internal project (but it could be).

It wasn't 6 months ago that Shuttleworth was complaining that Ubuntu needed to start making money, and here he is wasting development resources on reinventing things. Between Mir, Upstart, Harmony, and all the others he's going to have forked everything but the kernel (hey maybe that's next!, I hear forking the FreeBSD Kernel is common) and his costs only go up while he spends all his time fixing bugs all by himself. The result will be Ubuntu advancement will slow down, or it will become a buggy POS with no long term security.

Either way I think they suffer from NIH disease and maybe they should consider a fork of the FreeBSD kernel. I imagine it won't be long before Mint/Arch or whatever fully replaces all the popularity Ubuntu managed to create. I already see Mint recommended more often than Ubuntu.

Re:This just proves it's NIH

[Bill Dimm]

...This decision was entirely based on NIH (Not in House) Syndrome...

NIH = Not Invented Here

Re:This just proves it's NIH

[Anonymous Coward]

No, his initialism is fine. Just because it's not the one you were expected doesn't mean there is anything wrong with it. The real problem is he has no idea how to use it.

First, you state what you mean: Not in House Syndrome
Which you follow with the initialism: (NIH)
Then you can use NIH to your heart's content throughout the rest of your post.

Re:This just proves it's NIH

[AuMatar]

Unfortunately the grandparent has NIH, so he had to reinvent the acronym.

Re:This just proves it's NIH

[phantomfive]

Yup. Here is what I consider to be the key quote of the article:

the upsides of doing our own thing - we can do exactly and only what we want, we can build an easily-testable codebase, we can use our own infrastructure, we don't have an additional layer of upstream review - look like they'll outweigh the costs of having to duplicate effort.

They are doing it because they want to do it. So if you are someone who relies on backwards compatibility, cross-compatibility, or some feature in X that they don't care about, then you should realize that this is basically the guys at Canonical giving you the middle finger.

Also, it should be mentioned that one of the primary features of a good API is that it communicates its purpose well to those who want to use it. This is a communication issue, and unfortunately if the writing article is any indication, the MIR API is going to be haphazard and confusing.

Re:This just proves it's NIH

[MichaelSmith]

Doesn't come more meta than that.

Re:This just proves it's NIH

[rahvin112]

Have you ever considered perhaps that every acronym you can imagine there are other acronyms that are spelled identical and have similar meaning but use complete different words?

i.e.
NSA = National Security Agency or
NSA = National Speakers Association or
NSA = National Stuttering Association or
NSA = National Society of Accountants or
NSA = Network Security Appliance.

What makes you think that the acronym you think is the right one is the one I even intended? Or do you actually think every abbreviation only has one definition? I used the definition for NIH that I'm most familiar with, maybe instead of playing grammar nazi you should focus on content instead. But alas, you would rather demonstrate your belief in your own superiority.

BTW you're an asshole along with everyone else that felt the need to correct an abbreviation because only YOUR abbreviation is the correct one. Not that I expect much from someone that feels the need to post something as inane and free of content as your post was.

Re:This just proves it's NIH

[ndogg]

Sure, that could be part of it, but I think a careful reading would show that there were a number of things missing from Wayland that they wanted, and there were a number of things that would have required some heavy patching to get what they wanted, which probably wouldn't have been any better than starting anew anyway. This way they also don't have to worry about whether or not their patches get accepted upstream.

I guess they could have forked Wayland, but if they're not going to use most of that code anyway, what would be the point?

Re:This just proves it's NIH

[Anonymous Coward]

Ubuntu isn't already a buggy POS? Have you tried anything since 11.x? The only thing worse is Fedora, but Fedora doesn't pretend to be a stable distribution.

Re:This just proves it's NIH

[Anonymous Coward]

Arch? Popular? Hahaha, not in a hundred years. There are dozens of distros that are easier to install. It's got deserved popularity amongst the more technical users, but amongst people in general? Nope. You might as well claim that LyX will replace Word.

Re:This just proves it's NIH

[Anonymous Coward]

So if you are someone who relies on backwards compatibility, cross-compatibility, or some feature in X that they don't care about, then you should realize that this is basically the guys at Canonical giving you the middle finger.

You're just as stuffed with Wayland.

Re:This just proves it's NIH

[phantomfive]

And that's the real reason people are concerned about Wayland, not because of some love affair with X. It's not clear that Wayland is anything more than a group of "here today gone tomorrow" guys. But X, X will always be there.

Re:This just proves it's NIH

[Anonymous Coward]

As someone above said, they're implementing X on top of Wayland, so you'll still be able to run your 1993 Motif applications.

Mir, on the other hand, seems to be related to Ubuntu Mobile, which is probably dead-on-arrival.

Re:This just proves it's NIH

[Intropy]

What makes you think that the acronym you think is the right one is the one I even intended?

Because in context "National Institutes of Health" wouldn't make sense?

Re:This just proves it's NIH

[rahvin112]

Only two possible acronyms! That's right, just like the other idiots you think that only YOU can decide what are valid acronyms and if you don't think it's right, and you are the only valid judge of such things. Clearly you are clearly superior to everyone else, even if you are basement dwelling troglodyte with autism.

NASA has a ~300 page book of just acronyms. There are many, and just because you think you know what one of them means doesn't mean you have a clue what the author used, that's why people define what the acronym they are using means (well people not stupid enough to think there is only one definition), because there are so many of them. But there are stupid people that thing there is only one or two acronyms to any given sequence of letters and that they can't have similar meanings. It's as valid as a criticism of grammar that's riddled with grammatical errors. Internet is full of experts that aren't and you are one of them.

Re:This just proves it's NIH

[rahvin112]

Wayland is being developed by the same people behind X.org. 99.9% of the people lambasting Wayland have no idea what it is, what it's going to accomplish or how entrenched it already is.

Wayland is the future. It will take some time to get everything in place but it's already in play and many other project from the kernel to window managers are already moving towards implementing the plumbing necessary. Given this is slashdot I'm not particularly surprised by the ignorance, nor that people think something as complex as a complete rewrite of the GUI could be accomplished in weeks nor am I surprised that no one has bothered to actually learn about wayland and what it is but frankly the hatred is a bit surprising given the total ignorance. People hate software they know nothing about because they are afraid of change, it's just silly.

You think they would at least try to learn what it is given that almost all the people behind it are the same people behind X.org.

Re:This just proves it's NIH

[Randle_Revar]

>"here today gone tomorrow" guys

except for the fact that they are largely all the people that have been driving X development for years and years...

Re:This just proves it's NIH

[phantomfive]

They've been working on X for something like 6 years, right? That's like a quarter of the time X has been around? When they go, X will still be there. Will Wayland?

Re:This just proves it's NIH

[deniable]

So, if you don't like the usual version, you create a new one and expect people to follow. Too meta for me.

Re:This just proves it's NIH

[Zontar The Mindless]

I hereby award you this thread and 10 Internets. (OP is defo making stuff up.)

Re:This just proves it's NIH

[Anonymous Coward]

you: blah

962 other people: bleh

The bleh's have it, I think. Get over yourself.

Re:This just proves it's NIH

[rahvin112]

And the misinformation is already being quoted as fact. Per the discussion on G+ where the Wayland developers responded to the FUD from Canonical, AFAIK none of the claimed missing feature of Wayland are even missing. In fact from what I was reading tonight touch input has already been implemented in Wayland and the work on virtual keyboards and such is being worked on (Canonical hasn't even started this part of MIR).

Given the Canonical didn't even talk to the Wayland project it's not surprising but what Canonical claimed is nothing but FUD. They are trying to back justify their decision, but they didn't even bother to learn about Wayland before creating a bunch of false assumptions and FUD. Unfortunately that FUD is so far out there now that people are even quoting it as fact.

Go to G+ and google MIR, you'll find a number of threads where the Wayland developers point out that Canonical outright lied about what Wayland could/couldn't do. The linked post basically points this out, they didn't talk to Wayland, they didn't find out about wayland, they just wanted something they had total control over.

In the end they'll end up with a monster that eats coder time to no actual benefit where had they devoted those developers to Wayland they could have had more input into Wayland AND helped it get here quicker. It's a sad story of Shuttleworth desire for total control, even if what he ends up with is unmaintainable crap that's dropped after 2 versions and fragments the community in the interim. All because he wants a tablet/phone OS in a very crowded space.

It's ironic, if he wanted Android so bad, why didn't he just fork Android. The reality is he doesn't have the resources to do what Google did. Instead he's going to create a Frankenstein blend of (half-assed) Wayland, X and SurfaceFlinger that will likely have all the worst of each and none of the benefits.

Re:This just proves it's NIH

[Zontar The Mindless]

You're doing the bright-but-butthurt 14-y-o thing pretty well there. Keep up the good work.

Re:This just proves it's NIH

[Randle_Revar]

Dunno about the younger guys, but Keith was an X dev way back in the day. And by back in the day I mean 1988.
At least a few of the other devs where from the XFree era...

Re:This just proves it's NIH

[Anonymous Coward]

Then you can use NIH to your heart's content throughout the rest of your post while looking like an ignorant and/or self-absorbed little prat.

TFTFY.

Re:This just proves it's NIH

[quadrox]

Look, sometimes you are just wrong - this is one of them. Nothing to be ashamed of, we all get it wrong from time to time. The difference is in how you deal with it, so far you are not doing it very well...

Re:This just proves it's NIH

[Anonymous Coward]

Oh how I wish I had mod points.....

Re:This just proves it's NIH

[flyingfsck]

No, it was the 'Knights that say NIH'...

Re:This just proves it's NIH

[L4t3r4lu5]

It's so meta, even the acronym

Re:This just proves it's NIH

[eennaarbrak]

Ubuntu is convinced that they have to spend all their development resources on reinventing the wheel because Wayland isn't an internal project (but it could be).

You simply invoke "NIH-syndrome" without clarifying why Canonical is making the wrong decision in this specific case. You are implying that it is *never* a good decision to do things in-house when an existing solution (however imperfect) is already available. But looking around at technology companies that are successful (Apple, Google, Amazon), it is obvious that your reasoning is flawed, as all these companies have, on occasion, done things in-house when existing solutions were already available.

Clearly, the decision to do something in-house or not is more complex than following a stupid rule of thumb.

Re:This just proves it's NIH

[serviscope_minor]

Wayland is being developed by the same people behind X.org.

So? Xorg is boring. It doesn't need to change all that fast. It's not new and interesting. Careful improvements is far less funt than nuking it and starting again. Just because they develop Xorg doesn't mean they're not hopelessly biased for other reasons.

99.9% of the people lambasting Wayland have no idea what it is, what it's going to accomplish or how entrenched it already is.

Then enilghten us.

Wayland is the future.

I hope not.

It will take some time to get everything in place but it's already in play and many other project from the kernel to window managers are already moving towards implementing the plumbing necessary.

WTF? You really have no clue. The kernel side stuff is just for graphics and works as well with X11 as anything else. Secondly for "plumbing" there is no plu8mbing for window managers. WMs are replaced entirely by the compositor. None of the X11 WMs will work. It's a completely different architecture.

Given this is slashdot I'm not particularly surprised by the ignorance,

Is the irony intended.

nor am I surprised that no one has bothered to actually learn about wayland and what it is but frankly the hatred is a bit surprising given the total ignorance. People hate software they know nothing about because they are afraid of change, it's just silly.

Change is not always good, especially when it's for the better. Wayland looses us network transparency. So far all the counters to this tell me that (a) I'm lieing and I don't really want it (b) it can be hacked on after a la VNC and (c) it can be hacked on at the toolkit level providing a delightful level of inconsistency.

Those are not good arguments. (a) is particularly insulting.

You think they would at least try to learn what it is given that almost all the people behind it are the same people behind X.org.

And these are the user-hostile numpties who have come up with some really dubious decisions of late.

For instance, nixing the "kill active grab" keystroke, because it shouldn't be needed because it's caused by buggy programs. I mean WTF? How is that any comfort when some buggy program locks up the X server again and I have to switch to a console and try to kill it (if I can even find which one).

And they've decided that the Wayland policy is to have client side decorations "because it will allow consistend window decorations". The last point is an outright lie---it cannot be explained by incompetence. So in addition to having inconsistent decorations (from each toolkit, unlike now), hung windows will be immovable.

But that's OK because that's an application bug and apparently those don't ever happen. Especially not to developers.

Oh and then there's the persistent lie about X11 on Wayland. It's a lie because it's a half truth intended to decieve which probably makes it even worse. Of course you can run X11 on it. You can run X11 on a dead mouse, OS9/8/7/6 OSX, Win95, DOS Win 3.11 and modern Windows. That doesn't mean the user experience will be integrated and it doesn't mean that thw Wayland programs get the same advantages.

I wouldn't mind Wayland nearly so much if the creators (who also apparently had a lot to do with X) weren't such blantant FUD machines. If they're demonstrably lieing about a system they know in detail then it gives the feeling that they're really messing things up.

That and they've taken a really user hostile turn recently.

The thing is, thatWayland could be quite useful for multiplexing consoles and X11 sessions (if you care about graphical transitions between them, which I manifestly do not). But it's being sold very forcefully as a replacement general windowing system and due to the design lacks a number of really important feautres. If I have to choose between fancy transitions to ctrl+alt+f1 and remote windowing, I and many other slashdotters would choose the latter in a heartbeat.

And that is why there is so much hate for Wayland here: it's been earned.

Re:This just proves it's NIH

[dkf]

Wayland is being developed by the same people behind X.org.

That explains my number one complaint about Wayland: the documentation is terrible. Truly awful. I mean this in a very specific way: there is insufficient information there to tell me how I could get a surface on which I could render things, and there is insufficient information there to permit me to do an independent reimplementation of the client library. My only recourse would be to read the source code, but right now that doesn't seem to help either. (Sure, I could connect and probably get a surface, but I have no idea what I could do with that surface or how I would change the handle into something that some other library could draw on.) There's just too much information missing, and that's about par for the course with anything produced by the folks from X.org; they can code cleanly enough, but they can't document critical info.

I am a GUI toolkit maintainer. I'm not porting anything away from X11 for now because I just don't see enough of a platform to port to. (Some bits are probably there. Some definitely aren't. I have other things to do as well as filling out gaping holes in others' critical info.)

Re:This just proves it's NIH

[prefec2]

You miss the point. Ubuntu wanted to use Wayland. They said it is a great idea when the project started. But then the project got somewhat stuck. The public available documentation is weak, which makes it very complicated to add to the project. Furthermore, Ubuntu proposed to use a "test-driven" development method. While such a decision is debatable, the Wayland project does not talk about its development method.

Hopefully, the both sides do a lot of talking (which is already taking place) and in the end they can come up with one API for all. It is not helpful to a) say Canonical did not contribute to Wayland and then b) say that their move will harm the Wayland development. First, they did and if this was insignificant, the withdrawal of resources by Canonical would not effect the development. Second, both server use the same driver and EGL stack. The different uses might even help to stabilize this stack further. Third, Canonical wants something available for all computer devices with a screen. Wayland was started as a desktop replacement. Even though it is able to do its job on other devices, these ideas were later added.

On a side note: The biggest issues of Wayland are a) not enough communication in form of specs, documentation, and a roadmap (including all the stuff for project management), and b) they are not able to deliver Wayland+Weston for years now. All widget-set ports and other uses of Wayland are only demos. You cannot run it for real. Yes I know the task is complicated. But if you need more help then make it easy to help. At the moment. I will use Wayland or Mir what ever will be available in a working form.

Re:This just proves it's NIH

[Alex Belits]

As someone above said, they're implementing X on top of Wayland, so you'll still be able to run your 1993 Motif applications.

The problem is not with running X applications, it's with running new applications on complex display systems with local and remote displays, screens, window management, handling of input and dealing with misbehaving applications. Any application written for Wayland, Mir, etc. is worthless unless you have exactly the same display configuration, shell and everything, those systems' developers intended to support.

Mir, on the other hand, seems to be related to Ubuntu Mobile, which is probably dead-on-arrival.

I don't know and don't care. If those people wanted to do something useful, they would improve X protocol (what some people already done, better than them), or implement optional extensions that optimize the support for GUI features that people actually want (what some people also done, including some of them). Dropping features and design decisions just because they aren't useful for smartphones, is a stupid and harmful direction of general-purpose systems' development.

Re:This just proves it's NIH

[Anonymous Coward]

Per the discussion on G+ where the Wayland developers responded to the FUD from Canonical

Your post has adequately demonstrated that you do not know what FUD even means. FUD is a tactic, a strategy to, on purpose, discredit the target through fear, uncertainty and doubt. There is NO evidence that Canonical has done these things on purpose, only your assumptions that they have. This, in turn, makes you, consciously and on purpose, go on a rampage against Canonical.

At least their actions can be explained by ignorance. Yours, on the other hand, is nothing but conscious misguided hatred.

Re:This just proves it's NIH

[drinkypoo]

This just proves what everyone was saying last week. This decision was entirely based on NIH (Not in House) Syndrome.

Even though I think that's probably what's happening, this proves nothing of the sort and asserting that it does is simply logically fallacious. If they wanted all the details to be different, and it wasn't going to happen, then why not create something different? Maybe they have a good reason for their objections. Or maybe it's just as you say, but this article proves nothing.

Re:This just proves it's NIH

[Anonymous Coward]

So basically, the Wayland developers are incompetent if not dishonest.

You should fire them!

Oh, wait...

Well, just stop buying their stuff, then!

Oh, wait...

Actually, what you could do is stop telling people what they should be doing with their own time. If they want to work on something new, legacy be damned, good for them. And if you feel X is Perfect as is, only requiring a bit of maintenance, feel free to jump in.

Re:This just proves it's NIH

[bluefoxlucid]

Embrace. Extend. Extinguish.

Re:This just proves it's NIH

[Anonymous Coward]

Because Linux is better than Android.

Re:This just proves it's NIH

[Anonymous Coward]

What makes you think that the acronym you think is the right one is the one I even intended?

NIH = "not invented here" at slashdot and other tech sites. If you don't mean the common useage of the acronym. spell it out you lazy fuck. Also, a pet peeve of mine is when someone refers to cops as "LEO" -- that's Low Earth Orbit here, and why use a three letter acronym when there's a three letter word that means the same thing?

Don't be so fucking lazy, spell it out. Now GTFO! HAND.

Re:This just proves it's NIH

[Hatta]

Wayland have no idea what it is, what it's going to accomplish or how entrenched it already is.

We know what it's not going to accomplish. Network transparancy.

almost all the people behind it are the same people behind X.org.

Then there's no excuse for them to not know how important network transparency is. Shame on them for abandoning such a useful feature.

Re:This just proves it's NIH

[Hatta]

AFAIK none of the claimed missing feature of Wayland are even missing

Native Wayland apps will be network transparent by default? I'll be able to continue using my favorite window manager? Citation please!

I'd love to be enthusiastic about Wayland, but everything I've read indicates that it will be a downgrade from X.org.

Re:This just proves it's NIH

[Cloud K]

I already see Mint recommended more often than Ubuntu.

Please remember however that the Mint most people are recommending is actually based on Ubuntu.

I'm not saying that everyone who switches to Mint is doing so to spite or boycott Ubuntu/Canonical/Shuttleworth, however it's worth knowing that by using the Ubuntu-based version of Mint you are still indirectly supporting and relying on Canonical and their Evil Ways :)

LMDE (Linux Mint Debian Edition) is another story, although I'm not too sure where it stands in terms of maturity at the moment.

Re:This just proves it's NIH

[Anonymous Coward]

Agreed. Just replace effect with affect so I can find rest!

Re:This just proves it's NIH

[DragonWriter]

They are doing it because they want to do it. So if you are someone who relies on backwards compatibility, cross-compatibility, or some feature in X that they don't care about, then you should realize that this is basically the guys at Canonical giving you the middle finger.

This probably wouldn't be as bad if it weren't just a little while ago that Canonical was touting how they were totally committed to Wayland, all the while working on Mir behind the scenes.

Re:This just proves it's NIH

[davydagger]

AAAAA = American Association for the Abandonment of All Acronyms

Re:This just proves it's NIH

[serviscope_minor]

Actually, what you could do is stop telling people what they should be doing with their own time.

If you actually read my post you would see that I didn't do that. I would in fact never presume to do such a thing.

However when they post long detailed, deceptive and insulting arguments as to why their system is better than the one I prefer, I certainly reserve the right to yell "bullshit" very loudly.

Also, if they do sumbass things like remove really handy features I also reserve the right to call it a dumbass idea.

Re:This just proves it's NIH

[Anonymous Coward]

Removing ungrab key - that's a bad decision. I wasn't aware of this key, and it's bad if it was removed. There should be more, a switch to restore some sane display mode and "ungrab" full screen. I think this needs a more holistic approach than just a shortcut (redirection API, and something hooked, like Windows-style task manager). But it's a valid point, a useful feature, although insecure as it allows screen saver to be bypassed (but why not design screensaver API so it's disabled when s.saver is active? or even let the user configure it.

Hung windows: OK, with X-style WM there is always area where you can move hung window. But I can imagine workarounds for Wayland. I suppose (a total guess!) that the protocol allows pre-definition of surface area that is used to move, or definition where are the WM buttons. This can then be integrated into toolkits so app devs don't worry. And if that fails, user should be able to move it using Alt key. AFAIR, Aero stuff in Windows does client-side decorations and it seems to more or less work fine.

Consistent windows decorations, seriously? I hate to see window decorations not matched to the remaining GUI elements. Maybe it's just me. Btw. we anyway use two mainstream toolkits, which nowadays automatically adjust styles to each other.

Abd before you continue ranting, Mir isn't envisioned to be more X-like than Wayland...

Re:This just proves it's NIH

[Anonymous Coward]

The test driven issue is just bullshit.
If for no other reason, for this: nobody is supposed to actually use Weston as a display server. Weston is just a reference implementation of a Wayland display server.
Instead, you're supposed to take the Wayland protocol specification and probably libwayland and write your own Wayland display server (which includes the function of window/composition manager).
This is exactly the path Gnome and KDE are taking. They aim to modify Mutter and KWin, which are their current X window/composition managers and make then Wayland display servers.
And Ubuntu would of course write a display server for Unity.

Re:This just proves it's NIH

[jbolden]

I agree with you. /. has become incredibly conservative over time. /. today, is much more like what the BSD crowd was like in the late 1990s when they were resisting the earlier rounds of changes to get a (semi) popular desktop environment with Linux. You see it with discussions of programming languages, discussions of Gnome and Wayland.

That being said, Wayland has been sucking resources away from X11 for 4 years now without having replaced it. So from the perspective of an end user Wayland is getting very expensive. This is starting to remind me of Perl 6.

Re:This just proves it's NIH

[unixisc]

I haven't seen Canonical say anything about Wayland. Have you? It's perfectly legitimate for Canonical to go from a 30 year old standard to a new one of their own and ignore another one that is still under development. The advantage of Mir is that it's developed at Canonical's pace, w/ the wishlist that Canonical has. They don't owe it to endorse Wayland.

Re:This just proves it's NIH

[Grishnakh]

Network transparency in X is pretty much useless these days because it has no compression, so it's uselessly slow, since no one uses X drawing primitives or font servers any more. If you want network transparency, you need to use a protocol like NX. And it's not hard to add this into Wayland, in fact I'm pretty sure that's the plan.

Re:This just proves it's NIH

[Anonymous Coward]

Will I still be able to ssh -X into a machine and run *any* application. No? Then it is a failure from my point of view.

Prediction: There will be a schism in the Linux community. The Ubuntu/Gnome 3/Wayland crowds will compete over the idiots with their dumbed down kids-linux and the rest will move on to a more traditional UNIX-like distribution.

Re:This just proves it's NIH

[Hatta]

If you want network transparency, you need to use a protocol like NX.

NX builds on top of X. The right thing to do is not ditch X, but to build NX into X.

And it's not hard to add this into Wayland, in fact I'm pretty sure that's the plan.

Then why hasn't anyone from the project said "All Wayland apps will be network transparent by default."? It's an easy thing to do that would quiet a lot of FUD.

That it is possible to implement network transparency with Wayland is not enough. It must be impossible to implement Wayland without network transparency. Only that will provide the same consistency of experience that X has provided so well for so long.

Re:This just proves it's NIH

[Plombo]

At least their actions can be explained by ignorance. Yours, on the other hand, is nothing but conscious misguided hatred.

That's not entirely true. If ignorance is the reason, it has to be paired with gross incompetence - they didn't bother to do their homework or even ask one of the developers about the capabilities and future direction of Wayland. Not to mention that it was beyond irresponsible to spread fear, uncertainty, and doubt about the capabilities of Wayland without fact-checking in what they had to know would be widely disseminated. Now, even though they've retracted it all since literally every one of their claims was wrong, we have to deal with that false information being mistakenly claimed as fact in discussions like this one.

Re:This just proves it's NIH

[Plombo]

The companies you mentioned all have vastly more resources and technical expertise at their disposal than Canonical does.

But the main reason that his "NIH syndrome" criticism is valid is that in all of its recent defense of MIr, Canonical has not cited any other reason for not being satisfied with Wayland. Or at least not any other reason that wasn't later retracted for being based on blatantly false claims.

Re:This just proves it's NIH

[Plombo]

Furthermore, Ubuntu proposed to use a "test-driven" development method. While such a decision is debatable, the Wayland project does not talk about its development method.

What's that supposed to mean? Have you ever tried going to the Wayland IRC channel (#wayland on freenode) and asking? Wayland is a project developed out in the open, but you make it sound like it's a secret how exactly Wayland development proceeds. It's not.

Everything else you say in your post is fair enough, but the point about Canonical not contributing to Wayland deserves more mention than it has been getting in these discussions. It's nice to want to use Wayland, but if their only problem with it was development not going fast enough, then implementing a new display server from scratch is the exact opposite of a solution, especially when none of the Mir developers have significant prior experience working on display servers. If they wanted to have a modern display server to happen faster, the easiest and most reasonable way to accomplish that - both for Canonical's needs and for everyone else's - would be to take an active role in the development of Wayland.

Re:This just proves it's NIH

[prefec2]

Furthermore, Ubuntu proposed to use a "test-driven" development method. While such a decision is debatable, the Wayland project does not talk about its development method.

What's that supposed to mean? Have you ever tried going to the Wayland IRC channel (#wayland on freenode) and asking?

That is beside the point. If they have such process, it should be documented in the FAQ or other form of documentation. They might have some sort of understanding. Such information can be gathered by inquiry. However, in all projects, I have seen so far. If it is not documented, the project participants might think they have a common understanding, but when it comes down to get a coherent answer from all participants, it deviates. Also it is not very effective agreeing on something, then not documenting it, and in the end have to tell every new member everything about the project from scratch.

My point is: They don't make it easy to participate for new members. And while they are producing open source (great thing), they did not such a good job on communicating their knowledge. For an easy access to a project of such size you need three things documented:

1. Process and development model (they may change over time, but then you have to fix the documentation)
2. The architecture and concepts used. And the not only the "how", but also the "why".
3. Documentation of the API including methods/function call signature and their meaning. When the API speaks an state based language, the state (or model) associated with the API has to be documented as well

Wayland did not do a good job on this documentation side. From the Mir project, I haven't seen such information. So at present both projects have the same problem.

Wayland is a project developed out in the open, but you make it sound like it's a secret how exactly Wayland development proceeds. It's not.

Wayland is an open source project, but it is not an open development project, because (lake many other open source projects and also most closed source projects) documentation is not part of the development process. I could aggregate most of the information I requested by reading the whole mailing list and aggregate the information. That would most likely cost my one or two month to come up with the necessary documentation. The next guy who wants to participate in the project has to do the same all over again. Yes I can ask question in IRC or the mailing list. Yes I can pull the developer for every bit of information, but that wastes a lot of development time for nothing. The problem of the Wayland project is not singular to it, other projects have similar problems.

Everything else you say in your post is fair enough, but the point about Canonical not contributing to Wayland deserves more mention than it has been getting in these discussions. It's nice to want to use Wayland, but if their only problem with it was development not going fast enough, then implementing a new display server from scratch is the exact opposite of a solution, especially when none of the Mir developers have significant prior experience working on display servers. If they wanted to have a modern display server to happen faster, the easiest and most reasonable way to accomplish that - both for Canonical's needs and for everyone else's - would be to take an active role in the development of Wayland.

I personally find it sad, that Canonical was not able to discuss their problems with Wayland before they launch a new project. IMHO they should have designed a concept and published that. That would have been a better starting point for a discussion. So frankly I am disappointed from Canonical. But I am also a little bit sad, because Wayland is not proceeding that well. If I had any spare time left, I would give it a try and fix some of the bugs in Wayland ;-) However, I am pretty much tied up in other (also OSS) projects. And yes they sucked on the documentation side big time. For our key project, we fixed it over the last two years. It was a long process, but it made the whole product better.

Re:This just proves it's NIH

[eennaarbrak]

The companies you mentioned all have vastly more resources and technical expertise at their disposal than Canonical does.

The size of Canonical is essentially a non-sequitur. It is not only large companies that can benefit from in-house developed software assets. The question is whether the benefit justifies the investment.

But the main reason that his "NIH syndrome" criticism is valid is that in all of its recent defense of MIr, Canonical has not cited any other reason for not being satisfied with Wayland. Or at least not any other reason that wasn't later retracted for being based on blatantly false claims.

'The upsides of doing our own thing — we can do exactly and only what we want, we can build an easily-testable codebase, we can use our own infrastructure, we don't have an additional layer of upstream review.'

They don't have to be dissatisfied with Wayland per se for this decision to be the right one for them. There are upsides to maintaining your own codebase, especially when it comes down to an integral part of your core business. Hence my example of the above mentioned tech companies - they have learned that sometimes being in control of your own assets is important enough to invest some resources to it.

Good for Ubuntu

[Stalyn]

We could have had a modern display server years ago with XGL/Xegl. But it was killed off because Red Hat and nVidia didn't like. Mainly because it wasn't their idea. Now it seems all the pissing and moaning is coming from the Red Hat camp. Well karma's a bitch ain't it.

Re:Good for Ubuntu

[phantomfive]

What's wrong with AIGLX?

Re:Good for Ubuntu

[Anonymous Coward]

Unlike Ubuntu, RedHat actually contributes code that isn't complete garbage.

Re:Good for Ubuntu

[Anonymous Coward]

Gnome 3 was complete garbage and is still being pushed mainly by RedHat.

Re:Good for Ubuntu

[Anonymous Coward]

Gnome3 is fine. Cinnamon runs on it.

Re:Good for Ubuntu

[Gaygirlie]

It's not a display server. See https://en.wikipedia.org/wiki/AIGLX

Re:Good for Ubuntu

[serviscope_minor]

What? It's an X server which allows GL stuff to be rendereded accelerated. How does Xorg (with AIGLX) not fit that criteria?

Re:Good for Ubuntu

[Gaygirlie]

What? It's an X server which allows GL stuff to be rendereded accelerated. How does Xorg (with AIGLX) not fit that criteria?

AIGLX is an extension of X.org, not a display-server of its own.

Re:Good for Ubuntu

[serviscope_minor]

AIGLX is an extension of X.org, not a display-server of its own.

Well, Xorg then is a display server with accelerated 3D, remote and local, just like Xsgi. AIGLX is a component of Xorg which deals with that. Despite it not being a display server in its own right, I think the GGP's comments (what's wrong with it) still stand.

Re:Good for Ubuntu

[Anonymous Coward]

You might hate Gnome Shell, but as the name says, it is just a shell. That means their visual design might be bad to some, not that the code absolutely sucks.

Wrong spelling

[OhANameWhatName]

"Myrrh was used by the ancient Egyptians, along with natron, for the embalming of mummies."

Re:Wrong spelling

[Anonymous Coward]

A balm, what are you giving him a balm for? It might bite him.

Re:Wrong spelling

[MurukeshM]

I thought it might have something to do with the Russian word for world - (pronounced mir, it seems, and spelled as such in the Time Odyssey series).

Re:Wrong spelling

[Anonymous Coward]

There are two meanings: "peace" and "world". My guess is that the space station was named Mir to promote peace, as it was an "international" space station. http://en.wikipedia.org/wiki/Mir

Re:Wrong spelling

[Anonymous Coward]

Just to add to my previus post: the space station was launched in the midst of Cold War, and everyone was aftaid of nuclear holocaust, so the primary meaning behind the name is definitely "peace"

"our own thing — we can do exactly what we w

[G3ckoG33k]

"doing our own thing — we can do exactly and only what we want, we can build an easily-testable codebase, we can use our own infrastructure, we don't have an additional layer of upstream review."

IOW, Fuck GPL and collaboration.

Canonical better find an attitude. This is why they are disliked by the Debian team and others.

This is also why I dislike Shuttleworth and Canonical - the lack of helpful upstream collaboration.

not likely to be competent to do it

[bcrowell]

We know what a disaster it was when Canonical tried to adopt PulseAudio in Ubuntu. Basically they broke audio for no good reason. (See http://en.wikipedia.org/wiki/PulseAudio#Problems_during_adoption_phase for more info.)

Mir would seem to be an order of magnitude more difficult to pull off, since it's to be developed in-house by Canonical, and video is *much* more complex than audio.

Over all, it seems extremely unlikely to me that Canonical is competent to succeed in this.

They also don't seem to have learned their lesson from the PulseAudio experience in terms of "if it ain't broke, don't fix it."

Re:not likely to be competent to do it

[Anonymous Coward]

Pulse Audio sucks on all platforms. It's not a Ubuntu thing.

ALSA, Jack, anything but Pulse.

Re:not likely to be competent to do it

[Anonymous Coward]

Pulse Audio made things a LOT better. The people bitching about it going in too early into distros made their own problems by using bleeding edge distros to try to do real work.

Use RHEL (CentOS) or Debian if you can't handle your system breaking.

Wha?

[MouseTheLuckyDog]

'We want something like Wayland, but different in almost all the details.'

If you change all the details then won't it be very unlike Wayland?

Re:Wha?

[BlackPignouf]

http://nearwen.com/2013/02/client-comment-poster-i-really-like-the-colour-but-can-you-change-it/ :D

Re:Wha?

[prefec2]

They want conceptually something like Wayland, but not the concrete realization.

Re:Wha?

[flyingfsck]

It would be almost exactly, but not quite unlike Wayland. To paraphrase Ol'Douglas.

Re:Wha?

[bluefoxlucid]

No, think like when Bill Gates asked: "Can we do something specific to break ACPI in Linux? I don't want Linux to be able to use ACPI." That's the details. They want software to become popular on Ubuntu, they want Steam to run under Mir but not X or Wayland, to cripple everything else and become the Linux, and make the Money.

Embrace. Extend. Extinguish.

And if you disagree...

[Stiletto]

The great thing about Linux is... You can simply choose to not use Ubuntu. BAM! Problem solved.

Re:And if you disagree...

[gweihir]

Indeed! I do like that they explore things though. The X.org folks need a kick in the rear. They seem to think graphics has been solved. Not that it has gotten noticeably better since the X.org fork-off, but it is still pretty bad.

Re:And if you disagree...

[gweihir]

Wups, that should read "Not that it has not gotten noticeably better".

Re:And if you disagree...

[Randle_Revar]

Have you paid any attention to Linux graphics in, I don't know, the past year or so? Missed the whole Wayland thing, did you? Missed the part of this where all the X/Wayland devs are basically yelling "Why did start reimplementing Wayland late, with slight variations?"

Re:And if you disagree...

[gweihir]

I follow it, but apparently I did understand what was going on, in contrast to you.

Re:And if you disagree...

[GauteL]

The great thing about Linux is... You can simply choose to not use Ubuntu. BAM! Problem solved.

Not quite. Linux users do rely on a large amount of other users making it viable and interesting to make applications, drivers, etc. for the platform. The more Ubuntu succeeds in gathering Linux users to their Ubuntu OS, the smaller the rest of the Linux market becomes.

Canonical wants to go their own way in order to distinguish themselves from other distributions in order to gather more Linux market share (larger slice), rather than attempt to cooperate with others to grow the market (larger cake). Canonical does not have the resources to compete with Apple, Google or Microsoft on their own, so their fragmentation of the Linux base will only result in a net loss for Linux and free software.

Re:And if you disagree...

[Anonymous Coward]

F#$k them then, i'm switching back to Fedora, right this moment.

Re:And if you disagree...

[Bill_the_Engineer]

So your saying that as long as Ubuntu satisfies the needs of their growing user base, they will succeed in becoming a dominate player in the Linux distribution market.

I see absolutely nothing wrong with this. Competition is good and it is not like Ubuntu is selling their distribution at a loss to put their competition out of business. Every distribution has a chance to grow in popularity, all they need to do is cater to their user's needs.

Re:And if you disagree...

[Burz]

Not quite. Linux users do rely on a large amount of other users making it viable and interesting to make applications, drivers, etc. for the platform. The more Ubuntu succeeds in gathering Linux users to their Ubuntu OS, the smaller the rest of the Linux market becomes.

Just. WOW.

It's amazing that a zero-sum assessment of desktop Linux would be modded up like this. Ubuntu is trying to get past distro-itis or the Linux distro curse that has made the genre so repellent to most desktop users and app developers. If none of the distros are able to enlarge Linux' overall share of the desktop, its because none of them have quite figured out personal computing.

In any case, it should be becoming clear by now that 'Linux' is not an operating system by any means that a typical desktop user could recognize. If the community knew what was good for it, they would go back to using the moniker as a reference to the kernel only... the way Android does. Otherwise, it is impossible to have sane conversations about what is expected in terms of compatilibility, features, etc.

Canonical wants to go their own way in order to distinguish themselves from other distributions in order to gather more Linux market share (larger slice), rather than attempt to cooperate with others to grow the market (larger cake).

"With others" refers to the current desktop distro community who, to be perfectly honest, have their collective heads up their posteriors. No one but a hobbyist wants a bunch of ill-fitting pieces presented to them in a random pile. That is what the typical distro repository looks like to most prospective users. Sorry. The community are essentially hobbyists themselves and its really no one's loss for anyone to diverge from them; not when there is no marketshare to speak of.

If Ubuntu want to be the ones who show the way, they will have to stop being another "Linux distro" because that identity doesn't stand for much of anything definite. Google recognized this early on with Android.

Re:And if you disagree...

[Randle_Revar]

You have that backwards, son.

> The X.org folks need a kick in the rear.
No, they do not. They are well aware of the problems of X (it certainly has problems, though I still rather like it), which is why they created Wayland. Even if you somehow think Wayland is not enough of a change (dunno why anyone would think that...), Mir sure as hell will not change things or drive innovation or anything like that. It is all the same basic ideas as Wayland, but with a different license, a CLA, and controlled by one company. And it will be able to use Android drivers later, but Wayland could do that too (not that it will necessarily).

Re:And if you disagree...

[gweihir]

What are you talking about? Are you even aware what the problems. with X.org are?

Re:And if you disagree...

[Randle_Revar]

What do you mean what am I talking about? I am saying the Xorg folks do not need "a kick in the rear" from Mir or anyone else, they already got up off their rears and started Wayland, which has a very different approach from X. They are more aware than most of the problems of X and they aim to fix that with Wayland.

> Are you even aware what the problems with X.org are?

In general, it has over 20 years of backward compatibility cruft that no one uses anymore, and they end up having to implement the new ways of doing things in completely roundabout ways. The compositor is a separate program stuck off to the side for example.

Wayland was designed by the Xorg people to provide a very straightforward way of doing the things a modern-style graphics stack needs to do, and without any historical stuff like built-in fonts or drawing primitives.

Anything but X

[A bsd fool]

When you're on the bottom, the only way to do is up. It would be difficult to build a new GUI and do *worse* than X11, though if that's too difficult for Canonical I can't say. If they take direction from XP, OSX, and Win7 it may be good. If they all have eyes glazed over by words like "mobile" and "cloud" and take more direction from Android, iOS, and Win8, it may well be worse than X11.

Re:Anything but X

[mvdwege]

So what exactly is wrong with X? Please be specific.

Re:Anything but X

[FranTaylor]

Google "The Unix Haters Handbook" start reading on page 123

Re:Anything but X

[serviscope_minor]

So what exactly is wrong with X? Please be specific.

It's legacy. And it's a real dog on my Sun 3/60. Those 20 MHz haven't got room to spare you know.

Also having the old style drawing code in the server but paged out to disk unused, while technically it doesn't use any resources or slow anything down, offends my delicate sensibilities.

Oh, and I hate being able to remote windows or choose my own window management scheme.

Re:Anything but X

[mvdwege]

In other words, all you can do is parrot decades old grumbling.

Alex had more sense than you.

Re:Anything but X

[Anonymous Coward]

It would be difficult to build a new GUI and do *worse* than X11

Apparently not. X11 is a protocol for displaying windows remotely, and so far both Apple and Microsoft has managed to build GUIs that do worse than X11.

Come'on, I can't even do "DISPLAY=remote:0 OUTLOOK.EXE", and neither can I do the equivalent on a Mac (classic or OSX), and instead need to use inferior remote viewing tools like VNC or RDP. And so far, it seems both Wayland and MIR are going to be be worse than X11 in exactly the same way, even though the Wayland FUD-team keep claiming that you can run X11 on Wayland just fine, while ignoring that this is not the question asked.

Re:Anything but X

[FranTaylor]

X windows hasn't changed, why do the arguments need to change?

Re:Anything but X

[mvdwege]

I think I am soiling Alex' memory by comparing him to you.

Re:Anything but X

[Anonymous Coward]

Many things. http://mirror.linux.org.au/linux.conf.au/2013/ogv/The_real_story_behind_Wayland_and_X.ogv

Re:Anything but X

[jbolden]

1) X applications can't share an application and the video buffer. There has to be a memory copy. On high performance complex video this introduces lag which humans can detect. Human's are very good at detecting lag. Worse they seem to be about 10 times better at detecting lag when touch is involved, because the spacing between the finger and the objects being moved shifts. When we start talking high density screens (retina display) 10" + touch there is just no feasible hardware solution in the next decade using X.

2) In terms of WAN network transparency i.e. remote over a network does not compensate effectively for lag. There is too much server to to client communication. This is unfixable because of the speed of light. We need to redistribute what is done client and server side.

3) The X codebase is really hard to change and complex because of legacy. That drives up development times and uses resources inefficiently.

Re:Anything but X

[Anonymous Coward]

it's a piece of shit, poorly coded, cobbled together and poor

Re:Anything but X

[Anonymous Coward]

This talk provides a nice overview of the issues: https://www.youtube.com/watch?v=RIctzAQOe44

Re:Anything but X

[Plombo]

It might not directly answer the question asked, but it does solve the problem. The Wayland developers have made clear that no one expects X11 to disappear from Linux distributions in the foreseeable future. Since every toolkit on Linux already supports X, you can use the X backend of whatever toolkit when running the application remotely, and the Wayland backend otherwise.

Re:Anything but X

[mvdwege]

1. On modern X servers the video buffer is shared, and media playback is done by direct writes into a shared buffer. If I am wrong, or you mean something different, can you provide a link? (And on a side note, I've never seen systematic video problems traceable back to X, only incidental ones, and no system is free from those).
2. X worked in days when the network standards were slower and less responsive, and today it should be worse? If there is too much communication, that is partly bad toolkit design. The alternatives of shoving full bitmap images over the lines for remote rendering can hardly improve the situation.
3. Boohoo. Complex problems lead to complex code. Oh those poor programmers, they don't get to reinvent the wheel for fame and glory. Fuck them.

Re:Anything but X

[jbolden]

On modern X servers the video buffer is shared, and media playback is done by direct writes into a shared buffer. If I am wrong, or you mean something different, can you provide a link? (And on a side note, I've never seen systematic video problems traceable back to X, only incidental ones, and no system is free from those).

I'm losing you. Are you talking XDirectFB or something else? As far as systematic video problems from X11, that's easy to reproduce. Boot your computer to Windows or OSX as appropriate. Start running some video streams while holding down and moving them. So you have: multiple video streams with at least one in motion. Assuming your video card(s) aren't excellent relative to your screen, you should be able to get slight hiccups and noticeable lag.

Now reboot to Linux. Take the same streams moving at the same speed. You'll see an obvious difference.

X worked in days when the network standards were slower and less responsive, and today it should be worse?

X worked in the days when bandwidth was much worse. Latency is a different issue. Latency on average is drifting upwards as:

a) The amount of distance between server and client is going from meters to thousands of miles.
b) The number of routers in between increasing
c) Higher latency connections (like cell phone tethering) are being used, also QoS based connections increase latency to decrease jitter.

On the plus side routers in broad use are much faster today than 15 years ago. Ultimately (b) and (c) are solvable issues, but the fact that the size of the earth is big relative to the speed of light means (a) isn't solvable. At the end of the day 1ms (what's needed for responsive touch) cannot possibly happen over distances 90 miles, 10ms latency (what's needed for most mouse interactions to feel instant) 900 miles. Can't be fixed even if all the other problems were go to zero, which ain't happening anytime soon.

The alternatives of shoving full bitmap images over the lines for remote rendering can hardly improve the situation.

Sure it can. Once the client has the bitmap it can render it essentially instantly. Also more and more we are moving towards vector graphics. Obviously a large bitmap relative to bandwidth introduces a 1x cost in latency but it is one time. Same as caching fonts on a printer.

jbolden:The X codebase is really hard to change and complex because of legacy. That drives up development times and uses resources inefficiently.
mbdwedge: Boohoo. Complex problems lead to complex code. Oh those poor programmers, they don't get to reinvent the wheel for fame and glory. Fuck them.

You are actually making a different claim. My claim was that bug fixes were taking long because of a complex code base. Your counter in the article is that developers would rather rebuild than fix. Your claim may also be true. But that only compounds the problem if X11 is leading to the maintainers being bored while they are excited to work on Wayland I'm hard pressed to see how that's an argument against Wayland. The people who were working on XFree86 in the 1990s primarily were working for commercial X servers which used parts of the codebase like Hummingbird. The people working on X11 today are associated with distributions primarily Suse and RedHat. I can easily see them being less interested in maintenance work, getting people to do work they don't want to do requires money. The commercial X servers had more money to spend on X11 than the distributions have.

So even if your counter were a counter and even if it were true, how is that an argument for Wayland?

Re:Anything but X

[mvdwege]

I have rarely seen problems with multiple video streams, and only on systems where decoding the video was the bottleneck. Rendering has always been as good as on Windows (which pre-XP wasn't very good either).

As for pro-Wayland: I think there is a misunderstanding; I am not arguing in favour of or against Wayland, I am arguing against what in my view are shortsighted and badly founded claims against X.

Sure, it's old and complex code, that takes some getting used to. Throwing it away is however not the answer. Xorg was a step in the right direction, and I wonder why people gave up on that and started pushing the new hotness (aside from the CADT model applying, of course).

Re:Anything but X

[jbolden]

Xorg was a step in the right direction, and I wonder why people gave up on that and started pushing the new hotness (aside from the CADT model applying, of course).

Well that's easy. They pushed through most of the stuff that had been backlogged that the XFree86 guys hadn't wanted that kept them busy for a few years. What was left was stuff that was hard to do with the X11 codebase.

I have rarely seen problems with multiple video streams, and only on systems where decoding the video was the bottleneck. Rendering has always been as good as on Windows (which pre-XP wasn't very good either).

I'm talking Windows 7, maybe Vista. Or OSX 10.4 or later. You have to be using modern video codecs for this comparison.

Re:Anything but X

[mvdwege]

As I said, I have rarely seen video problems, and most of them I've seen on machines that were not powerful enough to decode modern codecs at the prerequisite framerates to run multiple video streams.

Short of actual numbers, all we have is anecdotes of people saying 'X video playback sucks' and people saying 'works for me'. That in itself is no ground to make decisions on.

Re:Anything but X

[jbolden]

Short of actual numbers, all we have is anecdotes of people saying 'X video playback sucks' and people saying 'works for me'. That in itself is no ground to make decisions on.

I didn't say playback sucks. I gave you a repeatable experiment to prove the problem. Now this problem might not be a problem for an end user. Lag is highly activity dependent, of 2-3 ms are a problem for drawing. Lags of 2-3 seconds might not a problem for watching a movie full screen.

You don't need numbers. I gave you a simple test you can do on any X11 that should be repeatable. My assertion is simple pick a workload (video frames in motion) that stresses the video card causing minor problems under Windows or OSX (recent versions) and under X11 it will be disastrously overtaxed. You do numbers when the differences aren't obvious, this is obvious.

You want to see problems overwhelm your hardware. Any hardware can be overwhelmed. Increase the number of megapixels. Increase the number of number of things the card is having to do. Heck if you have a really fast setup have it flip between a Blu-ray movie and a highres game 30x per second interleaving the frames 60x / second. I doubt your card can handle that. If you get nothing slow it down till you get something that's jarring but understandable.

I have an nvidia 650M which is an excellent laptop card. I'm using OSX which is arguably the best design for video around. Because I have a 5mega pixel screen and virtualization that Apple does I can get visible lag fairly easily. If I throw the computer into Intel 4000 mode it is hard not to get visible lag.

_____

You asked for an example. This is an infinitely repeatable example demonstrating the problem.

Re:Anything but X

[mvdwege]

And yet I run an Intel 945 and I see none of the problems you describe.

Again, anecdotes do not make for reliable data.

Re:Anything but X

[Urkki]

At the end of the day 1ms (what's needed for responsive touch) cannot possibly happen over distances 90 miles, 10ms latency (what's needed for most mouse interactions to feel instant) 900 miles. Can't be fixed even if all the other problems were go to zero, which ain't happening anytime soon.

Uh, these millisecond times are just bullshit. Display updating at 60Hz, that is every 16ms, feels completely smooth, and that means shortest possible average delay from finger movement to it showing on screen in half of that. Because it actually jitters between 0..16ms + rendering delay, realistic best case is, display will show response after next frame, that means delay of in 16...33ms.

Re:Anything but X

[jbolden]

No latency is much lower than 16ms under that situation. It is close to 0, it is just relying on the fact that the visual system will fill in missing details at 60hz. But it will fill in the detail with continuing the previous motion. 33ms would be a problem except that the later frames will be inconsistent with the delay so the brain fixes it. If the delay were really 33ms then it would be visually stressing.

This has been tested. With computer graphics up to about 125fps and instant response feels better. Do a web search on frame rates and computer graphics.

Playing devil's advocate

[foreverdisillusioned]

I'm almost inclined to cut Canonical some slack here. Almost. I don't think NIH is such a horrible thing if the project in question still isn't anywhere near usable. In a situation like this, it's entirely possible that a team of paid, full time, competent programmers could start over from scratch and quickly surpass the original project. Given equal talent and effort, the Cathedral is always more efficient better than the Bazaar.

However, I haven't seen evidence that Ubuntu possesses the talent or the manpower. Time and again, I've either read about or experienced firsthand halfassed, quite unnecessary 'improvements' while watching them neglect the fundamentals.

So, like most every other thing they've done for the past five years, this decision may be fine in theory (I'm not super familiar with the issues surrounding Wayland, so I can't say for sure), but in practice will quickly become a category five disaster.

Re:Playing devil's advocate

[21mhz]

I'm almost inclined to cut Canonical some slack here. Almost. I don't think NIH is such a horrible thing if the project in question still isn't anywhere near usable. In a situation like this, it's entirely possible that a team of paid, full time, competent programmers could start over from scratch and quickly surpass the original project. Given equal talent and effort, the Cathedral is always more efficient better than the Bazaar.

This is showcased nicely by the previous projects near-single-handedly developed by Canonical: Bazaar (heh; there were actually two iterations of it, both ultimately crap) and Upstart. Interestingly, neither of those was clearly NIH-motivated, they just were not satisfactory from the engineering standpoint as later, better projects have demonstrated.

Re:Playing devil's advocate

[Compaqt]

What's wrong with Upstart? Doesn't it restart services like it's supposed to?

Re:Playing devil's advocate

[Anonymous Coward]

What are the problems with upstart? Seems to be working just fine.

Re:Playing devil's advocate

[21mhz]

What's wrong with Upstart? Doesn't it restart services like it's supposed to?

It does, and it does other things, but it did not offer the flexibility and the features that systemd was able to provide (in less development time, too).

And here's a pattern: Canonical invests in a "better mouse trap", but they lack the first-rate talent it takes to create the kind of outstanding technology that other players would want to adopt, and their project is eventually passed over for something that works clearly better, enjoys greater mind share, etc.

Re:Playing devil's advocate

[Compaqt]

I'm using Ubuntu because 1) Redhat basically abandoned the desktop, and 2) I need a more recent stable platform (Ubuntu Server) than RHell.

But I definitely agree about the emerging pattern of Canonical doing stuff just for the sake of it, spending money like crazy, and then wondering why it doesn't make any profit$.

Re:Playing devil's advocate

[21mhz]

I'm using Ubuntu because 1) Redhat basically abandoned the desktop,

Hmph, I'm using GNOME 3 on Fedora and it works OK, not worse than on Ubuntu at any rate. They have even added MATE into the distro for those who are outraged about GNOME 3.

Re:"our own thing — we can do exactly what w

[Anonymous Coward]

Lots of open source project start behind a curtain and then get opened up for all to see, use, change etc.

Personally I like the network nature of X but with lots of things like VNC some of what X brings isn't needed.

Re:"our own thing — we can do exactly what w

[Anonymous Coward]

"Lots of open source project start behind a curtain and then get opened up for all to see, use, change etc."

Fait accompli

Just pulling a Google

[Anonymous Coward]

Not many people were bitching when Google went a lot farther than this with every aspect of Android-- some were, but then Android was a huge success and then Google started committing their changes upstream and people shut up about it. This is JUST a display server that's being talked about right now. Can you imagine if Canonical took wayland and dumped so many patches on it that it became something completely different, with different requirements, different goals, etc? They want something different, so they're making something different. It's not complicated. Calm down.

Re:Just pulling a Google

[Rosco P. Coltrane]

Not many people were bitching when Google went a lot farther than this with every aspect of Android

There's a small difference: Google wasn't a two-bit Linux shop with a chronic lack of cash.

Re:Just pulling a Google

[FranTaylor]

Not many people were bitching when Google went a lot farther than this with every aspect of Android

There's a small difference: Google wasn't a two-bit Linux shop with a chronic lack of cash.

Android was a two-bit Linux shop with a chronic lack of cash UNTIL GOOGLE BOUGHT THEM

Re:Just pulling a Google

[serviscope_minor]

There's a small difference: Google wasn't a two-bit Linux shop with a chronic lack of cash.

There's another thing. Google aren't trying to replace the GUI on desktop Linux. You could expect a lot of justified whining if google tried to oust X on the desktop.

Re:Just pulling a Google

[GovCheese]

That Canonical's citing of Wayland's limitations were mostly refuted speaks to the larger issue of Canonical just not speaking to the non-Canonical dev community. Or at least this is the perception. Now that Caonical has influence, the non-Canonical devs perceive more and more that Shuttlecock is effectively developing a closed system that abandons the cooperative consensus that has driven community progress in the past. And when their Contributor License Agreement provides for non-free copyright, if Canonical chooses, with contributions toCanonical code, the fear is heightened. Of course the lens/privacy issue confirmed that fear. Basically Canonical is seen as more and more as throwing its corporate weight in ways that aren't pretty. It may or may not be good for linux going mainstream, but it's not pretty.

Re:Just pulling a Google

[DragonWriter]

There's another thing. Google aren't trying to replace the GUI on desktop Linux.

Well, arguably, they are -- via ChromeOS.

But not in a desktop OS that has a history as a traditional-style desktop Linux distribution.

Re:Just pulling a Google

[mbkennel]

I'd be quite happy if Google tried to oust X on the desktop. They could commit Apple-like resources if they chose to.

Canonical isn't good enough, and rich enough to do a good job---that's the problem. A bad job here is worse than spending their modest money working on something else.

Why not X?

[Damouze]

Why not continue using and developing on and for X? It is and remains -the- standard way for UNIX applications to get a graphical user interface. X is also largely platform independent. If I want to run my X server on system A and the applications on system B, it is the X protocol that separates my desktop from my applications. My display is not necessarily directly connected to the computer I run my applications on.

Re:Why not X?

[FranTaylor]

It is and remains -the- standard way for UNIX applications to get a graphical user interface.

Yeah let's just FORGET ALL ABOUT OSX, it is UNIX and it has a graphical user interface!

And if OSX is not "standard" well then WHY are "standard" UNIX applications like emacs and firefox written for it?

X Windows is also the standard way for VMS applications to get a user interface, but you neglected to mention this valuable addition to your pathetic argument.

Re:Why not X?

[Tailhook]

Yeah let's just FORGET ALL ABOUT OSX

Yeah let's just FORGET ALL ABOUT Android, it is UNIX and it has a graphical user interface!

Mozilla Firefox is on Android too!

Wait for it.... Waaaaait.....

YES, EMAC FOR ANDROID! Yay.

You neglected a bunch of stuff you stupids, pathetic and stupid, hrmph.

Remember; on sentence per line, just like they taught you.

Stupids.

Re:Why not X?

[FranTaylor]

duh, your are just proving my point!

X windows is NOT "standard"

Re:Why not X?

[ultranova]

My display is not necessarily directly connected to the computer I run my applications on.

But it almost certainly is, so it makes more sense to optimize for that and handle special cases with things like VNC - which also has benefits which remote X doesn't have, such as the ability disconnect from the remote machine without force-quitting the apps through X disconnect.

Re:Why not X?

[Anonymous Coward]

OS X is certified Unix. Android is not.

Re:Why not X?

[Alex Belits]

Windows is "certified Unix". And there is Emacs port to it.

The problem is, it's shit, its design is shit, and the only way to do anything with it is in its shitty Windows way. Same applies, at lesser degree, to OSX, iOS and Android, but iOS and Android have an advantage of being used only on phones and tablets, devices that were never intended to do general-purpose computing.

On the other hand, my Maemo-based N900 works remarkably well for its microscopic by modern standards CPU, and its GUI runs entirely on X11.

Re:Why not X?

[Anonymous Coward]

I don't think you are using the word "standard" correctly.

Re:Why not X?

[Damouze]

Let's try and keep this discussion civilized shall we?

There are lots and lots of reasons I -prefer- the X11 way of doing things over anything else. But what I said has very little to do with my preference, and everything with the concept of established standards.

X11 is such a standard. Unless you don't care about portability or network transparency (in its true sense), for example when you're working in an embedded environment, X11 is the standard way to separate the display from the application. The X11 protocol is largely hardware agnostic - the X server handles direct hardware access, and provides client applications an interface to work with. It does not matter if you're working through a UNIX socket on one and the same host, or through a remote network connection, your application will work independently of the actual hardware you're running on. So, an old SGI or SUN workstation could be perfect display host for heavy duty applications because the applications themselves run on a heavy UNIX or Linux host or cluster.

Rio

[Anonymous Coward]

The first company to get a web-browser running on Rio/Plan9 advances to Alpha Centauri.

Re:Rio

[Anonymous Coward]

The first company to get a web-browser running on Rio/Plan9 advances to Alpha Centauri.

No, the first to get all of the current open source gui applications to work on Plan 9, including KDE and Gnome, plus writes Plan 9 drivers for all recent graphics cards advances to Alpha Centauri.
Sigh.
If only we'd picked Inferno and Limbo instead of Java it all would have happened already.

Re:Rio

[Anonymous Coward]

You get pretty close to it with plan9port.

Not entirely the wrong choice though

[dbIII]

Since Wayland hasn't got very far yet there is little to lose by starting a different project that does some of the same things instead of extending Wayland.

Re:Not entirely the wrong choice though

[Plombo]

Wayland actually [i]has[/i] gotten quite far, though. It's still not ready for widespread use, but there is a lot that goes into a display server, and most of that is in Wayland currently. Mir, on the other hand, is nowhere near that. Just look at the to-do list for Mir. Mir doesn't even have basic things like resizing windows or any form of window decorations yet.

Re:Not entirely the wrong choice though

[dbIII]

How about a link to what Wayland can do now instead of taking the easy, pointless and misleading choice of pointing out that a freshly commenced project has only just started? Play the ball instead of the man.

Ignorance on display

[FranTaylor]

You're just betraying your ignorance of Wayland. Wayland does NOT replace X windows. In fact Wayland was designed from scratch so that an X server can run in wayland WITH NO PERFORMANCE PENALTY.

So with Wayland you can STILL run your old legacy X11 apps and get decent performance too!

Win win all around! What is the downside?

Re:Ignorance on display

[overbom]

It wasn't invented at canonical from what i can tell from TFA.

Re:Ignorance on display

[FranTaylor]

huh?

Re:Ignorance on display

[Anonymous Coward]

> What is the downside?

The downside is that a lot of development resources are being funneled to the rewrite of functionality currently quite well implemented by Xorg. Wayland wikipedia article doesn't shed light what are the benefits of Wayland for the end users.They keep talking in terms of reshuffling of some structural blocks, and that Xorg became way too complex, blah, blah, blah... No benefit for users. What can I do with Wayland that I couldn't do with Xorg?

Re:Ignorance on display

[FranTaylor]

what are the benefits of Wayland for the end users. No benefit for users. What can I do with Wayland that I couldn't do with Xorg?

You can have a display server with 10% of the code and 10% of the bugs!

TELL US MORE about how pruning dead code and reducing the number of bugs is not a benefit for the user.

TELL US MORE about the benefits of maintaining DEAD UNUSABLE remote code! WHY should users put up with the performance issues associated with years and years of X lossage?

Re:Ignorance on display

[FranTaylor]

The downside is that a lot of development resources are being funneled to the rewrite of functionality currently quite well implemented by Xorg.

QUITE WELL MAINTAINED???

do you actually use X windows at all?

It's buggy as heck and its performance is miserable.

Your crack about "developement resources" is pretty funny because the original X developers are also developing Wayland because they are SICK of funneling their development resources into fixing X bugs.

Re:Ignorance on display

[gl4ss]

the article is about canonical inventing an inhouse wayland/android-display-handler clone.

not about wayland.

the question is, why ubuntu needs this and why can't they go with wayland? are they planning on not releasing this - and using this for interfacing with closed source embedded drivers(actually- this wouldn't be a bad guess??).

Re:Ignorance on display

[Anonymous Coward]

> do you actually use X windows at all?

I use it 100% of time (time on computer that is), and never experience any noticeable issues.

> It's buggy as heck and its performance is miserable.

Really? How did you come to this conclusion? What testcases are you comparing on what platforms?

I use kde4 on xorg with transparency enabled, day in and day out, and never see any performance issues, or any issues at all.
It is actually a very nice desktop system. I see some bugs in various pieces of software daily, mostly in browsers, mail clients, messaging clients, office suite, etc. But it has been a very, very long time some defect or poor performance in xorg or window manager caught my attention.

Re:Ignorance on display

[FranTaylor]

What's the problem if it's all "under the covers" ???

Most users don't give a rat's ass about the display software. It's hidden under many many layers.

Shoot, even application developers should not even care at all. This is why we have toolkits like Qt, so nobody has to care about display software.

And besides, maybe an alternative to wayland will point out its deficiencies and encourage its developers to make it even better!

Believe it or not software projects can coexist! And PLEASE read "The Mythical Man Month" before you start talking about how the Mir developers could be helping the Wayland developers.

Re:Ignorance on display

[serviscope_minor]

You're full of FUD today.

That code is old and very long since debugged. Also, while it was big in 1987, it sure isn't now.

Secondly please FUCK OFF and stop telling me how I don't use remte windowing.

Re:Ignorance on display

[serviscope_minor]

legacy

Know how I know you're biased?

Also what you are saying is a lie. There is a performance penalty and there are downsides. The lagacy Wayland apps can't be sent to a remote X server. Also the legacy Wayland apps, just like the lecacy Windows and legacy OSX ones won't integrate properly with the Xserver in terms of DnD and copy/paste and things like that.

Re:Ignorance on display

[xiando]

TELL US MORE about the benefits of maintaining DEAD UNUSABLE remote code!

Please tell me more about how I don't run remote programs on my local X11 screen over the Internet every single day. Please tell me more about how all the people who find this feature very usefull and use it daily wil be happy without that feature.

Re:Ignorance on display

[Bill_the_Engineer]

You're just betraying your ignorance of Wayland. Wayland does NOT replace X windows. In fact Wayland was designed from scratch so that an X server can run in wayland WITH NO PERFORMANCE PENALTY.

You should at least read the Wayland FAQ before calling someone ignorant. Because I think you'll be surprised about who actually is the 'ignorant' one. (Why even do an ad hominem attack at all?)

Wayland DOES replace X windows. It just allows you to run an X server alongside it (like OS X does). They even go so far as state that Wayland native applications will not offer network transparent remote rendering (you will have to run remote desktop software like Windows and native OS X). Also unlike your claims, the FAQ explicitly states that there will be some minimum performance overhead for X windows applications running within Wayland.

Re:Ignorance on display

[Anonymous Coward]

X11 = Application A runs on Server B, user is on workstation C in other side of country and is using application A as local but everything is running on Server B
Wayland = Application A is installed to user workstation C and Wayland emulates X11 to run Application A on Workstation C withoyt any connection to other computers

Yeah... sure really AWESOME!

Re:Ignorance on display

[Hatta]

So with Wayland you can STILL run your old legacy X11 apps and get decent performance too!

So? I can do that today. What does adding another layer get me?

Assuming adding the Wayland layer gets me something, what happens to my legacy X11 apps when everyone starts writing Wayland apps instead? Will those native Wayland apps support all the features of X? e.g. network transparency?

Re:Ignorance on display

[0123456]

do you actually use X windows at all?

I've rarely used anything else on a computer for the past six years.

It's buggy as heck and its performance is miserable.

No, it's not.

Re:Ignorance on display

[Anonymous Coward]

Actually, you should FUCK OFF. You do so much trolling on Slashdot that one might suspect your unemployed. Get off the computer, go outside and get a job, asshole.

Re:Ignorance on display

[Anonymous Coward]

Users will give a shit about it when nvidia or AMD won't make drivers or test anything for one or the other because they've concentrated their efforts on one of them. We have a hard enough time as it is with nvidia and AMD drivers on Linux... When shit doesn't work right on certain distros because of more fragmentation it's not gonna be good for users.

Re:Ignorance on display

[Baki]

But if all non-"legacy" clients don't use X anymore, I loose network transparency for modern applications. Which is horrible.
I hope all of this fails, and X survives as mainstream.

Re:Ignorance on display

[melikamp]

But no one is writing network-friendly apps for X anymore, and so network transparency is not nearly as useful as it used to be. All modern UIs are super-cluttered with pixmaps, 3d-borders, and shadows, and take forever to render over the Internet. There are vastly more efficient ways to do network transparency, they are available today, and they do not involve X at all: text-based interface, Web server + XHTML, remote procedure calls. Applications that do not support one of those are clearly not intended to be remotely run. I used to run Mozilla thunderbird over X, and can attest that it is a nightmare. High-speed Boston to Boston was almost unbearable, and T1 in Boston to high-speed cable in Sacramento was truly at a standstill. On the other side of the spectrum are applications such as transmission, with built-in Web-server and Web interface, that are pretty and highly responsive over the worst connections.

I am curious, what do you use remote X for?

Re:Ignorance on display

[Hatta]

Bullshit. The whole reason for supporting network transparency by default is that no one has to write "network friendly" apps. It "just works".

network transparency is not nearly as useful as it used to be

I use network transparency every day. With GUI apps that use pixmaps, borders, and shadows. With FreeNX, the extra rendering time is barely perceptible.

But even if you were right, for the sake of argument, and we had to choose between network transparency and pretty widgets, network transparency is the only sensible choice. Network transparency is a real feature that enables people to work better. Pretty widgets are just eye candy.

There are vastly more efficient ways to do network transparency, they are available today, and they do not involve X at all: text-based interface, Web server + XHTML, remote procedure calls.

But they require a serious investment in IT in order to work. Setting up and securing a web server is a lot more work than simply installing freenx, logging in, and getting to work.

Applications that do not support one of those are clearly not intended to be remotely run.

Fuck you. As the user, it should be up to me whether I want to run an app remotely. I don't use open source so I can be dictated to.

I am curious, what do you use remote X for?

Bioinformatics software that runs on a virtual machine in a data center. I perform analyses that eat a ton of RAM and display them graphically on

Re:Ignorance on display

[melikamp]

Applications that do not support one of those are clearly not intended to be remotely run.

Fuck you.

Is this a personal issue or something? Besides, I never claimed you can't run these remotely. Indeed, you can use X till hell freezes over and run anything you want remotely until the end of time. That doesn't mean that the software you are running on top was intended for remote use. Most software is not. And no matter how good NX is, XTHML will destroy it in interface latency, bandwidth, and security categories, and match in everything else.

Don't be mad at me for telling you this. Be mad at the developers who fail to provide the modern level of remote access for applications that obviously need it.

Re:Ignorance on display

[Trogre]

Look, I get that Wayland is great and all, and in fact look forward to using it on my primary workstations, but until it supports network transparency it is nothing more than a useless toy.

Re:"our own thing — we can do exactly what w

[OhANameWhatName]

the lack of helpful upstream collaboration

You've just got to get downstream from them.

remote X is garbage anyway

[FranTaylor]

Everybody says "ooh noooo don't kill remote X windows! it's the best!"

except for one thing: IT SUCKS.

Have you ever tried to actually USE remote X? It's just beyond horrible.

The failure is that X was designed for low-latency between the display and the application, and that use case is just not very useful.

In reality the display and the application are connected over a high-latency link and X is UNUSABLE in this context.

VNC does not assume a low-latency link and so it remains responsive and pleasant even over a crappy ADSL connection.

Go ahead and TRY to use Firefox remotely over your ISP connection. It's just a pathetic joke and you will kill it out of frustration before even a single page loads.

Try the exact same thing with a VNC connection and it works just fine.

Re:remote X is garbage anyway

[mvdwege]

I have done all you say is impossible, with little to no issues. So now we have competing anecdotes, how about next time you provide some actual data to go with your FUD?

Re:remote X is garbage anyway

[Anonymous Coward]

> Have you ever tried to actually USE remote X?
Yep. All day, every day. It mostly works fine (except that GLX hasn't yet been updated to cover certain features in OpenGL 3).

> The failure is that X was designed for low-latency between the display and the application,
Wrong. X itself goes to great lengths to avoid being affected by latency. Problems with latency are usually a result of either poorly-written applications or poorly-written toolkits, or both, not with X itself.

> VNC does not assume a low-latency link and so it remains responsive and pleasant even over a crappy ADSL connection.
VNC is limited by bandwidth. Also, it gets no benefit from any acceleration offered by the video hardware on the system which actually has a display connected to it. It might be able to use the video hardware on the server, except that's probably nowhere near as capable as that on the desktop system, and is shared between all users. So normally everything is rendered in software.
The net result is that I find VNC too slow even over a direct GigE connection between the PCs on either side of my desk.

> Go ahead and TRY to use Firefox remotely
Firefox is pretty much the poster child for "poorly-written X application", although admittedly the sheer complexity of its job is a half-way decent excuse.

Re:remote X is garbage anyway

[EzInKy]

No problems here with Intel and rare problems with AMD chips. Maybe you are tied to a company that doesn't like openness?

Re:remote X is garbage anyway

[EzInKy]

I've never had a problem with X on open source hardware. Only closed sourced shit causes problems.

Re:remote X is garbage anyway

[FranTaylor]

X itself goes to great lengths to avoid being affected by latency.

How about this quote from Keith Packard:

---

One of the design ``mistakes'' of X11 exacerbated by its very success is the extensible type system called atoms (as in the Lisp systems from which it was derived). This has been heavily used in the interclient communications protocols used between applications (primarily toolkits) and window managers. The InternAtom function requires a round trip to provide agreement among clients on a small (32 bit) handle for a string. A modern design would almost certainly avoid round trips entirely by using cryptographic hashes (or just using strings everywhere). Unfortunately, it is very hard to retrofit this

---

X was designed when CPUs ran at 8 MHz, the network ran at 10 Mbit and the display was black and white.

In 1985, the network was FAST and the computers were SLOW so latency was not so much of an issue.

Today the network is SLOW and the computers are FAST and so network latency rears its ugly head.

I have to ask: if it works so great, why does nobody use it? Why doesn't it work with sound? Why can't I use it for my Windows or OSX apps like I can with VNC?

If X makes it too hard to write a decently performing application, THAT ALONE is good reason to dump it

Re:remote X is garbage anyway

[FranTaylor]

Here are some RESULTS from an experiment done by lbl.gov

The first number is X windows tunneled through SSH
the second number is VNC
the third number is NX

Start Matlab (-nosplash) 9.6s 4.9s 5s
Open edit window 2.9s 1.3s 1.2s
Activate File menu 0.6s 0.1s 0.1s
Activate Edit menu 0.6s 0.1s 0.1s
Activate Text menu 0.5s 0.2s 0.1s
Close edit window, redraw main window 1.5s 0.4s 0.3s
Close matlab 0.5s 0.6s 0.6s

As you can see REMOTE X WINDOWS SUCKS

Re:remote X is garbage anyway

[FranTaylor]

really? no problems ever with open source X windows? How about lack of 3-D support? You've never had a monitor sync issue with nouveau? Nouveau works PERFECTLY with ALL of your Nvidia cards? You've never gotten a blank screen from the radeon driver? You're just not looking.

Re:remote X is garbage anyway

[Anonymous Coward]

I use it, the grandparent uses it. Several other commenters use it. That is not "nobody".

Re:remote X is garbage anyway

[dkf]

Have you ever tried to actually USE remote X?

I've used it over SLIP over a 9k6 baud serial line connection. I was running a document preparation system (Framemaker). The application startup time was frustratingly long, but the overall speed after that was acceptable. (This was about 20 years ago, and yes, I would have loved a faster connection. I didn't have one at the time though.)

Go ahead and TRY to use Firefox remotely over your ISP connection. It's just a pathetic joke and you will kill it out of frustration before even a single page loads.

The specific part that is slow when running remotely is any operation that requires the bulk transfer of a large buffer (in either direction). That's an operation that is frustratingly common with web pages (all those highly animated adverts!) and there are certain operations (video rendering) that should always be done locally to the display, but all other operations should not require that sort of thing. Some current implementations of operations (font rendering) may be done through buffer transfers as well, but that's really a quality-of-implementation issue: there's no actual requirement to perform them away from the display system.

Try the exact same thing with a VNC connection and it works just fine.

VNC's always felt sluggish to me, since we're doing dueling anecdotes. ;-)

Re:remote X is garbage anyway

[Anonymous Coward]

You must have Google Fiber or something... I use remote X11 apps over a LAN every day. Works great. I have tried running apps from work to home and vice versa and it is unusable. Running the same apps through NX and it's ALMOST like being local. VNC is okay but NX is far better.

Re:remote X is garbage anyway

[progician]

Nvidia cards aren't open hardware hence the open source drivers are born without proper documentation. No wonder that they aren't as good as the product of people who have access to that magic documentation. Just saying... The AMD hardware drivers should be improved, but hey, I actually remember problems with propriety software as well, even the the developer of the drivers happen to be the producer of the hardware.

Re:remote X is garbage anyway

[serviscope_minor]

This is a weird comment, especially from one so illustrious as Keith Packard, though perhaps not surprising.

In well written X11 programs...

An aside. There's no point in talking about anything else. You can make badly written programs for any system perform arbitrarily badly. X11 is no exception. It's only worth talking abotu well well written programs and how easy it is to write them.

Anyway continuing.

I've done quite a lot of Xlib hacking.

Atoms are 32 bit handles for strings. Strings (i.e.) atoms are used for all sorts of things on the X server. They name properties (chunks of data associated with each window), are used for MIME (and older) types in the copy/paste and DnD mechanism. That kind of thing.

The thing is that Atoms refer to immutable strings which describe things.

Mutable strings such as window titles and text data for copy/paste are held in properties, not atoms.

Now, it is true that a round trip is required to populate an atom, XInternAtom being the xlib call. However, this is indentionally being used in a deceptive way to prove the slowness of X.

The thing is that InternAtom is not called frequently. You usually need a small number of Atoms and you know almost all of them at the program startup. Not only that but sinec X is asynchronus, you can fire off all the InternAtom requests and then wait for all the replies. IOW, you need only to wait one latency chunk in order to populate almost every atom you will ever need.

And that happens once at the startup of the program.

If you're InterningAtoms frequently enough to get bitten by the latency of that call, then you are really not using the protocol in a sane way.

And once they're all set up, the 32 bit quantity can be used round trip free from then on. And that's a really tiny packed ot fround trip free data.

Re:remote X is garbage anyway

[serviscope_minor]

I'm also tempted to make an unkind jab at Keith Packard here, since he's shown signs of suffering from C hacker syndrome. Perhaps if he used C++ and set up a std::map in his program he could use strings throughout and not have to worry about efficiency of lookups or excessive roundtrips from inappropriate use of InternAtom.

Of course that would be much harder in C where you'd have to write your own hash map or RB tree...

Re:remote X is garbage anyway

[rec9140]

I use XDMCP over SSH all the time, daily.

I also use KRDC as well.

I have no issues with using it.

I don't wan't need waycrap. I don't need or want another layer for X to run on.

Improve on X, rewrite X so long as it is X and fully 100% backward compatible and 100% INCLUDES XDMCP.

Just because you whippersnappers don't get it or use is not my problem.

Re:remote X is garbage anyway

[Anonymous Coward]

For the benefit of those who have come to the computing party late, there were NO remote connections in those days (at least as it is being implied by the previous post). The X protocol was designed in an era when "remote connections" were still on the LAN. And it still performs very well in that scenario, even on 802.11b (11 Mbps) WiFi. And it is blazingly fast on 100 Mbps wired LANs. I use it all the time. I will not give this feature up.

Where the X protocol has latency problems is in wide-area networks due to the many back and forth exchanges in the protocol. The cost of the exchanges is amplified by the increased latency of the WAN. That is what people complain about. However, the NX folks have developed a solution that works very well for this scenario. You can think of it as a compression protocol for X. But it still is the X protocol at least from the perspective of the X client and server. It works and works well. Comparing the X protocol without NX is like saying that you have to send all correspondence by snail mail. It will work but most of us find the latency maddening. Not allowing NX to extend X is similar to deny the possibility of sending PDFs via email and forcing them to be printed and mailed.

Note: I am not saying we shouldn't improve UI protocols. I AM saying that just because YOU don't use remote connections (or are willing to accept or do not even see the limitations of VNC) doesn't mean that some of us don't make use of advanced features, such as remote access, afforded by X. Improve UIs by all means. Just don't force those of us used to working with multi-user multi-tasking operating systems into being crippled by the myopic imaginations of commodity OSs which were developed in the days when a system would only support a single person doing one thing at a time on their anemic hardware. If you give us something that does what we now enjoy but better, I am sure we will all be overjoyed. If not, don't be surprised if we aren't enthusiastic about your proposal. (In fact, our lack of enthusiasm may even be perceived as hostile.)

(Obligatory: now get off my lawn!)

Re:remote X is garbage anyway

[Anonymous Coward]

Hate to break it to you, but NX *is* a "compression technology" for X windows. Thanks for showing that X windows works BETTER than VNC over the WAN!

Re:remote X is garbage anyway

[Bill_the_Engineer]

Evidently you never heard of NX. It solves the latency issues quite nicely and you don't have to dedicate a port for each user's desktop like VNC. I use it all the time over a slow VPN connection, and the remote X window application is as responsive as my native applications.

Re:remote X is garbage anyway

[Hatta]

That's a fine argument in theory, but in practice X performs as well as any other display server.

Re:remote X is garbage anyway

[Hatta]

As you can see REMOTE X WINDOWS SUCKS ...unless you use NX. So the proper solution is not to ditch X, but to build NX into X.

Re:remote X is garbage anyway

[serviscope_minor]

So your so-called "proof" is to point to a notorious piece of software, the modern MATLAB GUI.

Actually if you look at the old MATLAB gui, the results are very different. Since it could draw in OpenGL and that was remote accelerated, zooming, rotating, etc even complex 3D graphs was incredibly smooth over the network. It uploaded the data once and sent nothing but matrices and viewports after that.

Re:remote X is garbage anyway

[Anonymous Coward]

Have you ever tried to actually USE remote X? It's just beyond horrible.

Almost every day. I frequently use it here at work when I'm sshing into various machines on our network.

Here's the thing: I don't care how it happens, but I need the ability to ssh into another machine, run a graphical program on it, and have that program pop up in my GUI as though it were native. I don't need/can't have a desktop running on all these remote systems. X accomplishes this with zero problems for me. Now, if you have a replacement that works the same way but doesn't scare you, I'd consider using it; but the proposed alternatives always seem to include a lot more crap on top, because, as we're told, "you don't use X forwarding". Bullshit.

Re:remote X is garbage anyway

[Anonymous Coward]

I have to ask: if it works so great, why does nobody use it?

I know all I have is anecdotal evidence, but in academia, there's thousands of people using it. During my PhD I routinely used remote X. It worked fine for all we needed. Granted, the latency was small, as I was using it mostly in-campus, but it doesn't mean there's no use for it.

And concerning this "nobody use it"... how many people actually use VNC or the Remote Desktop Viewer of Microsoft? Compared to the actual computer users, people needing remote desktop-like features are always a minority. Hell, from my where I see it there's plenty more people using remote X than VNC or whatnot.

Re:remote X is garbage anyway

[0123456]

Have you ever tried to actually USE remote X? It's just beyond horrible.

I use it all the time to forward applications from one machine to another over my LAN. It works fine.

Yeah, it's sucky over a WAN, but VNC is sucky everywhere.

Re:remote X is garbage anyway

[Anonymous Coward]

It's SSH's fault, obviously.

Re:remote X is garbage anyway

[evilviper]

The failure is that X was designed for low-latency between the display and the application, and that use case is just not very useful.

It works superbly over any LAN, with SSH.

If you need to use it over a WAN or other slow network, NX is free and open, and works wonderfully... I'd hate to have to go back to using that horrible VNC.

Most importantly, NX is built on top of X11. It really just acts as a proxy, to get rid of those round-trips that need low-latency, and throws in a bit of compression as well. NX is awesome, and if there was no X11, there would be no NX.

If anyone wants to replace X without the network transparency, fine... Just give me something like Citrix/RDP/NX FIRST, before you tell me I need to adopt your crippled window manager. And "NO, VNC is NOT a sufficient replacement!"

Re:remote X is garbage anyway

[Trogre]

xpra is really a pre-requisite for anyone considering doing anything with remote X these days...

Re:remote X is garbage anyway

[Anonymous Coward]

Like others, I run remote X all the time for simple browsing. It is slower than over VNC, but overall it works fine. I have actually on several occasions used firefox over X as a quick workaround for bizarre networking problems where routers randomly decide to reroute traffic on certain ports.

remote X is even more garbage!

[FranTaylor]

sound? nope, not happening

3-d effects? nope, not happening

D-BUS integration? nope, not happening

what a mess. kill it now. even the X developers are actively working to kiil X

All those rants about X windows in the Unix Hater's Handbook are STILL TRUE

I think I speak for all of Slashdot...

[Anonymous Coward]

...when I say "GO FUCK YOURSELF MR SHUTTLEWORTH!"

Filter error: Don't use so many caps. It's like YELLING.
Filter error: Don't use so many caps. It's like YELLING.

regression

[stenvar]

They want to integrate the shell into the display server? Wow, we're really regressing to the dark ages of display architectures here.

mod parent up

[FranTaylor]

one of the few here who knows what they are talking about

Protobuf RPC mechanism - is it generic?

[Anonymous Coward]

Hi, I read somewhere that MIR uses a protobuf based RPC mechanism for communication between client and servers. Is that available already? Is it generic to be used outside of MIR? What lanaguages can be used to write clients and servers? Got any links?

Thanks!

Re:Protobuf RPC mechanism - is it generic?

[Ignacio]

mechanism for communication between client and servers

I hope you meant remote clients and servers. Otherwise it's just X all over again, but slightly different. One thing Windows and OS X get right is that their GUI is based around local API calls.

Re:Protobuf RPC mechanism - is it generic?

[FranTaylor]

One thing Windows and OS X get right is that their GUI is based around local API calls.

That's the difference in a nutshell.

The X protocol is limited by the fact that the whole API has to be serialized, and in many cases, a network round-trip has to be performed even though nothing is drawn on the screen.

And HELLO, accelerated video on the server is not much good when 90% of the latency is in the network. Oh big deal, you optimized the part of the system that least needs it.

Fascist commiters.

[Anonymous Coward]

It's entirely possible that Shuttleworth weighed up Wayland but discovered blowhard, insufferable assholes at the wheel. Why bother dealing with the deadweight? Wayland has been shuffling along for quite a while now and not really getting anywhere, why do you think that is?

Re:Fascist commiters.

[loufoque]

What you pointed out is actually a quality.
Code quality is important. If you can't satisfy the basic quality criteria, then of course your commits will be rejected.

See then believe

[Mister Liberty]

The other day I saw a video of some Wayland developer in front of
group of developers, some of whom were X developers.
It was really embarrassing.

The Wayland guy was all trying to be cool, second guessing X and
poking fun at it and presenting the image of how on earth we all could
have gotten by with tsuch a lousy naive piece of shit.

Almost noone in the audience dared to contradict this totally
unrespectful smug piece of shit, and point out the shoulders that his
shaky boots were standing on.

To me though I saw it coming that the joke was on him. Wayland is
just a name and a lot of foam and fuzz.
X has been around 30 years. They must have done SOMETHING
right.

Re:See then believe

[Anonymous Coward]

You know that the ppl behind wayland are the X devs right?

No upstream reviewers

[loufoque]

They don't want upstream reviews because they know their code sucks and they don't want people to point it out before they can get shit done.

Someone didn't do their homework...

[Mr Thinly Sliced]

We could have had a modern display server years ago with XGL/Xegl. But it was killed off because Red Hat and nVidia didn't like.

The disagreement was purely technical.

The XGL approach caused a bunch of peformance problems for various rendering scenarios (stereo3d, overlays like video) - XGL forced everything through a pixmap to be rendered by GL.

No acceleration using the GPU for video / scaling or anything else.

XGL was cool because it was first and everyone got googly eyed at the effects. It probably was a catalyst in getting the right solution (AIGLX), too.

Re:Someone didn't do their homework...

[Stalyn]

Those were issues with Xglx (mostly raised by nVidia specifically) which was supposed to be a stop-gap measure. Xegl was the long term approach. It wasn't just purely technical but rather a debate if the current X display server was salvageable. Red Hat and nVidia thought it was.

I reference David Reveman's post to the xorg mailing list.

I think the arguments made by nvidia to why X on OpenGL would be worse
than the current driver architecture can be debated on until forever. I
think it all boils down to if we want put some more effort to it and
take the big scary step to something new or if we want to stick to the
old well known. Not too surprising, we have people who are in favor of
both and we'll likely have development being done on both, which I don't
think is that bad after all.

So far I haven't heard a single argument for why X on OpenGL is a a bad
idea other than that it's a big step and a lot of work will have to be
done. If that would stop me from working on Xgl, I wouldn't have started
working on it in the first place

So yes I did do my homework. I did it 7 years ago and the teacher just forgot to collect it.

Re:Someone didn't do their homework...

[Mr Thinly Sliced]

Moving to Xegl would have been steps backwards until appropriate approaches for the problems I mentioned could be found. (How would existing stereo 3D GLX applications work? Very important to the people that use them. Video was a mess, too, what about multi-screens...) David was rather flippant about these problems at that time, but they were real roadblocks.

AIGLX provided a simpler route that didn't lose functionality in the meantime and didn't require writing a new driver. It wasn't just Red Hat / Nvidia bullying their way through here (your premise up the thread) - it gathered momentum as it was (at that time) the simpler way forward that didn't break anything. I think some of the Mesa drivers were first to implement AIGLX.

I'll agree Xegl did show promise in providing a single simple approach for driver development though.

So, given the nature of open source - if Xegl was superior, why didn't someone keep working on it? Why aren't we discussing Mir and Xegl instead of Mir and Wayland?

Re:Someone didn't do their homework...

[Stalyn]

Mir and Wayland both use EGL. They are both essentially what Xegl might have become if the appropriate resources were attributed to it. Xegl was dumped because a consensus was reached in the xorg community at the time that the current display server with AIGLX would be fine. They did not want to rewrite a X display server from scratch. Without the support of the majority of the xorg community, which was necessary for such an endeavor, the project just died out.

And there was a schism focusing on that XGL was developed in house, "behind closed doors", at Novell by David Reveman (who now works at Google). The majority of which came from Red Hat who offered and wrote AIGLX. Was there blatant bullying? Of course not and I never suggested such. But was there some jealously and collision of egos? Yes.

Re:Someone didn't do their homework...

[Mr Thinly Sliced]

Was there blatant bullying? Of course not and I never suggested such.

So did I misintepret your comment:

But it was killed off because Red Hat and nVidia didn't like.

I infered from that that Red Hat and NVidia actively looked to stop it. I apologise if that wasn't what you meant, it just came off that way.

The only reason (of two) I'm not runing Linux.

[Anonymous Coward]

The first is the graphics drivers. I have an ATI HD3450. All ATI HD cards below HD5000 level now are totally FUCKING BUSTED in ubuntu 12.04 and 12.10 and as far as I have tested only work in debian squeeze. I appreciate debian for what it is (the last version of linux that seems to support below HD5000).

Do you blame ATI? Do you blame the Xorg? Do you blame the kernel developers? What the hell is going on? Seriously? Oh well. For anyone using an ati HD card below 5000, you are stuck with windows unless you know something I don't. Please feel free to enlighten me. (And please dont say anything about the open source ATI drivers they are a total worthless peice of shit).

Re:The only reason (of two) I'm not runing Linux.

[ak3ldama]

I have no idea if you are just completely trolling or if you think you are serious... I have seen Ubuntu 12.04 systems with ATI HD3450 cards working perfectly fine - without needing the proprietary drivers. My system is a Fedora 16 box with a 4670 card and it also runs perfectly fine and doesn't need the proprietary drivers at all. I did a live boot of Fedora 18 and it ran fine though I have not done the install yet. I have no idea how you would want to say they are "fucking busted." Unless you specifically mean that in your delusional rage you cannot possibly run the regular drivers and thus attempt to use the proprietary drivers and these fail in some manner making everything "totally FUCKING BUSTED" for some reason. Wow... but hey those functional drivers must be a "peice of shit."

Re:The only reason (of two) I'm not runing Linux.

[Blaskowicz]

There's a workaround by downgrading Xorg that you may try
This is linked to in linuxmint 14's release notes, which are almost immediately reached from the front page when you when to get to the distro.. That's why I can provide you with this link even though I don't have ATI or AMD cards.

http://www.ubuntuvibes.com/2012/10/how-to-install-amd-catalyst-legacy.html

It's just about AMD saving money and resources. Blame them, and/or yourself because every one know only nvidia does fast and long term linux/unix drivers.

Munchausen Syndrome

[FranTaylor]

It's the only explanation I can think of for the defenders of X Windows.

They've been putting up with BAD for so long that they've lost all objectivity.

Re:Munchausen Syndrome

[Anonymous Coward]

*Stockholm Syndrome.

Canonical lately

[Britz]

Canonical is behaving very "weird" lately.

This is an interview with Jonathan Riddell, the lead on Kubuntu [1].

Quotes:

"I only had contact with the Linux Mint developer recently when Canonical claimed that they needed a licence to use the compiled packages from Ubuntu. This is a dangerous misunderstanding of copyright licencing from a company which should understand it. I advised Linux Mint to say some rude things to Canonical but I think they're too polite for that."

"Canonical has the trademark of Kubuntu so they had to get a trademark licence from Canonical which took many months of long and slow negotiations. It was very frustracting to have Canonical be the blocker for part of the Ubuntu community since Canonical should be an enabler for the Ubuntu community (at least when we don't compete directly). So we did look at changing the name of Kubuntu but were told by Mark we'd be kicked out the project if we did that which would be a worst case scenario for everyone."

"Since then Canonical has started asking for donations when downloading Ubuntu and one option is to give "Better support for flavours like Kubuntu, Xubuntu, Lubuntu Slider thumb". Kubuntu has never received any of these funds or seen any better support, so this is a disappointing case of fraud."

[1] http://www.muktware.com/5369/how-will-changes-ubuntu-affect-kubuntu-exclusive-interview-jonathan-riddell

Re:Canonical lately

[Anonymous Coward]

Canonical claimed that [Linux Mint] needed a licence to use the compiled packages from Ubuntu.

I don't know what this refers to, but...

I noticed that my current installation of Linux Mint (installed slightly less than two years ago) attempts to download some binary packages from Canonical's servers (and fails because the servers no longer exist, but that's besides the point). I'm sure this is entirely legal from a copyright point of view but it is rude as fuck. It's like embedding images hosted by other people in your own web pages, only worse because the amount of data involved is much larger. It's leaching and Canonical has every right to be annoyed.

Re:Canonical lately

[notknown86]

I'd recommend dumping ubuntu and moving to mint as the base for kubuntu.

The new name (first two letters from kubuntu, last two letters from mint) would pay an appropriate tribute to Mark Shuttleworth.

Wayland does not have remote capabilities

[Anonymous Coward]

Read all this cruft and nobody points out that wayland can't do remote windows like the x server can or like rdp

Re:Wayland does not have remote capabilities

[Plombo]

And neither can Mir.

The down side of 'doing our own thing'

[ThatsNotPudding]

The wonton destruction of openess and community that made Linux what it is today.

Shuttleworth has gone mad and has willfully made Ubuntu a priah.

Re:The down side of 'doing our own thing'

[Alioth]

Wonton is soup. Did you mean wanton?
Also, "pariah".

Signed, the grammar/spelling taliban.

Not in favor

[Anonymous Coward]

I appose this initiative.

Who cares?

[zenyu]

Neither of these have network transparency, and we're all going to be running a flavor Android on the hardware Wayland and Mir are targetted at.

Probably actually CADT.

[SEE]

I mean, NIH is one thing, but this kind of thing goes way past that. Ubuntu is in the full-throttle grip of CADT.

Closed Source Mobile device drivers is why

[NGRhodes]

Canonical wants to get into Mobile devices. Most of that hardware has closed source display drivers for Android (and iOS devices are totally off the radar). They want a GFX stack that is compatible with those drivers, to more easily get compatibility. They can't get that with Wayland. Cheers, Nick

Re:"our own thing — we can do exactly what w

[Anonymous Coward]

Mir is GPLv3, just saying.

If you run a house of developers, their decision is perfectly valid. Yes, collaboration over the internet is a good thing, but if you can just holler to the guy at the next desk, that's better collaboration-wise.

Canonical has something Debian has not, and that's a lot of people in the same office. Not taking advantage of this and refusing to shape their development-model around it is stupid.

Opposed

[Anonymous Coward]

As opposed to. Not apposed.

No problem, me likey options

[RedHackTea]

I see no problem with this in the initial phase. If developers are willing to potentially waste time and money, by all means please make multiple options. This is how our "system" has always worked. The one that users like the best will win, and the best parts/features of the others will be merged into the winner. Personally, I'd like to see at least 1 other candidate. The only problem will be if the developers of Wayland and/or Mir don't listen to their peers/users and for the potential problem of Ubuntu being the most used desktop "winning" simply because of their dominance. Hopefully, if Wayland truly is better from a developer and user perspective, a forked distro like Linux Mint will start using it instead over Mir. Then if most of the users start using Linux Mint over Ubuntu, hopefully Canonical will get the picture to drop Mir and use Wayland. Again, the problem is that Canonical is already building a reputation similar to that of Windows. They have dominance, so they refuse to drop Unity and/or the Amazon searches, even though very few users are okay with either. Luckily, in the Linux world, we don't have to put up with this and just switch to another distro/flavor. Either way, the future will be interesting, and I applaud any developers trying to come up with new solutions for X.

XInternAtoms

[Chemisor]

Yes, InternAtom requires a round trip, but only a newbie would use it often. If you have a lot of atoms (and any nontrivial X11 application does), you use the XInternAtoms call, which will stream all the requests into a single round trip. You can also use libXcb and do that to all the other calls as well. With proper design you only need 3-4 roundtrips to get your app fully loaded.

too many pessimist and stuck in the past

[Vince6791]

I'm guessing canonical wants more flexibility, better control, take advantage of today's hardware technologies. Better organization to improve development and to rely less on others to get things fixed. Like not having to wait on xorg to fix issues so canonical can improve it's compiz windows manager. It's probably same situation with wayland which the project and documentation seems to be disorganized just. It seems to me a lot of linux developers are stuck in the 80's and 90's mindset no need to create new technologies just stick with what works even if it does not take advantage of newer hardware technologies, this is what killed unix. This is why Microsoft is #1 at home and business they change and improve their software they always moved forward not backwards. Metro and Ribbon are both revolutionary and it's sad ppl don't see that.

  And why do linux zealots with their mental illness think what canonical is doing will destroy the whole linux foundation? There will always be tons of different linux distros out there. I personally like ubuntu(disabled amazon) and unity and it looks modern compared to the rest of the 1990's lxde, xfce, mate, etc.... Even kde(although graphics and text kind of fuzzy or blurry) is pretty damn nice but not a fan of the windows type start menu's. Canonical wants to turn their ubuntu distro into a usable gaming, business, home desktop to attract more users. I hope Canonical has great success with Mir and hopefully the rest would adapt and move forward on instead of living in the past.

Good to see the fragmentation

[Improv]

Hopefully it will keep us on X11 for the long-term, where we have network transparency. No proposed replacement without automatic and reliable network transparency for most apps is worth considering. Let Wayland and Mir die.

Low latency remote is a real use case

[Anonymous Coward]

The failure is that X was designed for low-latency between the display and the application, and that use case is just not very useful.

One damn minute, admiral. Here's something from real life. It happens a few times per week.

The application is Handbrake. (Background: Handbrake is a CPU-intense application which transcodes multimedia. Its input data consists of tens of gigabytes of data, and its output is a few gigabytes.)

I sit in front of a machine with an Atom CPU (ION) with no storage other than a small SSD. This machine has a keyboard and a large monitor (actually a TV). It was originally intended to just run mythfrontend all day, but its role has expanded to pretty much general-purpose.

The Atom machine is connected by wifi to another machine, which has a relatively fast CPU (ok, so it's only a quad core Athlon II 610e but everything is relatively fast compared to an Atom) and many terabytes of RAID1 disk. It is headless, and crammed into an out-of-the-way place chosen for convenient network topography.

IMHO it makes sense to run Handbrake on the machine which has the fastest CPU and also happens to have the data available on local disk, rather than have an Atom doing transcoding on NFS-over-wifi data. Agree? Please, please tell me you agree with that premise.

(Even if I upgrade the Atoms (low-power Core i3s could indeed be pretty good, and they would be faster than the Athlon II) there's still the issue of the network. Moving tens of gigabytes over my 802.11n network is slow, and always will be, no matter how you slice it. Even if I could run copper and use gigabit ethernet, it wouldn't be as good as local disk. Not to mention that once you introduce the idea of machine upgrades, I'm going to replace the Athlon II with an i7 long before I ever replace multiple Atoms with i3s.)

Handbrake over X has turned out to be a perfect fit, IMHO. Maybe you could show me tables of benchmark numbers and convince me

IT SUCKS

It's just beyond horrible

but in day-to-day use, I'm not able to spot the problem. OTOH if you take away my remote X and have me transcode on the Atoms, I'm not going to need benchmark tables to see the problem: I'll notice when something that used to take an hour, starts taking a whole day. Unlike X's deficiencies, it'll be within the realm of human perception.

VNC would be a bad replacement, I think, because it would mean the headless server would need to have some kind of graphic display running in the first place, for VNC to mirror. So I'll need gsm (or whatever its equivalent is) and maybe even have to make it auto-login. What a pain in the ass. I presume the machine would also need some kind of monitor hooked up to it, so that Wayland or Mir or whatever we're talking about, would know what size display to initialize and show. Thanks, your solution just cost me money on nearly-but-not-completely useless equipment. Assuming I have room on the shelf for a small monitor.

Dude, please. Don't make this hard. You're talking about a technological regression.

That said, I know the Handbrake example is a little unusual. There are lots of applications where the software is broken into a server and client, which communicate at a higher level than pixels (e.g. deluge-gtk and deluged). Or some are web apps (e.g. sabnzbdplus and your web browser). If Handbrake worked like that, I wouldn't need X.

But Handbrake, as it exists today, is what I have. Given this, I see low-latency X as a very real use case, it's making my life easier, and its performance is just fine. And Handbrake's authors, unlike the deluge and sabnzbd guys, didn't even need to think about it. That's the power of abstraction and indirection. Thank you, X11 team.

Re:Low latency remote is a real use case

[CaptSlaq]

This leads to the question "Why are you using handbrakeGUI when you could use the CLI?

Fragmentation? Choice!

[jjohn_h]

It was not easy but I forced myself to walk the fine G+ thread and I learnt a couple of things.

* There is plenty of animosity between RedHat and Canonical.

* Wayland is not the personal initiative of some individuals. RedHat is fully behind it.

* The Wayland developers were or are X developers.

* X is already sentenced but the death sentence will never be publicly executed. X will slowly disappear while "What's exactly wrong with X?" will linger on from here to eternity.

* Mark Shuttleworth used to be a classical South African pale male: a wrapper of soft talk around a core of hard lies. He can be sincere and rough now. Kudos to him.

* The meme has changed. No more "Linux is all about choice", rather "Don't fragment Linux".

* Mir isn't going to fail as some Redhatters wish to think but it will undergo a dozen reincarnations before its final release to users.

* I really hope I'm wrong here but it appears that neither Wayland nor Mir are in any hurry to modify the crappiest aspect of X as far as users are concerned: keyboard input.

Re:Fragmentation? Choice!

[unixisc]

It was not easy but I forced myself to walk the fine G+ thread and I learnt a couple of things.

* There is plenty of animosity between RedHat and Canonical.

* Wayland is not the personal initiative of some individuals. RedHat is fully behind it.

Why would Red Hat be behind Wayland? Red Hat does a server OS, which is fine even in console mode, so things like GUIs, windowing systems would be relatively irrelevant for them. I could understand it if Fedora was pushing it, but why would Red Hat care?

On a different note, what is Debian's position on this - will they stay w/ X11, or endorse Wayland, or Mir? I read recently that FBSD has just started working on Wayland

Re:Fragmentation? Choice!

[Anonymous Coward]

Why would Red Hat be behind Wayland?

Because they, contrary to your next incorrect statement about a server OS (implying it's only a server OS), make an enterprise OS with incarnations for both servers and workstations.

Red Hat does a server OS

No. Red Hat does an enterprise OS which can be, and is, used on servers as well as on workstations.

That's why.

You should learn more about things before making factually incorrect statements about them. Ask CERN, Fermi and a number of other large organizations.

What's actually wrong with X

[mbkennel]

"Mechanism not policy".

That's the Nicene Credo of X, and is what's wrong with X.

It was an interesting academic project at MIT in 1982-1984, with the not-particularly-publishable issues of policy relegated as a grad student project.

Policy, and good policy is the really difficult and very important part.

NeXTStep was substantially better by 1988.

Re:What's actually wrong with X

[serviscope_minor]

That's the Nicene Credo of X, and is what's wrong with X.

Or, if you prefer, it is everything that's right with X. And this is the reason X is still the superior GUI: it has heaps and heaps and heaps of Window managers to suit every taste.

NeXTStep was substantially better by 1988.

NextStep did many things differently including integrating a much more advanced display _mechanism_ (DPS). And pedant point, it was released in 89 not 88 :)

Noone had bothered to write a good toolkit for X11 in 1988 either: it was just out. Those things made Next nice. But the specific policy, not so much.

Re:What's actually wrong with X

[mbkennel]

"And this is the reason X is still the superior GUI: it has heaps and heaps and heaps of Window managers to suit every taste."

Except good taste.

Re:"our own thing — we can do exactly what w

[unixisc]

Mir is licensed under all 3 - BSDL, GPL3 and LGPL3. Anybody can take any edition of it and run w/ it.

X12

[markdavis]

>" In a separate post Halse Rogers answer the question: Does this fragment the Linux graphics driver space?""

Yes. That is why we should work on X12 and ignore anything else :)

I use remote X daily

[Anonymous Coward]

Everybody says "ooh noooo don't kill remote X windows! it's the best!"

except for one thing: IT SUCKS.

Have you ever tried to actually USE remote X? It's just beyond horrible.

Remote X enables some compelling use cases that are easier to manage and use compared to alternatives like VNC. We deploy some common X apps on local virtual servers (gigabit LAN). They are multi-user, concurrent access. ssh -X and Bob's your uncle. Simple, easy, secure, and more than fast enough in most cases on the LAN. Nice local WM integration, including cut and paste. It's a great system decomposition point in a virtualized environment. We get great stability for core apps even as our developers are constantly updating and otherwise changing their desktop software load, sometimes in ways that would break the app if it were installed locally.

I think it is too simple to dismiss X network transparency because it's slow. This doesn't seem to allow an honest assessment of its real capabilities and usability.

Mir only works with Ubuntu

[peawormsworth]

I dont mind if Ubuntu wants to recreate the wheel. But what I fear is that they will be too controlling over the X-like software. It seems like whenever you want to reconfigure a Ubuntu system running Unity, that there are all kinds of difficulties with getting it to display correctly. There is a limited set of Ubuntu supported applications that display correctly in the taskbar, but once you move ouside their default set and install alternate applications, nothing is integrated properly. Furthermore, the Ubuntu packages are tangled in such a way that it is difficult to remove apparently unrelated packages without removing everything else Ubuntu supplies. In one sense, this could be that Ubuntu wants to force the users to have a certain "look" or suite of applications to call it "Ubuntu". But in another sense, I feel that they are using this as an excuse to make it difficult for users to opt-out of their profit goals. Like the Amazon shopping cart integration and sending all the dash keystokes back to their servers in order to monitize it. Some users really like these automatic "features", while others see this as a potential security threat and a reduction of the privacy benefits linux offers. My fear is that Ubuntu will use Mir as a mechanism to control Ubuntu users into applications and services that channel much of our usage through them. And make it difficult for users to use Mir with a non-standard set of applications. In a similar way that Apple products channel everything through itunes for media usage. Generally itunes is a good product, but in another sense it is too much control over the users. It maximizes profits for Apple, but it limits consumer choice, especially when Apple has the final say over what will and will not be allowed to operate. Because it is in apples interest to make sure the content is channeled through them as the supplier of the media service. So the software is limited in a way that maximizes the channel that provides profit back to them. In the same way, I expect Mir will limit the end users free choice and encourage or force users to use the approved channels such as Ubuntu One and their set of shopping and advertising partners.

so glad I'm not a ubuntu sucker

[Anonymous Coward]

I never did see what the fuss was about ubuntu - I'm a smug debian user. Can you see and feel my smugness ? Its oozing everywhere.