Page 2 of 6 FirstFirst 1234 ... LastLast
Results 11 to 20 of 60

Thread: Luc Verhaegen Comments On Intel/Mir Politics

  1. #11
    Join Date
    Feb 2011
    Posts
    943

    Default

    Quote Originally Posted by Pajn View Post
    if the competition
    plays by the rules with Intel now didn't.
    What specific rules have Intel broken?

  2. #12
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by Pajn View Post
    The whole Wayland vs. Mir is just fanboys and hatred.
    People who care about the technology doesn't rely care.
    No one gets hurt by having a competition if the competition plays by the rules with Intel now didn't.
    I'm really tired of this kind of comments. I'm giving free testing to Canonical's Mir, so please stop calling me a hater (and don't deny you did, because you clearly generalized to everyone who tries to make sense out of it). The fact is I care about the technology, and that's why I don't bitch about all of the other NIH syndromes around open source (including the whole systemd/upstart situation), because most actually bring some differences. This time, it introduces more severe fragmentation (I'm aware it's partially alleviated by toolkits), and I'm still waiting to see any reason for it. Also, I'm completely against running DEs on XMir because I care about the technology, and specifically I care about friends who will be using this technology. That's also why I test it whenever I can. Luckily, my flavor of choice won't use it in 13.10.

  3. #13
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by TheBlackCat View Post
    What specific rules have Intel broken?
    They showed a policy they never seemed to have (management reverting a patch) just because it helped a specific group. I don't think that's very community friendly, even when the ones taking profit of it are Canonical. Picture this situation: you are an independent developer, you take the time to design a patch to do something, you pass through all of the process of getting your patch merged, and then some anonymous individual decides to revert it because they do not condone the actions of a group who is benefitted by your patch. I don't think that's OK. If it got accepted, it means there was no technical reason to reject it.

  4. #14
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    302

    Default

    Quote Originally Posted by mrugiero View Post
    Yes, I commented before reaching half of the article, my bad on that. However, you stopped to make an article about that, while I don't recall you mentioned Canonical as an example in the previous article, while you did mention Intel proves your point now. Both of them proved your point.

    Also, as I discussed in the original thread about Intel reverting the patch, even though it's ugly that the management gets to choose about it, they are paying those devs, and they don't want them to maintain that support (even if the patch is trivial) on their money. If the ones maintaining it will be from Canonical, then it's probably easier for them to just skip all of the upstream revisions and just get it out of tree, so I think Chris shouldn't have done the patch in the first place, until it stops being a one distro solution, since until then it makes more sense in downstream. Of course, one could argue he did it in his free time, but I think if that's so, he should state it, so every discussion about Intel here will be over with the "they rejected a free patch just because of politics" statement.
    TBH, I thought that Intel was in the business of selling hardware, and that therefor providing good driver support should be their prime concern. Reinventing the X server, or fighting battles over such things, should be less of important. With this move intel seems to have forgotten about this niggle.

  5. #15
    Join Date
    Mar 2012
    Posts
    184

    Default

    Quote Originally Posted by mark45 View Post
    No it's not, unless you're a drama queen type. It's stupid for Intel to support a product of a different company which directly competes with its own product (Wayland devs are paid mostly by Intel/Red Hat). Folks, this is not socialism where anyone has to be nice to the point of supporting its own competition, it's about winning and making money, get real.

    This is what every open source company does, on the surface they pretend they're nice and "share" everything they can with everybody (call it neo-socialism or whatever) but in reality every open or non-open source company only cares about growing profits, market expansion and crushing the competition. There was never a time "when companies were good".
    +1 to this especially the second part

  6. #16
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by Honton View Post
    You need to do more than writing the patch. You need tp prove you will be there for the entire life time to maintain it. If not you can't do that it will become Intel's burden. They have solid reasons to back out of this. Canonical can pick up the patch if they like such non-CLA code.
    Yes, but that's for getting accepted. If it got accepted, it means the maintainer was convinced enough.
    Also, I mentioned several times already that they can pick up the patch, and that I do think it belongs to downstream. This doesn't change the fact management choose politics over technical reasons. On the technical side, I will always trust more the maintainer than the manager, and I do that because the maintainer is usually someone trained to pay attention this technical details, while management is trained to evaluate more on the costs/benefits side.

    Quote Originally Posted by libv View Post
    TBH, I thought that Intel was in the business of selling hardware, and that therefor providing good driver support should be their prime concern. Reinventing the X server, or fighting battles over such things, should be less of important. With this move intel seems to have forgotten about this niggle.
    Yes, but you are wrong in one part of your article: the fact Ubuntu has a sizable portion of the desktop Linux doesn't change the fact it's under 4% of the market share, and I'm actually giving an exaggerated big number just to be sure, so it's probably not a sizable portion of their client base on the desktop. They probably think their investment on Wayland outweighs what they gain from selling computers to Ubuntu users, and probably expect either the mobile or the enterprise users to make more money for them, and probably think this will happen with Wayland, not with Mir.

  7. #17
    Join Date
    Sep 2012
    Posts
    252

    Default

    Quote Originally Posted by mrugiero View Post
    I'm really tired of this kind of comments. I'm giving free testing to Canonical's Mir, so please stop calling me a hater (and don't deny you did, because you clearly generalized to everyone who tries to make sense out of it). The fact is I care about the technology, and that's why I don't bitch about all of the other NIH syndromes around open source (including the whole systemd/upstart situation), because most actually bring some differences. This time, it introduces more severe fragmentation (I'm aware it's partially alleviated by toolkits), and I'm still waiting to see any reason for it. Also, I'm completely against running DEs on XMir because I care about the technology, and specifically I care about friends who will be using this technology. That's also why I test it whenever I can. Luckily, my flavor of choice won't use it in 13.10.
    No having Mir and Wayland doesn't introduces severe fragmentation. Neither Mir
    nor Wayland have any built in toolkit. All renderings are done to buffers and buffers
    alone. And because of that no software like xclock or xcalc will be written for any
    of the as that simply isn't possible. Toolkit is what will be used and if a toolkit
    supports both your app bill support both.

    And I don't know what running a DE in XMir have to do whit any of this. If you
    think it's pointless then god don't do it, nobody cares.

  8. #18
    Join Date
    Feb 2009
    Posts
    137

    Default

    Quote Originally Posted by libv View Post
    TBH, I thought that Intel was in the business of selling hardware, and that therefor providing good driver support should be their prime concern. Reinventing the X server, or fighting battles over such things, should be less of important. With this move intel seems to have forgotten about this niggle.
    While your logic makes sense, I think you're overdoing it.. Maybe Intel is just worried about future maintenance burden of something they don't understand the reason to exist.

    Given Intel's history with open source, I'm inclined (though certainly with eyes opened) to believe there's a valid reason behind droping XMir support until proven otherwise.

  9. #19
    Join Date
    Feb 2009
    Posts
    137

    Default

    Quote Originally Posted by Pajn View Post
    No having Mir and Wayland doesn't introduces severe fragmentation. Neither Mir
    nor Wayland have any built in toolkit. All renderings are done to buffers and buffers
    alone. And because of that no software like xclock or xcalc will be written for any
    of the as that simply isn't possible. Toolkit is what will be used and if a toolkit
    supports both your app bill support both.
    What about the maintainers of QT, GTK and so on? They need to double the effort to support and maintain both Mir and Wayland.
    Bugs found and fixed on Mir aren't going to be bugs found and fixed on Wayland and vice-versa, therefore fragmenting efforts.

  10. #20
    Join Date
    Jun 2009
    Posts
    1,020

    Default

    Quote Originally Posted by libv View Post
    TBH, I thought that Intel was in the business of selling hardware, and that therefor providing good driver support should be their prime concern. Reinventing the X server, or fighting battles over such things, should be less of important. With this move intel seems to have forgotten about this niggle.
    the problem with your logic is that you bypass all past canonical bad decisions and go straight to intel sell hardware and money grow on the floor so there is no reason to reject it, canonical has indeed over time a very bad track in maintaining projects even internally and intel is not an non-profit foundation. simply put an good manager realized "why in the hell we have to put money to maintain a canonical exclusive project for their own exclusive product that only works with their exclusive DE??" and after check some project maintain history i would have made the exact same bussiness decision.

    you could argue they support android but the solid truth is they did so because they see profit in that platform and choose to support it, it wasn't google forcing intel.

    google since they bought android they keep their specific android only code downstream and only upstream the non android specific code which from my POV is the proper professional way of doing things, you assume the cost of your fork and contribute back all the useful code for everyone else to keep the community support[i know they aren't exactly perfect at it but at least they try].

    beside mir situation im sure intel don't support hurd, bsd, amigaOS, genode, etc. either

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •