Wednesday 11 August 2010

Are Intel subverting MeeGo.com?

Well... there's a "challenging" blog title :)

Please read on and allow me to explain.

Intro

So what's making me risk offending one of the powerhouses behind MeeGo?


First off, let me say that I think the answer is "No"; but I do think there's a problem and it should be solved.


So having hopefully gotten your attention; what's the problem? Well, quelle surprise, it's that inconvenient "openness" again.


MeeGo is an open distribution; I don't think that's really in doubt. However there have been many discussions on what makes something open and I'd like to add another: "Inclusiveness".


For the record : In the remainder of this post I've included issues that I've seen raised that I may not personally support.


Issue

The question is ... who gets to use the builds that are produced at meego.com? Well, technically "anyone", but practically "only people who've bought recent Intel hardware".


Why? Because the MeeGo.com builds are optimised for the Intel Atom processor; not a generic x86.


So what's the impact of this?


Pros: Less CPU usage for some functions (3D and audio codecs AFAIUI get +20% performance on certain tasks)


.... that's it


Cons. Well machines with a non-Atom CPU running MeeGo netbook edition may boot up but often fail to run. Additionally non Atom machines can't easily develop for MeeGo (eg the image building app uses ssse3 instructions inside somewhere.)


Impact

If a developer wanders over to look at MeeGo and sees that she needs to buy an Atom netbook to run it then: "Oh, I need special HW to run it? Ubuntu just runs on my laptop. Bye MeeGo, hello Ubuntu."


Making it hard to use MeeGo is *not* inclusive.


Details


The way MeeGo is built any binary could contain SSSE3 instructions; however which ones actually do depends on the optimisation flags used, the compiler version and the source code and and a change in any of them can add or remove instructions.


Essentially it's "random" - or at least not humanly determinable if a given application will suddenly choke on non-Atom hardware.


In irc Thiago scanned the Qt binaries to try and find any SSSE3 instructions. When he ran a quick and dirty analysis he couldn't find any SSSE3 instruction in QtCore and QtWebKit; and found a total of 4 SSSE3 instructions on QtGui - that's many 10s or 100s of Mb of binary code and only a handful of instructions.


So given the entirety of Qt uses *4* instructions there was a challenge to the "performance benefit" it offers by using these options "across the board".

Postition


Given MeeGo.com is supposed to be open and to minimise barrier to entry this exclusion seems wrong.


MeeGo is managed by the Linux Foundation and I was under the impression that we had a Linux Foundation managed build service at build.meego.com; so why are we building for exclusivity and not inclusivity?


Fairness


My understanding of the business model is that Nokia and other vendors would have an internal OBS to allow them to tailor and optimise MeeGo for their commercial product


MeeGo's model is that Intel, Nokia and others (as vendors) have their own internal build service (OBS) to optimise for a commercial product so why does Intel get to optimise for Atom on the MeeGo.com build service?


Why do we optimise for only Atom machines on the MeeGo.com builder? Why isn't that done on build.meego.intel.com? Is Intel essentially using MeeGo.com to make "the Intel MeeGo" not "the community MeeGo"?


Obviously, as a fallback the community OBS is a potential place for this generic build but that was *not* the point. We have often been told that MeeGo *is* the community.


Counters


One point has been of the "cost" of the shared infrastructure and Intel employees having said that Intel should not be burdened with the cost of supporting other arch/platforms/builds.


There's some validity to this - and I don't think the community would object in the slightest to seeing optimisations for Atom made available *as well* as a generic build.


One question is: Is MeeGo an open and inclusive distro? Who dictates the commercial aspects of the "shared resources" and who gets to dictate what is and is not on the agenda.


One argument has been "Intel contributed the hardware and they want it optimised for their platform"; However that's not a community platform; that's a vendor specific build platform.


And are we seriously saying that a vendor producing a version of MeeGo for a non-Intel based x86 device is going to have a problem rebuilding with appropriate gcc flags?


Proposal


Add a 'generic x86' target to the MeeGo.com build architectures. This will form the basis for more inclusive MeeGo variants.


Allow the builder to create targetted binaries for some hardware; this is going to become a requirement as more hardware appears.


As we know: 'optimized for Atom' sells and attracts developers to the platform and a set of development hardware, etc..


But surely we can be "optimized for Atom" without excluding non-Atom users.


This means anyone with a non-Atom device could at least start MeeGo on eg an AMD desktop. As Arjan says: "I and several of my coworkers run MeeGo to develop MeeGo" "it's still very much intended to be a quite complete *client* PC linux"


http://lists.meego.com/pipermail/meego-dev/2010-April/001318.html
http://lists.meego.com/pipermail/meego-dev/2010-April/001392.html


Works for everyone

Well, isn't that the job of MeeGo.com?


MeeGo.com is supposed to be open and to minimise barrier to entry - lets help it do that


Conclusion

The point is that MeeGo should be doing a generic i586 build


Not Intel, MeeGo

5 comments:

  1. I'll add to this that the reception to people asking about other hardware support isn't always clear that it's Intel people defending Intel's right to not spend resources on a competitor (or old) hardware, rather than the MeeGo project saying they don't want to support everything on which it'd work well.

    I *think* I could go to every single one of the threads asking about non-SSSE3 support and find very defensive messages about "why should Intel..." rather than "The MeeGo project aims to be hardware agnostic, however we currently don't have the hardware resources (OBS), QA mechanisms or staff to work on it. Patches and contributions wlecome."

    The problem is that these messages are coming from people who are senior at Intel (say), but also senior within the MeeGo project: with which hat are they answering?

    ReplyDelete
  2. I think this is a biggest problem currently with MeeGo. Out of 5 computers at home none of it can run MeeGo as released on the page. I think Intel still has a little more to learn how to play in an open community like MeeGo Linux. There should be as little discrimination as possible. I hope this gets resolved soon and default builds get build for safe common architecture. Even if it is slow in the end. Slow is far better than not working at all.

    ReplyDelete
  3. You can include the GPU: intel vs nvidia.

    ReplyDelete
  4. I was thinking along the same lines (I had MeeGo running fine & fast on EEE pc 900, but apparently it would be a bit untrustworthy).

    But then, you realize a new supported netbook only costs 300EUR, so I'm not sure I care that much. The bigger problem is lack of nvidia drivers - hobbyist computers typically don't have an Intel gpu, and many of us would like to run MeeGo on a big computer on occasion.

    ReplyDelete
  5. The major issue I have is that SSSE3 optimized binaries will run on a system that does not support the ISA (Instruction Set Architecture) without any kind of warning or error.

    I think that by default Linux should detect this mismatch and by default refuse to run it.

    The runtime issue here should be possible to be cleared up with some changes to binutils/gcc. Making it emit into every object code compiled the level of ISA used by the emitted code. There information is then merged by the linker "ld" to be included in the final executable/DSO. This information is then used by the dynamic-linker to perform detection and rejection.

    Not all binaries on MeeGo make use of SSSE3 instructions and this is the problem. Even though the compiler flag it set to enable the possibility the compiler can select an SSSE3 instruction, but did not need to do so. This means a large number of binaries run fine on non-SSSE3 CPUs and the rarity of the SSSE3 use even in an executable which uses an instruction could mean a random SIGILL crash of the application even though it has been working for a month without problem.


    Other things which are bad with Intel MeeGo is that there should be a big warning on bootup that the distribution you have loaded is optimized for SSSE3 but the hardware of the system does not support it.

    I think an optimized Intel MeeGo distribution is a worthy goal but the method to achieve this is the problem.

    ReplyDelete