new stable branch of the toolkit , which provides a system for building self-contained packages that are not tied to specific Linux distributions and run in a special container, isolating the application from the rest of the system. Support for running Flatpak packages is provided for Arch Linux, , Debian, Fedora, Gentoo, Mageia, Linux Mint, and Ubuntu. Flatpak packages are included in the Fedora repository and are supported in the GNOME application management program by default.
Key In the Flatpak 1.4 branch:
- The organization of external repository configuration settings has been changed. Instead of *.conf files, regular '.flatpakrepo' files are now used in the /etc/flatpak/remotes.d directory, which are automatically imported upon first use of flatpak. These files can be freely edited and deleted, similar to manually added repositories;
- The organization of installations for system-wide available packages has been significantly changed. In earlier releases, the package was first installed in a user-specific temporary directory, and then the system-helper process was invoked to import it into the system from that directory. This approach led to high disk resource consumption, unnecessary I/O, and potential security issues. In the new version, a special new FUSE filesystem is utilized for installing system packages, allowing the user to write data, but once writing is completed, access to the written files is blocked for the user. This new approach requires creating a separate user for flatpak (by default 'flatpak') and changing SELinux rules;
- The feature to define filters for external repositories on the client system has been added. Filters can limit the applications visible in the repository using a whitelist and blacklist model;
- A library API has been added to add external repositories from flatpakref files;
- A seccomp profile for Docker has been added, allowing flatpak to run inside containers;
- Improved P2P installation capabilities from multiple sources (via USB drives or local network);
- In the command 'flatpak remote-ls', automatic filtering of applications for which support time has expired has been provided;
- 'flatpak remote-ls' and 'flatpak remote-info' now implement the '--cached' option for returning information based on local cached data;
- The ability to specify the version at which the package's lifetime will end, after which an offer to switch to a new branch will be presented, has been added;
- An option '--socket=pcsc' has been added to gain access to smart cards;
- Support for systems with multiple NVIDIA graphics cards has been added;
- Support for dconf placed in a sandbox environment has been implemented;
- The build-update-repo command has been updated to include the options "--no-update-[summary,appstream]" and "--static-delta-ignore-ref=PATTERN";
- The speed of regenerating appstream branches for large repositories has been significantly improved.
Let’s remember that Flatpak gives application developers the opportunity to simplify the distribution of their programs not included in standard distribution repositories by of a single universal container without creating separate builds for each distribution. For users concerned about security, Flatpak enables running untrusted applications in a container, granting access only to the network functionalities and user files related to the application. For users interested in the latest features, Flatpak allows installing the newest beta and stable releases of applications without requiring system modifications. For example, Flatpak packages are already for LibreOffice, Firefox, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, and more.
To reduce the package size, it only includes application-specific dependencies, while the base system and graphical libraries (Gtk+, Qt, GNOME, KDE libraries, etc.) are presented as plug-in standard runtime environments. The key distinction between Flatpak and Snap is that Snap uses components from the main system environment and isolation based on system call filtering, while Flatpak creates a container separate from the system and operates large sets of runtimes, providing standard system environments as dependencies (for example, all libraries required for running GNOME or KDE applications).
In addition to the standard system environment (runtime) installed via a special , additional dependencies (bundle) required for application operation are supplied. Together, the runtime and bundle form the contents of the container, with the runtime being installed separately and linked to several containers at once, thus avoiding duplication of shared system files among containers. Multiple different runtimes (GNOME, KDE) or several versions of one runtime (GNOME 3.26, GNOME 3.28) can be installed on one system. A container with the application as a dependency links only to a specific runtime, disregarding the individual packages that make up the runtime. All missing components are bundled directly with the application. When creating a container, the contents of the runtime are mounted as the partition /usr, while the bundle is mounted in the /app directory.
The contents of the runtime and application containers are formed using the technology , in which the image is atomically updated from a Git-like repository, allowing version control methods to be applied to distribution components (for example, the system can be quickly rolled back to a previous state). RPM packages are translated into the OSTree repository using a special layer . Separate installation and updating of packages within the working environment is not supported; the system is updated not at the level of individual components but as a whole, atomically changing its state. Tools are provided for the incremental application of updates, alleviating the need for complete image replacement with each update.
The isolated environment created is completely independent of the distribution in use, and with proper package settings, it has no access to the user's files and processes or the main system, cannot directly access hardware, except for output via DRI, and the network subsystem. The graphical output and input organization using the Wayland protocol or through X11 socket forwarding. Interaction with the external environment is based on the DBus messaging system and a special API Portals. For isolation is used and the traditional container virtualization technologies for Linux, based on the use of cgroups, namespaces, Seccomp, and SELinux. PulseAudio is used for sound output.
Source: opennet.ru
