Announcement

Collapse
No announcement yet.

Snaps & Ubuntu Core Desktop Talked Up At FOSDEM 2024

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

  • Daktyl198
    replied
    Originally posted by Artim View Post

    You are hillarious. Find a single piece of software without any bugs, I dare you. And also, if you can prove that "95% of applications distributed as Flatpaks break out of the sandbox by default because of point 1: bugs", then go ahead. Right now you are only spreading lies and misinformation. Canonical must have paid you a lot for that.
    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).

    Leave a comment:


  • TiCPU
    replied
    I still prefer something that's well integrated and tested to work as a whole than another layer of abstraction to satisfy having hundreds of different package managers. Sure, updating a system library like libc for a security update that could cause every package to break is not always fun but sure better than having to wait an arbitrary number of days for each upstreams to do so.
    I understand the secure aspect of it and am saddened that not any many packages are secured by apparmor and system's security by default on Ubuntu and even worse on Debian. But then, maybe it's better this way and makes for even tighter case by case security profiles.

    Leave a comment:


  • Artim
    replied
    Originally posted by woddy View Post
    I read the comments a bit... are they different ways of packaging the packages or do you trust the dev. of the application and you should otherwise you have no reason to use it or you trust your distribution, you have to trust someone... but if you buy bread you should trust whoever sells it to you and does it. The problem with distributions is that they often lag behind in versions with unresolved security bugs, furthermore if you install many system applications you risk weighing down the system and creating regressions in the convoluted management of dependencies, the applications tested by the distributions are only the default ones , don't think that Ubuntu, Debian etc. I test the 1000+ applications available and if they create regressions, they don't, it would be impossible. Personally I prefer flatpak and you can manage sandbox permissions as you like, with KDE you can do it from the system settings.​
    Wow. Welcome to the 90s. That is some decades old outdated bs you're spewing here with comparisons that are no longer limping, but crawling...Yes, for the sake of stability, some distributions like Debian lag behind in feature updates. But that's the point. You can have up-to-date software or thoroughly tested software. Never both. But that never means lagging behind security update wise, as those are patched independent of feature updates. So the only thing reporting such nonsense would be software (or stupid humans) only checking the version number of a program. Spoiler alert, just because you have a version in theory susceptible to security issues doesn't mean nobody has patched either way. That's the beautiful thing only possible with the classical distribution system. With either Flatpak, Snap or AppImage you're damned to hope the dev fixes it at some point, especially if the issue is inside a dependency. And no, these dependencies do never create any alleged regressions in a working distribution. That might happen in something highly unstable as Arch, but that's it. And there's absolutely nothing convoluted about it, just ignorant people that only learned the outdated Windows ways of things and that refuse to understand concepts that just work.

    And yes, especially Debian tests all over 70.000 packages for every platform they offer. That's the whole point of it. And it's very easy, it's called automation. Also, with Debian you have 2 years of development for each version, including litterally 6 months of continuously harder freezes where less feature updates are allowed in so all testing users and all developers can concentrate on finding as many bugs as possible beforehand and hopefully fix them before release. Or at least have them well documented so users can decide on their own when they'll upgrade. On the other hand, with Flatpaks and Snapd you aren't getting even close to this degree of testing. So these packages need to be isolated from the rest of the system to keep damage to a lower level than Arch does. But if you need stability - and that's pretty much the one and only reason you run Debian, only the packages from the official repos are the way to go as nothing else has been scrutinized that much.

    You can like Flatpak all you want, but that's no excuse for spreading blatant lies. Of course if you have any proof for the nonsense that hasn't been true in recent decades, go ahead, present it. But until then your comment is just a very sad try of make distros look bad because that's the only way you can make Flatpak look good. Very pathetic.

    Leave a comment:


  • woddy
    replied
    I read the comments a bit... are they different ways of packaging the packages or do you trust the dev. of the application and you should otherwise you have no reason to use it or you trust your distribution, you have to trust someone... but if you buy bread you should trust whoever sells it to you and does it. The problem with distributions is that they often lag behind in versions with unresolved security bugs, furthermore if you install many system applications you risk weighing down the system and creating regressions in the convoluted management of dependencies, the applications tested by the distributions are only the default ones , don't think that Ubuntu, Debian etc. I test the 1000+ applications available and if they create regressions, they don't, it would be impossible. Personally I prefer flatpak and you can manage sandbox permissions as you like, with KDE you can do it from the system settings.​

    Leave a comment:


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

    Leave a comment:


  • Artim
    replied
    Originally posted by user1 View Post

    Ok, but in the end will it have on screen notification like "do you want to allow app X to access you /home folder?" This is what I mean by dynamic permissions like on Android.

    Edit: Yeah, ok. I guess you meant exactly that.
    Ideally, it will be much better, not needing any stupid notifications. Just look at file access permissions. Absolutely no need for any of that nonsense Android uses. If an app wants to access a file outside its scope, through a portal it communicates that to the underlying distro, the file picker (soon not necessarily Nautilus, but your default one) lets the user select the file and the system automatically (or with your words, dynamically) grants permissions for that one file by implicit means. And probably the same would happen if you use a file from your file explorer with that app. Your proposal would - that only reflects the worst practice Android follows - is the absolute opposite of how permissions should be used. E.g. some Office App should not have access to all of /home. Why should it? There's no reason to give it access to anything that the user doesn't choose to handle in the app. Of course this gets more difficult with stuff like media players who are supposed to create a collection of all media on your system, or DigiKam, that's supposed to do that for your images. But since the user rarely just dump files anywhere, it's not that hard to grant access to just a handful of directories.

    Leave a comment:


  • Artim
    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.
    you are litterally the only person claiming that everyone will switch to Flatpak. That will probably never happen, that's not what it's made for.

    Leave a comment:


  • Artim
    replied
    Originally posted by Daktyl198 View Post

    Flatpaks are the same age as snaps (a decade old!) and have almost all of the same issues that snaps have. The only area Flatpaks are better are speed (and they’re still slower than standard packages, sometimes by a lot) and slightly better permission control.

    Red Hat has just managed to brainwash people into saying that Ubuntu is a bad company while RH are the magical saviors of Linux, so anything Ubuntu is bad and anything RH does is good.

    Tell me when Flatpaks are stable (don’t introduce bugs) and are also ACTUALLY sandboxed, since 95% of applications distributed as Flatpaks break out of the sandbox by default because of point 1: bugs.
    You are hillarious. Find a single piece of software without any bugs, I dare you. And also, if you can prove that "95% of applications distributed as Flatpaks break out of the sandbox by default because of point 1: bugs", then go ahead. Right now you are only spreading lies and misinformation. Canonical must have paid you a lot for that.

    Leave a comment:


  • Artim
    replied
    Originally posted by user1 View Post

    Yeah, I was just thinking about regular user distros. Idk how things are in RHEL / CentOS / Alma Linux and other such distros. Regarding OpenSUSE, I'm not sure if they give such amount of attention to package stability like Debian (at least in regards to Tumbleweed, since it's a rolling release), but they certainly do a much better job than Arch. Unlike Arch, I've never heard about Tumbleweed needing manual intervention after updates (unless you have proprietary drivers) and if there is a broken package found, it should get fixed pretty quickly. OpenQA of course helps them a lot.
    well, Arch is made to be broken every other day, if they weren't rolling, they would be crashing

    Leave a comment:


  • Daktyl198
    replied
    Originally posted by Britoid View Post

    The only performance overhead of Flatpaks is the time to setup the namespaces (near instant, systemd is already doing it anyway) and that the Flatpak won't be able to use the fs cache of shared libraries that were used to boot your machine, but they can use the shared cache of other flatpaks with the same library version combination.

    There's no extraction, no mounting of anything, no decompression (other than that of your filesystem).
    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.

    Leave a comment:

Working...
X