Intel Reverts Plans, Will Not Support Ubuntu's XMir


Recommended Posts

Why would you even use Ubuntu? So many superior alternatives out here for you to use, it's becoming like MS was during the XP days, bloated arrogant and complacent all at the same time

 

Aren't all distros, except, say arch, bloated with software?

Link to comment
Share on other sites

this blog post on the matter by a former dev on the RadeonHD project sums up my thoughts quite nicely >> http://libv.livejournal.com/25325.html

Guy seems quite upset for some reason, comes across in his flawed reasoning (Like complaining that Intel is forcing Canonical to patch the driver, so bugs in the Canonical only patch have to get reported to Canonical, which actually makes perfect sense)

Why should Intel maintain code solely to support one distros changes? Stuff like that makes much more sense in the distro copy (Same reason the GTK and QT guys won't accept the Mir backend, they don't want to maintain somebody else's code they'll never use)

Edit: Never mind that Canonical already patches the hell out of stuff, forcing them to include a small patch to one driver isn't a big deal at all.

Link to comment
Share on other sites

Ha I wasn't referring to Mir in my rant. What code did Mir take from Wayland? Also if Mir was completely about control, I don't think they would care as much about getting others to work with them or even use it.

 

Wayland's driver situation isn't any better. If you want to use it, you still have to use the terrible open source drivers. So what's your point? Also practically all of the issues as far as legacy X apps that Mir has (or will have) will be shared by Wayland...yet people only seem to be using that issue to bash Mir.

 

 Also "officially supported" doesn't really mean much as Steam works well on other "not-Ubuntu" distros.

Not all open source drivers are 'terrible'. For example intel's are excellent, intel has a full team developing their oss linux driver. AMD's open source driver is actually getting quite good too (but only with a very recent graphics stack, in kernel 3.11 and mesa 9.2+ I believe they now have fully working dynamic power management, hugely improved performance with a new shader backend, video acceleration with vdpau. Still not as fast for games as fglrx, but perfectly usable now. A year ago I would have agreed with you that most of the oss drivers aside from intel were bad, but thats starting to be untrue. The oss nvidia drivers are still bad, but thats because nvidia refuses to release any documentation at all for their hardware, unlike amd who releases documentation and even code drops, and intel who actually develop and oss driver themselves).

 

IMO proprietary drivers in linux are nothing but trouble, even if they do have better performance. They are implemented in very 'hacky' ways since they don't use the existing oss driver infrastructure. I was much happier using linux after switching to intel graphics, the drivers always just 'work' out of the box and that's awesome :)

 

And regarding 'what code did mir take from wayland'. Regarding straight code, afaik xmir is a fork of xwayland. Mir itself was written from scratch. But mir would not be able to work at all if not for the work of many upstream xorg, wayland, and mesa developers. Much infastructure changes needed to happen with the linux graphics stack to make wayland or mir possible. For example: Much work has been done over the years to move as many things out of X as possible (moving most of the driver functionality into the kernel, making xorg more modular; KMS/DRI2 etc...), EGL support in the OSS drivers and various other things. Canonical worked on none of these things. Wayland was a collaborative effort from the upstream developers of various projects, even if they weren't all working on wayland directly. This is why wayland has been in development for so long, much of the work needed to be done outside of wayland. Because mir swooped in at a later date when much of this work was already done, canonical is seen as 'being faster' which is not really true.

 

And the reasoning behind mir is dubious to begin with, none of the technical arguments they originally listed held any water. Its also dubious how mir came to be: Canonical cited these aforementioned 'technical reasons', all of which were quite weak, and some basically FUD against wayland (and canonical even took down this page at a later date), and prior to developing mir in secret did canonical ever go to any upstream devs about their concerns? no. Did they ever contribute any code to wayland? no. They just developed mir in secret based on some bull**** reasons.

 

Is their anything technically wrong with mir's code, is it any worse than wayland in that way? Probably not, what people have a problem with was how canonical went about creating and developing mir, based on poor reasoning, and when there was already a good X alternative in the works. People fear their poor decision will cause unneeded fragmentation. This doesn't mean there's anything wrong with mir from a technical perspective (well unless you can count their restrictive licensing, GPL3 + a CLA means no outside developers will be interested in contributing to mir).

Link to comment
Share on other sites

Guy seems quite upset for some reason, comes across in his flawed reasoning (Like complaining that Intel is forcing Canonical to patch the driver, so bugs in the Canonical only patch have to get reported to Canonical, which actually makes perfect sense)

Why should Intel maintain code solely to support one distros changes? Stuff like that makes much more sense in the distro copy (Same reason the GTK and QT guys won't accept the Mir backend, they don't want to maintain somebody else's code they'll never use)

Edit: Never mind that Canonical already patches the hell out of stuff, forcing them to include a small patch to one driver isn't a big deal at all.

Agreed, this decision seemed par for the course for an upstream project, most wouldn't want to accept distro-specific patches.

Link to comment
Share on other sites

Agreed, this decision seemed par for the course for an upstream project, most wouldn't want to accept distro-specific patches.

 

I agree as well. No distro-specific patches seems like a very reasonable position. Section 3.3 of the Debian New Maintainer's Guide explicitly recommends this approach to Debian package maintainers. In the interest of being good members of the open-source ecosystem I'm sure most other distros have a similar policy.

 

Now you have a series of patches.

  1. Upstream bug fix: debian/patches/fix-gentoo-target.patch

  2. Debian specific packaging modification: debian/patches/install.patch

Whenever you make changes that are not specific to the Debian package such as debian/patches/fix-gentoo-target.patch, be sure to send them to the upstream maintainer so they can be included in the next version of the program and be useful to everyone else. Also remember to avoid making your fixes specific to Debian or Linux - or even Unix! Make them portable. This will make your fixes much easier to apply.

Link to comment
Share on other sites

Why would you even use Ubuntu? So many superior alternatives out here for you to use, it's becoming like MS was during the XP days, bloated arrogant and complacent all at the same time

 

I love the Ubuntu base but I don't care for other bits, like Unity. Linux is Linux, so Ubuntu can be as slim or as bloated as you want it to be, and you can use whatever desktop you want. I love the ease of use with Ubuntu compared with other distros and I love the available software and the documentation. I can find out how to do almost anything and any piece of software to do it. 

Link to comment
Share on other sites

IMO, you can do that exact same thing, getting apps that work,  in any distro, just that more of it in Ubuntu is easier to get at.

 

I know Orangekiller and myself uses Debian, and we use mostly terminal or synaptics, not a software center.

Link to comment
Share on other sites

...

Wayland was a collaborative effort from the upstream developers of various projects, even if they weren't all working on wayland directly. This is why wayland has been in development for so long, much of the work needed to be done outside of wayland. Because mir swooped in at a later date when much of this work was already done, canonical is seen as 'being faster' which is not really true.

 

And the reasoning behind mir is dubious to begin with, none of the technical arguments they originally listed held any water. Its also dubious how mir came to be: Canonical cited these aforementioned 'technical reasons', all of which were quite weak, and some basically FUD against wayland (and canonical even took down this page at a later date), and prior to developing mir in secret did canonical ever go to any upstream devs about their concerns? no. Did they ever contribute any code to wayland? no. They just developed mir in secret based on some bull**** reasons.

...

Yeah, the guys working on Wayland aren't the same guys writing the Wayland backend for GTK or Qt, they're separate groups, but with Mir you have the same guys (or company) writing both, so they can code it to much more aggressive timelines (You might have a team working purely on the Mir backend for GTK, while the Wayland backend is being developed along side general GTK work, etc.)

Also, wasn't one of the Canonical claims about Wayland along the lines of "Wayland doesn't have an input mechanism"? That always struck me as amazingly silly, since Canonical would have to write one for Mir anyway.

Link to comment
Share on other sites

Also, wasn't one of the Canonical claims about Wayland along the lines of "Wayland doesn't have an input mechanism"? That always struck me as amazingly silly, since Canonical would have to write one for Mir anyway.

 

The whole thing with Mir is an re-invention of the wheel to me. However, if nothing else comes from it, Canonical has lit a fire under the Wayland guys, which might end up being good for us all.

Link to comment
Share on other sites

The whole thing with Mir is an re-invention of the wheel to me. However, if nothing else comes from it, Canonical has lit a fire under the Wayland guys, which might end up being good for us all.

It could also make the whole process of switching away from X take even longer do to unnecessary fragmentation.

Link to comment
Share on other sites

As nice as free software is in principle, this is why it's still not taking off in practice. Developers having hissy fits over small features or obsessing over offering a billion competing alternatives instead of working together to promote common goals. Hopefully Valve's attempt to bring gaming to Linux might help things.

Link to comment
Share on other sites

This topic is now closed to further replies.