Intel Says No to Ubuntu's New Display Server | Hacker News Reader

Intel Says No to Ubuntu's New Display Server

news.softpedia.com

103 pointshanuca94 comments

The site that plagues Google with shitty search results by scraping Github and other websites and removing source links brings us a summary of yesterday's news via a spam account.

For extra fuckwittery they even nofollow the source links they steal their news from.

Stay classy, Softpedia!

https://news.ycombinator.com/submitted?id=hanuca

https://news.ycombinator.com/item?id=6347244

Why don't we simply blacklist Softpedia and other bullshit sites from HN submissions.

For those interested, this comment is caused by this commit revert: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/com...

So originally the XMir support was merged in, then reverted on instructions from Higher Ups.

I can't really blame them, if they make driver changes Intel would have to adapt the XMir code to cope with them.

What is the reasoning for putting this code in the video driver?

The "Theory of Operation" comment in the merged-then-reverted code is insightful. Apparently, the code is supposed to figure out which parts of windows are damaged, and then tell the windowing system to do something about it.

IMHO, windows are not a concept that should even exist in the video driver [1]. They should be entirely under control of the windowing system. Which means that figuring out which parts of windows are damaged is logic that should totally reside in the windowing system, having no parts in the video driver.

If this code must be in the driver because it needs to access private data/functionality that's not visible outside the driver, then an API to expose those driver internals to the windowing system would be a design that better separates those layers.

Reverting this commit seems like a sound technical decision to me. Assuming Intel's decision is politically motivated, and then getting outraged about it, seems counterproductive.

[1] Even if this concept has already leaked into the driver for X or other windowing systems, doesn't mean that questionable designs used in old code should be allowed in new code.

Not really informed here but I would venture a guess that 'perfect separation of concerns' causes a performance hit. In the backend web dev world you can usually suck that up by making the load parallelizable across servers, something you don't have the option of doing with code running locally. In other words, 'separation of concerns' is great until you hit a performance bottleneck, as you often do with any resource constrained system.

"Reverting this commit seems like a sound technical decision to me."

Well, the commit message says:

    Ordered-by: The Management.

But I'm not sure what exactly means.

According to Phornoix, Chris Wilson of Intel wrote this in a Git commit:

We do not condone or support Canonical in the course of action they have chosen, and will not carry XMir patches upstream.

http://www.phoronix.com/scan.php?page=news_item&px=MTQ1NjY

Phoronix's link to said commit does not work, so it is hard to infer context. But I would assume that "the course of action they have chosen" refers to working on Mir in the first place rather than contributing to Wayland. If that's the case, can't say I really blame Intel.

""the course of action they have chosen" refers to working on Mir in the first place rather than contributing to Wayland. If that's the case, can't say I really blame Intel."

I absolutely blame Intel. Whatever you think about Ubuntu's decision to make their own X server, it is childish to not include working patches for purely political reasons. It's not like Ubuntu is asking Intel to do their work for them.

So Canonical got railed for not contributing upstream, and they try to contribute upstream they get everyone blaming them again? That's ridiculous.

Most upstreams will generally accept responsibility for keeping code working - just having it "merged" often means then handling bug reports, testing, etc. If the Intel people don't want to maintain specialized Ubuntu-only environments just to test the Mir codepaths, that's kind of their call.

It probably also didn't help that Canonical employees were using it as a political football to boot other GPU vendors, e.g. https://twitter.com/olliries/status/375704285083738112

It was Canonical's decision to fork, if they have to bear the costs of the fork then so be it.

The old classic argument around why Linux doesn't have a rigid internal API comes to mind (http://www.kroah.com/log/linux/stable_api_nonsense.html). Maybe there are commonalities between supporting Mir and Wayland that would allow Intel to create a more universal piece of software? If Canonical does the work to make the driver universal, wouldn't the whole community benefit?

I'm not a big fan of letting politics get in the way of engineering, and this smells of the fact that Intel is trying to battle ARM in a proxy war, with FOSS as collateral damage.

> Maybe there are commonalities between supporting Mir and Wayland that would allow Intel to create a more universal piece of software?

This still increases cost on the part of Intel.

XMir support in intel's driver uses a significant amount of separate code. I'm not saying intel's actions are ok, but XMir is not creating anything more universal.

What about the FUD storm about Wayland that Canonnical released? When Mir was announced Canonnical and Shuttleworth basically shat on every Wayland developer. They even edited and/or removed their statements later on, it was so bad.

When a company starts supporting something in public, it usually ends up amounting to a kind of commitment - such that reneging on the commitment has costs, in reputation if nothing else.

In other words, the cost of this patch is not just this immediate code, but ongoing maintenance and support of further features. Almost certainly the guy who pushed the patch doesn't have permission to enter Intel into this kind of commitment.

> Whatever you think about Ubuntu's decision to make their own X server, it is childish to not include working patches for purely political reasons.

Absolutely not. Projects need to take a strong stance on what to include or not because every piece of code in there needs to be maintained.

>Projects need to take a strong stance on what to include or not because every piece of code in there needs to be maintained.

In theory maybe.

In actual reality, from the 15+ years I follow Linux/OSS, projects are all to happy to NOT maintain code, let it rot, do tons of incompatible changes in major releases, or even start from scratch whenever they feel like.

Don't blame Intel. This driver is theirs to maintain, not Canonical's. If every distro wanted to create their own display server then should it be Intel's responsibility to merge in support code for all those display servers and to maintain all that code?

But the Xmir patches, were not a contributing upstream, in any meaningful sence. It's a we have our own project, here is what you need to make it work, and while your at it can you maintain them too (assumption, based on Canonical culture)

Code dumps (especially when the code is only to support your project(Xmir), rather then improving project(Intel driver) itself) != contributing

Choice is good, but for too long has open source been fighting among itself. I commend Intel for doing this. They're hardly alone after all, they're just joining Kde, Gnome, Enlightenment and all the other open source projects that embraced Wayland.

Maybe this means Canonical will focus more on ARM hardware now, which is kind of the point of Mir anyway - to be a lot more efficient on "lower-end" mobile hardware like ARM chips. Can't say I wouldn't like that to happen.

Or Canonical's packagers will just carry on patching the Intel drivers?

That works fine because Intel has open source drivers. Not so much if NVIDIA and AMD decide to only support Wayland.

True enough. No support for NVIDIA cards at all in current Ubuntu betas. I think even nouveau was falling back to X compatibility but I might have that wrong. It was sloooow

It would be smart to focus on ARM as a long-term strategy. There is a huge investment and legacy in x86 but if history is right, ARM will eat up x86 from the bottom-up just like x86 did to the other ISA's.

Of course the ARM future is not all that glorious. The open-source friendly ARM vendors are not that common, most ARM GPUs do not have (1st party) opensource graphics drivers.

Why would any party make such a hostile announcement in the FOSS scene? I'm not all that involved in that scene, but surely this approach is counter-productive? Especially if you can't back it with a sound technical reason.

> Why would any party make such a hostile announcement in the FOSS scene? I'm not all that involved in that scene, but surely this approach is counter-productive?

Something like this is actually quite common, and more or less necessary.

In proprietary software development, there is typically some hierarchical authority that makes design decisions. You might debate for a while, but eventually someone is going to come up with a decision of how things are going to be done. In FOSS, no such central authority exists, so design of inter-related projects is effectively a distributed negotiation. Usually, things are done amicably, everyone is happy to share each other's code, and disputes are handled peacefully. However, every now and then there is a situation where two entities simply cannot agree, and one of them has to put the foot down and say: "No, this is a bad idea, we won't spend the effort helping you do this. If you want it, do it yourself."

And since it's all a very public negotiation, making this kind of announcement is just one step up the ladder of escalation from a private email declining a patch. As flames go, it's rather tame. :)

> Especially if you can't back it with a sound technical reason.

Intel absolutely can, and has, for hundreds of times over the past few months. At some time you just have to give up on trying to convince the other people and do something useful.

I do not know this code but the diff, posted elsewhere in this thread, looks more than trivial to me. Such changes tend to have maintenance cost. If the original authors don't care about the functionality and aren't testing it, it's probably not worth keeping, as they may go through great pains to leave it in and still end up breaking it frequently.

It's not as if Canonical's approach was exactly uncontroversial either. My reaction to the Mir announcement was not exactly that I was overwhelmed by warm fuzzies, to put it that way, because I think they should collaborate on Wayland rather than doing their own thing for something as central as the display server.

IMHO, if it's a political decision, it's better to be upfront about it (as Intel was), instead of coming up with some technical excuse for it.

It seems there's similarities between Wayland and Mir:

http://en.wikipedia.org/wiki/Mir_(software)

"Mir, like Wayland, is built on EGL[6] and utilizes some of the infrastructure originally developed for Wayland[7] such as Mesa’s EGL implementation[6] and Jolla’s libhybris."

So why didn't Canonical just use Wayland, I thought that was their plan forward a couple of years ago?

Whatever they do I hope they don't screw up Ubuntu 12.04's excellent ability to play Steam based games.

EDIT: Read the controversy of the Wiki article, interesting insights.

What an awful move. Note that they are deliberately hurting open source software by restricting contributions for a purely political reason.

Obviously it will result in an Ubuntu fork of the intel drivers, which will eventually lead to a situation where the only consequence is a more painful workflow for Ubuntu core contributers and early adopters looking for up to date drivers.

Ubuntu is creating Mir for political reasons. There's no reason for upstream projects to maintain code that only benefits a single distribution.

Yep, all of their technical reasons have pretty much been debunked. The reason for Mir's existence is mainly about project control. As Matthew Garrett mentions[1], they likely need that control for Ubuntu Phone to be able to relicense the code to keep their hardware partners happy.

[1] http://mjg59.dreamwidth.org/25376.html

This is why I think licenses such as AGPL and GPLv3 are hurting open-source (and Free Software). The intentions behind them are good, but in practice they are used in parallel with commercial licenses that have nothing to do with open-source.

There is nothing wrong with dual licensing, even RMS has said:

"I've considered selling exceptions acceptable since the 1990s, and on occasion I've suggested it to companies. Sometimes this approach has made it possible for important programs to become free software."

His reasoning is that selling proprietary licenses to otherwise GPL'd code is reasonable since it enables companies to do the same thing that they would be able to do if a project was dual licensed with GPL/MIT. Since he does not consider MIT/X11 style licenses wrong, merely inferior, he concludes that selling GPL exceptions is reasonable:

"When I first heard of the practice of selling exceptions, I asked myself whether the practice is ethical. If someone buys an exception to embed a program in a larger proprietary program, he's doing something wrong (namely, making proprietary software). Does it follow that the developer that sold the exception is doing something wrong too?

If that implication is valid, it would also apply to releasing the same program under a noncopyleft free software license, such as the X11 license. That also permits such embedding. So either we have to conclude that it's wrong to release anything under the X11 license -- a conclusion I find unacceptably extreme -- or reject this implication. Using a noncopyleft license is weak, and usually an inferior choice, but it's not wrong."

http://www.fsf.org/blogs/rms/selling-exceptions

Well, I think RMS is wrong. The fact that these licenses cannot be used in certain contexts, such that commercial licensing is justified, does hint to them not being really open.

Here's a quote by Linus Tolvards, when discussing GPLv2 versus GPLv3:

GPLv2 in no way limits your use of the software. If you're a mad scientist, you can use GPLv2'd software for your evil plans to take over the world ("Sharks with lasers on their heads!!"), and the GPLv2 just says that you have to give source code back. And that's OK by me. I like sharks with lasers.

> does hint to them not being really open.

And what does "really open" mean?

Software licenses exist to define situation the author can live with, and which ones he would be unhappy about. Some authors:

Do not care at all (WTFLicense).

Demands attributions, and would be unhappy if someone else falsely claim authorship of the authors software (MIT/BSD).

Demands that companies not go and backstab customers and sue them over patents for code they themselves have redistributed (Apache).

Demands the same as all above, but also that users get the source code of the program that they have bought/received. (GPLv2)

Demands the same as all above, but that users can actually use modified version of the source code. (GPLv3)

Demands the same as all above, but adds a clause about users of web services are equivalent to customers who buys software in the store? (AGPL)

So I must then ask, which one is the "really open"? Only WTFlicense? Only BSD/MIT and above?

It's more direct and clear to state the real problem. The real problem isn't the AGPL or the GPLv3, as both of those licenses can be very good in the right context. The real problem is copyright assignment to companies like Canonical, as in practice that is equivalent to dual licensing where the second license is "let this company do whatever the fuck they want".

As I said, the intentions are good, but in practice these licenses are used as an actual incentive for companies to purchase the commercial alternative for redistribution.

But that's only true for a small minority of GPLv3 software. The exact same small minority that requires copyright assignment to a for-profit corporation.

Saying "licenses such as AGPL and GPLv3 are hurting open-source" is complete and utter FUD. A non-FUD way of saying it would be something like, "copyright assignment to for-profit corporations hurts the free software movement".

If there is no copyright assignment to a mischievous corporation, then GPLv3 is practically strictly superior to GPLv2 in terms of software freedom.

Wayland is not under such licences. It uses the MIT license.

I think bad_user is talking about Mir: it's licensed under GPLv3 [1].

My point was more that license was no reason, Wayland already has a good license. Mir is first under a different license to then require a special CLA to be able to license it differently. In Wayland everyone has the same rights.

I am in complete agreement with you. I don't see any reason for Mir other than Canonical choosing to go their own route in an attempt to persuade businesses to buy commercial licenses for it.

This is something Canonical should have considered before developing they're own display server. The community attitude from the start seems to generally be "we won't carry support upstream", so this doesn't seem unreasonable.

Who's saying Canonical hasn't considered this? If this truly reflects the community attitude towards a new open source project than that is an awful thing.

No one is saying it, but Wayland is just a display server, and worse, it's just a display server that's been developed on by just one guy in what is clearly his spare time. For years, and it's still not something we can readily use.

If instead of Canonical this was just a random dude with a kickstarter project, promising that if he built this something new he would get NVidia and AMD in on it we'd all be cheering them on.

We want a replacement for X. Wether it's Wayland or Mir, the community shouldn't care. If both of them grow up to be great display servers, then the projects can have their choice. Why make that choice now, when Mir isn't anything yet, and Wayland looks like an infinite road to nowhere?

So there you have it, a bad comment about Wayland. Why? Because I'm frustrated. X has been a pain in our collective asses for so many years, and the project that was going to change that receives almost no support. It's just this one guy going at it. No vendor support, no distro support. No one wants to touch it, so it takes 5 years to get to this point where it seems like it's almost ready for adoption, but still no one builds a desktop environment for it or any vendor interest.

Then a company just goes for it, allocates significant resources to it, and even uses its connections and leverage to get vendors in on it, and makes sure there's going to be a desktop environment for it. And the whole community just goes 'boo!'? what is that about?

What's the community got to lose? Why is it hurt? What has it invested in wayland?

I'll say it. Nothing. Just some code some dude made that's possibly going to be obsolete if Canonical succeeds. And if not, then Canonical made some obsolete code, which is their business risk, not ours to judge over.

If you ask me, the community should be positive. What have we got to gain? A possible X successor that's got multi-vendor support and a desktop environment that works. It's going to have a nice interface, takes up a lot of design clues from wayland and generally is going to kick ass if it works out.

I'm not sure why, but you seem unaware of the massive community effort that has already been plowed into Wayland and the massive loss of credibility the community suffers when it's wishy-washy about display infrastructure without Very Good Reasons. Qt and GTK have already been mostly ported, driver code has been contributed in various projects over the last 2-3 years, and other major efforts have been invested into Wayland to break the iron hand of X11, and then Canonical ignorantly struts along with Mir and jeopardizes the whole thing.

If we want big hardware players like nvidia and intel to take us seriously, we must behave in a professional manner, and one of the biggest players in the space creating an incompatible fork on such a fundamental piece of architecture five years after a similar project began making inroads, basically because "We don't have anyone smart enough to understand Wayland", is _not_ professional.

Maybe this would've been justified after Wayland support went mainstream, but all Canonical has accomplished by the release and announcement of Mir is the further entrenchment of X11 by accentuating what a horrendous wreck it is to attempt to remove it.

What are you even talking about? Most of the Wayland developers work at Intel.

Also, not even other *buntu maintainers are going with Mir, so unless you are equating Canonical with open source, you must be a tad lost.

Oh yeah, all of those Wayland developers:

https://github.com/nobled/wayland/graphs/contributors

I'm not equating Canonical with open source, I'm equating what they're making with open source. Because it is. What are you even talking about?

I don't know how github generates that data, but if you page through this:

http://cgit.freedesktop.org/wayland/wayland/log/?qt=author&q...

It paints a very different picture about the distribution of authorship.

Hmm, you are right. That's a bit awkward, git doesn't actually track authors, it just tracks committers. So there's actually a bunch of authors, and krh is just committing for them. Woops, sorry about that :) Would like to see a graph that shows authorship though, very interested in how large and active the wayland dev team actually is.

I don't see how it's political to let Canonical keep the burden of maintaining code that only they care about...

Is that what is happening here? Intel's explanation of "The Management" handing down orders doesn't imply technical reasons were the motivation. It's unclear.

If there are technical reasons - like the one you mentioned - let's hear them, they might be valid.

I don't think I mentioned any technical reason? Allocating developer time is generally a management decision.

If anything, Intel has already put their resources into Wayland and the lack of any good technical reasons for Mir's existence probably played a large role in their decision.

I don't see why this is so shocking really, many other projects in the Linux graphics stack have already said that they won't be supporting Mir upstream any time soon. At this point, I'd be more surprised of hearing a project supporting Mir than the other way around.

Does anyone else see the "-The Management" comment as having more than a tinge of sarcasm? I think people are taking it a little too seriously.

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/com...

Note "Ordered-by:" line, clearly intended to communicate Chris Wilson was ordered to do this, rather than doing it of his own accord.

You still see no attempt at humor or lightheartedness in this? May I remind you that his email ends in .co.uk, so many people may need to apply a "British humour filter". Most of his commits have "Signed-off-by:" with a name; he replaced "signed-off" with "ordered" and the name with a vague reference to "The Management".

The further context I was thinking of was this:

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/com...

I'm obviously aware of both commits, and of much, much further context beyond the commits. No, I see no humor or lightheartedness. Signed-off-by is not just something Chris made up, it's a pseudo-standardized line for git commit messages.

Further context I'm aware of is that Chris explicitly accepted and applied the patch after working with the developers to get it right, along with other signs of cooperation.

Yet more context I'm aware of is much of the political bullshit surrounding Mir, Wayland, Canonical, Red Hat, Intel and really the entire FOSS community at this point.

This isn't a joke. This is Intel's management intervening.

> I'm obviously aware of both commits, and of much, much further context beyond the commits.

Maybe you should share that first, rather than leaving it implicit. (If your comment tells the whole story I am unconvinced. OK, so the guy merged a patch, then it turns out he did not in fact have the blessing of his employer, so he reverted it with a slightly snarky commit message. Any more context I should be aware of beyond that? It does not sound like a huge conspiracy to me.)

Edit: also, what does "The Management" mean? This guy's immediate supervisor? Intel CEO? I feel like some people are taking an oddly paranoid reading of the situation. I don't know anything about Intel specifically but I have worked at a large company, I am willing to bet that the higher you get in Intel's management the less they care about Ubuntu.

No, I'm not about to spend days or weeks trying to impart knowledge of the history, values, and practices of the entire FOSS community on you.

You're free to continue acting smug about things you don't understand and building strawmen left and right (I note this is at least the second time in the last week you've done this), but you should stop expecting others to do the heavy lifting for you.

You made it sound like you had inside knowledge of Intel's decision making process that is relevant here. If that's the case I think you should disclose it instead of getting mad at me or assuming it is universal knowledge.

Our thread from last week is totally unrelated to any of this. I would rather not engage in discussion that is based on personal animosity. Let's stay on topic.

No, I didn't make it sound like that. You are, once again, inventing a strawman, and drawing wild conclusions based on insufficient knowledge. Last week's thread is not unrelated. It shows the same pattern of inane, bad-faith behavior.

So saying that publicly signing something "The Management" while working in a company the size of Intel is comically vague, and saying people should lighten up a bit without additional info and perspective, that is acting in bad faith? I am not trying to offend anyone with this commentary, it is my own opinion.

> So saying that publicly signing something "The Management" while working in a company the size of Intel is comically vague

You didn't say that.

> saying people should lighten up

You didn't say that, either. Which is good, because "lighten up" is not, has never been, and will never be a reasonable thing to say to anyone, anytime, anywhere.

Your original comment wasn't unreasonable. Where you started going off the rails was initially with "May I remind you", which is patronizing.

Then "Maybe you should share that first, rather than leaving it implicit.", chiding me for failing to magically know that you lacked knowledge that is relatively common within the set of people who care about the subject at hand.

Then you characterized my statements as describing a "huge conspiracy". Being unaware of any "huge conspiracy", only a lot of wide-open politics, this is, to me, at once puzzling and insulting. "oddly paranoid" makes it even worse.

Then you accuse me of pretending to have inside knowledge of Intel, when I did no such thing, and did not intend to, and say I should "disclose" this thing I don't have, as if I'm trying to hide something.

And now you seek to rewrite history.

I am pretty sure I did say these things. But nevermind. More importantly I don't think I'm guilty of nearly the malice you ascribed to me, and a part of me is wondering where you are based on the off chance we can share a beverage of your choice and you can see I'm not a monster. Is it the thread from last week that has you angry at me?

I didn't even know who you were until your third comment, which sounded eerily familiar. And there are certainly no circumstances under which I would voluntarily associate with someone who displays your pattern of lashing out whenever they don't understand something.

Well, I tried. I would humbly suggest that one person's "lashing out" could be another's simple misunderstanding.

In the meantime I think there is a phrase you used to describe me, something along the lines of "willful misinterpretation"; I believe you may have done the same for me.

Canonical wrote the initial patches. It stands to reason they will also be fairly heavily involved in maintaining them. That's a fairly thin argument against incorporating patches upstream.

Almost by definition, most of the patches I've committed to upstream are things that I was the first person to care enough about to write a patch. It's nice to see other people use them, but the idea that "why should upstream carry your patch when you are the only one that cares about it" is a bit counter to what has made FOSS get this far. Especially when "only they care about it" still represents one of the largest blocks of users.

I'm sure upstream would be more willing to work with Mir if there was technical reasons for its existence. As it stands, Mir provides no benefit to anyone but Canonical, who simply want control. That control comes at the cost of fragmenting a fragile part of the ecosystem. You can't expect the rest of the community to be okay with that.

Ubuntu is the one that decided to go their own way. Why does Intel have to support them?

The reason for starting Mir is still unclear to me. The is a very real cost of maintaining Mir. If you're not Canonical, why would you spend money, time and complexity for an unclear benefit? Better have it stay Canonical-only.

You are of course assuming Ubuntu can maintain Intel drivers, which given their upstream contribution track record might be a tall order.

This is a great comment in that it shows the cognitive dissonance of slamming Canonical for trying to commit upstream while also slamming them for their past lack of upstream commits, in a handy Twitter length package.

Sorry, but sending code upstream for their distribution-specific display server (which has no technical reasons for existing) isn't benefiting the rest of the community.

Given the size and content of the patches under discussion here, I think they'll be fine maintaining that level of Mir integration with the Intel drivers themselves.

Sure, Intel's actions are more symbolic than anything else.

Ubuntu has received a lot of flack for their aggressively NIH attitude, but being able to point to support for their NIH-motivated products in other widely-used software would signify some amount of acceptance of their actions in the wider community.

I think their are many people who don't want to send that signal.

Does not surprise me.

Many guys in FOSS tend to like Intel, but not all Intel departments are FOSS friendly.

Even the graphics division, tends to put more resources into DirectX tooling and processors like the PowerVR family, than what they contribute to X.

This is not about FOSS, it is about one man's vision to circumvent the mainstream developer community. Ubuntu chose to make the transition from pre-configuring Debian and making compiz themes for Gnome to trying its hand at systems-level programming. It would be somewhat self-assured of them to assume that all hardware vendors, who are already heavily invested in Linux, as a platform, would necessarily pick up the slack, especially when those investments did not foresee a move like Mir.

I don't say otherwise, just that Intel as a company is a corporation like any other, with contributions to FOSS also driven by internal politics.

I don't think it's entirely a corporate move here. Free software contributions aren't infinite; if you have $N developers working on integrating support for display servers, then it's simple math that having to support two display servers means that you'll have $N/2 developers working on each, and will therefore get half the work done (and, since they'll probably still have to support X11 for a while, make that $N/3). Ubuntu selfishly forked Mir instead of choosing to try to use Wayland (especially when they had originally committed to using Wayland[1]), so the burden is on them here. It also doesn't help that Canonical employees were using the inclusion of XMir support as political fodder[2].

[1] http://www.markshuttleworth.com/archives/551 [2] https://twitter.com/olliries/status/375704285083738112

I don't know what to say here. I'm still running Ubuntu but the phone-tablet-desktop eat it all strategy got me seriously concerned. Come on, Microsoft can't do that with its deep pocket, neither does Google, you just don't eat more than you can chew, not to mention you have no market share in any of them yet. Focusing on ubuntu server LTS, charging service fees, focusing on cloud platforms, while maintaining a free desktop to keep a wide user base, seems more reasonable to me.

Political talks aside, it looks all good. Intel will develop code for Wayland (which potentially will be used in all but Ubuntu distros) and Ubuntu will be working on adding patches for XMir on their own since XMir will be used only in Ubuntu. Eventually either XMir will be proven better and more distros adopt it and then it will be more reasonable for Intel spend time on integrating drivers with XMir.

No real news here.

There is one vendor using Mir. One. I don't blame Intel for not backing it.

And there are zero using Wayland. Zero.

Ubuntu isn't planning to use Mir until the 14.10 release. [1]

GNOME 3.10 will have Wayland support later this month. [2]

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2013-June/037...

[2] https://wiki.gnome.org/ThreePointNine/Features/WaylandSuppor...

Wayland packages have been in Fedora since 18 (it's at 19 now and 20 is to drop in under 3 months time). You can already start testing your apps to see how they work in Wayland, and it's on the roadmap to being integrated as the default. Gentoo and Archlinux also appear to have experimental support and plans to switch.

> Gentoo and Archlinux also appear to have experimental support and plans to switch.

Indeed, but the problem with Wayland is that one can't just 'switch' from X. Wayland provides graphics multiplexing; that's it.

Possibly mangled analogy: it's like saying we're switching from a LAMP stack to Postgres; it doesn't make sense as a statement.

>the problem with Wayland is that one can't just 'switch' from X.

Does switching to a wayland compositor by default and using xwayland for the applications that still can't talk to it not sufficiently address that? At least as practically as is possible when replacing a popular piece of interoperable software with a large user install base?

https://wiki.ubuntu.com/Mir/Spec doesn't even consider remoting, and to date Wayland has just punted on it. Is there any way they can both lose? The brief era of only caring about the machine under my desk is coming to an end, and any display system that isn't designed around accommodating latency is going to become a terrible mistake.

True or false?

True:

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/com...

Intel is the most active company in Wayland developement too.

This is a totally bullshit way of managing a FOSS project. You should never remove working code from a FOSS project if someone is already maintaining it and that someone represents a major chunk of your users. I hate that Ubuntu guys are moving away from X/Wayland (so suddenly and in a close-is way), but treating them like this indirectly is wrong. We got to play fair with the FOSS eco-system.

Not sure it deserves the down votes you got but I think you are very wrong. If you are running a project you can remove what you want, if someone wants something different enough they can fork it. If you do it early before many people are using it you will get far less complaints than when there are millions of users.

Adding code, and features places further requirements and limitations on further changes and any feature added and widely used will become nearly impossible to remove later.

Reply on news.ycombinator.com