Luc Verhaegen Comments On Intel/Mir Politics

[johnc]

X is the wave of the future.

But putting that fact aside for the moment, is it pretty much certain now that there will be no -- zero, zip, nada -- Mir support in Intel drivers? Because it's going to be hard to jive the idea of not accepting an XMir patch on the basis of Intel "not condoning the actions of Canonical [by creating Mir]", and then separately providing support for Mir.

[jrch2k8]

This will all very soon be resolved, intel will revert its position as soon as the real management hears whats going on. Intel's business is not on selling OSes, much less display servers or whatherver. Intel's business is selling chips, and it is stupid to not accept patches to your driver that allows the support of more users, thus selling more chips.

well this problem is way more complex, hardware bussiness people don't count ubuntu users they count OEM sales and even if you have ubuntu or mint or gentoo or arch that computer you bought already included the money for intel and was registered as a microsoft sale not ubuntu with exception of hand picked OEM like system76 or Dell linux laptops or custom builds that compared to HP/Gateway/other big OEM are extremely low, as far as intel care you payed the hardware already and payed microsoft too. On the other hand Xeon/opteron/firegl/quattro chips are registered as RedHat sales by the OEM and have huge margin gains[unlike that cheap corei7/FX/radeon/geforce], this is intel/amd/nvidia real interest in linux desktop[tizen/jolla/IVI/etc influence this too but for mobile] and they basically have open drivers[except nvidia] to please this RedHat customers, ofc make it open and maintained for other distros like ubuntu or fedora allow you to reduce cost and ROI + free technical able testers/contributors.

In the case of valve is the same, they don't care about ubuntu/gentoo/arch/fedora users per se, they care about BigPicture and SteamBox and for that they need to learn the platform and get free testers to reduce the initial investment and make bussiness decisions, get Valve games on linux is just a nice side effect. Seeing this and the need of Valve for AAA+ hardware support they will simply follow intel/amd/nvidia decisions for the custom valve distro software implementation.

the real management make that decision based on bussiness since suporting mir cost them money but loose every ubuntu users out there cost them 0$ since they already sold the chip to you and since the number of ubuntu are so low compared to windows or mac that they don't even care and since they market position is so big that you want it or not you will buy intel again at some point in time.

the only reason they listen to RedHat is that RedHat move lots of sales through OEM with big fat gross gains in the enterprise market

[mrugiero]

This is just an ugly situation for everyone. What happens when ubuntu users, which make up the majority of steam users, don't submit their bugs to intel anymore. And intel will ignore the patches sent from Ubuntu..... so will steam bugs in the intel gpu driver just sit unknown and unfixed? This is a shitty situation for everyone, especially the users.

Please, point out how support for XMir on the DDX driver affects Steam at all.

[Figueiredo]

This will all very soon be resolved, intel will revert its position as soon as the real management hears whats going on. Intel's business is not on selling OSes, much less display servers or whatherver. Intel's business is selling chips, and it is stupid to not accept patches to your driver that allows the support of more users, thus selling more chips.

[dh04000]

This is just an ugly situation for everyone. What happens when ubuntu users, which make up the majority of steam users, don't submit their bugs to intel anymore. And intel will ignore the patches sent from Ubuntu..... so will steam bugs in the intel gpu driver just sit unknown and unfixed? This is a shitty situation for everyone, especially the users.

[Brane215]

I agree with most of his statements and estimates, but I fail to see how Wayland is bad as reinvention of X.

Wayland doesn't seem to fail in his list of shitty reinventions on 3-year cycle.

X11 is with us _much_ longer and the need to modernize it had became urgent long ago.

And behind the Wayland is at least some of the team that managed to patch and update Xorg so far.

Jump from Waland to Mir has nothing to show for on this front.

How is it comparable, then and why shouldn't Wayland reinventors be justified in "preaching about needles reinvention" ?

Wayland/Weston seem to be born out of technical need while Mir seems purely as a political tool.

[mrugiero]

No having Mir and Wayland doesn't introduces severe fragmentation. Neither Mir nor Wayland have any built in toolkit. All renderings are done to buffers and buffers alone. And because of that no software like xclock or xcalc will be written for any of the as that simply isn't possible. Toolkit is what will be used and if a toolkit supports both your app bill support both.

First, point out where did I say any of those have built in toolkits. I only said toolkits (as in Qt, GTK, etc) help alleviate the fragmentation. Also, I didn't say it was severe fragmentation, but that it was *more* severe than the general case. This is due to having to write, when not using a toolkit, or using some specific things of the underlying infrastructure, a backend for each, if you want to support everyone.
Also, rendering doesn't require a toolkit, since you can do it yourself in several ways.

And I don't know what running a DE in XMir have to do whit any of this. If you think it's pointless then god don't do it, nobody cares.

It has things to do with this, specifically with you talking about how people who cares about the technology doesn't care about this discussions. The fact is, I will not use it, but I know of several people who will because they lack the technical knowledge to disable it, and those users, friends of mine, will see mostly negative effects out of it, when the only reason to run it is to make some noise.

What about the maintainers of QT, GTK and so on? They need to double the effort to support and maintain both Mir and Wayland.
Bugs found and fixed on Mir aren't going to be bugs found and fixed on Wayland and vice-versa, therefore fragmenting efforts.

Also, this. This is why it's more severe than in most cases. In most cases, which exclude toolkits and display servers, the fragmentation introduces affects only the project who introduces it (i.e., having people maintaining MATE only means this people ain't be working on something else). In the case of having several toolkits and display servers, there are other things depending on them, which will pay the consequences.

[jrch2k8]

No having Mir and Wayland doesn't introduces severe fragmentation. Neither Mir
nor Wayland have any built in toolkit. All renderings are done to buffers and buffers
alone. And because of that no software like xclock or xcalc will be written for any
of the as that simply isn't possible. Toolkit is what will be used and if a toolkit
supports both your app bill support both.

And I don't know what running a DE in XMir have to do whit any of this. If you
think it's pointless then god don't do it, nobody cares.

awesome comment from a dude that never touched a compiler, in the real world even using toolkit X.y version can sigsegv between different Xorg minor releases[lets say 1.14.0 and 1.14.1] and very very often you need a lot of swtiching logic to deal with graphic drivers and opengl implementations

[jrch2k8]

TBH, I thought that Intel was in the business of selling hardware, and that therefor providing good driver support should be their prime concern. Reinventing the X server, or fighting battles over such things, should be less of important. With this move intel seems to have forgotten about this niggle.

the problem with your logic is that you bypass all past canonical bad decisions and go straight to intel sell hardware and money grow on the floor so there is no reason to reject it, canonical has indeed over time a very bad track in maintaining projects even internally and intel is not an non-profit foundation. simply put an good manager realized "why in the hell we have to put money to maintain a canonical exclusive project for their own exclusive product that only works with their exclusive DE??" and after check some project maintain history i would have made the exact same bussiness decision.

you could argue they support android but the solid truth is they did so because they see profit in that platform and choose to support it, it wasn't google forcing intel.

google since they bought android they keep their specific android only code downstream and only upstream the non android specific code which from my POV is the proper professional way of doing things, you assume the cost of your fork and contribute back all the useful code for everyone else to keep the community support[i know they aren't exactly perfect at it but at least they try].

beside mir situation im sure intel don't support hurd, bsd, amigaOS, genode, etc. either

[mdias]

No having Mir and Wayland doesn't introduces severe fragmentation. Neither Mir
nor Wayland have any built in toolkit. All renderings are done to buffers and buffers
alone. And because of that no software like xclock or xcalc will be written for any
of the as that simply isn't possible. Toolkit is what will be used and if a toolkit
supports both your app bill support both.

What about the maintainers of QT, GTK and so on? They need to double the effort to support and maintain both Mir and Wayland.
Bugs found and fixed on Mir aren't going to be bugs found and fixed on Wayland and vice-versa, therefore fragmenting efforts.