Page 1 of 4 123 ... LastLast
Results 1 to 10 of 32

Thread: Ubuntu Phone 13.10: The Runway Is Clear For Mir

  1. #1
    Join Date
    Jan 2007
    Posts
    14,809

    Default Ubuntu Phone 13.10: The Runway Is Clear For Mir

    Phoronix: Ubuntu Phone 13.10: The Runway Is Clear For Mir

    While the Ubuntu 13.10 release is just over one week away, Mir still hasn't officially landed in the Ubuntu Phone images as the new display server. There's been some bugs but it looks like it will now be landing rather soon...

    http://www.phoronix.com/vr.php?view=MTQ3OTk

  2. #2
    Join Date
    Nov 2010
    Posts
    396

    Default

    looking forward to click packages, which will also translate to the desktop, will be so much easier to make apps portable and to share them.

  3. #3
    Join Date
    Aug 2012
    Posts
    458

    Default

    Quote Originally Posted by madjr View Post
    looking forward to click packages, which will also translate to the desktop, will be so much easier to make apps portable and to share them.
    How do they compare to mac .dmg files, which I understand (I've never used mac, just heard about it) is the best in application install and uninstall due the process literally being, drag into a folder to install and drag out to remove. Are these similar or more like a .deb that carries all its dependency with it?

    Warning, talk to me like I'm 5, I'm very tired and will have trouble understanding.

  4. #4
    Join Date
    Jul 2013
    Posts
    46

    Default

    Quote Originally Posted by dh04000 View Post
    How do they compare to mac .dmg files, which I understand (I've never used mac, just heard about it) is the best in application install and uninstall due the process literally being, drag into a folder to install and drag out to remove. Are these similar or more like a .deb that carries all its dependency with it?

    Warning, talk to me like I'm 5, I'm very tired and will have trouble understanding.
    im not sure if we will be able to drag to install and to uninstall but the new package will be kinda like .dmg the files will contain theyr on dependencies and stuff like that inside it, also meaning every app will be sandboxed.
    i might be wrong but this is what i understand.

  5. #5
    Join Date
    Sep 2012
    Posts
    280

    Default

    The click packages are very similar to Androids apks.
    I.E.
    BYOD - Bring Your Own Dependencies
    Sandboxed - Declare what you want to use and let the user allow or deny.
    Not possible to access anything outside your sandbox if not
    explicitly specified in the manifest.
    No install scripts - Your app can't do anything until the user chooses to start it.

    It's simply a easier package that is safer (sandboxing, install scripts) and suits
    better in the phone where users tend to install everything they can.
    For desktop sand boxing is of course nice, however BYOD may be a pain in the ass.

    Personally I think they should delay the 1.0 (13.10) release to 14.04. It isn't
    done and Mir won't be tested enough. If they want they could release but
    tag it beta, preview or something like that...

  6. #6
    Join Date
    Sep 2013
    Location
    Germany
    Posts
    39

    Default

    Click packages too my mind is a really stuped idea.
    You can read all about it here: http://www.jonobacon.org/2013/08/21/...pload-process/

    Click packages are designed to only depend on Qt-libs (are Ubuntu-SDK-libs).
    If you app depends on external (non-Ubuntu SDK) libs, the developer has to bundle the library into the click package instead of using and installing the libaries from the official repository. Here lies the problem, instead on relying in the repo, they get:

    1. wasted storage, because the same library is contained and used in different apps
    2. static linking, insted of using the libraries from apt, a library version of click package is used

    It's in general the same problem as under MacOS which is also a security flaw. Who guarantees, that the package libraries are not manipulated or outdated ? Exactly, nobody. And Ubuntu's devs are saying that it's all no problem, they have sandboxing (just read through the comments). This is ridicoulus and simply stupid.

  7. #7
    Join Date
    Dec 2009
    Posts
    344

    Default

    Still it's not clear why couldn't Canonical use Wayland in the Ubuntu Phone.

  8. #8
    Join Date
    Sep 2012
    Posts
    280

    Default

    Quote Originally Posted by shmerl View Post
    Still it's not clear why couldn't Canonical use Wayland in the Ubuntu Phone.
    Why Mir?

    We wanted to integrate the shell with a display server
    There are all sorts of frustrations involved in writing a desktop shell in X. See any number of Wayland videos for details .

    We therefore want Wayland, or something like it.


    We don't want to use Weston (and neither does anyone else)
    Weston, the reference Wayland compositor, is a test-bed. It's for the development of the Wayland protocol, not for being an actual desktop shell. We could have forked Weston and bent it to our will, but we're on a bit of an automated-testing run at the moment, and it's generally hard to retro-fit tests onto an existing codebase. Weston has some tests, but we want super-awesome-tested code.

    It's perhaps worth noting that neither GNOME nor KDE have based their Wayland compositor work on Weston.

    We don't want Weston, but maybe we want Wayland?


    What about input?
    At the time Mir was started, Wayland's input handling was basically non-existent. +Daniel Stone's done a lot of work on it since then, but at the time it would have looked like we needed to write an input stack.

    Maybe we want Wayland, but we'll need to write the input stack.


    We want server-side buffer allocation; will that work?

    We need server-side buffer allocation for ARM hardware; for various reasons we want server-side buffer allocation everywhere. Weston uses client-side allocation, and the Wayland EGL platform in Mesa does likewise. Although it's possible to do server-side allocation in a Wayland protocol, it's swimming against the tide.

    Maybe we want Wayland, but we'll need to write an input stack and patch XWayland and the Mesa EGL platform.


    Can we tailor this to Unity's needs?

    We want the minimum possible complexity; we ideally want something tailored exactly to our requirements, with no surplus code. We want different WM semantics to the existing wl_shell and wl_shell_surface, so we ideally want to throw them away and replace them with something new.

    Maybe we want Wayland, but we'll need to write an input stack, patch XWayland and the Mesa EGL platform, and redo the WM handling in all the toolkits.


    So, does it make sense to write a Wayland compositor?

    At this point, it looks like we want something like Wayland, but different in almost all the details. It's not clear that starting with Wayland will save us all that much effort, so the upsides of doing our own thing - we can do exactly and only what we want, we can build an easily-testable code base, we can use our own infrastructure, we don't have an additional layer of upstream review - look like they'll outweigh the costs of having to duplicate effort.
    Therefore, Mir.
    http://blog.cooperteam.net/2013/03/for-posterity.html

  9. #9
    Join Date
    Dec 2009
    Posts
    344

    Default

    Those were already refuted. Canonical had no clue about what Wayland could or couldn't do. And especially now, those reasons don't make any sense at all. I expect Canonical to come to their senses in some future and to focus on Wayland again.

  10. #10
    Join Date
    Sep 2012
    Posts
    280

    Default

    Quote Originally Posted by theghost View Post
    Click packages too my mind is a really stuped idea.
    You can read all about it here: http://www.jonobacon.org/2013/08/21/...pload-process/

    Click packages are designed to only depend on Qt-libs (are Ubuntu-SDK-libs).
    If you app depends on external (non-Ubuntu SDK) libs, the developer has to bundle the library into the click package instead of using and installing the libaries from the official repository. Here lies the problem, instead on relying in the repo, they get:

    1. wasted storage, because the same library is contained and used in different apps
    2. static linking, insted of using the libraries from apt, a library version of click package is used

    It's in general the same problem as under MacOS which is also a security flaw. Who guarantees, that the package libraries are not manipulated or outdated ? Exactly, nobody. And Ubuntu's devs are saying that it's all no problem, they have sandboxing (just read through the comments). This is ridicoulus and simply stupid.
    First: If you don't trust the app developer to not manipulate the libraries, how can you trust the app itself?
    Second (Why no dependencies): Click packages is designed for the phones, phones are slow. Dependency
    resolving requires every install to scan all installed packages to see if the dependency is installed. On
    mobile platforms this is real slow (look at raspberry pi). As mobile apps usually don't require dependencies
    (look at Android, no problem there) this is unnecessary.

    Click packages won't replace deb on the desktop where you use more advanced apps that usually pull
    in a couple of dependencies.

    Quote Originally Posted by shmerl View Post
    Those were already refuted. Canonical had no clue about what Wayland could or couldn't do. And especially now, those reasons don't make any sense at all. I expect Canonical to come to their senses in some future and to focus on Wayland again.
    Well, what Wayland does now have very little to do with what Wayland did when the decision was taken.

Posting Permissions

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