Advertisement
GStreamer Conference 2013, 22-23 Oct, Edinburgh
GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.
Weekly Edition
Return to the Front page
| |||||||||||||
Intel and XMirReverting a patch, at least one that isn't causing a bug or regression, is often controversial. Normally, the patch has been technically vetted before it was merged, so there is—or can be—a non-technical reason behind its removal. That is the case with the recent reversion of a patch to add XMir support to the Intel video driver. As might be guessed, rejecting support for the X compatibility layer of the Mir display server resulted in a loud hue and cry—with conspiracy theories aplenty. The patch adding support for XMir was merged into the xf86-video-intel driver tree on September 4 by maintainer Chris Wilson. That driver is the user-space X.org code for supporting Intel GPUs; it is code that Intel has developed and maintains. The commit message noted that the XMir API had likely been frozen so support for the API was being added to the driver. The patch consists of less than 300 lines of code, most of it confined to a new sna_xmir.c file. Based on the commit and message, Wilson clearly didn't see any reason not to merge the patch. All of that changed sometime before the revert on September 7, which also prompted the release of the 2.99.902 snapshot. In the NEWS file for the snapshot was the following message:
We do not condone or support Canonical in the course of action they have
chosen, and will not carry XMir patches upstream. -The Management There are a number of possible interpretations for that statement, but, however it was meant, it was certain to raise the ire of Canonical and/or Mir fans—and it did. When asked about the removal of XMir support, Wilson pointed to Intel management for answers. I contacted Dirk Hohndel, CTO of the Intel Open Source Technology Center, who answered the main question at hand: Intel's "engineering team and the senior technical people made the decision that we needed to continue to focus our efforts on X and Wayland", he said. It was a question of focus, he said, "adding more targets to our QA and validations needs, having to check more environments for regressions [...] would require us to cut somewhere else". So removing support for XMir was requested by Intel management, but seemingly did not sit very well with Wilson. One suspects the NEWS file entry did not get approved, for example. But it's hard to see that any reversion (or outright rejection) of the XMir support would have led to a different outcome. Ubuntu has a legion of fans, who can often be quite vocal when they believe their distribution is being treated unfairly. Michael Hall, a Canonical employee on the Community team, obliquely referenced the XMir removal in a post to Google+: "You will not make your open source project better by pulling another open source project down." The argument that Hall and others make is that because Intel supports Wayland, it is hamstringing Mir by removing support for it, and, in effect, helping to keep Mir as a single-distribution display server. "This just strikes me as trying to win the race by tripping the competition, not by running faster", Hall said in the comments. But accepting any code into a codebase you maintain is a burden at some level. Supporting a new component, like a display server, also requires a certain amount of testing. All of those things need to be weighed before taking on that maintenance. As Matthew Garrett put it (also in the comments to Hall's post):
Intel commit to supporting the code that they ship, even if that would
require them to write or fix large amounts of code to keep it
working. Keeping the XMir code comes at a cost to Intel with (at present)
zero benefit to Intel. As long as XMir is a single-distribution solution,
it's unsurprising that they'd want to leave that up to the distribution.
Certainly Canonical can continue to carry the XMir patches for the Intel video driver. It is, after all, carrying its own display server code in addition to its Unity user interface and various other Ubuntu-specific components. But Hall sees the "single-distribution solution" as a self-fulfilling prophecy:
Upstream won't take patches because other distros don't use it. Other
distros don't use it because other DE's don't use it. Other DE's don't use
it because it requires upstream patches that haven't been accepted.
Upstream won't accept the patches because other distros don't use it.
Since its initial attempt—with less than stellar results—Canonical has not really tried to make any kind of compelling technical arguments about Mir's superiority or why any other distribution (or desktop environment) would want to spend time working on it (as opposed to, say, Wayland). The whole idea is to have a display server that serves Unity's needs and will run on multiple form factors in a time frame that Canonical requires. That's not much of an argument for other projects to jump on board. As Garrett points out, Canonical has instead chosen the route of "winning in the market", which is going to require that it shoulder most or all of the burden until that win becomes apparent. Casting the rejection of XMir as an attack of some kind is not sensible, Garrett said:
Refusing to adopt code that doesn't benefit your project in any way isn't a
hostile act, any more than Canonical's refusal to adopt code that permitted
moving the Unity launcher was a hostile act or upstream Linux's refusal to
adopt the Android wakelock code was a hostile act. In all cases the code in
question simply doesn't align with the interests of the people maintaining
the code.
Other comment threads (for example on Reddit here and here) followed a similar pattern. Intel focusing on Wayland and X is seen as Mir (or Canonical) bashing, with some positing that it really was an attempt to prop up Tizen vs. Ubuntu Touch (or some other Canonical mobile initiative). Or that Intel believes Wayland is so badly broken it needs to stop the Mir "momentum" any way it can. Most of that seems fairly far-fetched. One can understand Intel's lack of interest in maintaining support for XMir without resorting to convoluted reasons—though the size of the patch and how self-contained it is do lead some to wonder a bit. There is a risk for Intel in doing so, however. As Luc Verhaegen, developer of the Lima driver for ARM Mali GPUs, pointed out in a highly critical blog post, Intel could actually end up harming its own interests:
By not carrying this patch, Intel forces Ubuntu users to only report bugs
to Ubuntu, which then means that only few bug reports will filter through
to the actual driver developers. At the same time, Ubuntu users cannot
simply test upstream code which contains extra debugging or potential
fixes. Even worse, if this madness continues, you can imagine Intel stating
to its customers that they refuse to fix bugs which only appear under Mir,
even though there is a very very high chance of these bugs being real
driver bugs which are just exposed by Mir.
At this point, though, Intel may well be waiting to see the "proof of the pudding". If Canonical is successful at getting Mir onto the desktops of lots of Intel customers in the next year or two, one suspects that any needed changes for Mir or XMir will be cheerfully added to the Intel video driver. For now, the company loses little, and gains some maintenance and testing time, by waiting for it all to play out. In the end, there is an element of a "tempest in a teapot" to the whole affair. We are talking about 300 lines of code that, evidently, won't need much in the way of changes in the future (since the API is frozen). Intel is almost certainly embarrassed by how the whole thing played out, and Ubuntu fans will undoubtedly see it as yet another diss of their favorite distribution. But in the final analysis, the impact on Mir users will be minimal to non-existent, at least in the short term and probably the long as well. (Log in to post comments)
Intel and XMir Posted Sep 11, 2013 14:01 UTC (Wed) by maxiaojun (subscriber, #91482) [Link]
Yet another case where Linux customers are treated as shit.
Intel and XMir Posted Sep 11, 2013 14:37 UTC (Wed) by hunger (subscriber, #36242) [Link]
This is much ado about nothing.
In this case there are canonical customers and intel customers.
Intel does not seem to see mir as valuable to their customers, so they do not want to spend time on maintaining support for it. That will change if mir finds lots of users. Intel does provide the source code for their drivers though.
That enables Canonical to providing patched drivers to their customers. They will get the drivers from Canonical/Ubuntu in any case, independent of whether those are patched or not. So they get the same experience either way.
Who exactly is mistreated here?
I do wonder what will happen if AMD or NVidia will do not care to patch their drivers for mir though.
Intel and XMir Posted Sep 11, 2013 14:48 UTC (Wed) by lkundrak (subscriber, #43452) [Link]
I feel mistreated. Thanks for asking.
I run Fedora, have Intel hardware and would like to run XMir. If XMir support would be upstream, it would be a lot less hassle for me to get it runnig.
Intel and XMir Posted Sep 11, 2013 15:10 UTC (Wed) by ovitters (subscriber, #27950) [Link]
Canonical for a long time said that Mir is just for Unity. This is similar to Unity, which for a very long time was very difficult to get working on any other distribution.
For a long time it was impossible to do any Mir development if not running Ubuntu. Meaning, there were 0 instructions on how to build it and it required patches all over the place.
Seems unrealistic expectations to have Unity or Mir working on Fedora. The focus within Canonical is foremost on Ubuntu, all other distributions are secondary. Not saying it does not happen one day (IIRC Unity nowadays is much easier to get working).
Intel and XMir Posted Sep 11, 2013 15:24 UTC (Wed) by maxiaojun (subscriber, #91482) [Link]
> The focus within Canonical is foremost on Ubuntu, all other distributions are secondary.
The focus within Red Hat is foremost on Fedora, all other distributions are secondary.
Intel and XMir Posted Sep 11, 2013 15:35 UTC (Wed) by ovitters (subscriber, #27950) [Link]
Actually SuSE does a lot of cross distribution work. Red Hat primary focus is RHEL (not Fedora), but they do loads and loads of non-distribution specific work. Just look at e.g. the kernel contributions.
Would be nice to investigate a little bit before saying something on LWN. There are a lot of people who do not mind to investigate.
Intel and XMir Posted Sep 12, 2013 2:34 UTC (Thu) by daniels (subscriber, #16193) [Link]
> Would be nice to investigate a little bit before saying something on LWN. There are a lot of people who do not mind to investigate.
You think this is bad? Try the Phoronix forums.
Intel and XMir Posted Sep 15, 2013 4:22 UTC (Sun) by rahvin (subscriber, #16953) [Link]
This is LWN, lets not make it phoronix or slashdot or anything else.
Intel and XMir Posted Sep 12, 2013 2:57 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> Actually SuSE does a lot of cross distribution work. Red Hat primary focus is RHEL (not Fedora), but they do loads and loads of non-distribution specific work. Just look at e.g. the kernel contributions.
How your "facts" make my statements wrong? You even acknowledge that Red Hat focus on their own "enterprise" distribution.
How can a billion dollar Linux company not contribute "loads and loads" of work? You really believe that Linux (kernel) is primarily contributed by hobbyists?
You may look a bit closer to IBus project ( https://code.google.com/p/ibus/ ) , and see how shitty a Red Hat backed project can be. Yes, I mean shitty.
Intel and XMir Posted Sep 12, 2013 6:16 UTC (Thu) by ncm (subscriber, #165) [Link]
It might be educational at this juncture, and perhaps even redemptive, to look up "Sturgeon's Law".
Intel and XMir Posted Sep 12, 2013 7:36 UTC (Thu) by ovitters (subscriber, #27950) [Link]
You really have a thing for Red Hat in a way you cannot see things objectively anymore.
I am talking about Canonical and Canonical projects. Upstart did not start out at Canonical, they just hired the main developer. Canonical focusses within just one project solely on Ubuntu. Red Hat and SuSE do not.
Regarding IBus, I don't know. Maybe out of all the projects their sponsor one is focussed solely on Fedora. That's not the case though.
You only make clear you have an issue with Red Hat. I don't care.
Intel and XMir Posted Sep 12, 2013 8:59 UTC (Thu) by cjwatson (subscriber, #7322) [Link]
> Upstart did not start out at Canonical, they just hired the main developer.
This is a curious piece of historical revisionism, and since I was there I can't let it pass.
Scott was arguably Canonical's first full-time employee (things were a little fuzzy in the very early days and he and Robert Collins had a long-running debate over who was first), hired in early 2004. To start with Scott wasn't doing anything related to init systems, and indeed wasn't initially on the "distro team" that was focusing solely on Ubuntu, but was mainly working on problems related to revision control.
In late 2004 / early 2005, Scott started working on the boot process (recall that that was the time when everyone was moving over to the various components of Project Utopia, including udev), and over a year or so of working on that he came to the conclusion that a number of problems were fundamentally unfixable without replacing the init system. At a Canonical distro team sprint in early 2006 he presented a design for a new event-based init daemon to us, and I remember going over it in considerable detail and giving him feedback on the proposed state machine (I think that was roughly when he settled on the name "Upstart" too). At UDS in June 2006 he presented this as a spec for the Ubuntu 6.10 cycle (and you can see that https://wiki.ubuntu.com/ReplacementInit?action=info lines up with this), it was one of his four specced projects for that release cycle, and we switched Ubuntu over to the new Upstart init daemon in September 2006.
Now, it's certainly fair to say that Upstart was Scott's brainchild rather than something that Canonical management asked him to do or whatever, and he did a lot of the work for it in his free time because it was something he cared about. He also did a lot of it on work time, he had many discussions with me and other Canonical employees about its design and implementation, and he felt strongly about making Ubuntu's boot process reliable as well as running it as an upstream project that other distributions could use.
Upstart would not have happened without Scott, just as many projects (corporate-backed or not) wouldn't have happened without their initial primary developers. But it is quite false to say that Canonical "just hired the main developer", as if we noticed this promising Upstart project and decided we should hire the person who'd been developing it. That's not how it happened.
Intel and XMir Posted Sep 12, 2013 9:45 UTC (Thu) by ovitters (subscriber, #27950) [Link]
Oops, I was not trying to say anything factually wrong. I really thought I was correct, so thanks for educating me!
Intel and XMir Posted Sep 13, 2013 0:57 UTC (Fri) by jdub (subscriber, #27) [Link]
I can clear up the employee number debate.
1) David Miller (bugzilla, not kernel)
(It's Scott and I that argued over 3 and 4.)
:-)
Intel and XMir Posted Sep 13, 2013 2:56 UTC (Fri) by cjwatson (subscriber, #7322) [Link]
Aha, thanks. I had a sneaky feeling I was remembering that slightly wrongly :-), probably because of debates between Scott and Robert after you left ...
Intel and XMir Posted Sep 14, 2013 19:54 UTC (Sat) by jbailey (subscriber, #16890) [Link]
David didn't stay very long, so easy to forget. I only remember because one of my starting tasks was "we need XMLRPC in Bugzilla" and I had to ask him for help finding the installation. No one seemed to know quite where or how it was all setup.
Intel and XMir Posted Sep 12, 2013 17:18 UTC (Thu) by kiko (subscriber, #69905) [Link]
> Canonical focusses within just one project solely on Ubuntu
C'mon Olav.. you of all people know that there is no such thing as a company contributing code to an open source project; open source is contributed to by people, and Canonical's engineers certainly do -- regularly -- contribute code to open source projects in general. It's a small company, though, with 600 employees and about 2/3 that of engineers. If you compare that population to the size of the RHEL engineering contingent, it's no wonder their contributions upstream have less impact.
If you were saying that a) Canonical prioritizes Ubuntu as its own product and b) focuses on integration and polish as opposed to upstream features, there is absolutely no contest there. You're right -- last-mile polish is the area where the biggest gap existed in open source when it was founded, and I think Ubuntu' s success and adoption confirm it was an effective goal to pursue. I truly wish the company had more resource to invest in upstream features -- I myself miss many -- but when you are a small and yet-to-be-profitable company, focus can be a good way to avoid failure.
I know Canonical has its share of policy problems. But as a key influencer, your criticism could help us fix them, as opposed to blending them all into a big Canonical Does Nothing For Open Source meme.
Intel and XMir Posted Sep 12, 2013 21:23 UTC (Thu) by niner (subscriber, #26151) [Link]
Your arguments about focusing and polish would carry much more weight, if Canonical actually focused and polished. But it much rather seems to invest huge amounts of resources into rewriting the whole desktop stack single handedly. From init system to display server to desktop, everything home grown. Seems like a huge task for a small company. I can very well understand that Canonical's engineers don't have time to contribute much to upstream projects. But is this actually helping the Linux desktop? I fear it's actually harming it.
As an application developer, I see for example systemd as a unifying force long overdue. I've never had the time to write init scripts for distributions other than the one I use, but I can be quite sure that my systemd unit files work just about everywhere (or at least will work). Well except for Ubuntu. And sadly they do not even have any good reasons. The same story now seems to be happeing with Mir.
Intel and XMir Posted Oct 1, 2013 12:21 UTC (Tue) by JanC_ (guest, #34940) [Link]
AFAIK there is no guarantee that your unit files will work (as intended) on every systemd-based distro?
Intel and XMir Posted Oct 1, 2013 12:31 UTC (Tue) by niner (subscriber, #26151) [Link]
Is there a guarantee? Probably not. But I never said I was guaranteed. I said I can be quite sure. For example the following few lines will probably work on every systemd distribution:
[Unit]
[Service]
[Install]
There might be some obscure system where this might not work. Maybe. Small chance.
Now write a SysV init script that does the same and works on at least the major distributions. After network's up, Xvfb should be started with the given parameters and if it crashes it should be restarted. It should by default be enabled in a multi-user runlevel. And to make things interesting: do it without having these distributions to test. Bonus points for not even having to try to find distribution specific documentation.
Systemd makes this so, so, so much easier. Finally.
Intel and XMir Posted Sep 12, 2013 20:05 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> Regarding IBus, I don't know. Maybe out of all the projects their sponsor one is focussed solely on Fedora. That's not the case though.
Go and learn about it, otherwise don't claim anything about Red Hat.
Intel and XMir Posted Sep 12, 2013 20:22 UTC (Thu) by ovitters (subscriber, #27950) [Link]
Go learn to have a discussion before posting anything on LWN.
Anyway, I do whatever I please and please just shut the fuck up.
Intel and XMir Posted Sep 12, 2013 20:27 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
Shut the fuck up yourself, troll.
Intel and XMir Posted Sep 12, 2013 20:30 UTC (Thu) by ovitters (subscriber, #27950) [Link]
Lost for words I see :P
Intel and XMir Posted Sep 12, 2013 20:36 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
Obvious troll obvious.
Intel and XMir Posted Sep 12, 2013 22:43 UTC (Thu) by ean5533 (subscriber, #69480) [Link]
This conversation is devolving. Please take a deep breath and step back for a while. Aggressive insulting and arguing is not good for anyone.
Intel and XMir Posted Sep 14, 2013 1:49 UTC (Sat) by liam (subscriber, #84133) [Link]
https://www.linux.com/learn/tutorials/560928-counting-con...
So, "volunteers" are the biggest single contributing body.
Intel and XMir Posted Sep 12, 2013 3:49 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> Actually SuSE does a lot of cross distribution work.
At the end of day, many applications are only certificated with SLES, so nice.
Intel and XMir Posted Sep 12, 2013 7:41 UTC (Thu) by ovitters (subscriber, #27950) [Link]
How does this relate to Mir being really focussed on Canonical/Unity/Ubuntu?
I can tell you: not related at all. Just saying a bunch of things and hoping something proves you right is a pretty bad strategy to have a discussion. Please, please try to stick on topic.
Regarding "many applications": this again does not relate to the huge amount of cross distribution work they do.
Intel and XMir Posted Sep 12, 2013 20:25 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
Hey, troll, I'm talking about SUSE here not, Mir.
> Regarding "many applications": this again does not relate to the huge amount of cross distribution work they do.
How can you justify your claim given the fact that many applications are SLES "exclusive"? When you say "huge", how do you measure it?
I do know one key contribution from SUSE, SCIM.
It might be the king of its time, after its primary author heads to Google, it suddenly became an abandon-ware.
Then it comes IBus...
Intel and XMir Posted Sep 12, 2013 20:29 UTC (Thu) by ovitters (subscriber, #27950) [Link]
Hey, troll, the article is about XMir and you were talking about XMir. Already told you various times that you keep switching topics as soon it becomes too difficult for you.
If you're able to respond to a claim of mine, then fine. At the moment, you keep switching topics.
You brought up Red Hat, SuSE, The topic is XMir. If you are able to say anything relevant, cool. At the moment, you're just a mosquito.
Intel and XMir Posted Sep 12, 2013 20:34 UTC (Thu) by corbet (editor, #1) [Link] Perhaps both of you could stop? Please?
Intel and XMir Posted Sep 12, 2013 20:34 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
Hey, troll, I gave very specific example of Red Hat and SUSE backed projects. You know nothing about them. You still feel that you know better, so nice.
If you do not bother to justify your ungrounded claims, then fine, yet another liar in FOSS world.
Intel and XMir Posted Sep 11, 2013 17:15 UTC (Wed) by drag (subscriber, #31333) [Link]
> The focus within Red Hat is foremost on Fedora, all other distributions are secondary.
That's pretty much BS. Redhat has had a good track record of working changes into upstream for the various projects they work on and they open source their software fairly aggressively. Canonical does not.
Redhat is not perfect, of course. However, juxtaposing words around in a juvenile manner isn't a way you win a arguments or convince people of your position.
----
That being said I see absolutely no reason at all why Canonical should be obligated to work with other distributions, nor why they should be condemned if they choose not to make their software portable.
There are very significant penalties you pay when you want to make your software portable across all Linux distributions and getting distributions to package it. You have to deal with politics, inane and petty differences between distributions, some significant technical issues, coordinating efforts, packaging, testing... etc etc. You are going to increase the complexity significantly by taking that approach. It's going slow down performance, slow down improvements, increase complexities, increase bug counts, lose of control, etc etc. There is also significant overhead in just trying to get people to agree to your approach. You will be spending a lot of your time and money doing things that provide almost no direct benefit to your project or your users.
So if the benefits of concentrating on portable software (ie. Wider audience, more participation from third party developers, etc) do not outweigh the obvious negatives, then there is no point to pursuing it. If you are going that direction (not pursuing third party distribution participation) then, unfortunately, you do not really have any right to complain when you try to place a maintenance burden on other people not involved in your project.
Canonical should neither feel guilty nor be condemned for wanting to work on their own stuff in their own way. Their approach may work out. But if that is what they want and the way things they are going then everybody just needs to be honest and accept this is what they are doing and not blame third parties for not accepting burdens for Canonical.
If Canonical is not taking this approach (ie. being Unity/Ubuntu-specific) and they really want Mir to be widely adopted by other distributions then they are going to have to go out of their way to try to make that happen and be fully prepared to abandon Mir if their approach is not adopted by a wide audience.
In addition, and going a bit off-topic, I think that in the long-run that Linux-land would be far better off dealing with two isolated and unique application stacks then dealing with a thousand possible combinations of this or that.
Intel and XMir Posted Sep 12, 2013 3:11 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> That's pretty much BS. Redhat has had a good track record of working changes into upstream for the various projects they work on and they open source their software fairly aggressively.
No.
Red Hat has a good record of control various upstreams by implanting their employees, throwing whatever shit they come up into Fedora and probably fixing some problems when RHEL release is close (for example GNOME Classic mode).
Sure, the works are open source. It follows that API/ABI stability receives zero respect. Programs work today may not even build tomorrow.
Intel and XMir Posted Sep 12, 2013 14:48 UTC (Thu) by robclark (subscriber, #74945) [Link]
> Red Hat has a good record of control various upstreams by implanting their employees
Sure, you have more people contributing to upstream projects, then I suppose by virtue of those contributions you have some influence over the direction of those projects.
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.
I fail to see a problem in that. But I suppose some people see controversy where they want to see it.
> Sure, the works are open source. It follows that API/ABI stability receives zero respect. Programs work today may not even build tomorrow.
no, that doesn't actually follow, but whatever, I guess I shouldn't feed the troll
Intel and XMir Posted Sep 12, 2013 20:59 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> 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.
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?
> 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.
Intel and XMir Posted Sep 12, 2013 21:15 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Because Upstart is inferior to systemd. Ubuntu users suffer for it.
XMir is another inferior solution.
Intel and XMir Posted Sep 12, 2013 21:25 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
Because systemd is inferior to Upstart. Fedora users suffer for it.
Wayland is another inferior solution.
If you thought that only your claim is right, then explain again what is free software.
Intel and XMir Posted Sep 12, 2013 21:30 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Nope. SystemD is technically superior (just look at unit files vs. upstart init files) and has more features. Decision to create SystemD was technical-driven.
Mir is inferior to Wayland (still), though it's quickly gaining new functionality.
And what's worse, the decision to start Mir was purely political. There are absolutely no technical reasons for Ubuntu _not_ to use Wayland.
Intel and XMir Posted Sep 12, 2013 21:46 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> Nope. SystemD is technically superior (just look at unit files vs. upstart init files) and has more features. Decision to create SystemD was technical-driven.
> Mir is inferior to Wayland (still), though it's quickly gaining new functionality.
Having more features doesn't mean superior.
Moreover, I once noticed that yum/zypper is probably superior to APT. Should we give up APT and switch, then?
> And what's worse, the decision to start Mir was purely political. There are absolutely no technical reasons for Ubuntu _not_ to use Wayland.
Probably true. But given the obvious hostility showed by Intel this time, I find that political concerns, if any, are justified.
Intel and XMir Posted Sep 12, 2013 21:50 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
> Having more features doesn't mean superior.
It is, if those features make common tasks less complicated.
> Moreover, I once noticed that yum/zypper is probably superior to APT. Should we give up APT and switch, then?
> Probably true. But given the obvious hostility showed by Intel this time, I find that political concerns, if any, are justified.
Intel and XMir Posted Sep 12, 2013 22:04 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> It is, if those features make common tasks less complicated.
So, how do you measure complexity?
> Intel's hostility is mostly reaction to Ubuntu's.
If not picking some free software is hostility, then free software is a misnomer of fascist software.
Intel and XMir Posted Sep 12, 2013 22:52 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>So, how do you measure complexity?
Lines of code to implement certain functionality and chances to make a mistake.
> If not picking some free software is hostility, then free software is a misnomer of fascist software.
Intel and XMir Posted Sep 12, 2013 23:20 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> Lines of code to implement certain functionality and chances to make a mistake.
Oh, then it is even better to use Windows Server, where it generally requires 0 line of code to do things have 0 chance of making a mistake.
> Creating a technically pointless local fork is hostility and one of the major reasons for fragmentation.
I find that it is quite meaningful, after encountering so many hostile, fascist people like you.
Intel and XMir Posted Sep 12, 2013 23:23 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
For servers? Nope, Windows Server requires quite a bit of configuration (just look at service installation). So my comparison holds.
SystemD _is_ easier to use than Upstart, especially with its JournalD integration.
Intel and XMir Posted Sep 12, 2013 23:33 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> For servers? Nope, Windows Server requires quite a bit of configuration (just look at service installation). So my comparison holds.
Yes, you are always 100% correct.
> SystemD _is_ easier to use than Upstart, especially with its JournalD integration.
A straight search of "JournalD" gives me this: https://bbs.archlinux.org/viewtopic.php?id=168524
Intel and XMir Posted Sep 12, 2013 23:41 UTC (Thu) by pizza (subscriber, #46) [Link]
> A straight search of "JournalD" gives me this: https://bbs.archlinux.org/viewtopic.php?id=168524
Something works for you doesn't necessarily works for other people (especially true in Linux eco-system as software configurations are way too many)
You do realize that that link actually contradicts your assertion? The actual problem is another piece of software (ie nepomuk) either had corrupted data files or said files weren't compatible from one version to the next, and was continually (and rapidly) crashing and restarting itself. Journald, being the system logger, did its job and logged each and every occurance.
Intel and XMir Posted Sep 19, 2013 5:04 UTC (Thu) by jamesh (guest, #1159) [Link]
Your arguments against Mir sound like they could have equally been leveled against systemd when it was started: that its changes could have been integrated into Upstart (that most major distros were either using at the time or evaluating).
Instead, they continued work as a new project and ended up with a product that you apparently like a lot.
Is it really that difficult to give Mir the same courtesy, and accept that its reasons for existence might not just be political?
Intel and XMir Posted Sep 19, 2013 5:13 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
No. Systemd from the very beginning had features that would have required complete re-architecting of upstart. And it had been considered at that time, btw.
Intel and XMir Posted Sep 19, 2013 5:36 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
" Is it really that difficult to give Mir the same courtesy, and accept that its reasons for existence might not just be political?"
That comparison weakens your plea
http://0pointer.de/blog/projects/why.html explains why systemd was started and has the technical details of how the architecture is different and really the inverse of upstart and they still talked to upstart developers before developing an alternative.
If there are similar technical reasons for Mir or if Mir developers talked to Wayland and tried collaborating, feel free to provide pointers.
Intel and XMir Posted Sep 12, 2013 23:32 UTC (Thu) by HelloWorld (subscriber, #56129) [Link]
As drag put it already:
> juxtaposing words around in a juvenile manner isn't a way you win a arguments or convince people of your position. So please just stfu.
Intel and XMir Posted Sep 12, 2013 23:37 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
As drag put it already:
> juxtaposing words around in a juvenile manner isn't a way you win a arguments or convince people of your position.
Yes, only Fedora fascist can call Ubuntu inferior, not other way around.
> So please just stfu.
Obvious troll obvious.
Intel and XMir Posted Sep 14, 2013 23:29 UTC (Sat) by marcH (subscriber, #57642) [Link]
The real, important question is: does this post count for 3, or is there a maximum of 1 Godwin point you can get per post?
Intel and XMir Posted Sep 15, 2013 17:14 UTC (Sun) by mathstuf (subscriber, #69389) [Link]
I always thought Godwin posts implicated the all sub-threads and, to some extent, its parents (and more specifically, the user). The question I would like to know: what percentage of Godwin sub-threads get back on track[1]? Is it permanently tainted or is there some hope?
[1]This is a meta-discussion, so it probably doesn't count here.
Intel and XMir Posted Sep 16, 2013 22:24 UTC (Mon) by nix (subscriber, #2304) [Link]
Please stop that, I just laughed so loud I woke up my neighbour. :)
Intel and XMir Posted Sep 12, 2013 21:34 UTC (Thu) by robclark (subscriber, #74945) [Link]
>> 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.
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.
Intel and XMir Posted Sep 13, 2013 0:25 UTC (Fri) by daniels (subscriber, #16193) [Link]
GTK+ 2.x was ABI-stable (as well as API-stable, obviously) for 9 years. Nine. Including major releases adding features and new capabilities.
That's two years longer than the period between the initial release of Windows XP, and the release of its last service pack.
Intel and XMir Posted Sep 16, 2013 9:23 UTC (Mon) by dgm (subscriber, #49227) [Link]
And probably is the reason why so many projects used GTK+ when targeting Linux.
Windows, on the other hand, still supports the same ABI and API since Windows 95. That's 18 years, and still counting.
Intel and XMir Posted Sep 16, 2013 16:53 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
No, windows doesn't. They changed things so a lot of programs that were written for windows 95 no longer work and need to be updated.
Intel and XMir Posted Sep 17, 2013 7:09 UTC (Tue) by dgm (subscriber, #49227) [Link]
I do routinely run binaries that I compiled for Win32 like 15 years ago. None of my early GTK+ (1.2) binaries runs today. Most don't even compile any more. That's sad.
Intel and XMir Posted Sep 17, 2013 10:26 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
I have had a number of programs that were written for Win 95/98 that stopped working with newer versions of windows until they were updated.
i also have some very old binaries on some of my Linux systems that are still working today. Some of those are graphical apps that were written for motif (although admittedly, most are command line apps)
The fact that you are having problems with GTK+ 1.2 apps has more to say about the GTK developers than Linux overall.
You will not find me defending the backwards compatibility of Desktop Environment developers, and the fact that Gnome2 and Gnome3 could not both be insalled on the same system is a perfect example of the problem (and far from the only one, it's not limited to Gnome)
Intel and XMir Posted Sep 17, 2013 12:09 UTC (Tue) by pizza (subscriber, #46) [Link]
I doubt they fail to run or compile due to GTK-1.2 errors specifically, because the GTK folks are pretty good about backwards compatibility within a major API series and explicitly encourage parallel library installations.
That said, I know Fedora (and presumably others) stopped shipping GTK-1.2 libraries by default several years ago because there's nothing in the standard install sets that uses GTK-1.2 any more. It's still available via yum for those that want/need it.
So, I'm genuinely curious as to what you are trying to run/build, and if you checked that the libraries/headers are indeed installed, and if that build error is indeed due to GTK.
And on a tangental note, I've found that Linux (via Wine) often provides better backwards compatibility for older/ancient Windows software than modern Windows does, especially for stuff written during the years of massive DirectX API churn.
Intel and XMir Posted Sep 17, 2013 13:16 UTC (Tue) by dgm (subscriber, #49227) [Link]
> So, I'm genuinely curious as to what you are trying to run/build, and if you checked that the libraries/headers are indeed installed, and if that build error is indeed due to GTK.
My own tools I wrote back in the day, while learning GTK+. GTK+ 1.x has not been available in Ubuntu for a long time (don't know about others), so no headers and no libraries here. Unless I compile my own, something I'm was not very inclined to do.
Intel and XMir Posted Sep 17, 2013 13:35 UTC (Tue) by peter-b (subscriber, #66996) [Link]
GTK+ 1.2 libraries are still in Fedora, fortunately!
Intel and XMir Posted Sep 17, 2013 15:02 UTC (Tue) by mathstuf (subscriber, #69389) [Link]
Ubuntu doesn't ship dillo, the best browser ever? Heresy!
Intel and XMir Posted Oct 1, 2013 12:38 UTC (Tue) by JanC_ (guest, #34940) [Link]
Ubuntu ships Dillo 3.x, which uses FLTK, which is available in Ubuntu.
Intel and XMir Posted Sep 19, 2013 17:33 UTC (Thu) by Wol (guest, #4433) [Link]
And I have a bunch of programs that were sold certified for XP, and now won't even install on Win7.
Cheers,
Intel and XMir Posted Sep 19, 2013 5:24 UTC (Thu) by freetard (guest, #92836) [Link]
Exercise time:
Try compile http://i8086emu.sourceforge.net/ on any recent distribution. RHEL family doesn't count.
Intel and XMir Posted Sep 19, 2013 7:00 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
No gtk2 issues. I did have to pass -fPIC explicitly in the CFLAGS for it build. There were also quite a few apparent 64bit issues. But it built, linked and ran OK.
System: Debian Stable (7.0).
Intel and XMir Posted Sep 19, 2013 11:39 UTC (Thu) by pizza (subscriber, #46) [Link]
Compiled just fine (even with the GUI) on Fedora 19 (x86_64). I had to add '-fPIC' to CFLAGS, and add the appropriate -devel packages.
Fedora 19 is about as recent as it gets, BTW.
Intel and XMir Posted Sep 12, 2013 17:21 UTC (Thu) by pizza (subscriber, #46) [Link]
> Red Hat has a good record of control various upstreams by implanting their employees, throwing whatever shit they come up into Fedora and probably fixing some problems when RHEL release is close (for example GNOME Classic mode).
Or to put it another way -- "The people who do the actual work get to decide the direction a project takes."
Intel and XMir Posted Sep 12, 2013 20:44 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
You are right, their great leadership left us a 0.10 (GNOME3 0.10) desktop after many many years of hope.
If you count contribution by counting number of commits, I'm sure that Red Hat should be the "king".
But what kind of product we have at the end of day?
Intel and XMir Posted Sep 25, 2013 18:14 UTC (Wed) by makomk (guest, #51493) [Link]
Red Hat upstream most of their code. What they don't upstream is any of the work required to turn that code into an actual working release, which means the upstream releases of Red Hat-run projects are often unusable. Take for example PulseAudio - the latest version, 4.0, includes a patch that breaks resampling in a number of apps because it's half-baked and should never have been merged in that state. The (rather trivial) revert for this is upstream - mixed in with a number of other major changes that are inevitably going to cause their own regressions. There's no bugfix-only releases anymore.
Red Hat aren't affected by the fact all the upstream "releases" are actually semi-working code dumps - they employ the PulseAudio developers, and they effectively make the Red Hat packages into the real release by cherry-picking the safe patches and taking regressions seriously. (They don't necessarily upstream their patches promptly either - I've encountered at least one really obnoxious bug that was patched in the Red Hat packages by Lennart Poettering but not fixed in the upstream version.)
Intel and XMir Posted Sep 11, 2013 16:14 UTC (Wed) by lkundrak (subscriber, #43452) [Link]
> Canonical for a long time said that Mir is just for Unity.
I'd like to run Unity. Why not.
I was running Unity on Fedora. http://fedorapeople.org/~lkundrak/unity/
Intel and XMir Posted Sep 12, 2013 2:47 UTC (Thu) by salimma (subscriber, #34460) [Link] The focus within Canonical is foremost on Ubuntu, all other distributions are secondary. To the point that even their laptop collaborations with Dell tend not to work so well when you either install another distro or upgrade major components. Canonical simply could do much, much better at collaborating upstream.
Intel and XMir Posted Sep 12, 2013 3:20 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> To the point that even their laptop collaborations with Dell tend not to work so well when you either install another distro or upgrade major components.
I rather see this as a problem of Linux development model.
So I'm a hardware vendor, I have some drivers not in mainline yet. Can mainlining a driver to a futuristic version, say, 3.12 help me get CentOS 6 work on my laptop model?
Intel and XMir Posted Sep 12, 2013 4:37 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Yes. If your driver isn't in the upstream kernel, it's unlikely that Red Hat will backport it.
Intel and XMir Posted Sep 11, 2013 15:44 UTC (Wed) by error27 (subscriber, #8346) [Link]
"would be a lot less hassle for me to get it runnig."
I suspect patching the kernel is less than 1% of the overall hassle. XMir is an X emulator that runs on Mir. So you'd first have to build Mir and get that to work. No one has documented how to build Mir under Fedora yet but it involves patching a bunch of project like gtk, and mesa. Once mir builds, it's unlikely to run so you will also need to code a bunch of things yourself. The coding is going to be 99% of the hassle.
Good luck. :)
Intel and XMir Posted Sep 11, 2013 20:07 UTC (Wed) by drag (subscriber, #31333) [Link]
> XMir is an X emulator that runs on Mir.
Well no, it isn't.
(besides the fact that X emulator doesn't actually exist. It would be like calling Firefox a HTML emulator)
Last time I read anything about it the Mir used Xorg infrastructure for everything to do with graphics drivers, mode setting, keyboard, and most other I/O stuff.
The end result was that Mir ended up a sort of compositor on top of Xorg that provided Mir APIs.
Intel and XMir Posted Sep 11, 2013 15:57 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Why would you want to run XMir? It's worse in every way than running native Xorg. The only reason it exists is to provide a transition strategy to Mir, and right now the only software targeting Mir can't be built on Fedora anyway.
Intel and XMir Posted Sep 11, 2013 16:18 UTC (Wed) by lkundrak (subscriber, #43452) [Link]
> right now the only software targeting Mir can't be built on Fedora anyway.
As the development if quite fast, the Ubuntu packages diverge from upstreams. I'm assuming things will settle a bit as development slows down and things stabilize. It happened with Compiz-based Unity.
Intel and XMir Posted Sep 11, 2013 16:21 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
My understanding was that Unity-compiz still required code that Fedora doesn't ship. Is that out of date?
Intel and XMir Posted Sep 11, 2013 16:27 UTC (Wed) by lkundrak (subscriber, #43452) [Link]
Fedora didn't ship it mostly because noone volunteered to maintain the packages. It certainly didn't conflict with anything in Fedora.
In its early days it depended on features that were not yet in Fedora, such as XInput 2, but that's no longer the case. If I recall correctly their GTK plugin for global menus did not work with version of GTK in Fedora, but I can't remember why. There might have been more small inconveniences, but nothing major and overally the shell was fairly usable.
Intel and XMir Posted Sep 11, 2013 17:29 UTC (Wed) by ovitters (subscriber, #27950) [Link]
It took a few *years* before Unity was in such a state. XMir is of low benefit to anyone (explained various times before, not going to repeat). This project just started and there were loads of problems getting even instructions on how to contribute (if outside of Ubuntu).
Unity is a good example why not to expect Mir to be running on any distribution any time soon.
Intel and XMir Posted Sep 15, 2013 16:06 UTC (Sun) by jspaleta (subscriber, #50639) [Link]
There was a semi-required gtk patch at one point that held up.
Its nice to see a packageset. So what's the plan for these packages now? Are you working on submitting them to maintain them in fedora proper? Compiz based unity is effectively on life support by upstream as Canonical makes the leap to unity next or whatever its formally called..which complicates things a bit for any external distro that wants to ship unity. I can't see the upstream codebase for this is official dead...but by all indication its grown a bit cold. I wonder if anyone over in debian-land is continuing the effort and get old-unity into debian.
Unfortunately the next unity requires mir, and mir is mired with significant upstream patchsets against xorg,mesa and graphics drivers. It's a bit of a rabbithole from a distro package maintainer standpoint..even with the compile from source instructions added to mir's dev pages.
-jef
Intel and XMir Posted Sep 18, 2013 9:43 UTC (Wed) by lkundrak (subscriber, #43452) [Link]
I don't have any plans with Compiz & Unity. Though I find it really neat it is, as you said it, on life support. I didn't intend to push it to Fedora without at least one other person comaintain it either.
My motivation was that desktop that works well for me (which currently is el6 with GNOME 2) is not going to be around forever and I could not see a viable alternative in recent Fedora (situation may have changes with Mate) releases. On the other hand Ubuntu had a beautifully usable desktop.
> mir is mired with significant upstream patchsets against xorg,mesa and
Seems like they're actively trying to get their changes included in respective upstreams, which is a good thing. The challenges in doing that are well illustrated by this article.
Intel and XMir Posted Sep 18, 2013 16:41 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
Honestly, I don't necessarily think you need a comaintainer inside Fedora, you need a cross distro team to be able to maintain the non-packaging system specific bits in a shared workload sort of way.
You should try to have a chat with unpaid volunteers from any other Ubuntu distribution who has beat their head against this particular wall at some point... especially anyone from debian who is keen on using the compiz based unity in their distro of choice. There was an effort made in debian proper, it stalled out due to the early patching requirements.
Find those people and see if you can have a discussion about how to keep the code in a usable state across the distro boundaries with them and have the original Canonical devs in the room at least listening. I mean really, if you can spin up packages for Fedora without any mods to any other packages, then someone from debian proper should be able to re-engineer the packaging and get the equivalent up and running.
My offer still stands, I'll do the package reviews (when I'm actually on the grid and not at the arse end of the earth) for any serious Unity dep chain package submission into the fedora packaging process. But I'd really like to see a plan on how this codebase is going to be maintained via some upstream group now that Canonical looks to be moving on. Hence my suggestion to talk to other distros about their interest in keeping this alive.
-jef
Intel and XMir Posted Sep 12, 2013 17:00 UTC (Thu) by kiko (subscriber, #69905) [Link]
Matthew Garrett's comment mirrors yours about this "not being valuable to Intel customers". But I think that completely fails to recognize that Ubuntu (which will default to using Mir RSN) is the third most widely used OS running on x86 today (behind MacOS and Windows), and that it ships preinstalled on a pretty sizeable number of Intel-based laptops and desktops by the world's largest consumer OEMs, Lenovo, Dell and HP. Canonical helps move a lot of Intel silicon.
It's a bit irksome to see Intel benefit directly from the work that goes into making Ubuntu a real product but then deny it when it comes the time to.. err.. accept a 300-liner? Come to think of it, it's not irksome. It just boggles the mind at how anything that would consider itself wise enough to be deemed "management" would make a decision like this.
Intel and XMir Posted Sep 12, 2013 17:09 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Isn't that the point? It'll ship regardless of whether Intel put any effort into it. Intel still gets their cut of the sale.
The things it makes sense to focus on are the things that the distributions can't provide - support for the features that differentiate Intel and the other options. They don't benefit in any way from the Xmir code.
Intel and XMir Posted Sep 12, 2013 17:23 UTC (Thu) by kiko (subscriber, #69905) [Link]
I'd understand that position if we were talking about anything but maintenance of an open source project.
To carry code is some investment, I agree, but it's not like Canonical engineers aren't willing to help maintain it, and as I was trying to point out, carrying the code will benefit Intel customers directly.
Intel and XMir Posted Sep 12, 2013 20:46 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
While Ubuntu is the only distribution shipping Mir, the customers gain the same benefit regardless of whether or not Intel ship it. Open Source project management doesn't require you to ship anything a downstream wants you to - an obvious analogy is the difficulty involved in getting the Android code into the upstream kernel.
Intel and XMir Posted Sep 13, 2013 0:18 UTC (Fri) by daniels (subscriber, #16193) [Link]
The 'but it's all open source' thing is a bit of a red herring, when Mir is developed under a CLA which allows Canonical — and only Canonical — to relicense code under proprietary terms for its own profit, to the exclusion of all others, including any external contributors.
Intel and XMir Posted Sep 26, 2013 15:52 UTC (Thu) by kiko (subscriber, #69905) [Link]
I don't think that's a fair comment; what we are discussing here is open source, non-CLA'd code in the open source Intel driver -- it's definitely odd to see for political reasons a patch like that backed out, and it's weird that you don't think the same.
Any copyright owner has the right to selfishly relicense code they wrote; the CLA is definitely controversial in its expansiveness (and overall myself I don't like it) but it's not like we are doing something that unusual. Companies with different business models care about different types of freedom and openness. Canonical gives away its main product, with updates, at no cost to the end-user. Redhat and SUSE charge end-users for theirs.
But let me put this controversy a different way, using a contrived analogy (that is contrived only because Intel doesn't license its GPU IP, but I feel is still useful). Let's say there was code in this GPU driver that would only be useful on ARM-based systems -- say, to work with the ARM memory controller and memory architecture. Would it be reasonable for an Intel maintainer to back out patches on the basis that ARM isn't interesting to them?
Intel and XMir Posted Sep 11, 2013 15:11 UTC (Wed) by ovitters (subscriber, #27950) [Link]
Ubuntu can include the patch no problem.
Intel and XMir Posted Sep 11, 2013 16:21 UTC (Wed) by lkundrak (subscriber, #43452) [Link]
> Ubuntu can include the patch no problem.
They certainly will. People that don't run Ubuntu are the ones who loose here, since their distributors would be less likely to include it. That means no Unity for them (unless it would be possible to port it to Wayland, of course), which is a pity -- Unity looks great.
Intel and XMir Posted Sep 11, 2013 17:26 UTC (Wed) by ovitters (subscriber, #27950) [Link]
As said elsewhere, Canonical in their projects really focus on Ubuntu. It usually is very difficult to package their things. This patch is terribly minor compared to what you had to do initially for Unity. If you want Unity, run Ubuntu. Pretty simple and result of the focus of Canonical.
Intel and XMir Posted Sep 12, 2013 3:34 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
Ubuntu specific patches exist for reasons.
From this case, we see that hostility of self-appointed upstream is certainly one of the reasons.
Yes, some software seems ubiquitous in Linux ecosystem, e.g. GNOME. Is it because these software are truly cross-distribution? No, GNOME is very different in every single distribution. GNOME proper (for example Epiphany as default browser) doesn't seem to exist, if we do not count GNOME OS.
Intel and XMir Posted Sep 12, 2013 7:39 UTC (Thu) by ovitters (subscriber, #27950) [Link]
Jeez, get your facts straight and make some sense!
GNOME is not hugely different per distribution. Self-appointed upstream? What do you mean? Obviously upstream is upstream. You make no sense at all. A default application is not the same as having a lot of patches.
GNOME OS is not meant to replace any distribution, which has been explained to you various times before.
A distribution is free to decide things for themselves. Seems you're having an issue with this?!? I don't understand your point actually.
You have an awfully short memory and tend to repeat the same statements. Does not make things true.
Intel and XMir Posted Sep 12, 2013 20:14 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> GNOME is not hugely different per distribution.
How do you measure it?
> GNOME OS is not meant to replace any distribution, which has been explained to you various times before.
It shows that GNOME proper never seem to exist, every distribution has to massage GNOME to get it working.
> A distribution is free to decide things for themselves. Seems you're having an issue with this?!? I don't understand your point actually.
Yes, it is, except Canonical, troll.
Intel and XMir Posted Sep 12, 2013 20:20 UTC (Thu) by ovitters (subscriber, #27950) [Link]
Hahaha, you calling me a troll. Jeez! Anyway, you conveniently again didn't say anything of value, yet again for the x'th amount of time on LWN. Good luck!
Intel and XMir Posted Sep 12, 2013 13:24 UTC (Thu) by robclark (subscriber, #74945) [Link]
>> Ubuntu can include the patch no problem.
> > They certainly will. People that don't run Ubuntu are the ones who loose here, since their distributors would be less likely to include it. That means no Unity for them (unless it would be possible to port it to Wayland, of course), which is a pity -- Unity looks great.
whatever, one patch in xf86-video-intel is going to be such a tiny bit of works compared to getting the rest of the Mir stack going on some other distro (xserver patches, mesa patches, other ddx patches, etc)
This really doesn't change anything. It is just a statement from intel management that they don't want to spend testing/maintenance resources on mir. Which is their decision to make and a completely valid one at that.
Intel and XMir Posted Sep 12, 2013 19:12 UTC (Thu) by hummassa (subscriber, #307) [Link]
> It is just a statement from intel management that they don't want to spend testing/maintenance resources on mir.
It does look more like a statement from intel management saying that they are immature and don't understand what these "free software" and "community" things are about. There is a lot of *that* going around, unfortunately... :(
Intel and XMir Posted Sep 12, 2013 19:44 UTC (Thu) by robclark (subscriber, #74945) [Link]
>> It is just a statement from intel management that they don't want to spend testing/maintenance resources on mir.
> It does look more like a statement from intel management saying that they are immature and don't understand what these "free software" and "community" things are about. There is a lot of *that* going around, unfortunately... :(
whatev.. it's intel's $$ that pays for most of the devel and (all?) the QA on xf86-video-intel, so it's their decision.
The immaturity I see going around is from the people whining about intel not waiting to pay to maintain an ubuntu specific patch.
Intel and XMir Posted Sep 12, 2013 20:08 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
All these maintenance burden shit.
Why Intel, and almost all other hardware vendors always support Windows very well?
Intel and XMir Posted Sep 12, 2013 20:13 UTC (Thu) by hummassa (subscriber, #307) [Link]
This is BS and you know it. The patch was already there, it would be maintained by Canonical, it costed nothing and would continue to cost nothing for the foreseable future.
Intel actually *incurred* in cost, by patching to revert the patch. At their own expense and at everyone else's expense. So, yeah, immature and whining. Pff.
Intel and XMir Posted Sep 12, 2013 21:19 UTC (Thu) by robclark (subscriber, #74945) [Link]
> This is BS and you know it. The patch was already there, it would be maintained by Canonical, it costed nothing and would continue to cost nothing for the foreseable future.
Not BS in the least. I'm sorry if you don't understand sw engineering and QA (or possibly not even looked at the patch), but the patch is adding additional code paths which can only be compiled and tested in a ubuntu environment, thereby incurring additional ongoing maintenance cost.
Sure, just leaving the patch in and letting those codepaths bitrot with no compile testing or runtime testing might not cost anything. But it gains nothing either. And having the patch merged implies it is intel's problem to deal with when the code breaks.
Intel and XMir Posted Sep 12, 2013 21:29 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> Sure, just leaving the patch in and letting those codepaths bitrot with no compile testing or runtime testing might not cost anything. But it gains nothing either. And having the patch merged implies it is intel's problem to deal with when the code breaks.
As some guy already mentioned, additional code path mentions additional chance of bug revelation in driver. Some backend wrapper code is hardly the root cause of bugs after some iterations.
Intel and XMir Posted Sep 12, 2013 21:43 UTC (Thu) by robclark (subscriber, #74945) [Link]
>> Sure, just leaving the patch in and letting those codepaths bitrot with no compile testing or runtime testing might not cost anything. But it gains nothing either. And having the patch merged implies it is intel's problem to deal with when the code breaks.
>As some guy already mentioned, additional code path mentions additional chance of bug revelation in driver. Some backend wrapper code is hardly the root cause of bugs after some iterations.
I don't think that is the issue. xwayland works in a very similar way to xmir (from ddx driver perspective), so any bugs it turns up will be the same.
But the problem is, as code in the driver changes, things on the #ifdef MIR side of the conditional compile might get broken. It is easy to happen, and without having an mir/ubuntu development and test environment, there is no way to catch this. So best to leave maintenance of this patch to people who do (ie. ubuntu/canonical).
As I've mentioned elsewhere, if the ubuntu folks were clever, they would figure out how to have a common API between xmir and xwayland (since really, they are doing basically the same thing), so that the same code paths in the DDX driver would get built/tested in both wayland and mir environments. Then it would be no additional workload for xf86-video-{intel,nouveau,etc} and upstreams would happily carry the patch.
Intel and XMir Posted Sep 12, 2013 21:53 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> But the problem is, as code in the driver changes, things on the #ifdef MIR side of the conditional compile might get broken. It is easy to happen, and without having an mir/ubuntu development and test environment, there is no way to catch this. So best to leave maintenance of this patch to people who do (ie. ubuntu/canonical).
I believe that Intel does have some Ubuntu infrastructure, otherwise how can they release driver installer for Ubuntu 13.04?
> As I've mentioned elsewhere, if the ubuntu folks were clever, they would figure out how to have a common API between xmir and xwayland (since really, they are doing basically the same thing), so that the same code paths in the DDX driver would get built/tested in both wayland and mir environments. Then it would be no additional workload for xf86-video-{intel,nouveau,etc} and upstreams would happily carry the patch.
Remember that the XMir patch is first accepted by the driver developer then reverted by "the management". Your idea is probably good in technical sense, but it is a political story here.
Intel and XMir Posted Sep 12, 2013 22:14 UTC (Thu) by robclark (subscriber, #74945) [Link]
> I believe that Intel does have some Ubuntu infrastructure, otherwise how can they release driver installer for Ubuntu 13.04?
I don't have the behind-the-scenes view, so couldn't tell you, but since 13.04 is x11 based, I'd have to guess that it is sufficiently similar to other distros to not cause major extra work on intel's part. It is mainly just a matter of installer/packaging rather than being different code paths that aren't even compiled on other distros.
> Remember that the XMir patch is first accepted by the driver developer then reverted by "the management". Your idea is probably good in technical sense, but it is a political story here.
well, it is often the case that the developers aren't the ones caring about scheduling and budget. Maybe Chris should have checked w/ his boss first before merging the patch.
But none of this means there is any "political story" here. I probably won't be able to convince anyone who wants to see a political controversy here otherwise, anymore than I could convince some people that there are not aliens in area-51. But I strongly suspect the real behind the scenes story here is a lot more boring... A pointy-haired-boss somewhere realized that it would cost extra $$ and staffing to maintain the xmir support. So out it went.
And anyways, where is the problem in that? Intel funds most of the devel and testing for intel drivers, so it is their decision to make. Let the mir and xmir developers, who have the right environment for test/devel maintain the patch. No one forced them to choose to make mir.
Intel and XMir Posted Sep 12, 2013 22:35 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> It is mainly just a matter of installer/packaging rather than being different code paths that aren't even compiled on other distros.
Seems like you have major problem with code paths. The fact is that many many software support multiple backend no problem.
> But none of this means there is any "political story" here. I probably won't be able to convince anyone who wants to see a political controversy here otherwise, anymore than I could convince some people that there are not aliens in area-51. But I strongly suspect the real behind the scenes story here is a lot more boring... A pointy-haired-boss somewhere realized that it would cost extra $$ and staffing to maintain the xmir support. So out it went.
Oh, cool, the fancy "boss" understand the issue of Mir and Wayland better than the driver developer.
>And anyways, where is the problem in that? Intel funds most of the devel and testing for intel drivers, so it is their decision to make. Let the mir and xmir developers, who have the right environment for test/devel maintain the patch. No one forced them to choose to make mir.
Yes, your god Intel can do whatever no problem
Intel and XMir Posted Sep 12, 2013 23:19 UTC (Thu) by pizza (subscriber, #46) [Link]
> Seems like you have major problem with code paths. The fact is that many many software support multiple backend no problem.
This statement conveys that you have little to no experience writing, testing, or supporting software, yet you presume to tell others how it should or shouldn't be done.
Which, incidentally, sums up your attitude in this thread. What I find sad is that in doing so, you are engaging in the very behavior that you are ascribing to others. (This is a phenomenon known as "projection", BTW)
Intel and XMir Posted Sep 12, 2013 23:55 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
> This statement conveys that you have little to no experience writing, testing, or supporting software
So what kind of experience do you have? Never able to get software working using multiple backends?
> yet you presume to tell others how it should or shouldn't be done.
Intel and XMir Posted Sep 13, 2013 0:18 UTC (Fri) by pizza (subscriber, #46) [Link]
> So what kind of experience do you have? Never able to get software working using multiple backends?
I have fourteen years worth of cross-platform software development experience. And yes, "cross-platform" includes, but is not limited to, "multiple backends".
Intel and XMir Posted Sep 12, 2013 23:58 UTC (Thu) by robclark (subscriber, #74945) [Link]
>> It is mainly just a matter of installer/packaging rather than being different code paths that aren't even compiled on other distros.
> Seems like you have major problem with code paths. The fact is that many many software support multiple backend no problem.
My point here is that it is codepaths that you cannot even compile test without a different distro setup.
Many successful upstream projects also drop backends which they cannot maintain, fwiw.
>> But none of this means there is any "political story" here. I probably won't be able to convince anyone who wants to see a political controversy here otherwise, anymore than I could convince some people that there are not aliens in area-51. But I strongly suspect the real behind the scenes story here is a lot more boring... A pointy-haired-boss somewhere realized that it would cost extra $$ and staffing to maintain the xmir support. So out it went.
> Oh, cool, the fancy "boss" understand the issue of Mir and Wayland better than the driver developer.
I have been a professional sw developer long enough to see this sort of scenario play out before. Developer wants to add support for some new OS/environment/whatever, QA lead speaks up and says that it will require X additional manpower per release, and Y additional hw setups to test this, head boss crunches the budget/schedule numbers, and decides that it is not possible.
As a developer, I think "great, I can implement this code in a weekend, let's do it!", but I didn't take into account the long term maintenance/QA cost.
Maybe I am disappointed by this. But the boss is the one taking into account the other factors. I don't have to like the decision. But it certainly doesn't make it some big conspiracy.
>> And anyways, where is the problem in that? Intel funds most of the devel and testing for intel drivers, so it is their decision to make. Let the mir and xmir developers, who have the right environment for test/devel maintain the patch. No one forced them to choose to make mir.
> Yes, your god Intel can do whatever no problem
I do not work for intel, I am not affiliated with intel, and they are certainly not my god. I *am* a happy user of intel graphics. And I'm appreciative of the massive development and QA effort they put in. Desktop linux graphics would not be where it is if it weren't for this, and I think others should be more appreciative of what intel does for linux.
I'm just trying (perhaps in vain) to bring a voice of reason to this silly fud-fest that ubuntu/canonical has started.
Intel and XMir Posted Oct 1, 2013 13:10 UTC (Tue) by JanC_ (guest, #34940) [Link] My point here is that it is codepaths that you cannot even compile test without a different distro setup. What if you consider the Canonical employees as part of upstream, as maintainers (both development & QA) for that part of the code? It's not like Linus, the Linux Foundation, or any of the other linux developers have hardware to compile & test all linux architectures, drivers & features for example... Of course, if at some point in time Mir-related problems start to accumulate and nobody fixes them (if it becomes unmaintained), then you should drop support for it.
Intel and XMir Posted Sep 13, 2013 10:50 UTC (Fri) by hummassa (subscriber, #307) [Link]
You started your response with an ad hominem fallacious attack:
> I'm sorry if you don't understand sw engineering and QA (or possibly not even looked at the patch)
and ended it in an slippery slope fallacious attack:
> And having the patch merged implies it is intel's problem to deal with when the code breaks.
I'm sorry, but if there is any truth in between, it's not worth it.
Intel and XMir Posted Sep 13, 2013 13:49 UTC (Fri) by robclark (subscriber, #74945) [Link]
Fair enough, not much substance to the counter-argument. But there really wasn't much substance to the "This is BS" argument that I was countering. How do you argue with someone who is claiming the sky is green? It just isn't!
It doesn't cost intel nothing to maintain and QA the patch. Maybe someone from canonical will send patches after the fact when things break. That doesn't really help for QA'ing releases. And since this is something that intel funds, it is their decision to make.
Intel and XMir Posted Sep 11, 2013 17:20 UTC (Wed) by marduk (subscriber, #3831) [Link]
Canonical's problem isn't a technical one, but a PR problem. You've got to have a lot of weight to throw around if you want to be "disruptive" in the Open Source community, and Canonical has not yet learned this. You either go with the flow or wait a while until you've got enough street cred to be "disruptive." Unfortunately, to the perception of many, Canonical started being "disruptive" as soon as they got a decent share of the consumer market, but didn't wait until they got enough share of buy-in from OSS developers. It takes a certain kind of company to be able to come in and say "Here's our stuff. It's awesome. Now drop whatever it is you're doing and use it!" That kind of bravado is usually reserved for the big guys, like Apple and Microsoft.
and Google.
Intel and XMir Posted Sep 11, 2013 19:49 UTC (Wed) by smurf (subscriber, #17840) [Link]
Actually that kind of bravado ^w success, in the Linux world (and beyond), is reserved for infrastructure stuff that's clearly so much better than the alternative that pretty much everybody decides to use it. Despite actually having to learn some new tricks.
Dbus, for instance. Or udev. Or git. Or cups.
Systemd isn't quite in that position yet, but only because it requires Linux – and thus Debian drags its feet.
Mir will never get there. It has zero benefits WRT Wayland and a more restrictive license. And getting Unity to run on Wayland instead of Mir is probably not THAT difficult.
Intel and XMir Posted Sep 12, 2013 4:06 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
Wayland will never get there. It has zero benefits WRT Mir and a more permissive license. And getting GNOME to run on Mir instead of Wayland is probably not THAT difficult.
Intel and XMir Posted Sep 12, 2013 9:28 UTC (Thu) by Frej (subscriber, #4165) [Link]
Stop feeding the Troll!
Intel and XMir Posted Sep 12, 2013 4:03 UTC (Thu) by maxiaojun (subscriber, #91482) [Link]
So a small company cannot develop some unique stuff for their own small distribution?
I rather see systemd "disruptive", as its primary author stridently ask everybody to follow.
Intel and XMir Posted Sep 11, 2013 20:08 UTC (Wed) by Kayden (subscriber, #89093) [Link]
Does anyone know if the other drivers (such as xf86-video-ati, xf86-video-nouveau) have landed XMir support? I didn't think that anybody had merged XMir support.
Intel and XMir Posted Sep 12, 2013 0:27 UTC (Thu) by airlied (subscriber, #9104) [Link]
no and they have no intent to merge it either until the X server code is upstream in the X server, since they can't even build it otherwise.
Now if that happens i've no idea.
Intel and XMir Posted Sep 12, 2013 15:43 UTC (Thu) by chadversary (subscriber, #71202) [Link]
On a related note, Mesa's EGL also lacks Mir support, despite that Canonical submitted the needed patches to mesa-dev months ago. The patches have received zero replies because, I assume, no Mesa committer knows how to review their correctness nor test them.
Intel and XMir Posted Sep 11, 2013 20:27 UTC (Wed) by kugel (subscriber, #70540) [Link]
I'm undecided.
On the one hand I feel that any driver is not in the position to make such a move. The driver should enable to use the hardware on whatever platform the costumer of the hardware wants to use it on (where feasible, but this 300 line change is feasible).
On the other hand I can understand that a project doesn't want code (and the associated maintenance burden) when the code doesn't align with the maintainers interests (or even work against them).
But there is one thing that I totally don't understand: why does a device driver and/or mesa even require display specific code in the first place. To my understanding a driver should pretty agnostic to whatever client code. The client code (display server) is calling the driver's APIs (even generic stuff like OpenGL in this case), not the other way around. This situation I find strange and I think Intel shouldn't even be in the position that requires a decision (technical or political).
Is the mesa architecture just bad in this detail or am I missing something?
Intel and XMir Posted Sep 11, 2013 21:20 UTC (Wed) by Frej (subscriber, #4165) [Link]
The intel driver in question is xf86-video-intel, which is not a mesa driver, it is the xorg driver.
Read up on
wayland.freedesktop.org/architecture.html
Somewhat more technical :)
Intel and XMir Posted Sep 12, 2013 6:17 UTC (Thu) by kugel (subscriber, #70540) [Link]
Ah, so there was my confusion. So this all is about the driver for X which needs to modified to work with non-X systems?
Okay, these were probably design with X (and only X) in mind and that simplified the driver development back then. But I still think that a proper thing would be a generic driver API X/Wayland/Mir should be backed by.
Intel and XMir Posted Sep 12, 2013 8:56 UTC (Thu) by Frej (subscriber, #4165) [Link]
A more unified driver interface is what you get, when all this is done (10+ years?). Wayland does not have device specific drivers. Instead you need a kernel drm driver and some user space part in mesa (or your own GL implementation).
I think there is some tiny integration needed between Wayland and mesa(or similar) for EGL to work (and similar Mir). But EGL is just another windowing API instead of GLX, not the core parts of opengl itself. Windows has WGL, osx has CGL, EGL is supposed to be portable API.
Intel and XMir Posted Sep 12, 2013 17:24 UTC (Thu) by glisse (subscriber, #44837) [Link]
It's not a driver for X that needs to be modified for non X system. It's a driver for X that need to be modified so X emulation in Mir can work.
So right now you have XApp talking to Xserver talk to Xdriver (xf86-video-intel in this case).
When running Xapp inside Mir you have Xapp talking to modified Xserver that talk to Mir and to modified Xdriver (xf86-video-intel in this case).
The modified Xdriver also talk to Mir and to the hardware. Mir in itself needs another completely different driver than xf86-video-intel. In this case a GL driver.
So a native mir app would talk to mir server and to a graphic driver (GL being the obvious and only choice at the moment). Mir server itself would talk to a GL driver.
I tried to make ascii schematic but lwn just swallow space.
Same logic apply to wayland and to allow an Xapp to run on top of modified Xserver that talk to wayland server and to wayland modified Xdriver.
Intel and XMir Posted Sep 15, 2013 12:59 UTC (Sun) by krake (subscriber, #55996) [Link]
Do you know if this is a short term hack?
I.e. until fully implemented Mir/Wayland "drivers" forXorg exists or a new X server on top of Mir/Wayland have been written?
Or is it unlikely that XMir/XWayland will ever be just normal clients of their respective display server?
Intel and XMir Posted Sep 16, 2013 9:15 UTC (Mon) by dgm (subscriber, #49227) [Link]
I'm not sure about Mir, but under Wayland X11 works exactly the same as under Windows or OS X, that is, X11 should implement the drawing primitives using the drawing API at hand. Under Windows that would be GDI and Quartz under OS X. As Wayland does not force you to use any particular drawing API, you could use OpenGL/EGL or a software renderer or whatever.
If Mir does something different it probably means (wild speculation) that they are cutting corers in the name of shipping earlier. But don't quote me on that.
Intel and XMir Posted Sep 16, 2013 9:32 UTC (Mon) by krake (subscriber, #55996) [Link]
This was my initial understanding as well.
However, when I asked about this on another site's comment section, someone pointed out that the xwayland branch of the driver contains a similar change: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/...
Hence the uncertainty whether this is a short time hack (and removed before merged) or whether it will stay that way for a longer time.
Intel and XMir Posted Sep 16, 2013 15:58 UTC (Mon) by dgm (subscriber, #49227) [Link]
Interesting. Thanks for pointing this out.
Intel and XMir Posted Sep 12, 2013 5:18 UTC (Thu) by Kayden (subscriber, #89093) [Link]
As Frej mentioned, this controversy is about xf86-video-intel, not Mesa.
However, since you brought it up...Mesa's EGL implementation needs to know about the underlying window system (X11, Wayland, Mir, surfaceflinger, etc.), since that's sort of EGL's job. The rest of Mesa doesn't know or care.
The Mesa patches haven't been upstreamed yet either. As far as I know, xf86-video-intel was the only thing that ever had support (if briefly).
Intel and XMir Posted Sep 11, 2013 21:17 UTC (Wed) by sgruszka (guest, #71482) [Link]
Worth to refresh 29 September quote of the week: "as soon as management gets involved in decisions about drivers all hope is lost".
Goobuntu Posted Sep 12, 2013 17:05 UTC (Thu) by kh (subscriber, #19413) [Link]
Does Goobuntu not have plans to use Mir, or does it not count as another distribution?
Intel and XMir Posted Sep 14, 2013 19:05 UTC (Sat) by behdad (subscriber, #18708) [Link]
Ubuntu shouting foul is a joke. And most of us upstream developers prefer not receiving "only happens on Ubuntu" bugs.
Intel and XMir Posted Sep 19, 2013 5:13 UTC (Thu) by freetard (guest, #92836) [Link]
Fuck you upstream trash
This is yet another perfect example of upstream animosity.
Intel and XMir Posted Sep 19, 2013 5:15 UTC (Thu) by freetard (guest, #92836) [Link]
Upstream trashes and Wayland trolls are cancer of GNU/Linux.
Intel and XMir Posted Sep 19, 2013 11:09 UTC (Thu) by cortana (subscriber, #24596) [Link]
Please stop posting stuff like this. It adds nothing to the conversation.
Intel and XMir Posted Sep 20, 2013 2:14 UTC (Fri) by sitaram (subscriber, #5959) [Link]
I couldn't (re-)confirm this on a quick search but don't all Canonical products mandate copyright assignment? (Please correct me if I'm wrong. A link would be even better!)
If so, I think that's a fundamental reason to completely ignore it. Copyright assignment should only be accepted if the assignee is a non-profit, like the FSF.
And to be clear, I mean this even for people who are not contributing, and are therefore not directly affected by the clause. The problem is if the entire product -- every single line -- belongs to a commercial entity, it could become closed source at any time. That's probably OK for a trivial product I can live without if it suddenly disappears from my life, but not for fundamental stuff.
Intel and XMir Posted Sep 20, 2013 2:36 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Not sure why you couldn't find it. A quick search for copyright assignment and Mir turns up http://mjg59.dreamwidth.org/25376.html
Intel and XMir Posted Sep 20, 2013 4:00 UTC (Fri) by sitaram (subscriber, #5959) [Link]
I meant something official.
But even then, I think I searched for the wrong term or didn't look too far down or whatever. Fail on my part. Searching for "canonical contributor license agreement" works.
Intel and XMir Posted Sep 20, 2013 9:18 UTC (Fri) by khim (subscriber, #9252) [Link] AFAICS this agreement is extremely similar to Google's one and lot's of guys seems to cooperate with Google. Of course when you assign code to the Google you also get it back under terms of three-clause BSD license (which is as close to public domain in today's world as you could imagine), but it's still more-or-less identical copyright assignment to what Canonical is doing.
Intel and XMir Posted Sep 20, 2013 10:43 UTC (Fri) by sitaram (subscriber, #5959) [Link]
It might look similar if you don't look too closely but Google does not reserve the right to make a *commercial* product out of it.
Specifically, [1] does not have the equivalent of section 2.3 in [2].
[1]: https://developers.google.com/open-source/cla/individual?...
Intel and XMir Posted Sep 20, 2013 11:03 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
if it's under a 3 clause BSD license, that gives them the right to make a commercial product out of it.
The Apache license allows the same thing.
they don't _need_ a separate clause to give them that permission
Intel and XMir Posted Sep 20, 2013 11:29 UTC (Fri) by sitaram (subscriber, #5959) [Link]
*Anyone* can, not just Google.
With the Canonical agreement, only Canonical can.
Intel and XMir Posted Sep 20, 2013 11:44 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
that's true, but the tone of the post I was replying to implied that signing the canonical agreement would allow canonical to create a commercial product with your code, while signing a google agreement would not allow google to make a commercial product with your code.
If your argument is that with the google agreement _anyone_ can make a proprietary product with your code, but with the canonical agreement only canonical can make a proprietary product with your code, that's a very different thing.
Personally, I have trouble understanding how people can be so opposed to one company making a proprietary product with their code, but seem to be perfectly happy if anyone (including the one company they are complaining about) could do so.
and if you really are in this situation, just license your patch under the BSD license and then everyone can make proprietary versions of your code, and include it in codebases with incompatible licenses.
If you are Ok with this, then you should have no problem at all with Canonical including your code in their codebase, which they _can_ take proprietary in addition to the open version.
Intel and XMir Posted Sep 20, 2013 11:59 UTC (Fri) by sitaram (subscriber, #5959) [Link]
It appears to me that we're rehashing what mjg said in the link Rahul posted somewhere above.
I'll stop here.
Intel and XMir Posted Sep 20, 2013 14:11 UTC (Fri) by khim (subscriber, #9252) [Link] Personally, I have trouble understanding how people can be so opposed to one company making a proprietary product with their code, but seem to be perfectly happy if anyone (including the one company they are complaining about) could do so. In the last case they are creating digital commons which everyone (yes, including the one company they are complaining about) can use for anything. In the first case they are acting as a unpaid workers and help to produce freemium software package which can/will be sold by one particular company. and if you really are in this situation, just license your patch under the BSD license and then everyone can make proprietary versions of your code, and include it in codebases with incompatible licenses. Everyone will be able to use my patch in their own proprietary projects but I will not be able to use their work in my proprietary project? Do you feel it's fair? Both FSF's and Google's agreements feel “fair” (FSF's one gives noone right to create proprietary forks while Google's one gives everyone right to create proprietary forks) while Canonical's one is most definitely one-sided. BTW people start to be wary of FSF's agreement after GPLv3 fiasco because FSF relicensed their work under terms they don't like while they could do nothing (well, they could always leave GNU project and go back to GPLv2—and some of them actually did that).
|
|||||||||||||