If we skip the requirement of the .deb package, we will have more apps.
I want an app that is not available for FB nor debian. I go read the docs on how to add a new app an it all looks good except one pain point: the debian package.
Don’t take it wrong! I’m not against the packaging format, but it’s certainly a problem. Nowadays you can read lots of docs can make lots of work to create a .deb for just Debian and friends, or you can just drop in a Dockerfile and have your app running everywhere. Lowering the barrier for packagers is as important as for and users!
Support and document how to add to plinth apps packaged as an OCI image. FB could use podman.io to execute them in a secure way, or the more known but less secure Docker.
Also support and document how to find community apps and how to install them.
snaps or flatpaks. I think that for server apps, the Dockerfile is more widespread, though.
If these “containers” were not to be a disguised form of corporate binary package format, they could easily work on any distribution like the universal Nix and Guix (see “GNU Guix in other GNU/Linux distros”) package managers.
Nix looks nice. I don’t have any experience on it though. I thought of OCI images because that’s more common, and provides a good isolation out of the box.
Many server software supply official images supported upstream, and doing custom ones or distributing them is a piece of cake (if you don’t like docker hub, you have quay.io, github package registry and gitlab registry (which can be self hosted easily)).
It would let freedom box apps evolve at a faster or slower pace than debian.
Regarding storage, if official apps remain as .deb, it shouldn’t be a problem. Those being packaged as images would share lowest layers, so in many cases they wouldn’t increase required space so much.
Finally, I don’t understand about “handling access to resources”. With normal volume mounts and ports publishing you’d be done for most (if not all) cases.
Anyways… is it really possible to add a plinth app like this? If so, I don’t think documenting it would harm.
First, the requirement for FreedomBox would be that software packages can run several CPU architectures: x86 64 bit, ARM 32 and 64 bit. Not all projects (server softare) publish images for all the CPU architectures supported by FreedomBox, therefore you have to make custom images.
Second, in case a container does not work as expected, people will blame FreedomBox. Some will blame it, others are more constructive and will ask in this forum for help or even provide patches. Again, FreedomBox can only solve this by providing tested custom images.
Third, you have to take care of the configuration, security and integration into FreedomBox of each containerized application. Otherwise you end up with a difficult to manage zoo of containers.
Fourth, to build containers you need a build farm or something similar, unless you want to do it by hand. As you pointed out, GitLab has a container registry. Debian Salsa, where FreedomBox is hosted is a GitLab instance. In addition, I think GitLab allows you to configure a pipeline. The infrastructure is probably in place to build containers, but you would still need to setup everything and make sure it works.
Fifth, I do not trust any container I get from some community member. Maybe, that community member is evil and build some backdoor into the container. I want to see the build script and understand how the image was build. I want to be able to rebuild the container (for more information have a look at https://reproducible-builds.org/).
Lastly, you still need an operating system to build a container from. What would you use? Debian, but then what is the benefit? You still have to package you app at the end to make it convenient for users to install.
Only in case you build your app against Debian testing or unstable. Alternatively, you could install it or compile it directly from the code base of the application in question. The last part is what many “official images” of projects (server software) do.
As @NickA pointed out solutions like Guix are probably the better tool to solve the problem you describe. Using Guix and containers is not mutually exclusive. It is possible to build containers and containers in the docker format using Guix: Creating bundles with guix pack.
Well, there’s the https://linuxserver.io project, whose packages are built in many arches, and are suited for single-server usage, just like the FreedomBox approach. It might be a good complement for FB.
Apart from that I find the nix stuff interesting. I never paid attention to that because I thought it was unnecessary in a world full of containers, but if it fixes these problems it might be a good alternative too.