Page 5 of 11 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 107

Thread: XBMC Ported To Run On Mir Display Server

  1. #41
    Join Date
    Sep 2012
    Posts
    280

    Default

    Quote Originally Posted by rvalles View Post
    Reminder: The Mir hate train was kickstarted by the "wayland sucks" document they pretty much attached to their announcement. That was a technical argument that wayland sucked and mir was better, and it turned out to just be a battery of misunderstandings by Canonical people on how Wayland works or what Wayland is. If they were afraid as you suggest, this wouldn't have happened at all.
    No, it were just the person writing the wikipage that didn't have everything under control.
    Here is a blog post by a developer knowing what he's talking about and why Mir would have been
    unsuited for Canonical. http://blog.cooperteam.net/2013/03/for-posterity.html
    Also read later post of him if you are interested. They explain some architectural differences between Mir and Wayland
    and why Canonical have chosen those.

    But there are also one more big thing. Look at previous development by Canonical. It fast and may change direction
    over one night. Look at Wayland development: It's better planned (and therefore slower) and lays much more energy
    on having it right at the first time. If Canonical had sticked to Wayland I can guarantee that there would have been
    much energy between Canonical and Wayland developers and probably resulting in a fork sooner or later.

  2. #42
    Join Date
    May 2010
    Posts
    684

    Default

    Quote Originally Posted by verde View Post
    Fantastic job. It seems that porting an application to Wayland AND Mir is not that hard. So there is no reason for community civil war in the end. It would be nice if they have a healthy competition like OpenOffice/LibreOffice have, that will push both projects to a better and better state. Already Wayland project seemS to have accelerated since Mir announced.
    Yeah, but people love drama so much that you will probably continue to see absurd FUD posted about both for years to come.

  3. #43
    Join Date
    Feb 2011
    Posts
    1,134

    Default

    Quote Originally Posted by Pajn View Post
    No, it were just the person writing the wikipage that didn't have everything under control.
    Here is a blog post by a developer knowing what he's talking about and why Mir would have been
    unsuited for Canonical. http://blog.cooperteam.net/2013/03/for-posterity.html
    Also read later post of him if you are interested. They explain some architectural differences between Mir and Wayland
    and why Canonical have chosen those.
    None of those reasons are valid. For example, he admits he was wrong about the input stack, which could have been avoided just by talking to the Wayland devs (which they never did). Similarly, writing server-side buffer allocation in Wayland is trivial (there are already proof-of-concept version), and is much easier than starting over from scratch. Similarly, anything that they needed to do differently could have been done in extensions.

    So no, they still have not provided any valid reason why Wayland is unsuitable. All of their reasons are either false, or would have taken much less work to do within Wayland than starting over completely from scratch.

    Quote Originally Posted by Pajn View Post
    But there are also one more big thing. Look at previous development by Canonical. It fast and may change direction
    over one night. Look at Wayland development: It's better planned (and therefore slower) and lays much more energy
    on having it right at the first time. If Canonical had sticked to Wayland I can guarantee that there would have been
    much energy between Canonical and Wayland developers and probably resulting in a fork sooner or later.
    First, that assumes Mir will be done before Wayland has implemented the missing parts Canonical needs. This is far from certain.

    Even if it was true, that is why Wayland supports extensions. Canonical could have written their own extensions for Wayland that did things quickly and dirty, then ported away from them (or not) when Wayland devs got better implementations in the official protocol. No fork would have been needed, just extensions.

  4. #44
    Join Date
    Jul 2013
    Posts
    68

    Default

    Quote Originally Posted by Nille View Post
    Not sure if serious.
    Oh, I'm serious. I personally see Mark Shuttelworth as the heir to Miguel De Icaza as the prominent leader for divide and rule in FLOSS. All Canonical is bringing to the table is fragmentation.

  5. #45
    Join Date
    Jul 2013
    Posts
    68

    Default

    Quote Originally Posted by jayrulez View Post
    Any fool can criticize, condemn and complain - most fools do.

    Benjamin Franklin
    Yeah! Like the Suffragettes, the Solidarność, like the women in The March on Versailles, this old guy Mandela who spent many years on Robben Island and the Boston Tea Party participants. Fools all of them! Why did they ever bother complaining...

  6. #46
    Join Date
    Sep 2012
    Posts
    280

    Default

    Quote Originally Posted by TheBlackCat View Post
    None of those reasons are valid. For example, he admits he was wrong about the input stack, which could have been avoided just by talking to the Wayland devs (which they never did). Similarly, writing server-side buffer allocation in Wayland is trivial (there are already proof-of-concept version), and is much easier than starting over from scratch. Similarly, anything that they needed to do differently could have been done in extensions.

    So no, they still have not provided any valid reason why Wayland is unsuitable. All of their reasons are either false, or would have taken much less work to do within Wayland than starting over completely from scratch.
    Waylands input stack was at that time not good which isn't wrong. Surly they could have asked the Wayland devs if there soon will be a totally change in input stack soon. I expect that they thought that would have been a very long and difficult journey to make then replace their input stack, I would. Now they didn't and thatís how it is.

    Of course Waylands protocol support server-side buffers. The question is how compatible it would be with the rest of the environments when everyone expects client-side buffers.
    OTE=TheBlackCat;345352]
    First, that assumes Mir will be done before Wayland has implemented the missing parts Canonical needs. This is far from certain.

    Even if it was true, that is why Wayland supports extensions. Canonical could have written their own extensions for Wayland that did things quickly and dirty, then ported away from them (or not) when Wayland devs got better implementations in the official protocol. No fork would have been needed, just extensions.[/QUOTE]
    Mir probably will. It's developed in a much higher peace than Wayland. But I'm also thinking about the future when both are "done"
    and Canonical says next Ubuntu version will have THIS and starts developing it with four months to go.

    And there you have it again. A possible break in compatibility in Ubuntuís Wayland compared to everyone elseís.

    It's better for everyone to have two display servers than one that is incompatible with other builds of itself.

  7. #47
    Join Date
    Jan 2013
    Posts
    1,458

    Default

    Quote Originally Posted by Pajn View Post
    Waylands input stack was at that time not good which isn't wrong. Surly they could have asked the Wayland devs if there soon will be a totally change in input stack soon. I expect that they thought that would have been a very long and difficult journey to make then replace their input stack, I would. Now they didn't and thatís how it is.

    Of course Waylands protocol support server-side buffers. The question is how compatible it would be with the rest of the environments when everyone expects client-side buffers.
    Well, probably more compatible than, say... making an entirely new display server?

    Obviously compatibility is not a concern for Canonical... server-side allocation doesn't make sense on non-mobile environments anyway, so they could have used clientside on the desktop where it's shown to work better anyway, and server-side allocation on the mobile, where they're not concerned with compatibility anyway.

    Mir probably will. It's developed in a much higher peace than Wayland.
    No it's not. That's an illusion born from the fact that Mir is taking advantage of all the groundwork done by Wayland devs. The fact is, Wayland will be usable faster - Wayland phones will be on the market before Mir phones, and Wayland desktops will be available before the Mir desktop (native, not some XMir hack).

    But I'm also thinking about the future when both are "done"
    and Canonical says next Ubuntu version will have THIS and starts developing it with four months to go.

    And there you have it again. A possible break in compatibility in Ubuntuís Wayland compared to everyone elseís.

    It's better for everyone to have two display servers than one that is incompatible with other builds of itself.
    That doesn't make any sense, at all. There's no need to break the client-side protocol in Wayland, ever, because of extensions, and because Wayland provides a stable protocol with guaranteed backwards compatibility.

    If Canonical wants to purposely break compatibility,*that's another matter - as that's what it looks like they're aiming to do, right now.

  8. #48
    Join Date
    Feb 2011
    Posts
    1,134

    Default

    Quote Originally Posted by Pajn View Post
    Waylands input stack was at that time not good which isn't wrong. Surly they could have asked the Wayland devs if there soon will be a totally change in input stack soon. I expect that they thought that would have been a very long and difficult journey to make then replace their input stack, I would. Now they didn't and that’s how it is.
    So they write an entire display server from scratch based on nothing but wrong assumptions, assumptions a single email could have cleared up.

    Quote Originally Posted by Pajn View Post
    Of course Waylands protocol support server-side buffers. The question is how compatible it would be with the rest of the environments when everyone expects client-side buffers.
    Completely, 100% compatible. Wayland is completely agnostic in this regard, Wayland clients don't "expect" either.

    Again, Canonical devs decided to use Mir based on false assumption. They could have cleared this up with one email (the same email they could have used to clear up the input stuff).

    Quote Originally Posted by Pajn View Post
    And there you have it again. A possible break in compatibility in Ubuntu’s Wayland compared to everyone else’s.
    First, it is a possible break. But with the extra manpower that Canonical used for Mir going to Wayland, it may not have been an issue at all. But even if it was, it is clear from how other distros have handled Wayland that until it is actually ready Canonical would be the only one using it, so there wouldn't be a break in compatibility anyway.

    Besides, that is the whole point of having extensions, so that it can be tuned to fit the needs of each project.

    Quote Originally Posted by Pajn View Post
    It's better for everyone to have two display servers than one that is incompatible with other builds of itself.
    Completely and utter nonsense. First, again there is no guarantee that there would have been any differences to begin with. There is no technical basis for any difference, the only even possible reason for a difference is that Canonical wanted to rush Wayland out the door before it was ready. But with the added manpower from Canonical, Wayland very well could have been done early enough that there was no reason for Canonical to rush at all.

    But even assuming they still did, having two things that are almost completely compatible but may have a handful of differences, which clients can easily recognize and deal (when necessary) by testing for particular extensions, is far better for everyone than having two completely incompatible systems that share nothing. It is less work for the server or protocol developers, less work for window manager developers, less work for application developers, less work for distributions, and less work and confusion for users.
    Last edited by TheBlackCat; 07-24-2013 at 12:58 PM.

  9. #49
    Join Date
    Jan 2013
    Posts
    1,458

    Default

    Once this whole Mir business blows up Canonical's face, they'll have to run back to Wayland with their tail between their legs, and all that will be accomplished is that they've wasted tons of money, resources and time of everyone involved.

  10. #50
    Join Date
    May 2010
    Posts
    80

    Default

    Quote Originally Posted by brosis View Post
    Consider opportunity to pull your head out of Canonical and Shuttlewroth propaganda shit(because it is) and think rationally for yourself. There is no such thing as "healthy competition" between opensource projects. There is only competition in reaching the set goal, between projects own "as-is" and "as-planned" that is, but the projects benefit ONLY if their goals do substantially differ. They are fighting with themselves in reaching the goal, not with others.

    For example, Razor-Qt profited from KDE and was never seen as "competition". Now it joined with LXDE and it also was never seen as competition.
    Hell, even BSD profited from Linux opensource driver development by porting. Nothing by rewriting or fighting over community. Competition between opensource projects is actually very harmful.

    Which healthy competition profit do you mean by mentioning "OpenOffice/LibreOffice" ?? Any proof (except worthless taskbar ofc) ? OpenOffice must be burrowed and resources should be used within LibreOffice, or he should completely change its goals to start being profitable instead of damaging behavior.

    For closed source projects, them being completely different world, yes, competition MAY bring improvements in theory, but in practice it brings half-finished projects, with very short support cycle, that are quickly made obsolete by next on-purpose incompatible versions, so that customers upgrade, as in "paying again". It drains money, reassures bad quality over timescale, as well as lots of versions. This is exactly why opensource development is better and is next evolution step. If you call this "healthy competition", no further questions for you.



    Oh, of course he has the evidence. You check the article and report back. Its called wasted resources.

    Second, yes, we would be a LOT better if we had ONE player, browser etc - but UNIQUE in goals. Could be 100 players with own unique approaches. But not 2 display servers targeting same goal, or two Office Suits targeting same goals. Read above - WASTE. And to add spice, its not an end solution, its a display server, its to be built upon. Having several toolkits damages the development rate exactly the same (yes, I am talking about Qt vs GTK useless battle).

    The best solution was to fork Wayland and mod it, then report any changes back. In case they are needed at all. That's how stuff is done.

    Gnome is destroyed thanks to Miguel and co. They abadoned user wishes, they shut the doors, then Canonical had to do something, since they never ever support or package KDE properly for unknown reasons. So they have built their own Gnome and called it Unity. Ofc it WAS different from existing DEs, so it was not met with criticism of fragmentation (except from Gnome), but with criticism of instability (Canonical's unique constant "feature"). Unity is by far not "polished, modern, productive, feature rich (you gotta be kidding me right???)" - Unity is simple and consistent in looks on all possible platforms; and thats where it ends. I worked exclusively with Unity 3-4 months, at first it was very nice, but finally it became very very limited. I got bored. Installed KDE. What a breeze. Canonical thinks now same way with migration to Qt. But this will hardly ever make Unity "feature rich".
    Free and fair competition is one of the reasons why open source development is superior. It makes free competition easier because you don't have to reinvent the wheel before you can get started; instead you take the parts of the code from the other guys you like and add your own things in the stew and then you get what you want. A classic example of this was the Google Linux fork for Android.

    One of the greatest strengths of free software is precisely in that name - we're free to do what we want with it and to combine it in any way we like. By saying "It's Wayland or the highway, pal" you are attempting to construct a monopoly - the very same kind that plague the proprietary software world, and the reason why Richard Stallman started the GNU project in the first place.

    I see there was an edit which didn't show up in my quotebox but did show up in the quote... Oh well.

    I thought it was quite clear by now that the goals of Wayland and Mir are not the same. They're close, but they're not the same.
    Last edited by Ishayu; 07-24-2013 at 02:44 PM.

Posting Permissions

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