Announcement

Collapse
No announcement yet.

Canonical Is Hiring More Mir, Unity Developers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by seb24 View Post
    1 ) Fail : Canonical work in a Qt and Gtk backend
    2 ) They have some patch for mesa
    3 ) Nouveau, Intel and Radeon work yet on Mir and Wayland
    4 ) Lol they support it because The dev of SDL work for Valve and Valve support Ubuntu
    5 ) bullshit again
    6 ) Yes saying nothing interesting

    Reason to have more than one project :
    1 ) No more application depending directly for a display server.
    2 ) If a project fail we have another option
    3 ) People can choose what is better depending what are their needs
    To resume : all the avantage offer by the free software phylosophy... Not from the proprietary philosophy...
    1.) the qt backed barely working is there, show me the bazaar repo for gtk cuz i can't find it
    2.) no, Mir still can work with noveau,intel and amd in mesa but if tomorrow wayland set EGL 1.1 and ask to remove 1.0 wayland will have support the same day while canonical will have to fork to maintain the previous version until they migrate for example, not official means nobody cares if a change break Mir <-- that is my point
    3.) SDL2 is in code freeze and only have wayland backend official and Valve have not announced support for Mir nor SDL main developer has either, so in best case scenario SDL will not support Mir at release time because the 2.1 branch have 0 Mir code, so if such code exist at all will land in 2.2 that is far away
    4.) most enterprise application give higher priority to RHEL, you can call support yourself and certify it. im not saying right are impossible to install in ubuntu but nobody pays that ludicrous amount of cash for a software to install it outside redhat with gold 365 support plan, unless you are those that live in the Oz land that believe anyone win money with ubuntu and redhat evil eyed reviewers to be in the top fortune 500 list of companies
    5.) wine use its own render api base on GDI and that need to be ported too, is unrelated to SDL

    Comment


    • #42
      Originally posted by BO$$ View Post
      Is it really that hard to believe that Wayland isn't the greatest piece of software in the world and that others consider that they can do better?
      As long as no one can provide any valid reasons why Mir is needed, yes.

      Canonical has provided not even one valid reason why they couldn't use Wayland, or why it's necessary to create Mir. Vague PR doublespeak about "unforeseen problems" and "not fitting our business plan" or whatever do not count.

      The justifications of Ubuntu fanboys/girls are even more pathetic. They all go along the lines of:
      - "it's good to have alternatives" (no, there's no inherent value in alternatives if there's no valid reason for them to exist and good reasons for them not to)
      - "there are already X number of package managers/sound servers/desktops/file systems/init systems, so why not display servers" (because the graphics stack is not comparable to any of those things, and compatibility is crucial in this area)
      - "Mir is good because Wayland started developing faster after it was announced" (a - not true, and b - if the only benefit of Mir is the supposed speeding up of Wayland, then logically it'd be even better to forget Mir and help with the development of Wayland!)
      - "everyone is just jealous of Canonical because they're the bestest and neatest Linux" (stupid, juvenile, fallacious argument that tries to distract from the real issue)
      - "Mir needed to be done because Wayland was taking too long" (yeah, real smart... Wayland is taking too long, so let's not contribute to Wayland development, instead, let's start a NEW project...)

      etc. etc.

      I'm looking forward to the day we can put all this Mir nonsense behind us and all concentrate on Wayland.

      Comment


      • #43
        Originally posted by dee. View Post
        As long as no one can provide any valid reasons why Mir is needed, yes.

        Canonical has provided not even one valid reason why they couldn't use Wayland, or why it's necessary to create Mir. Vague PR doublespeak about "unforeseen problems" and "not fitting our business plan" or whatever do not count.
        To be fair there is one real difference between Mir and Wayland: Mir is using test-driven development.

        Of course they haven't pointed out any flaws in Wayland that test-driven development would have corrected, nor is there any reason they couldn't have made their test-driven version API compatible at the very least, nor have they provided any reason to think that test-driven development can compensate for rushing a central part of the software stack (poorly-thought-out tests are not much better than poorly-though-out code), nor is there any reason to think that test-driven development can compensate for not having anyone on the team who has any familiarity with this sort of project (you can't write good tests if you don't know what to test), nor has it even been established conclusively that test-driven development is really superior.

        But it nevertheless is a real difference. As you probably guess, though, I don't think this is a valid reason to start over from scratch.

        Comment


        • #44
          Originally posted by TheBlackCat View Post
          To be fair there is one real difference between Mir and Wayland: Mir is using test-driven development.

          Of course they haven't pointed out any flaws in Wayland that test-driven development would have corrected, nor is there any reason they couldn't have made their test-driven version API compatible at the very least, nor have they provided any reason to think that test-driven development can compensate for rushing a central part of the software stack (poorly-thought-out tests are not much better than poorly-though-out code), nor is there any reason to think that test-driven development can compensate for not having anyone on the team who has any familiarity with this sort of project (you can't write good tests if you don't know what to test), nor has it even been established conclusively that test-driven development is really superior.

          But it nevertheless is a real difference. As you probably guess, though, I don't think this is a valid reason to start over from scratch.
          Also, test driven development is something different only at the implementation level. Not only this means there is no reason to fork from the protocol (they could still do their own implementation, which wouldn't mess anything), but this technique could be applied from now on if desired. Write the tests, and continue the development as test driven, and problem solved.

          Comment


          • #45
            Originally posted by TheBlackCat View Post
            I am a research scientist, too, and the fact that there are scientists like you who feel that way scares the hell out of me. In fact I was under the apparently naive impression that this was a strawman used by anti-science types to attack scientists. I guess we still need animal and human research ethical review boards after all.
            I meant along the lines of its ok to reinvent the wheel and come up of new tools that do the samething. Sometimes the new tool is better in the different situtions than the first tool. Even better, we learn that the first tool was biased, thus we learn the truth. Same concept with more than one way to approach or solve a problem. Reducancy is important sometimes.

            Comment


            • #46
              Originally posted by dh04000 View Post
              I meant along the lines of its ok to reinvent the wheel and come up of new tools that do the samething. Sometimes the new tool is better in the different situtions than the first tool. Even better, we learn that the first tool was biased, thus we learn the truth. Same concept with more than one way to approach or solve a problem. Reducancy is important sometimes.
              Enough with the vague philosophical arguments. What exactly is the benefit of redundancy in this case?

              Comment


              • #47
                Originally posted by dee. View Post
                Enough with the vague philosophical arguments.
                OH WOW, a linux user whom doesn't want to talk in entrely vague philosophical terms.

                I nearly dropped my pipette I laughed so hard.

                Comment


                • #48
                  Originally posted by dh04000 View Post
                  OH WOW, a linux user whom doesn't want to talk in entrely vague philosophical terms.

                  I nearly dropped my pipette I laughed so hard.
                  It's better to be quiet and be thought a fool, than open your mouth and remove all doubt.

                  Now, either cease behaving like an obnoxious tool, stop dodging and answer the question if you can, or shut up and leave the talking to people who actually know what they're talking about.

                  Comment


                  • #49
                    Originally posted by dh04000 View Post
                    OH WOW, a linux user whom doesn't want to talk in entrely vague philosophical terms.

                    I nearly dropped my pipette I laughed so hard.
                    You used the wrong word there, pal.

                    Comment


                    • #50
                      Originally posted by dh04000 View Post
                      I meant along the lines of its ok to reinvent the wheel and come up of new tools that do the samething. Sometimes the new tool is better in the different situtions than the first tool. Even better, we learn that the first tool was biased, thus we learn the truth. Same concept with more than one way to approach or solve a problem. Reducancy is important sometimes.
                      And that is has what, exactly, to do with my post you were responding to?

                      You said that you found the idea that we might not want to do everything that we are able to do "offensive"? How is that remotely related to your current point that redundancy can sometimes be a good thing?

                      Neither you nor I said anything about redundancy. Further, your constant repetition of "sometimes" indicates that you think that redundancy is not always a good thing. So unless you think that we should do redundant things even when it isn't beneficial, then you seem to be agreeing with me that there are situations that we shouldn't do things just because we can.

                      And if you really think scientists just going around randomly creating radically new approaches to carrying out standard tasks for no reason then you aren't a very good scientist. Scientists certainly do new things and use new approaches when there is a good reason to do so, but they don't randomly re-create whole, well-established procedures from scratch without a very good reason, and reviewers would rightly reject a paper that tried. It adds too many additional variables that can interfere with the experimental approach. Good scientific practice calls for exactly the opposite, in fact. You need to try to make your experiment as similar as possible to the ones you are basing it off of in order to avoid unexpected confounding factors. The principle of changing the absolute fewest number of variables possible is one of the bedrock principles of science.
                      Last edited by TheBlackCat; 27 June 2013, 06:14 PM.

                      Comment

                      Working...
                      X