If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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...

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.

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.

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...

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.

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.

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.

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.

Originally Posted by shmerl

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.