Announcement

Collapse
No announcement yet.

Canonical To Focus On A New, More Modular Snapcraft - Current Codebase Goes Legacy

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

  • #71
    Originally posted by STiAT View Post
    My personal preference aside, which are AppImages (which I use to make packages for desktop appslications), which I think are completely underrated in the discussion, I see flatpaks and Snap trying to solve the same problem, fragmenting application deployment even further.

    I personally think snap lost a lot of ground to flatpak in the past years.

    AppImages probably have the advantage of not being sandboxed, which eases deployments and integration.
    Phoronix: Canonical To Focus On A New, More Modular Snapcraft - Current Codebase Goes Legacy A few minutes ago a new Ubuntu blog post hit the wire entitled "The Future of Snapcraft" where immediately I wondered if it was announcing plans to move away from their own app packaging/store/update tech and shift over to a


    Phoronix: Canonical To Focus On A New, More Modular Snapcraft - Current Codebase Goes Legacy A few minutes ago a new Ubuntu blog post hit the wire entitled "The Future of Snapcraft" where immediately I wondered if it was announcing plans to move away from their own app packaging/store/update tech and shift over to a


    Do read these posts of mine. Appimages have on going issues causes by OS host runtimes differences. Yes you are right flatpak and snap are both attempts at solving the runtime incompatibility issue. Steam with the steam runtime is another attempt to fix this problem.

    Jack Wallen doesn't think AppImages are the application nirvana many developers believe them to be. Find out why and see if you agree.


    Yes some people go as far as saying you should not use appimage because the issues they have is not worth the time.

    Lot of ways people do need to take a serous look at Appimage design and the libcapsule work. I do think both libcapsule and appimage could be integrated with each other and make a solution that support different to host runtimes.

    Like currently you cannot make a appimage and say using the steam runtime instead of the host runtime. There is no flatpak/snap application to run appimage applications please don't think this is impossible valve has done work with flatpak to make this kind of stuff possible for the applications steam provides.

    From my point of view AppImageLauncher need to be extended to be able to take advantage of runtimes provided by flatpak at least. So in the case X appimage does not work with Y distribution provided runtime yet the user has flatpak they are still able to use the appimage by having it run in flatpak and use the flatpak provide runtime.

    Appimage able to run on host without a sandbox has advantages at times due to reduced sandboxing but this has issues with host runtime yet flatpak you must always be sandboxed and you have predictable runtime so no host runtime problem. There is a best of both worlds solution that could be built where a user is able to choose if application runs on host or inside flatpak using a launcher. Yes if the host runtime is giving application trouble set like a windows compatibility mode on it to force it to run in flatpak .

    Yes the best of both worlds option would be look at what valve has paid to done with libcapsule and flatpak and have appimage solutions be able to take advantage of it.

    I see a lot of problem here comes from flatpak, snap and appimage being uses as a pick 1 option. Reality we need a pick 2 at least. Yes the pick two would not have to result in those maintaining appimage applications making more appimage applications. Instead it would just some support software so that end users have choice of runtime between host , flatpak and possible others so finally getting on top of the incompatible runtime problem that has plagued appimage since forever.

    Easing desktop integration does not help if the application does not run due to host runtime issue. Yes the host runtime conflict problems is the big problems holding appimage back and will keep on holding appimage uptake back until its addressed. The technologies exist to address the problems yes valve for steam funded development of them because steam store runs into all the same problems.

    Comment


    • #72
      Originally posted by simonsaysthis View Post

      Disagree that Canonical is shady. They have been very transparent about the Chromium case. And why should they even provide the option of removing a technology from their base? Should Windows have the option of removing .Net ? Canonicals vision for the future of Ubuntu is Snap, whilst they acknowledge that it is not perfect today. What big controversy am I missing here?
      I consider it shady to publish a package in one packaging system that just redirects to another packaging system. End of story.

      While there are acceptable special cases, like the MS Core Fonts DEB which is required to do it for licensing reasons, it'd be unarguably shady if Canonical decided to offer a rust package that literally just executed curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

      Comment


      • #73
        It's been said before, but considering the astounding investment that Valve and other groups are pouring into Wine, and the backwards-compatibility built into Wine, we may reach the point where the easiest way to package applications in a way supported across Linux distributions is to write them for Windows.

        I'm not saying Microsoft is good, Windows is good, or the Windows API is good. I'm just saying that the backwards compatibility is outstanding, which makes it a plausible deployment target.

        Originally posted by ssokolow View Post
        I consider it shady to publish a package in one packaging system that just redirects to another packaging system. End of story.
        What other option do they have, if nobody has the time or interest in packaging Chromium updates in .deb/dpkg?

        Ubuntu desktop is aimed first at novice users, and they're not going to know or care about the packaging system distinctions. They just want Chromium, or whatever.

        And I think it's especially a legitimate approach since Ubuntu has snap support installed by default. It would be different if snap was not installed out of the box, and "apt install chromium" added it. But removing snap on Ubuntu has to be pretty rare - most people annoyed at snaps are probably jumping distros.

        Comment


        • #74
          Originally posted by Michael_S View Post
          It's been said before, but considering the astounding investment that Valve and other groups are pouring into Wine, and the backwards-compatibility built into Wine, we may reach the point where the easiest way to package applications in a way supported across Linux distributions is to write them for Windows.

          I'm not saying Microsoft is good, Windows is good, or the Windows API is good. I'm just saying that the backwards compatibility is outstanding, which makes it a plausible deployment target.
          Windows backwards compatibility is not as great as it first appears.


          Wine test suite shows different versions of windows and even windows with different software installed having a different ABI compatibility. Valve interest in wine is not just to run Windows applications on Linux. Some of it is to be able to run windows applications on Linux that no longer works on Windows so they can keep on selling those programs. Do remember steam for the applications it installs have different configuration tweaks and so on so applications work even on Windows.

          So packaging a working windows application is not exactly straight forwards either.

          Originally posted by Michael_S View Post
          What other option do they have, if nobody has the time or interest in packaging Chromium updates in .deb/dpkg?

          Ubuntu desktop is aimed first at novice users, and they're not going to know or care about the packaging system distinctions. They just want Chromium, or whatever.

          And I think it's especially a legitimate approach since Ubuntu has snap support installed by default. It would be different if snap was not installed out of the box, and "apt install chromium" added it. But removing snap on Ubuntu has to be pretty rare - most people annoyed at snaps are probably jumping distros.
          Something you miss here is quite common for users to end up uninstalling snap at least its current form. Problem is the more snaps you install due to the way the loopback is used the worst system start up and shutdown comes sooner or latter this starts annoying users. Yes they either move distribution or remove snap.

          Now there is the option of flatpak that Canonical does not use to install stuff like Chromium that does not result in the progressively degrading system performance.

          If the new modular snap finally fixes the performance issue the hate of snap by users will go away.


          Instructions like this for ubuntu are very common.

          Michael_S users uninstalling snap is very common you can get ubuntu popcon numbers(the popularitty contest program of debian that ubuntu also had) and find that snapd has basically been uninstalled by lot of users. So in the collectable stats about Ubuntu installed packages there is a major problem around snap because users are refusing to use it.


          #rank name inst vote old recent no-files (maintainer)
          29 dpkg 2800227 5467 2794306 84 370 (Dpkg Developers)
          2540 chromium-browser 455348 289 454756 10 293 (Unknown)
          10102 snapd 23991 701 23263 9 18 (Unknown)
          44493 flatpak 603 14 587 1 1 (Unknown)

          Yes snapd is installed out the box but it not remaining installed. As the user gains experience they get rid of it. Yes half of dpkg number.

          The other interesting point when you look at popcon data you find chromium being installed from a deb/dpkg by a PPA instead of the offical repo that forces snap version more often. The reality here the Ubuntu users are voting with their feet and its not snap packages or flatpak. Instead its third party PPA of deb/dpkg instead of the ubuntu official repository yes this is why you have chromium-browser as ranking 2540 and snapd is at 10102. Having a higher ranking than snapd is not possible if the snap version is being used.

          The popcon program was designed by debian to attempt to work out what packages users in fact wanted to guide resource allocation. Yes at times it can tell you what they don't want. Most Ubuntu users don't want flatpak or snapd that the reality of location at the moment.

          Yes third parties are packaging chromium and other items as PPA in deb/dpkg for ubuntu.

          Michael_S basically there are real collected metrics here and they don't say that Ubuntu users on average are happy with current snapd in fact says on average they will uninstall snapd and the longer that use Ubuntu the more likely that will uninstall snapd. A new redesign of snapd is need by what the popcon numbers are saying.

          Something to also remember Michael_S a novice user don't remain a novice user forever at some point they have learnt enough to add third party PPA and remove snapd and by the numbers fairly soon after they have learn how to add third party PPA they are removing snapd.

          This is the hard reality we have public numbers that are not 100 percent exact with popcon because not every user takes part but its enough detail to give a reasonable overview of what Ubuntu users are doing. Snapd popcon install numbers don't match for a popular default installed application, Snapd install number match for a default installed application that users get rid off as soon as they have the skills to because they hate it for some reason.

          Yes googling around you will find the same hate story over and over again snapd bad effects on startup and shutdown cause users to hate it.

          Comment


          • #75
            Originally posted by Michael_S View Post
            What other option do they have, if nobody has the time or interest in packaging Chromium updates in .deb/dpkg?

            Ubuntu desktop is aimed first at novice users, and they're not going to know or care about the packaging system distinctions. They just want Chromium, or whatever.

            And I think it's especially a legitimate approach since Ubuntu has snap support installed by default. It would be different if snap was not installed out of the box, and "apt install chromium" added it. But removing snap on Ubuntu has to be pretty rare - most people annoyed at snaps are probably jumping distros.
            They're free to have things like Chromium and Firefox only available through snaps, and they're free to have snappy installed by default... just don't lie about what's available through debs.

            They've got snappy backends for things like GNOME Software and that's the proper level to merge things together.

            Comment


            • #76
              Originally posted by oiaohm View Post

              Windows backwards compatibility is not as great as it first appears.
              Granted. It's not perfect. But it is started to look like a more stable ABI candidate than Qt/KDE Frameworks, GTK, etc...

              Originally posted by oiaohm View Post
              Something you miss here is quite common for users to end up uninstalling snap at least its current form. Problem is the more snaps you install due to the way the loopback is used the worst system start up and shutdown comes sooner or latter this starts annoying users. Yes they either move distribution or remove snap.
              I am familiar with the problems with snaps. But I don't think the data you presented from popcon makes any sense.

              #Format #
              #<name> is the package name;
              #<inst> is the number of people who installed this package;
              #<vote> is the number of people who use this package regularly;
              #<old> is the number of people who installed, but don't use this package
              # regularly;
              #<recent> is the number of people who upgraded this package recently;
              #<no-files> is the number of people whose entry didn't contain enough
              # information (atime and ctime were 0).

              29 dpkg 2800227 5467 2794306 84 370
              So dpkg was installed 2800227 times, 5467 use it regularly, 2794306 do not use it regularly, 84 upgraded it recently, 370 don't have enough information.
              10102 snapd 23991 701 23263 9 18 (Unknown)
              So snapd was installed by 23991, 701 use it regularly, 23263 are the people who installed it but don't use it, 9 is the number that upgraded it, 18 is the number that didn't have enough information.

              But by that metric, dpkg was installed 116 times more than snapd. So either 99% of Ubuntu users - seriously, 99% - that run popularity contest uninstalled snapd or there is something wacky going on.


              Comment


              • #77
                I'm not a fan of bundled packages, and will avoid them as long as I can.
                But Canonical has always demonstrated a real user-oriented vision, and I trust them far more than whatever NIH fake-community solution Red Hat will try to enforce upon its naive cultists, so I'd pick snaps over flatpaks any day of the week if it resorts to that at some point. It's clearly the lesser of two evils.

                Comment


                • #78
                  Originally posted by jntesteves View Post
                  For some time, I've considered Canonical to be effectively harmful to Linux. Snapcraft is the ultimate example, proprietary BS that takes control over the OS from users and puts it into corporate hands. The kind of Microsoft crap I would steer miles away from.

                  At this point, I never recommend Ubuntu to newcomers anymore. I instead usually recommend the distros that come with Flathub by default, or Fedora + setting up Flathub.
                  It's funny as this is my exact opposite experience.
                  Red Hat is constantly reinventing the wheel, creating cheap Gnome apps that have dozen of better and established alternatives out there, wasting time and effort. Total NIH syndrome. And they deceive naive people into believing it is community-driven (while it's 70% RH sponsored and lobbied with their finances in mind) and how others should help contribute instead of doing their own thing, while their narrow-minded developer-oriented vision often impedes others to actually contribute with their own more user-oriented vision, hence being the exact reason why others eventually are forced to fork or start over to pursue their own vision.
                  They're driving others away then blaming them for leaving, and the fanboys then go on to vilipend these others for leaving, like the good sheeps they are.
                  Last edited by Mez'; 09 January 2022, 10:05 AM.

                  Comment


                  • #79
                    Originally posted by Michael_S View Post
                    Granted. It's not perfect. But it is started to look like a more stable ABI candidate than Qt/KDE Frameworks, GTK, etc...
                    This is not true. Microsoft heavily depends on SXS to link application up with right versions of libraries.

                    Originally posted by Michael_S View Post
                    I am familiar with the problems with snaps. But I don't think the data you presented from popcon makes any sense.

                    #Format #
                    #<name> is the package name;
                    #<inst> is the number of people who installed this package;
                    #<vote> is the number of people who use this package regularly;
                    #<old> is the number of people who installed, but don't use this package
                    # regularly;
                    #<recent> is the number of people who upgraded this package recently;
                    #<no-files> is the number of people whose entry didn't contain enough
                    # information (atime and ctime were 0).

                    29 dpkg 2800227 5467 2794306 84 370
                    So dpkg was installed 2800227 times, 5467 use it regularly, 2794306 do not use it regularly, 84 upgraded it recently, 370 don't have enough information.
                    10102 snapd 23991 701 23263 9 18 (Unknown)
                    So snapd was installed by 23991, 701 use it regularly, 23263 are the people who installed it but don't use it, 9 is the number that upgraded it, 18 is the number that didn't have enough information.

                    But by that metric, dpkg was installed 116 times more than snapd. So either 99% of Ubuntu users - seriously, 99% - that run popularity contest uninstalled snapd or there is something wacky going on.
                    263 xorg 2730843 0 22 0 2730821 (Debian X Strike Force)

                    I should have include xorg instead of dpkg but its still over a 99% uninstall rate of snapd by those running popularity constest. Yes that by people who had snapd installed by default.

                    Yes the vote number and the old number and the recent number need to be taken with a serous grain of salt . Install number in popcon reasonably trust-able.

                    For how far snapd is hated I don't think doing a major change snapd has any possibility of making snapd market share worse even if they screw up the process quite badly. Snapd is not like kde 3 that was liked. The like rate(as in install it and use it) of early KDE 4 is higher than snapd and early KDE 4 is classed as a failure.

                    Really the numbers don't justify legacy snapd being installed by default.

                    Comment


                    • #80
                      Originally posted by oiaohm View Post
                      This is not true. Microsoft heavily depends on SXS to link application up with right versions of libraries.
                      Wrong. Most of the ABI/API is stable, it's just small differences in behavior. Wine has only a couple dozen DLLs in winsxs and works just fine for 95% of apps, so stop this bullshit.

                      Maybe there's 5% rare cases but you know what? When Linux libs do not break 95% of the apps using them, you can start talking about Windows. Got it?

                      Comment

                      Working...
                      X