Announcement

Collapse
No announcement yet.

Ubuntu Phone 13.10: The Runway Is Clear For Mir

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

  • #16
    Originally posted by Pajn View Post
    Well, what Wayland does now have very little to do with what Wayland did when the decision was taken.
    True, but those claims were bullshit at the time decision was taken. That's a big part of why so many people have a grudge against Mir - that when they launched their project, they justified it with a bunch of lies and misinformation about Wayland. And they *were* lies, because if they'd looked at Wayland as closely as they claimed, they'd have known those statements were incorrect.

    Comment


    • #17
      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.
      1. Space isn't extremely limited like it used to be. Most OSX .dmg .app files measure into the hundreds of megabytes each, yet hardly any users complain about them. Similarly, .apk files function the same way on Android and there seems to be little criticism there besides from proprietary software developers and that's mostly around piracy.

      2. This isn't a problem, but a benefit. Say for instance you have library Z v1.5 but v1.6 comes out which your script is incompatible with, apt-get does an upgrade and suddenly you don't have a functioning script.
      Having libraries bundled with the application stops this sort of breakage occurring.

      Comment


      • #18
        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.
        Correct. Ubuntu is becoming a dumber and dumber distro every day. They have totally lost their minds over there.

        And now in 13.10 you have to go through all kinds of gymnastics just to get the adware deactivated.

        Comment


        • #19
          I think it is very alarming, they are pushing in fixes mere days before the release. The idea that a release date cannot be pushed back will result in buggy release...

          Comment


          • #20
            Originally posted by johnc View Post

            And now in 13.10 you have to go through all kinds of gymnastics just to get the adware deactivated.
            what?? dash/applications/filter results/search plugins/click on amazon and disable

            Pretty straight forward id of thought What issue do you have with the other scopes in the 100 Scopes project apart from amazon ?

            Comment


            • #21
              Originally posted by borsook View Post
              I think it is very alarming, they are pushing in fixes mere days before the release. The idea that a release date cannot be pushed back will result in buggy release...
              Final freeze and release candidate due on 10th Yet you are surprised and alarmed they are pushing fixes to something still in final beta??

              Comment


              • #22
                Originally posted by DDF420 View Post
                what?? dash/applications/filter results/search plugins/click on amazon and disable

                Pretty straight forward id of thought What issue do you have with the other scopes in the 100 Scopes project apart from amazon ?

                Hmmm on second thought what the hell more adware crap to remove i can handle ebay and ubuntu one music but what the hell is skimlinks

                Comment


                • #23
                  Originally posted by liam View Post
                  I'm not sure how true that is. Much of the input handling was added fairly recently, but they could've asked the devs about its status.
                  Apparently mesa handles things on the client-side so there would be no swimming against the tide EXCEPT for when mesa is used and they still have to deal with that.
                  The bottom line is this was not a decision that was up to the devs. Watching that recent state or mir talk with CHR made that even more clear to me based on both his responses and his embarrassed expressions. I genuinely feel sorry that the devs were put in this situation if my interpretation is correct.
                  Do you have a link to that state of Mir talk? Google is a bit useless.

                  Comment


                  • #24
                    Originally posted by bkor View Post
                    Do you have a link to that state of Mir talk? Google is a bit useless.
                    http://www.youtube.com/watch?v=khXlETtVaKY

                    Comment


                    • #25
                      Originally posted by liam View Post
                      I'm not sure how true that is. Much of the input handling was added fairly recently, but they could've asked the devs about its status.
                      It was landed 17 months ago.

                      Comment


                      • #26
                        Originally posted by johnc View Post
                        Correct. Ubuntu is becoming a dumber and dumber distro every day. They have totally lost their minds over there.

                        And now in 13.10 you have to go through all kinds of gymnastics just to get the adware deactivated.
                        Are you agreeing with his flawed and incorrect analysis of Ubuntu's new package management system which I rebutted?

                        Comment


                        • #27
                          Originally posted by Pajn View Post
                          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.


                          Well, what Wayland does now have very little to do with what Wayland did when the decision was taken.
                          Dependency resolving for Linux packages isn't slow. It worked fine when it was created ~20 years ago, and hardware has only gotten faster since then. Finding out whether or not a package is installed is a matter of a single lookup in an indexed table. I have used apt-get on a Raspberry Pi and in reality it is no slower than Android (which has to download larger packages because all of the dependencies are bundled).

                          Comment


                          • #28
                            Originally posted by chrisb View Post
                            Dependency resolving for Linux packages isn't slow. It worked fine when it was created ~20 years ago, and hardware has only gotten faster since then. Finding out whether or not a package is installed is a matter of a single lookup in an indexed table. I have used apt-get on a Raspberry Pi and in reality it is no slower than Android (which has to download larger packages because all of the dependencies are bundled).
                            I will vouch entirely against that. Apt-get runs much slower on the Raspberry Pi than on Android mobile handsets such as the GSIII, I should know since I own both.
                            The only time the former can outperform the latter is if the package database was recently updated and the GSIII is installing a larger program than the RasPi.
                            In most cases, a full apt-get update on Raspbian without any updates before hand will take upwards of 3-5 minutes.

                            I haven't been able to test apk install times on the Pi as the Android builds for it are currently unstable.

                            Comment


                            • #29
                              Originally posted by intellivision View Post
                              I will vouch entirely against that. Apt-get runs much slower on the Raspberry Pi than on Android mobile handsets such as the GSIII, I should know since I own both.
                              The only time the former can outperform the latter is if the package database was recently updated and the GSIII is installing a larger program than the RasPi.
                              In most cases, a full apt-get update on Raspbian without any updates before hand will take upwards of 3-5 minutes.

                              I haven't been able to test apk install times on the Pi as the Android builds for it are currently unstable.
                              Not a fair test. Pi has a single core 700Mhz cpu, GSIII has a quad core 1.4Ghz cpu and faster memory etc. Pi MMC interface is much slower too for general file system operations. Also 'apt-get update' time isn't really relevant since you don't need to run it in realtime, once a day from cron or similar is enough.

                              Comment


                              • #30
                                Originally posted by chrisb View Post
                                Not a fair test. Pi has a single core 700Mhz cpu, GSIII has a quad core 1.4Ghz cpu and faster memory etc. Pi MMC interface is much slower too for general file system operations. Also 'apt-get update' time isn't really relevant since you don't need to run it in realtime, once a day from cron or similar is enough.
                                The test wasn't supposed to be fair, more so highlighting the problems of package resolution for shared libraries rather than library bundling for each application on low performance devices.
                                The issues of breakage that I alluded to in an earlier post also happens less with bundled applications rather than with shared libraries.

                                Comment

                                Working...
                                X