Intel and XMir [LWN.net]

Intel and XMir

Posted Sep 12, 2013 21:34 UTC (Thu) by robclark (subscriber, #74945)
In reply to: Intel and XMir by maxiaojun
Parent article: Intel and XMir

>> But it may surprise you there is no corporate agenda as such behind this. There was no memo telling us what to think about mir (or systemd or gnome-shell or ... in fact there are outspoken RH employees on both sides of the systemd and gnome-shell debates.). It is just that RH see the benefit of a healthy upstream and making contributions to upstream projects.

> The problem is that, well, even if RH doesn't have consensus internally, as you mentioned, an external entity, e.g., Canonical, would be bashed by many people if they do not follow the direction of systemd and/or gnome-shell.

well, I'd phrase it a different way, ie. that RH gives a lot of freedom to employees that work on upstream projects (and really, that RH employs a lot of people who are very passionate about open source and upstream). I guess when you have a lot of people with passion and strong opinions (in and outside of RH), there may be some bashing. Don't take it too seriously.

> As a matter of fact, Lennart explicitly called Canonical to adopt systemd on Google+. If it is even OK within RH to dislike systemd, what's wrong with Canonical if they decide to keep UpStart around for some time?

I don't see any particular big problem if canonical keeps upstart.

But otoh, upstart doesn't really have a big impact on graphics stack and toolkits, so it is an area that doesn't cause as much fragmentation of effort for the linux desktop and graphics drivers. Maybe I take this more seriously because I'm a graphics driver developer... but graphics drivers are an area where we are seriously outnumbered by our closed source counterparts, and seriously understaffed. So needless fragmentation in this area is a bad thing.

>> no, that doesn't actually follow

>Yes, it doesn't follow in strict logical sense. However, after observing numerous breakage caused by GTK+ and so on, after some very bad experience about PyGTK, I'd conclude that the "open source atomsphere" does contribute to the loose API/ABI stability we are experiencing today.

Hmm, maybe a matter of bad experience with a particular project. I would say that the linux kernel has an "open source atmosphere" and it has some of the most rigorous ABI stability requirements (when it comes to userspace/kernel ABI). And likewise, the client<->xserver protocol ABI is very rigorously maintained. And the wayland crew is taking the same approach with wayland protocol.

(Log in to post comments)

Intel and XMir

Posted Sep 12, 2013 23:04 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]

> Maybe I take this more seriously because I'm a graphics driver developer... but graphics drivers are an area where we are seriously outnumbered by our closed source counterparts, and seriously understaffed.

Yes, indeed.

> So needless fragmentation in this area is a bad thing.

This is unrelated. Fragmentation gonna happen when there is conflict interest. And people have right to have conflict interest.

> Hmm, maybe a matter of bad experience with a particular project. I would say that the linux kernel has an "open source atmosphere" and it has some of the most rigorous ABI stability requirements (when it comes to userspace/kernel ABI). And likewise, the client<->xserver protocol ABI is very rigorously maintained. And the wayland crew is taking the same approach with wayland protocol.

Without GTK+ and so, many interesting stuff won't build.

Intel and XMir

Posted Sep 13, 2013 0:10 UTC (Fri) by robclark (subscriber, #74945) [Link]

>> So needless fragmentation in this area is a bad thing.

> This is unrelated. Fragmentation gonna happen when there is conflict interest. And people have right to have conflict interest.

yeah, perhaps I put it badly.. one aspect of open source / free software is the freedom to take it and try something different.

But, when that something different is something that touches many different projects which make up the (in this case, graphics) stack, you have no right to demand that those various upstream projects shoulder the burden of maintaining your changes.

And fwiw, I'd have the same negative opinion if, for example, some distro wanted to fork a different core piece of the linux ecosystem, like the kernel (cough, cough, android.. although at least in the android case there are some vaguely valid technical reasons)

>> Hmm, maybe a matter of bad experience with a particular project. I would say that the linux kernel has an "open source atmosphere" and it has some of the most rigorous ABI stability requirements (when it comes to userspace/kernel ABI). And likewise, the client<->xserver protocol ABI is very rigorously maintained. And the wayland crew is taking the same approach with wayland protocol.

> Without GTK+ and so, many interesting stuff won't build.

Ok, I guess I am missing the point you are trying to make here. But I'm not really getting the connection between "open source atmosphere" meaning that projects must have no respect for ABI compatibility (or really what has to do with this topic at all). Maybe certain projects have a problem, I'm not really involved w/ gtk+ so I don't really know the details in this particular case.