GNOME Software Moving Forward With Disabling Snap Plugin

[tildearrow]

Ok, lemme get in my smart car that has laser, radar, and lidar, but I hope I don't get tased, I got scuba lessons with bae later lol.

I don't see what does this have to do with the discussion.

[tildearrow]

You're digging yourself into a massive hole of complexity and autism. If you take a step back out of your bubble, you'll realize this is untenable. Brain memory is limited. Coordinated consesus is limited. RAM and disk memory are far less limited. Just keep it simple and package runtimes with statically-linked dependencies and move on with your life. You're in a rush, after all -- exactly.

Perfection is the enemy of good.

So, basically you're telling me to accept that we've given up on optimizing? Because that is why we're writing applications in JavaScript and Electron that run on a browser and waste hundreds of megabytes of memory instead of writing them in clean C/C++ and GTK/Qt that run natively and only use a few megabytes of memory.

You know, if we apply that phrase to medical equipment, you're going to see a massive increase in number of fatalities caused by system errors. Would you like that? No, of course!

[tildearrow]

Windows runtime for backwards compatibility scare as it sounds is growing faster than the FDo runtimes. Your maths are way off.



Installing 30 runtimes in flatpak does not grow as fast as one would first think mostly because.

Hang on :>

Everything you typed here is already implemented in flatpak.

https://ostree.readthedocs.io/en/latest/manual/formats/#static-delta-internal-structure

Flatpak sits on ostree and is already delta optimised. Ostree was designed from the ground up not to expand quickly to use delta and deduplication massively. Flatpak repository is really a front end for ostree.

Next we are not seeing org.freedesktop.Platform runtime multiply that much at all. If you have org.freedesktop.Platform 18.08.34 installed in flatpak and application now wants org.freedesktop.Platform 1.6 than is less than a 10Meg delta. There is plans to use a fuse filesystem to apply delta this will make the disc usage growth only the delta. So 30 of the same runtimes is barely 300megs+. Your largest runtime is your first runtime in each class on flatpak. Sorry 30 runtimes does not get flatpak anywhere windows SXS mess costing over 4G and growing.

Snap has the problem of growing out of control flatpak does not. Yes flatpak is growing in disc requirement but it is as slow as that is practical.

OK, great. Now I have a question.

Can I not be forced to sandbox? macOS allows to not sandbox bundles.

[josh_walrath]

So, basically you're telling me to accept that we've given up on optimizing? Because that is why we're writing applications in JavaScript and Electron that run on a browser and waste hundreds of megabytes of memory instead of writing them in clean C/C++ and GTK/Qt that run natively and only use a few megabytes of memory.

You know, if we apply that phrase to medical equipment, you're going to see a massive increase in number of fatalities caused by system errors. Would you like that? No, of course!

Medical equipment is a matter of life and death. We're talking about end user software. Let this be symptomatic of your failure to maintain sober perspective.

(And we're not even talking about lost efficiency corollary with less security or more bugs; you're just choosing that false dichotomy when, ironically, security and bugs are a huge concern if you're working with "clean" C/C++.)

Let me try again: you keep insisting that megabytes of memory are a bigger priority than productivity and availability. This is an insane misalignment of priorities. Without those browser/Electron apps you hate, we wouldn't have cross-platform solutions for some major things that I use on Linux on a daily basis. They're popular things because they work well and are easy to use and are cross-platform by design. I would sorely miss those things while pondering what to do with 90% of my 24 GBs of RAM (a majority of which barely gets touched as it is -- the humanity!). I think the same applies to the vast majority of people, whether they're l337est developers or not.

[oiaohm]

OK, great. Now I have a question.

Can I not be forced to sandbox? macOS allows to not sandbox bundles.

Its a trade off. Flatpak usage of ostree has a price.

https://ostree.readthedocs.io/en/latest/manual/adapting-existing/#system-layout

Ostree massive delta usage comes at the price that everything is container-ed by at least a chroot because the delta generated files you want read only . Also you don't have to modify libraries source code that have built time install directories in to use them.(like you configured library that it was going to be at /usr prefix and it record in a string inside itself that "/usr/share/iampain/icon.png " as the file it attempts use. Might sound stupid but making programs with hard paths to their resources then placing them in a chroot/file system namespace results in a faster running program that if you go to all the coding effort to make a program location neutral.

Its the stupidest part the lightest sandbox possible has bugger all overhead on Linux also provided bugger all security.

Nix patches binaries, source and uses symbolic linking as another option.

https://sandervanderburg.blogspot.com/2018/10/auto-patching-prebuilt-binary-software.html

Yes this patching now means binary file checksum don't match original any more. Also this is not going to be as disc effective as the ostree deltas.

There are options I see a mix of nix and flatpak providing the best possible.

MacOS not sandbox bundles are not that disc effective also they do demand that you have coded with multi location of install support.

So as I said it a tradeoff. The macOS option has a downside and the flatpak path has a downside.

[tildearrow]

Its a trade off. Flatpak usage of ostree has a price.

https://ostree.readthedocs.io/en/latest/manual/adapting-existing/#system-layout

Ostree massive delta usage comes at the price that everything is container-ed by at least a chroot because the delta generated files you want read only . Also you don't have to modify libraries source code that have built time install directories in to use them.(like you configured library that it was going to be at /usr prefix and it record in a string inside itself that "/usr/share/iampain/icon.png " as the file it attempts use. Might sound stupid but making programs with hard paths to their resources then placing them in a chroot/file system namespace results in a faster running program that if you go to all the coding effort to make a program location neutral.

Its the stupidest part the lightest sandbox possible has bugger all overhead on Linux also provided bugger all security.

Nix patches binaries, source and uses symbolic linking as another option.

https://sandervanderburg.blogspot.com/2018/10/auto-patching-prebuilt-binary-software.html

Yes this patching now means binary file checksum don't match original any more. Also this is not going to be as disc effective as the ostree deltas.

There are options I see a mix of nix and flatpak providing the best possible.

MacOS not sandbox bundles are not that disc effective also they do demand that you have coded with multi location of install support.

So as I said it a tradeoff. The macOS option has a downside and the flatpak path has a downside.

You not haved understand my question. What I ask is, can I Flatpak with no sandbox/container?

[oiaohm]

You not haved understand my question. What I ask is, can I Flatpak with no sandbox/container?

Its a trade off. Flatpak usage of ostree has a price.
Ostree massive delta usage comes at the price that everything is container-ed by at least a chroot because the delta generated files you want read only .

I did answer that please read carefully. Flatpak using ostree forces a minimal container. Without that minimal container you cannot do delta to the same level ostree/flatpak does as well.

Please note a chroot/file system namespace is not that much of a sandbox Only thing that need to be sandboxed for ostree/flatpak operations is file system access so everything else can be direct.

Please note the file system namespace protection of files also exists under windows done a different way.

https://en.wikipedia.org/wiki/Windows_Resource_Protection

Yes if you go back to windows 2000 you have Windows File Protection because you cannot have good quality applications working across multi versions of windows if third programs can go and mess up core files.

Yes OS X also has it own version of core file protection. So can I have flatpak without a sandbox is really foolish question. Part of doing cross distribution/operating system applications is securing those applications so they cannot ruin everything. If you don't use a file system sandbox you have to use something else that is even more stupid.

Can flatpak runtimes be used in a bare bones container based around ostree the answer is yes. This is really all that is important. No container/sandbox at all means not having a feature you in fact require by that route and having to do something else to cover for it like Nix modifying executable.

Basically if you really want no sandbox at all think how in heck you are going to protect the core files of the run-time to prevent 1 program modify another programs used library in the run-time. After you do this you will work out that a file system sandbox is not a major problem. Particular with how effective Linux kernel is able todo containers of this type where is basically zero overhead once program is running. There is a once off application startup cost for it...

[josh_walrath]

Basically if you really want no sandbox at all think how in heck you are going to protect the core files of the run-time to prevent 1 program modify another programs used library in the run-time. After you do this you will work out that a file system sandbox is not a major problem. Particular with how effective Linux kernel is able todo containers of this type where is basically zero overhead once program is running. There is a once off application startup cost for it...

In Fuchsia, everything's sandboxed. We won't even have these conversations. The future when?

[drownthepoor]

The other thing that's not being really talked about here, Flatpaks are designed for the desktop. Snaps were designed for Ubuntu Touch via Snapp which is now Ubuntu-Core. Ubuntu-Core is an IoT system where Snaps are a decent option for IoT. But both have become desktop solutions as well. Both Snaps and Flatpaks are flawed for desktop in their own way, but I run Ubuntu Core on my Rpi2, and it's awesome for that.

[fuzz]

The other thing that's not being really talked about here, Flatpaks are designed for the desktop. Snaps were designed for Ubuntu Touch via Snapp which is now Ubuntu-Core. Ubuntu-Core is an IoT system where Snaps are a decent option for IoT. But both have become desktop solutions as well. Both Snaps and Flatpaks are flawed for desktop in their own way, but I run Ubuntu Core on my Rpi2, and it's awesome for that.

True, but for servers docker/containers tend to be a much better solution. And now Ubuntu has to compete with Fedora CoreOS.