Announcement

Collapse
No announcement yet.

Mir/Ubuntu Developer Talks Up Mir Outside Of Unity 8

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

  • Mir/Ubuntu Developer Talks Up Mir Outside Of Unity 8

    Phoronix: Mir/Ubuntu Developer Talks Up Mir Outside Of Unity 8

    Most talk these days of Ubuntu's Unity 8 next-gen desktop experience and their Mir display server goes hand-in-hand since the change-over is planned in-step before Ubuntu 18.04 LTS, but there's a new Ubuntu Insights blog post up working to promote Mir as more than just tech for the Unity 8 desktop...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Could some one remind me.. Why didn't Canonical just use Wayland?
    Despite asking this, every time an article is posted on this subject, I haven't heard any really good reason yet.

    Comment


    • #3
      They wanted to be ablento use drivers for Android, and they can't be used on Wayland. The real reson for creating the whole thing from the ground up is not clear to me, but I remember they didn't want to use libinput (and they ended up using libinput, some years later).

      Comment


      • #4
        Originally posted by pracedru View Post
        Could some one remind me.. Why didn't Canonical just use Wayland?
        Despite asking this, every time an article is posted on this subject, I haven't heard any really good reason yet.
        They will tell you that it's need for convergence, even though the actual convergence is done by the QML toolkit, which simply has two layouts for the app and doesn't care about the display server.
        They will tell you that it's needed to run on Android phones, even though Wayland compositors ran on Android hardware before Mir was even a thing and Canonical uses libhybris which was developed by Jolla/Mer for Wayland.
        They will tell you that it's needed so that they can have server allocated buffers (http://blog.cooperteam.net/2013/03/s...rs-in-mir.html), even though this has been debunked by Daniel Stone many times and Wayland can do client and server allocated buffers.

        I think that Canonical simply underestimated the amount of work it is as with Ubuntu Touch in general ( remeber that Mark Shuttleworth expected devices to ship as early as Q3 2013, when Ubuntu Touch was basically just a giant mock-up https://youtu.be/sLtcj7FdIYA?t=4m41s) and now they kind of have to stick to it to not lose face, especially since they started of flinging some mud at the Wayland project and made up some poorly researched arguments against it on their Wiki page, which they had to remove later.

        Comment


        • #5
          Originally posted by pracedru View Post
          Could some one remind me.. Why didn't Canonical just use Wayland?
          No one outside canonical really knows. The reasons they listed ending up being technically incorrect, and no more legitimate reasons have been provided other than that they want control.

          My speculation is that this is an example of the Dunning–Kruger effect, Ninety-nine rule, and the Sunk-cost fallacy

          What I suspect happened is that someone inside of Canonical told management that Wayland was trying to do to much and satisfy too many different needs and that this was slowing it down. If Canonical just created something simple for their own needs, they could get it done much faster. The problem is no one at Canonical knew enough about display servers to understand how complicated they really are (the Dunning–Kruger effect).

          So management gave the group some time (probably six months or so judging by the timeline) to get something usable. That is why they kept it a secret, they didn't know whether it would actually pan out. After those six months, the developers had a basic working display server. They thought this was the hard part, and the rest was just finishing touches. So they made the announcement, and set a timeline based on this (lack of) understanding. But then, as they started trying to implement these "finishing touches", they ran into problem after problem. Design decisions in Wayland that they thought were wasting time ended up being important for reasons Canonical didn't have the expertise to recognize. Things that thought would be easy to implement ended up being harder than the display server itself, which Wayland had factored into their timelines but Canonical hadn't.

          So months turned into years, and the simpler, more focused alternative to Wayland ended up adopting more and more of Wayland's design. Things Canonical thought they would implement themselves ended up having to be borrowed from Wayland. They got bit by the Ninety-nine rule, where the "last little bit" of the development ends up taking more time than the "main part" of the project.

          However, by the point this became clear they had put too much resources into Mir. The Sunk-cost fallacy came into play. Add to that the fact that they had burnt too many bridges with their comments early in the Mir development and the fact that Mir had become a matter of pride, and changing course became impossible.

          Again, this is just speculation on my part. But to me it seems to fit what we know about the timeline, people involved, and events after the announcement better than any other explanation I have seen.

          Comment


          • #6
            Originally posted by andrebrait View Post
            They wanted to be ablento use drivers for Android, and they can't be used on Wayland.
            Except not only can they be used, and are being used, Canonical actually used a Wayland Android compatibility layer called libhybris for Mir.

            Comment


            • #7
              Sorry, Canonical. Red Hat beat you at the race once again.

              Comment


              • #8
                To be fair, Wayland is just a protocol. If Canonical decided to use the Wayland protocol, they would still have to write their Wayland display server from the ground up just like Gnome KDE et al have been doing. By not adhering to the protocol, there is an increase in flexibility. If that flexibility has or ever will materialize into any tangible benefit remains to be seen...

                Comment


                • #9
                  Originally posted by pracedru View Post
                  Could some one remind me.. Why didn't Canonical just use Wayland?
                  Despite asking this, every time an article is posted on this subject, I haven't heard any really good reason yet.
                  Because they thought they could make something better than Wayland, and also faster. (to give a sense of scale, Wayland is developed by everyone, Mir only by Canonical)

                  And this is generally the same reason they also made Bazaar, Upstart, and pretty much anything else that crashed and burned in the past.

                  Comment


                  • #10
                    Originally posted by pracedru View Post
                    Could some one remind me.. Why didn't Canonical just use Wayland?
                    Despite asking this, every time an article is posted on this subject, I haven't heard any really good reason yet.
                    They did it, because Wayland wasn't created by them.

                    Comment

                    Working...
                    X