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

  • oiaohm
    replied
    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?
    The biggest problem is the way the snap works that going to be legacy branch now. System comes slower to boot and shutdown as you install more snap packages. This is a behavour flatpak does not have. Docker there is some over ahead with running images but the non running ones don't have any over head effect. Yes this is install more snap packages don't run the applications and the system start up and shutdown slows down.

    I hope the new version does not have this bug any more. I also hope this time around they support users making their own private repos on USB keys and the like for non internet connected machines. Yes the snap where its design to use only 1 store the canonical one is a major issue for those running isolated systems.

    Leave a comment:


  • STiAT
    replied
    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.

    Leave a comment:


  • simonsaysthis
    replied
    Originally posted by ssokolow View Post

    This is a bit different, because Canonical is engaging in shady decisions.
    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?

    Leave a comment:


  • ssokolow
    replied
    Originally posted by simonsaysthis View Post
    or installing Flatpak on Ubuntu
    This is a bit different, because Canonical is engaging in shady decisions. For example, if you uninstall the snap system, there are various packages on the system (eg. chromium) which appear as APT packages but, when you install them, they pull snappy back in and then trigger a snap-based install of the corresponding package.

    Not cool and I'm just glad that I know how to use APT pinning to disallow reinstallation after removing it so I can get an "Error. you didn't want snappy. Please grab it from Flatpak or find a PPA instead" message.

    Leave a comment:


  • simonsaysthis
    replied
    Damn right, Canonical should make improvements and commitments about their technology which benefits anyone (freely!) who doesn’t sway with the tides of internet cancel culture.

    I’m usually quite fond of this site but this article, or rather commentary to Canonical’s article, symbolises perfectly what is wrong with the Linux community of today.

    In the past, Canonical received much criticism about abandoning their projects. Today, Michael Larabel chaffs at the company for not doing “what everyone else does”.

    Our community is home to many troubled users, angry that Ubuntu, or sandboxing, or systemd, or GNOME, or CentOS, or anything else for that matter hasn’t been cancelled yet.

    And so they dedicate years seeking validation and internet points for their dissatisfaction. When instead, they are well capable of installing traditional packages from the terminal or installing Flatpak on Ubuntu.

    But remember: they are doing all this selflessly in the name of the non-converted Windows user, who won't convert either way.

    I feel deeply sorry for them. This is a big burden to carry.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Sonadow View Post
    Installation of runtimes and packages on demand is complete BS when the computer has no internet access.
    I would not say so. People did this for decades with windows by bundling direct x and other parts with their applications.

    https://docs.flatpak.org/en/latest/usb-drives.html

    Yes different flakpak bundling options do this. Of course it does mean applications are not small.

    Leave a comment:


  • Sonadow
    replied
    Originally posted by ssokolow View Post

    And a huge whack of that 32GiB is WinSxS... Flatpak runtimes you can't uninstall if you don't need them because your "Windows/NSIS" installers assume they'll be present and have insufficient metadata to request they be installed on demand.
    Installation of runtimes and packages on demand is complete BS when the computer has no internet access.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Danny3 View Post
    Flatpaks are better but I don't know where is this security feature called sandbox as I have never seen any pop-up window asking me to grant some permission or not.
    I assume that all of them just come will all permissions allowed which defeats the whole purpose of a sandbox and security and I don't know why some people insist that they are more secure than AppImage when they can just access anything without any restrictions and questions asked.
    MacNuke already mentioned Flatseal for customizing the manifest permissions (the equivalent to the prompts Firefox/Chrome/etc. extensions and Android apps ask for at install time which, yes, the flatpak install CLI will present an "are these permissions OK?" prompt for) but, as for prompting while running, that's what XDG portals are for and they're not just used by Flatpak.

    They're equivalent to Android's Intents system and you've probably used them without even knowing, because they're designed to be as seamless as possible.

    For example, if you ever run a Qt application on GNOME and see GNOME Open/Save dialogs, that's because QFileDialog seamlessly uses the XDG File Chooser Portal when present. If you run a GTK app on KDE from inside a Flatpak (or export GTK_USE_PORTAL=1 to accept that there are still a few warts to be fixed when running GTK apps with portals outside a sandbox) and see KDE Open/Save dialogs, that's because GtkFileChooserNative transparently hands off to the XDG File Chooser Portal.

    Qt or GTK then makes a D-Bus call to a daemon called a "portal host" that's part of your desktop environment, which displays the dialog and, if you click OK, it mounts the path into the sandbox and returns the in-sandbox path instead of the out-of-sandbox path. If an application makes the D-Bus call directly, then it can set a boolean to request the grant be made permanent, so it'll persist across runs. (IIRC, that's how some game engine reimplementations are able to prompt you for the location of your data files just once on the first run without hard-coding any sandbox exceptions into the manifest. I think CorsixTH for Theme Hospital is one such example.)

    ...and if you've already got D-Bus in your application for something else, it's often less code than with QFileDialog or GtkFileChooserNative since it's just a single method call, rather than setting up a dialog object, configuring it, and then invoking it.

    I use export GTK_USE_PORTAL=1 because, sandboxing or not, I want my KDE "Places" bookmarks accessible in my GTK applications' Open/Save dialogs and the ability to right-click and rename or delete from right inside the dialog, like every non-GTK desktop allows.

    Likewise, the flatpak run command used by .desktop files has a syntax for specifying "these arguments are paths or possibly-file:// URLs which should be mapped into the sandbox and rewritten before invoking the application. The Flatpak people have punted on avoiding name collisions but here's my proof of concept for making Flatpak-installed application invokable from the command line the same as distro-installed ones.

    (Note that cases like firefox thing.html aren't perfect yet unless you set an install-time exception like filesystem=home or filesystem=host, because they're stil spec-ing out a variant that would grant access to thing.html's parent folder so subresources are accessible too... which is how they intend to make it suitable for things like IDEs. Double-click the project file in the root of the project, choose it from the portal-provided Open dialog, or specify it in a command you type in the terminal, and get the entire project directory tree granted into the sandbox.)
    Last edited by ssokolow; 08 January 2022, 02:29 AM.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Setif View Post
    I don't know something comes preinstalled on Windows beside Windows-API Libraries.
    Does Windows come with Python and Qt preinstalled?

    Wow!!
    That never happened. The minimum storage required for Windows 11 is 32GB.
    And a huge whack of that 32GiB is WinSxS... Flatpak runtimes you can't uninstall if you don't need them because your "Windows/NSIS" installers assume they'll be present and have insufficient metadata to request they be installed on demand.

    Leave a comment:


  • krzyzowiec
    replied
    Thanks Canonical! I’m grateful snaps let me run up to date versions of things like Firefox, VSCode, etc. Anything you do to improve the experience sounds good.

    Leave a comment:

Working...
X