Announcement

Collapse
No announcement yet.

Snaps & Ubuntu Core Desktop Talked Up At FOSDEM 2024

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

  • szymon_g
    replied
    Originally posted by user1 View Post
    additional wall of security which you don't have if you get the software directly from the developer. What if the developer makes his software do something malicious and no one catches it before it gets to the user?
    if the dev will put something malicious inside the app the maintainer/packager will be very unlikely to spot it- unless there will be some warning for buffer overflow etc - but any half decent dev would make sure it would not show up so easily.

    it's way more likely that it's the maintainer will put something inside- either by an accident or on purpose. And snaps/flatpaks do offer some sort of sandboxing (even if many of them runs with the very broad access by default). applications installed via debs do not run in sandbox unless otherwisely specified. and they can do whatever they want in pre and post installation scripts.

    Leave a comment:


  • archerallstars
    replied
    Originally posted by user1 View Post
    What if the developer makes his software do something malicious and no one catches it before it gets to the user?
    You better quit using the software from that developer, period.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by TheJackiNonster View Post

    I made a different experience. On Flathub I never received any hint to lower permission requirements. Neither I did notice anyone checking my app for changes after initial verification. With snaps on the other hand my apps are continuously verified manually which I get notified about after a new build and they automatically notify me about outdated dependencies in my apps. Flathub doesn't seem to care at all about deprecated dependencies which is why a lot of apps probably contain known security issues inside.
    The instructions for enabling their dependency-checking bot are at https://github.com/flathub-infra/fla...l-data-checker

    Once the relevant lines are added to your flatpak-builder manifest, it will automatically check for updates and open PRs with updated dependencies and, if paired with GitHub Actions or some other CI bot, and a good test suite, can turn updating dependencies into a simple matter of "Receive e-mail from GitHub, look at test results, Click merge button, wait three-hour 'oops' grace period for changes to go live".​

    As someone who wrote the manifest the PySolFC maintainer now uses, and who maintains the I Have No Tomatoes Flatpak, I can confirm that it'll support basically anything, including parsing arbitrary HTML to find updated dependency URLs.
    Last edited by ssokolow; 08 February 2024, 01:52 PM.

    Leave a comment:


  • Artim
    replied
    Originally posted by ssokolow View Post

    That's exactly how things work in a free market. They made a competing product and people are choosing to use it... they just wish they didn't have to be the providers of a competing product and see it as a position they've been pushed into by the incumbents' refusal to cater to un-served demand.
    Solely your opinion that they don't want to be. My understanding is they are the only ones interested in having an actual product for the masses, not just a very quick-and-dirty solution for a problem that doesn't exist - besides sheer laziness.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Artim View Post

    ...that's not how anything works.
    That's exactly how things work in a free market. They made a competing product and people are choosing to use it... they just wish they didn't have to be the providers of a competing product and see it as a position they've been pushed into by the incumbents' refusal to cater to un-served demand.

    Leave a comment:


  • Artim
    replied
    Originally posted by ssokolow View Post

    Flatpak is a shot across the bow. It's "Don't like it? Stop squabbling and compete with us. We're tired of waiting." in the form of runnable code. (Same as systemd. "Don't like it? Then prove you can meet our needs 'the proper way'.")
    ...that's not how anything works.

    Leave a comment:


  • Artim
    replied
    Originally posted by Daktyl198 View Post

    You’re exactly the type of fanboy I’m talking about. Nobody can say anything bad about flatpak or else they’re paid by Canonical. For the record, I hate snaps more than I hate flatpaks, and haven’t touched an Ubuntu based distro in over a decade. I only call out the hypocrisy of fanboying over flatpaks but shitting on snaps every chance you get.

    As for breaking out of the sandbox, just go to flat hub and look at the default permissions for the most popular software. If any of that software gets file system access to the /home directory, it’s breaking out of the sandbox. And that’s just the most common way. Most applications require far too lax permissions to work properly so the sandbox is basically nonfunctional unless you go in after the fact and lock it down (at the cost of application features and stability).
    The point is that you are writing utter bs. You aren't saying "anything bad about Flatpak", you are incapable of sticking to the truth, which immediately invalidates your arguments. If you need to lie, you must be desperate because you have no real arguments.

    Leave a comment:


  • intelfx
    replied
    Originally posted by mirmirmir View Post

    there's a reason why a patch doesn't get merged
    More often than not, it's because the upstream doesn't care about the problems that do not happen on the upstream developer's machine.

    Originally posted by mirmirmir View Post

    Remember, a packager will never be smarter than the developer
    That's where you are dead wrong.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by muncrief View Post
    I've never liked either Flatpaks or Snaps, as they encourage incompatibility by essentially packaging a partial mini-distro along with an application. This just seems ludicrous, wasteful, and counterproductive to me.

    However during experimentation with them I was never able to get a Snap to work at all, while Flatpaks were mostly, if not completely, functional. But as I said, neither really seems suitable for permanent installation, and I wish the goal were still set on Linux distribution compatibility, like the now failed LSB idea. But just because LSB failed doesn't mean everyone should just throw up their hands and go with distro within a distro ideas like Flatpak and Snap.
    Flatpak is a shot across the bow. It's "Don't like it? Stop squabbling and compete with us. We're tired of waiting." in the form of runnable code. (Same as systemd. "Don't like it? Then prove you can meet our needs 'the proper way'.")

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Daktyl198 View Post

    And yet, benchmark’s consistently show that in many cases, Flatpaks run slower than standard packages. In many cases, they do run at similar speeds, but not every time which means that there’s still improvements to be made a decade later.

    Every year for the last 6 years has been “the year we all switch to flatpak”, but not even Fedora (owned and operated by the makers of flatpak) default to it as far as I know. Only security nuts (who actually modify and take advantage of the flatpak sandbox) and fanboys go out of their way to use Flatpaks for more than a couple apps that aren’t available in the standard repos.
    Depending on what you mean by "run slower", that may be the seccomp system call filter. Try running a program from a standard package inside Firejail to do fine-grained experiments into what effect various sandboxing constructs have on performance.

    Leave a comment:

Working...
X