Intel and XMir
Intel and XMir
Posted Sep 11, 2013 14:01 UTC (Wed) by maxiaojun (guest, #91482)Parent article: Intel and XMir
Posted Sep 11, 2013 14:37 UTC (Wed)
by hunger (subscriber, #36242)
[Link] (94 responses)
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.
Posted Sep 11, 2013 14:48 UTC (Wed)
by lkundrak (subscriber, #43452)
[Link] (87 responses)
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.
Posted Sep 11, 2013 15:10 UTC (Wed)
by ovitters (guest, #27950)
[Link] (76 responses)
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).
Posted Sep 11, 2013 15:24 UTC (Wed)
by maxiaojun (guest, #91482)
[Link] (71 responses)
The focus within Red Hat is foremost on Fedora, all other distributions are secondary.
Posted Sep 11, 2013 15:35 UTC (Wed)
by ovitters (guest, #27950)
[Link] (27 responses)
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.
Posted Sep 12, 2013 2:34 UTC (Thu)
by daniels (subscriber, #16193)
[Link] (1 responses)
You think this is bad? Try the Phoronix forums.
Posted Sep 15, 2013 4:22 UTC (Sun)
by rahvin (guest, #16953)
[Link]
Posted Sep 12, 2013 2:57 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (18 responses)
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.
Posted Sep 12, 2013 6:16 UTC (Thu)
by ncm (guest, #165)
[Link]
Posted Sep 12, 2013 7:36 UTC (Thu)
by ovitters (guest, #27950)
[Link] (15 responses)
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.
Posted Sep 12, 2013 8:59 UTC (Thu)
by cjwatson (subscriber, #7322)
[Link] (4 responses)
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.
Posted Sep 12, 2013 9:45 UTC (Thu)
by ovitters (guest, #27950)
[Link]
Posted Sep 13, 2013 0:57 UTC (Fri)
by jdub (guest, #27)
[Link] (2 responses)
1) David Miller (bugzilla, not kernel)
(It's Scott and I that argued over 3 and 4.)
:-)
Posted Sep 13, 2013 2:56 UTC (Fri)
by cjwatson (subscriber, #7322)
[Link] (1 responses)
Posted Sep 14, 2013 19:54 UTC (Sat)
by jbailey (guest, #16890)
[Link]
Posted Sep 12, 2013 17:18 UTC (Thu)
by kiko (subscriber, #69905)
[Link] (3 responses)
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.
Posted Sep 12, 2013 21:23 UTC (Thu)
by niner (subscriber, #26151)
[Link] (2 responses)
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.
Posted Oct 1, 2013 12:21 UTC (Tue)
by JanC_ (guest, #34940)
[Link] (1 responses)
Posted Oct 1, 2013 12:31 UTC (Tue)
by niner (subscriber, #26151)
[Link]
[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.
Posted Sep 12, 2013 20:05 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (5 responses)
Go and learn about it, otherwise don't claim anything about Red Hat.
Posted Sep 12, 2013 20:22 UTC (Thu)
by ovitters (guest, #27950)
[Link] (4 responses)
Anyway, I do whatever I please and please just shut the fuck up.
Posted Sep 12, 2013 20:27 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (2 responses)
Posted Sep 12, 2013 22:43 UTC (Thu)
by ean5533 (guest, #69480)
[Link]
Posted Sep 14, 2013 1:49 UTC (Sat)
by liam (guest, #84133)
[Link]
So, "volunteers" are the biggest single contributing body.
Posted Sep 12, 2013 3:49 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (5 responses)
At the end of day, many applications are only certificated with SLES, so nice.
Posted Sep 12, 2013 7:41 UTC (Thu)
by ovitters (guest, #27950)
[Link] (4 responses)
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.
Posted Sep 12, 2013 20:25 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (3 responses)
> 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...
Posted Sep 12, 2013 20:29 UTC (Thu)
by ovitters (guest, #27950)
[Link] (2 responses)
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.
Posted Sep 12, 2013 20:34 UTC (Thu)
by corbet (editor, #1)
[Link]
Posted Sep 12, 2013 20:34 UTC (Thu)
by maxiaojun (guest, #91482)
[Link]
If you do not bother to justify your ungrounded claims, then fine, yet another liar in FOSS world.
Posted Sep 11, 2013 17:15 UTC (Wed)
by drag (guest, #31333)
[Link] (42 responses)
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.
Posted Sep 12, 2013 3:11 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (40 responses)
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.
Posted Sep 12, 2013 14:48 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (37 responses)
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
Posted Sep 12, 2013 20:59 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (36 responses)
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.
Posted Sep 12, 2013 21:15 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
XMir is another inferior solution.
Posted Sep 12, 2013 21:25 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (17 responses)
Wayland is another inferior solution.
If you thought that only your claim is right, then explain again what is free software.
Posted Sep 12, 2013 21:30 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
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.
Posted Sep 12, 2013 21:46 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (7 responses)
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.
Posted Sep 12, 2013 21:50 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
> 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.
Posted Sep 12, 2013 22:04 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (5 responses)
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.
Posted Sep 12, 2013 22:52 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
> If not picking some free software is hostility, then free software is a misnomer of fascist software.
Posted Sep 12, 2013 23:20 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (3 responses)
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.
Posted Sep 12, 2013 23:23 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
SystemD _is_ easier to use than Upstart, especially with its JournalD integration.
Posted Sep 12, 2013 23:33 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (1 responses)
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
Posted Sep 12, 2013 23:41 UTC (Thu)
by pizza (subscriber, #46)
[Link]
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.
Posted Sep 19, 2013 5:04 UTC (Thu)
by jamesh (guest, #1159)
[Link] (2 responses)
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?
Posted Sep 19, 2013 5:13 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Sep 19, 2013 5:36 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
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.
Posted Sep 12, 2013 23:32 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (4 responses)
Posted Sep 12, 2013 23:37 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (3 responses)
Yes, only Fedora fascist can call Ubuntu inferior, not other way around.
> So please just stfu.
Obvious troll obvious.
Posted Sep 14, 2013 23:29 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (2 responses)
Posted Sep 15, 2013 17:14 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
[1]This is a meta-discussion, so it probably doesn't count here.
Posted Sep 16, 2013 22:24 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Sep 12, 2013 21:34 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (2 responses)
> 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.
Posted Sep 12, 2013 23:04 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (1 responses)
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.
Posted Sep 13, 2013 0:10 UTC (Fri)
by robclark (subscriber, #74945)
[Link]
> 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.
Posted Sep 13, 2013 0:25 UTC (Fri)
by daniels (subscriber, #16193)
[Link] (13 responses)
That's two years longer than the period between the initial release of Windows XP, and the release of its last service pack.
Posted Sep 16, 2013 9:23 UTC (Mon)
by dgm (subscriber, #49227)
[Link] (9 responses)
Windows, on the other hand, still supports the same ABI and API since Windows 95. That's 18 years, and still counting.
Posted Sep 16, 2013 16:53 UTC (Mon)
by dlang (guest, #313)
[Link] (8 responses)
Posted Sep 17, 2013 7:09 UTC (Tue)
by dgm (subscriber, #49227)
[Link] (7 responses)
Posted Sep 17, 2013 10:26 UTC (Tue)
by dlang (guest, #313)
[Link]
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)
Posted Sep 17, 2013 12:09 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
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.
Posted Sep 17, 2013 13:16 UTC (Tue)
by dgm (subscriber, #49227)
[Link] (3 responses)
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.
Posted Sep 17, 2013 13:35 UTC (Tue)
by peter-b (guest, #66996)
[Link]
Posted Sep 17, 2013 15:02 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Oct 1, 2013 12:38 UTC (Tue)
by JanC_ (guest, #34940)
[Link]
Posted Sep 19, 2013 17:33 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Sep 19, 2013 5:24 UTC (Thu)
by freetard (guest, #92836)
[Link] (2 responses)
Try compile http://i8086emu.sourceforge.net/ on any recent distribution. RHEL family doesn't count.
Posted Sep 19, 2013 7:00 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link]
System: Debian Stable (7.0).
Posted Sep 19, 2013 11:39 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Fedora 19 is about as recent as it gets, BTW.
Posted Sep 12, 2013 17:21 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
Or to put it another way -- "The people who do the actual work get to decide the direction a project takes."
Posted Sep 12, 2013 20:44 UTC (Thu)
by maxiaojun (guest, #91482)
[Link]
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?
Posted Sep 25, 2013 18:14 UTC (Wed)
by makomk (guest, #51493)
[Link]
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.)
Posted Sep 11, 2013 16:14 UTC (Wed)
by lkundrak (subscriber, #43452)
[Link]
I'd like to run Unity. Why not.
I was running Unity on Fedora. http://fedorapeople.org/~lkundrak/unity/
Posted Sep 12, 2013 2:47 UTC (Thu)
by salimma (subscriber, #34460)
[Link] (2 responses)
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.
Posted Sep 12, 2013 3:20 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (1 responses)
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?
Posted Sep 12, 2013 4:37 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Posted Sep 11, 2013 15:44 UTC (Wed)
by error27 (subscriber, #8346)
[Link] (1 responses)
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. :)
Posted Sep 11, 2013 20:07 UTC (Wed)
by drag (guest, #31333)
[Link]
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.
Posted Sep 11, 2013 15:57 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (7 responses)
Posted Sep 11, 2013 16:18 UTC (Wed)
by lkundrak (subscriber, #43452)
[Link] (6 responses)
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.
Posted Sep 11, 2013 16:21 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (5 responses)
Posted Sep 11, 2013 16:27 UTC (Wed)
by lkundrak (subscriber, #43452)
[Link] (4 responses)
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.
Posted Sep 11, 2013 17:29 UTC (Wed)
by ovitters (guest, #27950)
[Link]
Unity is a good example why not to expect Mir to be running on any distribution any time soon.
Posted Sep 15, 2013 16:06 UTC (Sun)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
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
Posted Sep 18, 2013 9:43 UTC (Wed)
by lkundrak (subscriber, #43452)
[Link] (1 responses)
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.
Posted Sep 18, 2013 16:41 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link]
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
Posted Sep 12, 2013 17:00 UTC (Thu)
by kiko (subscriber, #69905)
[Link] (5 responses)
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.
Posted Sep 12, 2013 17:09 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (4 responses)
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.
Posted Sep 12, 2013 17:23 UTC (Thu)
by kiko (subscriber, #69905)
[Link] (3 responses)
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.
Posted Sep 12, 2013 20:46 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Posted Sep 13, 2013 0:18 UTC (Fri)
by daniels (subscriber, #16193)
[Link] (1 responses)
Posted Sep 26, 2013 15:52 UTC (Thu)
by kiko (subscriber, #69905)
[Link]
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?
Posted Sep 11, 2013 15:11 UTC (Wed)
by ovitters (guest, #27950)
[Link] (24 responses)
Posted Sep 11, 2013 16:21 UTC (Wed)
by lkundrak (subscriber, #43452)
[Link] (23 responses)
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.
Posted Sep 11, 2013 17:26 UTC (Wed)
by ovitters (guest, #27950)
[Link] (4 responses)
Posted Sep 12, 2013 3:34 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (3 responses)
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.
Posted Sep 12, 2013 7:39 UTC (Thu)
by ovitters (guest, #27950)
[Link] (2 responses)
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.
Posted Sep 12, 2013 20:14 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (1 responses)
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.
Posted Sep 12, 2013 20:20 UTC (Thu)
by ovitters (guest, #27950)
[Link]
Posted Sep 12, 2013 13:24 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (17 responses)
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.
Posted Sep 12, 2013 19:12 UTC (Thu)
by hummassa (subscriber, #307)
[Link] (16 responses)
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... :(
Posted Sep 12, 2013 19:44 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (15 responses)
> 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.
Posted Sep 12, 2013 20:08 UTC (Thu)
by maxiaojun (guest, #91482)
[Link]
Why Intel, and almost all other hardware vendors always support Windows very well?
Posted Sep 12, 2013 20:13 UTC (Thu)
by hummassa (subscriber, #307)
[Link] (13 responses)
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.
Posted Sep 12, 2013 21:19 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (12 responses)
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.
Posted Sep 12, 2013 21:29 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (9 responses)
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.
Posted Sep 12, 2013 21:43 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (8 responses)
>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.
Posted Sep 12, 2013 21:53 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (7 responses)
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.
Posted Sep 12, 2013 22:14 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (6 responses)
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.
Posted Sep 12, 2013 22:35 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (5 responses)
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
Posted Sep 12, 2013 23:19 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
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)
Posted Sep 12, 2013 23:55 UTC (Thu)
by maxiaojun (guest, #91482)
[Link] (1 responses)
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.
Posted Sep 13, 2013 0:18 UTC (Fri)
by pizza (subscriber, #46)
[Link]
I have fourteen years worth of cross-platform software development experience. And yes, "cross-platform" includes, but is not limited to, "multiple backends".
Posted Sep 12, 2013 23:58 UTC (Thu)
by robclark (subscriber, #74945)
[Link] (1 responses)
> 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.
Posted Oct 1, 2013 13:10 UTC (Tue)
by JanC_ (guest, #34940)
[Link]
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.
Posted Sep 13, 2013 10:50 UTC (Fri)
by hummassa (subscriber, #307)
[Link] (1 responses)
> 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.
Posted Sep 13, 2013 13:49 UTC (Fri)
by robclark (subscriber, #74945)
[Link]
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
Intel and XMir
Intel and XMir
Intel and XMir
The focus within SUSE is foremost on openSUSE, all other distributions are secondary.
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
2) Robert Collins
3) Jeff Waugh
4) Scott James Remnant
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Description=X Window Virtual Framebuffer
After=network.target
Type=simple
ExecStart=/usr/bin/Xvfb -screen 0 800x600x24
Restart=always
WantedBy=multi-user.target
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Perhaps both of you could stop? Please?
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
> Mir is inferior to Wayland (still), though it's quickly gaining new functionality.
Otherwise I may able to claim that KDE is superior to GNOME.
Intel and XMir
It is, if those features make common tasks less complicated.
It's definitely not completely superior. And once something better comes and the switch is not too complicated, then yes we should switch.
Intel's hostility is mostly reaction to Ubuntu's.
Intel and XMir
Intel and XMir
Lines of code to implement certain functionality and chances to make a mistake.
Creating a technically pointless local fork is hostility and one of the major reasons for fragmentation.
Intel and XMir
Intel and XMir
Intel and XMir
Something works for you doesn't necessarily works for other people (especially true in Linux eco-system as software configurations are way too many)
Intel and XMir
Something works for you doesn't necessarily works for other people (especially true in Linux eco-system as software configurations are way too many)
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
> 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
> juxtaposing words around in a juvenile manner isn't a way you win a arguments or convince people of your position.
Yes, only systemd fascist can call Upstart inferior, not other way around.
Yes, only Wayland fascist can call Mir inferior, not other way around.
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Wol
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Notice how it contains practically no patches with workarounds for anything.
Intel and XMir
The focus within Canonical is foremost on Ubuntu, all other distributions are secondary.
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
> graphics drivers
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
>
> 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
Intel and XMir
Intel and XMir
Is it because it is cheaper to write Windows drivers?
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
Intel and XMir
I'm never say that Intel must accept XMir patch in the first place. The problem is that it is reverted by "the management", not by the driver developer. Then you try to reconstruct a technical reason for that. It is history revisionism at best.
Intel and XMir
Intel and XMir
Intel and XMir
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.Intel and XMir
Intel and XMir