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

[szymon_g]

You mean you miss to give random scripts from someone root access to your operating system? Windows installers are basically the unix equivalent of "curl http://my.script | sudo bash". No thank you.

you talk as if linux package installation was in any way safer.
but hey, super-secure linux doesn't allow you for an easy and dumbproof protection of important folders within $HOME.

but, hey, as long as they cannot load an extra kernel module it's fine, right?

[mppix]

Well then I'm not one of such users. Personally, I don't even like sandboxed software even if it's proprietary because I'm against hindering usability in the name of security. I also don't have problem downloading random binaries from the internet because I trust all the software I use.

w95 user?

[mppix]

you talk as if linux package installation was in any way safer.
but hey, super-secure linux doesn't allow you for an easy and dumbproof protection of important folders within $HOME.

but, hey, as long as they cannot load an extra kernel module it's fine, right?

unfortunately "dumbproof protection of important folders within $HOME" requires you to create a zip archive with password that you unpack and recreate every time that you access it

Alternatively, if your can remove the "dumb" part from the equation, you could also:
- right-click -> properties -> permissions
- chmod and or chown commands if you don't use a GUI
- setup an encrypted folder that you mount/unmount for access (say cryfs)
- encrypt you entire disk or home folder
- ACL

[ngraham]

Well that's pretty much the end of Snap IMO.

Anytime a project is announced to build the next generation of a thing from scratch and deprecate the old version, it's a very dangerous time. The team is split between maintenance and new stuff and each becomes overworked. The old version stagnates while the new version takes much longer to build than anyone anticipated, and the first release is terrible. I've seen many projects fail to survive this trauma. KDE almost suffered this fate with KDE 4 and survived badly damaged, consuming a great deal of its historical goodwill and popularity in the process. But Snap doesn't have any of that goodwill and popularity to keep it afloat. I don't see it surviving.

[tildearrow]

The problems with Flatpak and Snap are:
- sandboxing is mandatory and there is no way to have a non-sandboxed Flatpak/Snap application
- feels more Android/iOS-like than desktop-like with all the layers you have to go through just to read a file (hundreds of lines of code to open a file vs. one without it)

The problems with AppImage is:
- no standard for organizing/installing AppImages. appimaged, AppImageLauncher, just move them to a directory like /opt, etc.
- it has less fame than the other two only because a corporation didn't create it
- bigger than macOS bundles due to the mess Linux user-space is in most distributions
- doesn't fully resolve EWLSLlCOSOFNSFoDoD ("error while loading shared libraries: libsomething.so.1: cannot open shared object file: No such file or directory of death") problem. I've had the VSCodium AppImage fail after a pacman -Syu and I was forced to manually patch the AppImage to get it working again, and even so I still cannot run CMake from the VSCodium terminal since it fails with "cmake: /opt/vscodium/lib/x86_64-linux-gnu/liblzma.so.5: version `XZ_5.2' not found (required by /usr/lib/libarchive.so.13)"
- Sadly, this is something that's very difficult to fix, and the problem resides on the linker (ld.so). Weasel explained this to some degree in several posts from years ago, but even he is partially wrong as he thinks the problem is in ELF and not the linker. Here it is:

With ELF, it's like placing all symbols as global variables, while with DLL, it's like placing them each in their own separate class or namespace, given by the module. e.g.

// ELF
symbolA;
symbolB;
symbolC;

symbolA; <-- conflict


// DLL
namespace module1
{
symbolA
symbolB
}
namespace module2
{
symbolC
}
namespace module3
{
symbolA
symbolC
}

You know, it doesn't really take so long to realize which one is vastly superior here.

The former is a complete total spaghetti mess and extremely fragile the more libraries you pull in. Now try it with loading the same library but different versions: DLL has no conflict (separate namespaces) while with ELF it's guaranteed to conflict.

ELF is like: "here's a bunch of libraries to import, here's a bunch of symbols to import"
DLL is like: "here's a bunch of libraries to import; then within each such library, here's what symbols to import from it"

Windows app->gtk2->libfoo->gtk3->no symbol conflict.
Linux app->gtk2->libfoo->gtk3->conflict and crash.

Because of ELF and the fact that everything is compiled with global namespace, of course. You don't control the entire dependency chain unless you supply the entire runtime which is what flatpak does.

And here are three holy wars on this issue.

[oiaohm]

Well that's pretty much the end of Snap IMO.

Anytime a project is announced to build the next generation of a thing from scratch and deprecate the old version, it's a very dangerous time. The team is split between maintenance and new stuff and each becomes overworked. The old version stagnates while the new version takes much longer to build than anyone anticipated, and the first release is terrible. I've seen many projects fail to survive this trauma. KDE almost suffered this fate with KDE 4 and survived badly damaged, consuming a great deal of its historical goodwill and popularity in the process. But Snap doesn't have any of that goodwill and popularity to keep it afloat. I don't see it surviving.

Snap legacy has had many fundamental flaws. Usage of loopback has caused on going performance issues for snap legacy and this is a big one.

Snap legacy is in a different location to KDE 3. KDE 3 was liked to the point people forked the code base to keep it alive. I don't see anyone forking snap legacy to keep it live because it is fairly much hated.

I might be surprised but I don't think we are going to see them support using your own repository/store like flatpak does.

[oiaohm]

The problems with Flatpak and Snap are:
- sandboxing is mandatory and there is no way to have a non-sandboxed Flatpak/Snap application
- feels more Android/iOS-like than desktop-like with all the layers you have to go through just to read a file (hundreds of lines of code to open a file vs. one without it)

Snap legacy has a stack more issues than Flatpak does lot come from the choice to use loopback.

The problems with AppImage is:
- no standard for organizing/installing AppImages. appimaged, AppImageLauncher, just move them to a directory like /opt, etc.
- it has less fame than the other two only because a corporation didn't create it

https://avidemux.org/smif/index.php?topic=19475.0

No there is the on going problem of appimages not working due to some system provided library not being there or being wrong for what the Appimage expects.

Sandbox controlled runtime of flatpak and snap by sandbox does have its advantages of making the runtime to applications predictable.

I would say that AppImage is not ideal either.

[tildearrow]

No there is the on going problem of appimages not working due to some system provided library not being th-

Wait, wait wait. I was completing the post. ;p

[You-]

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.

I think you have experienced the beauty of some of the flatpaks without even realising here: Apps can be both sandboxed and not require a dialogue to grant permission.

An example is to select a file, you get a portal file selector. Choosing a file with it automatically grants you the permission to use that file. Because you selected it. You do not need another dialog to ask you what you have already chosen is ok.

With other choices, like screencapture, the permission is only partially hidden - you get an option to choose screen/area/app to capture. If done properly, it wont feel like a confirm dialogue, but when existing apps used it, it may feel like another confirm dialogue.

Camera/microphone etc will probably feel opaque with you having to grant permission when those portals are ready and in use.

(There are also built in sandbox holes to allow access for things where portals are not yet ready or dont fit, but over time hopefully those will be closed.)

[oiaohm]

The problems with Flatpak and Snap are:

Weasel[/B]]Windows app->gtk2->libfoo->gtk3->no symbol conflict.
Linux app->gtk2->libfoo->gtk3->conflict and crash.
Because of ELF and the fact that everything is compiled with global namespace, of course. You don't control the entire dependency chain unless you supply the entire runtime which is what flatpak does.

And here are three holy on this issue.

Yes there might have been 3 holy wars on the issue but that does not stop errors.

https://manpages.debian.org/testing/manpages-dev/dlmopen.3.en.html

The reality is the ELF format does not mandate everything in a global namespace this is way dlmopen works. Reality with ELF you can have a many namespaces as you like as long as the ELF dynamic loader plays ball. Solaris ELF loader could avoid the symbol conflict.

Solaris app->gtk2->libfoo->gtk3->no symbol conflict and its a ELF system if you build with the right flags. What those flags have added is STT_FIle entries into the ELF dynamic loader table and the Solaris dynamic loader takes the existence of this to perform Segregated Dynamic Linking. Linux libc dynamic loaders don't have this be it glibc or musl.

Yet there is a funny one Linux app->gtk2->libfoo->libfoo->gtk3 no symbol conflict.

That libfoo typed twice is not a mistake. If you have made a libcapsule version of the library it works. Yes the first libfoo is a shim using ufunc and dlmopen.

https://people.collabora.com/~vivek/dynamic-linking/segregated-dynamic-linking.pdf

The reality is the ELF loaders on Linux are quite feature poor.

Yes the libcapsule work done 2017/2018 found that the belief that ELF had to be a single global namespace was not true. Single global namespace is the lazy way to implement a elf loader. PE format does in fact have cases where its used only with a single global namespace as well fun of different UEFI implementations.

Yes glibc elf loader today with dlmopen does support multi namespaces. But we still cannot do a build flag to say these imports come from X libraries must be in different namespace so you must use wrapper libraries.

The reality of libcapsule it would be possible for appimage to contain a stack of proxy libraries that could process a xattr/environmental var on the program to say where to find the runtime. So allowing independent runtime to system to be installed.

The single global namespace of elf is a lie as a limitation of the design. Elf design support multi namespaces just the common elf loaders default to using only one even when they support multi-able so causing hell. Yes PE onwindows yes it also does segregated loading but when you get into UEFI the UEFI loader PE can be simplified the same way as the glibc/musl ELF loaders on Linux leading to the same cases of symbol conflict.