LWN: Comments on "Intel and XMir"

Intel and XMir

JanC_ — 2013-10-01T13:10:03+00:00

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.

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

JanC_ — 2013-10-01T12:38:00+00:00

Ubuntu ships Dillo 3.x, which uses FLTK, which is available in Ubuntu.

Intel and XMir

niner — 2013-10-01T12:31:36+00:00

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]
Description=X Window Virtual Framebuffer
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/Xvfb -screen 0 800x600x24
Restart=always

[Install]
WantedBy=multi-user.target

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

JanC_ — 2013-10-01T12:21:35+00:00

AFAIK there is no guarantee that your unit files will work (as intended) on every systemd-based distro?

Intel and XMir

kiko — 2013-09-26T15:52:20+00:00

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

makomk — 2013-09-25T18:14:11+00:00

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

khim — 2013-09-20T14:11:20+00:00

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).

Intel and XMir

sitaram — 2013-09-20T11:59:45+00:00

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

dlang — 2013-09-20T11:44:24+00:00

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

sitaram — 2013-09-20T11:29:49+00:00

*Anyone* can, not just Google.

With the Canonical agreement, only Canonical can.

Intel and XMir

dlang — 2013-09-20T11:03:17+00:00

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

sitaram — 2013-09-20T10:43:30+00:00

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?...
[2]: http://www.canonical.com/sites/default/files/active/image...

Intel and XMir

khim — 2013-09-20T09:18:23+00:00

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

sitaram — 2013-09-20T04:00:40+00:00

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

rahulsundaram — 2013-09-20T02:36:16+00:00

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

sitaram — 2013-09-20T02:14:48+00:00

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

Wol — 2013-09-19T17:33:33+00:00

And I have a bunch of programs that were sold certified for XP, and now won't even install on Win7.

Cheers,
Wol

Intel and XMir

pizza — 2013-09-19T11:39:15+00:00

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

cortana — 2013-09-19T11:09:53+00:00

Please stop posting stuff like this. It adds nothing to the conversation.

Intel and XMir

tzafrir — 2013-09-19T07:00:39+00:00

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

rahulsundaram — 2013-09-19T05:36:48+00:00

" 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

freetard — 2013-09-19T05:24:59+00:00

Exercise time:

Try compile http://i8086emu.sourceforge.net/ on any recent distribution. RHEL family doesn't count.

Intel and XMir

freetard — 2013-09-19T05:15:48+00:00

Upstream trashes and Wayland trolls are cancer of GNU/Linux.

Intel and XMir

freetard — 2013-09-19T05:13:12+00:00

Fuck you upstream trash

This is yet another perfect example of upstream animosity.

Intel and XMir

Cyberax — 2013-09-19T05:13:05+00:00

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

jamesh — 2013-09-19T05:04:23+00:00

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

jspaleta — 2013-09-18T16:41:59+00:00

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

lkundrak — 2013-09-18T09:43:09+00:00

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
> graphics drivers

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

mathstuf — 2013-09-17T15:02:14+00:00

Ubuntu doesn't ship dillo, the best browser ever? Heresy!

Intel and XMir

peter-b — 2013-09-17T13:35:21+00:00

GTK+ 1.2 libraries are still in Fedora, fortunately!

Intel and XMir

dgm — 2013-09-17T13:16:27+00:00

> 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

pizza — 2013-09-17T12:09:49+00:00

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

dlang — 2013-09-17T10:26:24+00:00

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

dgm — 2013-09-17T07:09:40+00:00

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

nix — 2013-09-16T22:24:10+00:00

Please stop that, I just laughed so loud I woke up my neighbour. :)

Intel and XMir

dlang — 2013-09-16T16:53:04+00:00

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

dgm — 2013-09-16T15:58:25+00:00

Interesting. Thanks for pointing this out.

Intel and XMir

krake — 2013-09-16T09:32:30+00:00

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

dgm — 2013-09-16T09:23:40+00:00

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

dgm — 2013-09-16T09:15:55+00:00

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.